From daniel.odonnell at uleth.ca Fri Jan 1 14:26:57 2010 From: daniel.odonnell at uleth.ca (O'Donnell, Dan) Date: Fri, 01 Jan 2010 12:26:57 -0700 Subject: [tei-council] Anybody attending the AHA? Message-ID: <4B3E4C81.8090509@uleth.ca> Hi all, I have a request from somebody on a large historical project whether there might be somebody from the TEI attending the conference of the American Historical Association next week (7-9 Jan.). They hadn't heard about the TEI before and are about to begin a major digitization project. If you could let me know, I can pass on the details. -dan -- Daniel Paul O'Donnell Associate Professor of English University of Lethbridge Chair and CEO, Text Encoding Initiative (http://www.tei-c.org/) Co-Chair, Digital Initiatives Advisory Board, Medieval Academy of America President-elect (English), Society for Digital Humanities/Soci?t? pour l'?tude des m?dias interactifs (http://sdh-semi.org/) Founding Director (2003-2009), Digital Medievalist Project (http://www.digitalmedievalist.org/) Vox: +1 403 329-2377 Fax: +1 403 382-7191 (non-confidental) Home Page: http://people.uleth.ca/~daniel.odonnell/ From mholmes at uvic.ca Tue Jan 5 10:18:56 2010 From: mholmes at uvic.ca (Martin Holmes) Date: Tue, 05 Jan 2010 07:18:56 -0800 Subject: [tei-council] next face to face meeting In-Reply-To: <5EF8BE4D-1AC7-48AC-BCC4-243BF129C1C5@loria.fr> References: <5EF8BE4D-1AC7-48AC-BCC4-243BF129C1C5@loria.fr> Message-ID: <4B435860.4040105@uvic.ca> Hi all, I'd like to get some details of the face-to-face in April as soon as possible, because my trip will be international and I'd like to book it soon. I've never been to Dublin, so suggestions on where we could stay, where we'll be meeting, and how to get there from the airport would be helpful. All the best, Martin Laurent Romary wrote: > I have just issued a meeting request on Meeting Wizard, which you > should all of you (young or old members) have received. Please respond > as quickly as possible and do think of sending me your most urgent > agenda items! > > We have also set our next face to face meeting to be hold in Dublin on > 28-30 April. Please book these dates which have been quite hard to > set. One of the three days will be dedicated to a local seminar as > usual. I will tell you more on this as soon as possible. Thanks very > much to Susan Schreibman and DHO for taking care of local organisation. > > Laurent > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council From susan.schreibman at gmail.com Tue Jan 5 10:21:51 2010 From: susan.schreibman at gmail.com (Susan Schreibman) Date: Tue, 05 Jan 2010 15:21:51 +0000 Subject: [tei-council] next face to face meeting In-Reply-To: <4B435860.4040105@uvic.ca> References: <5EF8BE4D-1AC7-48AC-BCC4-243BF129C1C5@loria.fr> <4B435860.4040105@uvic.ca> Message-ID: <4B43590F.30907@gmail.com> just a quick reply Martin -- re accommodation -- we're going to block book a hotel for Council members in the city centre. Getting to the hotel will be very easy (there are several airport bus options). When we have someplace sorted will send out further directions. susan Martin Holmes wrote: > Hi all, > > I'd like to get some details of the face-to-face in April as soon as > possible, because my trip will be international and I'd like to book it > soon. I've never been to Dublin, so suggestions on where we could stay, > where we'll be meeting, and how to get there from the airport would be > helpful. > > All the best, > Martin > > Laurent Romary wrote: > >> I have just issued a meeting request on Meeting Wizard, which you >> should all of you (young or old members) have received. Please respond >> as quickly as possible and do think of sending me your most urgent >> agenda items! >> >> We have also set our next face to face meeting to be hold in Dublin on >> 28-30 April. Please book these dates which have been quite hard to >> set. One of the three days will be dedicated to a local seminar as >> usual. I will tell you more on this as soon as possible. Thanks very >> much to Susan Schreibman and DHO for taking care of local organisation. >> >> Laurent >> >> _______________________________________________ >> tei-council mailing list >> tei-council at lists.village.Virginia.EDU >> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council >> > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > -- Susan Schreibman, PhD Director Digital Humanities Observatory Pembroke House 28-32 Upper Pembroke Street Dublin 2, Ireland -- A Project of the Royal Irish Academy -- Phone: +353 1 234 2440 Fax: +353 1 234 2400 Mobile: +353 86 049 1966 Email: susan.schreibman at gmail.com Email: s.schreibman at ria.ie http://dho.ie http://irith.org http://macgreevy.org http://v-machine.org From kevin.s.hawkins at ultraslavonic.info Tue Jan 5 10:22:36 2010 From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins) Date: Tue, 05 Jan 2010 15:22:36 +0000 Subject: [tei-council] next face to face meeting In-Reply-To: <4B435860.4040105@uvic.ca> References: <5EF8BE4D-1AC7-48AC-BCC4-243BF129C1C5@loria.fr> <4B435860.4040105@uvic.ca> Message-ID: <4B43593C.500@ultraslavonic.info> Hi Martin, Emily Cullen, my colleague here at the DHO in Dublin, is as we speak working on booking a room block for everyone. We'll also provide additional information on travel logistics as soon as we can pull it together. Kevin Martin Holmes wrote: > Hi all, > > I'd like to get some details of the face-to-face in April as soon as > possible, because my trip will be international and I'd like to book it > soon. I've never been to Dublin, so suggestions on where we could stay, > where we'll be meeting, and how to get there from the airport would be > helpful. > > All the best, > Martin > > Laurent Romary wrote: >> I have just issued a meeting request on Meeting Wizard, which you >> should all of you (young or old members) have received. Please respond >> as quickly as possible and do think of sending me your most urgent >> agenda items! >> >> We have also set our next face to face meeting to be hold in Dublin on >> 28-30 April. Please book these dates which have been quite hard to >> set. One of the three days will be dedicated to a local seminar as >> usual. I will tell you more on this as soon as possible. Thanks very >> much to Susan Schreibman and DHO for taking care of local organisation. >> >> Laurent >> >> _______________________________________________ >> tei-council mailing list >> tei-council at lists.village.Virginia.EDU >> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council From laurent.romary at loria.fr Tue Jan 5 10:25:03 2010 From: laurent.romary at loria.fr (Laurent Romary) Date: Tue, 5 Jan 2010 16:25:03 +0100 Subject: [tei-council] next face to face meeting In-Reply-To: <4B435860.4040105@uvic.ca> References: <5EF8BE4D-1AC7-48AC-BCC4-243BF129C1C5@loria.fr> <4B435860.4040105@uvic.ca> Message-ID: <57DA1299-4717-4FEE-826E-E5BAEE1F1BDE@loria.fr> Hi Martin, Kevin and I have planned a Skype tomorrow to discuss the main aspects of the planned meeting. I should come back afterwards with more details. Best, Laurent Le 5 janv. 10 ? 16:18, Martin Holmes a ?crit : > Hi all, > > I'd like to get some details of the face-to-face in April as soon as > possible, because my trip will be international and I'd like to book > it > soon. I've never been to Dublin, so suggestions on where we could > stay, > where we'll be meeting, and how to get there from the airport would be > helpful. > > All the best, > Martin > > Laurent Romary wrote: >> I have just issued a meeting request on Meeting Wizard, which you >> should all of you (young or old members) have received. Please >> respond >> as quickly as possible and do think of sending me your most urgent >> agenda items! >> >> We have also set our next face to face meeting to be hold in Dublin >> on >> 28-30 April. Please book these dates which have been quite hard to >> set. One of the three days will be dedicated to a local seminar as >> usual. I will tell you more on this as soon as possible. Thanks very >> much to Susan Schreibman and DHO for taking care of local >> organisation. >> >> Laurent >> >> _______________________________________________ >> tei-council mailing list >> tei-council at lists.village.Virginia.EDU >> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council From laurent.romary at loria.fr Tue Jan 5 10:32:43 2010 From: laurent.romary at loria.fr (Laurent Romary) Date: Tue, 5 Jan 2010 16:32:43 +0100 Subject: [tei-council] A new year for the council! Message-ID: <68804417-6D10-4721-8F6A-7FD4AA071019@loria.fr> Dear all (but more specifically Paul, David, Peter and Manfred...), As the 1st of January has passed, we now have to say good bye to the council members whose term has come to an end, namely David Sewell, Paul Schaffner, Peter Boot and Manfred Thaller. Thank you all for your contributions, experience and above all enthusiasm which have raised the working standard of the council to such a high level. I guess you will all carry on spreading the TEI gospel and keep providing contributions to the TEI framework through the general list. Amicalement, Laurent From pfs-listmail at umich.edu Tue Jan 5 10:38:08 2010 From: pfs-listmail at umich.edu (Paul F. Schaffner) Date: Tue, 5 Jan 2010 10:38:08 -0500 (EST) Subject: [tei-council] A new year for the council! In-Reply-To: <68804417-6D10-4721-8F6A-7FD4AA071019@loria.fr> References: <68804417-6D10-4721-8F6A-7FD4AA071019@loria.fr> Message-ID: Thank you, and good luck. (Don't worry: you haven't heard the last from me.) pfs On Tue, 5 Jan 2010, Laurent Romary wrote: > Dear all (but more specifically Paul, David, Peter and Manfred...), > As the 1st of January has passed, we now have to say good bye to the > council members whose term has come to an end, namely David Sewell, > Paul Schaffner, Peter Boot and Manfred Thaller. Thank you all for your > contributions, experience and above all enthusiasm which have raised > the working standard of the council to such a high level. I guess you > will all carry on spreading the TEI gospel and keep providing > contributions to the TEI framework through the general list. > Amicalement, > Laurent > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > > > -------------------------------------------------------------------- Paul Schaffner | PFSchaffner at umich.edu | http://www.umich.edu/~pfs/ 316-C Hatcher Library N, Univ. of Michigan, Ann Arbor MI 48109-1205 -------------------------------------------------------------------- From dsewell at virginia.edu Tue Jan 5 10:42:29 2010 From: dsewell at virginia.edu (David Sewell) Date: Tue, 5 Jan 2010 10:42:29 -0500 (EST) Subject: [tei-council] A new year for the council! In-Reply-To: <68804417-6D10-4721-8F6A-7FD4AA071019@loria.fr> References: <68804417-6D10-4721-8F6A-7FD4AA071019@loria.fr> Message-ID: I am just about to say "goodbye, cruel world" by removing myself and the other retiring members from the tei-council list. (Remember that the list archives are public, so if you start talking about us behind our backs we will find out!) However, I remain list administrator for the email lists hosted at Virginia (tei-council, tei-board) and am also taking over TEI Webmaster duties from Chris Ruotolo this year. (If you saw her at the TEI Meeting this is not news, but she is expecting her first baby in the near future and will be taking a long maternity leave.) So please continue to report to me any problems or requests concerning the list or the website. Good luck to all, David On Tue, 5 Jan 2010, Laurent Romary wrote: > Dear all (but more specifically Paul, David, Peter and Manfred...), > As the 1st of January has passed, we now have to say good bye to the > council members whose term has come to an end, namely David Sewell, > Paul Schaffner, Peter Boot and Manfred Thaller. Thank you all for your > contributions, experience and above all enthusiasm which have raised > the working standard of the council to such a high level. I guess you > will all carry on spreading the TEI gospel and keep providing > contributions to the TEI framework through the general list. > Amicalement, > Laurent > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > -- David Sewell, Editorial and Technical Manager ROTUNDA, The University of Virginia Press PO Box 801079, Charlottesville, VA 22904-4318 USA Courier: 310 Old Ivy Way, Suite 302, Charlottesville VA 22903 Email: dsewell at virginia.edu Tel: +1 434 924 9973 Web: http://rotunda.upress.virginia.edu/ From laurent.romary at loria.fr Wed Jan 6 05:01:29 2010 From: laurent.romary at loria.fr (Laurent Romary) Date: Wed, 6 Jan 2010 11:01:29 +0100 Subject: [tei-council] Attendance plans for our next TEI council meeting Message-ID: <6B71F257-9288-49E3-8D39-4440A673AAE8@loria.fr> Dear all, Following the call I have just had with Kevin, our Dublin organizers would like to have a more precise idea of the actual number of rooms to be booked in the context of our F2F meeting. As you know, the meeting will take place on 28-30 April, starting with a one day Symposium followed by the actual close council meeting. Could you all send me a note as to your rough travel plans (date of arrival, date of departure) so that we get a first estimate of the number of rooms to be booked. Thanks in advance, Laurent From James.Cummings at oucs.ox.ac.uk Wed Jan 6 05:15:29 2010 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Wed, 06 Jan 2010 10:15:29 +0000 Subject: [tei-council] Attendance plans for our next TEI council meeting In-Reply-To: <6B71F257-9288-49E3-8D39-4440A673AAE8@loria.fr> References: <6B71F257-9288-49E3-8D39-4440A673AAE8@loria.fr> Message-ID: <4B4462C1.6000007@oucs.ox.ac.uk> What time is the Symposium starting on the 28th? (Just trying to judge whether I need to fly on the 27th or just early morning on the 28th.) -James Laurent Romary wrote: > Dear all, > Following the call I have just had with Kevin, our Dublin organizers > would like to have a more precise idea of the actual number of rooms > to be booked in the context of our F2F meeting. As you know, the > meeting will take place on 28-30 April, starting with a one day > Symposium followed by the actual close council meeting. > Could you all send me a note as to your rough travel plans (date of > arrival, date of departure) so that we get a first estimate of the > number of rooms to be booked. > Thanks in advance, > Laurent > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council From laurent.romary at loria.fr Wed Jan 6 05:32:46 2010 From: laurent.romary at loria.fr (Laurent Romary) Date: Wed, 6 Jan 2010 11:32:46 +0100 Subject: [tei-council] Attendance plans for our next TEI council meeting In-Reply-To: <4B4462C1.6000007@oucs.ox.ac.uk> References: <6B71F257-9288-49E3-8D39-4440A673AAE8@loria.fr> <4B4462C1.6000007@oucs.ox.ac.uk> Message-ID: <345ED5DA-6591-4712-9AF8-DAB277A515E9@loria.fr> .... [iterating with Dubliners] ... we're set for a start at 10.00! Le 6 janv. 10 ? 11:15, James Cummings a ?crit : > > What time is the Symposium starting on the 28th? (Just trying to > judge whether I need to fly on the 27th or just early morning on the > 28th.) > > -James > > > Laurent Romary wrote: >> Dear all, >> Following the call I have just had with Kevin, our Dublin >> organizers would like to have a more precise idea of the actual >> number of rooms to be booked in the context of our F2F meeting. As >> you know, the meeting will take place on 28-30 April, starting >> with a one day Symposium followed by the actual close council >> meeting. >> Could you all send me a note as to your rough travel plans (date >> of arrival, date of departure) so that we get a first estimate of >> the number of rooms to be booked. >> Thanks in advance, >> Laurent >> _______________________________________________ >> tei-council mailing list >> tei-council at lists.village.Virginia.EDU >> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > From lou.burnard at oucs.ox.ac.uk Thu Jan 14 11:44:38 2010 From: lou.burnard at oucs.ox.ac.uk (Lou) Date: Thu, 14 Jan 2010 16:44:38 +0000 Subject: [tei-council] oops... Message-ID: <4B4F49F6.8060706@oucs.ox.ac.uk> According to http://www.tei-c.org/Activities/Council/Meetings/tcm43.xml, which Sebastian has just reminded me about, we were supposed to be having another TEI council call this week. (It says "Agreed to reconvene in w/s January 11th"). Well, we haven't yet and it looks a bit unlikely tomorrow, so I'm wondering if anyone feels up to fixing a date for a quick call in the next couple of weeks? Or whether it should slip into February? From mholmes at uvic.ca Thu Jan 14 13:20:43 2010 From: mholmes at uvic.ca (Martin Holmes) Date: Thu, 14 Jan 2010 10:20:43 -0800 Subject: [tei-council] oops... In-Reply-To: <4B4F49F6.8060706@oucs.ox.ac.uk> References: <4B4F49F6.8060706@oucs.ox.ac.uk> Message-ID: <4B4F607B.8000500@uvic.ca> The week of Jan 25 is good for me, and should give most of us time to do a bit of prep. Any day, assuming it's early in my day and late for the Europeans (between three and six pm GMT). Cheers, Martin Lou wrote: > According to http://www.tei-c.org/Activities/Council/Meetings/tcm43.xml, > which Sebastian has just reminded me about, we were supposed to be > having another TEI council call this week. (It says "Agreed to reconvene > in w/s January 11th"). > > Well, we haven't yet and it looks a bit unlikely tomorrow, so I'm > wondering if anyone feels up to fixing a date for a quick call in the > next couple of weeks? Or whether it should slip into February? > > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > -- Martin Holmes University of Victoria Humanities Computing and Media Centre (mholmes at uvic.ca) Half-Baked Software, Inc. (mholmes at halfbakedsoftware.com) martin at mholmes.com From dot.porter at gmail.com Thu Jan 14 17:09:36 2010 From: dot.porter at gmail.com (Dot Porter) Date: Thu, 14 Jan 2010 17:09:36 -0500 Subject: [tei-council] oops... In-Reply-To: <4B4F607B.8000500@uvic.ca> References: <4B4F49F6.8060706@oucs.ox.ac.uk> <4B4F607B.8000500@uvic.ca> Message-ID: <96f3df641001141409x68480ebbnda0448c8bdc2dfe2@mail.gmail.com> I'm only available the 27th-29th that week but my schedule those days is open. Dot On Thu, Jan 14, 2010 at 1:20 PM, Martin Holmes wrote: > The week of Jan 25 is good for me, and should give most of us time to do > a bit of prep. Any day, assuming it's early in my day and late for the > Europeans (between three and six pm GMT). > > Cheers, > Martin > > Lou wrote: >> According to http://www.tei-c.org/Activities/Council/Meetings/tcm43.xml, >> which Sebastian has just reminded me about, we were supposed to be >> having another TEI council call this week. (It says "Agreed to reconvene >> in w/s January 11th"). >> >> Well, we haven't yet and it looks a bit unlikely tomorrow, so I'm >> wondering if anyone feels up to fixing a date for a quick call in the >> next couple of weeks? Or whether it should slip into February? >> >> >> _______________________________________________ >> tei-council mailing list >> tei-council at lists.village.Virginia.EDU >> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council >> > > -- > Martin Holmes > University of Victoria Humanities Computing and Media Centre > (mholmes at uvic.ca) > Half-Baked Software, Inc. > (mholmes at halfbakedsoftware.com) > martin at mholmes.com > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > -- *~*~*~*~*~*~*~*~*~*~* Dot Porter (MA, MSLS) Metadata Manager (on leave) Digital Humanities Observatory (RIA), Regus House, 28-32 Upper Pembroke Street, Dublin 2, Ireland -- A Project of the Royal Irish Academy -- Phone: +353 1 234 2444 Fax: +353 1 234 2400 http://dho.ie Email: dot.porter at gmail.com *~*~*~*~*~*~*~*~*~*~* From laurent.romary at loria.fr Thu Jan 14 22:40:00 2010 From: laurent.romary at loria.fr (Laurent Romary) Date: Fri, 15 Jan 2010 04:40:00 +0100 Subject: [tei-council] oops... In-Reply-To: <4B4F49F6.8060706@oucs.ox.ac.uk> References: <4B4F49F6.8060706@oucs.ox.ac.uk> Message-ID: <979E9D46-E9FA-4773-9403-A0B3101DBAC4@loria.fr> My fault there, but I did take holidays over Christmas and this has piled up. I'll send an inquiry on this when I have recovered from jetlag here in Hong Kong. Setting a date by email is a pain, anyhow. Laurent Le 14 janv. 10 ? 17:44, Lou a ?crit : > According to http://www.tei-c.org/Activities/Council/Meetings/tcm43.xml > , > which Sebastian has just reminded me about, we were supposed to be > having another TEI council call this week. (It says "Agreed to > reconvene > in w/s January 11th"). > > Well, we haven't yet and it looks a bit unlikely tomorrow, so I'm > wondering if anyone feels up to fixing a date for a quick call in the > next couple of weeks? Or whether it should slip into February? > > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council From lou.burnard at oucs.ox.ac.uk Fri Jan 15 09:35:01 2010 From: lou.burnard at oucs.ox.ac.uk (Lou) Date: Fri, 15 Jan 2010 14:35:01 +0000 Subject: [tei-council] [Fwd: [ tei-Bugs-2932853 ] TEI/@version] Message-ID: <4B507D15.1060806@oucs.ox.ac.uk> Any thoughts on this one? I am minded to change the datatype to data.enumerated (though that leaves open the question of how to specify a closed set of numeric values) -------------- next part -------------- An embedded message was scrubbed... From: SourceForge.net Subject: [ tei-Bugs-2932853 ] TEI/@version Date: Fri, 15 Jan 2010 14:02:04 +0000 Size: 4455 Url: http://lists.village.Virginia.EDU/pipermail/tei-council/attachments/20100115/40c3f996/attachment.eml From gabriel.bodard at kcl.ac.uk Fri Jan 15 10:52:37 2010 From: gabriel.bodard at kcl.ac.uk (Gabriel Bodard) Date: Fri, 15 Jan 2010 15:52:37 +0000 Subject: [tei-council] [Fwd: [ tei-Bugs-2932853 ] TEI/@version] In-Reply-To: <4B507D15.1060806@oucs.ox.ac.uk> References: <4B507D15.1060806@oucs.ox.ac.uk> Message-ID: <4B508F45.1020308@kcl.ac.uk> Seems reasonable. Is there some reason that values like, "5.1.0", "5.1.2" would be more problematic to constrain than "elephant", "kangaroo", etc.? Lou a ?crit : > Any thoughts on this one? I am minded to change the datatype to > data.enumerated (though that leaves open the question of how to specify > a closed set of numeric values) > -- Dr Gabriel BODARD (Epigrapher & Digital Classicist) Centre for Computing in the Humanities King's College London 26-29 Drury Lane London WC2B 5RL Email: gabriel.bodard at kcl.ac.uk Tel: +44 (0)20 7848 1388 Fax: +44 (0)20 7848 2980 http://www.digitalclassicist.org/ http://www.currentepigraphy.org/ From mholmes at uvic.ca Fri Jan 15 11:25:28 2010 From: mholmes at uvic.ca (Martin Holmes) Date: Fri, 15 Jan 2010 08:25:28 -0800 Subject: [tei-council] [Fwd: [ tei-Bugs-2932853 ] TEI/@version] In-Reply-To: <4B507D15.1060806@oucs.ox.ac.uk> References: <4B507D15.1060806@oucs.ox.ac.uk> Message-ID: <4B5096F8.2010908@uvic.ca> HI Lou, It's directly analogous to application/@version, which has a nice regexp that Syd and I put together: [\d]+[a-z]*[\d]*(\.[\d]+[a-z]*[\d]*){0,3} token { pattern = "[\d]+[a-z]*[\d]*(\.[\d]+[a-z]*[\d]*){0,3}" } I'd suggest merging these two attributes, which already have the same name. Cheers, Martin Lou wrote: > Any thoughts on this one? I am minded to change the datatype to > data.enumerated (though that leaves open the question of how to specify > a closed set of numeric values) > > > > ------------------------------------------------------------------------ > > Subject: > [ tei-Bugs-2932853 ] TEI/@version > From: > SourceForge.net > Date: > Fri, 15 Jan 2010 06:02:04 -0800 > To: > "noreply at sourceforge.net" > > To: > "noreply at sourceforge.net" > > > Bugs item #2932853, was opened at 2010-01-15 13:07 > Message generated for change (Comment added) made by louburnard > You can respond by visiting: > https://sourceforge.net/tracker/?func=detail&atid=644062&aid=2932853&group_id=106328 > > Please note that this message will contain a full copy of the comment thread, > including the initial issue submission, for this request, > not just the latest update. > Category: TEI: Definition of Elements/Attributes/Classes > Group: AMBER > Status: Open > Resolution: None > Priority: 5 > Private: No > Submitted By: Ian Rons (ianrons) > Assigned to: Nobody/Anonymous (nobody) > Summary: TEI/@version > > Initial Comment: > TEI/@version is an xsd:decimal, but TEI version numbers aren't decimals, e.g. "1.5.0". Can I suggest changing this to something more applicable, perhaps data.enumerated. This would allow a limited range of values, and could even be reduced to one (the current value), thus causing a validation error if one attempts to validate against the wrong TEI schema version. > > ---------------------------------------------------------------------- > >> Comment By: Lou Burnard (louburnard) > Date: 2010-01-15 14:02 > > Message: > When defined, this attribute was for the base version of the Guidelines as > a whole (e.g. P5 as opposed to P4), and we had not yet set in place the > programme of regular version releases. It would certainly make sense for > this now to be used for point release numbers e.g. 5.1.2 > > Your suggestion of making it data.enumerated is a good one, since it would > permit projects to define explicitly the versions for which a given > document is valid in their project ODD. Let's see what the Council > thinks... > > ---------------------------------------------------------------------- > > You can respond by visiting: > https://sourceforge.net/tracker/?func=detail&atid=644062&aid=2932853&group_id=106328 > -- Martin Holmes University of Victoria Humanities Computing and Media Centre (mholmes at uvic.ca) Half-Baked Software, Inc. (mholmes at halfbakedsoftware.com) martin at mholmes.com From lou.burnard at oucs.ox.ac.uk Fri Jan 15 11:58:09 2010 From: lou.burnard at oucs.ox.ac.uk (Lou) Date: Fri, 15 Jan 2010 16:58:09 +0000 Subject: [tei-council] [Fwd: [ tei-Feature Requests-2910712 ] reappraisal of author, editor, and respStmt] Message-ID: <4B509EA1.8080709@oucs.ox.ac.uk> I think the discussion in this ticket addresses the Action in tcm43, and I'd like Council to express a view as to whether or not the action taken is sufficient to warrant now closing the ticket. -------------- next part -------------- An embedded message was scrubbed... From: SourceForge.net Subject: [ tei-Feature Requests-2910712 ] reappraisal of author, editor, and respStmt Date: Fri, 15 Jan 2010 16:55:47 +0000 Size: 8629 Url: http://lists.village.Virginia.EDU/pipermail/tei-council/attachments/20100115/2ef21aaf/attachment.eml From lou.burnard at oucs.ox.ac.uk Fri Jan 15 12:07:04 2010 From: lou.burnard at oucs.ox.ac.uk (Lou) Date: Fri, 15 Jan 2010 17:07:04 +0000 Subject: [tei-council] [Fwd: [ tei-Feature Requests-2909766 ] make and (etc) dateable] Message-ID: <4B50A0B8.2080900@oucs.ox.ac.uk> Any views on this one? -------------- next part -------------- An embedded message was scrubbed... From: SourceForge.net Subject: [ tei-Feature Requests-2909766 ] make and (etc) dateable Date: Fri, 15 Jan 2010 17:06:16 +0000 Size: 4357 Url: http://lists.village.Virginia.EDU/pipermail/tei-council/attachments/20100115/8c464894/attachment.eml From lou.burnard at oucs.ox.ac.uk Fri Jan 15 12:10:36 2010 From: lou.burnard at oucs.ox.ac.uk (Lou) Date: Fri, 15 Jan 2010 17:10:36 +0000 Subject: [tei-council] [Fwd: [ tei-Bugs-2932853 ] TEI/@version] In-Reply-To: <4B508F45.1020308@kcl.ac.uk> References: <4B507D15.1060806@oucs.ox.ac.uk> <4B508F45.1020308@kcl.ac.uk> Message-ID: <4B50A18C.6090205@oucs.ox.ac.uk> Gabriel Bodard wrote: > Seems reasonable. Is there some reason that values like, "5.1.0", > "5.1.2" would be more problematic to constrain than "elephant", > "kangaroo", etc.? Yes. See #2925031 > > Lou a ?crit : >> Any thoughts on this one? I am minded to change the datatype to >> data.enumerated (though that leaves open the question of how to specify >> a closed set of numeric values) >> > From sebastian.rahtz at oucs.ox.ac.uk Fri Jan 15 13:05:27 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Fri, 15 Jan 2010 18:05:27 +0000 Subject: [tei-council] [Fwd: [ tei-Feature Requests-2909766 ] make and (etc) dateable] In-Reply-To: <4B50A0B8.2080900@oucs.ox.ac.uk> References: <4B50A0B8.2080900@oucs.ox.ac.uk> Message-ID: <20B34BF4-D6C3-4EA9-A178-F94BEB7FECB2@oucs.ox.ac.uk> On 15 Jan 2010, at 17:07, Lou wrote: > > Slippery slope warning. The date is presumably unambiguously always the > date that the addition or deletion was made, rather than the date that it > was identified by the encoder? well, yes. we dont usually record the date when a feature was identified, do we? we don't say January 1974 meaning "We decided in 2010 that she died in 1974" > So I can say notAfter="1802">wibble for an addition which I think was made before > 1802. Of course some bright spark will now ask for the ability to record an > addition that was (prior to evidence uncovered in 1904) believed to be 19th > century, but which is actually much older. Seems to me a fairly shallow and well-treated slope. I don't see any real problem saying that recording this is done in some other way. But I guess I am biased cos I made the suggestion.... -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From mholmes at uvic.ca Fri Jan 15 13:20:09 2010 From: mholmes at uvic.ca (Martin Holmes) Date: Fri, 15 Jan 2010 10:20:09 -0800 Subject: [tei-council] [Fwd: [ tei-Feature Requests-2909766 ] make and (etc) dateable] In-Reply-To: <4B50A0B8.2080900@oucs.ox.ac.uk> References: <4B50A0B8.2080900@oucs.ox.ac.uk> Message-ID: <4B50B1D9.7050404@uvic.ca> This looks sensible to me. I don't think we need to worry about the bright spark scenario; if it's unambiguous that the date is the date of the addition or deletion, then the discovery that an addition was wrongly dated simply requires that the markup be changed. I vote yes on this. I can see a practical usage of this for myself in the next year or two, on an upcoming project. Cheers, Martin Lou wrote: > Any views on this one? > > > > ------------------------------------------------------------------------ > > Subject: > [ tei-Feature Requests-2909766 ] make and (etc) dateable > From: > SourceForge.net > Date: > Fri, 15 Jan 2010 09:06:16 -0800 > To: > "noreply at sourceforge.net" > > To: > "noreply at sourceforge.net" > > > Feature Requests item #2909766, was opened at 2009-12-06 21:28 > Message generated for change (Comment added) made by louburnard > You can respond by visiting: > https://sourceforge.net/tracker/?func=detail&atid=644065&aid=2909766&group_id=106328 > > Please note that this message will contain a full copy of the comment thread, > including the initial issue submission, for this request, > not just the latest update. > Category: TEI: New or Changed Element >> Group: AMBER > Status: Open > Priority: 5 > Private: No > Submitted By: Sebastian Rahtz (rahtz) > Assigned to: Lou Burnard (louburnard) > Summary: make and (etc) dateable > > Initial Comment: > I am using and to mark changes in a born-digital document, and I know the exact date of the additions and deletions. It seems obvious to me that I should be able to say , of course. Can we just add these elements to the dateable class? > > ---------------------------------------------------------------------- > >> Comment By: Lou Burnard (louburnard) > Date: 2010-01-15 17:06 > > Message: > Slippery slope warning. The date is presumably unambiguously always the > date that the addition or deletion was made, rather than the date that it > was identified by the encoder? So I can say notAfter="1802">wibble for an addition which I think was made before > 1802. Of course some bright spark will now ask for the ability to record an > addition that was (prior to evidence uncovered in 1904) believed to be 19th > century, but which is actually much older. > > ---------------------------------------------------------------------- > > You can respond by visiting: > https://sourceforge.net/tracker/?func=detail&atid=644065&aid=2909766&group_id=106328 > -- Martin Holmes University of Victoria Humanities Computing and Media Centre (mholmes at uvic.ca) Half-Baked Software, Inc. (mholmes at halfbakedsoftware.com) martin at mholmes.com From laurent.romary at loria.fr Sat Jan 16 01:42:28 2010 From: laurent.romary at loria.fr (Laurent Romary) Date: Sat, 16 Jan 2010 07:42:28 +0100 Subject: [tei-council] [Fwd: [ tei-Feature Requests-2909766 ] make and (etc) dateable] In-Reply-To: <4B50B1D9.7050404@uvic.ca> References: <4B50A0B8.2080900@oucs.ox.ac.uk> <4B50B1D9.7050404@uvic.ca> Message-ID: I add my vote, with the word of caution that this should probably not be extended to any element taken at randon in the TEI (cf. the (counter-)example). The ad/del combinaiton with when is straightforward, though. Laurent (from Hong Kong...) Le 15 janv. 10 ? 19:20, Martin Holmes a ?crit : > This looks sensible to me. I don't think we need to worry about the > bright spark scenario; if it's unambiguous that the date is the date > of > the addition or deletion, then the discovery that an addition was > wrongly dated simply requires that the markup be changed. > > I vote yes on this. I can see a practical usage of this for myself in > the next year or two, on an upcoming project. > > Cheers, > Martin > > Lou wrote: >> Any views on this one? >> >> >> >> ------------------------------------------------------------------------ >> >> Subject: >> [ tei-Feature Requests-2909766 ] make and (etc) dateable >> From: >> SourceForge.net >> Date: >> Fri, 15 Jan 2010 09:06:16 -0800 >> To: >> "noreply at sourceforge.net" >> >> To: >> "noreply at sourceforge.net" >> >> >> Feature Requests item #2909766, was opened at 2009-12-06 21:28 >> Message generated for change (Comment added) made by louburnard >> You can respond by visiting: >> https://sourceforge.net/tracker/?func=detail&atid=644065&aid=2909766&group_id=106328 >> >> Please note that this message will contain a full copy of the >> comment thread, >> including the initial issue submission, for this request, >> not just the latest update. >> Category: TEI: New or Changed Element >>> Group: AMBER >> Status: Open >> Priority: 5 >> Private: No >> Submitted By: Sebastian Rahtz (rahtz) >> Assigned to: Lou Burnard (louburnard) >> Summary: make and (etc) dateable >> >> Initial Comment: >> I am using and to mark changes in a born-digital >> document, and I know the exact date of the additions and deletions. >> It seems obvious to me that I should be able to say > when="2009-11-01">, of course. Can we just add these elements >> to the dateable class? >> >> ---------------------------------------------------------------------- >> >>> Comment By: Lou Burnard (louburnard) >> Date: 2010-01-15 17:06 >> >> Message: >> Slippery slope warning. The date is presumably unambiguously always >> the >> date that the addition or deletion was made, rather than the date >> that it >> was identified by the encoder? So I can say > notAfter="1802">wibble for an addition which I think was made >> before >> 1802. Of course some bright spark will now ask for the ability to >> record an >> addition that was (prior to evidence uncovered in 1904) believed to >> be 19th >> century, but which is actually much older. >> >> ---------------------------------------------------------------------- >> >> You can respond by visiting: >> https://sourceforge.net/tracker/?func=detail&atid=644065&aid=2909766&group_id=106328 >> > > -- > Martin Holmes > University of Victoria Humanities Computing and Media Centre > (mholmes at uvic.ca) > Half-Baked Software, Inc. > (mholmes at halfbakedsoftware.com) > martin at mholmes.com > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council From James.Cummings at oucs.ox.ac.uk Sat Jan 16 05:03:58 2010 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Sat, 16 Jan 2010 10:03:58 +0000 Subject: [tei-council] [Fwd: [ tei-Feature Requests-2909766 ] make and (etc) dateable] In-Reply-To: References: <4B50A0B8.2080900@oucs.ox.ac.uk> <4B50B1D9.7050404@uvic.ca> Message-ID: <4B518F0E.2090104@oucs.ox.ac.uk> Hiya, I think I'm very slightly against this because of exactly the point Sebastian later made about using @when to record when we decided something. Even if in the case of add/del we were recording the date at which we thought the addition/deletion took place, we already have mechanisms in place to do this. (timeline being one of them) Also, where does it stop? Surely any act of scribal interaction with a document could be similarly time coded? Then any act of editorial interpretation.... then every act of encoding of the document. Does it really get us anywhere? Technically someone could already do that with a TEI document (with a stand-off solution being the easiest to implement). Surely this is a concern in genetic editing? Has the group of people working on the Genetic ODD added anything additional to deal with time/order or authorial interventions? If so, it would make sense to examine that before deciding on this. If I was too lazy to use timeline or similar though I'd probably just do: foo. While a little bit incorrect, probably, it does embed a date inside the add and so work for purposes of processing. -James Laurent Romary wrote: > I add my vote, with the word of caution that this should probably not > be extended to any element taken at randon in the TEI (cf. the when> (counter-)example). The ad/del combinaiton with when is > straightforward, though. > Laurent (from Hong Kong...) > >>> Initial Comment: >>> I am using and to mark changes in a born-digital >>> document, and I know the exact date of the additions and deletions. >>> It seems obvious to me that I should be able to say >> when="2009-11-01">, of course. Can we just add these elements >>> to the dateable class? >>> Message: >>> Slippery slope warning. The date is presumably unambiguously always >>> the >>> date that the addition or deletion was made, rather than the date >>> that it >>> was identified by the encoder? So I can say >> notAfter="1802">wibble for an addition which I think was made >>> before >>> 1802. Of course some bright spark will now ask for the ability to >>> record an >>> addition that was (prior to evidence uncovered in 1904) believed to >>> be 19th >>> century, but which is actually much older. From lou.burnard at oucs.ox.ac.uk Sat Jan 16 06:56:45 2010 From: lou.burnard at oucs.ox.ac.uk (Lou Burnard) Date: Sat, 16 Jan 2010 11:56:45 +0000 Subject: [tei-council] A nice easy one Message-ID: <4B51A97D.6090701@oucs.ox.ac.uk> As a change from some recent tricky questions on the list, here is a nice simple one. A User (P. Banski to be exact) writes "The Guidelines contain three orthographic variants of "stand-off" ("stand-off", "stand off", and "standoff"), sometimes within a single chapter (e.g. ch. 18). " Please could we have a show of hands as to which spelling should be adopted? This is also an opportunity for you to show that you are alive and reading the list! The spelling for which I receive most votes by Monday morning 1100 GMT will be uniformly imposed at that time. From mjd at hum.ku.dk Sat Jan 16 08:25:36 2010 From: mjd at hum.ku.dk (Matthew James Driscoll) Date: Sat, 16 Jan 2010 14:25:36 +0100 Subject: [tei-council] A nice easy one References: <4B51A97D.6090701@oucs.ox.ac.uk> Message-ID: "Stand-off", any day ("Standoff" sounds like a cheap brand of vodka). Matthew -----Original Message----- From: tei-council-bounces at lists.village.Virginia.EDU on behalf of Lou Burnard Sent: Sat 16/01/2010 12:56 To: TEI Council Subject: [tei-council] A nice easy one As a change from some recent tricky questions on the list, here is a nice simple one. A User (P. Banski to be exact) writes "The Guidelines contain three orthographic variants of "stand-off" ("stand-off", "stand off", and "standoff"), sometimes within a single chapter (e.g. ch. 18). " Please could we have a show of hands as to which spelling should be adopted? This is also an opportunity for you to show that you are alive and reading the list! The spelling for which I receive most votes by Monday morning 1100 GMT will be uniformly imposed at that time. _______________________________________________ tei-council mailing list tei-council at lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council From sebastian.rahtz at oucs.ox.ac.uk Sat Jan 16 09:02:41 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Sat, 16 Jan 2010 14:02:41 +0000 Subject: [tei-council] A nice easy one In-Reply-To: References: <4B51A97D.6090701@oucs.ox.ac.uk> Message-ID: <7B6C195B-681A-4E54-922A-912FBBB1E493@oucs.ox.ac.uk> "stand-off", no question. "standoff" is not cheap vodka, its a cheap tv show. http://www.tv.com/standoff/show/58389/summary.html -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From mholmes at uvic.ca Sat Jan 16 09:52:36 2010 From: mholmes at uvic.ca (Martin Holmes) Date: Sat, 16 Jan 2010 06:52:36 -0800 Subject: [tei-council] A nice easy one In-Reply-To: <7B6C195B-681A-4E54-922A-912FBBB1E493@oucs.ox.ac.uk> References: <4B51A97D.6090701@oucs.ox.ac.uk> <7B6C195B-681A-4E54-922A-912FBBB1E493@oucs.ox.ac.uk> Message-ID: <4B51D2B4.3030003@uvic.ca> "Stand-off" for me too. Cheers, Martin Sebastian Rahtz wrote: > "stand-off", no question. > > "standoff" is not cheap vodka, its a cheap tv show. http://www.tv.com/standoff/show/58389/summary.html > -- > Sebastian Rahtz > Information Manager, Oxford University Computing Services > 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 > > S?lo le pido a Dios > que el futuro no me sea indiferente > > > > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council From James.Cummings at oucs.ox.ac.uk Sat Jan 16 09:56:27 2010 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Sat, 16 Jan 2010 14:56:27 +0000 Subject: [tei-council] A nice easy one In-Reply-To: <7B6C195B-681A-4E54-922A-912FBBB1E493@oucs.ox.ac.uk> References: <4B51A97D.6090701@oucs.ox.ac.uk> <7B6C195B-681A-4E54-922A-912FBBB1E493@oucs.ox.ac.uk> Message-ID: <4B51D39B.1090607@oucs.ox.ac.uk> Sebastian Rahtz wrote: > "stand-off", no question. > > "standoff" is not cheap vodka, its a cheap tv show. http://www.tv.com/standoff/show/58389/summary.html I've done some very imprecise and unscientific searching with various search engines. 'standoff' seems to be used more in north american publications where 'stand-off' seems preferred elsewhere. (Also it seemed to me that 'standoff' was used earlier.) As a place, it is of course 'Stand Off'... as demonstrated by this photo that I took on my way back from the 2006 TEIMM: http://gallery.blushingbunny.net/v/james/2006/Victoria-2006-10/TripBack/Kamloops2Leth/Kamloops2Leth261.jpg.html -James From James.Cummings at oucs.ox.ac.uk Sat Jan 16 10:48:12 2010 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Sat, 16 Jan 2010 15:48:12 +0000 Subject: [tei-council] A nice easy one In-Reply-To: <4B51D39B.1090607@oucs.ox.ac.uk> References: <4B51A97D.6090701@oucs.ox.ac.uk> <7B6C195B-681A-4E54-922A-912FBBB1E493@oucs.ox.ac.uk> <4B51D39B.1090607@oucs.ox.ac.uk> Message-ID: <4B51DFBC.2070801@oucs.ox.ac.uk> Oh, I realised that I didn't express a preference. I'd definitely go for 'stand-off' vs 'standoff' with no real good reason other than it looks better to me. Aren't there rules about hyphenation and such things that some weird people follow? -James James Cummings wrote: > I've done some very imprecise and unscientific searching with various > search engines. 'standoff' seems to be used more in north american > publications where 'stand-off' seems preferred elsewhere. (Also it > seemed to me that 'standoff' was used earlier.) > > As a place, it is of course 'Stand Off'... as demonstrated by this photo > that I took on my way back from the 2006 TEIMM: > > http://gallery.blushingbunny.net/v/james/2006/Victoria-2006-10/TripBack/Kamloops2Leth/Kamloops2Leth261.jpg.html > > > -James > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council From kevin.s.hawkins at ultraslavonic.info Sat Jan 16 11:38:42 2010 From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins) Date: Sat, 16 Jan 2010 16:38:42 +0000 Subject: [tei-council] A nice easy one In-Reply-To: <4B51DFBC.2070801@oucs.ox.ac.uk> References: <4B51A97D.6090701@oucs.ox.ac.uk> <7B6C195B-681A-4E54-922A-912FBBB1E493@oucs.ox.ac.uk> <4B51D39B.1090607@oucs.ox.ac.uk> <4B51DFBC.2070801@oucs.ox.ac.uk> Message-ID: <4B51EB92.2020003@ultraslavonic.info> Being a bit of a nut for orthography, I wholeheartedly support "stand-off" or "standoff" but never "stand off" when used as an adjective, as in "stand-off markup". I don't think any of use "stand off" as a verb (never hyphenated in any case) or as a noun (hyphenation debatable). The hyphenation fanatics get riled up over hyphenated words vs. space between words, not hyphenated words vs. written as one word. You write something as one word if it becomes well known as a compound and isn't hard to read without the hyphen. That's why it's okay to write "email". There are a a few ossified exceptions (like "ice cream") that are unfortunate pollutions of the purity of the English language. ;-) Kevin From laurent.romary at loria.fr Sat Jan 16 21:17:01 2010 From: laurent.romary at loria.fr (Laurent Romary) Date: Sun, 17 Jan 2010 03:17:01 +0100 Subject: [tei-council] A nice easy one In-Reply-To: <4B51EB92.2020003@ultraslavonic.info> References: <4B51A97D.6090701@oucs.ox.ac.uk> <7B6C195B-681A-4E54-922A-912FBBB1E493@oucs.ox.ac.uk> <4B51D39B.1090607@oucs.ox.ac.uk> <4B51DFBC.2070801@oucs.ox.ac.uk> <4B51EB92.2020003@ultraslavonic.info> Message-ID: <2EC0A543-3208-4E3C-9556-6E98819CAD13@loria.fr> I vote for "stand-off" (to allow my fingers to keep typing this automatically) and confirm that Piotr, sitting next to me in Hong Kong prefers it as well. Cheers, Laurent Le 16 janv. 10 ? 17:38, Kevin Hawkins a ?crit : > Being a bit of a nut for orthography, I wholeheartedly support > "stand-off" or "standoff" but never "stand off" when used as an > adjective, as in "stand-off markup". I don't think any of use "stand > off" as a verb (never hyphenated in any case) or as a noun > (hyphenation > debatable). > > The hyphenation fanatics get riled up over hyphenated words vs. space > between words, not hyphenated words vs. written as one word. You > write > something as one word if it becomes well known as a compound and isn't > hard to read without the hyphen. That's why it's okay to write > "email". > There are a a few ossified exceptions (like "ice cream") that are > unfortunate pollutions of the purity of the English language. ;-) > > Kevin > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council From dot.porter at gmail.com Sun Jan 17 08:45:26 2010 From: dot.porter at gmail.com (Dot Porter) Date: Sun, 17 Jan 2010 08:45:26 -0500 Subject: [tei-council] A nice easy one In-Reply-To: <2EC0A543-3208-4E3C-9556-6E98819CAD13@loria.fr> References: <4B51A97D.6090701@oucs.ox.ac.uk> <7B6C195B-681A-4E54-922A-912FBBB1E493@oucs.ox.ac.uk> <4B51D39B.1090607@oucs.ox.ac.uk> <4B51DFBC.2070801@oucs.ox.ac.uk> <4B51EB92.2020003@ultraslavonic.info> <2EC0A543-3208-4E3C-9556-6E98819CAD13@loria.fr> Message-ID: <96f3df641001170545p643bd6d1p5b7e981c6628b27c@mail.gmail.com> I vote for stand-off On Sat, Jan 16, 2010 at 9:17 PM, Laurent Romary wrote: > I vote for "stand-off" (to allow my fingers to keep typing this > automatically) and confirm that Piotr, sitting next to me in Hong Kong > prefers it as well. > Cheers, > Laurent > > Le 16 janv. 10 ? 17:38, Kevin Hawkins a ?crit : > >> Being a bit of a nut for orthography, I wholeheartedly support >> "stand-off" or "standoff" but never "stand off" when used as an >> adjective, as in "stand-off markup". ?I don't think any of use "stand >> off" as a verb (never hyphenated in any case) or as a noun >> (hyphenation >> debatable). >> >> The hyphenation fanatics get riled up over hyphenated words vs. space >> between words, not hyphenated words vs. written as one word. ?You >> write >> something as one word if it becomes well known as a compound and isn't >> hard to read without the hyphen. ?That's why it's okay to write >> "email". >> ?There are a a few ossified exceptions (like "ice cream") that are >> unfortunate pollutions of the purity of the English language. ;-) >> >> Kevin >> _______________________________________________ >> tei-council mailing list >> tei-council at lists.village.Virginia.EDU >> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > -- *~*~*~*~*~*~*~*~*~*~* Dot Porter (MA, MSLS) Metadata Manager (on leave) Digital Humanities Observatory (RIA), Regus House, 28-32 Upper Pembroke Street, Dublin 2, Ireland -- A Project of the Royal Irish Academy -- Phone: +353 1 234 2444 Fax: +353 1 234 2400 http://dho.ie Email: dot.porter at gmail.com *~*~*~*~*~*~*~*~*~*~* From daniel.odonnell at uleth.ca Sun Jan 17 14:14:36 2010 From: daniel.odonnell at uleth.ca (O'Donnell, Dan) Date: Sun, 17 Jan 2010 14:14:36 -0500 Subject: [tei-council] A nice easy one Message-ID: <0bf601ca97a9$551465b1$2907428e@uleth.ca> It's also a small town on Blood Reserve just outside of Lethbridge: then it is called 'Stand Off'. ----------- Daniel O'Donnell University of Lethbridge (From my mobile telephone) --- original message --- From: "Sebastian Rahtz" Subject: Re: [tei-council] A nice easy one Date: January 16, 2010 Time: 3:2:46 "stand-off", no question. "standoff" is not cheap vodka, its a cheap tv show. http://www.tv.com/standoff/show/58389/summary.html -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente _______________________________________________ tei-council mailing list tei-council at lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council From laurent.romary at loria.fr Mon Jan 18 04:17:05 2010 From: laurent.romary at loria.fr (Laurent Romary) Date: Mon, 18 Jan 2010 10:17:05 +0100 Subject: [tei-council] [Fwd: [ tei-Feature Requests-2910712 ] reappraisal of author, editor, and respStmt] In-Reply-To: <4B509EA1.8080709@oucs.ox.ac.uk> References: <4B509EA1.8080709@oucs.ox.ac.uk> Message-ID: <430054E3-5CF2-483C-9395-0D5167EDFBFB@loria.fr> I would say so. Laurent Le 15 janv. 10 ? 17:58, Lou a ?crit : > I think the discussion in this ticket addresses the Action in tcm43, > and I'd like Council to express a view as to whether or not the > action taken is sufficient to warrant now closing the ticket. > > > De : SourceForge.net > Date : 15 janvier 2010 17:55:47 GMT+01:00 > ? : "noreply at sourceforge.net" > Objet : [ tei-Feature Requests-2910712 ] reappraisal of author, > editor, and respStmt > > > Feature Requests item #2910712, was opened at 2009-12-08 14:28 > Message generated for change (Comment added) made by louburnard > You can respond by visiting: > https://sourceforge.net/tracker/?func=detail&atid=644065&aid=2910712&group_id=106328 > > Please note that this message will contain a full copy of the > comment thread, > including the initial issue submission, for this request, > not just the latest update. > Category: None >> Group: GREEN > Status: Open > Priority: 5 > Private: No > Submitted By: Kevin Hawkins (kshawkin) > Assigned to: Nobody/Anonymous (nobody) > Summary: reappraisal of author, editor, and respStmt > > Initial Comment: > There are three elements in TEI which are used to represent various > parties responsible for a work: > > author > editor > respStmt > > According to the definition of , it may take a role= > attribute to indicate "the nature of the intellectual > responsibility", with suggested values being: > > translator > editor > compiler > illustrator > > However, 3.11.2.2 says "The author element should be used for the > person or agency with primary responsibility for a work's > intellectual content, and the element editor for an editor of the > work." > > I do not consider translators, compilers, and illustrators to be > compatible with 3.11.2.2, so I think this discrepancy should be > clarified. > > According to Lou (at https://sourceforge.net/tracker/?func=detail&aid=2798963&group_id=106328&atid=644065 > ), author was meant for primary responsibility, editor for various > types of secondary responsibility, and respStmt for anything else. > However, Council decided on 2009-12-07 to add @role to author to > allow for distinguishing various types of authors. > > The distinction among these three elements is problematic. The > TEI's ontology of entities responsible for a work is different from > those used in other schemas (like the NLM DTDs for journals, as > described in the ticket above, and in library cataloging practice, > which does not attempt to distinguish types of responsibility), and > it's not clear what purpose it serves to have three different > elements when we can't agree on the semantics of them. > > I suggest we either prescribe use of these elements more carefully > or remove author and editor in favor of the respStmt element, which > would have an optional type=. This attribute could be used by a > project if a taxonomy of responsibilities is desired and if the > various types of responsibility are not adequately conveyed by free > text in resp. > > ---------------------------------------------------------------------- > >> Comment By: Lou Burnard (louburnard) > Date: 2010-01-15 16:55 > > Message: > I have changed the wording at 3.11.2.2 as follows: > " The author element should be used for the person or agency > with > primary responsibility for a work's intellectual content, and the > element editor for any others with some responsibility for > that content, whether or not they are called > editor. An organization such as a radio or > television station is usually accounted author of > a broadcast, for example, while the author of a Government report will > usually be the agency which produced it. A translator, illustrator, or > compiler, may however be marked by means of the editor > element, > optionally using the role attribute to specify the nature > of their responsibility more exactly. > > The reason for having the three different elements, as Martin notes, > is to > make life a bit easier for simple uses. I think there is a good case > to be > made for recommending only a subset of what the TEI provides in > specific > contexts, but that's often the case. > > > > ---------------------------------------------------------------------- > > Comment By: Martin Holmes (martindholmes) > Date: 2010-01-14 18:17 > > Message: > I think removing and , as suggested in your last > paragraph, would be highly disruptive; it would also make life > slightly, > but noticeably, more difficult for newbies, who are happy to see > simple tag > names that they can understand without thinking too hard. > > However, there does seem to be a general issue here, which also > applies to > the distinction between and

. If is the general case, > and

> is syntactic sugar for , while is the > general case and is syntactic sugar for > author -- and I think there are many > other such cases -- perhaps we should develop a general policy with > regard > to the class membership and attribute availability for such > syntactic sugar > elements. It would also help to see an exhaustive list of such > elements -- > does one exist? > > ---------------------------------------------------------------------- > > You can respond by visiting: > https://sourceforge.net/tracker/?func=detail&atid=644065&aid=2910712&group_id=106328 > > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council From julianne.nyhan at gmail.com Mon Jan 18 08:37:43 2010 From: julianne.nyhan at gmail.com (Julianne Nyhan) Date: Mon, 18 Jan 2010 14:37:43 +0100 Subject: [tei-council] [Fwd: [ tei-Feature Requests-2910712 ] reappraisal of author, editor, and respStmt] In-Reply-To: <430054E3-5CF2-483C-9395-0D5167EDFBFB@loria.fr> References: <4B509EA1.8080709@oucs.ox.ac.uk> <430054E3-5CF2-483C-9395-0D5167EDFBFB@loria.fr> Message-ID: <30b37191001180537h5518c48mea334068b3c8a4e4@mail.gmail.com> I find the revised wording of 3.11.2.2 to be clear and easy to understand. I agree also. Julianne On Mon, Jan 18, 2010 at 10:17 AM, Laurent Romary wrote: > I would say so. > Laurent > > Le 15 janv. 10 ? 17:58, Lou a ?crit : > > > I think the discussion in this ticket addresses the Action in tcm43, > > and I'd like Council to express a view as to whether or not the > > action taken is sufficient to warrant now closing the ticket. > > > > > > De : SourceForge.net > > Date : 15 janvier 2010 17:55:47 GMT+01:00 > > ? : "noreply at sourceforge.net" > > Objet : [ tei-Feature Requests-2910712 ] reappraisal of author, > > editor, and respStmt > > > > > > Feature Requests item #2910712, was opened at 2009-12-08 14:28 > > Message generated for change (Comment added) made by louburnard > > You can respond by visiting: > > > https://sourceforge.net/tracker/?func=detail&atid=644065&aid=2910712&group_id=106328 > > > > Please note that this message will contain a full copy of the > > comment thread, > > including the initial issue submission, for this request, > > not just the latest update. > > Category: None > >> Group: GREEN > > Status: Open > > Priority: 5 > > Private: No > > Submitted By: Kevin Hawkins (kshawkin) > > Assigned to: Nobody/Anonymous (nobody) > > Summary: reappraisal of author, editor, and respStmt > > > > Initial Comment: > > There are three elements in TEI which are used to represent various > > parties responsible for a work: > > > > author > > editor > > respStmt > > > > According to the definition of , it may take a role= > > attribute to indicate "the nature of the intellectual > > responsibility", with suggested values being: > > > > translator > > editor > > compiler > > illustrator > > > > However, 3.11.2.2 says "The author element should be used for the > > person or agency with primary responsibility for a work's > > intellectual content, and the element editor for an editor of the > > work." > > > > I do not consider translators, compilers, and illustrators to be > > compatible with 3.11.2.2, so I think this discrepancy should be > > clarified. > > > > According to Lou (at > https://sourceforge.net/tracker/?func=detail&aid=2798963&group_id=106328&atid=644065 > > ), author was meant for primary responsibility, editor for various > > types of secondary responsibility, and respStmt for anything else. > > However, Council decided on 2009-12-07 to add @role to author to > > allow for distinguishing various types of authors. > > > > The distinction among these three elements is problematic. The > > TEI's ontology of entities responsible for a work is different from > > those used in other schemas (like the NLM DTDs for journals, as > > described in the ticket above, and in library cataloging practice, > > which does not attempt to distinguish types of responsibility), and > > it's not clear what purpose it serves to have three different > > elements when we can't agree on the semantics of them. > > > > I suggest we either prescribe use of these elements more carefully > > or remove author and editor in favor of the respStmt element, which > > would have an optional type=. This attribute could be used by a > > project if a taxonomy of responsibilities is desired and if the > > various types of responsibility are not adequately conveyed by free > > text in resp. > > > > ---------------------------------------------------------------------- > > > >> Comment By: Lou Burnard (louburnard) > > Date: 2010-01-15 16:55 > > > > Message: > > I have changed the wording at 3.11.2.2 as follows: > > " The author element should be used for the person or agency > > with > > primary responsibility for a work's intellectual content, and the > > element editor for any others with some responsibility for > > that content, whether or not they are called > > editor. An organization such as a radio or > > television station is usually accounted author of > > a broadcast, for example, while the author of a Government report will > > usually be the agency which produced it. A translator, illustrator, or > > compiler, may however be marked by means of the editor > > element, > > optionally using the role attribute to specify the nature > > of their responsibility more exactly. > > > > The reason for having the three different elements, as Martin notes, > > is to > > make life a bit easier for simple uses. I think there is a good case > > to be > > made for recommending only a subset of what the TEI provides in > > specific > > contexts, but that's often the case. > > > > > > > > ---------------------------------------------------------------------- > > > > Comment By: Martin Holmes (martindholmes) > > Date: 2010-01-14 18:17 > > > > Message: > > I think removing and , as suggested in your last > > paragraph, would be highly disruptive; it would also make life > > slightly, > > but noticeably, more difficult for newbies, who are happy to see > > simple tag > > names that they can understand without thinking too hard. > > > > However, there does seem to be a general issue here, which also > > applies to > > the distinction between and

. If is the general case, > > and

> > is syntactic sugar for , while is the > > general case and is syntactic sugar for > > author -- and I think there are many > > other such cases -- perhaps we should develop a general policy with > > regard > > to the class membership and attribute availability for such > > syntactic sugar > > elements. It would also help to see an exhaustive list of such > > elements -- > > does one exist? > > > > ---------------------------------------------------------------------- > > > > You can respond by visiting: > > > https://sourceforge.net/tracker/?func=detail&atid=644065&aid=2910712&group_id=106328 > > > > > > _______________________________________________ > > tei-council mailing list > > tei-council at lists.village.Virginia.EDU > > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > -- Dr Julianne Nyhan, Kompetenzzentrum f?r elektronische Erschlie?ungs- und Publikationsverfahren in den Geisteswissenschaften Universit?t Trier Fachbereich II / Germanistik Universit?tsring 15 54286 Trier + 49 (0)651 201-3358 http://germazope.uni-trier.de/Projects/KoZe2/ http://epu.ucc.ie/theses/jnyhan/ http://maney.co.uk/index.php/journals/isr/ http://www.tei-c.org/Activities/SIG/Education/index.xml From julianne.nyhan at gmail.com Mon Jan 18 09:18:53 2010 From: julianne.nyhan at gmail.com (Julianne Nyhan) Date: Mon, 18 Jan 2010 15:18:53 +0100 Subject: [tei-council] [Fwd: [ tei-Feature Requests-2909766 ] make and (etc) dateable] In-Reply-To: <4B518F0E.2090104@oucs.ox.ac.uk> References: <4B50A0B8.2080900@oucs.ox.ac.uk> <4B50B1D9.7050404@uvic.ca> <4B518F0E.2090104@oucs.ox.ac.uk> Message-ID: <30b37191001180618pbb9cd80xbb9c5c24464ff46@mail.gmail.com> Hello, My initial thoughts are that I agree with this. In line with Martin, I think it is far more likely that the markup would simply be changed in the 'bright spark scenario'. But as James points out, those working on the genetic ODD may well be tackling this - I would be glad to have their perspective and to know how regularly e.g. MSS scholars need/want to record such 'bright spark scenarios'. Best, Julianne On Sat, Jan 16, 2010 at 11:03 AM, James Cummings < James.Cummings at oucs.ox.ac.uk> wrote: > Hiya, > > I think I'm very slightly against this because of exactly the point > Sebastian later made about using @when to record when we decided > something. Even if in the case of add/del we were recording the date at > which we thought the addition/deletion took place, we already have > mechanisms in place to do this. (timeline being one of them) Also, > where does it stop? Surely any act of scribal interaction with a > document could be similarly time coded? Then any act of editorial > interpretation.... then every act of encoding of the document. Does it > really get us anywhere? Technically someone could already do that with > a TEI document (with a stand-off solution being the easiest to implement). > > Surely this is a concern in genetic editing? Has the group of people > working on the Genetic ODD added anything additional to deal with > time/order or authorial interventions? If so, it would make sense to > examine that before deciding on this. > > If I was too lazy to use timeline or similar though I'd probably just > do: foo. While a little bit > incorrect, probably, it does embed a date inside the add and so work for > purposes of processing. > > -James > > Laurent Romary wrote: > > I add my vote, with the word of caution that this should probably not > > be extended to any element taken at randon in the TEI (cf. the > when> (counter-)example). The ad/del combinaiton with when is > > straightforward, though. > > Laurent (from Hong Kong...) > > > >>> Initial Comment: > >>> I am using and to mark changes in a born-digital > >>> document, and I know the exact date of the additions and deletions. > >>> It seems obvious to me that I should be able to say >>> when="2009-11-01">, of course. Can we just add these elements > >>> to the dateable class? > >>> Message: > >>> Slippery slope warning. The date is presumably unambiguously always > >>> the > >>> date that the addition or deletion was made, rather than the date > >>> that it > >>> was identified by the encoder? So I can say >>> notAfter="1802">wibble for an addition which I think was made > >>> before > >>> 1802. Of course some bright spark will now ask for the ability to > >>> record an > >>> addition that was (prior to evidence uncovered in 1904) believed to > >>> be 19th > >>> century, but which is actually much older. > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > -- Dr Julianne Nyhan, Kompetenzzentrum f?r elektronische Erschlie?ungs- und Publikationsverfahren in den Geisteswissenschaften Universit?t Trier Fachbereich II / Germanistik Universit?tsring 15 54286 Trier + 49 (0)651 201-3358 http://germazope.uni-trier.de/Projects/KoZe2/ http://epu.ucc.ie/theses/jnyhan/ http://maney.co.uk/index.php/journals/isr/ http://www.tei-c.org/Activities/SIG/Education/index.xml From elena.pierazzo at kcl.ac.uk Mon Jan 18 10:56:18 2010 From: elena.pierazzo at kcl.ac.uk (Elena Pierazzo) Date: Mon, 18 Jan 2010 15:56:18 +0000 Subject: [tei-council] [Fwd: [ tei-Feature Requests-2909766 ] make and (etc) dateable] In-Reply-To: <4B518F0E.2090104@oucs.ox.ac.uk> References: <4B50A0B8.2080900@oucs.ox.ac.uk> <4B50B1D9.7050404@uvic.ca> <4B518F0E.2090104@oucs.ox.ac.uk> Message-ID: <4B5484A2.6070006@kcl.ac.uk> Hi, Sorry for slow replies, I was, ehm, on holiday! Yes James is right here, this is addressed in the genetic module in several ways according to the complexity of the case, but the simplest one is by the use of an attribute @stage so you can express that some additions/deletions or indeed other operation in the document belong to the same stage of revision. Stages are defined and dated into the header. Have a look at http://users.ox.ac.uk/~lou/wip/geneticTEI.doc.html#stages Question is: should we hold this until the genetic module is ready for the council to be submitted, or should the council act as we did not know that such a module is in preparation? Elena James Cummings wrote: > Hiya, > > I think I'm very slightly against this because of exactly the point > Sebastian later made about using @when to record when we decided > something. Even if in the case of add/del we were recording the date at > which we thought the addition/deletion took place, we already have > mechanisms in place to do this. (timeline being one of them) Also, > where does it stop? Surely any act of scribal interaction with a > document could be similarly time coded? Then any act of editorial > interpretation.... then every act of encoding of the document. Does it > really get us anywhere? Technically someone could already do that with > a TEI document (with a stand-off solution being the easiest to implement). > > Surely this is a concern in genetic editing? Has the group of people > working on the Genetic ODD added anything additional to deal with > time/order or authorial interventions? If so, it would make sense to > examine that before deciding on this. > > If I was too lazy to use timeline or similar though I'd probably just > do: foo. While a little bit > incorrect, probably, it does embed a date inside the add and so work for > purposes of processing. > > -James > > Laurent Romary wrote: > >> I add my vote, with the word of caution that this should probably not >> be extended to any element taken at randon in the TEI (cf. the > when> (counter-)example). The ad/del combinaiton with when is >> straightforward, though. >> Laurent (from Hong Kong...) >> >> >>>> Initial Comment: >>>> I am using and to mark changes in a born-digital >>>> document, and I know the exact date of the additions and deletions. >>>> It seems obvious to me that I should be able to say >>> when="2009-11-01">, of course. Can we just add these elements >>>> to the dateable class? >>>> Message: >>>> Slippery slope warning. The date is presumably unambiguously always >>>> the >>>> date that the addition or deletion was made, rather than the date >>>> that it >>>> was identified by the encoder? So I can say >>> notAfter="1802">wibble for an addition which I think was made >>>> before >>>> 1802. Of course some bright spark will now ask for the ability to >>>> record an >>>> addition that was (prior to evidence uncovered in 1904) believed to >>>> be 19th >>>> century, but which is actually much older. >>>> > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > -- Dr Elena Pierazzo Research Associate Centre for Computing in the Humanities King's College London 26-29 Drury Lane London WC2B 5RL Phone: 0207-848-1949 Fax: 0207-848-2980 elena.pierazzo[at]kcl.ac.uk www.kcl.ac.uk/cch From sebastian.rahtz at oucs.ox.ac.uk Mon Jan 18 11:01:19 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 18 Jan 2010 16:01:19 +0000 Subject: [tei-council] [Fwd: [ tei-Feature Requests-2909766 ] make and (etc) dateable] In-Reply-To: <4B5484A2.6070006@kcl.ac.uk> References: <4B50A0B8.2080900@oucs.ox.ac.uk> <4B50B1D9.7050404@uvic.ca> <4B518F0E.2090104@oucs.ox.ac.uk> <4B5484A2.6070006@kcl.ac.uk> Message-ID: <3CCFC8D8-7C2A-4985-A42E-F4A10E7CE755@oucs.ox.ac.uk> I don't see the genetic stuff contradicting the request to make and dateable, unless I misread? -- Sebastian Rahtz (acting) Information and Support Group Manager Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From elena.pierazzo at kcl.ac.uk Mon Jan 18 11:08:13 2010 From: elena.pierazzo at kcl.ac.uk (Elena Pierazzo) Date: Mon, 18 Jan 2010 16:08:13 +0000 Subject: [tei-council] [Fwd: [ tei-Feature Requests-2909766 ] make and (etc) dateable] In-Reply-To: <3CCFC8D8-7C2A-4985-A42E-F4A10E7CE755@oucs.ox.ac.uk> References: <4B50A0B8.2080900@oucs.ox.ac.uk> <4B50B1D9.7050404@uvic.ca> <4B518F0E.2090104@oucs.ox.ac.uk> <4B5484A2.6070006@kcl.ac.uk> <3CCFC8D8-7C2A-4985-A42E-F4A10E7CE755@oucs.ox.ac.uk> Message-ID: <4B54876D.7050109@kcl.ac.uk> Genetic stuff is not contradicting a @date on add and dell, but it will offer yet another way to deal with dating or grouping documentary/revisional phenomena, with the results of offering too many options (therefore confusing) to the users. Mind you that the genetic offers also a (revised) @seq attribute, and a pseudo-timeline mechanism as well. It is not sure that the genetic proposal is the best option, but I would not implement something we might regret in the moment we look into it, unless the council, as I said in my previous email, thinks we should act as we did not know that the genetic module is in preparations. Elena Sebastian Rahtz wrote: > I don't see the genetic stuff contradicting the request to make and dateable, unless I misread? > -- > Sebastian Rahtz > (acting) Information and Support Group Manager > Oxford University Computing Services > 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 > > S?lo le pido a Dios > que el futuro no me sea indiferente > > -- Dr Elena Pierazzo Research Associate Centre for Computing in the Humanities King's College London 26-29 Drury Lane London WC2B 5RL Phone: 0207-848-1949 Fax: 0207-848-2980 elena.pierazzo[at]kcl.ac.uk www.kcl.ac.uk/cch From sebastian.rahtz at oucs.ox.ac.uk Mon Jan 18 11:34:16 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 18 Jan 2010 16:34:16 +0000 Subject: [tei-council] [Fwd: [ tei-Feature Requests-2909766 ] make and (etc) dateable] In-Reply-To: <4B54876D.7050109@kcl.ac.uk> References: <4B50A0B8.2080900@oucs.ox.ac.uk> <4B50B1D9.7050404@uvic.ca> <4B518F0E.2090104@oucs.ox.ac.uk> <4B5484A2.6070006@kcl.ac.uk> <3CCFC8D8-7C2A-4985-A42E-F4A10E7CE755@oucs.ox.ac.uk> <4B54876D.7050109@kcl.ac.uk> Message-ID: On 18 Jan 2010, at 16:08, Elena Pierazzo wrote: > Genetic stuff is not contradicting a @date on add and dell, but it will offer yet another way to deal with dating or grouping documentary/revisional phenomena, it provides a way of associating and with named modification groups, which are associated with periods of intervention, but that would surely always be impossible overkill for when every has a different date? what I would use from genetic for my docs is the @stage attribute, but I'd point out that this has some overlap with @period -- Sebastian Rahtz (acting) Information and Support Group Manager Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From laurent.romary at loria.fr Tue Jan 19 02:26:09 2010 From: laurent.romary at loria.fr (Laurent Romary) Date: Tue, 19 Jan 2010 08:26:09 +0100 Subject: [tei-council] Scholarly publishing roundtable - possible role of the TEI Message-ID: [Sorry for duplicates if you are in more then one list, but the four, council, board, libraries, publishing seem to be relevant] Dear all (particularly American colleagues), If you have a look at the following report resulting from the Scholarly Publishing Roundtable convened since June 2009: http://science.house.gov/press/PRArticle.aspx?NewsID=2710 You will see that the recommendations are not only tackling open access issues (which is a good thing), but also state that "Policies should be guided by the need to foster interoperability". It urges there agencies to develop "robust standards for the structure of full text and metadata, navigation tools and other applications to achieve interoperability across the literature, taking international standards into account". If these recommendations are to be followed, I guess some of you should use their contacts within such agencies as the NEH to propose their service to help actuate this policy. Has someone been in the loop of this roundtable and/or see an opportunity for the consortium to take action here? Good recommendations on our part may prevent that some of these agencies reinvent the wheel of text encoding. Laurent From lou.burnard at oucs.ox.ac.uk Tue Jan 19 12:15:48 2010 From: lou.burnard at oucs.ox.ac.uk (Lou) Date: Tue, 19 Jan 2010 17:15:48 +0000 Subject: [tei-council] relatedItem@type values In-Reply-To: References: <4AEB2017.2070901@kcl.ac.uk> Message-ID: <4B55E8C4.60207@oucs.ox.ac.uk> Paul F. Schaffner wrote: > I have not forgotten that I was supposed to be coming up with > a sample list of relationships between related bibliographical items to > serve as exemplary values for @type (and/or @subtype) > on the element . > Sorry I've taken so long to get round to doing this, but I have now started. Many thanks again to Paul for doing the homework on this. Some comments 1. the current Guidelines have only one example of a related item, and the relatedness is that one item is the "original" of another. Following your naming system (which I like) I have replaced that value with "otherForm" (in the case of a microprint facsimile reproduction) or "otherEdition" (in the case of a diplomatic edition). But maybe "original source" is important enough to warrant its own value? 2. Please please Paul could you choose a couple of the many examples provided and give me a full citation? i.e. not just the info about the "related item" but also the item it's related to. 3. I added the following example (from a book conveniently lingering on my bookshelf) Tolkien, J.R.R. Den hobbit aus dem Engleschen iwwersat Henry Wickens Esch-sur-S?re Op der Lay S. ?r. L 1922 Originally published in English by Harper Collins Publishers Ltd under the title The Hobbit. but need more, preferably of other types. 4. At present, my feeling remains that we shouldn't actually constrain these types in the ODD itself, and that just a few examples of sensible uses would do. However, I think Council agreed that suggested values list would also be helpful. In which case, a selection needs to be made from Paul's original email (dated 30 oct 09) From sebastian.rahtz at oucs.ox.ac.uk Tue Jan 19 12:22:45 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 19 Jan 2010 17:22:45 +0000 Subject: [tei-council] relatedItem@type values In-Reply-To: <4B55E8C4.60207@oucs.ox.ac.uk> References: <4AEB2017.2070901@kcl.ac.uk> <4B55E8C4.60207@oucs.ox.ac.uk> Message-ID: <4529103D-4D20-4EE8-8E24-03E62B68A66E@oucs.ox.ac.uk> On 19 Jan 2010, at 17:15, Lou wrote: > > > > Tolkien, J.R.R. > Den hobbit > aus dem Engleschen iwwersat > Henry Wickens > > Esch-sur-S?re > Op der Lay S. ?r. L > 1922 > > Must be an amazing translation, coming out 15 years before Tolkien published it in English. or is this an obscure joke? -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From mjd at hum.ku.dk Tue Jan 19 12:30:51 2010 From: mjd at hum.ku.dk (Matthew James Driscoll) Date: Tue, 19 Jan 2010 18:30:51 +0100 Subject: [tei-council] relatedItem@type values References: <4AEB2017.2070901@kcl.ac.uk><4B55E8C4.60207@oucs.ox.ac.uk> <4529103D-4D20-4EE8-8E24-03E62B68A66E@oucs.ox.ac.uk> Message-ID: Should be 2002, but it's real enough. L?tzebuergesch, don't you know; the language almost afraid to know itself. Matthew -----Original Message----- From: tei-council-bounces at lists.village.Virginia.EDU on behalf of Sebastian Rahtz Sent: Tue 19/01/2010 18:22 To: Lou Burnard Cc: TEI Council Subject: Re: [tei-council] relatedItem at type values On 19 Jan 2010, at 17:15, Lou wrote: > > > > Tolkien, J.R.R. > Den hobbit > aus dem Engleschen iwwersat > Henry Wickens > > Esch-sur-S?re > Op der Lay S. ?r. L > 1922 > > Must be an amazing translation, coming out 15 years before Tolkien published it in English. or is this an obscure joke? -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente _______________________________________________ tei-council mailing list tei-council at lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council From lou.burnard at oucs.ox.ac.uk Tue Jan 19 12:33:02 2010 From: lou.burnard at oucs.ox.ac.uk (Lou) Date: Tue, 19 Jan 2010 17:33:02 +0000 Subject: [tei-council] relatedItem@type values In-Reply-To: <4529103D-4D20-4EE8-8E24-03E62B68A66E@oucs.ox.ac.uk> References: <4AEB2017.2070901@kcl.ac.uk> <4B55E8C4.60207@oucs.ox.ac.uk> <4529103D-4D20-4EE8-8E24-03E62B68A66E@oucs.ox.ac.uk> Message-ID: <4B55ECCE.5060801@oucs.ox.ac.uk> Sebastian Rahtz wrote: > On 19 Jan 2010, at 17:15, Lou wrote: > >> >> >> Tolkien, J.R.R. >> Den hobbit >> aus dem Engleschen iwwersat >> Henry Wickens >> >> Esch-sur-S?re >> Op der Lay S. ?r. L >> 1922 >> >> > > Must be an amazing translation, coming out 15 years before Tolkien published it in English. > > or is this an obscure joke? > ooops. No, it's a typo. tx for noticing From dsewell at virginia.edu Thu Jan 21 15:08:54 2010 From: dsewell at virginia.edu (David Sewell) Date: Thu, 21 Jan 2010 15:08:54 -0500 (EST) Subject: [tei-council] Vault migration progress Message-ID: Council-folk, I have been working on the migration of the TEI Vault to the Virginia server at www.tei-c.org. The files are in place and basically all working. I spent some time cleaning up control characters in text files (which often cause Apache to treat them as binary), tweaking MIME content types, and as a gift to Lou converting some ugly ASCII-7 French http://projects.oucs.ox.ac.uk/teiweb/Vault/ED/edr01.txt to UTF-8 http://www.tei-c.org/Vault/ED/edr01.txt I am fixing broken internal links, where possible, but I'd like to know what Council wants done with broken external ones. For example, most of the links on this page http://www.tei-c.org/Vault/ED/edr14.html are invalid. The ones to www.uic.edu can mostly be mapped to current pages on www.tei-c.org. Undoubtedly many external links are gone forever. Should I take the time to fix those, where possible? The number is not huge, ca. 60 in all. Users will not expect all the links to be working but will be pleased if they are. Please copy me on any reply as I am not subscribed to Council list now, David -- David Sewell, Editorial and Technical Manager ROTUNDA, The University of Virginia Press PO Box 801079, Charlottesville, VA 22904-4318 USA Courier: 310 Old Ivy Way, Suite 302, Charlottesville VA 22903 Email: dsewell at virginia.edu Tel: +1 434 924 9973 Web: http://rotunda.upress.virginia.edu/ From kevin.s.hawkins at ultraslavonic.info Thu Jan 21 15:22:46 2010 From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins) Date: Thu, 21 Jan 2010 20:22:46 +0000 Subject: [tei-council] Vault migration progress In-Reply-To: References: Message-ID: <4B58B796.4070408@ultraslavonic.info> From an archival standpoint, I think it is best not to correct any links in documents in the Vault. That would be manipulating the historical record in a way that will make it even more difficult for future researchers to imagine what the authors of these documents were referring to at the time. Fixing internal links only is okay if it's needed for documents to let users get from one document to another, though I don't think it's actually required. I think it's acceptable to fix character encoding (as you have) in order to make these documents readable by contemporary software. We are offering an archive for users, after all -- not a preservation-quality bitstream. Kevin David Sewell wrote: > Council-folk, > > I have been working on the migration of the TEI Vault to the Virginia > server at www.tei-c.org. The files are in place and basically all > working. I spent some time cleaning up control characters in text files > (which often cause Apache to treat them as binary), tweaking MIME content > types, and as a gift to Lou converting some ugly ASCII-7 French > > http://projects.oucs.ox.ac.uk/teiweb/Vault/ED/edr01.txt > > to UTF-8 > > http://www.tei-c.org/Vault/ED/edr01.txt > > I am fixing broken internal links, where possible, but I'd like to know > what Council wants done with broken external ones. For example, most of > the links on this page > > http://www.tei-c.org/Vault/ED/edr14.html > > are invalid. The ones to www.uic.edu can mostly be mapped to current > pages on www.tei-c.org. Undoubtedly many external links are gone > forever. > > Should I take the time to fix those, where possible? The number is not > huge, ca. 60 in all. Users will not expect all the links to be working > but will be pleased if they are. > > Please copy me on any reply as I am not subscribed to Council list now, > > David > From dsewell at virginia.edu Thu Jan 21 16:09:48 2010 From: dsewell at virginia.edu (David Sewell) Date: Thu, 21 Jan 2010 16:09:48 -0500 (EST) Subject: [tei-council] Vault migration progress In-Reply-To: <4B58B796.4070408@ultraslavonic.info> References: <4B58B796.4070408@ultraslavonic.info> Message-ID: This makes sense. I will update links that point to the Vault documents themselves (many of the old www.uic.edu links are to the original static forms of those documents), but not external links or links to dynamic documents, such as the various incarnations of the "Gentle Guides". David On Thu, 21 Jan 2010, Kevin Hawkins wrote: > From an archival standpoint, I think it is best not to correct any links in > documents in the Vault. That would be manipulating the historical record in a > way that will make it even more difficult for future researchers to imagine > what the authors of these documents were referring to at the time. Fixing > internal links only is okay if it's needed for documents to let users get from > one document to another, though I don't think it's actually required. > > I think it's acceptable to fix character encoding (as you have) in order to > make these documents readable by contemporary software. We are offering an > archive for users, after all -- not a preservation-quality bitstream. > > Kevin > > David Sewell wrote: > > Council-folk, > > > > I have been working on the migration of the TEI Vault to the Virginia > > server at www.tei-c.org. The files are in place and basically all > > working. I spent some time cleaning up control characters in text files > > (which often cause Apache to treat them as binary), tweaking MIME content > > types, and as a gift to Lou converting some ugly ASCII-7 French > > > > http://projects.oucs.ox.ac.uk/teiweb/Vault/ED/edr01.txt > > > > to UTF-8 > > > > http://www.tei-c.org/Vault/ED/edr01.txt > > > > I am fixing broken internal links, where possible, but I'd like to know > > what Council wants done with broken external ones. For example, most of > > the links on this page > > > > http://www.tei-c.org/Vault/ED/edr14.html > > > > are invalid. The ones to www.uic.edu can mostly be mapped to current > > pages on www.tei-c.org. Undoubtedly many external links are gone > > forever. > > > > Should I take the time to fix those, where possible? The number is not > > huge, ca. 60 in all. Users will not expect all the links to be working > > but will be pleased if they are. > > > > Please copy me on any reply as I am not subscribed to Council list now, > > > > David > > > -- David Sewell, Editorial and Technical Manager ROTUNDA, The University of Virginia Press PO Box 801079, Charlottesville, VA 22904-4318 USA Courier: 310 Old Ivy Way, Suite 302, Charlottesville VA 22903 Email: dsewell at virginia.edu Tel: +1 434 924 9973 Web: http://rotunda.upress.virginia.edu/ From lou.burnard at oucs.ox.ac.uk Thu Jan 21 16:49:28 2010 From: lou.burnard at oucs.ox.ac.uk (Lou Burnard) Date: Thu, 21 Jan 2010 21:49:28 +0000 Subject: [tei-council] Vault migration progress In-Reply-To: <4B58B796.4070408@ultraslavonic.info> References: <4B58B796.4070408@ultraslavonic.info> Message-ID: <4B58CBE8.3070403@oucs.ox.ac.uk> This really is quite a difficult set of issues here. First off, in the case of edr01, I'm not certain that converting the "ugly ASCII" conventions was that wise, partly because you leave other aspects of the markup (.sk .co) untouched, but mainly because the comment about the accents at the start of the text is now mystifying. (and the file doesnt display properly in my web browser anyways, because it looks like an ASCII file, not a UTF8 one) Secondly, I wonder if it helps to distinguish form and function when considering the links? It's (just about) possible to preserve the function of internal links if we know how to decode the form they take, and we're probably not over concerned about the exact form they took originally anyway (though I suppose we might be...). It's just not possible to preserve the function of an external link because the thing it's pointing to either isn't there at all, or if it is has now moved on entirely. (OK, you might say we should point into places on the Internet Archive or something...) So I'm not sure. I think I agree that tidying up internal links is reasonable and helpful. I feel quite strongly that we shouldn't mess with external links: it's quite a major editorial act to say that this link is actually to this other document. Can't comment on the "removal of control characters" without more details. Kevin Hawkins wrote: > From an archival standpoint, I think it is best not to correct any > links in documents in the Vault. That would be manipulating the > historical record in a way that will make it even more difficult for > future researchers to imagine what the authors of these documents were > referring to at the time. Fixing internal links only is okay if it's > needed for documents to let users get from one document to another, > though I don't think it's actually required. > > I think it's acceptable to fix character encoding (as you have) in order > to make these documents readable by contemporary software. We are > offering an archive for users, after all -- not a preservation-quality > bitstream. > > Kevin > > David Sewell wrote: >> Council-folk, >> >> I have been working on the migration of the TEI Vault to the Virginia >> server at www.tei-c.org. The files are in place and basically all >> working. I spent some time cleaning up control characters in text files >> (which often cause Apache to treat them as binary), tweaking MIME content >> types, and as a gift to Lou converting some ugly ASCII-7 French >> >> http://projects.oucs.ox.ac.uk/teiweb/Vault/ED/edr01.txt >> >> to UTF-8 >> >> http://www.tei-c.org/Vault/ED/edr01.txt >> >> I am fixing broken internal links, where possible, but I'd like to know >> what Council wants done with broken external ones. For example, most of >> the links on this page >> >> http://www.tei-c.org/Vault/ED/edr14.html >> >> are invalid. The ones to www.uic.edu can mostly be mapped to current >> pages on www.tei-c.org. Undoubtedly many external links are gone >> forever. >> >> Should I take the time to fix those, where possible? The number is not >> huge, ca. 60 in all. Users will not expect all the links to be working >> but will be pleased if they are. >> >> Please copy me on any reply as I am not subscribed to Council list now, >> >> David >> > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council From dsewell at virginia.edu Fri Jan 22 10:42:27 2010 From: dsewell at virginia.edu (David Sewell) Date: Fri, 22 Jan 2010 10:42:27 -0500 (EST) Subject: [tei-council] Vault migration progress In-Reply-To: <4B58CBE8.3070403@oucs.ox.ac.uk> References: <4B58B796.4070408@ultraslavonic.info> <4B58CBE8.3070403@oucs.ox.ac.uk> Message-ID: I've restored the original edr01. I thought that Apache on www.tei-c.org treated text/plain as UTF-8 by default but apparently not. The control characters I removed were all artifacts of conversion from a word processing format to ASCII. Mostly ^Z at the end of file, some ^L page feeds, a handful of other ones. Their presence causes Apache to treat a file as a binary and offer it for downloading rather than sending it as plain text, which is a nuisance. I am updating or fixing only internal links that point to other parts of the Vault, which all use either relative paths or a hard-coded reference to the old www-tei.uic.edu server. I think this strikes the right balance between current usability and desire to preserve archival information. David On Thu, 21 Jan 2010, Lou Burnard wrote: > This really is quite a difficult set of issues here. > > First off, in the case of edr01, I'm not certain that converting the "ugly > ASCII" conventions was that wise, partly because you leave other aspects of > the markup (.sk .co) untouched, but mainly because the comment about the > accents at the start of the text is now mystifying. > (and the file doesnt display properly in my web browser anyways, because it > looks like an ASCII file, not a UTF8 one) > > Secondly, I wonder if it helps to distinguish form and function when > considering the links? It's (just about) possible to preserve the function of > internal links if we know how to decode the form they take, and we're probably > not over concerned about the exact form they took originally anyway (though I > suppose we might be...). It's just not possible to preserve the function of an > external link because the thing it's pointing to either isn't there at all, or > if it is has now moved on entirely. (OK, you might say we should point into > places on the Internet Archive or something...) > > So I'm not sure. I think I agree that tidying up internal links is reasonable > and helpful. I feel quite strongly that we shouldn't mess with external links: > it's quite a major editorial act to say that this link is actually to this > other document. > > Can't comment on the "removal of control characters" without more details. > > > > Kevin Hawkins wrote: > > From an archival standpoint, I think it is best not to correct any links in > > documents in the Vault. That would be manipulating the historical record in > > a way that will make it even more difficult for future researchers to > > imagine what the authors of these documents were referring to at the time. > > Fixing internal links only is okay if it's needed for documents to let users > > get from one document to another, though I don't think it's actually > > required. > > > > I think it's acceptable to fix character encoding (as you have) in order to > > make these documents readable by contemporary software. We are offering an > > archive for users, after all -- not a preservation-quality bitstream. > > > > Kevin > > > > David Sewell wrote: > > > Council-folk, > > > > > > I have been working on the migration of the TEI Vault to the Virginia > > > server at www.tei-c.org. The files are in place and basically all > > > working. I spent some time cleaning up control characters in text files > > > (which often cause Apache to treat them as binary), tweaking MIME content > > > types, and as a gift to Lou converting some ugly ASCII-7 French > > > > > > http://projects.oucs.ox.ac.uk/teiweb/Vault/ED/edr01.txt > > > > > > to UTF-8 > > > > > > http://www.tei-c.org/Vault/ED/edr01.txt > > > > > > I am fixing broken internal links, where possible, but I'd like to know > > > what Council wants done with broken external ones. For example, most of > > > the links on this page > > > > > > http://www.tei-c.org/Vault/ED/edr14.html > > > > > > are invalid. The ones to www.uic.edu can mostly be mapped to current > > > pages on www.tei-c.org. Undoubtedly many external links are gone > > > forever. > > > > > > Should I take the time to fix those, where possible? The number is not > > > huge, ca. 60 in all. Users will not expect all the links to be working > > > but will be pleased if they are. > > > > > > Please copy me on any reply as I am not subscribed to Council list now, > > > > > > David > > > > > _______________________________________________ > > tei-council mailing list > > tei-council at lists.village.Virginia.EDU > > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > > -- David Sewell, Editorial and Technical Manager ROTUNDA, The University of Virginia Press PO Box 801079, Charlottesville, VA 22904-4318 USA Courier: 310 Old Ivy Way, Suite 302, Charlottesville VA 22903 Email: dsewell at virginia.edu Tel: +1 434 924 9973 Web: http://rotunda.upress.virginia.edu/ From daniel.odonnell at uleth.ca Fri Jan 22 14:51:53 2010 From: daniel.odonnell at uleth.ca (O'Donnell, Dan) Date: Fri, 22 Jan 2010 12:51:53 -0700 Subject: [tei-council] Upcoming meetings? Message-ID: <4B5A01D9.6030606@uleth.ca> Hi all, I have a sneaking suspicion I've dropped a telco date from my agenda. Is there one coming up soon? -dan -- Daniel Paul O'Donnell Associate Professor of English University of Lethbridge Chair and CEO, Text Encoding Initiative (http://www.tei-c.org/) Co-Chair, Digital Initiatives Advisory Board, Medieval Academy of America President-elect (English), Society for Digital Humanities/Soci?t? pour l'?tude des m?dias interactifs (http://sdh-semi.org/) Founding Director (2003-2009), Digital Medievalist Project (http://www.digitalmedievalist.org/) Vox: +1 403 329-2377 Fax: +1 403 382-7191 (non-confidential) Home Page: http://people.uleth.ca/~daniel.odonnell/ From dsewell at virginia.edu Fri Jan 22 15:19:53 2010 From: dsewell at virginia.edu (David Sewell) Date: Fri, 22 Jan 2010 15:19:53 -0500 (EST) Subject: [tei-council] Oxford --> Virginia Vault migration complete Message-ID: http://www.tei-c.org/Vault/ Of course let me know if you notice anything that is broken (apart from old links to other websites). Lou and I have discussed where we go from here with adding post-1998 documents; James and I will return to the question of archiving current and future Guidelines releases. David -- David Sewell, Editorial and Technical Manager ROTUNDA, The University of Virginia Press PO Box 801079, Charlottesville, VA 22904-4318 USA Courier: 310 Old Ivy Way, Suite 302, Charlottesville VA 22903 Email: dsewell at virginia.edu Tel: +1 434 924 9973 Web: http://rotunda.upress.virginia.edu/ From daniel.odonnell at uleth.ca Fri Jan 22 15:25:55 2010 From: daniel.odonnell at uleth.ca (O'Donnell, Dan) Date: Fri, 22 Jan 2010 13:25:55 -0700 Subject: [tei-council] Oxford --> Virginia Vault migration complete In-Reply-To: References: Message-ID: <4B5A09D3.2030902@uleth.ca> Is there some kind of announcement we could make about this? There are differences from the user's perspective, right? David Sewell wrote: > http://www.tei-c.org/Vault/ > > Of course let me know if you notice anything that is broken (apart from > old links to other websites). > > Lou and I have discussed where we go from here with adding post-1998 > documents; James and I will return to the question of archiving current > and future Guidelines releases. > > David > > -- Daniel Paul O'Donnell Associate Professor of English University of Lethbridge Chair and CEO, Text Encoding Initiative (http://www.tei-c.org/) Co-Chair, Digital Initiatives Advisory Board, Medieval Academy of America President-elect (English), Society for Digital Humanities/Soci?t? pour l'?tude des m?dias interactifs (http://sdh-semi.org/) Founding Director (2003-2009), Digital Medievalist Project (http://www.digitalmedievalist.org/) Vox: +1 403 329-2377 Fax: +1 403 382-7191 (non-confidential) Home Page: http://people.uleth.ca/~daniel.odonnell/ From dsewell at virginia.edu Sun Jan 24 17:18:51 2010 From: dsewell at virginia.edu (David Sewell) Date: Sun, 24 Jan 2010 17:18:51 -0500 (EST) Subject: [tei-council] Oxford --> Virginia Vault migration complete In-Reply-To: <4B5A09D3.2030902@uleth.ca> References: <4B5A09D3.2030902@uleth.ca> Message-ID: The only real difference for users is that these previous bookmarks are now obsolete: http://www.tei-c.org.uk/Vault/ http://projects.oucs.ox.ac.uk/teiweb/Vault/ And cross-reference links have been fixed so they work. If you think this all is enough to merit a news item, do you want to post something to TEI-L that I can copy as a news item on www.tei-c.org? On Fri, 22 Jan 2010, O'Donnell, Dan wrote: > Is there some kind of announcement we could make about this? There are > differences from the user's perspective, right? > > David Sewell wrote: >> http://www.tei-c.org/Vault/ >> >> Of course let me know if you notice anything that is broken (apart from >> old links to other websites). >> >> Lou and I have discussed where we go from here with adding post-1998 >> documents; James and I will return to the question of archiving current >> and future Guidelines releases. >> >> David >> >> > > -- David Sewell, Editorial and Technical Manager ROTUNDA, The University of Virginia Press PO Box 801079, Charlottesville, VA 22904-4318 USA Courier: 310 Old Ivy Way, Suite 302, Charlottesville VA 22903 Email: dsewell at virginia.edu Tel: +1 434 924 9973 Web: http://rotunda.upress.virginia.edu/ From lou.burnard at oucs.ox.ac.uk Mon Jan 25 05:06:07 2010 From: lou.burnard at oucs.ox.ac.uk (Lou Burnard) Date: Mon, 25 Jan 2010 10:06:07 +0000 Subject: [tei-council] Spelling Bee, take two Message-ID: <4B5D6D0F.9010307@oucs.ox.ac.uk> Following our recent rapid consensus on how to spell stand-off, I have another question for the assembled orthographists. Is this an - xpath - xPath - XPath - XPATH expression I see before me? From elena.pierazzo at kcl.ac.uk Mon Jan 25 05:08:31 2010 From: elena.pierazzo at kcl.ac.uk (Elena Pierazzo) Date: Mon, 25 Jan 2010 10:08:31 +0000 Subject: [tei-council] Spelling Bee, take two In-Reply-To: <4B5D6D0F.9010307@oucs.ox.ac.uk> References: <4B5D6D0F.9010307@oucs.ox.ac.uk> Message-ID: <4B5D6D9F.8080101@kcl.ac.uk> According to the W3C specs, it is XPath http://www.w3.org/TR/xpath/ Lou Burnard wrote: > Following our recent rapid consensus on how to spell stand-off, I have > another question for the assembled orthographists. > > Is this an > - xpath > - xPath > - XPath > - XPATH > expression I see before me? > > > > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > -- Dr Elena Pierazzo Research Associate Centre for Computing in the Humanities King's College London 26-29 Drury Lane London WC2B 5RL Phone: 0207-848-1949 Fax: 0207-848-2980 elena.pierazzo[at]kcl.ac.uk www.kcl.ac.uk/cch From mjd at hum.ku.dk Mon Jan 25 05:09:00 2010 From: mjd at hum.ku.dk (Matthew James Driscoll) Date: Mon, 25 Jan 2010 11:09:00 +0100 Subject: [tei-council] Spelling Bee, take two In-Reply-To: <4B5D6D0F.9010307@oucs.ox.ac.uk> References: <4B5D6D0F.9010307@oucs.ox.ac.uk> Message-ID: XPath, I reckon. -----Oprindelig meddelelse----- Fra: tei-council-bounces at lists.village.Virginia.EDU [mailto:tei-council-bounces at lists.village.Virginia.EDU] P? vegne af Lou Burnard Sendt: 25. januar 2010 11:06 Til: TEI Council Emne: [tei-council] Spelling Bee, take two Following our recent rapid consensus on how to spell stand-off, I have another question for the assembled orthographists. Is this an - xpath - xPath - XPath - XPATH expression I see before me? _______________________________________________ tei-council mailing list tei-council at lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council From James.Cummings at oucs.ox.ac.uk Mon Jan 25 05:10:09 2010 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Mon, 25 Jan 2010 10:10:09 +0000 Subject: [tei-council] Spelling Bee, take two In-Reply-To: <4B5D6D9F.8080101@kcl.ac.uk> References: <4B5D6D0F.9010307@oucs.ox.ac.uk> <4B5D6D9F.8080101@kcl.ac.uk> Message-ID: <4B5D6E01.2030306@oucs.ox.ac.uk> XPath, as Elena and MattiD say..... if there is a spec or somesuch that we are referring to, then we should be using its orthography. -James Elena Pierazzo wrote: > According to the W3C specs, it is XPath > > http://www.w3.org/TR/xpath/ > > Lou Burnard wrote: >> Following our recent rapid consensus on how to spell stand-off, I have >> another question for the assembled orthographists. >> >> Is this an >> - xpath >> - xPath >> - XPath >> - XPATH >> expression I see before me? >> >> >> >> >> _______________________________________________ >> tei-council mailing list >> tei-council at lists.village.Virginia.EDU >> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council >> > From sebastian.rahtz at oucs.ox.ac.uk Mon Jan 25 05:12:08 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 25 Jan 2010 10:12:08 +0000 Subject: [tei-council] Spelling Bee, take two In-Reply-To: <4B5D6D0F.9010307@oucs.ox.ac.uk> References: <4B5D6D0F.9010307@oucs.ox.ac.uk> Message-ID: On 25 Jan 2010, at 10:06, Lou Burnard wrote: > Following our recent rapid consensus on how to spell stand-off, I have > another question for the assembled orthographists. > > Is this an > - xpath > - xPath > - XPath > - XPATH > expression I see before me? Its XPath. James Clark says so. See http://www.w3.org/TR/xpath/ -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From lou.burnard at oucs.ox.ac.uk Mon Jan 25 05:25:31 2010 From: lou.burnard at oucs.ox.ac.uk (Lou Burnard) Date: Mon, 25 Jan 2010 10:25:31 +0000 Subject: [tei-council] Spelling Bee, take two In-Reply-To: References: <4B5D6D0F.9010307@oucs.ox.ac.uk> Message-ID: <4B5D719B.2000606@oucs.ox.ac.uk> That's what I thought too. Imagine my surprise therefore to find "xpath" used consistently throughout the text of the Guidelines. It's in hand. L Sebastian Rahtz wrote: > On 25 Jan 2010, at 10:06, Lou Burnard wrote: > > >> Following our recent rapid consensus on how to spell stand-off, I have >> another question for the assembled orthographists. >> >> Is this an >> - xpath >> - xPath >> - XPath >> - XPATH >> expression I see before me? >> > > Its XPath. James Clark says so. See http://www.w3.org/TR/xpath/ > -- > Sebastian Rahtz > Information Manager, Oxford University Computing Services > 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 > > S?lo le pido a Dios > que el futuro no me sea indiferente > > > > > From mholmes at uvic.ca Mon Jan 25 08:21:33 2010 From: mholmes at uvic.ca (Martin Holmes) Date: Mon, 25 Jan 2010 05:21:33 -0800 Subject: [tei-council] Spelling Bee, take two In-Reply-To: <4B5D6D0F.9010307@oucs.ox.ac.uk> References: <4B5D6D0F.9010307@oucs.ox.ac.uk> Message-ID: <4B5D9ADD.5070901@uvic.ca> The W3C says XPath: Cheers, Martin Lou Burnard wrote: > Following our recent rapid consensus on how to spell stand-off, I have > another question for the assembled orthographists. > > Is this an > - xpath > - xPath > - XPath > - XPATH > expression I see before me? > > > > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council From gabriel.bodard at kcl.ac.uk Mon Jan 25 08:57:38 2010 From: gabriel.bodard at kcl.ac.uk (Gabriel Bodard) Date: Mon, 25 Jan 2010 13:57:38 +0000 Subject: [tei-council] xml:space in TEI Message-ID: <4B5DA352.6080308@kcl.ac.uk> We've come across a use-case where we need inter-element spaces to be preserved in processing (in the text transcription area where mixed content is unavoidable), and the solution to this seems to be to stick an xml:space="preserve" on the div in question. Would anyone have any objection to adding this attribute to the TEI menu, alongside the other attributes from the xml: namespace we use already? (It was pointed out that as this is in the xml: and not the tei: namespace that we could add it locally without compromising conformance, but I'm not sure if this is true or not. My--probably na?ve--test of conformance to to ask whether my XML will validate against tei-p5-all, and with xml:space in there it doesn't.) I don't suppose this is controversial, but if it needs discussion I'm happy to post to TEI-L. Cheers, Gabby -- Dr Gabriel BODARD (Epigrapher & Digital Classicist) Centre for Computing in the Humanities King's College London 26-29 Drury Lane London WC2B 5RL Email: gabriel.bodard at kcl.ac.uk Tel: +44 (0)20 7848 1388 Fax: +44 (0)20 7848 2980 http://www.digitalclassicist.org/ http://www.currentepigraphy.org/ From sebastian.rahtz at oucs.ox.ac.uk Mon Jan 25 09:06:52 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 25 Jan 2010 14:06:52 +0000 Subject: [tei-council] xml:space in TEI In-Reply-To: <4B5DA352.6080308@kcl.ac.uk> References: <4B5DA352.6080308@kcl.ac.uk> Message-ID: <495D1861-766A-466A-9D73-E4D90FC1F5DF@oucs.ox.ac.uk> we used to have xml:space in att.global, but took it out for reasons I can't now recall. It is available of and via the att.xmlspace classes, also for reasons I can't now recall?.. The way to track this down is to look at Council maillist prior to 23rd October 2007 when the change was made. Unless someone can remember off-hand... -- Sebastian Rahtz (acting) Information and Support Group Manager Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From kevin.s.hawkins at ultraslavonic.info Wed Jan 27 13:10:03 2010 From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins) Date: Wed, 27 Jan 2010 18:10:03 +0000 Subject: [tei-council] Upcoming meetings? In-Reply-To: <4B5A01D9.6030606@uleth.ca> References: <4B5A01D9.6030606@uleth.ca> Message-ID: <4B60817B.4000202@ultraslavonic.info> Laurent sent a Meeting Wizard scheduling request today. If you didn't receive it, contact him. It came with a short comment that we need to get through more SourceForge tickets before our next face-to-face meeting (April 29-30 in Dublin). On 22/01/2010 19:51, O'Donnell, Dan wrote: > Hi all, > > I have a sneaking suspicion I've dropped a telco date from my agenda. Is > there one coming up soon? > > -dan > From laurent.romary at loria.fr Thu Jan 28 09:30:31 2010 From: laurent.romary at loria.fr (Laurent Romary) Date: Thu, 28 Jan 2010 15:30:31 +0100 Subject: [tei-council] TEI pre-council symposium on 28 April Message-ID: <78EDC6CE-1040-440A-ADA9-9F333F6B6B0A@loria.fr> Dear all, Kevin and I (with support from Susan) have started to compile notes on what the one day symposium before our F2F could look like. You will find these uner: http://docs.google.com/Doc?docid=0ARyxZGtPbrQ1ZHYzZHg3aF85Znc4dzN0ZDQ&hl=en Please provide feedback and proposal for improvement to Kevin and I (unless it's a discussion item for the list), in particular, we would like confirmation from James and Martin that we were right to think of them? Best wishes, Laurent From dot.porter at gmail.com Thu Jan 28 09:46:27 2010 From: dot.porter at gmail.com (Dot Porter) Date: Thu, 28 Jan 2010 09:46:27 -0500 Subject: [tei-council] TEI pre-council symposium on 28 April In-Reply-To: <78EDC6CE-1040-440A-ADA9-9F333F6B6B0A@loria.fr> References: <78EDC6CE-1040-440A-ADA9-9F333F6B6B0A@loria.fr> Message-ID: <96f3df641001280646u7e041eaap4d5baf6b5babd965@mail.gmail.com> I added a suggestion to invite someone from Yale University Press (which is working on an electronic publication with one of the RIA projects), and someone leading the IMLS planning grant to develop a service for publishing TEI documents (names on the g-doc). Sounds like it will be a good and interesting symposium, look forward to it! Dot On Thu, Jan 28, 2010 at 9:30 AM, Laurent Romary wrote: > Dear all, > Kevin and I (with support from Susan) have started to compile notes on > what the one day symposium before our F2F could look like. You will > find these uner: http://docs.google.com/Doc?docid=0ARyxZGtPbrQ1ZHYzZHg3aF85Znc4dzN0ZDQ&hl=en > Please provide feedback and proposal for improvement to Kevin and I > (unless it's a discussion item for the list), in particular, we would > like confirmation from James and Martin that we were right to think of > them? > Best wishes, > Laurent > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > -- *~*~*~*~*~*~*~*~*~*~* Dot Porter (MA, MSLS) Metadata Manager (on leave) Digital Humanities Observatory (RIA), Regus House, 28-32 Upper Pembroke Street, Dublin 2, Ireland -- A Project of the Royal Irish Academy -- Phone: +353 1 234 2444 Fax: +353 1 234 2400 http://dho.ie Email: dot.porter at gmail.com *~*~*~*~*~*~*~*~*~*~* From mholmes at uvic.ca Thu Jan 28 11:47:33 2010 From: mholmes at uvic.ca (Martin Holmes) Date: Thu, 28 Jan 2010 08:47:33 -0800 Subject: [tei-council] TEI pre-council symposium on 28 April In-Reply-To: <78EDC6CE-1040-440A-ADA9-9F333F6B6B0A@loria.fr> References: <78EDC6CE-1040-440A-ADA9-9F333F6B6B0A@loria.fr> Message-ID: <4B61BFA5.5090806@uvic.ca> I'm happy to be included. Did you have any particular thing you wanted me to talk about? I could do something on bibliographies in scholarly articles, if that's suitable, perhaps looking at different approaches with TEI and NLM. Cheers, Martin Laurent Romary wrote: > Dear all, > Kevin and I (with support from Susan) have started to compile notes on > what the one day symposium before our F2F could look like. You will > find these uner: http://docs.google.com/Doc?docid=0ARyxZGtPbrQ1ZHYzZHg3aF85Znc4dzN0ZDQ&hl=en > Please provide feedback and proposal for improvement to Kevin and I > (unless it's a discussion item for the list), in particular, we would > like confirmation from James and Martin that we were right to think of > them? > Best wishes, > Laurent > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > -- Martin Holmes University of Victoria Humanities Computing and Media Centre (mholmes at uvic.ca) Half-Baked Software, Inc. (mholmes at halfbakedsoftware.com) martin at mholmes.com From James.Cummings at oucs.ox.ac.uk Thu Jan 28 12:12:19 2010 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Thu, 28 Jan 2010 17:12:19 +0000 Subject: [tei-council] TEI pre-council symposium on 28 April In-Reply-To: <4B61BFA5.5090806@uvic.ca> References: <78EDC6CE-1040-440A-ADA9-9F333F6B6B0A@loria.fr> <4B61BFA5.5090806@uvic.ca> Message-ID: <4B61C573.6060003@oucs.ox.ac.uk> Martin Holmes wrote: > I'm happy to be included. Did you have any particular thing you wanted > me to talk about? I could do something on bibliographies in scholarly > articles, if that's suitable, perhaps looking at different approaches > with TEI and NLM. Likewise, I'm happy to talk as well... What would you want me to talk about? DM's journal system? TEI Projects we're working on here in Oxford? Something else entirely? -James From laurent.romary at loria.fr Fri Jan 29 02:42:14 2010 From: laurent.romary at loria.fr (Laurent Romary) Date: Fri, 29 Jan 2010 08:42:14 +0100 Subject: [tei-council] TEI pre-council symposium on 28 April In-Reply-To: <4B61C573.6060003@oucs.ox.ac.uk> References: <78EDC6CE-1040-440A-ADA9-9F333F6B6B0A@loria.fr> <4B61BFA5.5090806@uvic.ca> <4B61C573.6060003@oucs.ox.ac.uk> Message-ID: I would suggest (Kevin, please check): - Martin: experience gained from TEIJournal and vision/advice on the direction the TEI should go to provide a better support for scholarly publishing, and yes, what could be the optimal strategy with regards NLM - James: yes, DM and, analysing (a little like Martin) how the TEI impacted or constrained the design of the whole thing Think of your talks as position papers: the intend is to make us all "think". Does this help? Laurent Le 28 janv. 10 ? 18:12, James Cummings a ?crit : > Martin Holmes wrote: >> I'm happy to be included. Did you have any particular thing you >> wanted >> me to talk about? I could do something on bibliographies in scholarly >> articles, if that's suitable, perhaps looking at different approaches >> with TEI and NLM. > > Likewise, I'm happy to talk as well... What would you want me to > talk about? DM's journal system? TEI Projects we're working on > here in Oxford? Something else entirely? > -James > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council From James.Cummings at oucs.ox.ac.uk Fri Jan 29 03:23:50 2010 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Fri, 29 Jan 2010 08:23:50 +0000 Subject: [tei-council] TEI pre-council symposium on 28 April In-Reply-To: References: <78EDC6CE-1040-440A-ADA9-9F333F6B6B0A@loria.fr> <4B61BFA5.5090806@uvic.ca> <4B61C573.6060003@oucs.ox.ac.uk> Message-ID: <4B629B16.3080707@oucs.ox.ac.uk> Laurent Romary wrote: > I would suggest (Kevin, please check): > - Martin: experience gained from TEIJournal and vision/advice on the > direction the TEI should go to provide a better support for scholarly > publishing, and yes, what could be the optimal strategy with regards > NLM > - James: yes, DM and, analysing (a little like Martin) how the TEI > impacted or constrained the design of the whole thing > > Think of your talks as position papers: the intend is to make us all > "think". > Does this help? Yes, works for me. -James > Laurent > > Le 28 janv. 10 ? 18:12, James Cummings a ?crit : > >> Martin Holmes wrote: >>> I'm happy to be included. Did you have any particular thing you >>> wanted >>> me to talk about? I could do something on bibliographies in scholarly >>> articles, if that's suitable, perhaps looking at different approaches >>> with TEI and NLM. >> Likewise, I'm happy to talk as well... What would you want me to >> talk about? DM's journal system? TEI Projects we're working on >> here in Oxford? Something else entirely? >> -James >> >> _______________________________________________ >> tei-council mailing list >> tei-council at lists.village.Virginia.EDU >> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > -- Dr James Cummings, Research Technology Service Oxford University Computing Services University of Oxford From lou.burnard at oucs.ox.ac.uk Fri Jan 29 03:53:37 2010 From: lou.burnard at oucs.ox.ac.uk (Lou Burnard) Date: Fri, 29 Jan 2010 08:53:37 +0000 Subject: [tei-council] certainty revised Message-ID: <4B62A211.2040609@oucs.ox.ac.uk> Some council members may remember that in October last there was a flurry of debate about the correct way to describe usage for the newly introduced @match attribute on and . The issue is documented, largely, on SF ticket #2877940, and over the last few weeks I've been batting ideas about how to resolve it with a few experts, notably Wendell P. We've now reached the stage of having a draft revision of the chapter which none of the experts has declared themself unhappy with, and I would therefore now like to pass this under the critical nose of the council. Please could you devote half an hour or so of careful reading to http://tei.oucs.ox.ac.uk/P5/Guidelines-web/en/html/CE.html Like Eccles, the chapter is short, and (in parts) dense. I don't feel I can close the ticket without some kind of imprimatur from the Council, since although there is very little or nothing changed in terms of document validity, there has been quite a lot of revision in the way the features of this module are described, and almost certainly there remain some inconsistencies of expression or typos. From kevin.s.hawkins at ultraslavonic.info Fri Jan 29 05:31:26 2010 From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins) Date: Fri, 29 Jan 2010 10:31:26 +0000 Subject: [tei-council] TEI pre-council symposium on 28 April In-Reply-To: References: <78EDC6CE-1040-440A-ADA9-9F333F6B6B0A@loria.fr> <4B61BFA5.5090806@uvic.ca> <4B61C573.6060003@oucs.ox.ac.uk> Message-ID: <4B62B8FE.2020909@ultraslavonic.info> These all sounds good to me. Laurent's suggestions for Martin don't seem to be quite what Martin first suggested, but perhaps he could write to Laurent and me to agree on a topic from the various suggestions put forth. --Kevin Laurent Romary wrote: > I would suggest (Kevin, please check): > - Martin: experience gained from TEIJournal and vision/advice on the > direction the TEI should go to provide a better support for scholarly > publishing, and yes, what could be the optimal strategy with regards > NLM > - James: yes, DM and, analysing (a little like Martin) how the TEI > impacted or constrained the design of the whole thing > > Think of your talks as position papers: the intend is to make us all > "think". > Does this help? > Laurent From mholmes at uvic.ca Fri Jan 29 11:46:54 2010 From: mholmes at uvic.ca (Martin Holmes) Date: Fri, 29 Jan 2010 08:46:54 -0800 Subject: [tei-council] certainty revised In-Reply-To: <4B62A211.2040609@oucs.ox.ac.uk> References: <4B62A211.2040609@oucs.ox.ac.uk> Message-ID: <4B6310FE.20606@uvic.ca> Here's my couple of cents on the first part -- I haven't had time to get through it all yet: --------------------- QUOTE: [one] the note element defined in section 3.8 Notes, Annotation, and Indexing may be used with a value of certainty for its type attribute. [two (example)] Elizabeth went to Essex. She had always liked Essex. It is not clear here whether Essex refers to the place or to the nobleman. -MSM COMMENT: The text says type="certainty", the example shows type="uncertainty". --------------------- QUOTE: @match supplies an arbitrary XPath expression identifying a set of nodes, selected within the context identified by the target attribute if this is supplied, or by the parent element if it is not. COMMENT: This was at the heart of the previous discussion, and for me it's still not absolutely clear at this point in the text. The parent element of what? Later we learn that it's the parent of the , or element bearing the @match attribute, but I think it would help to specify it here. --------------------- QUOTE: [one] The certainty element is designed to encode the following sorts: [...] * the content of an element is uncertain, perhaps because it is hard to read or hard to hear, or for some other reason. [two (just below)] The following types of uncertainty are not indicated with the certainty element: [...] * the document being transcribed may be read in different ways (for this use the transcriptional elements such as unclear, discussed in chapter 11 Representation of Primary Sources) COMMENT: These seem in direct contradiction: the first is saying "use where the text is uncertain because it's hard to read", and the second is saying "don't use , I think it would be best to specify that here. As it reads now, you might get the impression that anything goes. Hope this helps, Martin Lou Burnard wrote: > Some council members may remember that in October last there was a flurry of debate about the correct way to describe usage for the newly introduced @match attribute on and . The issue is documented, largely, on SF ticket #2877940, and over the last few weeks I've been batting ideas about how to resolve it with a few experts, notably Wendell P. We've now reached the stage of having a draft revision of the chapter which none of the experts has declared themself unhappy with, and I would therefore now like to pass this under the critical nose of the council. > > Please could you devote half an hour or so of careful reading to > > http://tei.oucs.ox.ac.uk/P5/Guidelines-web/en/html/CE.html > > > Like Eccles, the chapter is short, and (in parts) dense. > > I don't feel I can close the ticket without some kind of imprimatur from the Council, since although there is very little or nothing changed in terms of document validity, there has been quite a lot of revision in the way the features of this module are described, and almost certainly there remain some inconsistencies of expression or typos. > > > > > > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > -- Martin Holmes University of Victoria Humanities Computing and Media Centre (mholmes at uvic.ca) Half-Baked Software, Inc. (mholmes at halfbakedsoftware.com) martin at mholmes.com From lou.burnard at oucs.ox.ac.uk Mon Feb 1 09:26:12 2010 From: lou.burnard at oucs.ox.ac.uk (Lou Burnard) Date: Mon, 01 Feb 2010 14:26:12 +0000 Subject: [tei-council] certainty revised In-Reply-To: <4B6310FE.20606@uvic.ca> References: <4B62A211.2040609@oucs.ox.ac.uk> <4B6310FE.20606@uvic.ca> Message-ID: <4B66E484.9020809@oucs.ox.ac.uk> Martin Holmes wrote: > Here's my couple of cents on the first part -- I haven't had time to get > through it all yet: > Hope you havent been too dispirited to continue... > --------------------- > > QUOTE: > > [one] > the note element defined in section 3.8 Notes, Annotation, and Indexing > may be used with a value of certainty for its type attribute. > > [two (example)] > Elizabeth went to Essex. She > had always liked Essex. > It is not > clear here whether Essex > refers to the place or to the nobleman. -MSM > > COMMENT: > > The text says type="certainty", the example shows type="uncertainty". > Well spotted. Fixed. > --------------------- > > QUOTE: > > @match supplies an arbitrary XPath expression identifying a set of > nodes, selected within the context identified by the target attribute if > this is supplied, or by the parent element if it is not. > > COMMENT: > > This was at the heart of the previous discussion, and for me it's still > not absolutely clear at this point in the text. The parent element of > what? Later we learn that it's the parent of the , > or element bearing the @match attribute, but I > think it would help to specify it here. > > --------------------- > > Um yes. "by the context of the element bearing the attribute, i.e. its parent" . I think. > QUOTE: > > [one] > The certainty element is designed to encode the following sorts: > [...] > * the content of an element is uncertain, perhaps because it is > hard to read or hard to hear, or for some other reason. > > [two (just below)] > The following types of uncertainty are not indicated with the certainty > element: > [...] > * the document being transcribed may be read in different ways (for > this use the transcriptional elements such as unclear, discussed in > chapter 11 Representation of Primary Sources) > > COMMENT: > > These seem in direct contradiction: the first is saying "use > where the text is uncertain because it's hard to read", and the second > is saying "don't use ways because it's unclear". If this isn't a contradiction, then I think > it needs more detailed explanation. > > --------------------- > > There is a problem here, certainly :-) . I think the first means "use certainty when you don't know what the unknowns are" and the second means "you know what the unknowns are but you dont know which you want", and will try to rephrase accordingly. But it's a rather nebulous distinction... and maybe in fact we should do better to be honest and say we have two rather different mechanisms and you can choose whichever you like. > QUOTE: > > locus indicates more exactly the aspect concerning which uncertainty > is being expressed: for example, whether the markup is correctly > located, whether the right element or attribute name has been used, > whether the content of the element or attribute is correct, etc. > > COMMENT: > > Since @locus is constrained to one of five fixed values (according to > , > I think it would be best to specify that here. As it reads now, you > might get the impression that anything goes. > > > Good point. Will adapt accordingly. > Hope this helps, > Very much so. tx From mholmes at uvic.ca Mon Feb 1 13:19:54 2010 From: mholmes at uvic.ca (Martin Holmes) Date: Mon, 1 Feb 2010 10:19:54 -0800 Subject: [tei-council] certainty revised In-Reply-To: <4B66E484.9020809@oucs.ox.ac.uk> References: <4B62A211.2040609@oucs.ox.ac.uk> <4B6310FE.20606@uvic.ca> <4B66E484.9020809@oucs.ox.ac.uk> Message-ID: <4B671B4A.7030904@uvic.ca> Lou Burnard wrote: > Martin Holmes wrote: >> Here's my couple of cents on the first part -- I haven't had time to get >> through it all yet: >> > Hope you havent been too dispirited to continue... Sorry -- got distracted. Here's a bit more: -------------------- The current documentation for () includes an example based on: Ernest went to old Saybrook. and it says "For discussion of this example, see section 21.1.2 Structured Indications of Uncertainty", but the example discussed in 21.1.2 is now the much better (IMHO) example of Elizabeth and Essex. -------------------- The example of the abbreviation expansion of SGML looks like this: You will want to use Standard Generalized Markup Language Some Grandiose Methodology for Losers SGML ... I suspect that the second @degree value should be "0.1", shouldn't it? Don't the two have to add up to 1? --------------------- Finally, I find myself a little puzzled by the application of to @notAfter, @notBefore, etc. My habit in using these attributes has been to decide once and for all, based on known information and logical deduction, what the _actual_ earliest and latest possible dates would be. It seems a little odd to me to say that something is "not after 1857", but there's a 50% chance that it might be. If you're not sure it's @notAfter="1857", then you need to move your @notAfter value forward until you can be sure, don't you? In my experience, there always _is_ a genuine value for @notBefore or @notAfter -- in the case of an action by a person, for instance, the date before which they were definitely not born, the date after which they were definitely dead, or the point at which they would have been so old as to break all known longevity records. After all, @notAfter is defined as specifying "the latest possible date". One example from the text: From the 1st of March to some time in April of 1857. Now, if "some time in April" is true, then @degree should surely be "1.0". If "some time in April" is doubtful, then surely so is "the 1st of March". But if there is doubt, that doubt presumably originates in external evidence, which ought at least to be adduced, and which itself would presumably give a more realistic value for @notAfter. Hope this helps. Martin >> --------------------- >> >> QUOTE: >> >> [one] >> the note element defined in section 3.8 Notes, Annotation, and Indexing >> may be used with a value of certainty for its type attribute. >> >> [two (example)] >> Elizabeth went to Essex. She >> had always liked Essex. >> It is not >> clear here whether Essex >> refers to the place or to the nobleman. -MSM >> >> COMMENT: >> >> The text says type="certainty", the example shows type="uncertainty". >> > > Well spotted. Fixed. > >> --------------------- >> >> QUOTE: >> >> @match supplies an arbitrary XPath expression identifying a set of >> nodes, selected within the context identified by the target attribute if >> this is supplied, or by the parent element if it is not. >> >> COMMENT: >> >> This was at the heart of the previous discussion, and for me it's still >> not absolutely clear at this point in the text. The parent element of >> what? Later we learn that it's the parent of the , >> or element bearing the @match attribute, but I >> think it would help to specify it here. >> >> --------------------- >> >> > > Um yes. "by the context of the element bearing the attribute, i.e. its > parent" . > I think. > > > >> QUOTE: >> >> [one] >> The certainty element is designed to encode the following sorts: >> [...] >> * the content of an element is uncertain, perhaps because it is >> hard to read or hard to hear, or for some other reason. >> >> [two (just below)] >> The following types of uncertainty are not indicated with the certainty >> element: >> [...] >> * the document being transcribed may be read in different ways (for >> this use the transcriptional elements such as unclear, discussed in >> chapter 11 Representation of Primary Sources) >> >> COMMENT: >> >> These seem in direct contradiction: the first is saying "use >> where the text is uncertain because it's hard to read", and the second >> is saying "don't use > ways because it's unclear". If this isn't a contradiction, then I think >> it needs more detailed explanation. >> >> --------------------- >> >> > > There is a problem here, certainly :-) . I think the first means "use > certainty when you don't know what the unknowns are" and the second > means "you know what the unknowns are but you dont know which you want", > and will try to rephrase accordingly. But it's a rather nebulous > distinction... and maybe in fact we should do better to be honest and > say we have two rather different mechanisms and you can choose whichever > you like. > > > >> QUOTE: >> >> locus indicates more exactly the aspect concerning which uncertainty >> is being expressed: for example, whether the markup is correctly >> located, whether the right element or attribute name has been used, >> whether the content of the element or attribute is correct, etc. >> >> COMMENT: >> >> Since @locus is constrained to one of five fixed values (according to >> , >> I think it would be best to specify that here. As it reads now, you >> might get the impression that anything goes. >> >> >> > > Good point. Will adapt accordingly. > >> Hope this helps, >> > > Very much so. > > tx > > . > -- Martin Holmes University of Victoria Humanities Computing and Media Centre (mholmes at uvic.ca) Half-Baked Software, Inc. (mholmes at halfbakedsoftware.com) martin at mholmes.com From mholmes at uvic.ca Fri Feb 5 11:37:00 2010 From: mholmes at uvic.ca (Martin Holmes) Date: Fri, 5 Feb 2010 08:37:00 -0800 Subject: [tei-council] Teleconference on Monday Message-ID: <4B6C492C.5020109@uvic.ca> Hi all, For our meeting on Monday, are we using Skype? If so, who's hosting? Cheers, Martin -- Martin Holmes University of Victoria Humanities Computing and Media Centre (mholmes at uvic.ca) Half-Baked Software, Inc. (mholmes at halfbakedsoftware.com) martin at mholmes.com From daniel.odonnell at uleth.ca Fri Feb 5 12:54:09 2010 From: daniel.odonnell at uleth.ca (O'Donnell, Dan) Date: Fri, 05 Feb 2010 10:54:09 -0700 Subject: [tei-council] Conference Call Numbers Message-ID: <4B6C5B41.8040308@uleth.ca> Here is a list of numbers for my conference space. If you use Skype, you will be directly connected to the room (the call is free on Skype). If you call from a land line/cell phone, you will be asked to enter the room number. Conference Room: 1349998 Skype (free): +9900827041349998 Telephone numbers: USA 1-201-793-9022 Canada 1-201-793-9022 Austria 0820 401 15470 Belgium 0703 57 134 France 0826 109 071 Germany 01805 00 9527 Ireland 0818 270 968 Italy 848 390 177 Spain 902 885 791 Switzerland 0848 560 397 United Kingdom 0870 0990 931 All other countries should choose the cheapest of the above national numbers or use Skype. -- Daniel Paul O'Donnell Associate Professor of English University of Lethbridge Chair and CEO, Text Encoding Initiative (http://www.tei-c.org/) Co-Chair, Digital Initiatives Advisory Board, Medieval Academy of America President-elect (English), Society for Digital Humanities/Soci?t? pour l'?tude des m?dias interactifs (http://sdh-semi.org/) Founding Director (2003-2009), Digital Medievalist Project (http://www.digitalmedievalist.org/) Vox: +1 403 329-2377 Fax: +1 403 382-7191 (non-confidential) Home Page: http://people.uleth.ca/~daniel.odonnell/ From James.Cummings at oucs.ox.ac.uk Sat Feb 6 15:07:24 2010 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Sat, 06 Feb 2010 20:07:24 +0000 Subject: [tei-council] Conference Call Numbers In-Reply-To: <4B6C5B41.8040308@uleth.ca> References: <4B6C5B41.8040308@uleth.ca> Message-ID: <4B6DCBFC.4060908@oucs.ox.ac.uk> Dan, Can you confirm that UK number, I just tested and it doesn't seem to work. I have a meeting directly before the conference call and may or may not be late. If I am, I do apologise. -James O'Donnell, Dan wrote: > Here is a list of numbers for my conference space. If you use Skype, you > will be directly connected to the room (the call is free on Skype). If > you call from a land line/cell phone, you will be asked to enter the > room number. > > Conference Room: 1349998 > > Skype (free): +9900827041349998 > > Telephone numbers: > USA 1-201-793-9022 > Canada 1-201-793-9022 > > Austria 0820 401 15470 > Belgium 0703 57 134 > France 0826 109 071 > Germany 01805 00 9527 > Ireland 0818 270 968 > Italy 848 390 177 > Spain 902 885 791 > Switzerland 0848 560 397 > United Kingdom 0870 0990 931 > > All other countries should choose the cheapest of the above national > numbers or use Skype. > -- Dr James Cummings, Research Technology Service Oxford University Computing Services University of Oxford From daniel.odonnell at uleth.ca Sat Feb 6 15:45:23 2010 From: daniel.odonnell at uleth.ca (O'Donnell, Dan) Date: Sat, 6 Feb 2010 13:45:23 -0700 Subject: [tei-council] Conference Call Numbers Message-ID: <05b001caa76d$4c7e8e03$2907428e@uleth.ca> I'll double check when I'm behind my computer again. ----------- Daniel O'Donnell University of Lethbridge (From my mobile telephone) --- original message --- From: "James Cummings" Subject: Re: [tei-council] Conference Call Numbers Date: February 6, 2010 Time: 1:7:46 Dan, Can you confirm that UK number, I just tested and it doesn't seem to work. I have a meeting directly before the conference call and may or may not be late. If I am, I do apologise. -James O'Donnell, Dan wrote: > Here is a list of numbers for my conference space. If you use Skype, you > will be directly connected to the room (the call is free on Skype). If > you call from a land line/cell phone, you will be asked to enter the > room number. > > Conference Room: 1349998 > > Skype (free): +9900827041349998 > > Telephone numbers: > USA 1-201-793-9022 > Canada 1-201-793-9022 > > Austria 0820 401 15470 > Belgium 0703 57 134 > France 0826 109 071 > Germany 01805 00 9527 > Ireland 0818 270 968 > Italy 848 390 177 > Spain 902 885 791 > Switzerland 0848 560 397 > United Kingdom 0870 0990 931 > > All other countries should choose the cheapest of the above national > numbers or use Skype. > -- Dr James Cummings, Research Technology Service Oxford University Computing Services University of Oxford From lou.burnard at oucs.ox.ac.uk Sun Feb 7 10:44:23 2010 From: lou.burnard at oucs.ox.ac.uk (Lou Burnard) Date: Sun, 07 Feb 2010 15:44:23 +0000 Subject: [tei-council] certainty revised In-Reply-To: <4B671B4A.7030904@uvic.ca> References: <4B62A211.2040609@oucs.ox.ac.uk> <4B6310FE.20606@uvic.ca> <4B66E484.9020809@oucs.ox.ac.uk> <4B671B4A.7030904@uvic.ca> Message-ID: <4B6EDFD7.7000309@oucs.ox.ac.uk> Martin Holmes wrote: > -------------------- > > The current documentation for > () > includes an example based on: > > Ernest went to old > Saybrook. > > and it says "For discussion of this example, see section 21.1.2 > Structured Indications of Uncertainty", but the example discussed in > 21.1.2 is now the much better (IMHO) example of Elizabeth and Essex. > Fixed xref; thanks! > -------------------- > > The example of the abbreviation expansion of SGML looks like this: > > You will want to use > > Standard > Generalized Markup Language > Some Grandiose Methodology for Losers > SGML > ... > > > > > > I suspect that the second @degree value should be "0.1", shouldn't it? > Don't the two have to add up to 1? > Um, no I don't think so. They are independent probabilities, I think. Unless @given is used, of course. > --------------------- > > Finally, I find myself a little puzzled by the application of > to @notAfter, @notBefore, etc. My habit in using these > attributes has been to decide once and for all, based on known > information and logical deduction, what the _actual_ earliest and latest > possible dates would be. It seems a little odd to me to say that > something is "not after 1857", but there's a 50% chance that it might > be. If you're not sure it's @notAfter="1857", then you need to move your > @notAfter value forward until you can be sure, don't you? That would seem like a sensible practoce to me too. I observe only that people like to be more nuanced (or vague) sometimes. In my > experience, there always _is_ a genuine value for @notBefore or > @notAfter -- in the case of an action by a person, for instance, the > date before which they were definitely not born, the date after which > they were definitely dead, or the point at which they would have been so > old as to break all known longevity records. After all, @notAfter is > defined as specifying "the latest possible date". > yes, but.... > One example from the text: > > From the 1st of March to > some time in April of 1857. > > > > Now, if "some time in April" is true, then @degree should surely be > "1.0". No, the precision implies only to the @notAfter value If "some time in April" is doubtful, then surely so is "the 1st > of March". Why? You might have documentary evidence for the 1st of March, for example. But if there is doubt, that doubt presumably originates in > external evidence, which ought at least to be adduced, and which itself > would presumably give a more realistic value for @notAfter. > Or it might not! I think this example is quite plausible as it stands, but would you find it more convincing if the @notAfter were replaced by a @to ? From lou.burnard at oucs.ox.ac.uk Sun Feb 7 11:44:53 2010 From: lou.burnard at oucs.ox.ac.uk (Lou Burnard) Date: Sun, 07 Feb 2010 16:44:53 +0000 Subject: [tei-council] Monday ticket agenda Message-ID: <4B6EEE05.9090800@oucs.ox.ac.uk> According to the minutes of our last call, we were going to discuss the following items * 2811239: new element 'object' * 2811234: add @ref to 'material' * 2724997: Cater for audio/video facsimile However, in practice, I haven't seen any discussion of these topics as yet so we should probably relegate them to the Dublin FTF unless anyone is all fired up to speak to them. There has however been some discussion of some of the 40 or so other outstanding tickets. I've therefore made a quick selection from outstanding amber issues, looking for some which (I think) we might possibly be able to resolve quickly. Feel free to propose others! * 2714682: permit as child or as sibling of -- at present we allow either. This is confusing. Is it right? * 2812634: @docStatus on * 2909766: made del and add dateable -- these both relate to use of TEI for born digital docs. not unreasonable stretches * 2925031: @ident datatype on -- what is the diff between data.code and data.enumerated * 2940860: add xml:space to att.global -- is this really necessary? * 2919640: global at facsKey -- redefine @facs or replace it? * 2925145: generic date class -- should @when mean @when-iso or @when-w3c? From mholmes at uvic.ca Sun Feb 7 12:51:32 2010 From: mholmes at uvic.ca (Martin Holmes) Date: Sun, 07 Feb 2010 09:51:32 -0800 Subject: [tei-council] certainty revised In-Reply-To: <4B6EDFD7.7000309@oucs.ox.ac.uk> References: <4B62A211.2040609@oucs.ox.ac.uk> <4B6310FE.20606@uvic.ca> <4B66E484.9020809@oucs.ox.ac.uk> <4B671B4A.7030904@uvic.ca> <4B6EDFD7.7000309@oucs.ox.ac.uk> Message-ID: <4B6EFDA4.1050906@uvic.ca> Hi Lou, >> -------------------- >> >> The example of the abbreviation expansion of SGML looks like this: >> >> You will want to use >> >> Standard >> Generalized Markup Language >> Some Grandiose Methodology for Losers >> SGML >> ... >> >> >> >> >> >> I suspect that the second @degree value should be "0.1", shouldn't it? >> Don't the two have to add up to 1? >> > > Um, no I don't think so. They are independent probabilities, I think. > Unless @given is used, of course. Aren't they mutually exclusive? And if so, shouldn't their probabilities add up to 1? (Apologies if I'm being dumb here -- I'm completely ignorant when it comes to stats.) >> --------------------- >> >> Finally, I find myself a little puzzled by the application of >> to @notAfter, @notBefore, etc. My habit in using these >> attributes has been to decide once and for all, based on known >> information and logical deduction, what the _actual_ earliest and latest >> possible dates would be. It seems a little odd to me to say that >> something is "not after 1857", but there's a 50% chance that it might >> be. If you're not sure it's @notAfter="1857", then you need to move your >> @notAfter value forward until you can be sure, don't you? > > That would seem like a sensible practoce to me too. I observe only that > people like to be more nuanced (or vague) sometimes. > > > In my >> experience, there always _is_ a genuine value for @notBefore or >> @notAfter -- in the case of an action by a person, for instance, the >> date before which they were definitely not born, the date after which >> they were definitely dead, or the point at which they would have been so >> old as to break all known longevity records. After all, @notAfter is >> defined as specifying "the latest possible date". >> > > yes, but.... > >> One example from the text: >> >> From the 1st of March to >> some time in April of 1857. >> >> >> >> Now, if "some time in April" is true, then @degree should surely be >> "1.0". > > No, the precision implies only to the @notAfter value > > > If "some time in April" is doubtful, then surely so is "the 1st >> of March". > > Why? You might have documentary evidence for the 1st of March, for example. > > But if there is doubt, that doubt presumably originates in >> external evidence, which ought at least to be adduced, and which itself >> would presumably give a more realistic value for @notAfter. >> > > Or it might not! > > I think this example is quite plausible as it stands, but would you find > it more convincing if the @notAfter were replaced by a @to ? I think if you find it OK, then we're simply differing with regard to the way I prefer to use these attributes versus the way other people might prefer to use them. I'm a bit literal-minded, so to me notAfter means "not after"; if it's perfectly OK for it to mean "probably not after", then I have no quibble. Cheers, Martin From dot.porter at gmail.com Sun Feb 7 12:54:08 2010 From: dot.porter at gmail.com (Dot Porter) Date: Sun, 7 Feb 2010 12:54:08 -0500 Subject: [tei-council] Monday ticket agenda In-Reply-To: <4B6EEE05.9090800@oucs.ox.ac.uk> References: <4B6EEE05.9090800@oucs.ox.ac.uk> Message-ID: <96f3df641002070954r1d7627e8t53386a81ece7d005@mail.gmail.com> Hi everyone, On Sun, Feb 7, 2010 at 11:44 AM, Lou Burnard wrote: > According to the minutes of our last call, we were going to discuss the > following items > ? ? * 2811239: new element 'object' > ? ? * 2811234: add @ref to 'material' > ? ? * 2724997: Cater for audio/video facsimile > However, in practice, I haven't seen any discussion of these topics as > yet so we should probably relegate them to the Dublin FTF unless anyone > is all fired up to speak to them. > The first two are interesting (imo) but not anything that can be taken care of quickly. I agree that they should be held off on until the F2F. Same for the third I'd think. Dot > There has however been some discussion of some of the 40 or so other > outstanding tickets. I've therefore made a quick selection from > outstanding amber issues, looking for some which (I think) we might > possibly be able to resolve quickly. Feel free to propose others! > > ? ? * 2714682: permit as child or as sibling of > ? ? ? ?-- at present we allow either. This is confusing. Is it right? > > ? ? * 2812634: @docStatus on > ? ? * 2909766: made del and add dateable > ? ? ? -- these both relate to use of TEI for born digital docs. > ? ? ? not unreasonable stretches > > ? ? * 2925031: @ident datatype on > ? ? ? -- what is the diff between data.code and data.enumerated > > ? ? * 2940860: add xml:space to att.global > ? ? ? -- is this really necessary? > > ? ? * 2919640: global at facsKey > ? ? ? ?-- redefine @facs or replace it? > > ? ? * 2925145: generic date class -- > ? ? ? ?should @when mean @when-iso or @when-w3c? > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > -- *~*~*~*~*~*~*~*~*~*~* Dot Porter (MA, MSLS) Metadata Manager (on leave) Digital Humanities Observatory (RIA), Regus House, 28-32 Upper Pembroke Street, Dublin 2, Ireland -- A Project of the Royal Irish Academy -- Phone: +353 1 234 2444 Fax: +353 1 234 2400 http://dho.ie Email: dot.porter at gmail.com *~*~*~*~*~*~*~*~*~*~* From sebastian.rahtz at oucs.ox.ac.uk Sun Feb 7 13:40:32 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Sun, 7 Feb 2010 18:40:32 +0000 Subject: [tei-council] Monday ticket agenda In-Reply-To: <4B6EEE05.9090800@oucs.ox.ac.uk> References: <4B6EEE05.9090800@oucs.ox.ac.uk> Message-ID: <37057505-2011-4BA4-94C8-8A45FCD50C02@oucs.ox.ac.uk> On 7 Feb 2010, at 16:44, Lou Burnard wrote: > According to the minutes of our last call, we were going to discuss the > following items > * 2811239: new element 'object' > * 2811234: add @ref to 'material' > * 2724997: Cater for audio/video facsimile I agree, we are not worthy/ready to address these > > * 2714682: permit as child or as sibling of > -- at present we allow either. This is confusing. Is it right? at first sight, seems like a mistake being a child of imprint. can someone see an example where its wrong to have biblScope as sibling? > > * 2812634: @docStatus on > * 2909766: made del and add dateable > -- these both relate to use of TEI for born digital docs. > not unreasonable stretches yes please, its time to get off the fence! > > * 2925031: @ident datatype on > -- what is the diff between data.code and data.enumerated > I've got a lot of sympathy with this request, it bites me all the time. but the proposed solution using breaks backward compatibility more than somewhat, surely? allowing either @ident or seems messy. I'm more inclined to give its local defintion of @ident > * 2940860: add xml:space to att.global > -- is this really necessary? I'm willing to bet not, but I'd be interested to hear from Syd, for I believe it was here who -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From mholmes at uvic.ca Sun Feb 7 14:50:51 2010 From: mholmes at uvic.ca (Martin Holmes) Date: Sun, 07 Feb 2010 11:50:51 -0800 Subject: [tei-council] Monday ticket agenda In-Reply-To: <37057505-2011-4BA4-94C8-8A45FCD50C02@oucs.ox.ac.uk> References: <4B6EEE05.9090800@oucs.ox.ac.uk> <37057505-2011-4BA4-94C8-8A45FCD50C02@oucs.ox.ac.uk> Message-ID: <4B6F199B.8040009@uvic.ca> Sebastian Rahtz wrote: > On 7 Feb 2010, at 16:44, Lou Burnard wrote: > >> * 2714682: permit as child or as sibling of >> -- at present we allow either. This is confusing. Is it right? > > at first sight, seems like a mistake being a child of imprint. can someone > see an example where its wrong to have biblScope as sibling? I favour having it in both places -- If it's no longer allowed as a child of , I'll have hundreds of documents and a huge amount of XSLT to fix. :-) On the larger issue, though, I don't really know what is doing, exactly. One reason I'm beginning to move away from in favour of is that the structness of it doesn't make much sense to me, and makes processing quite hard. I'm never sure why some elements are direct children of and some show up in . >> * 2812634: @docStatus on >> * 2909766: made del and add dateable >> -- these both relate to use of TEI for born digital docs. >> not unreasonable stretches > > yes please, its time to get off the fence! Seconded. >> * 2925031: @ident datatype on >> -- what is the diff between data.code and data.enumerated >> > I've got a lot of sympathy with this request, it bites me all the time. > but the proposed solution using breaks backward > compatibility more than somewhat, surely? allowing > either @ident or seems messy. I'm more inclined > to give its local defintion of @ident As a newbie, I realize I don't know whether, or under what conditions, changes to P5 that break backward compatibility would be allowed. Is there a policy on this? I would tend to assume that any changes to P5 should maintain backward compabitility with previous iterations of P5, while anything that would break compatibility should be moved forward into the plans for P6. Is that how it works? Cheers, Martin From sebastian.rahtz at oucs.ox.ac.uk Sun Feb 7 14:59:27 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Sun, 7 Feb 2010 19:59:27 +0000 Subject: [tei-council] Monday ticket agenda In-Reply-To: <4B6F199B.8040009@uvic.ca> References: <4B6EEE05.9090800@oucs.ox.ac.uk> <37057505-2011-4BA4-94C8-8A45FCD50C02@oucs.ox.ac.uk> <4B6F199B.8040009@uvic.ca> Message-ID: <8FFC493A-CD34-42D4-B751-EE7847D202E9@oucs.ox.ac.uk> On 7 Feb 2010, at 19:50, Martin Holmes wrote: > > I favour having it in both places -- If it's no longer allowed as a > child of , I'll have hundreds of documents and a huge amount of > XSLT to fix. :-) oh well, yes, there is that small problem! > > On the larger issue, though, I don't really know what is > doing, exactly. One reason I'm beginning to move away from > in favour of you worry me. I hope you are not following the model of our Great Leader From France, who has had in the past a habit of filling a with database-like markup and being surprised when no punctuation is generated. If you do , you're in charge of all the formatting. is much more robust. IMHO. > I'm never sure why some elements > are direct children of and some show up in . I'd probably agree, if we were starting from scratch > > As a newbie, I realize I don't know whether, or under what conditions, > changes to P5 that break backward compatibility would be allowed. Is > there a policy on this? I would tend to assume that any changes to P5 > should maintain backward compabitility with previous iterations of P5, > while anything that would break compatibility should be moved forward > into the plans for P6. Is that how it works? > the Birnbaum doctrine states that we should never break backward compatibility - except when we really have to. It's not forbidden, merely to be taken very seriously. There _are_ no plans for P6, it should be noted. Its entirely unclear to me what would prompt us to cross that Rubicon. -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From James.Cummings at oucs.ox.ac.uk Sun Feb 7 15:07:51 2010 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Sun, 07 Feb 2010 20:07:51 +0000 Subject: [tei-council] certainty revised In-Reply-To: <4B6EFDA4.1050906@uvic.ca> References: <4B62A211.2040609@oucs.ox.ac.uk> <4B6310FE.20606@uvic.ca> <4B66E484.9020809@oucs.ox.ac.uk> <4B671B4A.7030904@uvic.ca> <4B6EDFD7.7000309@oucs.ox.ac.uk> <4B6EFDA4.1050906@uvic.ca> Message-ID: <4B6F1D97.4090808@oucs.ox.ac.uk> Martin Holmes wrote: > I think if you find it OK, then we're simply differing with regard to > the way I prefer to use these attributes versus the way other people > might prefer to use them. I'm a bit literal-minded, so to me notAfter > means "not after"; if it's perfectly OK for it to mean "probably not > after", then I have no quibble. Isn't this true of any markup though? If I say I can elsewhere express doubts about that @when. Just because it is precise doesn't mean it is certain. So just because I'm precise in my @notAfter (because I have evidence that provides me that date) doesn't mean that I'm 100% confidence in the nature of that evidence. In my mind @notAfter means the latest possible date for which we have some evidence...the quality of that evidence may be disputable. -James From James.Cummings at oucs.ox.ac.uk Sun Feb 7 15:28:19 2010 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Sun, 07 Feb 2010 20:28:19 +0000 Subject: [tei-council] Monday ticket agenda In-Reply-To: <8FFC493A-CD34-42D4-B751-EE7847D202E9@oucs.ox.ac.uk> References: <4B6EEE05.9090800@oucs.ox.ac.uk> <37057505-2011-4BA4-94C8-8A45FCD50C02@oucs.ox.ac.uk> <4B6F199B.8040009@uvic.ca> <8FFC493A-CD34-42D4-B751-EE7847D202E9@oucs.ox.ac.uk> Message-ID: <4B6F2263.1040801@oucs.ox.ac.uk> Sebastian Rahtz wrote: >> As a newbie, I realize I don't know whether, or under what conditions, >> changes to P5 that break backward compatibility would be allowed. Is >> there a policy on this? I would tend to assume that any changes to P5 >> should maintain backward compabitility with previous iterations of P5, >> while anything that would break compatibility should be moved forward >> into the plans for P6. Is that how it works? >> > the Birnbaum doctrine states that we should > never break backward compatibility - except when we really have to. > It's not forbidden, merely to be taken very seriously. > > There _are_ no plans for P6, it should be noted. Its entirely unclear > to me what would prompt us to cross that Rubicon. For others, the 'Birnbaum doctrine' is simply this document here: http://www.tei-c.org/Activities/Council/Working/tcw09.xml On move to P6 it says: "Council may break backward compatibility in a more substantial and comprehensive way (as happened with the transition to P4 to P5) only with the transition to a new major version (e.g., P6, but not P5.99999). Such transitions should happen only in response to the emergence of new technologies (e.g., the transition from SGML to XML) or the development of a new architecture that conveys substantial benefit (e.g., the development of the new class system). Historically, new major versions have emerged approximately every five years." -James From mholmes at uvic.ca Sun Feb 7 18:02:35 2010 From: mholmes at uvic.ca (Martin Holmes) Date: Sun, 07 Feb 2010 15:02:35 -0800 Subject: [tei-council] Monday ticket agenda In-Reply-To: <8FFC493A-CD34-42D4-B751-EE7847D202E9@oucs.ox.ac.uk> References: <4B6EEE05.9090800@oucs.ox.ac.uk> <37057505-2011-4BA4-94C8-8A45FCD50C02@oucs.ox.ac.uk> <4B6F199B.8040009@uvic.ca> <8FFC493A-CD34-42D4-B751-EE7847D202E9@oucs.ox.ac.uk> Message-ID: <4B6F468B.6040502@uvic.ca> Hi Sebastian, Sebastian Rahtz wrote: > On 7 Feb 2010, at 19:50, Martin Holmes wrote: >> I favour having it in both places -- If it's no longer allowed as a >> child of , I'll have hundreds of documents and a huge amount of >> XSLT to fix. :-) > oh well, yes, there is that small problem! > >> On the larger issue, though, I don't really know what is >> doing, exactly. One reason I'm beginning to move away from >> in favour of > > you worry me. I hope you are not following the model of our > Great Leader From France, who has had in the past a habit > of filling a with database-like markup and being surprised > when no punctuation is generated. If you do , you're in charge > of all the formatting. is much more robust. IMHO. I am following his lead, but including all my own punctuation. This is one of the things I'll talk about in Dublin. >> I'm never sure why some elements >> are direct children of and some show up in . > I'd probably agree, if we were starting from scratch > >> As a newbie, I realize I don't know whether, or under what conditions, >> changes to P5 that break backward compatibility would be allowed. Is >> there a policy on this? I would tend to assume that any changes to P5 >> should maintain backward compabitility with previous iterations of P5, >> while anything that would break compatibility should be moved forward >> into the plans for P6. Is that how it works? >> > the Birnbaum doctrine states that we should > never break backward compatibility - except when we really have to. > It's not forbidden, merely to be taken very seriously. > > There _are_ no plans for P6, it should be noted. Its entirely unclear > to me what would prompt us to cross that Rubicon. Perhaps the existence of a few desirable changes that would break backward compatibility? Cheers, Martin From daniel.odonnell at uleth.ca Mon Feb 8 01:02:45 2010 From: daniel.odonnell at uleth.ca (O'Donnell, Dan) Date: Sun, 07 Feb 2010 23:02:45 -0700 Subject: [tei-council] Conference Call Numbers In-Reply-To: <4B6DCBFC.4060908@oucs.ox.ac.uk> References: <4B6C5B41.8040308@uleth.ca> <4B6DCBFC.4060908@oucs.ox.ac.uk> Message-ID: <4B6FA905.6040108@uleth.ca> They were doing planned server work on the weekend. The number looks good (though I can't test it from Canada). But I suspect you hit them when the server was down. -dan James Cummings wrote: > > Dan, > > Can you confirm that UK number, I just tested and it doesn't seem to > work. > > I have a meeting directly before the conference call and may or may > not be late. If I am, I do apologise. > > -James > > > O'Donnell, Dan wrote: >> Here is a list of numbers for my conference space. If you use Skype, >> you will be directly connected to the room (the call is free on >> Skype). If you call from a land line/cell phone, you will be asked to >> enter the room number. >> >> Conference Room: 1349998 >> >> Skype (free): +9900827041349998 >> >> Telephone numbers: >> USA 1-201-793-9022 >> Canada 1-201-793-9022 >> >> Austria 0820 401 15470 >> Belgium 0703 57 134 >> France 0826 109 071 >> Germany 01805 00 9527 >> Ireland 0818 270 968 >> Italy 848 390 177 >> Spain 902 885 791 >> Switzerland 0848 560 397 >> United Kingdom 0870 0990 931 >> >> All other countries should choose the cheapest of the above national >> numbers or use Skype. >> > > -- Daniel Paul O'Donnell Associate Professor of English University of Lethbridge Chair and CEO, Text Encoding Initiative (http://www.tei-c.org/) Co-Chair, Digital Initiatives Advisory Board, Medieval Academy of America President-elect (English), Society for Digital Humanities/Soci?t? pour l'?tude des m?dias interactifs (http://sdh-semi.org/) Founding Director (2003-2009), Digital Medievalist Project (http://www.digitalmedievalist.org/) Vox: +1 403 329-2377 Fax: +1 403 382-7191 (non-confidential) Home Page: http://people.uleth.ca/~daniel.odonnell/ From sebastian.rahtz at oucs.ox.ac.uk Mon Feb 8 04:57:26 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 8 Feb 2010 09:57:26 +0000 Subject: [tei-council] Conference Call Numbers In-Reply-To: <4B6C5B41.8040308@uleth.ca> References: <4B6C5B41.8040308@uleth.ca> Message-ID: <1FD8E6E9-1A92-4597-A64B-74280A6D9FE0@oucs.ox.ac.uk> the UK number still claims to be non-existent when I call it to test. -- Sebastian Rahtz (acting) Information and Support Group Manager Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From sebastian.rahtz at oucs.ox.ac.uk Mon Feb 8 09:58:50 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 8 Feb 2010 14:58:50 +0000 Subject: [tei-council] phone numbers Message-ID: <4CD809E7-471B-4B7F-A0C2-8D0478A1C2F3@oucs.ox.ac.uk> is anyone getting throigh on UK number? -- Sebastian Rahtz (acting) Information and Support Group Manager Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From lou.burnard at oucs.ox.ac.uk Mon Feb 8 09:59:10 2010 From: lou.burnard at oucs.ox.ac.uk (Lou) Date: Mon, 08 Feb 2010 14:59:10 +0000 Subject: [tei-council] phone numbers In-Reply-To: <4CD809E7-471B-4B7F-A0C2-8D0478A1C2F3@oucs.ox.ac.uk> References: <4CD809E7-471B-4B7F-A0C2-8D0478A1C2F3@oucs.ox.ac.uk> Message-ID: <4B7026BE.4060108@oucs.ox.ac.uk> I'm on skype., me Sebastian Rahtz wrote: > is anyone getting throigh on UK number? > -- > Sebastian Rahtz > (acting) Information and Support Group Manager > Oxford University Computing Services > 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 > > S?lo le pido a Dios > que el futuro no me sea indiferente > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council From gabriel.bodard at kcl.ac.uk Mon Feb 8 09:59:48 2010 From: gabriel.bodard at kcl.ac.uk (Gabriel Bodard) Date: Mon, 8 Feb 2010 14:59:48 +0000 Subject: [tei-council] Monday ticket agenda In-Reply-To: <4B6EEE05.9090800@oucs.ox.ac.uk> References: <4B6EEE05.9090800@oucs.ox.ac.uk> Message-ID: <4B7026E4.30108@kcl.ac.uk> I will argue in support of xml:space, below. I'd also like to add to today's agenda: * 2862151: Allow certainty etc. in "empty" elements which was on hold while we were discussing the meaning of @match (some of which discussion found its way into the comments of that ticket), but which I have re-opened now that the definition of @match is that which I erroneously previously thought it was. Gabby On 2010-02-07 16:44, Lou Burnard wrote: > According to the minutes of our last call, we were going to discuss the > following items > * 2811239: new element 'object' > * 2811234: add @ref to 'material' > * 2724997: Cater for audio/video facsimile > However, in practice, I haven't seen any discussion of these topics as > yet so we should probably relegate them to the Dublin FTF unless anyone > is all fired up to speak to them. > > There has however been some discussion of some of the 40 or so other > outstanding tickets. I've therefore made a quick selection from > outstanding amber issues, looking for some which (I think) we might > possibly be able to resolve quickly. Feel free to propose others! > > * 2714682: permit as child or as sibling of > -- at present we allow either. This is confusing. Is it right? > > * 2812634: @docStatus on > * 2909766: made del and add dateable > -- these both relate to use of TEI for born digital docs. > not unreasonable stretches > > * 2925031: @ident datatype on > -- what is the diff between data.code and data.enumerated > > * 2940860: add xml:space to att.global > -- is this really necessary? > > * 2919640: global at facsKey > -- redefine @facs or replace it? > > * 2925145: generic date class -- > should @when mean @when-iso or @when-w3c? > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council -- Dr Gabriel BODARD (Epigrapher & Digital Classicist) Centre for Computing in the Humanities King's College London 26-29 Drury Lane London WC2B 5RL Email: gabriel.bodard at kcl.ac.uk Tel: +44 (0)20 7848 1388 Fax: +44 (0)20 7848 2980 http://www.digitalclassicist.org/ http://www.currentepigraphy.org/ From sebastian.rahtz at oucs.ox.ac.uk Mon Feb 8 11:22:12 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 8 Feb 2010 16:22:12 +0000 Subject: [tei-council] xml:space Message-ID: <877B3A87-0929-4D80-8A7E-34EC5AF78C86@oucs.ox.ac.uk> worth looking at http://lists.village.virginia.edu/pipermail/tei-council/2007/008770.html and messages thereafter -- Sebastian Rahtz (acting) Information and Support Group Manager Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From sebastian.rahtz at oucs.ox.ac.uk Mon Feb 8 11:35:46 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 8 Feb 2010 16:35:46 +0000 Subject: [tei-council] how can John W use @facs legally? Message-ID: <1508F57D-B245-4539-83FC-A20C594F035F@oucs.ox.ac.uk> This is a bit ugly, but it is technically feasible.

hello world

-- Sebastian Rahtz (acting) Information and Support Group Manager Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From mholmes at uvic.ca Mon Feb 8 11:55:17 2010 From: mholmes at uvic.ca (Martin Holmes) Date: Mon, 8 Feb 2010 08:55:17 -0800 Subject: [tei-council] Apologies for late arrival at the telco Message-ID: <4B7041F5.6040308@uvic.ca> Hi there, Just wanted to apologise for only getting in for the second half of the telco today. It started right in the middle of my commute time, so my plan had been to take the morning off and do the telco from home, but it turned out that I had to be at work for other reasons. Cheers, Martin -- Martin Holmes University of Victoria Humanities Computing and Media Centre (mholmes at uvic.ca) Half-Baked Software, Inc. (mholmes at halfbakedsoftware.com) martin at mholmes.com From laurent.romary at loria.fr Mon Feb 8 12:03:40 2010 From: laurent.romary at loria.fr (Laurent Romary) Date: Mon, 8 Feb 2010 18:03:40 +0100 Subject: [tei-council] Apologies for late arrival at the telco In-Reply-To: <4B7041F5.6040308@uvic.ca> References: <4B7041F5.6040308@uvic.ca> Message-ID: <68658096-AF2D-4D00-9BD1-7A68EBAF23F0@loria.fr> No problem. You have indeed been appointed in the little task force (with Kevin and I) on biblStruct, with the following objectives: - identify a core set of types that we want the TEI to support - elicit reference biblStruct usages for such types on the basis of a selection of commented examples (extracted from the giudelines). Have a good day! Laurent Le 8 f?vr. 10 ? 17:55, Martin Holmes a ?crit : > Hi there, > > Just wanted to apologise for only getting in for the second half of > the > telco today. It started right in the middle of my commute time, so my > plan had been to take the morning off and do the telco from home, > but it > turned out that I had to be at work for other reasons. > > Cheers, > Martin > -- > Martin Holmes > University of Victoria Humanities Computing and Media Centre > (mholmes at uvic.ca) > Half-Baked Software, Inc. > (mholmes at halfbakedsoftware.com) > martin at mholmes.com > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council From gabriel.bodard at kcl.ac.uk Mon Feb 8 12:19:45 2010 From: gabriel.bodard at kcl.ac.uk (Gabriel Bodard) Date: Mon, 8 Feb 2010 17:19:45 +0000 Subject: [tei-council] xml:space In-Reply-To: <877B3A87-0929-4D80-8A7E-34EC5AF78C86@oucs.ox.ac.uk> References: <877B3A87-0929-4D80-8A7E-34EC5AF78C86@oucs.ox.ac.uk> Message-ID: <4B7047B1.5040904@kcl.ac.uk> From what I can see, Syd's argument was not that @xml:space should not be allowed, but that it should not be global, because it is meaningless on empty elements such as . If this really worries people then I could get behind a proposal to only introduce it on and a few other block level elements, for example. (But it doesn't worry me.) G On 2010-02-08 16:22, Sebastian Rahtz wrote: > worth looking at http://lists.village.virginia.edu/pipermail/tei-council/2007/008770.html and messages thereafter > -- > Sebastian Rahtz > (acting) Information and Support Group Manager > Oxford University Computing Services > 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 > > S?lo le pido a Dios > que el futuro no me sea indiferente > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council -- Dr Gabriel BODARD (Epigrapher & Digital Classicist) Centre for Computing in the Humanities King's College London 26-29 Drury Lane London WC2B 5RL Email: gabriel.bodard at kcl.ac.uk Tel: +44 (0)20 7848 1388 Fax: +44 (0)20 7848 2980 http://www.digitalclassicist.org/ http://www.currentepigraphy.org/ From mholmes at uvic.ca Mon Feb 8 12:24:17 2010 From: mholmes at uvic.ca (Martin Holmes) Date: Mon, 8 Feb 2010 09:24:17 -0800 Subject: [tei-council] Apologies for late arrival at the telco In-Reply-To: <68658096-AF2D-4D00-9BD1-7A68EBAF23F0@loria.fr> References: <4B7041F5.6040308@uvic.ca> <68658096-AF2D-4D00-9BD1-7A68EBAF23F0@loria.fr> Message-ID: <4B7048C1.1080307@uvic.ca> Hi Laurent, These are the 62 item types I've needed to differentiate over the past few years: 1. ABSTRACT 2. ADDENDUM 3. ANNOUNCEMENT 4. ARTICLE COMMENTARY 5. ARTWORK 6. AUDIO RECORDING 7. BILL 8. BLOG 9. BLOG POSTING 10. BOOK - one author 11. BOOK - two authors 12. BOOK - three authors 13. BOOK - four or more authors 14. BOOK - EDITED 15. BOOKS - MULTIPLE EDITIONS 16. BOOK - MULTIPLE VOLUMES 17. BOOKS - CORPORATE AUTHOR 18. BOOK IN A SERIES 19. BOOK REVIEW in a JOURNAL 20. BOOK SUBMITTED BUT NOT YET PUBLISHED 21. CASE 22. CHAPTER IN A BOOK (WORK IN AN ANTHOLOGY) 23. COMPUTER SOFTWARE 24. DISSERTATION or THESIS (UNPUBLISHED) 25. E-BOOK 26. EDITION (of a saga or similar traditional text) 27. ENCYCLOPEDIA or DICTIONARY ENTRY 28. FILM, VIDEOTAPE, or DVD 29. GOVERNMENT DOCUMENT 30. HEARING 31. INSTANT MESSAGE 32. JOURNAL ARTICLE 33. JOURNAL ARTICLE in a SPECIAL ISSUE 34. LETTER 35. MAGAZINE ? NO AUTHOR 36. MANUSCRIPT 37. MAP 38. NEWSPAPER: NO AUTHOR 39. ONLINE ARTICLE 40. ONLINE BROCHURE 41. ONLINE COMMUNITY 42. ONLINE FACT SHEET 43. ONLINE LETTER TO EDITOR 44. ONLINE PROJECT 45. ONLINE PUBLIC ANNOUNCEMENT 46. ONLINE REPORT 47. PATENT 48. PERSONAL COMMUNICATION 49. PERSONAL INTERVIEW 50. PRESENTATION (e.g. Conference paper) 51. PODCAST 52. PRIVATE EMAIL 53. PAPER IN A PROCEEDINGS 54. PAPER SUBMITTED BUT NOT YET PUBLISHED 55. PAPER (UNPUBLISHED) DELIVERED AT A CONFERENCE 56. RADIO BROADCAST 57. REPRINT 58. STATUTE 59. TELEVISION: NEWS BROADCAST 60. TELEVISION: SERIES EPISODE 61. TRANSLATION 62. WEBSITE The main reasons for having to differentiate them have been the requirement to render them in particular ways to conform with one or other of the major style guides (or the idiosyncratic preferences of an editor). We might start by trying to reduce these to a set of coherent categories. Cheers, Martin Laurent Romary wrote: > No problem. You have indeed been appointed in the little task force > (with Kevin and I) on biblStruct, with the following objectives: > - identify a core set of types that we want the TEI to support > - elicit reference biblStruct usages for such types on the basis of a > selection of commented examples (extracted from the giudelines). > Have a good day! > Laurent > > Le 8 f?vr. 10 ? 17:55, Martin Holmes a ?crit : > >> Hi there, >> >> Just wanted to apologise for only getting in for the second half of >> the >> telco today. It started right in the middle of my commute time, so my >> plan had been to take the morning off and do the telco from home, >> but it >> turned out that I had to be at work for other reasons. >> >> Cheers, >> Martin >> -- >> Martin Holmes >> University of Victoria Humanities Computing and Media Centre >> (mholmes at uvic.ca) >> Half-Baked Software, Inc. >> (mholmes at halfbakedsoftware.com) >> martin at mholmes.com >> _______________________________________________ >> tei-council mailing list >> tei-council at lists.village.Virginia.EDU >> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > > . > -- Martin Holmes University of Victoria Humanities Computing and Media Centre (mholmes at uvic.ca) Half-Baked Software, Inc. (mholmes at halfbakedsoftware.com) martin at mholmes.com From laurent.romary at loria.fr Mon Feb 8 12:27:22 2010 From: laurent.romary at loria.fr (Laurent Romary) Date: Mon, 8 Feb 2010 18:27:22 +0100 Subject: [tei-council] Apologies for late arrival at the telco In-Reply-To: <4B7048C1.1080307@uvic.ca> References: <4B7041F5.6040308@uvic.ca> <68658096-AF2D-4D00-9BD1-7A68EBAF23F0@loria.fr> <4B7048C1.1080307@uvic.ca> Message-ID: Thanks Martin, My rule of thumb would be to group them in classes with similar bibliographical behaviours, i.e. (and more prosaically) classes that we tend to describe in the same way from the point of view of biblStruct. ... we need a good ontological principle here. Laurent Le 8 f?vr. 10 ? 18:24, Martin Holmes a ?crit : > Hi Laurent, > > These are the 62 item types I've needed to differentiate over the past > few years: > > 1. ABSTRACT > 2. ADDENDUM > 3. ANNOUNCEMENT > 4. ARTICLE COMMENTARY > 5. ARTWORK > 6. AUDIO RECORDING > 7. BILL > 8. BLOG > 9. BLOG POSTING > 10. BOOK - one author > 11. BOOK - two authors > 12. BOOK - three authors > 13. BOOK - four or more authors > 14. BOOK - EDITED > 15. BOOKS - MULTIPLE EDITIONS > 16. BOOK - MULTIPLE VOLUMES > 17. BOOKS - CORPORATE AUTHOR > 18. BOOK IN A SERIES > 19. BOOK REVIEW in a JOURNAL > 20. BOOK SUBMITTED BUT NOT YET PUBLISHED > 21. CASE > 22. CHAPTER IN A BOOK (WORK IN AN ANTHOLOGY) > 23. COMPUTER SOFTWARE > 24. DISSERTATION or THESIS (UNPUBLISHED) > 25. E-BOOK > 26. EDITION (of a saga or similar traditional text) > 27. ENCYCLOPEDIA or DICTIONARY ENTRY > 28. FILM, VIDEOTAPE, or DVD > 29. GOVERNMENT DOCUMENT > 30. HEARING > 31. INSTANT MESSAGE > 32. JOURNAL ARTICLE > 33. JOURNAL ARTICLE in a SPECIAL ISSUE > 34. LETTER > 35. MAGAZINE ? NO AUTHOR > 36. MANUSCRIPT > 37. MAP > 38. NEWSPAPER: NO AUTHOR > 39. ONLINE ARTICLE > 40. ONLINE BROCHURE > 41. ONLINE COMMUNITY > 42. ONLINE FACT SHEET > 43. ONLINE LETTER TO EDITOR > 44. ONLINE PROJECT > 45. ONLINE PUBLIC ANNOUNCEMENT > 46. ONLINE REPORT > 47. PATENT > 48. PERSONAL COMMUNICATION > 49. PERSONAL INTERVIEW > 50. PRESENTATION (e.g. Conference paper) > 51. PODCAST > 52. PRIVATE EMAIL > 53. PAPER IN A PROCEEDINGS > 54. PAPER SUBMITTED BUT NOT YET PUBLISHED > 55. PAPER (UNPUBLISHED) DELIVERED AT A CONFERENCE > 56. RADIO BROADCAST > 57. REPRINT > 58. STATUTE > 59. TELEVISION: NEWS BROADCAST > 60. TELEVISION: SERIES EPISODE > 61. TRANSLATION > 62. WEBSITE > > The main reasons for having to differentiate them have been the > requirement to render them in particular ways to conform with one or > other of the major style guides (or the idiosyncratic preferences of > an > editor). We might start by trying to reduce these to a set of coherent > categories. > > Cheers, > Martin > > Laurent Romary wrote: >> No problem. You have indeed been appointed in the little task force >> (with Kevin and I) on biblStruct, with the following objectives: >> - identify a core set of types that we want the TEI to support >> - elicit reference biblStruct usages for such types on the basis of a >> selection of commented examples (extracted from the giudelines). >> Have a good day! >> Laurent >> >> Le 8 f?vr. 10 ? 17:55, Martin Holmes a ?crit : >> >>> Hi there, >>> >>> Just wanted to apologise for only getting in for the second half of >>> the >>> telco today. It started right in the middle of my commute time, so >>> my >>> plan had been to take the morning off and do the telco from home, >>> but it >>> turned out that I had to be at work for other reasons. >>> >>> Cheers, >>> Martin >>> -- >>> Martin Holmes >>> University of Victoria Humanities Computing and Media Centre >>> (mholmes at uvic.ca) >>> Half-Baked Software, Inc. >>> (mholmes at halfbakedsoftware.com) >>> martin at mholmes.com >>> _______________________________________________ >>> tei-council mailing list >>> tei-council at lists.village.Virginia.EDU >>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council >> >> . >> > > -- > Martin Holmes > University of Victoria Humanities Computing and Media Centre > (mholmes at uvic.ca) > Half-Baked Software, Inc. > (mholmes at halfbakedsoftware.com) > martin at mholmes.com > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council From mholmes at uvic.ca Mon Feb 8 12:30:20 2010 From: mholmes at uvic.ca (Martin Holmes) Date: Mon, 8 Feb 2010 09:30:20 -0800 Subject: [tei-council] xml:space In-Reply-To: <4B7047B1.5040904@kcl.ac.uk> References: <877B3A87-0929-4D80-8A7E-34EC5AF78C86@oucs.ox.ac.uk> <4B7047B1.5040904@kcl.ac.uk> Message-ID: <4B704A2C.5050106@uvic.ca> Gabriel Bodard wrote: > From what I can see, Syd's argument was not that @xml:space should not > be allowed, but that it should not be global, because it is meaningless > on empty elements such as . If this really worries people then > I could get behind a proposal to only introduce it on and a > few other block level elements, for example. (But it doesn't worry me.) It doesn't worry me either. As Lou pointed out today, there are lots of ways in which you can encode things nonsensically without breaking validity. While we might want to use the schema to disallow such things where it's easy to do so, in this case it would be hard. We'd end up having to create a class of elements worthy of xml:space, and there would be ongoing debate about which elements deserved to be members of that class. Far simpler to allow it and be done with it. If I want to go for then (probably) more fool me. [Cue someone with a compelling use-case for @xml:space on .] Cheers, Martin -- Martin Holmes University of Victoria Humanities Computing and Media Centre (mholmes at uvic.ca) Half-Baked Software, Inc. (mholmes at halfbakedsoftware.com) martin at mholmes.com From James.Cummings at oucs.ox.ac.uk Mon Feb 8 13:35:24 2010 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Mon, 08 Feb 2010 18:35:24 +0000 Subject: [tei-council] xml:space In-Reply-To: <4B704A2C.5050106@uvic.ca> References: <877B3A87-0929-4D80-8A7E-34EC5AF78C86@oucs.ox.ac.uk> <4B7047B1.5040904@kcl.ac.uk> <4B704A2C.5050106@uvic.ca> Message-ID: <4B70596C.10007@oucs.ox.ac.uk> Martin Holmes wrote: > > then (probably) more fool me. > [Cue someone with a compelling use-case for @xml:space on .] I've just spent the last few minutes trying to come up with some, but every time I do I think to myself 'that is really a
not a ' or thing 'no, that is @xml:space on the element containing ' ... I give up. I don't see that this is any more nonsensical than: ... the @xml:lang does not apply to the thing the element points at (by its definition), but the content of the element itself, which is non-existent. I sometimes think that I should write a blog post entitled: "Global Attributes Considered Harmful", because it annoys the heck out of me every time I notice a global attribute on some element (usually in the header) which doesn't make sense with the semantics of that element. In most cases it is because to my mind the attribute in question should be global-underneath-text rather than truly global. -James From mholmes at uvic.ca Mon Feb 8 14:15:34 2010 From: mholmes at uvic.ca (Martin Holmes) Date: Mon, 8 Feb 2010 11:15:34 -0800 Subject: [tei-council] xml:space In-Reply-To: <4B70596C.10007@oucs.ox.ac.uk> References: <877B3A87-0929-4D80-8A7E-34EC5AF78C86@oucs.ox.ac.uk> <4B7047B1.5040904@kcl.ac.uk> <4B704A2C.5050106@uvic.ca> <4B70596C.10007@oucs.ox.ac.uk> Message-ID: <4B7062D6.4060907@uvic.ca> James Cummings wrote: > I sometimes think that I should write a blog post entitled: > "Global Attributes Considered Harmful", because it annoys the > heck out of me every time I notice a global attribute on some > element (usually in the header) which doesn't make sense with the > semantics of that element. In most cases it is because to my mind > the attribute in question should be global-underneath-text rather > than truly global. I think global attributes deserve to be so when the difficulty of restricting them without endless bickering outweighs the annoyance you (and others) feel when they're inappropriately available. I can almost always think of ways that anything that shows up in might show up also in somewhere. Perhaps I prefer to express my in the form of Anglo-Saxon verse, for instance, and I want @xml:space="preserve" so that the half-lines line up properly. Cheers, Martin -- Martin Holmes University of Victoria Humanities Computing and Media Centre (mholmes at uvic.ca) Half-Baked Software, Inc. (mholmes at halfbakedsoftware.com) martin at mholmes.com From gabriel.bodard at kcl.ac.uk Mon Feb 8 17:46:25 2010 From: gabriel.bodard at kcl.ac.uk (Gabriel BODARD) Date: Mon, 8 Feb 2010 22:46:25 +0000 Subject: [tei-council] TEI SF repo blocked to US-sanctioned countries? Message-ID: <4B709441.9000307@kcl.ac.uk> Would someone who had admin control over the TEI project at SourceForge like to take a look at the project settings and consider unchecking the box that says we need to be blocked to users from US-sanctioned areas because of rules against the export of encryption technology? (See http://sourceforge.net/blog/some-good-news-sourceforge-removes-blanket-blocking/ for the background.) As far as I know the TEI isn't in the business of building or using encyrption tech, so this should be safe...? (And I hate to think of colleagues in N Korea, Iran or Cuba unable to download the source of the TEI schemas, guidelines, Roma, etc.) G -- Dr Gabriel BODARD (Epigrapher & Digital Classicist) Centre for Computing in the Humanities King's College London 26-29 Drury Lane London WC2B 5RL Email: gabriel.bodard at kcl.ac.uk Tel: +44 (0)20 7848 1388 Fax: +44 (0)20 7848 2980 http://www.digitalclassicist.org/ http://www.currentepigraphy.org/ From sebastian.rahtz at oucs.ox.ac.uk Mon Feb 8 18:06:32 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 8 Feb 2010 23:06:32 +0000 Subject: [tei-council] TEI SF repo blocked to US-sanctioned countries? In-Reply-To: <4B709441.9000307@kcl.ac.uk> References: <4B709441.9000307@kcl.ac.uk> Message-ID: <05C5B8B9-4993-4971-A87B-001039E14E91@oucs.ox.ac.uk> On 8 Feb 2010, at 22:46, Gabriel BODARD wrote: > Would someone who had admin control over the TEI project at SourceForge > like to take a look at the project settings and consider unchecking the > box that says we need to be blocked to users from US-sanctioned areas > because of rules against the export of encryption technology? done. -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From lou.burnard at oucs.ox.ac.uk Mon Feb 8 18:07:42 2010 From: lou.burnard at oucs.ox.ac.uk (Lou Burnard) Date: Mon, 08 Feb 2010 23:07:42 +0000 Subject: [tei-council] TEI SF repo blocked to US-sanctioned countries? In-Reply-To: <05C5B8B9-4993-4971-A87B-001039E14E91@oucs.ox.ac.uk> References: <4B709441.9000307@kcl.ac.uk> <05C5B8B9-4993-4971-A87B-001039E14E91@oucs.ox.ac.uk> Message-ID: <4B70993E.5080505@oucs.ox.ac.uk> Sebastian Rahtz wrote: > On 8 Feb 2010, at 22:46, Gabriel BODARD wrote: > >> Would someone who had admin control over the TEI project at SourceForge >> like to take a look at the project settings and consider unchecking the >> box that says we need to be blocked to users from US-sanctioned areas >> because of rules against the export of encryption technology? > > done. > beat me to it. Was busy watching strange program about danish comedians in n. korea on bbc4 From sebastian.rahtz at oucs.ox.ac.uk Mon Feb 8 18:17:02 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 8 Feb 2010 23:17:02 +0000 Subject: [tei-council] facsKey agayne Message-ID: <76B43C96-34D7-4898-93F0-FB77D5145CDF@oucs.ox.ac.uk> A couple of conversations outside my office this afternoon suggest that people who want to use @facs to point to an arbitrary identifier can do so trivially by making up their own protocol. Thus

is short for the normal HTTP

but

is equally a legal URI, where "tk" is a new adhoc protocol. Examples at http://en.wikipedia.org/wiki/URI_scheme#Unofficial_but_common_URI_schemes show similar ideas - the "doi:" protocol is like this, since it references an arbitrary identifier which does not get resolved to some web address. Using @facs in this way is much better than @facsKey, IMHO, because it signals clearly to the processing application what is going on, but does not need a new attribute. It means the user can make use of _several_ protocols in the same document. Or is all this completely mad? -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From sebastian.rahtz at oucs.ox.ac.uk Mon Feb 8 18:17:26 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 8 Feb 2010 23:17:26 +0000 Subject: [tei-council] TEI SF repo blocked to US-sanctioned countries? In-Reply-To: <4B70993E.5080505@oucs.ox.ac.uk> References: <4B709441.9000307@kcl.ac.uk> <05C5B8B9-4993-4971-A87B-001039E14E91@oucs.ox.ac.uk> <4B70993E.5080505@oucs.ox.ac.uk> Message-ID: <6074411E-761B-4B4C-8497-959A61D8F564@oucs.ox.ac.uk> On 8 Feb 2010, at 23:07, Lou Burnard wrote: > > beat me to it. Was busy watching strange program about danish comedians > in n. korea on bbc4 > well, Glee finished earlier -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From sebastian.rahtz at oucs.ox.ac.uk Mon Feb 8 18:21:47 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 8 Feb 2010 23:21:47 +0000 Subject: [tei-council] facsKey agayne In-Reply-To: <76B43C96-34D7-4898-93F0-FB77D5145CDF@oucs.ox.ac.uk> References: <76B43C96-34D7-4898-93F0-FB77D5145CDF@oucs.ox.ac.uk> Message-ID: <50B45F19-2274-4219-91D2-F1BD7F63FBE4@oucs.ox.ac.uk> or am I in fact inventing URN? how about

OK, so there are issues of registration here..... -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From sebastian.rahtz at oucs.ox.ac.uk Mon Feb 8 18:42:50 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 8 Feb 2010 23:42:50 +0000 Subject: [tei-council] xml:space In-Reply-To: <4B7062D6.4060907@uvic.ca> References: <877B3A87-0929-4D80-8A7E-34EC5AF78C86@oucs.ox.ac.uk> <4B7047B1.5040904@kcl.ac.uk> <4B704A2C.5050106@uvic.ca> <4B70596C.10007@oucs.ox.ac.uk> <4B7062D6.4060907@uvic.ca> Message-ID: I am finding this convincing, I must say, am inclined to vote for putting xml:space back in straightaway. -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From laurent.romary at loria.fr Mon Feb 8 23:16:35 2010 From: laurent.romary at loria.fr (Laurent Romary) Date: Tue, 9 Feb 2010 05:16:35 +0100 Subject: [tei-council] xml:space In-Reply-To: References: <877B3A87-0929-4D80-8A7E-34EC5AF78C86@oucs.ox.ac.uk> <4B7047B1.5040904@kcl.ac.uk> <4B704A2C.5050106@uvic.ca> <4B70596C.10007@oucs.ox.ac.uk> <4B7062D6.4060907@uvic.ca> Message-ID: +1 let's simplify the TEI Le 9 f?vr. 10 ? 00:42, Sebastian Rahtz a ?crit : > I am finding this convincing, I must say, am inclined to vote for > putting xml:space back in straightaway. > > -- > Sebastian Rahtz > Information Manager, Oxford University Computing Services > 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 > > S?lo le pido a Dios > que el futuro no me sea indiferente > > > > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council From Laurent.Romary at loria.fr Tue Feb 9 03:49:52 2010 From: Laurent.Romary at loria.fr (Laurent Romary) Date: Tue, 9 Feb 2010 09:49:52 +0100 Subject: [tei-council] facsKey agayne In-Reply-To: <76B43C96-34D7-4898-93F0-FB77D5145CDF@oucs.ox.ac.uk> References: <76B43C96-34D7-4898-93F0-FB77D5145CDF@oucs.ox.ac.uk> Message-ID: <6A6576FE-71EA-4A26-A359-8CE6ED8ECE03@loria.fr> These (with the urn comment) are good points. Do you mean we could/ should have a uniform mechanism for pointers and keys in general? Le 9 f?vr. 10 ? 00:17, Sebastian Rahtz a ?crit : > A couple of conversations outside my office this afternoon suggest > that people who want > to use @facs to point to an arbitrary identifier can do so trivially > by making up their own > protocol. Thus > >

> > is short for the normal HTTP > >

> > but > >

> > is equally a legal URI, where "tk" is a new adhoc protocol. Examples > at > http://en.wikipedia.org/wiki/URI_scheme#Unofficial_but_common_URI_schemes > show similar ideas - the "doi:" protocol is like this, since it > references > an arbitrary identifier which does not get resolved to some web > address. > > Using @facs in this way is much better than @facsKey, IMHO, because > it signals > clearly to the processing application what is going on, but does not > need a new > attribute. It means the user can make use of _several_ protocols in > the same > document. > > Or is all this completely mad? > -- > Sebastian Rahtz > Information Manager, Oxford University Computing Services > 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 > > S?lo le pido a Dios > que el futuro no me sea indiferente > > > > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council From lou.burnard at oucs.ox.ac.uk Tue Feb 9 04:09:51 2010 From: lou.burnard at oucs.ox.ac.uk (Lou Burnard) Date: Tue, 09 Feb 2010 09:09:51 +0000 Subject: [tei-council] facsKey agayne In-Reply-To: <6A6576FE-71EA-4A26-A359-8CE6ED8ECE03@loria.fr> References: <76B43C96-34D7-4898-93F0-FB77D5145CDF@oucs.ox.ac.uk> <6A6576FE-71EA-4A26-A359-8CE6ED8ECE03@loria.fr> Message-ID: <4B71265F.7040908@oucs.ox.ac.uk> That is the proposal, yes. The syntax of data.URI supports functionality equivalent to (or better than) data.key, so we can combine the two in one attribute, Laurent Romary wrote: > These (with the urn comment) are good points. Do you mean we could/ > should have a uniform mechanism for pointers and keys in general? > > Le 9 f?vr. 10 ? 00:17, Sebastian Rahtz a ?crit : > >> A couple of conversations outside my office this afternoon suggest >> that people who want >> to use @facs to point to an arbitrary identifier can do so trivially >> by making up their own >> protocol. Thus >> >>

>> >> is short for the normal HTTP >> >>

>> >> but >> >>

>> >> is equally a legal URI, where "tk" is a new adhoc protocol. Examples >> at >> http://en.wikipedia.org/wiki/URI_scheme#Unofficial_but_common_URI_schemes >> show similar ideas - the "doi:" protocol is like this, since it >> references >> an arbitrary identifier which does not get resolved to some web >> address. >> >> Using @facs in this way is much better than @facsKey, IMHO, because >> it signals >> clearly to the processing application what is going on, but does not >> need a new >> attribute. It means the user can make use of _several_ protocols in >> the same >> document. >> >> Or is all this completely mad? >> -- >> Sebastian Rahtz >> Information Manager, Oxford University Computing Services >> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 >> >> S?lo le pido a Dios >> que el futuro no me sea indiferente >> >> >> >> >> _______________________________________________ >> tei-council mailing list >> tei-council at lists.village.Virginia.EDU >> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council From Laurent.Romary at loria.fr Tue Feb 9 04:39:43 2010 From: Laurent.Romary at loria.fr (Laurent Romary) Date: Tue, 9 Feb 2010 10:39:43 +0100 Subject: [tei-council] facsKey agayne In-Reply-To: <4B71265F.7040908@oucs.ox.ac.uk> References: <76B43C96-34D7-4898-93F0-FB77D5145CDF@oucs.ox.ac.uk> <6A6576FE-71EA-4A26-A359-8CE6ED8ECE03@loria.fr> <4B71265F.7040908@oucs.ox.ac.uk> Message-ID: <157D2048-8004-4B61-847D-D51DB6A6F0AF@loria.fr> Awesome. That would be an important move for the TEI framework. May I ask all of you in the council to brainstorm a little on the consequence and be ready to have this put on the Dublin table (maybe with a generic session on (x)pointers). Le 9 f?vr. 10 ? 10:09, Lou Burnard a ?crit : > That is the proposal, yes. The syntax of data.URI supports > functionality equivalent to (or better than) data.key, so we can > combine the two in one attribute, > > Laurent Romary wrote: >> These (with the urn comment) are good points. Do you mean we could/ >> should have a uniform mechanism for pointers and keys in general? >> Le 9 f?vr. 10 ? 00:17, Sebastian Rahtz a ?crit : >>> A couple of conversations outside my office this afternoon >>> suggest that people who want >>> to use @facs to point to an arbitrary identifier can do so >>> trivially by making up their own >>> protocol. Thus >>> >>>

>>> >>> is short for the normal HTTP >>> >>>

>>> >>> but >>> >>>

>>> >>> is equally a legal URI, where "tk" is a new adhoc protocol. >>> Examples at >>> http://en.wikipedia.org/wiki/URI_scheme#Unofficial_but_common_URI_schemes >>> show similar ideas - the "doi:" protocol is like this, since it >>> references >>> an arbitrary identifier which does not get resolved to some web >>> address. >>> >>> Using @facs in this way is much better than @facsKey, IMHO, >>> because it signals >>> clearly to the processing application what is going on, but does >>> not need a new >>> attribute. It means the user can make use of _several_ protocols >>> in the same >>> document. >>> >>> Or is all this completely mad? >>> -- >>> Sebastian Rahtz >>> Information Manager, Oxford University Computing Services >>> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 >>> >>> S?lo le pido a Dios >>> que el futuro no me sea indiferente >>> >>> >>> >>> >>> _______________________________________________ >>> tei-council mailing list >>> tei-council at lists.village.Virginia.EDU >>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council >> _______________________________________________ >> tei-council mailing list >> tei-council at lists.village.Virginia.EDU >> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > From sebastian.rahtz at oucs.ox.ac.uk Tue Feb 9 04:52:11 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 9 Feb 2010 09:52:11 +0000 Subject: [tei-council] facsKey agayne In-Reply-To: <157D2048-8004-4B61-847D-D51DB6A6F0AF@loria.fr> References: <76B43C96-34D7-4898-93F0-FB77D5145CDF@oucs.ox.ac.uk> <6A6576FE-71EA-4A26-A359-8CE6ED8ECE03@loria.fr> <4B71265F.7040908@oucs.ox.ac.uk> <157D2048-8004-4B61-847D-D51DB6A6F0AF@loria.fr> Message-ID: <78B209AB-C08B-4AFB-A7A1-8196841CC723@oucs.ox.ac.uk> my concern is to find out whether this is regarded as "immoral" by good people; technically, it can work, but we don't want the rest of the world telling us off?. -- Sebastian Rahtz (acting) Information and Support Group Manager Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From sebastian.rahtz at oucs.ox.ac.uk Tue Feb 9 09:15:50 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 9 Feb 2010 14:15:50 +0000 Subject: [tei-council] facsKey agayne In-Reply-To: <157D2048-8004-4B61-847D-D51DB6A6F0AF@loria.fr> References: <76B43C96-34D7-4898-93F0-FB77D5145CDF@oucs.ox.ac.uk> <6A6576FE-71EA-4A26-A359-8CE6ED8ECE03@loria.fr> <4B71265F.7040908@oucs.ox.ac.uk> <157D2048-8004-4B61-847D-D51DB6A6F0AF@loria.fr> Message-ID: <9A3BA378-21F8-47A0-A1CF-3F669A40743F@oucs.ox.ac.uk> discussed this further with folks out running today, and got a mixed response. In _some_ ways the comparison is with "isbn:1234567", where there is no single point of reference for an ISBN, and deciding how to handle it is local. But we do generally assume that ISBN is unique, whereas in this case "local:P45" means something entirely different in each institution. the comparison with DOI is also possible, as in urn:doi:10.1029/2003GL018014 but again this must assume that 10.1029/2003GL018014 is a permanent identifier in a way that "P45" is not. Still, I do feel that this direction is interesting enough that we should not implement @facsKey until we are really sure we need it. -- Sebastian Rahtz (acting) Information and Support Group Manager Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From James.Cummings at oucs.ox.ac.uk Tue Feb 9 10:40:55 2010 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Tue, 09 Feb 2010 15:40:55 +0000 Subject: [tei-council] facsKey agayne In-Reply-To: <9A3BA378-21F8-47A0-A1CF-3F669A40743F@oucs.ox.ac.uk> References: <76B43C96-34D7-4898-93F0-FB77D5145CDF@oucs.ox.ac.uk> <6A6576FE-71EA-4A26-A359-8CE6ED8ECE03@loria.fr> <4B71265F.7040908@oucs.ox.ac.uk> <157D2048-8004-4B61-847D-D51DB6A6F0AF@loria.fr> <9A3BA378-21F8-47A0-A1CF-3F669A40743F@oucs.ox.ac.uk> Message-ID: <4B718207.1090506@oucs.ox.ac.uk> Sebastian Rahtz wrote: > Still, I do feel that this direction is interesting enough that we should not implement > @facsKey until we are really sure we need it. I think someone should post a summary of the issue to TEI-L for wider discussion. Would this also mean that other places we have say a @ref and a @key that we might deprecate @key in favour of optionally using @ref in this manner as well? There are an awful lot of xsd:anyURI attributes out there e.g. http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-data.pointer.html some of which might usefully be allowed to have database-key values. -James From sebastian.rahtz at oucs.ox.ac.uk Tue Feb 9 10:45:45 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 9 Feb 2010 15:45:45 +0000 Subject: [tei-council] facsKey agayne In-Reply-To: <4B718207.1090506@oucs.ox.ac.uk> References: <76B43C96-34D7-4898-93F0-FB77D5145CDF@oucs.ox.ac.uk> <6A6576FE-71EA-4A26-A359-8CE6ED8ECE03@loria.fr> <4B71265F.7040908@oucs.ox.ac.uk> <157D2048-8004-4B61-847D-D51DB6A6F0AF@loria.fr> <9A3BA378-21F8-47A0-A1CF-3F669A40743F@oucs.ox.ac.uk> <4B718207.1090506@oucs.ox.ac.uk> Message-ID: On 9 Feb 2010, at 15:40, James Cummings wrote: > > I think someone should post a summary of the issue to TEI-L for > wider discussion. I was waiting for more thoughts; I dont want to look too stupid on TEI-L. ("hi" to all those people reading this list via Google anyway?.) > > Would this also mean that other places we have say a @ref and a > @key that we might deprecate @key in favour of optionally using > @ref in this manner as well? ideally -- Sebastian Rahtz (acting) Information and Support Group Manager Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From laurent.romary at loria.fr Tue Feb 9 10:50:21 2010 From: laurent.romary at loria.fr (Laurent Romary) Date: Tue, 09 Feb 2010 16:50:21 +0100 Subject: [tei-council] facsKey agayne In-Reply-To: References: <76B43C96-34D7-4898-93F0-FB77D5145CDF@oucs.ox.ac.uk> <6A6576FE-71EA-4A26-A359-8CE6ED8ECE03@loria.fr> <4B71265F.7040908@oucs.ox.ac.uk> <157D2048-8004-4B61-847D-D51DB6A6F0AF@loria.fr> <9A3BA378-21F8-47A0-A1CF-3F669A40743F@oucs.ox.ac.uk> <4B718207.1090506@oucs.ox.ac.uk> Message-ID: <20100209165021.126115yn7ezgqzwd@webmail.loria.fr> Sebastian Rahtz a ?crit?: > > On 9 Feb 2010, at 15:40, James Cummings wrote: >> >> >> Would this also mean that other places we have say a @ref and a >> @key that we might deprecate @key in favour of optionally using >> @ref in this manner as well? > ideally > And that's what I had understood :-) (simplicity...) From mholmes at uvic.ca Tue Feb 9 11:24:25 2010 From: mholmes at uvic.ca (Martin Holmes) Date: Tue, 9 Feb 2010 08:24:25 -0800 Subject: [tei-council] facsKey agayne In-Reply-To: References: <76B43C96-34D7-4898-93F0-FB77D5145CDF@oucs.ox.ac.uk> <6A6576FE-71EA-4A26-A359-8CE6ED8ECE03@loria.fr> <4B71265F.7040908@oucs.ox.ac.uk> <157D2048-8004-4B61-847D-D51DB6A6F0AF@loria.fr> <9A3BA378-21F8-47A0-A1CF-3F669A40743F@oucs.ox.ac.uk> <4B718207.1090506@oucs.ox.ac.uk> Message-ID: <4B718C39.60906@uvic.ca> Sebastian Rahtz wrote: > On 9 Feb 2010, at 15:40, James Cummings wrote: >> I think someone should post a summary of the issue to TEI-L for >> wider discussion. > > I was waiting for more thoughts; I dont want to look too stupid on TEI-L. > ("hi" to all those people reading this list via Google anyway?.) > >> Would this also mean that other places we have say a @ref and a >> @key that we might deprecate @key in favour of optionally using >> @ref in this manner as well? > ideally I really like this idea in principle. IIRC, there isn't yet a formal method of deprecating an element or attribute, though, is there? We also need to think about @cRef here. I've used that on occasion, and have been caught (by Syd, naturally) failing to supply "a canonical reference from a scheme defined in a refsDecl element in the TEI header", as I'm supposed to. If we're encouraging the use of custom protocols in @facs and elsewhere, do we also want to encourage or require some equivalent documentation of a method for discovering the actual destination of the pointer? Cheers, Martin -- Martin Holmes University of Victoria Humanities Computing and Media Centre (mholmes at uvic.ca) Half-Baked Software, Inc. (mholmes at halfbakedsoftware.com) martin at mholmes.com From sebastian.rahtz at oucs.ox.ac.uk Tue Feb 9 11:35:09 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 9 Feb 2010 16:35:09 +0000 Subject: [tei-council] facsKey agayne In-Reply-To: <4B718C39.60906@uvic.ca> References: <76B43C96-34D7-4898-93F0-FB77D5145CDF@oucs.ox.ac.uk> <6A6576FE-71EA-4A26-A359-8CE6ED8ECE03@loria.fr> <4B71265F.7040908@oucs.ox.ac.uk> <157D2048-8004-4B61-847D-D51DB6A6F0AF@loria.fr> <9A3BA378-21F8-47A0-A1CF-3F669A40743F@oucs.ox.ac.uk> <4B718207.1090506@oucs.ox.ac.uk> <4B718C39.60906@uvic.ca> Message-ID: <3A6E30FE-84A1-4249-80F6-D92AA7D129E7@oucs.ox.ac.uk> On 9 Feb 2010, at 16:24, Martin Holmes wrote: > > I really like this idea in principle. IIRC, there isn't yet a formal > method of deprecating an element or attribute, though, is there? indeed, thats another issue > header", as I'm supposed to. If we're encouraging the use of custom > protocols in @facs and elsewhere, do we also want to encourage or > require some equivalent documentation of a method for discovering the > actual destination of the pointer? > very much so, I think. if we say "local:P45", we need to have a way to say up in the header what "local:" means, even if only for humans. -- Sebastian Rahtz (acting) Information and Support Group Manager Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From mholmes at uvic.ca Tue Feb 9 11:36:46 2010 From: mholmes at uvic.ca (Martin Holmes) Date: Tue, 9 Feb 2010 08:36:46 -0800 Subject: [tei-council] facsKey agayne In-Reply-To: <4B718C39.60906@uvic.ca> References: <76B43C96-34D7-4898-93F0-FB77D5145CDF@oucs.ox.ac.uk> <6A6576FE-71EA-4A26-A359-8CE6ED8ECE03@loria.fr> <4B71265F.7040908@oucs.ox.ac.uk> <157D2048-8004-4B61-847D-D51DB6A6F0AF@loria.fr> <9A3BA378-21F8-47A0-A1CF-3F669A40743F@oucs.ox.ac.uk> <4B718207.1090506@oucs.ox.ac.uk> <4B718C39.60906@uvic.ca> Message-ID: <4B718F1E.70200@uvic.ca> Also, while we're looking at this issue, I'd like to include another thing that's been confusing me. Why do we have @target = 1?? occurrences of data.pointer and @targets = 2?? occurrences of data.pointer It seems to me that @target is all we need, since it can handle any number of pointers. Am I missing something? I think any attribute that holds at least one data.pointer might as well hold 1?? of them. Cheers, Martin Martin Holmes wrote: > Sebastian Rahtz wrote: >> On 9 Feb 2010, at 15:40, James Cummings wrote: >>> I think someone should post a summary of the issue to TEI-L for >>> wider discussion. >> I was waiting for more thoughts; I dont want to look too stupid on TEI-L. >> ("hi" to all those people reading this list via Google anyway?.) >> >>> Would this also mean that other places we have say a @ref and a >>> @key that we might deprecate @key in favour of optionally using >>> @ref in this manner as well? >> ideally > > I really like this idea in principle. IIRC, there isn't yet a formal > method of deprecating an element or attribute, though, is there? > > We also need to think about @cRef here. I've used that on occasion, and > have been caught (by Syd, naturally) failing to supply "a canonical > reference from a scheme defined in a refsDecl element in the TEI > header", as I'm supposed to. If we're encouraging the use of custom > protocols in @facs and elsewhere, do we also want to encourage or > require some equivalent documentation of a method for discovering the > actual destination of the pointer? > > Cheers, > Martin > -- Martin Holmes University of Victoria Humanities Computing and Media Centre (mholmes at uvic.ca) Half-Baked Software, Inc. (mholmes at halfbakedsoftware.com) martin at mholmes.com From lou.burnard at oucs.ox.ac.uk Tue Feb 9 11:43:55 2010 From: lou.burnard at oucs.ox.ac.uk (Lou) Date: Tue, 09 Feb 2010 16:43:55 +0000 Subject: [tei-council] facsKey agayne In-Reply-To: <4B718C39.60906@uvic.ca> References: <76B43C96-34D7-4898-93F0-FB77D5145CDF@oucs.ox.ac.uk> <6A6576FE-71EA-4A26-A359-8CE6ED8ECE03@loria.fr> <4B71265F.7040908@oucs.ox.ac.uk> <157D2048-8004-4B61-847D-D51DB6A6F0AF@loria.fr> <9A3BA378-21F8-47A0-A1CF-3F669A40743F@oucs.ox.ac.uk> <4B718207.1090506@oucs.ox.ac.uk> <4B718C39.60906@uvic.ca> Message-ID: <4B7190CB.5090104@oucs.ox.ac.uk> Martin Holmes wrote: > Sebastian Rahtz wrote: >> On 9 Feb 2010, at 15:40, James Cummings wrote: >>> I think someone should post a summary of the issue to TEI-L for >>> wider discussion. >> I was waiting for more thoughts; I dont want to look too stupid on TEI-L. >> ("hi" to all those people reading this list via Google anyway?.) >> >>> Would this also mean that other places we have say a @ref and a >>> @key that we might deprecate @key in favour of optionally using >>> @ref in this manner as well? >> ideally > > I really like this idea in principle. IIRC, there isn't yet a formal > method of deprecating an element or attribute, though, is there? We do it in the prose. There is a long standing ticket saying we should have a more formal method of doing that in an ODD, but it's in the heap of things that would have been discussed at our ODD Workshop if we'd been funded, chiz chiz. > > We also need to think about @cRef here. I've used that on occasion, and > have been caught (by Syd, naturally) failing to supply "a canonical > reference from a scheme defined in a refsDecl element in the TEI > header", as I'm supposed to. If we're encouraging the use of custom > protocols in @facs and elsewhere, do we also want to encourage or > require some equivalent documentation of a method for discovering the > actual destination of the pointer? > I think @cref and @key are really quite different. @cRef supplies a "canonical reference" for the element carrying it (and the mapping between that and an XPath is defined in a ). It specifies a location *in the current document* by definition, so it's sort of an alternative to @n or @xml:id @key supplies a "magic token" which some system can use to locate a resource in situations where a URI is not available or is dispreferred. It points out to something almost certainly not forming part of the current document. Yes, it might be a good idea to document somewhere how the process of locating that something is supposed to be carried out but it's not likely to be as simple as "follow this xPath". It's more likely to be "feed this token into this select statement" or "add a .prn at the end and a wibble at the beginning and feed the result into the CMS". Personally, I think the TEI does better to leave well alone -- and say "this is a magic token. do the right thing with it". From laurent.romary at loria.fr Tue Feb 9 11:44:17 2010 From: laurent.romary at loria.fr (Laurent Romary) Date: Tue, 9 Feb 2010 17:44:17 +0100 Subject: [tei-council] facsKey agayne In-Reply-To: <4B718F1E.70200@uvic.ca> References: <76B43C96-34D7-4898-93F0-FB77D5145CDF@oucs.ox.ac.uk> <6A6576FE-71EA-4A26-A359-8CE6ED8ECE03@loria.fr> <4B71265F.7040908@oucs.ox.ac.uk> <157D2048-8004-4B61-847D-D51DB6A6F0AF@loria.fr> <9A3BA378-21F8-47A0-A1CF-3F669A40743F@oucs.ox.ac.uk> <4B718207.1090506@oucs.ox.ac.uk> <4B718C39.60906@uvic.ca> <4B718F1E.70200@uvic.ca> Message-ID: <1144C9DC-6812-4FD8-9C40-3B401FF3A1F8@loria.fr> This would also bring even more simplicity... Le 9 f?vr. 10 ? 17:36, Martin Holmes a ?crit : > Also, while we're looking at this issue, I'd like to include another > thing that's been confusing me. Why do we have > > @target = 1?? occurrences of data.pointer > > and > > @targets = 2?? occurrences of data.pointer > > It seems to me that @target is all we need, since it can handle any > number of pointers. Am I missing something? > > I think any attribute that holds at least one data.pointer might as > well > hold 1?? of them. > > Cheers, > Martin > > Martin Holmes wrote: >> Sebastian Rahtz wrote: >>> On 9 Feb 2010, at 15:40, James Cummings wrote: >>>> I think someone should post a summary of the issue to TEI-L for >>>> wider discussion. >>> I was waiting for more thoughts; I dont want to look too stupid on >>> TEI-L. >>> ("hi" to all those people reading this list via Google anyway?.) >>> >>>> Would this also mean that other places we have say a @ref and a >>>> @key that we might deprecate @key in favour of optionally using >>>> @ref in this manner as well? >>> ideally >> >> I really like this idea in principle. IIRC, there isn't yet a formal >> method of deprecating an element or attribute, though, is there? >> >> We also need to think about @cRef here. I've used that on occasion, >> and >> have been caught (by Syd, naturally) failing to supply "a canonical >> reference from a scheme defined in a refsDecl element in the TEI >> header", as I'm supposed to. If we're encouraging the use of custom >> protocols in @facs and elsewhere, do we also want to encourage or >> require some equivalent documentation of a method for discovering the >> actual destination of the pointer? >> >> Cheers, >> Martin >> > > -- > Martin Holmes > University of Victoria Humanities Computing and Media Centre > (mholmes at uvic.ca) > Half-Baked Software, Inc. > (mholmes at halfbakedsoftware.com) > martin at mholmes.com > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council From lou.burnard at oucs.ox.ac.uk Tue Feb 9 11:53:54 2010 From: lou.burnard at oucs.ox.ac.uk (Lou) Date: Tue, 09 Feb 2010 16:53:54 +0000 Subject: [tei-council] facsKey agayne In-Reply-To: <1144C9DC-6812-4FD8-9C40-3B401FF3A1F8@loria.fr> References: <76B43C96-34D7-4898-93F0-FB77D5145CDF@oucs.ox.ac.uk> <6A6576FE-71EA-4A26-A359-8CE6ED8ECE03@loria.fr> <4B71265F.7040908@oucs.ox.ac.uk> <157D2048-8004-4B61-847D-D51DB6A6F0AF@loria.fr> <9A3BA378-21F8-47A0-A1CF-3F669A40743F@oucs.ox.ac.uk> <4B718207.1090506@oucs.ox.ac.uk> <4B718C39.60906@uvic.ca> <4B718F1E.70200@uvic.ca> <1144C9DC-6812-4FD8-9C40-3B401FF3A1F8@loria.fr> Message-ID: <4B719322.6040709@oucs.ox.ac.uk> This issue is already discussed in outstanding sourceforge ticket 2531384 The difference between @targets and @target is presumably that the former does not allow less than 2 pointers Laurent Romary wrote: > This would also bring even more simplicity... > > Le 9 f?vr. 10 ? 17:36, Martin Holmes a ?crit : > >> Also, while we're looking at this issue, I'd like to include another >> thing that's been confusing me. Why do we have >> >> @target = 1?? occurrences of data.pointer >> >> and >> >> @targets = 2?? occurrences of data.pointer >> >> It seems to me that @target is all we need, since it can handle any >> number of pointers. Am I missing something? >> >> I think any attribute that holds at least one data.pointer might as >> well >> hold 1?? of them. >> >> From laurent.romary at loria.fr Tue Feb 9 12:23:46 2010 From: laurent.romary at loria.fr (Laurent Romary) Date: Tue, 9 Feb 2010 18:23:46 +0100 Subject: [tei-council] facsKey agayne In-Reply-To: <4B719322.6040709@oucs.ox.ac.uk> References: <76B43C96-34D7-4898-93F0-FB77D5145CDF@oucs.ox.ac.uk> <6A6576FE-71EA-4A26-A359-8CE6ED8ECE03@loria.fr> <4B71265F.7040908@oucs.ox.ac.uk> <157D2048-8004-4B61-847D-D51DB6A6F0AF@loria.fr> <9A3BA378-21F8-47A0-A1CF-3F669A40743F@oucs.ox.ac.uk> <4B718207.1090506@oucs.ox.ac.uk> <4B718C39.60906@uvic.ca> <4B718F1E.70200@uvic.ca> <1144C9DC-6812-4FD8-9C40-3B401FF3A1F8@loria.fr> <4B719322.6040709@oucs.ox.ac.uk> Message-ID: <9C3F8458-2D1A-4D80-BFA4-4AEE9AC6AB1E@loria.fr> It's now on the preliminary council agenda. I am touching the pulse of the council ;-) Le 9 f?vr. 10 ? 17:53, Lou a ?crit : > This issue is already discussed in outstanding sourceforge ticket > 2531384 > > The difference between @targets and @target is presumably that the > former does not allow less than 2 pointers > > > > Laurent Romary wrote: >> This would also bring even more simplicity... >> Le 9 f?vr. 10 ? 17:36, Martin Holmes a ?crit : >>> Also, while we're looking at this issue, I'd like to include another >>> thing that's been confusing me. Why do we have >>> >>> @target = 1?? occurrences of data.pointer >>> >>> and >>> >>> @targets = 2?? occurrences of data.pointer >>> >>> It seems to me that @target is all we need, since it can handle any >>> number of pointers. Am I missing something? >>> >>> I think any attribute that holds at least one data.pointer might >>> as well >>> hold 1?? of them. >>> >>> From James.Cummings at oucs.ox.ac.uk Tue Feb 9 12:53:09 2010 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Tue, 09 Feb 2010 17:53:09 +0000 Subject: [tei-council] facsKey agayne In-Reply-To: <4B7190CB.5090104@oucs.ox.ac.uk> References: <76B43C96-34D7-4898-93F0-FB77D5145CDF@oucs.ox.ac.uk> <6A6576FE-71EA-4A26-A359-8CE6ED8ECE03@loria.fr> <4B71265F.7040908@oucs.ox.ac.uk> <157D2048-8004-4B61-847D-D51DB6A6F0AF@loria.fr> <9A3BA378-21F8-47A0-A1CF-3F669A40743F@oucs.ox.ac.uk> <4B718207.1090506@oucs.ox.ac.uk> <4B718C39.60906@uvic.ca> <4B7190CB.5090104@oucs.ox.ac.uk> Message-ID: <4B71A105.6010908@oucs.ox.ac.uk> Lou wrote: > Yes, it might be a good idea to document somewhere how the process of > locating that something is supposed to be carried out but it's not > likely to be as simple as "follow this xPath". It's more likely to be > "feed this token into this select statement" or "add a .prn at the end > and a wibble at the beginning and feed the result into the CMS". > Personally, I think the TEI does better to leave well alone -- and say > "this is a magic token. do the right thing with it". If we are planning to move this to things like @ref and @target and other xsd:anyURI attributes, then I think it should be documented. I don't think we need to specify the method of documentation, just that it should be documented. I would propose that there should be a container element in the header somewhere (perhaps there is a suitable location already?) as the location for describing the method for resolving or nature of these pseudo-protocols. I want to suggest a requirement that any pseudo-protocol name should be the @xml:id of this description. This does have the, I think beneficial, side-effect of limiting the values of these pseudo-protocols to be an XML QName.... thus it couldn't have spaces so you could not do: facs="john walsh:abc123" but could do: facs="john_walsh:abc123" with a This is just something John made up.. I think that it should be an error (schematron enforced?) if the protocol is not so defined unless it is one of the official IANA registered protocol schemes. (see http://en.wikipedia.org/wiki/URI_scheme#Official_IANA-registered_schemes ... though there are many that are unofficial which I had assumed were official.) That seems to me to tread the balance between proper documentation and freedom/flexibility. -james From mholmes at uvic.ca Tue Feb 9 13:26:04 2010 From: mholmes at uvic.ca (Martin Holmes) Date: Tue, 9 Feb 2010 10:26:04 -0800 Subject: [tei-council] facsKey agayne In-Reply-To: <4B719322.6040709@oucs.ox.ac.uk> References: <76B43C96-34D7-4898-93F0-FB77D5145CDF@oucs.ox.ac.uk> <6A6576FE-71EA-4A26-A359-8CE6ED8ECE03@loria.fr> <4B71265F.7040908@oucs.ox.ac.uk> <157D2048-8004-4B61-847D-D51DB6A6F0AF@loria.fr> <9A3BA378-21F8-47A0-A1CF-3F669A40743F@oucs.ox.ac.uk> <4B718207.1090506@oucs.ox.ac.uk> <4B718C39.60906@uvic.ca> <4B718F1E.70200@uvic.ca> <1144C9DC-6812-4FD8-9C40-3B401FF3A1F8@loria.fr> <4B719322.6040709@oucs.ox.ac.uk> Message-ID: <4B71A8BC.1090407@uvic.ca> Lou wrote: > The difference between @targets and @target is presumably that the > former does not allow less than 2 pointers Is that difference worth the existence of a separate attribute? The SF ticket doesn't really address this; it just mentions @targets in passing, I think. Cheers, Martin -- Martin Holmes University of Victoria Humanities Computing and Media Centre (mholmes at uvic.ca) Half-Baked Software, Inc. (mholmes at halfbakedsoftware.com) martin at mholmes.com From sebastian.rahtz at oucs.ox.ac.uk Tue Feb 9 16:47:42 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 9 Feb 2010 21:47:42 +0000 Subject: [tei-council] more on facsKey debate References: <4B71D01B.80903@oucs.ox.ac.uk> Message-ID: I asked around at work. The message below is a useful confirmation that we're not barking mad. I also see a useful quote from http://www.ietf.org/rfc/rfc3986.txt: "A common misunderstanding of URIs is that they are only used to refer to accessible resources. The URI itself only provides identification; access to the resource is neither guaranteed nor implied by the presence of a URI. Instead, any operation associated with a URI reference is defined by the protocol element, data format attribute, or natural language text in which it appears." Begin forwarded message: > > First we should remember that the "protocol" of a URI is not a protocol, > it is a schema. In many cases it happens to be a protocol too, but that > is coincidence rather than design. In fact, in an URL it can be an > indicator of resource type. > > Next we need to ask how is the attribute facs defined? Do your docs say > that it contains an URI, URL or URN? > > If an URL then this is, a little evil since URLs are intended to refer > to the location of a resource. Providing a locator that is not easily > dereferenced is a problem for clients. However, strictly speaking it is > legal. > > I'll skip URNs as you say you don't want to use them. > > So that leaves us with URIs. In theory all schemes should be registered > with IANA, but in practice unregistered schemes are used. As with URLs > the fact that processors don't know how to work with unregistered > schemes is a minor hinderence, a well behaved client will fail > gracefully. However, they need to know how to. > > So, as far as issue a) is concerned, I would suggest you (re)define > @facs as an URI and allow the use of unregistered schemas. Since URLs > and URNs are subsets of URIs there would be no backward compatibility > issues. By defining @facs as a URI you are sending a clear signal to > client maintainers that they may receive something that does not > necessarily provide a location for the resource. > > With respect to b) URIs, by definition, are not permanent identifiers > nor are they necessarily unique. For example "../hello.png" is "only > unique in the processing domain, it is not in any sense a permanent > identifier". > > So, in summary: > > Ensure @facs is defined as a URI and encourage people to use world > unique identifiers and I believe it is not evil. -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From lou.burnard at oucs.ox.ac.uk Wed Feb 10 08:02:09 2010 From: lou.burnard at oucs.ox.ac.uk (Lou) Date: Wed, 10 Feb 2010 13:02:09 +0000 Subject: [tei-council] xml:space Message-ID: <4B72AE51.7090102@oucs.ox.ac.uk> Here's the wording I'm proposing to add to the Guidelines (following the sections describing global attributes in ST) concerning use of xml:space Tx to Gabriel and Sebastian for helping clarify the issue. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: foo.txt Url: http://lists.village.Virginia.EDU/pipermail/tei-council/attachments/20100210/da070c62/attachment.txt From sebastian.rahtz at oucs.ox.ac.uk Wed Feb 10 08:28:24 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Wed, 10 Feb 2010 13:28:24 +0000 Subject: [tei-council] xml:space In-Reply-To: <4B72AE51.7090102@oucs.ox.ac.uk> References: <4B72AE51.7090102@oucs.ox.ac.uk> Message-ID: <52F33B6A-C117-401F-A7A6-7ED2F7616A9E@oucs.ox.ac.uk> "? between the first and second items, and that between the second and third, is significant only if the content model for list permits text as well as item elements" no. the XML processor does not look at the schema, it simply looks to see if there _is_ text as well as "Most TEI elements are defined as having mixed content, and for the most part TEI markup appears at places in a document where the presence or absence of whitespace is not in any case significant. " eh? the opposite, surely? "For the most part TEI markup appears at places in a document where the whitespace is significant" "an editor is not then permitted " --> "an editor or processor is not then permitted " -- Sebastian Rahtz (acting) Information and Support Group Manager Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From sebastian.rahtz at oucs.ox.ac.uk Wed Feb 10 08:44:28 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Wed, 10 Feb 2010 13:44:28 +0000 Subject: [tei-council] xml:space In-Reply-To: <4B72AE51.7090102@oucs.ox.ac.uk> References: <4B72AE51.7090102@oucs.ox.ac.uk> Message-ID: for those what want to see the effect, consider this:

Ave Maria Imperatrix Coeli
Ave Maria Imperatrix Coeli
when processed by an XSLT identity transform using Saxon you get
Ave Maria Imp eratrix Coeli
Ave Maria Imperatrix Coeli
notice the spurious newline introduced between and in stanza 1 -- Sebastian Rahtz (acting) Information and Support Group Manager Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From lou.burnard at oucs.ox.ac.uk Wed Feb 10 09:44:23 2010 From: lou.burnard at oucs.ox.ac.uk (Lou) Date: Wed, 10 Feb 2010 14:44:23 +0000 Subject: [tei-council] xml:space In-Reply-To: <52F33B6A-C117-401F-A7A6-7ED2F7616A9E@oucs.ox.ac.uk> References: <4B72AE51.7090102@oucs.ox.ac.uk> <52F33B6A-C117-401F-A7A6-7ED2F7616A9E@oucs.ox.ac.uk> Message-ID: <4B72C647.5010104@oucs.ox.ac.uk> Sebastian Rahtz wrote: > "? between the first and second items, and that between the > second and third, is significant only if the content model for > list permits text as well as item elements" > > no. the XML processor does not look at the schema, it simply looks > to see if there _is_ text as well as > oops, yes. I was thinking SGML whitespace rules there. Tsk tsk. More coffee needed. > > "Most TEI elements are defined as having mixed content, and > for the most part TEI markup appears at places in a document where the > presence or absence of whitespace is not in any case significant. " > > eh? the opposite, surely? "For the most part TEI markup appears at places in a document where the whitespace is significant" > Well, what I meant was that 99.9% of the TEI tags used in the world are things like

or

which if you put a space before or after them it really doesn't make much difference. > > "an editor is not then permitted " --> "an editor or processor is not then permitted " > -- yes. I already fixed that to read "an XML editor or other processor" > Sebastian Rahtz > (acting) Information and Support Group Manager > Oxford University Computing Services > 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 > > S?lo le pido a Dios > que el futuro no me sea indiferente > From sebastian.rahtz at oucs.ox.ac.uk Wed Feb 10 10:31:55 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Wed, 10 Feb 2010 15:31:55 +0000 Subject: [tei-council] xml:space In-Reply-To: <4B72C647.5010104@oucs.ox.ac.uk> References: <4B72AE51.7090102@oucs.ox.ac.uk> <52F33B6A-C117-401F-A7A6-7ED2F7616A9E@oucs.ox.ac.uk> <4B72C647.5010104@oucs.ox.ac.uk> Message-ID: <6ED23CEC-64ED-46A2-94BE-9C50B7BCE2B5@oucs.ox.ac.uk> On 10 Feb 2010, at 14:44, Lou wrote: > Well, what I meant was that 99.9% of the TEI tags used in the world are > things like

or

which if you put a space before or after them > it really doesn't make much difference. i think you mean "between them". to me "after the

tag" means

hello world

as opposed to

hello world

-- Sebastian Rahtz (acting) Information and Support Group Manager Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From lou.burnard at oucs.ox.ac.uk Wed Feb 10 11:48:11 2010 From: lou.burnard at oucs.ox.ac.uk (Lou) Date: Wed, 10 Feb 2010 16:48:11 +0000 Subject: [tei-council] xml:space In-Reply-To: <6ED23CEC-64ED-46A2-94BE-9C50B7BCE2B5@oucs.ox.ac.uk> References: <4B72AE51.7090102@oucs.ox.ac.uk> <52F33B6A-C117-401F-A7A6-7ED2F7616A9E@oucs.ox.ac.uk> <4B72C647.5010104@oucs.ox.ac.uk> <6ED23CEC-64ED-46A2-94BE-9C50B7BCE2B5@oucs.ox.ac.uk> Message-ID: <4B72E34B.6000300@oucs.ox.ac.uk> Sebastian Rahtz wrote: > On 10 Feb 2010, at 14:44, Lou wrote: >> Well, what I meant was that 99.9% of the TEI tags used in the world are >> things like

or

which if you put a space before or after them >> it really doesn't make much difference. > > i think you mean "between them". to me "after the

tag" means >

hello world

> as opposed to >

hello world

> OK I've revised the text again, in line with Sebastian's comments and now checked it in. From gabriel.bodard at kcl.ac.uk Wed Feb 10 12:27:02 2010 From: gabriel.bodard at kcl.ac.uk (Gabriel Bodard) Date: Wed, 10 Feb 2010 17:27:02 +0000 Subject: [tei-council] xml:space In-Reply-To: <4B72E34B.6000300@oucs.ox.ac.uk> References: <4B72AE51.7090102@oucs.ox.ac.uk> <52F33B6A-C117-401F-A7A6-7ED2F7616A9E@oucs.ox.ac.uk> <4B72C647.5010104@oucs.ox.ac.uk> <6ED23CEC-64ED-46A2-94BE-9C50B7BCE2B5@oucs.ox.ac.uk> <4B72E34B.6000300@oucs.ox.ac.uk> Message-ID: <4B72EC66.3020207@kcl.ac.uk> Excellent! So at what point would we expect the dev version of Roma to produce schemata with global @xml:space? (I can't wait to start using it, but should I bother customizing our odd at the moment, or just wait for some magic moment when it's there by default?) Please consider this not a selfish request, but a general workflow question. G On 2010-02-10 16:48, Lou wrote: > Sebastian Rahtz wrote: >> On 10 Feb 2010, at 14:44, Lou wrote: >>> Well, what I meant was that 99.9% of the TEI tags used in the world are >>> things like

or

which if you put a space before or after them >>> it really doesn't make much difference. >> >> i think you mean "between them". to me "after the

tag" means >>

hello world

>> as opposed to >>

hello world

>> > > OK I've revised the text again, in line with Sebastian's comments and > now checked it in. > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council -- Dr Gabriel BODARD (Epigrapher & Digital Classicist) Centre for Computing in the Humanities King's College London 26-29 Drury Lane London WC2B 5RL Email: gabriel.bodard at kcl.ac.uk Tel: +44 (0)20 7848 1388 Fax: +44 (0)20 7848 2980 http://www.digitalclassicist.org/ http://www.currentepigraphy.org/ From lou.burnard at oucs.ox.ac.uk Wed Feb 10 12:30:48 2010 From: lou.burnard at oucs.ox.ac.uk (Lou) Date: Wed, 10 Feb 2010 17:30:48 +0000 Subject: [tei-council] xml:space In-Reply-To: <4B72EC66.3020207@kcl.ac.uk> References: <4B72AE51.7090102@oucs.ox.ac.uk> <52F33B6A-C117-401F-A7A6-7ED2F7616A9E@oucs.ox.ac.uk> <4B72C647.5010104@oucs.ox.ac.uk> <6ED23CEC-64ED-46A2-94BE-9C50B7BCE2B5@oucs.ox.ac.uk> <4B72E34B.6000300@oucs.ox.ac.uk> <4B72EC66.3020207@kcl.ac.uk> Message-ID: <4B72ED48.5030302@oucs.ox.ac.uk> We are hoping to push the button for the next release on Friday. This particular change should be in that version. Gabriel Bodard wrote: > Excellent! > > So at what point would we expect the dev version of Roma to produce > schemata with global @xml:space? (I can't wait to start using it, but > should I bother customizing our odd at the moment, or just wait for some > magic moment when it's there by default?) > > Please consider this not a selfish request, but a general workflow question. > > G > > On 2010-02-10 16:48, Lou wrote: >> Sebastian Rahtz wrote: >>> On 10 Feb 2010, at 14:44, Lou wrote: >>>> Well, what I meant was that 99.9% of the TEI tags used in the world are >>>> things like

or

which if you put a space before or after them >>>> it really doesn't make much difference. >>> i think you mean "between them". to me "after the

tag" means >>>

hello world

>>> as opposed to >>>

hello world

>>> >> OK I've revised the text again, in line with Sebastian's comments and >> now checked it in. >> >> _______________________________________________ >> tei-council mailing list >> tei-council at lists.village.Virginia.EDU >> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > From sebastian.rahtz at oucs.ox.ac.uk Wed Feb 10 12:33:29 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Wed, 10 Feb 2010 17:33:29 +0000 Subject: [tei-council] xml:space In-Reply-To: <4B72EC66.3020207@kcl.ac.uk> References: <4B72AE51.7090102@oucs.ox.ac.uk> <52F33B6A-C117-401F-A7A6-7ED2F7616A9E@oucs.ox.ac.uk> <4B72C647.5010104@oucs.ox.ac.uk> <6ED23CEC-64ED-46A2-94BE-9C50B7BCE2B5@oucs.ox.ac.uk> <4B72E34B.6000300@oucs.ox.ac.uk> <4B72EC66.3020207@kcl.ac.uk> Message-ID: <15AE0840-5663-4B10-A327-7ABEC526A076@oucs.ox.ac.uk> since we're now looking at a release on Friday, I think I'll try to make a dev release this very evening so that we have some minimal testing -- Sebastian Rahtz (acting) Information and Support Group Manager Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From bbarney2 at unlnotes.unl.edu Tue Feb 9 17:38:46 2010 From: bbarney2 at unlnotes.unl.edu (Brett Barney) Date: Tue, 9 Feb 2010 16:38:46 -0600 Subject: [tei-council] Attached: draft of minutes Message-ID: All, I'm afraid this draft is a shocking mess, considering the time it took me to get it out to you. I apologize. In the future I'll restrain myself from volunteering so glibly. Please send corrections to me. One specific request: DoD (or someone anyone else who got it right), could you please supply the missing information currently marked by ? After everyone has had a chance to chime in I'll send to David, who will put the file in its final resting place. Brett ------------------ (See attached file: tcm44_draft.xml) -------------- next part -------------- A non-text attachment was scrubbed... Name: tcm44_draft.xml Type: application/octet-stream Size: 9184 bytes Desc: not available Url : http://lists.village.Virginia.EDU/pipermail/tei-council/attachments/20100209/8756fc03/attachment.obj From gabriel.bodard at kcl.ac.uk Thu Feb 11 07:31:27 2010 From: gabriel.bodard at kcl.ac.uk (Gabriel Bodard) Date: Thu, 11 Feb 2010 12:31:27 +0000 Subject: [tei-council] xml:space In-Reply-To: <15AE0840-5663-4B10-A327-7ABEC526A076@oucs.ox.ac.uk> References: <4B72AE51.7090102@oucs.ox.ac.uk> <52F33B6A-C117-401F-A7A6-7ED2F7616A9E@oucs.ox.ac.uk> <4B72C647.5010104@oucs.ox.ac.uk> <6ED23CEC-64ED-46A2-94BE-9C50B7BCE2B5@oucs.ox.ac.uk> <4B72E34B.6000300@oucs.ox.ac.uk> <4B72EC66.3020207@kcl.ac.uk> <15AE0840-5663-4B10-A327-7ABEC526A076@oucs.ox.ac.uk> Message-ID: <4B73F89F.9010509@kcl.ac.uk> That would be great. Just to confirm, is this the dev Roma served from http://tei.oucs.ox.ac.uk/Roma/ ? If so, are the dates at the bottom of the schema generation page manually or automatically generated? It currently reads, "This is Roma version 3.12, last updated 2009-07-13. Using TEI P5 version 1.5.0. Last updated on November 8th 2009." (Indeed the schema I generate from this doesn't include @xml:space, so perhaps you never got around to releasing last night, which is quite understandable. :-) Or perhaps I'm looking in the wrong place?) G On 2010-02-10 17:33, Sebastian Rahtz wrote: > since we're now looking at a release on Friday, I think I'll try to make a dev release this very evening > so that we have some minimal testing > -- > Sebastian Rahtz > (acting) Information and Support Group Manager > Oxford University Computing Services > 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 > > S?lo le pido a Dios > que el futuro no me sea indiferente > -- Dr Gabriel BODARD (Epigrapher & Digital Classicist) Centre for Computing in the Humanities King's College London 26-29 Drury Lane London WC2B 5RL Email: gabriel.bodard at kcl.ac.uk Tel: +44 (0)20 7848 1388 Fax: +44 (0)20 7848 2980 http://www.digitalclassicist.org/ http://www.currentepigraphy.org/ From gabriel.bodard at kcl.ac.uk Thu Feb 11 07:47:37 2010 From: gabriel.bodard at kcl.ac.uk (Gabriel Bodard) Date: Thu, 11 Feb 2010 12:47:37 +0000 Subject: [tei-council] FR 2862151: allow certainty in gap and space Message-ID: <4B73FC69.8050909@kcl.ac.uk> Dear all, Lou has suggested on this ticket that the simplest way to meet this request approved by Council this week, "would be to add certainty, precision, and respons to model.glossLike." This sounds good to me, as it would allow certainty et al. on any "empty" element that currently takes . Space is not currently in model.glossLike, but I would see no problem with it being added there. Any objections? Gabby (hoping that this might be agreed and incorporated in the looming release ;-) ) -- Dr Gabriel BODARD (Epigrapher & Digital Classicist) Centre for Computing in the Humanities King's College London 26-29 Drury Lane London WC2B 5RL Email: gabriel.bodard at kcl.ac.uk Tel: +44 (0)20 7848 1388 Fax: +44 (0)20 7848 2980 http://www.digitalclassicist.org/ http://www.currentepigraphy.org/ From James.Cummings at oucs.ox.ac.uk Thu Feb 11 09:12:58 2010 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Thu, 11 Feb 2010 14:12:58 +0000 Subject: [tei-council] FR 2862151: allow certainty in gap and space In-Reply-To: <4B73FC69.8050909@kcl.ac.uk> References: <4B73FC69.8050909@kcl.ac.uk> Message-ID: <4B74106A.6000101@oucs.ox.ac.uk> Gabriel Bodard wrote: > Space is not currently in model.glossLike, but I would see no problem > with it being added there. > > Any objections? This seems entirely reasonable to me. If I am providing a element I can currently say how big the space is, but have no way to describe the nature of the space or its reason for existence without employing various other methods. Space left for illuminated initial which was never added. -James From elena.pierazzo at kcl.ac.uk Thu Feb 11 10:06:53 2010 From: elena.pierazzo at kcl.ac.uk (Elena Pierazzo) Date: Thu, 11 Feb 2010 15:06:53 +0000 Subject: [tei-council] FR 2862151: allow certainty in gap and space In-Reply-To: <4B74106A.6000101@oucs.ox.ac.uk> References: <4B73FC69.8050909@kcl.ac.uk> <4B74106A.6000101@oucs.ox.ac.uk> Message-ID: <26FDE88E-B845-48ED-8896-01F8B8F5FC83@kcl.ac.uk> +1 Elena On 11 Feb 2010, at 14:12, James Cummings wrote: > Gabriel Bodard wrote: >> Space is not currently in model.glossLike, but I would see no problem >> with it being added there. >> >> Any objections? > > This seems entirely reasonable to me. If I am providing a > element I can currently say how big the space is, but > have no way to describe the nature of the space or its reason for > existence without employing various other methods. > > Space left for > illuminated initial which was never added. > > -James > > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council -- Dr Elena Pierazzo Research Associate Centre for Computing in the Humanities King's College London 26-29 Drury Lane London WC2B 5RL Phone: 0207-848-1949 Fax: 0207-848-2980 elena.pierazzo at kcl.ac.uk www.kcl.ac.uk From sebastian.rahtz at oucs.ox.ac.uk Thu Feb 11 10:26:40 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Thu, 11 Feb 2010 15:26:40 +0000 Subject: [tei-council] xml:space In-Reply-To: <4B73F89F.9010509@kcl.ac.uk> References: <4B72AE51.7090102@oucs.ox.ac.uk> <52F33B6A-C117-401F-A7A6-7ED2F7616A9E@oucs.ox.ac.uk> <4B72C647.5010104@oucs.ox.ac.uk> <6ED23CEC-64ED-46A2-94BE-9C50B7BCE2B5@oucs.ox.ac.uk> <4B72E34B.6000300@oucs.ox.ac.uk> <4B72EC66.3020207@kcl.ac.uk> <15AE0840-5663-4B10-A327-7ABEC526A076@oucs.ox.ac.uk> <4B73F89F.9010509@kcl.ac.uk> Message-ID: <46FA9A8A-F290-4F31-BC43-3ECE4EB8B433@oucs.ox.ac.uk> > so > perhaps you never got around to releasing last night it failed :-} working on it now -- Sebastian Rahtz (acting) Information and Support Group Manager Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From mholmes at uvic.ca Thu Feb 11 11:22:43 2010 From: mholmes at uvic.ca (Martin Holmes) Date: Thu, 11 Feb 2010 08:22:43 -0800 Subject: [tei-council] FR 2862151: allow certainty in gap and space In-Reply-To: <26FDE88E-B845-48ED-8896-01F8B8F5FC83@kcl.ac.uk> References: <4B73FC69.8050909@kcl.ac.uk> <4B74106A.6000101@oucs.ox.ac.uk> <26FDE88E-B845-48ED-8896-01F8B8F5FC83@kcl.ac.uk> Message-ID: <4B742ED3.2010207@uvic.ca> Me too. Martin Elena Pierazzo wrote: > +1 > > Elena > On 11 Feb 2010, at 14:12, James Cummings wrote: > >> Gabriel Bodard wrote: >>> Space is not currently in model.glossLike, but I would see no problem >>> with it being added there. >>> >>> Any objections? >> This seems entirely reasonable to me. If I am providing a >> element I can currently say how big the space is, but >> have no way to describe the nature of the space or its reason for >> existence without employing various other methods. >> >> Space left for >> illuminated initial which was never added. >> >> -James >> >> >> _______________________________________________ >> tei-council mailing list >> tei-council at lists.village.Virginia.EDU >> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > > -- > Dr Elena Pierazzo > Research Associate > Centre for Computing in the Humanities > King's College London > 26-29 Drury Lane > London WC2B 5RL > > Phone: 0207-848-1949 > Fax: 0207-848-2980 > elena.pierazzo at kcl.ac.uk > www.kcl.ac.uk > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > -- Martin Holmes University of Victoria Humanities Computing and Media Centre (mholmes at uvic.ca) Half-Baked Software, Inc. (mholmes at halfbakedsoftware.com) martin at mholmes.com From dot.porter at gmail.com Thu Feb 11 11:31:26 2010 From: dot.porter at gmail.com (Dot Porter) Date: Thu, 11 Feb 2010 11:31:26 -0500 Subject: [tei-council] FR 2862151: allow certainty in gap and space In-Reply-To: <4B742ED3.2010207@uvic.ca> References: <4B73FC69.8050909@kcl.ac.uk> <4B74106A.6000101@oucs.ox.ac.uk> <26FDE88E-B845-48ED-8896-01F8B8F5FC83@kcl.ac.uk> <4B742ED3.2010207@uvic.ca> Message-ID: <96f3df641002110831h67967c88ud445878632c9591b@mail.gmail.com> +1 On Thu, Feb 11, 2010 at 11:22 AM, Martin Holmes wrote: > Me too. > > Martin > > Elena Pierazzo wrote: >> +1 >> >> Elena >> On 11 Feb 2010, at 14:12, James Cummings wrote: >> >>> Gabriel Bodard wrote: >>>> Space is not currently in model.glossLike, but I would see no problem >>>> with it being added there. >>>> >>>> Any objections? >>> This seems entirely reasonable to me. If I am providing a >>> element I can currently say how big the space is, but >>> have no way to describe the nature of the space or its reason for >>> existence without employing various other methods. >>> >>> Space left for >>> illuminated initial which was never added. >>> >>> -James >>> >>> >>> _______________________________________________ >>> tei-council mailing list >>> tei-council at lists.village.Virginia.EDU >>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council >> >> -- >> Dr Elena Pierazzo >> Research Associate >> Centre for Computing in the Humanities >> King's College London >> 26-29 Drury Lane >> London WC2B 5RL >> >> Phone: 0207-848-1949 >> Fax: 0207-848-2980 >> elena.pierazzo at kcl.ac.uk >> www.kcl.ac.uk >> >> _______________________________________________ >> tei-council mailing list >> tei-council at lists.village.Virginia.EDU >> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council >> > > -- > Martin Holmes > University of Victoria Humanities Computing and Media Centre > (mholmes at uvic.ca) > Half-Baked Software, Inc. > (mholmes at halfbakedsoftware.com) > martin at mholmes.com > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > -- *~*~*~*~*~*~*~*~*~*~* Dot Porter (MA, MSLS) Metadata Manager (on leave) Digital Humanities Observatory (RIA), Regus House, 28-32 Upper Pembroke Street, Dublin 2, Ireland -- A Project of the Royal Irish Academy -- Phone: +353 1 234 2444 Fax: +353 1 234 2400 http://dho.ie Email: dot.porter at gmail.com *~*~*~*~*~*~*~*~*~*~* From laurent.romary at loria.fr Thu Feb 11 12:07:08 2010 From: laurent.romary at loria.fr (Laurent Romary) Date: Thu, 11 Feb 2010 18:07:08 +0100 Subject: [tei-council] FR 2862151: allow certainty in gap and space In-Reply-To: <96f3df641002110831h67967c88ud445878632c9591b@mail.gmail.com> References: <4B73FC69.8050909@kcl.ac.uk> <4B74106A.6000101@oucs.ox.ac.uk> <26FDE88E-B845-48ED-8896-01F8B8F5FC83@kcl.ac.uk> <4B742ED3.2010207@uvic.ca> <96f3df641002110831h67967c88ud445878632c9591b@mail.gmail.com> Message-ID: If no strong voice again, we could ask the editorial support group in Oxford to implement... Le 11 f?vr. 10 ? 17:31, Dot Porter a ?crit : > +1 > > On Thu, Feb 11, 2010 at 11:22 AM, Martin Holmes > wrote: >> Me too. >> >> Martin >> >> Elena Pierazzo wrote: >>> +1 >>> >>> Elena >>> On 11 Feb 2010, at 14:12, James Cummings wrote: >>> >>>> Gabriel Bodard wrote: >>>>> Space is not currently in model.glossLike, but I would see no >>>>> problem >>>>> with it being added there. >>>>> >>>>> Any objections? >>>> This seems entirely reasonable to me. If I am providing a >>>> element I can currently say how big the space is, but >>>> have no way to describe the nature of the space or its reason for >>>> existence without employing various other methods. >>>> >>>> Space left for >>>> illuminated initial which was never added. >>>> >>>> -James >>>> >>>> >>>> _______________________________________________ >>>> tei-council mailing list >>>> tei-council at lists.village.Virginia.EDU >>>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council >>> >>> -- >>> Dr Elena Pierazzo >>> Research Associate >>> Centre for Computing in the Humanities >>> King's College London >>> 26-29 Drury Lane >>> London WC2B 5RL >>> >>> Phone: 0207-848-1949 >>> Fax: 0207-848-2980 >>> elena.pierazzo at kcl.ac.uk >>> www.kcl.ac.uk >>> >>> _______________________________________________ >>> tei-council mailing list >>> tei-council at lists.village.Virginia.EDU >>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council >>> >> >> -- >> Martin Holmes >> University of Victoria Humanities Computing and Media Centre >> (mholmes at uvic.ca) >> Half-Baked Software, Inc. >> (mholmes at halfbakedsoftware.com) >> martin at mholmes.com >> _______________________________________________ >> tei-council mailing list >> tei-council at lists.village.Virginia.EDU >> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council >> > > > > -- > *~*~*~*~*~*~*~*~*~*~* > Dot Porter (MA, MSLS) Metadata Manager (on leave) > Digital Humanities Observatory (RIA), Regus House, 28-32 Upper > Pembroke Street, Dublin 2, Ireland > -- A Project of the Royal Irish Academy -- > Phone: +353 1 234 2444 Fax: +353 1 234 2400 > http://dho.ie Email: dot.porter at gmail.com > *~*~*~*~*~*~*~*~*~*~* > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council From lou.burnard at oucs.ox.ac.uk Thu Feb 11 12:09:26 2010 From: lou.burnard at oucs.ox.ac.uk (Lou) Date: Thu, 11 Feb 2010 17:09:26 +0000 Subject: [tei-council] FR 2862151: allow certainty in gap and space In-Reply-To: References: <4B73FC69.8050909@kcl.ac.uk> <4B74106A.6000101@oucs.ox.ac.uk> <26FDE88E-B845-48ED-8896-01F8B8F5FC83@kcl.ac.uk> <4B742ED3.2010207@uvic.ca> <96f3df641002110831h67967c88ud445878632c9591b@mail.gmail.com> Message-ID: <4B7439C6.7060303@oucs.ox.ac.uk> Done already.... watch sourceforge! Laurent Romary wrote: > If no strong voice again, we could ask the editorial support group in > Oxford to implement... > > Le 11 f?vr. 10 ? 17:31, Dot Porter a ?crit : > >> +1 >> >> On Thu, Feb 11, 2010 at 11:22 AM, Martin Holmes >> wrote: >>> Me too. >>> >>> Martin >>> >>> Elena Pierazzo wrote: >>>> +1 >>>> >>>> Elena >>>> On 11 Feb 2010, at 14:12, James Cummings wrote: >>>> >>>>> Gabriel Bodard wrote: >>>>>> Space is not currently in model.glossLike, but I would see no >>>>>> problem >>>>>> with it being added there. >>>>>> >>>>>> Any objections? >>>>> This seems entirely reasonable to me. If I am providing a >>>>> element I can currently say how big the space is, but >>>>> have no way to describe the nature of the space or its reason for >>>>> existence without employing various other methods. >>>>> >>>>> Space left for >>>>> illuminated initial which was never added. >>>>> >>>>> -James >>>>> >>>>> >>>>> _______________________________________________ >>>>> tei-council mailing list >>>>> tei-council at lists.village.Virginia.EDU >>>>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council >>>> -- >>>> Dr Elena Pierazzo >>>> Research Associate >>>> Centre for Computing in the Humanities >>>> King's College London >>>> 26-29 Drury Lane >>>> London WC2B 5RL >>>> >>>> Phone: 0207-848-1949 >>>> Fax: 0207-848-2980 >>>> elena.pierazzo at kcl.ac.uk >>>> www.kcl.ac.uk >>>> >>>> _______________________________________________ >>>> tei-council mailing list >>>> tei-council at lists.village.Virginia.EDU >>>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council >>>> >>> -- >>> Martin Holmes >>> University of Victoria Humanities Computing and Media Centre >>> (mholmes at uvic.ca) >>> Half-Baked Software, Inc. >>> (mholmes at halfbakedsoftware.com) >>> martin at mholmes.com >>> _______________________________________________ >>> tei-council mailing list >>> tei-council at lists.village.Virginia.EDU >>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council >>> >> >> >> -- >> *~*~*~*~*~*~*~*~*~*~* >> Dot Porter (MA, MSLS) Metadata Manager (on leave) >> Digital Humanities Observatory (RIA), Regus House, 28-32 Upper >> Pembroke Street, Dublin 2, Ireland >> -- A Project of the Royal Irish Academy -- >> Phone: +353 1 234 2444 Fax: +353 1 234 2400 >> http://dho.ie Email: dot.porter at gmail.com >> *~*~*~*~*~*~*~*~*~*~* >> _______________________________________________ >> tei-council mailing list >> tei-council at lists.village.Virginia.EDU >> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council From daniel.odonnell at uleth.ca Thu Feb 11 12:34:38 2010 From: daniel.odonnell at uleth.ca (O'Donnell, Dan) Date: Thu, 11 Feb 2010 10:34:38 -0700 Subject: [tei-council] Tite requests Message-ID: <4B743FAE.3040102@uleth.ca> Hi all, As I mentioned at the teleconference, we received some notes on issues with Tite that Apex would like to see addressed before the launch of the programme. Most of them are very sensible and agree with things that people have said here. They've also pointed out an issue to do with release schedules and the way Tite is designed that would require longer-term thinking, but ties in with what people said here when I asked which version of Tite we should refer to in the contract. Perry is extracting the notes to form an actual proposal for Council to consider in much the same way we often ask people to think about sf tickets and discuss them for us. It should be done over the weekend. I'll pass it on to you as soon as it is done. Ideally we should add him to the conversation as a non-voting member. -dan -- Daniel Paul O'Donnell Associate Professor of English University of Lethbridge Chair and CEO, Text Encoding Initiative (http://www.tei-c.org/) Co-Chair, Digital Initiatives Advisory Board, Medieval Academy of America President-elect (English), Society for Digital Humanities/Soci?t? pour l'?tude des m?dias interactifs (http://sdh-semi.org/) Founding Director (2003-2009), Digital Medievalist Project (http://www.digitalmedievalist.org/) Vox: +1 403 329-2377 Fax: +1 403 382-7191 (non-confidential) Home Page: http://people.uleth.ca/~daniel.odonnell/ From sebastian.rahtz at oucs.ox.ac.uk Thu Feb 11 13:56:09 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Thu, 11 Feb 2010 18:56:09 +0000 Subject: [tei-council] xml:space In-Reply-To: <4B73F89F.9010509@kcl.ac.uk> References: <4B72AE51.7090102@oucs.ox.ac.uk> <52F33B6A-C117-401F-A7A6-7ED2F7616A9E@oucs.ox.ac.uk> <4B72C647.5010104@oucs.ox.ac.uk> <6ED23CEC-64ED-46A2-94BE-9C50B7BCE2B5@oucs.ox.ac.uk> <4B72E34B.6000300@oucs.ox.ac.uk> <4B72EC66.3020207@kcl.ac.uk> <15AE0840-5663-4B10-A327-7ABEC526A076@oucs.ox.ac.uk> <4B73F89F.9010509@kcl.ac.uk> Message-ID: <730E79E4-D14C-4AE9-A926-242F74033127@oucs.ox.ac.uk> With many apologies, http://tei.oucs.ox.ac.uk/Roma/ and points south (http://tei.oucs.ox.ac.uk/release/doc/tei-p5-doc/en/html/ref-att.global.html) are now all up to date. I'm likely to release this over the weekend Lou, do you have the wherewithall to knock up some release notes? -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From gabriel.bodard at kcl.ac.uk Fri Feb 12 11:43:06 2010 From: gabriel.bodard at kcl.ac.uk (Gabriel Bodard) Date: Fri, 12 Feb 2010 16:43:06 +0000 Subject: [tei-council] Roma problem Re: xml:space In-Reply-To: <730E79E4-D14C-4AE9-A926-242F74033127@oucs.ox.ac.uk> References: <4B72AE51.7090102@oucs.ox.ac.uk> <52F33B6A-C117-401F-A7A6-7ED2F7616A9E@oucs.ox.ac.uk> <4B72C647.5010104@oucs.ox.ac.uk> <6ED23CEC-64ED-46A2-94BE-9C50B7BCE2B5@oucs.ox.ac.uk> <4B72E34B.6000300@oucs.ox.ac.uk> <4B72EC66.3020207@kcl.ac.uk> <15AE0840-5663-4B10-A327-7ABEC526A076@oucs.ox.ac.uk> <4B73F89F.9010509@kcl.ac.uk> <730E79E4-D14C-4AE9-A926-242F74033127@oucs.ox.ac.uk> Message-ID: <4B75851A.7050100@kcl.ac.uk> I just created an rng schema using the dev Roma, and it's given me an invalid schema--duplicate attribute "cert" (seems to affect addSpan). This would presumably be a problem if it found its way into the release version...? (Sorry to drop this so late on a Friday.) My odd and schemata are at https://epidoc.svn.sourceforge.net/svnroot/epidoc/trunk/schema in case that helps anyone duplicate the problem. G On 2010-02-11 18:56, Sebastian Rahtz wrote: > With many apologies, http://tei.oucs.ox.ac.uk/Roma/ and points south > (http://tei.oucs.ox.ac.uk/release/doc/tei-p5-doc/en/html/ref-att.global.html) > are now all up to date. I'm likely to release this over the weekend > > Lou, do you have the wherewithall to knock up some release notes? > -- > Sebastian Rahtz > Information Manager, Oxford University Computing Services > 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 > > S?lo le pido a Dios > que el futuro no me sea indiferente > > > > -- Dr Gabriel BODARD (Epigrapher & Digital Classicist) Centre for Computing in the Humanities King's College London 26-29 Drury Lane London WC2B 5RL Email: gabriel.bodard at kcl.ac.uk Tel: +44 (0)20 7848 1388 Fax: +44 (0)20 7848 2980 http://www.digitalclassicist.org/ http://www.currentepigraphy.org/ From sebastian.rahtz at oucs.ox.ac.uk Fri Feb 12 12:05:15 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Fri, 12 Feb 2010 17:05:15 +0000 Subject: [tei-council] Roma problem Re: xml:space In-Reply-To: <4B75851A.7050100@kcl.ac.uk> References: <4B72AE51.7090102@oucs.ox.ac.uk> <52F33B6A-C117-401F-A7A6-7ED2F7616A9E@oucs.ox.ac.uk> <4B72C647.5010104@oucs.ox.ac.uk> <6ED23CEC-64ED-46A2-94BE-9C50B7BCE2B5@oucs.ox.ac.uk> <4B72E34B.6000300@oucs.ox.ac.uk> <4B72EC66.3020207@kcl.ac.uk> <15AE0840-5663-4B10-A327-7ABEC526A076@oucs.ox.ac.uk> <4B73F89F.9010509@kcl.ac.uk> <730E79E4-D14C-4AE9-A926-242F74033127@oucs.ox.ac.uk> <4B75851A.7050100@kcl.ac.uk> Message-ID: <86901D5E-44E2-4DCD-A832-F76883D6A6E3@oucs.ox.ac.uk> well, thank god you found it today and not tomorrow :-} looking at it, definitely a show-stopper bug -- Sebastian Rahtz (acting) Information and Support Group Manager Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From sebastian.rahtz at oucs.ox.ac.uk Fri Feb 12 12:10:24 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Fri, 12 Feb 2010 17:10:24 +0000 Subject: [tei-council] Roma problem Re: xml:space In-Reply-To: <4B75851A.7050100@kcl.ac.uk> References: <4B72AE51.7090102@oucs.ox.ac.uk> <52F33B6A-C117-401F-A7A6-7ED2F7616A9E@oucs.ox.ac.uk> <4B72C647.5010104@oucs.ox.ac.uk> <6ED23CEC-64ED-46A2-94BE-9C50B7BCE2B5@oucs.ox.ac.uk> <4B72E34B.6000300@oucs.ox.ac.uk> <4B72EC66.3020207@kcl.ac.uk> <15AE0840-5663-4B10-A327-7ABEC526A076@oucs.ox.ac.uk> <4B73F89F.9010509@kcl.ac.uk> <730E79E4-D14C-4AE9-A926-242F74033127@oucs.ox.ac.uk> <4B75851A.7050100@kcl.ac.uk> Message-ID: no, its OK, its all Gabby's fault (mostly anyway). He writes: but there _is_ no attribute @cert in att.editLike to replace. My processing should have, but didnt, picked up the error. @cert is in att.responsibility -- Sebastian Rahtz (acting) Information and Support Group Manager Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From daniel.odonnell at uleth.ca Mon Feb 15 12:28:01 2010 From: daniel.odonnell at uleth.ca (O'Donnell, Dan) Date: Mon, 15 Feb 2010 10:28:01 -0700 Subject: [tei-council] FR 2862151: allow certainty in gap and space In-Reply-To: References: <4B73FC69.8050909@kcl.ac.uk> <4B74106A.6000101@oucs.ox.ac.uk> <26FDE88E-B845-48ED-8896-01F8B8F5FC83@kcl.ac.uk> <4B742ED3.2010207@uvic.ca> <96f3df641002110831h67967c88ud445878632c9591b@mail.gmail.com> Message-ID: <4B798421.6010701@uleth.ca> In fact I love it. Laurent Romary wrote: > If no strong voice again, we could ask the editorial support group in > Oxford to implement... > > Le 11 f?vr. 10 ? 17:31, Dot Porter a ?crit : > > >> +1 >> >> On Thu, Feb 11, 2010 at 11:22 AM, Martin Holmes >> wrote: >> >>> Me too. >>> >>> Martin >>> >>> Elena Pierazzo wrote: >>> >>>> +1 >>>> >>>> Elena >>>> On 11 Feb 2010, at 14:12, James Cummings wrote: >>>> >>>> >>>>> Gabriel Bodard wrote: >>>>> >>>>>> Space is not currently in model.glossLike, but I would see no >>>>>> problem >>>>>> with it being added there. >>>>>> >>>>>> Any objections? >>>>>> >>>>> This seems entirely reasonable to me. If I am providing a >>>>> element I can currently say how big the space is, but >>>>> have no way to describe the nature of the space or its reason for >>>>> existence without employing various other methods. >>>>> >>>>> Space left for >>>>> illuminated initial which was never added. >>>>> >>>>> -James >>>>> >>>>> >>>>> _______________________________________________ >>>>> tei-council mailing list >>>>> tei-council at lists.village.Virginia.EDU >>>>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council >>>>> >>>> -- >>>> Dr Elena Pierazzo >>>> Research Associate >>>> Centre for Computing in the Humanities >>>> King's College London >>>> 26-29 Drury Lane >>>> London WC2B 5RL >>>> >>>> Phone: 0207-848-1949 >>>> Fax: 0207-848-2980 >>>> elena.pierazzo at kcl.ac.uk >>>> www.kcl.ac.uk >>>> >>>> _______________________________________________ >>>> tei-council mailing list >>>> tei-council at lists.village.Virginia.EDU >>>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council >>>> >>>> >>> -- >>> Martin Holmes >>> University of Victoria Humanities Computing and Media Centre >>> (mholmes at uvic.ca) >>> Half-Baked Software, Inc. >>> (mholmes at halfbakedsoftware.com) >>> martin at mholmes.com >>> _______________________________________________ >>> tei-council mailing list >>> tei-council at lists.village.Virginia.EDU >>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council >>> >>> >> >> -- >> *~*~*~*~*~*~*~*~*~*~* >> Dot Porter (MA, MSLS) Metadata Manager (on leave) >> Digital Humanities Observatory (RIA), Regus House, 28-32 Upper >> Pembroke Street, Dublin 2, Ireland >> -- A Project of the Royal Irish Academy -- >> Phone: +353 1 234 2444 Fax: +353 1 234 2400 >> http://dho.ie Email: dot.porter at gmail.com >> *~*~*~*~*~*~*~*~*~*~* >> _______________________________________________ >> tei-council mailing list >> tei-council at lists.village.Virginia.EDU >> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council >> > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > -- Daniel Paul O'Donnell Associate Professor of English University of Lethbridge Chair and CEO, Text Encoding Initiative (http://www.tei-c.org/) Co-Chair, Digital Initiatives Advisory Board, Medieval Academy of America President-elect (English), Society for Digital Humanities/Soci?t? pour l'?tude des m?dias interactifs (http://sdh-semi.org/) Founding Director (2003-2009), Digital Medievalist Project (http://www.digitalmedievalist.org/) Vox: +1 403 329-2377 Fax: +1 403 382-7191 (non-confidential) Home Page: http://people.uleth.ca/~daniel.odonnell/ From James.Cummings at oucs.ox.ac.uk Mon Feb 15 13:05:51 2010 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Mon, 15 Feb 2010 18:05:51 +0000 Subject: [tei-council] FR 2862151: allow certainty in gap and space In-Reply-To: <4B798421.6010701@uleth.ca> References: <4B73FC69.8050909@kcl.ac.uk> <4B74106A.6000101@oucs.ox.ac.uk> <26FDE88E-B845-48ED-8896-01F8B8F5FC83@kcl.ac.uk> <4B742ED3.2010207@uvic.ca> <96f3df641002110831h67967c88ud445878632c9591b@mail.gmail.com> <4B798421.6010701@uleth.ca> Message-ID: <4B798CFF.3040703@oucs.ox.ac.uk> Thinking about allowing desc on currently empty elements....reminds me of this highly sensible icket: http://sourceforge.net/tracker/?func=detail&atid=644062&aid=2812295&group_id=106328 The argument being you have plenty of places one needs to use graphic, and specifically not figure, but need to provide the equivalent of html:img/@alt text for the graphic. Solution: add graphic to model.glossLike -James O'Donnell, Dan wrote: > In fact I love it. > > Laurent Romary wrote: >> If no strong voice again, we could ask the editorial support group in >> Oxford to implement... >> >> Le 11 f?vr. 10 ? 17:31, Dot Porter a ?crit : >> >> >>> +1 >>> >>> On Thu, Feb 11, 2010 at 11:22 AM, Martin Holmes >>> wrote: >>> >>>> Me too. >>>> >>>> Martin >>>> >>>> Elena Pierazzo wrote: >>>> >>>>> +1 >>>>> >>>>> Elena >>>>> On 11 Feb 2010, at 14:12, James Cummings wrote: >>>>> >>>>> >>>>>> Gabriel Bodard wrote: >>>>>> >>>>>>> Space is not currently in model.glossLike, but I would see no >>>>>>> problem >>>>>>> with it being added there. >>>>>>> >>>>>>> Any objections? >>>>>>> >>>>>> This seems entirely reasonable to me. If I am providing a >>>>>> element I can currently say how big the space is, but >>>>>> have no way to describe the nature of the space or its reason for >>>>>> existence without employing various other methods. >>>>>> >>>>>> Space left for >>>>>> illuminated initial which was never added. >>>>>> >>>>>> -James >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> tei-council mailing list >>>>>> tei-council at lists.village.Virginia.EDU >>>>>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council >>>>>> >>>>> -- >>>>> Dr Elena Pierazzo >>>>> Research Associate >>>>> Centre for Computing in the Humanities >>>>> King's College London >>>>> 26-29 Drury Lane >>>>> London WC2B 5RL >>>>> >>>>> Phone: 0207-848-1949 >>>>> Fax: 0207-848-2980 >>>>> elena.pierazzo at kcl.ac.uk >>>>> www.kcl.ac.uk >>>>> >>>>> _______________________________________________ >>>>> tei-council mailing list >>>>> tei-council at lists.village.Virginia.EDU >>>>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council >>>>> >>>>> >>>> -- >>>> Martin Holmes >>>> University of Victoria Humanities Computing and Media Centre >>>> (mholmes at uvic.ca) >>>> Half-Baked Software, Inc. >>>> (mholmes at halfbakedsoftware.com) >>>> martin at mholmes.com >>>> _______________________________________________ >>>> tei-council mailing list >>>> tei-council at lists.village.Virginia.EDU >>>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council >>>> >>>> >>> -- >>> *~*~*~*~*~*~*~*~*~*~* >>> Dot Porter (MA, MSLS) Metadata Manager (on leave) >>> Digital Humanities Observatory (RIA), Regus House, 28-32 Upper >>> Pembroke Street, Dublin 2, Ireland >>> -- A Project of the Royal Irish Academy -- >>> Phone: +353 1 234 2444 Fax: +353 1 234 2400 >>> http://dho.ie Email: dot.porter at gmail.com >>> *~*~*~*~*~*~*~*~*~*~* >>> _______________________________________________ >>> tei-council mailing list >>> tei-council at lists.village.Virginia.EDU >>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council >>> >> _______________________________________________ >> tei-council mailing list >> tei-council at lists.village.Virginia.EDU >> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council >> > From daniel.odonnell at uleth.ca Mon Feb 15 13:10:58 2010 From: daniel.odonnell at uleth.ca (O'Donnell, Dan) Date: Mon, 15 Feb 2010 11:10:58 -0700 Subject: [tei-council] FR 2862151: allow certainty in gap and space In-Reply-To: <4B798CFF.3040703@oucs.ox.ac.uk> References: <4B73FC69.8050909@kcl.ac.uk> <4B74106A.6000101@oucs.ox.ac.uk> <26FDE88E-B845-48ED-8896-01F8B8F5FC83@kcl.ac.uk> <4B742ED3.2010207@uvic.ca> <96f3df641002110831h67967c88ud445878632c9591b@mail.gmail.com> <4B798421.6010701@uleth.ca> <4B798CFF.3040703@oucs.ox.ac.uk> Message-ID: <4B798E32.2060400@uleth.ca> As always, I would ask whether there is a generalisable principle or process here? Are we actually rethinking the semantics of glossLike? What other parallel situations are there? -dan P.S. You're not allowed to characterise your own tickets as sensible ;) James Cummings wrote: > Thinking about allowing desc on currently empty elements....reminds me > of this highly sensible icket: > > http://sourceforge.net/tracker/?func=detail&atid=644062&aid=2812295&group_id=106328 > > > The argument being you have plenty of places one needs to use graphic, > and specifically not figure, but need to provide the equivalent of > html:img/@alt text for the graphic. > > Solution: add graphic to model.glossLike > > -James > > O'Donnell, Dan wrote: >> In fact I love it. >> >> Laurent Romary wrote: >>> If no strong voice again, we could ask the editorial support group >>> in Oxford to implement... >>> >>> Le 11 f?vr. 10 ? 17:31, Dot Porter a ?crit : >>> >>> >>>> +1 >>>> >>>> On Thu, Feb 11, 2010 at 11:22 AM, Martin Holmes >>>> wrote: >>>> >>>>> Me too. >>>>> >>>>> Martin >>>>> >>>>> Elena Pierazzo wrote: >>>>> >>>>>> +1 >>>>>> >>>>>> Elena >>>>>> On 11 Feb 2010, at 14:12, James Cummings wrote: >>>>>> >>>>>> >>>>>>> Gabriel Bodard wrote: >>>>>>> >>>>>>>> Space is not currently in model.glossLike, but I would see no >>>>>>>> problem >>>>>>>> with it being added there. >>>>>>>> >>>>>>>> Any objections? >>>>>>>> >>>>>>> This seems entirely reasonable to me. If I am providing a >>>>>>> element I can currently say how big the space is, but >>>>>>> have no way to describe the nature of the space or its reason for >>>>>>> existence without employing various other methods. >>>>>>> >>>>>>> Space left for >>>>>>> illuminated initial which was never added. >>>>>>> >>>>>>> -James >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> tei-council mailing list >>>>>>> tei-council at lists.village.Virginia.EDU >>>>>>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council >>>>>>> >>>>>> -- >>>>>> Dr Elena Pierazzo >>>>>> Research Associate >>>>>> Centre for Computing in the Humanities >>>>>> King's College London >>>>>> 26-29 Drury Lane >>>>>> London WC2B 5RL >>>>>> >>>>>> Phone: 0207-848-1949 >>>>>> Fax: 0207-848-2980 >>>>>> elena.pierazzo at kcl.ac.uk >>>>>> www.kcl.ac.uk >>>>>> >>>>>> _______________________________________________ >>>>>> tei-council mailing list >>>>>> tei-council at lists.village.Virginia.EDU >>>>>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council >>>>>> >>>>>> >>>>> -- >>>>> Martin Holmes >>>>> University of Victoria Humanities Computing and Media Centre >>>>> (mholmes at uvic.ca) >>>>> Half-Baked Software, Inc. >>>>> (mholmes at halfbakedsoftware.com) >>>>> martin at mholmes.com >>>>> _______________________________________________ >>>>> tei-council mailing list >>>>> tei-council at lists.village.Virginia.EDU >>>>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council >>>>> >>>>> >>>> -- >>>> *~*~*~*~*~*~*~*~*~*~* >>>> Dot Porter (MA, MSLS) Metadata Manager (on leave) >>>> Digital Humanities Observatory (RIA), Regus House, 28-32 Upper >>>> Pembroke Street, Dublin 2, Ireland >>>> -- A Project of the Royal Irish Academy -- >>>> Phone: +353 1 234 2444 Fax: +353 1 234 2400 >>>> http://dho.ie Email: dot.porter at gmail.com >>>> *~*~*~*~*~*~*~*~*~*~* >>>> _______________________________________________ >>>> tei-council mailing list >>>> tei-council at lists.village.Virginia.EDU >>>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council >>>> >>> _______________________________________________ >>> tei-council mailing list >>> tei-council at lists.village.Virginia.EDU >>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council >>> >> > -- Daniel Paul O'Donnell Associate Professor of English University of Lethbridge Chair and CEO, Text Encoding Initiative (http://www.tei-c.org/) Co-Chair, Digital Initiatives Advisory Board, Medieval Academy of America President-elect (English), Society for Digital Humanities/Soci?t? pour l'?tude des m?dias interactifs (http://sdh-semi.org/) Founding Director (2003-2009), Digital Medievalist Project (http://www.digitalmedievalist.org/) Vox: +1 403 329-2377 Fax: +1 403 382-7191 (non-confidential) Home Page: http://people.uleth.ca/~daniel.odonnell/ From James.Cummings at oucs.ox.ac.uk Tue Feb 16 03:53:18 2010 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Tue, 16 Feb 2010 08:53:18 +0000 Subject: [tei-council] FR 2862151: allow certainty in gap and space In-Reply-To: <4B798E32.2060400@uleth.ca> References: <4B73FC69.8050909@kcl.ac.uk> <4B74106A.6000101@oucs.ox.ac.uk> <26FDE88E-B845-48ED-8896-01F8B8F5FC83@kcl.ac.uk> <4B742ED3.2010207@uvic.ca> <96f3df641002110831h67967c88ud445878632c9591b@mail.gmail.com> <4B798421.6010701@uleth.ca> <4B798CFF.3040703@oucs.ox.ac.uk> <4B798E32.2060400@uleth.ca> Message-ID: <4B7A5CFE.4090606@oucs.ox.ac.uk> O'Donnell, Dan wrote: > As always, I would ask whether there is a generalisable principle or > process here? Are we actually rethinking the semantics of glossLike? No, I think the semantics are the same... the members of model.glossLike all in some way describe or further refine our knowledge about the element that contains them. Providing it on and similar elements would only mean that we're able to describe that element (which is suitable enough for the use case I think). What I didn't realise was that gloss is both a member of model.emphLike and model.glossLike ... some places get gloss not from model.glossLike but from model.limitedPhrase <- model.emphLike. Maybe we should look again and see if the other model.glossLike members make sense wherever gloss is allowed? > What other parallel situations are there? That might want : span? anchor? graphic? cb/lb/pb/milestone? addSpan/damageSpan/delSpan? ptr? pause? caesura? etc. etc.(random sample) Basically, if one can argue that you might have a need to describe the element, or its certainty/precision, then many empty elements could be lacking model.glossLike. is a clear and demonstrable use-case. It is good practice to include alt text on your graphics when transformed to XHTML, and currently the TEI does not provide a convenient way to do this. (Because not all graphics are figures.) > P.S. You're not allowed to characterise your own tickets as sensible ;) I'm allowed to do whatever I want... now you might not *believe* me. ;-) It was intended as a tongue-in-cheek comment. -James -- Dr James Cummings, Research Technology Service Oxford University Computing Services University of Oxford From gabriel.bodard at kcl.ac.uk Tue Feb 16 08:59:42 2010 From: gabriel.bodard at kcl.ac.uk (Gabriel Bodard) Date: Tue, 16 Feb 2010 13:59:42 +0000 Subject: [tei-council] FR 2862151: allow certainty in gap and space In-Reply-To: <4B7A5CFE.4090606@oucs.ox.ac.uk> References: <4B73FC69.8050909@kcl.ac.uk> <4B74106A.6000101@oucs.ox.ac.uk> <26FDE88E-B845-48ED-8896-01F8B8F5FC83@kcl.ac.uk> <4B742ED3.2010207@uvic.ca> <96f3df641002110831h67967c88ud445878632c9591b@mail.gmail.com> <4B798421.6010701@uleth.ca> <4B798CFF.3040703@oucs.ox.ac.uk> <4B798E32.2060400@uleth.ca> <4B7A5CFE.4090606@oucs.ox.ac.uk> Message-ID: <4B7AA4CE.70603@kcl.ac.uk> I agree that (a) this was a sensible ticket, and (b) there is a concrete use-case here which is different from merely thinking something might be a good idea in principle. Allowing glossLike on all empty elements might be a good idea in principle, but until there's a use-case for it, let's not frighten the bees. On 2010-02-16 08:53, James Cummings wrote: > O'Donnell, Dan wrote: >> As always, I would ask whether there is a generalisable principle or >> process here? Are we actually rethinking the semantics of glossLike? > > No, I think the semantics are the same... the members of model.glossLike > all in some way describe or further refine our knowledge about the > element that contains them. Providing it on and similar > elements would only mean that we're able to describe that element (which > is suitable enough for the use case I think). > > What I didn't realise was that gloss is both a member of model.emphLike > and model.glossLike ... some places get gloss not from model.glossLike > but from model.limitedPhrase<- model.emphLike. Maybe we should look > again and see if the other model.glossLike members make sense wherever > gloss is allowed? > >> What other parallel situations are there? > > That might want: span? anchor? graphic? cb/lb/pb/milestone? > addSpan/damageSpan/delSpan? ptr? pause? caesura? etc. etc.(random > sample) Basically, if one can argue that you might have a need to > describe the element, or its certainty/precision, then many empty > elements could be lacking model.glossLike. > > is a clear and demonstrable use-case. It is good practice to > include alt text on your graphics when transformed to XHTML, and > currently the TEI does not provide a convenient way to do this. (Because > not all graphics are figures.) > >> P.S. You're not allowed to characterise your own tickets as sensible ;) > > I'm allowed to do whatever I want... now you might not *believe* me. ;-) > It was intended as a tongue-in-cheek comment. > > -James > -- Dr Gabriel BODARD (Epigrapher & Digital Classicist) Centre for Computing in the Humanities King's College London 26-29 Drury Lane London WC2B 5RL Email: gabriel.bodard at kcl.ac.uk Tel: +44 (0)20 7848 1388 Fax: +44 (0)20 7848 2980 http://www.digitalclassicist.org/ http://www.currentepigraphy.org/ From James.Cummings at oucs.ox.ac.uk Tue Feb 16 17:32:24 2010 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Tue, 16 Feb 2010 22:32:24 +0000 Subject: [tei-council] FR 2862151: allow certainty in gap and space In-Reply-To: <4B7AA4CE.70603@kcl.ac.uk> References: <4B73FC69.8050909@kcl.ac.uk> <4B74106A.6000101@oucs.ox.ac.uk> <26FDE88E-B845-48ED-8896-01F8B8F5FC83@kcl.ac.uk> <4B742ED3.2010207@uvic.ca> <96f3df641002110831h67967c88ud445878632c9591b@mail.gmail.com> <4B798421.6010701@uleth.ca> <4B798CFF.3040703@oucs.ox.ac.uk> <4B798E32.2060400@uleth.ca> <4B7A5CFE.4090606@oucs.ox.ac.uk> <4B7AA4CE.70603@kcl.ac.uk> Message-ID: <4B7B1CF8.5060401@oucs.ox.ac.uk> Gabriel Bodard wrote: > I agree that (a) this was a sensible ticket, Why thank you, cynics might say that since you've got a use case for it as well that you might be biased. > and (b) there is a concrete > use-case here which is different from merely thinking something might be > a good idea in principle. Allowing glossLike on all empty elements might > be a good idea in principle, but until there's a use-case for it, let's > not frighten the bees. Completely reasonable, yes, of course. I was only responding to Dan's idea that we might be changing the semantics slowly (is that 'semantic creep'?), and I don't think we are even if we did add lots of things with a similar structure. But yes, all we're suggesting now is that graphic should be added to model.glossLike. -James From laurent.romary at loria.fr Wed Feb 17 05:19:31 2010 From: laurent.romary at loria.fr (Laurent Romary) Date: Wed, 17 Feb 2010 11:19:31 +0100 Subject: [tei-council] FR 2862151: allow certainty in gap and space In-Reply-To: <4B7B1CF8.5060401@oucs.ox.ac.uk> References: <4B73FC69.8050909@kcl.ac.uk> <4B74106A.6000101@oucs.ox.ac.uk> <26FDE88E-B845-48ED-8896-01F8B8F5FC83@kcl.ac.uk> <4B742ED3.2010207@uvic.ca> <96f3df641002110831h67967c88ud445878632c9591b@mail.gmail.com> <4B798421.6010701@uleth.ca> <4B798CFF.3040703@oucs.ox.ac.uk> <4B798E32.2060400@uleth.ca> <4B7A5CFE.4090606@oucs.ox.ac.uk> <4B7AA4CE.70603@kcl.ac.uk> <4B7B1CF8.5060401@oucs.ox.ac.uk> Message-ID: <444020A5-AB65-4642-8F16-E288692FBBF8@loria.fr> Consensus? (y/n) Laurent Le 16 f?vr. 10 ? 23:32, James Cummings a ?crit : > But yes, all we're suggesting now is that > graphic should be added to model.glossLike. From lou.burnard at oucs.ox.ac.uk Wed Feb 17 05:34:56 2010 From: lou.burnard at oucs.ox.ac.uk (Lou Burnard) Date: Wed, 17 Feb 2010 10:34:56 +0000 Subject: [tei-council] FR 2862151: allow certainty in gap and space In-Reply-To: <444020A5-AB65-4642-8F16-E288692FBBF8@loria.fr> References: <4B73FC69.8050909@kcl.ac.uk> <4B74106A.6000101@oucs.ox.ac.uk> <26FDE88E-B845-48ED-8896-01F8B8F5FC83@kcl.ac.uk> <4B742ED3.2010207@uvic.ca> <96f3df641002110831h67967c88ud445878632c9591b@mail.gmail.com> <4B798421.6010701@uleth.ca> <4B798CFF.3040703@oucs.ox.ac.uk> <4B798E32.2060400@uleth.ca> <4B7A5CFE.4090606@oucs.ox.ac.uk> <4B7AA4CE.70603@kcl.ac.uk> <4B7B1CF8.5060401@oucs.ox.ac.uk> <444020A5-AB65-4642-8F16-E288692FBBF8@loria.fr> Message-ID: <4B7BC650.30305@oucs.ox.ac.uk> I haven't thought about it yet. Is this so that we can put notes inside the graphic a la METS? Laurent Romary wrote: > Consensus? (y/n) > Laurent > > Le 16 f?vr. 10 ? 23:32, James Cummings a ?crit : > > >> But yes, all we're suggesting now is that >> graphic should be added to model.glossLike. >> > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > From James.Cummings at oucs.ox.ac.uk Wed Feb 17 07:03:05 2010 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Wed, 17 Feb 2010 12:03:05 +0000 Subject: [tei-council] FR 2862151: allow certainty in gap and space In-Reply-To: <4B7BC650.30305@oucs.ox.ac.uk> References: <4B73FC69.8050909@kcl.ac.uk> <4B74106A.6000101@oucs.ox.ac.uk> <26FDE88E-B845-48ED-8896-01F8B8F5FC83@kcl.ac.uk> <4B742ED3.2010207@uvic.ca> <96f3df641002110831h67967c88ud445878632c9591b@mail.gmail.com> <4B798421.6010701@uleth.ca> <4B798CFF.3040703@oucs.ox.ac.uk> <4B798E32.2060400@uleth.ca> <4B7A5CFE.4090606@oucs.ox.ac.uk> <4B7AA4CE.70603@kcl.ac.uk> <4B7B1CF8.5060401@oucs.ox.ac.uk> <444020A5-AB65-4642-8F16-E288692FBBF8@loria.fr> <4B7BC650.30305@oucs.ox.ac.uk> Message-ID: <4B7BDAF9.4030401@oucs.ox.ac.uk> Lou Burnard wrote: > I haven't thought about it yet. Is this so that we can put notes inside > the graphic a la METS? Or HTML in my use-case, but yes something like that. My basic argument would be: There are plenty of places where one only has graphic (or graphic is semantically the right choice over figure) where one also has a need to create a description of the graphic element. For example, when wanting to output either HTML (I guess or METS) you may wish to provide some text for the @html:alt attribute on html:img. Currently the TEI gives no easy way to do this (without abusing the semantics of figure, even if it were available everywhere graphic is, which it isn't). Given that some countries have disability legislation that means websites of publicly-funded institutions (such as universities) must provide alt text for images and other accessibility rules (SENDA in the UK), it seems reasonable that the TEI should have a straightforward way of providing descriptions of graphics. This might also prove useful in locations where figure is not allowed but graphic is (e.g. facsimile). -James > > Laurent Romary wrote: >> Consensus? (y/n) >> Laurent >> >> Le 16 f?vr. 10 ? 23:32, James Cummings a ?crit : >> >> >>> But yes, all we're suggesting now is that >>> graphic should be added to model.glossLike. >>> >> _______________________________________________ >> tei-council mailing list >> tei-council at lists.village.Virginia.EDU >> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council >> > From mholmes at uvic.ca Wed Feb 17 08:29:30 2010 From: mholmes at uvic.ca (Martin Holmes) Date: Wed, 17 Feb 2010 05:29:30 -0800 Subject: [tei-council] FR 2862151: allow certainty in gap and space In-Reply-To: <444020A5-AB65-4642-8F16-E288692FBBF8@loria.fr> References: <4B73FC69.8050909@kcl.ac.uk> <4B74106A.6000101@oucs.ox.ac.uk> <26FDE88E-B845-48ED-8896-01F8B8F5FC83@kcl.ac.uk> <4B742ED3.2010207@uvic.ca> <96f3df641002110831h67967c88ud445878632c9591b@mail.gmail.com> <4B798421.6010701@uleth.ca> <4B798CFF.3040703@oucs.ox.ac.uk> <4B798E32.2060400@uleth.ca> <4B7A5CFE.4090606@oucs.ox.ac.uk> <4B7AA4CE.70603@kcl.ac.uk> <4B7B1CF8.5060401@oucs.ox.ac.uk> <444020A5-AB65-4642-8F16-E288692FBBF8@loria.fr> Message-ID: <4B7BEF3A.8070805@uvic.ca> y for me. Laurent Romary wrote: > Consensus? (y/n) > Laurent > > Le 16 f?vr. 10 ? 23:32, James Cummings a ?crit : > >> But yes, all we're suggesting now is that >> graphic should be added to model.glossLike. > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council From kevin.s.hawkins at ultraslavonic.info Wed Feb 17 08:42:31 2010 From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins) Date: Wed, 17 Feb 2010 13:42:31 +0000 Subject: [tei-council] bug 2812295: add graphic to model.glossLike (was Re: FR 2862151: allow certainty in gap and space) In-Reply-To: <4B7BEF3A.8070805@uvic.ca> References: <4B73FC69.8050909@kcl.ac.uk> <4B74106A.6000101@oucs.ox.ac.uk> <26FDE88E-B845-48ED-8896-01F8B8F5FC83@kcl.ac.uk> <4B742ED3.2010207@uvic.ca> <96f3df641002110831h67967c88ud445878632c9591b@mail.gmail.com> <4B798421.6010701@uleth.ca> <4B798CFF.3040703@oucs.ox.ac.uk> <4B798E32.2060400@uleth.ca> <4B7A5CFE.4090606@oucs.ox.ac.uk> <4B7AA4CE.70603@kcl.ac.uk> <4B7B1CF8.5060401@oucs.ox.ac.uk> <444020A5-AB65-4642-8F16-E288692FBBF8@loria.fr> <4B7BEF3A.8070805@uvic.ca> Message-ID: <4B7BF247.8050405@ultraslavonic.info> This discussion is now about something quite unrelated to the original subject line, so I'm changing it for the benefit of those who may not be following the discussion very closely. We're now discussing this bug: https://sourceforge.net/tracker/?func=detail&atid=644062&aid=2812295&group_id=106328 James recently wrote: *** My basic argument would be: There are plenty of places where one only has graphic (or graphic is semantically the right choice over figure) where one also has a need to create a description of the graphic element. For example, when wanting to output either HTML (I guess or METS) you may wish to provide some text for the @html:alt attribute on html:img. Currently the TEI gives no easy way to do this (without abusing the semantics of figure, even if it were available everywhere graphic is, which it isn't). Given that some countries have disability legislation that means websites of publicly-funded institutions (such as universities) must provide alt text for images and other accessibility rules (SENDA in the UK), it seems reasonable that the TEI should have a straightforward way of providing descriptions of graphics. This might also prove useful in locations where figure is not allowed but graphic is (e.g. facsimile). *** So we're talking about changing from being an empty element to one that may contain any of the following: altIdent certainty desc equiv gloss precision respons in order to provide some metadata. I support it, but it does make me wonder whether
should also be added to this class even though it (
) already has some ability to "attach" metadata. Kevin From mholmes at uvic.ca Wed Feb 17 08:52:03 2010 From: mholmes at uvic.ca (Martin Holmes) Date: Wed, 17 Feb 2010 05:52:03 -0800 Subject: [tei-council] bug 2812295: add graphic to model.glossLike (was Re: FR 2862151: allow certainty in gap and space) In-Reply-To: <4B7BF247.8050405@ultraslavonic.info> References: <4B73FC69.8050909@kcl.ac.uk> <4B74106A.6000101@oucs.ox.ac.uk> <26FDE88E-B845-48ED-8896-01F8B8F5FC83@kcl.ac.uk> <4B742ED3.2010207@uvic.ca> <96f3df641002110831h67967c88ud445878632c9591b@mail.gmail.com> <4B798421.6010701@uleth.ca> <4B798CFF.3040703@oucs.ox.ac.uk> <4B798E32.2060400@uleth.ca> <4B7A5CFE.4090606@oucs.ox.ac.uk> <4B7AA4CE.70603@kcl.ac.uk> <4B7B1CF8.5060401@oucs.ox.ac.uk> <444020A5-AB65-4642-8F16-E288692FBBF8@loria.fr> <4B7BEF3A.8070805@uvic.ca> <4B7BF247.8050405@ultraslavonic.info> Message-ID: <4B7BF483.6010906@uvic.ca> Kevin Hawkins wrote: > I support it, but it does make me wonder whether
should also be > added to this class even though it (
) already has some ability > to "attach" metadata.
often contains , so we'd then be providing more options (and potentially more confusion) with regard to where descriptive information should go. If no-one has actually asked for
to be added to the class, I'd say let's not worry about it. Cheers, Martin From James.Cummings at oucs.ox.ac.uk Wed Feb 17 09:11:02 2010 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Wed, 17 Feb 2010 14:11:02 +0000 Subject: [tei-council] bug 2812295: add graphic to model.glossLike (was Re: FR 2862151: allow certainty in gap and space) In-Reply-To: <4B7BF483.6010906@uvic.ca> References: <4B73FC69.8050909@kcl.ac.uk> <4B74106A.6000101@oucs.ox.ac.uk> <26FDE88E-B845-48ED-8896-01F8B8F5FC83@kcl.ac.uk> <4B742ED3.2010207@uvic.ca> <96f3df641002110831h67967c88ud445878632c9591b@mail.gmail.com> <4B798421.6010701@uleth.ca> <4B798CFF.3040703@oucs.ox.ac.uk> <4B798E32.2060400@uleth.ca> <4B7A5CFE.4090606@oucs.ox.ac.uk> <4B7AA4CE.70603@kcl.ac.uk> <4B7B1CF8.5060401@oucs.ox.ac.uk> <444020A5-AB65-4642-8F16-E288692FBBF8@loria.fr> <4B7BEF3A.8070805@uvic.ca> <4B7BF247.8050405@ultraslavonic.info> <4B7BF483.6010906@uvic.ca> Message-ID: <4B7BF8F6.6040604@oucs.ox.ac.uk> Martin Holmes wrote: > If no-one has actually asked for
to be added to the class, I'd > say let's not worry about it. I'd second this. As Gaby mentioned with the milestone type elements which could possibly also benefit from model.glossLike, I would say that since no one has asked for them, let's not go crazy and get carried away. inside has been asked for, at least twice (coincidentally by members of council) with slightly different but equally valid (IMNSHO) use-cases. -James From James.Cummings at oucs.ox.ac.uk Tue Mar 2 11:58:34 2010 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Tue, 02 Mar 2010 16:58:34 +0000 Subject: [tei-council] Criteria for TEI Repository Inclusion Message-ID: <4B8D43BA.4010302@oucs.ox.ac.uk> Hi there, We were having a discussion recently about a TEI Customisation that we created for the ENRICH project and its future maintenance. Although I believe we're leaning in favour of setting up a separate Sourceforge or Google Code repository for it and managing it separately from the TEI SF repository, somehow 'donating' it to the TEI-C was suggested at one point. While I frankly think it is better for such things to be managed separately form the TEI, it made me realise that we don't seem to have a set policy on when something (an ODD, a piece of software, etc.) gets included in the TEI SF repository and when it doesn't. Currently we have directories for the following: Carthage Documents Extensions genetic I18N javalib jerusalem P4toP5 P5 P5-Council passivetex Roma Stylesheets Stylesheets2 TEIC TEICSS tei-emacs TEIOO TEIWORD Vesta And of course a number of ODD files in P5/Exemplars/ which are the templates provided in Roma. The question is when a new piece of software or important TEI Customisation is being created, when should it be considered part of the TEI SF repository and when should it be hosted elsewhere? One thing to bear in mind is that the TEI SF SVN repository does not give fine-grained access. If you give access to personX as a developer on it, then they have the ability to add/change/edit the whole of the TEI Guidelines and any of the software above. Currently I'm just trying to have us think about when something should be part of this repository or not, and under what circumstances we might 'adopt' things that the TEI-C itself did not create. However, I could see good arguments for making things like the Stylesheets, Roma, Vesta, TEIOO, etc. separate SF or other projects at some point in the future. Any thoughts? -James From kevin.s.hawkins at ultraslavonic.info Tue Mar 2 12:14:54 2010 From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins) Date: Tue, 02 Mar 2010 17:14:54 +0000 Subject: [tei-council] Criteria for TEI Repository Inclusion In-Reply-To: <4B8D43BA.4010302@oucs.ox.ac.uk> References: <4B8D43BA.4010302@oucs.ox.ac.uk> Message-ID: <4B8D478E.3080603@ultraslavonic.info> James, thanks for bringing up this important issue. Whether or not code is stored in SF is related to the question of what is required for a customization or other code to be maintained by the TEI-C. I think at the moment we are operating under the assumption that only code in SourceForge is maintained by the TEI-C and that in order for something to be maintained by the TEI-C, it has to be in SF. However, this need not be the case. --Kevin On 02/03/2010 16:58, James Cummings wrote: > Hi there, > > We were having a discussion recently about a TEI Customisation that we > created for the ENRICH project and its future maintenance. Although I > believe we're leaning in favour of setting up a separate Sourceforge or > Google Code repository for it and managing it separately from the TEI SF > repository, somehow 'donating' it to the TEI-C was suggested at one > point. While I frankly think it is better for such things to be managed > separately form the TEI, it made me realise that we don't seem to have a > set policy on when something (an ODD, a piece of software, etc.) gets > included in the TEI SF repository and when it doesn't. > > Currently we have directories for the following: > > Carthage > Documents > Extensions > genetic > I18N > javalib > jerusalem > P4toP5 > P5 > P5-Council > passivetex > Roma > Stylesheets > Stylesheets2 > TEIC > TEICSS > tei-emacs > TEIOO > TEIWORD > Vesta > > > And of course a number of ODD files in P5/Exemplars/ which are the > templates provided in Roma. > > The question is when a new piece of software or important TEI > Customisation is being created, when should it be considered part of the > TEI SF repository and when should it be hosted elsewhere? > > One thing to bear in mind is that the TEI SF SVN repository does not > give fine-grained access. If you give access to personX as a developer > on it, then they have the ability to add/change/edit the whole of the > TEI Guidelines and any of the software above. Currently I'm just trying > to have us think about when something should be part of this repository > or not, and under what circumstances we might 'adopt' things that the > TEI-C itself did not create. However, I could see good arguments for > making things like the Stylesheets, Roma, Vesta, TEIOO, etc. separate SF > or other projects at some point in the future. > > Any thoughts? > > -James > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council From James.Cummings at oucs.ox.ac.uk Tue Mar 2 12:15:44 2010 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Tue, 02 Mar 2010 17:15:44 +0000 Subject: [tei-council] Lists of Council Members Message-ID: <4B8D47C0.7050908@oucs.ox.ac.uk> The other day while examining Sebastian's PDF of the Guidelines for flaws I noticed the acknowledgement section. In it there is a list of council members who elected and active during the years that TEI P5 version 1.0 was created. See: http://www.tei-c.org/release/doc/tei-p5-doc/en/html/FM1.html This got me thinking about all those Council members who have contributed sometimes significantly to the Guidelines since their initial P5 publication, and that the donation of their time to the TEI isn't recorded in the Guidelines per se. There is a list of currently serving members at http://www.tei-c.org/Activities/Council/ but that as well only lists currently elected members. What I was going to suggest is that: a) there should be a publicly accessible, simple alphabetic list of who has been on Council (optionally board as well), and their associated dates, which is updated each year. b) that the Guidelines (at the bottom of the list of Council members) give a link to this with a note to the effect that ongoing maintenance has been undertaken by the TEI Council. And no, in case you're interested, I'm already in the list in the Guidelines so this isn't some way to try and shoehorn my name in, just a recognition that there are some who I know have worked hard on the Guidelines since then who aren't in that list. Food for thought, -James From julianne.nyhan at gmail.com Tue Mar 2 12:18:57 2010 From: julianne.nyhan at gmail.com (Julianne Nyhan) Date: Tue, 2 Mar 2010 18:18:57 +0100 Subject: [tei-council] Criteria for TEI Repository Inclusion In-Reply-To: <4B8D43BA.4010302@oucs.ox.ac.uk> References: <4B8D43BA.4010302@oucs.ox.ac.uk> Message-ID: <30b37191003020918g400bc1f1h660dc98d78bfc5b4@mail.gmail.com> Hi, >when a new piece of software or important TEI >Customisation is being created, when should it be considered part of the >TEI SF repository and when should it be hosted elsewhere? even if, as you say TEI-C did not create the e.g. customisation in question it seems to me that having a centralised access point for customisations could be very convenient and useful. >One thing to bear in mind is that the TEI SF SVN repository does not >give fine-grained access. If you give access to personX as a developer >on it, then they have the ability to add/change/edit the whole of the >TEI Guidelines and any of the software above. Yikes - in that case I guess it would be too risky. Is it possible to change this at all? Best, Julianne On Tue, Mar 2, 2010 at 5:58 PM, James Cummings wrote: > Hi there, > > We were having a discussion recently about a TEI Customisation that we > created for the ENRICH project and its future maintenance. Although I > believe we're leaning in favour of setting up a separate Sourceforge or > Google Code repository for it and managing it separately from the TEI SF > repository, somehow 'donating' it to the TEI-C was suggested at one > point. While I frankly think it is better for such things to be managed > separately form the TEI, it made me realise that we don't seem to have a > set policy on when something (an ODD, a piece of software, etc.) gets > included in the TEI SF repository and when it doesn't. > > Currently we have directories for the following: > > Carthage > Documents > Extensions > genetic > I18N > javalib > jerusalem > P4toP5 > P5 > P5-Council > passivetex > Roma > Stylesheets > Stylesheets2 > TEIC > TEICSS > tei-emacs > TEIOO > TEIWORD > Vesta > > > And of course a number of ODD files in P5/Exemplars/ which are the > templates provided in Roma. > > The question is when a new piece of software or important TEI > Customisation is being created, when should it be considered part of the > TEI SF repository and when should it be hosted elsewhere? > > One thing to bear in mind is that the TEI SF SVN repository does not > give fine-grained access. If you give access to personX as a developer > on it, then they have the ability to add/change/edit the whole of the > TEI Guidelines and any of the software above. Currently I'm just trying > to have us think about when something should be part of this repository > or not, and under what circumstances we might 'adopt' things that the > TEI-C itself did not create. However, I could see good arguments for > making things like the Stylesheets, Roma, Vesta, TEIOO, etc. separate SF > or other projects at some point in the future. > > Any thoughts? > > -James > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > -- Dr Julianne Nyhan, Kompetenzzentrum f?r elektronische Erschlie?ungs- und Publikationsverfahren in den Geisteswissenschaften Universit?t Trier Fachbereich II / Germanistik Universit?tsring 15 54286 Trier + 49 (0)651 201-3358 http://germazope.uni-trier.de/Projects/KoZe2/ http://epu.ucc.ie/theses/jnyhan/ http://maney.co.uk/index.php/journals/isr/ http://www.tei-c.org/Activities/SIG/Education/index.xml From julianne.nyhan at gmail.com Tue Mar 2 12:24:33 2010 From: julianne.nyhan at gmail.com (Julianne Nyhan) Date: Tue, 2 Mar 2010 18:24:33 +0100 Subject: [tei-council] Lists of Council Members In-Reply-To: <4B8D47C0.7050908@oucs.ox.ac.uk> References: <4B8D47C0.7050908@oucs.ox.ac.uk> Message-ID: <30b37191003020924q438c126cne5b9d3e4b089e190@mail.gmail.com> HI, James, I think this is a good idea. Not only is it important in terms of recognition but also from the perspective of those who want to study the history of TEI as part of e.g. a history of Digital Humanities. Best, Julianne I think this is important to do not only in terms of acknowledging the efforts of those who have given their time to TEI but also for historians, sociologists etc who want to w On Tue, Mar 2, 2010 at 6:15 PM, James Cummings wrote: > The other day while examining Sebastian's PDF of the Guidelines for > flaws I noticed the acknowledgement section. In it there is a list of > council members who elected and active during the years that TEI P5 > version 1.0 was created. See: > http://www.tei-c.org/release/doc/tei-p5-doc/en/html/FM1.html > > This got me thinking about all those Council members who have > contributed sometimes significantly to the Guidelines since their > initial P5 publication, and that the donation of their time to the TEI > isn't recorded in the Guidelines per se. There is a list of currently > serving members at http://www.tei-c.org/Activities/Council/ but that as > well only lists currently elected members. > > What I was going to suggest is that: > a) there should be a publicly accessible, simple alphabetic list of who > has been on Council (optionally board as well), and their associated > dates, which is updated each year. > b) that the Guidelines (at the bottom of the list of Council members) > give a link to this with a note to the effect that ongoing maintenance > has been undertaken by the TEI Council. > > And no, in case you're interested, I'm already in the list in the > Guidelines so this isn't some way to try and shoehorn my name in, just a > recognition that there are some who I know have worked hard on the > Guidelines since then who aren't in that list. > > Food for thought, > > -James > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > -- Dr Julianne Nyhan, Kompetenzzentrum f?r elektronische Erschlie?ungs- und Publikationsverfahren in den Geisteswissenschaften Universit?t Trier Fachbereich II / Germanistik Universit?tsring 15 54286 Trier + 49 (0)651 201-3358 http://germazope.uni-trier.de/Projects/KoZe2/ http://epu.ucc.ie/theses/jnyhan/ http://maney.co.uk/index.php/journals/isr/ http://www.tei-c.org/Activities/SIG/Education/index.xml From sebastian.rahtz at oucs.ox.ac.uk Tue Mar 2 15:05:39 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 2 Mar 2010 20:05:39 +0000 Subject: [tei-council] Lists of Council Members In-Reply-To: <4B8D47C0.7050908@oucs.ox.ac.uk> References: <4B8D47C0.7050908@oucs.ox.ac.uk> Message-ID: <7BEF4568-0E88-4DDC-96A3-6F6B51A12544@oucs.ox.ac.uk> I don't see why each release of the Guidelines should not include the latest version of the Council list. Why not just keep that file in the source up to date? -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From sebastian.rahtz at oucs.ox.ac.uk Tue Mar 2 15:10:58 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 2 Mar 2010 20:10:58 +0000 Subject: [tei-council] Criteria for TEI Repository Inclusion In-Reply-To: <30b37191003020918g400bc1f1h660dc98d78bfc5b4@mail.gmail.com> References: <4B8D43BA.4010302@oucs.ox.ac.uk> <30b37191003020918g400bc1f1h660dc98d78bfc5b4@mail.gmail.com> Message-ID: On 2 Mar 2010, at 17:18, Julianne Nyhan wrote: > even if, as you say TEI-C did not create the e.g. customisation in question > it seems to me > that having a centralised access point for customisations could be > very convenient and useful. which is not quite the same thing as having ENRICH on SF next to TEI. Having a nice new catalogue on the TEI web pages would be very sensible > >> One thing to bear in mind is that the TEI SF SVN repository does not >> give fine-grained access. If you give access to personX as a developer >> on it, then they have the ability to add/change/edit the whole of the >> TEI Guidelines and any of the software above. > > Yikes - in that case I guess it would be too risky. Is it possible to change > this at all? not that we know of. to be honest, the risk is small. everything is in a version control system, and I (at least) get an email telling me of every commit, so weirdnesses get picked up pretty quickly. If all else failed, I (or some other admin) would get back the state of last known saneness and restore over the top. -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From James.Cummings at oucs.ox.ac.uk Tue Mar 2 19:44:40 2010 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Wed, 03 Mar 2010 00:44:40 +0000 Subject: [tei-council] Criteria for TEI Repository Inclusion In-Reply-To: References: <4B8D43BA.4010302@oucs.ox.ac.uk> <30b37191003020918g400bc1f1h660dc98d78bfc5b4@mail.gmail.com> Message-ID: <4B8DB0F8.2030005@oucs.ox.ac.uk> Sebastian Rahtz wrote: > On 2 Mar 2010, at 17:18, Julianne Nyhan wrote: > >> even if, as you say TEI-C did not create the e.g. customisation in question >> it seems to me >> that having a centralised access point for customisations could be >> very convenient and useful. > > which is not quite the same thing as having ENRICH on SF next to TEI. > Having a nice new catalogue on the TEI web pages would be very sensible Should I point out that we have a place on the TEI wiki for putting customisations? i.e. you can put an ODD in a wiki page if suitable, or link to an external site. When we get the tei-enrich google code site sorted out, I will be putting a link to that on the TEI wiki. However, producing a list of them wasn't really my point, more when should TEI-C conclude that something is central enough to the TEI to store/develop/etc. as an exemplar or not. For example, the TEI Journal will I assume have a slimed down TEI ODD for its schema... is this something that the TEI-C SVN repository should contain? Or should it be hosted separately? I'm undecided on all these questions. >>> One thing to bear in mind is that the TEI SF SVN repository does not >>> give fine-grained access. If you give access to personX as a developer >>> on it, then they have the ability to add/change/edit the whole of the >>> TEI Guidelines and any of the software above. >> Yikes - in that case I guess it would be too risky. Is it possible to change >> this at all? > not that we know of. When I last looked into it, the answer was no. You can give different rights to different roles, but not assign them editing rights on one particular branch or part of the repository in the way that SF has implemented it. > to be honest, the risk is small. everything is in a version control system, > and I (at least) get an email telling me of every commit, so weirdnesses > get picked up pretty quickly. If all else failed, I (or some other > admin) would get back the state of last known saneness and restore over the top. Sure, I mean, this is the point of having a version control repository (well, one of them). But equally just from the point of view of a separation of concerns, I could easily see that having, say, Roma, as a separate SF project would make a lot of sense. But really that is getting ahead of the very first issue of what should and should not be in the TEI repository as a matter of policy. -James From laurent.romary at loria.fr Wed Mar 3 02:07:25 2010 From: laurent.romary at loria.fr (Laurent Romary) Date: Wed, 3 Mar 2010 08:07:25 +0100 Subject: [tei-council] Lists of Council Members In-Reply-To: <7BEF4568-0E88-4DDC-96A3-6F6B51A12544@oucs.ox.ac.uk> References: <4B8D47C0.7050908@oucs.ox.ac.uk> <7BEF4568-0E88-4DDC-96A3-6F6B51A12544@oucs.ox.ac.uk> Message-ID: Could not we use the same very source that is used to produce the list on the web site (should be TEI in the background?). Le 2 mars 10 ? 21:05, Sebastian Rahtz a ?crit : > I don't see why each release of the Guidelines should not include > the latest version of the Council list. Why not just keep > that file in the source up to date? > -- > Sebastian Rahtz > Information Manager, Oxford University Computing Services > 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 > > S?lo le pido a Dios > que el futuro no me sea indiferente > > > > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council From sebastian.rahtz at oucs.ox.ac.uk Wed Mar 3 03:34:29 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Wed, 3 Mar 2010 08:34:29 +0000 Subject: [tei-council] Criteria for TEI Repository Inclusion In-Reply-To: <4B8DB0F8.2030005@oucs.ox.ac.uk> References: <4B8D43BA.4010302@oucs.ox.ac.uk> <30b37191003020918g400bc1f1h660dc98d78bfc5b4@mail.gmail.com> <4B8DB0F8.2030005@oucs.ox.ac.uk> Message-ID: On 3 Mar 2010, at 00:44, James Cummings wrote: > Should I point out that we have a place on the TEI wiki for putting > customisations? no. cos wikis are not, by any stretch of the imagination, the right tool for software distribution. IMHO. -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From sebastian.rahtz at oucs.ox.ac.uk Wed Mar 3 03:36:55 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Wed, 3 Mar 2010 08:36:55 +0000 Subject: [tei-council] Lists of Council Members In-Reply-To: References: <4B8D47C0.7050908@oucs.ox.ac.uk> <7BEF4568-0E88-4DDC-96A3-6F6B51A12544@oucs.ox.ac.uk> Message-ID: <7A20D397-EF15-4FE9-85BA-E08438E8BE81@oucs.ox.ac.uk> On 3 Mar 2010, at 07:07, Laurent Romary wrote: > Could not we use the same very source that is used to produce the list > on the web site (should be TEI in the background?). sure, whichever way around one wants to do it. but until/if the web site is built from a stable version-conrolled source, the Guidelines source seems to me the obvious place to maintain the data -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From lou.burnard at oucs.ox.ac.uk Wed Mar 3 03:50:44 2010 From: lou.burnard at oucs.ox.ac.uk (Lou Burnard) Date: Wed, 03 Mar 2010 08:50:44 +0000 Subject: [tei-council] Criteria for TEI Repository Inclusion In-Reply-To: References: <4B8D43BA.4010302@oucs.ox.ac.uk> <30b37191003020918g400bc1f1h660dc98d78bfc5b4@mail.gmail.com> <4B8DB0F8.2030005@oucs.ox.ac.uk> Message-ID: <4B8E22E4.3090800@oucs.ox.ac.uk> And both Google and SF repositories come with their own wiki attached. Sebastian Rahtz wrote: > On 3 Mar 2010, at 00:44, James Cummings wrote: > >> Should I point out that we have a place on the TEI wiki for putting >> customisations? > > no. cos wikis are not, by any stretch of the imagination, > the right tool for software distribution. IMHO. > > > -- > Sebastian Rahtz > Information Manager, Oxford University Computing Services > 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 > > S?lo le pido a Dios > que el futuro no me sea indiferente > > > > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council From sebastian.rahtz at oucs.ox.ac.uk Wed Mar 3 03:51:38 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Wed, 3 Mar 2010 08:51:38 +0000 Subject: [tei-council] Criteria for TEI Repository Inclusion In-Reply-To: <4B8E22E4.3090800@oucs.ox.ac.uk> References: <4B8D43BA.4010302@oucs.ox.ac.uk> <30b37191003020918g400bc1f1h660dc98d78bfc5b4@mail.gmail.com> <4B8DB0F8.2030005@oucs.ox.ac.uk> <4B8E22E4.3090800@oucs.ox.ac.uk> Message-ID: <55940CEB-72BB-4249-B2D0-6ABBF62028FC@oucs.ox.ac.uk> On 3 Mar 2010, at 08:50, Lou Burnard wrote: > And both Google and SF repositories come with their own wiki attached. > with all due respect, that's a red herring. Google and SF have wiki software, suited for eg developing documentation. They don't supply wiki software for software distribution..... -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From lou.burnard at oucs.ox.ac.uk Wed Mar 3 03:54:55 2010 From: lou.burnard at oucs.ox.ac.uk (Lou Burnard) Date: Wed, 03 Mar 2010 08:54:55 +0000 Subject: [tei-council] Criteria for TEI Repository Inclusion In-Reply-To: References: <4B8D43BA.4010302@oucs.ox.ac.uk> <30b37191003020918g400bc1f1h660dc98d78bfc5b4@mail.gmail.com> <4B8DB0F8.2030005@oucs.ox.ac.uk> Message-ID: <4B8E23DF.9070902@oucs.ox.ac.uk> So I suppose what James meant to say was that the TEI wiki has a place for putting *information about* customisations (and links to their canonical homes if any)? Sebastian Rahtz wrote: > On 3 Mar 2010, at 00:44, James Cummings wrote: > >> Should I point out that we have a place on the TEI wiki for putting >> customisations? > > no. cos wikis are not, by any stretch of the imagination, > the right tool for software distribution. IMHO. > > > -- > Sebastian Rahtz > Information Manager, Oxford University Computing Services > 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 > > S?lo le pido a Dios > que el futuro no me sea indiferente > > > > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council From sebastian.rahtz at oucs.ox.ac.uk Wed Mar 3 03:54:59 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Wed, 3 Mar 2010 08:54:59 +0000 Subject: [tei-council] Criteria for TEI Repository Inclusion In-Reply-To: <4B8E23DF.9070902@oucs.ox.ac.uk> References: <4B8D43BA.4010302@oucs.ox.ac.uk> <30b37191003020918g400bc1f1h660dc98d78bfc5b4@mail.gmail.com> <4B8DB0F8.2030005@oucs.ox.ac.uk> <4B8E23DF.9070902@oucs.ox.ac.uk> Message-ID: <7EE15A93-D471-4752-9E1B-774CA2C05C2F@oucs.ox.ac.uk> On 3 Mar 2010, at 08:54, Lou Burnard wrote: > So I suppose what James meant to say was that the TEI wiki has a place > for putting *information about* customisations (and links to their > canonical homes if any)? yes, which is orthogonal to the question he asked about where the canonical homes should be -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From julianne.nyhan at gmail.com Wed Mar 3 05:36:12 2010 From: julianne.nyhan at gmail.com (Julianne Nyhan) Date: Wed, 3 Mar 2010 11:36:12 +0100 Subject: [tei-council] Criteria for TEI Repository Inclusion In-Reply-To: <7EE15A93-D471-4752-9E1B-774CA2C05C2F@oucs.ox.ac.uk> References: <4B8D43BA.4010302@oucs.ox.ac.uk> <30b37191003020918g400bc1f1h660dc98d78bfc5b4@mail.gmail.com> <4B8DB0F8.2030005@oucs.ox.ac.uk> <4B8E23DF.9070902@oucs.ox.ac.uk> <7EE15A93-D471-4752-9E1B-774CA2C05C2F@oucs.ox.ac.uk> Message-ID: <30b37191003030236j63d88534r88f401352fca2b6f@mail.gmail.com> Hello, >However, producing a list of them wasn't really my point, more when should TEI-C >conclude that something is central enough to the TEI to >store/develop/etc. as an exemplar or not. For example, the TEI Journal >will I assume have a slimed down TEI ODD for its schema... is this >something that the TEI-C SVN repository should contain? Or should it be >hosted separately? Right now I can see both for and against. I can see certain benefits in terms of having e.g. the TEI Journal ODD on the TEI-C SN repository (i.e. 'store/develop/etc. as an exemplar or not' ). But what extra responsibilites would such a move bring for TEI-C? Is there a possibility that the responsibilities could outweigh the benefits? Best, Julianne On Wed, Mar 3, 2010 at 9:54 AM, Sebastian Rahtz < sebastian.rahtz at oucs.ox.ac.uk> wrote: > > On 3 Mar 2010, at 08:54, Lou Burnard wrote: > > > So I suppose what James meant to say was that the TEI wiki has a place > > for putting *information about* customisations (and links to their > > canonical homes if any)? > > > > yes, which is orthogonal to the question he asked about where the canonical > homes should be > -- > Sebastian Rahtz > Information Manager, Oxford University Computing Services > 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 > > S?lo le pido a Dios > que el futuro no me sea indiferente > > > > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > -- Dr Julianne Nyhan, Kompetenzzentrum f?r elektronische Erschlie?ungs- und Publikationsverfahren in den Geisteswissenschaften Universit?t Trier Fachbereich II / Germanistik Universit?tsring 15 54286 Trier + 49 (0)651 201-3358 http://germazope.uni-trier.de/Projects/KoZe2/ http://epu.ucc.ie/theses/jnyhan/ http://maney.co.uk/index.php/journals/isr/ http://www.tei-c.org/Activities/SIG/Education/index.xml From sebastian.rahtz at oucs.ox.ac.uk Wed Mar 3 05:47:00 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Wed, 3 Mar 2010 10:47:00 +0000 Subject: [tei-council] Criteria for TEI Repository Inclusion In-Reply-To: <30b37191003030236j63d88534r88f401352fca2b6f@mail.gmail.com> References: <4B8D43BA.4010302@oucs.ox.ac.uk> <30b37191003020918g400bc1f1h660dc98d78bfc5b4@mail.gmail.com> <4B8DB0F8.2030005@oucs.ox.ac.uk> <4B8E23DF.9070902@oucs.ox.ac.uk> <7EE15A93-D471-4752-9E1B-774CA2C05C2F@oucs.ox.ac.uk> <30b37191003030236j63d88534r88f401352fca2b6f@mail.gmail.com> Message-ID: <7E6FA86C-F19B-439B-BF8C-BA9B1AA492D2@oucs.ox.ac.uk> On 3 Mar 2010, at 10:36, Julianne Nyhan wrote: > I can see certain benefits in terms of > having e.g. the TEI Journal ODD on the TEI-C SN repository (i.e. > 'store/develop/etc. as an exemplar or not' ). But what extra responsibilites > would such a move bring for TEI-C? > > Is there a possibility that the responsibilities could outweigh the > benefits? > Yes, I would say so. It would mean the TEIC having to manage the process of change over future years, and support it. So for TEI Tite, we accept thats a project of TEIC, and we know it'll be some work every year keeping it oiled and adapted, and documenting it more and more. But something like ENRICH (or Epidoc) has its own momentum and support community, and does not need or want the TEI Council to oversee its every move (as we should for Tite). If hosting projects were rare or expensive, of course the TEIC should offer it, but since we are blessed with excellent free services, I see no question but that ENRICH should float on its own, in a pool with Epidoc As for the TEI Journal customization, that depends on whether its a community project with other publishers, or specific to the TEIC -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From laurent.romary at loria.fr Wed Mar 3 06:07:18 2010 From: laurent.romary at loria.fr (Laurent Romary) Date: Wed, 3 Mar 2010 12:07:18 +0100 Subject: [tei-council] Criteria for TEI Repository Inclusion In-Reply-To: <30b37191003030236j63d88534r88f401352fca2b6f@mail.gmail.com> References: <4B8D43BA.4010302@oucs.ox.ac.uk> <30b37191003020918g400bc1f1h660dc98d78bfc5b4@mail.gmail.com> <4B8DB0F8.2030005@oucs.ox.ac.uk> <4B8E23DF.9070902@oucs.ox.ac.uk> <7EE15A93-D471-4752-9E1B-774CA2C05C2F@oucs.ox.ac.uk> <30b37191003030236j63d88534r88f401352fca2b6f@mail.gmail.com> Message-ID: <17F5E214-1D93-47D7-A211-39AF97D9C1CC@loria.fr> I don't think this would necessarily move right away any responsibility to the TEI-C. But for such a strategic project as a TEI Journal customization, we may want to clearly indicate that the TEI-C endorses this activity and possibly that the council expressed a view on this customization. As opposed to ENRICH or EPidoc, it's more a TEI internal initiative than a community activity. We may want to put this on the agenda for Dublin. Laurent Le 3 mars 10 ? 11:36, Julianne Nyhan a ?crit : > Hello, > >> However, producing a list of them wasn't really my point, more when >> should > TEI-C >> conclude that something is central enough to the TEI to >> store/develop/etc. as an exemplar or not. For example, the TEI >> Journal >> will I assume have a slimed down TEI ODD for its schema... is this >> something that the TEI-C SVN repository should contain? Or should >> it be >> hosted separately? > > Right now I can see both for and against. > > I can see certain benefits in terms of > having e.g. the TEI Journal ODD on the TEI-C SN repository (i.e. > 'store/develop/etc. as an exemplar or not' ). But what extra > responsibilites > would such a move bring for TEI-C? > > Is there a possibility that the responsibilities could outweigh the > benefits? > > Best, > Julianne > > > > > On Wed, Mar 3, 2010 at 9:54 AM, Sebastian Rahtz < > sebastian.rahtz at oucs.ox.ac.uk> wrote: > >> >> On 3 Mar 2010, at 08:54, Lou Burnard wrote: >> >>> So I suppose what James meant to say was that the TEI wiki has a >>> place >>> for putting *information about* customisations (and links to their >>> canonical homes if any)? >> >> >> >> yes, which is orthogonal to the question he asked about where the >> canonical >> homes should be >> -- >> Sebastian Rahtz >> Information Manager, Oxford University Computing Services >> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 >> >> S?lo le pido a Dios >> que el futuro no me sea indiferente >> >> >> >> >> _______________________________________________ >> tei-council mailing list >> tei-council at lists.village.Virginia.EDU >> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council >> > > > > -- > Dr Julianne Nyhan, > Kompetenzzentrum f?r elektronische Erschlie?ungs- und > Publikationsverfahren > in den Geisteswissenschaften > Universit?t Trier > Fachbereich II / Germanistik > Universit?tsring 15 > 54286 Trier > > + 49 (0)651 201-3358 > http://germazope.uni-trier.de/Projects/KoZe2/ > http://epu.ucc.ie/theses/jnyhan/ > http://maney.co.uk/index.php/journals/isr/ > http://www.tei-c.org/Activities/SIG/Education/index.xml > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council From lou.burnard at oucs.ox.ac.uk Wed Mar 3 06:17:14 2010 From: lou.burnard at oucs.ox.ac.uk (Lou) Date: Wed, 03 Mar 2010 11:17:14 +0000 Subject: [tei-council] Criteria for TEI Repository Inclusion In-Reply-To: <17F5E214-1D93-47D7-A211-39AF97D9C1CC@loria.fr> References: <4B8D43BA.4010302@oucs.ox.ac.uk> <30b37191003020918g400bc1f1h660dc98d78bfc5b4@mail.gmail.com> <4B8DB0F8.2030005@oucs.ox.ac.uk> <4B8E23DF.9070902@oucs.ox.ac.uk> <7EE15A93-D471-4752-9E1B-774CA2C05C2F@oucs.ox.ac.uk> <30b37191003030236j63d88534r88f401352fca2b6f@mail.gmail.com> <17F5E214-1D93-47D7-A211-39AF97D9C1CC@loria.fr> Message-ID: <4B8E453A.6090407@oucs.ox.ac.uk> I agree with Laurent : the Council should concern itself with developments which are strategic for the TEI as a whole -- things which enable the TEI to do its business properly. ODD itself is in that category, clearly. Light, and Tite (because of the tie-in with the membership deal which the Board has confected) are strategic because they are regarded as typical generic TEI applications by the community. By contrast there are huge numbers of TEI users (and I say it with sorrow) who are and can remain blissfully ignorant of the delights of Epidoc or Enrich. A TEI solution for digital publishing is a different matter -- possibly intermediate between the two. Most existing use cases (and there are some) seem to start from TEI Lite and tweak it a bit (or a lot) so there may well be a case for this coming into the Council's remit. I assume that it's on the brief of the Publishing SIG to work towards a proposal for a common TEI profile, which could form the basis of such a thing. Laurent Romary wrote: > I don't think this would necessarily move right away any > responsibility to the TEI-C. But for such a strategic project as a TEI > Journal customization, we may want to clearly indicate that the TEI-C > endorses this activity and possibly that the council expressed a view > on this customization. As opposed to ENRICH or EPidoc, it's more a TEI > internal initiative than a community activity. > We may want to put this on the agenda for Dublin. > Laurent > > > Le 3 mars 10 ? 11:36, Julianne Nyhan a ?crit : > >> Hello, >> >>> However, producing a list of them wasn't really my point, more when >>> should >> TEI-C >>> conclude that something is central enough to the TEI to >>> store/develop/etc. as an exemplar or not. For example, the TEI >>> Journal >>> will I assume have a slimed down TEI ODD for its schema... is this >>> something that the TEI-C SVN repository should contain? Or should >>> it be >>> hosted separately? >> Right now I can see both for and against. >> >> I can see certain benefits in terms of >> having e.g. the TEI Journal ODD on the TEI-C SN repository (i.e. >> 'store/develop/etc. as an exemplar or not' ). But what extra >> responsibilites >> would such a move bring for TEI-C? >> >> Is there a possibility that the responsibilities could outweigh the >> benefits? >> >> Best, >> Julianne >> >> >> >> >> On Wed, Mar 3, 2010 at 9:54 AM, Sebastian Rahtz < >> sebastian.rahtz at oucs.ox.ac.uk> wrote: >> >>> On 3 Mar 2010, at 08:54, Lou Burnard wrote: >>> >>>> So I suppose what James meant to say was that the TEI wiki has a >>>> place >>>> for putting *information about* customisations (and links to their >>>> canonical homes if any)? >>> >>> >>> yes, which is orthogonal to the question he asked about where the >>> canonical >>> homes should be >>> -- >>> Sebastian Rahtz >>> Information Manager, Oxford University Computing Services >>> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 >>> >>> S?lo le pido a Dios >>> que el futuro no me sea indiferente >>> >>> >>> >>> >>> _______________________________________________ >>> tei-council mailing list >>> tei-council at lists.village.Virginia.EDU >>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council >>> >> >> >> -- >> Dr Julianne Nyhan, >> Kompetenzzentrum f?r elektronische Erschlie?ungs- und >> Publikationsverfahren >> in den Geisteswissenschaften >> Universit?t Trier >> Fachbereich II / Germanistik >> Universit?tsring 15 >> 54286 Trier >> >> + 49 (0)651 201-3358 >> http://germazope.uni-trier.de/Projects/KoZe2/ >> http://epu.ucc.ie/theses/jnyhan/ >> http://maney.co.uk/index.php/journals/isr/ >> http://www.tei-c.org/Activities/SIG/Education/index.xml >> _______________________________________________ >> tei-council mailing list >> tei-council at lists.village.Virginia.EDU >> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council From James.Cummings at oucs.ox.ac.uk Wed Mar 3 06:25:36 2010 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Wed, 03 Mar 2010 11:25:36 +0000 Subject: [tei-council] Criteria for TEI Repository Inclusion In-Reply-To: References: <4B8D43BA.4010302@oucs.ox.ac.uk> <30b37191003020918g400bc1f1h660dc98d78bfc5b4@mail.gmail.com> <4B8DB0F8.2030005@oucs.ox.ac.uk> Message-ID: <4B8E4730.4000504@oucs.ox.ac.uk> Sebastian Rahtz wrote: > On 3 Mar 2010, at 00:44, James Cummings wrote: > >> Should I point out that we have a place on the TEI wiki for putting >> customisations? > > no. cos wikis are not, by any stretch of the imagination, > the right tool for software distribution. IMHO. ODDs are not software, they are documentation and meta-schema. -James From sebastian.rahtz at oucs.ox.ac.uk Wed Mar 3 06:30:07 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Wed, 3 Mar 2010 11:30:07 +0000 Subject: [tei-council] Criteria for TEI Repository Inclusion In-Reply-To: <4B8E4730.4000504@oucs.ox.ac.uk> References: <4B8D43BA.4010302@oucs.ox.ac.uk> <30b37191003020918g400bc1f1h660dc98d78bfc5b4@mail.gmail.com> <4B8DB0F8.2030005@oucs.ox.ac.uk> <4B8E4730.4000504@oucs.ox.ac.uk> Message-ID: <65C846E8-8D4F-45AB-955E-08292E8ACCBF@oucs.ox.ac.uk> On 3 Mar 2010, at 11:25, James Cummings wrote: >> >> no. cos wikis are not, by any stretch of the imagination, >> the right tool for software distribution. IMHO. > > ODDs are not software, they are documentation and meta-schema. they are so software! .... is a specification of a task in a computer language, which an appropriate processor will act upon. you only count software as code in which you can write a turing machine? -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From James.Cummings at oucs.ox.ac.uk Wed Mar 3 06:36:36 2010 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Wed, 03 Mar 2010 11:36:36 +0000 Subject: [tei-council] Criteria for TEI Repository Inclusion In-Reply-To: <4B8E23DF.9070902@oucs.ox.ac.uk> References: <4B8D43BA.4010302@oucs.ox.ac.uk> <30b37191003020918g400bc1f1h660dc98d78bfc5b4@mail.gmail.com> <4B8DB0F8.2030005@oucs.ox.ac.uk> <4B8E23DF.9070902@oucs.ox.ac.uk> Message-ID: <4B8E49C4.30504@oucs.ox.ac.uk> Lou Burnard wrote: > So I suppose what James meant to say was that the TEI wiki has a place > for putting *information about* customisations (and links to their > canonical homes if any)? Well and indeed I said: "When we get the tei-enrich google code site sorted out, I will be putting a link to that on the TEI wiki" as an example of this. But I still disagree with Sebastian's central assumption. While I'm not suggesting that ODDs should really be managed in a wiki, or that this is the best technology to use, it is plainly not the case that ODDs are software. Yes, we can use software-tools to manage them and there is nothing wrong with that, but ODDs as meta-schema and documentation especially when being collaboratively authored might benefit from collaborative authoring tools, like say wikis. Alternatively, when an ODD reaches a certain stability I see no problem having it in a wiki page with accompanying documentation about how to use it and why it was made. It is just one tool in the toolbox. -James >> no. cos wikis are not, by any stretch of the imagination, >> the right tool for software distribution. IMHO. From sebastian.rahtz at oucs.ox.ac.uk Wed Mar 3 06:43:26 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Wed, 3 Mar 2010 11:43:26 +0000 Subject: [tei-council] Criteria for TEI Repository Inclusion In-Reply-To: <4B8E49C4.30504@oucs.ox.ac.uk> References: <4B8D43BA.4010302@oucs.ox.ac.uk> <30b37191003020918g400bc1f1h660dc98d78bfc5b4@mail.gmail.com> <4B8DB0F8.2030005@oucs.ox.ac.uk> <4B8E23DF.9070902@oucs.ox.ac.uk> <4B8E49C4.30504@oucs.ox.ac.uk> Message-ID: On 3 Mar 2010, at 11:36, James Cummings wrote: > case that ODDs are software. Yes, we can use software-tools to > manage them and there is nothing wrong with that, but ODDs as > meta-schema and documentation especially when being > collaboratively authored might benefit from collaborative > authoring tools, like say wikis. Alternatively, when an ODD > reaches a certain stability I see no problem having it in a wiki > page with accompanying documentation about how to use it and why > it was made. It is just one tool in the toolbox. > Your arguments apply just as much, or not, to eg Javascript code or Python programs. Whether a wiki is the right place to manage .xml or .py has no relation to whether its doc or code - its structured computer language. Our TEI wiki is a pretty low-class primitive CMS, designed for looking after _documents_. It groks a particular document markup language, and does it well, which is why we use it for collaborative editing. It does not grok arbitrary XML (or JS, or Python, or PHP), which makes it an unsuitable container for collaborative editing of that type of content. If wikimedia was a higher class of document repository like (god help us) Sharepoint, then I might be be convinced. But its non-text management is grotesquely primitive. IMHO. -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From James.Cummings at oucs.ox.ac.uk Wed Mar 3 06:44:53 2010 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Wed, 03 Mar 2010 11:44:53 +0000 Subject: [tei-council] Criteria for TEI Repository Inclusion In-Reply-To: <65C846E8-8D4F-45AB-955E-08292E8ACCBF@oucs.ox.ac.uk> References: <4B8D43BA.4010302@oucs.ox.ac.uk> <30b37191003020918g400bc1f1h660dc98d78bfc5b4@mail.gmail.com> <4B8DB0F8.2030005@oucs.ox.ac.uk> <4B8E4730.4000504@oucs.ox.ac.uk> <65C846E8-8D4F-45AB-955E-08292E8ACCBF@oucs.ox.ac.uk> Message-ID: <4B8E4BB5.3010707@oucs.ox.ac.uk> Sebastian Rahtz wrote: > On 3 Mar 2010, at 11:25, James Cummings wrote: > >>> no. cos wikis are not, by any stretch of the imagination, >>> the right tool for software distribution. IMHO. >> ODDs are not software, they are documentation and meta-schema. > they are so software! > > is a specification of a task in a computer language, which an > appropriate processor will act upon. We'll have to agree to differ here, to me a schema is not software, but the thing processing the schema is software. It is simply a configuration file or documentation file. I'll assume we're just using different definitions. But I think this theoretical distinction isn't actually germane to the problem we're discussing. > you only count software as code in which you can write a turing > machine? No, I believe no such thing. Plenty of software is not turing-complete. In my mind an ODD is not software because the ODD doesn't *do* anything, simply documents the rules by which something (validation perhaps) could be done. The ODD/schema processor is software because it takes this configuration file and does something with it. I'm sure I'm not the only one who makes a distinction between files which do something (whether text-based scripts or not) and files which are just inputs to those. But again, this isn't getting us anywhere. -James From laurent.romary at loria.fr Wed Mar 3 06:44:59 2010 From: laurent.romary at loria.fr (Laurent Romary) Date: Wed, 3 Mar 2010 12:44:59 +0100 Subject: [tei-council] Criteria for TEI Repository Inclusion In-Reply-To: <4B8E49C4.30504@oucs.ox.ac.uk> References: <4B8D43BA.4010302@oucs.ox.ac.uk> <30b37191003020918g400bc1f1h660dc98d78bfc5b4@mail.gmail.com> <4B8DB0F8.2030005@oucs.ox.ac.uk> <4B8E23DF.9070902@oucs.ox.ac.uk> <4B8E49C4.30504@oucs.ox.ac.uk> Message-ID: <996A8703-FFF3-445E-A887-9EF191135D29@loria.fr> I would second Sebastian here. While I would not enter the debate of whether an ODD spec is a piece of software or not, I can identify that we need some functionalities such as: - version management - compilation (to generate the documentation and schemas) - online dissemination That are very close to what we do with any other piece of code. The notion of "stability" for an ODD spec is to my view to difficult to grasp to imagine being able to put a link to such version in a TEI wiki page. Laurent Le 3 mars 10 ? 12:36, James Cummings a ?crit : > Lou Burnard wrote: >> So I suppose what James meant to say was that the TEI wiki has a >> place >> for putting *information about* customisations (and links to their >> canonical homes if any)? > > Well and indeed I said: "When we get the tei-enrich google code > site sorted out, I will be putting a link to that on the TEI > wiki" as an example of this. > > But I still disagree with Sebastian's central assumption. While > I'm not suggesting that ODDs should really be managed in a wiki, > or that this is the best technology to use, it is plainly not the > case that ODDs are software. Yes, we can use software-tools to > manage them and there is nothing wrong with that, but ODDs as > meta-schema and documentation especially when being > collaboratively authored might benefit from collaborative > authoring tools, like say wikis. Alternatively, when an ODD > reaches a certain stability I see no problem having it in a wiki > page with accompanying documentation about how to use it and why > it was made. It is just one tool in the toolbox. > > -James > >>> no. cos wikis are not, by any stretch of the imagination, >>> the right tool for software distribution. IMHO. > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council From James.Cummings at oucs.ox.ac.uk Wed Mar 3 06:50:28 2010 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Wed, 03 Mar 2010 11:50:28 +0000 Subject: [tei-council] Criteria for TEI Repository Inclusion In-Reply-To: References: <4B8D43BA.4010302@oucs.ox.ac.uk> <30b37191003020918g400bc1f1h660dc98d78bfc5b4@mail.gmail.com> <4B8DB0F8.2030005@oucs.ox.ac.uk> <4B8E23DF.9070902@oucs.ox.ac.uk> <4B8E49C4.30504@oucs.ox.ac.uk> Message-ID: <4B8E4D04.4090809@oucs.ox.ac.uk> Sebastian Rahtz wrote: > On 3 Mar 2010, at 11:36, James Cummings wrote: > Your arguments apply just as much, or not, to eg Javascript > code or Python programs. Whether a wiki is the right place > to manage .xml or .py has no relation to whether its doc or code - > its structured computer language. Yes, many of which you can cut and paste from wikis around the web. ;-) You were the one claiming that wikis were bad because it wasn't for software... all I'm saying is a) ODDs aren't software applications and b) we have a place on the TEI wiki where you can document customisations (whether you include a copy of it or not). > Our TEI wiki is a pretty low-class primitive CMS, designed > for looking after _documents_. It groks a particular > document markup language, and does it well, which > is why we use it for collaborative editing. It does not grok > arbitrary XML (or JS, or Python, or PHP), which makes > it an unsuitable container for collaborative editing of that > type of content. Yes, but it has also been fairly well used for putting one-off XSLT scripts there as well because the TEI provides no other centralised place to put community-contributed stylesheets. This comes back really to the heart of what I was trying to get at... that TEI-C needs a defined policy of when it adopts community-created *stuff* (ODDs, Software, Whatever). Another answer to this is to say there is no policy, but create some repository specifically for community-created *stuff*. > If wikimedia was a higher class of document repository > like (god help us) Sharepoint, then I might be be convinced. > But its non-text management is grotesquely primitive. I don't disagree with that. -James From sebastian.rahtz at oucs.ox.ac.uk Wed Mar 3 06:59:40 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Wed, 3 Mar 2010 11:59:40 +0000 Subject: [tei-council] Criteria for TEI Repository Inclusion In-Reply-To: <4B8E4D04.4090809@oucs.ox.ac.uk> References: <4B8D43BA.4010302@oucs.ox.ac.uk> <30b37191003020918g400bc1f1h660dc98d78bfc5b4@mail.gmail.com> <4B8DB0F8.2030005@oucs.ox.ac.uk> <4B8E23DF.9070902@oucs.ox.ac.uk> <4B8E49C4.30504@oucs.ox.ac.uk> <4B8E4D04.4090809@oucs.ox.ac.uk> Message-ID: <395077AF-6BBA-4580-82C0-030D2593637C@oucs.ox.ac.uk> On 3 Mar 2010, at 11:50, James Cummings wrote: > Yes, but it has also been fairly well used for putting one-off > XSLT scripts there as well because the TEI provides no other > centralised place to put community-contributed stylesheets. I would question your use of "well used". Yes, there is a representation of code there, which one has to painfully copy and paste (from memory), but we have done no analysis of any kind on whether it is effective, appreciated, or has had any impact. It might well be/have had, but we don't know. But my hatred of wikis makes me digress, sorry :-} > This > comes back really to the heart of what I was trying to get at... > that TEI-C needs a defined policy of when it adopts > community-created *stuff* (ODDs, Software, Whatever). agreed. and whether its "adopt yes/no" or "adopt entirely / manage development of / just provide space for" > Another > answer to this is to say there is no policy, but create some > repository specifically for community-created *stuff*. do you think, being serious now, that the barriers to SF and Google Code are too high for the casual user? or can we just set up a "TEI contrib" project? I'd say that an unmanaged project is doomed to failure, and that we (TEI Council) cannot justify time spent on management from our very limited budget -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From James.Cummings at oucs.ox.ac.uk Wed Mar 3 07:21:52 2010 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Wed, 03 Mar 2010 12:21:52 +0000 Subject: [tei-council] Criteria for TEI Repository Inclusion In-Reply-To: <395077AF-6BBA-4580-82C0-030D2593637C@oucs.ox.ac.uk> References: <4B8D43BA.4010302@oucs.ox.ac.uk> <30b37191003020918g400bc1f1h660dc98d78bfc5b4@mail.gmail.com> <4B8DB0F8.2030005@oucs.ox.ac.uk> <4B8E23DF.9070902@oucs.ox.ac.uk> <4B8E49C4.30504@oucs.ox.ac.uk> <4B8E4D04.4090809@oucs.ox.ac.uk> <395077AF-6BBA-4580-82C0-030D2593637C@oucs.ox.ac.uk> Message-ID: <4B8E5460.6020207@oucs.ox.ac.uk> Sebastian Rahtz wrote: > I would question your use of "well used". Yes, there is a representation of code > there, which one has to painfully copy and paste (from memory), but > we have done no analysis of any kind on whether it is effective, > appreciated, or has had any impact. It might well be/have had, but > we don't know. That's probably fair. > But my hatred of wikis makes me digress, sorry :-} They aren't ideal for many things, even what they were designed for, but some people like them. > agreed. and whether its "adopt yes/no" > or "adopt entirely / manage development of / just provide space for" Yes, the latter is really the question. We do the first two in SF SVN and (for what it's worth) the last of these on the TEI wiki. > do you think, being serious now, that the barriers to SF and Google Code > are too high for the casual user? or can we just set up a "TEI contrib" project? > I'd say that an unmanaged project is doomed to failure, and that > we (TEI Council) cannot justify time spent on management from our > very limited budget The problem is, as you say, ongoing management. Even if we just had a contrib/ directory in subversion, when groupA had a new version of their nifty 'script to tell you what's changed in the TEI since you first made your ODD', then someone would have to get the released file and put it into that directory etc. This also, of course, loses the benefit of version control. How do other projects manage this sort of contribution? Some software I use has plugins and such that are distributed along with the software and these are available from the equivalent of a contrib/ directory in the SF SVN repository... I wonder if they just give access to loads of people or have a developer whose job it is to keep those up to date. As a thought experiment, what are the arguments against having a contrib/ dir and giving one developer from each project in there developer access on the subversion repository? Extra time spent reverting their changes to the main TEI source? Some form of legitimisation of their dodgy code as reflecting the TEI? Just thinking out loud, apologies. -James From sebastian.rahtz at oucs.ox.ac.uk Wed Mar 3 07:42:48 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Wed, 3 Mar 2010 12:42:48 +0000 Subject: [tei-council] Criteria for TEI Repository Inclusion In-Reply-To: <4B8E5460.6020207@oucs.ox.ac.uk> References: <4B8D43BA.4010302@oucs.ox.ac.uk> <30b37191003020918g400bc1f1h660dc98d78bfc5b4@mail.gmail.com> <4B8DB0F8.2030005@oucs.ox.ac.uk> <4B8E23DF.9070902@oucs.ox.ac.uk> <4B8E49C4.30504@oucs.ox.ac.uk> <4B8E4D04.4090809@oucs.ox.ac.uk> <395077AF-6BBA-4580-82C0-030D2593637C@oucs.ox.ac.uk> <4B8E5460.6020207@oucs.ox.ac.uk> Message-ID: <3EECD107-3C91-465D-BA8E-4161593190A9@oucs.ox.ac.uk> On 3 Mar 2010, at 12:21, James Cummings wrote: > also, of course, loses the benefit of version control. How do > other projects manage this sort of contribution? every different way you can conceive I spent 15 years of my life herding these cats for the TeX community, where you have a core product and a million addons of all levels, and I am not seeing any real change in the attitudes, needs and solutions. > As a thought experiment, what > are the arguments against having a contrib/ dir and giving one > developer from each project in there developer access on the > subversion repository? > > Extra time spent reverting their changes to the main TEI source? > Some form of legitimisation of their dodgy code as reflecting > the TEI? yes, precisely those. when the author goes AWOL, people expect TEI-C to pick up the pieces and support the project. They complain if it does not work, to us. We all know the inability of most folk to differentiate core from addons when they find a problem in something. I don't think there is any one-answer-fits-all solution. People and their "software" vary hugely, both in themselves and over time. We do know roughly the boundaries, by using our exemplars of * Tite (close to our hearts) * Epidoc (far away, own very capable community) * TEIJ (in between) for the last, I think we start by cultivating it inhouse and then branching it off when it grows some legs (i _lurv_ mixed metaphor) -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From mholmes at uvic.ca Wed Mar 3 08:42:04 2010 From: mholmes at uvic.ca (Martin Holmes) Date: Wed, 03 Mar 2010 05:42:04 -0800 Subject: [tei-council] Criteria for TEI Repository Inclusion In-Reply-To: <30b37191003030236j63d88534r88f401352fca2b6f@mail.gmail.com> References: <4B8D43BA.4010302@oucs.ox.ac.uk> <30b37191003020918g400bc1f1h660dc98d78bfc5b4@mail.gmail.com> <4B8DB0F8.2030005@oucs.ox.ac.uk> <4B8E23DF.9070902@oucs.ox.ac.uk> <7EE15A93-D471-4752-9E1B-774CA2C05C2F@oucs.ox.ac.uk> <30b37191003030236j63d88534r88f401352fca2b6f@mail.gmail.com> Message-ID: <4B8E672C.40602@uvic.ca> Hi all, My feeling is that the only subprojects that should end up on the TEI SF site are ones which are sponsored/maintained by an official SIG. If the SIG disbands or becomes moribund (no activity for a year, say), then the customization should be moved to an archive area as soon as a problem appears with it (for instance, if an update to TEI breaks something in the customization, or a bug emerges that no-one is willing to fix). Cheers, Martin Julianne Nyhan wrote: > Hello, > >> However, producing a list of them wasn't really my point, more when should > TEI-C >> conclude that something is central enough to the TEI to >> store/develop/etc. as an exemplar or not. For example, the TEI Journal >> will I assume have a slimed down TEI ODD for its schema... is this >> something that the TEI-C SVN repository should contain? Or should it be >> hosted separately? > > Right now I can see both for and against. > > I can see certain benefits in terms of > having e.g. the TEI Journal ODD on the TEI-C SN repository (i.e. > 'store/develop/etc. as an exemplar or not' ). But what extra responsibilites > would such a move bring for TEI-C? > > Is there a possibility that the responsibilities could outweigh the > benefits? > > Best, > Julianne > > > > > On Wed, Mar 3, 2010 at 9:54 AM, Sebastian Rahtz < > sebastian.rahtz at oucs.ox.ac.uk> wrote: > >> On 3 Mar 2010, at 08:54, Lou Burnard wrote: >> >>> So I suppose what James meant to say was that the TEI wiki has a place >>> for putting *information about* customisations (and links to their >>> canonical homes if any)? >> >> >> yes, which is orthogonal to the question he asked about where the canonical >> homes should be >> -- >> Sebastian Rahtz >> Information Manager, Oxford University Computing Services >> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 >> >> S?lo le pido a Dios >> que el futuro no me sea indiferente >> >> >> >> >> _______________________________________________ >> tei-council mailing list >> tei-council at lists.village.Virginia.EDU >> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council >> > > > From James.Cummings at oucs.ox.ac.uk Wed Mar 3 08:52:08 2010 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Wed, 03 Mar 2010 13:52:08 +0000 Subject: [tei-council] Criteria for TEI Repository Inclusion In-Reply-To: <3EECD107-3C91-465D-BA8E-4161593190A9@oucs.ox.ac.uk> References: <4B8D43BA.4010302@oucs.ox.ac.uk> <30b37191003020918g400bc1f1h660dc98d78bfc5b4@mail.gmail.com> <4B8DB0F8.2030005@oucs.ox.ac.uk> <4B8E23DF.9070902@oucs.ox.ac.uk> <4B8E49C4.30504@oucs.ox.ac.uk> <4B8E4D04.4090809@oucs.ox.ac.uk> <395077AF-6BBA-4580-82C0-030D2593637C@oucs.ox.ac.uk> <4B8E5460.6020207@oucs.ox.ac.uk> <3EECD107-3C91-465D-BA8E-4161593190A9@oucs.ox.ac.uk> Message-ID: <4B8E6988.50208@oucs.ox.ac.uk> Sebastian Rahtz wrote: > I don't think there is any one-answer-fits-all solution. People and their > "software" vary hugely, both in themselves and over time. We > do know roughly the boundaries, by using our exemplars of > > * Tite (close to our hearts) > * Epidoc (far away, own very capable community) > * TEIJ (in between) > > for the last, I think we start by cultivating it inhouse and then branching > it off when it grows some legs (i _lurv_ mixed metaphor) I think that seems quite reasonable as a vague policy myself. But if EpiDoc was just starting out, would we then include it and only kick it out when it got mature enough to stand on its own three feet? What about something like the genetic editing material? We have a directory called genetic/ where some of those working on genetic editing (as a sub-group of the TEI-MS SIG originally) have some work in progress which will eventually come before the council. Now in this case it is probably there because various members of the council/board are involved in this completely worthwhile endeavour, and it just seemed like a convenient place to store it. But why isn't there one fr work happening in scholarly journals, correspondence, or other SIG activities? (It isn't that I object to the genetic being there, just that it seems potentially incongruous or confusing to others). If we are thinking about how/when we include/exclude stuff, where does general SIG working materials/testfiles/examples fall? -James From James.Cummings at oucs.ox.ac.uk Wed Mar 3 08:53:25 2010 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Wed, 03 Mar 2010 13:53:25 +0000 Subject: [tei-council] Criteria for TEI Repository Inclusion In-Reply-To: <4B8E672C.40602@uvic.ca> References: <4B8D43BA.4010302@oucs.ox.ac.uk> <30b37191003020918g400bc1f1h660dc98d78bfc5b4@mail.gmail.com> <4B8DB0F8.2030005@oucs.ox.ac.uk> <4B8E23DF.9070902@oucs.ox.ac.uk> <7EE15A93-D471-4752-9E1B-774CA2C05C2F@oucs.ox.ac.uk> <30b37191003030236j63d88534r88f401352fca2b6f@mail.gmail.com> <4B8E672C.40602@uvic.ca> Message-ID: <4B8E69D5.509@oucs.ox.ac.uk> Martin Holmes wrote: > My feeling is that the only subprojects that should end up on the TEI SF > site are ones which are sponsored/maintained by an official SIG. If the > SIG disbands or becomes moribund (no activity for a year, say), then the > customization should be moved to an archive area as soon as a problem > appears with it (for instance, if an update to TEI breaks something in > the customization, or a bug emerges that no-one is willing to fix). Would another option be to have a separate repository for TEI-SIG (i.e. contrib of a specialised sort) and have it administered by the SIG coordinator? -James From laurent.romary at loria.fr Wed Mar 3 09:03:49 2010 From: laurent.romary at loria.fr (Laurent Romary) Date: Wed, 3 Mar 2010 15:03:49 +0100 Subject: [tei-council] Criteria for TEI Repository Inclusion In-Reply-To: <4B8E69D5.509@oucs.ox.ac.uk> References: <4B8D43BA.4010302@oucs.ox.ac.uk> <30b37191003020918g400bc1f1h660dc98d78bfc5b4@mail.gmail.com> <4B8DB0F8.2030005@oucs.ox.ac.uk> <4B8E23DF.9070902@oucs.ox.ac.uk> <7EE15A93-D471-4752-9E1B-774CA2C05C2F@oucs.ox.ac.uk> <30b37191003030236j63d88534r88f401352fca2b6f@mail.gmail.com> <4B8E672C.40602@uvic.ca> <4B8E69D5.509@oucs.ox.ac.uk> Message-ID: Do rember that whatever we discuss here, the result has to be transparent for our users. Let me restate the policy statement I made a long time ago: we should avoid fragmented our technical tools... Le 3 mars 10 ? 14:53, James Cummings a ?crit : > Martin Holmes wrote: >> My feeling is that the only subprojects that should end up on the >> TEI SF >> site are ones which are sponsored/maintained by an official SIG. If >> the >> SIG disbands or becomes moribund (no activity for a year, say), >> then the >> customization should be moved to an archive area as soon as a problem >> appears with it (for instance, if an update to TEI breaks something >> in >> the customization, or a bug emerges that no-one is willing to fix). > > Would another option be to have a separate repository for TEI-SIG > (i.e. contrib of a specialised sort) and have it administered by > the SIG coordinator? > > -James > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council From sebastian.rahtz at oucs.ox.ac.uk Wed Mar 3 09:04:06 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Wed, 3 Mar 2010 14:04:06 +0000 Subject: [tei-council] Criteria for TEI Repository Inclusion In-Reply-To: <4B8E6988.50208@oucs.ox.ac.uk> References: <4B8D43BA.4010302@oucs.ox.ac.uk> <30b37191003020918g400bc1f1h660dc98d78bfc5b4@mail.gmail.com> <4B8DB0F8.2030005@oucs.ox.ac.uk> <4B8E23DF.9070902@oucs.ox.ac.uk> <4B8E49C4.30504@oucs.ox.ac.uk> <4B8E4D04.4090809@oucs.ox.ac.uk> <395077AF-6BBA-4580-82C0-030D2593637C@oucs.ox.ac.uk> <4B8E5460.6020207@oucs.ox.ac.uk> <3EECD107-3C91-465D-BA8E-4161593190A9@oucs.ox.ac.uk> <4B8E6988.50208@oucs.ox.ac.uk> Message-ID: <1A6259D1-B8EB-4C0B-BF11-E8AB34C993BB@oucs.ox.ac.uk> On 3 Mar 2010, at 13:52, James Cummings wrote: > > What about something like the genetic editing material? We have > a directory called genetic/ where some of those working on > genetic editing (as a sub-group of the TEI-MS SIG originally) > have some work in progress which will eventually come before the > council. that one is a bit different, and a mess, as its partly a drafting of a new chapter, but also creating a Tite-like documented Exemplar. I suspect it will end up splitting apart. I _think_ I would actually go now for breaking apart the TEI SF monolith, using it just for the Guidelines sources. Then create a new "tei-tools" for Roma, Stylesheets, Emacs, OOTEI, etc, which could also be a home for exemplars and incubation projects like genetics whose future is unsure. Big secure projects like Epidoc remain in their own place, of course. The status of "tei-tools" would be that it was managed by TEI-C as a service, but that its contents were not as official as "tei" why don't we just do this? basically because my heart fails at the the thought of all the work involved of breaking apart and migrating the Subversion repos. It would a lot of very careful donkey labour, and I don't want to do it. -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From lou.burnard at oucs.ox.ac.uk Wed Mar 3 09:09:08 2010 From: lou.burnard at oucs.ox.ac.uk (Lou) Date: Wed, 03 Mar 2010 14:09:08 +0000 Subject: [tei-council] Criteria for TEI Repository Inclusion In-Reply-To: <1A6259D1-B8EB-4C0B-BF11-E8AB34C993BB@oucs.ox.ac.uk> References: <4B8D43BA.4010302@oucs.ox.ac.uk> <30b37191003020918g400bc1f1h660dc98d78bfc5b4@mail.gmail.com> <4B8DB0F8.2030005@oucs.ox.ac.uk> <4B8E23DF.9070902@oucs.ox.ac.uk> <4B8E49C4.30504@oucs.ox.ac.uk> <4B8E4D04.4090809@oucs.ox.ac.uk> <395077AF-6BBA-4580-82C0-030D2593637C@oucs.ox.ac.uk> <4B8E5460.6020207@oucs.ox.ac.uk> <3EECD107-3C91-465D-BA8E-4161593190A9@oucs.ox.ac.uk> <4B8E6988.50208@oucs.ox.ac.uk> <1A6259D1-B8EB-4C0B-BF11-E8AB34C993BB@oucs.ox.ac.uk> Message-ID: <4B8E6D84.9010603@oucs.ox.ac.uk> Sebastian Rahtz wrote: > On 3 Mar 2010, at 13:52, James Cummings wrote: > >> What about something like the genetic editing material? We have >> a directory called genetic/ where some of those working on >> genetic editing (as a sub-group of the TEI-MS SIG originally) >> have some work in progress which will eventually come before the >> council. > > that one is a bit different, and a mess, as its partly a drafting of a new chapter, > but also creating a Tite-like documented Exemplar. I suspect it will end > up splitting apart. > > I _think_ I would actually go now for breaking apart the TEI SF monolith, > using it just for the Guidelines sources. Then create a new "tei-tools" > for Roma, Stylesheets, Emacs, OOTEI, etc, which could also be a home > for exemplars and incubation projects like genetics whose future is > unsure. Big secure projects like Epidoc remain in their own place, > of course. The status of "tei-tools" would be that it was managed by TEI-C > as a service, but that its contents were not as official as "tei" > > why don't we just do this? basically because my heart fails at the the thought > of all the work involved of breaking apart and migrating the Subversion > repos. It would a lot of very careful donkey labour, and I don't want to do it. > -- While I am sure it's not too hard to find a careful donkey, I'm not convinced that this fragmentation would buy us much. We'd still have to decide whether or not new project x was worthy of going into "tei-tools" or not. From mholmes at uvic.ca Wed Mar 3 11:23:55 2010 From: mholmes at uvic.ca (Martin Holmes) Date: Wed, 3 Mar 2010 08:23:55 -0800 Subject: [tei-council] Criteria for TEI Repository Inclusion In-Reply-To: <4B8E69D5.509@oucs.ox.ac.uk> References: <4B8D43BA.4010302@oucs.ox.ac.uk> <30b37191003020918g400bc1f1h660dc98d78bfc5b4@mail.gmail.com> <4B8DB0F8.2030005@oucs.ox.ac.uk> <4B8E23DF.9070902@oucs.ox.ac.uk> <7EE15A93-D471-4752-9E1B-774CA2C05C2F@oucs.ox.ac.uk> <30b37191003030236j63d88534r88f401352fca2b6f@mail.gmail.com> <4B8E672C.40602@uvic.ca> <4B8E69D5.509@oucs.ox.ac.uk> Message-ID: <4B8E8D1B.40806@uvic.ca> James Cummings wrote: > Martin Holmes wrote: >> My feeling is that the only subprojects that should end up on the TEI SF >> site are ones which are sponsored/maintained by an official SIG. If the >> SIG disbands or becomes moribund (no activity for a year, say), then the >> customization should be moved to an archive area as soon as a problem >> appears with it (for instance, if an update to TEI breaks something in >> the customization, or a bug emerges that no-one is willing to fix). > > Would another option be to have a separate repository for TEI-SIG > (i.e. contrib of a specialised sort) and have it administered by > the SIG coordinator? That makes sense to me. The main thing we want to avoid is to be seen to be endorsing customizations over which we have no control, in which we have no interest, or which no-one is competent to update or fix. Anything in SF has the implicit blessing of the TEI, and users who adopt such customizations may have a reasonable expectation that the Council or TEI-L will provide some help and support for them. If that's not the case, then we'll end up confusing and disappointing users, and that's not good for anyone. I also like the idea of attaching someone's name to each contribution in a separate repository. The SIG coordinator is a good option. If the person responsible later repudiates the responsibility, and no-one steps up to take it over, then it's reasonable to move it into a different type of archive. Cheers, Martin -- Martin Holmes University of Victoria Humanities Computing and Media Centre (mholmes at uvic.ca) Half-Baked Software, Inc. (mholmes at halfbakedsoftware.com) martin at mholmes.com From sebastian.rahtz at oucs.ox.ac.uk Wed Mar 3 16:20:19 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Wed, 3 Mar 2010 21:20:19 +0000 Subject: [tei-council] a proposal for a change to ODD (copy of ticket I just put in SF) Message-ID: [from a discussion with Lou and James earlier today] Currently, we say things in an ODD like which works fine to get the subset of elements we want. But that has the side effect that when the TEI adds to the module, it pops up when we next compile our ODD, and our schema has changed. We need a way to say exactly what we _do_ want, not what we _don't_ want. I therefore propose 3 new elements, , and , which have same attributes as , and dictate which elements are to be appear in the output schema. No other elements can creep in in future. Similarly, I explicitly say what attribute classes I want (I am not quite so sure about macros), apart from att.global. The result is much less likelihood of surprises at future releases. New attributes _will_ pop up sometimes, but I think that's bearable. Yes, its may be a pig to implement, but I claim the semantics are fairly clear. As an alternative, if you dont like <*Ref>, we could add an attribute "copyOf" to <*Spec>, with the same effect. I believe that there is real demand for this (Tite is an excellent example of a project which badly needs no surprises at TEI version changes), that it is doable, and that it does not mean a rethink of ODD. (it would help to discuss this in public on the SF ticket: https://sourceforge.net/tracker/?func=detail&aid=2962880&group_id=106328&atid=644065) -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From James.Cummings at oucs.ox.ac.uk Wed Mar 3 19:22:37 2010 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Thu, 04 Mar 2010 00:22:37 +0000 Subject: [tei-council] a proposal for a change to ODD (copy of ticket I just put in SF) In-Reply-To: References: Message-ID: <4B8EFD4D.1050003@oucs.ox.ac.uk> Sebastian Rahtz wrote: > surprises at future releases. New attributes _will_ pop up sometimes, but I think that's bearable. And of course content models and class memberships might change as well...but of course that is true at the moment. > As an alternative, if you dont like <*Ref>, we could add an attribute "copyOf" to <*Spec>, with the > same effect. I prefer your initial suggestion. > I believe that there is real demand for this (Tite is an excellent example > of a project which badly needs no surprises at TEI version changes), > that it is doable, and that it does not mean a rethink of ODD. I think all of those are good points. Though with the last I would hope that this would fit in with any changes we do make to ODD eventually. (but of course we can't predict that?) I've been trying to think of flaws with this setup which would cause problems. The only anxiousness I have is something to do with what it means for processing if an ODD seems to be using both inherited and explicit models simultaneously. -James From gabriel.bodard at kcl.ac.uk Thu Mar 4 10:44:30 2010 From: gabriel.bodard at kcl.ac.uk (Gabriel Bodard) Date: Thu, 4 Mar 2010 15:44:30 +0000 Subject: [tei-council] a proposal for a change to ODD (copy of ticket I just put in SF) In-Reply-To: <4B8EFD4D.1050003@oucs.ox.ac.uk> References: <4B8EFD4D.1050003@oucs.ox.ac.uk> Message-ID: <4B8FD55E.4040400@kcl.ac.uk> This is not really an objection, but I note that I quite like being able to re-run my unchanged ODD against the new version of Roma and see the new element added to my schema, because it's in the modules/classes that I've already said I want. Is your proposal a replacement for, or a supplement to, the existing model? On 2010-03-04 00:22, James Cummings wrote: > Sebastian Rahtz wrote: >> surprises at future releases. New attributes _will_ pop up sometimes, but I think that's bearable. > > And of course content models and class memberships might change as > well...but of course that is true at the moment. > >> As an alternative, if you dont like<*Ref>, we could add an attribute "copyOf" to<*Spec>, with the >> same effect. > > I prefer your initial suggestion. > >> I believe that there is real demand for this (Tite is an excellent example >> of a project which badly needs no surprises at TEI version changes), >> that it is doable, and that it does not mean a rethink of ODD. > > I think all of those are good points. Though with the last I would hope > that this would fit in with any changes we do make to ODD eventually. > (but of course we can't predict that?) I've been trying to think of > flaws with this setup which would cause problems. The only anxiousness > I have is something to do with what it means for processing if an ODD > seems to be using both inherited and explicit models simultaneously. > > -James > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council -- Dr Gabriel BODARD (Epigrapher & Digital Classicist) Centre for Computing in the Humanities King's College London 26-29 Drury Lane London WC2B 5RL Email: gabriel.bodard at kcl.ac.uk Tel: +44 (0)20 7848 1388 Fax: +44 (0)20 7848 2980 http://www.digitalclassicist.org/ http://www.currentepigraphy.org/ From sebastian.rahtz at oucs.ox.ac.uk Thu Mar 4 11:03:42 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Thu, 4 Mar 2010 16:03:42 +0000 Subject: [tei-council] a proposal for a change to ODD (copy of ticket I just put in SF) In-Reply-To: <4B8FD55E.4040400@kcl.ac.uk> References: <4B8EFD4D.1050003@oucs.ox.ac.uk> <4B8FD55E.4040400@kcl.ac.uk> Message-ID: On 4 Mar 2010, at 15:44, Gabriel Bodard wrote: > This is not really an objection, but I note that I quite like being able > to re-run my unchanged ODD against the new version of Roma and see the > new element added to my schema, because it's in the > modules/classes that I've already said I want. > > Is your proposal a replacement for, or a supplement to, the existing model? definitely a supplement. existing ODDs work as before -- Sebastian Rahtz (acting) Information and Support Group Manager Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From James.Cummings at oucs.ox.ac.uk Thu Mar 4 11:38:58 2010 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Thu, 04 Mar 2010 16:38:58 +0000 Subject: [tei-council] a proposal for a change to ODD (copy of ticket I just put in SF) In-Reply-To: References: <4B8EFD4D.1050003@oucs.ox.ac.uk> <4B8FD55E.4040400@kcl.ac.uk> Message-ID: <4B8FE222.9050108@oucs.ox.ac.uk> Sebastian Rahtz wrote: > On 4 Mar 2010, at 15:44, Gabriel Bodard wrote: >> This is not really an objection, but I note that I quite like being able >> to re-run my unchanged ODD against the new version of Roma and see the >> new element added to my schema, because it's in the >> modules/classes that I've already said I want. >> Is your proposal a replacement for, or a supplement to, the existing model? > definitely a supplement. existing ODDs work as before Yes, I mean I would assume that you can have ODDs written exactly as before and saying then you want the entire module and whatever is it in the future. If instead you only want certain elements you wouldn't have the moduleRef at all, and instead just have lots of elementRefs. Or am I misunderstanding the mechanism? -James From dot.porter at gmail.com Thu Mar 4 12:32:28 2010 From: dot.porter at gmail.com (Dot Porter) Date: Thu, 4 Mar 2010 12:32:28 -0500 Subject: [tei-council] a proposal for a change to ODD (copy of ticket I just put in SF) In-Reply-To: <4B8FE222.9050108@oucs.ox.ac.uk> References: <4B8EFD4D.1050003@oucs.ox.ac.uk> <4B8FD55E.4040400@kcl.ac.uk> <4B8FE222.9050108@oucs.ox.ac.uk> Message-ID: <96f3df641003040932ne846772o8c14afa64bc9041a@mail.gmail.com> I fully support this proposed change. Many of the customizations I've made for projects include only a few elements from whatever module, so most of the ODD is specifying what to take out. This would make the process much more simple, if I'm understanding it correctly. Dot On Thu, Mar 4, 2010 at 11:38 AM, James Cummings wrote: > Sebastian Rahtz wrote: >> On 4 Mar 2010, at 15:44, Gabriel Bodard wrote: >>> This is not really an objection, but I note that I quite like being able >>> to re-run my unchanged ODD against the new version of Roma and see the >>> new element added to my schema, because it's in the >>> modules/classes that I've already said I want. >>> Is your proposal a replacement for, or a supplement to, the existing model? >> definitely a supplement. existing ODDs work as before > > Yes, I mean I would assume that you can have ODDs written exactly > as before and saying then you want the > entire module and whatever is it in the future. ?If instead you > only want certain elements you wouldn't have the moduleRef at > all, and instead just have lots of elementRefs. ?Or am I > misunderstanding the mechanism? > > -James > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > -- *~*~*~*~*~*~*~*~*~*~* Dot Porter (MA, MSLS) Metadata Manager (on leave) Digital Humanities Observatory (RIA), Regus House, 28-32 Upper Pembroke Street, Dublin 2, Ireland -- A Project of the Royal Irish Academy -- Phone: +353 1 234 2444 Fax: +353 1 234 2400 http://dho.ie Email: dot.porter at gmail.com *~*~*~*~*~*~*~*~*~*~* From laurent.romary at loria.fr Fri Mar 5 02:23:37 2010 From: laurent.romary at loria.fr (Laurent Romary) Date: Fri, 5 Mar 2010 08:23:37 +0100 Subject: [tei-council] a proposal for a change to ODD (copy of ticket I just put in SF) In-Reply-To: <4B8FE222.9050108@oucs.ox.ac.uk> References: <4B8EFD4D.1050003@oucs.ox.ac.uk> <4B8FD55E.4040400@kcl.ac.uk> <4B8FE222.9050108@oucs.ox.ac.uk> Message-ID: I think you're right and in my talk in Ann Arbour, I started to think of mechanisms to simplify the move. First, instead of introducing a new element to the purpose of indicating what one wants to use, we could just invent a new mode, like: (and probably do something similar for moduleRef) Second, we need to simplify the listing of needed elements by introducing a simplified version of 'cristals', so that by saying: , we tell the processor that we want biblStruct and all (mandatory?, defined in the same module?, classes?, ) elements directly below. We could then in turn have a few 'delete' instruction to further reduce the thing. Le 4 mars 10 ? 17:38, James Cummings a ?crit : > Sebastian Rahtz wrote: >> On 4 Mar 2010, at 15:44, Gabriel Bodard wrote: >>> This is not really an objection, but I note that I quite like >>> being able >>> to re-run my unchanged ODD against the new version of Roma and see >>> the >>> new element added to my schema, because it's in the >>> modules/classes that I've already said I want. >>> Is your proposal a replacement for, or a supplement to, the >>> existing model? >> definitely a supplement. existing ODDs work as before > > Yes, I mean I would assume that you can have ODDs written exactly > as before and saying then you want the > entire module and whatever is it in the future. If instead you > only want certain elements you wouldn't have the moduleRef at > all, and instead just have lots of elementRefs. Or am I > misunderstanding the mechanism? > > -James > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council From sebastian.rahtz at oucs.ox.ac.uk Fri Mar 5 04:58:16 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Fri, 5 Mar 2010 09:58:16 +0000 Subject: [tei-council] a proposal for a change to ODD (copy of ticket I just put in SF) In-Reply-To: References: <4B8EFD4D.1050003@oucs.ox.ac.uk> <4B8FD55E.4040400@kcl.ac.uk> <4B8FE222.9050108@oucs.ox.ac.uk> Message-ID: I wonder how to take this discussion to a conclusion? Everyone who has spoken agrees that we need the functionality, but there are three proposals on the table in the ticket which have about the same effect. Do we have enough data to take this up in Dublin, or can we arrive at consensus before then? -- Sebastian Rahtz (acting) Information and Support Group Manager Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From lou.burnard at oucs.ox.ac.uk Fri Mar 5 05:04:56 2010 From: lou.burnard at oucs.ox.ac.uk (Lou) Date: Fri, 05 Mar 2010 10:04:56 +0000 Subject: [tei-council] a proposal for a change to ODD (copy of ticket I just put in SF) In-Reply-To: References: <4B8EFD4D.1050003@oucs.ox.ac.uk> <4B8FD55E.4040400@kcl.ac.uk> <4B8FE222.9050108@oucs.ox.ac.uk> Message-ID: <4B90D748.9080306@oucs.ox.ac.uk> I suggest a separate discussion list to thrash out a position paper which can be presented in Dublin. We're getting there with sebastian's last comment on the sf ticket, but not quite. Sebastian Rahtz wrote: > I wonder how to take this discussion to a conclusion? Everyone who has spoken agrees that we > need the functionality, but there are three proposals on the table in the ticket which have about > the same effect. > > Do we have enough data to take this up in Dublin, or can we arrive at consensus before then? > -- > Sebastian Rahtz > (acting) Information and Support Group Manager > Oxford University Computing Services > 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 > > S?lo le pido a Dios > que el futuro no me sea indiferente > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council From sebastian.rahtz at oucs.ox.ac.uk Fri Mar 5 05:05:11 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Fri, 5 Mar 2010 10:05:11 +0000 Subject: [tei-council] a proposal for a change to ODD (copy of ticket I just put in SF) In-Reply-To: References: <4B8EFD4D.1050003@oucs.ox.ac.uk> <4B8FD55E.4040400@kcl.ac.uk> <4B8FE222.9050108@oucs.ox.ac.uk> Message-ID: <369BE795-83AE-480C-BF14-AF4B535DF5D0@oucs.ox.ac.uk> On 5 Mar 2010, at 07:23, Laurent Romary wrote: > Second, we need to simplify the listing of needed elements by > introducing a simplified version of 'cristals' I think what you have in mind really is "design patterns", viz LR's considered opinion of what a well-dressed bibliographical ODD should wear. I suspect that trying to formalize this into the TEI core is going to run into problems. I'd rather you said to make it explicit that it is, basically, a _view_ of the TEI. -- Sebastian Rahtz (acting) Information and Support Group Manager Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From sebastian.rahtz at oucs.ox.ac.uk Fri Mar 5 05:08:02 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Fri, 5 Mar 2010 10:08:02 +0000 Subject: [tei-council] a proposal for a change to ODD (copy of ticket I just put in SF) In-Reply-To: <4B90D748.9080306@oucs.ox.ac.uk> References: <4B8EFD4D.1050003@oucs.ox.ac.uk> <4B8FD55E.4040400@kcl.ac.uk> <4B8FE222.9050108@oucs.ox.ac.uk> <4B90D748.9080306@oucs.ox.ac.uk> Message-ID: On 5 Mar 2010, at 10:04, Lou wrote: > I suggest a separate discussion list to thrash out a position paper > which can be presented in Dublin. do you literally mean a new list? if we wanted to set up a fixed-term "ODD Architecture changes" list for between now and Dublin, there are some other tickets it could resolve too :-} But who would be on this list apart from people already on this list? only Syd is currently engaged (but thats because no-one on TEI-L knows about it) -- Sebastian Rahtz (acting) Information and Support Group Manager Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From lou.burnard at oucs.ox.ac.uk Fri Mar 5 05:10:12 2010 From: lou.burnard at oucs.ox.ac.uk (Lou) Date: Fri, 05 Mar 2010 10:10:12 +0000 Subject: [tei-council] a proposal for a change to ODD (copy of ticket I just put in SF) In-Reply-To: <369BE795-83AE-480C-BF14-AF4B535DF5D0@oucs.ox.ac.uk> References: <4B8EFD4D.1050003@oucs.ox.ac.uk> <4B8FD55E.4040400@kcl.ac.uk> <4B8FE222.9050108@oucs.ox.ac.uk> <369BE795-83AE-480C-BF14-AF4B535DF5D0@oucs.ox.ac.uk> Message-ID: <4B90D884.3040603@oucs.ox.ac.uk> Not wishing to be drawn into speculation about what Laurent may or may not have in mind, I do think there is a case to be made for saying that when I ask for a given element, I actually mean "this element and all its possible children". In other words, I want this element to behave as if it and its possible children were a distinct module. This is not the same as saying "I want this element and all its mandatory children" of course -- I believe that ODD processors are required to do this already (whence the presenece of so many zombies) Hence my proposal on the SF ticket for an additional attribute on (or if we go that way) Sebastian Rahtz wrote: > On 5 Mar 2010, at 07:23, Laurent Romary wrote: > >> Second, we need to simplify the listing of needed elements by >> introducing a simplified version of 'cristals' > > I think what you have in mind really is "design patterns", viz > LR's considered opinion of what a well-dressed bibliographical > ODD should wear. I suspect that trying to formalize this into the > TEI core is going to run into problems. > > I'd rather you said > > > > to make it explicit that it is, basically, a _view_ of the TEI. > -- > Sebastian Rahtz > (acting) Information and Support Group Manager > Oxford University Computing Services > 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 > > S?lo le pido a Dios > que el futuro no me sea indiferente > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council From lou.burnard at oucs.ox.ac.uk Fri Mar 5 05:11:55 2010 From: lou.burnard at oucs.ox.ac.uk (Lou) Date: Fri, 05 Mar 2010 10:11:55 +0000 Subject: [tei-council] a proposal for a change to ODD (copy of ticket I just put in SF) In-Reply-To: References: <4B8EFD4D.1050003@oucs.ox.ac.uk> <4B8FD55E.4040400@kcl.ac.uk> <4B8FE222.9050108@oucs.ox.ac.uk> <4B90D748.9080306@oucs.ox.ac.uk> Message-ID: <4B90D8EB.6030902@oucs.ox.ac.uk> Sebastian Rahtz wrote: > On 5 Mar 2010, at 10:04, Lou wrote: > >> I suggest a separate discussion list to thrash out a position paper >> which can be presented in Dublin. > > do you literally mean a new list? > Yes. We did it before, for choice, and for relatedItem. > if we wanted to set up a fixed-term "ODD Architecture changes" list for between now > and Dublin, there are some other tickets it could resolve too :-} > > But who would be on this list apart from people already on this list? only Syd > is currently engaged (but thats because no-one on TEI-L knows about it) > -- There would be no point in doing this unless it were announced to TEI land generally. But if twere done, twere well twere done quickly, init. From sebastian.rahtz at oucs.ox.ac.uk Fri Mar 5 05:15:38 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Fri, 5 Mar 2010 10:15:38 +0000 Subject: [tei-council] a proposal for a change to ODD (copy of ticket I just put in SF) In-Reply-To: <4B90D884.3040603@oucs.ox.ac.uk> References: <4B8EFD4D.1050003@oucs.ox.ac.uk> <4B8FD55E.4040400@kcl.ac.uk> <4B8FE222.9050108@oucs.ox.ac.uk> <369BE795-83AE-480C-BF14-AF4B535DF5D0@oucs.ox.ac.uk> <4B90D884.3040603@oucs.ox.ac.uk> Message-ID: On 5 Mar 2010, at 10:10, Lou wrote: > Not wishing to be drawn into speculation about what Laurent may or may > not have in mind, I do think there is a case to be made for saying that > when I ask for a given element, I actually mean "this element and all > its possible children". in all possible module universes? just add

, I bet it can contain most of the TEI within it?.. and don't forget that if you has a mandatory child and an optional child , but you also ask for , in which is mandatory, then will pop up in to your surprise. > This is not the same as saying "I want this element and all its > mandatory children" of course -- I believe that ODD processors are > required to do this already ( not so, for good or bad. thats why/cos the TEI is ambiguous > > Hence my proposal on the SF ticket for an additional attribute on > (or if we go that way) if you can spell out the total algorithm -- Sebastian Rahtz (acting) Information and Support Group Manager Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From lou.burnard at oucs.ox.ac.uk Fri Mar 5 05:20:37 2010 From: lou.burnard at oucs.ox.ac.uk (Lou) Date: Fri, 05 Mar 2010 10:20:37 +0000 Subject: [tei-council] a proposal for a change to ODD (copy of ticket I just put in SF) In-Reply-To: References: <4B8EFD4D.1050003@oucs.ox.ac.uk> <4B8FD55E.4040400@kcl.ac.uk> <4B8FE222.9050108@oucs.ox.ac.uk> <369BE795-83AE-480C-BF14-AF4B535DF5D0@oucs.ox.ac.uk> <4B90D884.3040603@oucs.ox.ac.uk> Message-ID: <4B90DAF5.40609@oucs.ox.ac.uk> Sebastian Rahtz wrote: > On 5 Mar 2010, at 10:10, Lou wrote: > >> Not wishing to be drawn into speculation about what Laurent may or may >> not have in mind, I do think there is a case to be made for saying that >> when I ask for a given element, I actually mean "this element and all >> its possible children". > > in all possible module universes? just add

, I bet it can contain most of the TEI > within it?.. No, not in all possible universes; in the universe created by the rest of my selections. > > and don't forget that if you has a mandatory child and an optional child , > but you also ask for , in which is mandatory, then will pop up in > to your surprise. Wy should I be surprised? If is mandatory in , I would expect to get it; if it's optional in therefore I would still expect to see it. > >> This is not the same as saying "I want this element and all its >> mandatory children" of course -- I believe that ODD processors are >> required to do this already ( > > not so, for good or bad. thats why/cos the TEI is ambiguous > Ah, I had my doubts about that. I didn't claim that any ODD processor actually does it, just my fervent belief that they should be required to... >> Hence my proposal on the SF ticket for an additional attribute on >> (or if we go that way) > > > if you can spell out the total algorithm SMOP ... I think we;re required to spell out the intended behaviour not the implementation. From sebastian.rahtz at oucs.ox.ac.uk Fri Mar 5 05:35:14 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Fri, 5 Mar 2010 10:35:14 +0000 Subject: [tei-council] a proposal for a change to ODD (copy of ticket I just put in SF) In-Reply-To: <4B90DAF5.40609@oucs.ox.ac.uk> References: <4B8EFD4D.1050003@oucs.ox.ac.uk> <4B8FD55E.4040400@kcl.ac.uk> <4B8FE222.9050108@oucs.ox.ac.uk> <369BE795-83AE-480C-BF14-AF4B535DF5D0@oucs.ox.ac.uk> <4B90D884.3040603@oucs.ox.ac.uk> <4B90DAF5.40609@oucs.ox.ac.uk> Message-ID: On 5 Mar 2010, at 10:20, Lou wrote: > No, not in all possible universes; in the universe created by the rest > of my selections. so you've already got biblStruct and all its children, whats the problemo? > > SMOP ... I think we;re required to spell out the intended behaviour not > the implementation. I asked for the algorithm, not the implementation?. can you or Laurent produce an example ODD, using current syntax, which does NOT do what you expect, and then another ODD with the extra clues in it? -- Sebastian Rahtz (acting) Information and Support Group Manager Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From sebastian.rahtz at oucs.ox.ac.uk Fri Mar 5 05:44:51 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Fri, 5 Mar 2010 10:44:51 +0000 Subject: [tei-council] a proposal for a change to ODD (copy of ticket I just put in SF) In-Reply-To: <4B90D8EB.6030902@oucs.ox.ac.uk> References: <4B8EFD4D.1050003@oucs.ox.ac.uk> <4B8FD55E.4040400@kcl.ac.uk> <4B8FE222.9050108@oucs.ox.ac.uk> <4B90D748.9080306@oucs.ox.ac.uk> <4B90D8EB.6030902@oucs.ox.ac.uk> Message-ID: <21926E02-8CFE-4350-A558-FFD5108EFA76@oucs.ox.ac.uk> On 5 Mar 2010, at 10:11, Lou wrote: > > There would be no point in doing this unless it were announced to TEI > land generally. But if twere done, twere well twere done quickly, init. > > as you'll see I posted to TEI-L on the subject. lets see who comes out of the woodwork. my suggestion is to ask an ad hoc committee to look at 2962880, 2890254 and 2834871 and make a concrete proposal for Council to validate in Dublin. That proposal to be include the proposed text for Guidelines and the source for the changed elements. amusingly, this comes back to the question of where such a group would/should do its development of a shared document/code -- Sebastian Rahtz (acting) Information and Support Group Manager Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From lou.burnard at oucs.ox.ac.uk Fri Mar 5 05:47:05 2010 From: lou.burnard at oucs.ox.ac.uk (Lou) Date: Fri, 05 Mar 2010 10:47:05 +0000 Subject: [tei-council] a proposal for a change to ODD (copy of ticket I just put in SF) In-Reply-To: <21926E02-8CFE-4350-A558-FFD5108EFA76@oucs.ox.ac.uk> References: <4B8EFD4D.1050003@oucs.ox.ac.uk> <4B8FD55E.4040400@kcl.ac.uk> <4B8FE222.9050108@oucs.ox.ac.uk> <4B90D748.9080306@oucs.ox.ac.uk> <4B90D8EB.6030902@oucs.ox.ac.uk> <21926E02-8CFE-4350-A558-FFD5108EFA76@oucs.ox.ac.uk> Message-ID: <4B90E129.20201@oucs.ox.ac.uk> Sebastian Rahtz wrote: > On 5 Mar 2010, at 10:11, Lou wrote: >> There would be no point in doing this unless it were announced to TEI >> land generally. But if twere done, twere well twere done quickly, init. >> >> > as you'll see I posted to TEI-L on the subject. lets see who comes out of the woodwork. > indeed so > my suggestion is to ask an ad hoc committee to look at 2962880, 2890254 and 2834871 > and make a concrete proposal for Council to validate in Dublin. That proposal to be include > the proposed text for Guidelines and the source for the changed elements. > > amusingly, this comes back to the question of where such a group would/should > do its development of a shared document/code > -- Indeed. You;d think by now that there would be some better way of interfacing with the sf ticket system than filling in those poxy web forms. From lou.burnard at oucs.ox.ac.uk Fri Mar 5 12:31:00 2010 From: lou.burnard at oucs.ox.ac.uk (Lou) Date: Fri, 05 Mar 2010 17:31:00 +0000 Subject: [tei-council] Discussion about TEI ODD Message-ID: <4B913FD4.4020203@oucs.ox.ac.uk> Further to Sebastian's request earlier today, there are now several Sourceforge tickets which, if addressed together, should enable us to extend considerably the capabilities of the current ODD system. We'd like to move forward as rapidly as possible, and benefit as much as possible from community wisdom on this rather technical topic. To that end, we're proposing to form an ad hoc mailing list, which we hope will be able to discuss briefly and intensively the various ideas kicked around so far, with a view to having a reasonably complete proposal on the table for the next TEI Council face to face meeting, to be held in Dublin at the end of April. We need technical experts, people who design schemas, people who think about what kinds of subsetting of the TEI make sense in their environment, and people who can express rather complex ideas clearly. And who have time to focus on the issue in the next few weeks: ideally this should be sewn up by the start of April. To get an idea of the topics under debate, check out existing SF tickets 2962880, 2890254 and 2834871 (at least). To visit a SF ticket, point your browser at https://sourceforge.net/tracker/index.php?func=detail&aid=ZZZZZZ&group_id=106328&atid=644065 replacing ZZZZZZ with the number of the ticket, as above. An initial discussion paper, summarising our current understanding of the issues, should appear on the list early next week. If you grock ODD, then we want and need you in that discussion, To sign up to the mailing list just send an (empty) email to tei-meta-subscribe at maillist.ox.ac.uk ... do it now! If you're just curious about it, probably best wait till the gabbling calms down again. We'll be back... From kevin.s.hawkins at ultraslavonic.info Sun Mar 7 13:28:16 2010 From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins) Date: Sun, 07 Mar 2010 18:28:16 +0000 Subject: [tei-council] update on Symposium on TEI and Scholarly Publishing Message-ID: <4B93F040.3040303@ultraslavonic.info> Hello everyone, Laurent and I have been working on the programme for the Symposium on TEI and Scholarly Publishing, to be held on 28 April, just before the Council meeting in Dublin (29-30 April). Though we're still waiting on a few final confirmations, we don't want to delay publicity much longer Please take a look at what we have: http://docs.google.com/Doc?docid=0ARyxZGtPbrQ1ZHYzZHg3aF85Znc4dzN0ZDQ I've asked the speakers to look at http://dho.ie/node/673 (which is publicly readable but has not been announced) and let me know of any corrections to their names and affiliations. I still need to create the registration form and insert that link at http://dho.ie/node/673 before we start distributing. Please think of email lists to which we should send the announcement. Laurent will be in touch soon with some of you to ask you to chair various sessions. Kevin From kevin.s.hawkins at ultraslavonic.info Sun Mar 7 16:51:05 2010 From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins) Date: Sun, 07 Mar 2010 21:51:05 +0000 Subject: [tei-council] update on room reservations in Dublin Message-ID: <4B941FC9.3030104@ultraslavonic.info> You might recall that earlier this year Laurent asked everyone to let him know what day they would arrive and depart from Dublin. We at the DHO have been working on reserving a block of rooms, so my colleague Emily Cullen or I will be in touch soon about this. No need to reserve a room on your own (as in the information I prepared for Symposium participants). --Kevin From laurent.romary at loria.fr Mon Mar 8 00:25:49 2010 From: laurent.romary at loria.fr (Laurent Romary) Date: Mon, 8 Mar 2010 06:25:49 +0100 Subject: [tei-council] update on room reservations in Dublin In-Reply-To: <4B941FC9.3030104@ultraslavonic.info> References: <4B941FC9.3030104@ultraslavonic.info> Message-ID: <6275B5D2-07C2-4694-B74C-FF6001832B79@loria.fr> Dear all, Let me mention on this topic that I am about to use my Visa to secure the reservation. Please tell us quickly if you change travel plans to Dublin in any respect so that I (and the TEI) is not forced to pay a fee. Best, Laurent Le 7 mars 10 ? 22:51, Kevin Hawkins a ?crit : > You might recall that earlier this year Laurent asked everyone to let > him know what day they would arrive and depart from Dublin. We at the > DHO have been working on reserving a block of rooms, so my colleague > Emily Cullen or I will be in touch soon about this. No need to > reserve > a room on your own (as in the information I prepared for Symposium > participants). --Kevin > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council From kevin.s.hawkins at ultraslavonic.info Mon Mar 8 08:01:02 2010 From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins) Date: Mon, 08 Mar 2010 13:01:02 +0000 Subject: [tei-council] update on room reservations in Dublin In-Reply-To: <4B941FC9.3030104@ultraslavonic.info> References: <4B941FC9.3030104@ultraslavonic.info> Message-ID: <4B94F50E.7080202@ultraslavonic.info> All, All of you coming to Dublin have rooms booked at: Temple Bar Hotel Fleet Street Dublin 2 Direct line: +353 (0)1 6129292 Fax: +353 (0)1 6773088 www.templebarhotel.com based on the arrival and departure dates that you provide to Laurent. If your plans change, please contact the hotel directly to adjust your reservation. (The hotel has your names already.) While we are holding the rooms, you will need to pay for the room yourself upon check out and submit the receipt to the TEI treasurer for reimbursement. Instructions on doing this will follow at some point. Kevin On 07/03/2010 21:51, Kevin Hawkins wrote: > You might recall that earlier this year Laurent asked everyone to let > him know what day they would arrive and depart from Dublin. We at the > DHO have been working on reserving a block of rooms, so my colleague > Emily Cullen or I will be in touch soon about this. No need to reserve > a room on your own (as in the information I prepared for Symposium > participants). --Kevin > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council From lou.burnard at oucs.ox.ac.uk Mon Mar 8 08:27:03 2010 From: lou.burnard at oucs.ox.ac.uk (Lou) Date: Mon, 08 Mar 2010 13:27:03 +0000 Subject: [tei-council] update on room reservations in Dublin In-Reply-To: <4B94F50E.7080202@ultraslavonic.info> References: <4B941FC9.3030104@ultraslavonic.info> <4B94F50E.7080202@ultraslavonic.info> Message-ID: <4B94FB27.4030609@oucs.ox.ac.uk> Except me, chiz chiz... my consolation is that I am staying in a hotel on Molesworth St. Kevin Hawkins wrote: > All, > > All of you coming to Dublin have rooms booked at: > > Temple Bar Hotel > Fleet Street > Dublin 2 > Direct line: +353 (0)1 6129292 > Fax: +353 (0)1 6773088 > www.templebarhotel.com > > based on the arrival and departure dates that you provide to Laurent. > If your plans change, please contact the hotel directly to adjust your > reservation. (The hotel has your names already.) > > While we are holding the rooms, you will need to pay for the room > yourself upon check out and submit the receipt to the TEI treasurer for > reimbursement. Instructions on doing this will follow at some point. > > Kevin > > On 07/03/2010 21:51, Kevin Hawkins wrote: >> You might recall that earlier this year Laurent asked everyone to let >> him know what day they would arrive and depart from Dublin. We at the >> DHO have been working on reserving a block of rooms, so my colleague >> Emily Cullen or I will be in touch soon about this. No need to reserve >> a room on your own (as in the information I prepared for Symposium >> participants). --Kevin >> _______________________________________________ >> tei-council mailing list >> tei-council at lists.village.Virginia.EDU >> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council From kevin.s.hawkins at ultraslavonic.info Mon Mar 8 10:27:40 2010 From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins) Date: Mon, 08 Mar 2010 15:27:40 +0000 Subject: [tei-council] update on room reservations in Dublin In-Reply-To: <4B94F50E.7080202@ultraslavonic.info> References: <4B941FC9.3030104@ultraslavonic.info> <4B94F50E.7080202@ultraslavonic.info> Message-ID: <4B95176C.9070903@ultraslavonic.info> I neglected to mention that you each have a double room with wifi and breakfast included for ?69 per night. --Kevin On 08/03/2010 13:01, Kevin Hawkins wrote: > All, > > All of you coming to Dublin have rooms booked at: > > Temple Bar Hotel > Fleet Street > Dublin 2 > Direct line: +353 (0)1 6129292 > Fax: +353 (0)1 6773088 > www.templebarhotel.com > > based on the arrival and departure dates that you provide to Laurent. If > your plans change, please contact the hotel directly to adjust your > reservation. (The hotel has your names already.) > > While we are holding the rooms, you will need to pay for the room > yourself upon check out and submit the receipt to the TEI treasurer for > reimbursement. Instructions on doing this will follow at some point. > > Kevin > > On 07/03/2010 21:51, Kevin Hawkins wrote: >> You might recall that earlier this year Laurent asked everyone to let >> him know what day they would arrive and depart from Dublin. We at the >> DHO have been working on reserving a block of rooms, so my colleague >> Emily Cullen or I will be in touch soon about this. No need to reserve >> a room on your own (as in the information I prepared for Symposium >> participants). --Kevin >> _______________________________________________ >> tei-council mailing list >> tei-council at lists.village.Virginia.EDU >> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council From kevin.s.hawkins at ultraslavonic.info Mon Mar 8 11:55:52 2010 From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins) Date: Mon, 08 Mar 2010 16:55:52 +0000 Subject: [tei-council] virtual hosts for HTML versions of Guidelines Message-ID: <4B952C18.209@ultraslavonic.info> Would anyone oppose me asking the folks at Virginia to investigate setting up the following virtual hosts: en.guidelines.tei-c.org de.guidelines.tei-c.org es.guidelines.tei-c.org it.guidelines.tei-c.org fr.guidelines.tei-c.org ja.guidelines.tei-c.org kr.guidelines.tei-c.org zh-tw.guidelines.tei-c.org which would serve the content currently at: http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ http://www.tei-c.org/release/doc/tei-p5-doc/de/html/ etc. I suggest this because right now the only way to search the full text of the Guidelines -- and only the full text of the Guidelines -- is to search within the PDF version. If we had a virtual host for each languages's HTML version, we could all use our favorite search engines to search the full text in our language of choice. Kevin From daniel.odonnell at uleth.ca Mon Mar 8 12:03:25 2010 From: daniel.odonnell at uleth.ca (O'Donnell, Dan) Date: Mon, 08 Mar 2010 10:03:25 -0700 Subject: [tei-council] virtual hosts for HTML versions of Guidelines In-Reply-To: <4B952C18.209@ultraslavonic.info> References: <4B952C18.209@ultraslavonic.info> Message-ID: <4B952DDD.1000403@uleth.ca> Is that not part of the work that David and James have been doing regarding stable URLs? -dan Kevin Hawkins wrote: > Would anyone oppose me asking the folks at Virginia to investigate > setting up the following virtual hosts: > > en.guidelines.tei-c.org > de.guidelines.tei-c.org > es.guidelines.tei-c.org > it.guidelines.tei-c.org > fr.guidelines.tei-c.org > ja.guidelines.tei-c.org > kr.guidelines.tei-c.org > zh-tw.guidelines.tei-c.org > > which would serve the content currently at: > > http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ > http://www.tei-c.org/release/doc/tei-p5-doc/de/html/ > etc. > > I suggest this because right now the only way to search the full text of > the Guidelines -- and only the full text of the Guidelines -- is to > search within the PDF version. If we had a virtual host for each > languages's HTML version, we could all use our favorite search engines > to search the full text in our language of choice. > > Kevin > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > -- Daniel Paul O'Donnell Associate Professor of English University of Lethbridge Chair and CEO, Text Encoding Initiative (http://www.tei-c.org/) Co-Chair, Digital Initiatives Advisory Board, Medieval Academy of America President-elect (English), Society for Digital Humanities/Soci?t? pour l'?tude des m?dias interactifs (http://sdh-semi.org/) Founding Director (2003-2009), Digital Medievalist Project (http://www.digitalmedievalist.org/) Vox: +1 403 329-2377 Fax: +1 403 382-7191 (non-confidential) Home Page: http://people.uleth.ca/~daniel.odonnell/ From dsewell at virginia.edu Mon Mar 8 12:40:47 2010 From: dsewell at virginia.edu (David Sewell) Date: Mon, 8 Mar 2010 12:40:47 -0500 (EST) Subject: [tei-council] virtual hosts for HTML versions of Guidelines In-Reply-To: <4B952DDD.1000403@uleth.ca> References: <4B952C18.209@ultraslavonic.info> <4B952DDD.1000403@uleth.ca> Message-ID: This is not a proposal that has been floated before. It would be analogous to Wikipedia's use of domains, I guess (en.wikipedia.org, de.wikipedia.org, etc.). Should I inquire of the UVA IT people whether they impose a limit on the number of host aliases they are willing to register in the DNS? Beyond that it would just be a question of writing virtual host entries in the Apache configuration. It would be trivially easy to change the directories to which those entries point later, if we implement a different naming structure. A counterargument might be that it's not really necessary. I just tried a Google search for "r?f?rence bibliographique" with site:www-tei-c.org and not surprisingly the French reference for was the top hit. David On Mon, 8 Mar 2010, O'Donnell, Dan wrote: > Is that not part of the work that David and James have been doing > regarding stable URLs? > > -dan > > Kevin Hawkins wrote: > > Would anyone oppose me asking the folks at Virginia to investigate > > setting up the following virtual hosts: > > > > en.guidelines.tei-c.org > > de.guidelines.tei-c.org > > es.guidelines.tei-c.org > > it.guidelines.tei-c.org > > fr.guidelines.tei-c.org > > ja.guidelines.tei-c.org > > kr.guidelines.tei-c.org > > zh-tw.guidelines.tei-c.org > > > > which would serve the content currently at: > > > > http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ > > http://www.tei-c.org/release/doc/tei-p5-doc/de/html/ > > etc. > > > > I suggest this because right now the only way to search the full text of > > the Guidelines -- and only the full text of the Guidelines -- is to > > search within the PDF version. If we had a virtual host for each > > languages's HTML version, we could all use our favorite search engines > > to search the full text in our language of choice. > > > > Kevin > > _______________________________________________ > > tei-council mailing list > > tei-council at lists.village.Virginia.EDU > > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > > > > -- David Sewell, Editorial and Technical Manager ROTUNDA, The University of Virginia Press PO Box 801079, Charlottesville, VA 22904-4318 USA Courier: 310 Old Ivy Way, Suite 302, Charlottesville VA 22903 Email: dsewell at virginia.edu Tel: +1 434 924 9973 Web: http://rotunda.upress.virginia.edu/ From kevin.s.hawkins at ultraslavonic.info Mon Mar 8 13:01:31 2010 From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins) Date: Mon, 08 Mar 2010 18:01:31 +0000 Subject: [tei-council] virtual hosts for HTML versions of Guidelines In-Reply-To: References: <4B952C18.209@ultraslavonic.info> <4B952DDD.1000403@uleth.ca> Message-ID: <4B953B7B.8020800@ultraslavonic.info> I'm not aware of any work that David and James are doing regarding stable URLs, but in any case David says this is different. I neglected to mention that I meant for these virtual hosts to always point at the latest version of the Guidelines. As David said, this would be easy enough to change once new versions are made (or in case /release/doc/tei-p5-doc/en/html/ etc. is no longer the place to find P5). My suggestion was driven not by having trouble searching the non-English version but in having trouble searching the English version and excluding the rest of TEI website: customizations, files in the Vault, working group reports, etc. While it's obviously not necessary (we've all lived without it this long), it would make the Guidelines easier to use. For example, try using Google to search for the following: xml:id site:www.tei-c.org "mandatory when applicable" site:www.tei-c.org On 08/03/2010 17:40, David Sewell wrote: > This is not a proposal that has been floated before. It would be > analogous to Wikipedia's use of domains, I guess (en.wikipedia.org, > de.wikipedia.org, etc.). > > Should I inquire of the UVA IT people whether they impose a limit on the > number of host aliases they are willing to register in the DNS? Beyond > that it would just be a question of writing virtual host entries in the > Apache configuration. It would be trivially easy to change the > directories to which those entries point later, if we implement a > different naming structure. > > A counterargument might be that it's not really necessary. I just tried > a Google search for "r?f?rence bibliographique" with site:www-tei-c.org > and not surprisingly the French reference for was the top hit. > > David > > On Mon, 8 Mar 2010, O'Donnell, Dan wrote: > >> Is that not part of the work that David and James have been doing >> regarding stable URLs? >> >> -dan >> >> Kevin Hawkins wrote: >>> Would anyone oppose me asking the folks at Virginia to investigate >>> setting up the following virtual hosts: >>> >>> en.guidelines.tei-c.org >>> de.guidelines.tei-c.org >>> es.guidelines.tei-c.org >>> it.guidelines.tei-c.org >>> fr.guidelines.tei-c.org >>> ja.guidelines.tei-c.org >>> kr.guidelines.tei-c.org >>> zh-tw.guidelines.tei-c.org >>> >>> which would serve the content currently at: >>> >>> http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ >>> http://www.tei-c.org/release/doc/tei-p5-doc/de/html/ >>> etc. >>> >>> I suggest this because right now the only way to search the full text of >>> the Guidelines -- and only the full text of the Guidelines -- is to >>> search within the PDF version. If we had a virtual host for each >>> languages's HTML version, we could all use our favorite search engines >>> to search the full text in our language of choice. >>> >>> Kevin >>> _______________________________________________ >>> tei-council mailing list >>> tei-council at lists.village.Virginia.EDU >>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council >>> >> >> > From daniel.odonnell at uleth.ca Mon Mar 8 15:45:07 2010 From: daniel.odonnell at uleth.ca (O'Donnell, Dan) Date: Mon, 08 Mar 2010 13:45:07 -0700 Subject: [tei-council] a proposal for a change to ODD (copy of ticket I just put in SF) In-Reply-To: References: Message-ID: <4B9561D3.7070407@uleth.ca> I'm only coming to this late due to a family emergency, but I'd love this too, if I'm understanding it: we were just discussing this problem with Perry and Apex in relation to AccessTEI. Would it be possible to build in a way of handling examples as well? Another problem we've run into is that you can end up with inappropriate examples after all the deletions. -dan Sebastian Rahtz wrote: > [from a discussion with Lou and James earlier today] > > Currently, we say things in an ODD like > > > > > which works fine to get the subset of elements we want. But that has the side effect that when the TEI adds to the module, > it pops up when we next compile our ODD, and our schema has changed. We need a way to say exactly what we _do_ want, not > what we _don't_ want. > > I therefore propose 3 new elements, , and , which have same attributes as , > and dictate which elements are to be appear in the output schema. No other elements can creep in in future. Similarly, I explicitly > say what attribute classes I want (I am not quite so sure about macros), apart from att.global. The result is much less likelihood of > surprises at future releases. New attributes _will_ pop up sometimes, but I think that's bearable. > > Yes, its may be a pig to implement, but I claim the semantics are fairly clear. > > As an alternative, if you dont like <*Ref>, we could add an attribute "copyOf" to <*Spec>, with the > same effect. > > I believe that there is real demand for this (Tite is an excellent example > of a project which badly needs no surprises at TEI version changes), > that it is doable, and that it does not mean a rethink of ODD. > > > (it would help to discuss this in public on the SF ticket: > https://sourceforge.net/tracker/?func=detail&aid=2962880&group_id=106328&atid=644065) > -- > Sebastian Rahtz > Information Manager, Oxford University Computing Services > 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 > > S?lo le pido a Dios > que el futuro no me sea indiferente > > > > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > -- Daniel Paul O'Donnell Associate Professor of English University of Lethbridge Chair and CEO, Text Encoding Initiative (http://www.tei-c.org/) Co-Chair, Digital Initiatives Advisory Board, Medieval Academy of America President-elect (English), Society for Digital Humanities/Soci?t? pour l'?tude des m?dias interactifs (http://sdh-semi.org/) Founding Director (2003-2009), Digital Medievalist Project (http://www.digitalmedievalist.org/) Vox: +1 403 329-2377 Fax: +1 403 382-7191 (non-confidential) Home Page: http://people.uleth.ca/~daniel.odonnell/ From kevin.s.hawkins at ultraslavonic.info Mon Mar 8 15:50:42 2010 From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins) Date: Mon, 08 Mar 2010 20:50:42 +0000 Subject: [tei-council] Lists of Council Members In-Reply-To: <4B8D47C0.7050908@oucs.ox.ac.uk> References: <4B8D47C0.7050908@oucs.ox.ac.uk> Message-ID: <4B956322.4070403@ultraslavonic.info> Discussion of this died out, but I agree with James that this is an important issue that we should deal with. I support keeping a record of people who have made past contributions to the TEI and TEI-C (editors, Board members, Council members, and officers). I don't have a preference on whether this is included in an appendix to the Guidelines or on pages on the website. What I do not support is simply having the current Council (and Board?) members in the Guidelines during any release. Digging up old interim releases for proof of this is difficult, and our work, after all, contributes not only to the current release but to future ones as well. On 02/03/2010 17:15, James Cummings wrote: > The other day while examining Sebastian's PDF of the Guidelines for > flaws I noticed the acknowledgement section. In it there is a list of > council members who elected and active during the years that TEI P5 > version 1.0 was created. See: > http://www.tei-c.org/release/doc/tei-p5-doc/en/html/FM1.html > > This got me thinking about all those Council members who have > contributed sometimes significantly to the Guidelines since their > initial P5 publication, and that the donation of their time to the TEI > isn't recorded in the Guidelines per se. There is a list of currently > serving members at http://www.tei-c.org/Activities/Council/ but that as > well only lists currently elected members. > > What I was going to suggest is that: > a) there should be a publicly accessible, simple alphabetic list of who > has been on Council (optionally board as well), and their associated > dates, which is updated each year. > b) that the Guidelines (at the bottom of the list of Council members) > give a link to this with a note to the effect that ongoing maintenance > has been undertaken by the TEI Council. > > And no, in case you're interested, I'm already in the list in the > Guidelines so this isn't some way to try and shoehorn my name in, just a > recognition that there are some who I know have worked hard on the > Guidelines since then who aren't in that list. > > Food for thought, > > -James > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council From sebastian.rahtz at oucs.ox.ac.uk Mon Mar 8 16:00:45 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 8 Mar 2010 21:00:45 +0000 Subject: [tei-council] a proposal for a change to ODD (copy of ticket I just put in SF) In-Reply-To: <4B9561D3.7070407@uleth.ca> References: <4B9561D3.7070407@uleth.ca> Message-ID: On 8 Mar 2010, at 20:45, O'Donnell, Dan wrote: > I'm only coming to this late due to a family emergency, but I'd love > this too, if I'm understanding it: we were just discussing this > problem > with Perry and Apex in relation to AccessTEI. Would it be possible to > build in a way of handling examples as well? Another problem we've run > into is that you can end up with inappropriate examples after all the > deletions. I'd be keen to sort out examples. Can you define the problem in more detail? -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From daniel.odonnell at uleth.ca Mon Mar 8 16:04:28 2010 From: daniel.odonnell at uleth.ca (O'Donnell, Dan) Date: Mon, 08 Mar 2010 14:04:28 -0700 Subject: [tei-council] Lists of Council Members In-Reply-To: <4B956322.4070403@ultraslavonic.info> References: <4B8D47C0.7050908@oucs.ox.ac.uk> <4B956322.4070403@ultraslavonic.info> Message-ID: <4B95665C.4010607@uleth.ca> My recollection in the runup to P5 was that we researched this to make sure we didn't just thank the members who happened to be on at any one time. I agree that it is a good idea. Presumably it wouldn't be too hard to maintain. Kevin Hawkins wrote: > Discussion of this died out, but I agree with James that this is an > important issue that we should deal with. > > I support keeping a record of people who have made past contributions to > the TEI and TEI-C (editors, Board members, Council members, and > officers). I don't have a preference on whether this is included in an > appendix to the Guidelines or on pages on the website. What I do not > support is simply having the current Council (and Board?) members in the > Guidelines during any release. Digging up old interim releases for > proof of this is difficult, and our work, after all, contributes not > only to the current release but to future ones as well. > > On 02/03/2010 17:15, James Cummings wrote: > >> The other day while examining Sebastian's PDF of the Guidelines for >> flaws I noticed the acknowledgement section. In it there is a list of >> council members who elected and active during the years that TEI P5 >> version 1.0 was created. See: >> http://www.tei-c.org/release/doc/tei-p5-doc/en/html/FM1.html >> >> This got me thinking about all those Council members who have >> contributed sometimes significantly to the Guidelines since their >> initial P5 publication, and that the donation of their time to the TEI >> isn't recorded in the Guidelines per se. There is a list of currently >> serving members at http://www.tei-c.org/Activities/Council/ but that as >> well only lists currently elected members. >> >> What I was going to suggest is that: >> a) there should be a publicly accessible, simple alphabetic list of who >> has been on Council (optionally board as well), and their associated >> dates, which is updated each year. >> b) that the Guidelines (at the bottom of the list of Council members) >> give a link to this with a note to the effect that ongoing maintenance >> has been undertaken by the TEI Council. >> >> And no, in case you're interested, I'm already in the list in the >> Guidelines so this isn't some way to try and shoehorn my name in, just a >> recognition that there are some who I know have worked hard on the >> Guidelines since then who aren't in that list. >> >> Food for thought, >> >> -James >> _______________________________________________ >> tei-council mailing list >> tei-council at lists.village.Virginia.EDU >> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council >> > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > -- Daniel Paul O'Donnell Associate Professor of English University of Lethbridge Chair and CEO, Text Encoding Initiative (http://www.tei-c.org/) Co-Chair, Digital Initiatives Advisory Board, Medieval Academy of America President-elect (English), Society for Digital Humanities/Soci?t? pour l'?tude des m?dias interactifs (http://sdh-semi.org/) Founding Director (2003-2009), Digital Medievalist Project (http://www.digitalmedievalist.org/) Vox: +1 403 329-2377 Fax: +1 403 382-7191 (non-confidential) Home Page: http://people.uleth.ca/~daniel.odonnell/ From lou.burnard at oucs.ox.ac.uk Mon Mar 8 16:08:06 2010 From: lou.burnard at oucs.ox.ac.uk (Lou Burnard) Date: Mon, 08 Mar 2010 21:08:06 +0000 Subject: [tei-council] a proposal for a change to ODD (copy of ticket I just put in SF) In-Reply-To: References: <4B9561D3.7070407@uleth.ca> Message-ID: <4B956736.8060509@oucs.ox.ac.uk> Sebastian Rahtz wrote: > On 8 Mar 2010, at 20:45, O'Donnell, Dan wrote: > >> I'm only coming to this late due to a family emergency, but I'd love >> this too, if I'm understanding it: we were just discussing this >> problem >> with Perry and Apex in relation to AccessTEI. Would it be possible to >> build in a way of handling examples as well? Another problem we've run >> into is that you can end up with inappropriate examples after all the >> deletions. > > > I'd be keen to sort out examples. Can you define the problem > in more detail? > -- My understanding of the problem is that the reference doc for elements you include in your ODD without modification will include the same examples as they do in P5. This is confusing if, say, you have removed some of the elements contained by those examples. I don't think there's any way round this, other than to provide your own customized examples in your ODD. As I suggested to Perry last week this is probably good practice anyway. From lou.burnard at oucs.ox.ac.uk Mon Mar 8 16:19:27 2010 From: lou.burnard at oucs.ox.ac.uk (Lou Burnard) Date: Mon, 08 Mar 2010 21:19:27 +0000 Subject: [tei-council] a proposal for a change to ODD (copy of ticket I just put in SF) In-Reply-To: <12E94F2F-AEFB-4562-A9C5-4F1381CD6FA9@ARTSCI.WUSTL.EDU> References: <4B9561D3.7070407@uleth.ca> <4B956736.8060509@oucs.ox.ac.uk> <12E94F2F-AEFB-4562-A9C5-4F1381CD6FA9@ARTSCI.WUSTL.EDU> Message-ID: <4B9569DF.8000004@oucs.ox.ac.uk> A standalone collection of examples is a nice idea : you could pull in the individual ones you want in your ODD doc by using xInclude. Perry Trolard wrote: > I was just going to chime in with this, Lou, thanks to your earlier suggestion: it is. > > The other fleeting thought I had, completely without regard for implementation, was that one could provide a sample document from which examples could be pulled during ODD processing. I.e. inputs are (1) ODD & (2) this supplied example doc & the output is documentation populated with examples from the supplied doc. This is only marginally more convenient than using in the ODD, however? > > Perry > > On Mar 8, 2010, at 3:08 PM, Lou Burnard wrote: > >> Sebastian Rahtz wrote: >>> On 8 Mar 2010, at 20:45, O'Donnell, Dan wrote: >>>> I'm only coming to this late due to a family emergency, but I'd love >>>> this too, if I'm understanding it: we were just discussing this problem >>>> with Perry and Apex in relation to AccessTEI. Would it be possible to >>>> build in a way of handling examples as well? Another problem we've run >>>> into is that you can end up with inappropriate examples after all the >>>> deletions. >>> I'd be keen to sort out examples. Can you define the problem >>> in more detail? >>> -- >> My understanding of the problem is that the reference doc for elements you include in your ODD without modification will include the same examples as they do in P5. This is confusing if, say, you have removed some of the elements contained by those examples. >> >> I don't think there's any way round this, other than to provide your own customized examples in your ODD. As I suggested to Perry last week this is probably good practice anyway. > From bbarney2 at unlnotes.unl.edu Mon Mar 8 16:20:30 2010 From: bbarney2 at unlnotes.unl.edu (Brett Barney) Date: Mon, 8 Mar 2010 15:20:30 -0600 Subject: [tei-council] update on Symposium on TEI and Scholarly Publishing In-Reply-To: <4B93F040.3040303@ultraslavonic.info> References: <4B93F040.3040303@ultraslavonic.info> Message-ID: Kevin, Very small quibble: The last sentence of the announcement strikes me as a little tangled. How about something like Registration to attend in person is free but required. For further information, please see http://dho.ie/node/673 ? Best regards, Brett |------------> | From: | |------------> >--------------------------------------------------------------------------------------------------------------------------------------------------| |Kevin Hawkins | >--------------------------------------------------------------------------------------------------------------------------------------------------| |------------> | To: | |------------> >--------------------------------------------------------------------------------------------------------------------------------------------------| |TEI Council | >--------------------------------------------------------------------------------------------------------------------------------------------------| |------------> | Date: | |------------> >--------------------------------------------------------------------------------------------------------------------------------------------------| |03/07/2010 12:28 PM | >--------------------------------------------------------------------------------------------------------------------------------------------------| |------------> | Subject: | |------------> >--------------------------------------------------------------------------------------------------------------------------------------------------| |[tei-council] update on Symposium on TEI and Scholarly Publishing | >--------------------------------------------------------------------------------------------------------------------------------------------------| Hello everyone, Laurent and I have been working on the programme for the Symposium on TEI and Scholarly Publishing, to be held on 28 April, just before the Council meeting in Dublin (29-30 April). Though we're still waiting on a few final confirmations, we don't want to delay publicity much longer Please take a look at what we have: http://docs.google.com/Doc?docid=0ARyxZGtPbrQ1ZHYzZHg3aF85Znc4dzN0ZDQ I've asked the speakers to look at http://dho.ie/node/673 (which is publicly readable but has not been announced) and let me know of any corrections to their names and affiliations. I still need to create the registration form and insert that link at http://dho.ie/node/673 before we start distributing. Please think of email lists to which we should send the announcement. Laurent will be in touch soon with some of you to ask you to chair various sessions. Kevin _______________________________________________ tei-council mailing list tei-council at lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council -------------- next part -------------- A non-text attachment was scrubbed... Name: graycol.gif Type: image/gif Size: 105 bytes Desc: not available Url : http://lists.village.Virginia.EDU/pipermail/tei-council/attachments/20100308/54300040/attachment.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: ecblank.gif Type: image/gif Size: 45 bytes Desc: not available Url : http://lists.village.Virginia.EDU/pipermail/tei-council/attachments/20100308/54300040/attachment-0001.gif From kevin.s.hawkins at ultraslavonic.info Mon Mar 8 16:26:05 2010 From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins) Date: Mon, 08 Mar 2010 21:26:05 +0000 Subject: [tei-council] update on Symposium on TEI and Scholarly Publishing In-Reply-To: References: <4B93F040.3040303@ultraslavonic.info> Message-ID: <4B956B6D.1050805@ultraslavonic.info> Good call! Fixed. On 08/03/2010 21:20, Brett Barney wrote: > > Kevin, > > Very small quibble: The last sentence of the announcement strikes me as a > little tangled. How about something like > Registration to attend in person is free but required. For further > information, please see http://dho.ie/node/673 > ? > > Best regards, > Brett >> Please take a look at what we have: >> >> http://docs.google.com/Doc?docid=0ARyxZGtPbrQ1ZHYzZHg3aF85Znc4dzN0ZDQ From sebastian.rahtz at oucs.ox.ac.uk Mon Mar 8 17:44:23 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 8 Mar 2010 22:44:23 +0000 Subject: [tei-council] a proposal for a change to ODD (copy of ticket I just put in SF) In-Reply-To: <12E94F2F-AEFB-4562-A9C5-4F1381CD6FA9@ARTSCI.WUSTL.EDU> References: <4B9561D3.7070407@uleth.ca> <4B956736.8060509@oucs.ox.ac.uk> <12E94F2F-AEFB-4562-A9C5-4F1381CD6FA9@ARTSCI.WUSTL.EDU> Message-ID: <3803939E-D156-4DB4-885B-ED44E3FD51B6@oucs.ox.ac.uk> On 8 Mar 2010, at 21:16, Perry Trolard wrote: > The other fleeting thought I had, completely without regard for > implementation, was that one could provide a sample document from > which examples could be pulled during ODD processing. I.e. inputs > are (1) ODD & (2) this supplied example doc & the output is > documentation populated with examples from the supplied doc. This is > only marginally more convenient than using in the ODD, > however? I think I would suggest that you do this statically, rather than letting Roma do it. i.e. write your ODD, build your example file, then write a processor to read the example file and update the ODD. That gives you a chance to edit the result. I have queasy feelings about the chance of getting this totally working in generality. -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From sebastian.rahtz at oucs.ox.ac.uk Mon Mar 8 17:46:42 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 8 Mar 2010 22:46:42 +0000 Subject: [tei-council] a proposal for a change to ODD (copy of ticket I just put in SF) In-Reply-To: <4B956736.8060509@oucs.ox.ac.uk> References: <4B9561D3.7070407@uleth.ca> <4B956736.8060509@oucs.ox.ac.uk> Message-ID: On 8 Mar 2010, at 21:08, Lou Burnard wrote: > My understanding of the problem is that the reference doc for elements > you include in your ODD without modification will include the same > examples as they do in P5. This is confusing if, say, you have > removed > some of the elements contained by those examples. It would be possible, at least, to automatically remove any which uses element not in your ODD. Is that worth pursuing? However, I think the priority work has to be sorting out the inclusion model of ODD writing and implementing it -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From lou.burnard at oucs.ox.ac.uk Mon Mar 8 17:50:03 2010 From: lou.burnard at oucs.ox.ac.uk (Lou Burnard) Date: Mon, 08 Mar 2010 22:50:03 +0000 Subject: [tei-council] a proposal for a change to ODD (copy of ticket I just put in SF) In-Reply-To: References: <4B9561D3.7070407@uleth.ca> <4B956736.8060509@oucs.ox.ac.uk> Message-ID: <4B957F1B.80805@oucs.ox.ac.uk> Sebastian Rahtz wrote: > On 8 Mar 2010, at 21:08, Lou Burnard wrote: >> My understanding of the problem is that the reference doc for elements >> you include in your ODD without modification will include the same >> examples as they do in P5. This is confusing if, say, you have >> removed >> some of the elements contained by those examples. > > > It would be possible, at least, to automatically remove any > which uses element > not in your ODD. Is that worth pursuing? I'd say not -- you probably don't want to remove the example, if it's a nice one, you (probably) just want the non-existent elements in it to disappear. So you're now into auto-editing examples, yikes. From sebastian.rahtz at oucs.ox.ac.uk Mon Mar 8 17:54:17 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 8 Mar 2010 22:54:17 +0000 Subject: [tei-council] a proposal for a change to ODD (copy of ticket I just put in SF) In-Reply-To: <4B957F1B.80805@oucs.ox.ac.uk> References: <4B9561D3.7070407@uleth.ca> <4B956736.8060509@oucs.ox.ac.uk> <4B957F1B.80805@oucs.ox.ac.uk> Message-ID: <3E77E683-519A-4F97-A0FD-13F29DD480C9@oucs.ox.ac.uk> On 8 Mar 2010, at 22:50, Lou Burnard wrote: > I'd say not -- you probably don't want to remove the example, if > it's a > nice one, you (probably) just want the non-existent elements in it to > disappear. So you're now into auto-editing examples, yikes. you jest, I hope. That way madness lies. -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From James.Cummings at oucs.ox.ac.uk Mon Mar 8 17:56:27 2010 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Mon, 08 Mar 2010 22:56:27 +0000 Subject: [tei-council] a proposal for a change to ODD (copy of ticket I just put in SF) In-Reply-To: <4B9569DF.8000004@oucs.ox.ac.uk> References: <4B9561D3.7070407@uleth.ca> <4B956736.8060509@oucs.ox.ac.uk> <12E94F2F-AEFB-4562-A9C5-4F1381CD6FA9@ARTSCI.WUSTL.EDU> <4B9569DF.8000004@oucs.ox.ac.uk> Message-ID: <4B95809B.8060600@oucs.ox.ac.uk> Lou Burnard wrote: > A standalone collection of examples is a nice idea : you could pull in > the individual ones you want in your ODD doc by using xInclude. I believe *cough* someone *cough* suggested this fervently before our meeting in Lyon. I then restated this in a later email and refer my learned colleague to my email to the council list of 2009-04-30. In it I reiterated the idea that having a standalone collection of examples, which the Guidelines would then XInclude (or similarly transclude). This would allow (amongst many other things) a coordinated method of using the same example in multiple places in the Guidelines and ODD documentation. I believe when I stated my reasons for thinking this was a good idea, it was indeed my honourable colleagues in Oxford who disagreed most vehemently with this suggestion. I am of course heartened to see your suggestion and assume that you have now seen the light. I believe that the current problem could be solved with more rigorous ODD processing. The multi-pass solution I would recommend is testing any example in the generated documentation against a schema generated from the ODD (but allowing any element as a starting element), much as we do in validating ex:egXML. The step that I'm not sure of in how to do it is how to capture and feed that information back into the transformation to then not include examples which do not validate. This would result in the transformation for documentation just not including any examples which did not validate against the current schema. That's just a suggestion mind you, I'm certainly not offering to attempt to implement it. -James From James.Cummings at oucs.ox.ac.uk Mon Mar 8 17:59:37 2010 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Mon, 08 Mar 2010 22:59:37 +0000 Subject: [tei-council] a proposal for a change to ODD (copy of ticket I just put in SF) In-Reply-To: <3E77E683-519A-4F97-A0FD-13F29DD480C9@oucs.ox.ac.uk> References: <4B9561D3.7070407@uleth.ca> <4B956736.8060509@oucs.ox.ac.uk> <4B957F1B.80805@oucs.ox.ac.uk> <3E77E683-519A-4F97-A0FD-13F29DD480C9@oucs.ox.ac.uk> Message-ID: <4B958159.1010108@oucs.ox.ac.uk> Sebastian Rahtz wrote: > On 8 Mar 2010, at 22:50, Lou Burnard wrote: > >> I'd say not -- you probably don't want to remove the example, if >> it's a >> nice one, you (probably) just want the non-existent elements in it to >> disappear. So you're now into auto-editing examples, yikes. > you jest, I hope. That way madness lies. I can envision a system where it says "sorry the default example is no longer valid under your schema... but *this one is* and uses this element... do you want to replace it?" But I certainly can't think there is any mileage in automatically editing examples. -James From daniel.odonnell at uleth.ca Mon Mar 8 17:59:41 2010 From: daniel.odonnell at uleth.ca (O'Donnell, Dan) Date: Mon, 08 Mar 2010 15:59:41 -0700 Subject: [tei-council] a proposal for a change to ODD (copy of ticket I just put in SF) In-Reply-To: <4B95809B.8060600@oucs.ox.ac.uk> References: <4B9561D3.7070407@uleth.ca> <4B956736.8060509@oucs.ox.ac.uk> <12E94F2F-AEFB-4562-A9C5-4F1381CD6FA9@ARTSCI.WUSTL.EDU> <4B9569DF.8000004@oucs.ox.ac.uk> <4B95809B.8060600@oucs.ox.ac.uk> Message-ID: <4B95815D.3010603@uleth.ca> All good things come to those who wait, James. My knees are calloused invoking higher powers about a sensible but your example gives me hope ;) -dan James Cummings wrote: > Lou Burnard wrote: > >> A standalone collection of examples is a nice idea : you could pull in >> the individual ones you want in your ODD doc by using xInclude. >> > > I believe *cough* someone *cough* suggested this fervently before our > meeting in Lyon. I then restated this in a later email and refer my > learned colleague to my email to the council list of 2009-04-30. In it > I reiterated the idea that having a standalone collection of examples, > which the Guidelines would then XInclude (or similarly transclude). > This would allow (amongst many other things) a coordinated method of > using the same example in multiple places in the Guidelines and ODD > documentation. I believe when I stated my reasons for thinking this was > a good idea, it was indeed my honourable colleagues in Oxford who > disagreed most vehemently with this suggestion. I am of course heartened > to see your suggestion and assume that you have now seen the light. > > I believe that the current problem could be solved with more rigorous > ODD processing. The multi-pass solution I would recommend is testing > any example in the generated documentation against a schema generated > from the ODD (but allowing any element as a starting element), much as > we do in validating ex:egXML. The step that I'm not sure of in how to do > it is how to capture and feed that information back into the > transformation to then not include examples which do not validate. This > would result in the transformation for documentation just not including > any examples which did not validate against the current schema. That's > just a suggestion mind you, I'm certainly not offering to attempt to > implement it. > > -James > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > -- Daniel Paul O'Donnell Associate Professor of English University of Lethbridge Chair and CEO, Text Encoding Initiative (http://www.tei-c.org/) Co-Chair, Digital Initiatives Advisory Board, Medieval Academy of America President-elect (English), Society for Digital Humanities/Soci?t? pour l'?tude des m?dias interactifs (http://sdh-semi.org/) Founding Director (2003-2009), Digital Medievalist Project (http://www.digitalmedievalist.org/) Vox: +1 403 329-2377 Fax: +1 403 382-7191 (non-confidential) Home Page: http://people.uleth.ca/~daniel.odonnell/ From sebastian.rahtz at oucs.ox.ac.uk Mon Mar 8 18:02:53 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 8 Mar 2010 23:02:53 +0000 Subject: [tei-council] a proposal for a change to ODD (copy of ticket I just put in SF) In-Reply-To: <4B95809B.8060600@oucs.ox.ac.uk> References: <4B9561D3.7070407@uleth.ca> <4B956736.8060509@oucs.ox.ac.uk> <12E94F2F-AEFB-4562-A9C5-4F1381CD6FA9@ARTSCI.WUSTL.EDU> <4B9569DF.8000004@oucs.ox.ac.uk> <4B95809B.8060600@oucs.ox.ac.uk> Message-ID: On 8 Mar 2010, at 22:56, James Cummings wrote: > documentation. I believe when I stated my reasons for thinking this > was > a good idea, it was indeed my honourable colleagues in Oxford who > disagreed most vehemently with this suggestion. I think, from memory, that we disagreed with the practicality of it for real-world work on the whole Guidelines. The theory is fine. > > ....This > would result in the transformation for documentation just not > including > any examples which did not validate against the current schema. doable, similar to what I just suggested. It's a big stick, though. -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From sebastian.rahtz at oucs.ox.ac.uk Mon Mar 8 18:04:41 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 8 Mar 2010 23:04:41 +0000 Subject: [tei-council] a proposal for a change to ODD (copy of ticket I just put in SF) In-Reply-To: <4B958159.1010108@oucs.ox.ac.uk> References: <4B9561D3.7070407@uleth.ca> <4B956736.8060509@oucs.ox.ac.uk> <4B957F1B.80805@oucs.ox.ac.uk> <3E77E683-519A-4F97-A0FD-13F29DD480C9@oucs.ox.ac.uk> <4B958159.1010108@oucs.ox.ac.uk> Message-ID: <1D81AB5B-1E39-486B-93E8-17661D008587@oucs.ox.ac.uk> On 8 Mar 2010, at 22:59, James Cummings wrote: > > I can envision a system where it says "sorry the default example is no > longer valid under your schema... but *this one is* and uses this > element... do you want to replace it?" Now you're talking about an interactive ODD processor. Whoo hoo. Bring on the orders of complexity....... -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From lou.burnard at oucs.ox.ac.uk Mon Mar 8 18:06:36 2010 From: lou.burnard at oucs.ox.ac.uk (Lou Burnard) Date: Mon, 08 Mar 2010 23:06:36 +0000 Subject: [tei-council] a proposal for a change to ODD (copy of ticket I just put in SF) In-Reply-To: References: <4B9561D3.7070407@uleth.ca> <4B956736.8060509@oucs.ox.ac.uk> <12E94F2F-AEFB-4562-A9C5-4F1381CD6FA9@ARTSCI.WUSTL.EDU> <4B9569DF.8000004@oucs.ox.ac.uk> <4B95809B.8060600@oucs.ox.ac.uk> Message-ID: <4B9582FC.4070609@oucs.ox.ac.uk> Sebastian Rahtz wrote: > On 8 Mar 2010, at 22:56, James Cummings wrote: > >> documentation. I believe when I stated my reasons for thinking this >> was >> a good idea, it was indeed my honourable colleagues in Oxford who >> disagreed most vehemently with this suggestion. > > I think, from memory, that we disagreed with the practicality of > it for real-world work on the whole Guidelines. The theory is fine. Precisely. The present conversation is about a customisation of the TEI, not the whole of the Guidelines. Then there's also the question of foreign language examples (cf recent email from our man in Nancy) > >> ....This >> would result in the transformation for documentation just not >> including >> any examples which did not validate against the current schema. > > doable, similar to what I just suggested. It's a big stick, though. > a big stick to squash a fairly small insect, I'd say From James.Cummings at oucs.ox.ac.uk Mon Mar 8 19:08:05 2010 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Tue, 09 Mar 2010 00:08:05 +0000 Subject: [tei-council] a proposal for a change to ODD (copy of ticket I just put in SF) In-Reply-To: <4B9582FC.4070609@oucs.ox.ac.uk> References: <4B9561D3.7070407@uleth.ca> <4B956736.8060509@oucs.ox.ac.uk> <12E94F2F-AEFB-4562-A9C5-4F1381CD6FA9@ARTSCI.WUSTL.EDU> <4B9569DF.8000004@oucs.ox.ac.uk> <4B95809B.8060600@oucs.ox.ac.uk> <4B9582FC.4070609@oucs.ox.ac.uk> Message-ID: <4B959165.7070401@oucs.ox.ac.uk> Lou Burnard wrote: >> I think, from memory, that we disagreed with the practicality of >> it for real-world work on the whole Guidelines. The theory is fine. That was one of the objections. You two also argued that decontextualised examples don't always make sense (which really missed the point, that they wouldn't necessarily be decontextualised, just decoupled from the guidelines/specs so that their re-use was facillitated). > Precisely. The present conversation is about a customisation of the TEI, > not the whole of the Guidelines. Is not the TEI Guidelines in theory one big ODD file? If it makes sense for one, why not for the other? > Then there's also the question of foreign language examples (cf recent > email from our man in Nancy) I only think this *strengthens* the case for a repository of examples which are then referenced from the Guidelines/Specs. Just as the English Guidelines use examples from many languages, so might translations of the Guidelines. Moreover, they want them to stay up to date when the examples are changed because of changes in the TEI. >> doable, similar to what I just suggested. It's a big stick, though. > a big stick to squash a fairly small insect, I'd say I'd be tempted to say that an ODD should maybe check simply that all the elements in an example are present for the current schema, and if not add a comment to the example indicating it might be out of date because element is no longer included in the schema. That seems like it would be much more straightforward to program, doesn't remove the example, but warns the user that it may be inaccurate. -James From laurent.romary at loria.fr Tue Mar 9 02:16:56 2010 From: laurent.romary at loria.fr (Laurent Romary) Date: Tue, 9 Mar 2010 08:16:56 +0100 Subject: [tei-council] virtual hosts for HTML versions of Guidelines In-Reply-To: References: <4B952C18.209@ultraslavonic.info> <4B952DDD.1000403@uleth.ca> Message-ID: <1843A3F9-9B49-47F0-8E33-7439B7221DD5@loria.fr> I would support Kevin's proposal. And the point you made about google is only half true. If I do use words which are "language independent" (google makes no difference between "reference" and "r?f?rence") I may come across any version of the guidelines; Since it does not hurt any other functionality and unless someone shouts loudly in the coming hours, I would suggest that Kevin and David proceed further with this. Laurent Le 8 mars 10 ? 18:40, David Sewell a ?crit : > This is not a proposal that has been floated before. It would be > analogous to Wikipedia's use of domains, I guess (en.wikipedia.org, > de.wikipedia.org, etc.). > > Should I inquire of the UVA IT people whether they impose a limit on > the > number of host aliases they are willing to register in the DNS? Beyond > that it would just be a question of writing virtual host entries in > the > Apache configuration. It would be trivially easy to change the > directories to which those entries point later, if we implement a > different naming structure. > > A counterargument might be that it's not really necessary. I just > tried > a Google search for "r?f?rence bibliographique" with site:www-tei- > c.org > and not surprisingly the French reference for was the top hit. > > David > > On Mon, 8 Mar 2010, O'Donnell, Dan wrote: > >> Is that not part of the work that David and James have been doing >> regarding stable URLs? >> >> -dan >> >> Kevin Hawkins wrote: >>> Would anyone oppose me asking the folks at Virginia to investigate >>> setting up the following virtual hosts: >>> >>> en.guidelines.tei-c.org >>> de.guidelines.tei-c.org >>> es.guidelines.tei-c.org >>> it.guidelines.tei-c.org >>> fr.guidelines.tei-c.org >>> ja.guidelines.tei-c.org >>> kr.guidelines.tei-c.org >>> zh-tw.guidelines.tei-c.org >>> >>> which would serve the content currently at: >>> >>> http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ >>> http://www.tei-c.org/release/doc/tei-p5-doc/de/html/ >>> etc. >>> >>> I suggest this because right now the only way to search the full >>> text of >>> the Guidelines -- and only the full text of the Guidelines -- is to >>> search within the PDF version. If we had a virtual host for each >>> languages's HTML version, we could all use our favorite search >>> engines >>> to search the full text in our language of choice. >>> >>> Kevin >>> _______________________________________________ >>> tei-council mailing list >>> tei-council at lists.village.Virginia.EDU >>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council >>> >> >> > > -- > David Sewell, Editorial and Technical Manager > ROTUNDA, The University of Virginia Press > PO Box 801079, Charlottesville, VA 22904-4318 USA > Courier: 310 Old Ivy Way, Suite 302, Charlottesville VA 22903 > Email: dsewell at virginia.edu Tel: +1 434 924 9973 > Web: http://rotunda.upress.virginia.edu/_______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council From sebastian.rahtz at oucs.ox.ac.uk Tue Mar 9 04:13:45 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 9 Mar 2010 09:13:45 +0000 Subject: [tei-council] a proposal for a change to ODD (copy of ticket I just put in SF) In-Reply-To: <4B959165.7070401@oucs.ox.ac.uk> References: <4B9561D3.7070407@uleth.ca> <4B956736.8060509@oucs.ox.ac.uk> <12E94F2F-AEFB-4562-A9C5-4F1381CD6FA9@ARTSCI.WUSTL.EDU> <4B9569DF.8000004@oucs.ox.ac.uk> <4B95809B.8060600@oucs.ox.ac.uk> <4B9582FC.4070609@oucs.ox.ac.uk> <4B959165.7070401@oucs.ox.ac.uk> Message-ID: <481A9005-367F-409A-BA60-2C72020CF3E0@oucs.ox.ac.uk> re: repository of examples, I don't see that we need do anything to let people use it. we have which can do the job fine, no? > I'd be tempted to say that an ODD should maybe check simply that all the > elements in an example are present for the current schema, and if not > add a comment to the example indicating it might be out of date because > element is no longer included in the schema. That seems like it > would be much more straightforward to program, doesn't remove the > example, but warns the user that it may be inaccurate. that doesnt make me _very_ happy. "we've found a problem but we cant fix it, so hey just have it anyway" seems unfriendly. but I agree, programmable. -- Sebastian Rahtz (acting) Information and Support Group Manager Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From laurent.romary at loria.fr Tue Mar 9 04:45:10 2010 From: laurent.romary at loria.fr (Laurent Romary) Date: Tue, 9 Mar 2010 10:45:10 +0100 Subject: [tei-council] a proposal for a change to ODD (copy of ticket I just put in SF) In-Reply-To: <481A9005-367F-409A-BA60-2C72020CF3E0@oucs.ox.ac.uk> References: <4B9561D3.7070407@uleth.ca> <4B956736.8060509@oucs.ox.ac.uk> <12E94F2F-AEFB-4562-A9C5-4F1381CD6FA9@ARTSCI.WUSTL.EDU> <4B9569DF.8000004@oucs.ox.ac.uk> <4B95809B.8060600@oucs.ox.ac.uk> <4B9582FC.4070609@oucs.ox.ac.uk> <4B959165.7070401@oucs.ox.ac.uk> <481A9005-367F-409A-BA60-2C72020CF3E0@oucs.ox.ac.uk> Message-ID: May I mention that I don't see the point of xi:include. We need a mechanism wher we can refer to an example anyplace within a document with just a reference to it. Something similar to specDesc (egRef?), with the appropriate attribute(s) (key or target mechanism) Le 9 mars 10 ? 10:13, Sebastian Rahtz a ?crit : > re: repository of examples, I don't see that we need do anything > to let people use it. we have which can do the job fine, > no? > >> I'd be tempted to say that an ODD should maybe check simply that >> all the >> elements in an example are present for the current schema, and if not >> add a comment to the example indicating it might be out of date >> because >> element is no longer included in the schema. That seems like >> it >> would be much more straightforward to program, doesn't remove the >> example, but warns the user that it may be inaccurate. > > > that doesnt make me _very_ happy. "we've found a problem but we cant > fix it, so hey just have it anyway" seems unfriendly. but I agree, > programmable. > -- > Sebastian Rahtz > (acting) Information and Support Group Manager > Oxford University Computing Services > 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 > > S?lo le pido a Dios > que el futuro no me sea indiferente > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council From sebastian.rahtz at oucs.ox.ac.uk Tue Mar 9 04:52:50 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 9 Mar 2010 09:52:50 +0000 Subject: [tei-council] a proposal for a change to ODD (copy of ticket I just put in SF) In-Reply-To: References: <4B9561D3.7070407@uleth.ca> <4B956736.8060509@oucs.ox.ac.uk> <12E94F2F-AEFB-4562-A9C5-4F1381CD6FA9@ARTSCI.WUSTL.EDU> <4B9569DF.8000004@oucs.ox.ac.uk> <4B95809B.8060600@oucs.ox.ac.uk> <4B9582FC.4070609@oucs.ox.ac.uk> <4B959165.7070401@oucs.ox.ac.uk> <481A9005-367F-409A-BA60-2C72020CF3E0@oucs.ox.ac.uk> Message-ID: On 9 Mar 2010, at 09:45, Laurent Romary wrote: > May I mention that I don't see the point of xi:include. We need a > mechanism wher we can refer to an example anyplace within a document > with just a reference to it. Something similar to specDesc (egRef?), > with the appropriate attribute(s) (key or target mechanism) > but XInclude allows for that, surely? or, indeed, -- Sebastian Rahtz (acting) Information and Support Group Manager Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From James.Cummings at oucs.ox.ac.uk Tue Mar 9 05:28:30 2010 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Tue, 09 Mar 2010 10:28:30 +0000 Subject: [tei-council] a proposal for a change to ODD (copy of ticket I just put in SF) In-Reply-To: <481A9005-367F-409A-BA60-2C72020CF3E0@oucs.ox.ac.uk> References: <4B9561D3.7070407@uleth.ca> <4B956736.8060509@oucs.ox.ac.uk> <12E94F2F-AEFB-4562-A9C5-4F1381CD6FA9@ARTSCI.WUSTL.EDU> <4B9569DF.8000004@oucs.ox.ac.uk> <4B95809B.8060600@oucs.ox.ac.uk> <4B9582FC.4070609@oucs.ox.ac.uk> <4B959165.7070401@oucs.ox.ac.uk> <481A9005-367F-409A-BA60-2C72020CF3E0@oucs.ox.ac.uk> Message-ID: <4B9622CE.6030201@oucs.ox.ac.uk> Sebastian Rahtz wrote: > re: repository of examples, I don't see that we need do anything > to let people use it. we have which can do the job fine, > no? Yes, or just a ptr would be fine. The question is more about where it is pointing. As you are aware I think that the examples should be decoupled from the Guidelines prose and the element specs and stored separately. This way two places in the Guidelines could transclude/xinclude the same example, and when the example was updated, both places would be updated. One of the fundamental principles of easy re-use, no? >> I'd be tempted to say that an ODD should maybe check simply that all the >> elements in an example are present for the current schema, and if not >> add a comment to the example indicating it might be out of date because >> element is no longer included in the schema. That seems like it >> would be much more straightforward to program, doesn't remove the >> example, but warns the user that it may be inaccurate. > that doesnt make me _very_ happy. "we've found a problem but we cant > fix it, so hey just have it anyway" seems unfriendly. but I agree, programmable. I was thinking of it more like "Warning: The following default example may not match your schema." but I see your point. I think having the warning is _better_ than providing the invalid example without a warning. Not as good, of course, as providing a valid example, but I don't see how to do that without a great deal of complexity. If we're only testing element presence or not, rather than content models, then it is a rough estimation at best. (I.e. we know if it is completely invalid, it contains elements which don't exist in the schema, but we don't know if that attribute is allowed here or if the content model for this element has been changed.) The choices, as I see them are: a) Provide the invalid example, no warning b) Provide the invalid example, with warning c) Do not provide invalid examples, reference just has no example e) Attempt somehow attempt to find a valid example which includes this element in the corpus of examples, falling back to one of the above otherwise f) Attempt somehow to validate the examples and use their full validity to do one of the above. g) Do something else that is even better. Of all of these b) actually seems the friendliest to me. -James -- Dr James Cummings, Research Technologies Service OUCS, University of Oxford From kevin.s.hawkins at ultraslavonic.info Tue Mar 9 09:56:30 2010 From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins) Date: Tue, 09 Mar 2010 14:56:30 +0000 Subject: [tei-council] Symposium on TEI and Scholarly Publishing: registration, announcement for sharing Message-ID: <4B96619E.90908@ultraslavonic.info> Dear Council Members, Registration is now open. Please take a moment to register online so we can prepare name badges and food orders from a single source. Please circulate the message below to any colleagues who might be interested in our event and note who you've sent it to in *the other* Google Docs file: http://docs.google.com/Doc?docid=0ARyxZGtPbrQ1ZHYzZHg3aF85Znc4dzN0ZDQ&hl=en_GB --Kevin *** *Please circulate* Symposium on TEI and Scholarly Publishing http://dho.ie/node/673 Wednesday, 28 April 2010 Royal Irish Academy, 19 Dawson Street, Dublin 2 The TEI Council and the Digital Humanities Observatory, a project of the Royal Irish Academy, invite you to participate in a one-day Symposium on TEI and Scholarly Publishing, to be held 28 April 2010 in conjunction with a meeting of the TEI Council. Invited speakers from universities, publishing organizations, and private industry will identify current difficulties in making publication systems interoperable and identify priority actions for the TEI to intervene in this arena. During the presentations, there will be simultaneous discussion in the backchannel #teipublishing and in a publicly readable and editable Google Docs file for collaborative identification of priority actions for the TEI. To avoid infestation by spambots, we will not include the actual URL in announcements. Please type "docs.google.com" into your browser and then paste the following after it: /Doc?id=dv3dx7h_12gtqzjxg5 We encourage participation on the backchannel and in this collaborative writing exercise by all, even those unable to attend in person. Registration to attend in person is free but required. For further information, please see http://dho.ie/node/673 From dsewell at virginia.edu Tue Mar 9 10:06:05 2010 From: dsewell at virginia.edu (David Sewell) Date: Tue, 9 Mar 2010 10:06:05 -0500 (EST) Subject: [tei-council] virtual hosts for HTML versions of Guidelines In-Reply-To: <1843A3F9-9B49-47F0-8E33-7439B7221DD5@loria.fr> References: <4B952C18.209@ultraslavonic.info> <4B952DDD.1000403@uleth.ca> <1843A3F9-9B49-47F0-8E33-7439B7221DD5@loria.fr> Message-ID: The first step is to contact the U of Virginia network administrators to be sure they do not set a limit on the number of aliases associated with a machine. If not, I or Shayne Brandon (tei-c.org sysadmin) will submit the request and go from there. David On Tue, 9 Mar 2010, Laurent Romary wrote: > I would support Kevin's proposal. And the point you made about google is only > half true. If I do use words which are "language independent" (google makes no > difference between "reference" and "r?f?rence") I may come across any version > of the guidelines; > > Since it does not hurt any other functionality and unless someone shouts > loudly in the coming hours, I would suggest that Kevin and David proceed > further with this. > > Laurent > > > Le 8 mars 10 ? 18:40, David Sewell a ?crit : > > > This is not a proposal that has been floated before. It would be > > analogous to Wikipedia's use of domains, I guess (en.wikipedia.org, > > de.wikipedia.org, etc.). > > > > Should I inquire of the UVA IT people whether they impose a limit on the > > number of host aliases they are willing to register in the DNS? Beyond > > that it would just be a question of writing virtual host entries in the > > Apache configuration. It would be trivially easy to change the > > directories to which those entries point later, if we implement a > > different naming structure. > > > > A counterargument might be that it's not really necessary. I just tried > > a Google search for "r?f?rence bibliographique" with site:www-tei-c.org > > and not surprisingly the French reference for was the top hit. > > > > David > > > > On Mon, 8 Mar 2010, O'Donnell, Dan wrote: > > > > > Is that not part of the work that David and James have been doing > > > regarding stable URLs? > > > > > > -dan > > > > > > Kevin Hawkins wrote: > > > > Would anyone oppose me asking the folks at Virginia to investigate > > > > setting up the following virtual hosts: > > > > > > > > en.guidelines.tei-c.org > > > > de.guidelines.tei-c.org > > > > es.guidelines.tei-c.org > > > > it.guidelines.tei-c.org > > > > fr.guidelines.tei-c.org > > > > ja.guidelines.tei-c.org > > > > kr.guidelines.tei-c.org > > > > zh-tw.guidelines.tei-c.org > > > > > > > > which would serve the content currently at: > > > > > > > > http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ > > > > http://www.tei-c.org/release/doc/tei-p5-doc/de/html/ > > > > etc. > > > > > > > > I suggest this because right now the only way to search the full text of > > > > the Guidelines -- and only the full text of the Guidelines -- is to > > > > search within the PDF version. If we had a virtual host for each > > > > languages's HTML version, we could all use our favorite search engines > > > > to search the full text in our language of choice. > > > > > > > > Kevin > > > > _______________________________________________ > > > > tei-council mailing list > > > > tei-council at lists.village.Virginia.EDU > > > > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > > > > > > > > > > > > > > -- > > David Sewell, Editorial and Technical Manager > > ROTUNDA, The University of Virginia Press > > PO Box 801079, Charlottesville, VA 22904-4318 USA > > Courier: 310 Old Ivy Way, Suite 302, Charlottesville VA 22903 > > Email: dsewell at virginia.edu Tel: +1 434 924 9973 > > Web: > > http://rotunda.upress.virginia.edu/_______________________________________________ > > tei-council mailing list > > tei-council at lists.village.Virginia.EDU > > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > -- David Sewell, Editorial and Technical Manager ROTUNDA, The University of Virginia Press PO Box 801079, Charlottesville, VA 22904-4318 USA Courier: 310 Old Ivy Way, Suite 302, Charlottesville VA 22903 Email: dsewell at virginia.edu Tel: +1 434 924 9973 Web: http://rotunda.upress.virginia.edu/ From laurent.romary at loria.fr Tue Mar 9 11:35:44 2010 From: laurent.romary at loria.fr (Laurent Romary) Date: Tue, 9 Mar 2010 17:35:44 +0100 Subject: [tei-council] virtual hosts for HTML versions of Guidelines In-Reply-To: References: <4B952C18.209@ultraslavonic.info> <4B952DDD.1000403@uleth.ca> <1843A3F9-9B49-47F0-8E33-7439B7221DD5@loria.fr> Message-ID: David: can you take care of this? Thanks a lot, Laurent Le 9 mars 10 ? 16:06, David Sewell a ?crit : > The first step is to contact the U of Virginia network > administrators to > be sure they do not set a limit on the number of aliases associated > with > a machine. If not, I or Shayne Brandon (tei-c.org sysadmin) will > submit > the request and go from there. > > David > > On Tue, 9 Mar 2010, Laurent Romary wrote: > >> I would support Kevin's proposal. And the point you made about >> google is only >> half true. If I do use words which are "language >> independent" (google makes no >> difference between "reference" and "r?f?rence") I may come across >> any version >> of the guidelines; >> >> Since it does not hurt any other functionality and unless someone >> shouts >> loudly in the coming hours, I would suggest that Kevin and David >> proceed >> further with this. >> >> Laurent >> >> >> Le 8 mars 10 ? 18:40, David Sewell a ?crit : >> >>> This is not a proposal that has been floated before. It would be >>> analogous to Wikipedia's use of domains, I guess (en.wikipedia.org, >>> de.wikipedia.org, etc.). >>> >>> Should I inquire of the UVA IT people whether they impose a limit >>> on the >>> number of host aliases they are willing to register in the DNS? >>> Beyond >>> that it would just be a question of writing virtual host entries >>> in the >>> Apache configuration. It would be trivially easy to change the >>> directories to which those entries point later, if we implement a >>> different naming structure. >>> >>> A counterargument might be that it's not really necessary. I just >>> tried >>> a Google search for "r?f?rence bibliographique" with site:www-tei- >>> c.org >>> and not surprisingly the French reference for was the top >>> hit. >>> >>> David >>> >>> On Mon, 8 Mar 2010, O'Donnell, Dan wrote: >>> >>>> Is that not part of the work that David and James have been doing >>>> regarding stable URLs? >>>> >>>> -dan >>>> >>>> Kevin Hawkins wrote: >>>>> Would anyone oppose me asking the folks at Virginia to investigate >>>>> setting up the following virtual hosts: >>>>> >>>>> en.guidelines.tei-c.org >>>>> de.guidelines.tei-c.org >>>>> es.guidelines.tei-c.org >>>>> it.guidelines.tei-c.org >>>>> fr.guidelines.tei-c.org >>>>> ja.guidelines.tei-c.org >>>>> kr.guidelines.tei-c.org >>>>> zh-tw.guidelines.tei-c.org >>>>> >>>>> which would serve the content currently at: >>>>> >>>>> http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ >>>>> http://www.tei-c.org/release/doc/tei-p5-doc/de/html/ >>>>> etc. >>>>> >>>>> I suggest this because right now the only way to search the full >>>>> text of >>>>> the Guidelines -- and only the full text of the Guidelines -- is >>>>> to >>>>> search within the PDF version. If we had a virtual host for each >>>>> languages's HTML version, we could all use our favorite search >>>>> engines >>>>> to search the full text in our language of choice. >>>>> >>>>> Kevin >>>>> _______________________________________________ >>>>> tei-council mailing list >>>>> tei-council at lists.village.Virginia.EDU >>>>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council >>>>> >>>> >>>> >>> >>> -- >>> David Sewell, Editorial and Technical Manager >>> ROTUNDA, The University of Virginia Press >>> PO Box 801079, Charlottesville, VA 22904-4318 USA >>> Courier: 310 Old Ivy Way, Suite 302, Charlottesville VA 22903 >>> Email: dsewell at virginia.edu Tel: +1 434 924 9973 >>> Web: >>> http://rotunda.upress.virginia.edu/_______________________________________________ >>> tei-council mailing list >>> tei-council at lists.village.Virginia.EDU >>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council >> > > -- > David Sewell, Editorial and Technical Manager > ROTUNDA, The University of Virginia Press > PO Box 801079, Charlottesville, VA 22904-4318 USA > Courier: 310 Old Ivy Way, Suite 302, Charlottesville VA 22903 > Email: dsewell at virginia.edu Tel: +1 434 924 9973 > Web: http://rotunda.upress.virginia.edu/ From Laurent.Romary at loria.fr Tue Mar 9 11:53:08 2010 From: Laurent.Romary at loria.fr (Laurent Romary) Date: Tue, 9 Mar 2010 17:53:08 +0100 Subject: [tei-council] a proposal for a change to ODD (copy of ticket I just put in SF) In-Reply-To: References: <4B9561D3.7070407@uleth.ca> <4B956736.8060509@oucs.ox.ac.uk> <12E94F2F-AEFB-4562-A9C5-4F1381CD6FA9@ARTSCI.WUSTL.EDU> <4B9569DF.8000004@oucs.ox.ac.uk> <4B95809B.8060600@oucs.ox.ac.uk> <4B9582FC.4070609@oucs.ox.ac.uk> <4B959165.7070401@oucs.ox.ac.uk> <481A9005-367F-409A-BA60-2C72020CF3E0@oucs.ox.ac.uk> Message-ID: Le 9 mars 10 ? 10:52, Sebastian Rahtz a ?crit : > > On 9 Mar 2010, at 09:45, Laurent Romary wrote: > >> May I mention that I don't see the point of xi:include. We need a >> mechanism wher we can refer to an example anyplace within a document >> with just a reference to it. Something similar to specDesc (egRef?), >> with the appropriate attribute(s) (key or target mechanism) >> > but XInclude allows for that, surely? or, indeed, type="transclude"> I have a bad intuition about this since we may want to add further instructions for the ODD processor rather than relying blindly on an external mechanism (I can hear a famous conundrum in the background...) From dsewell at virginia.edu Tue Mar 9 12:11:31 2010 From: dsewell at virginia.edu (David Sewell) Date: Tue, 9 Mar 2010 12:11:31 -0500 (EST) Subject: [tei-council] Adding virtual hosts for www.tei-c.org (fwd) Message-ID: Council, We have requested the language-specific host aliases (en.guidelines.tei-c.org, etc.), and they should be accessible by tomorrow. However, Shayne points out that unless the hierarchy of the releases is changed, it won't work to make "en.guidelines.tei-c.org" resolve to the directory root of http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ because the PDF Guidelines stored at ../Guidelines.pdf are then inaccessible. (See Shayne's note below.) Shayne proposes as an alternative that "en.guidelines.tei-c.org" point to the document root http://www.tei-c.org/release/doc/tei-p5-doc/en/ which means that the "home page" of the English guidelines as browsable HTML would be addressed as http://en.guidelines.tei-c.org/html/index.html and we could optionally have a redirect rule so that http://en.guidelines.tei-c.org would go to that page. I would suggest this: that we accept Shayne's suggestion, and experiment with the result starting tomorrow (assuming that the DNS aliases are active by then). Then we could tweak as needed before publicly announcing the existence of the new hosts. David ---------- Forwarded message ---------- Date: Tue, 09 Mar 2010 11:10:25 -0500 From: Shayne Brandon To: David Sewell Subject: Re: Adding virtual hosts for www.tei-c.org Hi David I see problems with the proposal already. The relase files aren't structured in a way that makes them work as a document root. For example, if I make the releasee/xxx/en/html/ a document root, the Guidlines.pdf file will be inaccessible because it is a relative link to "../../en/Fuidelines.pdf" Nothing outside the html directory will be accessible if html is the root. To fix, all the Guideline pdf files would need to be moved into the html directories in the master version of these files. I think Sebastian is the source of these files and they get updated every so often by downloading the revised version from his web server. That's where this change would have to take place. Then all the links to the Guidelines.pdf files would need to change from "../../xx/Guidlines.pdf" to "Guidlines.pdf" I advise against handling these problems with the apache configuration. I made the request before I noticed the problems. If the hostname was guidelines.tei-c.org and you used /en, /de, etc as the first part of the url that would eliminate this problem. A url like guidelines.tei-c.org/en could be redirected to guidelines.tei-c.org/en/html/index.html and the links to Guidelines.pdf would still work. Shayne From kevin.s.hawkins at ultraslavonic.info Tue Mar 9 12:21:34 2010 From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins) Date: Tue, 09 Mar 2010 17:21:34 +0000 Subject: [tei-council] Adding virtual hosts for www.tei-c.org (fwd) In-Reply-To: References: Message-ID: <4B96839E.6020108@ultraslavonic.info> This sounds like a good way forward. Thanks for doing this so quickly! On 09/03/2010 17:11, David Sewell wrote: > Council, > > We have requested the language-specific host aliases > (en.guidelines.tei-c.org, etc.), and they should be accessible by > tomorrow. However, Shayne points out that unless the hierarchy of the > releases is changed, it won't work to make "en.guidelines.tei-c.org" > resolve to the directory root of > > http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ > > because the PDF Guidelines stored at ../Guidelines.pdf are then inaccessible. > (See Shayne's note below.) Shayne proposes as an alternative that > "en.guidelines.tei-c.org" point to the document root > > http://www.tei-c.org/release/doc/tei-p5-doc/en/ > > which means that the "home page" of the English guidelines as browsable > HTML would be addressed as > > http://en.guidelines.tei-c.org/html/index.html > > and we could optionally have a redirect rule so that > > http://en.guidelines.tei-c.org > > would go to that page. > > I would suggest this: that we accept Shayne's suggestion, and experiment > with the result starting tomorrow (assuming that the DNS aliases are > active by then). Then we could tweak as needed before publicly > announcing the existence of the new hosts. > > David > > ---------- Forwarded message ---------- > Date: Tue, 09 Mar 2010 11:10:25 -0500 > From: Shayne Brandon > To: David Sewell > Subject: Re: Adding virtual hosts for www.tei-c.org > > Hi David > > I see problems with the proposal already. > > The relase files aren't structured in a way that makes them work as a document > root. > > For example, if I make the releasee/xxx/en/html/ a document root, the > Guidlines.pdf file will be inaccessible because it is a relative link to > "../../en/Fuidelines.pdf" Nothing outside the html directory will be accessible > if html is the root. > > To fix, all the Guideline pdf files would need to be moved into the html > directories in the master version of these files. I think Sebastian is the > source of these files and they get updated every so often by downloading the > revised version from his web server. That's where this change would have to take > place. > > Then all the links to the Guidelines.pdf files would need to change from > "../../xx/Guidlines.pdf" to "Guidlines.pdf" > > I advise against handling these problems with the apache configuration. > > I made the request before I noticed the problems. > > If the hostname was guidelines.tei-c.org and you used /en, /de, etc as the first > part of the url that would eliminate this problem. > > A url like guidelines.tei-c.org/en could be redirected to > guidelines.tei-c.org/en/html/index.html and the links to Guidelines.pdf would > still work. > > Shayne > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council From sebastian.rahtz at oucs.ox.ac.uk Tue Mar 9 12:28:19 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 9 Mar 2010 17:28:19 +0000 Subject: [tei-council] a proposal for a change to ODD (copy of ticket I just put in SF) In-Reply-To: References: <4B9561D3.7070407@uleth.ca> <4B956736.8060509@oucs.ox.ac.uk> <12E94F2F-AEFB-4562-A9C5-4F1381CD6FA9@ARTSCI.WUSTL.EDU> <4B9569DF.8000004@oucs.ox.ac.uk> <4B95809B.8060600@oucs.ox.ac.uk> <4B9582FC.4070609@oucs.ox.ac.uk> <4B959165.7070401@oucs.ox.ac.uk> <481A9005-367F-409A-BA60-2C72020CF3E0@oucs.ox.ac.uk> Message-ID: <2D548A76-14EB-48CD-8361-7F7655F06D56@oucs.ox.ac.uk> On 9 Mar 2010, at 16:53, Laurent Romary wrote: >> but XInclude allows for that, surely? or, indeed, > type="transclude"> > > I have a bad intuition about this since we may want to add further > instructions for the ODD processor rather than relying blindly on an > external mechanism and I say "keep it simple" until you find a concrete reason not to?. but geez, I dont care. -- Sebastian Rahtz (acting) Information and Support Group Manager Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From dsewell at virginia.edu Wed Mar 10 18:33:35 2010 From: dsewell at virginia.edu (David Sewell) Date: Wed, 10 Mar 2010 18:33:35 -0500 (EST) Subject: [tei-council] [TEI-L] application/tei+xml redux (fwd) Message-ID: I have just replied to Brett about his TEI-L message, noting that Council did reverse its original decision and last December approved applying for a MIME type. Cf. http://lists.village.virginia.edu/pipermail/tei-council/2009/011465.html and other messages following. Sigfrid Lundberg had volunteered to determine how to fill out the IANA application but obviously has not done so. Someone on Council or Board should be the formal submitter, but maybe you could delegate Brett to help with completion of the application? David ---------- Forwarded message ---------- Date: Wed, 10 Mar 2010 12:36:51 +0800 From: Brett Zamir To: TEI-L at listserv.brown.edu Subject: [TEI-L] application/tei+xml redux To resurrect an old (and I know, already settled) question, I think I may have found a good use for application/tei+xml after all. I am currently working on proposing/developing a modification of METS which can be used not only to download a set of TEI files in the browser and with stylesheets (as well as XQuery like mentioned in my other recent post, etc.), but also potentially supply XSLT files without TEI or XML, such as TEI's own stylesheets, and allow them to register themselves as content handlers for application/tei+xml content encountered on the web and/or as namespace handlers which could operate within any documents containing the TEI namespace (such as embedded within XHTML). This might even operate at an individual tag level (e.g., to replace native XHTML buttons with one's own HTML5 "canvas"-drawn element or, in the case of TEI, to override the default styling provided by Sebastian's stylesheets for certain tags). Thus, TEI files in the browser could be shown (by default) in one standard format across web pages, at least if they were not pre-styled by the author, with the major bonus of the user not needing to re-download the same standard stylesheets, especially when visiting a new TEI-hosting site, after they had obtained the stylesheets just once from any page as long as it registered itself as a TEI content handler (though since multiple content handlers could be registered, TEI's own stylesheets would not need to be the only choice out there when viewing TEI and users could switch between handlers for specific pages). The overhead of client-side XSL would be obviated greatly by not having to transfer the often large stylesheet files across the web upon each new site visit; the only extra overhead compared to regular XHTML would be the internal conversion made by the browser (which is very little in comparison to network transmission). The manifest file within the file package containing the stylesheets could also indicate an update URL which could be checked for new updates to the stylesheets. I think this could remove the primary barrier to serving TEI directly on the web and having it be directly viewed without long delays. Besides TEI, other experimental or alternative formats like Markdown, ODF, localized XHTML (e.g., http://bahai-library.com/zamir/chintest9.xml? ) could become possible and practical if applied in other browsers and by default. What do people think of this? Brett From laurent.romary at loria.fr Thu Mar 11 02:19:46 2010 From: laurent.romary at loria.fr (Laurent Romary) Date: Thu, 11 Mar 2010 08:19:46 +0100 Subject: [tei-council] Fwd: [TEI-L] application/tei+xml References: Message-ID: <6C4337F2-68CE-450D-9B30-12EF02300517@loria.fr> Dear Sigfrid and Brett, Following a message from Brett on the TEI-L, I would like to ask you if you could give a hand in implementing the already made decision from the council (Cf. http://lists.village.virginia.edu/pipermail/tei-council/2009/011465.html) to proceed with an application/tei+XML MIME type. One would have to fill out a IANA application, and I could well be the formal submitter as council chair. Would you have some time to dedicate to this? Thanks in advance, Laurent > > ---------- Forwarded message ---------- > Date: Wed, 10 Mar 2010 12:36:51 +0800 > From: Brett Zamir > To: TEI-L at listserv.brown.edu > Subject: [TEI-L] application/tei+xml redux > > To resurrect an old (and I know, already settled) question, I think > I may have found a good use for > application/tei+xml after all. > > I am currently working on proposing/developing a modification of > METS which can be used not only to download > a set of TEI files in the browser and with stylesheets (as well as > XQuery like mentioned in my other recent > post, etc.), but also potentially supply XSLT files without TEI or > XML, such as TEI's own stylesheets, and > allow them to register themselves as content handlers for > application/tei+xml content encountered on the web > and/or as namespace handlers which could operate within any > documents containing the TEI namespace (such as > embedded within XHTML). > > This might even operate at an individual tag level (e.g., to replace > native XHTML buttons with one's own > HTML5 "canvas"-drawn element or, in the case of TEI, to override the > default styling provided by Sebastian's > stylesheets for certain tags). > > Thus, TEI files in the browser could be shown (by default) in one > standard format across web pages, at least > if they were not pre-styled by the author, with the major bonus of > the user not needing to re-download the > same standard stylesheets, especially when visiting a new TEI- > hosting site, after they had obtained the > stylesheets just once from any page as long as it registered itself > as a TEI content handler (though since > multiple content handlers could be registered, TEI's own stylesheets > would not need to be the only choice > out there when viewing TEI and users could switch between handlers > for specific pages). The overhead of > client-side XSL would be obviated greatly by not having to transfer > the often large stylesheet files across > the web upon each new site visit; the only extra overhead compared > to regular XHTML would be the internal > conversion made by the browser (which is very little in comparison > to network transmission). > > The manifest file within the file package containing the stylesheets > could also indicate an update URL which > could be checked for new updates to the stylesheets. > > I think this could remove the primary barrier to serving TEI > directly on the web and having it be directly > viewed without long delays. > > Besides TEI, other experimental or alternative formats like > Markdown, ODF, localized XHTML (e.g., > http://bahai-library.com/zamir/chintest9.xml ) could become > possible and practical if applied in other > browsers and by default. > > What do people think of this? > > Brett > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council From laurent.romary at loria.fr Thu Mar 11 05:10:21 2010 From: laurent.romary at loria.fr (Laurent Romary) Date: Thu, 11 Mar 2010 11:10:21 +0100 Subject: [tei-council] [TEI-L] application/tei+xml In-Reply-To: References: , <6C4337F2-68CE-450D-9B30-12EF02300517@loria.fr> Message-ID: <101D33D4-E64B-4456-BC09-F34B13117C22@loria.fr> Thanks a lot! Laurent Le 11 mars 10 ? 10:53, Sigfrid Lundberg a ?crit : > > Hi Laurent, > > Yeah, since I'm one of those who raised the issue I'll have a look > at it next week > > Sigge > > ________________________________________ > Fra: Laurent Romary [laurent.romary at loria.fr] > Sendt: 11. marts 2010 08:19 > Til: Sigfrid Lundberg; Brett Zamir > Cc: TEI Council > Emne: Fwd: [tei-council] [TEI-L] application/tei+xml > > Dear Sigfrid and Brett, > Following a message from Brett on the TEI-L, I would like to ask you > if you could give a hand in implementing the already made decision > from the council (Cf. http://lists.village.virginia.edu/pipermail/tei-council/2009/011465.html) > to proceed with an application/tei+XML MIME type. One would have to > fill out a IANA application, and I could well be the formal submitter > as council chair. > Would you have some time to dedicate to this? > Thanks in advance, > Laurent > >> >> ---------- Forwarded message ---------- >> Date: Wed, 10 Mar 2010 12:36:51 +0800 >> From: Brett Zamir >> To: TEI-L at listserv.brown.edu >> Subject: [TEI-L] application/tei+xml redux >> >> To resurrect an old (and I know, already settled) question, I think >> I may have found a good use for >> application/tei+xml after all. >> >> I am currently working on proposing/developing a modification of >> METS which can be used not only to download >> a set of TEI files in the browser and with stylesheets (as well as >> XQuery like mentioned in my other recent >> post, etc.), but also potentially supply XSLT files without TEI or >> XML, such as TEI's own stylesheets, and >> allow them to register themselves as content handlers for >> application/tei+xml content encountered on the web >> and/or as namespace handlers which could operate within any >> documents containing the TEI namespace (such as >> embedded within XHTML). >> >> This might even operate at an individual tag level (e.g., to replace >> native XHTML buttons with one's own >> HTML5 "canvas"-drawn element or, in the case of TEI, to override the >> default styling provided by Sebastian's >> stylesheets for certain tags). >> >> Thus, TEI files in the browser could be shown (by default) in one >> standard format across web pages, at least >> if they were not pre-styled by the author, with the major bonus of >> the user not needing to re-download the >> same standard stylesheets, especially when visiting a new TEI- >> hosting site, after they had obtained the >> stylesheets just once from any page as long as it registered itself >> as a TEI content handler (though since >> multiple content handlers could be registered, TEI's own stylesheets >> would not need to be the only choice >> out there when viewing TEI and users could switch between handlers >> for specific pages). The overhead of >> client-side XSL would be obviated greatly by not having to transfer >> the often large stylesheet files across >> the web upon each new site visit; the only extra overhead compared >> to regular XHTML would be the internal >> conversion made by the browser (which is very little in comparison >> to network transmission). >> >> The manifest file within the file package containing the stylesheets >> could also indicate an update URL which >> could be checked for new updates to the stylesheets. >> >> I think this could remove the primary barrier to serving TEI >> directly on the web and having it be directly >> viewed without long delays. >> >> Besides TEI, other experimental or alternative formats like >> Markdown, ODF, localized XHTML (e.g., >> http://bahai-library.com/zamir/chintest9.xml ) could become >> possible and practical if applied in other >> browsers and by default. >> >> What do people think of this? >> >> Brett >> _______________________________________________ >> tei-council mailing list >> tei-council at lists.village.Virginia.EDU >> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > From laurent.romary at loria.fr Thu Mar 11 13:40:52 2010 From: laurent.romary at loria.fr (Laurent Romary) Date: Thu, 11 Mar 2010 19:40:52 +0100 Subject: [tei-council] [TEI-L] application/tei+xml In-Reply-To: <4B992EC6.2080901@yahoo.com> References: <6C4337F2-68CE-450D-9B30-12EF02300517@loria.fr> <4B992EC6.2080901@yahoo.com> Message-ID: <6EEB7BCC-FCFB-4096-8114-D03939137F0D@loria.fr> At least stay in the loop with Sigfrid. I let you two do your best to move this foward. Thanks in advance, Laurent Le 11 mars 10 ? 18:56, Brett Zamir a ?crit : > Hello Laurent, > > I'd be happy to try to spell out the use case with which I am best > familiar, but I'm quite swamped at the moment to do much else > (looking for work actually). > > best wishes, > Brett > > On 3/11/2010 3:19 PM, Laurent Romary wrote: >> Dear Sigfrid and Brett, >> Following a message from Brett on the TEI-L, I would like to ask >> you if you could give a hand in implementing the already made >> decision from the council (Cf. http://lists.village.virginia.edu/pipermail/tei-council/2009/011465.html) >> to proceed with an application/tei+XML MIME type. One would have >> to fill out a IANA application, and I could well be the formal >> submitter as council chair. >> Would you have some time to dedicate to this? >> Thanks in advance, >> Laurent >> >>> >>> ---------- Forwarded message ---------- >>> Date: Wed, 10 Mar 2010 12:36:51 +0800 >>> From: Brett Zamir >>> To: TEI-L at listserv.brown.edu >>> Subject: [TEI-L] application/tei+xml redux >>> >>> To resurrect an old (and I know, already settled) question, I >>> think I may have found a good use for >>> application/tei+xml after all. >>> >>> I am currently working on proposing/developing a modification of >>> METS which can be used not only to download >>> a set of TEI files in the browser and with stylesheets (as well as >>> XQuery like mentioned in my other recent >>> post, etc.), but also potentially supply XSLT files without TEI or >>> XML, such as TEI's own stylesheets, and >>> allow them to register themselves as content handlers for >>> application/tei+xml content encountered on the web >>> and/or as namespace handlers which could operate within any >>> documents containing the TEI namespace (such as >>> embedded within XHTML). >>> >>> This might even operate at an individual tag level (e.g., to >>> replace native XHTML buttons with one's own >>> HTML5 "canvas"-drawn element or, in the case of TEI, to override >>> the default styling provided by Sebastian's >>> stylesheets for certain tags). >>> >>> Thus, TEI files in the browser could be shown (by default) in one >>> standard format across web pages, at least >>> if they were not pre-styled by the author, with the major bonus of >>> the user not needing to re-download the >>> same standard stylesheets, especially when visiting a new TEI- >>> hosting site, after they had obtained the >>> stylesheets just once from any page as long as it registered >>> itself as a TEI content handler (though since >>> multiple content handlers could be registered, TEI's own >>> stylesheets would not need to be the only choice >>> out there when viewing TEI and users could switch between handlers >>> for specific pages). The overhead of >>> client-side XSL would be obviated greatly by not having to >>> transfer the often large stylesheet files across >>> the web upon each new site visit; the only extra overhead compared >>> to regular XHTML would be the internal >>> conversion made by the browser (which is very little in comparison >>> to network transmission). >>> >>> The manifest file within the file package containing the >>> stylesheets could also indicate an update URL which >>> could be checked for new updates to the stylesheets. >>> >>> I think this could remove the primary barrier to serving TEI >>> directly on the web and having it be directly >>> viewed without long delays. >>> >>> Besides TEI, other experimental or alternative formats like >>> Markdown, ODF, localized XHTML (e.g., >>> http://bahai-library.com/zamir/chintest9.xml ) could become >>> possible and practical if applied in other >>> browsers and by default. >>> >>> What do people think of this? >>> >>> Brett >>> _______________________________________________ >>> tei-council mailing list >>> tei-council at lists.village.Virginia.EDU >>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council >> >> >> > From laurent.romary at loria.fr Tue Mar 16 07:03:59 2010 From: laurent.romary at loria.fr (Laurent Romary) Date: Tue, 16 Mar 2010 12:03:59 +0100 Subject: [tei-council] app-tei-xml again In-Reply-To: References: Message-ID: Very good. May I ask my colleagues from the council to have a quick look and validate if you feel like this is OK? Cheers, Laurent Le 16 mars 10 ? 11:33, Sigfrid Lundberg a ?crit : > Thank Brett, > > Here is a new version with, I hope, no visible dependencies of the > old docbook RFC > > Cheers > > Sigfrid > ________________________________________ > Fra: Sigfrid Lundberg > Sendt: 16. marts 2010 11:06 > Til: Laurent Romary; Brett Zamir > Cc: TEI Council; Christian S. Vandel > Emne: SV: [tei-council] [TEI-L] application/tei+xml > > Please find attached an early draft to an Internet draft. You can > format it as traditional rfc*.txt or to HTML at http://xml.resource.org/ > > I don't know who should be on the list as authors and so forth. I > hadn't realised that IETF had such a wonderful infrastructure for > writing RFC's and internet drafts > > The goal is a line here http://www.iana.org/assignments/media-types/application/ > > I suppose we need to fill in the form:on http://www.iana.org/cgi-bin/mediatypes.pl > and the draft should be submitted to the IETF > > Yours > > Sigfrid > > ________________________________________ > Fra: Laurent Romary [laurent.romary at loria.fr] > Sendt: 11. marts 2010 19:40 > Til: Brett Zamir > Cc: Sigfrid Lundberg; TEI Council > Emne: Re: [tei-council] [TEI-L] application/tei+xml > > At least stay in the loop with Sigfrid. I let you two do your best to > move this foward. > Thanks in advance, > Laurent > > Le 11 mars 10 ? 18:56, Brett Zamir a ?crit : > >> Hello Laurent, >> >> I'd be happy to try to spell out the use case with which I am best >> familiar, but I'm quite swamped at the moment to do much else >> (looking for work actually). >> >> best wishes, >> Brett >> >> On 3/11/2010 3:19 PM, Laurent Romary wrote: >>> Dear Sigfrid and Brett, >>> Following a message from Brett on the TEI-L, I would like to ask >>> you if you could give a hand in implementing the already made >>> decision from the council (Cf. http://lists.village.virginia.edu/pipermail/tei-council/2009/011465.html) >>> to proceed with an application/tei+XML MIME type. One would have >>> to fill out a IANA application, and I could well be the formal >>> submitter as council chair. >>> Would you have some time to dedicate to this? >>> Thanks in advance, >>> Laurent >>> >>>> >>>> ---------- Forwarded message ---------- >>>> Date: Wed, 10 Mar 2010 12:36:51 +0800 >>>> From: Brett Zamir >>>> To: TEI-L at listserv.brown.edu >>>> Subject: [TEI-L] application/tei+xml redux >>>> >>>> To resurrect an old (and I know, already settled) question, I >>>> think I may have found a good use for >>>> application/tei+xml after all. >>>> >>>> I am currently working on proposing/developing a modification of >>>> METS which can be used not only to download >>>> a set of TEI files in the browser and with stylesheets (as well as >>>> XQuery like mentioned in my other recent >>>> post, etc.), but also potentially supply XSLT files without TEI or >>>> XML, such as TEI's own stylesheets, and >>>> allow them to register themselves as content handlers for >>>> application/tei+xml content encountered on the web >>>> and/or as namespace handlers which could operate within any >>>> documents containing the TEI namespace (such as >>>> embedded within XHTML). >>>> >>>> This might even operate at an individual tag level (e.g., to >>>> replace native XHTML buttons with one's own >>>> HTML5 "canvas"-drawn element or, in the case of TEI, to override >>>> the default styling provided by Sebastian's >>>> stylesheets for certain tags). >>>> >>>> Thus, TEI files in the browser could be shown (by default) in one >>>> standard format across web pages, at least >>>> if they were not pre-styled by the author, with the major bonus of >>>> the user not needing to re-download the >>>> same standard stylesheets, especially when visiting a new TEI- >>>> hosting site, after they had obtained the >>>> stylesheets just once from any page as long as it registered >>>> itself as a TEI content handler (though since >>>> multiple content handlers could be registered, TEI's own >>>> stylesheets would not need to be the only choice >>>> out there when viewing TEI and users could switch between handlers >>>> for specific pages). The overhead of >>>> client-side XSL would be obviated greatly by not having to >>>> transfer the often large stylesheet files across >>>> the web upon each new site visit; the only extra overhead compared >>>> to regular XHTML would be the internal >>>> conversion made by the browser (which is very little in comparison >>>> to network transmission). >>>> >>>> The manifest file within the file package containing the >>>> stylesheets could also indicate an update URL which >>>> could be checked for new updates to the stylesheets. >>>> >>>> I think this could remove the primary barrier to serving TEI >>>> directly on the web and having it be directly >>>> viewed without long delays. >>>> >>>> Besides TEI, other experimental or alternative formats like >>>> Markdown, ODF, localized XHTML (e.g., >>>> http://bahai-library.com/zamir/chintest9.xml ) could become >>>> possible and practical if applied in other >>>> browsers and by default. >>>> >>>> What do people think of this? >>>> >>>> Brett >>>> _______________________________________________ >>>> tei-council mailing list >>>> tei-council at lists.village.Virginia.EDU >>>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council >>> >>> >>> >> > > From laurent.romary at loria.fr Tue Mar 16 07:29:30 2010 From: laurent.romary at loria.fr (Laurent Romary) Date: Tue, 16 Mar 2010 12:29:30 +0100 Subject: [tei-council] app-tei-xml again In-Reply-To: References: Message-ID: <764BFA25-EEED-481D-81C1-AA32B126E61D@loria.fr> OK. The council list does not accept attachments... I had forgotten... sigh. Whoever wants to have a look can ask me directly! Laurent Le 16 mars 10 ? 11:33, Sigfrid Lundberg a ?crit : > Thank Brett, > > Here is a new version with, I hope, no visible dependencies of the > old docbook RFC > > Cheers > > Sigfrid > ________________________________________ > Fra: Sigfrid Lundberg > Sendt: 16. marts 2010 11:06 > Til: Laurent Romary; Brett Zamir > Cc: TEI Council; Christian S. Vandel > Emne: SV: [tei-council] [TEI-L] application/tei+xml > > Please find attached an early draft to an Internet draft. You can > format it as traditional rfc*.txt or to HTML at http://xml.resource.org/ > > I don't know who should be on the list as authors and so forth. I > hadn't realised that IETF had such a wonderful infrastructure for > writing RFC's and internet drafts > > The goal is a line here http://www.iana.org/assignments/media-types/application/ > > I suppose we need to fill in the form:on http://www.iana.org/cgi-bin/mediatypes.pl > and the draft should be submitted to the IETF > > Yours > > Sigfrid > > ________________________________________ > Fra: Laurent Romary [laurent.romary at loria.fr] > Sendt: 11. marts 2010 19:40 > Til: Brett Zamir > Cc: Sigfrid Lundberg; TEI Council > Emne: Re: [tei-council] [TEI-L] application/tei+xml > > At least stay in the loop with Sigfrid. I let you two do your best to > move this foward. > Thanks in advance, > Laurent > > Le 11 mars 10 ? 18:56, Brett Zamir a ?crit : > >> Hello Laurent, >> >> I'd be happy to try to spell out the use case with which I am best >> familiar, but I'm quite swamped at the moment to do much else >> (looking for work actually). >> >> best wishes, >> Brett >> >> On 3/11/2010 3:19 PM, Laurent Romary wrote: >>> Dear Sigfrid and Brett, >>> Following a message from Brett on the TEI-L, I would like to ask >>> you if you could give a hand in implementing the already made >>> decision from the council (Cf. http://lists.village.virginia.edu/pipermail/tei-council/2009/011465.html) >>> to proceed with an application/tei+XML MIME type. One would have >>> to fill out a IANA application, and I could well be the formal >>> submitter as council chair. >>> Would you have some time to dedicate to this? >>> Thanks in advance, >>> Laurent >>> >>>> >>>> ---------- Forwarded message ---------- >>>> Date: Wed, 10 Mar 2010 12:36:51 +0800 >>>> From: Brett Zamir >>>> To: TEI-L at listserv.brown.edu >>>> Subject: [TEI-L] application/tei+xml redux >>>> >>>> To resurrect an old (and I know, already settled) question, I >>>> think I may have found a good use for >>>> application/tei+xml after all. >>>> >>>> I am currently working on proposing/developing a modification of >>>> METS which can be used not only to download >>>> a set of TEI files in the browser and with stylesheets (as well as >>>> XQuery like mentioned in my other recent >>>> post, etc.), but also potentially supply XSLT files without TEI or >>>> XML, such as TEI's own stylesheets, and >>>> allow them to register themselves as content handlers for >>>> application/tei+xml content encountered on the web >>>> and/or as namespace handlers which could operate within any >>>> documents containing the TEI namespace (such as >>>> embedded within XHTML). >>>> >>>> This might even operate at an individual tag level (e.g., to >>>> replace native XHTML buttons with one's own >>>> HTML5 "canvas"-drawn element or, in the case of TEI, to override >>>> the default styling provided by Sebastian's >>>> stylesheets for certain tags). >>>> >>>> Thus, TEI files in the browser could be shown (by default) in one >>>> standard format across web pages, at least >>>> if they were not pre-styled by the author, with the major bonus of >>>> the user not needing to re-download the >>>> same standard stylesheets, especially when visiting a new TEI- >>>> hosting site, after they had obtained the >>>> stylesheets just once from any page as long as it registered >>>> itself as a TEI content handler (though since >>>> multiple content handlers could be registered, TEI's own >>>> stylesheets would not need to be the only choice >>>> out there when viewing TEI and users could switch between handlers >>>> for specific pages). The overhead of >>>> client-side XSL would be obviated greatly by not having to >>>> transfer the often large stylesheet files across >>>> the web upon each new site visit; the only extra overhead compared >>>> to regular XHTML would be the internal >>>> conversion made by the browser (which is very little in comparison >>>> to network transmission). >>>> >>>> The manifest file within the file package containing the >>>> stylesheets could also indicate an update URL which >>>> could be checked for new updates to the stylesheets. >>>> >>>> I think this could remove the primary barrier to serving TEI >>>> directly on the web and having it be directly >>>> viewed without long delays. >>>> >>>> Besides TEI, other experimental or alternative formats like >>>> Markdown, ODF, localized XHTML (e.g., >>>> http://bahai-library.com/zamir/chintest9.xml ) could become >>>> possible and practical if applied in other >>>> browsers and by default. >>>> >>>> What do people think of this? >>>> >>>> Brett >>>> _______________________________________________ >>>> tei-council mailing list >>>> tei-council at lists.village.Virginia.EDU >>>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council >>> >>> >>> >> > > From dsewell at virginia.edu Tue Mar 16 10:30:33 2010 From: dsewell at virginia.edu (David Sewell) Date: Tue, 16 Mar 2010 10:30:33 -0400 (EDT) Subject: [tei-council] Attachment test -- ignore Message-ID: List should be accepting attachments except .exe, .bat, etc. There should be a small XML file attached. -- David Sewell, Editorial and Technical Manager ROTUNDA, The University of Virginia Press PO Box 801079, Charlottesville, VA 22904-4318 USA Courier: 310 Old Ivy Way, Suite 302, Charlottesville VA 22903 Email: dsewell at virginia.edu Tel: +1 434 924 9973 Web: http://rotunda.upress.virginia.edu/ -------------- next part -------------- A non-text attachment was scrubbed... Name: test.xml Type: application/xml Size: 79 bytes Desc: Url : http://lists.village.Virginia.EDU/pipermail/tei-council/attachments/20100316/12357e78/attachment.rdf From laurent.romary at loria.fr Tue Mar 16 12:46:29 2010 From: laurent.romary at loria.fr (Laurent Romary) Date: Tue, 16 Mar 2010 17:46:29 +0100 Subject: [tei-council] Fwd: SV: SV: app-tei-xml again References: Message-ID: <9E6F6C47-8E75-4052-AE38-8F76FC0B1C89@loria.fr> I make a test with the new configuration. Laurent D?but du message r?exp?di? : > De : Sigfrid Lundberg > Date : 16 mars 2010 14:08:05 GMT+01:00 > ? : Brett Zamir > Cc : Kevin Hawkins , Laurent > Romary , "Christian S. Vandel" > Objet : SV: SV: [tei-council] app-tei-xml again > > Here is a version including the revisions I made in response to the > comments by Kevin. > > I'm not mentioning the namespace problem at all. First, this is > mostly a problem for people who will use TEI in REST based web > services, and they will almost certainly be TEI P5+ Then, this will > be a request for comments, so someone knowledgeable could comment > if they feel there is need for it ;-) > > English isn't my native language, so if there's need for correcting > my pidgin, please do. > > Yours > > Sigfrid > > > > ________________________________________ > Fra: Brett Zamir [brettz9 at yahoo.com] > Sendt: 16. marts 2010 13:36 > Til: Sigfrid Lundberg > Cc: Kevin Hawkins; Laurent Romary; Christian S. Vandel > Emne: Re: SV: [tei-council] app-tei-xml again > > I guess the content-type is meant to give it away, but a lot of web > processing tools may rely on DOM, XPath, etc. methods which expect to > find the TEI namespace... So I wonder whether limiting to P5 and > beyond > may be better? TEI Lite (P5) will be supported if TEI is supported > (managing the full tag set of P5 in at least a generic (text-based) > way > should not be problematic, e.g., if we made a browser extension to > optionally transform a document with the TEI content type but > without an > attached stylesheet using the default TEI stylesheets behind the scene > to render it)... > > best wishes, > Brett > > On 3/16/2010 8:27 PM, Sigfrid Lundberg wrote: >> 1. I agree that there is no reason to exclude P4 and earlier. I've >> changed my copy of the document >> 2. I've changed the reference to http://www.tei-c.org/Guidelines/ >> (which reflects 1.) >> 3. Added the suffix tei >> 4. Changed Tei to TEI >> >> I don't think there's any problems with TEI lite, they can be >> parsed by any TEI aware software. There might be problems mixing >> TEI.2 and TEI though. >> >> Yours >> >> Sigge >> ________________________________________ >> Fra: Kevin Hawkins [kevin.s.hawkins at ultraslavonic.info] >> Sendt: 16. marts 2010 12:41 >> Til: Laurent Romary >> Cc: Sigfrid Lundberg; Christian S. Vandel; Brett Zamir >> Emne: Re: [tei-council] app-tei-xml again >> >> A few notes from a TEI Council member ... >> >> In the Encoding considerations, change "Tei" --> "TEI" >> >> The Published specifications says this MIME type is for documents >> encoded according to P5 or later. Do we really want to exclude any >> P4 >> documents in XML? What about XML documents in TEI Lite or another >> TEI >> customization? >> >> Maybe the Normative References should simply point to >> http://www.tei-c.org/Guidelines/ ? >> >> Under additional information, you might note that some people use the >> file extension ".tei". However, you're entirely right that ".xml" is >> the most common. >> >> --Kevin >> >> On 16/03/2010 11:29, Laurent Romary wrote: >> >>> OK. The council list does not accept attachments... I had >>> forgotten... >>> sigh. >>> Whoever wants to have a look can ask me directly! >>> Laurent >>> >>> >>> Le 16 mars 10 ? 11:33, Sigfrid Lundberg a ?crit : >>> >>> >>>> Thank Brett, >>>> >>>> Here is a new version with, I hope, no visible dependencies of the >>>> old docbook RFC >>>> >>>> Cheers >>>> >>>> Sigfrid >>>> ________________________________________ >>>> Fra: Sigfrid Lundberg >>>> Sendt: 16. marts 2010 11:06 >>>> Til: Laurent Romary; Brett Zamir >>>> Cc: TEI Council; Christian S. Vandel >>>> Emne: SV: [tei-council] [TEI-L] application/tei+xml >>>> >>>> Please find attached an early draft to an Internet draft. You can >>>> format it as traditional rfc*.txt or to HTML at http://xml.resource.org/ >>>> >>>> I don't know who should be on the list as authors and so forth. I >>>> hadn't realised that IETF had such a wonderful infrastructure for >>>> writing RFC's and internet drafts >>>> >>>> The goal is a line here http://www.iana.org/assignments/media-types/application/ >>>> >>>> I suppose we need to fill in the form:on http://www.iana.org/cgi-bin/mediatypes.pl >>>> and the draft should be submitted to the IETF >>>> >>>> Yours >>>> >>>> Sigfrid >>>> >>>> ________________________________________ >>>> Fra: Laurent Romary [laurent.romary at loria.fr] >>>> Sendt: 11. marts 2010 19:40 >>>> Til: Brett Zamir >>>> Cc: Sigfrid Lundberg; TEI Council >>>> Emne: Re: [tei-council] [TEI-L] application/tei+xml >>>> >>>> At least stay in the loop with Sigfrid. I let you two do your >>>> best to >>>> move this foward. >>>> Thanks in advance, >>>> Laurent >>>> >>>> Le 11 mars 10 ? 18:56, Brett Zamir a ?crit : >>>> >>>> >>>>> Hello Laurent, >>>>> >>>>> I'd be happy to try to spell out the use case with which I am best >>>>> familiar, but I'm quite swamped at the moment to do much else >>>>> (looking for work actually). >>>>> >>>>> best wishes, >>>>> Brett >>>>> >>>>> On 3/11/2010 3:19 PM, Laurent Romary wrote: >>>>> >>>>>> Dear Sigfrid and Brett, >>>>>> Following a message from Brett on the TEI-L, I would like to ask >>>>>> you if you could give a hand in implementing the already made >>>>>> decision from the council (Cf. http://lists.village.virginia.edu/pipermail/tei-council/2009/011465.html) >>>>>> to proceed with an application/tei+XML MIME type. One would have >>>>>> to fill out a IANA application, and I could well be the formal >>>>>> submitter as council chair. >>>>>> Would you have some time to dedicate to this? >>>>>> Thanks in advance, >>>>>> Laurent >>>>>> >>>>>> >>>>>>> ---------- Forwarded message ---------- >>>>>>> Date: Wed, 10 Mar 2010 12:36:51 +0800 >>>>>>> From: Brett Zamir >>>>>>> To: TEI-L at listserv.brown.edu >>>>>>> Subject: [TEI-L] application/tei+xml redux >>>>>>> >>>>>>> To resurrect an old (and I know, already settled) question, I >>>>>>> think I may have found a good use for >>>>>>> application/tei+xml after all. >>>>>>> >>>>>>> I am currently working on proposing/developing a modification of >>>>>>> METS which can be used not only to download >>>>>>> a set of TEI files in the browser and with stylesheets (as >>>>>>> well as >>>>>>> XQuery like mentioned in my other recent >>>>>>> post, etc.), but also potentially supply XSLT files without >>>>>>> TEI or >>>>>>> XML, such as TEI's own stylesheets, and >>>>>>> allow them to register themselves as content handlers for >>>>>>> application/tei+xml content encountered on the web >>>>>>> and/or as namespace handlers which could operate within any >>>>>>> documents containing the TEI namespace (such as >>>>>>> embedded within XHTML). >>>>>>> >>>>>>> This might even operate at an individual tag level (e.g., to >>>>>>> replace native XHTML buttons with one's own >>>>>>> HTML5 "canvas"-drawn element or, in the case of TEI, to override >>>>>>> the default styling provided by Sebastian's >>>>>>> stylesheets for certain tags). >>>>>>> >>>>>>> Thus, TEI files in the browser could be shown (by default) in >>>>>>> one >>>>>>> standard format across web pages, at least >>>>>>> if they were not pre-styled by the author, with the major >>>>>>> bonus of >>>>>>> the user not needing to re-download the >>>>>>> same standard stylesheets, especially when visiting a new TEI- >>>>>>> hosting site, after they had obtained the >>>>>>> stylesheets just once from any page as long as it registered >>>>>>> itself as a TEI content handler (though since >>>>>>> multiple content handlers could be registered, TEI's own >>>>>>> stylesheets would not need to be the only choice >>>>>>> out there when viewing TEI and users could switch between >>>>>>> handlers >>>>>>> for specific pages). The overhead of >>>>>>> client-side XSL would be obviated greatly by not having to >>>>>>> transfer the often large stylesheet files across >>>>>>> the web upon each new site visit; the only extra overhead >>>>>>> compared >>>>>>> to regular XHTML would be the internal >>>>>>> conversion made by the browser (which is very little in >>>>>>> comparison >>>>>>> to network transmission). >>>>>>> >>>>>>> The manifest file within the file package containing the >>>>>>> stylesheets could also indicate an update URL which >>>>>>> could be checked for new updates to the stylesheets. >>>>>>> >>>>>>> I think this could remove the primary barrier to serving TEI >>>>>>> directly on the web and having it be directly >>>>>>> viewed without long delays. >>>>>>> >>>>>>> Besides TEI, other experimental or alternative formats like >>>>>>> Markdown, ODF, localized XHTML (e.g., >>>>>>> http://bahai-library.com/zamir/chintest9.xml ) could become >>>>>>> possible and practical if applied in other >>>>>>> browsers and by default. >>>>>>> >>>>>>> What do people think of this? >>>>>>> >>>>>>> Brett >>>>>>> _______________________________________________ >>>>>>> tei-council mailing list >>>>>>> tei-council at lists.village.Virginia.EDU >>>>>>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council >>>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> >>> _______________________________________________ >>> tei-council mailing list >>> tei-council at lists.village.Virginia.EDU >>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council >>> >> >> > From mholmes at uvic.ca Tue Mar 16 13:11:49 2010 From: mholmes at uvic.ca (Martin Holmes) Date: Tue, 16 Mar 2010 10:11:49 -0700 Subject: [tei-council] Fwd: SV: SV: app-tei-xml again In-Reply-To: <9E6F6C47-8E75-4052-AE38-8F76FC0B1C89@loria.fr> References: <9E6F6C47-8E75-4052-AE38-8F76FC0B1C89@loria.fr> Message-ID: <4B9FBBD5.4050006@uvic.ca> A bit of feedback: This bit: "In order to increase the possibilities for generic XML processing this document defines the 'application/tei+xml' in accordance with RFC3023." either "the" should go: "...this document defines 'application/tei+xml'..." or a noun should be supplied : "...this document defines 'application/tei+xml' mediatype..." In this bit: "TEI elements may refer to arbitrary URIs. Hence the security issues of RFC , section 7, applies." "applies" should be "apply" (the subject is "issues"). Hope this helps, Martin Laurent Romary wrote: > I make a test with the new configuration. > Laurent > > D?but du message r?exp?di? : > >> *De : *Sigfrid Lundberg > >> *Date : *16 mars 2010 14:08:05 GMT+01:00 >> *? : *Brett Zamir > >> *Cc : *Kevin Hawkins > >, Laurent Romary >> >, "Christian >> S. Vandel" > >> *Objet : **SV: SV: [tei-council] app-tei-xml again* >> >> Here is a version including the revisions I made in response to the >> comments by Kevin. >> >> I'm not mentioning the namespace problem at all. First, this is mostly >> a problem for people who will use TEI in REST based web services, and >> they will almost certainly be TEI P5+ Then, this will be a request >> for comments, so someone knowledgeable could comment if they feel >> there is need for it ;-) >> >> English isn't my native language, so if there's need for correcting my >> pidgin, please do. >> >> Yours >> >> Sigfrid >> >> >> >> ________________________________________ >> Fra: Brett Zamir [brettz9 at yahoo.com ] >> Sendt: 16. marts 2010 13:36 >> Til: Sigfrid Lundberg >> Cc: Kevin Hawkins; Laurent Romary; Christian S. Vandel >> Emne: Re: SV: [tei-council] app-tei-xml again >> >> I guess the content-type is meant to give it away, but a lot of web >> processing tools may rely on DOM, XPath, etc. methods which expect to >> find the TEI namespace... So I wonder whether limiting to P5 and beyond >> may be better? TEI Lite (P5) will be supported if TEI is supported >> (managing the full tag set of P5 in at least a generic (text-based) way >> should not be problematic, e.g., if we made a browser extension to >> optionally transform a document with the TEI content type but without an >> attached stylesheet using the default TEI stylesheets behind the scene >> to render it)... >> >> best wishes, >> Brett >> >> On 3/16/2010 8:27 PM, Sigfrid Lundberg wrote: >>> 1. I agree that there is no reason to exclude P4 and earlier. I've >>> changed my copy of the document >>> 2. I've changed the reference to http://www.tei-c.org/Guidelines/ >>> (which reflects 1.) >>> 3. Added the suffix tei >>> 4. Changed Tei to TEI >>> >>> I don't think there's any problems with TEI lite, they can be parsed >>> by any TEI aware software. There might be problems mixing TEI.2 and >>> TEI though. >>> >>> Yours >>> >>> Sigge >>> ________________________________________ >>> Fra: Kevin Hawkins [kevin.s.hawkins at ultraslavonic.info >>> ] >>> Sendt: 16. marts 2010 12:41 >>> Til: Laurent Romary >>> Cc: Sigfrid Lundberg; Christian S. Vandel; Brett Zamir >>> Emne: Re: [tei-council] app-tei-xml again >>> >>> A few notes from a TEI Council member ... >>> >>> In the Encoding considerations, change "Tei" --> "TEI" >>> >>> The Published specifications says this MIME type is for documents >>> encoded according to P5 or later. Do we really want to exclude any P4 >>> documents in XML? What about XML documents in TEI Lite or another TEI >>> customization? >>> >>> Maybe the Normative References should simply point to >>> http://www.tei-c.org/Guidelines/ ? >>> >>> Under additional information, you might note that some people use the >>> file extension ".tei". However, you're entirely right that ".xml" is >>> the most common. >>> >>> --Kevin >>> >>> On 16/03/2010 11:29, Laurent Romary wrote: >>> >>>> OK. The council list does not accept attachments... I had forgotten... >>>> sigh. >>>> Whoever wants to have a look can ask me directly! >>>> Laurent >>>> >>>> >>>> Le 16 mars 10 ? 11:33, Sigfrid Lundberg a ?crit : >>>> >>>> >>>>> Thank Brett, >>>>> >>>>> Here is a new version with, I hope, no visible dependencies of the >>>>> old docbook RFC >>>>> >>>>> Cheers >>>>> >>>>> Sigfrid >>>>> ________________________________________ >>>>> Fra: Sigfrid Lundberg >>>>> Sendt: 16. marts 2010 11:06 >>>>> Til: Laurent Romary; Brett Zamir >>>>> Cc: TEI Council; Christian S. Vandel >>>>> Emne: SV: [tei-council] [TEI-L] application/tei+xml >>>>> >>>>> Please find attached an early draft to an Internet draft. You can >>>>> format it as traditional rfc*.txt or to HTML at >>>>> http://xml.resource.org/ >>>>> >>>>> I don't know who should be on the list as authors and so forth. I >>>>> hadn't realised that IETF had such a wonderful infrastructure for >>>>> writing RFC's and internet drafts >>>>> >>>>> The goal is a line here >>>>> http://www.iana.org/assignments/media-types/application/ >>>>> >>>>> I suppose we need to fill in the form:on >>>>> http://www.iana.org/cgi-bin/mediatypes.pl >>>>> and the draft should be submitted to the IETF >>>>> >>>>> Yours >>>>> >>>>> Sigfrid >>>>> >>>>> ________________________________________ >>>>> Fra: Laurent Romary [laurent.romary at loria.fr >>>>> ] >>>>> Sendt: 11. marts 2010 19:40 >>>>> Til: Brett Zamir >>>>> Cc: Sigfrid Lundberg; TEI Council >>>>> Emne: Re: [tei-council] [TEI-L] application/tei+xml >>>>> >>>>> At least stay in the loop with Sigfrid. I let you two do your best to >>>>> move this foward. >>>>> Thanks in advance, >>>>> Laurent >>>>> >>>>> Le 11 mars 10 ? 18:56, Brett Zamir a ?crit : >>>>> >>>>> >>>>>> Hello Laurent, >>>>>> >>>>>> I'd be happy to try to spell out the use case with which I am best >>>>>> familiar, but I'm quite swamped at the moment to do much else >>>>>> (looking for work actually). >>>>>> >>>>>> best wishes, >>>>>> Brett >>>>>> >>>>>> On 3/11/2010 3:19 PM, Laurent Romary wrote: >>>>>> >>>>>>> Dear Sigfrid and Brett, >>>>>>> Following a message from Brett on the TEI-L, I would like to ask >>>>>>> you if you could give a hand in implementing the already made >>>>>>> decision from the council (Cf. >>>>>>> http://lists.village.virginia.edu/pipermail/tei-council/2009/011465.html) >>>>>>> to proceed with an application/tei+XML MIME type. One would have >>>>>>> to fill out a IANA application, and I could well be the formal >>>>>>> submitter as council chair. >>>>>>> Would you have some time to dedicate to this? >>>>>>> Thanks in advance, >>>>>>> Laurent >>>>>>> >>>>>>> >>>>>>>> ---------- Forwarded message ---------- >>>>>>>> Date: Wed, 10 Mar 2010 12:36:51 +0800 >>>>>>>> From: Brett Zamir> >>>>>>>> To: TEI-L at listserv.brown.edu >>>>>>>> Subject: [TEI-L] application/tei+xml redux >>>>>>>> >>>>>>>> To resurrect an old (and I know, already settled) question, I >>>>>>>> think I may have found a good use for >>>>>>>> application/tei+xml after all. >>>>>>>> >>>>>>>> I am currently working on proposing/developing a modification of >>>>>>>> METS which can be used not only to download >>>>>>>> a set of TEI files in the browser and with stylesheets (as well as >>>>>>>> XQuery like mentioned in my other recent >>>>>>>> post, etc.), but also potentially supply XSLT files without TEI or >>>>>>>> XML, such as TEI's own stylesheets, and >>>>>>>> allow them to register themselves as content handlers for >>>>>>>> application/tei+xml content encountered on the web >>>>>>>> and/or as namespace handlers which could operate within any >>>>>>>> documents containing the TEI namespace (such as >>>>>>>> embedded within XHTML). >>>>>>>> >>>>>>>> This might even operate at an individual tag level (e.g., to >>>>>>>> replace native XHTML buttons with one's own >>>>>>>> HTML5 "canvas"-drawn element or, in the case of TEI, to override >>>>>>>> the default styling provided by Sebastian's >>>>>>>> stylesheets for certain tags). >>>>>>>> >>>>>>>> Thus, TEI files in the browser could be shown (by default) in one >>>>>>>> standard format across web pages, at least >>>>>>>> if they were not pre-styled by the author, with the major bonus of >>>>>>>> the user not needing to re-download the >>>>>>>> same standard stylesheets, especially when visiting a new TEI- >>>>>>>> hosting site, after they had obtained the >>>>>>>> stylesheets just once from any page as long as it registered >>>>>>>> itself as a TEI content handler (though since >>>>>>>> multiple content handlers could be registered, TEI's own >>>>>>>> stylesheets would not need to be the only choice >>>>>>>> out there when viewing TEI and users could switch between handlers >>>>>>>> for specific pages). The overhead of >>>>>>>> client-side XSL would be obviated greatly by not having to >>>>>>>> transfer the often large stylesheet files across >>>>>>>> the web upon each new site visit; the only extra overhead compared >>>>>>>> to regular XHTML would be the internal >>>>>>>> conversion made by the browser (which is very little in comparison >>>>>>>> to network transmission). >>>>>>>> >>>>>>>> The manifest file within the file package containing the >>>>>>>> stylesheets could also indicate an update URL which >>>>>>>> could be checked for new updates to the stylesheets. >>>>>>>> >>>>>>>> I think this could remove the primary barrier to serving TEI >>>>>>>> directly on the web and having it be directly >>>>>>>> viewed without long delays. >>>>>>>> >>>>>>>> Besides TEI, other experimental or alternative formats like >>>>>>>> Markdown, ODF, localized XHTML (e.g., >>>>>>>> http://bahai-library.com/zamir/chintest9.xml ) could become >>>>>>>> possible and practical if applied in other >>>>>>>> browsers and by default. >>>>>>>> >>>>>>>> What do people think of this? >>>>>>>> >>>>>>>> Brett >>>>>>>> _______________________________________________ >>>>>>>> tei-council mailing list >>>>>>>> tei-council at lists.village.Virginia.EDU >>>>>>>> >>>>>>>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>> _______________________________________________ >>>> tei-council mailing list >>>> tei-council at lists.village.Virginia.EDU >>>> >>>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council >>>> >>> >>> >> > > ------------------------------------------------------------------------ > > -- Martin Holmes University of Victoria Humanities Computing and Media Centre (mholmes at uvic.ca) Half-Baked Software, Inc. (mholmes at halfbakedsoftware.com) martin at mholmes.com From bbarney2 at unlnotes.unl.edu Tue Mar 16 14:42:13 2010 From: bbarney2 at unlnotes.unl.edu (Brett Barney) Date: Tue, 16 Mar 2010 13:42:13 -0500 Subject: [tei-council] Fwd: SV: SV: app-tei-xml again In-Reply-To: <4B9FBBD5.4050006@uvic.ca> References: <9E6F6C47-8E75-4052-AE38-8F76FC0B1C89@loria.fr> <4B9FBBD5.4050006@uvic.ca> Message-ID: Just wanted to note that Laurent's attachment didn't come through here, though I take it that it did for Martin. In David's test post I got the attachment, though . . . . Brett |------------> | From: | |------------> >--------------------------------------------------------------------------------------------------------------------------------------------------| |Martin Holmes | >--------------------------------------------------------------------------------------------------------------------------------------------------| |------------> | To: | |------------> >--------------------------------------------------------------------------------------------------------------------------------------------------| |TEI Council | >--------------------------------------------------------------------------------------------------------------------------------------------------| |------------> | Date: | |------------> >--------------------------------------------------------------------------------------------------------------------------------------------------| |03/16/2010 12:11 PM | >--------------------------------------------------------------------------------------------------------------------------------------------------| |------------> | Subject: | |------------> >--------------------------------------------------------------------------------------------------------------------------------------------------| |Re: [tei-council] Fwd: SV: SV: app-tei-xml again | >--------------------------------------------------------------------------------------------------------------------------------------------------| A bit of feedback: This bit: "In order to increase the possibilities for generic XML processing this document defines the 'application/tei+xml' in accordance with RFC3023." either "the" should go: "...this document defines 'application/tei+xml'..." or a noun should be supplied : "...this document defines 'application/tei+xml' mediatype..." In this bit: "TEI elements may refer to arbitrary URIs. Hence the security issues of RFC , section 7, applies." "applies" should be "apply" (the subject is "issues"). Hope this helps, Martin Laurent Romary wrote: > I make a test with the new configuration. > Laurent > > D?but du message r?exp?di? : > >> *De : *Sigfrid Lundberg > >> *Date : *16 mars 2010 14:08:05 GMT+01:00 >> *? : *Brett Zamir > >> *Cc : *Kevin Hawkins > >, Laurent Romary >> >, "Christian >> S. Vandel" > >> *Objet : **SV: SV: [tei-council] app-tei-xml again* >> >> Here is a version including the revisions I made in response to the >> comments by Kevin. >> >> I'm not mentioning the namespace problem at all. First, this is mostly >> a problem for people who will use TEI in REST based web services, and >> they will almost certainly be TEI P5+ Then, this will be a request >> for comments, so someone knowledgeable could comment if they feel >> there is need for it ;-) >> >> English isn't my native language, so if there's need for correcting my >> pidgin, please do. >> >> Yours >> >> Sigfrid >> >> >> >> ________________________________________ >> Fra: Brett Zamir [brettz9 at yahoo.com ] >> Sendt: 16. marts 2010 13:36 >> Til: Sigfrid Lundberg >> Cc: Kevin Hawkins; Laurent Romary; Christian S. Vandel >> Emne: Re: SV: [tei-council] app-tei-xml again >> >> I guess the content-type is meant to give it away, but a lot of web >> processing tools may rely on DOM, XPath, etc. methods which expect to >> find the TEI namespace... So I wonder whether limiting to P5 and beyond >> may be better? TEI Lite (P5) will be supported if TEI is supported >> (managing the full tag set of P5 in at least a generic (text-based) way >> should not be problematic, e.g., if we made a browser extension to >> optionally transform a document with the TEI content type but without an >> attached stylesheet using the default TEI stylesheets behind the scene >> to render it)... >> >> best wishes, >> Brett >> >> On 3/16/2010 8:27 PM, Sigfrid Lundberg wrote: >>> 1. I agree that there is no reason to exclude P4 and earlier. I've >>> changed my copy of the document >>> 2. I've changed the reference to http://www.tei-c.org/Guidelines/ >>> (which reflects 1.) >>> 3. Added the suffix tei >>> 4. Changed Tei to TEI >>> >>> I don't think there's any problems with TEI lite, they can be parsed >>> by any TEI aware software. There might be problems mixing TEI.2 and >>> TEI though. >>> >>> Yours >>> >>> Sigge >>> ________________________________________ >>> Fra: Kevin Hawkins [kevin.s.hawkins at ultraslavonic.info >>> ] >>> Sendt: 16. marts 2010 12:41 >>> Til: Laurent Romary >>> Cc: Sigfrid Lundberg; Christian S. Vandel; Brett Zamir >>> Emne: Re: [tei-council] app-tei-xml again >>> >>> A few notes from a TEI Council member ... >>> >>> In the Encoding considerations, change "Tei" --> "TEI" >>> >>> The Published specifications says this MIME type is for documents >>> encoded according to P5 or later. Do we really want to exclude any P4 >>> documents in XML? What about XML documents in TEI Lite or another TEI >>> customization? >>> >>> Maybe the Normative References should simply point to >>> http://www.tei-c.org/Guidelines/ ? >>> >>> Under additional information, you might note that some people use the >>> file extension ".tei". However, you're entirely right that ".xml" is >>> the most common. >>> >>> --Kevin >>> >>> On 16/03/2010 11:29, Laurent Romary wrote: >>> >>>> OK. The council list does not accept attachments... I had forgotten... >>>> sigh. >>>> Whoever wants to have a look can ask me directly! >>>> Laurent >>>> >>>> >>>> Le 16 mars 10 ? 11:33, Sigfrid Lundberg a ?crit : >>>> >>>> >>>>> Thank Brett, >>>>> >>>>> Here is a new version with, I hope, no visible dependencies of the >>>>> old docbook RFC >>>>> >>>>> Cheers >>>>> >>>>> Sigfrid >>>>> ________________________________________ >>>>> Fra: Sigfrid Lundberg >>>>> Sendt: 16. marts 2010 11:06 >>>>> Til: Laurent Romary; Brett Zamir >>>>> Cc: TEI Council; Christian S. Vandel >>>>> Emne: SV: [tei-council] [TEI-L] application/tei+xml >>>>> >>>>> Please find attached an early draft to an Internet draft. You can >>>>> format it as traditional rfc*.txt or to HTML at >>>>> http://xml.resource.org/ >>>>> >>>>> I don't know who should be on the list as authors and so forth. I >>>>> hadn't realised that IETF had such a wonderful infrastructure for >>>>> writing RFC's and internet drafts >>>>> >>>>> The goal is a line here >>>>> http://www.iana.org/assignments/media-types/application/ >>>>> >>>>> I suppose we need to fill in the form:on >>>>> http://www.iana.org/cgi-bin/mediatypes.pl >>>>> and the draft should be submitted to the IETF >>>>> >>>>> Yours >>>>> >>>>> Sigfrid >>>>> >>>>> ________________________________________ >>>>> Fra: Laurent Romary [laurent.romary at loria.fr >>>>> ] >>>>> Sendt: 11. marts 2010 19:40 >>>>> Til: Brett Zamir >>>>> Cc: Sigfrid Lundberg; TEI Council >>>>> Emne: Re: [tei-council] [TEI-L] application/tei+xml >>>>> >>>>> At least stay in the loop with Sigfrid. I let you two do your best to >>>>> move this foward. >>>>> Thanks in advance, >>>>> Laurent >>>>> >>>>> Le 11 mars 10 ? 18:56, Brett Zamir a ?crit : >>>>> >>>>> >>>>>> Hello Laurent, >>>>>> >>>>>> I'd be happy to try to spell out the use case with which I am best >>>>>> familiar, but I'm quite swamped at the moment to do much else >>>>>> (looking for work actually). >>>>>> >>>>>> best wishes, >>>>>> Brett >>>>>> >>>>>> On 3/11/2010 3:19 PM, Laurent Romary wrote: >>>>>> >>>>>>> Dear Sigfrid and Brett, >>>>>>> Following a message from Brett on the TEI-L, I would like to ask >>>>>>> you if you could give a hand in implementing the already made >>>>>>> decision from the council (Cf. >>>>>>> http://lists.village.virginia.edu/pipermail/tei-council/2009/011465.html) >>>>>>> to proceed with an application/tei+XML MIME type. One would have >>>>>>> to fill out a IANA application, and I could well be the formal >>>>>>> submitter as council chair. >>>>>>> Would you have some time to dedicate to this? >>>>>>> Thanks in advance, >>>>>>> Laurent >>>>>>> >>>>>>> >>>>>>>> ---------- Forwarded message ---------- >>>>>>>> Date: Wed, 10 Mar 2010 12:36:51 +0800 >>>>>>>> From: Brett Zamir> >>>>>>>> To: TEI-L at listserv.brown.edu >>>>>>>> Subject: [TEI-L] application/tei+xml redux >>>>>>>> >>>>>>>> To resurrect an old (and I know, already settled) question, I >>>>>>>> think I may have found a good use for >>>>>>>> application/tei+xml after all. >>>>>>>> >>>>>>>> I am currently working on proposing/developing a modification of >>>>>>>> METS which can be used not only to download >>>>>>>> a set of TEI files in the browser and with stylesheets (as well as >>>>>>>> XQuery like mentioned in my other recent >>>>>>>> post, etc.), but also potentially supply XSLT files without TEI or >>>>>>>> XML, such as TEI's own stylesheets, and >>>>>>>> allow them to register themselves as content handlers for >>>>>>>> application/tei+xml content encountered on the web >>>>>>>> and/or as namespace handlers which could operate within any >>>>>>>> documents containing the TEI namespace (such as >>>>>>>> embedded within XHTML). >>>>>>>> >>>>>>>> This might even operate at an individual tag level (e.g., to >>>>>>>> replace native XHTML buttons with one's own >>>>>>>> HTML5 "canvas"-drawn element or, in the case of TEI, to override >>>>>>>> the default styling provided by Sebastian's >>>>>>>> stylesheets for certain tags). >>>>>>>> >>>>>>>> Thus, TEI files in the browser could be shown (by default) in one >>>>>>>> standard format across web pages, at least >>>>>>>> if they were not pre-styled by the author, with the major bonus of >>>>>>>> the user not needing to re-download the >>>>>>>> same standard stylesheets, especially when visiting a new TEI- >>>>>>>> hosting site, after they had obtained the >>>>>>>> stylesheets just once from any page as long as it registered >>>>>>>> itself as a TEI content handler (though since >>>>>>>> multiple content handlers could be registered, TEI's own >>>>>>>> stylesheets would not need to be the only choice >>>>>>>> out there when viewing TEI and users could switch between handlers >>>>>>>> for specific pages). The overhead of >>>>>>>> client-side XSL would be obviated greatly by not having to >>>>>>>> transfer the often large stylesheet files across >>>>>>>> the web upon each new site visit; the only extra overhead compared >>>>>>>> to regular XHTML would be the internal >>>>>>>> conversion made by the browser (which is very little in comparison >>>>>>>> to network transmission). >>>>>>>> >>>>>>>> The manifest file within the file package containing the >>>>>>>> stylesheets could also indicate an update URL which >>>>>>>> could be checked for new updates to the stylesheets. >>>>>>>> >>>>>>>> I think this could remove the primary barrier to serving TEI >>>>>>>> directly on the web and having it be directly >>>>>>>> viewed without long delays. >>>>>>>> >>>>>>>> Besides TEI, other experimental or alternative formats like >>>>>>>> Markdown, ODF, localized XHTML (e.g., >>>>>>>> http://bahai-library.com/zamir/chintest9.xml ) could become >>>>>>>> possible and practical if applied in other >>>>>>>> browsers and by default. >>>>>>>> >>>>>>>> What do people think of this? >>>>>>>> >>>>>>>> Brett >>>>>>>> _______________________________________________ >>>>>>>> tei-council mailing list >>>>>>>> tei-council at lists.village.Virginia.EDU >>>>>>>> >>>>>>>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>> _______________________________________________ >>>> tei-council mailing list >>>> tei-council at lists.village.Virginia.EDU >>>> >>>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council >>>> >>> >>> >> > > ------------------------------------------------------------------------ > > -- Martin Holmes University of Victoria Humanities Computing and Media Centre (mholmes at uvic.ca) Half-Baked Software, Inc. (mholmes at halfbakedsoftware.com) martin at mholmes.com _______________________________________________ tei-council mailing list tei-council at lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council -------------- next part -------------- A non-text attachment was scrubbed... Name: graycol.gif Type: image/gif Size: 105 bytes Desc: not available Url : http://lists.village.Virginia.EDU/pipermail/tei-council/attachments/20100316/38569ea0/attachment.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: ecblank.gif Type: image/gif Size: 45 bytes Desc: not available Url : http://lists.village.Virginia.EDU/pipermail/tei-council/attachments/20100316/38569ea0/attachment-0001.gif From kevin.s.hawkins at ultraslavonic.info Tue Mar 16 19:12:44 2010 From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins) Date: Tue, 16 Mar 2010 23:12:44 +0000 Subject: [tei-council] attachments In-Reply-To: References: <9E6F6C47-8E75-4052-AE38-8F76FC0B1C89@loria.fr> <4B9FBBD5.4050006@uvic.ca> Message-ID: <4BA0106C.5030905@ultraslavonic.info> Yes, same for me. Either there are user-specific attachment settings or Martin received a copy direct from Laurent by asking for it. Brett Barney wrote: > Just wanted to note that Laurent's attachment didn't come through here, > though I take it that it did for Martin. In David's test post I got the > attachment, though . . . . > > Brett From mholmes at uvic.ca Tue Mar 16 19:41:08 2010 From: mholmes at uvic.ca (Martin Holmes) Date: Tue, 16 Mar 2010 16:41:08 -0700 Subject: [tei-council] attachments In-Reply-To: <4BA0106C.5030905@ultraslavonic.info> References: <9E6F6C47-8E75-4052-AE38-8F76FC0B1C89@loria.fr> <4B9FBBD5.4050006@uvic.ca> <4BA0106C.5030905@ultraslavonic.info> Message-ID: <4BA01714.60002@uvic.ca> Laurent wrote to the list, but he copied me as well. I guess it got through to me one way but not the other. Here's one more attempt to send app-tei-xml.tar.gz to the list... Kevin Hawkins wrote: > Yes, same for me. Either there are user-specific attachment settings or > Martin received a copy direct from Laurent by asking for it. > > Brett Barney wrote: >> Just wanted to note that Laurent's attachment didn't come through here, >> though I take it that it did for Martin. In David's test post I got the >> attachment, though . . . . >> >> Brett > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > -- Martin Holmes University of Victoria Humanities Computing and Media Centre (mholmes at uvic.ca) Half-Baked Software, Inc. (mholmes at halfbakedsoftware.com) martin at mholmes.com -------------- next part -------------- A non-text attachment was scrubbed... Name: app-tei-xml.tar.gz Type: application/x-gzip Size: 6019 bytes Desc: not available Url : http://lists.village.Virginia.EDU/pipermail/tei-council/attachments/20100316/abf06a16/attachment.gz From sebastian.rahtz at oucs.ox.ac.uk Wed Mar 17 07:39:18 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Wed, 17 Mar 2010 11:39:18 +0000 Subject: [tei-council] any of you want to buy me an iPad? Message-ID: <80C89912-2B7E-41B4-8916-25B986D1023D@oucs.ox.ac.uk> Are any of you in America interesting in getting me an iPad and bringing it to Dublin next month? could pay you in advance or after as you wished. -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From laurent.romary at loria.fr Wed Mar 17 07:55:47 2010 From: laurent.romary at loria.fr (Laurent Romary) Date: Wed, 17 Mar 2010 12:55:47 +0100 Subject: [tei-council] app-tei-xml revised In-Reply-To: References: Message-ID: I could take this up. Laurent Le 17 mars 10 ? 12:50, Sigfrid Lundberg a ?crit : > A less early Internet draft is attached... > > As before you can format it as traditional rfc*.txt or to HTML at http://xml.resource.org/ > . On that page there's also information on how to submit the draft > to the IETF > We also need to fill in the form:on http://www.iana.org/cgi-bin/mediatypes.pl > > I think that it would be appropriate that a tei-council member > should be in the list of authors, and that person should be the > contact person registered with the IANA > > Yours > > Sigfrid > Laurent Romary INRIA & HUB-IDSL laurent.romary at inria.fr From mholmes at uvic.ca Wed Mar 17 08:41:25 2010 From: mholmes at uvic.ca (Martin Holmes) Date: Wed, 17 Mar 2010 05:41:25 -0700 Subject: [tei-council] any of you want to buy me an iPad? In-Reply-To: <80C89912-2B7E-41B4-8916-25B986D1023D@oucs.ox.ac.uk> References: <80C89912-2B7E-41B4-8916-25B986D1023D@oucs.ox.ac.uk> Message-ID: <4BA0CDF5.50908@uvic.ca> According to the Apple Store, it won't be available in Canada until late April anyway, so it probably wouldn't be practical for me. But after the recent debacle with the 27" iMacs, I wouldn't buy any Apple product until it's been in consumers' hands for a couple of months at least. Cheers, Martin Sebastian Rahtz wrote: > Are any of you in America interesting in getting me an iPad and > bringing it to Dublin next month? could pay you in advance or after as > you wished. > -- > Sebastian Rahtz > Information Manager, Oxford University Computing Services > 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 > > S?lo le pido a Dios > que el futuro no me sea indiferente > > > > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council From laurent.romary at loria.fr Wed Mar 17 09:40:11 2010 From: laurent.romary at loria.fr (Laurent Romary) Date: Wed, 17 Mar 2010 14:40:11 +0100 Subject: [tei-council] app-tei-xml: A profile parameter? In-Reply-To: References: Message-ID: <41D70FD9-C986-48E9-AE79-D26974383A5A@loria.fr> Hi council, Anyone with a strong view on this? Laurent Le 17 mars 10 ? 10:28, Sigfrid Lundberg a ?crit : > 'Thanks for comments. I've corrected the source file. > > I'd like to return to the P5 versus older versions, and TEI Lite > issue. I've read the application/xhtml+xml specification (http://www.rfc-editor.org/rfc/rfc3236.txt > ), and here they specify a profile parameter which could be used in > HTTP content negotiation. For instance a GET request header could > include > > Accept: application/xhtml+xml; > profile="http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd" > > This would imply that a WWW client only accepts xhtml content as > defined by the xhtml-basic10.dtd. TEI modularization is very good, > but is there a convention for the naming of profiles? On the other > hand, I feel that a profile parameter is very speculative. > > It seems that it could be meaningful to define the profiles > > http://www.tei-c.org/Guidelines/P5/ > http://www.tei-c.org/Guidelines/P4/ > > Any other ideas? > > Yours > > Sigfrid > ________________________________________ > Fra: Sigfrid Lundberg > Sendt: 16. marts 2010 14:08 > Til: Brett Zamir > Cc: Kevin Hawkins; Laurent Romary; Christian S. Vandel > Emne: SV: SV: [tei-council] app-tei-xml again > > Here is a version including the revisions I made in response to the > comments by Kevin. > > I'm not mentioning the namespace problem at all. First, this is > mostly a problem for people who will use TEI in REST based web > services, and they will almost certainly be TEI P5+ Then, this will > be a request for comments, so someone knowledgeable could comment > if they feel there is need for it ;-) > > English isn't my native language, so if there's need for correcting > my pidgin, please do. > > Yours > > Sigfrid > > > > ________________________________________ > Fra: Brett Zamir [brettz9 at yahoo.com] > Sendt: 16. marts 2010 13:36 > Til: Sigfrid Lundberg > Cc: Kevin Hawkins; Laurent Romary; Christian S. Vandel > Emne: Re: SV: [tei-council] app-tei-xml again > > I guess the content-type is meant to give it away, but a lot of web > processing tools may rely on DOM, XPath, etc. methods which expect to > find the TEI namespace... So I wonder whether limiting to P5 and > beyond > may be better? TEI Lite (P5) will be supported if TEI is supported > (managing the full tag set of P5 in at least a generic (text-based) > way > should not be problematic, e.g., if we made a browser extension to > optionally transform a document with the TEI content type but > without an > attached stylesheet using the default TEI stylesheets behind the scene > to render it)... > > best wishes, > Brett > > On 3/16/2010 8:27 PM, Sigfrid Lundberg wrote: >> 1. I agree that there is no reason to exclude P4 and earlier. I've >> changed my copy of the document >> 2. I've changed the reference to http://www.tei-c.org/Guidelines/ >> (which reflects 1.) >> 3. Added the suffix tei >> 4. Changed Tei to TEI >> >> I don't think there's any problems with TEI lite, they can be >> parsed by any TEI aware software. There might be problems mixing >> TEI.2 and TEI though. >> >> Yours >> >> Sigge >> ________________________________________ >> Fra: Kevin Hawkins [kevin.s.hawkins at ultraslavonic.info] >> Sendt: 16. marts 2010 12:41 >> Til: Laurent Romary >> Cc: Sigfrid Lundberg; Christian S. Vandel; Brett Zamir >> Emne: Re: [tei-council] app-tei-xml again >> >> A few notes from a TEI Council member ... >> >> In the Encoding considerations, change "Tei" --> "TEI" >> >> The Published specifications says this MIME type is for documents >> encoded according to P5 or later. Do we really want to exclude any >> P4 >> documents in XML? What about XML documents in TEI Lite or another >> TEI >> customization? >> >> Maybe the Normative References should simply point to >> http://www.tei-c.org/Guidelines/ ? >> >> Under additional information, you might note that some people use the >> file extension ".tei". However, you're entirely right that ".xml" is >> the most common. >> >> --Kevin >> >> On 16/03/2010 11:29, Laurent Romary wrote: >> >>> OK. The council list does not accept attachments... I had >>> forgotten... >>> sigh. >>> Whoever wants to have a look can ask me directly! >>> Laurent >>> >>> >>> Le 16 mars 10 ? 11:33, Sigfrid Lundberg a ?crit : >>> >>> >>>> Thank Brett, >>>> >>>> Here is a new version with, I hope, no visible dependencies of the >>>> old docbook RFC >>>> >>>> Cheers >>>> >>>> Sigfrid >>>> ________________________________________ >>>> Fra: Sigfrid Lundberg >>>> Sendt: 16. marts 2010 11:06 >>>> Til: Laurent Romary; Brett Zamir >>>> Cc: TEI Council; Christian S. Vandel >>>> Emne: SV: [tei-council] [TEI-L] application/tei+xml >>>> >>>> Please find attached an early draft to an Internet draft. You can >>>> format it as traditional rfc*.txt or to HTML at http://xml.resource.org/ >>>> >>>> I don't know who should be on the list as authors and so forth. I >>>> hadn't realised that IETF had such a wonderful infrastructure for >>>> writing RFC's and internet drafts >>>> >>>> The goal is a line here http://www.iana.org/assignments/media-types/application/ >>>> >>>> I suppose we need to fill in the form:on http://www.iana.org/cgi-bin/mediatypes.pl >>>> and the draft should be submitted to the IETF >>>> >>>> Yours >>>> >>>> Sigfrid >>>> >>>> ________________________________________ >>>> Fra: Laurent Romary [laurent.romary at loria.fr] >>>> Sendt: 11. marts 2010 19:40 >>>> Til: Brett Zamir >>>> Cc: Sigfrid Lundberg; TEI Council >>>> Emne: Re: [tei-council] [TEI-L] application/tei+xml >>>> >>>> At least stay in the loop with Sigfrid. I let you two do your >>>> best to >>>> move this foward. >>>> Thanks in advance, >>>> Laurent >>>> >>>> Le 11 mars 10 ? 18:56, Brett Zamir a ?crit : >>>> >>>> >>>>> Hello Laurent, >>>>> >>>>> I'd be happy to try to spell out the use case with which I am best >>>>> familiar, but I'm quite swamped at the moment to do much else >>>>> (looking for work actually). >>>>> >>>>> best wishes, >>>>> Brett >>>>> >>>>> On 3/11/2010 3:19 PM, Laurent Romary wrote: >>>>> >>>>>> Dear Sigfrid and Brett, >>>>>> Following a message from Brett on the TEI-L, I would like to ask >>>>>> you if you could give a hand in implementing the already made >>>>>> decision from the council (Cf. http://lists.village.virginia.edu/pipermail/tei-council/2009/011465.html) >>>>>> to proceed with an application/tei+XML MIME type. One would have >>>>>> to fill out a IANA application, and I could well be the formal >>>>>> submitter as council chair. >>>>>> Would you have some time to dedicate to this? >>>>>> Thanks in advance, >>>>>> Laurent >>>>>> >>>>>> >>>>>>> ---------- Forwarded message ---------- >>>>>>> Date: Wed, 10 Mar 2010 12:36:51 +0800 >>>>>>> From: Brett Zamir >>>>>>> To: TEI-L at listserv.brown.edu >>>>>>> Subject: [TEI-L] application/tei+xml redux >>>>>>> >>>>>>> To resurrect an old (and I know, already settled) question, I >>>>>>> think I may have found a good use for >>>>>>> application/tei+xml after all. >>>>>>> >>>>>>> I am currently working on proposing/developing a modification of >>>>>>> METS which can be used not only to download >>>>>>> a set of TEI files in the browser and with stylesheets (as >>>>>>> well as >>>>>>> XQuery like mentioned in my other recent >>>>>>> post, etc.), but also potentially supply XSLT files without >>>>>>> TEI or >>>>>>> XML, such as TEI's own stylesheets, and >>>>>>> allow them to register themselves as content handlers for >>>>>>> application/tei+xml content encountered on the web >>>>>>> and/or as namespace handlers which could operate within any >>>>>>> documents containing the TEI namespace (such as >>>>>>> embedded within XHTML). >>>>>>> >>>>>>> This might even operate at an individual tag level (e.g., to >>>>>>> replace native XHTML buttons with one's own >>>>>>> HTML5 "canvas"-drawn element or, in the case of TEI, to override >>>>>>> the default styling provided by Sebastian's >>>>>>> stylesheets for certain tags). >>>>>>> >>>>>>> Thus, TEI files in the browser could be shown (by default) in >>>>>>> one >>>>>>> standard format across web pages, at least >>>>>>> if they were not pre-styled by the author, with the major >>>>>>> bonus of >>>>>>> the user not needing to re-download the >>>>>>> same standard stylesheets, especially when visiting a new TEI- >>>>>>> hosting site, after they had obtained the >>>>>>> stylesheets just once from any page as long as it registered >>>>>>> itself as a TEI content handler (though since >>>>>>> multiple content handlers could be registered, TEI's own >>>>>>> stylesheets would not need to be the only choice >>>>>>> out there when viewing TEI and users could switch between >>>>>>> handlers >>>>>>> for specific pages). The overhead of >>>>>>> client-side XSL would be obviated greatly by not having to >>>>>>> transfer the often large stylesheet files across >>>>>>> the web upon each new site visit; the only extra overhead >>>>>>> compared >>>>>>> to regular XHTML would be the internal >>>>>>> conversion made by the browser (which is very little in >>>>>>> comparison >>>>>>> to network transmission). >>>>>>> >>>>>>> The manifest file within the file package containing the >>>>>>> stylesheets could also indicate an update URL which >>>>>>> could be checked for new updates to the stylesheets. >>>>>>> >>>>>>> I think this could remove the primary barrier to serving TEI >>>>>>> directly on the web and having it be directly >>>>>>> viewed without long delays. >>>>>>> >>>>>>> Besides TEI, other experimental or alternative formats like >>>>>>> Markdown, ODF, localized XHTML (e.g., >>>>>>> http://bahai-library.com/zamir/chintest9.xml ) could become >>>>>>> possible and practical if applied in other >>>>>>> browsers and by default. >>>>>>> >>>>>>> What do people think of this? >>>>>>> >>>>>>> Brett >>>>>>> _______________________________________________ >>>>>>> tei-council mailing list >>>>>>> tei-council at lists.village.Virginia.EDU >>>>>>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council >>>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> >>> _______________________________________________ >>> tei-council mailing list >>> tei-council at lists.village.Virginia.EDU >>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council >>> >> >> > Laurent Romary INRIA & HUB-IDSL laurent.romary at inria.fr From mholmes at uvic.ca Wed Mar 17 12:08:33 2010 From: mholmes at uvic.ca (Martin Holmes) Date: Wed, 17 Mar 2010 09:08:33 -0700 Subject: [tei-council] app-tei-xml: A profile parameter? In-Reply-To: <41D70FD9-C986-48E9-AE79-D26974383A5A@loria.fr> References: <41D70FD9-C986-48E9-AE79-D26974383A5A@loria.fr> Message-ID: <4BA0FE81.9040802@uvic.ca> Hi there, It looks as though the decision to use "profile" back in 2002 was a provisional one: The functionality afforded by this parameter can also be achieved with at least two other more general content description frameworks; the "Content-features" MIME header described in RFC 2912, and UAPROF from the WAPforum (see http://www.wapforum.org/what/technical.htm). At this time, choosing one of these solutions would require excluding the other, as interoperability between the two has not been defined. For this reason, it is suggested that this parameter be used until such time as that issue has been addressed. Does anyone know whether the interoperability between RFC 2912 and UAPROF was ever resolved? I do see the value in being able to distinguish between P4 and P5 (and P6, too, eventually). Are we required to specify a range of values ahead of time for these profiles, or can anything go in these header fields? Cheers, Martin Laurent Romary wrote: > Hi council, > Anyone with a strong view on this? > Laurent > > Le 17 mars 10 ? 10:28, Sigfrid Lundberg a ?crit : > >> 'Thanks for comments. I've corrected the source file. >> >> I'd like to return to the P5 versus older versions, and TEI Lite >> issue. I've read the application/xhtml+xml specification (http://www.rfc-editor.org/rfc/rfc3236.txt >> ), and here they specify a profile parameter which could be used in >> HTTP content negotiation. For instance a GET request header could >> include >> >> Accept: application/xhtml+xml; >> profile="http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd" >> >> This would imply that a WWW client only accepts xhtml content as >> defined by the xhtml-basic10.dtd. TEI modularization is very good, >> but is there a convention for the naming of profiles? On the other >> hand, I feel that a profile parameter is very speculative. >> >> It seems that it could be meaningful to define the profiles >> >> http://www.tei-c.org/Guidelines/P5/ >> http://www.tei-c.org/Guidelines/P4/ >> >> Any other ideas? >> >> Yours >> >> Sigfrid >> ________________________________________ >> Fra: Sigfrid Lundberg >> Sendt: 16. marts 2010 14:08 >> Til: Brett Zamir >> Cc: Kevin Hawkins; Laurent Romary; Christian S. Vandel >> Emne: SV: SV: [tei-council] app-tei-xml again >> >> Here is a version including the revisions I made in response to the >> comments by Kevin. >> >> I'm not mentioning the namespace problem at all. First, this is >> mostly a problem for people who will use TEI in REST based web >> services, and they will almost certainly be TEI P5+ Then, this will >> be a request for comments, so someone knowledgeable could comment >> if they feel there is need for it ;-) >> >> English isn't my native language, so if there's need for correcting >> my pidgin, please do. >> >> Yours >> >> Sigfrid >> >> >> >> ________________________________________ >> Fra: Brett Zamir [brettz9 at yahoo.com] >> Sendt: 16. marts 2010 13:36 >> Til: Sigfrid Lundberg >> Cc: Kevin Hawkins; Laurent Romary; Christian S. Vandel >> Emne: Re: SV: [tei-council] app-tei-xml again >> >> I guess the content-type is meant to give it away, but a lot of web >> processing tools may rely on DOM, XPath, etc. methods which expect to >> find the TEI namespace... So I wonder whether limiting to P5 and >> beyond >> may be better? TEI Lite (P5) will be supported if TEI is supported >> (managing the full tag set of P5 in at least a generic (text-based) >> way >> should not be problematic, e.g., if we made a browser extension to >> optionally transform a document with the TEI content type but >> without an >> attached stylesheet using the default TEI stylesheets behind the scene >> to render it)... >> >> best wishes, >> Brett >> >> On 3/16/2010 8:27 PM, Sigfrid Lundberg wrote: >>> 1. I agree that there is no reason to exclude P4 and earlier. I've >>> changed my copy of the document >>> 2. I've changed the reference to http://www.tei-c.org/Guidelines/ >>> (which reflects 1.) >>> 3. Added the suffix tei >>> 4. Changed Tei to TEI >>> >>> I don't think there's any problems with TEI lite, they can be >>> parsed by any TEI aware software. There might be problems mixing >>> TEI.2 and TEI though. >>> >>> Yours >>> >>> Sigge >>> ________________________________________ >>> Fra: Kevin Hawkins [kevin.s.hawkins at ultraslavonic.info] >>> Sendt: 16. marts 2010 12:41 >>> Til: Laurent Romary >>> Cc: Sigfrid Lundberg; Christian S. Vandel; Brett Zamir >>> Emne: Re: [tei-council] app-tei-xml again >>> >>> A few notes from a TEI Council member ... >>> >>> In the Encoding considerations, change "Tei" --> "TEI" >>> >>> The Published specifications says this MIME type is for documents >>> encoded according to P5 or later. Do we really want to exclude any >>> P4 >>> documents in XML? What about XML documents in TEI Lite or another >>> TEI >>> customization? >>> >>> Maybe the Normative References should simply point to >>> http://www.tei-c.org/Guidelines/ ? >>> >>> Under additional information, you might note that some people use the >>> file extension ".tei". However, you're entirely right that ".xml" is >>> the most common. >>> >>> --Kevin >>> >>> On 16/03/2010 11:29, Laurent Romary wrote: >>> >>>> OK. The council list does not accept attachments... I had >>>> forgotten... >>>> sigh. >>>> Whoever wants to have a look can ask me directly! >>>> Laurent >>>> >>>> >>>> Le 16 mars 10 ? 11:33, Sigfrid Lundberg a ?crit : >>>> >>>> >>>>> Thank Brett, >>>>> >>>>> Here is a new version with, I hope, no visible dependencies of the >>>>> old docbook RFC >>>>> >>>>> Cheers >>>>> >>>>> Sigfrid >>>>> ________________________________________ >>>>> Fra: Sigfrid Lundberg >>>>> Sendt: 16. marts 2010 11:06 >>>>> Til: Laurent Romary; Brett Zamir >>>>> Cc: TEI Council; Christian S. Vandel >>>>> Emne: SV: [tei-council] [TEI-L] application/tei+xml >>>>> >>>>> Please find attached an early draft to an Internet draft. You can >>>>> format it as traditional rfc*.txt or to HTML at http://xml.resource.org/ >>>>> >>>>> I don't know who should be on the list as authors and so forth. I >>>>> hadn't realised that IETF had such a wonderful infrastructure for >>>>> writing RFC's and internet drafts >>>>> >>>>> The goal is a line here http://www.iana.org/assignments/media-types/application/ >>>>> >>>>> I suppose we need to fill in the form:on http://www.iana.org/cgi-bin/mediatypes.pl >>>>> and the draft should be submitted to the IETF >>>>> >>>>> Yours >>>>> >>>>> Sigfrid >>>>> >>>>> ________________________________________ >>>>> Fra: Laurent Romary [laurent.romary at loria.fr] >>>>> Sendt: 11. marts 2010 19:40 >>>>> Til: Brett Zamir >>>>> Cc: Sigfrid Lundberg; TEI Council >>>>> Emne: Re: [tei-council] [TEI-L] application/tei+xml >>>>> >>>>> At least stay in the loop with Sigfrid. I let you two do your >>>>> best to >>>>> move this foward. >>>>> Thanks in advance, >>>>> Laurent >>>>> >>>>> Le 11 mars 10 ? 18:56, Brett Zamir a ?crit : >>>>> >>>>> >>>>>> Hello Laurent, >>>>>> >>>>>> I'd be happy to try to spell out the use case with which I am best >>>>>> familiar, but I'm quite swamped at the moment to do much else >>>>>> (looking for work actually). >>>>>> >>>>>> best wishes, >>>>>> Brett >>>>>> >>>>>> On 3/11/2010 3:19 PM, Laurent Romary wrote: >>>>>> >>>>>>> Dear Sigfrid and Brett, >>>>>>> Following a message from Brett on the TEI-L, I would like to ask >>>>>>> you if you could give a hand in implementing the already made >>>>>>> decision from the council (Cf. http://lists.village.virginia.edu/pipermail/tei-council/2009/011465.html) >>>>>>> to proceed with an application/tei+XML MIME type. One would have >>>>>>> to fill out a IANA application, and I could well be the formal >>>>>>> submitter as council chair. >>>>>>> Would you have some time to dedicate to this? >>>>>>> Thanks in advance, >>>>>>> Laurent >>>>>>> >>>>>>> >>>>>>>> ---------- Forwarded message ---------- >>>>>>>> Date: Wed, 10 Mar 2010 12:36:51 +0800 >>>>>>>> From: Brett Zamir >>>>>>>> To: TEI-L at listserv.brown.edu >>>>>>>> Subject: [TEI-L] application/tei+xml redux >>>>>>>> >>>>>>>> To resurrect an old (and I know, already settled) question, I >>>>>>>> think I may have found a good use for >>>>>>>> application/tei+xml after all. >>>>>>>> >>>>>>>> I am currently working on proposing/developing a modification of >>>>>>>> METS which can be used not only to download >>>>>>>> a set of TEI files in the browser and with stylesheets (as >>>>>>>> well as >>>>>>>> XQuery like mentioned in my other recent >>>>>>>> post, etc.), but also potentially supply XSLT files without >>>>>>>> TEI or >>>>>>>> XML, such as TEI's own stylesheets, and >>>>>>>> allow them to register themselves as content handlers for >>>>>>>> application/tei+xml content encountered on the web >>>>>>>> and/or as namespace handlers which could operate within any >>>>>>>> documents containing the TEI namespace (such as >>>>>>>> embedded within XHTML). >>>>>>>> >>>>>>>> This might even operate at an individual tag level (e.g., to >>>>>>>> replace native XHTML buttons with one's own >>>>>>>> HTML5 "canvas"-drawn element or, in the case of TEI, to override >>>>>>>> the default styling provided by Sebastian's >>>>>>>> stylesheets for certain tags). >>>>>>>> >>>>>>>> Thus, TEI files in the browser could be shown (by default) in >>>>>>>> one >>>>>>>> standard format across web pages, at least >>>>>>>> if they were not pre-styled by the author, with the major >>>>>>>> bonus of >>>>>>>> the user not needing to re-download the >>>>>>>> same standard stylesheets, especially when visiting a new TEI- >>>>>>>> hosting site, after they had obtained the >>>>>>>> stylesheets just once from any page as long as it registered >>>>>>>> itself as a TEI content handler (though since >>>>>>>> multiple content handlers could be registered, TEI's own >>>>>>>> stylesheets would not need to be the only choice >>>>>>>> out there when viewing TEI and users could switch between >>>>>>>> handlers >>>>>>>> for specific pages). The overhead of >>>>>>>> client-side XSL would be obviated greatly by not having to >>>>>>>> transfer the often large stylesheet files across >>>>>>>> the web upon each new site visit; the only extra overhead >>>>>>>> compared >>>>>>>> to regular XHTML would be the internal >>>>>>>> conversion made by the browser (which is very little in >>>>>>>> comparison >>>>>>>> to network transmission). >>>>>>>> >>>>>>>> The manifest file within the file package containing the >>>>>>>> stylesheets could also indicate an update URL which >>>>>>>> could be checked for new updates to the stylesheets. >>>>>>>> >>>>>>>> I think this could remove the primary barrier to serving TEI >>>>>>>> directly on the web and having it be directly >>>>>>>> viewed without long delays. >>>>>>>> >>>>>>>> Besides TEI, other experimental or alternative formats like >>>>>>>> Markdown, ODF, localized XHTML (e.g., >>>>>>>> http://bahai-library.com/zamir/chintest9.xml ) could become >>>>>>>> possible and practical if applied in other >>>>>>>> browsers and by default. >>>>>>>> >>>>>>>> What do people think of this? >>>>>>>> >>>>>>>> Brett >>>>>>>> _______________________________________________ >>>>>>>> tei-council mailing list >>>>>>>> tei-council at lists.village.Virginia.EDU >>>>>>>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council >>>>>>>> >>>>>>> >>>>>>> >>>>> >>>>> >>>> _______________________________________________ >>>> tei-council mailing list >>>> tei-council at lists.village.Virginia.EDU >>>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council >>>> >>> > > Laurent Romary > INRIA & HUB-IDSL > laurent.romary at inria.fr > > > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > . > -- Martin Holmes University of Victoria Humanities Computing and Media Centre (mholmes at uvic.ca) Half-Baked Software, Inc. (mholmes at halfbakedsoftware.com) martin at mholmes.com From mholmes at uvic.ca Thu Mar 18 08:49:48 2010 From: mholmes at uvic.ca (Martin Holmes) Date: Thu, 18 Mar 2010 05:49:48 -0700 Subject: [tei-council] app-tei-xml: A profile parameter? In-Reply-To: References: <41D70FD9-C986-48E9-AE79-D26974383A5A@loria.fr> <4BA0FE81.9040802@uvic.ca>, <4BA1054C.6070704@yahoo.com> Message-ID: <4BA2216C.9030200@uvic.ca> This makes sense to me. Cheers, Martin Sigfrid Lundberg wrote: > I've read the responses from Brett & Martin & and had a chat with Christian here at the office. An ultrabrief summary of my experiences would could be summarized as follows: > > 1. The content features Martin mentions seems to be as complicated as powerful. > 2. When trying to read the User Agent Profile from WAP forum I got a password prompt and didn't pursue the task further. > 3. I agree with Brett that a schema or DTD is more useful than a namespace for a profile parameter. > 4. My colleague Christian sitting here at KB remarked that if two XML objects have different namespace URIs they should have different mime types. > 5. Someone, don't remember who, mentioned that the use of profile parameters for xhtml modularization was regarded (by the RFC author) as a temporary work-around. > > In my view, to support both tei p4 and p5 could pose a problem, I propose that we actually define two mime-types application/tei+xml and for legacy data application/teip4+xml > This means that we can use the profile parameter for other purposes, and service providers can use them both for tei and teip4 data > > Using profiles rather than, say, content features is an advantage, They can be used by a user agent for content negotiation. A clever programmer could expose the range of mediatypes including profiles such that they are available via an OPTIONS HTTP request. > > We should mention the optional profile parameter but I suggest that we leave it's use open for implementers, but that we point out that the profile should not be used for xmlns URIs > > Any other opinions > > Sigge > > > > > ________________________________________ > Fra: Brett Zamir [brettz9 at yahoo.com] > Sendt: 17. marts 2010 17:37 > Til: Martin Holmes > Cc: TEI Council; Sigfrid Lundberg; Christian S. Vandel > Emne: Re: [tei-council] app-tei-xml: A profile parameter? > > On 3/18/2010 12:08 AM, Martin Holmes wrote: >> Hi there, >> >> It looks as though the decision to use "profile" back in 2002 was a >> provisional one: >> >> The functionality afforded by this parameter can also be achieved >> with at least two other more general content description frameworks; >> the "Content-features" MIME header described in RFC 2912, and UAPROF >> from the WAPforum (see http://www.wapforum.org/what/technical.htm). >> At this time, choosing one of these solutions would require excluding >> the other, as interoperability between the two has not been defined. >> For this reason, it is suggested that this parameter be used until >> such time as that issue has been addressed. >> >> >> Does anyone know whether the interoperability between RFC 2912 and >> UAPROF was ever resolved? >> >> I do see the value in being able to distinguish between P4 and P5 (and >> P6, too, eventually). Are we required to specify a range of values >> ahead of time for these profiles, or can anything go in these header >> fields? > > The RFC says "Though the URI need not be resolved in order to be useful > as a name, it could be a namespace, schema, or a language > specification.". I'd favor a schema/DTD rather than a namespace, since > it is, in practice, more fine-grained. The only problem to me is whether > the spec should specifically disallow non-conformant versions of TEI > (i.e., pointing to a DTD or schema which breaks TEI conformance) and > only allow subsets (as the XHTML spec envisions in speaking of XHTML > Basic). It'd most likely be hard enough for a vendor to program for P4 > and P5+, let alone impossibly guess at or build in support for more > specific non-conformant varieties (if people are making them) all under > the same content type umbrella. P6+ should be easy because I assume > there will be no reason to move away from as a root tag, nor its > convenient @version attribute, at least If TEI continues on with the > same namespace in future versions (as may be possible, I imagine, if > tags are not redefined so as to be backwards-incompatible). > > Is there a full TEI schema for P5 and P4 online, and if so, does TEI > want to risk the same problem the W3C faces with DTDs being resolved > (leading to a kind of attack on the server when applications try to > resolve the URL)? I doubt the risk would be any greater, since > content-type sniffers, unlike validators, have no reason to download a > public URL, but just mentioning it to be safer. > > But to be honest, at least as someone coming from more of a developer > angle, I think I'd be partial to only allowing TEI P5+, since the web is > a new field, since P5, in its support for namespaces (and schemas) is > truly modern, since XSL transforming to P5 is still possible for those > who wish to deploy P4 to the web, and since P5, in possessing both a > namespace and version attribute, sets up a nice consistent model for > future versions. P5 with namespacing also even invites embedding within > other content, as is especially likely on the web, such that detection > can only safely be detected via namespace (and having a content-type > which supports P4 may only encourage people to hang on to P4 longer than > necessary). For interoperability (and the ability to embed all web TEI), > I'd really suggest excluding P4 (which has no namespace and is thus > indistinguishable from other XML which might use the same tag names). > > best wishes, > Brett > >> Cheers, >> Martin >> >> Laurent Romary wrote: >>> Hi council, >>> Anyone with a strong view on this? >>> Laurent >>> >>> Le 17 mars 10 ? 10:28, Sigfrid Lundberg a ?crit : >>> >>>> 'Thanks for comments. I've corrected the source file. >>>> >>>> I'd like to return to the P5 versus older versions, and TEI Lite >>>> issue. I've read the application/xhtml+xml specification >>>> (http://www.rfc-editor.org/rfc/rfc3236.txt >>>> ), and here they specify a profile parameter which could be used in >>>> HTTP content negotiation. For instance a GET request header could >>>> include >>>> >>>> Accept: application/xhtml+xml; >>>> profile="http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd" >>>> >>>> This would imply that a WWW client only accepts xhtml content as >>>> defined by the xhtml-basic10.dtd. TEI modularization is very good, >>>> but is there a convention for the naming of profiles? On the other >>>> hand, I feel that a profile parameter is very speculative. >>>> >>>> It seems that it could be meaningful to define the profiles >>>> >>>> http://www.tei-c.org/Guidelines/P5/ >>>> http://www.tei-c.org/Guidelines/P4/ >>>> >>>> Any other ideas? >>>> >>>> Yours >>>> >>>> Sigfrid >>>> ________________________________________ >>>> Fra: Sigfrid Lundberg >>>> Sendt: 16. marts 2010 14:08 >>>> Til: Brett Zamir >>>> Cc: Kevin Hawkins; Laurent Romary; Christian S. Vandel >>>> Emne: SV: SV: [tei-council] app-tei-xml again >>>> >>>> Here is a version including the revisions I made in response to the >>>> comments by Kevin. >>>> >>>> I'm not mentioning the namespace problem at all. First, this is >>>> mostly a problem for people who will use TEI in REST based web >>>> services, and they will almost certainly be TEI P5+ Then, this will >>>> be a request for comments, so someone knowledgeable could comment >>>> if they feel there is need for it ;-) >>>> >>>> English isn't my native language, so if there's need for correcting >>>> my pidgin, please do. >>>> >>>> Yours >>>> >>>> Sigfrid >>>> >>>> >>>> >>>> ________________________________________ >>>> Fra: Brett Zamir [brettz9 at yahoo.com] >>>> Sendt: 16. marts 2010 13:36 >>>> Til: Sigfrid Lundberg >>>> Cc: Kevin Hawkins; Laurent Romary; Christian S. Vandel >>>> Emne: Re: SV: [tei-council] app-tei-xml again >>>> >>>> I guess the content-type is meant to give it away, but a lot of web >>>> processing tools may rely on DOM, XPath, etc. methods which expect to >>>> find the TEI namespace... So I wonder whether limiting to P5 and >>>> beyond >>>> may be better? TEI Lite (P5) will be supported if TEI is supported >>>> (managing the full tag set of P5 in at least a generic (text-based) >>>> way >>>> should not be problematic, e.g., if we made a browser extension to >>>> optionally transform a document with the TEI content type but >>>> without an >>>> attached stylesheet using the default TEI stylesheets behind the scene >>>> to render it)... >>>> >>>> best wishes, >>>> Brett >>>> >>>> On 3/16/2010 8:27 PM, Sigfrid Lundberg wrote: >>>>> 1. I agree that there is no reason to exclude P4 and earlier. I've >>>>> changed my copy of the document >>>>> 2. I've changed the reference to http://www.tei-c.org/Guidelines/ >>>>> (which reflects 1.) >>>>> 3. Added the suffix tei >>>>> 4. Changed Tei to TEI >>>>> >>>>> I don't think there's any problems with TEI lite, they can be >>>>> parsed by any TEI aware software. There might be problems mixing >>>>> TEI.2 and TEI though. >>>>> >>>>> Yours >>>>> >>>>> Sigge >>>>> ________________________________________ >>>>> Fra: Kevin Hawkins [kevin.s.hawkins at ultraslavonic.info] >>>>> Sendt: 16. marts 2010 12:41 >>>>> Til: Laurent Romary >>>>> Cc: Sigfrid Lundberg; Christian S. Vandel; Brett Zamir >>>>> Emne: Re: [tei-council] app-tei-xml again >>>>> >>>>> A few notes from a TEI Council member ... >>>>> >>>>> In the Encoding considerations, change "Tei" --> "TEI" >>>>> >>>>> The Published specifications says this MIME type is for documents >>>>> encoded according to P5 or later. Do we really want to exclude any >>>>> P4 >>>>> documents in XML? What about XML documents in TEI Lite or another >>>>> TEI >>>>> customization? >>>>> >>>>> Maybe the Normative References should simply point to >>>>> http://www.tei-c.org/Guidelines/ ? >>>>> >>>>> Under additional information, you might note that some people use the >>>>> file extension ".tei". However, you're entirely right that ".xml" is >>>>> the most common. >>>>> >>>>> --Kevin >>>>> >>>>> On 16/03/2010 11:29, Laurent Romary wrote: >>>>> >>>>>> OK. The council list does not accept attachments... I had >>>>>> forgotten... >>>>>> sigh. >>>>>> Whoever wants to have a look can ask me directly! >>>>>> Laurent >>>>>> >>>>>> >>>>>> Le 16 mars 10 ? 11:33, Sigfrid Lundberg a ?crit : >>>>>> >>>>>> >>>>>>> Thank Brett, >>>>>>> >>>>>>> Here is a new version with, I hope, no visible dependencies of the >>>>>>> old docbook RFC >>>>>>> >>>>>>> Cheers >>>>>>> >>>>>>> Sigfrid >>>>>>> ________________________________________ >>>>>>> Fra: Sigfrid Lundberg >>>>>>> Sendt: 16. marts 2010 11:06 >>>>>>> Til: Laurent Romary; Brett Zamir >>>>>>> Cc: TEI Council; Christian S. Vandel >>>>>>> Emne: SV: [tei-council] [TEI-L] application/tei+xml >>>>>>> >>>>>>> Please find attached an early draft to an Internet draft. You can >>>>>>> format it as traditional rfc*.txt or to HTML at >>>>>>> http://xml.resource.org/ >>>>>>> >>>>>>> I don't know who should be on the list as authors and so forth. I >>>>>>> hadn't realised that IETF had such a wonderful infrastructure for >>>>>>> writing RFC's and internet drafts >>>>>>> >>>>>>> The goal is a line here >>>>>>> http://www.iana.org/assignments/media-types/application/ >>>>>>> >>>>>>> I suppose we need to fill in the form:on >>>>>>> http://www.iana.org/cgi-bin/mediatypes.pl >>>>>>> and the draft should be submitted to the IETF >>>>>>> >>>>>>> Yours >>>>>>> >>>>>>> Sigfrid >>>>>>> >>>>>>> ________________________________________ >>>>>>> Fra: Laurent Romary [laurent.romary at loria.fr] >>>>>>> Sendt: 11. marts 2010 19:40 >>>>>>> Til: Brett Zamir >>>>>>> Cc: Sigfrid Lundberg; TEI Council >>>>>>> Emne: Re: [tei-council] [TEI-L] application/tei+xml >>>>>>> >>>>>>> At least stay in the loop with Sigfrid. I let you two do your >>>>>>> best to >>>>>>> move this foward. >>>>>>> Thanks in advance, >>>>>>> Laurent >>>>>>> >>>>>>> Le 11 mars 10 ? 18:56, Brett Zamir a ?crit : >>>>>>> >>>>>>> >>>>>>>> Hello Laurent, >>>>>>>> >>>>>>>> I'd be happy to try to spell out the use case with which I am best >>>>>>>> familiar, but I'm quite swamped at the moment to do much else >>>>>>>> (looking for work actually). >>>>>>>> >>>>>>>> best wishes, >>>>>>>> Brett >>>>>>>> >>>>>>>> On 3/11/2010 3:19 PM, Laurent Romary wrote: >>>>>>>> >>>>>>>>> Dear Sigfrid and Brett, >>>>>>>>> Following a message from Brett on the TEI-L, I would like to ask >>>>>>>>> you if you could give a hand in implementing the already made >>>>>>>>> decision from the council (Cf. >>>>>>>>> http://lists.village.virginia.edu/pipermail/tei-council/2009/011465.html) >>>>>>>>> >>>>>>>>> to proceed with an application/tei+XML MIME type. One would have >>>>>>>>> to fill out a IANA application, and I could well be the formal >>>>>>>>> submitter as council chair. >>>>>>>>> Would you have some time to dedicate to this? >>>>>>>>> Thanks in advance, >>>>>>>>> Laurent >>>>>>>>> >>>>>>>>> >>>>>>>>>> ---------- Forwarded message ---------- >>>>>>>>>> Date: Wed, 10 Mar 2010 12:36:51 +0800 >>>>>>>>>> From: Brett Zamir >>>>>>>>>> To: TEI-L at listserv.brown.edu >>>>>>>>>> Subject: [TEI-L] application/tei+xml redux >>>>>>>>>> >>>>>>>>>> To resurrect an old (and I know, already settled) question, I >>>>>>>>>> think I may have found a good use for >>>>>>>>>> application/tei+xml after all. >>>>>>>>>> >>>>>>>>>> I am currently working on proposing/developing a modification of >>>>>>>>>> METS which can be used not only to download >>>>>>>>>> a set of TEI files in the browser and with stylesheets (as >>>>>>>>>> well as >>>>>>>>>> XQuery like mentioned in my other recent >>>>>>>>>> post, etc.), but also potentially supply XSLT files without >>>>>>>>>> TEI or >>>>>>>>>> XML, such as TEI's own stylesheets, and >>>>>>>>>> allow them to register themselves as content handlers for >>>>>>>>>> application/tei+xml content encountered on the web >>>>>>>>>> and/or as namespace handlers which could operate within any >>>>>>>>>> documents containing the TEI namespace (such as >>>>>>>>>> embedded within XHTML). >>>>>>>>>> >>>>>>>>>> This might even operate at an individual tag level (e.g., to >>>>>>>>>> replace native XHTML buttons with one's own >>>>>>>>>> HTML5 "canvas"-drawn element or, in the case of TEI, to override >>>>>>>>>> the default styling provided by Sebastian's >>>>>>>>>> stylesheets for certain tags). >>>>>>>>>> >>>>>>>>>> Thus, TEI files in the browser could be shown (by default) in >>>>>>>>>> one >>>>>>>>>> standard format across web pages, at least >>>>>>>>>> if they were not pre-styled by the author, with the major >>>>>>>>>> bonus of >>>>>>>>>> the user not needing to re-download the >>>>>>>>>> same standard stylesheets, especially when visiting a new TEI- >>>>>>>>>> hosting site, after they had obtained the >>>>>>>>>> stylesheets just once from any page as long as it registered >>>>>>>>>> itself as a TEI content handler (though since >>>>>>>>>> multiple content handlers could be registered, TEI's own >>>>>>>>>> stylesheets would not need to be the only choice >>>>>>>>>> out there when viewing TEI and users could switch between >>>>>>>>>> handlers >>>>>>>>>> for specific pages). The overhead of >>>>>>>>>> client-side XSL would be obviated greatly by not having to >>>>>>>>>> transfer the often large stylesheet files across >>>>>>>>>> the web upon each new site visit; the only extra overhead >>>>>>>>>> compared >>>>>>>>>> to regular XHTML would be the internal >>>>>>>>>> conversion made by the browser (which is very little in >>>>>>>>>> comparison >>>>>>>>>> to network transmission). >>>>>>>>>> >>>>>>>>>> The manifest file within the file package containing the >>>>>>>>>> stylesheets could also indicate an update URL which >>>>>>>>>> could be checked for new updates to the stylesheets. >>>>>>>>>> >>>>>>>>>> I think this could remove the primary barrier to serving TEI >>>>>>>>>> directly on the web and having it be directly >>>>>>>>>> viewed without long delays. >>>>>>>>>> >>>>>>>>>> Besides TEI, other experimental or alternative formats like >>>>>>>>>> Markdown, ODF, localized XHTML (e.g., >>>>>>>>>> http://bahai-library.com/zamir/chintest9.xml ) could become >>>>>>>>>> possible and practical if applied in other >>>>>>>>>> browsers and by default. >>>>>>>>>> >>>>>>>>>> What do people think of this? >>>>>>>>>> >>>>>>>>>> Brett >>>>>>>>>> _______________________________________________ >>>>>>>>>> tei-council mailing list >>>>>>>>>> tei-council at lists.village.Virginia.EDU >>>>>>>>>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council >>>>>>>>>> >>>>>>>>> >>>>>>> >>>>>>> >>>>>> _______________________________________________ >>>>>> tei-council mailing list >>>>>> tei-council at lists.village.Virginia.EDU >>>>>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council >>>>>> >>> Laurent Romary >>> INRIA & HUB-IDSL >>> laurent.romary at inria.fr >>> >>> >>> >>> _______________________________________________ >>> tei-council mailing list >>> tei-council at lists.village.Virginia.EDU >>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council >>> . >>> > From laurent.romary at loria.fr Thu Mar 18 11:27:48 2010 From: laurent.romary at loria.fr (Laurent Romary) Date: Thu, 18 Mar 2010 16:27:48 +0100 Subject: [tei-council] draft-lundberg-app-tei-xml-00.txt submitted In-Reply-To: References: Message-ID: <1D85E051-EE80-4DB1-8A3C-5B39E4890899@loria.fr> I guess we all owe a big "merci" to Sigfrid as well as those who within council or outside (Brett!) gave a hand. Laurent Le 18 mars 10 ? 16:22, Sigfrid Lundberg a ?crit : > > Dear TEI Council > > Laurent and myself had a brief chat on phone and decided to go ahead > with publication with the (potential) problem brushed under the > carpet. We just don't mention it. > The expiry date is September 19, 2010 and we, or some other group > should revise the thing and resubmit it _before_ that date. > > I don't think it's a hard job owning an Internet standard, it needs > resubmission now and then until IETF has said thumbs up > > The documents are > > http://sigfrid-lundberg.se/entries/2010/03/appteixml/draft-lundberg-app-tei-xml-00.html > http://sigfrid-lundberg.se/entries/2010/03/appteixml/draft-lundberg-app-tei-xml-00.xml > http://sigfrid-lundberg.se/entries/2010/03/appteixml/draft-lundberg-app-tei-xml-00.txt > > You only need the .xml file. That one is the source. IETF only like > the txt one. If you didn't know: > > And finally: Yes they do check the number of lines per page and > number of characters per row ;^) > > I haven't submitted the thing to IANA, yet. > > > Yours > > Sigfrid > > > > Laurent Romary INRIA & HUB-IDSL laurent.romary at inria.fr From dsewell at virginia.edu Sat Mar 20 20:03:29 2010 From: dsewell at virginia.edu (David Sewell) Date: Sat, 20 Mar 2010 20:03:29 -0400 (EDT) Subject: [tei-council] Virtual language-based TEI Guidelines hosts are live but incomplete Message-ID: Shayne has created virtual hosts by language: http://en.guidelines.tei-c.org/ http://de.guidelines.tei-c.org/ http://es.guidelines.tei-c.org/ http://fr.guidelines.tei-c.org/ http://it.guidelines.tei-c.org/ http://kr.guidelines.tei-c.org/ http://zh-tw.guidelines.tei-c.org/ He overlooked one for Japanese so I've asked for that. Please consider and provide feedback on two problems with this system: 1. each of the above URLs currently goes to the top level of the language documentation release, i.e. one directory above /html. Should we: a) make 'html' explicit in all links to the HTML version of the Guidelines, i.e. for English link to http://en.guidelines.tei-c.org/html/, or b) add a rewrite rule so http://en.guidelines.tei-c.org/ ==> http://en.guidelines.tei-c.org/html/ ? (one disadvantage of 'b' is that Web crawlers going to the domain might miss any non-HTML content. Or is that a good thing?) 2) If you're at http://en.guidelines.tei-c.org/html/ and click on any other language version, the link is broken (because it's generated as a relative link). Likewise, the alternate language links in the Reference pages. Are we willing to convert all language-specific links to use the domain aliases? Obviously, those problems need solving and other testing should be done before we can advertise the existence of these virtual hosts. Unless we want to use those hosts only as a way to get Google to index by language? David -- David Sewell, Editorial and Technical Manager ROTUNDA, The University of Virginia Press PO Box 801079, Charlottesville, VA 22904-4318 USA Courier: 310 Old Ivy Way, Suite 302, Charlottesville VA 22903 Email: dsewell at virginia.edu Tel: +1 434 924 9973 Web: http://rotunda.upress.virginia.edu/ From laurent.romary at loria.fr Wed Mar 24 04:08:36 2010 From: laurent.romary at loria.fr (Laurent Romary) Date: Wed, 24 Mar 2010 09:08:36 +0100 Subject: [tei-council] Virtual language-based TEI Guidelines hosts are live but incomplete In-Reply-To: References: Message-ID: <660F89FF-75EF-42D1-A9E8-8508453D7BA6@loria.fr> Hi David, I am taking up on this... Thanks for having implemented this so quickly. I would favor 1.a indeed. As to 2. It would be good to test this with our Oxford colleagues and define the easiest procedure (also from the point of view of maintenance). Oxford: what do you think? Laurent Le 21 mars 10 ? 01:03, David Sewell a ?crit : > Shayne has created virtual hosts by language: > > http://en.guidelines.tei-c.org/ > http://de.guidelines.tei-c.org/ > http://es.guidelines.tei-c.org/ > http://fr.guidelines.tei-c.org/ > http://it.guidelines.tei-c.org/ > http://kr.guidelines.tei-c.org/ > http://zh-tw.guidelines.tei-c.org/ > > He overlooked one for Japanese so I've asked for that. > > Please consider and provide feedback on two problems with this system: > > 1. each of the above URLs currently goes to the top level of the > language documentation release, i.e. one directory above /html. Should > we: > > a) make 'html' explicit in all links to the HTML version of the > Guidelines, i.e. for English link to > http://en.guidelines.tei-c.org/html/, or > > b) add a rewrite rule so http://en.guidelines.tei-c.org/ ==> > http://en.guidelines.tei-c.org/html/ ? > > (one disadvantage of 'b' is that Web crawlers going to the domain > might > miss any non-HTML content. Or is that a good thing?) > > 2) If you're at http://en.guidelines.tei-c.org/html/ and click on any > other language version, the link is broken (because it's generated > as a > relative link). Likewise, the alternate language links in the > Reference > pages. Are we willing to convert all language-specific links to use > the > domain aliases? > > Obviously, those problems need solving and other testing should be > done > before we can advertise the existence of these virtual hosts. Unless > we > want to use those hosts only as a way to get Google to index by > language? > > David > > -- > David Sewell, Editorial and Technical Manager > ROTUNDA, The University of Virginia Press > PO Box 801079, Charlottesville, VA 22904-4318 USA > Courier: 310 Old Ivy Way, Suite 302, Charlottesville VA 22903 > Email: dsewell at virginia.edu Tel: +1 434 924 9973 > Web: http://rotunda.upress.virginia.edu/ > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Laurent Romary INRIA & HUB-IDSL laurent.romary at inria.fr From laurent.romary at loria.fr Thu Mar 25 11:21:44 2010 From: laurent.romary at loria.fr (Laurent Romary) Date: Thu, 25 Mar 2010 16:21:44 +0100 Subject: [tei-council] Fwd: [tei-board] call for proposals -- SIG Grants References: <4BAB5490.6040102@gmail.com> Message-ID: Council: I need two volunteers to stand in this committee and react quickly just before our meeting in APril. Send me a message telling me if you really really want to be there, or if you are just ready to fill in a gap (this will help me to sort things out if I have 10 volunteers ;-)). Thanks, Laurent D?but du message r?exp?di? : > De : Susan Schreibman > Date : 25 mars 2010 13:18:24 GMT+01:00 > ? : TEI Board of Directors > Objet : [tei-board] call for proposals -- SIG Grants > R?pondre ? : tei-board at lists.village.Virginia.EDU > > All --- rather belatedly I have revised the call from last year and > paste it in below. Lou -- I believe at the Board meeting you > expressed a > desire to be the Board rep. Laurent -- would you ask Council for two > people to adjudicate. I closed the grant on Monday the 26th so that we > might meet during the Council meeting in Dublin and made decisions. > Could you get me two names ASAP and I will announce, pending any > changes > the Board suggests. > > May I ask for any changes by Saturday the 27th. > > > many thanks and forgive the rush > > **************** > > Grant Call for TEI Special Interest Groups > Proposals Due 23 April 2010 > Total Call: $8,000 > > The TEI Board is delighted to announce on foot of the extremely > successful call for proposals from the 2009 grant call, we are > issuing a > call for 2010 with a significantly increased budget. > > All TEI SIGs are eligible to apply. Projects proposed should support > the > goals of the TEI, the objectives of the SIG, and should be carried out > within the calendar year 2010. Any of the nine SIGs that have been > approved by Council are eligible to apply: > > 1. Correspondence > 2. Education > 3. Libraries > 4. Manuscripts > 5. Music > 6. Ontologies > 7.Scholarly Publishing > 8. Text and Graphics > 9. Tools > > Applications will be adjudicated according to the following criteria: > > ? activity contributes to the promotion and development of the TEI; > ? activity is broadly in line with the goals and objectives of the > SIG; > ? the SIG is judged able to carry out the proposed activity; > ? deliverables are realistic and can be accomplished within the budget > and time period proposed. > > Although there is no upper amount for any individual proposal, > applicants should bear in mind that the total amount for this grant > call > is $8,000. Applications must be submitted by the SIG Chairs (although > the grant can be originated by any SIG member). No more than one > application per SIG will be accepted. > > Proposals should be no longer than three pages (ca. 750 words) and > should contain the following information: > > 1. Name and contact details of proposer > 2. SIG name > 3. Narrative addressing the points above > 4. Amount requested > 5. Date for final report > > > For further details, please email Susan Schreibman > susan.schreibman at gmail.com > The adjudication committee is comprised of > Susan Schreibman, Chair > Lou Bernard (Board Representative) > ?? (Council Representative) > ?? (Council Representative) > > -- > Susan Schreibman, PhD > Director > Digital Humanities Observatory > 28-32 Pembroke Street Upper > Dublin 2 > -- A project of the Royal Irish Academy -- > > Phone: +353 1 234 2440 > Mobile: +353 86 049 1966 > Fax: +353 1 234 2588 > Email:` s.schreibman at ria.ie > > http://dho.ie > http://irith.org > http://macgreevy.org > http://v-machine.org > > > > _______________________________________________ > tei-board mailing list > tei-board at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-board Laurent Romary INRIA & HUB-IDSL laurent.romary at inria.fr From daniel.odonnell at uleth.ca Thu Mar 25 11:51:35 2010 From: daniel.odonnell at uleth.ca (O'Donnell, Dan) Date: Thu, 25 Mar 2010 09:51:35 -0600 Subject: [tei-council] Influential Blogs? Message-ID: <4BAB8687.9030608@uleth.ca> Hi all, I have a request from the marketing people at Apex, that I thought the people here might be able to help with: > In the same vein of marketing TEI, we are looking into blogs where we > could advertise the service. Do you know of any blogs or blogging > platforms that are particularly associated with digitization or that > might be frequented by people who might want digitization services? Any suggestions? Obviously our own new and improved newserver and Digital Medievalist. But are there other influential blogs or newservers we should consider hitting? -dan -- Daniel Paul O'Donnell Associate Professor of English University of Lethbridge Chair and CEO, Text Encoding Initiative (http://www.tei-c.org/) Co-Chair, Digital Initiatives Advisory Board, Medieval Academy of America President-elect (English), Society for Digital Humanities/Soci?t? pour l'?tude des m?dias interactifs (http://sdh-semi.org/) Founding Director (2003-2009), Digital Medievalist Project (http://www.digitalmedievalist.org/) Vox: +1 403 329-2377 Fax: +1 403 382-7191 (non-confidential) Home Page: http://people.uleth.ca/~daniel.odonnell/ From kevin.s.hawkins at ultraslavonic.info Thu Mar 25 12:08:51 2010 From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins) Date: Thu, 25 Mar 2010 16:08:51 +0000 Subject: [tei-council] Influential Blogs? In-Reply-To: <4BAB8687.9030608@uleth.ca> References: <4BAB8687.9030608@uleth.ca> Message-ID: <4BAB8A93.7020408@ultraslavonic.info> Dan, Are they looking to announce AccessTEI? If so, shouldn't this be a joint press release between the TEI-C and Apex? Is AccessTEI actually ready to be announced? The last we heard from you on February 11, Perry Trolard was making some revisions based on suggestions from Apex and was going to bring them to the Council for approval. My offer to help with this (sent to you and Perry on March 14) and in particular to deal with the interface of Tite and the Best Practices for TEI in Libraries still stands. Kevin On 25/03/2010 15:51, O'Donnell, Dan wrote: > Hi all, > > I have a request from the marketing people at Apex, that I thought the > people here might be able to help with: > >> In the same vein of marketing TEI, we are looking into blogs where we >> could advertise the service. Do you know of any blogs or blogging >> platforms that are particularly associated with digitization or that >> might be frequented by people who might want digitization services? > Any suggestions? Obviously our own new and improved newserver and > Digital Medievalist. But are there other influential blogs or newservers > we should consider hitting? > > -dan > From julianne.nyhan at gmail.com Thu Mar 25 12:36:05 2010 From: julianne.nyhan at gmail.com (Julianne Nyhan) Date: Thu, 25 Mar 2010 17:36:05 +0100 Subject: [tei-council] Influential Blogs? In-Reply-To: <4BAB8A93.7020408@ultraslavonic.info> References: <4BAB8687.9030608@uleth.ca> <4BAB8A93.7020408@ultraslavonic.info> Message-ID: <30b37191003250936y3ee3ee4chc2548a4df427dd7@mail.gmail.com> Hello, the TEI-EJ website includes (in addition to journal articles) other site content, including Blog, Forum, Featured Projects, and Tutorials. The site has not been made public yet, but we are still on track to make our first publication in Summer 2010 (and we expect to make all additional site functionalities available then too). A joint press release will certainly be welcome on the Blog. Best, Julianne On Thu, Mar 25, 2010 at 5:08 PM, Kevin Hawkins < kevin.s.hawkins at ultraslavonic.info> wrote: > Dan, > > Are they looking to announce AccessTEI? If so, shouldn't this be a > joint press release between the TEI-C and Apex? > > Is AccessTEI actually ready to be announced? The last we heard from you > on February 11, Perry Trolard was making some revisions based on > suggestions from Apex and was going to bring them to the Council for > approval. My offer to help with this (sent to you and Perry on March > 14) and in particular to deal with the interface of Tite and the Best > Practices for TEI in Libraries still stands. > > Kevin > > On 25/03/2010 15:51, O'Donnell, Dan wrote: > > Hi all, > > > > I have a request from the marketing people at Apex, that I thought the > > people here might be able to help with: > > > >> In the same vein of marketing TEI, we are looking into blogs where we > >> could advertise the service. Do you know of any blogs or blogging > >> platforms that are particularly associated with digitization or that > >> might be frequented by people who might want digitization services? > > Any suggestions? Obviously our own new and improved newserver and > > Digital Medievalist. But are there other influential blogs or newservers > > we should consider hitting? > > > > -dan > > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > -- Dr Julianne Nyhan, Kompetenzzentrum f?r elektronische Erschlie?ungs- und Publikationsverfahren in den Geisteswissenschaften Universit?t Trier Fachbereich II / Germanistik Universit?tsring 15 54286 Trier + 49 (0)651 201-3358 http://germazope.uni-trier.de/Projects/KoZe2/ http://epu.ucc.ie/theses/jnyhan/ http://maney.co.uk/index.php/journals/isr/ http://www.tei-c.org/Activities/SIG/Education/index.xml From lou.burnard at oucs.ox.ac.uk Thu Mar 25 13:13:49 2010 From: lou.burnard at oucs.ox.ac.uk (Lou) Date: Thu, 25 Mar 2010 17:13:49 +0000 Subject: [tei-council] Influential Blogs? In-Reply-To: <4BAB8A93.7020408@ultraslavonic.info> References: <4BAB8687.9030608@uleth.ca> <4BAB8A93.7020408@ultraslavonic.info> Message-ID: <4BAB99CD.5010806@oucs.ox.ac.uk> Yes, I wondered about that too. I had some discussion with Perry some weeks ago, and made a few comments on the current state of Tite. We are still waiting for a version of it to fly past the Council, are we not? I say nothing about its reprehensible recommendations about using :-( Lou Kevin Hawkins wrote: > Dan, > > Are they looking to announce AccessTEI? If so, shouldn't this be a > joint press release between the TEI-C and Apex? > > Is AccessTEI actually ready to be announced? The last we heard from you > on February 11, Perry Trolard was making some revisions based on > suggestions from Apex and was going to bring them to the Council for > approval. My offer to help with this (sent to you and Perry on March > 14) and in particular to deal with the interface of Tite and the Best > Practices for TEI in Libraries still stands. > > Kevin > > On 25/03/2010 15:51, O'Donnell, Dan wrote: >> Hi all, >> >> I have a request from the marketing people at Apex, that I thought the >> people here might be able to help with: >> >>> In the same vein of marketing TEI, we are looking into blogs where we >>> could advertise the service. Do you know of any blogs or blogging >>> platforms that are particularly associated with digitization or that >>> might be frequented by people who might want digitization services? >> Any suggestions? Obviously our own new and improved newserver and >> Digital Medievalist. But are there other influential blogs or newservers >> we should consider hitting? >> >> -dan >> > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council From gabriel.bodard at kcl.ac.uk Thu Mar 25 14:03:12 2010 From: gabriel.bodard at kcl.ac.uk (Gabriel Bodard) Date: Thu, 25 Mar 2010 18:03:12 +0000 Subject: [tei-council] Influential Blogs? In-Reply-To: <30b37191003250936y3ee3ee4chc2548a4df427dd7@mail.gmail.com> References: <4BAB8687.9030608@uleth.ca> <4BAB8A93.7020408@ultraslavonic.info> <30b37191003250936y3ee3ee4chc2548a4df427dd7@mail.gmail.com> Message-ID: <4BABA560.5000508@kcl.ac.uk> The Stoa blog (http://www.stoa.org/) is also fairly widely read in DH circles, I think. Arts-humanities.net might also be a good place for a joint press release... On 2010-03-25 16:36, Julianne Nyhan wrote: > Hello, > > the TEI-EJ website includes (in addition to journal articles) other site > content, including Blog, Forum, Featured Projects, and Tutorials. The site > has not been made public yet, > but we are still on track to make our first publication in Summer 2010 (and > we expect to make all additional site functionalities available then too). A > joint press release will certainly be welcome on the Blog. > > Best, > Julianne > > > > > On Thu, Mar 25, 2010 at 5:08 PM, Kevin Hawkins< > kevin.s.hawkins at ultraslavonic.info> wrote: > >> Dan, >> >> Are they looking to announce AccessTEI? If so, shouldn't this be a >> joint press release between the TEI-C and Apex? >> >> Is AccessTEI actually ready to be announced? The last we heard from you >> on February 11, Perry Trolard was making some revisions based on >> suggestions from Apex and was going to bring them to the Council for >> approval. My offer to help with this (sent to you and Perry on March >> 14) and in particular to deal with the interface of Tite and the Best >> Practices for TEI in Libraries still stands. >> >> Kevin >> >> On 25/03/2010 15:51, O'Donnell, Dan wrote: >>> Hi all, >>> >>> I have a request from the marketing people at Apex, that I thought the >>> people here might be able to help with: >>> >>>> In the same vein of marketing TEI, we are looking into blogs where we >>>> could advertise the service. Do you know of any blogs or blogging >>>> platforms that are particularly associated with digitization or that >>>> might be frequented by people who might want digitization services? >>> Any suggestions? Obviously our own new and improved newserver and >>> Digital Medievalist. But are there other influential blogs or newservers >>> we should consider hitting? >>> >>> -dan >>> >> _______________________________________________ >> tei-council mailing list >> tei-council at lists.village.Virginia.EDU >> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council >> > > > -- Dr Gabriel BODARD (Epigrapher & Digital Classicist) Centre for Computing in the Humanities King's College London 26-29 Drury Lane London WC2B 5RL Email: gabriel.bodard at kcl.ac.uk Tel: +44 (0)20 7848 1388 Fax: +44 (0)20 7848 2980 http://www.digitalclassicist.org/ http://www.currentepigraphy.org/ From daniel.odonnell at uleth.ca Thu Mar 25 15:18:56 2010 From: daniel.odonnell at uleth.ca (O'Donnell, Dan) Date: Thu, 25 Mar 2010 13:18:56 -0600 Subject: [tei-council] Influential Blogs? In-Reply-To: <4BAB8A93.7020408@ultraslavonic.info> References: <4BAB8687.9030608@uleth.ca> <4BAB8A93.7020408@ultraslavonic.info> Message-ID: <4BABB720.8010206@uleth.ca> Thanks Kevin, The portal is three weeks away from being finished, they claim. In terms of the schema, we decided in consultation with Lou and Laurent (and Apex, of course) to clean up what we had, but to defer the issue of coordination with the encoding levels and the issue of generating schemas positively from tei-all as a longer term project. I'm supposed to report on this at the council meeting, but that might also be a good time to launch this properly as a council project. -dan Kevin Hawkins wrote: > Dan, > > Are they looking to announce AccessTEI? If so, shouldn't this be a > joint press release between the TEI-C and Apex? > > Is AccessTEI actually ready to be announced? The last we heard from you > on February 11, Perry Trolard was making some revisions based on > suggestions from Apex and was going to bring them to the Council for > approval. My offer to help with this (sent to you and Perry on March > 14) and in particular to deal with the interface of Tite and the Best > Practices for TEI in Libraries still stands. > > Kevin > > On 25/03/2010 15:51, O'Donnell, Dan wrote: > >> Hi all, >> >> I have a request from the marketing people at Apex, that I thought the >> people here might be able to help with: >> >> >>> In the same vein of marketing TEI, we are looking into blogs where we >>> could advertise the service. Do you know of any blogs or blogging >>> platforms that are particularly associated with digitization or that >>> might be frequented by people who might want digitization services? >>> >> Any suggestions? Obviously our own new and improved newserver and >> Digital Medievalist. But are there other influential blogs or newservers >> we should consider hitting? >> >> -dan >> >> > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > -- Daniel Paul O'Donnell Associate Professor of English University of Lethbridge Chair and CEO, Text Encoding Initiative (http://www.tei-c.org/) Co-Chair, Digital Initiatives Advisory Board, Medieval Academy of America President-elect (English), Society for Digital Humanities/Soci?t? pour l'?tude des m?dias interactifs (http://sdh-semi.org/) Founding Director (2003-2009), Digital Medievalist Project (http://www.digitalmedievalist.org/) Vox: +1 403 329-2377 Fax: +1 403 382-7191 (non-confidential) Home Page: http://people.uleth.ca/~daniel.odonnell/ From daniel.odonnell at uleth.ca Thu Mar 25 15:27:02 2010 From: daniel.odonnell at uleth.ca (O'Donnell, Dan) Date: Thu, 25 Mar 2010 13:27:02 -0600 Subject: [tei-council] Influential Blogs? In-Reply-To: <4BAB99CD.5010806@oucs.ox.ac.uk> References: <4BAB8687.9030608@uleth.ca> <4BAB8A93.7020408@ultraslavonic.info> <4BAB99CD.5010806@oucs.ox.ac.uk> Message-ID: <4BABB906.2080404@uleth.ca> If you remember Lou, we had the discussion about clearing up the examples and language, and then providing Apex with a fixed schema we could refer to for the first year. This was so we could then be free to work on the larger issues that came up about generating schemas by including rather than deleting examples and the issue of levels. You'd suggested that I report to Council on that work and discuss the future directions we might decide to go in. -dan Lou wrote: > Yes, I wondered about that too. I had some discussion with Perry some > weeks ago, and made a few comments on the current state of Tite. We are > still waiting for a version of it to fly past the Council, are we not? > > I say nothing about its reprehensible recommendations about using > > :-( > > Lou > > > Kevin Hawkins wrote: > >> Dan, >> >> Are they looking to announce AccessTEI? If so, shouldn't this be a >> joint press release between the TEI-C and Apex? >> >> Is AccessTEI actually ready to be announced? The last we heard from you >> on February 11, Perry Trolard was making some revisions based on >> suggestions from Apex and was going to bring them to the Council for >> approval. My offer to help with this (sent to you and Perry on March >> 14) and in particular to deal with the interface of Tite and the Best >> Practices for TEI in Libraries still stands. >> >> Kevin >> >> On 25/03/2010 15:51, O'Donnell, Dan wrote: >> >>> Hi all, >>> >>> I have a request from the marketing people at Apex, that I thought the >>> people here might be able to help with: >>> >>> >>>> In the same vein of marketing TEI, we are looking into blogs where we >>>> could advertise the service. Do you know of any blogs or blogging >>>> platforms that are particularly associated with digitization or that >>>> might be frequented by people who might want digitization services? >>>> >>> Any suggestions? Obviously our own new and improved newserver and >>> Digital Medievalist. But are there other influential blogs or newservers >>> we should consider hitting? >>> >>> -dan >>> >>> >> _______________________________________________ >> tei-council mailing list >> tei-council at lists.village.Virginia.EDU >> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council >> > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > -- Daniel Paul O'Donnell Associate Professor of English University of Lethbridge Chair and CEO, Text Encoding Initiative (http://www.tei-c.org/) Co-Chair, Digital Initiatives Advisory Board, Medieval Academy of America President-elect (English), Society for Digital Humanities/Soci?t? pour l'?tude des m?dias interactifs (http://sdh-semi.org/) Founding Director (2003-2009), Digital Medievalist Project (http://www.digitalmedievalist.org/) Vox: +1 403 329-2377 Fax: +1 403 382-7191 (non-confidential) Home Page: http://people.uleth.ca/~daniel.odonnell/ From lou.burnard at oucs.ox.ac.uk Thu Mar 25 16:30:45 2010 From: lou.burnard at oucs.ox.ac.uk (Lou Burnard) Date: Thu, 25 Mar 2010 20:30:45 +0000 Subject: [tei-council] Influential Blogs? In-Reply-To: <4BABB720.8010206@uleth.ca> References: <4BAB8687.9030608@uleth.ca> <4BAB8A93.7020408@ultraslavonic.info> <4BABB720.8010206@uleth.ca> Message-ID: <4BABC7F5.20207@oucs.ox.ac.uk> O'Donnell, Dan wrote: > > The portal is three weeks away from being finished, they claim. In terms > of the schema, we decided in consultation with Lou and Laurent (and > Apex, of course) to clean up what we had, but to defer the issue of > coordination with the encoding levels and the issue of generating > schemas positively from tei-all as a longer term project. What does "generating schemas positively from tei-all" mean? If Tite is to be presented as a TEI schema it must have an ODD and it must be derived from the TEI in a conformant manner. We decided that years (literally) ago. From sebastian.rahtz at oucs.ox.ac.uk Thu Mar 25 16:48:34 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Thu, 25 Mar 2010 20:48:34 +0000 Subject: [tei-council] Influential Blogs? In-Reply-To: <4BABC7F5.20207@oucs.ox.ac.uk> References: <4BAB8687.9030608@uleth.ca> <4BAB8A93.7020408@ultraslavonic.info> <4BABB720.8010206@uleth.ca> <4BABC7F5.20207@oucs.ox.ac.uk> Message-ID: <8C27BD29-D32C-428D-BCE9-F4965D0A43ED@oucs.ox.ac.uk> On 25 Mar 2010, at 20:30, Lou Burnard wrote: > > What does "generating schemas positively from tei-all" mean? I think Dan just means that Tite will need to use the to-come-whatever-we-decid method of writing an ODD in terms of inclusion rather than exclusion. Worryingly, the tei-meta list discussion convened to discuss how this is to work is going nowhere fast :-{ -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From lou.burnard at oucs.ox.ac.uk Thu Mar 25 17:09:23 2010 From: lou.burnard at oucs.ox.ac.uk (Lou Burnard) Date: Thu, 25 Mar 2010 21:09:23 +0000 Subject: [tei-council] Influential Blogs? In-Reply-To: <8C27BD29-D32C-428D-BCE9-F4965D0A43ED@oucs.ox.ac.uk> References: <4BAB8687.9030608@uleth.ca> <4BAB8A93.7020408@ultraslavonic.info> <4BABB720.8010206@uleth.ca> <4BABC7F5.20207@oucs.ox.ac.uk> <8C27BD29-D32C-428D-BCE9-F4965D0A43ED@oucs.ox.ac.uk> Message-ID: <4BABD103.3060608@oucs.ox.ac.uk> Thanks for the explanation. However, surely we shouldn't make production of a Tite ODD contingent on definition of the next version of ODD? That seems a bit strange. Sebastian Rahtz wrote: > On 25 Mar 2010, at 20:30, Lou Burnard wrote: > >> What does "generating schemas positively from tei-all" mean? > > > I think Dan just means that Tite will need to use the to-come-whatever-we-decid method > of writing an ODD in terms of inclusion rather than exclusion. > > Worryingly, the tei-meta list discussion convened to discuss how this > is to work is going nowhere fast :-{ > -- > Sebastian Rahtz > Information Manager, Oxford University Computing Services > 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 > > S?lo le pido a Dios > que el futuro no me sea indiferente > > > > From sebastian.rahtz at oucs.ox.ac.uk Thu Mar 25 17:14:32 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Thu, 25 Mar 2010 21:14:32 +0000 Subject: [tei-council] Influential Blogs? In-Reply-To: <4BABD103.3060608@oucs.ox.ac.uk> References: <4BAB8687.9030608@uleth.ca> <4BAB8A93.7020408@ultraslavonic.info> <4BABB720.8010206@uleth.ca> <4BABC7F5.20207@oucs.ox.ac.uk> <8C27BD29-D32C-428D-BCE9-F4965D0A43ED@oucs.ox.ac.uk> <4BABD103.3060608@oucs.ox.ac.uk> Message-ID: <3B70A0BF-15CC-40A3-892E-271F36FF2855@oucs.ox.ac.uk> On 25 Mar 2010, at 21:09, Lou Burnard wrote: > Thanks for the explanation. However, surely we shouldn't make production > of a Tite ODD contingent on definition of the next version of ODD? That > seems a bit strange. I think Dan is suggesting that we issue just a schema now, rather than the source ODD, for this reason. I make no claim to have an opinion in this matter; though I do think it is essential that the full proposal for Tite^2 be presented to the Council meeting in Ireland next month for discussion. It really does the full-blooded support of this group, not be a matter of a last-minute rubber-stamp. -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From daniel.odonnell at uleth.ca Thu Mar 25 17:21:57 2010 From: daniel.odonnell at uleth.ca (O'Donnell, Dan) Date: Thu, 25 Mar 2010 15:21:57 -0600 Subject: [tei-council] Influential Blogs? In-Reply-To: <4BABD103.3060608@oucs.ox.ac.uk> References: <4BAB8687.9030608@uleth.ca> <4BAB8A93.7020408@ultraslavonic.info> <4BABB720.8010206@uleth.ca> <4BABC7F5.20207@oucs.ox.ac.uk> <8C27BD29-D32C-428D-BCE9-F4965D0A43ED@oucs.ox.ac.uk> <4BABD103.3060608@oucs.ox.ac.uk> Message-ID: <4BABD3F5.6060302@uleth.ca> Lou: this is exactly the conclusion you, Laurent, and I came to a month or so ago: AccessTEI is a project and it needs a specific instantiation to work with rather than a way of producing instances. This also frees us up to work on Tite without worrying about retraining people in India every time we make a change; and it allowed us to intervene by hand to remove the inappropriate examples. I'm not sure we are disagreeing here at all. Lou Burnard wrote: > Thanks for the explanation. However, surely we shouldn't make > production of a Tite ODD contingent on definition of the next version > of ODD? That seems a bit strange. > > Sebastian Rahtz wrote: >> On 25 Mar 2010, at 20:30, Lou Burnard wrote: >> >>> What does "generating schemas positively from tei-all" mean? >> >> >> I think Dan just means that Tite will need to use the >> to-come-whatever-we-decid method >> of writing an ODD in terms of inclusion rather than exclusion. >> >> Worryingly, the tei-meta list discussion convened to discuss how this >> is to work is going nowhere fast :-{ >> -- >> Sebastian Rahtz Information Manager, Oxford University Computing >> Services >> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 >> >> S?lo le pido a Dios >> que el futuro no me sea indiferente >> >> >> >> > -- Daniel Paul O'Donnell Associate Professor of English University of Lethbridge Chair and CEO, Text Encoding Initiative (http://www.tei-c.org/) Co-Chair, Digital Initiatives Advisory Board, Medieval Academy of America President-elect (English), Society for Digital Humanities/Soci?t? pour l'?tude des m?dias interactifs (http://sdh-semi.org/) Founding Director (2003-2009), Digital Medievalist Project (http://www.digitalmedievalist.org/) Vox: +1 403 329-2377 Fax: +1 403 382-7191 (non-confidential) Home Page: http://people.uleth.ca/~daniel.odonnell/ From sebastian.rahtz at oucs.ox.ac.uk Thu Mar 25 17:28:32 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Thu, 25 Mar 2010 21:28:32 +0000 Subject: [tei-council] Influential Blogs? In-Reply-To: <4BABD3F5.6060302@uleth.ca> References: <4BAB8687.9030608@uleth.ca> <4BAB8A93.7020408@ultraslavonic.info> <4BABB720.8010206@uleth.ca> <4BABC7F5.20207@oucs.ox.ac.uk> <8C27BD29-D32C-428D-BCE9-F4965D0A43ED@oucs.ox.ac.uk> <4BABD103.3060608@oucs.ox.ac.uk> <4BABD3F5.6060302@uleth.ca> Message-ID: <31D9A956-C294-4C98-B828-4F30E554FC64@oucs.ox.ac.uk> On 25 Mar 2010, at 21:21, O'Donnell, Dan wrote: > Lou: this is exactly the conclusion you, Laurent, and I came to a month > or so ago: AccessTEI is a project and it needs a specific instantiation > to work with rather than a way of producing instances. This also frees > us up to work on Tite without worrying about retraining people in India > every time we make a change; and it allowed us to intervene by hand to > remove the inappropriate examples. I probably agree with you, but to be honest I don't at all understand what you mean by "a specific instantiation to work with rather than a way of producing instances" can you say it again in words of one syllable for me? and what do you mean by "intervene by hand to remove the inappropriate examples"? -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From daniel.odonnell at uleth.ca Thu Mar 25 18:09:18 2010 From: daniel.odonnell at uleth.ca (O'Donnell, Dan) Date: Thu, 25 Mar 2010 16:09:18 -0600 Subject: [tei-council] Influential Blogs? In-Reply-To: <31D9A956-C294-4C98-B828-4F30E554FC64@oucs.ox.ac.uk> References: <4BAB8687.9030608@uleth.ca> <4BAB8A93.7020408@ultraslavonic.info> <4BABB720.8010206@uleth.ca> <4BABC7F5.20207@oucs.ox.ac.uk> <8C27BD29-D32C-428D-BCE9-F4965D0A43ED@oucs.ox.ac.uk> <4BABD103.3060608@oucs.ox.ac.uk> <4BABD3F5.6060302@uleth.ca> <31D9A956-C294-4C98-B828-4F30E554FC64@oucs.ox.ac.uk> Message-ID: <4BABDF0E.6000800@uleth.ca> Sebastian Rahtz wrote: > On 25 Mar 2010, at 21:21, O'Donnell, Dan wrote: > > >> Lou: this is exactly the conclusion you, Laurent, and I came to a month >> or so ago: AccessTEI is a project and it needs a specific instantiation >> to work with rather than a way of producing instances. This also frees >> us up to work on Tite without worrying about retraining people in India >> every time we make a change; and it allowed us to intervene by hand to >> remove the inappropriate examples. >> > > > I probably agree with you, but to be honest I don't at all understand what you mean > by "a specific instantiation to work with rather than a way of producing instances" > > can you say it again in words of one syllable for me? > > and what do you mean by "intervene by hand to remove the > inappropriate examples"? > Sorry Sebastian, I've not been expressing myself well all week. Let me try again: what I mean is that although in the accessTEI contract we specified the Tite ODD rather than a specific schema or DTD as being the reference for the programme (after some discussion in Council), it turned out that that is not really very practical if the ODD is not completely locked down. Like any project, AccessTEI wants its schemas to change more slowly than the ODD might, especially if we on council pick up and look at some of the ideas for development we've been discussing here over the last while. In addition, the problems caused by defining an ODD by exclusion rather than inclusion turned out to be quite serious in constructing a training programme for the keyers in India: meaning (at the moment) that we needed to do some hand tweaking (removing examples, for example, that contained elements not found in Tite or used them in alternate ways when Tite restricts prefers one method over the other). So what I meant was that, again like most of us when we start our projects, AccessTEI developed a schema and coding guidelines based on the way the Tite ODD was on the day it was generated (this is what I meant by an instantiation); but it won't be returning to the ODD to generate new schemas and documentation (what I meant when I said it was better to have "a specific instantiation to work with rather than [only] a way of producing instances") for a little while--presumably until it is felt that the changes in the Tite ODD are such as to make regenerating the ODD and retraining the keyers worth the effort involved. This means that we at Council are free to concentrate on the issues that would really improve things, without worrying about whether making changes in the ODD would require a retraining of the keyers. Some of the big things that would make it worthwhile revisiting the ODD and regenerating the AccessTEI schema are the things we've been talking about: better integration with the DLF coding levels, changing the way we make ODDs so that it could proceed by inclusion rather than exclusion, working on the way examples are included in ODDs that are subsets. So while initially (at our last teleco, for example) I thought--with Lou and others--that it might be necessary to do some work on and locking down of the Tite ODD in order to start the Apex training programme, on reflection and discussion, it became clear that in actual fact there was nothing we needed to do to the ODD--all the issues involved tweaking and cleaning up artefacts of the generation process in response to the specific demands of the training programme for the keyers. So baiscally we generated the schemas from the canonical ODD and then did the kind of by-hand removal of examples that don't work so well in Tite that we were discussing at Council when we raised the problem a couple of weeks ago or so. -dan > -- > Sebastian Rahtz > Information Manager, Oxford University Computing Services > 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 > > S?lo le pido a Dios > que el futuro no me sea indiferente > > > > > -- Daniel Paul O'Donnell Associate Professor of English University of Lethbridge Chair and CEO, Text Encoding Initiative (http://www.tei-c.org/) Co-Chair, Digital Initiatives Advisory Board, Medieval Academy of America President-elect (English), Society for Digital Humanities/Soci?t? pour l'?tude des m?dias interactifs (http://sdh-semi.org/) Founding Director (2003-2009), Digital Medievalist Project (http://www.digitalmedievalist.org/) Vox: +1 403 329-2377 Fax: +1 403 382-7191 (non-confidential) Home Page: http://people.uleth.ca/~daniel.odonnell/ From sebastian.rahtz at oucs.ox.ac.uk Thu Mar 25 18:22:26 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Thu, 25 Mar 2010 22:22:26 +0000 Subject: [tei-council] Influential Blogs? In-Reply-To: <4BABDF0E.6000800@uleth.ca> References: <4BAB8687.9030608@uleth.ca> <4BAB8A93.7020408@ultraslavonic.info> <4BABB720.8010206@uleth.ca> <4BABC7F5.20207@oucs.ox.ac.uk> <8C27BD29-D32C-428D-BCE9-F4965D0A43ED@oucs.ox.ac.uk> <4BABD103.3060608@oucs.ox.ac.uk> <4BABD3F5.6060302@uleth.ca> <31D9A956-C294-4C98-B828-4F30E554FC64@oucs.ox.ac.uk> <4BABDF0E.6000800@uleth.ca> Message-ID: <928BC12E-2C8C-4106-877A-79FA5201B6BB@oucs.ox.ac.uk> On 25 Mar 2010, at 22:09, O'Donnell, Dan wrote: > completely locked down. Like any project, AccessTEI wants its schemas to > change more slowly than the ODD might, especially if we on council pick > up and look at some of the ideas for development we've been discussing > here over the last while. So what you really want is for Tite to be tied to a specific release of the TEI. Even when we move to ODD-by-inclusion, new TEI versions may still make changes that percolate to Tite. > meaning (at the moment) that we > needed to do some hand tweaking (removing examples, for example, that > contained elements not found in Tite or used them in alternate ways when > Tite restricts prefers one method over the other). what are you giving the folks in India? obviously the schema has no examples in. You mean you are giving them a cut-down version of P5 Guidelines based on Tite? thats fine, of course, but why do you need to hand-edit anything? you can describe all the example changes you need in the ODD. > > So what I meant was that, again like most of us when we start our > projects, AccessTEI developed a schema and coding guidelines based on > the way the Tite ODD was on the day it was generated (this is what I > meant by an instantiation); but it won't be returning to the ODD to > generate new schemas and documentation ever? you mean your manual changes and the original ODD will get out of sync. That sounds, excuse me, like a complete disaster which makes me very unhappy. But hopefully I am misunderstanding :-} > So while initially (at our last teleco, for example) I thought--with Lou > and others--that it might be necessary to do some work on and locking > down of the Tite ODD in order to start the Apex training programme, on > reflection and discussion, it became clear that in actual fact there was > nothing we needed to do to the ODD--all the issues involved tweaking and > cleaning up artefacts of the generation process in response to the > specific demands of the training programme for the keyers. So baiscally > we generated the schemas from the canonical ODD and then did the kind of > by-hand removal of examples that don't work so well in Tite that we were > discussing at Council when we raised the problem a couple of weeks ago > or so. as I said, there are no examples in the schema(s), so I am guess you mean the documentation, which is presumably non-normative anyway. The phrase "tweaking and cleaning up artefacts of the generation process" comes over to me like a red rag to a bull, I am afraid. -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From lou.burnard at oucs.ox.ac.uk Thu Mar 25 20:21:58 2010 From: lou.burnard at oucs.ox.ac.uk (Lou Burnard) Date: Fri, 26 Mar 2010 00:21:58 +0000 Subject: [tei-council] Tite (was re Influential Blogs?) In-Reply-To: <4BABDF0E.6000800@uleth.ca> References: <4BAB8687.9030608@uleth.ca> <4BAB8A93.7020408@ultraslavonic.info> <4BABB720.8010206@uleth.ca> <4BABC7F5.20207@oucs.ox.ac.uk> <8C27BD29-D32C-428D-BCE9-F4965D0A43ED@oucs.ox.ac.uk> <4BABD103.3060608@oucs.ox.ac.uk> <4BABD3F5.6060302@uleth.ca> <31D9A956-C294-4C98-B828-4F30E554FC64@oucs.ox.ac.uk> <4BABDF0E.6000800@uleth.ca> Message-ID: <4BABFE26.5070607@oucs.ox.ac.uk> O'Donnell, Dan wrote: > Sorry Sebastian, I've not been expressing myself well all week. Let me > try again: what I mean is that although in the accessTEI contract we > specified the Tite ODD rather than a specific schema or DTD as being the > reference for the programme (after some discussion in Council), it > turned out that that is not really very practical if the ODD is not > completely locked down. Like any project, AccessTEI wants its schemas to > change more slowly than the ODD might, especially if we on council pick > up and look at some of the ideas for development we've been discussing > here over the last while. This makes no sense to me, sorry. The Tite ODD defines the Tite schema and you can't talk about them independently. The schema is generated from the ODD. The problem we discussed earlier is that the schema generated from a given ODD is also determined by the version of the Guidelines against which the ODD is processed. Hence the requirement to tie the ODD to a specific release of the Guidelines, as previously discussed. > > In addition, the problems caused by defining an ODD by exclusion rather > than inclusion turned out to be quite serious in constructing a training > programme for the keyers in India: meaning (at the moment) that we > needed to do some hand tweaking (removing examples, for example, that > contained elements not found in Tite or used them in alternate ways when > Tite restricts prefers one method over the other). As I already suggested to Perry, and you (I thought) agreed, the right way to handle this is to supply Tite-specific examples in the ODD. Which will generate appropriate documentation. And then regenerate the schemas -- against the right version of the Guidelines! By the way, I haven't seen any response to my comments of 3 March about the absence of a header in Tite. Will we get to discuss this and other problems in the schema when it is presented to the Council? From laurent.romary at inria.fr Tue Mar 30 12:49:14 2010 From: laurent.romary at inria.fr (Laurent Romary) Date: Tue, 30 Mar 2010 18:49:14 +0200 Subject: [tei-council] Fwd: Internet draft revised References: <4BB227F8.7000902@uvic.ca> Message-ID: <0BC655A7-4B51-463B-B1FB-A0EE681569B3@inria.fr> Hi Council, Can I get the opinion of the others on this? Cheers, Laurent D?but du message r?exp?di? : > De : Martin Holmes > Date : 30 mars 2010 18:34:00 GMT+02:00 > ? : TEI-L at listserv.brown.edu > Objet : R?p : Internet draft revised > R?pondre ? : mholmes at uvic.ca > > Me too. I don't think it's likely that anyone is going to write a > web application or browser plugin that aims at dealing with generic > P4 code. > > Cheers, > Martin > > Sebastian Rahtz wrote: >> I'm with Brett, let's keep it clean and forward looking. Just P5 >> onwards. >> -- >> Sebastian Rahtz (acting) Information and Support Group Manager >> Oxford University Computing Services >> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 >> S?lo le pido a Dios >> que el futuro no me sea indiferente > > -- > Martin Holmes > University of Victoria Humanities Computing and Media Centre > (mholmes at uvic.ca) > Half-Baked Software, Inc. > (mholmes at halfbakedsoftware.com) > martin at mholmes.com Laurent Romary INRIA & HUB-IDSL laurent.romary at inria.fr From dot.porter at gmail.com Tue Mar 30 16:17:28 2010 From: dot.porter at gmail.com (Dot Porter) Date: Tue, 30 Mar 2010 16:17:28 -0400 Subject: [tei-council] Fwd: Internet draft revised In-Reply-To: <0BC655A7-4B51-463B-B1FB-A0EE681569B3@inria.fr> References: <4BB227F8.7000902@uvic.ca> <0BC655A7-4B51-463B-B1FB-A0EE681569B3@inria.fr> Message-ID: <96f3df641003301317i33bf47e6i619b32cc4b2eb3e6@mail.gmail.com> I'm pretty sure I'm with the looking ahead / P5 only camp. What kind of practical issues/problems might come with having an application/tei+xml mediatype apply only to P5 files, vs. applying to previous versions as well? As Martin says, new tools will most likely be P5 specific in any case... P5 is so different from previous versions, it seems that having a separate mediatype would be preferable, from an application-development point of view. Dot On Tue, Mar 30, 2010 at 12:49 PM, Laurent Romary wrote: > Hi Council, > Can I get the opinion of the others on this? > Cheers, > Laurent > > > D?but du message r?exp?di? : > >> De : Martin Holmes >> Date : 30 mars 2010 18:34:00 GMT+02:00 >> ? : TEI-L at listserv.brown.edu >> Objet : R?p : Internet draft revised >> R?pondre ? : mholmes at uvic.ca >> >> Me too. I don't think it's likely that anyone is going to write a >> web application or browser plugin that aims at dealing with generic >> P4 code. >> >> Cheers, >> Martin >> >> Sebastian Rahtz wrote: >>> I'm with Brett, let's keep it clean and forward looking. Just P5 >>> onwards. >>> -- >>> Sebastian Rahtz ? ? ?(acting) Information and Support Group Manager >>> Oxford University Computing Services >>> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 >>> S?lo le pido a Dios >>> que el futuro no me sea indiferente >> >> -- >> Martin Holmes >> University of Victoria Humanities Computing and Media Centre >> (mholmes at uvic.ca) >> Half-Baked Software, Inc. >> (mholmes at halfbakedsoftware.com) >> martin at mholmes.com > > Laurent Romary > INRIA & HUB-IDSL > laurent.romary at inria.fr > > > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > -- *~*~*~*~*~*~*~*~*~*~* Dot Porter (MA, MSLS) Metadata Manager (on leave) Digital Humanities Observatory (RIA), Regus House, 28-32 Upper Pembroke Street, Dublin 2, Ireland -- A Project of the Royal Irish Academy -- Phone: +353 1 234 2444 Fax: +353 1 234 2400 http://dho.ie Email: dot.porter at gmail.com *~*~*~*~*~*~*~*~*~*~* From kevin.s.hawkins at ultraslavonic.info Thu Apr 1 12:40:08 2010 From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins) Date: Thu, 01 Apr 2010 17:40:08 +0100 Subject: [tei-council] Fwd: Update re. group booking for TEI Council members Message-ID: <4BB4CC68.6080307@ultraslavonic.info> All, Below you'll find a confirmation of the arrival and departure dates as on file at the Temple Bar Hotel. If you need to adjust your reservation, please contact Annette Ryan. Kevin -------- Original Message -------- Subject: Update re. group booking for TEI Council members Date: Thu, 1 Apr 2010 17:35:54 +0100 From: Emily Cullen To: Kevin Hawkins Kevin, Below is the updated list re. TEI Council accommodation at the Temple Bar Hotel. Again the special corporate rate is ?69 and this is for a double room for single occupancy. Please inform Council members that if they wish to make any changes to their booking they should contact Annette Ryan at the Temple Bar Hotel as she is the person in charge of group bookings and she is handling this particular group reservation. Her contact details are: Annette Ryan Reservations Manager Temple Bar Hotel Fleet Street Dublin 2 Direct line: 01 6129292 Fax: 01 6773088 E-mail: annetteryan at tbh.ie All best, Emily 26/04 27/04 28/04 29/04 30/04 1/05 Sebastian Rahtz 0 1 1 1 0 0 Gabriel Bodard 0 1 1 1 1 0 Martin Holmes 1 1 1 1 1 1 Elena Pierazzo 0 0 1 1 1 0 Julianne Nyhan 0 1 1 1 1 0 James Cummings 0 1 1 1 1 1 Dan O'Donnel 0 0 1 1 1 0 Laurent Romary 0 1 1 1 0 0 Brett Barney 0 0 1 1 1 0 Matthew Driscoll 0 1 1 1 1 1 -- Emily Cullen, Ph.D., Programme Co-ordinator Digital Humanities Observatory 28-32 Upper Pembroke Street Dublin 2 Ireland Tel: +353(0)1-2342442 Fax:+353(0)1-2342400 E-mail: e.cullen at ria.ie http://dho.ie -- -- A Project of the Royal Irish Academy -- From kevin.s.hawkins at ultraslavonic.info Mon Apr 5 05:33:52 2010 From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins) Date: Mon, 05 Apr 2010 10:33:52 +0100 Subject: [tei-council] Virtual language-based TEI Guidelines hosts are live but incomplete In-Reply-To: <660F89FF-75EF-42D1-A9E8-8508453D7BA6@loria.fr> References: <660F89FF-75EF-42D1-A9E8-8508453D7BA6@loria.fr> Message-ID: <4BB9AE80.4000604@ultraslavonic.info> (1a) sounds fine to me as long converting the language-specific links isn't going to be a big problem. But I think the Oxford team needs to weigh in ... On 24/03/2010 08:08, Laurent Romary wrote: > Hi David, > I am taking up on this... Thanks for having implemented this so > quickly. > I would favor 1.a indeed. > As to 2. It would be good to test this with our Oxford colleagues and > define the easiest procedure (also from the point of view of > maintenance). > Oxford: what do you think? > Laurent > > Le 21 mars 10 ? 01:03, David Sewell a ?crit : > >> Shayne has created virtual hosts by language: >> >> http://en.guidelines.tei-c.org/ >> http://de.guidelines.tei-c.org/ >> http://es.guidelines.tei-c.org/ >> http://fr.guidelines.tei-c.org/ >> http://it.guidelines.tei-c.org/ >> http://kr.guidelines.tei-c.org/ >> http://zh-tw.guidelines.tei-c.org/ >> >> He overlooked one for Japanese so I've asked for that. >> >> Please consider and provide feedback on two problems with this system: >> >> 1. each of the above URLs currently goes to the top level of the >> language documentation release, i.e. one directory above /html. Should >> we: >> >> a) make 'html' explicit in all links to the HTML version of the >> Guidelines, i.e. for English link to >> http://en.guidelines.tei-c.org/html/, or >> >> b) add a rewrite rule so http://en.guidelines.tei-c.org/ ==> >> http://en.guidelines.tei-c.org/html/ ? >> >> (one disadvantage of 'b' is that Web crawlers going to the domain >> might >> miss any non-HTML content. Or is that a good thing?) >> >> 2) If you're at http://en.guidelines.tei-c.org/html/ and click on any >> other language version, the link is broken (because it's generated >> as a >> relative link). Likewise, the alternate language links in the >> Reference >> pages. Are we willing to convert all language-specific links to use >> the >> domain aliases? >> >> Obviously, those problems need solving and other testing should be >> done >> before we can advertise the existence of these virtual hosts. Unless >> we >> want to use those hosts only as a way to get Google to index by >> language? >> >> David >> >> -- >> David Sewell, Editorial and Technical Manager >> ROTUNDA, The University of Virginia Press >> PO Box 801079, Charlottesville, VA 22904-4318 USA >> Courier: 310 Old Ivy Way, Suite 302, Charlottesville VA 22903 >> Email: dsewell at virginia.edu Tel: +1 434 924 9973 >> Web: http://rotunda.upress.virginia.edu/ >> _______________________________________________ >> tei-council mailing list >> tei-council at lists.village.Virginia.EDU >> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > > Laurent Romary > INRIA& HUB-IDSL > laurent.romary at inria.fr > > > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council From sebastian.rahtz at oucs.ox.ac.uk Mon Apr 5 06:48:12 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 5 Apr 2010 11:48:12 +0100 Subject: [tei-council] Virtual language-based TEI Guidelines hosts are live but incomplete In-Reply-To: <4BB9AE80.4000604@ultraslavonic.info> References: <660F89FF-75EF-42D1-A9E8-8508453D7BA6@loria.fr> <4BB9AE80.4000604@ultraslavonic.info> Message-ID: >>> 2) If you're at http://en.guidelines.tei-c.org/html/ and click on any >>> other language version, the link is broken (because it's generated >>> as a >>> relative link). Likewise, the alternate language links in the >>> Reference >>> pages. Are we willing to convert all language-specific links to use >>> the >>> domain aliases? That would be harsh on people who install the documentation locally. It might be easier to do it with Apache rewrites on the server. so make http://de.guidelines.tei-c.org/it rewrite to http://it.guidelines.tei-c.org/html would that be easy enough, David? and yes, I would suggest that jumping straight to html/ would be fine, we don't -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From dsewell at virginia.edu Mon Apr 5 10:41:23 2010 From: dsewell at virginia.edu (David Sewell) Date: Mon, 5 Apr 2010 10:41:23 -0400 (EDT) Subject: [tei-council] Virtual language-based TEI Guidelines hosts are live but incomplete In-Reply-To: References: <660F89FF-75EF-42D1-A9E8-8508453D7BA6@loria.fr> <4BB9AE80.4000604@ultraslavonic.info> Message-ID: On Mon, 5 Apr 2010, Sebastian Rahtz wrote: > >>> 2) If you're at http://en.guidelines.tei-c.org/html/ and click on any > >>> other language version, the link is broken (because it's generated > >>> as a > >>> relative link). Likewise, the alternate language links in the > >>> Reference > >>> pages. Are we willing to convert all language-specific links to use > >>> the > >>> domain aliases? > > That would be harsh on people who install the documentation locally. > It might be easier to do it with Apache rewrites on the server. so > make http://de.guidelines.tei-c.org/it rewrite to http://it.guidelines.tei-c.org/html > > would that be easy enough, David? Well, yes and no. It's straightforward, but it means having to maintain N * (N - 1) rewrite rules in the apache config file, where N = number of language versions (currently 8), and remembering to update them whenever a language is added. I can ask Shayne to do that if everyone agrees it is the way to go. But can you think of any other relative links that might be broken under the language-specific virtual servers? I haven't found any but I have not done extensive testing of the links. David -- David Sewell, Editorial and Technical Manager ROTUNDA, The University of Virginia Press PO Box 801079, Charlottesville, VA 22904-4318 USA Courier: 310 Old Ivy Way, Suite 302, Charlottesville VA 22903 Email: dsewell at virginia.edu Tel: +1 434 924 9973 Web: http://rotunda.upress.virginia.edu/ From sebastian.rahtz at oucs.ox.ac.uk Mon Apr 5 11:01:52 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 5 Apr 2010 16:01:52 +0100 Subject: [tei-council] Virtual language-based TEI Guidelines hosts are live but incomplete In-Reply-To: References: <660F89FF-75EF-42D1-A9E8-8508453D7BA6@loria.fr> <4BB9AE80.4000604@ultraslavonic.info> Message-ID: On 5 Apr 2010, at 15:41, David Sewell wrote: > > Well, yes and no. It's straightforward, but it means having to maintain > N * (N - 1) rewrite rules in the apache config file, where N = number of > language versions (currently 8), and remembering to update them whenever > a language is added. one could imagine a little script which generated the Apache config files? > > I can ask Shayne to do that if everyone agrees it is the way to go. But > can you think of any other relative links that might be broken under the > language-specific virtual servers? I haven't found any but I have not > done extensive testing of the links. the good thing about my suggestion is that it would deal with any of the pre-existing links.... -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From lou.burnard at oucs.ox.ac.uk Wed Apr 7 13:05:00 2010 From: lou.burnard at oucs.ox.ac.uk (Lou) Date: Wed, 07 Apr 2010 18:05:00 +0100 Subject: [tei-council] Ticket status Message-ID: <4BBCBB3C.6090309@oucs.ox.ac.uk> As old hands will know, a major part of our ftf council meeting will be a review of the outstanding support tickets on the SF repository, with a view to disposing of as many of them as possible. In preparation for that, I've just been trawling through the current state of affairs, dealing with any easy ones, and categorising the rest as RED (too hard) or AMBER (not entirely clear what we should do) or GREEN (clear what needs doing) As of this evening, the numbers of tickets in each category stand as follows: Bugs RED: 0 GREEN: 2 AMBER: 10 Feature Requests RED: 6 AMBER: 19 GREEN: 4 This all looks quite do-able, especially because several of the older RED and AMBER items are likely to be disposed of as a by product of the other work planned for Dublin (specifically, consideration of the "new ODD", "genetic editing", and "biblStruct" draft proposals) In the meantime though, could I urge council members to take a look at some of these tickets, particularly the older ones (tickets, not members), and express an opinion, or prepare themselves to do so in debate? If you need help on accessing the tickets, let me know off list and I'll gladly step you through the process. From Laurent.Romary at loria.fr Sun Apr 11 13:47:34 2010 From: Laurent.Romary at loria.fr (Laurent Romary) Date: Sun, 11 Apr 2010 19:47:34 +0200 Subject: [tei-council] Fwd: please post to tei-council list References: <19393.50512.840872.243621@emt.wwp.brown.edu> Message-ID: D?but du message r?exp?di? : > De : Syd Bauman > Date : 11 avril 2010 14:49:20 GMT+02:00 > ? : Laurent Romary > Objet : please post to tei-council list > R?pondre ? : Syd_Bauman at Brown.edu > > Re: constraints > > > Dear TEI Council -- > > I discovered at our recent seminar that the constraints for > were internally inconsistent, and did not match the > prose. > > The RELAX NG constraint said target= was optional, and a single child > element was required. The prose said that if target= was present, in > general a child would not be. The Schematron check stated that if > both were present, it was an error, but the XPath test did not > actually check for child elements, but text() node descendants. (If > the child element is empty, then there may be no text() node > descendants; thus the formal check really said "if target= is present > then only an empty child element is allowed", thus missing target= > and or an accidentally empty .) > > So I have checked in a new version that "fixes" some of these > problems, but opens a can of worms. > > Fixed corrigible errors: > * added > * changed so that a child element is optional in RELAX NG > constraint > > Consequent fixes: > * added a Schematron rule to check that either target= or a child > element is present > * changed remarks to make it clear that both target= and a child > element are not allowed > > Questionable fix: > * altered existing Schematron rule to check for existence of child > elements, rather than text() descendant. > > Problems for Council to consider: > > 1) Should both target= and a child element be allowed? I am pretty > sure that ala SF FR 2728061[1], only one or the other should be > present. > > Personally, I agree with the conclusion in the ticket, that the > answer should be 'no': should have *either* a > target= or a child element, but not both. > > 2) IF the answer to (1) is "no", THEN Council also needs to consider > whether or not is allowed inside at all. I.e., > whether it makes sense to allow both > > and > > > > Note that if the answer to (1) is "yes", then needs to be > allowed as content, in order to say > > > > which is why I really think the answer to (1) should be "no" :-) > See below for my opinion on (2) itself. > > 3) Note that if the answer to (2) is "no, is not allowed as a > child of , use target= instead", then cRef= needs to > be added to , too. This is a pain, and thus another > reason to answer (2) as "yes" (although not a good one :-). > > 4) Should be allowed to be empty? I.e., should > > be valid? > I think it should not be valid, as it is meaningless. > > > below) > I think that should be allowed as a child of , > so that one can use parallel constructs for pointers to related > items whether I happen to want to auto-generate the content or > not. I.e., I think users should be allowed to have > > > > > > > > untitled article by unknown author > > > > > when they want to auto-generate the references to A, B, and D, but > hand-generate the reference to C. Furthermore, users may wish to > use other attributes on (most obviously type=). > > > BTW, this problem wouldn't be nearly so complicated if target= hadn't > been added to . I think that was a sizable mistake. It > added quite a bit of complication to save ~20-25 characters worth of > extra markup. Which, using oXygen's fancy completion, only takes a > few extra keystrokes to get inserted. > > P.S. In researching this I found reference to a suggested value list > for type= of invented by PS. I think having a > semi-open list of suggested values for type= of is > really important. This is a confusing issue, and many users will > have the exact same needs, may as well be using the same values. > > Notes > ----- > [1] https://sourceforge.net/tracker/?func=detail&atid=644065&aid=2728061&group_id=106328 Laurent Romary INRIA & HUB-IDSL laurent.romary at inria.fr From laurent.romary at inria.fr Wed Apr 14 05:01:09 2010 From: laurent.romary at inria.fr (Laurent Romary) Date: Wed, 14 Apr 2010 11:01:09 +0200 Subject: [tei-council] Agenda for Dublin Message-ID: <56FC2B2D-135C-4AEA-A97E-75C00BC2538C@inria.fr> Dear all, I have set a preliminary agenda for our f2f under http://wiki.tei-c.org/index.php/Council Please have a quick look and see: - whether you would want to have other points discussed - whether you are ready to take up the lead for one of the discussions (short presentation of the issue) Thanks, Laurent Laurent Romary INRIA & HUB-IDSL laurent.romary at inria.fr From mholmes at uvic.ca Fri Apr 16 11:06:02 2010 From: mholmes at uvic.ca (Martin Holmes) Date: Fri, 16 Apr 2010 08:06:02 -0700 Subject: [tei-council] Flights to Europe for the Dublin meeting Message-ID: <4BC87CDA.4070108@uvic.ca> HI all, I thought I should let everyone know that my trip to Dublin is looking a bit endangered by this volcano thing. I'm due to fly to Manchester on Monday, and then spend a week there getting un-jetlagged with family before flying to Dublin the following week. If this chaos goes on, and my flight next week is cancelled, it seems unlikely I'd be able to rearrange it for later in the week, given the fact that millions of people will be in a huge queue to be moved around the world as soon as the skies open up again. So if my flight goes on Monday, I should be able to get there one way or another even if airports close again, because I can go by rail and ferry to Dublin from Manchester. But if I don't get out on Monday, I'll probably be screwed. Is anyone else in a similar position? Cheers, Martin -- Martin Holmes University of Victoria Humanities Computing and Media Centre (mholmes at uvic.ca) Half-Baked Software, Inc. (mholmes at halfbakedsoftware.com) martin at mholmes.com From laurent.romary at inria.fr Fri Apr 16 11:50:44 2010 From: laurent.romary at inria.fr (Laurent Romary) Date: Fri, 16 Apr 2010 17:50:44 +0200 Subject: [tei-council] Flights to Europe for the Dublin meeting In-Reply-To: <4BC87CDA.4070108@uvic.ca> References: <4BC87CDA.4070108@uvic.ca> Message-ID: <3BAB3A7B-823F-4A53-8819-BA1EC3739EF9@inria.fr> Don't tell me. I was supposed to fly to Paris tomorrow morning. We're in a situation where we should just adapt and see how to do our best. We would definitely regret you if you're not there! If I were to be pessimistic, the news are saying that this may last for a few weeks... Cheers, Laurent Le 16 avr. 10 ? 17:06, Martin Holmes a ?crit : > HI all, > > I thought I should let everyone know that my trip to Dublin is > looking a > bit endangered by this volcano thing. I'm due to fly to Manchester on > Monday, and then spend a week there getting un-jetlagged with family > before flying to Dublin the following week. If this chaos goes on, and > my flight next week is cancelled, it seems unlikely I'd be able to > rearrange it for later in the week, given the fact that millions of > people will be in a huge queue to be moved around the world as soon as > the skies open up again. > > So if my flight goes on Monday, I should be able to get there one > way or > another even if airports close again, because I can go by rail and > ferry > to Dublin from Manchester. But if I don't get out on Monday, I'll > probably be screwed. > > Is anyone else in a similar position? > > Cheers, > Martin > -- > Martin Holmes > University of Victoria Humanities Computing and Media Centre > (mholmes at uvic.ca) > Half-Baked Software, Inc. > (mholmes at halfbakedsoftware.com) > martin at mholmes.com > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Laurent Romary INRIA & HUB-IDSL laurent.romary at inria.fr From kevin.s.hawkins at ultraslavonic.info Sun Apr 18 10:35:35 2010 From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins) Date: Sun, 18 Apr 2010 15:35:35 +0100 Subject: [tei-council] Virtual language-based TEI Guidelines hosts are live but incomplete In-Reply-To: References: <660F89FF-75EF-42D1-A9E8-8508453D7BA6@loria.fr> <4BB9AE80.4000604@ultraslavonic.info> Message-ID: <4BCB18B7.9080905@ultraslavonic.info> Sebastian's message below was truncated, so I'm not sure if he had more to say. David, what do you think of Sebastian's idea to have Apache rewrites? Kevin On 05/04/2010 11:48, Sebastian Rahtz wrote: >>>> 2) If you're at http://en.guidelines.tei-c.org/html/ and click on any >>>> other language version, the link is broken (because it's generated >>>> as a >>>> relative link). Likewise, the alternate language links in the >>>> Reference >>>> pages. Are we willing to convert all language-specific links to use >>>> the >>>> domain aliases? > > That would be harsh on people who install the documentation locally. > It might be easier to do it with Apache rewrites on the server. so > make http://de.guidelines.tei-c.org/it rewrite to http://it.guidelines.tei-c.org/html > > would that be easy enough, David? > > and yes, I would suggest that jumping straight to html/ would be fine, we don't > -- > Sebastian Rahtz > Information Manager, Oxford University Computing Services > 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 > > S?lo le pido a Dios > que el futuro no me sea indiferente > > > > From dsewell at virginia.edu Mon Apr 19 10:02:07 2010 From: dsewell at virginia.edu (David Sewell) Date: Mon, 19 Apr 2010 10:02:07 -0400 (EDT) Subject: [tei-council] Virtual language-based TEI Guidelines hosts are live but incomplete In-Reply-To: <4BCB18B7.9080905@ultraslavonic.info> References: <660F89FF-75EF-42D1-A9E8-8508453D7BA6@loria.fr> <4BB9AE80.4000604@ultraslavonic.info> <4BCB18B7.9080905@ultraslavonic.info> Message-ID: I was waiting for more feedback from Council before asking Shayne to implement this. Just as a reminder, the suggestion was to use apache rewrites so that the links to other languages from, for example http://en.guidelines.tei-c.org/html/ will not be broken. How about: if I don't hear any objection before tomorrow, I will ask Shayne to implement this. After that, plus a bit of testing, we should be able to advertise the new URLs. (Will a message to TEI-L suffice?) David On Sun, 18 Apr 2010, Kevin Hawkins wrote: > Sebastian's message below was truncated, so I'm not sure if he had more > to say. > > David, what do you think of Sebastian's idea to have Apache rewrites? > > Kevin > > On 05/04/2010 11:48, Sebastian Rahtz wrote: > >>>> 2) If you're at http://en.guidelines.tei-c.org/html/ and click on any > >>>> other language version, the link is broken (because it's generated > >>>> as a > >>>> relative link). Likewise, the alternate language links in the > >>>> Reference > >>>> pages. Are we willing to convert all language-specific links to use > >>>> the > >>>> domain aliases? > > > > That would be harsh on people who install the documentation locally. > > It might be easier to do it with Apache rewrites on the server. so > > make http://de.guidelines.tei-c.org/it rewrite to http://it.guidelines.tei-c.org/html > > > > would that be easy enough, David? > > > > and yes, I would suggest that jumping straight to html/ would be fine, we don't > > -- > > Sebastian Rahtz > > Information Manager, Oxford University Computing Services > > 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 > > > > S?lo le pido a Dios > > que el futuro no me sea indiferente > > > > > > > > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > -- David Sewell, Editorial and Technical Manager ROTUNDA, The University of Virginia Press PO Box 801079, Charlottesville, VA 22904-4318 USA Courier: 310 Old Ivy Way, Suite 302, Charlottesville VA 22903 Email: dsewell at virginia.edu Tel: +1 434 924 9973 Web: http://rotunda.upress.virginia.edu/ From mholmes at uvic.ca Mon Apr 19 12:05:55 2010 From: mholmes at uvic.ca (Martin Holmes) Date: Mon, 19 Apr 2010 09:05:55 -0700 Subject: [tei-council] Flights to Europe for the Dublin meeting In-Reply-To: <3BAB3A7B-823F-4A53-8819-BA1EC3739EF9@inria.fr> References: <4BC87CDA.4070108@uvic.ca> <3BAB3A7B-823F-4A53-8819-BA1EC3739EF9@inria.fr> Message-ID: <4BCC7F63.2010000@uvic.ca> My flight to Europe has definitely been cancelled, and with the mounting chaos it's not going to be practical (or, frankly, sensible) to rearrange it for later in the week, so I'm not going to make it to Dublin unfortunately. I've already been in touch with Kevin about presenting from afar at the symposium (as four other people are already doing). Cheers, Martin Laurent Romary wrote: > Don't tell me. I was supposed to fly to Paris tomorrow morning. We're > in a situation where we should just adapt and see how to do our best. > We would definitely regret you if you're not there! > If I were to be pessimistic, the news are saying that this may last > for a few weeks... > Cheers, > Laurent > > > Le 16 avr. 10 ? 17:06, Martin Holmes a ?crit : > >> HI all, >> >> I thought I should let everyone know that my trip to Dublin is >> looking a >> bit endangered by this volcano thing. I'm due to fly to Manchester on >> Monday, and then spend a week there getting un-jetlagged with family >> before flying to Dublin the following week. If this chaos goes on, and >> my flight next week is cancelled, it seems unlikely I'd be able to >> rearrange it for later in the week, given the fact that millions of >> people will be in a huge queue to be moved around the world as soon as >> the skies open up again. >> >> So if my flight goes on Monday, I should be able to get there one >> way or >> another even if airports close again, because I can go by rail and >> ferry >> to Dublin from Manchester. But if I don't get out on Monday, I'll >> probably be screwed. >> >> Is anyone else in a similar position? >> >> Cheers, >> Martin >> -- >> Martin Holmes >> University of Victoria Humanities Computing and Media Centre >> (mholmes at uvic.ca) >> Half-Baked Software, Inc. >> (mholmes at halfbakedsoftware.com) >> martin at mholmes.com >> _______________________________________________ >> tei-council mailing list >> tei-council at lists.village.Virginia.EDU >> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > > Laurent Romary > INRIA & HUB-IDSL > laurent.romary at inria.fr > > > From laurent.romary at inria.fr Mon Apr 19 12:08:06 2010 From: laurent.romary at inria.fr (Laurent Romary) Date: Mon, 19 Apr 2010 18:08:06 +0200 Subject: [tei-council] Flights to Europe for the Dublin meeting In-Reply-To: <4BCC7F63.2010000@uvic.ca> References: <4BC87CDA.4070108@uvic.ca> <3BAB3A7B-823F-4A53-8819-BA1EC3739EF9@inria.fr> <4BCC7F63.2010000@uvic.ca> Message-ID: <40A34006-AC15-42B5-ACA6-287EBD956159@inria.fr> Dear all, I am following the situation in Europe as closely as possible and will try to set my mind about our meeting in a couple of days. The European Minsitry of transport meeting today should maybe clarify the situation (if not the sky). Laurent Le 19 avr. 10 ? 18:05, Martin Holmes a ?crit : > My flight to Europe has definitely been cancelled, and with the > mounting > chaos it's not going to be practical (or, frankly, sensible) to > rearrange it for later in the week, so I'm not going to make it to > Dublin unfortunately. I've already been in touch with Kevin about > presenting from afar at the symposium (as four other people are > already > doing). > > Cheers, > Martin > > Laurent Romary wrote: >> Don't tell me. I was supposed to fly to Paris tomorrow morning. We're >> in a situation where we should just adapt and see how to do our best. >> We would definitely regret you if you're not there! >> If I were to be pessimistic, the news are saying that this may last >> for a few weeks... >> Cheers, >> Laurent >> >> >> Le 16 avr. 10 ? 17:06, Martin Holmes a ?crit : >> >>> HI all, >>> >>> I thought I should let everyone know that my trip to Dublin is >>> looking a >>> bit endangered by this volcano thing. I'm due to fly to Manchester >>> on >>> Monday, and then spend a week there getting un-jetlagged with family >>> before flying to Dublin the following week. If this chaos goes on, >>> and >>> my flight next week is cancelled, it seems unlikely I'd be able to >>> rearrange it for later in the week, given the fact that millions of >>> people will be in a huge queue to be moved around the world as >>> soon as >>> the skies open up again. >>> >>> So if my flight goes on Monday, I should be able to get there one >>> way or >>> another even if airports close again, because I can go by rail and >>> ferry >>> to Dublin from Manchester. But if I don't get out on Monday, I'll >>> probably be screwed. >>> >>> Is anyone else in a similar position? >>> >>> Cheers, >>> Martin >>> -- >>> Martin Holmes >>> University of Victoria Humanities Computing and Media Centre >>> (mholmes at uvic.ca) >>> Half-Baked Software, Inc. >>> (mholmes at halfbakedsoftware.com) >>> martin at mholmes.com >>> _______________________________________________ >>> tei-council mailing list >>> tei-council at lists.village.Virginia.EDU >>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council >> >> Laurent Romary >> INRIA & HUB-IDSL >> laurent.romary at inria.fr >> >> >> > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Laurent Romary INRIA & HUB-IDSL laurent.romary at inria.fr From laurent.romary at inria.fr Tue Apr 20 10:00:04 2010 From: laurent.romary at inria.fr (Laurent Romary) Date: Tue, 20 Apr 2010 16:00:04 +0200 Subject: [tei-council] Virtual language-based TEI Guidelines hosts are live but incomplete In-Reply-To: References: <660F89FF-75EF-42D1-A9E8-8508453D7BA6@loria.fr> <4BB9AE80.4000604@ultraslavonic.info> <4BCB18B7.9080905@ultraslavonic.info> Message-ID: Hi David, It's been 24hours: see this as a green light. Laurent Le 19 avr. 10 ? 16:02, David Sewell a ?crit : > I was waiting for more feedback from Council before asking Shayne to > implement this. Just as a reminder, the suggestion was to use apache > rewrites so that the links to other languages from, for example > > http://en.guidelines.tei-c.org/html/ > > will not be broken. > > How about: if I don't hear any objection before tomorrow, I will ask > Shayne to implement this. After that, plus a bit of testing, we should > be able to advertise the new URLs. (Will a message to TEI-L suffice?) > > David > > On Sun, 18 Apr 2010, Kevin Hawkins wrote: > >> Sebastian's message below was truncated, so I'm not sure if he had >> more >> to say. >> >> David, what do you think of Sebastian's idea to have Apache rewrites? >> >> Kevin >> >> On 05/04/2010 11:48, Sebastian Rahtz wrote: >>>>>> 2) If you're at http://en.guidelines.tei-c.org/html/ and click >>>>>> on any >>>>>> other language version, the link is broken (because it's >>>>>> generated >>>>>> as a >>>>>> relative link). Likewise, the alternate language links in the >>>>>> Reference >>>>>> pages. Are we willing to convert all language-specific links to >>>>>> use >>>>>> the >>>>>> domain aliases? >>> >>> That would be harsh on people who install the documentation locally. >>> It might be easier to do it with Apache rewrites on the server. so >>> make http://de.guidelines.tei-c.org/it rewrite to http://it.guidelines.tei-c.org/html >>> >>> would that be easy enough, David? >>> >>> and yes, I would suggest that jumping straight to html/ would be >>> fine, we don't >>> -- >>> Sebastian Rahtz >>> Information Manager, Oxford University Computing Services >>> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 >>> >>> S?lo le pido a Dios >>> que el futuro no me sea indiferente >>> >>> >>> >>> >> _______________________________________________ >> tei-council mailing list >> tei-council at lists.village.Virginia.EDU >> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council >> > > -- > David Sewell, Editorial and Technical Manager > ROTUNDA, The University of Virginia Press > PO Box 801079, Charlottesville, VA 22904-4318 USA > Courier: 310 Old Ivy Way, Suite 302, Charlottesville VA 22903 > Email: dsewell at virginia.edu Tel: +1 434 924 9973 > Web: http://rotunda.upress.virginia.edu/_______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Laurent Romary INRIA & HUB-IDSL laurent.romary at inria.fr From dsewell at virginia.edu Tue Apr 20 11:54:16 2010 From: dsewell at virginia.edu (David Sewell) Date: Tue, 20 Apr 2010 11:54:16 -0400 (EDT) Subject: [tei-council] Virtual language-based TEI Guidelines hosts are live but incomplete In-Reply-To: References: <660F89FF-75EF-42D1-A9E8-8508453D7BA6@loria.fr> <4BB9AE80.4000604@ultraslavonic.info> <4BCB18B7.9080905@ultraslavonic.info> Message-ID: I have asked Shayne to add the Apache rewrite rules to get this working, and will let Council know when this is done. Then you can decide how best to advertise the existence of the pages. David On Tue, 20 Apr 2010, Laurent Romary wrote: > Hi David, > It's been 24hours: see this as a green light. > Laurent > > > Le 19 avr. 10 ? 16:02, David Sewell a ?crit : > > > I was waiting for more feedback from Council before asking Shayne to > > implement this. Just as a reminder, the suggestion was to use apache > > rewrites so that the links to other languages from, for example > > > > http://en.guidelines.tei-c.org/html/ > > > > will not be broken. > > > > How about: if I don't hear any objection before tomorrow, I will ask > > Shayne to implement this. After that, plus a bit of testing, we should > > be able to advertise the new URLs. (Will a message to TEI-L suffice?) > > > > David > > > > On Sun, 18 Apr 2010, Kevin Hawkins wrote: > > > > > Sebastian's message below was truncated, so I'm not sure if he had more > > > to say. > > > > > > David, what do you think of Sebastian's idea to have Apache rewrites? > > > > > > Kevin > > > > > > On 05/04/2010 11:48, Sebastian Rahtz wrote: > > > > > > > 2) If you're at http://en.guidelines.tei-c.org/html/ and click on > > > > > > > any > > > > > > > other language version, the link is broken (because it's generated > > > > > > > as a > > > > > > > relative link). Likewise, the alternate language links in the > > > > > > > Reference > > > > > > > pages. Are we willing to convert all language-specific links to > > > > > > > use > > > > > > > the > > > > > > > domain aliases? > > > > > > > > That would be harsh on people who install the documentation locally. > > > > It might be easier to do it with Apache rewrites on the server. so > > > > make http://de.guidelines.tei-c.org/it rewrite to > > > > http://it.guidelines.tei-c.org/html > > > > > > > > would that be easy enough, David? > > > > > > > > and yes, I would suggest that jumping straight to html/ would be fine, > > > > we don't > > > > -- > > > > Sebastian Rahtz > > > > Information Manager, Oxford University Computing Services > > > > 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 > > > > > > > > S?lo le pido a Dios > > > > que el futuro no me sea indiferente > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > tei-council mailing list > > > tei-council at lists.village.Virginia.EDU > > > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > > > > > > > -- > > David Sewell, Editorial and Technical Manager > > ROTUNDA, The University of Virginia Press > > PO Box 801079, Charlottesville, VA 22904-4318 USA > > Courier: 310 Old Ivy Way, Suite 302, Charlottesville VA 22903 > > Email: dsewell at virginia.edu Tel: +1 434 924 9973 > > Web: > > http://rotunda.upress.virginia.edu/_______________________________________________ > > tei-council mailing list > > tei-council at lists.village.Virginia.EDU > > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > > Laurent Romary > INRIA & HUB-IDSL > laurent.romary at inria.fr > > > -- David Sewell, Editorial and Technical Manager ROTUNDA, The University of Virginia Press PO Box 801079, Charlottesville, VA 22904-4318 USA Courier: 310 Old Ivy Way, Suite 302, Charlottesville VA 22903 Email: dsewell at virginia.edu Tel: +1 434 924 9973 Web: http://rotunda.upress.virginia.edu/ From dsewell at virginia.edu Tue Apr 20 16:59:14 2010 From: dsewell at virginia.edu (David Sewell) Date: Tue, 20 Apr 2010 16:59:14 -0400 (EDT) Subject: [tei-council] TEI Guidelines virtual language hosts + some concerns Message-ID: All, The Guidelines virtual language hosts are now working. See linked pages at http://lister.ei.virginia.edu/~drs2n/test-links.html At the moment links from Spanish pages to other languages are broken but I've asked Shayne to correct the rewrite rule. HOWEVER... after all that work, I'm wondering if it is really worth advertising the results to the TEI community. There are a couple of issues. 1. If we claim to have language-specific P5 Guidelines hosts, it will seem all the more strange that we do not offer genuine complete translations of the Guidelines into any language besides English, and that most links will lead to macaronic pages that mingle English text with definitions and sometimes examples in another language. 2. I wish I had realized this sooner, but we did *not* need virtual hosts to enable searching on only French, German, etc., Guidelines localization. This can be done very easily using the appropriate Google search parameters. See the proof of concept in the bottom half of my test-links.html page (and look at the HTML source to see how it is done). Try searching for "application" using each of the 3 search options. When you do this in French, sure enough the French examples page for is the top hit. Even though most of the text there is in English...! And the French version of the ref page is near the top as well. The existing search box on most TEI-C pages could be extended this way. In addition, do we want to automatically generate a search box at the top of the HTML pages for the P5 Guidelines? It is inconsistent not to have one. I would suggest that if there is space on the April Council meeting agenda, perhaps you can discuss some of these things and come to decisions about exactly how you would like to present the Guidelines localizations and the search interface. David -- David Sewell, Editorial and Technical Manager ROTUNDA, The University of Virginia Press PO Box 801079, Charlottesville, VA 22904-4318 USA Courier: 310 Old Ivy Way, Suite 302, Charlottesville VA 22903 Email: dsewell at virginia.edu Tel: +1 434 924 9973 Web: http://rotunda.upress.virginia.edu/ From daniel.odonnell at uleth.ca Tue Apr 20 18:19:19 2010 From: daniel.odonnell at uleth.ca (O'Donnell, Dan) Date: Tue, 20 Apr 2010 16:19:19 -0600 Subject: [tei-council] TEI Guidelines virtual language hosts + some concerns In-Reply-To: References: Message-ID: <4BCE2867.4010701@uleth.ca> Thanks David! Both for the work and for the ideas for further (non-)development. David Sewell wrote: > All, > > The Guidelines virtual language hosts are now working. See linked pages at > > http://lister.ei.virginia.edu/~drs2n/test-links.html > > At the moment links from Spanish pages to other languages are broken but > I've asked Shayne to correct the rewrite rule. > > HOWEVER... after all that work, I'm wondering if it is really worth > advertising the results to the TEI community. There are a couple of issues. > > 1. If we claim to have language-specific P5 Guidelines hosts, it will seem > all the more strange that we do not offer genuine complete translations of > the Guidelines into any language besides English, and that most links will > lead to macaronic pages that mingle English text with definitions and > sometimes examples in another language. > > 2. I wish I had realized this sooner, but we did *not* need virtual > hosts to enable searching on only French, German, etc., Guidelines > localization. This can be done very easily using the appropriate Google > search parameters. See the proof of concept in the bottom half of my > test-links.html page (and look at the HTML source to see how it is > done). > > Try searching for "application" using each of the 3 search options. When you > do this in French, sure enough the French examples page for is > the top hit. Even though most of the text there is in English...! And the > French version of the ref page is near the top as well. > > The existing search box on most TEI-C pages could be extended this way. In > addition, do we want to automatically generate a search box at the top of > the HTML pages for the P5 Guidelines? It is inconsistent not to have one. > > I would suggest that if there is space on the April Council meeting agenda, > perhaps you can discuss some of these things and come to decisions about > exactly how you would like to present the Guidelines localizations and the > search interface. > > David > > -- Daniel Paul O'Donnell Professor of English University of Lethbridge Chair and CEO, Text Encoding Initiative (http://www.tei-c.org/) Co-Chair, Digital Initiatives Advisory Board, Medieval Academy of America President-elect (English), Society for Digital Humanities/Soci?t? pour l'?tude des m?dias interactifs (http://sdh-semi.org/) Founding Director (2003-2009), Digital Medievalist Project (http://www.digitalmedievalist.org/) Vox: +1 403 329-2377 Fax: +1 403 382-7191 (non-confidential) Home Page: http://people.uleth.ca/~daniel.odonnell/ From kevin.s.hawkins at ultraslavonic.info Wed Apr 21 10:40:31 2010 From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins) Date: Wed, 21 Apr 2010 15:40:31 +0100 Subject: [tei-council] TEI Guidelines virtual language hosts + some concerns In-Reply-To: References: Message-ID: <4BCF0E5F.8060202@ultraslavonic.info> Hi David, thanks for your continued work on this. We've got so much to discuss in Dublin anyway that I'm hoping we can resolve this by email. I only discovered the Google search box on tei-c.org a few weeks ago, after first bringing up this idea initially. As you point out, it's not included on any pages underneath http://www.tei-c.org/release/doc/tei-p5-doc/ (which is where I spend most of my time) and this is exactly the place where it would be most useful. Even seeing the box, it hadn't occurred to me that you could add parameters, as you've done already for searching P5 and P4. Frankly, I like the drop-down search box even more than virtual hosts since it suggests a mechanism to users for searching just the guidelines (or a particular language version) rather than hoping they know about tricks like using "site:" in a Google query. The only disadvantage is that I can't do a search directly from my Google search box in my browser by using the "site:" syntax. I can live without this. As for it being misleading that the non-English versions have some (or mostly) English-language content in them, someone who understands the i18n infrastructure should weigh in. So, my vote is to remove the virtual hosts and add the Google search box to the P5 HTML pages. If it's appropriate to also offer searches of P5 in other languages besides English, I would have these as additional drop-down options. On 20/04/2010 21:59, David Sewell wrote: > All, > > The Guidelines virtual language hosts are now working. See linked pages at > > http://lister.ei.virginia.edu/~drs2n/test-links.html > > At the moment links from Spanish pages to other languages are broken but > I've asked Shayne to correct the rewrite rule. > > HOWEVER... after all that work, I'm wondering if it is really worth > advertising the results to the TEI community. There are a couple of issues. > > 1. If we claim to have language-specific P5 Guidelines hosts, it will seem > all the more strange that we do not offer genuine complete translations of > the Guidelines into any language besides English, and that most links will > lead to macaronic pages that mingle English text with definitions and > sometimes examples in another language. > > 2. I wish I had realized this sooner, but we did *not* need virtual > hosts to enable searching on only French, German, etc., Guidelines > localization. This can be done very easily using the appropriate Google > search parameters. See the proof of concept in the bottom half of my > test-links.html page (and look at the HTML source to see how it is > done). > > Try searching for "application" using each of the 3 search options. When you > do this in French, sure enough the French examples page for is > the top hit. Even though most of the text there is in English...! And the > French version of the ref page is near the top as well. > > The existing search box on most TEI-C pages could be extended this way. In > addition, do we want to automatically generate a search box at the top of > the HTML pages for the P5 Guidelines? It is inconsistent not to have one. > > I would suggest that if there is space on the April Council meeting agenda, > perhaps you can discuss some of these things and come to decisions about > exactly how you would like to present the Guidelines localizations and the > search interface. > > David > From kevin.s.hawkins at ultraslavonic.info Wed Apr 21 11:03:06 2010 From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins) Date: Wed, 21 Apr 2010 16:03:06 +0100 Subject: [tei-council] update on next week in Dublin Message-ID: <4BCF13AA.7040902@ultraslavonic.info> All, I'm sure you're following the volcano situation and wondering whether you will be in Ireland next week. We are as well. However, the latest forecast is promising: http://www.irishtimes.com/newspaper/ireland/2010/0421/1224268771494.html Since Martin won't be joining us, we've canceled his reservation at the Temple Bar Hotel. *If anyone else learns for sure that they will not be coming,* please contact Annette Ryan (and only her!) at the Temple Bar Hotel as soon as possible to avoid cancellation penalties to the TEI-C. Annette is the person in charge of group bookings and she is handling our particular group reservation. Her contact details are: Annette Ryan Reservations Manager Temple Bar Hotel Fleet Street Dublin 2 Direct line: +353 1 6129292 Fax: +353 1 6773088 E-mail: annetteryan at tbh.ie Please also let us know so that know to order less food for you and to not expect any presentations from you. We are beginning at 9:30 a.m. on Wednesday, Thursday, and Friday. All three days are at the Royal Irish Academy, which is located at 19 Dawson Street, Dublin 2. Looking forward to seeing you here in Dublin. Kevin From kevin.s.hawkins at ultraslavonic.info Wed Apr 21 11:37:34 2010 From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins) Date: Wed, 21 Apr 2010 16:37:34 +0100 Subject: [tei-council] expenses for the Council meeting Message-ID: <4BCF1BBE.8030003@ultraslavonic.info> While we are holding the rooms for each of you (a double room with wifi and breakfast included for ?69 per night), you will need to pay for the room yourself upon check out and submit the receipt along with your other travel expenses using the form at http://www.tei-c.org/Admin/TEI_travel_form.pdf Expense forms should be submitted within 10 days of the end of the meeting. If you have any questions about reimbursement procedures, please email Sarah Wells, the TEI treasurer, at spw4s at virginia.edu . More details on reimbursement to follow in Dublin. From dsewell at virginia.edu Wed Apr 21 11:52:50 2010 From: dsewell at virginia.edu (David Sewell) Date: Wed, 21 Apr 2010 11:52:50 -0400 (EDT) Subject: [tei-council] TEI Guidelines virtual language hosts + some concerns In-Reply-To: <4BCF0E5F.8060202@ultraslavonic.info> References: <4BCF0E5F.8060202@ultraslavonic.info> Message-ID: On Wed, 21 Apr 2010, Kevin Hawkins wrote: > So, my vote is to remove the virtual hosts and add the Google search box to > the P5 HTML pages. If it's appropriate to also offer searches of P5 in other > languages besides English, I would have these as additional drop-down options. Even if we decide not to use the virtual hosts, we may as well leave them configured in case future localization work makes them desirable. (Plus I don't want to tell Shayne and the university DNS administrators, "sorry, we changed our mind about those...") -- David Sewell, Editorial and Technical Manager ROTUNDA, The University of Virginia Press PO Box 801079, Charlottesville, VA 22904-4318 USA Courier: 310 Old Ivy Way, Suite 302, Charlottesville VA 22903 Email: dsewell at virginia.edu Tel: +1 434 924 9973 Web: http://rotunda.upress.virginia.edu/ From daniel.odonnell at uleth.ca Wed Apr 21 16:12:45 2010 From: daniel.odonnell at uleth.ca (O'Donnell, Dan) Date: Wed, 21 Apr 2010 14:12:45 -0600 Subject: [tei-council] TEI Guidelines virtual language hosts + some concerns In-Reply-To: References: <4BCF0E5F.8060202@ultraslavonic.info> Message-ID: <4BCF5C3D.7000403@uleth.ca> David Sewell wrote: > On Wed, 21 Apr 2010, Kevin Hawkins wrote: > > >> So, my vote is to remove the virtual hosts and add the Google search box to >> the P5 HTML pages. If it's appropriate to also offer searches of P5 in other >> languages besides English, I would have these as additional drop-down options. >> > > Even if we decide not to use the virtual hosts, we may as well leave > them configured in case future localization work makes them desirable. > (Plus I don't want to tell Shayne and the university DNS administrators, > "sorry, we changed our mind about those...") > Maybe you should consider politics, David! (P.S. I understand the Tea Partiers are looking for leadership: I suspect you'd get on like a house on fire with them... literally). ;) > > -- Daniel Paul O'Donnell Professor of English University of Lethbridge Chair and CEO, Text Encoding Initiative (http://www.tei-c.org/) Co-Chair, Digital Initiatives Advisory Board, Medieval Academy of America President-elect (English), Society for Digital Humanities/Soci?t? pour l'?tude des m?dias interactifs (http://sdh-semi.org/) Founding Director (2003-2009), Digital Medievalist Project (http://www.digitalmedievalist.org/) Vox: +1 403 329-2377 Fax: +1 403 382-7191 (non-confidential) Home Page: http://people.uleth.ca/~daniel.odonnell/ From daniel.odonnell at uleth.ca Wed Apr 21 16:46:31 2010 From: daniel.odonnell at uleth.ca (O'Donnell, Dan) Date: Wed, 21 Apr 2010 14:46:31 -0600 Subject: [tei-council] easychair.org Message-ID: <4BCF6427.5010303@uleth.ca> Anybody have any experience with this? http://easychair.org/ -dan -- Daniel Paul O'Donnell Professor of English University of Lethbridge Chair and CEO, Text Encoding Initiative (http://www.tei-c.org/) Co-Chair, Digital Initiatives Advisory Board, Medieval Academy of America President-elect (English), Society for Digital Humanities/Soci?t? pour l'?tude des m?dias interactifs (http://sdh-semi.org/) Founding Director (2003-2009), Digital Medievalist Project (http://www.digitalmedievalist.org/) Vox: +1 403 329-2377 Fax: +1 403 382-7191 (non-confidential) Home Page: http://people.uleth.ca/~daniel.odonnell/ From laurent.romary at inria.fr Thu Apr 22 00:53:56 2010 From: laurent.romary at inria.fr (Laurent Romary) Date: Thu, 22 Apr 2010 06:53:56 +0200 Subject: [tei-council] easychair.org In-Reply-To: <4BCF6427.5010303@uleth.ca> References: <4BCF6427.5010303@uleth.ca> Message-ID: <003DC263-CEBE-4FCE-B875-6822F03986CD@inria.fr> Yeap. Several recent conference I have been reviewing for (ECDL, ACL) were managed on easychair. I am quite happy with it. You have all the usual functionalities, and i have not encountered a problem so far. Laurent Le 21 avr. 10 ? 22:46, O'Donnell, Dan a ?crit : > Anybody have any experience with this? http://easychair.org/ > > -dan > > -- > Daniel Paul O'Donnell > Professor of English > University of Lethbridge > > Chair and CEO, Text Encoding Initiative (http://www.tei-c.org/) > Co-Chair, Digital Initiatives Advisory Board, Medieval Academy of > America > President-elect (English), Society for Digital Humanities/Soci?t? > pour l'?tude des m?dias interactifs (http://sdh-semi.org/) > Founding Director (2003-2009), Digital Medievalist Project (http://www.digitalmedievalist.org/ > ) > > Vox: +1 403 329-2377 > Fax: +1 403 382-7191 (non-confidential) > Home Page: http://people.uleth.ca/~daniel.odonnell/ > > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Laurent Romary INRIA & HUB-IDSL laurent.romary at inria.fr From kevin.s.hawkins at ultraslavonic.info Fri Apr 23 13:29:36 2010 From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins) Date: Fri, 23 Apr 2010 18:29:36 +0100 Subject: [tei-council] for discussion in Dublin: proposed revisions to definitions of bibl, biblStruct, and biblFull Message-ID: <4BD1D900.4070004@ultraslavonic.info> Esteemed Colleagues, As you'll recall, at our last conference call (on 2010-02-07) we discussed bug 2714682 regarding biblScope as a child of imprint. Martin, Laurent, and I were charged with writing a proposal for consideration by the Council on revisions to the Guidelines (especially its examples) that would make clear how to use biblScope for various types of bibliographic citations, taking into account other encoding schemes for bibliographies. We found that we could not limit our investigation to this narrow question considering the broader deficiencies in the discussion of bibl, biblScope, and biblFull in the Guidelines. We examined the models of all of these elements and propose a number of changes that attempt to rationalize their use while also maintaining maximum backwards compatibility. In brief, the principles followed are: 1. Names should always be fully marked up in s. If the purpose of is to facilitate mechanical data parsing, it's essential to be able to separate forenames from surnames. 2. We prefer , , and to . 3. Punctuation should be kept outside data tags, otherwise a processor will be retrieving (for instance) names with commas in them. 4. Use of @level should be encouraged everywhere. It is often simple to deduce the level from the surrounding structure, but not always, so providing it is good practice. 5. should be available everywhere, so that URIs for electronic documents can be supplied at all levels. 6. Date values should be stored in @when wherever possible, so they can be validated. 7. Examples should not arbitrarily mix s and s in the same context; this is unlikely to happen, and seems needlessly confusing. 8. Values for biblScope/@type in the examples should be consistent with the suggested values in the element definition (i.e. "pp", not "pages", and "chap", not "chapter"). Ditto with title/@type ("sub", not "subordinate"). These principles, as well as specific (and often annotated) revisions to the prose of ? 2.7 and ? 3.11 of the Guidelines, are attached in a .doc file. (This file format was chosen for the ease of tracking revisions. We realize that our edits will need to be manually recreated in the ODD based on this, but we saw no better tool for our task at hand.) This document references SourceForge tickets that are required in order to address these principles above and which are required by our proposed changes to the prose of ? 3.11. It's a lot to look at, so we've tried to make it as easy as possible to review. With apologies for taking so long to produce this, please take a look before our discussion, currently scheduled for Thursday in Dublin. We have mused that if a P6 is ever created, we would like to return to these issues to propose a more significant changes to the content model of biblStruct to enforce more consistent encoding of bibliographic data -- or to abolish it entirely as ultimately unworkable for the range of citations we encounter in the world. We might also propose changing biblFull for more precise harmonization with ISBD. But this is all for another day. If you discover any points of confusion before Thursday, please contact Laurent, Martin, and me so that we can try to prepare a response in time for the discussion. Kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: biblio.doc Type: application/msword Size: 192780 bytes Desc: not available Url : http://lists.village.Virginia.EDU/pipermail/tei-council/attachments/20100423/935257f2/attachment.doc From kevin.s.hawkins at ultraslavonic.info Sat Apr 24 04:44:24 2010 From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins) Date: Sat, 24 Apr 2010 09:44:24 +0100 Subject: [tei-council] now in PDF! (for discussion in Dublin: proposed revisions to definitions of bibl, biblStruct, and biblFull) In-Reply-To: <4BD1D900.4070004@ultraslavonic.info> References: <4BD1D900.4070004@ultraslavonic.info> Message-ID: <4BD2AF68.1030606@ultraslavonic.info> While the "I" in "TEI" stands for interchange, there is no guarantee of interchange between Microsoft Word and OpenOffice.org. I'm attaching the proposal in PDF format. There's a greater chance of interchange here. --Kevin On 23/04/2010 18:29, Kevin Hawkins wrote: > Esteemed Colleagues, > > As you'll recall, at our last conference call (on 2010-02-07) we > discussed bug 2714682 regarding biblScope as a child of imprint. Martin, > Laurent, and I were charged with writing a proposal for consideration by > the Council on revisions to the Guidelines (especially its examples) > that would make clear how to use biblScope for various types of > bibliographic citations, taking into account other encoding schemes for > bibliographies. > > We found that we could not limit our investigation to this narrow > question considering the broader deficiencies in the discussion of bibl, > biblScope, and biblFull in the Guidelines. We examined the models of all > of these elements and propose a number of changes that attempt to > rationalize their use while also maintaining maximum backwards > compatibility. In brief, the principles followed are: > > 1. Names should always be fully marked up in s. If the > purpose of is to facilitate mechanical data parsing, it's > essential to be able to separate forenames from surnames. > > 2. We prefer , , and to type="whatever">. > > 3. Punctuation should be kept outside data tags, otherwise a processor > will be retrieving (for instance) names with commas in them. > > 4. Use of @level should be encouraged everywhere. It is often simple to > deduce the level from the surrounding structure, but not always, so > providing it is good practice. > > 5. should be available everywhere, so that URIs for electronic > documents can be supplied at all levels. > > 6. Date values should be stored in @when wherever possible, so they can > be validated. > > 7. Examples should not arbitrarily mix s and s in the > same context; this is unlikely to happen, and seems needlessly confusing. > > 8. Values for biblScope/@type in the examples should be consistent with > the suggested values in the element definition (i.e. "pp", > not "pages", and "chap", not "chapter"). Ditto with title/@type ("sub", > not "subordinate"). > > These principles, as well as specific (and often annotated) revisions to > the prose of ? 2.7 and ? 3.11 of the Guidelines, are attached in a .doc > file. (This file format was chosen for the ease of tracking revisions. > We realize that our edits will need to be manually recreated in the ODD > based on this, but we saw no better tool for our task at hand.) This > document references SourceForge tickets that are required in order to > address these principles above and which are required by our proposed > changes to the prose of ? 3.11. > > It's a lot to look at, so we've tried to make it as easy as possible to > review. With apologies for taking so long to produce this, please take a > look before our discussion, currently scheduled for Thursday in Dublin. > > We have mused that if a P6 is ever created, we would like to return to > these issues to propose a more significant changes to the content model > of biblStruct to enforce more consistent encoding of bibliographic data > -- or to abolish it entirely as ultimately unworkable for the range of > citations we encounter in the world. We might also propose changing > biblFull for more precise harmonization with ISBD. But this is all for > another day. > > If you discover any points of confusion before Thursday, please contact > Laurent, Martin, and me so that we can try to prepare a response in time > for the discussion. > > Kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: biblio.doc.pdf Type: application/pdf Size: 295987 bytes Desc: not available Url : http://lists.village.Virginia.EDU/pipermail/tei-council/attachments/20100424/d6264c9e/attachment.pdf From dot.porter at gmail.com Mon Apr 26 09:16:48 2010 From: dot.porter at gmail.com (Dot Porter) Date: Mon, 26 Apr 2010 09:16:48 -0400 Subject: [tei-council] Howth on Sunday Message-ID: Dear Council, If any of you will be staying in Dublin past the meetings and are looking for something fun and interesting to do on Sunday, I will be going to the farmer's market in Howth and would welcome company. Howth is a fishing village to the north of Dublin, accessible by DART and by bus. DART will drop you by the market; the bus will as well, but continues up to the top of Howth Head, offering a great view across the bay to D?n Laoghaire; then you have to walk down (which is a bit easier than walking up). I'm open to either approach. We can also walk to the end of the pier, eat fresh seafood, and feed the ugly fat seals if they are around. http://www.irishfarmersmarkets.ie/howth.html If you are interested, drop me a line or talk to me this week. Thanks! Dot -- *~*~*~*~*~*~*~*~*~*~* Dot Porter (MA, MSLS) Metadata Manager (on leave) Digital Humanities Observatory (RIA), Regus House, 28-32 Upper Pembroke Street, Dublin 2, Ireland -- A Project of the Royal Irish Academy -- Phone: +353 1 234 2444 Fax: +353 1 234 2400 http://dho.ie Email: dot.porter at gmail.com *~*~*~*~*~*~*~*~*~*~* From kevin.s.hawkins at ultraslavonic.info Mon Apr 26 11:44:39 2010 From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins) Date: Mon, 26 Apr 2010 16:44:39 +0100 Subject: [tei-council] information on your stay in Dublin Message-ID: <4BD5B4E7.2070000@ultraslavonic.info> All, Below is some information from Emily Cullen, my colleague at the DHO who has been doing a lot of the arrangements for the Council meeting this week. See you in a few days! ------------------------------------------------------------------------ Dear TEI Council Members, We are delighted that you will be joining us in Dublin this week. *Accommodation:* Your hotel is centrally located in Dublin's lively cultural quarter of Temple Bar http://www.templebarhotel.com/locations-directions. Wifi is available in your room free of charge. Please pay the EUR69 per night fee on your own and save your receipt for reimbursement along with other travel expenses. *Travel to and from Dublin Airport:* The Aircoach service, which leaves every fifteen minutes from Dublin Airport, stops outside Trinity College on Grafton Street, which is roughly a 10 minute walk to your hotel. The Aircoach service to Dublin Airport stops at various city centre locations, such as O'Connell St. and also outside Thomas Pink Shirt Shop at the top of Dawson Street (St Stephen's Green end). Allow an hour for your journey, though in non-peak hours the journey is significantly shorter. For further information see www.aircoach.ie *Directions to the Royal Irish Academy:* It takes roughly 15 minutes to walk from your hotel to the Royal Irish Academy. The best thing to do is to aim in the direction of College Green and Trinity College, then follow the path around Trinity College until you reach Nassau St. Next you will take the first turn on your right (not Grafton St. but the next street over) up to Dawson St. and Academy House is no. 19, which will be on your left in the centre of the street. The Royal Irish Academy website displays a small map which will show you the location of Academy House (Dawson st) here: http://www.ria.ie/about/location.html *Dining arrangements:* Your accommodation includes your breakfast, which will be served in the dining room at The Temple Bar hotel between 7am and 10am each morning. Lunch will be served at Academy House, 19 Dawson St, on Wednesday 28th April at 13:00, on Thursday 29th April at 12:30 and on Friday at 12:30. You are warmly invited to dinner at 6:30pm in Bleu restaurant, 2 Dawson St., Dublin 2 www.bleu.ie on Wednesday evening and at 6:15pm in Eden restaurant, Meeting House Square, Temple Bar, Dublin 2 www.edenrestaurant.ie on Thursday evening. *Other Tourist Information:* The website of the Dublin Tourism office has plenty of information on getting around the city, cultural events and activities, etc. See: www.visitdublin.com/ We look forward to seeing you at the Symposium on Wednesday. Kind regards, Emily -- Emily Cullen, Ph.D., Programme Co-ordinator Digital Humanities Observatory 28-32 Upper Pembroke Street Dublin 2 Ireland Tel:+353(0)1-2342442 Fax:+353(0)1-2342400 E-mail:e.cullen at ria.ie http://dho.ie -- -- A Project of the Royal Irish Academy -- From lou.burnard at oucs.ox.ac.uk Tue Apr 27 05:47:31 2010 From: lou.burnard at oucs.ox.ac.uk (Lou Burnard) Date: Tue, 27 Apr 2010 10:47:31 +0100 Subject: [tei-council] Genetic documents Message-ID: <4BD6B2B3.5070802@oucs.ox.ac.uk> Council members wishing to fortify themselves with reading matter in advance of this week's meeting may wish to peruse (in addition to those already mentioned) two documents emanating from the workgroup on genetic editing. There is a fully detailed report at http://www.tei-c.org/Activities/Council/Working/tcw19.html and a one-page summary of proposed changes needed to support it at http://www.tei-c.org/Activities/Council/Working/tcw18.xml From sebastian.rahtz at oucs.ox.ac.uk Tue Apr 27 06:46:09 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 27 Apr 2010 11:46:09 +0100 Subject: [tei-council] Genetic documents In-Reply-To: <4BD6B2B3.5070802@oucs.ox.ac.uk> References: <4BD6B2B3.5070802@oucs.ox.ac.uk> Message-ID: On 27 Apr 2010, at 10:47, Lou Burnard wrote: > Council members wishing to fortify themselves with reading matter in > advance of this week's meeting may wish to peruse (in addition to those > already mentioned) two documents emanating from the workgroup on genetic > editing. There is a fully detailed report at > http://www.tei-c.org/Activities/Council/Working/tcw19.html > and a one-page summary of proposed changes needed to support it at > http://www.tei-c.org/Activities/Council/Working/tcw18.xml note that I am bringing about 10 printed copies with me of these and other docs, for safety sake. -- Sebastian Rahtz (acting) Information and Support Group Manager Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From sebastian.rahtz at oucs.ox.ac.uk Wed Apr 28 11:52:48 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Wed, 28 Apr 2010 16:52:48 +0100 Subject: [tei-council] ipad and tei Message-ID: so, who amongst us is an iPhone/iPod Touch user who can log into the US app store for me and download the iBook app? -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From sebastian.rahtz at oucs.ox.ac.uk Wed Apr 28 12:50:00 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Wed, 28 Apr 2010 17:50:00 +0100 Subject: [tei-council] ipad and tei In-Reply-To: References: Message-ID: <073ED3C6-1D86-44FB-830C-6983CC29ABE8@oucs.ox.ac.uk> sorry, forget that panic. Sorted on my ownio with a fake US address (well, not fake - sorry, IATH, if Apple ever come calling.....) -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From sebastian.rahtz at oucs.ox.ac.uk Thu Apr 29 04:45:59 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Thu, 29 Apr 2010 09:45:59 +0100 Subject: [tei-council] doc addr Message-ID: <8D655434-96BE-4208-A5D2-5A5BAAC59687@oucs.ox.ac.uk> http://docs.google.com/Doc?id=dv3dx7h_12gtqzjxg5 -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From kevin.s.hawkins at ultraslavonic.info Sat May 1 12:43:23 2010 From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins) Date: Sat, 01 May 2010 17:43:23 +0100 Subject: [tei-council] Tite requests In-Reply-To: <4B743FAE.3040102@uleth.ca> References: <4B743FAE.3040102@uleth.ca> Message-ID: <4BDC5A2B.90306@ultraslavonic.info> All, Great meeting in Dublin, but unfortunately I forgot to ask Dan about the status of Tite. Dan hasn't forwarded to us any packages of revisions to the Tite spec. What's the status? Is there anything for Council to consider or any opportunities for more input on it? Kevin On 11/02/2010 17:34, O'Donnell, Dan wrote: > Hi all, > > As I mentioned at the teleconference, we received some notes on issues > with Tite that Apex would like to see addressed before the launch of the > programme. Most of them are very sensible and agree with things that > people have said here. They've also pointed out an issue to do with > release schedules and the way Tite is designed that would require > longer-term thinking, but ties in with what people said here when I > asked which version of Tite we should refer to in the contract. > > Perry is extracting the notes to form an actual proposal for Council to > consider in much the same way we often ask people to think about sf > tickets and discuss them for us. It should be done over the weekend. > I'll pass it on to you as soon as it is done. Ideally we should add him > to the conversation as a non-voting member. > > -dan > From bbarney2 at unlnotes.unl.edu Mon May 3 15:12:50 2010 From: bbarney2 at unlnotes.unl.edu (Brett Barney) Date: Mon, 3 May 2010 14:12:50 -0500 Subject: [tei-council] Green bug tidbit needed for minutes Message-ID: An HTML attachment was scrubbed... URL: http://lists.village.Virginia.EDU/pipermail/tei-council/attachments/20100503/000c490f/attachment.html From daniel.odonnell at uleth.ca Mon May 3 16:09:44 2010 From: daniel.odonnell at uleth.ca (O'Donnell, Dan) Date: Mon, 03 May 2010 14:09:44 -0600 Subject: [tei-council] Tite requests In-Reply-To: <4BDC5A2B.90306@ultraslavonic.info> References: <4BDC5A2B.90306@ultraslavonic.info> Message-ID: <4BDF2D88.1030706@uleth.ca> Thanks Kevin. We had discussed this a little on the council list in the run up to the meeting, but I should indeed have reported. While I was in Dublin I received what I believe is the last set of suggestions from Apex with regard to their own workflow in order to allow us to pump out a schema for the the first year of the contract. I still have to read through it and report back. On 10-05-01 10:43 AM, Kevin Hawkins wrote: > > All, > > Great meeting in Dublin, but unfortunately I forgot to ask Dan about the > status of Tite. Dan hasn't forwarded to us any packages of revisions to > the Tite spec. What's the status? Is there anything for Council to > consider or any opportunities for more input on it? > > Kevin > > On 11/02/2010 17:34, O'Donnell, Dan wrote: > > Hi all, > > > > As I mentioned at the teleconference, we received some notes on issues > > with Tite that Apex would like to see addressed before the launch of the > > programme. Most of them are very sensible and agree with things that > > people have said here. They've also pointed out an issue to do with > > release schedules and the way Tite is designed that would require > > longer-term thinking, but ties in with what people said here when I > > asked which version of Tite we should refer to in the contract. > > > > Perry is extracting the notes to form an actual proposal for Council to > > consider in much the same way we often ask people to think about sf > > tickets and discuss them for us. It should be done over the weekend. > > I'll pass it on to you as soon as it is done. Ideally we should add him > > to the conversation as a non-voting member. > > > > -dan > > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > > No virus found in this incoming message. > Checked by AVG - www.avg.com > Version: 9.0.814 / Virus Database: 271.1.1/2847 - Release Date: > 05/01/10 00:27:00 > -- Daniel Paul O'Donnell Professor of English University of Lethbridge Chair and CEO, Text Encoding Initiative (http://www.tei-c.org/) Co-Chair, Digital Initiatives Advisory Board, Medieval Academy of America President-elect (English), Society for Digital Humanities/Soci?t? pour l'?tude des m?dias interactifs (http://sdh-semi.org/) Founding Director (2003-2009), Digital Medievalist Project (http://www.digitalmedievalist.org/) Vox: +1 403 329-2377 Fax: +1 403 382-7191 (non-confidential) Home Page: http://people.uleth.ca/~daniel.odonnell/ From James.Cummings at oucs.ox.ac.uk Tue May 4 06:28:51 2010 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Tue, 04 May 2010 11:28:51 +0100 Subject: [tei-council] Green bug tidbit needed for minutes In-Reply-To: References: Message-ID: <4BDFF6E3.7050303@oucs.ox.ac.uk> Brett Barney wrote: > All, > > I'm working on the minutes from Thursday morning, and I've discovered a > lacuna in my notes. Does someone have at hand the ID number of the > second green bug? Was it, perhaps, 2863331 ('Used by' section empty in > model.physDescPart)? Hi Brett, I believe it was https://sourceforge.net/tracker/?func=detail&aid=2863331&group_id=106328&atid=644062 (ID no: 2863331) with the conclusion that it was indeed a bug, that SPQR knows that it is a problem and its on his to-do list to investigate and fix. -James -- Dr James Cummings, Research Technologies Service OUCS, University of Oxford From laurent.romary at inria.fr Thu May 6 09:07:35 2010 From: laurent.romary at inria.fr (Laurent Romary) Date: Thu, 6 May 2010 15:07:35 +0200 Subject: [tei-council] Fwd: Sharing macroSpecs between different ODD files References: <9A61A7D4-2F68-4EE5-B8DE-0C3CBB30DCFE@edirom.de> Message-ID: Hi all, DId we say last week that we would have a nice macroRef construct? L. D?but du message r?exp?di? : > De : Peter Stadler > Date : 6 mai 2010 14:42:32 GMT+02:00 > ? : TEI-L at listserv.brown.edu > Objet : Sharing macroSpecs between different ODD files > R?pondre ? : Peter Stadler > > Dear all, > > I have some common macro and element definitions which I would like > to import into different ODD files (with different schemaSpecs). > > Right now I have tried these possibilities: > 1. copy & paste ;-) > 2a. xincluding every macroSpec separately > 2b. xincluding a specGrp with the macroSpecs > 3. modulerefing a relaxNG file with the appropriate definitions > > Are there any more/better and what is the preferred way? > > Many thanks > Peter Laurent Romary INRIA & HUB-IDSL laurent.romary at inria.fr From sebastian.rahtz at oucs.ox.ac.uk Thu May 6 11:10:23 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Thu, 6 May 2010 16:10:23 +0100 Subject: [tei-council] Fwd: Sharing macroSpecs between different ODD files In-Reply-To: References: <9A61A7D4-2F68-4EE5-B8DE-0C3CBB30DCFE@edirom.de> Message-ID: <38E5C1CD-AD9A-4E4B-8453-6A444FBE541A@oucs.ox.ac.uk> On 6 May 2010, at 14:07, Laurent Romary wrote: > > DId we say last week that we would have a nice macroRef construct? yes, I suppose would do the job. -- Sebastian Rahtz (acting) Information and Support Group Manager Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From lou.burnard at oucs.ox.ac.uk Thu May 6 12:49:27 2010 From: lou.burnard at oucs.ox.ac.uk (Lou) Date: Thu, 06 May 2010 17:49:27 +0100 Subject: [tei-council] post Dublin ticket update 1 Message-ID: <4BE2F317.5020700@oucs.ox.ac.uk> I'm working through all the SF tickets again, applying changes agreed in Dublin as far as I remember them being agreed to. A small number remain outstanding for reasons indicated below, and there may well be other changes which I've forgotten documented in the minutes when they appear. The list below covers the Feature Requests; bugs are next, and then I plan to move on to the other major sets of action (the Kevin-Martin-Laurent bibliog paper; the ODDplus proposals; the genetic proposals). Comments on the following topics welcomed! 2925145 (Generic dating class) -- I think we felt this proposal needed more work still, but I don't know who if anyone was actioned to take it forward. There is now an additional though mysterious comment on the ticket. 2859355 ( should permit textual data) -- we spent quite a lot of time discussing this without I think addressing the real problem with this proposal. I've now added a comment to the ticket saying why I think it's a bad idea and would welcome further discussion. 2811239 (new element 'object') -- I may be thick but I am still having problems understanding what exactly is being proposed here and why it's necessary. I think we agreed to ask Gabby to give us more examples, as the ones on the ticket at present are unpersuasive. 2859183 (Make all milestoneLike elements spanning) and the more generic but less specific 2834511 (Add more elements to att.spanning) -- we didn't discuss these on the grounds that they were a part of the genetic proposal, but looking at them again, I don't think that's quite true. Certainly 2859183 is quite independent of it. 2909766 (make and (etc) dateable) -- I've added a comment asking whether the genetic @stage proposal is going to be sufficient for this use case, or whether we want to support that in parallel with the use of att.datable attributes (actually @stage looks remarkably similar to @period, so maybe the two should be considered together.) From daniel.odonnell at uleth.ca Thu May 6 13:03:46 2010 From: daniel.odonnell at uleth.ca (O'Donnell, Dan) Date: Thu, 06 May 2010 11:03:46 -0600 Subject: [tei-council] post Dublin ticket update 1 In-Reply-To: <4BE2F317.5020700@oucs.ox.ac.uk> References: <4BE2F317.5020700@oucs.ox.ac.uk> Message-ID: <4BE2F672.2010406@uleth.ca> Thanks Lou! On 10-05-06 10:49 AM, Lou wrote: > 2909766 (make and (etc) dateable) -- I've added a comment > asking whether the genetic @stage proposal is going to be sufficient for > this use case, or whether we want to support that in parallel with the > use of att.datable attributes (actually @stage looks remarkably similar > to @period, so maybe the two should be considered together.) > In broad terms as I understand the genetic proposal, @stage would be a theoretically appropriate approach to this... but in practice you might be just talking about, for example, the hand of a twentieth century librarian who put a folio number in the corner: calling that a revisions stage may seem to many to be de trop. But I'd cede to Elena on this. While I like the idea of trying to keep the number of distinct-but-semantically-similar attributes and elements to a minimum, I think in this case that there may be enough of a distinction between @stage and @period to keep them distinct. Again, as I understand it, a stage is really an event in the revision history of a document rather than a period. So while it could time associated with it, its main feature is where it falls in the historical sequence of revisions: you could have a known stage with an unknown period, for example. Again, I'd cede to Elena if I'm wrong on this. > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > -- Daniel Paul O'Donnell Professor of English University of Lethbridge Chair and CEO, Text Encoding Initiative (http://www.tei-c.org/) Co-Chair, Digital Initiatives Advisory Board, Medieval Academy of America President-elect (English), Society for Digital Humanities/Soci?t? pour l'?tude des m?dias interactifs (http://sdh-semi.org/) Founding Director (2003-2009), Digital Medievalist Project (http://www.digitalmedievalist.org/) Vox: +1 403 329-2377 Fax: +1 403 382-7191 (non-confidential) Home Page: http://people.uleth.ca/~daniel.odonnell/ From gabriel.bodard at kcl.ac.uk Thu May 6 13:56:50 2010 From: gabriel.bodard at kcl.ac.uk (Gabriel Bodard) Date: Thu, 6 May 2010 18:56:50 +0100 Subject: [tei-council] post Dublin ticket update 1 In-Reply-To: <4BE2F317.5020700@oucs.ox.ac.uk> References: <4BE2F317.5020700@oucs.ox.ac.uk> Message-ID: <4BE302E2.8030306@kcl.ac.uk> On 06/05/2010 17:49, Lou wrote: > 2811239 (new element 'object') -- I may be thick but I am still having > problems understanding what exactly is being proposed here and why it's > necessary. I think we agreed to ask Gabby to give us more examples, as > the ones on the ticket at present are unpersuasive. I actually find Dot's examples quite persuasive, but I've started a conversation with the group who original suggested this proposal, and we'll come back to the Council (via SourceForge) with more examples asap. Cheers, G -- Dr Gabriel BODARD (Epigrapher & Digital Classicist) Centre for Computing in the Humanities King's College London 26-29 Drury Lane London WC2B 5RL Email: gabriel.bodard at kcl.ac.uk Tel: +44 (0)20 7848 1388 Fax: +44 (0)20 7848 2980 http://www.digitalclassicist.org/ http://www.currentepigraphy.org/ From elena.pierazzo at kcl.ac.uk Sat May 8 12:17:00 2010 From: elena.pierazzo at kcl.ac.uk (Elena Pierazzo) Date: Sat, 8 May 2010 17:17:00 +0100 Subject: [tei-council] post Dublin ticket update 1 In-Reply-To: <4BE2F672.2010406@uleth.ca> References: <4BE2F317.5020700@oucs.ox.ac.uk> <4BE2F672.2010406@uleth.ca> Message-ID: <2A6AF1EF-3431-4B96-9264-7EE8390147DA@kcl.ac.uk> Hi all, > 2925145 (Generic dating class) -- I think we felt this proposal needed > more work still, but I don't know who if anyone was actioned to take > it > forward. There is now an additional though mysterious comment on the > ticket. I was chosen to take care of it. Basically we said that we understand the user case, but we did not like the proposal in itself. By mysterious comment you mean Syd's one? > 2859355 ( should permit textual data) -- we spent quite a > lot of > time discussing this without I think addressing the real problem with > this proposal. I've now added a comment to the ticket saying why I > think > it's a bad idea and would welcome further discussion. I have seen your comment and I take your point (which was from the beginning one of my concerns: one you allow text within then you have to allow the world and beyond which make it a close sibling of . I don't agree, though, that it is of a limited use: many people has requested more flexibility into therefore I think we should do something. > On 10-05-06 10:49 AM, Lou wrote: >> 2909766 (make and (etc) dateable) -- I've added a >> comment >> asking whether the genetic @stage proposal is going to be >> sufficient for >> this use case, or whether we want to support that in parallel with >> the >> use of att.datable attributes (actually @stage looks remarkably >> similar >> to @period, so maybe the two should be considered together.) >> > In broad terms as I understand the genetic proposal, @stage would be a > theoretically appropriate approach to this... but in practice you > might > be just talking about, for example, the hand of a twentieth century > librarian who put a folio number in the corner: calling that a > revisions > stage may seem to many to be de trop. But I'd cede to Elena on this. Don't forget that for this case there is also a @hand attribute, if you feel that using a @stage is too much. The use case was for born digital document and someone wanted to record which correction belonged to a specific moment/person, for which the use of @stage pointing to a is more appropriate than allowing datable attributes for this, as it is also likely that you want to record not only that a correction happened a t one time, but also that it was made by someone and why. > > While I like the idea of trying to keep the number of > distinct-but-semantically-similar attributes and elements to a > minimum, > I think in this case that there may be enough of a distinction between > @stage and @period to keep them distinct. Again, as I understand it, a > stage is really an event in the revision history of a document rather > than a period. So while it could time associated with it, its main > feature is where it falls in the historical sequence of revisions: you > could have a known stage with an unknown period, for example. > > Again, I'd cede to Elena if I'm wrong on this. Yes, I agree entirely: a stage is something that happened in to the document at a time that may or not be reconstructible, while a period represent some way of calling a span of time in which an event may have occurred: I think we are really speaking of two different things... Elena >> >> _______________________________________________ >> tei-council mailing list >> tei-council at lists.village.Virginia.EDU >> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council >> > > -- > Daniel Paul O'Donnell > Professor of English > University of Lethbridge > > Chair and CEO, Text Encoding Initiative (http://www.tei-c.org/) > Co-Chair, Digital Initiatives Advisory Board, Medieval Academy of > America > President-elect (English), Society for Digital Humanities/Soci?t? > pour l'?tude des m?dias interactifs (http://sdh-semi.org/) > Founding Director (2003-2009), Digital Medievalist Project (http://www.digitalmedievalist.org/ > ) > > Vox: +1 403 329-2377 > Fax: +1 403 382-7191 (non-confidential) > Home Page: http://people.uleth.ca/~daniel.odonnell/ > > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council -- Dr Elena Pierazzo Research Associate Centre for Computing in the Humanities King's College London 26-29 Drury Lane London WC2B 5RL Phone: 0207-848-1949 Fax: 0207-848-2980 elena.pierazzo at kcl.ac.uk www.kcl.ac.uk From lou.burnard at oucs.ox.ac.uk Sat May 8 16:36:52 2010 From: lou.burnard at oucs.ox.ac.uk (Lou Burnard) Date: Sat, 08 May 2010 21:36:52 +0100 Subject: [tei-council] @version (SF bug 2932853) Message-ID: <4BE5CB64.8030308@oucs.ox.ac.uk> A @version attribute exists on each of the elements , , and . A similarly named attribute is also supplied by the class att.translatable, members of which are desc, exemplum, gloss, remarks, and valDesc. The datatypes specified for this attribute vary, as follows: 1. On att.translatable it's data.word and there is a note saying "The version may be a number, a letter or a date" 2. On it's a token matching a specific RNG pattern [\d]+[a-z]*[\d]*(\.[\d]+[a-z]*[\d]*){0,3} 3. On and it's explicitly a W3C decimal number. 4. On unicodeName its the TEI-defined data.numeric (which matches all sorts of things) Obviously the datatypes for @version on TEI, teiCorpus, and unicodeName are just plain wrong (the first two don't match our actual current practice, and the last doesn't match the Unicode requirement). In an ideal world, we'd like attributes with the same name to have the same datatype, so one solution would be to give everything the same datatype as . Unfortunately the pattern defined there is too permissive for either Unicodename or TEI version (neither permits letters or a 4th number), so I have for the moment defined a new datatype data.version which matches the Unicode spec, and propose we restrict ourselves to that. There remains the problem of the @version provided by in the att.translatable class, which is uniformly a date, with hyphens separating the parts. We could at a pinch make that conform to the same pattern by permitting hyphens as well as dots in the pattern, but that I think that would be cheating. We could consider renaming the @version you get from att.translatable to "translateDate" or some such; so far as I know the attribute is only used for internal ODD processing by the TEI so the compatibility issue is less severe. Note that the semantics of this @version are quite different from the others -- it carries the date when an ODD component was last *translated* which is usually quite different from when the ODD component itself was last modified, and nothing to do with the version number of the P5 release into which that component was eventually incorporated. There is an outstanding issue about how the @version on these translateable elements should be used in our workflow specifically how we ensure consistency when the English language version has changed and the translations have not. From mholmes at uvic.ca Sat May 8 18:46:27 2010 From: mholmes at uvic.ca (Martin Holmes) Date: Sat, 08 May 2010 15:46:27 -0700 Subject: [tei-council] @version (SF bug 2932853) In-Reply-To: <4BE5CB64.8030308@oucs.ox.ac.uk> References: <4BE5CB64.8030308@oucs.ox.ac.uk> Message-ID: <4BE5E9C3.3050908@uvic.ca> > I have for the > moment defined a new datatype data.version which matches the Unicode > spec, and propose we restrict ourselves to that. Have you applied this new datatype to application/@version? If so, it will break backward compatibility. Cheers, Martin On 10-05-08 01:36 PM, Lou Burnard wrote: > A @version attribute exists on each of the elements, > , and. A similarly named attribute is > also supplied by the class att.translatable, members of which are > desc, exemplum, gloss, remarks, and valDesc. The datatypes specified > for this attribute vary, as follows: > > 1. On att.translatable it's data.word and there is a note saying "The > version may be a number, a letter or a date" > > 2. On it's a token matching a specific RNG pattern > [\d]+[a-z]*[\d]*(\.[\d]+[a-z]*[\d]*){0,3} > > 3. On and it's explicitly a W3C decimal number. > > 4. On unicodeName its the TEI-defined data.numeric (which matches all > sorts of things) > > Obviously the datatypes for @version on TEI, teiCorpus, and > unicodeName are just plain wrong (the first two don't match our actual > current practice, and the last doesn't match the Unicode > requirement). In an ideal world, we'd like attributes with the same > name to have the same datatype, so one solution would be to give > everything the same datatype as. Unfortunately the > pattern defined there is too permissive for either Unicodename or TEI > version (neither permits letters or a 4th number), so I have for the > moment defined a new datatype data.version which matches the Unicode > spec, and propose we restrict ourselves to that. > > There remains the problem of the @version provided by in the > att.translatable class, which is uniformly a date, with hyphens > separating the parts. We could at a pinch make that conform to the > same pattern by permitting hyphens as well as dots in the pattern, but > that I think that would be cheating. We could consider renaming the > @version you get from att.translatable to "translateDate" or some > such; so far as I know the attribute is only used for internal ODD > processing by the TEI so the compatibility issue is less severe. Note > that the semantics of this @version are quite different from the > others -- it carries the date when an ODD component was last > *translated* which is usually quite different from when the ODD > component itself was last modified, and nothing to do with the version > number of the P5 release into which that component was eventually > incorporated. > > There is an outstanding issue about how the @version on these > translateable elements should be used in our workflow specifically how > we ensure consistency when the English language version has changed and > the translations have not. > > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council From lou.burnard at oucs.ox.ac.uk Sun May 9 03:38:46 2010 From: lou.burnard at oucs.ox.ac.uk (Lou Burnard) Date: Sun, 09 May 2010 08:38:46 +0100 Subject: [tei-council] @version (SF bug 2932853) In-Reply-To: <4BE5E9C3.3050908@uvic.ca> References: <4BE5CB64.8030308@oucs.ox.ac.uk> <4BE5E9C3.3050908@uvic.ca> Message-ID: <4BE66686.8080601@oucs.ox.ac.uk> No, of course not, for precisely that reason. Sorry if my note below was not clear: I meant to suggest only that the TEI version numbering pattern should follow the Unicode one. Martin Holmes wrote: >> I have for the >> moment defined a new datatype data.version which matches the Unicode >> spec, and propose we restrict ourselves to that. >> > > Have you applied this new datatype to application/@version? If so, it > will break backward compatibility. > > Cheers, > Martin > > On 10-05-08 01:36 PM, Lou Burnard wrote: > >> A @version attribute exists on each of the elements, >> , and. A similarly named attribute is >> also supplied by the class att.translatable, members of which are >> desc, exemplum, gloss, remarks, and valDesc. The datatypes specified >> for this attribute vary, as follows: >> >> 1. On att.translatable it's data.word and there is a note saying "The >> version may be a number, a letter or a date" >> >> 2. On it's a token matching a specific RNG pattern >> [\d]+[a-z]*[\d]*(\.[\d]+[a-z]*[\d]*){0,3} >> >> 3. On and it's explicitly a W3C decimal number. >> >> 4. On unicodeName its the TEI-defined data.numeric (which matches all >> sorts of things) >> >> Obviously the datatypes for @version on TEI, teiCorpus, and >> unicodeName are just plain wrong (the first two don't match our actual >> current practice, and the last doesn't match the Unicode >> requirement). In an ideal world, we'd like attributes with the same >> name to have the same datatype, so one solution would be to give >> everything the same datatype as. Unfortunately the >> pattern defined there is too permissive for either Unicodename or TEI >> version (neither permits letters or a 4th number), so I have for the >> moment defined a new datatype data.version which matches the Unicode >> spec, and propose we restrict ourselves to that. >> >> There remains the problem of the @version provided by in the >> att.translatable class, which is uniformly a date, with hyphens >> separating the parts. We could at a pinch make that conform to the >> same pattern by permitting hyphens as well as dots in the pattern, but >> that I think that would be cheating. We could consider renaming the >> @version you get from att.translatable to "translateDate" or some >> such; so far as I know the attribute is only used for internal ODD >> processing by the TEI so the compatibility issue is less severe. Note >> that the semantics of this @version are quite different from the >> others -- it carries the date when an ODD component was last >> *translated* which is usually quite different from when the ODD >> component itself was last modified, and nothing to do with the version >> number of the P5 release into which that component was eventually >> incorporated. >> >> There is an outstanding issue about how the @version on these >> translateable elements should be used in our workflow specifically how >> we ensure consistency when the English language version has changed and >> the translations have not. >> >> >> _______________________________________________ >> tei-council mailing list >> tei-council at lists.village.Virginia.EDU >> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council >> > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > From James.Cummings at oucs.ox.ac.uk Sun May 9 07:20:31 2010 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Sun, 09 May 2010 12:20:31 +0100 Subject: [tei-council] @version (SF bug 2932853) In-Reply-To: <4BE66686.8080601@oucs.ox.ac.uk> References: <4BE5CB64.8030308@oucs.ox.ac.uk> <4BE5E9C3.3050908@uvic.ca> <4BE66686.8080601@oucs.ox.ac.uk> Message-ID: <4BE69A7F.3080207@oucs.ox.ac.uk> Am I the only one who thinks maybe we should have a att.versionable or something class which provides @version? And moreover that this should not be tightly constrained at this location? I'm doubting that with all sorts of different possibilities for version-numbering that there is a single pattern which matches them all. So maybe we should have it not constrained that much at all, but give examples of constraining it to tighter datatypes as customisations? I see this as related to the underlying ODD problem of needing to further constrain certain aspects of an element/attribute definition. e.g. we have an attribute that has this unspecific datatype in its attribute class, but here we have an instance of it that we've further constrained. Or, we have an attribute that has a particular definition (a version number) which in this particular location needs to be constrained further (say, version number of the applicable release of TEI). We have many instances of attributes which are not in classes primarily because they have slightly different definitions. -James Lou Burnard wrote: > No, of course not, for precisely that reason. Sorry if my note below was > not clear: I meant to suggest only that the TEI version numbering > pattern should follow the Unicode one. > > Martin Holmes wrote: >>> I have for the >>> moment defined a new datatype data.version which matches the Unicode >>> spec, and propose we restrict ourselves to that. >>> >> Have you applied this new datatype to application/@version? If so, it >> will break backward compatibility. >> >> Cheers, >> Martin >> >> On 10-05-08 01:36 PM, Lou Burnard wrote: >> >>> A @version attribute exists on each of the elements, >>> , and. A similarly named attribute is >>> also supplied by the class att.translatable, members of which are >>> desc, exemplum, gloss, remarks, and valDesc. The datatypes specified >>> for this attribute vary, as follows: >>> >>> 1. On att.translatable it's data.word and there is a note saying "The >>> version may be a number, a letter or a date" >>> >>> 2. On it's a token matching a specific RNG pattern >>> [\d]+[a-z]*[\d]*(\.[\d]+[a-z]*[\d]*){0,3} >>> >>> 3. On and it's explicitly a W3C decimal number. >>> >>> 4. On unicodeName its the TEI-defined data.numeric (which matches all >>> sorts of things) >>> >>> Obviously the datatypes for @version on TEI, teiCorpus, and >>> unicodeName are just plain wrong (the first two don't match our actual >>> current practice, and the last doesn't match the Unicode >>> requirement). In an ideal world, we'd like attributes with the same >>> name to have the same datatype, so one solution would be to give >>> everything the same datatype as. Unfortunately the >>> pattern defined there is too permissive for either Unicodename or TEI >>> version (neither permits letters or a 4th number), so I have for the >>> moment defined a new datatype data.version which matches the Unicode >>> spec, and propose we restrict ourselves to that. >>> >>> There remains the problem of the @version provided by in the >>> att.translatable class, which is uniformly a date, with hyphens >>> separating the parts. We could at a pinch make that conform to the >>> same pattern by permitting hyphens as well as dots in the pattern, but >>> that I think that would be cheating. We could consider renaming the >>> @version you get from att.translatable to "translateDate" or some >>> such; so far as I know the attribute is only used for internal ODD >>> processing by the TEI so the compatibility issue is less severe. Note >>> that the semantics of this @version are quite different from the >>> others -- it carries the date when an ODD component was last >>> *translated* which is usually quite different from when the ODD >>> component itself was last modified, and nothing to do with the version >>> number of the P5 release into which that component was eventually >>> incorporated. >>> >>> There is an outstanding issue about how the @version on these >>> translateable elements should be used in our workflow specifically how >>> we ensure consistency when the English language version has changed and >>> the translations have not. >>> >>> >>> _______________________________________________ >>> tei-council mailing list >>> tei-council at lists.village.Virginia.EDU >>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council >>> >> _______________________________________________ >> tei-council mailing list >> tei-council at lists.village.Virginia.EDU >> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council >> > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council From lou.burnard at oucs.ox.ac.uk Sun May 9 11:00:10 2010 From: lou.burnard at oucs.ox.ac.uk (Lou Burnard) Date: Sun, 09 May 2010 16:00:10 +0100 Subject: [tei-council] @version (SF bug 2932853) In-Reply-To: <4BE69A7F.3080207@oucs.ox.ac.uk> References: <4BE5CB64.8030308@oucs.ox.ac.uk> <4BE5E9C3.3050908@uvic.ca> <4BE66686.8080601@oucs.ox.ac.uk> <4BE69A7F.3080207@oucs.ox.ac.uk> Message-ID: <4BE6CDFA.4090809@oucs.ox.ac.uk> James Cummings wrote: > Am I the only one who thinks maybe we should have a att.versionable or > something class which provides @version? And moreover that this should > not be tightly constrained at this location? I'm doubting that with all > sorts of different possibilities for version-numbering that there is a > single pattern which matches them all. So maybe we should have it not > constrained that much at all, but give examples of constraining it to > tighter datatypes as customisations? > I am not sure what an attribute class would buy us here, precisely because the different @versions all need to have different datatypes. unicodeVersion/@version is constrained by Unicode, not us, so all I thought reasonable to do is (a) provide a corresponding datatype (b) explicitly tie TEI/@version to it. If I defined a class I'd have to decide what the default dataype would be and/or make it very unspoecific, and then modify it for all the other non default cases, which just looks like unnecessary work to me. > I see this as related to the underlying ODD problem of needing to > further constrain certain aspects of an element/attribute definition. > e.g. we have an attribute that has this unspecific datatype in its > attribute class, but here we have an instance of it that we've further > constrained. Or, we have an attribute that has a particular definition > (a version number) which in this particular location needs to be > constrained further (say, version number of the applicable release of > TEI). We have many instances of attributes which are not in classes > primarily because they have slightly different definitions. > > -James > > Lou Burnard wrote: > >> No, of course not, for precisely that reason. Sorry if my note below was >> not clear: I meant to suggest only that the TEI version numbering >> pattern should follow the Unicode one. >> >> Martin Holmes wrote: >> >>>> I have for the >>>> moment defined a new datatype data.version which matches the Unicode >>>> spec, and propose we restrict ourselves to that. >>>> >>>> >>> Have you applied this new datatype to application/@version? If so, it >>> will break backward compatibility. >>> >>> Cheers, >>> Martin >>> >>> On 10-05-08 01:36 PM, Lou Burnard wrote: >>> >>> >>>> A @version attribute exists on each of the elements, >>>> , and. A similarly named attribute is >>>> also supplied by the class att.translatable, members of which are >>>> desc, exemplum, gloss, remarks, and valDesc. The datatypes specified >>>> for this attribute vary, as follows: >>>> >>>> 1. On att.translatable it's data.word and there is a note saying "The >>>> version may be a number, a letter or a date" >>>> >>>> 2. On it's a token matching a specific RNG pattern >>>> [\d]+[a-z]*[\d]*(\.[\d]+[a-z]*[\d]*){0,3} >>>> >>>> 3. On and it's explicitly a W3C decimal number. >>>> >>>> 4. On unicodeName its the TEI-defined data.numeric (which matches all >>>> sorts of things) >>>> >>>> Obviously the datatypes for @version on TEI, teiCorpus, and >>>> unicodeName are just plain wrong (the first two don't match our actual >>>> current practice, and the last doesn't match the Unicode >>>> requirement). In an ideal world, we'd like attributes with the same >>>> name to have the same datatype, so one solution would be to give >>>> everything the same datatype as. Unfortunately the >>>> pattern defined there is too permissive for either Unicodename or TEI >>>> version (neither permits letters or a 4th number), so I have for the >>>> moment defined a new datatype data.version which matches the Unicode >>>> spec, and propose we restrict ourselves to that. >>>> >>>> There remains the problem of the @version provided by in the >>>> att.translatable class, which is uniformly a date, with hyphens >>>> separating the parts. We could at a pinch make that conform to the >>>> same pattern by permitting hyphens as well as dots in the pattern, but >>>> that I think that would be cheating. We could consider renaming the >>>> @version you get from att.translatable to "translateDate" or some >>>> such; so far as I know the attribute is only used for internal ODD >>>> processing by the TEI so the compatibility issue is less severe. Note >>>> that the semantics of this @version are quite different from the >>>> others -- it carries the date when an ODD component was last >>>> *translated* which is usually quite different from when the ODD >>>> component itself was last modified, and nothing to do with the version >>>> number of the P5 release into which that component was eventually >>>> incorporated. >>>> >>>> There is an outstanding issue about how the @version on these >>>> translateable elements should be used in our workflow specifically how >>>> we ensure consistency when the English language version has changed and >>>> the translations have not. >>>> >>>> >>>> _______________________________________________ >>>> tei-council mailing list >>>> tei-council at lists.village.Virginia.EDU >>>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council >>>> >>>> >>> _______________________________________________ >>> tei-council mailing list >>> tei-council at lists.village.Virginia.EDU >>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council >>> >>> >> _______________________________________________ >> tei-council mailing list >> tei-council at lists.village.Virginia.EDU >> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council >> > > From kevin.s.hawkins at ultraslavonic.info Tue May 11 05:14:26 2010 From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins) Date: Tue, 11 May 2010 10:14:26 +0100 Subject: [tei-council] @version (SF bug 2932853) In-Reply-To: <4BE5CB64.8030308@oucs.ox.ac.uk> References: <4BE5CB64.8030308@oucs.ox.ac.uk> Message-ID: <4BE91FF2.30102@ultraslavonic.info> Responses below ... On 08/05/2010 21:36, Lou Burnard wrote: > A @version attribute exists on each of the elements, > , and. A similarly named attribute is > also supplied by the class att.translatable, members of which are > desc, exemplum, gloss, remarks, and valDesc. The datatypes specified > for this attribute vary, as follows: > > 1. On att.translatable it's data.word and there is a note saying "The > version may be a number, a letter or a date" > > 2. On it's a token matching a specific RNG pattern > [\d]+[a-z]*[\d]*(\.[\d]+[a-z]*[\d]*){0,3} > > 3. On and it's explicitly a W3C decimal number. > > 4. On unicodeName its the TEI-defined data.numeric (which matches all > sorts of things) > > Obviously the datatypes for @version on TEI, teiCorpus, and > unicodeName are just plain wrong (the first two don't match our actual > current practice, and the last doesn't match the Unicode > requirement). In an ideal world, we'd like attributes with the same > name to have the same datatype, so one solution would be to give > everything the same datatype as. Unfortunately the > pattern defined there is too permissive for either Unicodename or TEI > version (neither permits letters or a 4th number), so I have for the > moment defined a new datatype data.version which matches the Unicode > spec, and propose we restrict ourselves to that. Restrict ourselves to data.version for what exactly? The values of @version on TEI, teiCorpus, and unicodeName? > There remains the problem of the @version provided by in the > att.translatable class, which is uniformly a date, with hyphens > separating the parts. We could at a pinch make that conform to the > same pattern by permitting hyphens as well as dots in the pattern, but > that I think that would be cheating. We could consider renaming the > @version you get from att.translatable to "translateDate" or some > such; so far as I know the attribute is only used for internal ODD > processing by the TEI so the compatibility issue is less severe. Note > that the semantics of this @version are quite different from the > others -- it carries the date when an ODD component was last > *translated* which is usually quite different from when the ODD > component itself was last modified, and nothing to do with the version > number of the P5 release into which that component was eventually > incorporated. If the @version that's part of att.translatable is only used internally by the TEI and never included in ODDs produced by Roma or Vesta, then, as you say, renaming this attribute wouldn't break backwards compatibility. However, I am not so troubled by having an attribute called @version in att.translatable with a different datatype (and semantics) from the @version on TEI, teiCorpus, and unicodeName, which have their own datatype and semantics. So if it's a lot of trouble to fix, I would just leave it. Kevin From lou.burnard at oucs.ox.ac.uk Tue May 11 05:20:05 2010 From: lou.burnard at oucs.ox.ac.uk (Lou Burnard) Date: Tue, 11 May 2010 10:20:05 +0100 Subject: [tei-council] @version (SF bug 2932853) In-Reply-To: <4BE91FF2.30102@ultraslavonic.info> References: <4BE5CB64.8030308@oucs.ox.ac.uk> <4BE91FF2.30102@ultraslavonic.info> Message-ID: <4BE92145.5080700@oucs.ox.ac.uk> Kevin Hawkins wrote: > > > Restrict ourselves to data.version for what exactly? The values of > @version on TEI, teiCorpus, and unicodeName? > > Krekt. That's what is implemented. If Unicode change their version format, I suppose we might have to revisit the question, so let us pray devoutly that they don't. > If the @version that's part of att.translatable is only used internally > by the TEI and never included in ODDs produced by Roma or Vesta, then, > as you say, renaming this attribute wouldn't break backwards > compatibility. However, I am not so troubled by having an attribute > called @version in att.translatable with a different datatype (and > semantics) from the @version on TEI, teiCorpus, and unicodeName, which > have their own datatype and semantics. So if it's a lot of trouble to > fix, I would just leave it. > Does Vesta produce ODDs? And the ODD s/schemas output by Roma will definitely include this attribute if you include any translatable elements. However, I agree with you that it's probably not worth worrying about right now. From kevin.s.hawkins at ultraslavonic.info Tue May 11 11:49:52 2010 From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins) Date: Tue, 11 May 2010 16:49:52 +0100 Subject: [tei-council] minutes from the Dublin Council meeting: part 1 Message-ID: <4BE97CA0.8060803@ultraslavonic.info> All, I've created a wiki page for minutes of the Dublin Council meeting, into which I've put my draft of minutes from Friday morning: http://wiki.tei-c.org/index.php/Draft_minutes_of_2010-04_Council_meeting Brett and Dan will add theirs here as well, allowing us all to offer corrections and additions before someone creates a final version encoded in TEI to put on www.tei-c.org. Please help us fill in the gaps of this productive discussion Kevin From daniel.odonnell at uleth.ca Tue May 11 13:56:11 2010 From: daniel.odonnell at uleth.ca (O'Donnell, Dan) Date: Tue, 11 May 2010 11:56:11 -0600 Subject: [tei-council] Can somebody remind me where the agenda was Message-ID: <4BE99A3B.4060503@uleth.ca> Hi all, I need to refer to something in the minutes (the bibliographic report actually). Can somebody remind me where the agenda is? -dan -- Daniel Paul O'Donnell Professor of English University of Lethbridge Chair and CEO, Text Encoding Initiative (http://www.tei-c.org/) Co-Chair, Digital Initiatives Advisory Board, Medieval Academy of America President-elect (English), Society for Digital Humanities/Soci?t? pour l'?tude des m?dias interactifs (http://sdh-semi.org/) Founding Director (2003-2009), Digital Medievalist Project (http://www.digitalmedievalist.org/) Vox: +1 403 329-2377 Fax: +1 403 382-7191 (non-confidential) Home Page: http://people.uleth.ca/~daniel.odonnell/ From kevin.s.hawkins at ultraslavonic.info Tue May 11 18:37:22 2010 From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins) Date: Tue, 11 May 2010 23:37:22 +0100 Subject: [tei-council] Can somebody remind me where the agenda was In-Reply-To: <4BE99A3B.4060503@uleth.ca> References: <4BE99A3B.4060503@uleth.ca> Message-ID: <4BE9DC22.2030605@ultraslavonic.info> Dan, are you talking about the agenda from the Dublin meeting? A rough agenda is at http://wiki.tei-c.org/index.php/Council but I don't remember to what extent we rearranged agenda items. The proposal on changing bibl, biblStruct, etc. is in a PDF email attachment I sent the Friday before the meeting. Not sure if you were actually looking for that ... On 11/05/2010 18:56, O'Donnell, Dan wrote: > Hi all, > > I need to refer to something in the minutes (the bibliographic report > actually). Can somebody remind me where the agenda is? > > -dan > From James.Cummings at oucs.ox.ac.uk Thu May 13 09:49:30 2010 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Thu, 13 May 2010 14:49:30 +0100 Subject: [tei-council] @calendar should be data.pointer Message-ID: <4BEC036A.8080601@oucs.ox.ac.uk> I'd like to draw Council's attention to Feature Request 2994671 http://sn.im/tei-fr&aid=2994671 where I make the suggestion that the @calendar attribute should be datatype data.pointer in a similar manner to the @period attribute. While I still think that is the better solution compared to a suggested value list of data.enumerated, however, if we decide not to make @calendar data.pointer my alternative suggestion is that it should have a much more standardised and certainly larger list of calendars. In my comment on the ticket I suggest those suggested by W3C for XPath date functions which are: ==== Designator Calendar AD Anno Domini (Christian Era) AH Anno Hegirae (Muhammedan Era) AME Mauludi Era (solar years since Mohammed's birth) AM Anno Mundi (Jewish Calendar) AP Anno Persici AS Aji Saka Era (Java) BE Buddhist Era CB Cooch Behar Era CE Common Era CL Chinese Lunar Era CS Chula Sakarat Era EE Ethiopian Era FE Fasli Era ISO ISO 8601 calendar JE Japanese Calendar KE Khalsa Era (Sikh calendar) KY Kali Yuga ME Malabar Era MS Monarchic Solar Era NS Nepal Samwat Era OS Old Style (Julian Calendar) RS Rattanakosin (Bangkok) Era SE Saka Era SH Mohammedan Solar Era (Iran) SS Saka Samvat TE Tripurabda Era VE Vikrama Era VS Vikrama Samvat Era ==== This is a much more reasonable and internationalised list of calendars than our current list. It comes from a little ways down in http://www.w3.org/TR/xpath-functions-11/#lang-cal-country But I still think that data.pointer is a more powerful solution. -James -- Dr James Cummings, Research Technologies Service OUCS, University of Oxford From daniel.odonnell at uleth.ca Thu May 13 13:26:22 2010 From: daniel.odonnell at uleth.ca (O'Donnell, Dan) Date: Thu, 13 May 2010 11:26:22 -0600 Subject: [tei-council] @calendar should be data.pointer In-Reply-To: <4BEC036A.8080601@oucs.ox.ac.uk> References: <4BEC036A.8080601@oucs.ox.ac.uk> Message-ID: <4BEC363E.9080103@uleth.ca> I'm a fan of data.pointer too. On 10-05-13 07:49 AM, James Cummings wrote: > I'd like to draw Council's attention to Feature Request 2994671 > http://sn.im/tei-fr&aid=2994671 where I make the suggestion that > the @calendar attribute should be datatype data.pointer in a > similar manner to the @period attribute. > > While I still think that is the better solution compared to a > suggested value list of data.enumerated, however, if we decide > not to make @calendar data.pointer my alternative suggestion is > that it should have a much more standardised and certainly larger > list of calendars. In my comment on the ticket I suggest those > suggested by W3C for XPath date functions which are: > ==== > Designator Calendar > AD Anno Domini (Christian Era) > AH Anno Hegirae (Muhammedan Era) > AME Mauludi Era (solar years since Mohammed's birth) > AM Anno Mundi (Jewish Calendar) > AP Anno Persici > AS Aji Saka Era (Java) > BE Buddhist Era > CB Cooch Behar Era > CE Common Era > CL Chinese Lunar Era > CS Chula Sakarat Era > EE Ethiopian Era > FE Fasli Era > ISO ISO 8601 calendar > JE Japanese Calendar > KE Khalsa Era (Sikh calendar) > KY Kali Yuga > ME Malabar Era > MS Monarchic Solar Era > NS Nepal Samwat Era > OS Old Style (Julian Calendar) > RS Rattanakosin (Bangkok) Era > SE Saka Era > SH Mohammedan Solar Era (Iran) > SS Saka Samvat > TE Tripurabda Era > VE Vikrama Era > VS Vikrama Samvat Era > ==== > This is a much more reasonable and internationalised list of > calendars > than our current list. It comes from a little ways down in > http://www.w3.org/TR/xpath-functions-11/#lang-cal-country > > But I still think that data.pointer is a more powerful solution. > > -James > -- Daniel Paul O'Donnell Professor of English University of Lethbridge Chair and CEO, Text Encoding Initiative (http://www.tei-c.org/) Co-Chair, Digital Initiatives Advisory Board, Medieval Academy of America President-elect (English), Society for Digital Humanities/Soci?t? pour l'?tude des m?dias interactifs (http://sdh-semi.org/) Founding Director (2003-2009), Digital Medievalist Project (http://www.digitalmedievalist.org/) Vox: +1 403 329-2377 Fax: +1 403 382-7191 (non-confidential) Home Page: http://people.uleth.ca/~daniel.odonnell/ From lou.burnard at oucs.ox.ac.uk Thu May 13 17:03:56 2010 From: lou.burnard at oucs.ox.ac.uk (Lou Burnard) Date: Thu, 13 May 2010 22:03:56 +0100 Subject: [tei-council] bibliog doc Message-ID: <4BEC693C.1060102@oucs.ox.ac.uk> As relaxation from grappling with implementing the proposed ODD changes, I thought I'd work through the document on bibliographic issues which Kevin circulated earlier. I have three reactions so far (and some comments below) ... 1. Following the gloss list in "Notes for library cataloguers" I have now revised the proposed new text as follows: -----------

Since the TEI file description elements are based on the ISBD areas, it should be possible to use the content of file description as the basis for a catalog record for a TEI document. However, cataloguers should be aware that the permissive nature of the TEI Guidelines may lead to divergences between practice in using the TEI file description and the comparatively strict recommendations of AACR2. Such divergences as the following may preclude automatic generation of catalogue records from TEI headers: The TEI title statement may not categorise constituent titles in the same way as recommended by AACR2. The TEI title statement contains authors, editors, and other responsible parties in separate elements, with names which may not have been normalized; it does not necessarily contain a single statement of responsibility from the chief source of information. The TEI header does not require use of a particular vocabulary for subject headings or mandate the use of subject headings.

----------------------- 2. I revised the additional material proposed for the end of section 3.? as follows:

The most commonly used elements in the model.biblLike class are biblStruct and bibl. biblStruct will usually be easier to process mechanically than bibl because its structure is more constrained and predictable. It is suited to situations in which the objective is to represent bibliographic information for machine processing directly by other systems or after conversion to some other bibliographic markup formats such as BibTeXML or MODS. Punctuation delimiting the components of a print citation is not permitted directly within a biblStruct element; instead, the presence and order of child elements must be used to reconstruct the punctuation required by a particular style.

By contrast, bibl allows for considerable flexibility in that it can include both delimiting punctuation and unmarked-up text; and its constituents can also be ordered in any way. This makes it suitable for marking up bibliographies in existing documents, where it is considered important to preserve the form of references in the original document, while also distinguishing important pieces of information such as authors, dates, publishers, and so on. bibl may also be useful when encoding born digital documents which require use of a specific style guide when rendering the content ; its flexibility makes it easier to provide all the information for a reference in the exact sequence required by the target rendering, including any necessary punctuation and linking words, rather than using an XSLT stylesheet or similar to reorder and punctuate the data.

The third element in the model.biblLike class, biblFull, has a content model based on the fileDesc element of the TEI header. Both are based on the International Standard for Bibliographic Description (ISBD), which forms the basis of several national standards for bibliographic citations. The order of child elements in both biblFull and fileDesc corresponds to the order of bibliographic desription areas in ISBD with two minor exceptions. First, the extent element, corresponding to the physical description area in ISBD, appears just after the publication, production, distribution, etc. area in ISBD, not before it as in TEI. Second, biblFull and fileDesc use the child element publicationStmt to cover not only the publication, production, distribution, etc. area but also the resource identifier and terms of availability area associated with that publication. Despite these inconsistencies, users encoding citations and attempting to format them according to a standard that closely adheres to ISBD may find that biblFull, used with its child elements and without delimiting punctuation, provides an appropriate granularity of encoding with elements that can easily rendered for the reader. However, it is important to note that some ISBD-derived citation formats (such as ANSI/NISO Z39.29 and ???? 7.1) are not entirely conformant to ISBD either, since they may begin with a statement of authorship that does not map to the ISBD statement of responsibility.

3. Use of persName inside biblStruct While this may be true, it presents us with quite a problem in terms of house style. Usually we try not to use elements from one module in examples appearing in a chapter which describes another. In the few rare exceptions, we make quite a song and dance about the need to include the other module etc. But biblStruct and friends are described in the core module, whereas the etc. elements are described in names and dates. (That incidentally is why the element was originally used in some of these examples -- name is available in the core). So, while I am perfectly to change some of the examples to indicate what you propose as appropriate use of the naming elements, I don't think it should be done uniformly. I fear this needs more mulling over. From mholmes at uvic.ca Thu May 13 18:30:04 2010 From: mholmes at uvic.ca (Martin Holmes) Date: Thu, 13 May 2010 15:30:04 -0700 Subject: [tei-council] bibliog doc In-Reply-To: <4BEC693C.1060102@oucs.ox.ac.uk> References: <4BEC693C.1060102@oucs.ox.ac.uk> Message-ID: <4BEC7D6C.8040409@uvic.ca> Hi Lou, In this bit: On 10-05-13 02:03 PM, Lou Burnard wrote: > I presume you mean that you're excising that part of our text because no problems have been presented to the council. We had a long discussion about this in our little committee, and talked about a number of problems, but there wasn't time to raise them at the Council meeting. I have lots of examples of situations in which it's virtually impossible to write an XSLT routine to format a according to a style guide, without absolutely special-casing it. Here's one: Brief Discours pour la reformation des mariages. Paris, de l?imprimerie d?Anthoine du Brueil, rue Saint-Jacques, au dessus de Saint-Benoist, ? la Couronne, 1614, dans Vari?t?s Historiques et Litt?raires. Recueil de pi?ces volantes rares et curieuses en prose et en vers, ?d. ?. Fournier, Paris, P. Jannet, 1856, t. IV. [Book (monograph) with no author, originally printed in 1614, collected as part of volume 4 of a series published in 1856.] Here's the : Brief Discours pour la reformation des mariages. Paris, de l?imprimerie d?Anthoine du Brueil, rue Saint-Jacques, au dessus de Saint-Benoist, ? la Couronne, 1614, dans Vari?t?s Historiques et Litt?raires. Recueil de pi?ces volantes rares et curieuses en prose et en vers, ?d. ?. Fournier, Paris, P. Jannet, 1856, t. IV. It's easy enough to create a for this, but it's extremely hard for generic XSLT to detect what kind of item it is, determine what kind of formatting it should be given based on that, and then compensate for the missing author in the rendering. With , it's easy -- encode all the elements in the order they need to come out, and you're done. Cheers, Martin -- Martin Holmes University of Victoria Humanities Computing and Media Centre (mholmes at uvic.ca) Half-Baked Software, Inc. (mholmes at halfbakedsoftware.com) martin at mholmes.com From laurent.romary at inria.fr Fri May 14 02:40:41 2010 From: laurent.romary at inria.fr (Laurent Romary) Date: Fri, 14 May 2010 08:40:41 +0200 Subject: [tei-council] bibliog doc In-Reply-To: <4BEC7D6C.8040409@uvic.ca> References: <4BEC693C.1060102@oucs.ox.ac.uk> <4BEC7D6C.8040409@uvic.ca> Message-ID: <1388D799-D892-423C-8352-F50B9317E1B7@inria.fr> As a matter of fact, this issue was not consensual within the group and we identified user scenarios where one or the other formats would be best useful. I am not sure there is any further action to be taken on this. Cheers, Laurent Le 14 mai 10 ? 00:30, Martin Holmes a ?crit : > Hi Lou, > > In this bit: > > On 10-05-13 02:03 PM, Lou Burnard wrote: >> > > I presume you mean that you're excising that part of our text > because no > problems have been presented to the council. We had a long discussion > about this in our little committee, and talked about a number of > problems, but there wasn't time to raise them at the Council > meeting. I > have lots of examples of situations in which it's virtually impossible > to write an XSLT routine to format a according to a style > guide, without absolutely special-casing it. Here's one: > > Brief Discours pour la reformation des mariages. Paris, de > l?imprimerie > d?Anthoine du Brueil, rue Saint-Jacques, au dessus de Saint-Benoist, ? > la Couronne, 1614, dans Vari?t?s Historiques et Litt?raires. Recueil > de > pi?ces volantes rares et curieuses en prose et en vers, ?d. ?. > Fournier, > Paris, P. Jannet, 1856, t. IV. > > [Book (monograph) with no author, originally printed in 1614, > collected > as part of volume 4 of a series published in 1856.] > > Here's the : > > > Brief Discours pour la reformation des > mariages. Paris, de l?imprimerie > d?Anthoine du Brueil, rue Saint-Jacques, au > dessus de Saint-Benoist, ? la Couronne, 1614, > dans Vari?t?s Historiques et Litt?raires. Recueil de > pi?ces volantes rares et curieuses en prose et en vers, ?d. > ?. > Fournier, Paris pubPlace>, > P. Jannet, 1856, > t. IV. > > > It's easy enough to create a for this, but it's extremely > hard for generic XSLT to detect what kind of item it is, determine > what > kind of formatting it should be given based on that, and then > compensate > for the missing author in the rendering. With , it's easy -- > encode all the elements in the order they need to come out, and > you're done. > > Cheers, > Martin > > -- > Martin Holmes > University of Victoria Humanities Computing and Media Centre > (mholmes at uvic.ca) > Half-Baked Software, Inc. > (mholmes at halfbakedsoftware.com) > martin at mholmes.com > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Laurent Romary INRIA & HUB-IDSL laurent.romary at inria.fr From lou.burnard at oucs.ox.ac.uk Fri May 14 05:38:11 2010 From: lou.burnard at oucs.ox.ac.uk (Lou) Date: Fri, 14 May 2010 10:38:11 +0100 Subject: [tei-council] bibliog doc In-Reply-To: <4BEC7D6C.8040409@uvic.ca> References: <4BEC693C.1060102@oucs.ox.ac.uk> <4BEC7D6C.8040409@uvic.ca> Message-ID: <4BED1A03.2000405@oucs.ox.ac.uk> Martin Holmes wrote: > Hi Lou, > > In this bit: > > On 10-05-13 02:03 PM, Lou Burnard wrote: >> > > I presume you mean that you're excising that part of our text because no > problems have been presented to the council. No, I mean that I am not including such a claim in the Guidelines text without further substantiation. > We had a long discussion > about this in our little committee, and talked about a number of > problems, but there wasn't time to raise them at the Council meeting. I > have lots of examples of situations in which it's virtually impossible > to write an XSLT routine to format a according to a style > guide, without absolutely special-casing it. Here's one: Thanks for the example, which certainly doesn't look that unusual to me. I'm not well enough acquainted with the "style guides" you have in mind to know how difficult or otherwise it would be to transform it satisfactorily using XSLT, though I am a bit curious about what the real difficulty is in this case. However, doesn't this issue apply to a whole raft of other possible application software for TEI encoded texts? In general, the TEI cannot legislate for the eccentricities of every possible application program: all it can do is provide tagging which gives the hooks for suitable software to do something with, if it can. As you indicate below, some TEI choices make that easier than others. > > It's easy enough to create a for this, but it's extremely > hard for generic XSLT to detect what kind of item it is, determine what > kind of formatting it should be given based on that, and then compensate > for the missing author in the rendering. Well that rather depends on how "generic" you "generic XSLT" is seems to me. FWIW you have @type attribute on biblStruct which you might for example set automatically by the absence of an , if that's the issue that's bedevilling your stylesheet! With , it's easy -- > encode all the elements in the order they need to come out, and you're done. > As I remarked elsewhere the trouble with this approach is that "the order they need to come out" may not be the same the next time you want to process this using some other application.... From mholmes at uvic.ca Fri May 14 11:10:41 2010 From: mholmes at uvic.ca (Martin Holmes) Date: Fri, 14 May 2010 08:10:41 -0700 Subject: [tei-council] bibliog doc In-Reply-To: <4BED1A03.2000405@oucs.ox.ac.uk> References: <4BEC693C.1060102@oucs.ox.ac.uk> <4BEC7D6C.8040409@uvic.ca> <4BED1A03.2000405@oucs.ox.ac.uk> Message-ID: <4BED67F1.30301@uvic.ca> HI Lou, On 10-05-14 02:38 AM, Lou wrote: >> It's easy enough to create a for this, but it's extremely >> hard for generic XSLT to detect what kind of item it is, determine what >> kind of formatting it should be given based on that, and then compensate >> for the missing author in the rendering. > > Well that rather depends on how "generic" you "generic XSLT" is seems to > me. FWIW you have @type attribute on biblStruct which you might for > example set automatically by the absence of an, if that's the > issue that's bedevilling your stylesheet! That's precisely my point: you need to do something like this: and then you have and end up with sixty-odd templates for each style guide.* I've been down this road at least three times in three different projects, and believe me, it's not easy, especially when the rendering requirements are rigorous -- such as in the case of formal print publications, when you must get everything absolutely right, or face an enraged editor. Also, in this particular example, how in do you handle the fact that a is part of another <monogr>? Do you have the two <title> elements in one <monogr>, or do you have the first title in <analytic>? > With<bibl>, it's easy -- >> encode all the elements in the order they need to come out, and you're done. >> > > As I remarked elsewhere the trouble with this approach is that "the > order they need to come out" may not be the same the next time you want > to process this<bibl> using some other application.... I know, but it's no harder to process a <bibl> than a <biblStruct>, so with <bibl> you get one free easy rendering and all the rest are hard; whereas with <biblStruct>, every rendering is hard. And in real life projects, we often only need to output one style guide. My main concern here is that the vast majority of examples in this section show <biblStruct>s. That's because <biblStruct>s are harder and need more explanation; but it gives the impression that they're somehow better than <bibl>s and to be preferred. This would lead most people to believe that they should really use <biblStruct>s if they can, and in many cases this would be the wrong decision -- especially, in my view, when your encoding as part of a publishing workflow. Cheers, Martin * You could also do this kind of thing: <xsl:template match="biblStruct[@type='monographLaterAnthologised']"> <xsl:choose> <xsl:when test="not(analytic/author) and not(analytic/editor)"> </xsl:when> and so on, which reduces the number of templates but makes each one much more complex. -- Martin Holmes University of Victoria Humanities Computing and Media Centre (mholmes at uvic.ca) Half-Baked Software, Inc. (mholmes at halfbakedsoftware.com) martin at mholmes.com From James.Cummings at oucs.ox.ac.uk Sat May 15 13:51:55 2010 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Sat, 15 May 2010 18:51:55 +0100 Subject: [tei-council] @source urns and @version datatype bug Message-ID: <4BEEDF3B.3070003@oucs.ox.ac.uk> Hiya, Lou checked in some changes recently to the TD chapter and the TEI elementSpec as a result of the earlier discussion on schemaSpec/@source and the TEI/@version attribute. One of them struck me as just unintuitive and unclear for users so I wanted to highlight it. I've already discussed it with Lou and I believe understand his reasons (for which I have a certain sympathy), but wanted to comment on it because of its implications. At lines 1174-1188 of http://tei.svn.sourceforge.net/viewvc/tei/trunk/P5/Source/Guidelines/en/TD-DocumentationElements.xml?revision=7524&view=markup It says: ==== <p>The value for the <att>source</att> attribute may be a specific URL as in the preceding example, or any other form of URI. A set of TEI-conformant specifications in a form directly usable by an ODD processor must be available at the location indicated. When no <att>source</att> value is supplied, an ODD processor may either raise an error or assume that the location of the current release of the TEI Guidelines is intended.</p> <p>If the source is specified in the form of a private URI, the form recommended is <code>tei:x.y.z</code>, where <code>x.y.z</code> indicates the version number, e.g. <code>tei:5.1</code> for the most recent version of P5 release 1, or <code>tei:5.2.11</code> for release 2.1.1 of P5. When such a URI is used, it may be necessary to remove or translate it before such a file can be used in blind interchange. </p> ==== What I'm uncomfortable with is the eliding of the last two digits of our published version numbers to form 5.2.11 from TEI P5 version 2.1.1 in the example given. This seems unintuitive and a very non-standard way to treat version numbers. (We are currently on 1.6.0 and this is on every HTML page of the Guidelines.) In addition I'm reluctant to call TEI P5 version 2.1.1 version '5' dot anything. By that I mean that mentally I separate TEI major releases (editions) and version numbering which I view as integral to an edition. (i.e. For TEI P6 we may also have a version 2.1.1, and Lou would sensibly number this 6.2.11 whereas I would number this P6 2.1.1). Moreover when we move from 1.9.x to 2.0.x I seem to remember us deciding that this would indicate a major change release, not as significant as moving to P6, but significant nonetheless. Partly I worry about this because we may indeed soon have a TEI P5 versions where the second numeral of the 1.6.0 version number will be in double-digits and that might cause even more confusion when eliding digits because we have referred to releases occasionally where we have dropped the minor-release number at the end. (e.g. we refer to 1.0, 0.9, 0.5, etc.) I recognise Lou's desire here in providing a straightforward tei: URN, but in this case I'd be more tempted to suggest this should be tei:p5:2.1.1 so in the form of 'project':'edition':'version'. But really what the discussion with Lou brought to my attention is that the default value of @version on the TEI element is '5.0' and in the example given it is '5.1.20' in the revision recently checked into subversion. http://tei.svn.sourceforge.net/viewvc/tei/trunk/P5/Source/Specs/TEI.xml?revision=7478&view=markup Yes, it would be good to rationalise @version attributes across elements (not done yet)... something I generally wholeheartedly encourage. However to me 1.2.0 is very different from 1.20 and I view the P-release numbers as entirely distinct and different from the version numbering of individual versions within any P-release number. My proposed solution would be to create a pattern for the @version attribute's datatype which allows both: a) 1, 2, or 3 digit version numbers separated by full-stops b) an optional P#: before a) Thus someone could use 1.2.3 for @version on unicodeName but P5:1.2.3 on TEI or indeed 1.2 or 1, or 3.11, or 3.4.5, etc. I believe having P#: prefix to the version number more clearly distinguishes the nature of P-editions than just having it be a major version number. I guess it comes down to whether you believe we are currently at TEI version 5.1.60 or whether you believe we are at TEI P5 version 1.6.0. I believe the latter, and feel that the minor-change number of the intermediate version numbering is potentially significant. I would also like to argue that this is what the TEI Council decided previously. If you look in the archive starting at 2007-11-06 in a message from Sebastian entitled "how to release errata, versions etc" you'll see that he says: > I am proposing that we start thinking about this as "P5 release 1.0", > "P5 release 1.0.1" etc. so "P5" is the name of the deliverable, not > the version number. And that day Syd also provides an eerie warning from history: > I'm > presuming P5 is version major.minor.bugFix, like lots of other > things. But this does raise problems with our version= attribute. Syd wrote: Christian wrote: Sebastian wrote: >>> I am proposing that we start thinking about this as "P5 release >>> 1.0", "P5 release 1.0.1" etc. so "P5" is the name of the >>> deliverable, not the version number. >> I thought we already agreed on this, no? > > That is what we decided, but not what we did. The default for > version= is "5.0", and its datatype is xsd:decimal. And Christian later commented: > This looks like a corrigible error then. (The discussion continues and is important historically as it is where we decided to make six-monthly maintenance releases... but that this bug needs correcting drops off the radar and obviously never got fixed.) I know this dissection seems quite intense for something so trivial, but I wanted to make sure I got what we had decided previously accurate. Thanks for reading this. -James From sebastian.rahtz at oucs.ox.ac.uk Sun May 16 09:41:59 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Sun, 16 May 2010 14:41:59 +0100 Subject: [tei-council] @source urns and @version datatype bug In-Reply-To: <4BEEDF3B.3070003@oucs.ox.ac.uk> References: <4BEEDF3B.3070003@oucs.ox.ac.uk> Message-ID: <D7DD4D17-717D-45CA-BADB-0008CF666AC8@oucs.ox.ac.uk> I do agree entirely that this is important to get right, and for it to sustainable. We also need to implement it! But I am unhappy with the "tei:" fake protocol. If we are going to set this up, why not go for a proper URN or at least a tag: URI? -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From mholmes at uvic.ca Mon May 17 12:45:52 2010 From: mholmes at uvic.ca (Martin Holmes) Date: Mon, 17 May 2010 09:45:52 -0700 Subject: [tei-council] @source urns and @version datatype bug In-Reply-To: <4BEEDF3B.3070003@oucs.ox.ac.uk> References: <4BEEDF3B.3070003@oucs.ox.ac.uk> Message-ID: <4BF172C0.7090606@uvic.ca> I don't think this is a minor issue at all; I think it's essential that the policy on version numbering for TEI be clear and clearly documented. It's the sort of thing that will dictate processing pathways for automated processes. I think I'm with Lou on this one: I think "P5" should be an informal human designation for the 5.x tree, and I favour "major.minor.build.revision" or "major.minor.build.release" for the four components. We should encourage people to include full version numbers in the TEI/@version of their data files if they know them, but in many cases, this is going to be impossible. If I encode a lot of data using a schema generated with 5.1.20, then update my schema to 5.2.0, but the update doesn't change the validity status of my files, should I have to change all my data files? So perhaps we should encourage a more generic: <TEI version="5"> where it's not practical or helpful to be more precise about the version number. Cheers, Martin On 10-05-15 10:51 AM, James Cummings wrote: > Hiya, > > Lou checked in some changes recently to the TD chapter and the TEI > elementSpec as a result of the earlier discussion on schemaSpec/@source > and the TEI/@version attribute. One of them struck me as just > unintuitive and unclear for users so I wanted to highlight it. I've > already discussed it with Lou and I believe understand his reasons (for > which I have a certain sympathy), but wanted to comment on it because of > its implications. > > At lines 1174-1188 of > http://tei.svn.sourceforge.net/viewvc/tei/trunk/P5/Source/Guidelines/en/TD-DocumentationElements.xml?revision=7524&view=markup > It says: > > ==== > <p>The value for the<att>source</att> attribute may be a specific URL > as in the preceding example, or any other form of URI. A set of > TEI-conformant specifications in a form directly usable by an ODD > processor must be available at the location indicated. When no > <att>source</att> value is supplied, an ODD processor may either raise > an error or assume that the location of the current release of the TEI > Guidelines is intended.</p> > <p>If the source is specified in the form of a private URI, > the form recommended is<code>tei:x.y.z</code>, where > <code>x.y.z</code> indicates the version number, > e.g.<code>tei:5.1</code> for the most recent version of P5 release 1, > or<code>tei:5.2.11</code> for release 2.1.1 of P5. When such a > URI is used, it may be necessary to remove or translate it before > such a file can be used in blind interchange. > </p> > ==== > > What I'm uncomfortable with is the eliding of the last two digits of our > published version numbers to form 5.2.11 from TEI P5 version 2.1.1 in > the example given. This seems unintuitive and a very non-standard way to > treat version numbers. (We are currently on 1.6.0 and this is on every > HTML page of the Guidelines.) > > In addition I'm reluctant to call TEI P5 version 2.1.1 version '5' dot > anything. By that I mean that mentally I separate TEI major releases > (editions) and version numbering which I view as integral to an edition. > (i.e. For TEI P6 we may also have a version 2.1.1, and Lou would > sensibly number this 6.2.11 whereas I would number this P6 2.1.1). > Moreover when we move from 1.9.x to 2.0.x I seem to remember us deciding > that this would indicate a major change release, not as significant as > moving to P6, but significant nonetheless. Partly I worry about this > because we may indeed soon have a TEI P5 versions where the second > numeral of the 1.6.0 version number will be in double-digits and that > might cause even more confusion when eliding digits because we have > referred to releases occasionally where we have dropped the > minor-release number at the end. (e.g. we refer to 1.0, 0.9, 0.5, etc.) > > I recognise Lou's desire here in providing a straightforward tei: URN, > but in this case I'd be more tempted to suggest this should be > tei:p5:2.1.1 so in the form of 'project':'edition':'version'. > > But really what the discussion with Lou brought to my attention is that > the default value of @version on the TEI element is '5.0' and in the > example given it is '5.1.20' in the revision recently checked into > subversion. > > http://tei.svn.sourceforge.net/viewvc/tei/trunk/P5/Source/Specs/TEI.xml?revision=7478&view=markup > > Yes, it would be good to rationalise @version attributes across elements > (not done yet)... something I generally wholeheartedly encourage. > > However to me 1.2.0 is very different from 1.20 and I view the P-release > numbers as entirely distinct and different from the version numbering of > individual versions within any P-release number. > > My proposed solution would be to create a pattern for the @version > attribute's datatype which allows both: > a) 1, 2, or 3 digit version numbers separated by full-stops > b) an optional P#: before a) > > Thus someone could use 1.2.3 for @version on unicodeName but P5:1.2.3 on > TEI or indeed 1.2 or 1, or 3.11, or 3.4.5, etc. > > I believe having P#: prefix to the version number more clearly > distinguishes the nature of P-editions than just having it be a major > version number. > > I guess it comes down to whether you believe we are currently at TEI > version 5.1.60 or whether you believe we are at TEI P5 version 1.6.0. I > believe the latter, and feel that the minor-change number of the > intermediate version numbering is potentially significant. > > I would also like to argue that this is what the TEI Council decided > previously. If you look in the archive starting at 2007-11-06 in a > message from Sebastian entitled "how to release errata, versions etc" > you'll see that he says: > >> I am proposing that we start thinking about this as "P5 release 1.0", >> "P5 release 1.0.1" etc. so "P5" is the name of the deliverable, not >> the version number. > > And that day Syd also provides an eerie warning from history: > >> I'm >> presuming P5 is version major.minor.bugFix, like lots of other >> things. But this does raise problems with our version= attribute. > > Syd wrote: > Christian wrote: > Sebastian wrote: >>>> I am proposing that we start thinking about this as "P5 release >>>> 1.0", "P5 release 1.0.1" etc. so "P5" is the name of the >>>> deliverable, not the version number. >>> I thought we already agreed on this, no? >> >> That is what we decided, but not what we did. The default for >> version= is "5.0", and its datatype is xsd:decimal. > > And Christian later commented: > >> This looks like a corrigible error then. > > (The discussion continues and is important historically as it is where > we decided to make six-monthly maintenance releases... but that this bug > needs correcting drops off the radar and obviously never got fixed.) > > I know this dissection seems quite intense for something so trivial, but > I wanted to make sure I got what we had decided previously accurate. > > Thanks for reading this. > -James > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > . > -- Martin Holmes University of Victoria Humanities Computing and Media Centre (mholmes at uvic.ca) Half-Baked Software, Inc. (mholmes at halfbakedsoftware.com) martin at mholmes.com From daniel.odonnell at uleth.ca Mon May 17 14:24:51 2010 From: daniel.odonnell at uleth.ca (O'Donnell, Dan) Date: Mon, 17 May 2010 12:24:51 -0600 Subject: [tei-council] @source urns and @version datatype bug In-Reply-To: <4BEEDF3B.3070003@oucs.ox.ac.uk> References: <4BEEDF3B.3070003@oucs.ox.ac.uk> Message-ID: <4BF189F3.9050407@uleth.ca> Hi James, I vaguely remember this discussion. I was a fan of 5.x.x but lost, as I remember (though apparently not in practice). I have a couple of questions/comments about this: 1) Does this mean that 5.1.2.2 is impossible? (i.e. is there some enforcement on the idea that you can only have two periods and three sets of digits) 2) My problem with your suggestion "Thus someone could use 1.2.3 for @version on unicodeName but P5:1.2.3 on TEI or indeed 1.2 or 1, or 3.11, or 3.4.5, etc." is that the stripped form on unicodeName is missing some pretty crucial information: the "edition" number. How would distinguish between unicodeName/@version="1.2.3" from P4 or (god help us, P6) from unicodeName/@version="1.2.3" from P5? It would be like referring to Ubuntu release .4 I agree with you that 1.2.34 when you want to say 1.2.3.4 is terrible as well. But it sounds like we might be constrained by datatypes? On 10-05-15 11:51 AM, James Cummings wrote: > Hiya, > > Lou checked in some changes recently to the TD chapter and the TEI > elementSpec as a result of the earlier discussion on schemaSpec/@source > and the TEI/@version attribute. One of them struck me as just > unintuitive and unclear for users so I wanted to highlight it. I've > already discussed it with Lou and I believe understand his reasons (for > which I have a certain sympathy), but wanted to comment on it because of > its implications. > > At lines 1174-1188 of > http://tei.svn.sourceforge.net/viewvc/tei/trunk/P5/Source/Guidelines/en/TD-DocumentationElements.xml?revision=7524&view=markup > It says: > > ==== > <p>The value for the<att>source</att> attribute may be a specific URL > as in the preceding example, or any other form of URI. A set of > TEI-conformant specifications in a form directly usable by an ODD > processor must be available at the location indicated. When no > <att>source</att> value is supplied, an ODD processor may either raise > an error or assume that the location of the current release of the TEI > Guidelines is intended.</p> > <p>If the source is specified in the form of a private URI, > the form recommended is<code>tei:x.y.z</code>, where > <code>x.y.z</code> indicates the version number, > e.g.<code>tei:5.1</code> for the most recent version of P5 release 1, > or<code>tei:5.2.11</code> for release 2.1.1 of P5. When such a > URI is used, it may be necessary to remove or translate it before > such a file can be used in blind interchange. > </p> > ==== > > What I'm uncomfortable with is the eliding of the last two digits of our > published version numbers to form 5.2.11 from TEI P5 version 2.1.1 in > the example given. This seems unintuitive and a very non-standard way to > treat version numbers. (We are currently on 1.6.0 and this is on every > HTML page of the Guidelines.) > > In addition I'm reluctant to call TEI P5 version 2.1.1 version '5' dot > anything. By that I mean that mentally I separate TEI major releases > (editions) and version numbering which I view as integral to an edition. > (i.e. For TEI P6 we may also have a version 2.1.1, and Lou would > sensibly number this 6.2.11 whereas I would number this P6 2.1.1). > Moreover when we move from 1.9.x to 2.0.x I seem to remember us deciding > that this would indicate a major change release, not as significant as > moving to P6, but significant nonetheless. Partly I worry about this > because we may indeed soon have a TEI P5 versions where the second > numeral of the 1.6.0 version number will be in double-digits and that > might cause even more confusion when eliding digits because we have > referred to releases occasionally where we have dropped the > minor-release number at the end. (e.g. we refer to 1.0, 0.9, 0.5, etc.) > > I recognise Lou's desire here in providing a straightforward tei: URN, > but in this case I'd be more tempted to suggest this should be > tei:p5:2.1.1 so in the form of 'project':'edition':'version'. > > But really what the discussion with Lou brought to my attention is that > the default value of @version on the TEI element is '5.0' and in the > example given it is '5.1.20' in the revision recently checked into > subversion. > > http://tei.svn.sourceforge.net/viewvc/tei/trunk/P5/Source/Specs/TEI.xml?revision=7478&view=markup > > Yes, it would be good to rationalise @version attributes across elements > (not done yet)... something I generally wholeheartedly encourage. > > However to me 1.2.0 is very different from 1.20 and I view the P-release > numbers as entirely distinct and different from the version numbering of > individual versions within any P-release number. > > My proposed solution would be to create a pattern for the @version > attribute's datatype which allows both: > a) 1, 2, or 3 digit version numbers separated by full-stops > b) an optional P#: before a) > > Thus someone could use 1.2.3 for @version on unicodeName but P5:1.2.3 on > TEI or indeed 1.2 or 1, or 3.11, or 3.4.5, etc. > > I believe having P#: prefix to the version number more clearly > distinguishes the nature of P-editions than just having it be a major > version number. > > I guess it comes down to whether you believe we are currently at TEI > version 5.1.60 or whether you believe we are at TEI P5 version 1.6.0. I > believe the latter, and feel that the minor-change number of the > intermediate version numbering is potentially significant. > > I would also like to argue that this is what the TEI Council decided > previously. If you look in the archive starting at 2007-11-06 in a > message from Sebastian entitled "how to release errata, versions etc" > you'll see that he says: > > >> I am proposing that we start thinking about this as "P5 release 1.0", >> "P5 release 1.0.1" etc. so "P5" is the name of the deliverable, not >> the version number. >> > And that day Syd also provides an eerie warning from history: > > >> I'm >> presuming P5 is version major.minor.bugFix, like lots of other >> things. But this does raise problems with our version= attribute. >> > Syd wrote: > Christian wrote: > Sebastian wrote: > >>>> I am proposing that we start thinking about this as "P5 release >>>> 1.0", "P5 release 1.0.1" etc. so "P5" is the name of the >>>> deliverable, not the version number. >>>> >>> I thought we already agreed on this, no? >>> >> That is what we decided, but not what we did. The default for >> version= is "5.0", and its datatype is xsd:decimal. >> > And Christian later commented: > > >> This looks like a corrigible error then. >> > (The discussion continues and is important historically as it is where > we decided to make six-monthly maintenance releases... but that this bug > needs correcting drops off the radar and obviously never got fixed.) > > I know this dissection seems quite intense for something so trivial, but > I wanted to make sure I got what we had decided previously accurate. > > Thanks for reading this. > -James > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > -- Daniel Paul O'Donnell Professor of English University of Lethbridge Chair and CEO, Text Encoding Initiative (http://www.tei-c.org/) Co-Chair, Digital Initiatives Advisory Board, Medieval Academy of America President-elect (English), Society for Digital Humanities/Soci?t? pour l'?tude des m?dias interactifs (http://sdh-semi.org/) Founding Director (2003-2009), Digital Medievalist Project (http://www.digitalmedievalist.org/) Vox: +1 403 329-2377 Fax: +1 403 382-7191 (non-confidential) Home Page: http://people.uleth.ca/~daniel.odonnell/ From lou.burnard at oucs.ox.ac.uk Mon May 17 15:39:14 2010 From: lou.burnard at oucs.ox.ac.uk (Lou Burnard) Date: Mon, 17 May 2010 20:39:14 +0100 Subject: [tei-council] @source urns and @version datatype bug In-Reply-To: <4BF189F3.9050407@uleth.ca> References: <4BEEDF3B.3070003@oucs.ox.ac.uk> <4BF189F3.9050407@uleth.ca> Message-ID: <4BF19B62.4080202@oucs.ox.ac.uk> There seem to be some misunderstanding about this issue. Let me try to state the situation again. 1. We have @version on unicodeName and on TEI. The former is defined (by Unicode) as 3 numbers 1.2.3 and we are not at liberty to change it! It refers to the version of the Unicode standard, of course, and has nothing to do with the TEI version. 2. We can define whatever we like for our own version number. I am merely proposing that it might be economical to use the same pattern as we are obliged to use for the unicode version. That in turn means that we have to do the admittedly slightly unwholesome business of concatenating the two final figures in the (comparatively rare) case where we have something like 1.2.0 and 1.2.1 , if you agree with me that there is a "5." at the start of every version number for P5, and if you agree with me that we want to use the same pattern as we do for unicodeName. Of course, you can disagree on either or both points -- but let's try to reach a speedy conclusion, as it matters. 3. We could make a distinction between "version" and "release" and have two attributes -- so release 1.2.0 of P5 would be @version="5" and @release=1.2.0. Or we could use a different four number pattern for @version and allow 5.1.2.0 4. This matters because we need to decide on a single way of refering to specific releases/versions which is now possible using the @source attribute on ODD *Ref elements O'Donnell, Dan wrote > Hi James, > > I vaguely remember this discussion. I was a fan of 5.x.x but lost, as I > remember (though apparently not in practice). I have a couple of > questions/comments about this: > > 1) Does this mean that 5.1.2.2 is impossible? (i.e. is there some > enforcement on the idea that you can only have two periods and three > sets of digits) > 2) My problem with your suggestion "Thus someone could use 1.2.3 for > @version on unicodeName but P5:1.2.3 on TEI or indeed 1.2 or 1, or 3.11, > or 3.4.5, etc." is that the stripped form on unicodeName is missing some > pretty crucial information: the "edition" number. How would distinguish > between unicodeName/@version="1.2.3" from P4 or (god help us, P6) from > unicodeName/@version="1.2.3" from P5? It would be like referring to > Ubuntu release .4 > > I agree with you that 1.2.34 when you want to say 1.2.3.4 is terrible as > well. But it sounds like we might be constrained by datatypes? > > > On 10-05-15 11:51 AM, James Cummings wrote: > >> Hiya, >> >> Lou checked in some changes recently to the TD chapter and the TEI >> elementSpec as a result of the earlier discussion on schemaSpec/@source >> and the TEI/@version attribute. One of them struck me as just >> unintuitive and unclear for users so I wanted to highlight it. I've >> already discussed it with Lou and I believe understand his reasons (for >> which I have a certain sympathy), but wanted to comment on it because of >> its implications. >> >> At lines 1174-1188 of >> http://tei.svn.sourceforge.net/viewvc/tei/trunk/P5/Source/Guidelines/en/TD-DocumentationElements.xml?revision=7524&view=markup >> It says: >> >> ==== >> <p>The value for the<att>source</att> attribute may be a specific URL >> as in the preceding example, or any other form of URI. A set of >> TEI-conformant specifications in a form directly usable by an ODD >> processor must be available at the location indicated. When no >> <att>source</att> value is supplied, an ODD processor may either raise >> an error or assume that the location of the current release of the TEI >> Guidelines is intended.</p> >> <p>If the source is specified in the form of a private URI, >> the form recommended is<code>tei:x.y.z</code>, where >> <code>x.y.z</code> indicates the version number, >> e.g.<code>tei:5.1</code> for the most recent version of P5 release 1, >> or<code>tei:5.2.11</code> for release 2.1.1 of P5. When such a >> URI is used, it may be necessary to remove or translate it before >> such a file can be used in blind interchange. >> </p> >> ==== >> >> What I'm uncomfortable with is the eliding of the last two digits of our >> published version numbers to form 5.2.11 from TEI P5 version 2.1.1 in >> the example given. This seems unintuitive and a very non-standard way to >> treat version numbers. (We are currently on 1.6.0 and this is on every >> HTML page of the Guidelines.) >> >> In addition I'm reluctant to call TEI P5 version 2.1.1 version '5' dot >> anything. By that I mean that mentally I separate TEI major releases >> (editions) and version numbering which I view as integral to an edition. >> (i.e. For TEI P6 we may also have a version 2.1.1, and Lou would >> sensibly number this 6.2.11 whereas I would number this P6 2.1.1). >> Moreover when we move from 1.9.x to 2.0.x I seem to remember us deciding >> that this would indicate a major change release, not as significant as >> moving to P6, but significant nonetheless. Partly I worry about this >> because we may indeed soon have a TEI P5 versions where the second >> numeral of the 1.6.0 version number will be in double-digits and that >> might cause even more confusion when eliding digits because we have >> referred to releases occasionally where we have dropped the >> minor-release number at the end. (e.g. we refer to 1.0, 0.9, 0.5, etc.) >> >> I recognise Lou's desire here in providing a straightforward tei: URN, >> but in this case I'd be more tempted to suggest this should be >> tei:p5:2.1.1 so in the form of 'project':'edition':'version'. >> >> But really what the discussion with Lou brought to my attention is that >> the default value of @version on the TEI element is '5.0' and in the >> example given it is '5.1.20' in the revision recently checked into >> subversion. >> >> http://tei.svn.sourceforge.net/viewvc/tei/trunk/P5/Source/Specs/TEI.xml?revision=7478&view=markup >> >> Yes, it would be good to rationalise @version attributes across elements >> (not done yet)... something I generally wholeheartedly encourage. >> >> However to me 1.2.0 is very different from 1.20 and I view the P-release >> numbers as entirely distinct and different from the version numbering of >> individual versions within any P-release number. >> >> My proposed solution would be to create a pattern for the @version >> attribute's datatype which allows both: >> a) 1, 2, or 3 digit version numbers separated by full-stops >> b) an optional P#: before a) >> >> Thus someone could use 1.2.3 for @version on unicodeName but P5:1.2.3 on >> TEI or indeed 1.2 or 1, or 3.11, or 3.4.5, etc. >> >> I believe having P#: prefix to the version number more clearly >> distinguishes the nature of P-editions than just having it be a major >> version number. >> >> I guess it comes down to whether you believe we are currently at TEI >> version 5.1.60 or whether you believe we are at TEI P5 version 1.6.0. I >> believe the latter, and feel that the minor-change number of the >> intermediate version numbering is potentially significant. >> >> I would also like to argue that this is what the TEI Council decided >> previously. If you look in the archive starting at 2007-11-06 in a >> message from Sebastian entitled "how to release errata, versions etc" >> you'll see that he says: >> >> >> >>> I am proposing that we start thinking about this as "P5 release 1.0", >>> "P5 release 1.0.1" etc. so "P5" is the name of the deliverable, not >>> the version number. >>> >>> >> And that day Syd also provides an eerie warning from history: >> >> >> >>> I'm >>> presuming P5 is version major.minor.bugFix, like lots of other >>> things. But this does raise problems with our version= attribute. >>> >>> >> Syd wrote: >> Christian wrote: >> Sebastian wrote: >> >> >>>>> I am proposing that we start thinking about this as "P5 release >>>>> 1.0", "P5 release 1.0.1" etc. so "P5" is the name of the >>>>> deliverable, not the version number. >>>>> >>>>> >>>> I thought we already agreed on this, no? >>>> >>>> >>> That is what we decided, but not what we did. The default for >>> version= is "5.0", and its datatype is xsd:decimal. >>> >>> >> And Christian later commented: >> >> >> >>> This looks like a corrigible error then. >>> >>> >> (The discussion continues and is important historically as it is where >> we decided to make six-monthly maintenance releases... but that this bug >> needs correcting drops off the radar and obviously never got fixed.) >> >> I know this dissection seems quite intense for something so trivial, but >> I wanted to make sure I got what we had decided previously accurate. >> >> Thanks for reading this. >> -James >> _______________________________________________ >> tei-council mailing list >> tei-council at lists.village.Virginia.EDU >> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council >> >> > > i From daniel.odonnell at uleth.ca Mon May 17 15:57:19 2010 From: daniel.odonnell at uleth.ca (O'Donnell, Dan) Date: Mon, 17 May 2010 13:57:19 -0600 Subject: [tei-council] @source urns and @version datatype bug In-Reply-To: <4BF19B62.4080202@oucs.ox.ac.uk> References: <4BEEDF3B.3070003@oucs.ox.ac.uk> <4BF189F3.9050407@uleth.ca> <4BF19B62.4080202@oucs.ox.ac.uk> Message-ID: <4BF19F9F.2000506@uleth.ca> Thanks Lou for clarifying this. I prefer either of the options in your #3. In honour of my old political alma mater, the lib dems, I'll use a transferable alternative vote to prioritise: 1) Use a 4 digit @version for the TEI elements or failing that 2) Use @version="5" @release="1.2.3" I suppose a third option might be to have either @unicodeVersion or @teiVersion against @version if you wanted to avoid using different constraints on identically named attributes. -dan On 10-05-17 01:39 PM, Lou Burnard wrote: > There seem to be some misunderstanding about this issue. Let me try to > state the situation again. > > 1. We have @version on unicodeName and on TEI. The former is defined (by > Unicode) as 3 numbers 1.2.3 and we are not at liberty to change it! It > refers to the version of the Unicode standard, of course, and has > nothing to do with the TEI version. > > 2. We can define whatever we like for our own version number. I am > merely proposing that it might be economical to use the same pattern as > we are obliged to use for the unicode version. That in turn means that > we have to do the admittedly slightly unwholesome business of > concatenating the two final figures in the (comparatively rare) case > where we have something like 1.2.0 and 1.2.1 , if you agree with me that > there is a "5." at the start of every version number for P5, and if you > agree with me that we want to use the same pattern as we do for > unicodeName. Of course, you can disagree on either or both points -- but > let's try to reach a speedy conclusion, as it matters. > > 3. We could make a distinction between "version" and "release" and have > two attributes -- so release 1.2.0 of P5 would be @version="5" and > @release=1.2.0. Or we could use a different four number pattern for > @version and allow 5.1.2.0 > > 4. This matters because we need to decide on a single way of refering to > specific releases/versions which is now possible using the @source > attribute on ODD *Ref elements > > O'Donnell, Dan wrote > >> Hi James, >> >> I vaguely remember this discussion. I was a fan of 5.x.x but lost, as I >> remember (though apparently not in practice). I have a couple of >> questions/comments about this: >> >> 1) Does this mean that 5.1.2.2 is impossible? (i.e. is there some >> enforcement on the idea that you can only have two periods and three >> sets of digits) >> 2) My problem with your suggestion "Thus someone could use 1.2.3 for >> @version on unicodeName but P5:1.2.3 on TEI or indeed 1.2 or 1, or 3.11, >> or 3.4.5, etc." is that the stripped form on unicodeName is missing some >> pretty crucial information: the "edition" number. How would distinguish >> between unicodeName/@version="1.2.3" from P4 or (god help us, P6) from >> unicodeName/@version="1.2.3" from P5? It would be like referring to >> Ubuntu release .4 >> >> I agree with you that 1.2.34 when you want to say 1.2.3.4 is terrible as >> well. But it sounds like we might be constrained by datatypes? >> >> >> On 10-05-15 11:51 AM, James Cummings wrote: >> >> >>> Hiya, >>> >>> Lou checked in some changes recently to the TD chapter and the TEI >>> elementSpec as a result of the earlier discussion on schemaSpec/@source >>> and the TEI/@version attribute. One of them struck me as just >>> unintuitive and unclear for users so I wanted to highlight it. I've >>> already discussed it with Lou and I believe understand his reasons (for >>> which I have a certain sympathy), but wanted to comment on it because of >>> its implications. >>> >>> At lines 1174-1188 of >>> http://tei.svn.sourceforge.net/viewvc/tei/trunk/P5/Source/Guidelines/en/TD-DocumentationElements.xml?revision=7524&view=markup >>> It says: >>> >>> ==== >>> <p>The value for the<att>source</att> attribute may be a specific URL >>> as in the preceding example, or any other form of URI. A set of >>> TEI-conformant specifications in a form directly usable by an ODD >>> processor must be available at the location indicated. When no >>> <att>source</att> value is supplied, an ODD processor may either raise >>> an error or assume that the location of the current release of the TEI >>> Guidelines is intended.</p> >>> <p>If the source is specified in the form of a private URI, >>> the form recommended is<code>tei:x.y.z</code>, where >>> <code>x.y.z</code> indicates the version number, >>> e.g.<code>tei:5.1</code> for the most recent version of P5 release 1, >>> or<code>tei:5.2.11</code> for release 2.1.1 of P5. When such a >>> URI is used, it may be necessary to remove or translate it before >>> such a file can be used in blind interchange. >>> </p> >>> ==== >>> >>> What I'm uncomfortable with is the eliding of the last two digits of our >>> published version numbers to form 5.2.11 from TEI P5 version 2.1.1 in >>> the example given. This seems unintuitive and a very non-standard way to >>> treat version numbers. (We are currently on 1.6.0 and this is on every >>> HTML page of the Guidelines.) >>> >>> In addition I'm reluctant to call TEI P5 version 2.1.1 version '5' dot >>> anything. By that I mean that mentally I separate TEI major releases >>> (editions) and version numbering which I view as integral to an edition. >>> (i.e. For TEI P6 we may also have a version 2.1.1, and Lou would >>> sensibly number this 6.2.11 whereas I would number this P6 2.1.1). >>> Moreover when we move from 1.9.x to 2.0.x I seem to remember us deciding >>> that this would indicate a major change release, not as significant as >>> moving to P6, but significant nonetheless. Partly I worry about this >>> because we may indeed soon have a TEI P5 versions where the second >>> numeral of the 1.6.0 version number will be in double-digits and that >>> might cause even more confusion when eliding digits because we have >>> referred to releases occasionally where we have dropped the >>> minor-release number at the end. (e.g. we refer to 1.0, 0.9, 0.5, etc.) >>> >>> I recognise Lou's desire here in providing a straightforward tei: URN, >>> but in this case I'd be more tempted to suggest this should be >>> tei:p5:2.1.1 so in the form of 'project':'edition':'version'. >>> >>> But really what the discussion with Lou brought to my attention is that >>> the default value of @version on the TEI element is '5.0' and in the >>> example given it is '5.1.20' in the revision recently checked into >>> subversion. >>> >>> http://tei.svn.sourceforge.net/viewvc/tei/trunk/P5/Source/Specs/TEI.xml?revision=7478&view=markup >>> >>> Yes, it would be good to rationalise @version attributes across elements >>> (not done yet)... something I generally wholeheartedly encourage. >>> >>> However to me 1.2.0 is very different from 1.20 and I view the P-release >>> numbers as entirely distinct and different from the version numbering of >>> individual versions within any P-release number. >>> >>> My proposed solution would be to create a pattern for the @version >>> attribute's datatype which allows both: >>> a) 1, 2, or 3 digit version numbers separated by full-stops >>> b) an optional P#: before a) >>> >>> Thus someone could use 1.2.3 for @version on unicodeName but P5:1.2.3 on >>> TEI or indeed 1.2 or 1, or 3.11, or 3.4.5, etc. >>> >>> I believe having P#: prefix to the version number more clearly >>> distinguishes the nature of P-editions than just having it be a major >>> version number. >>> >>> I guess it comes down to whether you believe we are currently at TEI >>> version 5.1.60 or whether you believe we are at TEI P5 version 1.6.0. I >>> believe the latter, and feel that the minor-change number of the >>> intermediate version numbering is potentially significant. >>> >>> I would also like to argue that this is what the TEI Council decided >>> previously. If you look in the archive starting at 2007-11-06 in a >>> message from Sebastian entitled "how to release errata, versions etc" >>> you'll see that he says: >>> >>> >>> >>> >>>> I am proposing that we start thinking about this as "P5 release 1.0", >>>> "P5 release 1.0.1" etc. so "P5" is the name of the deliverable, not >>>> the version number. >>>> >>>> >>>> >>> And that day Syd also provides an eerie warning from history: >>> >>> >>> >>> >>>> I'm >>>> presuming P5 is version major.minor.bugFix, like lots of other >>>> things. But this does raise problems with our version= attribute. >>>> >>>> >>>> >>> Syd wrote: >>> Christian wrote: >>> Sebastian wrote: >>> >>> >>> >>>>>> I am proposing that we start thinking about this as "P5 release >>>>>> 1.0", "P5 release 1.0.1" etc. so "P5" is the name of the >>>>>> deliverable, not the version number. >>>>>> >>>>>> >>>>>> >>>>> I thought we already agreed on this, no? >>>>> >>>>> >>>>> >>>> That is what we decided, but not what we did. The default for >>>> version= is "5.0", and its datatype is xsd:decimal. >>>> >>>> >>>> >>> And Christian later commented: >>> >>> >>> >>> >>>> This looks like a corrigible error then. >>>> >>>> >>>> >>> (The discussion continues and is important historically as it is where >>> we decided to make six-monthly maintenance releases... but that this bug >>> needs correcting drops off the radar and obviously never got fixed.) >>> >>> I know this dissection seems quite intense for something so trivial, but >>> I wanted to make sure I got what we had decided previously accurate. >>> >>> Thanks for reading this. >>> -James >>> _______________________________________________ >>> tei-council mailing list >>> tei-council at lists.village.Virginia.EDU >>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council >>> >>> >>> >> >> > i > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > -- Daniel Paul O'Donnell Professor of English University of Lethbridge Chair and CEO, Text Encoding Initiative (http://www.tei-c.org/) Co-Chair, Digital Initiatives Advisory Board, Medieval Academy of America President-elect (English), Society for Digital Humanities/Soci?t? pour l'?tude des m?dias interactifs (http://sdh-semi.org/) Founding Director (2003-2009), Digital Medievalist Project (http://www.digitalmedievalist.org/) Vox: +1 403 329-2377 Fax: +1 403 382-7191 (non-confidential) Home Page: http://people.uleth.ca/~daniel.odonnell/ From sebastian.rahtz at oucs.ox.ac.uk Mon May 17 18:47:10 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 17 May 2010 23:47:10 +0100 Subject: [tei-council] @source urns and @version datatype bug In-Reply-To: <4BF19B62.4080202@oucs.ox.ac.uk> References: <4BEEDF3B.3070003@oucs.ox.ac.uk> <4BF189F3.9050407@uleth.ca> <4BF19B62.4080202@oucs.ox.ac.uk> Message-ID: <AA6E6074-FB79-410D-9A3F-C3772E2EB879@oucs.ox.ac.uk> > we have to do the admittedly slightly unwholesome business of > concatenating the two final figures in the (comparatively rare) case > where we have something like 1.2.0 and 1.2.1 , Bear in mind that we have agreed that the "z" in x.y.z can only indicate cosmetic or wording changes. any change which affects the schema must increment the "y". So it would never make sense for an ODD to link itself to 1.2.1 or 1.2.0, only to 1.2 I am fence sitting, though, at the moment on this. -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From James.Cummings at oucs.ox.ac.uk Tue May 18 07:32:40 2010 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Tue, 18 May 2010 12:32:40 +0100 Subject: [tei-council] @source urns and @version datatype bug In-Reply-To: <4BF19B62.4080202@oucs.ox.ac.uk> References: <4BEEDF3B.3070003@oucs.ox.ac.uk> <4BF189F3.9050407@uleth.ca> <4BF19B62.4080202@oucs.ox.ac.uk> Message-ID: <4BF27AD8.2060607@oucs.ox.ac.uk> Lou Burnard wrote: > 3. We could make a distinction between "version" and "release" and have > two attributes -- so release 1.2.0 of P5 would be @version="5" and > @release=1.2.0. Or we could use a different four number pattern for > @version and allow 5.1.2.0 For the record, I don't really have a problem with 5.1.2.1 as a TEI version number. i.e. I don't mind there being 4 parts. Also long as wel announce this change, make sure the version number is displayed on the webpages and sourceforge like this, etc. I just want us be consistent over all places the TEI version is displayed and also not do special eliding of the last two digits. I have to say my preferences align with Dan's in this case, 4 digit number or if lots of argument against that, two attributes. I'm not really bothered about which solution is chosen as long as we are consistent and remember to implement it this time. ;-) > 4. This matters because we need to decide on a single way of refering to > specific releases/versions which is now possible using the @source > attribute on ODD *Ref elements Yes. DavidS and I proposed a method for canonical URLs for release packages on the website. I've got a copy of this with me and will re-read it and after discussion with DavidS might re-propose something specifically in this area. -James From daniel.odonnell at uleth.ca Tue May 18 12:21:39 2010 From: daniel.odonnell at uleth.ca (O'Donnell, Dan) Date: Tue, 18 May 2010 10:21:39 -0600 Subject: [tei-council] @source urns and @version datatype bug In-Reply-To: <4BF27AD8.2060607@oucs.ox.ac.uk> References: <4BEEDF3B.3070003@oucs.ox.ac.uk> <4BF189F3.9050407@uleth.ca> <4BF19B62.4080202@oucs.ox.ac.uk> <4BF27AD8.2060607@oucs.ox.ac.uk> Message-ID: <4BF2BE93.2040101@uleth.ca> James, I think that should be David.S (i.e. with a separator). ;) On 10-05-18 05:32 AM, James Cummings wrote: > Lou Burnard wrote: > >> 3. We could make a distinction between "version" and "release" and have >> two attributes -- so release 1.2.0 of P5 would be @version="5" and >> @release=1.2.0. Or we could use a different four number pattern for >> @version and allow 5.1.2.0 >> > For the record, I don't really have a problem with 5.1.2.1 as a TEI > version number. i.e. I don't mind there being 4 parts. Also long as wel > announce this change, make sure the version number is displayed on the > webpages and sourceforge like this, etc. I just want us be consistent > over all places the TEI version is displayed and also not do special > eliding of the last two digits. > > I have to say my preferences align with Dan's in this case, 4 digit > number or if lots of argument against that, two attributes. I'm not > really bothered about which solution is chosen as long as we are > consistent and remember to implement it this time. ;-) > > >> 4. This matters because we need to decide on a single way of refering to >> specific releases/versions which is now possible using the @source >> attribute on ODD *Ref elements >> > Yes. DavidS and I proposed a method for canonical URLs for release > packages on the website. I've got a copy of this with me and will > re-read it and after discussion with DavidS might re-propose something > specifically in this area. > > -James > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > -- Daniel Paul O'Donnell Professor of English University of Lethbridge Chair and CEO, Text Encoding Initiative (http://www.tei-c.org/) Co-Chair, Digital Initiatives Advisory Board, Medieval Academy of America President-elect (English), Society for Digital Humanities/Soci?t? pour l'?tude des m?dias interactifs (http://sdh-semi.org/) Founding Director (2003-2009), Digital Medievalist Project (http://www.digitalmedievalist.org/) Vox: +1 403 329-2377 Fax: +1 403 382-7191 (non-confidential) Home Page: http://people.uleth.ca/~daniel.odonnell/ From kevin.s.hawkins at ultraslavonic.info Tue May 18 22:31:41 2010 From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins) Date: Tue, 18 May 2010 22:31:41 -0400 (EDT) Subject: [tei-council] bibliog doc In-Reply-To: <4BED67F1.30301@uvic.ca> References: <4BEC693C.1060102@oucs.ox.ac.uk> <4BEC7D6C.8040409@uvic.ca> <4BED1A03.2000405@oucs.ox.ac.uk> <4BED67F1.30301@uvic.ca> Message-ID: <46840.96.244.216.144.1274236301.squirrel@www.lishost.net> Hi all, apologies for the delay in responding. Was in transit and am catching up. Lou Burnard wrote: > As relaxation from grappling with implementing the proposed ODD changes, > I thought I'd work through the document on bibliographic issues which > Kevin circulated earlier. > > I have three reactions so far (and some comments below) ... > > 1. Following the gloss list in "Notes for library cataloguers" I have now > revised the proposed new text as follows: [. . .] > <!-- item>There is no place in a TEI header to > specify main or added entries for the catalogue record.</item--> > <!-- I dont understand what this means : could you give an example of > the kind of info that the TEI header does not allow you to provide. --> First, some background. Catalog records include both information transcribed from the title page and official forms of names from an authority file, allowing users to find all works by an author who published under variants of their name. Let's take this example: http://mirlyn.lib.umich.edu/Record/003579580 The text that follows the slash ("edited, with an introduction and notes, [. . .]") is what is transcribed from the title page. However, the cataloger determined that the party most responsible for the content of the work is a person whose official name is constructed as: Shakespeare, William, 1564-1616. even though this string of text almost certainly never appeared in the original document, even on the title page. This is the "main entry". Furthermore, the cataloger determined that two other parties were also responsible: Page, Thomas. Paige, John. These are added entries. Both types of entries use names from the authority file. In the TEI, however, it's not clear whether the content of <author>, <editor>, and <respStmt> should contain the name as transcribed, the official form of a name, or some combination (such as through use of @key). Furthermore, if you want to indicate in your TEI header that a certain <author> is the main entry according to cataloging rules and another is an added entry, there's no given way to do this. > ----------------------- > > 2. I revised the additional material proposed for the end of section > 3.? as follows: > > > <p>The most commonly used elements in the model.biblLike class are > <gi>biblStruct</gi> and <gi>bibl</gi>. <gi>biblStruct</gi> will > usually be easier to process mechanically than <gi>bibl</gi> because > its structure is more constrained and predictable. It is suited to > situations in which the objective is to represent bibliographic > information for machine processing directly by other > systems or after conversion to some other bibliographic markup formats > such as BibTeXML or MODS. Punctuation delimiting the components of a > print citation is not permitted directly within a <gi>biblStruct</gi> > element; instead, the presence and order of child elements must be used to > reconstruct the punctuation required by a particular style. > <!--While <gi>biblStruct</gi> offers enough > flexibility for encoding bibliographic references to simple print > works, for many documents, especially electronic ones, it proves > problematic.--> <!-- no problems presented --> > </p> > > <p>By contrast, <gi>bibl</gi> allows for considerable flexibility in > that it can include both delimiting punctuation and unmarked-up text; > and its constituents can also be ordered in any way. This makes it > suitable for marking up bibliographies in existing documents, where it > is considered important to preserve the form of references in the > original document, while also distinguishing important pieces of > information such as authors, dates, publishers, and so > on. <gi>bibl</gi> may also be useful when encoding <soCalled>born > digital</soCalled> documents which require use of a specific style > guide when rendering the content <!-- why is this true of born digital > dox in particular? -->; its flexibility makes it easier to provide all > the information for a reference in the exact sequence required by the > target rendering, including any necessary punctuation and linking > words, rather than using an XSLT stylesheet or similar to reorder and > punctuate the data. <!-- tough if you later want it in a different > form for another rendering engine of course --> </p> Lou wants a clearer rationale here. Martin's done a good job of explaining his rationale, but let me try stating this in different terms just in case it alleviates confusion over Martin's use of "electronic" documents and "born-digital" ones. I believe Martin envisions two approaches to encoding bibliographic citations given in a source document: a) You want to represent the source document as it is, even if it has inconsistencies in it. b) You want to impose structure on the citations to catch errors and allow you to format the citations according to various style guides (MLA, Chicago, APA, etc.) automatically by displaying the content of various bibl/biblStruct/biblFull child elements in different orders. This is the born-digital case in the second paragraph: you're creating a new TEI document for which there's no print source to be represented. If you're doing (a), you basically have to use <bibl>. If you're doing (b), people are generally inclined to use biblStruct, but Martin argues in this document (and at the symposium in Dublin) that it's more practical to use bibl. As described in the first paragraph, he has found that citations to electronic works are often quite complicated in structure and that if you try to use biblStruct, it will be quite difficult to format according to the rules of MLA, Chicago, APA, etc. Martin, chime in if I got this wrong. > <p> The third element in the model.biblLike class, <gi>biblFull</gi>, > has a content model based on the <gi>fileDesc</gi> element of the TEI > header. Both are based on the International Standard for Bibliographic > Description (ISBD), which forms the basis of several national > standards for bibliographic citations. The order of child elements in > both <gi>biblFull</gi> and <gi>fileDesc</gi> corresponds to the order > of bibliographic desription <soCalled>areas</soCalled> in ISBD with > two minor exceptions. First, the <gi>extent</gi> element, > corresponding to the physical description area in ISBD, appears just > after the publication, production, distribution, etc. area in ISBD, > not before it as in TEI. Second, <gi>biblFull</gi> and > <gi>fileDesc</gi> use the child element <gi>publicationStmt</gi> to > cover not only the publication, production, distribution, etc. area > but also the resource identifier and terms of availability area > associated with that publication. <!-- how else would you show that > something was published by X with one identifier and by Y with a > different one? --> Despite these inconsistencies, users encoding > citations and attempting to format them according to a standard that > closely adheres to ISBD may find that <gi>biblFull</gi>, used with its > child elements and without delimiting punctuation, provides an > appropriate granularity of encoding with elements that can easily > rendered for the reader. However, it is important to note that some > ISBD-derived citation formats (such as ANSI/NISO Z39.29 and ГОСТ > 7.1) are not entirely conformant to ISBD either, since they may begin > with a statement of authorship that does not map to the ISBD statement > of responsibility. <!-- and which, therefore, cannot be encoded > anywhere inside of a <gi>biblFull</gi> (or <gi>fileDesc</gi>). --> > <!-- not so: you can use respStmt with an appropriate @type surely? > --> </p> There are two questions hidden in this paragraph: a) Lou wondered why I noted that in fileDesc and biblFull, idno and availability are children of publicationStmt. I understand why the TEI put them there, but I note it because the ISBD model, these are something akin to a sibling element to the publication statement. See http://en.wikipedia.org/wiki/International_Standard_Bibliographic_Description So, as I say earlier in that paragraph, the order doesn't quite match. b) Lou said you could handle the Z39.29 statement of authorship (my term!) which is separate from the statement of responsibility (an ISBD term) by using different values of @type on respStmt. This is true. My only point is that Z39.29 citations have a component that's not in ISBD, so if someone was going to produce citations according to Z39.29, they should understand that if they chose biblFull, there would an additional wrinkle in addition to the two minor exceptions I gave earlier in the paragraph. > 3. Use of persName inside biblStruct > > <!-- Name markup is essential for proper > indexing and other forms of processing. It > seems advisable that all biblStruct examples > use it, since the purpose of biblStruct is to > provide a highly-structured reference. --> > > While this may be true, it presents us with quite a problem in terms > of house style. Usually we try not to use elements from one module in > examples appearing in a chapter which describes another. In the few > rare exceptions, we make quite a song and dance about the need to > include the other module etc. But biblStruct and friends are > described in the core module, whereas the <persName> etc. elements > are described in names and dates. (That incidentally is why the <name> > element was originally used in some of these examples -- name is > available in the core). So, while I am perfectly to change some of the > examples to indicate what you propose as appropriate use of the > naming elements, I don't think it should be done uniformly. I fear > this needs more mulling over. Yes indeed. In the summary of our proposal to Council, Martin, Laurent, and I asserted in principle 1 that if you use biblStruct, you really should use the Names and Dates module. Council agreed to this. If we don't change all of the examples to reflect this, it needs to be as clear as possible to readers why this is the case. Kevin From mholmes at uvic.ca Wed May 19 11:02:31 2010 From: mholmes at uvic.ca (Martin Holmes) Date: Wed, 19 May 2010 08:02:31 -0700 Subject: [tei-council] bibliog doc In-Reply-To: <46840.96.244.216.144.1274236301.squirrel@www.lishost.net> References: <4BEC693C.1060102@oucs.ox.ac.uk> <4BEC7D6C.8040409@uvic.ca> <4BED1A03.2000405@oucs.ox.ac.uk> <4BED67F1.30301@uvic.ca> <46840.96.244.216.144.1274236301.squirrel@www.lishost.net> Message-ID: <4BF3FD87.3080807@uvic.ca> Hi all, >> 2. I revised the additional material proposed for the end of section >> 3.? as follows: >> >> >> <p>The most commonly used elements in the model.biblLike class are >> <gi>biblStruct</gi> and<gi>bibl</gi>.<gi>biblStruct</gi> will >> usually be easier to process mechanically than<gi>bibl</gi> because >> its structure is more constrained and predictable. It is suited to >> situations in which the objective is to represent bibliographic >> information for machine processing directly by other >> systems or after conversion to some other bibliographic markup formats >> such as BibTeXML or MODS. Punctuation delimiting the components of a >> print citation is not permitted directly within a<gi>biblStruct</gi> >> element; instead, the presence and order of child elements must be used to >> reconstruct the punctuation required by a particular style. >> <!--While<gi>biblStruct</gi> offers enough >> flexibility for encoding bibliographic references to simple print >> works, for many documents, especially electronic ones, it proves >> problematic.--> <!-- no problems presented --> >> </p> >> >> <p>By contrast,<gi>bibl</gi> allows for considerable flexibility in >> that it can include both delimiting punctuation and unmarked-up text; >> and its constituents can also be ordered in any way. This makes it >> suitable for marking up bibliographies in existing documents, where it >> is considered important to preserve the form of references in the >> original document, while also distinguishing important pieces of >> information such as authors, dates, publishers, and so >> on.<gi>bibl</gi> may also be useful when encoding<soCalled>born >> digital</soCalled> documents which require use of a specific style >> guide when rendering the content<!-- why is this true of born digital >> dox in particular? -->; its flexibility makes it easier to provide all >> the information for a reference in the exact sequence required by the >> target rendering, including any necessary punctuation and linking >> words, rather than using an XSLT stylesheet or similar to reorder and >> punctuate the data.<!-- tough if you later want it in a different >> form for another rendering engine of course --> </p> > > Lou wants a clearer rationale here. > > Martin's done a good job of explaining his rationale, but let me try > stating this in different terms just in case it alleviates confusion over > Martin's use of "electronic" documents and "born-digital" ones. > > I believe Martin envisions two approaches to encoding bibliographic > citations given in a source document: > > a) You want to represent the source document as it is, even if it has > inconsistencies in it. > > b) You want to impose structure on the citations to catch errors and allow > you to format the citations according to various style guides (MLA, > Chicago, APA, etc.) automatically by displaying the content of various > bibl/biblStruct/biblFull child elements in different orders. This is the > born-digital case in the second paragraph: you're creating a new TEI > document for which there's no print source to be represented. > > If you're doing (a), you basically have to use<bibl>. > > If you're doing (b), people are generally inclined to use biblStruct, but > Martin argues in this document (and at the symposium in Dublin) that it's > more practical to use bibl. As described in the first paragraph, he has > found that citations to electronic works are often quite complicated in > structure and that if you try to use biblStruct, it will be quite > difficult to format according to the rules of MLA, Chicago, APA, etc. > > Martin, chime in if I got this wrong. That's exactly my point, expressed more clearly than I've managed to express it so far myself. My worry is that we push people into using <biblStruct> when <bibl> would actually be more suitable, simply because of the weight of examples of <biblStruct> and the absence of any encouragement to think about <bibl> as a more practical alternative. >> 3. Use of persName inside biblStruct >> >> <!-- Name markup is essential for proper >> indexing and other forms of processing. It >> seems advisable that all biblStruct examples >> use it, since the purpose of biblStruct is to >> provide a highly-structured reference. --> >> >> While this may be true, it presents us with quite a problem in terms >> of house style. Usually we try not to use elements from one module in >> examples appearing in a chapter which describes another. In the few >> rare exceptions, we make quite a song and dance about the need to >> include the other module etc. But biblStruct and friends are >> described in the core module, whereas the<persName> etc. elements >> are described in names and dates. (That incidentally is why the<name> >> element was originally used in some of these examples -- name is >> available in the core). So, while I am perfectly to change some of the >> examples to indicate what you propose as appropriate use of the >> naming elements, I don't think it should be done uniformly. I fear >> this needs more mulling over. > > Yes indeed. In the summary of our proposal to Council, Martin, Laurent, > and I asserted in principle 1 that if you use biblStruct, you really > should use the Names and Dates module. Council agreed to this. If we > don't change all of the examples to reflect this, it needs to be as clear > as possible to readers why this is the case. This issue is similar to the one above: if we assume (and my experience suggests this is true) that most users, at least in the early stages of using TEI, will tend to copy-paste examples from the Guidelines and adapt them, then we ought to avoid providing examples which will not work very well for them in real projects. A <biblStruct> whose name components are not marked up is not very useful for its intended purpose -- automated processing and interchange. I'd suggest that we add a section on "Name encoding in bibliographical references", fairly early in the chapter, to clarify this. Does that make sense? Cheers, Martin -- Martin Holmes University of Victoria Humanities Computing and Media Centre (mholmes at uvic.ca) Half-Baked Software, Inc. (mholmes at halfbakedsoftware.com) martin at mholmes.com From lou.burnard at oucs.ox.ac.uk Wed May 19 11:14:02 2010 From: lou.burnard at oucs.ox.ac.uk (Lou Burnard) Date: Wed, 19 May 2010 16:14:02 +0100 Subject: [tei-council] bibliog doc In-Reply-To: <4BF3FD87.3080807@uvic.ca> References: <4BEC693C.1060102@oucs.ox.ac.uk> <4BEC7D6C.8040409@uvic.ca> <4BED1A03.2000405@oucs.ox.ac.uk> <4BED67F1.30301@uvic.ca> <46840.96.244.216.144.1274236301.squirrel@www.lishost.net> <4BF3FD87.3080807@uvic.ca> Message-ID: <4BF4003A.9090309@oucs.ox.ac.uk> Another suggestion, which probably wont make me any friends, might be to hive biblStruct and biblFull off to a chapter of their own. We might even go so far as to take them out of the core and put them in their very own module. Yes that would cause all existing ODDs using them to crash and burn, but it would slim the core down a bit, which has long been a desideratum. Martin Holmes wrote: > Hi all, > >>> 2. I revised the additional material proposed for the end of section >>> 3.? as follows: >>> >>> >>> <p>The most commonly used elements in the model.biblLike class are >>> <gi>biblStruct</gi> and<gi>bibl</gi>.<gi>biblStruct</gi> will >>> usually be easier to process mechanically than<gi>bibl</gi> because >>> its structure is more constrained and predictable. It is suited to >>> situations in which the objective is to represent bibliographic >>> information for machine processing directly by other >>> systems or after conversion to some other bibliographic markup formats >>> such as BibTeXML or MODS. Punctuation delimiting the components of a >>> print citation is not permitted directly within a<gi>biblStruct</gi> >>> element; instead, the presence and order of child elements must be used to >>> reconstruct the punctuation required by a particular style. >>> <!--While<gi>biblStruct</gi> offers enough >>> flexibility for encoding bibliographic references to simple print >>> works, for many documents, especially electronic ones, it proves >>> problematic.--> <!-- no problems presented --> >>> </p> >>> >>> <p>By contrast,<gi>bibl</gi> allows for considerable flexibility in >>> that it can include both delimiting punctuation and unmarked-up text; >>> and its constituents can also be ordered in any way. This makes it >>> suitable for marking up bibliographies in existing documents, where it >>> is considered important to preserve the form of references in the >>> original document, while also distinguishing important pieces of >>> information such as authors, dates, publishers, and so >>> on.<gi>bibl</gi> may also be useful when encoding<soCalled>born >>> digital</soCalled> documents which require use of a specific style >>> guide when rendering the content<!-- why is this true of born digital >>> dox in particular? -->; its flexibility makes it easier to provide all >>> the information for a reference in the exact sequence required by the >>> target rendering, including any necessary punctuation and linking >>> words, rather than using an XSLT stylesheet or similar to reorder and >>> punctuate the data.<!-- tough if you later want it in a different >>> form for another rendering engine of course --> </p> >>> >> Lou wants a clearer rationale here. >> >> Martin's done a good job of explaining his rationale, but let me try >> stating this in different terms just in case it alleviates confusion over >> Martin's use of "electronic" documents and "born-digital" ones. >> >> I believe Martin envisions two approaches to encoding bibliographic >> citations given in a source document: >> >> a) You want to represent the source document as it is, even if it has >> inconsistencies in it. >> >> b) You want to impose structure on the citations to catch errors and allow >> you to format the citations according to various style guides (MLA, >> Chicago, APA, etc.) automatically by displaying the content of various >> bibl/biblStruct/biblFull child elements in different orders. This is the >> born-digital case in the second paragraph: you're creating a new TEI >> document for which there's no print source to be represented. >> >> If you're doing (a), you basically have to use<bibl>. >> >> If you're doing (b), people are generally inclined to use biblStruct, but >> Martin argues in this document (and at the symposium in Dublin) that it's >> more practical to use bibl. As described in the first paragraph, he has >> found that citations to electronic works are often quite complicated in >> structure and that if you try to use biblStruct, it will be quite >> difficult to format according to the rules of MLA, Chicago, APA, etc. >> >> Martin, chime in if I got this wrong. >> > > That's exactly my point, expressed more clearly than I've managed to > express it so far myself. My worry is that we push people into using > <biblStruct> when <bibl> would actually be more suitable, simply because > of the weight of examples of <biblStruct> and the absence of any > encouragement to think about <bibl> as a more practical alternative. > > >>> 3. Use of persName inside biblStruct >>> >>> <!-- Name markup is essential for proper >>> indexing and other forms of processing. It >>> seems advisable that all biblStruct examples >>> use it, since the purpose of biblStruct is to >>> provide a highly-structured reference. --> >>> >>> While this may be true, it presents us with quite a problem in terms >>> of house style. Usually we try not to use elements from one module in >>> examples appearing in a chapter which describes another. In the few >>> rare exceptions, we make quite a song and dance about the need to >>> include the other module etc. But biblStruct and friends are >>> described in the core module, whereas the<persName> etc. elements >>> are described in names and dates. (That incidentally is why the<name> >>> element was originally used in some of these examples -- name is >>> available in the core). So, while I am perfectly to change some of the >>> examples to indicate what you propose as appropriate use of the >>> naming elements, I don't think it should be done uniformly. I fear >>> this needs more mulling over. >>> >> Yes indeed. In the summary of our proposal to Council, Martin, Laurent, >> and I asserted in principle 1 that if you use biblStruct, you really >> should use the Names and Dates module. Council agreed to this. If we >> don't change all of the examples to reflect this, it needs to be as clear >> as possible to readers why this is the case. >> > > This issue is similar to the one above: if we assume (and my experience > suggests this is true) that most users, at least in the early stages of > using TEI, will tend to copy-paste examples from the Guidelines and > adapt them, then we ought to avoid providing examples which will not > work very well for them in real projects. A <biblStruct> whose name > components are not marked up is not very useful for its intended purpose > -- automated processing and interchange. > > I'd suggest that we add a section on "Name encoding in bibliographical > references", fairly early in the chapter, to clarify this. Does that > make sense? > > Cheers, > Martin > > From laurent.romary at inria.fr Wed May 19 11:22:45 2010 From: laurent.romary at inria.fr (Laurent Romary) Date: Wed, 19 May 2010 17:22:45 +0200 Subject: [tei-council] bibliog doc In-Reply-To: <4BF4003A.9090309@oucs.ox.ac.uk> References: <4BEC693C.1060102@oucs.ox.ac.uk> <4BEC7D6C.8040409@uvic.ca> <4BED1A03.2000405@oucs.ox.ac.uk> <4BED67F1.30301@uvic.ca> <46840.96.244.216.144.1274236301.squirrel@www.lishost.net> <4BF3FD87.3080807@uvic.ca> <4BF4003A.9090309@oucs.ox.ac.uk> Message-ID: <2B71898C-7823-4A30-89E4-AFEFA3AAC8B9@inria.fr> I would not necessarily slim down the core just on this issue. Let us wait until we have an master plan of a set of reduce-sized modules. SO let us wait a while... Laurent (from Malte) Le 19 mai 10 ? 17:14, Lou Burnard a ?crit : > Another suggestion, which probably wont make me any friends, might be > to hive biblStruct and biblFull off to a chapter of their own. We > might > even go so far as to take them out of the core and put them in their > very own module. Yes that would cause all existing ODDs using them to > crash and burn, but it would slim the core down a bit, which has long > been a desideratum. > > Martin Holmes wrote: >> Hi all, >> >>>> 2. I revised the additional material proposed for the end of >>>> section >>>> 3.? as follows: >>>> >>>> >>>> <p>The most commonly used elements in the model.biblLike class are >>>> <gi>biblStruct</gi> and<gi>bibl</gi>.<gi>biblStruct</gi> will >>>> usually be easier to process mechanically than<gi>bibl</gi> >>>> because >>>> its structure is more constrained and predictable. It is suited to >>>> situations in which the objective is to represent bibliographic >>>> information for machine processing directly by other >>>> systems or after conversion to some other bibliographic markup >>>> formats >>>> such as BibTeXML or MODS. Punctuation delimiting the components >>>> of a >>>> print citation is not permitted directly within a<gi>biblStruct</ >>>> gi> >>>> element; instead, the presence and order of child elements must >>>> be used to >>>> reconstruct the punctuation required by a particular style. >>>> <!--While<gi>biblStruct</gi> offers enough >>>> flexibility for encoding bibliographic references to simple print >>>> works, for many documents, especially electronic ones, it proves >>>> problematic.--> <!-- no problems presented --> >>>> </p> >>>> >>>> <p>By contrast,<gi>bibl</gi> allows for considerable flexibility >>>> in >>>> that it can include both delimiting punctuation and unmarked-up >>>> text; >>>> and its constituents can also be ordered in any way. This makes it >>>> suitable for marking up bibliographies in existing documents, >>>> where it >>>> is considered important to preserve the form of references in the >>>> original document, while also distinguishing important pieces of >>>> information such as authors, dates, publishers, and so >>>> on.<gi>bibl</gi> may also be useful when encoding<soCalled>born >>>> digital</soCalled> documents which require use of a specific style >>>> guide when rendering the content<!-- why is this true of born >>>> digital >>>> dox in particular? -->; its flexibility makes it easier to >>>> provide all >>>> the information for a reference in the exact sequence required by >>>> the >>>> target rendering, including any necessary punctuation and linking >>>> words, rather than using an XSLT stylesheet or similar to reorder >>>> and >>>> punctuate the data.<!-- tough if you later want it in a different >>>> form for another rendering engine of course --> </p> >>>> >>> Lou wants a clearer rationale here. >>> >>> Martin's done a good job of explaining his rationale, but let me try >>> stating this in different terms just in case it alleviates >>> confusion over >>> Martin's use of "electronic" documents and "born-digital" ones. >>> >>> I believe Martin envisions two approaches to encoding bibliographic >>> citations given in a source document: >>> >>> a) You want to represent the source document as it is, even if it >>> has >>> inconsistencies in it. >>> >>> b) You want to impose structure on the citations to catch errors >>> and allow >>> you to format the citations according to various style guides (MLA, >>> Chicago, APA, etc.) automatically by displaying the content of >>> various >>> bibl/biblStruct/biblFull child elements in different orders. This >>> is the >>> born-digital case in the second paragraph: you're creating a new TEI >>> document for which there's no print source to be represented. >>> >>> If you're doing (a), you basically have to use<bibl>. >>> >>> If you're doing (b), people are generally inclined to use >>> biblStruct, but >>> Martin argues in this document (and at the symposium in Dublin) >>> that it's >>> more practical to use bibl. As described in the first paragraph, >>> he has >>> found that citations to electronic works are often quite >>> complicated in >>> structure and that if you try to use biblStruct, it will be quite >>> difficult to format according to the rules of MLA, Chicago, APA, >>> etc. >>> >>> Martin, chime in if I got this wrong. >>> >> >> That's exactly my point, expressed more clearly than I've managed to >> express it so far myself. My worry is that we push people into using >> <biblStruct> when <bibl> would actually be more suitable, simply >> because >> of the weight of examples of <biblStruct> and the absence of any >> encouragement to think about <bibl> as a more practical alternative. >> >> >>>> 3. Use of persName inside biblStruct >>>> >>>> <!-- Name markup is essential for proper >>>> indexing and other forms of processing. It >>>> seems advisable that all biblStruct examples >>>> use it, since the purpose of biblStruct is to >>>> provide a highly-structured reference. --> >>>> >>>> While this may be true, it presents us with quite a problem in >>>> terms >>>> of house style. Usually we try not to use elements from one >>>> module in >>>> examples appearing in a chapter which describes another. In the few >>>> rare exceptions, we make quite a song and dance about the need to >>>> include the other module etc. But biblStruct and friends are >>>> described in the core module, whereas the<persName> etc. elements >>>> are described in names and dates. (That incidentally is why >>>> the<name> >>>> element was originally used in some of these examples -- name is >>>> available in the core). So, while I am perfectly to change some >>>> of the >>>> examples to indicate what you propose as appropriate use of the >>>> naming elements, I don't think it should be done uniformly. I fear >>>> this needs more mulling over. >>>> >>> Yes indeed. In the summary of our proposal to Council, Martin, >>> Laurent, >>> and I asserted in principle 1 that if you use biblStruct, you really >>> should use the Names and Dates module. Council agreed to this. >>> If we >>> don't change all of the examples to reflect this, it needs to be >>> as clear >>> as possible to readers why this is the case. >>> >> >> This issue is similar to the one above: if we assume (and my >> experience >> suggests this is true) that most users, at least in the early >> stages of >> using TEI, will tend to copy-paste examples from the Guidelines and >> adapt them, then we ought to avoid providing examples which will not >> work very well for them in real projects. A <biblStruct> whose name >> components are not marked up is not very useful for its intended >> purpose >> -- automated processing and interchange. >> >> I'd suggest that we add a section on "Name encoding in >> bibliographical >> references", fairly early in the chapter, to clarify this. Does that >> make sense? >> >> Cheers, >> Martin >> >> > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Laurent Romary INRIA & HUB-IDSL laurent.romary at inria.fr From mholmes at uvic.ca Wed May 19 11:49:23 2010 From: mholmes at uvic.ca (Martin Holmes) Date: Wed, 19 May 2010 08:49:23 -0700 Subject: [tei-council] bibliog doc In-Reply-To: <4BF4003A.9090309@oucs.ox.ac.uk> References: <4BEC693C.1060102@oucs.ox.ac.uk> <4BEC7D6C.8040409@uvic.ca> <4BED1A03.2000405@oucs.ox.ac.uk> <4BED67F1.30301@uvic.ca> <46840.96.244.216.144.1274236301.squirrel@www.lishost.net> <4BF3FD87.3080807@uvic.ca> <4BF4003A.9090309@oucs.ox.ac.uk> Message-ID: <4BF40883.6060004@uvic.ca> On 10-05-19 08:14 AM, Lou Burnard wrote: > Another suggestion, which probably wont make me any friends, might be > to hive biblStruct and biblFull off to a chapter of their own. We might > even go so far as to take them out of the core and put them in their > very own module. Yes that would cause all existing ODDs using them to > crash and burn, but it would slim the core down a bit, which has long > been a desideratum. I think it should be on the table for P6. But at this point, I think we've encouraged enough use of <biblStruct> that we'll annoy almost everybody if we move it in P5. On a slightly different topic: for P6, how about if the core was identical to TEI Tite (or Lite, or whatever)? In other words, what Tite needs goes in the core, and everything else is out? Cheers, Martin > > Martin Holmes wrote: >> Hi all, >> >>>> 2. I revised the additional material proposed for the end of section >>>> 3.? as follows: >>>> >>>> >>>> <p>The most commonly used elements in the model.biblLike class are >>>> <gi>biblStruct</gi> and<gi>bibl</gi>.<gi>biblStruct</gi> will >>>> usually be easier to process mechanically than<gi>bibl</gi> because >>>> its structure is more constrained and predictable. It is suited to >>>> situations in which the objective is to represent bibliographic >>>> information for machine processing directly by other >>>> systems or after conversion to some other bibliographic markup formats >>>> such as BibTeXML or MODS. Punctuation delimiting the components of a >>>> print citation is not permitted directly within a<gi>biblStruct</gi> >>>> element; instead, the presence and order of child elements must be used to >>>> reconstruct the punctuation required by a particular style. >>>> <!--While<gi>biblStruct</gi> offers enough >>>> flexibility for encoding bibliographic references to simple print >>>> works, for many documents, especially electronic ones, it proves >>>> problematic.--> <!-- no problems presented --> >>>> </p> >>>> >>>> <p>By contrast,<gi>bibl</gi> allows for considerable flexibility in >>>> that it can include both delimiting punctuation and unmarked-up text; >>>> and its constituents can also be ordered in any way. This makes it >>>> suitable for marking up bibliographies in existing documents, where it >>>> is considered important to preserve the form of references in the >>>> original document, while also distinguishing important pieces of >>>> information such as authors, dates, publishers, and so >>>> on.<gi>bibl</gi> may also be useful when encoding<soCalled>born >>>> digital</soCalled> documents which require use of a specific style >>>> guide when rendering the content<!-- why is this true of born digital >>>> dox in particular? -->; its flexibility makes it easier to provide all >>>> the information for a reference in the exact sequence required by the >>>> target rendering, including any necessary punctuation and linking >>>> words, rather than using an XSLT stylesheet or similar to reorder and >>>> punctuate the data.<!-- tough if you later want it in a different >>>> form for another rendering engine of course --> </p> >>>> >>> Lou wants a clearer rationale here. >>> >>> Martin's done a good job of explaining his rationale, but let me try >>> stating this in different terms just in case it alleviates confusion over >>> Martin's use of "electronic" documents and "born-digital" ones. >>> >>> I believe Martin envisions two approaches to encoding bibliographic >>> citations given in a source document: >>> >>> a) You want to represent the source document as it is, even if it has >>> inconsistencies in it. >>> >>> b) You want to impose structure on the citations to catch errors and allow >>> you to format the citations according to various style guides (MLA, >>> Chicago, APA, etc.) automatically by displaying the content of various >>> bibl/biblStruct/biblFull child elements in different orders. This is the >>> born-digital case in the second paragraph: you're creating a new TEI >>> document for which there's no print source to be represented. >>> >>> If you're doing (a), you basically have to use<bibl>. >>> >>> If you're doing (b), people are generally inclined to use biblStruct, but >>> Martin argues in this document (and at the symposium in Dublin) that it's >>> more practical to use bibl. As described in the first paragraph, he has >>> found that citations to electronic works are often quite complicated in >>> structure and that if you try to use biblStruct, it will be quite >>> difficult to format according to the rules of MLA, Chicago, APA, etc. >>> >>> Martin, chime in if I got this wrong. >>> >> >> That's exactly my point, expressed more clearly than I've managed to >> express it so far myself. My worry is that we push people into using >> <biblStruct> when<bibl> would actually be more suitable, simply because >> of the weight of examples of<biblStruct> and the absence of any >> encouragement to think about<bibl> as a more practical alternative. >> >> >>>> 3. Use of persName inside biblStruct >>>> >>>> <!-- Name markup is essential for proper >>>> indexing and other forms of processing. It >>>> seems advisable that all biblStruct examples >>>> use it, since the purpose of biblStruct is to >>>> provide a highly-structured reference. --> >>>> >>>> While this may be true, it presents us with quite a problem in terms >>>> of house style. Usually we try not to use elements from one module in >>>> examples appearing in a chapter which describes another. In the few >>>> rare exceptions, we make quite a song and dance about the need to >>>> include the other module etc. But biblStruct and friends are >>>> described in the core module, whereas the<persName> etc. elements >>>> are described in names and dates. (That incidentally is why the<name> >>>> element was originally used in some of these examples -- name is >>>> available in the core). So, while I am perfectly to change some of the >>>> examples to indicate what you propose as appropriate use of the >>>> naming elements, I don't think it should be done uniformly. I fear >>>> this needs more mulling over. >>>> >>> Yes indeed. In the summary of our proposal to Council, Martin, Laurent, >>> and I asserted in principle 1 that if you use biblStruct, you really >>> should use the Names and Dates module. Council agreed to this. If we >>> don't change all of the examples to reflect this, it needs to be as clear >>> as possible to readers why this is the case. >>> >> >> This issue is similar to the one above: if we assume (and my experience >> suggests this is true) that most users, at least in the early stages of >> using TEI, will tend to copy-paste examples from the Guidelines and >> adapt them, then we ought to avoid providing examples which will not >> work very well for them in real projects. A<biblStruct> whose name >> components are not marked up is not very useful for its intended purpose >> -- automated processing and interchange. >> >> I'd suggest that we add a section on "Name encoding in bibliographical >> references", fairly early in the chapter, to clarify this. Does that >> make sense? >> >> Cheers, >> Martin >> >> > > . > -- Martin Holmes University of Victoria Humanities Computing and Media Centre (mholmes at uvic.ca) Half-Baked Software, Inc. (mholmes at halfbakedsoftware.com) martin at mholmes.com From daniel.odonnell at uleth.ca Wed May 19 13:54:58 2010 From: daniel.odonnell at uleth.ca (O'Donnell, Dan) Date: Wed, 19 May 2010 11:54:58 -0600 Subject: [tei-council] bibliog doc In-Reply-To: <2B71898C-7823-4A30-89E4-AFEFA3AAC8B9@inria.fr> References: <4BEC693C.1060102@oucs.ox.ac.uk> <4BEC7D6C.8040409@uvic.ca> <4BED1A03.2000405@oucs.ox.ac.uk> <4BED67F1.30301@uvic.ca> <46840.96.244.216.144.1274236301.squirrel@www.lishost.net> <4BF3FD87.3080807@uvic.ca> <4BF4003A.9090309@oucs.ox.ac.uk> <2B71898C-7823-4A30-89E4-AFEFA3AAC8B9@inria.fr> Message-ID: <4BF425F2.9030506@uleth.ca> I think that is P5.2 or P6 talk. I like the idea, and that is starting to come up enough that (shudder) we may need to start thinking of what might go in P6. But I think it would be a major issue for p5 users. The other possibility (but not now, I think) is to go with an idea like the W3C's xhtml strict and transitional system. On 10-05-19 09:22 AM, Laurent Romary wrote: > I would not necessarily slim down the core just on this issue. Let us > wait until we have an master plan of a set of reduce-sized modules. SO > let us wait a while... > Laurent (from Malte) > > > Le 19 mai 10 ? 17:14, Lou Burnard a ?crit : > > >> Another suggestion, which probably wont make me any friends, might be >> to hive biblStruct and biblFull off to a chapter of their own. We >> might >> even go so far as to take them out of the core and put them in their >> very own module. Yes that would cause all existing ODDs using them to >> crash and burn, but it would slim the core down a bit, which has long >> been a desideratum. >> >> Martin Holmes wrote: >> >>> Hi all, >>> >>> >>>>> 2. I revised the additional material proposed for the end of >>>>> section >>>>> 3.? as follows: >>>>> >>>>> >>>>> <p>The most commonly used elements in the model.biblLike class are >>>>> <gi>biblStruct</gi> and<gi>bibl</gi>.<gi>biblStruct</gi> will >>>>> usually be easier to process mechanically than<gi>bibl</gi> >>>>> because >>>>> its structure is more constrained and predictable. It is suited to >>>>> situations in which the objective is to represent bibliographic >>>>> information for machine processing directly by other >>>>> systems or after conversion to some other bibliographic markup >>>>> formats >>>>> such as BibTeXML or MODS. Punctuation delimiting the components >>>>> of a >>>>> print citation is not permitted directly within a<gi>biblStruct</ >>>>> gi> >>>>> element; instead, the presence and order of child elements must >>>>> be used to >>>>> reconstruct the punctuation required by a particular style. >>>>> <!--While<gi>biblStruct</gi> offers enough >>>>> flexibility for encoding bibliographic references to simple print >>>>> works, for many documents, especially electronic ones, it proves >>>>> problematic.--> <!-- no problems presented --> >>>>> </p> >>>>> >>>>> <p>By contrast,<gi>bibl</gi> allows for considerable flexibility >>>>> in >>>>> that it can include both delimiting punctuation and unmarked-up >>>>> text; >>>>> and its constituents can also be ordered in any way. This makes it >>>>> suitable for marking up bibliographies in existing documents, >>>>> where it >>>>> is considered important to preserve the form of references in the >>>>> original document, while also distinguishing important pieces of >>>>> information such as authors, dates, publishers, and so >>>>> on.<gi>bibl</gi> may also be useful when encoding<soCalled>born >>>>> digital</soCalled> documents which require use of a specific style >>>>> guide when rendering the content<!-- why is this true of born >>>>> digital >>>>> dox in particular? -->; its flexibility makes it easier to >>>>> provide all >>>>> the information for a reference in the exact sequence required by >>>>> the >>>>> target rendering, including any necessary punctuation and linking >>>>> words, rather than using an XSLT stylesheet or similar to reorder >>>>> and >>>>> punctuate the data.<!-- tough if you later want it in a different >>>>> form for another rendering engine of course --> </p> >>>>> >>>>> >>>> Lou wants a clearer rationale here. >>>> >>>> Martin's done a good job of explaining his rationale, but let me try >>>> stating this in different terms just in case it alleviates >>>> confusion over >>>> Martin's use of "electronic" documents and "born-digital" ones. >>>> >>>> I believe Martin envisions two approaches to encoding bibliographic >>>> citations given in a source document: >>>> >>>> a) You want to represent the source document as it is, even if it >>>> has >>>> inconsistencies in it. >>>> >>>> b) You want to impose structure on the citations to catch errors >>>> and allow >>>> you to format the citations according to various style guides (MLA, >>>> Chicago, APA, etc.) automatically by displaying the content of >>>> various >>>> bibl/biblStruct/biblFull child elements in different orders. This >>>> is the >>>> born-digital case in the second paragraph: you're creating a new TEI >>>> document for which there's no print source to be represented. >>>> >>>> If you're doing (a), you basically have to use<bibl>. >>>> >>>> If you're doing (b), people are generally inclined to use >>>> biblStruct, but >>>> Martin argues in this document (and at the symposium in Dublin) >>>> that it's >>>> more practical to use bibl. As described in the first paragraph, >>>> he has >>>> found that citations to electronic works are often quite >>>> complicated in >>>> structure and that if you try to use biblStruct, it will be quite >>>> difficult to format according to the rules of MLA, Chicago, APA, >>>> etc. >>>> >>>> Martin, chime in if I got this wrong. >>>> >>>> >>> That's exactly my point, expressed more clearly than I've managed to >>> express it so far myself. My worry is that we push people into using >>> <biblStruct> when<bibl> would actually be more suitable, simply >>> because >>> of the weight of examples of<biblStruct> and the absence of any >>> encouragement to think about<bibl> as a more practical alternative. >>> >>> >>> >>>>> 3. Use of persName inside biblStruct >>>>> >>>>> <!-- Name markup is essential for proper >>>>> indexing and other forms of processing. It >>>>> seems advisable that all biblStruct examples >>>>> use it, since the purpose of biblStruct is to >>>>> provide a highly-structured reference. --> >>>>> >>>>> While this may be true, it presents us with quite a problem in >>>>> terms >>>>> of house style. Usually we try not to use elements from one >>>>> module in >>>>> examples appearing in a chapter which describes another. In the few >>>>> rare exceptions, we make quite a song and dance about the need to >>>>> include the other module etc. But biblStruct and friends are >>>>> described in the core module, whereas the<persName> etc. elements >>>>> are described in names and dates. (That incidentally is why >>>>> the<name> >>>>> element was originally used in some of these examples -- name is >>>>> available in the core). So, while I am perfectly to change some >>>>> of the >>>>> examples to indicate what you propose as appropriate use of the >>>>> naming elements, I don't think it should be done uniformly. I fear >>>>> this needs more mulling over. >>>>> >>>>> >>>> Yes indeed. In the summary of our proposal to Council, Martin, >>>> Laurent, >>>> and I asserted in principle 1 that if you use biblStruct, you really >>>> should use the Names and Dates module. Council agreed to this. >>>> If we >>>> don't change all of the examples to reflect this, it needs to be >>>> as clear >>>> as possible to readers why this is the case. >>>> >>>> >>> This issue is similar to the one above: if we assume (and my >>> experience >>> suggests this is true) that most users, at least in the early >>> stages of >>> using TEI, will tend to copy-paste examples from the Guidelines and >>> adapt them, then we ought to avoid providing examples which will not >>> work very well for them in real projects. A<biblStruct> whose name >>> components are not marked up is not very useful for its intended >>> purpose >>> -- automated processing and interchange. >>> >>> I'd suggest that we add a section on "Name encoding in >>> bibliographical >>> references", fairly early in the chapter, to clarify this. Does that >>> make sense? >>> >>> Cheers, >>> Martin >>> >>> >>> >> _______________________________________________ >> tei-council mailing list >> tei-council at lists.village.Virginia.EDU >> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council >> > Laurent Romary > INRIA& HUB-IDSL > laurent.romary at inria.fr > > > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > -- Daniel Paul O'Donnell Professor of English University of Lethbridge Chair and CEO, Text Encoding Initiative (http://www.tei-c.org/) Co-Chair, Digital Initiatives Advisory Board, Medieval Academy of America President-elect (English), Society for Digital Humanities/Soci?t? pour l'?tude des m?dias interactifs (http://sdh-semi.org/) Founding Director (2003-2009), Digital Medievalist Project (http://www.digitalmedievalist.org/) Vox: +1 403 329-2377 Fax: +1 403 382-7191 (non-confidential) Home Page: http://people.uleth.ca/~daniel.odonnell/ From daniel.odonnell at uleth.ca Wed May 19 13:57:35 2010 From: daniel.odonnell at uleth.ca (O'Donnell, Dan) Date: Wed, 19 May 2010 11:57:35 -0600 Subject: [tei-council] bibliog doc In-Reply-To: <4BF3FD87.3080807@uvic.ca> References: <4BEC693C.1060102@oucs.ox.ac.uk> <4BEC7D6C.8040409@uvic.ca> <4BED1A03.2000405@oucs.ox.ac.uk> <4BED67F1.30301@uvic.ca> <46840.96.244.216.144.1274236301.squirrel@www.lishost.net> <4BF3FD87.3080807@uvic.ca> Message-ID: <4BF4268F.10003@uleth.ca> Hi Martin, My only problem with this is using the examples to sneak in what is in essence an argument for preferred or preferred vs. deprecated status (and didn't we decide that in the case of bibliographic stuff, we couldn't deprecate anyway, because the source material simply might not allow our non-deprecated methods?). Really, if we mean something is preferred, we should say so explicitly. If we don't mean it, then we really need examples for various ways of doing things: we can't just think of new or standard users of the Guidelines, IMO. On 10-05-19 09:02 AM, Martin Holmes wrote: > Hi all, > >>> 2. I revised the additional material proposed for the end of section >>> 3.? as follows: >>> >>> >>> <p>The most commonly used elements in the model.biblLike class are >>> <gi>biblStruct</gi> and<gi>bibl</gi>.<gi>biblStruct</gi> will >>> usually be easier to process mechanically than<gi>bibl</gi> because >>> its structure is more constrained and predictable. It is suited to >>> situations in which the objective is to represent bibliographic >>> information for machine processing directly by other >>> systems or after conversion to some other bibliographic markup formats >>> such as BibTeXML or MODS. Punctuation delimiting the components of a >>> print citation is not permitted directly within a<gi>biblStruct</gi> >>> element; instead, the presence and order of child elements must be used to >>> reconstruct the punctuation required by a particular style. >>> <!--While<gi>biblStruct</gi> offers enough >>> flexibility for encoding bibliographic references to simple print >>> works, for many documents, especially electronic ones, it proves >>> problematic.--> <!-- no problems presented --> >>> </p> >>> >>> <p>By contrast,<gi>bibl</gi> allows for considerable flexibility in >>> that it can include both delimiting punctuation and unmarked-up text; >>> and its constituents can also be ordered in any way. This makes it >>> suitable for marking up bibliographies in existing documents, where it >>> is considered important to preserve the form of references in the >>> original document, while also distinguishing important pieces of >>> information such as authors, dates, publishers, and so >>> on.<gi>bibl</gi> may also be useful when encoding<soCalled>born >>> digital</soCalled> documents which require use of a specific style >>> guide when rendering the content<!-- why is this true of born digital >>> dox in particular? -->; its flexibility makes it easier to provide all >>> the information for a reference in the exact sequence required by the >>> target rendering, including any necessary punctuation and linking >>> words, rather than using an XSLT stylesheet or similar to reorder and >>> punctuate the data.<!-- tough if you later want it in a different >>> form for another rendering engine of course --> </p> >>> >> Lou wants a clearer rationale here. >> >> Martin's done a good job of explaining his rationale, but let me try >> stating this in different terms just in case it alleviates confusion over >> Martin's use of "electronic" documents and "born-digital" ones. >> >> I believe Martin envisions two approaches to encoding bibliographic >> citations given in a source document: >> >> a) You want to represent the source document as it is, even if it has >> inconsistencies in it. >> >> b) You want to impose structure on the citations to catch errors and allow >> you to format the citations according to various style guides (MLA, >> Chicago, APA, etc.) automatically by displaying the content of various >> bibl/biblStruct/biblFull child elements in different orders. This is the >> born-digital case in the second paragraph: you're creating a new TEI >> document for which there's no print source to be represented. >> >> If you're doing (a), you basically have to use<bibl>. >> >> If you're doing (b), people are generally inclined to use biblStruct, but >> Martin argues in this document (and at the symposium in Dublin) that it's >> more practical to use bibl. As described in the first paragraph, he has >> found that citations to electronic works are often quite complicated in >> structure and that if you try to use biblStruct, it will be quite >> difficult to format according to the rules of MLA, Chicago, APA, etc. >> >> Martin, chime in if I got this wrong. >> > That's exactly my point, expressed more clearly than I've managed to > express it so far myself. My worry is that we push people into using > <biblStruct> when<bibl> would actually be more suitable, simply because > of the weight of examples of<biblStruct> and the absence of any > encouragement to think about<bibl> as a more practical alternative. > > >>> 3. Use of persName inside biblStruct >>> >>> <!-- Name markup is essential for proper >>> indexing and other forms of processing. It >>> seems advisable that all biblStruct examples >>> use it, since the purpose of biblStruct is to >>> provide a highly-structured reference. --> >>> >>> While this may be true, it presents us with quite a problem in terms >>> of house style. Usually we try not to use elements from one module in >>> examples appearing in a chapter which describes another. In the few >>> rare exceptions, we make quite a song and dance about the need to >>> include the other module etc. But biblStruct and friends are >>> described in the core module, whereas the<persName> etc. elements >>> are described in names and dates. (That incidentally is why the<name> >>> element was originally used in some of these examples -- name is >>> available in the core). So, while I am perfectly to change some of the >>> examples to indicate what you propose as appropriate use of the >>> naming elements, I don't think it should be done uniformly. I fear >>> this needs more mulling over. >>> >> Yes indeed. In the summary of our proposal to Council, Martin, Laurent, >> and I asserted in principle 1 that if you use biblStruct, you really >> should use the Names and Dates module. Council agreed to this. If we >> don't change all of the examples to reflect this, it needs to be as clear >> as possible to readers why this is the case. >> > This issue is similar to the one above: if we assume (and my experience > suggests this is true) that most users, at least in the early stages of > using TEI, will tend to copy-paste examples from the Guidelines and > adapt them, then we ought to avoid providing examples which will not > work very well for them in real projects. A<biblStruct> whose name > components are not marked up is not very useful for its intended purpose > -- automated processing and interchange. > > I'd suggest that we add a section on "Name encoding in bibliographical > references", fairly early in the chapter, to clarify this. Does that > make sense? > > Cheers, > Martin > > -- Daniel Paul O'Donnell Professor of English University of Lethbridge Chair and CEO, Text Encoding Initiative (http://www.tei-c.org/) Co-Chair, Digital Initiatives Advisory Board, Medieval Academy of America President-elect (English), Society for Digital Humanities/Soci?t? pour l'?tude des m?dias interactifs (http://sdh-semi.org/) Founding Director (2003-2009), Digital Medievalist Project (http://www.digitalmedievalist.org/) Vox: +1 403 329-2377 Fax: +1 403 382-7191 (non-confidential) Home Page: http://people.uleth.ca/~daniel.odonnell/ From kevin.s.hawkins at ultraslavonic.info Wed May 19 15:26:30 2010 From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins) Date: Wed, 19 May 2010 15:26:30 -0400 (EDT) Subject: [tei-council] bibliog doc In-Reply-To: <4BF4268F.10003@uleth.ca> References: <4BEC693C.1060102@oucs.ox.ac.uk> <4BEC7D6C.8040409@uvic.ca> <4BED1A03.2000405@oucs.ox.ac.uk> <4BED67F1.30301@uvic.ca> <46840.96.244.216.144.1274236301.squirrel@www.lishost.net> <4BF3FD87.3080807@uvic.ca> <4BF4268F.10003@uleth.ca> Message-ID: <1452.96.244.216.144.1274297190.squirrel@www.lishost.net> The proposal we presented to Council makes exactly such an argument for preferring bibl over biblStruct not only in the examples but also in the prose. In fact, it is the part of the prose making this argument which Lou is taking issue with. I believe he objects because we make the assertions in the brief introduction without immediately giving evidence. Martin and I have now summarized the argument a few ways by email, and I believe the proposed revisions to P5 also gives some of the rationale further down in the prose. Lou, are you able to rework the assertions to include the evidence that Martin and I have attempted to give? > Hi Martin, > > My only problem with this is using the examples to sneak in what is in > essence an argument for preferred or preferred vs. deprecated status > (and didn't we decide that in the case of bibliographic stuff, we > couldn't deprecate anyway, because the source material simply might not > allow our non-deprecated methods?). Really, if we mean something is > preferred, we should say so explicitly. If we don't mean it, then we > really need examples for various ways of doing things: we can't just > think of new or standard users of the Guidelines, IMO. > > On 10-05-19 09:02 AM, Martin Holmes wrote: >> Hi all, >> >>>> 2. I revised the additional material proposed for the end of section >>>> 3.? as follows: >>>> >>>> >>>> <p>The most commonly used elements in the model.biblLike class are >>>> <gi>biblStruct</gi> and<gi>bibl</gi>.<gi>biblStruct</gi> will >>>> usually be easier to process mechanically than<gi>bibl</gi> because >>>> its structure is more constrained and predictable. It is suited to >>>> situations in which the objective is to represent bibliographic >>>> information for machine processing directly by other >>>> systems or after conversion to some other bibliographic markup formats >>>> such as BibTeXML or MODS. Punctuation delimiting the components of a >>>> print citation is not permitted directly within a<gi>biblStruct</gi> >>>> element; instead, the presence and order of child elements must be >>>> used to >>>> reconstruct the punctuation required by a particular style. >>>> <!--While<gi>biblStruct</gi> offers enough >>>> flexibility for encoding bibliographic references to simple print >>>> works, for many documents, especially electronic ones, it proves >>>> problematic.--> <!-- no problems presented --> >>>> </p> >>>> >>>> <p>By contrast,<gi>bibl</gi> allows for considerable flexibility in >>>> that it can include both delimiting punctuation and unmarked-up text; >>>> and its constituents can also be ordered in any way. This makes it >>>> suitable for marking up bibliographies in existing documents, where it >>>> is considered important to preserve the form of references in the >>>> original document, while also distinguishing important pieces of >>>> information such as authors, dates, publishers, and so >>>> on.<gi>bibl</gi> may also be useful when encoding<soCalled>born >>>> digital</soCalled> documents which require use of a specific style >>>> guide when rendering the content<!-- why is this true of born digital >>>> dox in particular? -->; its flexibility makes it easier to provide all >>>> the information for a reference in the exact sequence required by the >>>> target rendering, including any necessary punctuation and linking >>>> words, rather than using an XSLT stylesheet or similar to reorder and >>>> punctuate the data.<!-- tough if you later want it in a different >>>> form for another rendering engine of course --> </p> >>>> >>> Lou wants a clearer rationale here. >>> >>> Martin's done a good job of explaining his rationale, but let me try >>> stating this in different terms just in case it alleviates confusion >>> over >>> Martin's use of "electronic" documents and "born-digital" ones. >>> >>> I believe Martin envisions two approaches to encoding bibliographic >>> citations given in a source document: >>> >>> a) You want to represent the source document as it is, even if it has >>> inconsistencies in it. >>> >>> b) You want to impose structure on the citations to catch errors and >>> allow >>> you to format the citations according to various style guides (MLA, >>> Chicago, APA, etc.) automatically by displaying the content of various >>> bibl/biblStruct/biblFull child elements in different orders. This is >>> the >>> born-digital case in the second paragraph: you're creating a new TEI >>> document for which there's no print source to be represented. >>> >>> If you're doing (a), you basically have to use<bibl>. >>> >>> If you're doing (b), people are generally inclined to use biblStruct, >>> but >>> Martin argues in this document (and at the symposium in Dublin) that >>> it's >>> more practical to use bibl. As described in the first paragraph, he >>> has >>> found that citations to electronic works are often quite complicated in >>> structure and that if you try to use biblStruct, it will be quite >>> difficult to format according to the rules of MLA, Chicago, APA, etc. >>> >>> Martin, chime in if I got this wrong. >>> >> That's exactly my point, expressed more clearly than I've managed to >> express it so far myself. My worry is that we push people into using >> <biblStruct> when<bibl> would actually be more suitable, simply >> because >> of the weight of examples of<biblStruct> and the absence of any >> encouragement to think about<bibl> as a more practical alternative. >> >> >>>> 3. Use of persName inside biblStruct >>>> >>>> <!-- Name markup is essential for proper >>>> indexing and other forms of processing. It >>>> seems advisable that all biblStruct examples >>>> use it, since the purpose of biblStruct is to >>>> provide a highly-structured reference. --> >>>> >>>> While this may be true, it presents us with quite a problem in terms >>>> of house style. Usually we try not to use elements from one module in >>>> examples appearing in a chapter which describes another. In the few >>>> rare exceptions, we make quite a song and dance about the need to >>>> include the other module etc. But biblStruct and friends are >>>> described in the core module, whereas the<persName> etc. elements >>>> are described in names and dates. (That incidentally is why the<name> >>>> element was originally used in some of these examples -- name is >>>> available in the core). So, while I am perfectly to change some of the >>>> examples to indicate what you propose as appropriate use of the >>>> naming elements, I don't think it should be done uniformly. I fear >>>> this needs more mulling over. >>>> >>> Yes indeed. In the summary of our proposal to Council, Martin, >>> Laurent, >>> and I asserted in principle 1 that if you use biblStruct, you really >>> should use the Names and Dates module. Council agreed to this. If we >>> don't change all of the examples to reflect this, it needs to be as >>> clear >>> as possible to readers why this is the case. >>> >> This issue is similar to the one above: if we assume (and my experience >> suggests this is true) that most users, at least in the early stages of >> using TEI, will tend to copy-paste examples from the Guidelines and >> adapt them, then we ought to avoid providing examples which will not >> work very well for them in real projects. A<biblStruct> whose name >> components are not marked up is not very useful for its intended purpose >> -- automated processing and interchange. >> >> I'd suggest that we add a section on "Name encoding in bibliographical >> references", fairly early in the chapter, to clarify this. Does that >> make sense? >> >> Cheers, >> Martin >> >> > > -- > Daniel Paul O'Donnell > Professor of English > University of Lethbridge > > Chair and CEO, Text Encoding Initiative (http://www.tei-c.org/) > Co-Chair, Digital Initiatives Advisory Board, Medieval Academy of America > President-elect (English), Society for Digital Humanities/Soci??t?? pour > l'??tude des m??dias interactifs (http://sdh-semi.org/) > Founding Director (2003-2009), Digital Medievalist Project > (http://www.digitalmedievalist.org/) > > Vox: +1 403 329-2377 > Fax: +1 403 382-7191 (non-confidential) > Home Page: http://people.uleth.ca/~daniel.odonnell/ > > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > From kevin.s.hawkins at ultraslavonic.info Fri May 21 00:06:43 2010 From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins) Date: Fri, 21 May 2010 00:06:43 -0400 Subject: [tei-council] soft hyphens (again) Message-ID: <4BF606D3.7050603@ultraslavonic.info> I would like to rework the section of the *Best Practices for TEI in Libraries* dealing with hyphenation ( http://wiki.tei-c.org/index.php/Best_Practices_for_TEI_in_Libraries#Hyphenation ) to take into account our verdict in Dublin for how to handle the "soft hyphen" problem. Looking at my notes from Dublin: http://wiki.tei-c.org/index.php/Draft_minutes_of_2010-04_Council_meeting#hyphenation it seems we were actually a little vague on the mechanics of the proposed encoding. At first we said we would use lb at type to indicate whether a lexical unit was broken by the hyphen and not leave a hyphen character in the data. That is, you might have something like: * <lb type="lexicalboundary" rend="-"/> for a hyphen at the end of a line where a hyphen would appear in any case, such as: This is not a run- on sentence. * <lb type="nolexicalboundary" rend="-"/> for a hyphen at the end of a line where a hyphen would not appear had there not been a line break there, such as: UTF-8 is a char- acter encoding for Unicode. * <lb type="uncertainlexicalboundary" rend="-"/> for a case where you're not sure which of the two above it should be, such as: Some people say TEI is a mark- up language. We did not agree on values for @type, so I just made up these three. However, we later discussed values of @rend which could be used for cases of type="uncertainlexicalboundary". As in the minutes, we agreed that you might use any of the following: a) - b) hyphen c) soft or hard hyphen d) ambiguous While (a) and (b) are effectively equivalent and could be used with any of the three @type values, (c) and (d) only make sense with type="uncertainlexicalboundary". However, it seems to me that if @type is used, there's no need for different values of @rend since there's no point in being redundant in our declaration of uncertainty. Perhaps I misunderstood the discussion, or perhaps Lou has unilaterally resolved these quesions in revisions he might have made in SourceForge already. But for clarify, let me post the following questions: 1) Is everyone okay with using @type instead of @rend to distinguish these cases? They are, after all, all rendered the same. 2) Can we come up with better values for @type than lexicalboundary nolexicalboundary uncertainlexicalboundary ? They're a bit unwieldy. --Kevin From bbarney2 at unlnotes.unl.edu Fri May 21 14:25:33 2010 From: bbarney2 at unlnotes.unl.edu (Brett Barney) Date: Fri, 21 May 2010 13:25:33 -0500 Subject: [tei-council] full minutes now on wiki Message-ID: <OF32AD95EC.84054331-ON8625772A.0064F67A-8625772A.006537D3@unl.edu> All, Tardily, I've added my portions of the minutes (4/29 a.m. and 4/30 p.m.) to the wiki. The notes covering the final session are especially sketchy, as I've not spent much time expanding things into full sentences, etc. If you have a hankering, therefore, please correct and supplement. Best regards, Brett From lou.burnard at oucs.ox.ac.uk Sun May 23 17:49:54 2010 From: lou.burnard at oucs.ox.ac.uk (Lou Burnard) Date: Sun, 23 May 2010 22:49:54 +0100 Subject: [tei-council] soft hyphens (again) In-Reply-To: <4BF606D3.7050603@ultraslavonic.info> References: <4BF606D3.7050603@ultraslavonic.info> Message-ID: <4BF9A302.1030108@oucs.ox.ac.uk> Hi Kevin! Although largely complete, I think the record of our Dublin discussion of this topic leaves out a few critical details. It also talks repeatedly about hyphenation as the problem, whereas the real problem is just hyphenation at the end of a line, in the specific case where you are also encoding the ends of lines. The discussion moved on to talk about the related problems caused by strange practices in other languages when words are broken across ends of lines -- involving not only hyphenation, but also changes in orthography. The recommendation made (which doesnt appear in your notes) was to use <choice> for these more complex cases, which is what led to the comment about where to put the <lb> if you didnt want to repeat it. I don't recall Brett's comment about a "standoff choice" and am not sure what that would look like. On the question you raise about values for @type, there is already a (carefully worded) recommendation in the Guidelines: "The type attribute may be used to characterize the line break in any respect, but its most common use is to specify that the presence of the line break does not imply the end of the word in which it is embedded. A value such as inWord or nobreak is recommended for this purpose, but encoders are free to choose whichever values are appropriate. " (I say "carefully worded" because quite a lot of virtual ink was spilled on the topic over on the Epidoc list some time back) If we are using @type to characterise the linebreak from a tokenization point of view, there really can be only three possible states: "inWord" (i.e. the tokeniser needs to combine the string before the linebreak with the string after it to form a single token) "betweenWords" (i.e. the string before the linebreak and the string after it are two separate tokens) and "uncertain" (i.e. it could be either of the other two and we're unwilling or unable to decide). If we use @rend on linebreak at all it can only be to say something about how the linebreak was or should be rendered. It's by no means certain that an <lb type="inWord"/> will always be rendered by means of a hyphen (hard or soft) and a linebreak: it might be some other character, or it might be nothing at all. Furthermore, some encoders will prefer to retain the hyphen as a character in the text while others will prefer to discard it and have it be generated by rendering software. (Similar case for <q> and quote marks) When the topic was discussed on TEI-L I both options were strongly advocated -- those who care about this topic really do care about it. Does this help? best wishes Lou From kevin.s.hawkins at ultraslavonic.info Sun Jun 6 12:35:18 2010 From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins) Date: Sun, 06 Jun 2010 12:35:18 -0400 Subject: [tei-council] soft hyphens (again) In-Reply-To: <4BF9A302.1030108@oucs.ox.ac.uk> References: <4BF606D3.7050603@ultraslavonic.info> <4BF9A302.1030108@oucs.ox.ac.uk> Message-ID: <4C0BCE46.1080008@ultraslavonic.info> Hello Lou and Fellow Council Members, Apologies for the delay in responding. An early summer vacation and transitioning back to Michigan from Dublin has left me weeks behind in email. On 5/23/2010 5:49 PM, Lou Burnard wrote: > Hi Kevin! > > Although largely complete, I think the record of our Dublin discussion > of this topic leaves out a few critical details. It also talks > repeatedly about hyphenation as the problem, whereas the real problem is > just hyphenation at the end of a line, in the specific case where you > are also encoding the ends of lines. The discussion moved on to talk > about the related problems caused by strange practices in other > languages when words are broken across ends of lines -- involving not > only hyphenation, but also changes in orthography. The recommendation > made (which doesnt appear in your notes) was to use<choice> for these > more complex cases, which is what led to the comment about where to put > the<lb> if you didnt want to repeat it. I don't recall Brett's comment > about a "standoff choice" and am not sure what that would look like. Lou and the rest of you should embellish and correct my minutes. Please! This was the whole idea of doing them in the wiki. I've tried to address Lou's complaints, but please double-check my work. > On the question you raise about values for @type, there is already a > (carefully worded) recommendation in the Guidelines: "The type attribute > may be used to characterize the line break in any respect, but its most > common use is to specify that the presence of the line break does not > imply the end of the word in which it is embedded. A value such as > inWord or nobreak is recommended for this purpose, but encoders are free > to choose whichever values are appropriate. " > > (I say "carefully worded" because quite a lot of virtual ink was spilled > on the topic over on the Epidoc list some time back) Ah yes, I had not seen this. > If we are using @type to characterise the linebreak from a tokenization > point of view, there really can be only three possible states: "inWord" > (i.e. the tokeniser needs to combine the string before the linebreak > with the string after it to form a single token) "betweenWords" (i.e. > the string before the linebreak and the string after it are two separate > tokens) and "uncertain" (i.e. it could be either of the other two and > we're unwilling or unable to decide). Agreed. > If we use @rend on linebreak at all it can only be to say something > about how the linebreak was or should be rendered. It's by no means > certain that an<lb type="inWord"/> will always be rendered by means of > a hyphen (hard or soft) and a linebreak: it might be some other > character, or it might be nothing at all. Furthermore, some encoders > will prefer to retain the hyphen as a character in the text while others > will prefer to discard it and have it be generated by rendering > software. (Similar case for<q> and quote marks) When the topic was > discussed on TEI-L I both options were strongly advocated -- those who > care about this topic really do care about it. > > Does this help? Yes! Kevin From laurent.romary at loria.fr Tue Jun 8 03:44:46 2010 From: laurent.romary at loria.fr (Laurent Romary) Date: Tue, 8 Jun 2010 09:44:46 +0200 Subject: [tei-council] Fwd: Using CALS within the TEI framework References: <CF7FD45F-8D90-4975-8727-9BD8EC80A6F5@oasis-open.org> Message-ID: <68FEC127-1074-4F69-9793-5159837F4DA5@loria.fr> Dear all, After several searches and mail exchanges, I think we have a clear answer concerning the freedom to integrate CALS in the TEI framework. What I read below seems to cover our wish to provide an ODD exemplum with CALS. Best wishes, Laurent D?but du message r?exp?di? : > De : Mary McRae <mary.mcrae at oasis-open.org> > Date : 8 juin 2010 01:48:42 GMT+02:00 > ? : Laurent Romary <laurent.romary at loria.fr> > Objet : R?p : Using CALS within the TEI framework > > Hello Laurent, > > Sorry for the delay in getting back to you; I wanted to make sure I > gave you the correct information since this work was created prior > to our current IPR Policy. > > OASIS does not often exclusively transfer its rights in a published > work, or the right to maintain or revise it, to other organizations. > However, our current IPR Policy at http://www.oasis-open.org/who/intellectualproperty.php > sets the usage terms for our specifications, which includes a > blanket permission to all parties to implement, derive from and > extend our specifications, so long as: > (a) they do not use our name for it, > (b) they do not misrepresent it as ours or authorized by us, and > (c) they include our mandated copyright notices, near or after their > own, along the following lines: > > ' Portions (c) OASIS Open [year]. All rights reserved. [And so > on, with some mandated exculpatory language.] ' > > The Exchange Table models in question predated our current IPR > Policy, so the licensing/disclosure terms of our policy did not > apply to it. However, the current Section 14 generally reflects our > intent to permit re-uses, so long as the manner of re-use does not > create confusion as to approvals or sources. Our expectation is > that this permission to derive from the tables would be sufficient > for your plans; and that those plans are not confidential. > > If you plan on creating a derivation or extension, please keep me > posted as I can note it on the TC's public home page as well as > notify some of the original participants who may be interested. > > Please let me know if I can be of any further assistance. > > Best regards, > > Mary P McRae > Director, Standards Development > Technical Committee Administrator > OASIS: Advancing open standards for the information society > email: mary.mcrae at oasis-open.org > web: www.oasis-open.org > twitter: @fiberartisan #oasisopen > phone: 1.603.232.9090 > > Standards are like parachutes: they work best when they're open. > > > > On May 15, 2010, at 1:53 PM, Laurent Romary wrote: > >> Hi Carol, >> Thanks for your feedback. I was actually referring to the Exchange >> Table Model. Is this one actually maintained within Oasis now, and/ >> or can the TEI consortium maintained the corresponding ODD >> specification and associated support? >> Best regards, >> Laurent >> >> Le 14 mai 10 ? 21:06, Carol Geyer a ?crit : >> >>> Mr. Romary, >>> I'm afraid the CALS table model has never been maintained at OASIS. >>> >>> The Exchange Table Model, a cross-vendor modification to the CALS >>> Table >>> model was created and approved by OASIS several years ago (when our >>> organization was called 'SGML Open'). The Exchange Table Model was >>> updated >>> to provide an XML version as well. >>> http://www.oasis-open.org/specs/tablemodels.php >>> >>> Carol >>> >>> -- >>> Carol Geyer >>> Senior Director of Communications and Development >>> >>> OASIS | Advancing open standards for the information society >>> +1.978.667.5115 x209 (Office) | +1.941.284.0403 (Cell) >>> http://www.oasis-open.org >>> >>> Take a Tour of OASIS >>> http://www.oasis-open.org/home/tour.php >>> >>> >>>> >>>> -----Original Message----- >>>> From: Laurent Romary [mailto:laurent.romary at loria.fr] >>>> Sent: Wednesday, May 12, 2010 2:01 AM >>>> To: info at oasis-open.org >>>> Subject: Fwd: Using CALS within the TEI framework >>>> >>>> Hi, >>>> It does not seem that this message went through. >>>> At our last TEI council meeting in April, we definitely >>>> identified the >>>> need for us to provide a CALS support. Would it make sense that the >>>> TEI takes up the maintenance of it? >>>> Best regards, >>>> Laurent >>>> >>>> >>>> D?but du message r?exp?di? : >>>> >>>> >>>> De : Laurent Romary <laurent.romary at loria.fr> >>>> Date : 27 janvier 2010 10:51:22 GMT+01:00 >>>> ? : info at oasis-open.org >>>> Objet : Using CALS within the TEI framework >>>> >>>> I am writing to you as chair of the Text Encoding Initiative >>>> council >>> >>>> (www.tei-c.org <http://www.tei-c.org/> ). Some requests have been >>>> expressed on a regularly basis to the TEI so that the CALS model be >>>> supported and maintained within the TEI architecture, in a context >>>> where the TEI has also developed its own table XML format (but >>>> basically not as good as CALS). My question at this stage is how >>>> much >>>> liberty would we have to provide a specification of CALS that would >>>> generate DTD, RelaxNG and W3C schema support? Is the CALS model >>>> still >>>> maintained officially within OASIS and to whom should we apply to >>>> have >>>> specific rights to reuse (and update if needed) the model. >>>> Best regards, >>>> Laurent Romary >>>> >>>> >>>> Laurent Romary >>>> INRIA & HUB-IDSL >>>> laurent.romary at inria.fr >>>> >>>> >>>> >>>> >>> >> >> Laurent Romary >> INRIA & HUB-IDSL >> laurent.romary at inria.fr >> >> >> > Laurent Romary INRIA & HUB-IDSL laurent.romary at inria.fr From gabriel.bodard at kcl.ac.uk Tue Jun 8 09:17:44 2010 From: gabriel.bodard at kcl.ac.uk (Gabriel Bodard) Date: Tue, 8 Jun 2010 14:17:44 +0100 Subject: [tei-council] xml:id definition Message-ID: <4C0E42F8.3050304@kcl.ac.uk> Can I just ask, has there been any progress on fixing the problem of the definition of @xml:id being broken by schemas containing tagdocs? (I've just been asked about this problem by a TEI user who is reluctant to join lists etc.) Last I recall, Sebastian seemed optimistic about fixing this based on George Bina's "cunning plan". When is next release scheduled? G -- Dr Gabriel BODARD (Epigrapher, Digital Classicist, Pirate) Centre for Computing in the Humanities King's College London 26-29 Drury Lane London WC2B 5RL Email: gabriel.bodard at kcl.ac.uk Tel: +44 (0)20 7848 1388 Fax: +44 (0)20 7848 2980 http://www.digitalclassicist.org/ http://www.currentepigraphy.org/ From sebastian.rahtz at oucs.ox.ac.uk Tue Jun 8 11:26:13 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 8 Jun 2010 16:26:13 +0100 Subject: [tei-council] xml:id definition In-Reply-To: <4C0E42F8.3050304@kcl.ac.uk> References: <4C0E42F8.3050304@kcl.ac.uk> Message-ID: <F69CFDD7-7640-4528-BD21-B22EC8C7ACEA@oucs.ox.ac.uk> On 8 Jun 2010, at 14:17, Gabriel Bodard wrote: > Can I just ask, has there been any progress on fixing the problem of the > definition of @xml:id being broken by schemas containing tagdocs? (I've > just been asked about this problem by a TEI user who is reluctant to > join lists etc.) Last I recall, Sebastian seemed optimistic about fixing > this based on George Bina's "cunning plan". Yes, I am glad to say that as of a week or so ago, this is fixed. Lou and I have tested it, and it seems OK. The ODD processing has had a fairly large set of changes, coping with new <elementRef> etc elements, @exclude/@include on <moduleRef>, and the @source facility on *Ref. You will suddenly have a lot more expressivity, at not much cost. the downside is that all this is only in the XSLT 2.0 stylesheets, which don't work with Roma. I don't have a plan for how to cope, I am sorry to say: choices 1 withdraw Roma from service 2 leave Roma frozen and old-style 3 reimplement all changes back in XSLT 1.0 as well (not a small task) 4 write a new Roma in Java 5 hack the old Roma to use a web service to do its transformation work (if we had a web service) any preferences ? > > When is next release scheduled? second week of July -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From James.Cummings at oucs.ox.ac.uk Tue Jun 8 11:36:01 2010 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Tue, 08 Jun 2010 16:36:01 +0100 Subject: [tei-council] xml:id definition In-Reply-To: <F69CFDD7-7640-4528-BD21-B22EC8C7ACEA@oucs.ox.ac.uk> References: <4C0E42F8.3050304@kcl.ac.uk> <F69CFDD7-7640-4528-BD21-B22EC8C7ACEA@oucs.ox.ac.uk> Message-ID: <4C0E6361.1000004@oucs.ox.ac.uk> Sebastian Rahtz wrote: > 1 withdraw Roma from service > 2 leave Roma frozen and old-style > 3 reimplement all changes back in XSLT 1.0 as well (not a small task) > 4 write a new Roma in Java > 5 hack the old Roma to use a web service to do its transformation work (if we had a web service) > any preferences ? 5 in preference. Though I'd prefer a combination of 2 and 4&5 (though not specific about it being java). I.e. freeze current Roma, and develop a new Roma which uses a web server for the transformation work (and the ODD2Schema work) using whatever technologies seem best for that. (Ok, Java probably is a good bet, but I wouldn't make it a requirement.) The problem with that is there is no funding (I believe?) to finance development on these things so the best we could hope for would be something like 5 on a best-effort basis. -James -- Dr James Cummings, Research Technologies Service OUCS, University of Oxford From sebastian.rahtz at oucs.ox.ac.uk Tue Jun 8 11:42:42 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 8 Jun 2010 16:42:42 +0100 Subject: [tei-council] xml:id definition In-Reply-To: <4C0E6361.1000004@oucs.ox.ac.uk> References: <4C0E42F8.3050304@kcl.ac.uk> <F69CFDD7-7640-4528-BD21-B22EC8C7ACEA@oucs.ox.ac.uk> <4C0E6361.1000004@oucs.ox.ac.uk> Message-ID: <B7299A53-6A71-4146-9FD6-C7F1E3DB63CA@oucs.ox.ac.uk> On 8 Jun 2010, at 16:36, James Cummings wrote: >> 5 hack the old Roma to use a web service to do its transformation work (if we had a web service) >> any preferences ? > > 5 in preference. Though I'd prefer a combination of 2 and 4&5 > (though not specific about it being java). unless you find me another XSLT 2.0 engine, it has to be Java ... > The problem with that > is there is no funding (I believe?) to finance development on > these things or, more importantly, no expertise on offer > so the best we could hope for would be something > like 5 on a best-effort basis. it remains a formidable task. viz a) write a web service to do it (based on Enrich Garage) and b) hack the PHP to use that. possible that we could decouple it. ie cut Roma back so that all it can do is deliver an ODD file, and separately upload it to a web service. I am more attracted by that as a half-way house. -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From kevin.s.hawkins at ultraslavonic.info Tue Jun 8 17:44:30 2010 From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins) Date: Tue, 08 Jun 2010 17:44:30 -0400 Subject: [tei-council] soft hyphens (again) In-Reply-To: <4C0BCE46.1080008@ultraslavonic.info> References: <4BF606D3.7050603@ultraslavonic.info> <4BF9A302.1030108@oucs.ox.ac.uk> <4C0BCE46.1080008@ultraslavonic.info> Message-ID: <4C0EB9BE.6040203@ultraslavonic.info> I brought the folks revising the *Best Practices for TEI in Libraries* up to speed on our hyphenation discussion. Perry Willett raised a good point: if we have encoding like: (A) This is not a run-<lb type="betweenWords"/>on sentence. (B) UTF-8 is a char-<lb type="inWord"/>acter encoding for Unicode. (C) Some people say TEI is a mark-<lb type="uncertain"/>up language. One might read (C) as if the encoder is sure whether a line break really occurs here. We're using an attribute of one element to describe the character that appears before it. The suggested these three type values (based in part on what's given in the definition of <lb>, but I think we might need a better value for @type in (C). Suggestions? Kevin From sebastian.rahtz at oucs.ox.ac.uk Wed Jun 9 04:25:46 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Wed, 9 Jun 2010 09:25:46 +0100 Subject: [tei-council] xml:id definition In-Reply-To: <B7299A53-6A71-4146-9FD6-C7F1E3DB63CA@oucs.ox.ac.uk> References: <4C0E42F8.3050304@kcl.ac.uk> <F69CFDD7-7640-4528-BD21-B22EC8C7ACEA@oucs.ox.ac.uk> <4C0E6361.1000004@oucs.ox.ac.uk> <B7299A53-6A71-4146-9FD6-C7F1E3DB63CA@oucs.ox.ac.uk> Message-ID: <4B9AD087-0147-42F8-B08E-F865862180A0@oucs.ox.ac.uk> on reflection, I think I may see a glimmer of light, in the shape of the ENRICH Garage (http://dl.psnc.pl/software/EGE/). If that can be configured to perform ODD conversions (which should be possible), it can act as a Roma web service. It would then be plausible to patch the old Roma to use that, if someone can find a PHP hacker for a few days. -- Sebastian Rahtz (acting) Information and Support Group Manager Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From daniel.odonnell at uleth.ca Tue Jun 15 00:13:51 2010 From: daniel.odonnell at uleth.ca (O'Donnell, Dan) Date: Mon, 14 Jun 2010 22:13:51 -0600 Subject: [tei-council] Attachment test -- ignore In-Reply-To: <alpine.OSX.2.00.1003161029550.37172@lister.ei.virginia.edu> References: <alpine.OSX.2.00.1003161029550.37172@lister.ei.virginia.edu> Message-ID: <4C16FDFF.5080706@uleth.ca> And there was. On 10-03-16 08:30 AM, David Sewell wrote: > List should be accepting attachments except .exe, .bat, etc. > > There should be a small XML file attached. > > > > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > -- Daniel Paul O'Donnell Professor of English University of Lethbridge Chair and CEO, Text Encoding Initiative (http://www.tei-c.org/) Co-Chair, Digital Initiatives Advisory Board, Medieval Academy of America President-elect (English), Society for Digital Humanities/Soci?t? pour l'?tude des m?dias interactifs (http://sdh-semi.org/) Founding Director (2003-2009), Digital Medievalist Project (http://www.digitalmedievalist.org/) Vox: +1 403 329-2377 Fax: +1 403 382-7191 (non-confidential) Home Page: http://people.uleth.ca/~daniel.odonnell/ From kevin.s.hawkins at ultraslavonic.info Tue Jun 15 11:25:44 2010 From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins) Date: Tue, 15 Jun 2010 11:25:44 -0400 Subject: [tei-council] soft hyphens (again) In-Reply-To: <4C0BCE46.1080008@ultraslavonic.info> References: <4BF606D3.7050603@ultraslavonic.info> <4BF9A302.1030108@oucs.ox.ac.uk> <4C0BCE46.1080008@ultraslavonic.info> Message-ID: <4C179B78.7060706@ultraslavonic.info> I'm resending this message with fewer typos and more context. *** I brought the folks revising the *Best Practices for TEI in Libraries* up to speed on our hyphenation discussion. Perry Willett raised a good point: if we have encoding like: (A) This is not a run-<lb type="betweenWords"/>on sentence. (B) UTF-8 is a char-<lb type="inWord"/>acter encoding for Unicode. (C) Some people say TEI is a mark-<lb type="uncertain"/>up language. One might read (C) as if the encoder is sure whether a line break really occurs here. We're using an attribute of one element to describe the character that appears before it. Lou suggested these three type values (see excerpt from his message below), but I think we might need a better value for @type in (C). Suggestions? The Best Practices team is trying to finish revising the prose by the beginning of July so that we have a stable basis for creating ODD specs. So I'd be grateful for a response soon (especially from Lou). Kevin > On the question you raise about values for @type, there is already a > (carefully worded) recommendation in the Guidelines: "The type attribute > may be used to characterize the line break in any respect, but its most > common use is to specify that the presence of the line break does not > imply the end of the word in which it is embedded. A value such as > inWord or nobreak is recommended for this purpose, but encoders are free > to choose whichever values are appropriate. " > > (I say "carefully worded" because quite a lot of virtual ink was spilled > on the topic over on the Epidoc list some time back) > > If we are using @type to characterise the linebreak from a tokenization > point of view, there really can be only three possible states: "inWord" > (i.e. the tokeniser needs to combine the string before the linebreak > with the string after it to form a single token) "betweenWords" (i.e. > the string before the linebreak and the string after it are two separate > tokens) and "uncertain" (i.e. it could be either of the other two and > we're unwilling or unable to decide). From mholmes at uvic.ca Tue Jun 15 11:51:57 2010 From: mholmes at uvic.ca (Martin Holmes) Date: Tue, 15 Jun 2010 08:51:57 -0700 Subject: [tei-council] soft hyphens (again) In-Reply-To: <4C179B78.7060706@ultraslavonic.info> References: <4BF606D3.7050603@ultraslavonic.info> <4BF9A302.1030108@oucs.ox.ac.uk> <4C0BCE46.1080008@ultraslavonic.info> <4C179B78.7060706@ultraslavonic.info> Message-ID: <4C17A19D.5070205@uvic.ca> Looking again at this, I'm struck also by what strikes you: the <lb/> is not the hyphen, and if we're trying to encode information about the hyphen, the <lb/> seems to be the wrong place to do it. I'd really prefer a container tag which encloses the hyphen and implies (for at least one rendering scenario) a linebreak. But I don't know what that tag should be. In the case of the three examples: (A) This is not a run-<lb/>on sentence. (This is just a line-break, isn't it? The hyphen is incidental.) (B) UTF-8 is a char<someTag type="breakInWord">-</someTag>acter encoding for Unicode. (The processor can decide whether to render the hyphen, depending on whether it's rendering the linebreaks or not; tokenizers can ignore the tag completely.) (C) Some people say TEI is a mark-<lb/>up language. OR (C) Some people say TEI is a mark<someTag type="breakInWord">-</someTag>up language. (If it's impossible to decide, then perhaps some kind of <choice> structure would be appropriate.) Cheers, Martin On 10-06-15 08:25 AM, Kevin Hawkins wrote: > I'm resending this message with fewer typos and more context. > > *** > > I brought the folks revising the *Best Practices for TEI in Libraries* > up to speed on our hyphenation discussion. Perry Willett raised a good > point: if we have encoding like: > > (A) This is not a run-<lb type="betweenWords"/>on sentence. > > (B) UTF-8 is a char-<lb type="inWord"/>acter encoding for Unicode. > > (C) Some people say TEI is a mark-<lb type="uncertain"/>up language. > > One might read (C) as if the encoder is sure whether a line break really > occurs here. We're using an attribute of one element to describe the > character that appears before it. > > Lou suggested these three type values (see excerpt from his message > below), but I think we might need a better value for @type in (C). > Suggestions? > > The Best Practices team is trying to finish revising the prose by the > beginning of July so that we have a stable basis for creating ODD specs. > So I'd be grateful for a response soon (especially from Lou). > > Kevin > >> On the question you raise about values for @type, there is already a >> (carefully worded) recommendation in the Guidelines: "The type attribute >> may be used to characterize the line break in any respect, but its most >> common use is to specify that the presence of the line break does not >> imply the end of the word in which it is embedded. A value such as >> inWord or nobreak is recommended for this purpose, but encoders are free >> to choose whichever values are appropriate. " >> >> (I say "carefully worded" because quite a lot of virtual ink was spilled >> on the topic over on the Epidoc list some time back) > > >> If we are using @type to characterise the linebreak from a tokenization >> point of view, there really can be only three possible states: "inWord" >> (i.e. the tokeniser needs to combine the string before the linebreak >> with the string after it to form a single token) "betweenWords" (i.e. >> the string before the linebreak and the string after it are two separate >> tokens) and "uncertain" (i.e. it could be either of the other two and >> we're unwilling or unable to decide). > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > . > -- Martin Holmes University of Victoria Humanities Computing and Media Centre (mholmes at uvic.ca) Half-Baked Software, Inc. (mholmes at halfbakedsoftware.com) martin at mholmes.com From lou.burnard at oucs.ox.ac.uk Tue Jun 15 12:06:52 2010 From: lou.burnard at oucs.ox.ac.uk (Lou) Date: Tue, 15 Jun 2010 17:06:52 +0100 Subject: [tei-council] soft hyphens (again) In-Reply-To: <4C179B78.7060706@ultraslavonic.info> References: <4BF606D3.7050603@ultraslavonic.info> <4BF9A302.1030108@oucs.ox.ac.uk> <4C0BCE46.1080008@ultraslavonic.info> <4C179B78.7060706@ultraslavonic.info> Message-ID: <4C17A51C.4040908@oucs.ox.ac.uk> Yes, I agree that @type=uncertain isn't much use if what we really mean is "@type="I'm_uncertain_whether_this_is_a_word_break_or_not" The problem is that we've appropriated the very general typology which @type provides for a very specific function. If we wanted to characterise linebreaks in some *other* respect than whether or not they coincided with word boundaries, we'd need to add other values ("authorial" and "scribal" suggest themselves as possible candidates) and then "uncertain" becomes *really* uncertain... and in any case we couldn't support multiple values -- it might be both "inWord" and "authorial" (or whatever). Yuk. It's yet another example of for why @type shouldn't be global and why its values should be mutually exclusive. I can only think of two possible solutions to this. No, make it three. 1. come up with a better word than "uncertain" for the third case (wbsu or wordBreakStatusUnknown?) 2. use a different attribute @wordBreaking = "true|false|unknown" 3. redefine the semantics of @type="wordBreaking" to mean just "this is probably a word breaker but possibly not" Solutions 1 and 3 have the advantage of leaving things more or less unchanged for the only people I am aware of who actually care about this problem i.e. epigraphers. Solution 2 has the advantage of being more explicit and elegant, but I wouldn't want it to replace the status quo for obvious reasons of backwards compatibility. Votes? Kevin Hawkins wrote: > I'm resending this message with fewer typos and more context. > > *** > > I brought the folks revising the *Best Practices for TEI in Libraries* > up to speed on our hyphenation discussion. Perry Willett raised a good > point: if we have encoding like: > > (A) This is not a run-<lb type="betweenWords"/>on sentence. > > (B) UTF-8 is a char-<lb type="inWord"/>acter encoding for Unicode. > > (C) Some people say TEI is a mark-<lb type="uncertain"/>up language. > > One might read (C) as if the encoder is sure whether a line break really > occurs here. We're using an attribute of one element to describe the > character that appears before it. > > Lou suggested these three type values (see excerpt from his message > below), but I think we might need a better value for @type in (C). > Suggestions? > > The Best Practices team is trying to finish revising the prose by the > beginning of July so that we have a stable basis for creating ODD specs. > So I'd be grateful for a response soon (especially from Lou). > > Kevin > >> On the question you raise about values for @type, there is already a >> (carefully worded) recommendation in the Guidelines: "The type attribute >> may be used to characterize the line break in any respect, but its most >> common use is to specify that the presence of the line break does not >> imply the end of the word in which it is embedded. A value such as >> inWord or nobreak is recommended for this purpose, but encoders are free >> to choose whichever values are appropriate. " >> >> (I say "carefully worded" because quite a lot of virtual ink was spilled >> on the topic over on the Epidoc list some time back) > > >> If we are using @type to characterise the linebreak from a tokenization >> point of view, there really can be only three possible states: "inWord" >> (i.e. the tokeniser needs to combine the string before the linebreak >> with the string after it to form a single token) "betweenWords" (i.e. >> the string before the linebreak and the string after it are two separate >> tokens) and "uncertain" (i.e. it could be either of the other two and >> we're unwilling or unable to decide). > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council From lou.burnard at oucs.ox.ac.uk Tue Jun 15 12:17:59 2010 From: lou.burnard at oucs.ox.ac.uk (Lou) Date: Tue, 15 Jun 2010 17:17:59 +0100 Subject: [tei-council] soft hyphens (again) In-Reply-To: <4C17A19D.5070205@uvic.ca> References: <4BF606D3.7050603@ultraslavonic.info> <4BF9A302.1030108@oucs.ox.ac.uk> <4C0BCE46.1080008@ultraslavonic.info> <4C179B78.7060706@ultraslavonic.info> <4C17A19D.5070205@uvic.ca> Message-ID: <4C17A7B7.9070100@oucs.ox.ac.uk> These boil down to saying "use two different ways of marking up the hyphen", one for when *it* is to be treated as a separator, one when it isn't. Which is sort of where we came in, several months ago, when discussing ­ But the issue currently on the table is what to do about LINEBREAKS. As I said in an earlier post, it isn't necessarily a hyphen character which is used to mark where a word (despite appearances) runs on to the next line. It may be something else entirely. It may be nothing at all. Martin Holmes wrote: > Looking again at this, I'm struck also by what strikes you: the <lb/> is > not the hyphen, and if we're trying to encode information about the > hyphen, the <lb/> seems to be the wrong place to do it. > > I'd really prefer a container tag which encloses the hyphen and implies > (for at least one rendering scenario) a linebreak. But I don't know what > that tag should be. In the case of the three examples: > > (A) This is not a run-<lb/>on sentence. > > (This is just a line-break, isn't it? The hyphen is incidental.) > > (B) UTF-8 is a char<someTag type="breakInWord">-</someTag>acter encoding > for Unicode. > > (The processor can decide whether to render the hyphen, depending on > whether it's rendering the linebreaks or not; tokenizers can ignore the > tag completely.) > > (C) Some people say TEI is a mark-<lb/>up language. OR > > (C) Some people say TEI is a mark<someTag > type="breakInWord">-</someTag>up language. > > (If it's impossible to decide, then perhaps some kind of <choice> > structure would be appropriate.) > > Cheers, > Martin > > On 10-06-15 08:25 AM, Kevin Hawkins wrote: >> I'm resending this message with fewer typos and more context. >> >> *** >> >> I brought the folks revising the *Best Practices for TEI in Libraries* >> up to speed on our hyphenation discussion. Perry Willett raised a good >> point: if we have encoding like: >> >> (A) This is not a run-<lb type="betweenWords"/>on sentence. >> >> (B) UTF-8 is a char-<lb type="inWord"/>acter encoding for Unicode. >> >> (C) Some people say TEI is a mark-<lb type="uncertain"/>up language. >> >> One might read (C) as if the encoder is sure whether a line break really >> occurs here. We're using an attribute of one element to describe the >> character that appears before it. >> >> Lou suggested these three type values (see excerpt from his message >> below), but I think we might need a better value for @type in (C). >> Suggestions? >> >> The Best Practices team is trying to finish revising the prose by the >> beginning of July so that we have a stable basis for creating ODD specs. >> So I'd be grateful for a response soon (especially from Lou). >> >> Kevin >> >>> On the question you raise about values for @type, there is already a >>> (carefully worded) recommendation in the Guidelines: "The type attribute >>> may be used to characterize the line break in any respect, but its most >>> common use is to specify that the presence of the line break does not >>> imply the end of the word in which it is embedded. A value such as >>> inWord or nobreak is recommended for this purpose, but encoders are free >>> to choose whichever values are appropriate. " >>> >>> (I say "carefully worded" because quite a lot of virtual ink was spilled >>> on the topic over on the Epidoc list some time back) >> > >>> If we are using @type to characterise the linebreak from a tokenization >>> point of view, there really can be only three possible states: "inWord" >>> (i.e. the tokeniser needs to combine the string before the linebreak >>> with the string after it to form a single token) "betweenWords" (i.e. >>> the string before the linebreak and the string after it are two separate >>> tokens) and "uncertain" (i.e. it could be either of the other two and >>> we're unwilling or unable to decide). >> _______________________________________________ >> tei-council mailing list >> tei-council at lists.village.Virginia.EDU >> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council >> . >> > From kevin.s.hawkins at ultraslavonic.info Tue Jun 15 14:22:37 2010 From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins) Date: Tue, 15 Jun 2010 14:22:37 -0400 Subject: [tei-council] soft hyphens (again) In-Reply-To: <4C17A51C.4040908@oucs.ox.ac.uk> References: <4BF606D3.7050603@ultraslavonic.info> <4BF9A302.1030108@oucs.ox.ac.uk> <4C0BCE46.1080008@ultraslavonic.info> <4C179B78.7060706@ultraslavonic.info> <4C17A51C.4040908@oucs.ox.ac.uk> Message-ID: <4C17C4ED.5090703@ultraslavonic.info> I vote for (1) (either string is okay with me) in the interest of backwards compatibility. But we should keep in mind (2) for a future major version of the TEI. On 6/15/2010 12:06 PM, Lou wrote: > Yes, I agree that @type=uncertain isn't much use if what we really mean > is "@type="I'm_uncertain_whether_this_is_a_word_break_or_not" > > The problem is that we've appropriated the very general typology which > @type provides for a very specific function. If we wanted to > characterise linebreaks in some *other* respect than whether or not they > coincided with word boundaries, we'd need to add other values > ("authorial" and "scribal" suggest themselves as possible candidates) > and then "uncertain" becomes *really* uncertain... and in any case we > couldn't support multiple values -- it might be both "inWord" and > "authorial" (or whatever). Yuk. It's yet another example of for why > @type shouldn't be global and why its values should be mutually exclusive. > > I can only think of two possible solutions to this. No, make it three. > > 1. come up with a better word than "uncertain" for the third case (wbsu > or wordBreakStatusUnknown?) > > 2. use a different attribute @wordBreaking = "true|false|unknown" > > 3. redefine the semantics of @type="wordBreaking" to mean just "this is > probably a word breaker but possibly not" > > > Solutions 1 and 3 have the advantage of leaving things more or less > unchanged for the only people I am aware of who actually care about this > problem i.e. epigraphers. Solution 2 has the advantage of being more > explicit and elegant, but I wouldn't want it to replace the status quo > for obvious reasons of backwards compatibility. > > Votes? > > > > > > Kevin Hawkins wrote: >> I'm resending this message with fewer typos and more context. >> >> *** >> >> I brought the folks revising the *Best Practices for TEI in Libraries* >> up to speed on our hyphenation discussion. Perry Willett raised a good >> point: if we have encoding like: >> >> (A) This is not a run-<lb type="betweenWords"/>on sentence. >> >> (B) UTF-8 is a char-<lb type="inWord"/>acter encoding for Unicode. >> >> (C) Some people say TEI is a mark-<lb type="uncertain"/>up language. >> >> One might read (C) as if the encoder is sure whether a line break >> really occurs here. We're using an attribute of one element to >> describe the character that appears before it. >> >> Lou suggested these three type values (see excerpt from his message >> below), but I think we might need a better value for @type in (C). >> Suggestions? >> >> The Best Practices team is trying to finish revising the prose by the >> beginning of July so that we have a stable basis for creating ODD >> specs. So I'd be grateful for a response soon (especially from Lou). >> >> Kevin >> >>> On the question you raise about values for @type, there is already a >>> (carefully worded) recommendation in the Guidelines: "The type attribute >>> may be used to characterize the line break in any respect, but its most >>> common use is to specify that the presence of the line break does not >>> imply the end of the word in which it is embedded. A value such as >>> inWord or nobreak is recommended for this purpose, but encoders are free >>> to choose whichever values are appropriate. " >>> >>> (I say "carefully worded" because quite a lot of virtual ink was spilled >>> on the topic over on the Epidoc list some time back) >> > >>> If we are using @type to characterise the linebreak from a tokenization >>> point of view, there really can be only three possible states: "inWord" >>> (i.e. the tokeniser needs to combine the string before the linebreak >>> with the string after it to form a single token) "betweenWords" (i.e. >>> the string before the linebreak and the string after it are two separate >>> tokens) and "uncertain" (i.e. it could be either of the other two and >>> we're unwilling or unable to decide). >> _______________________________________________ >> tei-council mailing list >> tei-council at lists.village.Virginia.EDU >> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > From gabriel.bodard at kcl.ac.uk Wed Jun 16 06:07:35 2010 From: gabriel.bodard at kcl.ac.uk (Gabriel Bodard) Date: Wed, 16 Jun 2010 11:07:35 +0100 Subject: [tei-council] soft hyphens (again) In-Reply-To: <4C17A51C.4040908@oucs.ox.ac.uk> References: <4BF606D3.7050603@ultraslavonic.info> <4BF9A302.1030108@oucs.ox.ac.uk> <4C0BCE46.1080008@ultraslavonic.info> <4C179B78.7060706@ultraslavonic.info> <4C17A51C.4040908@oucs.ox.ac.uk> Message-ID: <4C18A267.5000708@kcl.ac.uk> While (2) is attractive in terms of explicicity and elegance, I am tempted to vote for (3) on the grounds that if you're really uncertain about the status of a line-break there are other ways to express this (<certainty> element inside <lb> anyone?--to resurrect a TEI-L query that seems to have been met with defeaning indifference...) Has anyone ever had any use-case for characterizing linebreaks (and cb, pb, etc.) other than by whether they break works or not? G On 15/06/2010 17:06, Lou wrote: > Yes, I agree that @type=uncertain isn't much use if what we really mean > is "@type="I'm_uncertain_whether_this_is_a_word_break_or_not" > > The problem is that we've appropriated the very general typology which > @type provides for a very specific function. If we wanted to > characterise linebreaks in some *other* respect than whether or not they > coincided with word boundaries, we'd need to add other values > ("authorial" and "scribal" suggest themselves as possible candidates) > and then "uncertain" becomes *really* uncertain... and in any case we > couldn't support multiple values -- it might be both "inWord" and > "authorial" (or whatever). Yuk. It's yet another example of for why > @type shouldn't be global and why its values should be mutually exclusive. > > I can only think of two possible solutions to this. No, make it three. > > 1. come up with a better word than "uncertain" for the third case (wbsu > or wordBreakStatusUnknown?) > > 2. use a different attribute @wordBreaking = "true|false|unknown" > > 3. redefine the semantics of @type="wordBreaking" to mean just "this is > probably a word breaker but possibly not" > > > Solutions 1 and 3 have the advantage of leaving things more or less > unchanged for the only people I am aware of who actually care about this > problem i.e. epigraphers. Solution 2 has the advantage of being more > explicit and elegant, but I wouldn't want it to replace the status quo > for obvious reasons of backwards compatibility. > > Votes? > > > > > > Kevin Hawkins wrote: >> I'm resending this message with fewer typos and more context. >> >> *** >> >> I brought the folks revising the *Best Practices for TEI in Libraries* >> up to speed on our hyphenation discussion. Perry Willett raised a good >> point: if we have encoding like: >> >> (A) This is not a run-<lb type="betweenWords"/>on sentence. >> >> (B) UTF-8 is a char-<lb type="inWord"/>acter encoding for Unicode. >> >> (C) Some people say TEI is a mark-<lb type="uncertain"/>up language. >> >> One might read (C) as if the encoder is sure whether a line break really >> occurs here. We're using an attribute of one element to describe the >> character that appears before it. >> >> Lou suggested these three type values (see excerpt from his message >> below), but I think we might need a better value for @type in (C). >> Suggestions? >> >> The Best Practices team is trying to finish revising the prose by the >> beginning of July so that we have a stable basis for creating ODD specs. >> So I'd be grateful for a response soon (especially from Lou). >> >> Kevin >> >>> On the question you raise about values for @type, there is already a >>> (carefully worded) recommendation in the Guidelines: "The type attribute >>> may be used to characterize the line break in any respect, but its most >>> common use is to specify that the presence of the line break does not >>> imply the end of the word in which it is embedded. A value such as >>> inWord or nobreak is recommended for this purpose, but encoders are free >>> to choose whichever values are appropriate. " >>> >>> (I say "carefully worded" because quite a lot of virtual ink was spilled >>> on the topic over on the Epidoc list some time back) >> > >>> If we are using @type to characterise the linebreak from a tokenization >>> point of view, there really can be only three possible states: "inWord" >>> (i.e. the tokeniser needs to combine the string before the linebreak >>> with the string after it to form a single token) "betweenWords" (i.e. >>> the string before the linebreak and the string after it are two separate >>> tokens) and "uncertain" (i.e. it could be either of the other two and >>> we're unwilling or unable to decide). >> _______________________________________________ >> tei-council mailing list >> tei-council at lists.village.Virginia.EDU >> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council -- Dr Gabriel BODARD (Epigrapher, Digital Classicist, Pirate) Centre for Computing in the Humanities King's College London 26-29 Drury Lane London WC2B 5RL Email: gabriel.bodard at kcl.ac.uk Tel: +44 (0)20 7848 1388 Fax: +44 (0)20 7848 2980 http://www.digitalclassicist.org/ http://www.currentepigraphy.org/ From sebastian.rahtz at oucs.ox.ac.uk Fri Jun 18 13:33:37 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Fri, 18 Jun 2010 18:33:37 +0100 Subject: [tei-council] its release time Message-ID: <F466390F-E6D2-4547-BF01-1823275A9330@oucs.ox.ac.uk> I would like to make a new TEI release in the first week of July. Would people like to start checking that things which should have been done have been done? you can start looking at http://tei.oucs.ox.ac.uk/release/doc/tei-p5-doc/en/html/, which reflects the current state. -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From kevin.s.hawkins at ultraslavonic.info Sun Jun 20 17:09:21 2010 From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins) Date: Sun, 20 Jun 2010 17:09:21 -0400 Subject: [tei-council] soft hyphens (again) In-Reply-To: <4C17C4ED.5090703@ultraslavonic.info> References: <4BF606D3.7050603@ultraslavonic.info> <4BF9A302.1030108@oucs.ox.ac.uk> <4C0BCE46.1080008@ultraslavonic.info> <4C179B78.7060706@ultraslavonic.info> <4C17A51C.4040908@oucs.ox.ac.uk> <4C17C4ED.5090703@ultraslavonic.info> Message-ID: <4C1E8381.6090007@ultraslavonic.info> Lou offered three possible solutions: > I can only think of two possible solutions to this. No, make it > three. > > 1. come up with a better word than "uncertain" for the third case > (wbsu or wordBreakStatusUnknown?) > > 2. use a different attribute @wordBreaking = "true|false|unknown" > > 3. redefine the semantics of @type="wordBreaking" to mean just "this > is probably a word breaker but possibly not" For consistency with the options I originally presented, solution 3 should read: 3. redefine the semantics of @type="inWord" to mean just "this is probably a word breaker but possibly between words" Should we have a fourth option? 4. redefine the semantics of @type='betweenWords' to mean just "this is probably between words but possibly a word breaker" I've been puzzling over whether uncertain cases are more likely to be confused with "betweenWords" or "inWord" cases but can't figure it out. To respond to Gabby: > While (2) is attractive in terms of explicicity and elegance, I am > tempted to vote for (3) on the grounds that if you're really uncertain > about the status of a line-break there are other ways to express this > (<certainty> element inside <lb> anyone?--to resurrect a TEI-L query > that seems to have been met with defeaning indifference...) Which TEI-L query is this? <lb/> is an empty element, so we can't put certainty inside it without changing its content model (and that of <cb/> and <pb/>. > Has anyone ever had any use-case for characterizing linebreaks (and cb, > pb, etc.) other than by whether they break works or not? Aside from describing whether they break words, I can't think of anything. From gabriel.bodard at kcl.ac.uk Mon Jun 21 09:50:13 2010 From: gabriel.bodard at kcl.ac.uk (Gabriel Bodard) Date: Mon, 21 Jun 2010 14:50:13 +0100 Subject: [tei-council] soft hyphens (again) In-Reply-To: <4C1E8381.6090007@ultraslavonic.info> References: <4BF606D3.7050603@ultraslavonic.info> <4BF9A302.1030108@oucs.ox.ac.uk> <4C0BCE46.1080008@ultraslavonic.info> <4C179B78.7060706@ultraslavonic.info> <4C17A51C.4040908@oucs.ox.ac.uk> <4C17C4ED.5090703@ultraslavonic.info> <4C1E8381.6090007@ultraslavonic.info> Message-ID: <4C1F6E15.7000908@kcl.ac.uk> On 20/06/2010 22:09, Kevin Hawkins wrote: >> (<certainty> element inside<lb> anyone?--to resurrect a TEI-L query >> that seems to have been met with deafening indifference...) > > Which TEI-L query is this? http://listserv.brown.edu/archives/cgi-bin/wa?A2=ind1006&L=TEI-L&T=0&F=&S=&P=7480 > <lb/> is an empty element, so we can't put certainty inside it without > changing its content model (and that of<cb/> and<pb/>. Yes, that's exactly my point. So-called empty elements such as <gap/> and <space/> can now contain the certainty family, and it's very valuable (especially in [semi-]automated editing environments) to be able to attach certainty to a specific element like this by position, without having to worry about generated as @xml:id. By the same token, it might make sense to use certainty inside the milestoneLike elements to indicate specifically things like type="weDontKnowIfThisIsAWordBreakOrNot". (I'll return to the other query later today, if I can find a minute...) G -- Dr Gabriel BODARD (Epigrapher, Digital Classicist, Pirate) Centre for Computing in the Humanities King's College London 26-29 Drury Lane London WC2B 5RL Email: gabriel.bodard at kcl.ac.uk Tel: +44 (0)20 7848 1388 Fax: +44 (0)20 7848 2980 http://www.digitalclassicist.org/ http://www.currentepigraphy.org/ From kevin.s.hawkins at ultraslavonic.info Mon Jun 21 11:02:51 2010 From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins) Date: Mon, 21 Jun 2010 11:02:51 -0400 Subject: [tei-council] soft hyphens (again) In-Reply-To: <4C1F6E15.7000908@kcl.ac.uk> References: <4BF606D3.7050603@ultraslavonic.info> <4BF9A302.1030108@oucs.ox.ac.uk> <4C0BCE46.1080008@ultraslavonic.info> <4C179B78.7060706@ultraslavonic.info> <4C17A51C.4040908@oucs.ox.ac.uk> <4C17C4ED.5090703@ultraslavonic.info> <4C1E8381.6090007@ultraslavonic.info> <4C1F6E15.7000908@kcl.ac.uk> Message-ID: <4C1F7F1B.9020006@ultraslavonic.info> On 6/21/2010 9:50 AM, Gabriel Bodard wrote: > On 20/06/2010 22:09, Kevin Hawkins wrote: >>> (<certainty> element inside<lb> anyone?--to resurrect a TEI-L query >>> that seems to have been met with deafening indifference...) >> >> Which TEI-L query is this? > > http://listserv.brown.edu/archives/cgi-bin/wa?A2=ind1006&L=TEI-L&T=0&F=&S=&P=7480 > >> <lb/> is an empty element, so we can't put certainty inside it without >> changing its content model (and that of<cb/> and<pb/>. > > Yes, that's exactly my point. So-called empty elements such as<gap/> > and<space/> can now contain the certainty family, and it's very > valuable (especially in [semi-]automated editing environments) to be > able to attach certainty to a specific element like this by position, > without having to worry about generated as @xml:id. By the same token, > it might make sense to use certainty inside the milestoneLike elements > to indicate specifically things like > type="weDontKnowIfThisIsAWordBreakOrNot". I'm afraid I still don't understand. Are these elements no longer empty elements? They still appear that way even in Sebastian's test release. When did this change happen? Kevin From gabriel.bodard at kcl.ac.uk Mon Jun 21 11:45:38 2010 From: gabriel.bodard at kcl.ac.uk (Gabriel Bodard) Date: Mon, 21 Jun 2010 16:45:38 +0100 Subject: [tei-council] soft hyphens (again) In-Reply-To: <4C1F7F1B.9020006@ultraslavonic.info> References: <4BF606D3.7050603@ultraslavonic.info> <4BF9A302.1030108@oucs.ox.ac.uk> <4C0BCE46.1080008@ultraslavonic.info> <4C179B78.7060706@ultraslavonic.info> <4C17A51C.4040908@oucs.ox.ac.uk> <4C17C4ED.5090703@ultraslavonic.info> <4C1E8381.6090007@ultraslavonic.info> <4C1F6E15.7000908@kcl.ac.uk> <4C1F7F1B.9020006@ultraslavonic.info> Message-ID: <4C1F8922.9070404@kcl.ac.uk> On 21/06/2010 16:02, Kevin Hawkins wrote: > I'm afraid I still don't understand. Are these elements no longer empty > elements? They still appear that way even in Sebastian's test release. > When did this change happen? Which elements? <gap/> (always an "empty"--i.e. permitting no text-content--element), has taken a child <desc> ever since P5 first release; <space/> for some reason did not, although it does now. Both also take <certainty/>, <precision/> etc. It makes sense to me that a so-called empty element could contain another non-text-bearing element such as <certainty/>, which in this case serves as a much richer analogue to a cert attribute. At the moment, of course, <lb/> and the other milestoneLike elements are still literally empty, but I am arguing (lightly, as I don't have a specific use-case for them) that they could just as rationally be allowed to take a child from the certainty class, although still no text content, of course. Sorry if this was confusing. G -- Dr Gabriel BODARD (Epigrapher, Digital Classicist, Pirate) Centre for Computing in the Humanities King's College London 26-29 Drury Lane London WC2B 5RL Email: gabriel.bodard at kcl.ac.uk Tel: +44 (0)20 7848 1388 Fax: +44 (0)20 7848 2980 http://www.digitalclassicist.org/ http://www.currentepigraphy.org/ From dot.porter at gmail.com Mon Jun 21 12:43:14 2010 From: dot.porter at gmail.com (Dot Porter) Date: Mon, 21 Jun 2010 12:43:14 -0400 Subject: [tei-council] soft hyphens (again) In-Reply-To: <4C1F7F1B.9020006@ultraslavonic.info> References: <4BF606D3.7050603@ultraslavonic.info> <4BF9A302.1030108@oucs.ox.ac.uk> <4C0BCE46.1080008@ultraslavonic.info> <4C179B78.7060706@ultraslavonic.info> <4C17A51C.4040908@oucs.ox.ac.uk> <4C17C4ED.5090703@ultraslavonic.info> <4C1E8381.6090007@ultraslavonic.info> <4C1F6E15.7000908@kcl.ac.uk> <4C1F7F1B.9020006@ultraslavonic.info> Message-ID: <AANLkTilCuBW0RW7CuX47E9-cqK9J7UKrF9tfWWjhhHjN@mail.gmail.com> Kevin, if you look at the entries for both <gap/> and <space/> in the elements index you'll see that both of these may contain certainty etc. http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-space.html http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-gap.html If your schema isn't letting you act on this there may be a bug in the system, or perhaps your schema doesn't include the certainty module. Dot On Mon, Jun 21, 2010 at 11:02 AM, Kevin Hawkins < kevin.s.hawkins at ultraslavonic.info> wrote: > On 6/21/2010 9:50 AM, Gabriel Bodard wrote: > > On 20/06/2010 22:09, Kevin Hawkins wrote: > >>> (<certainty> element inside<lb> anyone?--to resurrect a TEI-L query > >>> that seems to have been met with deafening indifference...) > >> > >> Which TEI-L query is this? > > > > > http://listserv.brown.edu/archives/cgi-bin/wa?A2=ind1006&L=TEI-L&T=0&F=&S=&P=7480 > > > >> <lb/> is an empty element, so we can't put certainty inside it without > >> changing its content model (and that of<cb/> and<pb/>. > > > > Yes, that's exactly my point. So-called empty elements such as<gap/> > > and<space/> can now contain the certainty family, and it's very > > valuable (especially in [semi-]automated editing environments) to be > > able to attach certainty to a specific element like this by position, > > without having to worry about generated as @xml:id. By the same token, > > it might make sense to use certainty inside the milestoneLike elements > > to indicate specifically things like > > type="weDontKnowIfThisIsAWordBreakOrNot". > > I'm afraid I still don't understand. Are these elements no longer empty > elements? They still appear that way even in Sebastian's test release. > When did this change happen? > > Kevin > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > -- *~*~*~*~*~*~*~*~*~*~* Dot Porter (MA, MSLS) Digital Medievalist, Digital Librarian Email: dot.porter at gmail.com *~*~*~*~*~*~*~*~*~*~* From kevin.s.hawkins at ultraslavonic.info Mon Jun 21 14:24:12 2010 From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins) Date: Mon, 21 Jun 2010 14:24:12 -0400 Subject: [tei-council] soft hyphens (again) In-Reply-To: <AANLkTilCuBW0RW7CuX47E9-cqK9J7UKrF9tfWWjhhHjN@mail.gmail.com> References: <4BF606D3.7050603@ultraslavonic.info> <4BF9A302.1030108@oucs.ox.ac.uk> <4C0BCE46.1080008@ultraslavonic.info> <4C179B78.7060706@ultraslavonic.info> <4C17A51C.4040908@oucs.ox.ac.uk> <4C17C4ED.5090703@ultraslavonic.info> <4C1E8381.6090007@ultraslavonic.info> <4C1F6E15.7000908@kcl.ac.uk> <4C1F7F1B.9020006@ultraslavonic.info> <AANLkTilCuBW0RW7CuX47E9-cqK9J7UKrF9tfWWjhhHjN@mail.gmail.com> Message-ID: <4C1FAE4C.5010307@ultraslavonic.info> I was looking at <lb/>, <cb/>, and <pb/> since I thought Gabby was saying that these were just like <gap/> and <space/>. Now, from his reply, I see that he is proposing that we treat lb, cb, and pb like these formerly empty elements. This is an interesting idea. On 6/21/2010 12:43 PM, Dot Porter wrote: > Kevin, if you look at the entries for both <gap/> and <space/> in the > elements index you'll see that both of these may contain certainty etc. > > http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-space.html > http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-gap.html > > If your schema isn't letting you act on this there may be a bug in the > system, or perhaps your schema doesn't include the certainty module. > > Dot From laurent.romary at inria.fr Fri Jun 25 07:51:41 2010 From: laurent.romary at inria.fr (Laurent Romary) Date: Fri, 25 Jun 2010 13:51:41 +0200 Subject: [tei-council] Fwd: linkGrp References: <4C246E73.9090304@iln.uio.no> Message-ID: <12CEC4DF-E461-4601-8EFE-1AC4F46AA2B1@inria.fr> Hi all, On a related manner and before I make a stupid ticket on this, is it necessary to keep two specific occurances of @resp for respons and space, whereas both would be good members of att.responsability? Laurent D?but du message r?exp?di? : > De : Christian-Emil Ore <c.e.s.ore at ILN.UIO.NO> > Date : 25 juin 2010 10:53:07 GMT+02:00 > ? : TEI-L at listserv.brown.edu > Objet : linkGrp > R?pondre ? : c.e.s.ore at ILN.UIO.NO > > Dear all, > In P4 the element <linkGrp> may have the attribute 'resp'. In P5 it > cannot. Is this a work accident or is it intended? > > Regards, > Christian-Emil Ore Laurent Romary INRIA & HUB-IDSL laurent.romary at inria.fr From elena.pierazzo at kcl.ac.uk Fri Jun 25 09:48:04 2010 From: elena.pierazzo at kcl.ac.uk (Elena Pierazzo) Date: Fri, 25 Jun 2010 14:48:04 +0100 Subject: [tei-council] Content for <pb/> etc. [was: soft hyphens (again)] In-Reply-To: <4C1F8922.9070404@kcl.ac.uk> References: <4BF606D3.7050603@ultraslavonic.info> <4BF9A302.1030108@oucs.ox.ac.uk> <4C0BCE46.1080008@ultraslavonic.info> <4C179B78.7060706@ultraslavonic.info> <4C17A51C.4040908@oucs.ox.ac.uk> <4C17C4ED.5090703@ultraslavonic.info> <4C1E8381.6090007@ultraslavonic.info> <4C1F6E15.7000908@kcl.ac.uk> <4C1F7F1B.9020006@ultraslavonic.info> <4C1F8922.9070404@kcl.ac.uk> Message-ID: <4C24B394.9020407@kcl.ac.uk> Sorry if I intervene only now, but I have a case for which a content (even a textual content!!) for <pb/> might be very important. When you transcribe manuscripts you want to be able to record paginations and foliation for which you normally would use <pb n="my page number"/>. But what happens when there is a correction on a page number? I have found this case and many others while working on Austen manuscripts. Here is the cases we found: - page number missing (in a manuscript that normally has page numbers): it would be good to be able to use <pb><supplied>45</supplied></pb> (or similar) - page number corrected: Austen write 78 the correct the 8 into 7: <pb>7<subst><del>8</del><add>7</add></subst></pb/> - page number is wrong: Austen write 56 per 57: <pb>5<choice><sic>6</sic><corr>7</corr></choice></pb> One of the leading idea behind P5 was to move any textual content from attributes to element, I think the <pb> has escaped this revision. While <lb/> have numbers that are rarely written on the page, page numbers are often actual symbols on the page and therefore an editor would like to be able to transcribe them with all the possible features they may have (correction. alteration, underlining, etc.), in the same way one can transcribe other words written by the author. Elena Gabriel Bodard wrote: > On 21/06/2010 16:02, Kevin Hawkins wrote: > >> I'm afraid I still don't understand. Are these elements no longer empty >> elements? They still appear that way even in Sebastian's test release. >> When did this change happen? >> > > Which elements? <gap/> (always an "empty"--i.e. permitting no > text-content--element), has taken a child <desc> ever since P5 first > release; <space/> for some reason did not, although it does now. Both > also take <certainty/>, <precision/> etc. It makes sense to me that a > so-called empty element could contain another non-text-bearing element > such as <certainty/>, which in this case serves as a much richer > analogue to a cert attribute. > > At the moment, of course, <lb/> and the other milestoneLike elements are > still literally empty, but I am arguing (lightly, as I don't have a > specific use-case for them) that they could just as rationally be > allowed to take a child from the certainty class, although still no text > content, of course. > > Sorry if this was confusing. > > G > > -- Dr Elena Pierazzo Research Associate Centre for Computing in the Humanities King's College London 26-29 Drury Lane London WC2B 5RL Phone: 0207-848-1949 Fax: 0207-848-2980 elena.pierazzo[at]kcl.ac.uk www.kcl.ac.uk/cch From lou.burnard at oucs.ox.ac.uk Fri Jun 25 11:27:16 2010 From: lou.burnard at oucs.ox.ac.uk (Lou) Date: Fri, 25 Jun 2010 16:27:16 +0100 Subject: [tei-council] Content for <pb/> etc. [was: soft hyphens (again)] In-Reply-To: <4C24B394.9020407@kcl.ac.uk> References: <4BF606D3.7050603@ultraslavonic.info> <4BF9A302.1030108@oucs.ox.ac.uk> <4C0BCE46.1080008@ultraslavonic.info> <4C179B78.7060706@ultraslavonic.info> <4C17A51C.4040908@oucs.ox.ac.uk> <4C17C4ED.5090703@ultraslavonic.info> <4C1E8381.6090007@ultraslavonic.info> <4C1F6E15.7000908@kcl.ac.uk> <4C1F7F1B.9020006@ultraslavonic.info> <4C1F8922.9070404@kcl.ac.uk> <4C24B394.9020407@kcl.ac.uk> Message-ID: <4C24CAD4.9090903@oucs.ox.ac.uk> The equivalent tag for printed materials would be <fw> and it seems to me less of a stretch to the semantics of <fw> to say it can be used for this purpose, than it does for <pb/> which is a milestone element not intended to do anything except mark a point where the value in some reference scheme changes. <pb> is a textual marker, not a documentary one. Elena Pierazzo wrote: > Sorry if I intervene only now, but I have a case for which a content > (even a textual content!!) for <pb/> might be very important. > > When you transcribe manuscripts you want to be able to record > paginations and foliation for which you normally would use <pb n="my > page number"/>. > But what happens when there is a correction on a page number? I have > found this case and many others while working on Austen manuscripts. > Here is the cases we found: > > - page number missing (in a manuscript that normally has page numbers): > it would be good to be able to use <pb><supplied>45</supplied></pb> (or > similar) > - page number corrected: Austen write 78 the correct the 8 into 7: > <pb>7<subst><del>8</del><add>7</add></subst></pb/> > - page number is wrong: Austen write 56 per 57: > <pb>5<choice><sic>6</sic><corr>7</corr></choice></pb> > > One of the leading idea behind P5 was to move any textual content from > attributes to element, I think the <pb> has escaped this revision. While > <lb/> have numbers that are rarely written on the page, page numbers are > often actual symbols on the page and therefore an editor would like to > be able to transcribe them with all the possible features they may have > (correction. alteration, underlining, etc.), in the same way one can > transcribe other words written by the author. > > Elena > > > Gabriel Bodard wrote: >> On 21/06/2010 16:02, Kevin Hawkins wrote: >> >>> I'm afraid I still don't understand. Are these elements no longer empty >>> elements? They still appear that way even in Sebastian's test release. >>> When did this change happen? >>> >> Which elements? <gap/> (always an "empty"--i.e. permitting no >> text-content--element), has taken a child <desc> ever since P5 first >> release; <space/> for some reason did not, although it does now. Both >> also take <certainty/>, <precision/> etc. It makes sense to me that a >> so-called empty element could contain another non-text-bearing element >> such as <certainty/>, which in this case serves as a much richer >> analogue to a cert attribute. >> >> At the moment, of course, <lb/> and the other milestoneLike elements are >> still literally empty, but I am arguing (lightly, as I don't have a >> specific use-case for them) that they could just as rationally be >> allowed to take a child from the certainty class, although still no text >> content, of course. >> >> Sorry if this was confusing. >> >> G >> >> > From mholmes at uvic.ca Fri Jun 25 13:02:26 2010 From: mholmes at uvic.ca (Martin Holmes) Date: Fri, 25 Jun 2010 10:02:26 -0700 Subject: [tei-council] Content for <pb/> etc. [was: soft hyphens (again)] In-Reply-To: <4C24B394.9020407@kcl.ac.uk> References: <4BF606D3.7050603@ultraslavonic.info> <4BF9A302.1030108@oucs.ox.ac.uk> <4C0BCE46.1080008@ultraslavonic.info> <4C179B78.7060706@ultraslavonic.info> <4C17A51C.4040908@oucs.ox.ac.uk> <4C17C4ED.5090703@ultraslavonic.info> <4C1E8381.6090007@ultraslavonic.info> <4C1F6E15.7000908@kcl.ac.uk> <4C1F7F1B.9020006@ultraslavonic.info> <4C1F8922.9070404@kcl.ac.uk> <4C24B394.9020407@kcl.ac.uk> Message-ID: <4C24E122.9000700@uvic.ca> Wouldn't we want to distinguish between <pb/>, which is a page _break_, and <fw type="pageNum">, in which one would include the page number that actually appears (wrong or not)? Cheers, Martin On 10-06-25 06:48 AM, Elena Pierazzo wrote: > Sorry if I intervene only now, but I have a case for which a content > (even a textual content!!) for<pb/> might be very important. > > When you transcribe manuscripts you want to be able to record > paginations and foliation for which you normally would use<pb n="my > page number"/>. > But what happens when there is a correction on a page number? I have > found this case and many others while working on Austen manuscripts. > Here is the cases we found: > > - page number missing (in a manuscript that normally has page numbers): > it would be good to be able to use<pb><supplied>45</supplied></pb> (or > similar) > - page number corrected: Austen write 78 the correct the 8 into 7: > <pb>7<subst><del>8</del><add>7</add></subst></pb/> > - page number is wrong: Austen write 56 per 57: > <pb>5<choice><sic>6</sic><corr>7</corr></choice></pb> > > One of the leading idea behind P5 was to move any textual content from > attributes to element, I think the<pb> has escaped this revision. While > <lb/> have numbers that are rarely written on the page, page numbers are > often actual symbols on the page and therefore an editor would like to > be able to transcribe them with all the possible features they may have > (correction. alteration, underlining, etc.), in the same way one can > transcribe other words written by the author. > > Elena > > > Gabriel Bodard wrote: >> On 21/06/2010 16:02, Kevin Hawkins wrote: >> >>> I'm afraid I still don't understand. Are these elements no longer empty >>> elements? They still appear that way even in Sebastian's test release. >>> When did this change happen? >>> >> >> Which elements?<gap/> (always an "empty"--i.e. permitting no >> text-content--element), has taken a child<desc> ever since P5 first >> release;<space/> for some reason did not, although it does now. Both >> also take<certainty/>,<precision/> etc. It makes sense to me that a >> so-called empty element could contain another non-text-bearing element >> such as<certainty/>, which in this case serves as a much richer >> analogue to a cert attribute. >> >> At the moment, of course,<lb/> and the other milestoneLike elements are >> still literally empty, but I am arguing (lightly, as I don't have a >> specific use-case for them) that they could just as rationally be >> allowed to take a child from the certainty class, although still no text >> content, of course. >> >> Sorry if this was confusing. >> >> G >> >> > -- Martin Holmes University of Victoria Humanities Computing and Media Centre (mholmes at uvic.ca) Half-Baked Software, Inc. (mholmes at halfbakedsoftware.com) martin at mholmes.com From daniel.odonnell at uleth.ca Fri Jun 25 11:57:30 2010 From: daniel.odonnell at uleth.ca (O'Donnell, Dan) Date: Fri, 25 Jun 2010 09:57:30 -0600 Subject: [tei-council] Content for <pb/> etc. [was: soft hyphens (again)] In-Reply-To: <4C24B394.9020407@kcl.ac.uk> References: <4BF606D3.7050603@ultraslavonic.info> <4BF9A302.1030108@oucs.ox.ac.uk> <4C0BCE46.1080008@ultraslavonic.info> <4C179B78.7060706@ultraslavonic.info> <4C17A51C.4040908@oucs.ox.ac.uk> <4C17C4ED.5090703@ultraslavonic.info> <4C1E8381.6090007@ultraslavonic.info> <4C1F6E15.7000908@kcl.ac.uk> <4C1F7F1B.9020006@ultraslavonic.info> <4C1F8922.9070404@kcl.ac.uk> <4C24B394.9020407@kcl.ac.uk> Message-ID: <4C24D1EA.8010701@uleth.ca> On 10-06-25 07:48 AM, Elena Pierazzo wrote: > Sorry if I intervene only now, but I have a case for which a content > (even a textual content!!) for<pb/> might be very important. > > When you transcribe manuscripts you want to be able to record > paginations and foliation for which you normally would use<pb n="my > page number"/>. > But what happens when there is a correction on a page number? I have > found this case and many others while working on Austen manuscripts. > Here is the cases we found: > > - page number missing (in a manuscript that normally has page numbers): > it would be good to be able to use<pb><supplied>45</supplied></pb> (or > similar) > - page number corrected: Austen write 78 the correct the 8 into 7: > <pb>7<subst><del>8</del><add>7</add></subst></pb/> > - page number is wrong: Austen write 56 per 57: > <pb>5<choice><sic>6</sic><corr>7</corr></choice></pb> > Interesting question. I guess I'd ask, from a theoretical perspective, whether pb/@n is not supposed to refer to an editorially determined number rather than text in the witness, whereas the example you are discussing is really content. I.e. if @n is not metadata and Austen's mistakes and corrections content. For me, pb has always been a meta-data tag describing the concept of a page break rather than actual textual content. If you go with your interpretation, it raises other questions. For example, if Austen writes her page numbers in the bottom corner, should you use pb to mark the ends of pages rather than the beginning? Or if, as also happens, you end up with multiple paginations in multiple places (top right, corrected in bottom right, for example), what happens. It seems to me if the goal is to record the fact that the witness has some interesting pagination content, that should be treated as part of the content rather than part of pb--this is a great place for the new genetic module proposal. A place where pb/@n is not adequate even from a strictly theoretical perspective is when a document has multiple canonical/historical/editorial paginations. E.g. when the actual pagination is in dispute or has changed over time (e.g. as happens in some manuscripts that have been rebound over time or lost pages). > One of the leading idea behind P5 was to move any textual content from > attributes to element, I think the<pb> has escaped this revision. While > <lb/> have numbers that are rarely written on the page, page numbers are > often actual symbols on the page and therefore an editor would like to > be able to transcribe them with all the possible features they may have > (correction. alteration, underlining, etc.), in the same way one can > transcribe other words written by the author. > I think whatever we do, it should be allowed for all the *b/ elements: page numbers may be more common than with others, but lines and columns (and quires and every other kind of break) do show up with the same problems, so whatever the solution, it's just inviting trouble if we don't allow it for all the relevant milestones. > Elena > > > Gabriel Bodard wrote: > >> On 21/06/2010 16:02, Kevin Hawkins wrote: >> >> >>> I'm afraid I still don't understand. Are these elements no longer empty >>> elements? They still appear that way even in Sebastian's test release. >>> When did this change happen? >>> >>> >> Which elements?<gap/> (always an "empty"--i.e. permitting no >> text-content--element), has taken a child<desc> ever since P5 first >> release;<space/> for some reason did not, although it does now. Both >> also take<certainty/>,<precision/> etc. It makes sense to me that a >> so-called empty element could contain another non-text-bearing element >> such as<certainty/>, which in this case serves as a much richer >> analogue to a cert attribute. >> >> At the moment, of course,<lb/> and the other milestoneLike elements are >> still literally empty, but I am arguing (lightly, as I don't have a >> specific use-case for them) that they could just as rationally be >> allowed to take a child from the certainty class, although still no text >> content, of course. >> >> Sorry if this was confusing. >> >> G >> >> >> > -- Daniel Paul O'Donnell Professor of English University of Lethbridge Chair and CEO, Text Encoding Initiative (http://www.tei-c.org/) Co-Chair, Digital Initiatives Advisory Board, Medieval Academy of America President-elect (English), Society for Digital Humanities/Soci?t? pour l'?tude des m?dias interactifs (http://sdh-semi.org/) Founding Director (2003-2009), Digital Medievalist Project (http://www.digitalmedievalist.org/) Vox: +1 403 329-2377 Fax: +1 403 382-7191 (non-confidential) Home Page: http://people.uleth.ca/~daniel.odonnell/ From dot.porter at gmail.com Fri Jun 25 21:33:44 2010 From: dot.porter at gmail.com (Dot Porter) Date: Fri, 25 Jun 2010 21:33:44 -0400 Subject: [tei-council] Content for <pb/> etc. [was: soft hyphens (again)] In-Reply-To: <4C24E122.9000700@uvic.ca> References: <4BF606D3.7050603@ultraslavonic.info> <4BF9A302.1030108@oucs.ox.ac.uk> <4C0BCE46.1080008@ultraslavonic.info> <4C179B78.7060706@ultraslavonic.info> <4C17A51C.4040908@oucs.ox.ac.uk> <4C17C4ED.5090703@ultraslavonic.info> <4C1E8381.6090007@ultraslavonic.info> <4C1F6E15.7000908@kcl.ac.uk> <4C1F7F1B.9020006@ultraslavonic.info> <4C1F8922.9070404@kcl.ac.uk> <4C24B394.9020407@kcl.ac.uk> <4C24E122.9000700@uvic.ca> Message-ID: <AANLkTikVEOAv8by7SUG3CEuqvbTEFEJYpFKhTYpg1tGe@mail.gmail.com> I'm going with Lou and Martin on this - <pb/> is metadata to mark where one page ends and another page begins, while <fw type="'pageNum"> (or similar) would be used to mark whatever is written as the page numbering on the physical page. Dot On Fri, Jun 25, 2010 at 1:02 PM, Martin Holmes <mholmes at uvic.ca> wrote: > Wouldn't we want to distinguish between <pb/>, which is a page _break_, > and <fw type="pageNum">, in which one would include the page number that > actually appears (wrong or not)? > > Cheers, > Martin > > On 10-06-25 06:48 AM, Elena Pierazzo wrote: > > Sorry if I intervene only now, but I have a case for which a content > > (even a textual content!!) for<pb/> might be very important. > > > > When you transcribe manuscripts you want to be able to record > > paginations and foliation for which you normally would use<pb n="my > > page number"/>. > > But what happens when there is a correction on a page number? I have > > found this case and many others while working on Austen manuscripts. > > Here is the cases we found: > > > > - page number missing (in a manuscript that normally has page numbers): > > it would be good to be able to use<pb><supplied>45</supplied></pb> (or > > similar) > > - page number corrected: Austen write 78 the correct the 8 into 7: > > <pb>7<subst><del>8</del><add>7</add></subst></pb/> > > - page number is wrong: Austen write 56 per 57: > > <pb>5<choice><sic>6</sic><corr>7</corr></choice></pb> > > > > One of the leading idea behind P5 was to move any textual content from > > attributes to element, I think the<pb> has escaped this revision. While > > <lb/> have numbers that are rarely written on the page, page numbers are > > often actual symbols on the page and therefore an editor would like to > > be able to transcribe them with all the possible features they may have > > (correction. alteration, underlining, etc.), in the same way one can > > transcribe other words written by the author. > > > > Elena > > > > > > Gabriel Bodard wrote: > >> On 21/06/2010 16:02, Kevin Hawkins wrote: > >> > >>> I'm afraid I still don't understand. Are these elements no longer > empty > >>> elements? They still appear that way even in Sebastian's test release. > >>> When did this change happen? > >>> > >> > >> Which elements?<gap/> (always an "empty"--i.e. permitting no > >> text-content--element), has taken a child<desc> ever since P5 first > >> release;<space/> for some reason did not, although it does now. Both > >> also take<certainty/>,<precision/> etc. It makes sense to me that a > >> so-called empty element could contain another non-text-bearing element > >> such as<certainty/>, which in this case serves as a much richer > >> analogue to a cert attribute. > >> > >> At the moment, of course,<lb/> and the other milestoneLike elements are > >> still literally empty, but I am arguing (lightly, as I don't have a > >> specific use-case for them) that they could just as rationally be > >> allowed to take a child from the certainty class, although still no text > >> content, of course. > >> > >> Sorry if this was confusing. > >> > >> G > >> > >> > > > > -- > Martin Holmes > University of Victoria Humanities Computing and Media Centre > (mholmes at uvic.ca) > Half-Baked Software, Inc. > (mholmes at halfbakedsoftware.com) > martin at mholmes.com > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > -- *~*~*~*~*~*~*~*~*~*~* Dot Porter (MA, MSLS) Digital Medievalist, Digital Librarian Email: dot.porter at gmail.com *~*~*~*~*~*~*~*~*~*~* From kevin.s.hawkins at ultraslavonic.info Sun Jun 27 11:14:40 2010 From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins) Date: Sun, 27 Jun 2010 11:14:40 -0400 Subject: [tei-council] Content for <pb/> etc. [was: soft hyphens (again)] In-Reply-To: <AANLkTikVEOAv8by7SUG3CEuqvbTEFEJYpFKhTYpg1tGe@mail.gmail.com> References: <4BF606D3.7050603@ultraslavonic.info> <4BF9A302.1030108@oucs.ox.ac.uk> <4C0BCE46.1080008@ultraslavonic.info> <4C179B78.7060706@ultraslavonic.info> <4C17A51C.4040908@oucs.ox.ac.uk> <4C17C4ED.5090703@ultraslavonic.info> <4C1E8381.6090007@ultraslavonic.info> <4C1F6E15.7000908@kcl.ac.uk> <4C1F7F1B.9020006@ultraslavonic.info> <4C1F8922.9070404@kcl.ac.uk> <4C24B394.9020407@kcl.ac.uk> <4C24E122.9000700@uvic.ca> <AANLkTikVEOAv8by7SUG3CEuqvbTEFEJYpFKhTYpg1tGe@mail.gmail.com> Message-ID: <4C276AE0.5090202@ultraslavonic.info> Our discussion has wandered quite a bit, so let me try to summarize the ideas so far ... I want to know how to encode a hyphen that occurs at a line, column, or page break and whose status with respect to breaking a word is unclear. We had settled on doing this with <lb type="?"/>, <cb type="?"/>, and <pb type="?"/> but needed a value that doesn't imply that we are uncertain of whether a line break, column break, or page break occurs here. Martin suggested we invent an element to surround the hyphen and put the @type on this element rather than on the following <lb/>, <cb/>, or <pb/>. Lou noted this would lead to two different ways of encoding a hyphen and noted that there might be a different character or no character at all marking (or not marking) the point of continuation. Lou suggested three options (which I've clarified): 1. come up with a better word than "uncertain" for the type attribute, such as "wbsu" or "wordBreakStatusUnknown" 2. create a new attribute @wordBreaking, whose value could be true|false|unknown 3. redefine the semantics of @type="inWord" to mean just "this is probably a word breaker but possibly between words" I supported (1) for P5 but suggested a fourth option: 4. redefine the semantics of @type='betweenWords' to mean just "this is probably between words but possibly a word breaker" Gabby suggested that we do to <lb/>, <cb/>, and <pb/> what has already been done to <gap> and <space>: allow <certainty>, <precision>, etc. as content. That way if are *unsure whether a break actually occurs*, you could have something like: <lb> <certainty locus="break" degree="0.5"/> </lb> leaving the following way to express that we're *uncertain of the type of hyphen*: Some people say TEI is a mark-<lb type="uncertain"/>up language. Elena supported Gabby's change to content models since it would also work to handle missing, corrected, and incorrect page or line numbers, but Lou, Martin, and Dot said to use <fw> for representing numbering as it appears in the source. *** I still support (1). Gabby asked whether anyone would characterize breaks by anything other than whether they break words, and I too am having trouble imagining being uncertain whether a line, column, or page break actually *occurs* in a source. Therefore, I'm not too concerned with expanding the content model of <lb/>, <cb/>, and <pb/>. From kevin.s.hawkins at ultraslavonic.info Sun Jun 27 16:53:58 2010 From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins) Date: Sun, 27 Jun 2010 16:53:58 -0400 Subject: [tei-council] soft hyphens (again) In-Reply-To: <4C18A267.5000708@kcl.ac.uk> References: <4BF606D3.7050603@ultraslavonic.info> <4BF9A302.1030108@oucs.ox.ac.uk> <4C0BCE46.1080008@ultraslavonic.info> <4C179B78.7060706@ultraslavonic.info> <4C17A51C.4040908@oucs.ox.ac.uk> <4C18A267.5000708@kcl.ac.uk> Message-ID: <4C27BA66.5050105@ultraslavonic.info> On 6/16/2010 6:07 AM, Gabriel Bodard wrote: > Has anyone ever had any use-case for characterizing linebreaks (and cb, > pb, etc.) other than by whether they break works or not? I asked Paul Schaffner about this, and he offered the following: -- use of @type to distinguish word-breaking from in-word <lb>s seems to me a little strange to begin with. I should think that there are lots of other ways in which lines differ (and therefore their breaks differ) other than whether they occurr in a word-dividing position. And that some of those ways are a more natural fit for @type. E.g. ="forced" (by lack of space) vs. ="deliberate"; or "significant" vs. "insignificant"; or "vertical" vs. (whatever--line breaks can appear between lines in all sorts of formatted text, e.g. chunks of a 'scroll'-style heading in engravings are most easily divided by <lb>s, even though one such 'line' does not sit neatly below the previous one). -- the trio of "inWord" "betweenWords" and "uncertain" may not express all the options. One might want to distinguish (e.g.) (?) street<lb/>walker between components of a non-hyphenated cpd bag<lb/>lady between components of a usu. hyphenated cpd win<lb/>some between syllables (or morphemes) in a single word iP<lb/>hone word-internal breaks (misplaced according to usual rules*) gentle<lb/>man may or may not be regarded as a compound abusive<lb/>tagger between words (*this is the way that the WSJ breaks "iPhone" at line ends, for some reason) though I have to admit that when tagging inscriptions (or rather, when tagging transcriptions of inscriptions), my commonest need is to distinguish breaks that should be treated as word breaks, those that should not be, and those about which I have doubts. From mholmes at uvic.ca Mon Jun 28 12:17:00 2010 From: mholmes at uvic.ca (Martin Holmes) Date: Mon, 28 Jun 2010 09:17:00 -0700 Subject: [tei-council] soft hyphens (again) In-Reply-To: <4C27BA66.5050105@ultraslavonic.info> References: <4BF606D3.7050603@ultraslavonic.info> <4BF9A302.1030108@oucs.ox.ac.uk> <4C0BCE46.1080008@ultraslavonic.info> <4C179B78.7060706@ultraslavonic.info> <4C17A51C.4040908@oucs.ox.ac.uk> <4C18A267.5000708@kcl.ac.uk> <4C27BA66.5050105@ultraslavonic.info> Message-ID: <4C28CAFC.1040707@uvic.ca> Taking Paul's examples: <phr>street<lb/>walker</phr> between components of a non-hyphenated cpd <phr type="hyphenated">bag-<lb/>lady</phr> between components of a usu. hyphenated cpd <w>win-<lb/>some</w> between syllables (or morphemes) in a single word <w>iP-<lb/>hone</w> word-internal breaks (misplaced according to usual rules*) gentle<lb/>man may or may not be regarded as a compound <w>abusive</w>-<lb/><w>tagger</w> between words Lou responded to my previous message like this: > But the issue currently on the table is what to do about LINEBREAKS. As > I said in an earlier post, it isn't necessarily a hyphen character which > is used to mark where a word (despite appearances) runs on to the next > line. It may be something else entirely. It may be nothing at all. At the risk of another roasting, I still think that the linebreak tag is the wrong place to supply information about whatever-it-is-that-is-being-broken (word, phrase or whatever) and whatever-it-is-that-is-signalling-the-break (hyphen or whatever). The linebreak tag says there is a linebreak in the text. The context, and the glyph that precedes the linebreak, are not attributes of the linebreak. I think it would be better to encourage the use of <w>, <phr> and other inline-level tags to mark the context of the linebreak. Even if such tags are not being used for any other purpose in a text -- or perhaps _especially_ if they aren't -- they could be used for exactly this purpose, and it's easy for a processor to detect when a linebreak-signalling glyph or a linebreak tag occur within such contexts and process accordingly. Cheers, Martin On 10-06-27 01:53 PM, Kevin Hawkins wrote: > street<lb/>walker between components of a non-hyphenated cpd > bag<lb/>lady between components of a usu. hyphenated cpd > win<lb/>some between syllables (or morphemes) in a single word > iP<lb/>hone word-internal breaks (misplaced according to usual rules*) > gentle<lb/>man may or may not be regarded as a compound > abusive<lb/>tagger between words -- Martin Holmes University of Victoria Humanities Computing and Media Centre (mholmes at uvic.ca) Half-Baked Software, Inc. (mholmes at halfbakedsoftware.com) martin at mholmes.com From mholmes at uvic.ca Mon Jun 28 12:18:55 2010 From: mholmes at uvic.ca (Martin Holmes) Date: Mon, 28 Jun 2010 09:18:55 -0700 Subject: [tei-council] soft hyphens (again) In-Reply-To: <4C28CAFC.1040707@uvic.ca> References: <4BF606D3.7050603@ultraslavonic.info> <4BF9A302.1030108@oucs.ox.ac.uk> <4C0BCE46.1080008@ultraslavonic.info> <4C179B78.7060706@ultraslavonic.info> <4C17A51C.4040908@oucs.ox.ac.uk> <4C18A267.5000708@kcl.ac.uk> <4C27BA66.5050105@ultraslavonic.info> <4C28CAFC.1040707@uvic.ca> Message-ID: <4C28CB6F.2040800@uvic.ca> Forgot one instance: >gentle<lb/>man may or may not be regarded as a compound In this case, there are two competing possibilities for markup, so a <choice> element would be appropriate. Cheers, Martin On 10-06-28 09:17 AM, Martin Holmes wrote: > gentle<lb/>man may or may not be regarded as a compound -- Martin Holmes University of Victoria Humanities Computing and Media Centre (mholmes at uvic.ca) Half-Baked Software, Inc. (mholmes at halfbakedsoftware.com) martin at mholmes.com From kevin.s.hawkins at ultraslavonic.info Mon Jun 28 17:00:59 2010 From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins) Date: Mon, 28 Jun 2010 17:00:59 -0400 Subject: [tei-council] its release time In-Reply-To: <F466390F-E6D2-4547-BF01-1823275A9330@oucs.ox.ac.uk> References: <F466390F-E6D2-4547-BF01-1823275A9330@oucs.ox.ac.uk> Message-ID: <4C290D8B.1020601@ultraslavonic.info> *Sebastian*: Have you made added the Google search code to the stylesheets to have the same search box as on the rest of www.tei-c.org? (We decided to do this in Dublin; see the email that David Sewell sent on 2010-05-10 and the ensuing thread.) *Lou*: I see you've made some of the revisions that came out of the Ad-Hoc Committee on Encoding of Bibliographic Citations, based on the discussion in Dublin. The committee is waiting for the go-ahead from you to produce a second proposal for Council (just those issues which are controversial, plus revisions based on discussion in Dublin), which we were supposed to have produced by June 15. It would be great if you finished your part before Sebastian releases. Kevin On 6/18/2010 1:33 PM, Sebastian Rahtz wrote: > I would like to make a new TEI release in the first week of July. Would people like to start checking that things which should have been done have been done? > > you can start looking at http://tei.oucs.ox.ac.uk/release/doc/tei-p5-doc/en/html/, which reflects the current state. > -- > Sebastian Rahtz > Information Manager, Oxford University Computing Services > 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 > > S?lo le pido a Dios > que el futuro no me sea indiferente > > > > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council From sebastian.rahtz at oucs.ox.ac.uk Mon Jun 28 17:08:51 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 28 Jun 2010 22:08:51 +0100 Subject: [tei-council] its release time In-Reply-To: <4C290D8B.1020601@ultraslavonic.info> References: <F466390F-E6D2-4547-BF01-1823275A9330@oucs.ox.ac.uk> <4C290D8B.1020601@ultraslavonic.info> Message-ID: <3C6CAF2B-6F41-480F-948E-B60C2DB7F6E0@oucs.ox.ac.uk> On 28 Jun 2010, at 22:00, Kevin Hawkins wrote: > *Sebastian*: Have you made added the Google search code to the > stylesheets to have the same search box as on the rest of www.tei-c.org? > (We decided to do this in Dublin; see the email that David Sewell sent > on 2010-05-10 and the ensuing thread.) I believe I have, yes. I'll put up a test -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From lou.burnard at oucs.ox.ac.uk Mon Jun 28 17:37:28 2010 From: lou.burnard at oucs.ox.ac.uk (Lou Burnard) Date: Mon, 28 Jun 2010 22:37:28 +0100 Subject: [tei-council] its release time In-Reply-To: <4C290D8B.1020601@ultraslavonic.info> References: <F466390F-E6D2-4547-BF01-1823275A9330@oucs.ox.ac.uk> <4C290D8B.1020601@ultraslavonic.info> Message-ID: <4C291618.9010606@oucs.ox.ac.uk> Kevin Hawkins wrote: > Lou*: I see you've made some of the revisions that came out of the > Ad-Hoc Committee on Encoding of Bibliographic Citations, based on the > discussion in Dublin. The committee is waiting for the go-ahead from > you to produce a second proposal for Council (just those issues which > are controversial, plus revisions based on discussion in Dublin), which > we were supposed to have produced by June 15. It would be great if you > finished your part before Sebastian releases. > > Sorry, this has slipped down my agenda a bit due to other work. There seemed to be some difference of opinion within the Ad Hoc committee in the discussion at Dublin, which makes me a bit cautious about making many more substantative revisions. I'll try to have another look before the release date, but no promises. From sebastian.rahtz at oucs.ox.ac.uk Mon Jun 28 17:39:48 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 28 Jun 2010 22:39:48 +0100 Subject: [tei-council] its release time In-Reply-To: <4C290D8B.1020601@ultraslavonic.info> References: <F466390F-E6D2-4547-BF01-1823275A9330@oucs.ox.ac.uk> <4C290D8B.1020601@ultraslavonic.info> Message-ID: <B2CDD141-618C-4C35-8E3C-295ABF0BADC5@oucs.ox.ac.uk> On 28 Jun 2010, at 22:00, Kevin Hawkins wrote: > *Sebastian*: Have you made added the Google search code to the > stylesheets to have the same search box as on the rest of www.tei-c.org? > (We decided to do this in Dublin; see the email that David Sewell sent > on 2010-05-10 and the ensuing thread.) > see http://tei.oucs.ox.ac.uk/release/doc/tei-p5-doc/en/html/ now -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From kevin.s.hawkins at ultraslavonic.info Tue Jun 29 09:20:33 2010 From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins) Date: Tue, 29 Jun 2010 09:20:33 -0400 Subject: [tei-council] its release time In-Reply-To: <4C291618.9010606@oucs.ox.ac.uk> References: <F466390F-E6D2-4547-BF01-1823275A9330@oucs.ox.ac.uk> <4C290D8B.1020601@ultraslavonic.info> <4C291618.9010606@oucs.ox.ac.uk> Message-ID: <4C29F321.4050809@ultraslavonic.info> On 6/28/2010 5:37 PM, Lou Burnard wrote: > Kevin Hawkins wrote: >> Lou*: I see you've made some of the revisions that came out of the >> Ad-Hoc Committee on Encoding of Bibliographic Citations, based on the >> discussion in Dublin. The committee is waiting for the go-ahead from >> you to produce a second proposal for Council (just those issues which >> are controversial, plus revisions based on discussion in Dublin), >> which we were supposed to have produced by June 15. It would be great >> if you finished your part before Sebastian releases. >> > Sorry, this has slipped down my agenda a bit due to other work. There > seemed to be some difference of opinion within the Ad Hoc committee in > the discussion at Dublin, which makes me a bit cautious about making > many more substantative revisions. I'll try to have another look before > the release date, but no promises. Your caution is warranted since the Laurent, Martin, and I realized a few things while giving the presentation ... plus other Council members brought up objections. Still, we all agreed that you would make whichever revisions you felt comfortable making before we produced a condensed proposal for consideration again. Kevin From sebastian.rahtz at oucs.ox.ac.uk Wed Jun 30 12:47:07 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Wed, 30 Jun 2010 17:47:07 +0100 Subject: [tei-council] its release time In-Reply-To: <4C290D8B.1020601@ultraslavonic.info> References: <F466390F-E6D2-4547-BF01-1823275A9330@oucs.ox.ac.uk> <4C290D8B.1020601@ultraslavonic.info> Message-ID: <2D7BA559-2ADB-4DAB-A229-E2D7A10F44D4@oucs.ox.ac.uk> which reminds me to tell you all that after a lot of revision to the ODD processing stylesheets, I think I am more or less done: * the problem with @xml:id as datatype text has gone * you can use @except or @include on <moduleRef> to list elements you want to get * you can use <elementRef> to pick up elements as you like, regardless of module * <schemaSpec>, <moduleRef> and <elementRef> all have an attribute "source' which tells the processor where to find the version of P5 you want to read * the versions of P5 back to 1.0 are up on the web site and addressable * you can talk about TEI versions with a private URI of "tei:x.y.z" or even "tei:current" (which is effectively the default) there is a test file in Sourceforge at P5/Test/testmeta2010.odd which illustrates usage of most of these features. Of course, as I have said before, all the new stuff is only implemented using the XSLT 2.0 family of stylesheets; this means that it is not available through Roma yet. I hope to have a solution to this before the TEI MM in the autumn, ready for use in the pre-conference workshops. -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From James.Cummings at oucs.ox.ac.uk Wed Jun 30 14:34:22 2010 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Wed, 30 Jun 2010 19:34:22 +0100 Subject: [tei-council] its release time In-Reply-To: <2D7BA559-2ADB-4DAB-A229-E2D7A10F44D4@oucs.ox.ac.uk> References: <F466390F-E6D2-4547-BF01-1823275A9330@oucs.ox.ac.uk> <4C290D8B.1020601@ultraslavonic.info> <2D7BA559-2ADB-4DAB-A229-E2D7A10F44D4@oucs.ox.ac.uk> Message-ID: <4C2B8E2E.7030709@oucs.ox.ac.uk> Sebastian Rahtz wrote: > * the versions of P5 back to 1.0 are up on the web site and addressable Trivial bug: Some of the back versions have the TEI-C navbar other ones don't. Compare for example: http://www.tei-c.org/Vault/P5/1.0.0/doc/tei-p5-doc/en/html/ref-w.html and 1.0.1 which have it with ... well all the rest including current when in the vault which don't have it. e.g. http://www.tei-c.org/Vault/P5/1.5.0/doc/tei-p5-doc/en/html/ref-w.html Is there a relative pathname or something to pull in the navbar that isn't being found? For those of you interested in one of the benefits of this is that it gives a canonical way to refer to the human readable reference for 'w' above and compare its content model across versions. (see above) One can also of course can easily point to the sources for the elements http://www.tei-c.org/Vault/P5/1.0.0/xml/tei/odd/Source/Specs/w.xml vs http://www.tei-c.org/Vault/P5/1.6.0/xml/tei/odd/Source/Specs/w.xml Of course we could do this with SVN, but this is a better way to have a canonical URL at the TEI domain. I can just imagine some lovely applications allowing you to compare and contrast the TEI through the ages. ;-) I wonder if anyone will build any? We should think how to advertise this and point to it on the website itself. -james -- Dr James Cummings, Research Technology Service Oxford University Computing Services University of Oxford From dsewell at virginia.edu Wed Jun 30 14:53:32 2010 From: dsewell at virginia.edu (David Sewell) Date: Wed, 30 Jun 2010 14:53:32 -0400 (EDT) Subject: [tei-council] its release time In-Reply-To: <4C2B8E2E.7030709@oucs.ox.ac.uk> References: <F466390F-E6D2-4547-BF01-1823275A9330@oucs.ox.ac.uk> <4C290D8B.1020601@ultraslavonic.info> <2D7BA559-2ADB-4DAB-A229-E2D7A10F44D4@oucs.ox.ac.uk> <4C2B8E2E.7030709@oucs.ox.ac.uk> Message-ID: <alpine.OSX.2.00.1006301451440.32536@lister.ei.virginia.edu> This is just a note to plead for forbearance if I am slow to deal with any current TEI website issues. This week we are in the midst of (1) physically moving from one office to another, and (2) negotiating with a federal agency on a cooperative agreement for a collaborative publication. In other words, it is total insanity. I should be able to help with website work by this weekend at the latest, David On Wed, 30 Jun 2010, James Cummings wrote: > Sebastian Rahtz wrote: > > > * the versions of P5 back to 1.0 are up on the web site and addressable > > Trivial bug: > > Some of the back versions have the TEI-C navbar other ones don't. > > Compare for example: > http://www.tei-c.org/Vault/P5/1.0.0/doc/tei-p5-doc/en/html/ref-w.html > and 1.0.1 which have it with ... well all the rest including current > when in the vault which don't have it. > e.g. http://www.tei-c.org/Vault/P5/1.5.0/doc/tei-p5-doc/en/html/ref-w.html > > Is there a relative pathname or something to pull in the navbar that > isn't being found? > > For those of you interested in one of the benefits of this is that it > gives a canonical way to refer to the human readable reference for 'w' > above and compare its content model across versions. (see above) One > can also of course can easily point to the sources for the elements > http://www.tei-c.org/Vault/P5/1.0.0/xml/tei/odd/Source/Specs/w.xml > vs > http://www.tei-c.org/Vault/P5/1.6.0/xml/tei/odd/Source/Specs/w.xml > > Of course we could do this with SVN, but this is a better way to have a > canonical URL at the TEI domain. I can just imagine some lovely > applications allowing you to compare and contrast the TEI through the > ages. ;-) I wonder if anyone will build any? We should think how to > advertise this and point to it on the website itself. > > -james > -- David Sewell, Editorial and Technical Manager ROTUNDA, The University of Virginia Press PO Box 801079, Charlottesville, VA 22904-4318 USA Courier: 310 Old Ivy Way, Suite 302, Charlottesville VA 22903 Email: dsewell at virginia.edu Tel: +1 434 924 9973 Web: http://rotunda.upress.virginia.edu/ From sebastian.rahtz at oucs.ox.ac.uk Sat Jul 3 06:45:01 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Sat, 3 Jul 2010 11:45:01 +0100 Subject: [tei-council] its release time In-Reply-To: <4C2B8E2E.7030709@oucs.ox.ac.uk> References: <F466390F-E6D2-4547-BF01-1823275A9330@oucs.ox.ac.uk> <4C290D8B.1020601@ultraslavonic.info> <2D7BA559-2ADB-4DAB-A229-E2D7A10F44D4@oucs.ox.ac.uk> <4C2B8E2E.7030709@oucs.ox.ac.uk> Message-ID: <339F74B3-35A9-4743-963C-BDEEE09C7A1B@oucs.ox.ac.uk> On 30 Jun 2010, at 19:34, James Cummings wrote: > Trivial bug: > > Some of the back versions have the TEI-C navbar other ones don't. I have simply unpacked the release archives from Sourceforge, no more no less. I have not try to reconstruct what would have been done for the TEI web site. the TEIC navbar is a compile-time thing, I recall. -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From dsewell at virginia.edu Wed Jul 14 15:03:04 2010 From: dsewell at virginia.edu (David Sewell) Date: Wed, 14 Jul 2010 15:03:04 -0400 (EDT) Subject: [tei-council] Automated messages to membership@tei-c.org? Message-ID: <alpine.OSX.2.00.1007141459580.78830@lister.ei.virginia.edu> Shayne Brandon and I are trying to diagnose a problem with the membership at tei-c.org email address, which is supposed to deliver to Julia Flanders. It appears that something may be spamming that address many times a day, causing Julia's spam catcher to discard messages. Is anyone aware of legitimate software we have created that sends messages to that email address? I just want to be able to rule out some kind of looping problem that might be causing this, while Shayne checks into originating IP addresses. David -- David Sewell, Editorial and Technical Manager ROTUNDA, The University of Virginia Press PO Box 801079, Charlottesville, VA 22904-4318 USA Courier: 310 Old Ivy Way, Suite 302, Charlottesville VA 22903 Email: dsewell at virginia.edu Tel: +1 434 924 9973 Web: http://rotunda.upress.virginia.edu/ From lou.burnard at oucs.ox.ac.uk Tue Aug 3 10:37:42 2010 From: lou.burnard at oucs.ox.ac.uk (Lou) Date: Tue, 03 Aug 2010 15:37:42 +0100 Subject: [tei-council] [Fwd: [ tei-Bugs-3026868 ] <argument> as child of <titlePage>] Message-ID: <4C5829B6.7090303@oucs.ox.ac.uk> Council members are invited to comment on the table attached to this bug report in the SF repository (assuming that the list won't let me circulate attachments) It shows a number of anomalies about the current members of model.titlepagePart which I will attempt to summarize here 1. The model classes titlepagePart and pLikeFront have identical members, except that * head is a member of pLikeFront but not of titlepagePart * graphic and binaryObject are members of titlepagePart but not of pLikeFront 2. graphic and binaryObject are explicitly members of titlepagePart, whereas it might be more consistent to include them via model.graphicLike 3. imprimatur is a member of titlepagePart but nothing else, which seems odd -- it might appear in front matter outside the titlepage, surely? 4. argument, docAuthor, byline, and epigraph are members of divWrapper (as well as titlepagePart) thus allowing them to appear div-liminally. I suppose this sort of makes sense (you're unlikely to find an imprimatur or any of the doc* things attached to a particular div) but why is docAuthor in the list? 5. argument, byline and epigraph (but not docAuthor) can appear div-liminally within an opener (but not a closer) Comments welcome, here or on the ticket. I'm not proposing any course of action as yet (and I've fixed the bug reported on the ticket) but you may wish to ponder the matter during those long summery evenings hem hem -------------- next part -------------- A non-text attachment was scrubbed... Name: titlePageParts.pdf Type: text/x-moz-deleted Size: 15543 bytes Desc: not available Url : http://lists.village.Virginia.EDU/pipermail/tei-council/attachments/20100803/b270f3c9/attachment.bin -------------- next part -------------- An embedded message was scrubbed... From: SourceForge.net <noreply at sourceforge.net> Subject: [ tei-Bugs-3026868 ] <argument> as child of <titlePage> Date: Tue, 3 Aug 2010 15:13:22 +0100 Size: 4569 Url: http://lists.village.Virginia.EDU/pipermail/tei-council/attachments/20100803/b270f3c9/attachment.eml From kevin.s.hawkins at ultraslavonic.info Thu Aug 5 19:52:37 2010 From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins) Date: Thu, 05 Aug 2010 19:52:37 -0400 Subject: [tei-council] [Fwd: [ tei-Bugs-3026868 ] <argument> as child of <titlePage>] In-Reply-To: <4C5829B6.7090303@oucs.ox.ac.uk> References: <4C5829B6.7090303@oucs.ox.ac.uk> Message-ID: <4C5B4EC5.8060601@ultraslavonic.info> Hi, On 8/3/2010 10:37 AM, Lou wrote: > 1. The model classes titlepagePart and pLikeFront have identical > members, except that > * head is a member of pLikeFront but not of titlepagePart I think we should leave this as is. If someone ever brings us a title page containing headings on it that aren't titles, subtitles, or arguments (as discussed at the end of this message), we can consider changing. > * graphic and binaryObject are members of titlepagePart but not of > pLikeFront I think it makes sense to include these in pLikeFront in order to allow for the encoding of a frontispiece without a caption. > 2. graphic and binaryObject are explicitly members of titlepagePart, > whereas it might be more consistent to include them via model.graphicLike But wouldn't model.graphicLike then need to be included as allowed content of titlePage? It appears that this isn't currently the case. > 3. imprimatur is a member of titlepagePart but nothing else, which seems > odd -- it might appear in front matter outside the titlepage, surely? I say let's wait till someone brings us a document in which the imprimatur occurs somewhere besides the title page. > 4. argument, docAuthor, byline, and epigraph are members of divWrapper > (as well as titlepagePart) thus allowing them to appear div-liminally. I > suppose this sort of makes sense (you're unlikely to find an imprimatur > or any of the doc* things attached to a particular div) but why is > docAuthor in the list? I think docAuthor is here to handle the case of encoding an anthology or journal issue, in which each div has its own author. (While you could wrap an author in byline, this isn't required for titlePage, so I don't think we should require it here. Just like how you don't need a resp wrapped around author.) > 5. argument, byline and epigraph (but not docAuthor) can appear > div-liminally within an opener (but not a closer) These things do appear at the beginning, so that explains why they're in opener and not closer. Seems like we should include docAuthor here as long as we allow it without a wrapping byline elsewhere. > Comments welcome, here or on the ticket. I'm not proposing any course of > action as yet (and I've fixed the bug reported on the ticket) but you > may wish to ponder the matter during those long summery evenings hem hem As for the original bug on the ticket, I have a few comments ... As the ticket creator pointed out, section 4.6 mentions use of argument on title pages; however, this section never again discusses its use, so if we're going to allow it here, we should say something else about how to use it. Since old-fashioned titles were often, in fact, a list of topics addressed, we should give some guidance on choosing among docTitle, titlePart, and argument. I wonder, for example, whether the Pilgrim's Progress example in section 4.6 should be changed so that <titlePart type="desc"> becomes <argument>. Furthermore, argument is defined as "A formal list or prose description of the topics addressed by a subdivision of a text", so if we're going to allow it on title pages, that definition might need to be revised to say something like "A formal list or prose description of topics addressed in the following section or entirety of a text". Kevin From gabriel.bodard at kcl.ac.uk Fri Aug 6 06:57:28 2010 From: gabriel.bodard at kcl.ac.uk (Gabriel Bodard) Date: Fri, 6 Aug 2010 11:57:28 +0100 Subject: [tei-council] its release time In-Reply-To: <2D7BA559-2ADB-4DAB-A229-E2D7A10F44D4@oucs.ox.ac.uk> References: <F466390F-E6D2-4547-BF01-1823275A9330@oucs.ox.ac.uk> <4C290D8B.1020601@ultraslavonic.info> <2D7BA559-2ADB-4DAB-A229-E2D7A10F44D4@oucs.ox.ac.uk> Message-ID: <4C5BEA98.3000709@kcl.ac.uk> I feel as though this is me being stupid, because I've never found the documentation of ODD very easy to digest (not being one to rtfm from start to finish...), but I'm trying to figure out how to use the new feature of including an element (or in this case an attribute class) in ODD, rather than including a module and excluding unwanted elements. (The class I want is att.durations which will give me @dur on tei:date. I don't want anything else.) Help offlist welcome. Thanks, Gabby On 30/06/2010 17:47, Sebastian Rahtz wrote: > which reminds me to tell you all that after a lot of revision to the ODD processing stylesheets, I think > I am more or less done: > > * the problem with @xml:id as datatype text has gone > * you can use @except or @include on<moduleRef> to list elements you want to get > * you can use<elementRef> to pick up elements as you like, regardless of module > *<schemaSpec>,<moduleRef> and<elementRef> all have an attribute "source' which > tells the processor where to find the version of P5 you want to read > * the versions of P5 back to 1.0 are up on the web site and addressable > * you can talk about TEI versions with a private URI of "tei:x.y.z" or even "tei:current" > (which is effectively the default) > > there is a test file in Sourceforge at P5/Test/testmeta2010.odd which illustrates usage of most of these > features. > > Of course, as I have said before, all the new stuff is only implemented using the XSLT 2.0 > family of stylesheets; this means that it is not available through Roma yet. I hope to have > a solution to this before the TEI MM in the autumn, ready for use in the pre-conference > workshops. > -- > Sebastian Rahtz > Information Manager, Oxford University Computing Services > 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 > > S?lo le pido a Dios > que el futuro no me sea indiferente > > > > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council -- Dr Gabriel BODARD (Epigrapher, Digital Classicist, Pirate) Centre for Computing in the Humanities King's College London 26-29 Drury Lane London WC2B 5RL Email: gabriel.bodard at kcl.ac.uk Tel: +44 (0)20 7848 1388 Fax: +44 (0)20 7848 2980 http://www.digitalclassicist.org/ http://www.currentepigraphy.org/ From laurent.romary at inria.fr Fri Aug 6 07:01:36 2010 From: laurent.romary at inria.fr (Laurent Romary) Date: Fri, 6 Aug 2010 13:01:36 +0200 Subject: [tei-council] its release time In-Reply-To: <4C5BEA98.3000709@kcl.ac.uk> References: <F466390F-E6D2-4547-BF01-1823275A9330@oucs.ox.ac.uk> <4C290D8B.1020601@ultraslavonic.info> <2D7BA559-2ADB-4DAB-A229-E2D7A10F44D4@oucs.ox.ac.uk> <4C5BEA98.3000709@kcl.ac.uk> Message-ID: <A2C086D4-038E-4E49-8F7B-3B649EC4D59C@inria.fr> No, no. Help +in+ list. This may help to improve the documentation! Laurent (going through all July FS tickets and comments...) Le 6 ao?t 10 ? 12:57, Gabriel Bodard a ?crit : > I feel as though this is me being stupid, because I've never found the > documentation of ODD very easy to digest (not being one to rtfm from > start to finish...), but I'm trying to figure out how to use the new > feature of including an element (or in this case an attribute class) > in > ODD, rather than including a module and excluding unwanted elements. > > (The class I want is att.durations which will give me @dur on > tei:date. > I don't want anything else.) > > Help offlist welcome. Thanks, > > Gabby > > On 30/06/2010 17:47, Sebastian Rahtz wrote: >> which reminds me to tell you all that after a lot of revision to >> the ODD processing stylesheets, I think >> I am more or less done: >> >> * the problem with @xml:id as datatype text has gone >> * you can use @except or @include on<moduleRef> to list >> elements you want to get >> * you can use<elementRef> to pick up elements as you like, >> regardless of module >> *<schemaSpec>,<moduleRef> and<elementRef> all have an >> attribute "source' which >> tells the processor where to find the version of P5 you want >> to read >> * the versions of P5 back to 1.0 are up on the web site and >> addressable >> * you can talk about TEI versions with a private URI of >> "tei:x.y.z" or even "tei:current" >> (which is effectively the default) >> >> there is a test file in Sourceforge at P5/Test/testmeta2010.odd >> which illustrates usage of most of these >> features. >> >> Of course, as I have said before, all the new stuff is only >> implemented using the XSLT 2.0 >> family of stylesheets; this means that it is not available through >> Roma yet. I hope to have >> a solution to this before the TEI MM in the autumn, ready for use >> in the pre-conference >> workshops. >> -- >> Sebastian Rahtz >> Information Manager, Oxford University Computing Services >> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 >> >> S?lo le pido a Dios >> que el futuro no me sea indiferente >> >> >> >> >> _______________________________________________ >> tei-council mailing list >> tei-council at lists.village.Virginia.EDU >> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > > -- > Dr Gabriel BODARD > (Epigrapher, Digital Classicist, Pirate) > > Centre for Computing in the Humanities > King's College London > 26-29 Drury Lane > London WC2B 5RL > Email: gabriel.bodard at kcl.ac.uk > Tel: +44 (0)20 7848 1388 > Fax: +44 (0)20 7848 2980 > > http://www.digitalclassicist.org/ > http://www.currentepigraphy.org/ > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Laurent Romary INRIA & HUB-IDSL laurent.romary at inria.fr From lou.burnard at oucs.ox.ac.uk Fri Aug 6 08:00:26 2010 From: lou.burnard at oucs.ox.ac.uk (Lou) Date: Fri, 06 Aug 2010 13:00:26 +0100 Subject: [tei-council] its release time In-Reply-To: <4C5BEA98.3000709@kcl.ac.uk> References: <F466390F-E6D2-4547-BF01-1823275A9330@oucs.ox.ac.uk> <4C290D8B.1020601@ultraslavonic.info> <2D7BA559-2ADB-4DAB-A229-E2D7A10F44D4@oucs.ox.ac.uk> <4C5BEA98.3000709@kcl.ac.uk> Message-ID: <4C5BF95A.5040002@oucs.ox.ac.uk> Classes (all of them) are defined by the tei module. If you include that in your schema as well as tei:date, then date will come along with its class memberships. You can of course modify the class as well, if for example you don't want the other attributes in att.duration If you don't include the tei module, you will have to include all the TEI classes you want to use explicitly, using <classRef key="classname"/> for each one. And good luck -- classes have all sorts of tricky interdependencies. Note that including a class in your schema which you don't actually use is benign. Gabriel Bodard wrote: > I feel as though this is me being stupid, because I've never found the > documentation of ODD very easy to digest (not being one to rtfm from > start to finish...), but I'm trying to figure out how to use the new > feature of including an element (or in this case an attribute class) in > ODD, rather than including a module and excluding unwanted elements. > > (The class I want is att.durations which will give me @dur on tei:date. > I don't want anything else.) > > Help offlist welcome. Thanks, > > Gabby > > On 30/06/2010 17:47, Sebastian Rahtz wrote: >> which reminds me to tell you all that after a lot of revision to the ODD processing stylesheets, I think >> I am more or less done: >> >> * the problem with @xml:id as datatype text has gone >> * you can use @except or @include on<moduleRef> to list elements you want to get >> * you can use<elementRef> to pick up elements as you like, regardless of module >> *<schemaSpec>,<moduleRef> and<elementRef> all have an attribute "source' which >> tells the processor where to find the version of P5 you want to read >> * the versions of P5 back to 1.0 are up on the web site and addressable >> * you can talk about TEI versions with a private URI of "tei:x.y.z" or even "tei:current" >> (which is effectively the default) >> >> there is a test file in Sourceforge at P5/Test/testmeta2010.odd which illustrates usage of most of these >> features. >> >> Of course, as I have said before, all the new stuff is only implemented using the XSLT 2.0 >> family of stylesheets; this means that it is not available through Roma yet. I hope to have >> a solution to this before the TEI MM in the autumn, ready for use in the pre-conference >> workshops. >> -- >> Sebastian Rahtz >> Information Manager, Oxford University Computing Services >> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 >> >> S?lo le pido a Dios >> que el futuro no me sea indiferente >> >> >> >> >> _______________________________________________ >> tei-council mailing list >> tei-council at lists.village.Virginia.EDU >> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > From lou.burnard at oucs.ox.ac.uk Fri Aug 6 10:16:33 2010 From: lou.burnard at oucs.ox.ac.uk (Lou) Date: Fri, 06 Aug 2010 15:16:33 +0100 Subject: [tei-council] its release time In-Reply-To: <4C5BF95A.5040002@oucs.ox.ac.uk> References: <F466390F-E6D2-4547-BF01-1823275A9330@oucs.ox.ac.uk> <4C290D8B.1020601@ultraslavonic.info> <2D7BA559-2ADB-4DAB-A229-E2D7A10F44D4@oucs.ox.ac.uk> <4C5BEA98.3000709@kcl.ac.uk> <4C5BF95A.5040002@oucs.ox.ac.uk> Message-ID: <4C5C1941.9060505@oucs.ox.ac.uk> Ooops: in fact it is only *model* classes which are defined by the tei module [1]. Some, but not all, attribute classes are ... att.duration is a particularly ticklish one, because it inherits from att.duration.iso and att.duration.w3c. and is actually fully defined in the spoken module. At the risk of sounding unhelpful -- if you want to specify duration on <date> why not use the iso-when attribute, which allows specification of durations? [1] Thanks to Our man with an Ipad for the correction. Lou wrote: > Classes (all of them) are defined by the tei module. If you include that > in your schema as well as tei:date, then date will come along with its > class memberships. You can of course modify the class as well, if for > example you don't want the other attributes in att.duration > > If you don't include the tei module, you will have to include all the > TEI classes you want to use explicitly, using <classRef > key="classname"/> for each one. > > And good luck -- classes have all sorts of tricky interdependencies. > > Note that including a class in your schema which you don't actually use > is benign. > > Gabriel Bodard wrote: >> I feel as though this is me being stupid, because I've never found the >> documentation of ODD very easy to digest (not being one to rtfm from >> start to finish...), but I'm trying to figure out how to use the new >> feature of including an element (or in this case an attribute class) in >> ODD, rather than including a module and excluding unwanted elements. >> >> (The class I want is att.durations which will give me @dur on tei:date. >> I don't want anything else.) >> >> Help offlist welcome. Thanks, >> >> Gabby >> >> On 30/06/2010 17:47, Sebastian Rahtz wrote: >>> which reminds me to tell you all that after a lot of revision to the ODD processing stylesheets, I think >>> I am more or less done: >>> >>> * the problem with @xml:id as datatype text has gone >>> * you can use @except or @include on<moduleRef> to list elements you want to get >>> * you can use<elementRef> to pick up elements as you like, regardless of module >>> *<schemaSpec>,<moduleRef> and<elementRef> all have an attribute "source' which >>> tells the processor where to find the version of P5 you want to read >>> * the versions of P5 back to 1.0 are up on the web site and addressable >>> * you can talk about TEI versions with a private URI of "tei:x.y.z" or even "tei:current" >>> (which is effectively the default) >>> >>> there is a test file in Sourceforge at P5/Test/testmeta2010.odd which illustrates usage of most of these >>> features. >>> >>> Of course, as I have said before, all the new stuff is only implemented using the XSLT 2.0 >>> family of stylesheets; this means that it is not available through Roma yet. I hope to have >>> a solution to this before the TEI MM in the autumn, ready for use in the pre-conference >>> workshops. >>> -- >>> Sebastian Rahtz >>> Information Manager, Oxford University Computing Services >>> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 >>> >>> S?lo le pido a Dios >>> que el futuro no me sea indiferente >>> >>> >>> >>> >>> _______________________________________________ >>> tei-council mailing list >>> tei-council at lists.village.Virginia.EDU >>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council From sebastian.rahtz at oucs.ox.ac.uk Sun Aug 8 13:26:59 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Sun, 8 Aug 2010 18:26:59 +0100 Subject: [tei-council] its release time In-Reply-To: <4C5BEA98.3000709@kcl.ac.uk> References: <F466390F-E6D2-4547-BF01-1823275A9330@oucs.ox.ac.uk> <4C290D8B.1020601@ultraslavonic.info> <2D7BA559-2ADB-4DAB-A229-E2D7A10F44D4@oucs.ox.ac.uk> <4C5BEA98.3000709@kcl.ac.uk> Message-ID: <CC719892-81DB-4FA9-B78F-51933BF0973D@oucs.ox.ac.uk> On 6 Aug 2010, at 11:57, Gabriel Bodard wrote: > I feel as though this is me being stupid, because I've never found the > documentation of ODD very easy to digest probably because the tutorial about it is unpublished (Lou and I have written such a beast over time, but it has not seen the light of day yet) > (The class I want is att.durations which will give me @dur on tei:date. > I don't want anything else.) you need something like <classRef key="att.duration" /> <classRef key="att.duration.w3c"/> (because att.duration itself is a superclass pointing at att.duration.iso and/or att.duration.w3c) HOWEVER, Lou has found that this does not actually work because of a bug in the XSLT. This has been corrected, but a new stylesheets release is now needed. Many apologies about that. Those who work direct by checking out the stuff from Subversion can proceed as normal. -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From kevin.s.hawkins at ultraslavonic.info Sun Aug 8 13:30:23 2010 From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins) Date: Sun, 08 Aug 2010 13:30:23 -0400 Subject: [tei-council] Lists of Council Members In-Reply-To: <4B95665C.4010607@uleth.ca> References: <4B8D47C0.7050908@oucs.ox.ac.uk> <4B956322.4070403@ultraslavonic.info> <4B95665C.4010607@uleth.ca> Message-ID: <4C5EE9AF.2020608@ultraslavonic.info> This is now in SourceForge: https://sourceforge.net/tracker/?group_id=106328&atid=644065 From kevin.s.hawkins at ultraslavonic.info Sun Aug 8 13:44:08 2010 From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins) Date: Sun, 08 Aug 2010 13:44:08 -0400 Subject: [tei-council] ODD headers and licensing terms for customizations provided by TEI-C Message-ID: <4C5EECE8.8010801@ultraslavonic.info> While the TEI website gives clear instructions on licensing terms for P5 ( http://www.tei-c.org/Guidelines/access.xml ), it doesn't say anything about licensing for customizations provided by the TEI-C. Are these also published under GPL v. 2? I realize that these were probably all developed under unclear circumstances, so I think Council will need to declare something even if we don't have copyright agreements on file with those who first wrote these customizations. Whatever terms we settle on, I think it would be appropriate to add this information in an <availability> in the ODD files of Lite, Tite, and others along the lines of what is found at http://www.tei-c.org/release/xml/tei/odd/Source/guidelines.xml Incidentally, I also discovered that the ODD for Lite gives this: <publicationStmt> <p>Not for publication or redistribution</p> </publicationStmt> I'm not sure what this needs to be changed to, but I think we shouldn't leave it as it is. From sebastian.rahtz at oucs.ox.ac.uk Sun Aug 8 14:05:18 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Sun, 8 Aug 2010 19:05:18 +0100 Subject: [tei-council] ODD headers and licensing terms for customizations provided by TEI-C In-Reply-To: <4C5EECE8.8010801@ultraslavonic.info> References: <4C5EECE8.8010801@ultraslavonic.info> Message-ID: <1730F335-9ABF-4B71-8BC6-293512AB40F1@oucs.ox.ac.uk> the hand-rolled customizations say <availability status="free"> <p>This template file is freely available and you are hereby authorised to copy, modify, and redistribute it in any way without further reference or permissions.</p> <p>When making such modifications, you are strongly recommended to change the present text to include an accurate statement of the licencing conditions applicable to your modified text.</p> </availability> ie effectively putting then in the public domain. for the trivial ones like tei_all, this seems right. The wording was from Syd. I have changed Lite to use the same statement (GPL) as the main Guidelines, as that too seems the obvious course to take. Tite is less clear. It seems to be the work mainly of Perry T working for John U, but I hope they would agree the copyright belongs to the TEI C. I would strongly suggest it was work paid for and commissioned by TEIC (using Mellon's money). Simplest thing to do would be to bang a GPL 2 on Tite too, if folks agree. Talking of TEI Tite, what has happened to the updates that were said to be needed to the ODD and its generated schemas? The round of changes to ODD which enabled ODD_by_inclusion rather than ODD_by_exclusion have not been used by Tite yet, for which they are the archetypal example. -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From sebastian.rahtz at oucs.ox.ac.uk Sun Aug 8 14:15:56 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Sun, 8 Aug 2010 19:15:56 +0100 Subject: [tei-council] Lists of Council Members In-Reply-To: <4C5EE9AF.2020608@ultraslavonic.info> References: <4B8D47C0.7050908@oucs.ox.ac.uk> <4B956322.4070403@ultraslavonic.info> <4B95665C.4010607@uleth.ca> <4C5EE9AF.2020608@ultraslavonic.info> Message-ID: <29CC916E-9E5F-41BD-9C38-8051EEF92CDC@oucs.ox.ac.uk> On 8 Aug 2010, at 18:30, Kevin Hawkins wrote: > This is now in SourceForge: > > https://sourceforge.net/tracker/?group_id=106328&atid=644065 which says "it seems there was consensus to update the list of Council members in the Guidelines (and list of Council meetings) and possibly also say explicitly that ongoing development is carried out by the Council." and of course that seems right and proper. But the relevant section (file FM1-IntroductoryNote.xml) is very much written as a snapshot overview of the process leading up to P5 release, and simply updating the lists would not be sufficient. I suggest that ideally we need to retire that prefix as is to the back matter (PrefatoryNote.xml) and write a new short one which is more sustainable for the way we are now working. Would that be acceptable to everyone? -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From lou.burnard at oucs.ox.ac.uk Sun Aug 8 17:40:01 2010 From: lou.burnard at oucs.ox.ac.uk (Lou Burnard) Date: Sun, 08 Aug 2010 22:40:01 +0100 Subject: [tei-council] Lists of Council Members In-Reply-To: <29CC916E-9E5F-41BD-9C38-8051EEF92CDC@oucs.ox.ac.uk> References: <4B8D47C0.7050908@oucs.ox.ac.uk> <4B956322.4070403@ultraslavonic.info> <4B95665C.4010607@uleth.ca> <4C5EE9AF.2020608@ultraslavonic.info> <29CC916E-9E5F-41BD-9C38-8051EEF92CDC@oucs.ox.ac.uk> Message-ID: <4C5F2431.4070004@oucs.ox.ac.uk> On 08/08/10 19:15, Sebastian Rahtz wrote: > > On 8 Aug 2010, at 18:30, Kevin Hawkins wrote: > >> This is now in SourceForge: >> >> https://sourceforge.net/tracker/?group_id=106328&atid=644065 > > which says > > "it seems there was consensus to update the list of Council members in the Guidelines (and list of Council meetings) and possibly also say explicitly that ongoing development is carried out by the Council." > > and of course that seems right and proper. But the relevant section (file FM1-IntroductoryNote.xml) is very much written as a snapshot > overview of the process leading up to P5 release, and simply updating the lists would not be sufficient. > > I suggest that ideally we need to retire that prefix as is to the back matter (PrefatoryNote.xml) > and write a new short one which is more sustainable for the way we are now working. Would > that be acceptable to everyone? > I'm guessing that by "prefix" you mean "preface" ? Any volunteers to draft the new one? From sebastian.rahtz at oucs.ox.ac.uk Sun Aug 8 18:02:17 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Sun, 8 Aug 2010 23:02:17 +0100 Subject: [tei-council] Lists of Council Members In-Reply-To: <4C5F2431.4070004@oucs.ox.ac.uk> References: <4B8D47C0.7050908@oucs.ox.ac.uk> <4B956322.4070403@ultraslavonic.info> <4B95665C.4010607@uleth.ca> <4C5EE9AF.2020608@ultraslavonic.info> <29CC916E-9E5F-41BD-9C38-8051EEF92CDC@oucs.ox.ac.uk> <4C5F2431.4070004@oucs.ox.ac.uk> Message-ID: <CEE31BD6-2062-4BB3-8C5E-CF1BAB063F0E@oucs.ox.ac.uk> On 8 Aug 2010, at 22:40, Lou Burnard wrote: > I'm guessing that by "prefix" you mean "preface" ? > yes indeedy. > Any volunteers to draft the new one? if people agree, we could target that for the November MM release. I could make a stab at it next month -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From laurent.romary at inria.fr Mon Aug 9 03:25:07 2010 From: laurent.romary at inria.fr (Laurent Romary) Date: Mon, 9 Aug 2010 09:25:07 +0200 Subject: [tei-council] Lists of Council Members In-Reply-To: <CEE31BD6-2062-4BB3-8C5E-CF1BAB063F0E@oucs.ox.ac.uk> References: <4B8D47C0.7050908@oucs.ox.ac.uk> <4B956322.4070403@ultraslavonic.info> <4B95665C.4010607@uleth.ca> <4C5EE9AF.2020608@ultraslavonic.info> <29CC916E-9E5F-41BD-9C38-8051EEF92CDC@oucs.ox.ac.uk> <4C5F2431.4070004@oucs.ox.ac.uk> <CEE31BD6-2062-4BB3-8C5E-CF1BAB063F0E@oucs.ox.ac.uk> Message-ID: <A3233B84-55DD-467C-B5F5-1CF05D00DE32@inria.fr> Would be perfect! Thanks Sebastian, Laurent Le 9 ao?t 10 ? 00:02, Sebastian Rahtz a ?crit : > > On 8 Aug 2010, at 22:40, Lou Burnard wrote: >> I'm guessing that by "prefix" you mean "preface" ? >> > yes indeedy. > >> Any volunteers to draft the new one? > > > if people agree, we could target that for the November MM release. I > could > make a stab at it next month > -- > Sebastian Rahtz > Information Manager, Oxford University Computing Services > 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 > > S?lo le pido a Dios > que el futuro no me sea indiferente > > > > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Laurent Romary INRIA & HUB-IDSL laurent.romary at inria.fr From laurent.romary at inria.fr Mon Aug 9 04:31:28 2010 From: laurent.romary at inria.fr (Laurent Romary) Date: Mon, 9 Aug 2010 10:31:28 +0200 Subject: [tei-council] ODD headers and licensing terms for customizations provided by TEI-C In-Reply-To: <1730F335-9ABF-4B71-8BC6-293512AB40F1@oucs.ox.ac.uk> References: <4C5EECE8.8010801@ultraslavonic.info> <1730F335-9ABF-4B71-8BC6-293512AB40F1@oucs.ox.ac.uk> Message-ID: <AB3BDF80-C19D-4C67-A841-554E0B215E17@inria.fr> I would follow Sebastian here. @Dan: could you check that John U would agree on having the same licensing scheme attached to Tite? Laurent Le 8 ao?t 10 ? 20:05, Sebastian Rahtz a ?crit : > the hand-rolled customizations say > > <availability status="free"> > <p>This template file is freely available and you are > hereby authorised to copy, modify, and redistribute it in > any way without further reference or permissions.</p> > <p>When making such modifications, you are strongly > recommended to change the present text to include an > accurate statement of the licencing conditions applicable > to your modified text.</p> > </availability> > > ie effectively putting then in the public domain. for the trivial > ones like tei_all, this seems right. The wording was from Syd. > > I have changed Lite to use the same statement (GPL) as the main > Guidelines, > as that too seems the obvious course to take. > > Tite is less clear. It seems to be the work mainly of Perry T > working for John U, > but I hope they would agree the copyright belongs to the TEI C. I > would > strongly suggest it was work paid for and commissioned by TEIC > (using Mellon's > money). > > Simplest thing to do would be to bang a GPL 2 on Tite too, if folks > agree. > > Talking of TEI Tite, what has happened to the updates that were said > to be > needed to the ODD and its generated schemas? The round of changes to > ODD which enabled ODD_by_inclusion rather than ODD_by_exclusion > have not been used by Tite yet, for which they are the archetypal > example. > -- > Sebastian Rahtz > Information Manager, Oxford University Computing Services > 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 > > S?lo le pido a Dios > que el futuro no me sea indiferente > > > > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Laurent Romary INRIA & HUB-IDSL laurent.romary at inria.fr From gabriel.bodard at kcl.ac.uk Mon Aug 9 07:02:29 2010 From: gabriel.bodard at kcl.ac.uk (Gabriel Bodard) Date: Mon, 9 Aug 2010 12:02:29 +0100 Subject: [tei-council] its release time In-Reply-To: <4C5C1941.9060505@oucs.ox.ac.uk> References: <F466390F-E6D2-4547-BF01-1823275A9330@oucs.ox.ac.uk> <4C290D8B.1020601@ultraslavonic.info> <2D7BA559-2ADB-4DAB-A229-E2D7A10F44D4@oucs.ox.ac.uk> <4C5BEA98.3000709@kcl.ac.uk> <4C5BF95A.5040002@oucs.ox.ac.uk> <4C5C1941.9060505@oucs.ox.ac.uk> Message-ID: <4C5FE045.9090004@kcl.ac.uk> On 06/08/2010 15:16, Lou wrote: > At the risk of sounding unhelpful -- if you want to specify duration on > <date> why not use the iso-when attribute, which allows specification of > durations? That's a possibility, but I was pointed to @dur when I was trying to figure out how to tag these durations on TEI-L a while back, and I would have thought that @dur is a more pure way to do this, no? (Slightly more semantically unambiguous, anyway. If you disagree, I suppose we could drop the requirement for from EpiDoc @dur altogether, but then I wonder why @dur exists at all?) Thanks, G -- Dr Gabriel BODARD (Epigrapher, Digital Classicist, Pirate) Centre for Computing in the Humanities King's College London 26-29 Drury Lane London WC2B 5RL Email: gabriel.bodard at kcl.ac.uk Tel: +44 (0)20 7848 1388 Fax: +44 (0)20 7848 2980 http://www.digitalclassicist.org/ http://www.currentepigraphy.org/ From kevin.s.hawkins at ultraslavonic.info Mon Aug 9 11:01:25 2010 From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins) Date: Mon, 09 Aug 2010 11:01:25 -0400 Subject: [tei-council] Fwd: Re: TEI Web site Message-ID: <4C601845.5020703@ultraslavonic.info> I think David Sewell's recent note to TEI-L about how the TEI website works is an excellent start to a colophon for the TEI website. How do others feel about having such a page? -------- Original Message -------- Subject: Re: TEI Web site Date: Mon, 9 Aug 2010 10:03:04 -0400 (EDT) From: David Sewell <dsewell at virginia.edu> To: Kevin Hawkins <kevin.s.hawkins at ultraslavonic.info> Kevin, I certainly wasn't composing it to be an official document--but I'd suggest you run the idea of an "About this website" page by Council. If created, it should probably have more content than just a technical note on underlying data. David On Sun, 8 Aug 2010, Kevin Hawkins wrote: > David, I think your message would make a fine colophon for the TEI website. > Perhaps, in the navbar, there could be something like > > About --> This website > > which would bring up a short page containing more or less what you wrote > below. > > > The content on www.tei-c.org is a composite of quite a few underlying > > sources. To wit: > > > > * Most of the content pages, such as those under Activities, Membership, > > and About, live as mostly XML data in OpenCMS, a content management > > system; our configuration converts TEI-XML to HTML on the fly > > > > * The news sidebar on the main page and /News/ are pulled in > > quasi-dynamically from content that lives in the TEI WordPress blog on > > Sourceforge (http://sourceforge.net/apps/wordpress/tei/) > > > > * Some areas of the site are simply filesystem mirrors of the current > > TEI Sourceforge packages, e.g. the P4 and P5 Guidelines documentation > > under /release, and Roma under /Roma > > > > * Others are static filesystem directories with special material, such > > as the "TEI Vault" (http://www.tei-c.org/Vault/) > > > > * Yet others are pointers to TEI-related material hosted externally (the > > TEI webstore at http://www.tei-shop.org/, the new TEI Journal aka J-TEI > > site at http://journal.tei-c.org/) > > > > All integrated via an Apache configuration file resembling the wiring > > diagram of a nuclear submarine, and ably maintained by our sysadmin > > Shayne Brandon. > -- David Sewell, Editorial and Technical Manager ROTUNDA, The University of Virginia Press PO Box 400314, Charlottesville, VA 22904-4314 USA Email: dsewell at virginia.edu Tel: +1 434 924 9973 Web: http://rotunda.upress.virginia.edu/ From sebastian.rahtz at oucs.ox.ac.uk Mon Aug 9 13:21:14 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 9 Aug 2010 18:21:14 +0100 Subject: [tei-council] Fwd: Re: TEI Web site In-Reply-To: <4C601845.5020703@ultraslavonic.info> References: <4C601845.5020703@ultraslavonic.info> Message-ID: <4E3D6E02-9B29-40FE-A2C2-A688D9F9BFF5@oucs.ox.ac.uk> On 9 Aug 2010, at 16:01, Kevin Hawkins wrote: > I think David Sewell's recent note to TEI-L about how the TEI website > works is an excellent start to a colophon for the TEI website. How do > others feel about having such a page? definitely a good idea -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From sebastian.rahtz at oucs.ox.ac.uk Mon Aug 9 13:55:35 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 9 Aug 2010 18:55:35 +0100 Subject: [tei-council] maintenance of Tite Message-ID: <BEF4BAF2-B127-4E48-A24C-A2391726E44D@oucs.ox.ac.uk> Kevin has submitted some sensible bug reports on Sourceforge about Tite. But I am unsure how to handle these, as I don't know the state of the thing. Is Perry T working on it or not? and what maintenance schedule are we imposing on this beast, given the agreement with Apex? -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From daniel.odonnell at uleth.ca Mon Aug 9 16:29:33 2010 From: daniel.odonnell at uleth.ca (O'Donnell, Dan) Date: Mon, 09 Aug 2010 14:29:33 -0600 Subject: [tei-council] maintenance of Tite In-Reply-To: <BEF4BAF2-B127-4E48-A24C-A2391726E44D@oucs.ox.ac.uk> References: <BEF4BAF2-B127-4E48-A24C-A2391726E44D@oucs.ox.ac.uk> Message-ID: <4C60652D.3060405@uleth.ca> Good question. The Tite experience has prompted a number of very useful issues and experiences including the need to have specifically referable releases and the issue about positively or negatively defining the inclusion and exclusion of elements. My understanding, cc'd to Perry here to check that I've got this right, is that Apex are using a specific schema generated from the current odd, and that the TEI can update and change the official ODD as we go along on our regular update schedules. Obviously we want to avoid breaking backwards compatibility, but Perry also did some custom examples and things, I think. -dan On 10-08-09 11:55 AM, Sebastian Rahtz wrote: > Kevin has submitted some sensible bug reports on Sourceforge about Tite. But I am unsure how to handle these, as I don't know the state of the thing. Is Perry T working on it or not? and what maintenance schedule are we imposing on this beast, given the agreement with Apex? > -- > Sebastian Rahtz > Information Manager, Oxford University Computing Services > 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 > > S?lo le pido a Dios > que el futuro no me sea indiferente > > > > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > -- Daniel Paul O'Donnell Professor of English University of Lethbridge Chair and CEO, Text Encoding Initiative (http://www.tei-c.org/) Co-Chair, Digital Initiatives Advisory Board, Medieval Academy of America President-elect (English), Society for Digital Humanities/Soci?t? pour l'?tude des m?dias interactifs (http://sdh-semi.org/) Founding Director (2003-2009), Digital Medievalist Project (http://www.digitalmedievalist.org/) Vox: +1 403 329-2377 Fax: +1 403 382-7191 (non-confidential) Home Page: http://people.uleth.ca/~daniel.odonnell/ From daniel.odonnell at uleth.ca Mon Aug 9 16:35:54 2010 From: daniel.odonnell at uleth.ca (O'Donnell, Dan) Date: Mon, 09 Aug 2010 14:35:54 -0600 Subject: [tei-council] ODD headers and licensing terms for customizations provided by TEI-C In-Reply-To: <AB3BDF80-C19D-4C67-A841-554E0B215E17@inria.fr> References: <4C5EECE8.8010801@ultraslavonic.info> <1730F335-9ABF-4B71-8BC6-293512AB40F1@oucs.ox.ac.uk> <AB3BDF80-C19D-4C67-A841-554E0B215E17@inria.fr> Message-ID: <4C6066AA.70405@uleth.ca> I'll check that their understanding is the same as mine, which is it is licenced the same way Lite is. -dan On 10-08-09 02:31 AM, Laurent Romary wrote: > I would follow Sebastian here. > @Dan: could you check that John U would agree on having the same > licensing scheme attached to Tite? > Laurent > > Le 8 ao?t 10 ? 20:05, Sebastian Rahtz a ?crit : > > >> the hand-rolled customizations say >> >> <availability status="free"> >> <p>This template file is freely available and you are >> hereby authorised to copy, modify, and redistribute it in >> any way without further reference or permissions.</p> >> <p>When making such modifications, you are strongly >> recommended to change the present text to include an >> accurate statement of the licencing conditions applicable >> to your modified text.</p> >> </availability> >> >> ie effectively putting then in the public domain. for the trivial >> ones like tei_all, this seems right. The wording was from Syd. >> >> I have changed Lite to use the same statement (GPL) as the main >> Guidelines, >> as that too seems the obvious course to take. >> >> Tite is less clear. It seems to be the work mainly of Perry T >> working for John U, >> but I hope they would agree the copyright belongs to the TEI C. I >> would >> strongly suggest it was work paid for and commissioned by TEIC >> (using Mellon's >> money). >> >> Simplest thing to do would be to bang a GPL 2 on Tite too, if folks >> agree. >> >> Talking of TEI Tite, what has happened to the updates that were said >> to be >> needed to the ODD and its generated schemas? The round of changes to >> ODD which enabled ODD_by_inclusion rather than ODD_by_exclusion >> have not been used by Tite yet, for which they are the archetypal >> example. >> -- >> Sebastian Rahtz >> Information Manager, Oxford University Computing Services >> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 >> >> S?lo le pido a Dios >> que el futuro no me sea indiferente >> >> >> >> >> _______________________________________________ >> tei-council mailing list >> tei-council at lists.village.Virginia.EDU >> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council >> > Laurent Romary > INRIA& HUB-IDSL > laurent.romary at inria.fr > > > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > -- Daniel Paul O'Donnell Professor of English University of Lethbridge Chair and CEO, Text Encoding Initiative (http://www.tei-c.org/) Co-Chair, Digital Initiatives Advisory Board, Medieval Academy of America President-elect (English), Society for Digital Humanities/Soci?t? pour l'?tude des m?dias interactifs (http://sdh-semi.org/) Founding Director (2003-2009), Digital Medievalist Project (http://www.digitalmedievalist.org/) Vox: +1 403 329-2377 Fax: +1 403 382-7191 (non-confidential) Home Page: http://people.uleth.ca/~daniel.odonnell/ From kevin.s.hawkins at ultraslavonic.info Mon Aug 9 17:17:36 2010 From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins) Date: Mon, 09 Aug 2010 17:17:36 -0400 Subject: [tei-council] Tite requests In-Reply-To: <4BDF2D88.1030706@uleth.ca> References: <4BDC5A2B.90306@ultraslavonic.info> <4BDF2D88.1030706@uleth.ca> Message-ID: <4C607070.3000605@ultraslavonic.info> Sebastian asked in a postscript to a recent email to our list what the status of this is. I think it would be good to address whatever Apex suggested regarding Tite before the tickets I recently created in SourceForge. --Kevin On 5/3/2010 4:09 PM, O'Donnell, Dan wrote: > Thanks Kevin. We had discussed this a little on the council list in the > run up to the meeting, but I should indeed have reported. While I was in > Dublin I received what I believe is the last set of suggestions from > Apex with regard to their own workflow in order to allow us to pump out > a schema for the the first year of the contract. I still have to read > through it and report back. > > On 10-05-01 10:43 AM, Kevin Hawkins wrote: >> >> All, >> >> Great meeting in Dublin, but unfortunately I forgot to ask Dan about the >> status of Tite. Dan hasn't forwarded to us any packages of revisions to >> the Tite spec. What's the status? Is there anything for Council to >> consider or any opportunities for more input on it? >> >> Kevin >> >> On 11/02/2010 17:34, O'Donnell, Dan wrote: >>> Hi all, >>> >>> As I mentioned at the teleconference, we received some notes on issues >>> with Tite that Apex would like to see addressed before the launch of the >>> programme. Most of them are very sensible and agree with things that >>> people have said here. They've also pointed out an issue to do with >>> release schedules and the way Tite is designed that would require >>> longer-term thinking, but ties in with what people said here when I >>> asked which version of Tite we should refer to in the contract. >>> >>> Perry is extracting the notes to form an actual proposal for Council to >>> consider in much the same way we often ask people to think about sf >>> tickets and discuss them for us. It should be done over the weekend. >>> I'll pass it on to you as soon as it is done. Ideally we should add him >>> to the conversation as a non-voting member. >>> >>> -dan >>> >> _______________________________________________ >> tei-council mailing list >> tei-council at lists.village.Virginia.EDU >> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council >> >> No virus found in this incoming message. >> Checked by AVG - www.avg.com >> Version: 9.0.814 / Virus Database: 271.1.1/2847 - Release Date: >> 05/01/10 00:27:00 >> > From sebastian.rahtz at oucs.ox.ac.uk Mon Aug 9 19:05:12 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 10 Aug 2010 00:05:12 +0100 Subject: [tei-council] ODD headers and licensing terms for customizations provided by TEI-C In-Reply-To: <4C6066AA.70405@uleth.ca> References: <4C5EECE8.8010801@ultraslavonic.info> <1730F335-9ABF-4B71-8BC6-293512AB40F1@oucs.ox.ac.uk> <AB3BDF80-C19D-4C67-A841-554E0B215E17@inria.fr> <4C6066AA.70405@uleth.ca> Message-ID: <72A449D6-F91B-4A7F-AC37-2029B1034A7A@oucs.ox.ac.uk> On 9 Aug 2010, at 21:35, "O'Donnell, Dan" <daniel.odonnell at uleth.ca> wrote: > I'll check that their understanding is the same as mine, which is it is > licenced the same way Lite is. > >>> >>> >>> >>> Ie not licensed at all:-) Sebastian From daniel.odonnell at uleth.ca Mon Aug 9 19:06:06 2010 From: daniel.odonnell at uleth.ca (O'Donnell, Dan) Date: Mon, 09 Aug 2010 17:06:06 -0600 Subject: [tei-council] ODD headers and licensing terms for customizations provided by TEI-C In-Reply-To: <72A449D6-F91B-4A7F-AC37-2029B1034A7A@oucs.ox.ac.uk> References: <4C5EECE8.8010801@ultraslavonic.info> <1730F335-9ABF-4B71-8BC6-293512AB40F1@oucs.ox.ac.uk> <AB3BDF80-C19D-4C67-A841-554E0B215E17@inria.fr> <4C6066AA.70405@uleth.ca> <72A449D6-F91B-4A7F-AC37-2029B1034A7A@oucs.ox.ac.uk> Message-ID: <4C6089DE.2090005@uleth.ca> Indeed. But now with a new improved proposal. I think you'll find "kind of like lite, however that's done" represents the limit of the legal thinking so far on the topic by the team. -dan On 10-08-09 05:05 PM, Sebastian Rahtz wrote: > > > > On 9 Aug 2010, at 21:35, "O'Donnell, Dan"<daniel.odonnell at uleth.ca> wrote: > > >> I'll check that their understanding is the same as mine, which is it is >> licenced the same way Lite is. >> >> >>>> >>>> >>>> >>>> > Ie not licensed at all:-) > > Sebastian > -- Daniel Paul O'Donnell Professor of English University of Lethbridge Chair and CEO, Text Encoding Initiative (http://www.tei-c.org/) Co-Chair, Digital Initiatives Advisory Board, Medieval Academy of America President-elect (English), Society for Digital Humanities/Soci?t? pour l'?tude des m?dias interactifs (http://sdh-semi.org/) Founding Director (2003-2009), Digital Medievalist Project (http://www.digitalmedievalist.org/) Vox: +1 403 329-2377 Fax: +1 403 382-7191 (non-confidential) Home Page: http://people.uleth.ca/~daniel.odonnell/ From sebastian.rahtz at oucs.ox.ac.uk Mon Aug 9 19:10:38 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 10 Aug 2010 00:10:38 +0100 Subject: [tei-council] maintenance of Tite In-Reply-To: <4C60652D.3060405@uleth.ca> References: <BEF4BAF2-B127-4E48-A24C-A2391726E44D@oucs.ox.ac.uk> <4C60652D.3060405@uleth.ca> Message-ID: <33EF97D1-EBC8-4444-ABE4-D83D4C85D0D4@oucs.ox.ac.uk> On 9 Aug 2010, at 21:29, "O'Donnell, Dan" <daniel.odonnell at uleth.ca> wrote: > Good question. The Tite experience has prompted a number of very useful > issues and experiences including the need to have specifically referable > releases and the issue about positively or negatively defining the > inclusion and exclusion of elements. Indeed. And so Tite needs to be revised to use these facilities. > > My understanding, cc'd to Perry here to check that I've got this right, > is that Apex are using a specific schema generated from the current odd I was surprised to see no mention of the schema at Accesstei. When was this schema generated? > > and that the TEI can update and change the official ODD as we go along > on our regular update schedules. By what criteria do we change it? > Obviously we want to avoid breaking > backwards compatibility, but Perry also did some custom examples and > things, I think. Which we don't have chez the TEIC alongside the Odd? This all seems less than satisfactory. Sebastian From sebastian.rahtz at oucs.ox.ac.uk Mon Aug 9 19:13:08 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 10 Aug 2010 00:13:08 +0100 Subject: [tei-council] ODD headers and licensing terms for customizations provided by TEI-C In-Reply-To: <4C6089DE.2090005@uleth.ca> References: <4C5EECE8.8010801@ultraslavonic.info> <1730F335-9ABF-4B71-8BC6-293512AB40F1@oucs.ox.ac.uk> <AB3BDF80-C19D-4C67-A841-554E0B215E17@inria.fr> <4C6066AA.70405@uleth.ca> <72A449D6-F91B-4A7F-AC37-2029B1034A7A@oucs.ox.ac.uk> <4C6089DE.2090005@uleth.ca> Message-ID: <6DD80D53-232F-4860-BFB7-4D99FCB04343@oucs.ox.ac.uk> > Indeed. But now with a new improved proposal. I think you'll find "kind > of like lite, however that's done" represents the limit of the legal > thinking so far on the topic by the team. So any objections if I make tite be entirely in line with lite and the main tei? Copyright owned by TEIC? Sebastian > From daniel.odonnell at uleth.ca Mon Aug 9 19:14:05 2010 From: daniel.odonnell at uleth.ca (O'Donnell, Dan) Date: Mon, 09 Aug 2010 17:14:05 -0600 Subject: [tei-council] maintenance of Tite In-Reply-To: <33EF97D1-EBC8-4444-ABE4-D83D4C85D0D4@oucs.ox.ac.uk> References: <BEF4BAF2-B127-4E48-A24C-A2391726E44D@oucs.ox.ac.uk> <4C60652D.3060405@uleth.ca> <33EF97D1-EBC8-4444-ABE4-D83D4C85D0D4@oucs.ox.ac.uk> Message-ID: <4C608BBD.5040709@uleth.ca> I agree that it isn't at a satisfactory final state. We've benefited a lot from the development as a forerunner for exploring how we might develop customisations like this (and our discussions about the journal work is a result of that to a certain extent), but in the absence of an established process we're of course having to feel our way forward. I'm not quite sure the best way of getting this into the ideal relationship with the council. I don't think it's been a lack of will. I have a call with Apex later this week, I'll ask them about the schema. -dan On 10-08-09 05:10 PM, Sebastian Rahtz wrote: > > On 9 Aug 2010, at 21:29, "O'Donnell, Dan"<daniel.odonnell at uleth.ca> wrote: > > >> Good question. The Tite experience has prompted a number of very useful >> issues and experiences including the need to have specifically referable >> releases and the issue about positively or negatively defining the >> inclusion and exclusion of elements. >> > Indeed. And so Tite needs to be revised to use these facilities. > >> My understanding, cc'd to Perry here to check that I've got this right, >> is that Apex are using a specific schema generated from the current odd >> > I was surprised to see no mention of the schema at Accesstei. When was this schema generated? > > >> >> and that the TEI can update and change the official ODD as we go along >> on our regular update schedules. >> > By what criteria do we change it? > > >> Obviously we want to avoid breaking >> backwards compatibility, but Perry also did some custom examples and >> things, I think. >> > Which we don't have chez the TEIC alongside the Odd? This all seems less than satisfactory. > > Sebastian -- Daniel Paul O'Donnell Professor of English University of Lethbridge Chair and CEO, Text Encoding Initiative (http://www.tei-c.org/) Co-Chair, Digital Initiatives Advisory Board, Medieval Academy of America President-elect (English), Society for Digital Humanities/Soci?t? pour l'?tude des m?dias interactifs (http://sdh-semi.org/) Founding Director (2003-2009), Digital Medievalist Project (http://www.digitalmedievalist.org/) Vox: +1 403 329-2377 Fax: +1 403 382-7191 (non-confidential) Home Page: http://people.uleth.ca/~daniel.odonnell/ From daniel.odonnell at uleth.ca Mon Aug 9 19:14:29 2010 From: daniel.odonnell at uleth.ca (O'Donnell, Dan) Date: Mon, 09 Aug 2010 17:14:29 -0600 Subject: [tei-council] ODD headers and licensing terms for customizations provided by TEI-C In-Reply-To: <6DD80D53-232F-4860-BFB7-4D99FCB04343@oucs.ox.ac.uk> References: <4C5EECE8.8010801@ultraslavonic.info> <1730F335-9ABF-4B71-8BC6-293512AB40F1@oucs.ox.ac.uk> <AB3BDF80-C19D-4C67-A841-554E0B215E17@inria.fr> <4C6066AA.70405@uleth.ca> <72A449D6-F91B-4A7F-AC37-2029B1034A7A@oucs.ox.ac.uk> <4C6089DE.2090005@uleth.ca> <6DD80D53-232F-4860-BFB7-4D99FCB04343@oucs.ox.ac.uk> Message-ID: <4C608BD5.6070702@uleth.ca> I've asked. But that's always been my working assumption. On 10-08-09 05:13 PM, Sebastian Rahtz wrote: > > > >> Indeed. But now with a new improved proposal. I think you'll find "kind >> of like lite, however that's done" represents the limit of the legal >> thinking so far on the topic by the team. >> > So any objections if I make tite be entirely in line with lite and the main tei? Copyright owned by TEIC? > > Sebastian > >> -- Daniel Paul O'Donnell Professor of English University of Lethbridge Chair and CEO, Text Encoding Initiative (http://www.tei-c.org/) Co-Chair, Digital Initiatives Advisory Board, Medieval Academy of America President-elect (English), Society for Digital Humanities/Soci?t? pour l'?tude des m?dias interactifs (http://sdh-semi.org/) Founding Director (2003-2009), Digital Medievalist Project (http://www.digitalmedievalist.org/) Vox: +1 403 329-2377 Fax: +1 403 382-7191 (non-confidential) Home Page: http://people.uleth.ca/~daniel.odonnell/ From laurent.romary at inria.fr Tue Aug 10 00:54:37 2010 From: laurent.romary at inria.fr (Laurent Romary) Date: Tue, 10 Aug 2010 06:54:37 +0200 Subject: [tei-council] maintenance of Tite In-Reply-To: <4C608BBD.5040709@uleth.ca> References: <BEF4BAF2-B127-4E48-A24C-A2391726E44D@oucs.ox.ac.uk> <4C60652D.3060405@uleth.ca> <33EF97D1-EBC8-4444-ABE4-D83D4C85D0D4@oucs.ox.ac.uk> <4C608BBD.5040709@uleth.ca> Message-ID: <2ABA5674-CA71-4A42-9C29-79BF7D55A4E3@inria.fr> In any case, we should tend towards a situation where: - the council maintains the schema like any other official TEI customization - we need to secure that when a change impacts on the AcessTEI program Apex is in the loop to be informed We should not designed an adhoc maintenance system to preserve the simplicity of our processes. Laurent Le 10 ao?t 10 ? 01:14, O'Donnell, Dan a ?crit : > I agree that it isn't at a satisfactory final state. We've benefited a > lot from the development as a forerunner for exploring how we might > develop customisations like this (and our discussions about the > journal > work is a result of that to a certain extent), but in the absence of > an > established process we're of course having to feel our way forward. > I'm > not quite sure the best way of getting this into the ideal > relationship > with the council. I don't think it's been a lack of will. > > I have a call with Apex later this week, I'll ask them about the > schema. > > -dan > > > > On 10-08-09 05:10 PM, Sebastian Rahtz wrote: >> >> On 9 Aug 2010, at 21:29, "O'Donnell, >> Dan"<daniel.odonnell at uleth.ca> wrote: >> >> >>> Good question. The Tite experience has prompted a number of very >>> useful >>> issues and experiences including the need to have specifically >>> referable >>> releases and the issue about positively or negatively defining the >>> inclusion and exclusion of elements. >>> >> Indeed. And so Tite needs to be revised to use these facilities. >> >>> My understanding, cc'd to Perry here to check that I've got this >>> right, >>> is that Apex are using a specific schema generated from the >>> current odd >>> >> I was surprised to see no mention of the schema at Accesstei. When >> was this schema generated? >> >> >>> >>> and that the TEI can update and change the official ODD as we go >>> along >>> on our regular update schedules. >>> >> By what criteria do we change it? >> >> >>> Obviously we want to avoid breaking >>> backwards compatibility, but Perry also did some custom examples and >>> things, I think. >>> >> Which we don't have chez the TEIC alongside the Odd? This all seems >> less than satisfactory. >> >> Sebastian > > -- > Daniel Paul O'Donnell > Professor of English > University of Lethbridge > > Chair and CEO, Text Encoding Initiative (http://www.tei-c.org/) > Co-Chair, Digital Initiatives Advisory Board, Medieval Academy of > America > President-elect (English), Society for Digital Humanities/Soci?t? > pour l'?tude des m?dias interactifs (http://sdh-semi.org/) > Founding Director (2003-2009), Digital Medievalist Project (http://www.digitalmedievalist.org/ > ) > > Vox: +1 403 329-2377 > Fax: +1 403 382-7191 (non-confidential) > Home Page: http://people.uleth.ca/~daniel.odonnell/ > > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Laurent Romary INRIA & HUB-IDSL laurent.romary at inria.fr From laurent.romary at inria.fr Tue Aug 10 00:55:40 2010 From: laurent.romary at inria.fr (Laurent Romary) Date: Tue, 10 Aug 2010 06:55:40 +0200 Subject: [tei-council] maintenance of Tite In-Reply-To: <BEF4BAF2-B127-4E48-A24C-A2391726E44D@oucs.ox.ac.uk> References: <BEF4BAF2-B127-4E48-A24C-A2391726E44D@oucs.ox.ac.uk> Message-ID: <0CEB8A6F-7F04-4001-A577-AF2122FBFB0D@inria.fr> I forgot to mention that Kevin has just done it right here by considering that SF is the place where such bug reports should be recorded. Laurent Le 9 ao?t 10 ? 19:55, Sebastian Rahtz a ?crit : > Kevin has submitted some sensible bug reports on Sourceforge about > Tite. But I am unsure how to handle these, as I don't know the state > of the thing. Is Perry T working on it or not? and what maintenance > schedule are we imposing on this beast, given the agreement with Apex? > -- > Sebastian Rahtz > Information Manager, Oxford University Computing Services > 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 > > S?lo le pido a Dios > que el futuro no me sea indiferente > > > > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Laurent Romary INRIA & HUB-IDSL laurent.romary at inria.fr From laurent.romary at inria.fr Tue Aug 10 01:00:10 2010 From: laurent.romary at inria.fr (Laurent Romary) Date: Tue, 10 Aug 2010 07:00:10 +0200 Subject: [tei-council] ODD headers and licensing terms for customizations provided by TEI-C In-Reply-To: <6DD80D53-232F-4860-BFB7-4D99FCB04343@oucs.ox.ac.uk> References: <4C5EECE8.8010801@ultraslavonic.info> <1730F335-9ABF-4B71-8BC6-293512AB40F1@oucs.ox.ac.uk> <AB3BDF80-C19D-4C67-A841-554E0B215E17@inria.fr> <4C6066AA.70405@uleth.ca> <72A449D6-F91B-4A7F-AC37-2029B1034A7A@oucs.ox.ac.uk> <4C6089DE.2090005@uleth.ca> <6DD80D53-232F-4860-BFB7-4D99FCB04343@oucs.ox.ac.uk> Message-ID: <C7299541-5E99-4BBC-A0BE-B1A93158B960@inria.fr> Council: is there a voice again aligning Tite with the rest of the TEI from the point of view of licensing? Laurent Le 10 ao?t 10 ? 01:13, Sebastian Rahtz a ?crit : > > > >> Indeed. But now with a new improved proposal. I think you'll find >> "kind >> of like lite, however that's done" represents the limit of the legal >> thinking so far on the topic by the team. > > So any objections if I make tite be entirely in line with lite and > the main tei? Copyright owned by TEIC? > > Sebastian >> > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Laurent Romary INRIA & HUB-IDSL laurent.romary at inria.fr From daniel.odonnell at uleth.ca Tue Aug 10 01:02:37 2010 From: daniel.odonnell at uleth.ca (O'Donnell, Dan) Date: Mon, 9 Aug 2010 23:02:37 -0600 Subject: [tei-council] maintenance of Tite Message-ID: <qSklrxhvD5Hb.QN9lx4tG@mail-out.uleth.ca> I agree 100%. Let's get this under control. ------------ Daniel Paul O'Donnell, Professor of English University of Lethbridge Alberta, Canada >From my cell phone. -original message- Subject: Re: [tei-council] maintenance of Tite From: Laurent Romary <laurent.romary at inria.fr> Date: 2010/08/09 22:54 In any case, we should tend towards a situation where: - the council maintains the schema like any other official TEI customization - we need to secure that when a change impacts on the AcessTEI program Apex is in the loop to be informed We should not designed an adhoc maintenance system to preserve the simplicity of our processes. Laurent Le 10 ao?t 10 ? 01:14, O'Donnell, Dan a ?crit : > I agree that it isn't at a satisfactory final state. We've benefited a > lot from the development as a forerunner for exploring how we might > develop customisations like this (and our discussions about the > journal > work is a result of that to a certain extent), but in the absence of > an > established process we're of course having to feel our way forward. > I'm > not quite sure the best way of getting this into the ideal > relationship > with the council. I don't think it's been a lack of will. > > I have a call with Apex later this week, I'll ask them about the > schema. > > -dan > > > > On 10-08-09 05:10 PM, Sebastian Rahtz wrote: >> >> On 9 Aug 2010, at 21:29, "O'Donnell, >> Dan"<daniel.odonnell at uleth.ca> wrote: >> >> >>> Good question. The Tite experience has prompted a number of very >>> useful >>> issues and experiences including the need to have specifically >>> referable >>> releases and the issue about positively or negatively defining the >>> inclusion and exclusion of elements. >>> >> Indeed. And so Tite needs to be revised to use these facilities. >> >>> My understanding, cc'd to Perry here to check that I've got this >>> right, >>> is that Apex are using a specific schema generated from the >>> current odd >>> >> I was surprised to see no mention of the schema at Accesstei. When >> was this schema generated? >> >> >>> >>> and that the TEI can update and change the official ODD as we go >>> along >>> on our regular update schedules. >>> >> By what criteria do we change it? >> >> >>> Obviously we want to avoid breaking >>> backwards compatibility, but Perry also did some custom examples and >>> things, I think. >>> >> Which we don't have chez the TEIC alongside the Odd? This all seems >> less than satisfactory. >> >> Sebastian > > -- > Daniel Paul O'Donnell > Professor of English > University of Lethbridge > > Chair and CEO, Text Encoding Initiative (http://www.tei-c.org/) > Co-Chair, Digital Initiatives Advisory Board, Medieval Academy of > America > President-elect (English), Society for Digital Humanities/Soci?t? > pour l'?tude des m?dias interactifs (http://sdh-semi.org/) > Founding Director (2003-2009), Digital Medievalist Project (http://www.digitalmedievalist.org/ > ) > > Vox: +1 403 329-2377 > Fax: +1 403 382-7191 (non-confidential) > Home Page: http://people.uleth.ca/~daniel.odonnell/ > > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Laurent Romary INRIA & HUB-IDSL laurent.romary at inria.fr From James.Cummings at oucs.ox.ac.uk Tue Aug 10 05:28:30 2010 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Tue, 10 Aug 2010 10:28:30 +0100 Subject: [tei-council] ODD headers and licensing terms for customizations provided by TEI-C In-Reply-To: <C7299541-5E99-4BBC-A0BE-B1A93158B960@inria.fr> References: <4C5EECE8.8010801@ultraslavonic.info> <1730F335-9ABF-4B71-8BC6-293512AB40F1@oucs.ox.ac.uk> <AB3BDF80-C19D-4C67-A841-554E0B215E17@inria.fr> <4C6066AA.70405@uleth.ca> <72A449D6-F91B-4A7F-AC37-2029B1034A7A@oucs.ox.ac.uk> <4C6089DE.2090005@uleth.ca> <6DD80D53-232F-4860-BFB7-4D99FCB04343@oucs.ox.ac.uk> <C7299541-5E99-4BBC-A0BE-B1A93158B960@inria.fr> Message-ID: <4C611BBE.2030201@oucs.ox.ac.uk> Laurent Romary wrote: > Council: is there a voice again aligning Tite with the rest of the TEI > from the point of view of licensing? > Laurent I privately queried whether GPL was really the right thing to be licensing ODD files with since it is more commonly used with software, rather than some open data or open content license. Some of the decision about that hinges on what you philosophically believe the role of an ODD file to be (software library, data file, meta-schema, documentation, etc.). However Sebastian convinces me that *changing* the license away from GPL midstream might be more annoying than it being licensed GPL. So I only comment on this for the record so that it is clear that we did at least consider the possibility of moving away from the GPL for non-software. And certainly this is *not* a voice against aligning Tite with the rest of the TEI Exemplar Schemas from the point of view of licensing...they should all certainly be the same license. -James -- Dr James Cummings, Research Technologies Service OUCS, University of Oxford From lou.burnard at oucs.ox.ac.uk Tue Aug 10 06:37:21 2010 From: lou.burnard at oucs.ox.ac.uk (Lou) Date: Tue, 10 Aug 2010 11:37:21 +0100 Subject: [tei-council] maintenance of Tite In-Reply-To: <0CEB8A6F-7F04-4001-A577-AF2122FBFB0D@inria.fr> References: <BEF4BAF2-B127-4E48-A24C-A2391726E44D@oucs.ox.ac.uk> <0CEB8A6F-7F04-4001-A577-AF2122FBFB0D@inria.fr> Message-ID: <4C612BE1.8010004@oucs.ox.ac.uk> I think I agree that it would be a good thing if maintenance of TEI Lite were handled in the same way as other parts of the TEI. Can we have an explicit confirmation that Council has authority to modify this customization? It worries me a bit that there are clearly others who have an interest in it but who are not represented on Council, and so don't have a voice in any decisions we might make as to change in it. Back in March I sent Perry a pile of comments which I don't recall ever getting any detailed response to. Some were quite trivial stylistic issues about the text of the Tite doc, but others were quite substantive matters about the schema itself. Should I dig them up and resubmit them as SF tickets or what? Laurent Romary wrote: > I forgot to mention that Kevin has just done it right here by > considering that SF is the place where such bug reports should be > recorded. > Laurent > > Le 9 ao?t 10 ? 19:55, Sebastian Rahtz a ?crit : > >> Kevin has submitted some sensible bug reports on Sourceforge about >> Tite. But I am unsure how to handle these, as I don't know the state >> of the thing. Is Perry T working on it or not? and what maintenance >> schedule are we imposing on this beast, given the agreement with Apex? >> -- >> Sebastian Rahtz >> Information Manager, Oxford University Computing Services >> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 >> >> S?lo le pido a Dios >> que el futuro no me sea indiferente >> >> >> >> >> _______________________________________________ >> tei-council mailing list >> tei-council at lists.village.Virginia.EDU >> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > > Laurent Romary > INRIA & HUB-IDSL > laurent.romary at inria.fr > > > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council From lou.burnard at oucs.ox.ac.uk Tue Aug 10 06:52:06 2010 From: lou.burnard at oucs.ox.ac.uk (Lou) Date: Tue, 10 Aug 2010 11:52:06 +0100 Subject: [tei-council] maintenance of Tite In-Reply-To: <4C612BE1.8010004@oucs.ox.ac.uk> References: <BEF4BAF2-B127-4E48-A24C-A2391726E44D@oucs.ox.ac.uk> <0CEB8A6F-7F04-4001-A577-AF2122FBFB0D@inria.fr> <4C612BE1.8010004@oucs.ox.ac.uk> Message-ID: <4C612F56.8000302@oucs.ox.ac.uk> Lou wrote: > I think I agree that it would be a good thing if maintenance of TEI Lite doh. I meant "tite" of course. Here's a thought though: can we come up with some better branding for these two oft-confused schemas? From mholmes at uvic.ca Tue Aug 10 08:44:40 2010 From: mholmes at uvic.ca (Martin Holmes) Date: Tue, 10 Aug 2010 05:44:40 -0700 Subject: [tei-council] ODD headers and licensing terms for customizations provided by TEI-C In-Reply-To: <4C611BBE.2030201@oucs.ox.ac.uk> References: <4C5EECE8.8010801@ultraslavonic.info> <1730F335-9ABF-4B71-8BC6-293512AB40F1@oucs.ox.ac.uk> <AB3BDF80-C19D-4C67-A841-554E0B215E17@inria.fr> <4C6066AA.70405@uleth.ca> <72A449D6-F91B-4A7F-AC37-2029B1034A7A@oucs.ox.ac.uk> <4C6089DE.2090005@uleth.ca> <6DD80D53-232F-4860-BFB7-4D99FCB04343@oucs.ox.ac.uk> <C7299541-5E99-4BBC-A0BE-B1A93158B960@inria.fr> <4C611BBE.2030201@oucs.ox.ac.uk> Message-ID: <4C6149B8.4040502@uvic.ca> On 10-08-10 02:28 AM, James Cummings wrote: > Laurent Romary wrote: >> Council: is there a voice again aligning Tite with the rest of the TEI >> from the point of view of licensing? >> Laurent > > I privately queried whether GPL was really the right thing to be > licensing ODD files with since it is more commonly used with > software, rather than some open data or open content license.... It could be dual-licenced, or even triple-licenced, to get around this. Cheers, Martin From laurent.romary at inria.fr Tue Aug 10 08:51:48 2010 From: laurent.romary at inria.fr (Laurent Romary) Date: Tue, 10 Aug 2010 14:51:48 +0200 Subject: [tei-council] maintenance of Tite In-Reply-To: <4C612F56.8000302@oucs.ox.ac.uk> References: <BEF4BAF2-B127-4E48-A24C-A2391726E44D@oucs.ox.ac.uk> <0CEB8A6F-7F04-4001-A577-AF2122FBFB0D@inria.fr> <4C612BE1.8010004@oucs.ox.ac.uk> <4C612F56.8000302@oucs.ox.ac.uk> Message-ID: <BF37DA81-D20B-4BD2-89A2-523532026114@inria.fr> Tite = DIgiTEI ? Le 10 ao?t 10 ? 12:52, Lou a ?crit : > Lou wrote: >> I think I agree that it would be a good thing if maintenance of TEI >> Lite > > > doh. I meant "tite" of course. > > Here's a thought though: can we come up with some better branding > for these two oft-confused schemas? > > > Laurent Romary INRIA & HUB-IDSL laurent.romary at inria.fr From sebastian.rahtz at oucs.ox.ac.uk Tue Aug 10 10:19:42 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 10 Aug 2010 15:19:42 +0100 Subject: [tei-council] ODD headers and licensing terms for customizations provided by TEI-C In-Reply-To: <4C6149B8.4040502@uvic.ca> References: <4C5EECE8.8010801@ultraslavonic.info> <1730F335-9ABF-4B71-8BC6-293512AB40F1@oucs.ox.ac.uk> <AB3BDF80-C19D-4C67-A841-554E0B215E17@inria.fr> <4C6066AA.70405@uleth.ca> <72A449D6-F91B-4A7F-AC37-2029B1034A7A@oucs.ox.ac.uk> <4C6089DE.2090005@uleth.ca> <6DD80D53-232F-4860-BFB7-4D99FCB04343@oucs.ox.ac.uk> <C7299541-5E99-4BBC-A0BE-B1A93158B960@inria.fr> <4C611BBE.2030201@oucs.ox.ac.uk> <4C6149B8.4040502@uvic.ca> Message-ID: <A35173BF-6A03-4920-AB58-89FDE2D35B93@oucs.ox.ac.uk> > > It could be dual-licenced, or even triple-licenced, to get around this. > good point how strongly do people feel about this? our bottom line is (I assume) that we want the Guidelines and their adjuncts completely freely redistributable and re-useable, but * we don't want anyone else claiming it is their work * we don't want anyone producing versions of it (ie PDF) without source * we don't want forked changed versions (ie schemas) without source so YES: someone sells eBook versions of the Guidelines translated into Greek, and makes the source changes available NO: someone sells eBook versions of the Greek Guidelines, but does it by translating HTML output YES: someone makes changes to Lite, calls it MyLite, and distributes it as ODD + PDF + DTD NO: someone produces MyLite.dtd by editing teilite.dtd and distributes it I do claim that the GPL is still the right tool, as the TEI Guidelines have the characteristic of producing "compiled" forms which can be separately distributed and even changed in that form, and we want to preserve the link back to a free source form. but if there is an opendata/open document license which covers the situation, lets licence under that too. -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From sebastian.rahtz at oucs.ox.ac.uk Tue Aug 10 10:21:09 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 10 Aug 2010 15:21:09 +0100 Subject: [tei-council] maintenance of Tite In-Reply-To: <BF37DA81-D20B-4BD2-89A2-523532026114@inria.fr> References: <BEF4BAF2-B127-4E48-A24C-A2391726E44D@oucs.ox.ac.uk> <0CEB8A6F-7F04-4001-A577-AF2122FBFB0D@inria.fr> <4C612BE1.8010004@oucs.ox.ac.uk> <4C612F56.8000302@oucs.ox.ac.uk> <BF37DA81-D20B-4BD2-89A2-523532026114@inria.fr> Message-ID: <772FE843-116C-4808-81D6-2EF5BA6A5672@oucs.ox.ac.uk> On 10 Aug 2010, at 13:51, Laurent Romary wrote: > Tite = DIgiTEI ? > nous sommes prestiDigitatTEIurs? -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From laurent.romary at inria.fr Tue Aug 10 10:27:32 2010 From: laurent.romary at inria.fr (Laurent Romary) Date: Tue, 10 Aug 2010 16:27:32 +0200 Subject: [tei-council] maintenance of Tite In-Reply-To: <772FE843-116C-4808-81D6-2EF5BA6A5672@oucs.ox.ac.uk> References: <BEF4BAF2-B127-4E48-A24C-A2391726E44D@oucs.ox.ac.uk> <0CEB8A6F-7F04-4001-A577-AF2122FBFB0D@inria.fr> <4C612BE1.8010004@oucs.ox.ac.uk> <4C612F56.8000302@oucs.ox.ac.uk> <BF37DA81-D20B-4BD2-89A2-523532026114@inria.fr> <772FE843-116C-4808-81D6-2EF5BA6A5672@oucs.ox.ac.uk> Message-ID: <2FC8A978-6F99-4BF6-9A21-9FAFC10EE425@inria.fr> Excellent :-) Le 10 ao?t 10 ? 16:21, Sebastian Rahtz a ?crit : > > On 10 Aug 2010, at 13:51, Laurent Romary wrote: > >> Tite = DIgiTEI ? >> > nous sommes prestiDigitatTEIurs? > > -- > Sebastian Rahtz > Information Manager, Oxford University Computing Services > 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 > > S?lo le pido a Dios > que el futuro no me sea indiferente > > > > Laurent Romary INRIA & HUB-IDSL laurent.romary at inria.fr From mholmes at uvic.ca Tue Aug 10 11:18:52 2010 From: mholmes at uvic.ca (Martin Holmes) Date: Tue, 10 Aug 2010 08:18:52 -0700 Subject: [tei-council] ODD headers and licensing terms for customizations provided by TEI-C In-Reply-To: <A35173BF-6A03-4920-AB58-89FDE2D35B93@oucs.ox.ac.uk> References: <4C5EECE8.8010801@ultraslavonic.info> <1730F335-9ABF-4B71-8BC6-293512AB40F1@oucs.ox.ac.uk> <AB3BDF80-C19D-4C67-A841-554E0B215E17@inria.fr> <4C6066AA.70405@uleth.ca> <72A449D6-F91B-4A7F-AC37-2029B1034A7A@oucs.ox.ac.uk> <4C6089DE.2090005@uleth.ca> <6DD80D53-232F-4860-BFB7-4D99FCB04343@oucs.ox.ac.uk> <C7299541-5E99-4BBC-A0BE-B1A93158B960@inria.fr> <4C611BBE.2030201@oucs.ox.ac.uk> <4C6149B8.4040502@uvic.ca> <A35173BF-6A03-4920-AB58-89FDE2D35B93@oucs.ox.ac.uk> Message-ID: <4C616DDC.9090509@uvic.ca> On 10-08-10 07:19 AM, Sebastian Rahtz wrote: >> >> It could be dual-licenced, or even triple-licenced, to get around this. >> > good point Although on consideration, it might be a thornier problem than I originally thought. Wouldn't we have to get permission from every contributor for a change of licensing? That's been a problem for open-source projects in the past. > how strongly do people feel about this? our bottom line is (I assume) that we want the > Guidelines and their adjuncts completely freely redistributable and re-useable, but > > * we don't want anyone else claiming it is their work > * we don't want anyone producing versions of it (ie PDF) without source > * we don't want forked changed versions (ie schemas) without source I think the guidelines (or the source XML for the guidelines) and the schemas are two different types of thing. I don't think there's much to gain from trying to place any restrictions on the use and distribution of schemas. We all have everything to gain and nothing to lose from wider adoption of TEI-based schemas, and "forking" is customization, which we openly encourage. > so > > YES: someone sells eBook versions of the Guidelines translated into Greek, and makes the source changes available > NO: someone sells eBook versions of the Greek Guidelines, but does it by translating HTML output I would say YES to this. I don't care how they generate their text, as long as they acknowledge the source. > YES: someone makes changes to Lite, calls it MyLite, and distributes it as ODD + PDF + DTD > NO: someone produces MyLite.dtd by editing teilite.dtd and distributes it Again, I would say YES to this. Who cares how they arrive at their schema? It's a TEI schema -- we should be glad they're using and distributing it. > I do claim that the GPL is still the right tool, as the TEI Guidelines have the > characteristic of producing "compiled" forms which can be separately distributed > and even changed in that form, and we want to preserve the link back to a free > source form. My instinct is to be much more permissive; the only thing I'd want to encourage through licensing would be attribution (in the Creative Commons sense). But then again, if your root element is <TEI>, and your namespace is http://www.tei-c.org/ns/1.0, there's attribution right there. Cheers, Martin > but if there is an opendata/open document license which covers the situation, > lets licence under that too. > > > -- > Sebastian Rahtz > Information Manager, Oxford University Computing Services > 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 > > S?lo le pido a Dios > que el futuro no me sea indiferente > > > > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > -- Martin Holmes University of Victoria Humanities Computing and Media Centre (mholmes at uvic.ca) Half-Baked Software, Inc. (mholmes at halfbakedsoftware.com) martin at mholmes.com From sebastian.rahtz at oucs.ox.ac.uk Tue Aug 10 11:38:23 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 10 Aug 2010 16:38:23 +0100 Subject: [tei-council] ODD headers and licensing terms for customizations provided by TEI-C In-Reply-To: <4C616DDC.9090509@uvic.ca> References: <4C5EECE8.8010801@ultraslavonic.info> <1730F335-9ABF-4B71-8BC6-293512AB40F1@oucs.ox.ac.uk> <AB3BDF80-C19D-4C67-A841-554E0B215E17@inria.fr> <4C6066AA.70405@uleth.ca> <72A449D6-F91B-4A7F-AC37-2029B1034A7A@oucs.ox.ac.uk> <4C6089DE.2090005@uleth.ca> <6DD80D53-232F-4860-BFB7-4D99FCB04343@oucs.ox.ac.uk> <C7299541-5E99-4BBC-A0BE-B1A93158B960@inria.fr> <4C611BBE.2030201@oucs.ox.ac.uk> <4C6149B8.4040502@uvic.ca> <A35173BF-6A03-4920-AB58-89FDE2D35B93@oucs.ox.ac.uk> <4C616DDC.9090509@uvic.ca> Message-ID: <34F6CD47-6005-4A00-9C45-B4FA17DE91DD@oucs.ox.ac.uk> On 10 Aug 2010, at 16:18, Martin Holmes wrote: > Although on consideration, it might be a thornier problem than I > originally thought. Wouldn't we have to get permission from every > contributor for a change of licensing? That's been a problem for > open-source projects in the past. No, because we have always worked on the principle that the TEIC owns the IPR, not the individual. Actually, legally, we are in a mess, because none of us has explicitly assigned our rights to the TEIC via a contributor agreement, but can we agree to pretend I didn't mention that? > > schemas are two different types of thing. I don't think there's much to > gain from trying to place any restrictions on the use and distribution > of schemas. We all have everything to gain and nothing to lose from > wider adoption of TEI-based schemas, and "forking" is customization, > which we openly encourage. but not by tweaking the actual schema, surely? >> >> YES: someone sells eBook versions of the Guidelines translated into Greek, and makes the source changes available >> NO: someone sells eBook versions of the Greek Guidelines, but does it by translating HTML output > > I would say YES to this. I don't care how they generate their text, as > long as they acknowledge the source. > >> YES: someone makes changes to Lite, calls it MyLite, and distributes it as ODD + PDF + DTD >> NO: someone produces MyLite.dtd by editing teilite.dtd and distributes it > > Again, I would say YES to this. Who cares how they arrive at their > schema? It's a TEI schema -- we should be glad they're using and > distributing it. these are big philosophical questions, which we should resolve. The GPL licence we use now would enforce my NOs, I believe, so if everyone now believes this is wrong, we had better revisit with (with the Board). -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From daniel.odonnell at uleth.ca Tue Aug 10 12:11:12 2010 From: daniel.odonnell at uleth.ca (O'Donnell, Dan) Date: Tue, 10 Aug 2010 10:11:12 -0600 Subject: [tei-council] One Licence Does it all Message-ID: <4C617A20.5040703@uleth.ca> Perry (cc'd here) and John are perfectly happy aligning Tite with whatever we do with the rest of our stuff. So that's one point down. The next issue is how to get Tite into a regular maintenance schedule and authority. In this case, my understanding is that the will is there, it just needs direction. We already treat it as a TEI customisation; the question is probably simply taking initiative. Thanks to Kevin "The Hammer" Hawkins for moving us on this! -dan -- Daniel Paul O'Donnell Professor of English University of Lethbridge Chair and CEO, Text Encoding Initiative (http://www.tei-c.org/) Co-Chair, Digital Initiatives Advisory Board, Medieval Academy of America President-elect (English), Society for Digital Humanities/Soci?t? pour l'?tude des m?dias interactifs (http://sdh-semi.org/) Founding Director (2003-2009), Digital Medievalist Project (http://www.digitalmedievalist.org/) Vox: +1 403 329-2377 Fax: +1 403 382-7191 (non-confidential) Home Page: http://people.uleth.ca/~daniel.odonnell/ From sebastian.rahtz at oucs.ox.ac.uk Tue Aug 10 12:56:07 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 10 Aug 2010 17:56:07 +0100 Subject: [tei-council] One Licence Does it all In-Reply-To: <4C617A20.5040703@uleth.ca> References: <4C617A20.5040703@uleth.ca> Message-ID: <EB8BAE12-17C4-48CC-80BE-FD270A9662B8@oucs.ox.ac.uk> On 10 Aug 2010, at 17:11, O'Donnell, Dan wrote: > The next issue is how to get Tite into a regular maintenance schedule > and authority. In this case, my understanding is that the will is there, > it just needs direction. We already treat it as a TEI customisation; the > question is probably simply taking initiative. if we agree that the thing is simply another component of the guidelines, then we simply follow Kevin's lead, and have bugs/requests entered in Sourceforge, and acted upon by editorial team under council instruction -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From kevin.s.hawkins at ultraslavonic.info Tue Aug 10 13:07:07 2010 From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins) Date: Tue, 10 Aug 2010 13:07:07 -0400 Subject: [tei-council] Tite maintenance (was Re: One Licence Does it all) In-Reply-To: <EB8BAE12-17C4-48CC-80BE-FD270A9662B8@oucs.ox.ac.uk> References: <4C617A20.5040703@uleth.ca> <EB8BAE12-17C4-48CC-80BE-FD270A9662B8@oucs.ox.ac.uk> Message-ID: <4C61873B.3070105@ultraslavonic.info> On 8/10/2010 12:56 PM, Sebastian Rahtz wrote: > On 10 Aug 2010, at 17:11, O'Donnell, Dan wrote: > >> The next issue is how to get Tite into a regular maintenance schedule >> and authority. In this case, my understanding is that the will is there, >> it just needs direction. We already treat it as a TEI customisation; the >> question is probably simply taking initiative. > > > if we agree that the thing is simply another component of the guidelines, > then we simply follow Kevin's lead, and have bugs/requests entered > in Sourceforge, and acted upon by editorial team under council > instruction I agree that it would be good for all requests to revise the canonical version of Tite, maintained in SourceForge, to go as tickets in SourceForge. But we also want to make sure there is ongoing communication between this canonical version and Apex's fork (which they call Tite 1.1: http://accesstei.apexcovantage.com/Content/documents/TEI-Tite_guidelines__1.1.pdf ). We are promised a document from Perry Trolard describing changes made in this fork so that we can consider making these in the canonical version as well. While I suggested we do these before tackling any of my revisions, it might not really make a difference. After all, my errors are problems in 1.1 as well. Likewise, we would like Apex to continue informing someone on Council about any further changes they decide to make in their fork. We should also make sure that we communicate back to Apex any changes we make to the canonical version on our own (not at their suggestion) in case they want to incorporate any of these into their fork. Do we need a designated Council member whose job it is to maintain this communication with Apex? Kevin From mholmes at uvic.ca Tue Aug 10 13:11:28 2010 From: mholmes at uvic.ca (Martin Holmes) Date: Tue, 10 Aug 2010 10:11:28 -0700 Subject: [tei-council] ODD headers and licensing terms for customizations provided by TEI-C In-Reply-To: <34F6CD47-6005-4A00-9C45-B4FA17DE91DD@oucs.ox.ac.uk> References: <4C5EECE8.8010801@ultraslavonic.info> <1730F335-9ABF-4B71-8BC6-293512AB40F1@oucs.ox.ac.uk> <AB3BDF80-C19D-4C67-A841-554E0B215E17@inria.fr> <4C6066AA.70405@uleth.ca> <72A449D6-F91B-4A7F-AC37-2029B1034A7A@oucs.ox.ac.uk> <4C6089DE.2090005@uleth.ca> <6DD80D53-232F-4860-BFB7-4D99FCB04343@oucs.ox.ac.uk> <C7299541-5E99-4BBC-A0BE-B1A93158B960@inria.fr> <4C611BBE.2030201@oucs.ox.ac.uk> <4C6149B8.4040502@uvic.ca> <A35173BF-6A03-4920-AB58-89FDE2D35B93@oucs.ox.ac.uk> <4C616DDC.9090509@uvic.ca> <34F6CD47-6005-4A00-9C45-B4FA17DE91DD@oucs.ox.ac.uk> Message-ID: <4C618840.2070502@uvic.ca> On 10-08-10 08:38 AM, Sebastian Rahtz wrote: > > On 10 Aug 2010, at 16:18, Martin Holmes wrote: > >> Although on consideration, it might be a thornier problem than I >> originally thought. Wouldn't we have to get permission from every >> contributor for a change of licensing? That's been a problem for >> open-source projects in the past. > > No, because we have always worked on the principle that the TEIC > owns the IPR, not the individual. Actually, legally, we are in a mess, > because none of us has explicitly assigned our rights to the TEIC > via a contributor agreement, but can we agree to pretend I didn't mention > that? We may agree, but previous contributors will always have the right to disagree, and to block our attempts to change licensing terms on text they wrote, because of the absence of a contributor agreement. So the next question is: is this issue worth pursuing at all? If so, then we really would have to think about contacting everyone and getting them to sign an agreement. If that's too complicated to contemplate, then I think we're really stuck with the existing licence (not that that is bad, necessarily). >> schemas are two different types of thing. I don't think there's much to >> gain from trying to place any restrictions on the use and distribution >> of schemas. We all have everything to gain and nothing to lose from >> wider adoption of TEI-based schemas, and "forking" is customization, >> which we openly encourage. > but not by tweaking the actual schema, surely? I'm perhaps not really clear on what "the actual schema" is in this case. I can't honestly see why we would mind. How is tweaking the actual schema not just customization? >>> YES: someone sells eBook versions of the Guidelines translated into Greek, and makes the source changes available >>> NO: someone sells eBook versions of the Greek Guidelines, but does it by translating HTML output >> >> I would say YES to this. I don't care how they generate their text, as >> long as they acknowledge the source. >> >>> YES: someone makes changes to Lite, calls it MyLite, and distributes it as ODD + PDF + DTD >>> NO: someone produces MyLite.dtd by editing teilite.dtd and distributes it >> >> Again, I would say YES to this. Who cares how they arrive at their >> schema? It's a TEI schema -- we should be glad they're using and >> distributing it. > > these are big philosophical questions, which we should resolve. The > GPL licence we use now would enforce my NOs, I believe, so if everyone > now believes this is wrong, we had better revisit with (with the Board). The current GPL licence would (possibly) allow us to enforce those NOs if we wanted to. We might still agree that we don't care to, because it's not in the interest of propagating TEI. Cheers, Martin > Sebastian Rahtz > Information Manager, Oxford University Computing Services > 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 > > S?lo le pido a Dios > que el futuro no me sea indiferente > > > > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > -- Martin Holmes University of Victoria Humanities Computing and Media Centre (mholmes at uvic.ca) Half-Baked Software, Inc. (mholmes at halfbakedsoftware.com) martin at mholmes.com From sebastian.rahtz at oucs.ox.ac.uk Tue Aug 10 13:19:03 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 10 Aug 2010 18:19:03 +0100 Subject: [tei-council] Tite maintenance (was Re: One Licence Does it all) In-Reply-To: <4C61873B.3070105@ultraslavonic.info> References: <4C617A20.5040703@uleth.ca> <EB8BAE12-17C4-48CC-80BE-FD270A9662B8@oucs.ox.ac.uk> <4C61873B.3070105@ultraslavonic.info> Message-ID: <263818DD-B327-460F-B800-B24F6AC09B08@oucs.ox.ac.uk> On 10 Aug 2010, at 18:07, Kevin Hawkins wrote: > SourceForge. But we also want to make sure there is ongoing > communication between this canonical version and Apex's fork (which they > call Tite 1.1: > http://accesstei.apexcovantage.com/Content/documents/TEI-Tite_guidelines__1.1.pdf > ). > It really is quite depressing to see this come out without any chance to comment. oh well. -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From gabriel.bodard at kcl.ac.uk Tue Aug 10 14:09:52 2010 From: gabriel.bodard at kcl.ac.uk (Gabriel Bodard) Date: Tue, 10 Aug 2010 19:09:52 +0100 Subject: [tei-council] ODD headers and licensing terms for customizations provided by TEI-C In-Reply-To: <4C618840.2070502@uvic.ca> References: <4C5EECE8.8010801@ultraslavonic.info> <1730F335-9ABF-4B71-8BC6-293512AB40F1@oucs.ox.ac.uk> <AB3BDF80-C19D-4C67-A841-554E0B215E17@inria.fr> <4C6066AA.70405@uleth.ca> <72A449D6-F91B-4A7F-AC37-2029B1034A7A@oucs.ox.ac.uk> <4C6089DE.2090005@uleth.ca> <6DD80D53-232F-4860-BFB7-4D99FCB04343@oucs.ox.ac.uk> <C7299541-5E99-4BBC-A0BE-B1A93158B960@inria.fr> <4C611BBE.2030201@oucs.ox.ac.uk> <4C6149B8.4040502@uvic.ca> <A35173BF-6A03-4920-AB58-89FDE2D35B93@oucs.ox.ac.uk> <4C616DDC.9090509@uvic.ca> <34F6CD47-6005-4A00-9C45-B4FA17DE91DD@oucs.ox.ac.uk> <4C618840.2070502@uvic.ca> Message-ID: <4C6195F0.4090400@kcl.ac.uk> I think I'm largely in agreement with Martin in wanting the license to be more permissive and allowing dissemination without requiring too much beyond attribution. One concern below: On 10/08/2010 18:11, Martin Holmes wrote: > On 10-08-10 08:38 AM, Sebastian Rahtz wrote: >> but not by tweaking the actual schema, surely? > > I'm perhaps not really clear on what "the actual schema" is in this > case. I can't honestly see why we would mind. How is tweaking the actual > schema not just customization? While I agree that in principle there's not much wrong with a project customizing a TEI schema by hand (or by some other, non-canonical method) and distributing that with proper attribution and license, wouldn't a by-product of allowing this be to undermine the "downstream" aspect of the GPL (equiv of CC-ShareAlike)? By which I mean, if a project can circulate the modified schema (the software) like this, without making available their ODD (the code), then any project who wanted to make their ODD proprietary could claim that the schema was hand-edited. (I admit this is all rather unlikely, as industrial sabotage involving TEI schemas and ODDs is never going to be big business, but the downstream part of the GPL is there for a reason, and we probably shouldn't water it down.) G -- Dr Gabriel BODARD (Epigrapher, Digital Classicist, Pirate) Centre for Computing in the Humanities King's College London 26-29 Drury Lane London WC2B 5RL Email: gabriel.bodard at kcl.ac.uk Tel: +44 (0)20 7848 1388 Fax: +44 (0)20 7848 2980 http://www.digitalclassicist.org/ http://www.currentepigraphy.org/ From lou.burnard at oucs.ox.ac.uk Tue Aug 10 14:13:17 2010 From: lou.burnard at oucs.ox.ac.uk (Lou Burnard) Date: Tue, 10 Aug 2010 19:13:17 +0100 Subject: [tei-council] Tite maintenance (was Re: One Licence Does it all) In-Reply-To: <263818DD-B327-460F-B800-B24F6AC09B08@oucs.ox.ac.uk> References: <4C617A20.5040703@uleth.ca> <EB8BAE12-17C4-48CC-80BE-FD270A9662B8@oucs.ox.ac.uk> <4C61873B.3070105@ultraslavonic.info> <263818DD-B327-460F-B800-B24F6AC09B08@oucs.ox.ac.uk> Message-ID: <4C6196BD.9000009@oucs.ox.ac.uk> I think "depressing" is a bit of an understatement. What is the point of the TEI Council taking on maintenance of a TEI customisation which has already been forked? We can call it "canonical" if we like, but since the whole point of the TEI tite exercise is to define what Apex will undertake to deliver as part of the accessTEI scheme, what is the reason for having a "canonical" schema distinct from what Apex wish to specify in any case? On 10/08/10 18:19, Sebastian Rahtz wrote: > > On 10 Aug 2010, at 18:07, Kevin Hawkins wrote: > >> SourceForge. But we also want to make sure there is ongoing >> communication between this canonical version and Apex's fork (which they >> call Tite 1.1: >> http://accesstei.apexcovantage.com/Content/documents/TEI-Tite_guidelines__1.1.pdf >> ). >> > > It really is quite depressing to see this come out without > any chance to comment. oh well. > > -- > Sebastian Rahtz > Information Manager, Oxford University Computing Services > 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 > > S?lo le pido a Dios > que el futuro no me sea indiferente > > > > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council From lou.burnard at oucs.ox.ac.uk Tue Aug 10 14:17:20 2010 From: lou.burnard at oucs.ox.ac.uk (Lou Burnard) Date: Tue, 10 Aug 2010 19:17:20 +0100 Subject: [tei-council] Tite maintenance (was Re: One Licence Does it all) In-Reply-To: <4C61873B.3070105@ultraslavonic.info> References: <4C617A20.5040703@uleth.ca> <EB8BAE12-17C4-48CC-80BE-FD270A9662B8@oucs.ox.ac.uk> <4C61873B.3070105@ultraslavonic.info> Message-ID: <4C6197B0.80506@oucs.ox.ac.uk> On 10/08/10 18:07, Kevin Hawkins wrote: >> I agree that it would be good for all requests to revise the canonical > version of Tite, maintained in SourceForge, to go as tickets in > SourceForge. But we also want to make sure there is ongoing > communication between this canonical version and Apex's fork (which they > call Tite 1.1: > http://accesstei.apexcovantage.com/Content/documents/TEI-Tite_guidelines__1.1.pdf > ). I note that every page of this document, which bears a very strong resemblence to a TEI document, bears the text "Proprietary and confidential". Can we sue them for infringing the terms of the GPL? From kevin.s.hawkins at ultraslavonic.info Tue Aug 10 14:20:44 2010 From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins) Date: Tue, 10 Aug 2010 14:20:44 -0400 Subject: [tei-council] Fwd: suggestions for TEI Tite documentation on AccesTEI portal Message-ID: <4C61987C.4010901@ultraslavonic.info> Regarding "proprietary and confidential", I sent this to Apex a few days ago but haven't heard back since then. -------- Original Message -------- Subject: suggestions for TEI Tite documentation on AccesTEI portal Date: Sun, 08 Aug 2010 14:32:42 -0400 From: Kevin Hawkins <kevin.s.hawkins at ultraslavonic.info> To: Ed Moore <emoore at apexcovantage.com> Hi Ed, Regarding http://accesstei.apexcovantage.com/Content/documents/TEI-Tite_guidelines__1.1.pdf : 1. The title page says "Apex TEI-TITE Guidelines For TEI Access Project". I think you'll want to change that to something like "Guidelines for Encoding Documents for AccessTEI". 2. The running headers say the document is proprietary and confidential, but I think you'll want to remove the confidential statement since it's publicly available. It would be good to clarify the copyright on the document. I've asked the TEI Council to clarify the copyright on TEI Tite itself. It seems the TEI Consortium will release it under GNU GPL 2, meaning derivations such as this one would also need to be released under that. 2. You refer to the schema you're using as "TEI TITE" and "TITE", but the version on which yours is based is called "Tite". It would be good if your introduction clarified that the version of Tite you're using is derived from the version created and maintained by the TEI Consortium. Please let know if you have any questions, Kevin From laurent.romary at inria.fr Tue Aug 10 14:21:34 2010 From: laurent.romary at inria.fr (Laurent Romary) Date: Tue, 10 Aug 2010 20:21:34 +0200 Subject: [tei-council] One Licence Does it all In-Reply-To: <EB8BAE12-17C4-48CC-80BE-FD270A9662B8@oucs.ox.ac.uk> References: <4C617A20.5040703@uleth.ca> <EB8BAE12-17C4-48CC-80BE-FD270A9662B8@oucs.ox.ac.uk> Message-ID: <8C297ECB-4AC7-43B2-B7AE-A91A96A2F942@inria.fr> Le 10 ao?t 10 ? 18:56, Sebastian Rahtz a ?crit : > > On 10 Aug 2010, at 17:11, O'Donnell, Dan wrote: > >> The next issue is how to get Tite into a regular maintenance schedule >> and authority. In this case, my understanding is that the will is >> there, >> it just needs direction. We already treat it as a TEI >> customisation; the >> question is probably simply taking initiative. > > > if we agree that the thing is simply another component of the > guidelines, > then we simply follow Kevin's lead, and have bugs/requests entered > in Sourceforge, and acted upon by editorial team under council > instruction Exactly. Looks like a no-brainer activity (from an organisational point of view, I mean - let us expect Kevin has a few difficult cases for us). To answer Lou's question on another thread: things you've not seen implemented from your spring comments could be filed in as SF tickets, I think. From lou.burnard at oucs.ox.ac.uk Tue Aug 10 14:22:51 2010 From: lou.burnard at oucs.ox.ac.uk (Lou Burnard) Date: Tue, 10 Aug 2010 19:22:51 +0100 Subject: [tei-council] One Licence Does it all In-Reply-To: <8C297ECB-4AC7-43B2-B7AE-A91A96A2F942@inria.fr> References: <4C617A20.5040703@uleth.ca> <EB8BAE12-17C4-48CC-80BE-FD270A9662B8@oucs.ox.ac.uk> <8C297ECB-4AC7-43B2-B7AE-A91A96A2F942@inria.fr> Message-ID: <4C6198FB.9060700@oucs.ox.ac.uk> That's all very well, but what is the point of our making changes in the canonical TEI Tite so long as Access TEI uses something else? On 10/08/10 19:21, Laurent Romary wrote: > > Le 10 ao?t 10 ? 18:56, Sebastian Rahtz a ?crit : > >> >> On 10 Aug 2010, at 17:11, O'Donnell, Dan wrote: >> >>> The next issue is how to get Tite into a regular maintenance schedule >>> and authority. In this case, my understanding is that the will is >>> there, >>> it just needs direction. We already treat it as a TEI >>> customisation; the >>> question is probably simply taking initiative. >> >> >> if we agree that the thing is simply another component of the >> guidelines, >> then we simply follow Kevin's lead, and have bugs/requests entered >> in Sourceforge, and acted upon by editorial team under council >> instruction > > > Exactly. Looks like a no-brainer activity (from an organisational > point of view, I mean - let us expect Kevin has a few difficult cases > for us). > To answer Lou's question on another thread: things you've not seen > implemented from your spring comments could be filed in as SF tickets, > I think. > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council From laurent.romary at inria.fr Tue Aug 10 14:26:37 2010 From: laurent.romary at inria.fr (Laurent Romary) Date: Tue, 10 Aug 2010 20:26:37 +0200 Subject: [tei-council] One Licence Does it all In-Reply-To: <4C6198FB.9060700@oucs.ox.ac.uk> References: <4C617A20.5040703@uleth.ca> <EB8BAE12-17C4-48CC-80BE-FD270A9662B8@oucs.ox.ac.uk> <8C297ECB-4AC7-43B2-B7AE-A91A96A2F942@inria.fr> <4C6198FB.9060700@oucs.ox.ac.uk> Message-ID: <979E213B-DED1-4F46-977C-99C730D973CB@inria.fr> The point is that we should make sure that a) Apex uses the schema we maintain b) Apex is informed of our SF tickets on the fly (can we automatize this on SF?) and can react when differences are too big. @Dan: please make sure that Apex realign quickly Laurent Le 10 ao?t 10 ? 20:22, Lou Burnard a ?crit : > That's all very well, but what is the point of our making changes in > the > canonical TEI Tite so long as Access TEI uses something else? > > > On 10/08/10 19:21, Laurent Romary wrote: >> >> Le 10 ao?t 10 ? 18:56, Sebastian Rahtz a ?crit : >> >>> >>> On 10 Aug 2010, at 17:11, O'Donnell, Dan wrote: >>> >>>> The next issue is how to get Tite into a regular maintenance >>>> schedule >>>> and authority. In this case, my understanding is that the will is >>>> there, >>>> it just needs direction. We already treat it as a TEI >>>> customisation; the >>>> question is probably simply taking initiative. >>> >>> >>> if we agree that the thing is simply another component of the >>> guidelines, >>> then we simply follow Kevin's lead, and have bugs/requests entered >>> in Sourceforge, and acted upon by editorial team under council >>> instruction >> >> >> Exactly. Looks like a no-brainer activity (from an organisational >> point of view, I mean - let us expect Kevin has a few difficult cases >> for us). >> To answer Lou's question on another thread: things you've not seen >> implemented from your spring comments could be filed in as SF >> tickets, >> I think. >> _______________________________________________ >> tei-council mailing list >> tei-council at lists.village.Virginia.EDU >> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Laurent Romary INRIA & HUB-IDSL laurent.romary at inria.fr From laurent.romary at inria.fr Tue Aug 10 14:28:26 2010 From: laurent.romary at inria.fr (Laurent Romary) Date: Tue, 10 Aug 2010 20:28:26 +0200 Subject: [tei-council] Fwd: suggestions for TEI Tite documentation on AccesTEI portal In-Reply-To: <4C61987C.4010901@ultraslavonic.info> References: <4C61987C.4010901@ultraslavonic.info> Message-ID: <95D1F082-497B-446F-A0B6-2FF1B31B62BE@inria.fr> Very good, Kevin. Again, we need to secure this on the basis of our contractual link with them. But the lead should be on us. Le 10 ao?t 10 ? 20:20, Kevin Hawkins a ?crit : > Regarding "proprietary and confidential", I sent this to Apex a few > days > ago but haven't heard back since then. > > -------- Original Message -------- > Subject: suggestions for TEI Tite documentation on AccesTEI portal > Date: Sun, 08 Aug 2010 14:32:42 -0400 > From: Kevin Hawkins <kevin.s.hawkins at ultraslavonic.info> > To: Ed Moore <emoore at apexcovantage.com> > > Hi Ed, > > Regarding > http://accesstei.apexcovantage.com/Content/documents/TEI-Tite_guidelines__1.1.pdf > > : > > 1. The title page says "Apex TEI-TITE Guidelines For TEI Access > Project". I think you'll want to change that to something like > "Guidelines for Encoding Documents for AccessTEI". > > 2. The running headers say the document is proprietary and > confidential, > but I think you'll want to remove the confidential statement since > it's > publicly available. It would be good to clarify the copyright on the > document. I've asked the TEI Council to clarify the copyright on TEI > Tite itself. It seems the TEI Consortium will release it under GNU > GPL > 2, meaning derivations such as this one would also need to be released > under that. > > 2. You refer to the schema you're using as "TEI TITE" and "TITE", but > the version on which yours is based is called "Tite". It would be > good > if your introduction clarified that the version of Tite you're using > is > derived from the version created and maintained by the TEI Consortium. > > Please let know if you have any questions, > > Kevin > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Laurent Romary INRIA & HUB-IDSL laurent.romary at inria.fr From kevin.s.hawkins at ultraslavonic.info Tue Aug 10 14:31:52 2010 From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins) Date: Tue, 10 Aug 2010 14:31:52 -0400 Subject: [tei-council] TEI Tite maintenance (was Re: One Licence Does it all) In-Reply-To: <979E213B-DED1-4F46-977C-99C730D973CB@inria.fr> References: <4C617A20.5040703@uleth.ca> <EB8BAE12-17C4-48CC-80BE-FD270A9662B8@oucs.ox.ac.uk> <8C297ECB-4AC7-43B2-B7AE-A91A96A2F942@inria.fr> <4C6198FB.9060700@oucs.ox.ac.uk> <979E213B-DED1-4F46-977C-99C730D973CB@inria.fr> Message-ID: <4C619B18.6020100@ultraslavonic.info> My vision is that the TEI Council will continue maintaining the canonical version of Tite so that some day, if Apex and the TEI-C end their relationship, we will have an improved starting point for another vendor to use in this program rather than relying on Apex to give us their latest schema. Furthermore, if another vendor wants to start up their own bulk digitization program while AccessTEI is still going with Apex, this vendor has a good starting point in the form of the canonical version with corrections made to it. Kevin On 8/10/2010 2:26 PM, Laurent Romary wrote: > The point is that we should make sure that > a) Apex uses the schema we maintain > b) Apex is informed of our SF tickets on the fly (can we automatize > this on SF?) and can react when differences are too big. > @Dan: please make sure that Apex realign quickly > Laurent > > Le 10 ao?t 10 ? 20:22, Lou Burnard a ?crit : > >> That's all very well, but what is the point of our making changes in >> the >> canonical TEI Tite so long as Access TEI uses something else? From laurent.romary at inria.fr Tue Aug 10 14:42:24 2010 From: laurent.romary at inria.fr (Laurent Romary) Date: Tue, 10 Aug 2010 20:42:24 +0200 Subject: [tei-council] TEI Tite maintenance (was Re: One Licence Does it all) In-Reply-To: <4C619B18.6020100@ultraslavonic.info> References: <4C617A20.5040703@uleth.ca> <EB8BAE12-17C4-48CC-80BE-FD270A9662B8@oucs.ox.ac.uk> <8C297ECB-4AC7-43B2-B7AE-A91A96A2F942@inria.fr> <4C6198FB.9060700@oucs.ox.ac.uk> <979E213B-DED1-4F46-977C-99C730D973CB@inria.fr> <4C619B18.6020100@ultraslavonic.info> Message-ID: <16D5081B-6C72-4E8C-A80C-D75092BAA2E5@inria.fr> The serious issue is when one TEI member will make use of AccessTEI but come accros discrepancy with what he thinks would be the reference schema (namely Tite-canonical as maintained by us). This why I suggest a quick re-alignment with Apex (action on Dan) and then, as you suggest, have a council member act as liaison. Laurent Le 10 ao?t 10 ? 20:31, Kevin Hawkins a ?crit : > My vision is that the TEI Council will continue maintaining the > canonical version of Tite so that some day, if Apex and the TEI-C end > their relationship, we will have an improved starting point for > another > vendor to use in this program rather than relying on Apex to give us > their latest schema. > > Furthermore, if another vendor wants to start up their own bulk > digitization program while AccessTEI is still going with Apex, this > vendor has a good starting point in the form of the canonical version > with corrections made to it. > > Kevin > > On 8/10/2010 2:26 PM, Laurent Romary wrote: >> The point is that we should make sure that >> a) Apex uses the schema we maintain >> b) Apex is informed of our SF tickets on the fly (can we automatize >> this on SF?) and can react when differences are too big. >> @Dan: please make sure that Apex realign quickly >> Laurent >> >> Le 10 ao?t 10 ? 20:22, Lou Burnard a ?crit : >> >>> That's all very well, but what is the point of our making changes in >>> the >>> canonical TEI Tite so long as Access TEI uses something else? > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Laurent Romary INRIA & HUB-IDSL laurent.romary at inria.fr From sebastian.rahtz at oucs.ox.ac.uk Tue Aug 10 15:05:09 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 10 Aug 2010 20:05:09 +0100 Subject: [tei-council] ODD headers and licensing terms for customizations provided by TEI-C In-Reply-To: <4C618840.2070502@uvic.ca> References: <4C5EECE8.8010801@ultraslavonic.info> <1730F335-9ABF-4B71-8BC6-293512AB40F1@oucs.ox.ac.uk> <AB3BDF80-C19D-4C67-A841-554E0B215E17@inria.fr> <4C6066AA.70405@uleth.ca> <72A449D6-F91B-4A7F-AC37-2029B1034A7A@oucs.ox.ac.uk> <4C6089DE.2090005@uleth.ca> <6DD80D53-232F-4860-BFB7-4D99FCB04343@oucs.ox.ac.uk> <C7299541-5E99-4BBC-A0BE-B1A93158B960@inria.fr> <4C611BBE.2030201@oucs.ox.ac.uk> <4C6149B8.4040502@uvic.ca> <A35173BF-6A03-4920-AB58-89FDE2D35B93@oucs.ox.ac.uk> <4C616DDC.9090509@uvic.ca> <34F6CD47-6005-4A00-9C45-B4FA17DE91DD@oucs.ox.ac.uk> <4C618840.2070502@uvic.ca> Message-ID: <FE5CFF3C-312D-460F-A0CD-FA01DFD051EC@oucs.ox.ac.uk> > We may agree, but previous contributors will always have the right to > disagree, and to block our attempts to change licensing terms on text > they wrote, because of the absence of a contributor agreement. They can try. We'll fight them on the beaches. > So the > next question is: is this issue worth pursuing at all? If so, then we > really would have to think about contacting everyone and getting them to > sign an agreement. If that's too complicated to contemplate, then I > think we're really stuck with the existing licence (not that that is > bad, necessarily). but they never agreed to that licence in the first place :-} However, I would take the line that all contributions to the Guidelines up until recently have been fed through the editors, who accepted them as grist to a mill and then tuned their own prose. So I might claim that Michael, Lou and Syd contributed all the IPR; and they were all paid by the TEIC to do so, therefore the TEIC owns the IPR. > > The current GPL licence would (possibly) allow us to enforce those NOs > if we wanted to. We might still agree that we don't care to, because > it's not in the interest of propagating TEI. thats a dangerous game to play. if we ever _do_ want to enforce it, people might ask why we never pursued obvious violations in the past. A judge would take that into account. -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From sebastian.rahtz at oucs.ox.ac.uk Tue Aug 10 15:10:55 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 10 Aug 2010 20:10:55 +0100 Subject: [tei-council] ODD headers and licensing terms for customizations provided by TEI-C In-Reply-To: <4C6195F0.4090400@kcl.ac.uk> References: <4C5EECE8.8010801@ultraslavonic.info> <1730F335-9ABF-4B71-8BC6-293512AB40F1@oucs.ox.ac.uk> <AB3BDF80-C19D-4C67-A841-554E0B215E17@inria.fr> <4C6066AA.70405@uleth.ca> <72A449D6-F91B-4A7F-AC37-2029B1034A7A@oucs.ox.ac.uk> <4C6089DE.2090005@uleth.ca> <6DD80D53-232F-4860-BFB7-4D99FCB04343@oucs.ox.ac.uk> <C7299541-5E99-4BBC-A0BE-B1A93158B960@inria.fr> <4C611BBE.2030201@oucs.ox.ac.uk> <4C6149B8.4040502@uvic.ca> <A35173BF-6A03-4920-AB58-89FDE2D35B93@oucs.ox.ac.uk> <4C616DDC.9090509@uvic.ca> <34F6CD47-6005-4A00-9C45-B4FA17DE91DD@oucs.ox.ac.uk> <4C618840.2070502@uvic.ca> <4C6195F0.4090400@kcl.ac.uk> Message-ID: <A765BB39-D22E-49CF-931C-AB1715B12138@oucs.ox.ac.uk> On 10 Aug 2010, at 19:09, Gabriel Bodard wrote: > I think I'm largely in agreement with Martin in wanting the license to > be more permissive and allowing dissemination without requiring too much > beyond attribution. leaving aside the issue of whether we own the IPR for the moment (I believe we do), we can of course issue future releases under a more relaxed licence. Its tricky, this, because the Council of 2010 may have, reasonably, a different opinion from the Council of 2004 (or whenever it was), but we cant keep changing every few years :-} > aspect of the GPL (equiv of CC-ShareAlike)? By which I mean, if a > project can circulate the modified schema (the software) like this, > without making available their ODD (the code), then any project who > wanted to make their ODD proprietary could claim that the schema was > hand-edited. well, indeed. thats the scenario I personally want to avoid. -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From sebastian.rahtz at oucs.ox.ac.uk Tue Aug 10 15:18:12 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 10 Aug 2010 20:18:12 +0100 Subject: [tei-council] One Licence Does it all In-Reply-To: <20100810184123.GC34559@pjts-poly-2.local> References: <4C617A20.5040703@uleth.ca> <EB8BAE12-17C4-48CC-80BE-FD270A9662B8@oucs.ox.ac.uk> <8C297ECB-4AC7-43B2-B7AE-A91A96A2F942@inria.fr> <20100810184123.GC34559@pjts-poly-2.local> Message-ID: <D35F0E6B-C072-429C-8564-CFC567A63FB2@oucs.ox.ac.uk> On 10 Aug 2010, at 19:41, Perry Trolard wrote: > > If this is the recommended course, perhaps Dan & I should compare notes > about pending changes to Tite coming out of Apex, then I can file > tickets for each. which seems weird. Apex can't change TEI Tite, only we can do that. They should be submitting bugs or feature requests, which we implement > > (Dan, I recall that we were waiting on the results of a review of Apex's > schema from an outside party [David Seaman?], even weirder. What on earth is a review of the schema all about? or is this a different schema? I am afraid I don't feel the TEI Board, or sub-committee thereof, has handled this Apex thing very well. To find such a lack of clarity about fundamental aspects like licensing, authoritative files, and maintenance procedures, so late in the day is disturbing. I may be told, of course, that this was all done by the TEI/Apex work team, and its all sorted - but that would bring me back to asking exactly who is in charge of this customization and its offshoots? -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From daniel.odonnell at uleth.ca Tue Aug 10 16:55:58 2010 From: daniel.odonnell at uleth.ca (O'Donnell, Dan) Date: Tue, 10 Aug 2010 14:55:58 -0600 Subject: [tei-council] One Licence Does it all In-Reply-To: <D35F0E6B-C072-429C-8564-CFC567A63FB2@oucs.ox.ac.uk> References: <4C617A20.5040703@uleth.ca> <EB8BAE12-17C4-48CC-80BE-FD270A9662B8@oucs.ox.ac.uk> <8C297ECB-4AC7-43B2-B7AE-A91A96A2F942@inria.fr> <20100810184123.GC34559@pjts-poly-2.local> <D35F0E6B-C072-429C-8564-CFC567A63FB2@oucs.ox.ac.uk> Message-ID: <4C61BCDE.8000802@uleth.ca> I think people are confusing a couple of different things here, and that it is worthwhile to get them straight so that we understand what we are wanting to do and why others are acting the way they are. The first issue has to do with a canonical Tite and Apex's implementation of it at any one moment. I am frankly failing to see why this is getting everybody so riled up. We do not demand that any actual users reflect the real-time status of the latest version of a TEI ODD. Instead--and this is why we've been concerned about version numbers and the like lately--we expect them to derive /a/ version drawn, customised, extended, or whatever, for their own internal use. I imagine that we assume that such users will return every so often to the fount to update the version they are using in house. But I'd be surprised if a majority of us really through that users use the TEI through daily builds as it were. The same is true of Tite and Apex. They can't be expected to use the bleeding edge version to train their keyboarders (were Tite part of our regular revision programme, which it isn't yet--though thankfully that's about to change). They need to have a temporarily fixed schema that nails down some decisions for a reasonable period of time. And then, like we hope all users, they will presumably return to the source every so often to adopt the changes and improvements that the TEI have introduced in the meantime. So we should always expect that there will be differences between the most recent TEI ODD and the version used by a project or programme like AccessTEI, the main exception perhaps being on the day the update their schemas. The second thing to keep in mind is that the Canonicalisation of Tite is in fact something like a reverse fork: Perry developed Tite on the basis of schemas used by major libraries for their digitisation projects which were in turn developed from the TEI. And he built it as a customisation. As the TEI takes over on-going development and maintenance, the main task is naturally going to involve discovering and reconciling the bits where the forking happened. A second implication of this reverse forking is that Perry, and Apex, have been working without the usual support mechanisms and workflows we all expect and value in everything the TEI does with things it controls officially--so things like sf ticket workflows were not obviously established. When they needed to do things--for example, like adjust documentation so that it didn't include examples and text that referred to other things not in Tite--it made reasonable sense to handle this in-house rather than wait for the TEI to establish a maintenance mechanism for it. I think it is a very positive reflection on the people involved that much of this work was in fact done in ways that maintained the connection to the Guidelines and the ODD mechanism more generally. Our work on the ODD in Dublin, including particularly the ability to positively include rather than negatively eliminate elements and the development of a robust system for indicating versions and sources is a direct result of issues discovered during the Apex/Tite review. Many other users of the TEI do similar reviews and evaluations and make similar changes in far less responsible ways even when they have access to the established ticket system we use for our other ODDs. And these guys were working under commercial pressure--including from us--to get the work done. Rather than concentrating on what's wrong or what we would have done differently if Tite had been designed as an official project and run from the beginning within our workflows and processes, I think we should be looking at what we can now do to make Tite and its user base work better and more closely within the TEI (finish reversing the fork so to speak). We claim we want to encourage people to develop customisations; we also claim that we are interested in having commercial and quasi-commercial instances take up the ODD the TEI and develop appropriate task-oriented customisations. Tite has been a leader in this area, and, like any pathfinder, has discovered all the bumps and detours in the road that we'll be able to smooth out for others. We have already benefited significantly from the relationship. Also we should remember that it is only know we seem able to do this: when the subject came up in Nancy, we left it on the table because we didn't really know what to do about making it "official." The fact we can develop a real plan now is probably a sign that things have developed enough to allow us to do it profitably now. Rather than railing about law suits and god knows what else, maybe the thing to do is to simply place Tite in the ticket system, start maintaining it, and let people involved know how they can contribute. Given that we haven't been maintaining Tite this way yet, we will have to take a deep breath and realise that implementing a process like this will mean re-proposing ideas and comments that got missed when it wasn't enjoying such a robust maintenance system and introducing tickets based on proposals that were initially introduced in ways that we deprecate. I have the impression we are pushing (sometimes even a little rudely perhaps) against an open door. I don't know anybody who does not want to see the same end goal: a canonical, TEI maintained and supported Tite ODD with a regular release schedule and all the benefits of the ticket system and the like. And I don't know how people can be clearer about their willingness to work with us than indicating that they'd love to and they are happy with everything we propose. If we can't handle working with people who really want to work with us and have immense good will towards us, then I don't see us ever succeeding in our desire to work further with academic publishers, many of whom have a much heavier investment in their own ways of doing things and less of an intrinsic desire to work with the TEI. So this is also a test of us and how honestly we are interested in working with others, as well. This is perhaps especially true of our ability to work with commercial entities like Apex. They really don't deserve some of the acrimony they have been shown, both here and when they were in Michigan. On 10-08-10 01:18 PM, Sebastian Rahtz wrote: > On 10 Aug 2010, at 19:41, Perry Trolard wrote: > >> If this is the recommended course, perhaps Dan& I should compare notes >> about pending changes to Tite coming out of Apex, then I can file >> tickets for each. >> > which seems weird. Apex can't change TEI Tite, only we can do that. They should > be submitting bugs or feature requests, which we implement > > >> (Dan, I recall that we were waiting on the results of a review of Apex's >> schema from an outside party [David Seaman?], >> > even weirder. What on earth is a review of the schema all about? or is this a different > schema? > > I am afraid I don't feel the TEI Board, or sub-committee thereof, has handled > this Apex thing very well. To find such a lack of clarity about fundamental > aspects like licensing, authoritative files, and maintenance procedures, so late > in the day is disturbing. I may be told, of course, that this was all done by the > TEI/Apex work team, and its all sorted - but that would bring me back to asking > exactly who is in charge of this customization and its offshoots? > > > -- > Sebastian Rahtz > Information Manager, Oxford University Computing Services > 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 > > S?lo le pido a Dios > que el futuro no me sea indiferente > > > > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > -- Daniel Paul O'Donnell Professor of English University of Lethbridge Chair and CEO, Text Encoding Initiative (http://www.tei-c.org/) Co-Chair, Digital Initiatives Advisory Board, Medieval Academy of America President-elect (English), Society for Digital Humanities/Soci?t? pour l'?tude des m?dias interactifs (http://sdh-semi.org/) Founding Director (2003-2009), Digital Medievalist Project (http://www.digitalmedievalist.org/) Vox: +1 403 329-2377 Fax: +1 403 382-7191 (non-confidential) Home Page: http://people.uleth.ca/~daniel.odonnell/ From lou.burnard at oucs.ox.ac.uk Tue Aug 10 17:20:13 2010 From: lou.burnard at oucs.ox.ac.uk (Lou Burnard) Date: Tue, 10 Aug 2010 22:20:13 +0100 Subject: [tei-council] Fwd: Tite: header Message-ID: <4C61C28D.9090204@oucs.ox.ac.uk> Here's a note I sent to Perry, Laurent, and Dan back in March about what I consider to be a really off the wall modification introduced into TEI Tite. I never got any response, which is fine, we're all busy. But I would like to know whether anyone else feels as I do, or whether I should just keep this particular opinion to myself. -------- Original Message -------- Subject: Tite: header Date: Wed, 3 Mar 2010 15:03:40 +0000 From: Lou <lou.burnard at oucs.ox.ac.uk> To: Perry Trolard <ptrolard at artsci.wustl.edu>, Laurent Romary <laurent.romary at loria.fr>, "daniel.odonnell at uleth.ca" <daniel.odonnell at uleth.ca> Why no TEI Header in TEI Tite documents? The spec at http://www.tei-c.org/release/doc/tei-p5-exemplars/html/tei_tite.doc.html#teistruct says "Tite omits the <teiHeader> element as a convenience to transcribers. This departs from normal TEI practice, which requires <TEI> as the root element, containing <teiHeader> and text elements. In order to bring a document encoded in TEI Tite into adherence with the TEI abstract model, projects should add a teiHeader before engaging in post-transcription processing. " Why is it a "convenience to transcribers" to prevent them from adding useful metadata to the text they have described? In its absence, how will they indicate a) which text this xml document is supposed to represent or be a part of? b) when they did it? c) what's the status (preliminary, finished, proofed etc.) of this xml document? d) who's responsible for shipping it, paying for it, handling questions about it? etc? Presumably they will still do those things somehow -- by file naming conventions, associated paper work, mutual convention, or other means... Why not use the tool at hand for the job? No-one is saying that a "tite" TEI Header (or any other) need contain a kosher bibliographic description -- for that job we apply the rabbinical skills of the cataloguers when the xml document is accessioned. But it can still contain all that is needed for conformance to the TEI abstract model, namely * a title * a source description * a responsibility statement The title might be "text number 9456", the source description might be "microfilm batch number 6181032" and the responsibility statement might be "Joes Garage" but that would still be better than nothing at all, surely? I think the decision to junk the header in this context shows a surprising lack of imagination about what it's meant for, and how it can be used. I suggest we should try a bit harder to propose some minimal header structure that would fit in with the work flow anticipated for Tite documents. My belief is that Apex would welcome such an idea, though I haven't yet asked them! Lou From sebastian.rahtz at oucs.ox.ac.uk Tue Aug 10 17:29:26 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 10 Aug 2010 22:29:26 +0100 Subject: [tei-council] One Licence Does it all In-Reply-To: <4C61BCDE.8000802@uleth.ca> References: <4C617A20.5040703@uleth.ca> <EB8BAE12-17C4-48CC-80BE-FD270A9662B8@oucs.ox.ac.uk> <8C297ECB-4AC7-43B2-B7AE-A91A96A2F942@inria.fr> <20100810184123.GC34559@pjts-poly-2.local> <D35F0E6B-C072-429C-8564-CFC567A63FB2@oucs.ox.ac.uk> <4C61BCDE.8000802@uleth.ca> Message-ID: <1F690F14-354D-4288-B958-976A9F2C36E7@oucs.ox.ac.uk> On 10 Aug 2010, at 21:55, O'Donnell, Dan wrote: > The same is true of Tite and Apex. They can't be expected to use the > bleeding edge version to train their keyboarders (were Tite part of our > regular revision programme, which it isn't yet--though thankfully that's > about to change). They need to have a temporarily fixed schema that > nails down some decisions for a reasonable period of time. Sure. And we want to say what that schema is, not them. > introduced in the meantime. So we should always expect that there will > be differences between the most recent TEI ODD and the version used by a > project or programme like AccessTEI, We expect there will be differences between the current Tite (stable for, say, 3 years) and the current P5 (on a thrice-yearly update cycle), agreed. We do not expect the schema used by Apex to differ from what is created by running the Tite ODD at any point during those 3 years, as the ODD will be tied to a release. > The second thing to keep in mind is that the Canonicalisation of Tite is > in fact something like a reverse fork: Perry developed Tite on the basis > of schemas used by major libraries for their digitisation projects which > were in turn developed from the TEI. And he built it as a customisation. > As the TEI takes over on-going development and maintenance, the main > task is naturally going to involve discovering and reconciling the bits > where the forking happened. Eh? There was no forking involved. Perry created the Tite customization of TEI based on paper examination of the library DTDs, yes. It was discussed in detail in Berlin, and we got it conformant and nice and all. There isn't any reconciling or anything to do that I know of. At Berlin we agreed the Council was responsible for it. > > A second implication of this reverse forking is that Perry, and Apex, > have been working without the usual support mechanisms and workflows I can't imagine why they would think this. Since Berlin, Tite has been delvered as a TEI exemplar ODD, maintained like all the rest. We have made changes to it every year to keep it in sync and valid. > When they needed to do things--for example, like adjust > documentation so that it didn't include examples and text that referred > to other things not in Tite--it made reasonable sense to handle this > in-house rather than wait for the TEI to establish a maintenance > mechanism for it. sorry, but this is nonsensical. The mechanism for adding their own examples, suppressing existing ones, changing text etc is all inherent in the ODD setup. Apex may have chosen to ignore that and go their own way in a Word file, but not for lack of any type of support or help from us. > I think it is a very positive reflection on the people > involved that much of this work was in fact done in ways that maintained > the connection to the Guidelines and the ODD mechanism more generally. as opposed to what, though? yes, its good that Tite is a TEI customization rather than a free-standing schema... if it wasn't. we would not be worried about it. > Many > other users of the TEI do similar reviews and evaluations and make > similar changes in far less responsible ways even when they have access > to the established ticket system we use for our other ODDs. And these > guys were working under commercial pressure--including from us--to get > the work done. you puzzle me. You talk as if Apex, and Perry, came up with this on their own, and beavered away without help from the TEI. Unless my brain is entirely addled. the TEIC had a grant from Mellon which was used to pay Perry to develop Tite. When It was complete, we then asked suppliers to tender for doing digitisation work against the schema, and Apex came in. What work did their folks do? did you ask them to do something extra? > > Rather than concentrating on what's wrong or what we would have done > differently if Tite had been designed as an official project and run > from the beginning within our workflows and processes It was, though. I really think you are rewriting history in saying otherwise. > We claim we want to encourage people to develop customisations; > we also claim that we are interested in having commercial and > quasi-commercial instances take up the ODD the TEI and develop > appropriate task-oriented customisations. Tite has been a leader in this > area, and, like any pathfinder, has discovered all the bumps and detours > in the road that we'll be able to smooth out for others. I simply don't recognize this as bearing a relation to reality as I have lived it over the last however-many-years Tite has been touted around.... .... > This is > perhaps especially true of our ability to work with commercial entities > like Apex. They really don't deserve some of the acrimony they have been > shown, both here and when they were in Michigan. > I don't feel acrimony against Apex, what was the beef in Michigan? but I don't understand why you're so defensive about them. You and John and whoever came to a nice commercial deal with them to do digitisation against a limited TEI subset which we developed, which deal is all well and nice. Where's the issue? we didn't ask them to develop a schema, or documentation, or anything. I would have been entirely happy if Tite had a been a community-maintained customization like Epidoc, entirely outside the remit of this Council. But it was decided that the TEIC would own it, and try to use it as a member benefit and so on, and that the Council should oversee its integrity. My complaint all along is about the failure to involve the Council in the decisions about Tite, yet giving them the ownership of it. Are we having fun yet? I do wonder if this whole discussion is yet another example of cultural differences across the Atlantic :-} -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From kevin.s.hawkins at ultraslavonic.info Tue Aug 10 17:30:28 2010 From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins) Date: Tue, 10 Aug 2010 17:30:28 -0400 Subject: [tei-council] Fwd: Tite: header In-Reply-To: <4C61C28D.9090204@oucs.ox.ac.uk> References: <4C61C28D.9090204@oucs.ox.ac.uk> Message-ID: <4C61C4F4.6000300@ultraslavonic.info> My opinion is that this should not be our concern. When a vendor receives an object to be encoded, it comes with an ID assigned by the customer or is assigned one as soon as it comes in the door. This is used as all or part of the filename. The stages in their workflow are maintained in their own systems, either by file locations, a CMS, or version control system. Who the customer is is likely in a database of orders, and who encoded on their end is something they surely already track for quality-assurance purposes. These workflow methods need to exist on their end outside of the TEI document -- and likewise outside of any metadata format -- because they need these same things for all the work they do. The TEI's approach to metadata is that it's safer if metadata is included in a file because it's less likely to ever be separated from it. However, I think this only matters in a long-term archiving. For any ongoing digitization or publishing operation, there are other, better tools for managing this information. Kevin On 8/10/2010 5:20 PM, Lou Burnard wrote: > Here's a note I sent to Perry, Laurent, and Dan back in March about what > I consider to be a really off the wall modification introduced into TEI > Tite. > > I never got any response, which is fine, we're all busy. But I would > like to know whether anyone else feels as I do, or whether I should just > keep this particular opinion to myself. > > -------- Original Message -------- > Subject: Tite: header > Date: Wed, 3 Mar 2010 15:03:40 +0000 > From: Lou<lou.burnard at oucs.ox.ac.uk> > To: Perry Trolard<ptrolard at artsci.wustl.edu>, Laurent Romary > <laurent.romary at loria.fr>, "daniel.odonnell at uleth.ca" > <daniel.odonnell at uleth.ca> > > Why no TEI Header in TEI Tite documents? > > The spec at > http://www.tei-c.org/release/doc/tei-p5-exemplars/html/tei_tite.doc.html#teistruct > > says > > "Tite omits the<teiHeader> element as a convenience to transcribers. > This departs from normal TEI practice, which requires<TEI> as the root > element, containing<teiHeader> and text elements. In order to bring a > document encoded in TEI Tite into adherence with the TEI abstract model, > projects should add a teiHeader before engaging in post-transcription > processing. " > > Why is it a "convenience to transcribers" to prevent them from adding > useful metadata to the text they have described? > > In its absence, how will they indicate > > a) which text this xml document is supposed to represent or be a part of? > b) when they did it? > c) what's the status (preliminary, finished, proofed etc.) of this xml > document? > d) who's responsible for shipping it, paying for it, handling questions > about it? > etc? > > Presumably they will still do those things somehow -- by file naming > conventions, associated paper work, mutual convention, or other means... > > Why not use the tool at hand for the job? > > No-one is saying that a "tite" TEI Header (or any other) need contain a > kosher bibliographic description -- for that job we apply the > rabbinical skills of the cataloguers when the xml document is > accessioned. But it can still contain all that is needed for conformance > to the TEI abstract model, namely > > * a title > * a source description > * a responsibility statement > > The title might be "text number 9456", the source description might be > "microfilm batch number 6181032" and the responsibility statement might > be "Joes Garage" but that would still be better than nothing at all, surely? > > I think the decision to junk the header in this context shows a > surprising lack of imagination about what it's meant for, and how it can > be used. > > I suggest we should try a bit harder to propose some minimal header > structure that would fit in with the work flow anticipated for Tite > documents. My belief is that Apex would welcome such an idea, though I > haven't yet asked them! > > Lou > > > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council From sebastian.rahtz at oucs.ox.ac.uk Tue Aug 10 17:34:47 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 10 Aug 2010 22:34:47 +0100 Subject: [tei-council] Fwd: Tite: header In-Reply-To: <4C61C4F4.6000300@ultraslavonic.info> References: <4C61C28D.9090204@oucs.ox.ac.uk> <4C61C4F4.6000300@ultraslavonic.info> Message-ID: <217FFAA9-FD3F-4D34-824E-2EE743AD25FF@oucs.ox.ac.uk> On 10 Aug 2010, at 22:30, Kevin Hawkins wrote: > My opinion is that this should not be our concern. > I tend to agree with Kevin. The TEI header is a very good way to carry around metadata in a portable and sustainable way, but Tite is not being used to create archival TEI docs, it is an interchange format between digitizing company and client. The client will (I hope ...) make the TEI canonical by removing the non-TEI syntactic sugar elements, add a header, etc, as part of their onwards workflow. -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From sebastian.rahtz at oucs.ox.ac.uk Tue Aug 10 17:39:35 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 10 Aug 2010 22:39:35 +0100 Subject: [tei-council] tite and namespaces, idle thoughts In-Reply-To: <20100810184123.GC34559@pjts-poly-2.local> References: <4C617A20.5040703@uleth.ca> <EB8BAE12-17C4-48CC-80BE-FD270A9662B8@oucs.ox.ac.uk> <8C297ECB-4AC7-43B2-B7AE-A91A96A2F942@inria.fr> <20100810184123.GC34559@pjts-poly-2.local> Message-ID: <F7547651-662C-4717-A98A-25A7053E32AD@oucs.ox.ac.uk> Since Perry's here, I'll raise two small points which struck me reading the doc that Apex produced. a) I see no reference at all to XML namespaces. What was the deal agreed with them? will the files they produced have namespace decls? or will they be always come with the DTD which adds them by sleight of hand b) (totally other direction), what is the convention about small caps? in my world <smcap>ANTONIO, SALARINO</smcap> will produce either all caps or all small caps, not the cap A and S and small caps NTONIO etc which I would expect. Elsewhere I see <smcap>Ernest S. Bishop</smcap>, which operates a different convention. -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From kevin.s.hawkins at ultraslavonic.info Tue Aug 10 18:09:46 2010 From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins) Date: Tue, 10 Aug 2010 18:09:46 -0400 Subject: [tei-council] tite and namespaces, idle thoughts In-Reply-To: <F7547651-662C-4717-A98A-25A7053E32AD@oucs.ox.ac.uk> References: <4C617A20.5040703@uleth.ca> <EB8BAE12-17C4-48CC-80BE-FD270A9662B8@oucs.ox.ac.uk> <8C297ECB-4AC7-43B2-B7AE-A91A96A2F942@inria.fr> <20100810184123.GC34559@pjts-poly-2.local> <F7547651-662C-4717-A98A-25A7053E32AD@oucs.ox.ac.uk> Message-ID: <4C61CE2A.8010705@ultraslavonic.info> Please keep in mind that Perry can't post to tei-council, so when we cc: him and he replies, only some of us are seeing those messages. --Kevin On 8/10/2010 5:39 PM, Sebastian Rahtz wrote: > Since Perry's here, I'll raise two small points which struck me reading the doc that Apex produced. > > a) I see no reference at all to XML namespaces. What was the deal agreed with them? will the files they produced have namespace decls? or will they be always come with the DTD which adds them by sleight of hand > > b) (totally other direction), what is the convention about small caps? in my world > > <smcap>ANTONIO, SALARINO</smcap> > > will produce either all caps or all small caps, not the cap A and S and small caps NTONIO etc > which I would expect. Elsewhere I see<smcap>Ernest S. Bishop</smcap>, which operates > a different convention. > -- > Sebastian Rahtz > Information Manager, Oxford University Computing Services > 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 > > S?lo le pido a Dios > que el futuro no me sea indiferente > > > > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council From lou.burnard at oucs.ox.ac.uk Tue Aug 10 18:13:33 2010 From: lou.burnard at oucs.ox.ac.uk (Lou Burnard) Date: Tue, 10 Aug 2010 23:13:33 +0100 Subject: [tei-council] One Licence Does it all In-Reply-To: <4C61BCDE.8000802@uleth.ca> References: <4C617A20.5040703@uleth.ca> <EB8BAE12-17C4-48CC-80BE-FD270A9662B8@oucs.ox.ac.uk> <8C297ECB-4AC7-43B2-B7AE-A91A96A2F942@inria.fr> <20100810184123.GC34559@pjts-poly-2.local> <D35F0E6B-C072-429C-8564-CFC567A63FB2@oucs.ox.ac.uk> <4C61BCDE.8000802@uleth.ca> Message-ID: <4C61CF0D.30907@oucs.ox.ac.uk> On 10/08/10 21:55, O'Donnell, Dan wrote: > When they needed to do things--for example, like adjust > documentation so that it didn't include examples and text that referred > to other things not in Tite--it made reasonable sense to handle this > in-house rather than wait for the TEI to establish a maintenance > mechanism for it. I think back in March I reminded Perry how to revise the Tite ODD so that it used Tite-specific examples. This was not a new mechanism -- it's one that's been present since the first releases of P5. So there was no need to wait for the TEI to establish anything: just use the tools that are already there. >. Also we should remember > that it is only know we seem able to do this: when the subject came up > in Nancy, we left it on the table because we didn't really know what to > do about making it "official." Like Sebastian, I remember that the Council did actually spend quite a lot of time and effort discussing how to make Tite "official" at its meeting in Berlin and subsequently. > They really don't deserve some of the acrimony they have been > shown, both here and when they were in Michigan. I don't remember any acrimony in Michigan. Maybe I was in the wrong bar. My suggestion about litigation was not particularly bad-tempered -- In just find it ironic that at the same time as we were agonising over whether or not the GPL was what we wanted to use, the GPL was being openly flouted by the text of every page of the Tite Spec. (and I have every confidence in Kevin's ability to resolve that particular issue) >>> (Dan, I recall that we were waiting on the results of a review of Apex's >>> schema from an outside party [David Seaman?], >>> Dan, can we have an update on this? Is someone reviewing "Apex's schema"? will the council see the result? when? From kevin.s.hawkins at ultraslavonic.info Tue Aug 10 18:13:33 2010 From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins) Date: Tue, 10 Aug 2010 18:13:33 -0400 Subject: [tei-council] One Licence Does it all In-Reply-To: <D35F0E6B-C072-429C-8564-CFC567A63FB2@oucs.ox.ac.uk> References: <4C617A20.5040703@uleth.ca> <EB8BAE12-17C4-48CC-80BE-FD270A9662B8@oucs.ox.ac.uk> <8C297ECB-4AC7-43B2-B7AE-A91A96A2F942@inria.fr> <20100810184123.GC34559@pjts-poly-2.local> <D35F0E6B-C072-429C-8564-CFC567A63FB2@oucs.ox.ac.uk> Message-ID: <4C61CF0D.9060907@ultraslavonic.info> Sebastian is replying to a message from Perry Trolard which I haven't seen in its entirety. Nevertheless, let me attempt to clarify ... On 8/10/2010 3:18 PM, Sebastian Rahtz wrote: > > On 10 Aug 2010, at 19:41, Perry Trolard wrote: >> >> If this is the recommended course, perhaps Dan& I should compare notes >> about pending changes to Tite coming out of Apex, then I can file >> tickets for each. > > which seems weird. Apex can't change TEI Tite, only we can do that. They should > be submitting bugs or feature requests, which we implement By "pending changes out of Apex", I don't think Perry meant to imply that these changes will definitely make it into our canonical version. Rather, he has a list of changes that Apex made in their fork ("version 1.1"), and he and Dan will review them and create SF tickets for any that seem like they should make it back into our canonical version. This seems fine to me. --Kevin From sebastian.rahtz at oucs.ox.ac.uk Tue Aug 10 18:15:30 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 10 Aug 2010 23:15:30 +0100 Subject: [tei-council] tite and namespaces, idle thoughts In-Reply-To: <4C61CE2A.8010705@ultraslavonic.info> References: <4C617A20.5040703@uleth.ca> <EB8BAE12-17C4-48CC-80BE-FD270A9662B8@oucs.ox.ac.uk> <8C297ECB-4AC7-43B2-B7AE-A91A96A2F942@inria.fr> <20100810184123.GC34559@pjts-poly-2.local> <F7547651-662C-4717-A98A-25A7053E32AD@oucs.ox.ac.uk> <4C61CE2A.8010705@ultraslavonic.info> Message-ID: <E8EDAD0B-D28E-453A-AAEE-8E32AA33D51A@oucs.ox.ac.uk> On 10 Aug 2010, at 23:09, Kevin Hawkins wrote: > Please keep in mind that Perry can't post to tei-council, so when we cc: > him and he replies, only some of us are seeing those messages. --Kevin Yes, sorry, Perry. it is confusing. Whatever else, we agree that Tite technical bug reports and requests should be in Sourceforge, so I should repost my queries there. -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From sebastian.rahtz at oucs.ox.ac.uk Tue Aug 10 18:19:43 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 10 Aug 2010 23:19:43 +0100 Subject: [tei-council] One Licence Does it all In-Reply-To: <4C61CF0D.9060907@ultraslavonic.info> References: <4C617A20.5040703@uleth.ca> <EB8BAE12-17C4-48CC-80BE-FD270A9662B8@oucs.ox.ac.uk> <8C297ECB-4AC7-43B2-B7AE-A91A96A2F942@inria.fr> <20100810184123.GC34559@pjts-poly-2.local> <D35F0E6B-C072-429C-8564-CFC567A63FB2@oucs.ox.ac.uk> <4C61CF0D.9060907@ultraslavonic.info> Message-ID: <E2BEBE79-91A4-4523-A39F-E587C388D3AB@oucs.ox.ac.uk> > By "pending changes out of Apex", I don't think Perry meant to imply > that these changes will definitely make it into our canonical version. > Rather, he has a list of changes that Apex made in their fork ("version > 1.1"), and he and Dan will review them and create SF tickets for any > that seem like they should make it back into our canonical version. > This seems fine to me. It is fine by me if Apex or anyone else wants to fork Tite and make their own variant customization, It is entirely NOT fine by me if they call the result "Tite"! Would Gabby thank me if I released a schema calling itself "Epidoc, version 1.1", with small changes in it from his Epidoc? -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From sebastian.rahtz at oucs.ox.ac.uk Tue Aug 10 18:20:27 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 10 Aug 2010 23:20:27 +0100 Subject: [tei-council] Fwd: One Licence Does it all References: <20100810184123.GC34559@pjts-poly-2.local> Message-ID: <C51F43B5-87A2-402F-9C8E-1760C09752A0@oucs.ox.ac.uk> this was Perry's message, for the record. Begin forwarded message: > From: Perry Trolard <ptrolard at artsci.wustl.edu> > Date: 10 August 2010 19:41:23 GMT+01:00 > To: Laurent Romary <laurent.romary at inria.fr> > Cc: Sebastian Rahtz <sebastian.rahtz at oucs.ox.ac.uk>, "daniel.odonnell at uleth.ca" <daniel.odonnell at uleth.ca>, TEI Council <tei-council at lists.village.Virginia.EDU> > Subject: Re: [tei-council] One Licence Does it all > > Greetings, > > On Tue, Aug 10, 2010 at 08:21:34PM +0200, Laurent Romary wrote: >> Le 10 ao?t 10 ? 18:56, Sebastian Rahtz a ?crit : >>> if we agree that the thing is simply another component of the >>> guidelines, >>> then we simply follow Kevin's lead, and have bugs/requests entered >>> in Sourceforge, and acted upon by editorial team under council >>> instruction >> >> Exactly. Looks like a no-brainer activity (from an organisational >> point of view, I mean - let us expect Kevin has a few difficult >> cases for us). >> To answer Lou's question on another thread: things you've not seen >> implemented from your spring comments could be filed in as SF >> tickets, I think. > > If this is the recommended course, perhaps Dan & I should compare notes > about pending changes to Tite coming out of Apex, then I can file > tickets for each. > > (Dan, I recall that we were waiting on the results of a review of Apex's > schema from an outside party [David Seaman?], but this was before the > staff reorganization chez Apex; I imagine that if you asked for their > current stuff this week we could run with that. In any case, we can talk > more offline...) > > Perry -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From kevin.s.hawkins at ultraslavonic.info Tue Aug 10 18:38:51 2010 From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins) Date: Tue, 10 Aug 2010 18:38:51 -0400 Subject: [tei-council] communication about Tite (was Re: One Licence Does it all) In-Reply-To: <4C61BCDE.8000802@uleth.ca> References: <4C617A20.5040703@uleth.ca> <EB8BAE12-17C4-48CC-80BE-FD270A9662B8@oucs.ox.ac.uk> <8C297ECB-4AC7-43B2-B7AE-A91A96A2F942@inria.fr> <20100810184123.GC34559@pjts-poly-2.local> <D35F0E6B-C072-429C-8564-CFC567A63FB2@oucs.ox.ac.uk> <4C61BCDE.8000802@uleth.ca> Message-ID: <4C61D4FB.3040704@ultraslavonic.info> Thank you, Dan, for giving some background on Tite. The main issue is that Council doesn't know what's going on with Tite. I have been harping about this for years, in emails to Council, to Dan and sometimes also to Perry, and occasionally in public at our annual business meetings. Tite has been mentioned offhand on TEI-L for years with very little information about what it is, where it came from, and where it's going. (I pulled together what information I could gather on my own in an email to TEI-L in December 2008, when the SIG on Libraries solicited feedback on the schema.) In Council in 2010, we have at various times expected to discuss Tite, but word hasn't always made it around to the whole Council that plans have changed in some way or another from what we last heard. This could be because people are cc'd on a message from a non-Council member addressed to tei-council or simply because we all get a lot of email and forget who has seen what. This aside, I generally agree with Dan's sentiment that the TEI-C's relationship with Apex is a new thing that in part needs to be figured out as we go along. Like Sebastian, I do wish Apex hadn't used the version label "1.1" on what they're using since it implies there is no fork. But this is not irreversible. I doubt anyone is using Apex's document for any subsequent work, so they can rename the PDF (and remove the "confidential and proprietary" notice) on their website. Kevin From daniel.odonnell at uleth.ca Tue Aug 10 23:01:03 2010 From: daniel.odonnell at uleth.ca (O'Donnell, Dan) Date: Tue, 10 Aug 2010 21:01:03 -0600 Subject: [tei-council] One Licence Does it all In-Reply-To: <E2BEBE79-91A4-4523-A39F-E587C388D3AB@oucs.ox.ac.uk> References: <4C617A20.5040703@uleth.ca> <EB8BAE12-17C4-48CC-80BE-FD270A9662B8@oucs.ox.ac.uk> <8C297ECB-4AC7-43B2-B7AE-A91A96A2F942@inria.fr> <20100810184123.GC34559@pjts-poly-2.local> <D35F0E6B-C072-429C-8564-CFC567A63FB2@oucs.ox.ac.uk> <4C61CF0D.9060907@ultraslavonic.info> <E2BEBE79-91A4-4523-A39F-E587C388D3AB@oucs.ox.ac.uk> Message-ID: <4C62126F.7020006@uleth.ca> Once again, I think we are pushing on an open door. For me, "Hooray! let's get this canonical and clear up all the problems" seems to be about as clear an agreement to cooperate as we can get. I'd focus on that. -dan On 10-08-10 04:19 PM, Sebastian Rahtz wrote: >> By "pending changes out of Apex", I don't think Perry meant to imply >> that these changes will definitely make it into our canonical version. >> Rather, he has a list of changes that Apex made in their fork ("version >> 1.1"), and he and Dan will review them and create SF tickets for any >> that seem like they should make it back into our canonical version. >> This seems fine to me. >> > > > It is fine by me if Apex or anyone else wants to fork Tite and make their > own variant customization, It is entirely NOT fine by me if they call the result > "Tite"! > > Would Gabby thank me if I released a schema calling itself "Epidoc, version 1.1", > with small changes in it from his Epidoc? > -- > Sebastian Rahtz > Information Manager, Oxford University Computing Services > 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 > > S?lo le pido a Dios > que el futuro no me sea indiferente > > > > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > -- Daniel Paul O'Donnell Professor of English University of Lethbridge Chair and CEO, Text Encoding Initiative (http://www.tei-c.org/) Co-Chair, Digital Initiatives Advisory Board, Medieval Academy of America President-elect (English), Society for Digital Humanities/Soci?t? pour l'?tude des m?dias interactifs (http://sdh-semi.org/) Founding Director (2003-2009), Digital Medievalist Project (http://www.digitalmedievalist.org/) Vox: +1 403 329-2377 Fax: +1 403 382-7191 (non-confidential) Home Page: http://people.uleth.ca/~daniel.odonnell/ From daniel.odonnell at uleth.ca Wed Aug 11 16:51:02 2010 From: daniel.odonnell at uleth.ca (O'Donnell, Dan) Date: Wed, 11 Aug 2010 14:51:02 -0600 Subject: [tei-council] Fwd: suggestions for TEI Tite documentation on AccesTEI portal In-Reply-To: <95D1F082-497B-446F-A0B6-2FF1B31B62BE@inria.fr> References: <4C61987C.4010901@ultraslavonic.info> <95D1F082-497B-446F-A0B6-2FF1B31B62BE@inria.fr> Message-ID: <4C630D36.4010906@uleth.ca> I just spoke to them about this. As I suggested, this is just a standard header that slipped in rather than an attempt to claim IP (or assert that a web-circulated document is actually private. Peggy Glahn, who runs the programme with us, will get somebody to drop the top header and add the TEI logo to the bottom. I also told Peggy that the numbering would have to be aligned with the TEI's official numbering once we've got that set up and that we are adding Tite to the ticketing system at Source Forge. Also, as one might suspect, nothing they have problems with or are anything less than enthusiastic about. -dan On 10-08-10 12:28 PM, Laurent Romary wrote: > Very good, Kevin. Again, we need to secure this on the basis of our > contractual link with them. But the lead should be on us. > > Le 10 ao?t 10 ? 20:20, Kevin Hawkins a ?crit : > > >> Regarding "proprietary and confidential", I sent this to Apex a few >> days >> ago but haven't heard back since then. >> >> -------- Original Message -------- >> Subject: suggestions for TEI Tite documentation on AccesTEI portal >> Date: Sun, 08 Aug 2010 14:32:42 -0400 >> From: Kevin Hawkins<kevin.s.hawkins at ultraslavonic.info> >> To: Ed Moore<emoore at apexcovantage.com> >> >> Hi Ed, >> >> Regarding >> http://accesstei.apexcovantage.com/Content/documents/TEI-Tite_guidelines__1.1.pdf >> >> : >> >> 1. The title page says "Apex TEI-TITE Guidelines For TEI Access >> Project". I think you'll want to change that to something like >> "Guidelines for Encoding Documents for AccessTEI". >> >> 2. The running headers say the document is proprietary and >> confidential, >> but I think you'll want to remove the confidential statement since >> it's >> publicly available. It would be good to clarify the copyright on the >> document. I've asked the TEI Council to clarify the copyright on TEI >> Tite itself. It seems the TEI Consortium will release it under GNU >> GPL >> 2, meaning derivations such as this one would also need to be released >> under that. >> >> 2. You refer to the schema you're using as "TEI TITE" and "TITE", but >> the version on which yours is based is called "Tite". It would be >> good >> if your introduction clarified that the version of Tite you're using >> is >> derived from the version created and maintained by the TEI Consortium. >> >> Please let know if you have any questions, >> >> Kevin >> _______________________________________________ >> tei-council mailing list >> tei-council at lists.village.Virginia.EDU >> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council >> > Laurent Romary > INRIA& HUB-IDSL > laurent.romary at inria.fr > > > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > -- Daniel Paul O'Donnell Professor of English University of Lethbridge Chair and CEO, Text Encoding Initiative (http://www.tei-c.org/) Co-Chair, Digital Initiatives Advisory Board, Medieval Academy of America President-elect (English), Society for Digital Humanities/Soci?t? pour l'?tude des m?dias interactifs (http://sdh-semi.org/) Founding Director (2003-2009), Digital Medievalist Project (http://www.digitalmedievalist.org/) Vox: +1 403 329-2377 Fax: +1 403 382-7191 (non-confidential) Home Page: http://people.uleth.ca/~daniel.odonnell/ From lou.burnard at oucs.ox.ac.uk Wed Aug 11 16:58:37 2010 From: lou.burnard at oucs.ox.ac.uk (Lou Burnard) Date: Wed, 11 Aug 2010 21:58:37 +0100 Subject: [tei-council] Fwd: suggestions for TEI Tite documentation on AccesTEI portal In-Reply-To: <4C630D36.4010906@uleth.ca> References: <4C61987C.4010901@ultraslavonic.info> <95D1F082-497B-446F-A0B6-2FF1B31B62BE@inria.fr> <4C630D36.4010906@uleth.ca> Message-ID: <4C630EFD.2030803@oucs.ox.ac.uk> On 11/08/10 21:51, O'Donnell, Dan wrote: > > I also told Peggy that the numbering would have to be aligned with the > TEI's official numbering once we've got that set up If by our "official numbering" you mean the numbering of P5 releases, this has been set up since c. 2005. If you don't, please could you clarify what you do mean? The schemas generated from an ODD by the stylesheets now always specify the version number of the Guidelines they used as well as the date and time. That's a comparatively recent development, so maybe that's what you had in mind? From daniel.odonnell at uleth.ca Wed Aug 11 18:12:57 2010 From: daniel.odonnell at uleth.ca (O'Donnell, Dan) Date: Wed, 11 Aug 2010 16:12:57 -0600 Subject: [tei-council] Fwd: suggestions for TEI Tite documentation on AccesTEI portal In-Reply-To: <4C630EFD.2030803@oucs.ox.ac.uk> References: <4C61987C.4010901@ultraslavonic.info> <95D1F082-497B-446F-A0B6-2FF1B31B62BE@inria.fr> <4C630D36.4010906@uleth.ca> <4C630EFD.2030803@oucs.ox.ac.uk> Message-ID: <4C632069.4010505@uleth.ca> No Lou, I'm not talking about P5. You might recall this was about Tite and the version number Apex have put on their PDF. There was a hubbabaloo about the fact that they called this 1.1. In fact I think you wanted to sue. They've agreed to call it whatever we want. I imagine their lawyers warned them about taking us on. -dan On 10-08-11 02:58 PM, Lou Burnard wrote: > On 11/08/10 21:51, O'Donnell, Dan wrote: > > >> I also told Peggy that the numbering would have to be aligned with the >> TEI's official numbering once we've got that set up >> > If by our "official numbering" you mean the numbering of P5 releases, > this has been set up since c. 2005. If you don't, please could you > clarify what you do mean? > > The schemas generated from an ODD by the stylesheets now always specify > the version number of the Guidelines they used as well as the date and > time. That's a comparatively recent development, so maybe that's what > you had in mind? > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > -- Daniel Paul O'Donnell Professor of English University of Lethbridge Chair and CEO, Text Encoding Initiative (http://www.tei-c.org/) Co-Chair, Digital Initiatives Advisory Board, Medieval Academy of America President-elect (English), Society for Digital Humanities/Soci?t? pour l'?tude des m?dias interactifs (http://sdh-semi.org/) Founding Director (2003-2009), Digital Medievalist Project (http://www.digitalmedievalist.org/) Vox: +1 403 329-2377 Fax: +1 403 382-7191 (non-confidential) Home Page: http://people.uleth.ca/~daniel.odonnell/ From lou.burnard at oucs.ox.ac.uk Wed Aug 11 19:08:58 2010 From: lou.burnard at oucs.ox.ac.uk (Lou Burnard) Date: Thu, 12 Aug 2010 00:08:58 +0100 Subject: [tei-council] Fwd: suggestions for TEI Tite documentation on AccesTEI portal In-Reply-To: <4C632069.4010505@uleth.ca> References: <4C61987C.4010901@ultraslavonic.info> <95D1F082-497B-446F-A0B6-2FF1B31B62BE@inria.fr> <4C630D36.4010906@uleth.ca> <4C630EFD.2030803@oucs.ox.ac.uk> <4C632069.4010505@uleth.ca> Message-ID: <4C632D8A.8020801@oucs.ox.ac.uk> I knew it was about Tite, but I don't recall any "hubbabaloo" about the version number on their PDF: I expressed some concern about the licensing phrase, as I thought I already made clear, and those concerns have apparently been addressed, so I'm a happy baloo. On 11/08/10 23:12, O'Donnell, Dan wrote: > No Lou, I'm not talking about P5. You might recall this was about Tite > and the version number Apex have put on their PDF. There was a > hubbabaloo about the fact that they called this 1.1. In fact I think you > wanted to sue. > > They've agreed to call it whatever we want. I imagine their lawyers > warned them about taking us on. > > -dan > > On 10-08-11 02:58 PM, Lou Burnard wrote: >> On 11/08/10 21:51, O'Donnell, Dan wrote: >> >> >>> I also told Peggy that the numbering would have to be aligned with the >>> TEI's official numbering once we've got that set up >>> >> If by our "official numbering" you mean the numbering of P5 releases, >> this has been set up since c. 2005. If you don't, please could you >> clarify what you do mean? >> >> The schemas generated from an ODD by the stylesheets now always specify >> the version number of the Guidelines they used as well as the date and >> time. That's a comparatively recent development, so maybe that's what >> you had in mind? >> >> _______________________________________________ >> tei-council mailing list >> tei-council at lists.village.Virginia.EDU >> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council >> > From daniel.odonnell at uleth.ca Wed Aug 11 19:13:35 2010 From: daniel.odonnell at uleth.ca (O'Donnell, Dan) Date: Wed, 11 Aug 2010 17:13:35 -0600 Subject: [tei-council] Fwd: suggestions for TEI Tite documentation on AccesTEI portal In-Reply-To: <4C632D8A.8020801@oucs.ox.ac.uk> References: <4C61987C.4010901@ultraslavonic.info> <95D1F082-497B-446F-A0B6-2FF1B31B62BE@inria.fr> <4C630D36.4010906@uleth.ca> <4C630EFD.2030803@oucs.ox.ac.uk> <4C632069.4010505@uleth.ca> <4C632D8A.8020801@oucs.ox.ac.uk> Message-ID: <4C632E9F.5070600@uleth.ca> Then we are happy bali, which I'm guessing is the plural if, as I suspect, baloo comes from *balus (Gr. Balos). If it was fourth declension (perhaps Gabby can help) I suppose it might be "happy balus" in the plural. Unless we got it from French, of course, in which case all bets are off. -dan On 10-08-11 05:08 PM, Lou Burnard wrote: > I knew it was about Tite, but I don't recall any "hubbabaloo" about the > version number on their PDF: I expressed some concern about the > licensing phrase, as I thought I already made clear, and those concerns > have apparently been addressed, so I'm a happy baloo. > > > On 11/08/10 23:12, O'Donnell, Dan wrote: > >> No Lou, I'm not talking about P5. You might recall this was about Tite >> and the version number Apex have put on their PDF. There was a >> hubbabaloo about the fact that they called this 1.1. In fact I think you >> wanted to sue. >> >> They've agreed to call it whatever we want. I imagine their lawyers >> warned them about taking us on. >> >> -dan >> >> On 10-08-11 02:58 PM, Lou Burnard wrote: >> >>> On 11/08/10 21:51, O'Donnell, Dan wrote: >>> >>> >>> >>>> I also told Peggy that the numbering would have to be aligned with the >>>> TEI's official numbering once we've got that set up >>>> >>>> >>> If by our "official numbering" you mean the numbering of P5 releases, >>> this has been set up since c. 2005. If you don't, please could you >>> clarify what you do mean? >>> >>> The schemas generated from an ODD by the stylesheets now always specify >>> the version number of the Guidelines they used as well as the date and >>> time. That's a comparatively recent development, so maybe that's what >>> you had in mind? >>> >>> _______________________________________________ >>> tei-council mailing list >>> tei-council at lists.village.Virginia.EDU >>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council >>> >>> >> > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > -- Daniel Paul O'Donnell Professor of English University of Lethbridge Chair and CEO, Text Encoding Initiative (http://www.tei-c.org/) Co-Chair, Digital Initiatives Advisory Board, Medieval Academy of America President-elect (English), Society for Digital Humanities/Soci?t? pour l'?tude des m?dias interactifs (http://sdh-semi.org/) Founding Director (2003-2009), Digital Medievalist Project (http://www.digitalmedievalist.org/) Vox: +1 403 329-2377 Fax: +1 403 382-7191 (non-confidential) Home Page: http://people.uleth.ca/~daniel.odonnell/ From laurent.romary at inria.fr Thu Aug 12 10:57:34 2010 From: laurent.romary at inria.fr (Laurent Romary) Date: Thu, 12 Aug 2010 16:57:34 +0200 Subject: [tei-council] Fwd: Re: TEI Web site In-Reply-To: <4C601845.5020703@ultraslavonic.info> References: <4C601845.5020703@ultraslavonic.info> Message-ID: <40D633DF-9185-44D2-9726-9B28000B21DD@inria.fr> I do support this. Shall I ask David to procede further on this? Le 9 ao?t 10 ? 17:01, Kevin Hawkins a ?crit : > I think David Sewell's recent note to TEI-L about how the TEI website > works is an excellent start to a colophon for the TEI website. How do > others feel about having such a page? > > -------- Original Message -------- > Subject: Re: TEI Web site > Date: Mon, 9 Aug 2010 10:03:04 -0400 (EDT) > From: David Sewell <dsewell at virginia.edu> > To: Kevin Hawkins <kevin.s.hawkins at ultraslavonic.info> > > Kevin, > > I certainly wasn't composing it to be an official document--but I'd > suggest you run the idea of an "About this website" page by Council. > If > created, it should probably have more content than just a technical > note > on underlying data. > > David > > On Sun, 8 Aug 2010, Kevin Hawkins wrote: > >> David, I think your message would make a fine colophon for the TEI >> website. >> Perhaps, in the navbar, there could be something like >> >> About --> This website >> >> which would bring up a short page containing more or less what you >> wrote >> below. >> >>> The content on www.tei-c.org is a composite of quite a few >>> underlying >>> sources. To wit: >>> >>> * Most of the content pages, such as those under Activities, >>> Membership, >>> and About, live as mostly XML data in OpenCMS, a content management >>> system; our configuration converts TEI-XML to HTML on the fly >>> >>> * The news sidebar on the main page and /News/ are pulled in >>> quasi-dynamically from content that lives in the TEI WordPress >>> blog on >>> Sourceforge (http://sourceforge.net/apps/wordpress/tei/) >>> >>> * Some areas of the site are simply filesystem mirrors of the >>> current >>> TEI Sourceforge packages, e.g. the P4 and P5 Guidelines >>> documentation >>> under /release, and Roma under /Roma >>> >>> * Others are static filesystem directories with special material, >>> such >>> as the "TEI Vault" (http://www.tei-c.org/Vault/) >>> >>> * Yet others are pointers to TEI-related material hosted >>> externally (the >>> TEI webstore at http://www.tei-shop.org/, the new TEI Journal aka >>> J-TEI >>> site at http://journal.tei-c.org/) >>> >>> All integrated via an Apache configuration file resembling the >>> wiring >>> diagram of a nuclear submarine, and ably maintained by our sysadmin >>> Shayne Brandon. >> > > -- > David Sewell, Editorial and Technical Manager > ROTUNDA, The University of Virginia Press > PO Box 400314, Charlottesville, VA 22904-4314 USA > Email: dsewell at virginia.edu Tel: +1 434 924 9973 > Web: http://rotunda.upress.virginia.edu/ > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Laurent Romary INRIA & HUB-IDSL laurent.romary at inria.fr From sebastian.rahtz at oucs.ox.ac.uk Thu Aug 12 16:16:45 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Thu, 12 Aug 2010 21:16:45 +0100 Subject: [tei-council] tite and namespaces, idle thoughts In-Reply-To: <20100811172056.GH34559@pjts-poly-2.local> References: <4C617A20.5040703@uleth.ca> <EB8BAE12-17C4-48CC-80BE-FD270A9662B8@oucs.ox.ac.uk> <8C297ECB-4AC7-43B2-B7AE-A91A96A2F942@inria.fr> <20100810184123.GC34559@pjts-poly-2.local> <F7547651-662C-4717-A98A-25A7053E32AD@oucs.ox.ac.uk> <20100811172056.GH34559@pjts-poly-2.local> Message-ID: <251CDEB3-D188-407A-9A0C-DCA961EA3F54@oucs.ox.ac.uk> Sorry for the delay in replying (I am on holiday): >> b) (totally other direction), what is the convention about small caps? in my world >> >> <smcap>ANTONIO, SALARINO</smcap> >> >> will produce either all caps or all small caps, not the cap A and S and small caps NTONIO etc >> which I would expect. Elsewhere I see <smcap>Ernest S. Bishop</smcap>, which operates >> a different convention. > > I'm in your world on this. What document are you looking at? I am looking at the examples (scenarios) at the end of Apex' Tite documentation -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From sebastian.rahtz at oucs.ox.ac.uk Thu Aug 12 16:23:36 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Thu, 12 Aug 2010 21:23:36 +0100 Subject: [tei-council] Fwd: suggestions for TEI Tite documentation on AccesTEI portal In-Reply-To: <4C632069.4010505@uleth.ca> References: <4C61987C.4010901@ultraslavonic.info> <95D1F082-497B-446F-A0B6-2FF1B31B62BE@inria.fr> <4C630D36.4010906@uleth.ca> <4C630EFD.2030803@oucs.ox.ac.uk> <4C632069.4010505@uleth.ca> Message-ID: <20979472-E71D-4312-BD8C-D4DB9CE130ED@oucs.ox.ac.uk> I am puzzled, as ever, by the implication that something has to be done to manage Tite and its release numbers. The Tite we have released says its "Version 1.0 ? May 2009", no problem. It is good to see irony is alive and well in Canada, by the way. Unexpected. -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From sebastian.rahtz at oucs.ox.ac.uk Thu Aug 12 16:25:13 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Thu, 12 Aug 2010 21:25:13 +0100 Subject: [tei-council] Fwd: suggestions for TEI Tite documentation on AccesTEI portal In-Reply-To: <4C632E9F.5070600@uleth.ca> References: <4C61987C.4010901@ultraslavonic.info> <95D1F082-497B-446F-A0B6-2FF1B31B62BE@inria.fr> <4C630D36.4010906@uleth.ca> <4C630EFD.2030803@oucs.ox.ac.uk> <4C632069.4010505@uleth.ca> <4C632D8A.8020801@oucs.ox.ac.uk> <4C632E9F.5070600@uleth.ca> Message-ID: <4FD35A0C-84CA-47FA-98C7-B038BF53E3B9@oucs.ox.ac.uk> On 12 Aug 2010, at 00:13, O'Donnell, Dan wrote: > Then we are happy bali, which I'm guessing is the plural if, as I > suspect, baloo comes from *balus (Gr. Balos). It is the Hindi word "Bhalu", one believes -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From sebastian.rahtz at oucs.ox.ac.uk Thu Aug 12 17:11:59 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Thu, 12 Aug 2010 22:11:59 +0100 Subject: [tei-council] licensing of Exemplar ODD files Message-ID: <8A87CAFE-74B7-45F7-9E4B-6F5A953DC6B9@oucs.ox.ac.uk> For the record, I have checked all the Exemplar .odd files and made sure they either have GPL2 on them, or the "do what you like, this is so trivial we don't care" text. The former group consists of Lite, Tite and ENRICH. This is not trying to stop debate on what the right license for them is, just making sure they are consistent. To amuse myself, I also checked the license on all the things under Stylesheets, and more or less got them in sync. They are LGPL if in doubt. -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From daniel.odonnell at uleth.ca Thu Aug 12 17:54:08 2010 From: daniel.odonnell at uleth.ca (O'Donnell, Dan) Date: Thu, 12 Aug 2010 15:54:08 -0600 Subject: [tei-council] licensing of Exemplar ODD files In-Reply-To: <8A87CAFE-74B7-45F7-9E4B-6F5A953DC6B9@oucs.ox.ac.uk> References: <8A87CAFE-74B7-45F7-9E4B-6F5A953DC6B9@oucs.ox.ac.uk> Message-ID: <4C646D80.7060002@uleth.ca> Well done Sebastian. I'm amazed that hadn't really come up before. On 10-08-12 03:11 PM, Sebastian Rahtz wrote: > For the record, I have checked all the Exemplar .odd files and made sure they either have GPL2 on them, > or the "do what you like, this is so trivial we don't care" text. The former group consists of Lite, > Tite and ENRICH. > > This is not trying to stop debate on what the right license for them is, just making sure > they are consistent. > > To amuse myself, I also checked the license on all the things under Stylesheets, > and more or less got them in sync. They are LGPL if in doubt. > -- > Sebastian Rahtz > Information Manager, Oxford University Computing Services > 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 > > S?lo le pido a Dios > que el futuro no me sea indiferente > > > > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > -- Daniel Paul O'Donnell Professor of English University of Lethbridge Chair and CEO, Text Encoding Initiative (http://www.tei-c.org/) Co-Chair, Digital Initiatives Advisory Board, Medieval Academy of America President-elect (English), Society for Digital Humanities/Soci?t? pour l'?tude des m?dias interactifs (http://sdh-semi.org/) Founding Director (2003-2009), Digital Medievalist Project (http://www.digitalmedievalist.org/) Vox: +1 403 329-2377 Fax: +1 403 382-7191 (non-confidential) Home Page: http://people.uleth.ca/~daniel.odonnell/ From daniel.odonnell at uleth.ca Thu Aug 12 17:55:33 2010 From: daniel.odonnell at uleth.ca (O'Donnell, Dan) Date: Thu, 12 Aug 2010 15:55:33 -0600 Subject: [tei-council] Fwd: suggestions for TEI Tite documentation on AccesTEI portal In-Reply-To: <20979472-E71D-4312-BD8C-D4DB9CE130ED@oucs.ox.ac.uk> References: <4C61987C.4010901@ultraslavonic.info> <95D1F082-497B-446F-A0B6-2FF1B31B62BE@inria.fr> <4C630D36.4010906@uleth.ca> <4C630EFD.2030803@oucs.ox.ac.uk> <4C632069.4010505@uleth.ca> <20979472-E71D-4312-BD8C-D4DB9CE130ED@oucs.ox.ac.uk> Message-ID: <4C646DD5.8080007@uleth.ca> I think the issue is that our Tite and theirs still need reconciliation. Its part of the bumpiness as we get this wrangled. -dan On 10-08-12 02:23 PM, Sebastian Rahtz wrote: > I am puzzled, as ever, by the implication that something has to be done to manage Tite > and its release numbers. The Tite we have released says its "Version 1.0 ? May 2009", > no problem. > > It is good to see irony is alive and well in Canada, by the way. Unexpected. > > -- > Sebastian Rahtz > Information Manager, Oxford University Computing Services > 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 > > S?lo le pido a Dios > que el futuro no me sea indiferente > > > > > -- Daniel Paul O'Donnell Professor of English University of Lethbridge Chair and CEO, Text Encoding Initiative (http://www.tei-c.org/) Co-Chair, Digital Initiatives Advisory Board, Medieval Academy of America President-elect (English), Society for Digital Humanities/Soci?t? pour l'?tude des m?dias interactifs (http://sdh-semi.org/) Founding Director (2003-2009), Digital Medievalist Project (http://www.digitalmedievalist.org/) Vox: +1 403 329-2377 Fax: +1 403 382-7191 (non-confidential) Home Page: http://people.uleth.ca/~daniel.odonnell/ From daniel.odonnell at uleth.ca Thu Aug 12 18:54:08 2010 From: daniel.odonnell at uleth.ca (O'Donnell, Dan) Date: Thu, 12 Aug 2010 16:54:08 -0600 Subject: [tei-council] Fwd: Re: TEI Web site In-Reply-To: <40D633DF-9185-44D2-9726-9B28000B21DD@inria.fr> References: <4C601845.5020703@ultraslavonic.info> <40D633DF-9185-44D2-9726-9B28000B21DD@inria.fr> Message-ID: <4C647B90.8010400@uleth.ca> I think it would be a great idea. On 10-08-12 08:57 AM, Laurent Romary wrote: > I do support this. Shall I ask David to procede further on this? > > Le 9 ao?t 10 ? 17:01, Kevin Hawkins a ?crit : > > >> I think David Sewell's recent note to TEI-L about how the TEI website >> works is an excellent start to a colophon for the TEI website. How do >> others feel about having such a page? >> >> -------- Original Message -------- >> Subject: Re: TEI Web site >> Date: Mon, 9 Aug 2010 10:03:04 -0400 (EDT) >> From: David Sewell<dsewell at virginia.edu> >> To: Kevin Hawkins<kevin.s.hawkins at ultraslavonic.info> >> >> Kevin, >> >> I certainly wasn't composing it to be an official document--but I'd >> suggest you run the idea of an "About this website" page by Council. >> If >> created, it should probably have more content than just a technical >> note >> on underlying data. >> >> David >> >> On Sun, 8 Aug 2010, Kevin Hawkins wrote: >> >> >>> David, I think your message would make a fine colophon for the TEI >>> website. >>> Perhaps, in the navbar, there could be something like >>> >>> About --> This website >>> >>> which would bring up a short page containing more or less what you >>> wrote >>> below. >>> >>> >>>> The content on www.tei-c.org is a composite of quite a few >>>> underlying >>>> sources. To wit: >>>> >>>> * Most of the content pages, such as those under Activities, >>>> Membership, >>>> and About, live as mostly XML data in OpenCMS, a content management >>>> system; our configuration converts TEI-XML to HTML on the fly >>>> >>>> * The news sidebar on the main page and /News/ are pulled in >>>> quasi-dynamically from content that lives in the TEI WordPress >>>> blog on >>>> Sourceforge (http://sourceforge.net/apps/wordpress/tei/) >>>> >>>> * Some areas of the site are simply filesystem mirrors of the >>>> current >>>> TEI Sourceforge packages, e.g. the P4 and P5 Guidelines >>>> documentation >>>> under /release, and Roma under /Roma >>>> >>>> * Others are static filesystem directories with special material, >>>> such >>>> as the "TEI Vault" (http://www.tei-c.org/Vault/) >>>> >>>> * Yet others are pointers to TEI-related material hosted >>>> externally (the >>>> TEI webstore at http://www.tei-shop.org/, the new TEI Journal aka >>>> J-TEI >>>> site at http://journal.tei-c.org/) >>>> >>>> All integrated via an Apache configuration file resembling the >>>> wiring >>>> diagram of a nuclear submarine, and ably maintained by our sysadmin >>>> Shayne Brandon. >>>> >>> >> -- >> David Sewell, Editorial and Technical Manager >> ROTUNDA, The University of Virginia Press >> PO Box 400314, Charlottesville, VA 22904-4314 USA >> Email: dsewell at virginia.edu Tel: +1 434 924 9973 >> Web: http://rotunda.upress.virginia.edu/ >> _______________________________________________ >> tei-council mailing list >> tei-council at lists.village.Virginia.EDU >> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council >> > Laurent Romary > INRIA& HUB-IDSL > laurent.romary at inria.fr > > > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > -- Daniel Paul O'Donnell Professor of English University of Lethbridge Chair and CEO, Text Encoding Initiative (http://www.tei-c.org/) Co-Chair, Digital Initiatives Advisory Board, Medieval Academy of America President-elect (English), Society for Digital Humanities/Soci?t? pour l'?tude des m?dias interactifs (http://sdh-semi.org/) Founding Director (2003-2009), Digital Medievalist Project (http://www.digitalmedievalist.org/) Vox: +1 403 329-2377 Fax: +1 403 382-7191 (non-confidential) Home Page: http://people.uleth.ca/~daniel.odonnell/ From daniel.odonnell at uleth.ca Thu Aug 12 19:09:07 2010 From: daniel.odonnell at uleth.ca (O'Donnell, Dan) Date: Thu, 12 Aug 2010 17:09:07 -0600 Subject: [tei-council] Fwd: suggestions for TEI Tite documentation on AccesTEI portal In-Reply-To: <4FD35A0C-84CA-47FA-98C7-B038BF53E3B9@oucs.ox.ac.uk> References: <4C61987C.4010901@ultraslavonic.info> <95D1F082-497B-446F-A0B6-2FF1B31B62BE@inria.fr> <4C630D36.4010906@uleth.ca> <4C630EFD.2030803@oucs.ox.ac.uk> <4C632069.4010505@uleth.ca> <4C632D8A.8020801@oucs.ox.ac.uk> <4C632E9F.5070600@uleth.ca> <4FD35A0C-84CA-47FA-98C7-B038BF53E3B9@oucs.ox.ac.uk> Message-ID: <4C647F13.9090809@uleth.ca> Well, wouldn't that actually be related? PIE *bh --> Gmc *b by Grimm's law, and Verner's law wouldn't apply (http://people.uleth.ca/~daniel.odonnell/Tutorials/grimms-law-and-verners-law-notes). Actually, there is a discussion about this very thing on a blog maintained by your institution's vanity press: http://blog.oup.com/2006/11/etymological_fo/ A lot less fun as an explanation though. We murder to dissect. -dan On 10-08-12 02:25 PM, Sebastian Rahtz wrote: > On 12 Aug 2010, at 00:13, O'Donnell, Dan wrote: > > >> Then we are happy bali, which I'm guessing is the plural if, as I >> suspect, baloo comes from *balus (Gr. Balos). >> > It is the Hindi word "Bhalu", one believes > > -- > Sebastian Rahtz > Information Manager, Oxford University Computing Services > 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 > > S?lo le pido a Dios > que el futuro no me sea indiferente > > > > > -- Daniel Paul O'Donnell Professor of English University of Lethbridge Chair and CEO, Text Encoding Initiative (http://www.tei-c.org/) Co-Chair, Digital Initiatives Advisory Board, Medieval Academy of America President-elect (English), Society for Digital Humanities/Soci?t? pour l'?tude des m?dias interactifs (http://sdh-semi.org/) Founding Director (2003-2009), Digital Medievalist Project (http://www.digitalmedievalist.org/) Vox: +1 403 329-2377 Fax: +1 403 382-7191 (non-confidential) Home Page: http://people.uleth.ca/~daniel.odonnell/ From laurent.romary at inria.fr Fri Aug 13 01:41:31 2010 From: laurent.romary at inria.fr (Laurent Romary) Date: Fri, 13 Aug 2010 07:41:31 +0200 Subject: [tei-council] Fwd: Re: TEI Web site In-Reply-To: <4C647B90.8010400@uleth.ca> References: <4C601845.5020703@ultraslavonic.info> <40D633DF-9185-44D2-9726-9B28000B21DD@inria.fr> <4C647B90.8010400@uleth.ca> Message-ID: <22E10C74-C0FA-49AC-9A02-3E4DB31E862A@inria.fr> Fine. I am asking him to proceed. Laurent Le 13 ao?t 10 ? 00:54, O'Donnell, Dan a ?crit : > I think it would be a great idea. > > On 10-08-12 08:57 AM, Laurent Romary wrote: >> I do support this. Shall I ask David to procede further on this? >> >> Le 9 ao?t 10 ? 17:01, Kevin Hawkins a ?crit : >> >> >>> I think David Sewell's recent note to TEI-L about how the TEI >>> website >>> works is an excellent start to a colophon for the TEI website. >>> How do >>> others feel about having such a page? >>> >>> -------- Original Message -------- >>> Subject: Re: TEI Web site >>> Date: Mon, 9 Aug 2010 10:03:04 -0400 (EDT) >>> From: David Sewell<dsewell at virginia.edu> >>> To: Kevin Hawkins<kevin.s.hawkins at ultraslavonic.info> >>> >>> Kevin, >>> >>> I certainly wasn't composing it to be an official document--but I'd >>> suggest you run the idea of an "About this website" page by Council. >>> If >>> created, it should probably have more content than just a technical >>> note >>> on underlying data. >>> >>> David >>> >>> On Sun, 8 Aug 2010, Kevin Hawkins wrote: >>> >>> >>>> David, I think your message would make a fine colophon for the TEI >>>> website. >>>> Perhaps, in the navbar, there could be something like >>>> >>>> About --> This website >>>> >>>> which would bring up a short page containing more or less what you >>>> wrote >>>> below. >>>> >>>> >>>>> The content on www.tei-c.org is a composite of quite a few >>>>> underlying >>>>> sources. To wit: >>>>> >>>>> * Most of the content pages, such as those under Activities, >>>>> Membership, >>>>> and About, live as mostly XML data in OpenCMS, a content >>>>> management >>>>> system; our configuration converts TEI-XML to HTML on the fly >>>>> >>>>> * The news sidebar on the main page and /News/ are pulled in >>>>> quasi-dynamically from content that lives in the TEI WordPress >>>>> blog on >>>>> Sourceforge (http://sourceforge.net/apps/wordpress/tei/) >>>>> >>>>> * Some areas of the site are simply filesystem mirrors of the >>>>> current >>>>> TEI Sourceforge packages, e.g. the P4 and P5 Guidelines >>>>> documentation >>>>> under /release, and Roma under /Roma >>>>> >>>>> * Others are static filesystem directories with special material, >>>>> such >>>>> as the "TEI Vault" (http://www.tei-c.org/Vault/) >>>>> >>>>> * Yet others are pointers to TEI-related material hosted >>>>> externally (the >>>>> TEI webstore at http://www.tei-shop.org/, the new TEI Journal aka >>>>> J-TEI >>>>> site at http://journal.tei-c.org/) >>>>> >>>>> All integrated via an Apache configuration file resembling the >>>>> wiring >>>>> diagram of a nuclear submarine, and ably maintained by our >>>>> sysadmin >>>>> Shayne Brandon. >>>>> >>>> >>> -- >>> David Sewell, Editorial and Technical Manager >>> ROTUNDA, The University of Virginia Press >>> PO Box 400314, Charlottesville, VA 22904-4314 USA >>> Email: dsewell at virginia.edu Tel: +1 434 924 9973 >>> Web: http://rotunda.upress.virginia.edu/ >>> _______________________________________________ >>> tei-council mailing list >>> tei-council at lists.village.Virginia.EDU >>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council >>> >> Laurent Romary >> INRIA& HUB-IDSL >> laurent.romary at inria.fr >> >> >> >> _______________________________________________ >> tei-council mailing list >> tei-council at lists.village.Virginia.EDU >> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council >> > > -- > Daniel Paul O'Donnell > Professor of English > University of Lethbridge > > Chair and CEO, Text Encoding Initiative (http://www.tei-c.org/) > Co-Chair, Digital Initiatives Advisory Board, Medieval Academy of > America > President-elect (English), Society for Digital Humanities/Soci?t? > pour l'?tude des m?dias interactifs (http://sdh-semi.org/) > Founding Director (2003-2009), Digital Medievalist Project (http://www.digitalmedievalist.org/ > ) > > Vox: +1 403 329-2377 > Fax: +1 403 382-7191 (non-confidential) > Home Page: http://people.uleth.ca/~daniel.odonnell/ > > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Laurent Romary INRIA & HUB-IDSL laurent.romary at inria.fr From sebastian.rahtz at oucs.ox.ac.uk Fri Aug 13 05:46:24 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Fri, 13 Aug 2010 10:46:24 +0100 Subject: [tei-council] Fwd: suggestions for TEI Tite documentation on AccesTEI portal In-Reply-To: <4C647F13.9090809@uleth.ca> References: <4C61987C.4010901@ultraslavonic.info> <95D1F082-497B-446F-A0B6-2FF1B31B62BE@inria.fr> <4C630D36.4010906@uleth.ca> <4C630EFD.2030803@oucs.ox.ac.uk> <4C632069.4010505@uleth.ca> <4C632D8A.8020801@oucs.ox.ac.uk> <4C632E9F.5070600@uleth.ca> <4FD35A0C-84CA-47FA-98C7-B038BF53E3B9@oucs.ox.ac.uk> <4C647F13.9090809@uleth.ca> Message-ID: <0B027E6E-C059-430B-A37C-F6299AF33636@oucs.ox.ac.uk> surely no-one ever claimed a connection between "hullabaloo" and "Baloo the bear"? a hullabaloo seems more like something one associates with the Bandar Log -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From laurent.romary at inria.fr Mon Aug 16 02:13:53 2010 From: laurent.romary at inria.fr (Laurent Romary) Date: Mon, 16 Aug 2010 08:13:53 +0200 Subject: [tei-council] Colophon (was: TEI Web site) In-Reply-To: <4C601845.5020703@ultraslavonic.info> References: <4C601845.5020703@ultraslavonic.info> Message-ID: <3A7DDB54-C52A-44D4-B05F-775918196620@inria.fr> And David actually implemented this: see http://www.tei-c.org/About/website.xml He is about to add more links to this page from other places of the website. Laurent Le 9 ao?t 10 ? 17:01, Kevin Hawkins a ?crit : > I think David Sewell's recent note to TEI-L about how the TEI website > works is an excellent start to a colophon for the TEI website. How do > others feel about having such a page? > > -------- Original Message -------- > Subject: Re: TEI Web site > Date: Mon, 9 Aug 2010 10:03:04 -0400 (EDT) > From: David Sewell <dsewell at virginia.edu> > To: Kevin Hawkins <kevin.s.hawkins at ultraslavonic.info> > > Kevin, > > I certainly wasn't composing it to be an official document--but I'd > suggest you run the idea of an "About this website" page by Council. > If > created, it should probably have more content than just a technical > note > on underlying data. > > David > > On Sun, 8 Aug 2010, Kevin Hawkins wrote: > >> David, I think your message would make a fine colophon for the TEI >> website. >> Perhaps, in the navbar, there could be something like >> >> About --> This website >> >> which would bring up a short page containing more or less what you >> wrote >> below. >> >>> The content on www.tei-c.org is a composite of quite a few >>> underlying >>> sources. To wit: >>> >>> * Most of the content pages, such as those under Activities, >>> Membership, >>> and About, live as mostly XML data in OpenCMS, a content management >>> system; our configuration converts TEI-XML to HTML on the fly >>> >>> * The news sidebar on the main page and /News/ are pulled in >>> quasi-dynamically from content that lives in the TEI WordPress >>> blog on >>> Sourceforge (http://sourceforge.net/apps/wordpress/tei/) >>> >>> * Some areas of the site are simply filesystem mirrors of the >>> current >>> TEI Sourceforge packages, e.g. the P4 and P5 Guidelines >>> documentation >>> under /release, and Roma under /Roma >>> >>> * Others are static filesystem directories with special material, >>> such >>> as the "TEI Vault" (http://www.tei-c.org/Vault/) >>> >>> * Yet others are pointers to TEI-related material hosted >>> externally (the >>> TEI webstore at http://www.tei-shop.org/, the new TEI Journal aka >>> J-TEI >>> site at http://journal.tei-c.org/) >>> >>> All integrated via an Apache configuration file resembling the >>> wiring >>> diagram of a nuclear submarine, and ably maintained by our sysadmin >>> Shayne Brandon. >> > > -- > David Sewell, Editorial and Technical Manager > ROTUNDA, The University of Virginia Press > PO Box 400314, Charlottesville, VA 22904-4314 USA > Email: dsewell at virginia.edu Tel: +1 434 924 9973 > Web: http://rotunda.upress.virginia.edu/ > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Laurent Romary INRIA & HUB-IDSL laurent.romary at inria.fr From dsewell at virginia.edu Fri Aug 20 09:57:32 2010 From: dsewell at virginia.edu (David Sewell) Date: Fri, 20 Aug 2010 09:57:32 -0400 (EDT) Subject: [tei-council] Translations of P5 "TEI Lite" intro? Message-ID: <alpine.OSX.2.00.1008200954030.11406@lister.ei.virginia.edu> At Kevin's suggestion, I fixed a reference and link on our Tutorials webiste page pointing to TEI Lite documentation. Our TEI Lite page, http://www.tei-c.org/Guidelines/Customization/Lite/ lists several translations of the P4 version. Are there translations of the revised P5 version that we could add to this page? (If we aren't aware of any I can post the query on TEI-L.) David -- David Sewell, Editorial and Technical Manager ROTUNDA, The University of Virginia Press PO Box 400314, Charlottesville, VA 22904-4314 USA Email: dsewell at virginia.edu Tel: +1 434 924 9973 Web: http://rotunda.upress.virginia.edu/ From lou.burnard at oucs.ox.ac.uk Fri Aug 20 10:00:07 2010 From: lou.burnard at oucs.ox.ac.uk (Lou) Date: Fri, 20 Aug 2010 15:00:07 +0100 Subject: [tei-council] Translations of P5 "TEI Lite" intro? In-Reply-To: <alpine.OSX.2.00.1008200954030.11406@lister.ei.virginia.edu> References: <alpine.OSX.2.00.1008200954030.11406@lister.ei.virginia.edu> Message-ID: <4C6E8A67.90805@oucs.ox.ac.uk> David Sewell wrote: > At Kevin's suggestion, I fixed a reference and link on our Tutorials > webiste page pointing to TEI Lite documentation. Our TEI Lite page, > > http://www.tei-c.org/Guidelines/Customization/Lite/ > > lists several translations of the P4 version. Are there translations of > the revised P5 version that we could add to this page? (If we aren't > aware of any I can post the query on TEI-L.) > > David > Sadly, I dont think there are any. On the other hand, there is very little difference in the *text* between the P5 version and the P4 version. From laurent.romary at inria.fr Sat Aug 21 02:00:19 2010 From: laurent.romary at inria.fr (Laurent Romary) Date: Sat, 21 Aug 2010 08:00:19 +0200 Subject: [tei-council] Fwd: [ tei-Bugs-2900430 ] data type of @scribe and @script References: <E1OmcMv-0006r0-2h@sfs-web-9.v29.ch3.sourceforge.com> Message-ID: <229BE696-F4C5-4137-AF15-B0B6ECC457D9@inria.fr> Hi all, We get a lot of spam on SF. Would it not be possible to restrict writing to registered users? Laurent D?but du message r?exp?di? : > De : "SourceForge.net" <noreply at sourceforge.net> > Date : 21 ao?t 2010 02:55:33 GMT+02:00 > ? : Laurent.Romary at loria.fr > Objet : [ tei-Bugs-2900430 ] data type of @scribe and @script > > Bugs item #2900430, was opened at 2009-11-19 12:57 > Message generated for change (Comment added) made by nobody > You can respond by visiting: > https://sourceforge.net/tracker/?func=detail&atid=644062&aid=2900430&group_id=106328 > > Please note that this message will contain a full copy of the > comment thread, > including the initial issue submission, for this request, > not just the latest update. > Category: TEI: Definition of Elements/Attributes/Classes > Group: AMBER > Status: Open > Resolution: None > Priority: 5 > Private: No > Submitted By: Torsten Schassan (schassan) > Assigned to: Nobody/Anonymous (nobody) > Summary: data type of @scribe and @script > > Initial Comment: > Shouldn't the data type of @scribe and @script be data.pointer > rather than data.name? I would expect an explanation (i.e. > biographical details about the scribe, or characteristics of the > script) somewhere else if these attributes are filled. Thus, the > value of the attribute would be a pointer instead of just a name of > something? Especially as the description of @scribe states, that it > "gives a standard name or other identifier" (!). > > ---------------------------------------------------------------------- > > Comment By: Nobody/Anonymous (nobody) > Date: 2010-08-21 00:55 > > Message: > 4TLcxZ <a href="http://pzchoiejnczq.com/">pzchoiejnczq</a>, > [url=http://lczryxcibjpc.com/]lczryxcibjpc[/url], > [link=http://pqkpaktsweml.com/]pqkpaktsweml[/link], > http://mjcfjbvsnkcp.com/ > > ---------------------------------------------------------------------- > > Comment By: Dot Porter (dot_porter) > Date: 2010-04-30 13:10 > > Message: > the new <scriptNote>/<scriptDesc> should be considered parallel to > <typeNote>/<typeDesc> > (http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref- > typeDesc.html and > http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-typeNote.html) > > ---------------------------------------------------------------------- > > Comment By: Lou Burnard (louburnard) > Date: 2010-04-30 12:47 > > Message: > Nowhere to define a script; need to point to scribe and to script, > both > distinct. Not the same as hand. Need to decide on referring policy. > > ---------------------------------------------------------------------- > > Comment By: Elena Pierazzo (epierazzo) > Date: 2009-12-06 16:49 > > Message: > No to <handNote>, which describe the type of hand, but to something > like > <scriptNote> that describe the kind of script. For instance you want > to say > that the type of script is used mainly for the production of books > or for > charters; that was used mostly in a particular area/scriptorium, and > in a > particular date range. You can also say that the script is > characterised by > a particular shape of a given letter etc. > Into a <handNote> you will perhaps say that this particular scribe > uses > the script in a personal way, with log-short descendant, using a pen > which > is cut in a different way, using an ink of a given colour, etc. > Make sense? > > ---------------------------------------------------------------------- > > Comment By: Lou Burnard (louburnard) > Date: 2009-12-06 16:39 > > Message: > Presumably if @scribe (or @scribeRef) is a pointer it should point > to a > <person> and @script or @scriptRef should point to a <handNote>? > > ---------------------------------------------------------------------- > > Comment By: Elena Pierazzo (epierazzo) > Date: 2009-12-01 18:03 > > Message: > I agree Torsten you but I also see Lou's point about retro- > compatibility. > Perhaps we should add @scriptRef as pointer (as we did for <w> which > has > now @lemma and @lemmaRef for this very reason) and leave @script as > it is. > We definitely need a way to describe scripts properly! > Once we have done it, I think we have also to add something similar to > <handNotes> in the <profileDesc> in order to describe a script > properly. > > ---------------------------------------------------------------------- > > Comment By: Lou Burnard (louburnard) > Date: 2009-11-20 15:53 > > Message: > I can see why you might want this for @scribe, assuming you know > more about > the scribe than their conventional name (though how often is that the > case?), but what element would @script point to? For most usages these > attributes are just a convenient way of normalising references (like > @key) rather than requiring the stricter kind of validation which > @ref or > your proposal would permit-- or rather, require. This change would > thus > break a lot of existing documents. > > ---------------------------------------------------------------------- > > You can respond by visiting: > https://sourceforge.net/tracker/?func=detail&atid=644062&aid=2900430&group_id=106328 Laurent Romary INRIA & HUB-IDSL laurent.romary at inria.fr From lou.burnard at oucs.ox.ac.uk Sat Aug 21 06:15:47 2010 From: lou.burnard at oucs.ox.ac.uk (Lou Burnard) Date: Sat, 21 Aug 2010 11:15:47 +0100 Subject: [tei-council] trackers on sourceforge: login now required Message-ID: <4C6FA753.3090506@oucs.ox.ac.uk> As most readers of this list know, the TEI council uses the sourceforge tracker facility intensively as a part of the process of maintaining the TEI Guidelines. Anyone can read the suggestions for change to the Guidelines posted there, and follow the debate about their resolution. Anyone can also raise an issue and the Council pays attention to every ticket posted. Recently however we've been suffering from an outbreak of mindless and annoying spam. In order to try and cut down on this, I have now somewhat reluctantly turned off the ability to post bugs or feature requests anonymously, i.e. without first logging in to your sourceforge account. If you want to comment on something you think should change or be added to the Guidelines, use the Feature Request Tracker at http://sourceforge.net/tracker/?group_id=106328&atid=644065; if you want to report something you've noticed that appears to be broken, use the Bugs Tracker at http://sourceforge.net/tracker/?group_id=106328&atid=644062. (There are other trackers but we don't currently use them) At top right you'll see a "log in" link for those who already have a sourceforge account, and a "register" link for those who don't. Sourceforge accounts are completely free and give you other benefits too but it's still another account to manage, so I apologise for this slight increase in bureaucracy. From Laurent.Romary at inria.fr Wed Aug 25 04:38:31 2010 From: Laurent.Romary at inria.fr (Laurent Romary) Date: Wed, 25 Aug 2010 10:38:31 +0200 Subject: [tei-council] Fwd: References to OpenMath in the TEI P5 Guidelines References: <4C73F2E4.9080608@jacobs-university.de> Message-ID: <E241D330-8A05-498E-A7F7-31C3E19FBBAB@inria.fr> Hi all, I guess it is no-brainer. If no voice expresses a reluctance here I would ask our editorial support group in Oxford to implement this. Laurent D?but du message r?exp?di? : > De : Michael Kohlhase <m.kohlhase at jacobs-university.de> > Date : 24 ao?t 2010 18:27:16 GMT+02:00 > ? : <Laurent.Romary at inria.fr> > Cc : "Lange, Christoph" <ch.lange at jacobs-university.de> > Objet : References to OpenMath in the TEI P5 Guidelines > R?pondre ? : <m.kohlhase at jacobs-university.de> > > Dear Laurent Romary, > > I am writing to you as the Chair of the TEI council. I am writing > you in my capacity as the president of the OpenMath society (see http://www.openmath.org/society/) > . > > I have recently become aware that the TEI Guidelines (P5) mention > OpenMath in chapter 14 [http://www.tei-c.org/release/doc/tei-p5-doc/en/html/FT.html#FTFOR > ]. Unfortunately, most of the references are outdated (see below), > and I would be very grateful, if you could advise me whom to contact > to have them corrected. > > Thank you in advance, > > Michael Kohlhase > > ------------------------8<----------------------------- > Here are the sources (quoted) and the suggested updated URIs below. >> > The OpenMath Standard (http://www.openmath.org/V2/standard/index.html >> ) consists of specifications for > http://www.openmath.org/standard/om20-2004-06-30/ > >> > 1. OpenMath objects, representing the structure of formul? (http://www.openmath.org/V2/standard/objects.html >> ); > http://www.openmath.org/standard/om20-2004-06-30/omstd20html-2.xml#cha_obj > >> > 2. Content Dictionaries, providing semantic context (http://www.openmath.org/V2/standard/cd.html >> ); > http://www.openmath.org/standard/om20-2004-06-30/omstd20html-4.xml#cha_cd > >> > 3. Encodings, both binary (http://www.openmath.org/V2/standard/binary.html >> ) > http://www.openmath.org/standard/om20-2004-06-30/omstd20html-3.xml#sec_binary > >> > and XML (http://www.openmath.org/V2/standard/xml.html). > http://www.openmath.org/standard/om20-2004-06-30/omstd20html-3.xml#sec_xml > >> Finally, OMDoc (http://www.mathweb.org/omdoc/) is an extension > of the OpenMath standard that > > http://omdoc.org > -- > ---------------------------------------------------------------------- > Prof. Dr. Michael Kohlhase, Office: Research 1, Room 62 > Professor of Computer Science Campus Ring 1, > Jacobs University Bremen D-28759 Bremen, Germany > tel/fax: +49 421 200-3140/-493140 skype: m.kohlhase > m.kohlhase at jacobs-university.de http://kwarc.info/kohlhase > ---------------------------------------------------------------------- Laurent Romary INRIA & HUB-IDSL laurent.romary at inria.fr From Laurent.Romary at inria.fr Wed Aug 25 06:33:52 2010 From: Laurent.Romary at inria.fr (Laurent Romary) Date: Wed, 25 Aug 2010 12:33:52 +0200 Subject: [tei-council] Fwd: References to OpenMath in the TEI P5 Guidelines References: <4C73F2E4.9080608@jacobs-university.de> Message-ID: <EAB24D4F-3F4F-4C0B-990E-1DB31A699FC9@inria.fr> Hi all, I guess it is no-brainer. If no voice expresses a reluctance here I would ask our editorial support group in Oxford to implement this. Laurent D?but du message r?exp?di? : > De : Michael Kohlhase <m.kohlhase at jacobs-university.de> > Date : 24 ao?t 2010 18:27:16 GMT+02:00 > ? : <Laurent.Romary at inria.fr> > Cc : "Lange, Christoph" <ch.lange at jacobs-university.de> > Objet : References to OpenMath in the TEI P5 Guidelines > R?pondre ? : <m.kohlhase at jacobs-university.de> > > Dear Laurent Romary, > > I am writing to you as the Chair of the TEI council. I am writing > you in my capacity as the president of the OpenMath society (see http://www.openmath.org/society/) > . > > I have recently become aware that the TEI Guidelines (P5) mention > OpenMath in chapter 14 [http://www.tei-c.org/release/doc/tei-p5-doc/en/html/FT.html#FTFOR > ]. Unfortunately, most of the references are outdated (see below), > and I would be very grateful, if you could advise me whom to contact > to have them corrected. > > Thank you in advance, > > Michael Kohlhase > > ------------------------8<----------------------------- > Here are the sources (quoted) and the suggested updated URIs below. >> > The OpenMath Standard (http://www.openmath.org/V2/standard/index.html >> ) consists of specifications for > http://www.openmath.org/standard/om20-2004-06-30/ > >> > 1. OpenMath objects, representing the structure of formul? (http://www.openmath.org/V2/standard/objects.html >> ); > http://www.openmath.org/standard/om20-2004-06-30/omstd20html-2.xml#cha_obj > >> > 2. Content Dictionaries, providing semantic context (http://www.openmath.org/V2/standard/cd.html >> ); > http://www.openmath.org/standard/om20-2004-06-30/omstd20html-4.xml#cha_cd > >> > 3. Encodings, both binary (http://www.openmath.org/V2/standard/binary.html >> ) > http://www.openmath.org/standard/om20-2004-06-30/omstd20html-3.xml#sec_binary > >> > and XML (http://www.openmath.org/V2/standard/xml.html). > http://www.openmath.org/standard/om20-2004-06-30/omstd20html-3.xml#sec_xml > >> Finally, OMDoc (http://www.mathweb.org/omdoc/) is an extension > of the OpenMath standard that > > http://omdoc.org > -- > ---------------------------------------------------------------------- > Prof. Dr. Michael Kohlhase, Office: Research 1, Room 62 > Professor of Computer Science Campus Ring 1, > Jacobs University Bremen D-28759 Bremen, Germany > tel/fax: +49 421 200-3140/-493140 skype: m.kohlhase > m.kohlhase at jacobs-university.de http://kwarc.info/kohlhase > ---------------------------------------------------------------------- From laurent.romary at inria.fr Thu Aug 26 09:14:24 2010 From: laurent.romary at inria.fr (Laurent Romary) Date: Thu, 26 Aug 2010 15:14:24 +0200 Subject: [tei-council] What's next on the TEI publishing thread Message-ID: <02E66734-4A58-4B86-8321-CB2D090BEB5F@inria.fr> Hi all, You may remember that following the very nice symposium we had in Dublin, it was decided to charge a little group among us (Martin, Laurent, James, Lou, Sebastian, dan, coordinated efficiently by Kevin) to draft what we thought could be a charge to the the SIG on Scholarly Publishing (to develop a TEI customization). The document we have is accessible from http://docs.google.com/Doc?docid=0ARyxZGtPbrQ1ZHYzZHg3aF8xNmZyYjR3emY4&hl=en and Kevin and I would be happy to get feedback and advice on the next step to proceed through. Unless there are strong voices against this (will not be counted on the number of words; 1 person - 1 voice ;-)), I would like to ask the SIG if they share this vision and let volunteers to take up the initiative. How do you feel with this? Laurent Laurent Romary INRIA & HUB-IDSL laurent.romary at inria.fr From mholmes at uvic.ca Thu Aug 26 11:41:10 2010 From: mholmes at uvic.ca (Martin Holmes) Date: Thu, 26 Aug 2010 08:41:10 -0700 Subject: [tei-council] What's next on the TEI publishing thread In-Reply-To: <02E66734-4A58-4B86-8321-CB2D090BEB5F@inria.fr> References: <02E66734-4A58-4B86-8321-CB2D090BEB5F@inria.fr> Message-ID: <4C768B16.6010903@uvic.ca> This looks great to me. It might benefit from a final paragraph specifying roughly what we plan to do as a first step towards this goal (create a working group comprising e.g. three actively interested publishers and three TEI-ers? start working directly on identifying which modules should initially be included in the schema? etc.). Cheers, Martin On 10-08-26 06:14 AM, Laurent Romary wrote: > Hi all, > You may remember that following the very nice symposium we had in > Dublin, it was decided to charge a little group among us (Martin, > Laurent, James, Lou, Sebastian, dan, coordinated efficiently by Kevin) > to draft what we thought could be a charge to the the SIG on Scholarly > Publishing (to develop a TEI customization). The document we have is > accessible from > http://docs.google.com/Doc?docid=0ARyxZGtPbrQ1ZHYzZHg3aF8xNmZyYjR3emY4&hl=en > and Kevin and I would be happy to get feedback and advice on the next > step to proceed through. > Unless there are strong voices against this (will not be counted on > the number of words; 1 person - 1 voice ;-)), I would like to ask the > SIG if they share this vision and let volunteers to take up the > initiative. > How do you feel with this? > Laurent > > Laurent Romary > INRIA& HUB-IDSL > laurent.romary at inria.fr > > > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > -- Martin Holmes University of Victoria Humanities Computing and Media Centre (mholmes at uvic.ca) Half-Baked Software, Inc. (mholmes at halfbakedsoftware.com) martin at mholmes.com From laurent.romary at inria.fr Thu Aug 26 11:44:55 2010 From: laurent.romary at inria.fr (Laurent Romary) Date: Thu, 26 Aug 2010 17:44:55 +0200 Subject: [tei-council] What's next on the TEI publishing thread In-Reply-To: <4C768B16.6010903@uvic.ca> References: <02E66734-4A58-4B86-8321-CB2D090BEB5F@inria.fr> <4C768B16.6010903@uvic.ca> Message-ID: <B5124DD4-90F2-4249-8F62-05E92AEC08D5@inria.fr> That would be the next step (probably in response to the resonance we may or may not get from the SIG and/or the TEI community). Although, the last point you mention is already part of the work to be done once we have workers. Cheers, Laurent Le 26 ao?t 10 ? 17:41, Martin Holmes a ?crit : > This looks great to me. It might benefit from a final paragraph > specifying roughly what we plan to do as a first step towards this > goal > (create a working group comprising e.g. three actively interested > publishers and three TEI-ers? start working directly on identifying > which modules should initially be included in the schema? etc.). > > Cheers, > Martin > > On 10-08-26 06:14 AM, Laurent Romary wrote: >> Hi all, >> You may remember that following the very nice symposium we had in >> Dublin, it was decided to charge a little group among us (Martin, >> Laurent, James, Lou, Sebastian, dan, coordinated efficiently by >> Kevin) >> to draft what we thought could be a charge to the the SIG on >> Scholarly >> Publishing (to develop a TEI customization). The document we have is >> accessible from >> http://docs.google.com/Doc?docid=0ARyxZGtPbrQ1ZHYzZHg3aF8xNmZyYjR3emY4&hl=en >> and Kevin and I would be happy to get feedback and advice on the next >> step to proceed through. >> Unless there are strong voices against this (will not be counted on >> the number of words; 1 person - 1 voice ;-)), I would like to ask the >> SIG if they share this vision and let volunteers to take up the >> initiative. >> How do you feel with this? >> Laurent >> >> Laurent Romary >> INRIA& HUB-IDSL >> laurent.romary at inria.fr >> >> >> >> _______________________________________________ >> tei-council mailing list >> tei-council at lists.village.Virginia.EDU >> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council >> > > -- > Martin Holmes > University of Victoria Humanities Computing and Media Centre > (mholmes at uvic.ca) > Half-Baked Software, Inc. > (mholmes at halfbakedsoftware.com) > martin at mholmes.com > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Laurent Romary INRIA & HUB-IDSL laurent.romary at inria.fr From sebastian.rahtz at oucs.ox.ac.uk Thu Aug 26 13:02:47 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Thu, 26 Aug 2010 18:02:47 +0100 Subject: [tei-council] What's next on the TEI publishing thread In-Reply-To: <02E66734-4A58-4B86-8321-CB2D090BEB5F@inria.fr> References: <02E66734-4A58-4B86-8321-CB2D090BEB5F@inria.fr> Message-ID: <396CD713-64FE-4267-B6FA-6A1079F21869@oucs.ox.ac.uk> looks good to me. one sentence jarred: "The TEI Council would like to see the TEI adopted more widely as an archival format". There is a slight mixed message here - we want them to use TEI in their digital publishing workflow, but that may not be the same as their archival format. I _think_ we are saying we will define a customization which is guarenteed to be suitable for generating general-purpose epublications, somewhat equivalent to Tite, and we wlll develop and promote exemplar tools and transformations? This is much on the minds at the moment of those of us in Oxford, as we are coming to the end of local development on a document conversion web service, based on the Enrich Garage (we call it OxGarage). It accepts upload of typical formats (word processor, TEI XML, etc), and generates output as requested (TEI, docx, epub, odt, latex, pdf, html), using as many stages as needed behind the scenes. It also accepts ODD input and can spit out schemas, documentation etc; it even does Docbook to TEI conversion, and I think adding NLM to TEI would not be hard (or any other textual transformation you have to hand) In a separate thread I am asking about hosting a copy of Oxgarage at Virginia to demonstrate. This would provide a convenient testbed for the SIG's outputs? If I understood iptables, I'd open up our local test server now and point you at it, but I need to talk to someone clever first -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From laurent.romary at inria.fr Fri Aug 27 07:07:04 2010 From: laurent.romary at inria.fr (Laurent Romary) Date: Fri, 27 Aug 2010 13:07:04 +0200 Subject: [tei-council] What's next on the TEI publishing thread In-Reply-To: <396CD713-64FE-4267-B6FA-6A1079F21869@oucs.ox.ac.uk> References: <02E66734-4A58-4B86-8321-CB2D090BEB5F@inria.fr> <396CD713-64FE-4267-B6FA-6A1079F21869@oucs.ox.ac.uk> Message-ID: <EC0A1AE2-4A16-4841-A69C-CD7D5B96D079@inria.fr> Le 26 ao?t 10 ? 19:02, Sebastian Rahtz a ?crit : > looks good to me. > > one sentence jarred: "The TEI Council would like to see the TEI > adopted more widely as an archival format". There is a slight mixed > message here - we want them to use TEI in their digital publishing > workflow, but that may not be the same as their archival format. Agree. We may want to tune a clearer message. The idea is to have the TEI as a more long-standing formats than proprietary or domain specific solutions. > > I _think_ we are saying we will define a customization which is > guarenteed to be suitable for generating general-purpose > epublications, somewhat equivalent to Tite, and we wlll develop and > promote exemplar tools and transformations? Ideally yes. > > This is much on the minds at the moment of those of us in Oxford, as > we are coming to the end of local development on > a document conversion web service, based on the Enrich Garage (we > call it OxGarage). It accepts upload of typical > formats (word processor, TEI XML, etc), and generates output as > requested (TEI, docx, epub, odt, latex, pdf, html), using as many > stages > as needed behind the scenes. It also accepts ODD input and can spit > out schemas, documentation etc; it even does Docbook to TEI > conversion, and I think adding NLM to TEI would not be hard (or any > other textual transformation you have to hand) You mean, the ultimate Vesta? As to NLM, Martin and I have quite a bunch of stylesheets (Martin has TEI2NLM and I have NLM2TEI; plus a bunch of additional publisher formats). How can we proceed with this? > > In a separate thread I am asking about hosting a copy of Oxgarage > at Virginia to demonstrate. This would provide a convenient testbed > for the SIG's outputs? Good. > > If I understood iptables, I'd open up our local test server now and > point you at it, but I need to talk to someone clever first I thought you were such a person! > -- > Sebastian Rahtz > Information Manager, Oxford University Computing Services > 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 > > S?lo le pido a Dios > que el futuro no me sea indiferente > > > > Laurent Romary INRIA & HUB-IDSL laurent.romary at inria.fr From sebastian.rahtz at oucs.ox.ac.uk Fri Aug 27 08:15:39 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Fri, 27 Aug 2010 13:15:39 +0100 Subject: [tei-council] What's next on the TEI publishing thread In-Reply-To: <EC0A1AE2-4A16-4841-A69C-CD7D5B96D079@inria.fr> References: <02E66734-4A58-4B86-8321-CB2D090BEB5F@inria.fr> <396CD713-64FE-4267-B6FA-6A1079F21869@oucs.ox.ac.uk> <EC0A1AE2-4A16-4841-A69C-CD7D5B96D079@inria.fr> Message-ID: <1C65C59D-E4A9-499B-B55F-DB05258FB8AD@oucs.ox.ac.uk> On 27 Aug 2010, at 12:07, Laurent Romary wrote: > > Agree. We may want to tune a clearer message. The idea is to have the > TEI as a more long-standing formats than proprietary or domain > specific solutions. hmm. we need to be clear on this. is it the "lingua franca" rich interchange format to make digital publishng easy, or is it the archival format from which one derives formats which then to make new products? > > You mean, the ultimate Vesta? hmm. maybe. > As to NLM, Martin and I have quite a bunch of stylesheets (Martin has > TEI2NLM and I have NLM2TEI; plus a bunch of additional publisher > formats). How can we proceed with this? if you give me the transformations, I would add them to the family under Stylesheets on Sourceforge, and then OxGarage would find them to explain further, Oxgarage looks for files called "plugin.xml". The one for TEI to CSV looks like this: <extension plugin-id="pl.psnc.dl.ege.root" point-id="XslConverter" id="TEItoCSVconverter"> <parameter id="class" value="pl.psnc.dl.ege.MultiXslConverter"/> <parameter id="name" value="TEI to CSV"/> <parameter id="xsluri" value="profiles/default/csv/to.xsl" /> <parameter id="iMimeType" value="text/xml" /> <parameter id="iFormat" value="TEI" /> <parameter id="iDescription" value="TEI P5 XML Document" /> <parameter id="iType" value="text" /> <parameter id="oMimeType" value="text/csv" /> <parameter id="oFormat" value="csv" /> <parameter id="oDescription" value="Comma-Separated Values (.csv)" /> <parameter id="oType" value="spreadsheet" /> <parameter id="visibility" value="true" /> <parameter id="cost" value="11" /> </extension> this explains what the input and output formats are, and what the XSLT is to do the job. we'd bung in your file, write a plugin, and lo! it would appear >> >> If I understood iptables, I'd open up our local test server now and >> point you at it, but I need to talk to someone clever first > > I thought you were such a person! differently -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From mholmes at uvic.ca Fri Aug 27 08:44:45 2010 From: mholmes at uvic.ca (Martin Holmes) Date: Fri, 27 Aug 2010 05:44:45 -0700 Subject: [tei-council] What's next on the TEI publishing thread In-Reply-To: <1C65C59D-E4A9-499B-B55F-DB05258FB8AD@oucs.ox.ac.uk> References: <02E66734-4A58-4B86-8321-CB2D090BEB5F@inria.fr> <396CD713-64FE-4267-B6FA-6A1079F21869@oucs.ox.ac.uk> <EC0A1AE2-4A16-4841-A69C-CD7D5B96D079@inria.fr> <1C65C59D-E4A9-499B-B55F-DB05258FB8AD@oucs.ox.ac.uk> Message-ID: <4C77B33D.1060103@uvic.ca> On 10-08-27 05:15 AM, Sebastian Rahtz wrote: >> As to NLM, Martin and I have quite a bunch of stylesheets (Martin has >> TEI2NLM and I have NLM2TEI; plus a bunch of additional publisher >> formats). How can we proceed with this? > > if you give me the transformations, I would add them to the family under > Stylesheets on Sourceforge, and then OxGarage would find them While Laurent's stylesheets are generic, mine (TEI-to-NLM) are very specific to the tagset I'm using for my teiJournal project: <http://ialltjournal.org/> They'd be pretty useless for general use. If you look at an article, you can see links to the TEI, NLM 3.0, and NLM 2.3 versions: <http://ialltjournal.org/apa/doc.xhtml?id=iallt_40_01_sawhill> They might be a good start for someone planning to write a generic conversion, though. One issue is whether to go for NLM 2.3 or 3.0; IIRC, the NLM community seems to be rather split on whether 3.0 was a good idea, with some electing to stick with 2.3 (like GPL2 vs GPL3); so 3.0 is newer, but I think 2.3 has much broader adoption. I'll send you my stylesheets separately. Cheers, Martin From laurent.romary at inria.fr Fri Aug 27 09:34:30 2010 From: laurent.romary at inria.fr (Laurent Romary) Date: Fri, 27 Aug 2010 15:34:30 +0200 Subject: [tei-council] What's next on the TEI publishing thread In-Reply-To: <4C77B33D.1060103@uvic.ca> References: <02E66734-4A58-4B86-8321-CB2D090BEB5F@inria.fr> <396CD713-64FE-4267-B6FA-6A1079F21869@oucs.ox.ac.uk> <EC0A1AE2-4A16-4841-A69C-CD7D5B96D079@inria.fr> <1C65C59D-E4A9-499B-B55F-DB05258FB8AD@oucs.ox.ac.uk> <4C77B33D.1060103@uvic.ca> Message-ID: <4BB219F9-1FEE-45AF-810B-A9BC8A8EF3F5@inria.fr> Le 27 ao?t 10 ? 14:44, Martin Holmes a ?crit : > They might be a good start for someone planning to write a generic > conversion, though. One issue is whether to go for NLM 2.3 or 3.0; > IIRC, > the NLM community seems to be rather split on whether 3.0 was a good > idea, with some electing to stick with 2.3 (like GPL2 vs GPL3); so 3.0 > is newer, but I think 2.3 has much broader adoption. They actually pay the lack of a standardization strategy right from the onset.... From laurent.romary at inria.fr Fri Aug 27 09:36:22 2010 From: laurent.romary at inria.fr (Laurent Romary) Date: Fri, 27 Aug 2010 15:36:22 +0200 Subject: [tei-council] What's next on the TEI publishing thread In-Reply-To: <1C65C59D-E4A9-499B-B55F-DB05258FB8AD@oucs.ox.ac.uk> References: <02E66734-4A58-4B86-8321-CB2D090BEB5F@inria.fr> <396CD713-64FE-4267-B6FA-6A1079F21869@oucs.ox.ac.uk> <EC0A1AE2-4A16-4841-A69C-CD7D5B96D079@inria.fr> <1C65C59D-E4A9-499B-B55F-DB05258FB8AD@oucs.ox.ac.uk> Message-ID: <684223F4-931E-46C5-8F75-CA9D1794E1ED@inria.fr> Le 27 ao?t 10 ? 14:15, Sebastian Rahtz a ?crit : > > On 27 Aug 2010, at 12:07, Laurent Romary wrote: >> >> Agree. We may want to tune a clearer message. The idea is to have the >> TEI as a more long-standing formats than proprietary or domain >> specific solutions. > > hmm. we need to be clear on this. is it the "lingua franca" rich > interchange format > to make digital publishng easy, or is it the archival format from > which one derives > formats which then to make new products? Well. I am no clear on this. Could a native (Kevin?) try to find a way to leave this open without too many restrictions? From sebastian.rahtz at oucs.ox.ac.uk Fri Aug 27 16:24:32 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Fri, 27 Aug 2010 21:24:32 +0100 Subject: [tei-council] What's next on the TEI publishing thread In-Reply-To: <4C77B33D.1060103@uvic.ca> References: <02E66734-4A58-4B86-8321-CB2D090BEB5F@inria.fr> <396CD713-64FE-4267-B6FA-6A1079F21869@oucs.ox.ac.uk> <EC0A1AE2-4A16-4841-A69C-CD7D5B96D079@inria.fr> <1C65C59D-E4A9-499B-B55F-DB05258FB8AD@oucs.ox.ac.uk> <4C77B33D.1060103@uvic.ca> Message-ID: <5C78A6C7-4EB0-45B1-9526-67C32339581F@oucs.ox.ac.uk> On 27 Aug 2010, at 13:44, Martin Holmes wrote: > While Laurent's stylesheets are generic, mine (TEI-to-NLM) are very > specific to the tagset I'm using for my teiJournal project: that's OK. I am more concerned to just get the structure in place so that people can get the idea and add their own variants -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From sebastian.rahtz at oucs.ox.ac.uk Fri Aug 27 17:02:24 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Fri, 27 Aug 2010 22:02:24 +0100 Subject: [tei-council] OxGarage server for testing Message-ID: <B5BF1CA9-0C3B-45BB-BEA9-77476966CBB5@oucs.ox.ac.uk> Have a look at http://oxgarage.oucs.ox.ac.uk:8080/ege-webclient/ This is the test setup for our document conversion service which is an enhancement of Enrich Garage. Don't pass on the URL at the moment as a) it is not well tested, b) we don't know whether it will collapse under use, and c) I want to put a cleaner address on it But feel free to use it and report any errors you find. If you like it, we can make it run on tei-c.org (with TEI branding). The Garage can do three types of things * the docx, odt and epub conversions we have developed at Oxford * simpler XML->XML conversions expressed as XSL (such as TEI to NLM, included) * anything OpenOffice 3 can do But it also _chains_ conversions using any method it can. You pick a start format and and end format, and it works out the path. The result is controlled by "profiles", selected in the Advanced options. Not much variation at present, but a place where it is easy to add overrides, alternate CSS, changed options and so on. And for Laurent, yes it can do ODD processing. Did I mention a) it is NOT incredibly well tested? b) garbage in, garbage out. dont expect miracles -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From sebastian.rahtz at oucs.ox.ac.uk Fri Aug 27 17:07:27 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Fri, 27 Aug 2010 22:07:27 +0100 Subject: [tei-council] OxGarage server for testing In-Reply-To: <B5BF1CA9-0C3B-45BB-BEA9-77476966CBB5@oucs.ox.ac.uk> References: <B5BF1CA9-0C3B-45BB-BEA9-77476966CBB5@oucs.ox.ac.uk> Message-ID: <014B0A2C-1482-484A-BD2B-2C20E3130B9D@oucs.ox.ac.uk> PS I should have mentioned also that all the work is done by a RESTful web service which you can call in other ways. The "advanced options" shows you the URL it will use. -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From sebastian.rahtz at oucs.ox.ac.uk Mon Aug 30 07:51:28 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 30 Aug 2010 12:51:28 +0100 Subject: [tei-council] oxgarage service Message-ID: <9B38DB38-A67D-4704-8D52-B32552FBA02A@oucs.ox.ac.uk> to follow up my note last week, I have put up a page at http://www.oucs.ox.ac.uk/oxgarage/index.xml which gives the salient links for our oxgarage service (ie source and documentation). very much a case of "caveat convertor" at the moment -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From kevin.s.hawkins at ultraslavonic.info Tue Aug 31 16:30:52 2010 From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins) Date: Tue, 31 Aug 2010 16:30:52 -0400 Subject: [tei-council] TEI for publishing: archival or interchange format? (was Re: What's next on the TEI publishing thread) In-Reply-To: <684223F4-931E-46C5-8F75-CA9D1794E1ED@inria.fr> References: <02E66734-4A58-4B86-8321-CB2D090BEB5F@inria.fr> <396CD713-64FE-4267-B6FA-6A1079F21869@oucs.ox.ac.uk> <EC0A1AE2-4A16-4841-A69C-CD7D5B96D079@inria.fr> <1C65C59D-E4A9-499B-B55F-DB05258FB8AD@oucs.ox.ac.uk> <684223F4-931E-46C5-8F75-CA9D1794E1ED@inria.fr> Message-ID: <4C7D667C.5060503@ultraslavonic.info> Regarding: https://docs.google.com/Doc?docid=0ARyxZGtPbrQ1ZHYzZHg3aF8xNmZyYjR3emY4 ... Sebastian wrote: > one sentence jarred: "The TEI Council would like to see the TEI > adopted more widely as an archival format". There is a slight mixed > message here - we want them to use TEI in their digital publishing > workflow, but that may not be the same as their archival format. > > I _think_ we are saying we will define a customization which is > guarenteed to be suitable for generating general-purpose > epublications, somewhat equivalent to Tite, and we wlll develop and > promote exemplar tools and transformations? which was followed by an exchange (first Laurent, then Sebastian, and then Laurent again): >>> Agree. We may want to tune a clearer message. The idea is to have >>> the TEI as a more long-standing formats than proprietary or >>> domain specific solutions. >> >> hmm. we need to be clear on this. is it the "lingua franca" rich >> interchange format to make digital publishng easy, or is it the >> archival format from which one derives formats which then to make >> new products? > > > Well. I am no clear on this. Could a native (Kevin?) try to find a > way to leave this open without too many restrictions? Since I wrote most of the prose of the "call to action" in Google Docs, let me try to clarify what I meant. Sebastian thought that the call to action is proposing TEI as an output format for sharing with users, whereas I meant that we are proposing TEI as an archival format (a "pivot point") in publishing workflows. That's why I wrote "While market forces are converging on EPUB as the main distribution format for e-readers" before explaining why TEI is useful as an archival format. I don't think we can compete with EPUB and HTML as linguas francas. (Is that the plural of "lingua franca"?) However, I allow for the possibility that TEI files might also be provided to end users as a side benefit. That's why I added the phrase in parentheses after what Sebastian quoted. Here's the full sentence: The TEI Council would like to see the TEI adopted more widely as an archival format by publishers of scholarly content (and, when feasible for a business model, as a format for users). I'd like to make this all clearer in case others are confused in the way Sebastian was, but I'm not sure how to do so. Suggestions? Kevin From sebastian.rahtz at oucs.ox.ac.uk Tue Aug 31 16:48:43 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 31 Aug 2010 21:48:43 +0100 Subject: [tei-council] TEI for publishing: archival or interchange format? (was Re: What's next on the TEI publishing thread) In-Reply-To: <4C7D667C.5060503@ultraslavonic.info> References: <02E66734-4A58-4B86-8321-CB2D090BEB5F@inria.fr> <396CD713-64FE-4267-B6FA-6A1079F21869@oucs.ox.ac.uk> <EC0A1AE2-4A16-4841-A69C-CD7D5B96D079@inria.fr> <1C65C59D-E4A9-499B-B55F-DB05258FB8AD@oucs.ox.ac.uk> <684223F4-931E-46C5-8F75-CA9D1794E1ED@inria.fr> <4C7D667C.5060503@ultraslavonic.info> Message-ID: <90D6C305-1364-444E-8F84-0C7B5C4C7C8E@oucs.ox.ac.uk> On 31 Aug 2010, at 21:30, Kevin Hawkins wrote: > > Since I wrote most of the prose of the "call to action" in Google Docs, > let me try to clarify what I meant. Sebastian thought that the call to > action is proposing TEI as an output format for sharing with users, not quite. I meant was it the format from which the readonly formats like HTML and ePub are derived. I was distinguishing between the genuine archive format (with all the markup, metadata and goodness) and the interchange format from which one can make the output formats. Maybe the distinction is false, however But I would never propose TEI as a format for users, sorry :-} > > don't think we can compete with EPUB and HTML as linguas francas. (Is > that the plural of "lingua franca"?) linguae francae -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From kevin.s.hawkins at ultraslavonic.info Wed Sep 1 14:51:35 2010 From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins) Date: Wed, 01 Sep 2010 14:51:35 -0400 Subject: [tei-council] TEI for publishing: archival or interchange format? (was Re: What's next on the TEI publishing thread) In-Reply-To: <90D6C305-1364-444E-8F84-0C7B5C4C7C8E@oucs.ox.ac.uk> References: <02E66734-4A58-4B86-8321-CB2D090BEB5F@inria.fr> <396CD713-64FE-4267-B6FA-6A1079F21869@oucs.ox.ac.uk> <EC0A1AE2-4A16-4841-A69C-CD7D5B96D079@inria.fr> <1C65C59D-E4A9-499B-B55F-DB05258FB8AD@oucs.ox.ac.uk> <684223F4-931E-46C5-8F75-CA9D1794E1ED@inria.fr> <4C7D667C.5060503@ultraslavonic.info> <90D6C305-1364-444E-8F84-0C7B5C4C7C8E@oucs.ox.ac.uk> Message-ID: <4C7EA0B7.5090502@ultraslavonic.info> On 8/31/2010 4:48 PM, Sebastian Rahtz wrote: > > On 31 Aug 2010, at 21:30, Kevin Hawkins wrote: > >> >> Since I wrote most of the prose of the "call to action" in Google Docs, >> let me try to clarify what I meant. Sebastian thought that the call to >> action is proposing TEI as an output format for sharing with users, > > not quite. I meant was it the format from which the readonly formats like > HTML and ePub are derived. I was distinguishing between the genuine > archive format (with all the markup, metadata and goodness) and the interchange format > from which one can make the output formats. Maybe the distinction is false, however > > But I would never propose TEI as a format for users, sorry :-} Okay, I understand now. I have not been making such a distinction, which is why I conflated "archive" and "pivot point" in my document. I avoided using the term "interchange format" because I find it ambiguous: you use it as pivot point, whereas to me it sounds a bit like an output format. I have revised to leave more wiggle room: https://docs.google.com/Doc?docid=0ARyxZGtPbrQ1ZHYzZHg3aF8xNmZyYjR3emY4 Is this better? Kevin From daniel.odonnell at uleth.ca Wed Sep 1 15:01:37 2010 From: daniel.odonnell at uleth.ca (O'Donnell, Dan) Date: Wed, 01 Sep 2010 13:01:37 -0600 Subject: [tei-council] TEI for publishing: archival or interchange format? (was Re: What's next on the TEI publishing thread) In-Reply-To: <4C7EA0B7.5090502@ultraslavonic.info> References: <02E66734-4A58-4B86-8321-CB2D090BEB5F@inria.fr> <396CD713-64FE-4267-B6FA-6A1079F21869@oucs.ox.ac.uk> <EC0A1AE2-4A16-4841-A69C-CD7D5B96D079@inria.fr> <1C65C59D-E4A9-499B-B55F-DB05258FB8AD@oucs.ox.ac.uk> <684223F4-931E-46C5-8F75-CA9D1794E1ED@inria.fr> <4C7D667C.5060503@ultraslavonic.info> <90D6C305-1364-444E-8F84-0C7B5C4C7C8E@oucs.ox.ac.uk> <4C7EA0B7.5090502@ultraslavonic.info> Message-ID: <4C7EA311.4000509@uleth.ca> I like that Kevin. I think the weaselling is pretty good and not noticeable. I do wonder if we downplay (or at least don't emphasise heavily enough) the real benefit that users of other formats might gain from working with us. I'd say that things that would immediately strike me if I was reading this as an outsider already committed to another format are: do they want me to start encoding everything in TEI? And what do I gain concretely in my workflow by dealing with these people. I suspect the answer is to make developing some transformation tools to and from major alternative XMLs a key deliverable of the larger effort (i.e. something we could participate in making?), and emphasing a little more strongly that an ability to convert in and out of some standard publishing customisation would allow content publishers an opportunity to really take advantage of community-developed initiatives and publication opportunities. I realise you make this last point to a certain extent. But I wonder if it couldn't be hit harder. But really well done. -dan On 10-09-01 12:51 PM, Kevin Hawkins wrote: > On 8/31/2010 4:48 PM, Sebastian Rahtz wrote: > >> On 31 Aug 2010, at 21:30, Kevin Hawkins wrote: >> >> >>> Since I wrote most of the prose of the "call to action" in Google Docs, >>> let me try to clarify what I meant. Sebastian thought that the call to >>> action is proposing TEI as an output format for sharing with users, >>> >> not quite. I meant was it the format from which the readonly formats like >> HTML and ePub are derived. I was distinguishing between the genuine >> archive format (with all the markup, metadata and goodness) and the interchange format >> from which one can make the output formats. Maybe the distinction is false, however >> >> But I would never propose TEI as a format for users, sorry :-} >> > Okay, I understand now. I have not been making such a distinction, > which is why I conflated "archive" and "pivot point" in my document. I > avoided using the term "interchange format" because I find it ambiguous: > you use it as pivot point, whereas to me it sounds a bit like an output > format. > > I have revised to leave more wiggle room: > > https://docs.google.com/Doc?docid=0ARyxZGtPbrQ1ZHYzZHg3aF8xNmZyYjR3emY4 > > Is this better? > > Kevin > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > -- Daniel Paul O'Donnell Professor of English University of Lethbridge Chair and CEO, Text Encoding Initiative (http://www.tei-c.org/) Co-Chair, Digital Initiatives Advisory Board, Medieval Academy of America President-elect (English), Society for Digital Humanities/Soci?t? pour l'?tude des m?dias interactifs (http://sdh-semi.org/) Founding Director (2003-2009), Digital Medievalist Project (http://www.digitalmedievalist.org/) Vox: +1 403 329-2377 Fax: +1 403 382-7191 (non-confidential) Home Page: http://people.uleth.ca/~daniel.odonnell/ From kevin.s.hawkins at ultraslavonic.info Wed Sep 1 15:23:44 2010 From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins) Date: Wed, 01 Sep 2010 15:23:44 -0400 Subject: [tei-council] TEI for publishing: archival or interchange format? (was Re: What's next on the TEI publishing thread) In-Reply-To: <4C7EA311.4000509@uleth.ca> References: <02E66734-4A58-4B86-8321-CB2D090BEB5F@inria.fr> <396CD713-64FE-4267-B6FA-6A1079F21869@oucs.ox.ac.uk> <EC0A1AE2-4A16-4841-A69C-CD7D5B96D079@inria.fr> <1C65C59D-E4A9-499B-B55F-DB05258FB8AD@oucs.ox.ac.uk> <684223F4-931E-46C5-8F75-CA9D1794E1ED@inria.fr> <4C7D667C.5060503@ultraslavonic.info> <90D6C305-1364-444E-8F84-0C7B5C4C7C8E@oucs.ox.ac.uk> <4C7EA0B7.5090502@ultraslavonic.info> <4C7EA311.4000509@uleth.ca> Message-ID: <4C7EA840.3020001@ultraslavonic.info> Inserted a new last sentence in the "rationale": While it need not replace every publisher's XML workflow, some publishers currently using XML might even find that the TEI's robust infrastructure and community-driven nature allows them to better cope with deficiencies in their existing practice and participate in an open community. --K. On 9/1/2010 3:01 PM, O'Donnell, Dan wrote: > I like that Kevin. I think the weaselling is pretty good and not > noticeable. I do wonder if we downplay (or at least don't emphasise > heavily enough) the real benefit that users of other formats might gain > from working with us. > > I'd say that things that would immediately strike me if I was reading > this as an outsider already committed to another format are: do they > want me to start encoding everything in TEI? And what do I gain > concretely in my workflow by dealing with these people. > > I suspect the answer is to make developing some transformation tools to > and from major alternative XMLs a key deliverable of the larger effort > (i.e. something we could participate in making?), and emphasing a little > more strongly that an ability to convert in and out of some standard > publishing customisation would allow content publishers an opportunity > to really take advantage of community-developed initiatives and > publication opportunities. > > I realise you make this last point to a certain extent. But I wonder if > it couldn't be hit harder. > > But really well done. > > -dan > > On 10-09-01 12:51 PM, Kevin Hawkins wrote: >> On 8/31/2010 4:48 PM, Sebastian Rahtz wrote: >> >>> On 31 Aug 2010, at 21:30, Kevin Hawkins wrote: >>> >>> >>>> Since I wrote most of the prose of the "call to action" in Google Docs, >>>> let me try to clarify what I meant. Sebastian thought that the call to >>>> action is proposing TEI as an output format for sharing with users, >>>> >>> not quite. I meant was it the format from which the readonly formats like >>> HTML and ePub are derived. I was distinguishing between the genuine >>> archive format (with all the markup, metadata and goodness) and the interchange format >>> from which one can make the output formats. Maybe the distinction is false, however >>> >>> But I would never propose TEI as a format for users, sorry :-} >>> >> Okay, I understand now. I have not been making such a distinction, >> which is why I conflated "archive" and "pivot point" in my document. I >> avoided using the term "interchange format" because I find it ambiguous: >> you use it as pivot point, whereas to me it sounds a bit like an output >> format. >> >> I have revised to leave more wiggle room: >> >> https://docs.google.com/Doc?docid=0ARyxZGtPbrQ1ZHYzZHg3aF8xNmZyYjR3emY4 >> >> Is this better? >> >> Kevin >> _______________________________________________ >> tei-council mailing list >> tei-council at lists.village.Virginia.EDU >> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council >> > From laurent.romary at inria.fr Wed Sep 1 15:32:04 2010 From: laurent.romary at inria.fr (Laurent Romary) Date: Wed, 1 Sep 2010 21:32:04 +0200 Subject: [tei-council] TEI for publishing: archival or interchange format? (was Re: What's next on the TEI publishing thread) In-Reply-To: <4C7EA840.3020001@ultraslavonic.info> References: <02E66734-4A58-4B86-8321-CB2D090BEB5F@inria.fr> <396CD713-64FE-4267-B6FA-6A1079F21869@oucs.ox.ac.uk> <EC0A1AE2-4A16-4841-A69C-CD7D5B96D079@inria.fr> <1C65C59D-E4A9-499B-B55F-DB05258FB8AD@oucs.ox.ac.uk> <684223F4-931E-46C5-8F75-CA9D1794E1ED@inria.fr> <4C7D667C.5060503@ultraslavonic.info> <90D6C305-1364-444E-8F84-0C7B5C4C7C8E@oucs.ox.ac.uk> <4C7EA0B7.5090502@ultraslavonic.info> <4C7EA311.4000509@uleth.ca> <4C7EA840.3020001@ultraslavonic.info> Message-ID: <0A0F56F6-13C0-4725-A6FB-B9CB8145D527@inria.fr> Even at this late hour in the day (for me), I like this formulation. Thanks Kevin! Le 1 sept. 10 ? 21:23, Kevin Hawkins a ?crit : > Inserted a new last sentence in the "rationale": > > While it need not replace every publisher's XML workflow, some > publishers currently using XML might even find that the TEI's robust > infrastructure and community-driven nature allows them to better cope > with deficiencies in their existing practice and participate in an > open > community. > > --K. > > On 9/1/2010 3:01 PM, O'Donnell, Dan wrote: >> I like that Kevin. I think the weaselling is pretty good and not >> noticeable. I do wonder if we downplay (or at least don't emphasise >> heavily enough) the real benefit that users of other formats might >> gain >> from working with us. >> >> I'd say that things that would immediately strike me if I was reading >> this as an outsider already committed to another format are: do they >> want me to start encoding everything in TEI? And what do I gain >> concretely in my workflow by dealing with these people. >> >> I suspect the answer is to make developing some transformation >> tools to >> and from major alternative XMLs a key deliverable of the larger >> effort >> (i.e. something we could participate in making?), and emphasing a >> little >> more strongly that an ability to convert in and out of some standard >> publishing customisation would allow content publishers an >> opportunity >> to really take advantage of community-developed initiatives and >> publication opportunities. >> >> I realise you make this last point to a certain extent. But I >> wonder if >> it couldn't be hit harder. >> >> But really well done. >> >> -dan >> >> On 10-09-01 12:51 PM, Kevin Hawkins wrote: >>> On 8/31/2010 4:48 PM, Sebastian Rahtz wrote: >>> >>>> On 31 Aug 2010, at 21:30, Kevin Hawkins wrote: >>>> >>>> >>>>> Since I wrote most of the prose of the "call to action" in >>>>> Google Docs, >>>>> let me try to clarify what I meant. Sebastian thought that the >>>>> call to >>>>> action is proposing TEI as an output format for sharing with >>>>> users, >>>>> >>>> not quite. I meant was it the format from which the readonly >>>> formats like >>>> HTML and ePub are derived. I was distinguishing between the genuine >>>> archive format (with all the markup, metadata and goodness) and >>>> the interchange format >>>> from which one can make the output formats. Maybe the distinction >>>> is false, however >>>> >>>> But I would never propose TEI as a format for users, sorry :-} >>>> >>> Okay, I understand now. I have not been making such a distinction, >>> which is why I conflated "archive" and "pivot point" in my >>> document. I >>> avoided using the term "interchange format" because I find it >>> ambiguous: >>> you use it as pivot point, whereas to me it sounds a bit like an >>> output >>> format. >>> >>> I have revised to leave more wiggle room: >>> >>> https://docs.google.com/Doc?docid=0ARyxZGtPbrQ1ZHYzZHg3aF8xNmZyYjR3emY4 >>> >>> Is this better? >>> >>> Kevin >>> _______________________________________________ >>> tei-council mailing list >>> tei-council at lists.village.Virginia.EDU >>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council >>> >> > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Laurent Romary INRIA & HUB-IDSL laurent.romary at inria.fr From sebastian.rahtz at oucs.ox.ac.uk Wed Sep 1 18:13:46 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Wed, 1 Sep 2010 23:13:46 +0100 Subject: [tei-council] TEI for publishing: archival or interchange format? (was Re: What's next on the TEI publishing thread) In-Reply-To: <4C7EA311.4000509@uleth.ca> References: <02E66734-4A58-4B86-8321-CB2D090BEB5F@inria.fr> <396CD713-64FE-4267-B6FA-6A1079F21869@oucs.ox.ac.uk> <EC0A1AE2-4A16-4841-A69C-CD7D5B96D079@inria.fr> <1C65C59D-E4A9-499B-B55F-DB05258FB8AD@oucs.ox.ac.uk> <684223F4-931E-46C5-8F75-CA9D1794E1ED@inria.fr> <4C7D667C.5060503@ultraslavonic.info> <90D6C305-1364-444E-8F84-0C7B5C4C7C8E@oucs.ox.ac.uk> <4C7EA0B7.5090502@ultraslavonic.info> <4C7EA311.4000509@uleth.ca> Message-ID: <C87BED0B-0C6F-433E-85B4-98CEFF60B20C@oucs.ox.ac.uk> On 1 Sep 2010, at 20:01, O'Donnell, Dan wrote: > I suspect the answer is to make developing some transformation tools to > and from major alternative XMLs a key deliverable of the larger effort > (i.e. something we could participate in making?), This is just the market the OxGarage is in (http://oxgarage.oucs.ox.ac.uk:8080/ege-webclient), of course. Such conversions are easy to plugin; somewhat harder to make foolproof :-{ If you look at our Docbook to TEI, you may see that making this cover any or all Docbook docs will take some work. As for TEI to Docbook, thats potentially impossible. -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From daniel.odonnell at uleth.ca Wed Sep 1 18:15:42 2010 From: daniel.odonnell at uleth.ca (O'Donnell, Dan) Date: Wed, 01 Sep 2010 16:15:42 -0600 Subject: [tei-council] TEI for publishing: archival or interchange format? (was Re: What's next on the TEI publishing thread) In-Reply-To: <C87BED0B-0C6F-433E-85B4-98CEFF60B20C@oucs.ox.ac.uk> References: <02E66734-4A58-4B86-8321-CB2D090BEB5F@inria.fr> <396CD713-64FE-4267-B6FA-6A1079F21869@oucs.ox.ac.uk> <EC0A1AE2-4A16-4841-A69C-CD7D5B96D079@inria.fr> <1C65C59D-E4A9-499B-B55F-DB05258FB8AD@oucs.ox.ac.uk> <684223F4-931E-46C5-8F75-CA9D1794E1ED@inria.fr> <4C7D667C.5060503@ultraslavonic.info> <90D6C305-1364-444E-8F84-0C7B5C4C7C8E@oucs.ox.ac.uk> <4C7EA0B7.5090502@ultraslavonic.info> <4C7EA311.4000509@uleth.ca> <C87BED0B-0C6F-433E-85B4-98CEFF60B20C@oucs.ox.ac.uk> Message-ID: <4C7ED08E.6080606@uleth.ca> And this is why I (and everybody else) love you all so deeply ;) Seriously, I was thinking of exactly this (and of course your earlier--and on-going--work on stylesheets and other deliverables). It is this that allows us to make these claims. On 10-09-01 04:13 PM, Sebastian Rahtz wrote: > On 1 Sep 2010, at 20:01, O'Donnell, Dan wrote: > > >> I suspect the answer is to make developing some transformation tools to >> and from major alternative XMLs a key deliverable of the larger effort >> (i.e. something we could participate in making?), >> > This is just the market the OxGarage is in (http://oxgarage.oucs.ox.ac.uk:8080/ege-webclient), > of course. Such conversions are easy to plugin; somewhat harder > to make foolproof :-{ If you look at our Docbook to TEI, you may see that > making this cover any or all Docbook docs will take some work. As for > TEI to Docbook, thats potentially impossible. > > -- > Sebastian Rahtz > Information Manager, Oxford University Computing Services > 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 > > S?lo le pido a Dios > que el futuro no me sea indiferente > > > > > -- Daniel Paul O'Donnell Professor of English University of Lethbridge Chair and CEO, Text Encoding Initiative (http://www.tei-c.org/) Co-Chair, Digital Initiatives Advisory Board, Medieval Academy of America President-elect (English), Society for Digital Humanities/Soci?t? pour l'?tude des m?dias interactifs (http://sdh-semi.org/) Founding Director (2003-2009), Digital Medievalist Project (http://www.digitalmedievalist.org/) Vox: +1 403 329-2377 Fax: +1 403 382-7191 (non-confidential) Home Page: http://people.uleth.ca/~daniel.odonnell/ From sebastian.rahtz at oucs.ox.ac.uk Wed Sep 1 18:18:30 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Wed, 1 Sep 2010 23:18:30 +0100 Subject: [tei-council] TEI for publishing: archival or interchange format? (was Re: What's next on the TEI publishing thread) In-Reply-To: <4C7EA0B7.5090502@ultraslavonic.info> References: <02E66734-4A58-4B86-8321-CB2D090BEB5F@inria.fr> <396CD713-64FE-4267-B6FA-6A1079F21869@oucs.ox.ac.uk> <EC0A1AE2-4A16-4841-A69C-CD7D5B96D079@inria.fr> <1C65C59D-E4A9-499B-B55F-DB05258FB8AD@oucs.ox.ac.uk> <684223F4-931E-46C5-8F75-CA9D1794E1ED@inria.fr> <4C7D667C.5060503@ultraslavonic.info> <90D6C305-1364-444E-8F84-0C7B5C4C7C8E@oucs.ox.ac.uk> <4C7EA0B7.5090502@ultraslavonic.info> Message-ID: <1DF11F8F-C682-483F-BF75-5422E73BD8C0@oucs.ox.ac.uk> On 1 Sep 2010, at 19:51, Kevin Hawkins wrote: > Okay, I understand now. I have not been making such a distinction, > which is why I conflated "archive" and "pivot point" in my document. I > avoided using the term "interchange format" because I find it ambiguous: > you use it as pivot point, whereas to me it sounds a bit like an output > format. I agree, the terninology is open to interpretation. I do still see a distinction between tei_all (archive format) and tei_pub (pivot format), but its probably not appropriate for this doc. > > I have revised to leave more wiggle room: > > https://docs.google.com/Doc?docid=0ARyxZGtPbrQ1ZHYzZHg3aF8xNmZyYjR3emY4 > > Is this better? yes, seems fine now. I'll get back now to my current task of converting an InDesign file (via HTML) into TEI for use in making an ePub for the Bodleian Library ..... :-} -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From lou.burnard at oucs.ox.ac.uk Wed Sep 1 18:35:43 2010 From: lou.burnard at oucs.ox.ac.uk (Lou Burnard) Date: Wed, 01 Sep 2010 23:35:43 +0100 Subject: [tei-council] TEI for publishing: archival or interchange format? (was Re: What's next on the TEI publishing thread) In-Reply-To: <C87BED0B-0C6F-433E-85B4-98CEFF60B20C@oucs.ox.ac.uk> References: <02E66734-4A58-4B86-8321-CB2D090BEB5F@inria.fr> <396CD713-64FE-4267-B6FA-6A1079F21869@oucs.ox.ac.uk> <EC0A1AE2-4A16-4841-A69C-CD7D5B96D079@inria.fr> <1C65C59D-E4A9-499B-B55F-DB05258FB8AD@oucs.ox.ac.uk> <684223F4-931E-46C5-8F75-CA9D1794E1ED@inria.fr> <4C7D667C.5060503@ultraslavonic.info> <90D6C305-1364-444E-8F84-0C7B5C4C7C8E@oucs.ox.ac.uk> <4C7EA0B7.5090502@ultraslavonic.info> <4C7EA311.4000509@uleth.ca> <C87BED0B-0C6F-433E-85B4-98CEFF60B20C@oucs.ox.ac.uk> Message-ID: <4C7ED53F.5090704@oucs.ox.ac.uk> On 01/09/10 23:13, Sebastian Rahtz wrote: > > As for > TEI to Docbook, thats potentially impossible. > Oh well, if it's only *potentially* impossible ... From sebastian.rahtz at oucs.ox.ac.uk Wed Sep 1 18:48:50 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Wed, 1 Sep 2010 23:48:50 +0100 Subject: [tei-council] TEI for publishing: archival or interchange format? (was Re: What's next on the TEI publishing thread) In-Reply-To: <4C7ED53F.5090704@oucs.ox.ac.uk> References: <02E66734-4A58-4B86-8321-CB2D090BEB5F@inria.fr> <396CD713-64FE-4267-B6FA-6A1079F21869@oucs.ox.ac.uk> <EC0A1AE2-4A16-4841-A69C-CD7D5B96D079@inria.fr> <1C65C59D-E4A9-499B-B55F-DB05258FB8AD@oucs.ox.ac.uk> <684223F4-931E-46C5-8F75-CA9D1794E1ED@inria.fr> <4C7D667C.5060503@ultraslavonic.info> <90D6C305-1364-444E-8F84-0C7B5C4C7C8E@oucs.ox.ac.uk> <4C7EA0B7.5090502@ultraslavonic.info> <4C7EA311.4000509@uleth.ca> <C87BED0B-0C6F-433E-85B4-98CEFF60B20C@oucs.ox.ac.uk> <4C7ED53F.5090704@oucs.ox.ac.uk> Message-ID: <279008DD-14C8-40D2-8154-34A1F6CEF093@oucs.ox.ac.uk> On 1 Sep 2010, at 23:35, Lou Burnard wrote: > On 01/09/10 23:13, Sebastian Rahtz wrote: >> >> As for >> TEI to Docbook, thats potentially impossible. >> > > Oh well, if it's only *potentially* impossible ... it depends on the spec of a translation. plainly, you cant keep all the semantic distinctions of TEI in Docbook. and there are all the things we can mark up in TEI which simply have no presentation corollary. -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From mholmes at uvic.ca Wed Sep 1 19:01:58 2010 From: mholmes at uvic.ca (Martin Holmes) Date: Wed, 1 Sep 2010 16:01:58 -0700 Subject: [tei-council] TEI for publishing: archival or interchange format? (was Re: What's next on the TEI publishing thread) In-Reply-To: <279008DD-14C8-40D2-8154-34A1F6CEF093@oucs.ox.ac.uk> References: <02E66734-4A58-4B86-8321-CB2D090BEB5F@inria.fr> <396CD713-64FE-4267-B6FA-6A1079F21869@oucs.ox.ac.uk> <EC0A1AE2-4A16-4841-A69C-CD7D5B96D079@inria.fr> <1C65C59D-E4A9-499B-B55F-DB05258FB8AD@oucs.ox.ac.uk> <684223F4-931E-46C5-8F75-CA9D1794E1ED@inria.fr> <4C7D667C.5060503@ultraslavonic.info> <90D6C305-1364-444E-8F84-0C7B5C4C7C8E@oucs.ox.ac.uk> <4C7EA0B7.5090502@ultraslavonic.info> <4C7EA311.4000509@uleth.ca> <C87BED0B-0C6F-433E-85B4-98CEFF60B20C@oucs.ox.ac.uk> <4C7ED53F.5090704@oucs.ox.ac.uk> <279008DD-14C8-40D2-8154-34A1F6CEF093@oucs.ox.ac.uk> Message-ID: <4C7EDB66.2010806@uvic.ca> On 10-09-01 03:48 PM, Sebastian Rahtz wrote: > > On 1 Sep 2010, at 23:35, Lou Burnard wrote: > >> On 01/09/10 23:13, Sebastian Rahtz wrote: >>> >>> As for >>> TEI to Docbook, thats potentially impossible. >>> >> >> Oh well, if it's only *potentially* impossible ... > > it depends on the spec of a translation. plainly, you cant keep all the semantic distinctions of TEI in Docbook. > and there are all the things we can mark up in TEI which simply have no presentation corollary. If you could do a perfect conversion from any source document with XML schema X to a completely different schema Y, then format X would arguably be completely redundant. Cheers, Martin -- Martin Holmes University of Victoria Humanities Computing and Media Centre (mholmes at uvic.ca) From sebastian.rahtz at oucs.ox.ac.uk Thu Sep 2 04:23:03 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Thu, 2 Sep 2010 09:23:03 +0100 Subject: [tei-council] TEI for publishing: archival or interchange format? (was Re: What's next on the TEI publishing thread) In-Reply-To: <4C7EDB66.2010806@uvic.ca> References: <02E66734-4A58-4B86-8321-CB2D090BEB5F@inria.fr> <396CD713-64FE-4267-B6FA-6A1079F21869@oucs.ox.ac.uk> <EC0A1AE2-4A16-4841-A69C-CD7D5B96D079@inria.fr> <1C65C59D-E4A9-499B-B55F-DB05258FB8AD@oucs.ox.ac.uk> <684223F4-931E-46C5-8F75-CA9D1794E1ED@inria.fr> <4C7D667C.5060503@ultraslavonic.info> <90D6C305-1364-444E-8F84-0C7B5C4C7C8E@oucs.ox.ac.uk> <4C7EA0B7.5090502@ultraslavonic.info> <4C7EA311.4000509@uleth.ca> <C87BED0B-0C6F-433E-85B4-98CEFF60B20C@oucs.ox.ac.uk> <4C7ED53F.5090704@oucs.ox.ac.uk> <279008DD-14C8-40D2-8154-34A1F6CEF093@oucs.ox.ac.uk> <4C7EDB66.2010806@uvic.ca> Message-ID: <29728272-FB73-47B0-8BBD-2ED477A3C7AB@oucs.ox.ac.uk> On 2 Sep 2010, at 00:01, Martin Holmes wrote: > > If you could do a perfect conversion from any source document with XML > schema X to a completely different schema Y, then format X would > arguably be completely redundant. > arguably all our schemas are made redundant by RDF?.. -- Sebastian Rahtz (acting) Information and Support Group Manager Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From sebastian.rahtz at oucs.ox.ac.uk Mon Sep 6 14:21:47 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 6 Sep 2010 19:21:47 +0100 Subject: [tei-council] Fwd: References to OpenMath in the TEI P5 Guidelines In-Reply-To: <EAB24D4F-3F4F-4C0B-990E-1DB31A699FC9@inria.fr> References: <4C73F2E4.9080608@jacobs-university.de> <EAB24D4F-3F4F-4C0B-990E-1DB31A699FC9@inria.fr> Message-ID: <AE6F3A37-3463-4B8A-8931-24A174505BA9@oucs.ox.ac.uk> >> De : Michael Kohlhase <m.kohlhase at jacobs-university.de> >> Date : 24 ao?t 2010 18:27:16 GMT+02:00 >> >> I have recently become aware that the TEI Guidelines (P5) mention >> OpenMath in chapter 14 [http://www.tei-c.org/release/doc/tei-p5-doc/en/html/FT.html#FTFOR >> ]. Unfortunately, most of the references are outdated (see below), I have implemented these changes in the TEI source. They will appear in the next TEI release, due at the start of November. -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From laurent.romary at inria.fr Wed Sep 8 09:40:19 2010 From: laurent.romary at inria.fr (Laurent Romary) Date: Wed, 8 Sep 2010 15:40:19 +0200 Subject: [tei-council] Tite - maintenance scheme Message-ID: <18BA88BD-16C6-4293-8ED6-80A4F985BA61@inria.fr> Council, After several iteration of consultations, we do have a maintenance scheme for Tite that should lead to an alignment of Tite as maintained by the council and the schema used for the AccessTEI program. This scheme is articulated around a task force made of: - Kevin Hawkins, for the council - Perry Trolard, for the AccessTEI project (Mellon Foundation grant) - Greg Suprock, for Apex, to ensure that we do not break Apex workflow/ processes in their implementation of the AccessTEI program. The duty of the group is: - realign Tite at Apex with Tite at TEI by filing in changes already implemented in TIte at Apex into TEI at SourceForge - filing in evolution proposals to Tite at TEI and ensuring with Apex that they could live with these proposals as basis for the AccessTEI program At the end of the day, I would like to see one single Tite lineage, i.e. Tite at TEI. [@Greg: you should have an account on http://tei.sourceforge.net/ so that you can comment on tickets] [@Oxford, could we have a specific Tite category? which automatically send a message to Kevin, Perry and Greg?] Unless there is a strong voice against this. I would like this to be implemented at once. Laurent Romary INRIA & HUB-IDSL laurent.romary at inria.fr From sebastian.rahtz at oucs.ox.ac.uk Wed Sep 8 10:08:23 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Wed, 8 Sep 2010 15:08:23 +0100 Subject: [tei-council] Tite - maintenance scheme In-Reply-To: <18BA88BD-16C6-4293-8ED6-80A4F985BA61@inria.fr> References: <18BA88BD-16C6-4293-8ED6-80A4F985BA61@inria.fr> Message-ID: <DF890F48-FB82-4C7B-BCE2-15776E91F3B8@oucs.ox.ac.uk> > > [@Greg: you should have an account on http://tei.sourceforge.net/ so > that you can comment on tickets] I need to know the user name so that I can add permissions > [@Oxford, could we have a specific Tite category? I have added "Tite" to Bugs and to Feature Requests > which automatically > send a message to Kevin, Perry and Greg?] not so sure about that. need to look at SF some more and work out how -- Sebastian Rahtz (acting) Information and Support Group Manager Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From kevin.s.hawkins at ultraslavonic.info Wed Sep 8 13:29:05 2010 From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins) Date: Wed, 08 Sep 2010 13:29:05 -0400 Subject: [tei-council] Tite - maintenance scheme In-Reply-To: <DF890F48-FB82-4C7B-BCE2-15776E91F3B8@oucs.ox.ac.uk> References: <18BA88BD-16C6-4293-8ED6-80A4F985BA61@inria.fr> <DF890F48-FB82-4C7B-BCE2-15776E91F3B8@oucs.ox.ac.uk> Message-ID: <4C87C7E1.7010401@ultraslavonic.info> On 9/8/2010 10:08 AM, Sebastian Rahtz wrote: >> [@Oxford, could we have a specific Tite category? > I have added "Tite" to Bugs and to Feature Requests ... and I have recategorized open bug reports and feature requests relating to Tite into this new category. On 9/8/2010 9:40 AM, Laurent Romary wrote: > The duty of the group is: > - realign Tite at Apex with Tite at TEI by filing in changes already > implemented in TIte at Apex into TEI at SourceForge > - filing in evolution proposals to Tite at TEI and ensuring with Apex > that they could live with these proposals as basis for the AccessTEI > program > At the end of the day, I would like to see one single Tite lineage, > i.e. Tite at TEI. I understand that many months ago Apex provided to Dan and/or Perry, which they have been reviewing these and were supposed to present to Council as a revised ODD. Could someone provide me with a copy of these proposed revisions and then Perry and/or I can filter these into SourceForge as individual tickets? I am quite keen to move this along -- not only because I have been expecting these proposed revisions for months but also because I am now receiving content back from AccessTEI and am trying to convince Apex to change some of their AccessTEI encoding practices. Kevin From lou.burnard at oucs.ox.ac.uk Mon Sep 13 13:43:13 2010 From: lou.burnard at oucs.ox.ac.uk (Lou) Date: Mon, 13 Sep 2010 18:43:13 +0100 Subject: [tei-council] Vote early for ticket tidyup (part 1) Message-ID: <4C8E62B1.3030605@oucs.ox.ac.uk> In a unexpected access of zeal, I have been looking through long outstanding feature requests on sourceforge. Where possible, I have added a comment stating what I propose as a resolution (or not) of the issue discussed. The comment begins with the words "Proposal is..." Could Council members please take a look at these tickets as soon as possible, and VOTE as to whether they agree with the proposed resolution? You can vote by editing and then returning the following ballot paper, replacing the ellipsis with one of AGREE DISAGREE or DUNNO Where the AGREEs are in the majority, I will then carry out the proposed change and close the ticket. If the DISAGREE votes are in the majority, I won't. If the DUNNO votes are in the majority, we will have to discuss the item at our ftf, sigh, so please don't vote DUNNO unless you have to. Also note that if you vote DISAGREE, you are morally obliged to explain why, and preferably propose a better course of action (as an extra comment on the ticket). ------------------------------------------------ POLLING CLOSES AT MIDNIGHT ON 19 SEPT 2010 ------------------------------------------------ 2994666 Change idno content model to macro.xText .... 2859183 Make all milestoneLike elements spanning .... 2834871 Close ticket: will not fix .... 2859355 Permit macro.xText within <subst> .... 2984463 Add new class att.sortable .... 2994740 Add new milestoneLike element <gb> .... 2994671 Review suggested values for @calendar .... 3019781 Close ticket: text clarified ok .... Gosh is that the time. Part two of this list will come in a separate message, but you can start voting NOW! From lou.burnard at oucs.ox.ac.uk Mon Sep 13 17:58:02 2010 From: lou.burnard at oucs.ox.ac.uk (Lou Burnard) Date: Mon, 13 Sep 2010 22:58:02 +0100 Subject: [tei-council] and the remainder of the voting slip... Message-ID: <4C8E9E6A.7010206@oucs.ox.ac.uk> Actually, it turns out there are only a few more tickets where I think I have a concrete proposal to put to the vote. Here they are: ------------------------------------------------ POLLING CLOSES AT MIDNIGHT ON 19 SEPT 2010 ------------------------------------------------ 3044329 add @licence attribute to <availability> ... 3046288 modify content model of <f> to permit text ... 3054295 change content models of origDate and origPlace ... 3064014 add suggested values from known source for rs at type ... Get your votes in early, as we still have a fair few more complex issues to debate. I hope to post summaries of those in the next few days. The goal is to be able to crank out a nice new pre-release with as many as possible old gripes resolved in time for the Members' Meeting in November. From sebastian.rahtz at oucs.ox.ac.uk Mon Sep 13 17:58:42 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 13 Sep 2010 22:58:42 +0100 Subject: [tei-council] Vote early for ticket tidyup (part 1) In-Reply-To: <4C8E62B1.3030605@oucs.ox.ac.uk> References: <4C8E62B1.3030605@oucs.ox.ac.uk> Message-ID: <FD41C9CB-D8E9-46F9-BE61-F461FC27E6FC@oucs.ox.ac.uk> > 2994666 Change idno content model to macro.xText DISAGREE. cf Syd's analysis. keep it just rng:text. > 2859183 Make all milestoneLike elements spanning AGREE. > 2834871 Close ticket: will not fix AGREE. Wait for future generatiobs > 2859355 Permit macro.xText within <subst> DUNNO. feel unqualified. let greater minds decide > 2984463 Add new class att.sortable DISAGREE. We have the needed on author > 2994740 Add new milestoneLike element <gb> AGREE. > 2994671 Review suggested values for @calendar DISAGREE. ticket should remain open and JC asked to provide examples of what to point to > 3019781 Close ticket: text clarified ok .AGREE -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From sebastian.rahtz at oucs.ox.ac.uk Mon Sep 13 18:05:28 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 13 Sep 2010 23:05:28 +0100 Subject: [tei-council] and the remainder of the voting slip... In-Reply-To: <4C8E9E6A.7010206@oucs.ox.ac.uk> References: <4C8E9E6A.7010206@oucs.ox.ac.uk> Message-ID: <17B96283-EFEE-4109-8678-0C94AC66C19F@oucs.ox.ac.uk> On 13 Sep 2010, at 22:58, Lou Burnard wrote: > > 3044329 add @licence attribute to <availability> DISAGREE. see comment. premature > 3046288 modify content model of <f> to permit text .DISAGREE. see comment. premature. > 3054295 change content models of origDate and origPlace ... > 3064014 add suggested values from known source for rs at type ... > > Get your votes in early, as we still have a fair few more complex issues > to debate. I hope to post summaries of those in the next few days. The > goal is to be able to crank out a nice new pre-release with as many as > possible old gripes resolved in time for the Members' Meeting in November. > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From sebastian.rahtz at oucs.ox.ac.uk Mon Sep 13 18:08:06 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 13 Sep 2010 23:08:06 +0100 Subject: [tei-council] and the remainder of the voting slip... In-Reply-To: <17B96283-EFEE-4109-8678-0C94AC66C19F@oucs.ox.ac.uk> References: <4C8E9E6A.7010206@oucs.ox.ac.uk> <17B96283-EFEE-4109-8678-0C94AC66C19F@oucs.ox.ac.uk> Message-ID: <0D44E86D-927D-4681-BB7C-DF7AA67DCC26@oucs.ox.ac.uk> sorry, didnt finish >> 3044329 add @licence attribute to <availability> DISAGREE. see comment. premature >> 3046288 modify content model of <f> to permit text .DISAGREE. see comment. premature. >> 3054295 change content models of origDate and origPlace .AGREE >> 3064014 add suggested values from known source for rs at type AGREE -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From laurent.romary at inria.fr Tue Sep 14 04:22:45 2010 From: laurent.romary at inria.fr (Laurent Romary) Date: Tue, 14 Sep 2010 10:22:45 +0200 Subject: [tei-council] Vote early for ticket tidyup (part 1) In-Reply-To: <4C8E62B1.3030605@oucs.ox.ac.uk> References: <4C8E62B1.3030605@oucs.ox.ac.uk> Message-ID: <F3E35B1B-D134-4240-83D8-A3C212708F26@inria.fr> Le 13 sept. 10 ? 19:43, Lou a ?crit : > > ------------------------------------------------ > POLLING CLOSES AT MIDNIGHT ON 19 SEPT 2010 > ------------------------------------------------ > > 2994666 Change idno content model to macro.xText .... AGREE, cf. Kevin's comment. Even a wider content model (with words of cautiousness in the documentation) > 2859183 Make all milestoneLike elements spanning .... AGREE > 2834871 Close ticket: will not fix .... OK. But ODD is likely to come back as a topic for our next FTF > 2859355 Permit macro.xText within <subst> .... AGREE > 2984463 Add new class att.sortable .... AGREE > 2994740 Add new milestoneLike element <gb> .... AGREE > 2994671 Review suggested values for @calendar .... Follow Seb's comments here ==> James > 3019781 Close ticket: text clarified ok .... AGREE > > Gosh is that the time. Part two of this list will come in a separate > message, but you can start voting NOW! > > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Laurent Romary INRIA & HUB-IDSL laurent.romary at inria.fr From laurent.romary at inria.fr Tue Sep 14 04:34:29 2010 From: laurent.romary at inria.fr (Laurent Romary) Date: Tue, 14 Sep 2010 10:34:29 +0200 Subject: [tei-council] and the remainder of the voting slip... In-Reply-To: <4C8E9E6A.7010206@oucs.ox.ac.uk> References: <4C8E9E6A.7010206@oucs.ox.ac.uk> Message-ID: <6A94AA59-734B-4F7F-8630-070B2A0E1DA2@inria.fr> Le 13 sept. 10 ? 23:58, Lou Burnard a ?crit : > > ------------------------------------------------ > POLLING CLOSES AT MIDNIGHT ON 19 SEPT 2010 > ------------------------------------------------ > > 3044329 add @licence attribute to <availability> ... DISAGREE (agree with Seb): I don't feel at ease with such a partial answer to a more complex issue. > 3046288 modify content model of <f> to permit text ... AGREE > 3054295 change content models of origDate and origPlace ... AGREE > 3064014 add suggested values from known source for rs at type ... AGREE > > Get your votes in early, as we still have a fair few more complex > issues > to debate. I hope to post summaries of those in the next few days. The > goal is to be able to crank out a nice new pre-release with as many as > possible old gripes resolved in time for the Members' Meeting in > November. > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Laurent Romary INRIA & HUB-IDSL laurent.romary at inria.fr From elena.pierazzo at kcl.ac.uk Tue Sep 14 05:08:16 2010 From: elena.pierazzo at kcl.ac.uk (Elena Pierazzo) Date: Tue, 14 Sep 2010 10:08:16 +0100 Subject: [tei-council] Vote early for ticket tidyup (part 1) In-Reply-To: <4C8E62B1.3030605@oucs.ox.ac.uk> References: <4C8E62B1.3030605@oucs.ox.ac.uk> Message-ID: <51848075-DD95-493B-9B3A-63C6113069B4@kcl.ac.uk> Hi all, here are my opinions. Others later Ciao > ------------------------------------------------ > POLLING CLOSES AT MIDNIGHT ON 19 SEPT 2010 > ------------------------------------------------ > > 2994666 Change idno content model to macro.xText AGREE > 2859183 Make all milestoneLike elements spanning AGREE > 2834871 Close ticket: will not fix A BIT CONCERNED, > BUT AGREE > 2859355 Permit macro.xText within <subst> AGREE AGREE AGREE > 2984463 Add new class att.sortable DUNNO > 2994740 Add new milestoneLike element <gb> AGREE > 2994671 Review suggested values for @calendar AGREE > 3019781 Close ticket: text clarified ok AGREE > > Gosh is that the time. Part two of this list will come in a separate > message, but you can start voting NOW! > > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council -- Dr Elena Pierazzo Research Associate Centre for Computing in the Humanities King's College London 26-29 Drury Lane London WC2B 5RL Phone: 0207-848-1949 Fax: 0207-848-2980 elena.pierazzo at kcl.ac.uk www.kcl.ac.uk From elena.pierazzo at kcl.ac.uk Tue Sep 14 06:25:07 2010 From: elena.pierazzo at kcl.ac.uk (Elena Pierazzo) Date: Tue, 14 Sep 2010 11:25:07 +0100 Subject: [tei-council] and the remainder of the voting slip... In-Reply-To: <4C8E9E6A.7010206@oucs.ox.ac.uk> References: <4C8E9E6A.7010206@oucs.ox.ac.uk> Message-ID: <3FDB13BF-4119-413E-9E56-FF0704DCF951@kcl.ac.uk> Second helping > > ------------------------------------------------ > POLLING CLOSES AT MIDNIGHT ON 19 SEPT 2010 > ------------------------------------------------ > > 3044329 add @licence attribute to <availability> DUNNO, I > think Kevin remarks is quite sensible. > 3046288 modify content model of <f> to permit text DUNNO > 3054295 change content models of origDate and origPlace AGREE > 3064014 add suggested values from known source for rs at type DUNNO, I > think the <rs> element is willingly a generic one and therefore > difficult to narrow down with values... -- Dr Elena Pierazzo Research Associate Centre for Computing in the Humanities King's College London 26-29 Drury Lane London WC2B 5RL Phone: 0207-848-1949 Fax: 0207-848-2980 elena.pierazzo at kcl.ac.uk www.kcl.ac.uk From lou.burnard at oucs.ox.ac.uk Tue Sep 14 06:33:41 2010 From: lou.burnard at oucs.ox.ac.uk (Lou) Date: Tue, 14 Sep 2010 11:33:41 +0100 Subject: [tei-council] wait there's (a few) more Message-ID: <4C8F4F85.2030109@oucs.ox.ac.uk> I just went through the items on the Bugs tracker and found three new more items which seem to have clear proposals for closure for council members to vote on. 2900430 Add new scriptNote, scriptDesc, @scriptRef @scribeRef ... 2987241 Revise wording of discussion bibl/biblStruct ... 3058674 Add model.graphicLike to content of glyph ... I promise not to find any more. All that's left are items which require more discussion... Thanks very much for speedy vote casting -- this all makes the editorial drudgery much easier! From James.Cummings at oucs.ox.ac.uk Tue Sep 14 06:44:31 2010 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Tue, 14 Sep 2010 11:44:31 +0100 Subject: [tei-council] Vote early for ticket tidyup (part 1) In-Reply-To: <4C8E62B1.3030605@oucs.ox.ac.uk> References: <4C8E62B1.3030605@oucs.ox.ac.uk> Message-ID: <4C8F520F.6020107@oucs.ox.ac.uk> Not sure if it is appropriate to vote on request tickets I submitted but here goes: > 2994666 Change idno content model to macro.xText AGREE: good enough for now, adding <desc> is another FR. (but my ticket) > 2859183 Make all milestoneLike elements spanning .... AGREE > 2834871 Close ticket: will not fix .... Reluctantly AGREE: I think it is still an important idea and TEI should encourage someone to build it, but TEI has now created the possibility of doing so, before it was literally impossible. TEI should encourage good practice of @source usually pointing to that vault release of TEI so as to avoid unwanted additions in later schema generation. (but again, my ticket). > 2859355 Permit macro.xText within <subst> AGREE with macro.xtext, reservations about schematron rule. > 2984463 Add new class att.sortable AGREE > 2994740 Add new milestoneLike element <gb> AGREE: but think current milestone element works as well. > 2994671 Review suggested values for @calendar .... DISAGREE: Using the W3C suggested values is a good fallback, which I would agree with and must be done, but if and only if we don't change it to be a pointer which allows much more scope for documenting values not recognised by the W3C like medieval Iranian Jalali or the fantastical Star Trek 'stardate' calendar. See comment on ticket. (But again, my ticket). > 3019781 Close ticket: text clarified ok .... AGREE. > 3044329 add @licence attribute to <availability> ... AGREE > 3046288 modify content model of <f> to permit text AGREE > 3054295 change content models of origDate and origPlace ... AGREE > 3064014 add suggested values from known source for rs at type AGREE Also added comments to some tickets with further details. -James -- Dr James Cummings, Research Technologies Service OUCS, University of Oxford From sebastian.rahtz at oucs.ox.ac.uk Tue Sep 14 06:47:08 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 14 Sep 2010 11:47:08 +0100 Subject: [tei-council] Vote early for ticket tidyup (part 1) In-Reply-To: <4C8F520F.6020107@oucs.ox.ac.uk> References: <4C8E62B1.3030605@oucs.ox.ac.uk> <4C8F520F.6020107@oucs.ox.ac.uk> Message-ID: <6E306F2F-43AF-4E40-B472-C59EFAA78271@oucs.ox.ac.uk> On 14 Sep 2010, at 11:44, James Cummings wrote: > >> 2834871 Close ticket: will not fix .... > Reluctantly AGREE: I think it is still an important idea and TEI > should encourage someone to build it I agree it would be amusing and useful to some, but its purely a tool exercise, and I think discussion of new tools we might need is a very distinct exercise. -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From James.Cummings at oucs.ox.ac.uk Tue Sep 14 06:50:02 2010 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Tue, 14 Sep 2010 11:50:02 +0100 Subject: [tei-council] wait there's (a few) more In-Reply-To: <4C8F4F85.2030109@oucs.ox.ac.uk> References: <4C8F4F85.2030109@oucs.ox.ac.uk> Message-ID: <4C8F535A.3060604@oucs.ox.ac.uk> Lou wrote: > I just went through the items on the Bugs tracker and found three new > more items which seem to have clear proposals for closure for council > members to vote on. > > 2900430 Add new scriptNote, scriptDesc, @scriptRef @scribeRef AGREE: But unsure about whether 'writingDesc' would be better. > 2987241 Revise wording of discussion bibl/biblStruct ... AGREE: Just clarification so seems reasonable. > 3058674 Add model.graphicLike to content of glyph ... AGREE: but I pointed out the bug. -J -- Dr James Cummings, Research Technologies Service OUCS, University of Oxford From James.Cummings at oucs.ox.ac.uk Tue Sep 14 06:52:52 2010 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Tue, 14 Sep 2010 11:52:52 +0100 Subject: [tei-council] Vote early for ticket tidyup (part 1) In-Reply-To: <6E306F2F-43AF-4E40-B472-C59EFAA78271@oucs.ox.ac.uk> References: <4C8E62B1.3030605@oucs.ox.ac.uk> <4C8F520F.6020107@oucs.ox.ac.uk> <6E306F2F-43AF-4E40-B472-C59EFAA78271@oucs.ox.ac.uk> Message-ID: <4C8F5404.60803@oucs.ox.ac.uk> Sebastian Rahtz wrote: > I agree it would be amusing and useful to some, but its purely a tool exercise, > and I think discussion of new tools we might need is > a very distinct exercise. Agreed. I think the TEI has some wonderful tools, but some of them (e.g. web Roma) are static in the face of the continual development of the TEI. Either the community needs to start providing such tools or the TEI-C needs to decide if it will fund the creation/maintenance of such tools I guess. But an entirely separate discussion from that ticket. -James -- Dr James Cummings, Research Technologies Service OUCS, University of Oxford From sebastian.rahtz at oucs.ox.ac.uk Tue Sep 14 07:04:15 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 14 Sep 2010 12:04:15 +0100 Subject: [tei-council] Vote early for ticket tidyup (part 1) In-Reply-To: <4C8F5404.60803@oucs.ox.ac.uk> References: <4C8E62B1.3030605@oucs.ox.ac.uk> <4C8F520F.6020107@oucs.ox.ac.uk> <6E306F2F-43AF-4E40-B472-C59EFAA78271@oucs.ox.ac.uk> <4C8F5404.60803@oucs.ox.ac.uk> Message-ID: <CC3FBC72-1B13-459A-A948-8F3DF8855008@oucs.ox.ac.uk> On 14 Sep 2010, at 11:52, James Cummings wrote: > > Agreed. I think the TEI has some wonderful tools, but some of > them (e.g. web Roma) are static in the face of the continual > development of the TEI. unfair. Web Roma has had many developments, and will get more. It just does not develop as as fast as you might like. -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From elena.pierazzo at kcl.ac.uk Tue Sep 14 07:05:45 2010 From: elena.pierazzo at kcl.ac.uk (Elena Pierazzo) Date: Tue, 14 Sep 2010 12:05:45 +0100 Subject: [tei-council] wait there's (a few) more In-Reply-To: <4C8F4F85.2030109@oucs.ox.ac.uk> References: <4C8F4F85.2030109@oucs.ox.ac.uk> Message-ID: <A3813FC7-22AC-4DE4-B0F2-22A08693C5E7@kcl.ac.uk> > > 2900430 Add new scriptNote, scriptDesc, @scriptRef @scribeRef > AGREE. Disagree on writingDesc, they are very different things and > should be kept separate IMHO > 2987241 Revise wording of discussion bibl/biblStruct can't find it > on SourceForge... > 3058674 Add model.graphicLike to content of glyph DITTO -- Dr Elena Pierazzo Research Associate Centre for Computing in the Humanities King's College London 26-29 Drury Lane London WC2B 5RL Phone: 0207-848-1949 Fax: 0207-848-2980 elena.pierazzo at kcl.ac.uk www.kcl.ac.uk From sebastian.rahtz at oucs.ox.ac.uk Tue Sep 14 07:14:01 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 14 Sep 2010 12:14:01 +0100 Subject: [tei-council] wait there's (a few) more In-Reply-To: <4C8F4F85.2030109@oucs.ox.ac.uk> References: <4C8F4F85.2030109@oucs.ox.ac.uk> Message-ID: <E3D7C414-EFC3-4C96-98CE-950D7DF483DF@oucs.ox.ac.uk> On 14 Sep 2010, at 11:33, Lou wrote: > 2900430 Add new scriptNote, scriptDesc, @scriptRef @scribeRef ... the top proposal seems contradictory. is it just 4)? in which case sounds right. AGREE > 2987241 Revise wording of discussion bibl/biblStruct ... AGREE, depending on what the wording is :-} > 3058674 Add model.graphicLike to content of glyph ... make <glyph> a member of model.graphicLike? makes me nervous. what on earth would it mean in the text body? DISAGREE -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From sebastian.rahtz at oucs.ox.ac.uk Tue Sep 14 07:39:38 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 14 Sep 2010 12:39:38 +0100 Subject: [tei-council] wait there's (a few) more In-Reply-To: <4C8F5D74.9080705@oucs.ox.ac.uk> References: <4C8F4F85.2030109@oucs.ox.ac.uk> <E3D7C414-EFC3-4C96-98CE-950D7DF483DF@oucs.ox.ac.uk> <4C8F5D74.9080705@oucs.ox.ac.uk> Message-ID: <1BCF5D5F-EC71-4982-B7AA-9653AAD52071@oucs.ox.ac.uk> On 14 Sep 2010, at 12:33, Lou wrote: > Sebastian Rahtz wrote: > >> >>> 3058674 Add model.graphicLike to content of glyph ... >> make <glyph> a member of model.graphicLike? makes me nervous. >> what on earth would it mean in the text body? DISAGREE >> oh all right, since its been pointed out that I read the words in the ticket in entirely the wrong order, I change to AGREE -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From James.Cummings at oucs.ox.ac.uk Tue Sep 14 07:40:26 2010 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Tue, 14 Sep 2010 12:40:26 +0100 Subject: [tei-council] Vote early for ticket tidyup (part 1) In-Reply-To: <CC3FBC72-1B13-459A-A948-8F3DF8855008@oucs.ox.ac.uk> References: <4C8E62B1.3030605@oucs.ox.ac.uk> <4C8F520F.6020107@oucs.ox.ac.uk> <6E306F2F-43AF-4E40-B472-C59EFAA78271@oucs.ox.ac.uk> <4C8F5404.60803@oucs.ox.ac.uk> <CC3FBC72-1B13-459A-A948-8F3DF8855008@oucs.ox.ac.uk> Message-ID: <4C8F5F2A.90601@oucs.ox.ac.uk> Sebastian Rahtz wrote: > On 14 Sep 2010, at 11:52, James Cummings wrote: >> Agreed. I think the TEI has some wonderful tools, but some of >> them (e.g. web Roma) are static in the face of the continual >> development of the TEI. > > unfair. Web Roma has had many developments, and will get > more. It just does not develop as as fast as you might like. Hrmm I wasn't picking on Web Roma in a negative way... I just don't think development of it or anything as crucial should be done in a piecemeal un-resourced manner.TEI-C seems to believe it isn't in the job of producing software but then so much of the infrastructure of it is built on software (mostly thanks to you) which I believe not supporting is detrimental to the TEI overall. I'd prefer it if the TEI-C decided that X, Y, and Z were important enough to fund and then just did so. Or am I deluded here and is TEI-C already funding the development of Roma and Stylesheets, etc? -james -- Dr James Cummings, Research Technologies Service OUCS, University of Oxford From sebastian.rahtz at oucs.ox.ac.uk Tue Sep 14 07:41:40 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 14 Sep 2010 12:41:40 +0100 Subject: [tei-council] tei legal trouble? Message-ID: <8B3BF808-A78C-4F4D-8413-95C6F1257D2B@oucs.ox.ac.uk> When I read "EU may take legal action against France over Roma" on the BBC web site, I got excited for a moment..... -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From James.Cummings at oucs.ox.ac.uk Tue Sep 14 07:45:03 2010 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Tue, 14 Sep 2010 12:45:03 +0100 Subject: [tei-council] wait there's (a few) more In-Reply-To: <E3D7C414-EFC3-4C96-98CE-950D7DF483DF@oucs.ox.ac.uk> References: <4C8F4F85.2030109@oucs.ox.ac.uk> <E3D7C414-EFC3-4C96-98CE-950D7DF483DF@oucs.ox.ac.uk> Message-ID: <4C8F603F.9070404@oucs.ox.ac.uk> Sebastian Rahtz wrote: >> 3058674 Add model.graphicLike to content of glyph ... > make <glyph> a member of model.graphicLike? makes me nervous. > what on earth would it mean in the text body? DISAGREE Could I point out that <char> and <glyph> both had <graphic> before and it was erroneously removed before and substituted with <figure>? I then suggested that we return it to <char> because I had noticed it was removed from there and we have now already done so. It was simply me neglecting to notice it had also been removed from <glyph>. We are not suggesting that <glyph> becomes a member of model.graphicLike but that <glyph>'s content allow model.graphicLike. If you disagree with this you really need to explain why <char> should be allowed to have <graphic> elements in it but <glyph> should not be allowed to. I think you are misunderstanding the ticket. -James -- Dr James Cummings, Research Technologies Service OUCS, University of Oxford From James.Cummings at oucs.ox.ac.uk Tue Sep 14 07:45:34 2010 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Tue, 14 Sep 2010 12:45:34 +0100 Subject: [tei-council] wait there's (a few) more In-Reply-To: <1BCF5D5F-EC71-4982-B7AA-9653AAD52071@oucs.ox.ac.uk> References: <4C8F4F85.2030109@oucs.ox.ac.uk> <E3D7C414-EFC3-4C96-98CE-950D7DF483DF@oucs.ox.ac.uk> <4C8F5D74.9080705@oucs.ox.ac.uk> <1BCF5D5F-EC71-4982-B7AA-9653AAD52071@oucs.ox.ac.uk> Message-ID: <4C8F605E.1080504@oucs.ox.ac.uk> Sebastian Rahtz wrote: > On 14 Sep 2010, at 12:33, Lou wrote: > >> Sebastian Rahtz wrote: >> >>>> 3058674 Add model.graphicLike to content of glyph ... >>> make <glyph> a member of model.graphicLike? makes me nervous. >>> what on earth would it mean in the text body? DISAGREE > oh all right, since its been pointed out that I read the words in the ticket > in entirely the wrong order, I change to AGREE oops, ignore latest post then. ;-) -J -- Dr James Cummings, Research Technologies Service OUCS, University of Oxford From laurent.romary at inria.fr Tue Sep 14 07:52:44 2010 From: laurent.romary at inria.fr (Laurent Romary) Date: Tue, 14 Sep 2010 13:52:44 +0200 Subject: [tei-council] tei legal trouble? In-Reply-To: <8B3BF808-A78C-4F4D-8413-95C6F1257D2B@oucs.ox.ac.uk> References: <8B3BF808-A78C-4F4D-8413-95C6F1257D2B@oucs.ox.ac.uk> Message-ID: <BDD61533-A3D1-487C-A932-722AC6123B16@inria.fr> The French representative in the council abstain to comment... Le 14 sept. 10 ? 13:41, Sebastian Rahtz a ?crit : > When I read "EU may take legal action against France over Roma" on > the BBC web site, I got excited for a moment..... > -- > Sebastian Rahtz > Information Manager, Oxford University Computing Services > 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 > > S?lo le pido a Dios > que el futuro no me sea indiferente > > > > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Laurent Romary INRIA & HUB-IDSL laurent.romary at inria.fr From sebastian.rahtz at oucs.ox.ac.uk Tue Sep 14 08:40:46 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 14 Sep 2010 13:40:46 +0100 Subject: [tei-council] Vote early for ticket tidyup (part 1) In-Reply-To: <4C8F5F2A.90601@oucs.ox.ac.uk> References: <4C8E62B1.3030605@oucs.ox.ac.uk> <4C8F520F.6020107@oucs.ox.ac.uk> <6E306F2F-43AF-4E40-B472-C59EFAA78271@oucs.ox.ac.uk> <4C8F5404.60803@oucs.ox.ac.uk> <CC3FBC72-1B13-459A-A948-8F3DF8855008@oucs.ox.ac.uk> <4C8F5F2A.90601@oucs.ox.ac.uk> Message-ID: <342BAF68-C164-43CA-A15E-BB13BFB0E0C6@oucs.ox.ac.uk> On 14 Sep 2010, at 12:40, James Cummings wrote: > done in a piecemeal un-resourced manner.TEI-C seems to believe it > isn't in the job of producing software but then so much of the > infrastructure of it is built on software there's three sorts of software involved a) what the TEI needs to create its deliverables. so we MUST have an ODD processor to create stuff the P5 source. b) what the TEI provides to help you use the Gidlines better or at all, ie Roma c) tools that many TEIers like, but don't all need or agree on. eg Martin's lovely image tool between b) and c) are things like my TEI --> ePub, which are nice if you want them, but not essential; but which share an infrastructure with the ODD tools in a) > Or am I deluded > here and is TEI-C already funding the development of Roma and > Stylesheets, etc? > yes, it is. The editorial project is supposed to make sure the basic ODD tools work, and the Oxford Host contribution is stylesheet and similar tool maintenance. I don't say its satisfactory but its a start. The council can and should keep a closer eye on all this, and have a better strategic plan, I would suggest -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From laurent.romary at inria.fr Tue Sep 14 08:55:02 2010 From: laurent.romary at inria.fr (Laurent Romary) Date: Tue, 14 Sep 2010 14:55:02 +0200 Subject: [tei-council] Tools (was: Ticket stuff) In-Reply-To: <342BAF68-C164-43CA-A15E-BB13BFB0E0C6@oucs.ox.ac.uk> References: <4C8E62B1.3030605@oucs.ox.ac.uk> <4C8F520F.6020107@oucs.ox.ac.uk> <6E306F2F-43AF-4E40-B472-C59EFAA78271@oucs.ox.ac.uk> <4C8F5404.60803@oucs.ox.ac.uk> <CC3FBC72-1B13-459A-A948-8F3DF8855008@oucs.ox.ac.uk> <4C8F5F2A.90601@oucs.ox.ac.uk> <342BAF68-C164-43CA-A15E-BB13BFB0E0C6@oucs.ox.ac.uk> Message-ID: <0FF9A483-CC48-480B-A819-B813F77DA4AF@inria.fr> That would be an excellent topic for a prospective meeting... I wish the consortium would have the budget. Le 14 sept. 10 ? 14:40, Sebastian Rahtz a ?crit : > I don't say its satisfactory but its a start. The council can and > should > keep a closer eye on all this, and have a better strategic plan, I > would suggest Laurent Romary INRIA & HUB-IDSL laurent.romary at inria.fr From laurent.romary at inria.fr Tue Sep 14 09:01:49 2010 From: laurent.romary at inria.fr (Laurent Romary) Date: Tue, 14 Sep 2010 15:01:49 +0200 Subject: [tei-council] wait there's (a few) more In-Reply-To: <4C8F4F85.2030109@oucs.ox.ac.uk> References: <4C8F4F85.2030109@oucs.ox.ac.uk> Message-ID: <44D72BE5-FEAE-414F-9FA0-A5E958767CC7@inria.fr> Le 14 sept. 10 ? 12:33, Lou a ?crit : > I just went through the items on the Bugs tracker and found three new > more items which seem to have clear proposals for closure for council > members to vote on. > > 2900430 Add new scriptNote, scriptDesc, @scriptRef @scribeRef ... Intuitively AGREE, but would rely on people Elena for a refined analysis > 2987241 Revise wording of discussion bibl/biblStruct ... AGREE. I would not take up analytic and monogr bluntly in bibl. Makes no sense > 3058674 Add model.graphicLike to content of glyph ... Can you update the ticket so that I understand the discussion between you and James? > > I promise not to find any more. All that's left are items which > require > more discussion... > > Thanks very much for speedy vote casting -- this all makes the > editorial > drudgery much easier! > > > > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Laurent Romary INRIA & HUB-IDSL laurent.romary at inria.fr From James.Cummings at oucs.ox.ac.uk Tue Sep 14 09:47:00 2010 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Tue, 14 Sep 2010 14:47:00 +0100 Subject: [tei-council] TEI Canonical URIs and DOIs Message-ID: <4C8F7CD4.9070608@oucs.ox.ac.uk> I've just closed: https://sourceforge.net/tracker/index.php?func=detail&aid=2411994&group_id=106328&atid=644065 which was arguing for the TEI adopting a DOI solution to providing canonical URIs. I believe we now provide canonical URIs for source and guidelines as my last comment on that ticket shows. However, providing canonical URIs is indeed different than providing DOIs. I have a recollection that the council discussed this at some point but not what the conclusion was. If additional comments are added to the ticket, obviously, I'll reopen it. Just trying to tidy up, -James -- Dr James Cummings, Research Technologies Service OUCS, University of Oxford From dsewell at virginia.edu Tue Sep 14 09:51:21 2010 From: dsewell at virginia.edu (David Sewell) Date: Tue, 14 Sep 2010 09:51:21 -0400 (EDT) Subject: [tei-council] TEI Canonical URIs and DOIs In-Reply-To: <4C8F7CD4.9070608@oucs.ox.ac.uk> References: <4C8F7CD4.9070608@oucs.ox.ac.uk> Message-ID: <alpine.OSX.2.00.1009140950580.53506@lister.ei.virginia.edu> I believe the conclusion was that it would cost more money than it would be worth to register DOIs for all the Guidelines and Web pages. On Tue, 14 Sep 2010, James Cummings wrote: > I've just closed: > > https://sourceforge.net/tracker/index.php?func=detail&aid=2411994&group_id=106328&atid=644065 > > which was arguing for the TEI adopting a DOI solution to providing canonical > URIs. I believe we now provide canonical URIs for source and guidelines as my > last comment on that ticket shows. However, providing canonical URIs is > indeed different than providing DOIs. I have a recollection that the council > discussed this at some point but not what the conclusion was. > > If additional comments are added to the ticket, obviously, I'll reopen it. > > Just trying to tidy up, > -James > > -- David Sewell, Editorial and Technical Manager ROTUNDA, The University of Virginia Press PO Box 400314, Charlottesville, VA 22904-4314 USA Email: dsewell at virginia.edu Tel: +1 434 924 9973 Web: http://rotunda.upress.virginia.edu/ From James.Cummings at oucs.ox.ac.uk Tue Sep 14 09:52:43 2010 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Tue, 14 Sep 2010 14:52:43 +0100 Subject: [tei-council] TEI Canonical URIs and DOIs In-Reply-To: <alpine.OSX.2.00.1009140950580.53506@lister.ei.virginia.edu> References: <4C8F7CD4.9070608@oucs.ox.ac.uk> <alpine.OSX.2.00.1009140950580.53506@lister.ei.virginia.edu> Message-ID: <4C8F7E2B.20208@oucs.ox.ac.uk> Ah good, so I was right to close it. ;-) -James David Sewell wrote: > I believe the conclusion was that it would cost more money than it would > be worth to register DOIs for all the Guidelines and Web pages. > > On Tue, 14 Sep 2010, James Cummings wrote: > >> I've just closed: >> >> https://sourceforge.net/tracker/index.php?func=detail&aid=2411994&group_id=106328&atid=644065 >> >> which was arguing for the TEI adopting a DOI solution to providing canonical >> URIs. I believe we now provide canonical URIs for source and guidelines as my >> last comment on that ticket shows. However, providing canonical URIs is >> indeed different than providing DOIs. I have a recollection that the council >> discussed this at some point but not what the conclusion was. >> >> If additional comments are added to the ticket, obviously, I'll reopen it. >> >> Just trying to tidy up, >> -James >> >> > -- Dr James Cummings, Research Technologies Service OUCS, University of Oxford From James.Cummings at oucs.ox.ac.uk Tue Sep 14 10:02:08 2010 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Tue, 14 Sep 2010 15:02:08 +0100 Subject: [tei-council] wait there's (a few) more In-Reply-To: <44D72BE5-FEAE-414F-9FA0-A5E958767CC7@inria.fr> References: <4C8F4F85.2030109@oucs.ox.ac.uk> <44D72BE5-FEAE-414F-9FA0-A5E958767CC7@inria.fr> Message-ID: <4C8F8060.1060007@oucs.ox.ac.uk> >> 3058674 Add model.graphicLike to content of glyph ... > Can you update the ticket so that I understand the discussion between > you and James? I think the original request is complete clear (but maybe I'm biased!)... it says: === We replaced model.graphicLike in char and glyph with figure, and then I later made a good argument on another ticket for adding it back to char, which was accepted and duly done. However, char and glyph work in very similar ways and if it is justifiable for char to have model.graphicLike then glyph should have it as well. Recommendation: restore model.graphicLike to glyph, keeping figure as well, as is the case in char. === To be extra clear: Once upon a time <char> and <glyph> both allowed <graphic> as a child. Council decided that it should also have <figure>, in implementing this we carelessly removed model.graphicLike from their content model. I noticed this and said "Hey, why can't my <char> have any <graphic/> elements in it any more", put in a bug report, and model.graphicLike was added back to the content model of <char>. I neglected to complain about <glyph> because I don't really use it that much. But I was about to answer "Why not use a <graphic/> inside your <glyph>?" to a TEI-L posting when, upon checking, I found that I could not do so. When I asked to restore model.graphicLike to <char> I should have also said "and <glyph> as well". Mea culpa. In all honesty I think this is just a corrigible bug rather than something council should be bothered with, because to argue that it shouldn't be added back to <glyph> you have to make an argument for why <glyph>s can't have <graphic> and <char>s can, or you have to argue against it being present in <char>'s content model and say that it needs to be removed from both. On the ticket I also briefly mention that lots of the constituent members of the content model of <char> and <glyph> are identical and wonder why they are not provided by a class. However, that is really a separate bug. Does this help? -James -- Dr James Cummings, Research Technologies Service OUCS, University of Oxford From laurent.romary at inria.fr Tue Sep 14 10:44:31 2010 From: laurent.romary at inria.fr (Laurent Romary) Date: Tue, 14 Sep 2010 16:44:31 +0200 Subject: [tei-council] wait there's (a few) more In-Reply-To: <4C8F8060.1060007@oucs.ox.ac.uk> References: <4C8F4F85.2030109@oucs.ox.ac.uk> <44D72BE5-FEAE-414F-9FA0-A5E958767CC7@inria.fr> <4C8F8060.1060007@oucs.ox.ac.uk> Message-ID: <EA613E13-677F-4360-9C1F-3BF40EAF226E@inria.fr> Alles klar. So it's a no-brainer. Laurent Le 14 sept. 10 ? 16:02, James Cummings a ?crit : >>> 3058674 Add model.graphicLike to content of glyph ... >> Can you update the ticket so that I understand the discussion >> between you and James? > > I think the original request is complete clear (but maybe I'm > biased!)... it says: > > === > We replaced model.graphicLike in char and glyph with figure, and > then I later made a good argument on another ticket for adding it > back to char, which was accepted and duly done. However, char and > glyph work in very similar ways and if it is justifiable for char to > have model.graphicLike then glyph should have it as well. > > Recommendation: restore model.graphicLike to glyph, keeping figure > as well, as is the case in char. > === > > To be extra clear: Once upon a time <char> and <glyph> both allowed > <graphic> as a child. Council decided that it should also have > <figure>, in implementing this we carelessly removed > model.graphicLike from their content model. I noticed this and said > "Hey, why can't my <char> have any <graphic/> elements in it any > more", put in a bug report, and model.graphicLike was added back to > the content model of <char>. I neglected to complain about <glyph> > because I don't really use it that much. But I was about to answer > "Why not use a <graphic/> inside your <glyph>?" to a TEI-L posting > when, upon checking, I found that I could not do so. When I asked to > restore model.graphicLike to <char> I should have also said "and > <glyph> as well". Mea culpa. In all honesty I think this is just a > corrigible bug rather than something council should be bothered > with, because to argue that it shouldn't be added back to <glyph> > you have to make an argument for why <glyph>s can't have <graphic> > and <char>s can, or you have to argue against it being present in > <char>'s content model and say that it needs to be removed from both. > > On the ticket I also briefly mention that lots of the constituent > members of the content model of <char> and <glyph> are identical and > wonder why they are not provided by a class. However, that is really > a separate bug. > > Does this help? > > -James > > -- > Dr James Cummings, Research Technologies Service > OUCS, University of Oxford Laurent Romary INRIA & HUB-IDSL laurent.romary at inria.fr From mholmes at uvic.ca Tue Sep 14 11:51:29 2010 From: mholmes at uvic.ca (Martin Holmes) Date: Tue, 14 Sep 2010 08:51:29 -0700 Subject: [tei-council] wait there's (a few) more In-Reply-To: <4C8F4F85.2030109@oucs.ox.ac.uk> References: <4C8F4F85.2030109@oucs.ox.ac.uk> Message-ID: <4C8F9A01.1090704@uvic.ca> Didn't send my originals to the group, just to Lou so here they all are together: 2994666 Change idno content model to macro.xText DISAGREE 2859183 Make all milestoneLike elements spanning AGREE 2834871 Close ticket: will not fix AGREE 2859355 Permit macro.xText within<subst> AGREE 2984463 Add new class att.sortable AGREE 2994740 Add new milestoneLike element<gb> AGREE 2994671 Review suggested values for @calendar AGREE 3019781 Close ticket: text clarified ok AGREE 3044329 add @licence attribute to<availability> AGREE 3046288 modify content model of<f> to permit text DUNNO 3054295 change content models of origDate and origPl...AGREE 3064014 add sugg. values from known source for rs at type AGREE 2900430 Add new scriptNote, scriptDesc, @scriptRef ... AGREE (#4 only) 2987241 Revise wording of discussion bibl/biblStruct... AGREE 3058674 Add model.graphicLike to content of glyph... AGREE On 10-09-14 03:33 AM, Lou wrote: > I just went through the items on the Bugs tracker and found three new > more items which seem to have clear proposals for closure for council > members to vote on. > > 2900430 Add new scriptNote, scriptDesc, @scriptRef @scribeRef ... > 2987241 Revise wording of discussion bibl/biblStruct ... > 3058674 Add model.graphicLike to content of glyph ... > > I promise not to find any more. All that's left are items which require > more discussion... > > Thanks very much for speedy vote casting -- this all makes the editorial > drudgery much easier! > > > > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > -- Martin Holmes University of Victoria Humanities Computing and Media Centre (mholmes at uvic.ca) From lou.burnard at oucs.ox.ac.uk Tue Sep 14 11:58:16 2010 From: lou.burnard at oucs.ox.ac.uk (Lou) Date: Tue, 14 Sep 2010 16:58:16 +0100 Subject: [tei-council] wait there's (a few) more In-Reply-To: <4C8F9A01.1090704@uvic.ca> References: <4C8F4F85.2030109@oucs.ox.ac.uk> <4C8F9A01.1090704@uvic.ca> Message-ID: <4C8F9B98.8010900@oucs.ox.ac.uk> Many thanks Martin! It seems clear so far (but with only five out of the 11 members of Council having voted, who can be sure) that there's consensus on most of these items, with one or two on which opinions remain divided. Those should probably be added the list I'm currently working on, of items that need more detailed examination. From sebastian.rahtz at oucs.ox.ac.uk Tue Sep 14 12:00:54 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 14 Sep 2010 17:00:54 +0100 Subject: [tei-council] wait there's (a few) more In-Reply-To: <4C8F9B98.8010900@oucs.ox.ac.uk> References: <4C8F4F85.2030109@oucs.ox.ac.uk> <4C8F9A01.1090704@uvic.ca> <4C8F9B98.8010900@oucs.ox.ac.uk> Message-ID: <A3F2A64A-3C31-49C6-AE45-31646A93732D@oucs.ox.ac.uk> maybe we should have a check on who is going to be in Zadar in November? we might very well be able to put together a couple of 2 1/2 hour f2f working sessions if enough of us have evenings free in the first part of the week. -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From lou.burnard at oucs.ox.ac.uk Tue Sep 14 12:03:08 2010 From: lou.burnard at oucs.ox.ac.uk (Lou) Date: Tue, 14 Sep 2010 17:03:08 +0100 Subject: [tei-council] wait there's (a few) more In-Reply-To: <A3F2A64A-3C31-49C6-AE45-31646A93732D@oucs.ox.ac.uk> References: <4C8F4F85.2030109@oucs.ox.ac.uk> <4C8F9A01.1090704@uvic.ca> <4C8F9B98.8010900@oucs.ox.ac.uk> <A3F2A64A-3C31-49C6-AE45-31646A93732D@oucs.ox.ac.uk> Message-ID: <4C8F9CBC.3080208@oucs.ox.ac.uk> Sebastian Rahtz wrote: > maybe we should have a check on who is going to be in Zadar in November? we might very well be able to put together > a couple of 2 1/2 hour f2f working sessions if enough of us have evenings free in the first part of the week. > Excellent suggestion! But I was rather hoping that we might get most of these tickets dealt with well before then. From mholmes at uvic.ca Tue Sep 14 13:32:49 2010 From: mholmes at uvic.ca (Martin Holmes) Date: Tue, 14 Sep 2010 10:32:49 -0700 Subject: [tei-council] wait there's (a few) more In-Reply-To: <A3F2A64A-3C31-49C6-AE45-31646A93732D@oucs.ox.ac.uk> References: <4C8F4F85.2030109@oucs.ox.ac.uk> <4C8F9A01.1090704@uvic.ca> <4C8F9B98.8010900@oucs.ox.ac.uk> <A3F2A64A-3C31-49C6-AE45-31646A93732D@oucs.ox.ac.uk> Message-ID: <4C8FB1C1.4030104@uvic.ca> I won't be there, unfortunately. It's too expensive to travel that far. Cheers, Martin On 10-09-14 09:00 AM, Sebastian Rahtz wrote: > maybe we should have a check on who is going to be in Zadar in November? we might very well be able to put together > a couple of 2 1/2 hour f2f working sessions if enough of us have evenings free in the first part of the week. > > -- > Sebastian Rahtz > Information Manager, Oxford University Computing Services > 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 > > S?lo le pido a Dios > que el futuro no me sea indiferente > > > > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > -- Martin Holmes University of Victoria Humanities Computing and Media Centre (mholmes at uvic.ca) From kevin.s.hawkins at ultraslavonic.info Tue Sep 14 13:40:33 2010 From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins) Date: Tue, 14 Sep 2010 13:40:33 -0400 Subject: [tei-council] who will be in Zadar (was Re: wait there's (a few) more) In-Reply-To: <4C8FB1C1.4030104@uvic.ca> References: <4C8F4F85.2030109@oucs.ox.ac.uk> <4C8F9A01.1090704@uvic.ca> <4C8F9B98.8010900@oucs.ox.ac.uk> <A3F2A64A-3C31-49C6-AE45-31646A93732D@oucs.ox.ac.uk> <4C8FB1C1.4030104@uvic.ca> Message-ID: <4C8FB391.6070002@ultraslavonic.info> Same here: partly expense of travel and lodging and partly inconvenience of few flight options. --Kevin On 9/14/2010 1:32 PM, Martin Holmes wrote: > I won't be there, unfortunately. It's too expensive to travel that far. > > Cheers, > Martin > > On 10-09-14 09:00 AM, Sebastian Rahtz wrote: >> maybe we should have a check on who is going to be in Zadar in November? we might very well be able to put together >> a couple of 2 1/2 hour f2f working sessions if enough of us have evenings free in the first part of the week. >> >> -- >> Sebastian Rahtz >> Information Manager, Oxford University Computing Services >> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 >> >> S?lo le pido a Dios >> que el futuro no me sea indiferente >> >> >> >> >> _______________________________________________ >> tei-council mailing list >> tei-council at lists.village.Virginia.EDU >> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council >> > From dot.porter at gmail.com Tue Sep 14 13:51:18 2010 From: dot.porter at gmail.com (Dot Porter) Date: Tue, 14 Sep 2010 13:51:18 -0400 Subject: [tei-council] who will be in Zadar (was Re: wait there's (a few) more) In-Reply-To: <4C8FB391.6070002@ultraslavonic.info> References: <4C8F4F85.2030109@oucs.ox.ac.uk> <4C8F9A01.1090704@uvic.ca> <4C8F9B98.8010900@oucs.ox.ac.uk> <A3F2A64A-3C31-49C6-AE45-31646A93732D@oucs.ox.ac.uk> <4C8FB1C1.4030104@uvic.ca> <4C8FB391.6070002@ultraslavonic.info> Message-ID: <AANLkTinDM8==FfYowipo3Br-gW-ht4Pjnmvpc__X=EPD@mail.gmail.com> I'll be there although I haven't yet figured out how I'm getting from Zagreb to Zadar. Dot On Tue, Sep 14, 2010 at 1:40 PM, Kevin Hawkins < kevin.s.hawkins at ultraslavonic.info> wrote: > Same here: partly expense of travel and lodging and partly inconvenience > of few flight options. --Kevin > > On 9/14/2010 1:32 PM, Martin Holmes wrote: > > I won't be there, unfortunately. It's too expensive to travel that far. > > > > Cheers, > > Martin > > > > On 10-09-14 09:00 AM, Sebastian Rahtz wrote: > >> maybe we should have a check on who is going to be in Zadar in November? > we might very well be able to put together > >> a couple of 2 1/2 hour f2f working sessions if enough of us have > evenings free in the first part of the week. > >> > >> -- > >> Sebastian Rahtz > >> Information Manager, Oxford University Computing Services > >> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 > >> > >> S?lo le pido a Dios > >> que el futuro no me sea indiferente > >> > >> > >> > >> > >> _______________________________________________ > >> tei-council mailing list > >> tei-council at lists.village.Virginia.EDU > >> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > >> > > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > -- *~*~*~*~*~*~*~*~*~*~* Dot Porter (MA, MSLS) Digital Medievalist, Digital Librarian Email: dot.porter at gmail.com *~*~*~*~*~*~*~*~*~*~* From kevin.s.hawkins at ultraslavonic.info Tue Sep 14 14:02:39 2010 From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins) Date: Tue, 14 Sep 2010 14:02:39 -0400 Subject: [tei-council] wait there's (a few) more In-Reply-To: <4C8F4F85.2030109@oucs.ox.ac.uk> References: <4C8F4F85.2030109@oucs.ox.ac.uk> Message-ID: <4C8FB8BF.7010905@ultraslavonic.info> On 9/14/2010 6:33 AM, Lou wrote: > I just went through the items on the Bugs tracker and found three new > more items which seem to have clear proposals for closure for council > members to vote on. > > 2900430 Add new scriptNote, scriptDesc, @scriptRef @scribeRef ... Lou, is the typeNote/scriptNote/writingNote question at the end of your proposal in the ticket part of what we're voting on, or is that merely a musing? --Kevin From lou.burnard at oucs.ox.ac.uk Tue Sep 14 16:11:14 2010 From: lou.burnard at oucs.ox.ac.uk (Lou Burnard) Date: Tue, 14 Sep 2010 21:11:14 +0100 Subject: [tei-council] wait there's (a few) more In-Reply-To: <4C8FB8BF.7010905@ultraslavonic.info> References: <4C8F4F85.2030109@oucs.ox.ac.uk> <4C8FB8BF.7010905@ultraslavonic.info> Message-ID: <4C8FD6E2.8020904@oucs.ox.ac.uk> Most people have decided they're voting on option 4, the one at the end. On 14/09/10 19:02, Kevin Hawkins wrote: > On 9/14/2010 6:33 AM, Lou wrote: >> I just went through the items on the Bugs tracker and found three new >> more items which seem to have clear proposals for closure for council >> members to vote on. >> >> 2900430 Add new scriptNote, scriptDesc, @scriptRef @scribeRef ... > > Lou, is the typeNote/scriptNote/writingNote question at the end of your > proposal in the ticket part of what we're voting on, or is that merely a > musing? > > --Kevin > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council From kevin.s.hawkins at ultraslavonic.info Tue Sep 14 16:20:45 2010 From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins) Date: Tue, 14 Sep 2010 16:20:45 -0400 Subject: [tei-council] wait there's (a few) more In-Reply-To: <4C8FD6E2.8020904@oucs.ox.ac.uk> References: <4C8F4F85.2030109@oucs.ox.ac.uk> <4C8FB8BF.7010905@ultraslavonic.info> <4C8FD6E2.8020904@oucs.ox.ac.uk> Message-ID: <4C8FD91D.5070800@ultraslavonic.info> Oh, these are four options? I thought this is a package of four changes! So instead of voting AGREE, DISAGREE, or DUNNO, we're supposed to pick one of these? And what about that question at the end -- where does it fit in? On 9/14/2010 4:11 PM, Lou Burnard wrote: > Most people have decided they're voting on option 4, the one at the end. > > > On 14/09/10 19:02, Kevin Hawkins wrote: >> On 9/14/2010 6:33 AM, Lou wrote: >>> I just went through the items on the Bugs tracker and found three new >>> more items which seem to have clear proposals for closure for council >>> members to vote on. >>> >>> 2900430 Add new scriptNote, scriptDesc, @scriptRef @scribeRef ... >> >> Lou, is the typeNote/scriptNote/writingNote question at the end of your >> proposal in the ticket part of what we're voting on, or is that merely a >> musing? >> >> --Kevin >> _______________________________________________ >> tei-council mailing list >> tei-council at lists.village.Virginia.EDU >> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council From lou.burnard at oucs.ox.ac.uk Tue Sep 14 16:25:45 2010 From: lou.burnard at oucs.ox.ac.uk (Lou Burnard) Date: Tue, 14 Sep 2010 21:25:45 +0100 Subject: [tei-council] wait there's (a few) more In-Reply-To: <4C8FD91D.5070800@ultraslavonic.info> References: <4C8F4F85.2030109@oucs.ox.ac.uk> <4C8FB8BF.7010905@ultraslavonic.info> <4C8FD6E2.8020904@oucs.ox.ac.uk> <4C8FD91D.5070800@ultraslavonic.info> Message-ID: <4C8FDA49.3090009@oucs.ox.ac.uk> Sorry for being unclear. The Proposal is what counts. Vote to indicate which part of it (if any) you (dis)agree with. The question at the end was just me having a second thought: if you want to disagree with the proposal, you might want to support that thought. Or not. On 14/09/10 21:20, Kevin Hawkins wrote: > Oh, these are four options? I thought this is a package of four > changes! So instead of voting AGREE, DISAGREE, or DUNNO, we're supposed > to pick one of these? > > And what about that question at the end -- where does it fit in? > > On 9/14/2010 4:11 PM, Lou Burnard wrote: >> Most people have decided they're voting on option 4, the one at the end. >> >> >> On 14/09/10 19:02, Kevin Hawkins wrote: >>> On 9/14/2010 6:33 AM, Lou wrote: >>>> I just went through the items on the Bugs tracker and found three new >>>> more items which seem to have clear proposals for closure for council >>>> members to vote on. >>>> >>>> 2900430 Add new scriptNote, scriptDesc, @scriptRef @scribeRef ... >>> >>> Lou, is the typeNote/scriptNote/writingNote question at the end of your >>> proposal in the ticket part of what we're voting on, or is that merely a >>> musing? >>> >>> --Kevin >>> _______________________________________________ >>> tei-council mailing list >>> tei-council at lists.village.Virginia.EDU >>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council >> >> _______________________________________________ >> tei-council mailing list >> tei-council at lists.village.Virginia.EDU >> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council From julianne.nyhan at gmail.com Wed Sep 15 13:26:41 2010 From: julianne.nyhan at gmail.com (Julianne Nyhan) Date: Wed, 15 Sep 2010 18:26:41 +0100 Subject: [tei-council] and the remainder of the voting slip... In-Reply-To: <3FDB13BF-4119-413E-9E56-FF0704DCF951@kcl.ac.uk> References: <4C8E9E6A.7010206@oucs.ox.ac.uk> <3FDB13BF-4119-413E-9E56-FF0704DCF951@kcl.ac.uk> Message-ID: <AANLkTi=Cos5qajNXS8Tm84om6cQ2x48hz8G_A7_xLJGG@mail.gmail.com> Hello, First installment: 3044329 add @licence attribute to <availability> ... DISAGREE (proposal is not comprehensive enough) 3046288 modify content model of <f> to permit text ... AGREE 3054295 change content models of origDate and origPlace ... AGREE 3064014 add suggested values from known source for rs at type ... AGREE Best, Julianne On Tue, Sep 14, 2010 at 11:25 AM, Elena Pierazzo <elena.pierazzo at kcl.ac.uk>wrote: > Second helping > > > > > ------------------------------------------------ > > POLLING CLOSES AT MIDNIGHT ON 19 SEPT 2010 > > ------------------------------------------------ > > > > 3044329 add @licence attribute to <availability> DUNNO, I > > think Kevin remarks is quite sensible. > > 3046288 modify content model of <f> to permit text DUNNO > > 3054295 change content models of origDate and origPlace AGREE > > 3064014 add suggested values from known source for rs at type DUNNO, I > > think the <rs> element is willingly a generic one and therefore > > difficult to narrow down with values... > > > > -- > Dr Elena Pierazzo > Research Associate > Centre for Computing in the Humanities > King's College London > 26-29 Drury Lane > London WC2B 5RL > > Phone: 0207-848-1949 > Fax: 0207-848-2980 > elena.pierazzo at kcl.ac.uk > www.kcl.ac.uk > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > -- Dr Julianne Nyhan, Kompetenzzentrum f?r elektronische Erschlie?ungs- und Publikationsverfahren in den Geisteswissenschaften Universit?t Trier Fachbereich II / Germanistik Universit?tsring 15 54286 Trier + 49 (0)651 201-3358 http://germazope.uni-trier.de/Projects/KoZe2/ http://epu.ucc.ie/theses/jnyhan/ http://maney.co.uk/index.php/journals/isr/ http://www.tei-c.org/Activities/SIG/Education/index.xml From julianne.nyhan at gmail.com Wed Sep 15 15:04:26 2010 From: julianne.nyhan at gmail.com (Julianne Nyhan) Date: Wed, 15 Sep 2010 20:04:26 +0100 Subject: [tei-council] Vote early for ticket tidyup (part 1) In-Reply-To: <342BAF68-C164-43CA-A15E-BB13BFB0E0C6@oucs.ox.ac.uk> References: <4C8E62B1.3030605@oucs.ox.ac.uk> <4C8F520F.6020107@oucs.ox.ac.uk> <6E306F2F-43AF-4E40-B472-C59EFAA78271@oucs.ox.ac.uk> <4C8F5404.60803@oucs.ox.ac.uk> <CC3FBC72-1B13-459A-A948-8F3DF8855008@oucs.ox.ac.uk> <4C8F5F2A.90601@oucs.ox.ac.uk> <342BAF68-C164-43CA-A15E-BB13BFB0E0C6@oucs.ox.ac.uk> Message-ID: <AANLkTi=CSPHDy=KQQF+DwuFRWhaUvYiY8bFaL-oziFhJ@mail.gmail.com> Bonsoir, 2994666 Change idno content model to macro.xText .... AGREE 2859183 Make all milestoneLike elements spanning .... AGREE 2834871 Close ticket: will not fix .... AGREE (simply because it seems to be the only practical answer but issue is not resolved) 2859355 Permit macro.xText within <subst> .... AGREE 2984463 Add new class att.sortable .... DUNNO 2994740 Add new milestoneLike element <gb> .... AGREE 2994671 Review suggested values for @calendar .... AGREE 3019781 Close ticket: text clarified ok .... AGREE Beir bua is beannacht, Julianne On Tue, Sep 14, 2010 at 1:40 PM, Sebastian Rahtz < sebastian.rahtz at oucs.ox.ac.uk> wrote: > > On 14 Sep 2010, at 12:40, James Cummings wrote: > > > done in a piecemeal un-resourced manner.TEI-C seems to believe it > > isn't in the job of producing software but then so much of the > > infrastructure of it is built on software > > there's three sorts of software involved > > a) what the TEI needs to create its deliverables. so we MUST have > an ODD processor to create stuff the P5 source. > > b) what the TEI provides to help you use the Gidlines better or at all, ie > Roma > > c) tools that many TEIers like, but don't all need or agree on. eg > Martin's > lovely image tool > > between b) and c) are things like my TEI --> ePub, which are nice > if you want them, but not essential; but which share an infrastructure > with the ODD tools in a) > > > Or am I deluded > > here and is TEI-C already funding the development of Roma and > > Stylesheets, etc? > > > > yes, it is. The editorial project is supposed to make sure the basic > ODD tools work, and the Oxford Host contribution is stylesheet > and similar tool maintenance. > > I don't say its satisfactory but its a start. The council can and should > keep a closer eye on all this, and have a better strategic plan, I would > suggest > > -- > Sebastian Rahtz > Information Manager, Oxford University Computing Services > 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 > > S?lo le pido a Dios > que el futuro no me sea indiferente > > > > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > -- Dr Julianne Nyhan, Kompetenzzentrum f?r elektronische Erschlie?ungs- und Publikationsverfahren in den Geisteswissenschaften Universit?t Trier Fachbereich II / Germanistik Universit?tsring 15 54286 Trier + 49 (0)651 201-3358 http://germazope.uni-trier.de/Projects/KoZe2/ http://epu.ucc.ie/theses/jnyhan/ http://maney.co.uk/index.php/journals/isr/ http://www.tei-c.org/Activities/SIG/Education/index.xml From gabriel.bodard at kcl.ac.uk Thu Sep 16 07:18:52 2010 From: gabriel.bodard at kcl.ac.uk (Gabriel Bodard) Date: Thu, 16 Sep 2010 12:18:52 +0100 Subject: [tei-council] Vote early for ticket tidyup (part 1) In-Reply-To: <4C8E62B1.3030605@oucs.ox.ac.uk> References: <4C8E62B1.3030605@oucs.ox.ac.uk> Message-ID: <4C91FD1C.9010400@kcl.ac.uk> Apologies for late voting: I've been out of town. Other two lists will follow shortly. On 13/09/2010 18:43, Lou wrote: > 2994666 Change idno content model to macro.xText AGREE > 2859183 Make all milestoneLike elements spanning AGREE > 2834871 Close ticket: will not fix AGREE > 2859355 Permit macro.xText within<subst> PARTIALLY AGREE > 2984463 Add new class att.sortable AGREE > 2994740 Add new milestoneLike element<gb> abstain > 2994671 Review suggested values for @calendar DISAGREE > 3019781 Close ticket: text clarified ok AGREE Where values above != AGREE, I have commented in SF. G -- Dr Gabriel BODARD (Epigrapher, Digital Classicist, Pirate) Centre for Computing in the Humanities King's College London 26-29 Drury Lane London WC2B 5RL Email: gabriel.bodard at kcl.ac.uk Tel: +44 (0)20 7848 1388 Fax: +44 (0)20 7848 2980 http://www.digitalclassicist.org/ http://www.currentepigraphy.org/ From gabriel.bodard at kcl.ac.uk Thu Sep 16 07:25:46 2010 From: gabriel.bodard at kcl.ac.uk (Gabriel Bodard) Date: Thu, 16 Sep 2010 12:25:46 +0100 Subject: [tei-council] and the remainder of the voting slip... In-Reply-To: <4C8E9E6A.7010206@oucs.ox.ac.uk> References: <4C8E9E6A.7010206@oucs.ox.ac.uk> Message-ID: <4C91FEBA.7070707@kcl.ac.uk> On 13/09/2010 22:58, Lou Burnard wrote: > 3044329 add @licence attribute to<availability> AGREE > 3046288 modify content model of<f> to permit text AGREE > 3054295 change content models of origDate and origPlace AGREE > 3064014 add suggested values from known source for rs at type AGREE -- Dr Gabriel BODARD (Epigrapher, Digital Classicist, Pirate) Centre for Computing in the Humanities King's College London 26-29 Drury Lane London WC2B 5RL Email: gabriel.bodard at kcl.ac.uk Tel: +44 (0)20 7848 1388 Fax: +44 (0)20 7848 2980 http://www.digitalclassicist.org/ http://www.currentepigraphy.org/ From gabriel.bodard at kcl.ac.uk Thu Sep 16 07:51:09 2010 From: gabriel.bodard at kcl.ac.uk (Gabriel Bodard) Date: Thu, 16 Sep 2010 12:51:09 +0100 Subject: [tei-council] wait there's (a few) more In-Reply-To: <4C8F4F85.2030109@oucs.ox.ac.uk> References: <4C8F4F85.2030109@oucs.ox.ac.uk> Message-ID: <4C9204AD.20008@kcl.ac.uk> On 14/09/2010 11:33, Lou wrote: > 2900430 Add new scriptNote, scriptDesc, @scriptRef @scribeRef PARTIALLY AGREE > 2987241 Revise wording of discussion bibl/biblStruct DISAGREE > 3058674 Add model.graphicLike to content of glyph AGREE -- Dr Gabriel BODARD (Epigrapher, Digital Classicist, Pirate) Centre for Computing in the Humanities King's College London 26-29 Drury Lane London WC2B 5RL Email: gabriel.bodard at kcl.ac.uk Tel: +44 (0)20 7848 1388 Fax: +44 (0)20 7848 2980 http://www.digitalclassicist.org/ http://www.currentepigraphy.org/ From susan.schreibman at gmail.com Thu Sep 16 10:57:19 2010 From: susan.schreibman at gmail.com (Susan Schreibman) Date: Thu, 16 Sep 2010 15:57:19 +0100 Subject: [tei-council] Journal of the TEI Message-ID: <AANLkTimGXP3Tn1mBESAmBnJgu_=u24iQSdyKMDb+Z1Sx@mail.gmail.com> Colleagues -- We issued a call for reviewers some weeks ago and two people from the Council have registered. May I ask if you would consider giving a bit more to the TEI and register as a reviewer. We promise not to call on you too frequently. to register, please go to http://journal.tei-c.org/journal/index and click on the register tab. Once you fill up the form tick reviewer at the bottom of the page. Many thanks Susan -- Susan Schreibman, PhD Director Digital Humanities Observatory Royal Irish Academy 19 Dawson Street Dublin 2 Email: susan.schreibman at gmail.com phone: +353 1 234 2440 mobile: 353 1 86 049 1966 http://dho.ie http://irith.org http://macgreevy.org From gabriel.bodard at kcl.ac.uk Thu Sep 16 12:15:41 2010 From: gabriel.bodard at kcl.ac.uk (Gabriel Bodard) Date: Thu, 16 Sep 2010 17:15:41 +0100 Subject: [tei-council] Journal of the TEI In-Reply-To: <AANLkTimGXP3Tn1mBESAmBnJgu_=u24iQSdyKMDb+Z1Sx@mail.gmail.com> References: <AANLkTimGXP3Tn1mBESAmBnJgu_=u24iQSdyKMDb+Z1Sx@mail.gmail.com> Message-ID: <4C9242AD.8080406@kcl.ac.uk> Were several members of council not proposed to the advisory board when we discussed this last year? On 16/09/2010 15:57, Susan Schreibman wrote: > Colleagues -- We issued a call for reviewers some weeks ago and two people > from the Council have registered. May I ask if you would consider giving a > bit more to the TEI and register as a reviewer. We promise not to call on > you too frequently. > > to register, please go to > > http://journal.tei-c.org/journal/index > > and click on the register tab. Once you fill up the form tick reviewer at > the bottom of the page. > > Many thanks > > Susan > -- Dr Gabriel BODARD (Epigrapher, Digital Classicist, Pirate) Centre for Computing in the Humanities King's College London 26-29 Drury Lane London WC2B 5RL Email: gabriel.bodard at kcl.ac.uk Tel: +44 (0)20 7848 1388 Fax: +44 (0)20 7848 2980 http://www.digitalclassicist.org/ http://www.currentepigraphy.org/ From susan.schreibman at gmail.com Thu Sep 16 13:34:07 2010 From: susan.schreibman at gmail.com (Susan Schreibman) Date: Thu, 16 Sep 2010 18:34:07 +0100 Subject: [tei-council] Journal of the TEI In-Reply-To: <4C9242AD.8080406@kcl.ac.uk> References: <AANLkTimGXP3Tn1mBESAmBnJgu_=u24iQSdyKMDb+Z1Sx@mail.gmail.com> <4C9242AD.8080406@kcl.ac.uk> Message-ID: <AANLkTinT+e9_QCv7qZVkDySGhHGwTBtyVVL14b07_UPK@mail.gmail.com> The list of Board members is here: http://journal.tei-c.org/journal/about/editorialPolicies#custom1 Having said that, we are not automatically enrolling anybody as a reviewer (not even Advisory Board Members). Susan On 16 September 2010 17:15, Gabriel Bodard <gabriel.bodard at kcl.ac.uk> wrote: > Were several members of council not proposed to the advisory board when > we discussed this last year? > > On 16/09/2010 15:57, Susan Schreibman wrote: > > Colleagues -- We issued a call for reviewers some weeks ago and two > people > > from the Council have registered. May I ask if you would consider giving > a > > bit more to the TEI and register as a reviewer. We promise not to call on > > you too frequently. > > > > to register, please go to > > > > http://journal.tei-c.org/journal/index > > > > and click on the register tab. Once you fill up the form tick reviewer at > > the bottom of the page. > > > > Many thanks > > > > Susan > > > > -- > Dr Gabriel BODARD > (Epigrapher, Digital Classicist, Pirate) > > Centre for Computing in the Humanities > King's College London > 26-29 Drury Lane > London WC2B 5RL > Email: gabriel.bodard at kcl.ac.uk > Tel: +44 (0)20 7848 1388 > Fax: +44 (0)20 7848 2980 > > http://www.digitalclassicist.org/ > http://www.currentepigraphy.org/ > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > -- Susan Schreibman, PhD Director Digital Humanities Observatory Royal Irish Academy 19 Dawson Street Dublin 2 Email: susan.schreibman at gmail.com phone: +353 1 234 2440 mobile: 353 1 86 049 1966 http://dho.ie http://irith.org http://macgreevy.org From julianne.nyhan at gmail.com Fri Sep 17 18:51:40 2010 From: julianne.nyhan at gmail.com (Julianne Nyhan) Date: Fri, 17 Sep 2010 23:51:40 +0100 Subject: [tei-council] wait there's (a few) more In-Reply-To: <4C9204AD.20008@kcl.ac.uk> References: <4C8F4F85.2030109@oucs.ox.ac.uk> <4C9204AD.20008@kcl.ac.uk> Message-ID: <AANLkTi=UiowiBuFeCU+E=WZ2VUv0i9yOZhS5Ehsy+Hu_@mail.gmail.com> My final three votes: 2900430 Add new scriptNote, scriptDesc, @scriptRef ... AGREE 2987241 Revise wording of discussion bibl/biblStruct... AGREE 3058674 Add model.graphicLike to content of glyph... AGREE On Thu, Sep 16, 2010 at 12:51 PM, Gabriel Bodard <gabriel.bodard at kcl.ac.uk>wrote: > On 14/09/2010 11:33, Lou wrote: > > 2900430 Add new scriptNote, scriptDesc, @scriptRef @scribeRef PARTIALLY > AGREE > > 2987241 Revise wording of discussion bibl/biblStruct DISAGREE > > 3058674 Add model.graphicLike to content of glyph AGREE > > > -- > Dr Gabriel BODARD > (Epigrapher, Digital Classicist, Pirate) > > Centre for Computing in the Humanities > King's College London > 26-29 Drury Lane > London WC2B 5RL > Email: gabriel.bodard at kcl.ac.uk > Tel: +44 (0)20 7848 1388 > Fax: +44 (0)20 7848 2980 > > http://www.digitalclassicist.org/ > http://www.currentepigraphy.org/ > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > -- Dr Julianne Nyhan, Kompetenzzentrum f?r elektronische Erschlie?ungs- und Publikationsverfahren in den Geisteswissenschaften Universit?t Trier Fachbereich II / Germanistik Universit?tsring 15 54286 Trier + 49 (0)651 201-3358 http://germazope.uni-trier.de/Projects/KoZe2/ http://epu.ucc.ie/theses/jnyhan/ http://maney.co.uk/index.php/journals/isr/ http://www.tei-c.org/Activities/SIG/Education/index.xml From mjd at hum.ku.dk Sat Sep 18 07:44:10 2010 From: mjd at hum.ku.dk (Matthew James Driscoll) Date: Sat, 18 Sep 2010 13:44:10 +0200 Subject: [tei-council] wait there's (a few) more In-Reply-To: <4C8F535A.3060604@oucs.ox.ac.uk> References: <4C8F4F85.2030109@oucs.ox.ac.uk>,<4C8F535A.3060604@oucs.ox.ac.uk> Message-ID: <CF2BD0FB82A2624EA40D0EE4379C896D7925DB38CA@post> Copenhagen calling. Here are the results of the Danish jury: 2994666 Change idno content model to macro.xText DISAGREE 2859183 Make all milestoneLike elements spanning AGREE 2834871 Close ticket: will not fix DUNNO 2859355 Permit macro.xText within <subst> AGREE 2984463 Add new class att.sortable DUNNO (not persuaded that it's needed) 2994740 Add new milestoneLike element <gb> AGREE (I love it) 2994671 Review suggested values for @calendar AGREE 3019781 Close ticket: text clarified ok DUNNO (probably agree) 3044329 add @licence attribute to <availability> DUNNO (though seems not unreasonable to me) 3046288 modify content model of <f> to permit text AGREE 3054295 change content models of origDate and origPlace AGREE 3064014 add suggested values from known source for rs at type AGREE 2900430 Add new scriptNote, scriptDesc, @scriptRef @scribeRef AGREE 2987241 Revise wording of discussion bibl/biblStruct DISAGREE 3058674 Add model.graphicLike to content of glyph AGREE Matthew From dot.porter at gmail.com Sun Sep 19 18:32:09 2010 From: dot.porter at gmail.com (Dot Porter) Date: Sun, 19 Sep 2010 18:32:09 -0400 Subject: [tei-council] Vote early for ticket tidyup (part 1) In-Reply-To: <4C91FD1C.9010400@kcl.ac.uk> References: <4C8E62B1.3030605@oucs.ox.ac.uk> <4C91FD1C.9010400@kcl.ac.uk> Message-ID: <AANLkTinbRPj5_dAmYGJcc=S3qypnYsNx8LXCR6B+nQsC@mail.gmail.com> I have all my votes together > 2994666 Change idno content model to macro.xText AGREE > 2859183 Make all milestoneLike elements spanning AGREE > 2834871 Close ticket: will not fix AGREE > 2859355 Permit macro.xText within<subst> AGREE > 2984463 Add new class att.sortable AGREE > 2994740 Add new milestoneLike element<gb> AGREE > 2994671 Review suggested values for @calendar DISAGREE > 3019781 Close ticket: text clarified ok AGREE > 3044329 add @licence attribute to<availability> AGREE > 3046288 modify content model of<f> to permit text AGREE > 3054295 change content models of origDate and origPlace AGREE > 3064014 add suggested values from known source for rs at type AGREE > 2900430 Add new scriptNote, scriptDesc, @scriptRef @scribeRef AGREE > 2987241 Revise wording of discussion bibl/biblStruct DISAGREE > 3058674 Add model.graphicLike to content of glyph AGREE On Thu, Sep 16, 2010 at 7:18 AM, Gabriel Bodard <gabriel.bodard at kcl.ac.uk>wrote: > Apologies for late voting: I've been out of town. Other two lists will > follow shortly. > > On 13/09/2010 18:43, Lou wrote: > > 2994666 Change idno content model to macro.xText AGREE > > 2859183 Make all milestoneLike elements spanning AGREE > > 2834871 Close ticket: will not fix AGREE > > 2859355 Permit macro.xText within<subst> PARTIALLY AGREE > > 2984463 Add new class att.sortable AGREE > > 2994740 Add new milestoneLike element<gb> abstain > > 2994671 Review suggested values for @calendar DISAGREE > > 3019781 Close ticket: text clarified ok AGREE > > Where values above != AGREE, I have commented in SF. > > G > > -- > Dr Gabriel BODARD > (Epigrapher, Digital Classicist, Pirate) > > Centre for Computing in the Humanities > King's College London > 26-29 Drury Lane > London WC2B 5RL > Email: gabriel.bodard at kcl.ac.uk > Tel: +44 (0)20 7848 1388 > Fax: +44 (0)20 7848 2980 > > http://www.digitalclassicist.org/ > http://www.currentepigraphy.org/ > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > -- *~*~*~*~*~*~*~*~*~*~* Dot Porter (MA, MSLS) Digital Medievalist, Digital Librarian Email: dot.porter at gmail.com *~*~*~*~*~*~*~*~*~*~* From lou.burnard at oucs.ox.ac.uk Mon Sep 20 05:04:06 2010 From: lou.burnard at oucs.ox.ac.uk (Lou Burnard) Date: Mon, 20 Sep 2010 10:04:06 +0100 Subject: [tei-council] The poll Message-ID: <4C972386.2030804@oucs.ox.ac.uk> Here are the results of the poll which closed last night. Many thanks to all council members for their contributions! There's a pretty clear consensus as to which items are to be done, and which need more thought, so my plan when I get a minute or two later today will be to implement everything proposed EXCEPT for the first five items in the attached table. Thanks again for taking time to look at these issues. The TEI will be taking further advantage of you in the near future as we look at some of the more controversial outstanding issues... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.village.Virginia.EDU/pipermail/tei-council/attachments/20100920/5fcca8ef/attachment.html From sebastian.rahtz at oucs.ox.ac.uk Mon Sep 20 05:14:50 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 20 Sep 2010 10:14:50 +0100 Subject: [tei-council] The poll In-Reply-To: <4C972386.2030804@oucs.ox.ac.uk> References: <4C972386.2030804@oucs.ox.ac.uk> Message-ID: <BB7E227A-CF64-4894-A476-9068A54C8B73@oucs.ox.ac.uk> On 20 Sep 2010, at 10:04, Lou Burnard wrote: > Thanks again for taking time to look at these issues. The TEI will be > taking further advantage of you in the near future as we look at some of > the more controversial outstanding issues? > We have not had a telco for some considerable time, I think? Waybe we can resolve some of these by phone, and get any changes into the next release. We should also discuss, I think, what message Laurent will talk to Zadar to present to the eager peeple. Talking of releases, I propose a complete freeze date of 29th October for changes to P5 1.8. Realistically, that means all decisions made and implemented by October 15th to give time for any implications and nasties to be trapped. That is 3 weeks of work time left. -- Sebastian Rahtz (acting) Information and Support Group Manager Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From lou.burnard at oucs.ox.ac.uk Mon Sep 20 05:35:50 2010 From: lou.burnard at oucs.ox.ac.uk (Lou Burnard) Date: Mon, 20 Sep 2010 10:35:50 +0100 Subject: [tei-council] The poll In-Reply-To: <BB7E227A-CF64-4894-A476-9068A54C8B73@oucs.ox.ac.uk> References: <4C972386.2030804@oucs.ox.ac.uk> <BB7E227A-CF64-4894-A476-9068A54C8B73@oucs.ox.ac.uk> Message-ID: <4C972AF6.1080304@oucs.ox.ac.uk> Laurent is on holiday this week, so maybe we should wait for his input before organizing a telco but I have however already discussed the major outstanding issues with him and have a summary list I plan to post. The idea we had discussed was to ask Council members to volunteer each to take charge of one or two related issues, so that these could be discussed efficiently in a meeting, telephonic or otherwise. Three weeks is a bit tight, but possible... Sebastian Rahtz wrote: > On 20 Sep 2010, at 10:04, Lou Burnard wrote: > >> Thanks again for taking time to look at these issues. The TEI will be >> taking further advantage of you in the near future as we look at some of >> the more controversial outstanding issues? >> >> > We have not had a telco for some considerable time, I think? > > Waybe we can resolve some of these by phone, and get any changes into > the next release. We should also discuss, I think, what message Laurent > will talk to Zadar to present to the eager peeple. > > Talking of releases, I propose a complete freeze date of 29th October for changes > to P5 1.8. Realistically, that means all decisions made and implemented by October 15th to > give time for any implications and nasties to be trapped. That is 3 weeks of work time left. > -- > Sebastian Rahtz > (acting) Information and Support Group Manager > Oxford University Computing Services > 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 > > S?lo le pido a Dios > que el futuro no me sea indiferente > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > From sebastian.rahtz at oucs.ox.ac.uk Mon Sep 20 06:11:10 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 20 Sep 2010 11:11:10 +0100 Subject: [tei-council] The poll In-Reply-To: <4C972AF6.1080304@oucs.ox.ac.uk> References: <4C972386.2030804@oucs.ox.ac.uk> <BB7E227A-CF64-4894-A476-9068A54C8B73@oucs.ox.ac.uk> <4C972AF6.1080304@oucs.ox.ac.uk> Message-ID: <9EB52240-906C-4EFA-A5EF-033DFDDED10F@oucs.ox.ac.uk> On 20 Sep 2010, at 10:35, Lou Burnard wrote: > > Three weeks is a bit tight, but possible? > important, therefore, to prioritize the tickets somehow. if you can knock off the 100% AGREE tickets this week, we can consider which others to try for. I am conscious that we are missing a tranche of genetic changes. Is that waiting on anything from the WG? -- Sebastian Rahtz (acting) Information and Support Group Manager Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From lou.burnard at oucs.ox.ac.uk Mon Sep 20 06:11:56 2010 From: lou.burnard at oucs.ox.ac.uk (Lou Burnard) Date: Mon, 20 Sep 2010 11:11:56 +0100 Subject: [tei-council] The poll In-Reply-To: <9EB52240-906C-4EFA-A5EF-033DFDDED10F@oucs.ox.ac.uk> References: <4C972386.2030804@oucs.ox.ac.uk> <BB7E227A-CF64-4894-A476-9068A54C8B73@oucs.ox.ac.uk> <4C972AF6.1080304@oucs.ox.ac.uk> <9EB52240-906C-4EFA-A5EF-033DFDDED10F@oucs.ox.ac.uk> Message-ID: <4C97336C.8060008@oucs.ox.ac.uk> Sebastian Rahtz wrote: > > important, therefore, to prioritize the tickets somehow. if you > can knock off the 100% AGREE tickets this week, we > can consider which others to try for. > > I am conscious that we are missing a tranche of genetic > changes. Is that waiting on anything from the WG? In the other list. From lou.burnard at oucs.ox.ac.uk Mon Sep 20 09:52:44 2010 From: lou.burnard at oucs.ox.ac.uk (Lou Burnard) Date: Mon, 20 Sep 2010 14:52:44 +0100 Subject: [tei-council] Corrected ballot Message-ID: <4C97672C.7040008@oucs.ox.ac.uk> Ooops, hanging chads have been detected, which mean that 2859355 will get done, and 2984463 won't Thanks to the Council member who pointed out that I'd misread their set of votes! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.village.Virginia.EDU/pipermail/tei-council/attachments/20100920/7ddc6a97/attachment.html From kevin.s.hawkins at ultraslavonic.info Sun Sep 26 12:13:17 2010 From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins) Date: Sun, 26 Sep 2010 12:13:17 -0400 Subject: [tei-council] multiple namespaces in Tite documents Message-ID: <4C9F711D.2090301@ultraslavonic.info> Hi all, Perry Trolard and I are creating a set of SourceForge tickets dealing with Tite issues. Once we get all of our info in there, I'll bring these to Council with recommendations on how to resolve them. In the meantime, I have a technical and documentation style question. The Tite ODD introduces a few elements not in the TEI namespace, such as <b> and <i>. Since Tite's root element is <text>, you need to put two namespaces here: <text xmlns="http://www.tei-c.org/ns/1.0" xmlns:tite="http://www.tei-c.org/ns/tite/1.0" xml:id="foo"> (I gave the TEI namespace as the default and called the Tite one "tite". You could call the Tite one whatever you like, I suppose, and you could likewise put the Tite namespace elsewhere besides the root. But this seems like the sensible thing to do.) Would it be appropriate to specify in the Tite documentation the name you use for the tite namespace? If so, I think we should include this namespace on examples using elements from this namespace. For clarity, shouldn't definitions of elements from this namespace include this namespace on the element name? Kevin From sebastian.rahtz at oucs.ox.ac.uk Sun Sep 26 12:22:18 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Sun, 26 Sep 2010 17:22:18 +0100 Subject: [tei-council] multiple namespaces in Tite documents In-Reply-To: <4C9F711D.2090301@ultraslavonic.info> References: <4C9F711D.2090301@ultraslavonic.info> Message-ID: <B8255FEE-52CC-41BA-93DE-2C0C8BCCBA6D@oucs.ox.ac.uk> On 26 Sep 2010, at 17:13, Kevin Hawkins wrote: > The Tite ODD introduces a few elements not in the TEI namespace, such as > <b> and <i>. Since Tite's root element is <text>, you need to put two > namespaces here: > > <text xmlns="http://www.tei-c.org/ns/1.0" > xmlns:tite="http://www.tei-c.org/ns/tite/1.0" xml:id="foo"> that's one way of declaring the Tite namespace. however, if you then use (eg) <tite:b>, it will not validate against the DTD (which, we were assured, is what the vendors like to use). > > For clarity, shouldn't definitions of elements from this namespace > include this namespace on the element name? no. there is no such concept of including a namespace on the element name. honest, you just don't need do anything at all if you use the DTD - it makes things work Like Magic for you. -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From kevin.s.hawkins at ultraslavonic.info Sun Sep 26 12:31:30 2010 From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins) Date: Sun, 26 Sep 2010 12:31:30 -0400 Subject: [tei-council] multiple namespaces in Tite documents In-Reply-To: <B8255FEE-52CC-41BA-93DE-2C0C8BCCBA6D@oucs.ox.ac.uk> References: <4C9F711D.2090301@ultraslavonic.info> <B8255FEE-52CC-41BA-93DE-2C0C8BCCBA6D@oucs.ox.ac.uk> Message-ID: <4C9F7562.6050700@ultraslavonic.info> Thanks for the quick response. Notes below ... On 9/26/2010 12:22 PM, Sebastian Rahtz wrote: > > On 26 Sep 2010, at 17:13, Kevin Hawkins wrote: > >> The Tite ODD introduces a few elements not in the TEI namespace, such as >> <b> and<i>. Since Tite's root element is<text>, you need to put two >> namespaces here: >> >> <text xmlns="http://www.tei-c.org/ns/1.0" >> xmlns:tite="http://www.tei-c.org/ns/tite/1.0" xml:id="foo"> > > that's one way of declaring the Tite namespace. however, if you then > use (eg)<tite:b>, it will not validate against the DTD (which, we > were assured, is what the vendors like to use). Right, I was speaking about using a RelaxNG schema. Since Roma mixes elements from various namespaces into the DTD, you can't use namespaces there. While vendors do prefer DTDs, I believe we should make the Tite documentation not only vendor-agnostic but also technology-agnostic, like P5. So this question is a sort of general policy one. I believe Tite is the first time since the introduction of the namespace mechanism in P5 the TEI has declared elements outside of the TEI namespace, so I want to think through the question of how to best document these things. >> For clarity, shouldn't definitions of elements from this namespace >> include this namespace on the element name? > > > no. there is no such concept of including a namespace on the element name. Okay, that makes sense. Still, is there any sense in prescribing a namespace -- the string before the colon, not the URI where the namespace is documented -- for these elements to be used in your XML documents? I see this situation as different from people including, say, SVG elements in their TEI documents because the TEI-C maintains both of the following: http://www.tei-c.org/ns/1.0 http://www.tei-c.org/ns/tite/1.0 whereas we don't maintain http://www.w3.org/2000/svg --Kevin From lou.burnard at oucs.ox.ac.uk Sun Sep 26 12:37:03 2010 From: lou.burnard at oucs.ox.ac.uk (Lou Burnard) Date: Sun, 26 Sep 2010 17:37:03 +0100 Subject: [tei-council] multiple namespaces in Tite documents In-Reply-To: <4C9F7562.6050700@ultraslavonic.info> References: <4C9F711D.2090301@ultraslavonic.info> <B8255FEE-52CC-41BA-93DE-2C0C8BCCBA6D@oucs.ox.ac.uk> <4C9F7562.6050700@ultraslavonic.info> Message-ID: <4C9F76AF.60505@oucs.ox.ac.uk> On 26/09/10 17:31, Kevin Hawkins wrote: > Still, is there any sense in prescribing a namespace -- the string > before the colon, not the URI where the namespace is documented -- for > these elements to be used in your XML documents? First let's get the terminology right. The thing before the colon is a namespace prefix. The URI is the name of the namespace. Mandating a specific namespace prefix seems like a rather bad idea to me. Using the same one consistently in examples however is perfectly reasonably I see this situation > as different from people including, say, SVG elements in their TEI > documents because the TEI-C maintains both of the following: > > http://www.tei-c.org/ns/1.0 > http://www.tei-c.org/ns/tite/1.0 > Personally I'd be much happier if we were able to roll Tite into the main TEI and not have this distinction at all. But that's for future work. From sebastian.rahtz at oucs.ox.ac.uk Sun Sep 26 12:39:40 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Sun, 26 Sep 2010 17:39:40 +0100 Subject: [tei-council] multiple namespaces in Tite documents In-Reply-To: <4C9F7562.6050700@ultraslavonic.info> References: <4C9F711D.2090301@ultraslavonic.info> <B8255FEE-52CC-41BA-93DE-2C0C8BCCBA6D@oucs.ox.ac.uk> <4C9F7562.6050700@ultraslavonic.info> Message-ID: <BD79EDC1-B29B-4AEE-83B4-162084BE594F@oucs.ox.ac.uk> On 26 Sep 2010, at 17:31, Kevin Hawkins wrote: > Right, I was speaking about using a RelaxNG schema. sure, if you are using a RELAX NG schema, all bets are off and you can do it how you like, with or without prefixes. > > While vendors do prefer DTDs, I believe we should make the Tite > documentation not only vendor-agnostic but also technology-agnostic, > like P5. So this question is a sort of general policy one. we can't have a policy, I fear, about namespace prefixes, because it s not enforceable. some people like prefixes, others don't. amusing to read that James Clark thinks this is the greatest mistake that XML made :-} > I believe > Tite is the first time since the introduction of the namespace mechanism > in P5 the TEI has declared elements outside of the TEI namespace, so I > want to think through the question of how to best document these things. is it different from the MathML or SVG or RELAX inclusions. tho? > Still, is there any sense in prescribing a namespace -- the string > before the colon, not the URI where the namespace is documented Well, no. Sorry. them's the rules. The namespace prefix is an arbitrary convenience-only binding of a namespace (which is definitely NOT, by the way, "the URI where the namespace is documented"!) -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From sebastian.rahtz at oucs.ox.ac.uk Sun Sep 26 12:40:57 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Sun, 26 Sep 2010 17:40:57 +0100 Subject: [tei-council] multiple namespaces in Tite documents In-Reply-To: <4C9F76AF.60505@oucs.ox.ac.uk> References: <4C9F711D.2090301@ultraslavonic.info> <B8255FEE-52CC-41BA-93DE-2C0C8BCCBA6D@oucs.ox.ac.uk> <4C9F7562.6050700@ultraslavonic.info> <4C9F76AF.60505@oucs.ox.ac.uk> Message-ID: <D29A68F4-0275-449F-8B10-206FA8472DA0@oucs.ox.ac.uk> On 26 Sep 2010, at 17:37, Lou Burnard wrote: > > First let's get the terminology right. The thing before the colon is a > namespace prefix. The URI is the name of the namespace. URI --> "the thing which looks like a URI and often is actually one but does not have to be" > Personally I'd be much happier if we were able to roll Tite into the > main TEI amen to that...... -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From kevin.s.hawkins at ultraslavonic.info Sun Sep 26 13:00:55 2010 From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins) Date: Sun, 26 Sep 2010 13:00:55 -0400 Subject: [tei-council] multiple namespaces in Tite documents In-Reply-To: <D29A68F4-0275-449F-8B10-206FA8472DA0@oucs.ox.ac.uk> References: <4C9F711D.2090301@ultraslavonic.info> <B8255FEE-52CC-41BA-93DE-2C0C8BCCBA6D@oucs.ox.ac.uk> <4C9F7562.6050700@ultraslavonic.info> <4C9F76AF.60505@oucs.ox.ac.uk> <D29A68F4-0275-449F-8B10-206FA8472DA0@oucs.ox.ac.uk> Message-ID: <4C9F7C47.4010408@ultraslavonic.info> Thanks for straightening me out on terminology. On 9/26/2010 12:37 PM, Lou Burnard wrote: > Mandating a specific namespace prefix seems like a rather bad idea to > me. Using the same one consistently in examples however is perfectly > reasonably (Right now examples do not use any namespace.) On 9/26/2010 12:39 PM, Sebastian Rahtz wrote: > sure, if you are using a RELAX NG schema, all bets are off and you > can do it how you like, with or without prefixes. Huh. <oXygen/> XML Editor 10.0 (build 2008120916) wouldn't let me! >> I believe >> Tite is the first time since the introduction of the namespace mechanism >> in P5 the TEI has declared elements outside of the TEI namespace, so I >> want to think through the question of how to best document these things. > > is it different from the MathML or SVG or RELAX inclusions. tho? I think so, because we're including from a namespace we manage. >> Still, is there any sense in prescribing a namespace -- the string >> before the colon, not the URI where the namespace is documented > > Well, no. Sorry. them's the rules. The namespace prefix is an arbitrary > convenience-only binding of a namespace > (which is definitely NOT, by the way, "the URI where the namespace is documented"!) I realize the prefix can be arbitrary, but if we prescribe use of a particular one, we reduce barriers to interchange of Tite documents. However, this may all be moot ... On 9/26/2010 12:40 PM, Sebastian Rahtz wrote: >> Personally I'd be much happier if we were able to roll Tite into the >> main TEI > > amen to that...... Lou said rolling Tite into the TEI is for future work, but I'm trying to document such future work in SourceForge right now. So no need to wait! This is now a feature request: https://sourceforge.net/tracker/?func=detail&aid=3075996&group_id=106328&atid=644065 In light of this request, let's hold off on supplying any namespace in the examples. --Kevin From sebastian.rahtz at oucs.ox.ac.uk Sun Sep 26 13:08:58 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Sun, 26 Sep 2010 18:08:58 +0100 Subject: [tei-council] multiple namespaces in Tite documents In-Reply-To: <4C9F7C47.4010408@ultraslavonic.info> References: <4C9F711D.2090301@ultraslavonic.info> <B8255FEE-52CC-41BA-93DE-2C0C8BCCBA6D@oucs.ox.ac.uk> <4C9F7562.6050700@ultraslavonic.info> <4C9F76AF.60505@oucs.ox.ac.uk> <D29A68F4-0275-449F-8B10-206FA8472DA0@oucs.ox.ac.uk> <4C9F7C47.4010408@ultraslavonic.info> Message-ID: <744C0A35-E14E-4351-A9E4-7B834A3135EF@oucs.ox.ac.uk> On 26 Sep 2010, at 18:00, Kevin Hawkins wrote: >> sure, if you are using a RELAX NG schema, all bets are off and you >> can do it how you like, with or without prefixes. > > Huh. <oXygen/> XML Editor 10.0 (build 2008120916) wouldn't let me! > wouldn't let you do what? > I realize the prefix can be arbitrary, but if we prescribe use of a > particular one, we reduce barriers to interchange of Tite documents. I don't see why. If you say <tomato:b> and I say <potato:b>, and the prefixes are bound to the same ns, we are interchangeable. Only in the case where you attempted to process the XML files using non-XML tools might you have problems. don't forget that namespace prefixes can be, and are, rewritten or thrown away by XML processing tools. You have no guarentee they will stay as you wrote them. -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From sebastian.rahtz at oucs.ox.ac.uk Sun Sep 26 13:15:33 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Sun, 26 Sep 2010 18:15:33 +0100 Subject: [tei-council] multiple namespaces in Tite documents In-Reply-To: <4C9F7C47.4010408@ultraslavonic.info> References: <4C9F711D.2090301@ultraslavonic.info> <B8255FEE-52CC-41BA-93DE-2C0C8BCCBA6D@oucs.ox.ac.uk> <4C9F7562.6050700@ultraslavonic.info> <4C9F76AF.60505@oucs.ox.ac.uk> <D29A68F4-0275-449F-8B10-206FA8472DA0@oucs.ox.ac.uk> <4C9F7C47.4010408@ultraslavonic.info> Message-ID: <649CA46B-E522-45F7-A2C0-D0ABDECDFC71@oucs.ox.ac.uk> On 26 Sep 2010, at 18:00, Kevin Hawkins wrote: > > Lou said rolling Tite into the TEI is for future work, but I'm trying to > document such future work in SourceForge right now. So no need to wait! > I think that Lou probably meant to say "drop some of the sillier extensions in Tite and merge in the rest". So looking at new elements ident="cols" * add ident="sub" * add ident="sup" * add ident="ornament" * add ident="b" ident="i" ident="smcap" ident="ul" these remain _so_ much syntactic sugar that I'd be very reluctant to add them. is it really so very hard to simply constrain <hi> to allow only these values on @rend? -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From kevin.s.hawkins at ultraslavonic.info Sun Sep 26 13:19:36 2010 From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins) Date: Sun, 26 Sep 2010 13:19:36 -0400 Subject: [tei-council] multiple namespaces in Tite documents In-Reply-To: <649CA46B-E522-45F7-A2C0-D0ABDECDFC71@oucs.ox.ac.uk> References: <4C9F711D.2090301@ultraslavonic.info> <B8255FEE-52CC-41BA-93DE-2C0C8BCCBA6D@oucs.ox.ac.uk> <4C9F7562.6050700@ultraslavonic.info> <4C9F76AF.60505@oucs.ox.ac.uk> <D29A68F4-0275-449F-8B10-206FA8472DA0@oucs.ox.ac.uk> <4C9F7C47.4010408@ultraslavonic.info> <649CA46B-E522-45F7-A2C0-D0ABDECDFC71@oucs.ox.ac.uk> Message-ID: <4C9F80A8.2020805@ultraslavonic.info> I've added Sebastian's comments to the ticket. Please continue the discussion there so that when we vote on this question, all our notes on the topic are gathered in one place. On 9/26/2010 1:15 PM, Sebastian Rahtz wrote: > > On 26 Sep 2010, at 18:00, Kevin Hawkins wrote: > >> >> Lou said rolling Tite into the TEI is for future work, but I'm trying to >> document such future work in SourceForge right now. So no need to wait! >> > I think that Lou probably meant to say "drop some of the sillier extensions in Tite and merge > in the rest". So looking at new elements > > > ident="cols" > * add > ident="sub" > * add > ident="sup" > * add > ident="ornament" > * add > > ident="b" > ident="i" > ident="smcap" > ident="ul" > > these remain _so_ much syntactic sugar that I'd be very reluctant to add them. is it really so very hard > to simply constrain<hi> to allow only these values on @rend? > > > -- > Sebastian Rahtz > Information Manager, Oxford University Computing Services > 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 > > S?lo le pido a Dios > que el futuro no me sea indiferente > > > > From sebastian.rahtz at oucs.ox.ac.uk Sun Sep 26 13:27:53 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Sun, 26 Sep 2010 18:27:53 +0100 Subject: [tei-council] starting new Roma Message-ID: <93AFB202-35C5-49C6-8146-36845A926AD0@oucs.ox.ac.uk> if any of you feel strong, you may like to test a revised http://http://tei.oucs.ox.ac.uk/Roma/ What's the change, you say? same old manky interface and bugs. But no. This Roma now calls on OxGarage to do its transformations into schemas etc, and that means it uses the XSLT 2.0 stylesheets. When this is rolled out, the whole generation of ODD-processing XSLT 1.0 code will become obsolete at last. The next stage is to get OxGarage running on www.tei-c.org, as at present the service calls on an OxGarage on an unsupported VM in Oxford. -- Sebastian Rahtz Information Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From lou.burnard at oucs.ox.ac.uk Tue Sep 28 11:50:37 2010 From: lou.burnard at oucs.ox.ac.uk (Lou) Date: Tue, 28 Sep 2010 16:50:37 +0100 Subject: [tei-council] @scriptRef etc Message-ID: <4CA20ECD.4000501@oucs.ox.ac.uk> I've now implemented the changes proposed and agreed in sf ticket 2900430 (adding <scriptDesc> and <scriptNote>, @handRef and @scribeRef) Although I've closed the ticket I think the Guidelines really ought to include some examples of a <scriptNote>, if only to clarify usage of this element together with, or as an alternative to <handNote>. Any volunteers? From lou.burnard at oucs.ox.ac.uk Tue Sep 28 12:21:50 2010 From: lou.burnard at oucs.ox.ac.uk (Lou) Date: Tue, 28 Sep 2010 17:21:50 +0100 Subject: [tei-council] <subst> (sf ticket 2859355) Message-ID: <4CA2161E.7070308@oucs.ox.ac.uk> [ I've added the following comment to this ticket, and copy it here for your consideration] At present the content model of <subst> is (model.pPart.transcriptional), (model.pPart.transcriptional)+ and the following are the members of model.pPart.transcriptional: add app corr damage del orig reg restore sic supplied surplus unclear Clearly, this content model permits some things that can't reasonably be interpreted as part of a substitution, e.g. <app> or <corr>, and also some things that might plausibly appear within a substitution without forming part of either its "before" or its "after" such as <unclear> or <surplus>. You might want to say for example <subst><add>foo</add><unclear/><del>bar</del></subst> where the <unclear/> behave just like the bit of text which this ticket proposes should also be allowed. I cannot imagine however what it might mean to say <subst><add>foo</add><orig>fooo</orig><del>bar</del> </subst> or many of the other possibilities offered by this content model. I would *like* to be able to say that the content model should be (as proposed earlier) (text | model.gLike | add | del)* with an additional constraint that says there must be at least one <add> and one <del> . This would have the effect of forcing the encoder to put any of the other transcriptional markup *inside* one or other of the <add> and <del> elements. However this is quite a major change from the current model, so I would appreciate any second thoughts from council members before implementing it. Another thought: should this also allow <addSpan> and <delSpan> ? From James.Cummings at oucs.ox.ac.uk Wed Sep 29 08:37:26 2010 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Wed, 29 Sep 2010 13:37:26 +0100 Subject: [tei-council] <subst> (sf ticket 2859355) In-Reply-To: <4CA2161E.7070308@oucs.ox.ac.uk> References: <4CA2161E.7070308@oucs.ox.ac.uk> Message-ID: <4CA33306.2000403@oucs.ox.ac.uk> Lou wrote: > I would *like* to be able to say that the content model should be (as > proposed earlier) > > (text | model.gLike | add | del)* Playing devil's advocate, if we are allowing text inside so can do: <seg>Je <subst><del>ne</del> suis <del>pas convaincu</del><add>incertain</add></subst></seg> (to steal Gaby's example), then surely this small amount of text might be subject to most of the pPart.transcriptional or indeed pPart.edit elements? i.e. the original might have said 'sius' instead of 'suis' and I want to correct it with <sic> or <corr> (or indeed a <choice>), it might be that the 'ui' of 'suis' is partly illegible so I want <unclear> or any number of other things. I would agree, however, that providing <app> is clearly lunacy (since the better way is to have the subst inside the <rdg>). I'm, not entirely convinced by my line of argument here myself, but think it worth discussing. > Another thought: should this also allow <addSpan> and <delSpan> ? Would it be a requirement that the span be complete inside the <subst> or are we trying to cater for someone deleting (for example) from the middle of a substitution to anywhere else. (In which case, shouldn't things like <anchor> should be allowed inside <subst> in case a different <addSpan> or <delSpan> are ending at some arbitrary point inside the subst?) Slippery slopes ahoy. -James -- Dr James Cummings, Research Technologies Service OUCS, University of Oxford From gabriel.bodard at kcl.ac.uk Wed Sep 29 10:52:38 2010 From: gabriel.bodard at kcl.ac.uk (Gabriel Bodard) Date: Wed, 29 Sep 2010 15:52:38 +0100 Subject: [tei-council] <subst> (sf ticket 2859355) In-Reply-To: <4CA33306.2000403@oucs.ox.ac.uk> References: <4CA2161E.7070308@oucs.ox.ac.uk> <4CA33306.2000403@oucs.ox.ac.uk> Message-ID: <4CA352B6.2020801@kcl.ac.uk> On 29/09/2010 13:37, James Cummings wrote: > <seg>Je<subst><del>ne</del> suis<del>pas > convaincu</del><add>incertain</add></subst></seg> > > (to steal Gaby's example), then surely this small amount of text > might be subject to most of the pPart.transcriptional or indeed > pPart.edit elements? i.e. the original might have said 'sius' > instead of 'suis' and I want to correct it with<sic> or<corr> > (or indeed a<choice>), it might be that the 'ui' of 'suis' is > partly illegible so I want<unclear> or any number of other > things. I would agree, however, that providing<app> is clearly > lunacy (since the better way is to have the subst inside the > <rdg>). I'm, not entirely convinced by my line of argument here > myself, but think it worth discussing. Oh, I *am* completely convinced by your argument here (in fact it is precisely the point I was going to make if I'd had the time before now). if we allow any plain text inside <subst> at all (as we have decided to do), then that text will want to be tagged in all sorts of ways (maybe even as <w> or <name> for example), as well as with all the transcriptional tags that James mentions above. If we don't allow this, then having text in <subst> is (a) not all that useful, and (b) not enough, since we also need to be able, as suggested I think by Syd, to link two or more separate <add> and/or <del> tags as a single action, since the new expanded <subst> won't always be possible. G -- Dr Gabriel BODARD (Epigrapher, Digital Classicist, Pirate) Centre for Computing in the Humanities King's College London 26-29 Drury Lane London WC2B 5RL Email: gabriel.bodard at kcl.ac.uk Tel: +44 (0)20 7848 1388 Fax: +44 (0)20 7848 2980 http://www.digitalclassicist.org/ http://www.currentepigraphy.org/ From laurent.romary at inria.fr Sat Oct 2 00:27:21 2010 From: laurent.romary at inria.fr (Laurent Romary) Date: Sat, 2 Oct 2010 06:27:21 +0200 Subject: [tei-council] Fwd: bug report for Council, if you like References: <799139389.626181.1285991675368.JavaMail.root@zmbs3.inria.fr> Message-ID: <A0E28E2D-2F72-4888-9B0F-8E91EC3FE718@inria.fr> Hi there, Here's a note from Syd complementing a post on SF. Looks like a good point, doesn't it? Laurent D?but du message r?exp?di? : > De : Syd Bauman <Syd_Bauman at Brown.edu> > Date : 2 octobre 2010 05:54:35 GMT+02:00 > ? : Laurent Romary <Laurent.Romary at loria.fr> > Objet : bug report for Council, if you like > R?pondre ? : Syd_Bauman at Brown.edu > > I've just posted a bug report (3079842) which y'all may find easier > to discuss in e-mail, since it is somewhat long and uses formatting > that would be lost in Sourceforge. > > If you'd like to forward this to Council, feel free. If you'd prefer > to leave it to be dealt with only on Sourceforge, that's fine, too. > > --------- > > The declaration of the points= attribute in att.coordinated looks > like it is probably in error, but since there are no examples of > the use of point= anywhere in the Guidelines, and the tagdocs for > att.coordinated, <surface>, and <zone> do not have <listRef>s, it > is hard to be sure. But the prose of the <desc> does say "a > series of pairs of numbers", which gives some help. > > The current declaration is > > attribute points { > list { > xsd:token { pattern = "[d]+,[\d]+([\s]+[\d]+,[\d]+){2,}" }, > xsd:token { pattern = "[d]+,[\d]+([\s]+[\d]+,[\d]+){2,}" }* > } > } > > (Numbers in pointy-brackets refer to productions in > http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/) > There are quite a few confusing constructs in there. First, > putting a single multi-character escape <37> into a character > class expression <12> is odd. Since "\s" is the same as > "[#x20\t\n\r]", saying "[\s]" seems superfluous, and I think it > would match exactly the same set of characters. I may be wrong on > this, though, because I can't get it to match *anything* using > either `jing` or `rnv`. > > The use of "[\d]" is similarly odd. But here, "\d" is the same as > "\p{Nd}", which matches [0-9𝟎-𝟿０-９], > which may not be what TEI wants. Besides the normal range 0-9, > this permits the ten FULLWIDTH DIGIT characters, the ten > MATHEMATICAL BOLD DIGIT characters, the ten MATHEMATICAL > DOUBLE-STRUCK DIGIT characters, the ten MATHEMATICAL SANS-SERIF > DIGIT characters, the ten MATHEMATICAL SANS-SERIF BOLD DIGIT, and > the ten MATHEMATICAL MONOSPACE DIGIT characters. While Unicode > defines these characters as having the appropriate numeric > values, there are still many legacy programming languages that do > not process them correctly. So TEI may wish to consider using > "[0-9]" rather than "\d" (aka "\p{Nd}"). > > But the first atom of the regular expression is "[d]", which > matches the U+0064, LATIN SMALL LETTER D. I'm guessing this is > just a typo for "[\d]" which would match numbers as described in > the previous paragraph. > > If that first atom is intended to match a digit (and thus the > first bit before the comma is supposed to match an integer), then > the entire pattern, it would seem, is intended to match a list of > 3 or more pairs of integers separated by a comma. But the regular > expression is itself in a RELAX NG list of itself followed by > zero or more of itself, and so can be matched 1 or more times. > This duplication -- 1 or more occurrences of 3 or more pairs of > integers -- seems silly, since any number of pairs of integers > will match so long as it's more than 3. > > The RELAX NG list construct is expressed using the maxOccurs= > attribute of the <datatype> element in the ODD. So assuming that > the intent is to match a series of 3 or more pairs of non- > negative integers, I think the TEI has four choices, based on two > binary possibilities: > * express a number using only ASCII digits vs using any Unicode > digits > * express the "3 or more" using the regular expression or using > maxOccurs=. > > In any case, the description should be more clear. "a series of > pairs of numbers" should probably be "a series of 3 or more > comma- separated pairs of non-negative integers". (If I have that > right -- ostensibly because the points are measured in pixels > which can't be measured fractionally, and they always relative to > the containing <surface>, so negative values would be off the > surface, and are thus out of bounds.) Moreover, it should be made > clear whether the numbers are relative to the bounding box, or > just must be within it. > > <!-- ASCII digits, TEI occurrence constraint --> > <datatype minOccurs="3" maxOccurs="unbounded"> > <rng:data type="token"> > <rng:param > name="pattern">[0-9]+,[0-9]+</rng:param> > </rng:data> > </datatype> > > <!-- ASCII digits, XSD occurrence constraint --> > <datatype minOccurs="1" maxOccurs="1"> > <rng:data type="token"> > <rng:param > name="pattern">[0-9]+,[0-9]+(\s+[0-9]+,[0-9]+){2,}</ > rng:param> > </rng:data> > </datatype> > > <!-- Unicode digits, TEI occurrence constraint --> > <datatype minOccurs="3" maxOccurs="unbounded"> > <rng:data type="token"> > <rng:param > name="pattern">[\d]+,[\d]+</rng:param> > </rng:data> > </datatype> > > <!-- Unicode digits, XSD occurrence constraint --> > <datatype minOccurs="1" maxOccurs="1"> > <rng:data type="token"> > <rng:param > name="pattern">[\d]+,[\d]+(\s+[\d]+,[\d]+){2,}</ > rng:param> > </rng:data> > </datatype> > > Personally, I think the best way to go is to define a TEI > datatype (data.point) as > xsd:token { pattern = "[0-9]+,[0-9]+" } > and then use > > <datatype minOccurs="3" maxOccurs="unbounded"> > <rng:ref name="data.point"/> > </datatype> > > Besides being more elegant and generalizable, this means that if > and when Council decides to support the other Unicode digits it > is an easy change. > > --------- Laurent Romary INRIA & HUB-IDSL laurent.romary at inria.fr From lou.burnard at oucs.ox.ac.uk Sat Oct 2 05:00:28 2010 From: lou.burnard at oucs.ox.ac.uk (Lou Burnard) Date: Sat, 02 Oct 2010 10:00:28 +0100 Subject: [tei-council] Fwd: bug report for Council, if you like In-Reply-To: <A0E28E2D-2F72-4888-9B0F-8E91EC3FE718@inria.fr> References: <799139389.626181.1285991675368.JavaMail.root@zmbs3.inria.fr> <A0E28E2D-2F72-4888-9B0F-8E91EC3FE718@inria.fr> Message-ID: <4CA6F4AC.2010000@oucs.ox.ac.uk> On 02/10/10 05:27, Laurent Romary wrote: > Hi there, > Here's a note from Syd complementing a post on SF. Looks like a good > point, doesn't it? > Laurent a good *point* ha ha ha Will deal with the bug report on sf -- don't forget we still have quite a lot of other outstanding issues too... From laurent.romary at inria.fr Sat Oct 2 05:18:19 2010 From: laurent.romary at inria.fr (Laurent Romary) Date: Sat, 2 Oct 2010 11:18:19 +0200 Subject: [tei-council] Fwd: bug report for Council, if you like In-Reply-To: <1336419846.629971.1286010036383.JavaMail.root@zmbs3.inria.fr> References: <799139389.626181.1285991675368.JavaMail.root@zmbs3.inria.fr> <A0E28E2D-2F72-4888-9B0F-8E91EC3FE718@inria.fr> <1336419846.629971.1286010036383.JavaMail.root@zmbs3.inria.fr> Message-ID: <B9EC999F-DCB4-4808-BDF4-7C6E529EE4CC@inria.fr> At least someone gets my jokes in English (relief...). No, not forgotten the 1001 nightmares. Le 2 oct. 10 ? 11:00, Lou Burnard a ?crit : > On 02/10/10 05:27, Laurent Romary wrote: >> Hi there, >> Here's a note from Syd complementing a post on SF. Looks like a good >> point, doesn't it? >> Laurent > > a good *point* ha ha ha > > Will deal with the bug report on sf -- don't forget we still have > quite > a lot of other outstanding issues too... > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Laurent Romary INRIA & HUB-IDSL laurent.romary at inria.fr From sebastian.rahtz at oucs.ox.ac.uk Sat Oct 2 09:37:14 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Sat, 2 Oct 2010 14:37:14 +0100 Subject: [tei-council] Fwd: bug report for Council, if you like In-Reply-To: <A0E28E2D-2F72-4888-9B0F-8E91EC3FE718@inria.fr> References: <799139389.626181.1285991675368.JavaMail.root@zmbs3.inria.fr> <A0E28E2D-2F72-4888-9B0F-8E91EC3FE718@inria.fr> Message-ID: <2148202B-528E-44CF-AAF8-6786BCBA9503@oucs.ox.ac.uk> big black mark against us for not having an example or a test file for this. -- Sebastian Rahtz Information and Support Group Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From sebastian.rahtz at oucs.ox.ac.uk Sat Oct 2 09:42:15 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Sat, 2 Oct 2010 14:42:15 +0100 Subject: [tei-council] Fwd: bug report for Council, if you like In-Reply-To: <A0E28E2D-2F72-4888-9B0F-8E91EC3FE718@inria.fr> References: <799139389.626181.1285991675368.JavaMail.root@zmbs3.inria.fr> <A0E28E2D-2F72-4888-9B0F-8E91EC3FE718@inria.fr> Message-ID: <0125FB49-D9E1-4E7F-A334-D6219B581BD1@oucs.ox.ac.uk> amusing to see that SVG completely wimps out, and uses <!-- a path data specification --> <define name="svg.Points"> <data type="string"/> </define> -- Sebastian Rahtz Information and Support Group Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From sebastian.rahtz at oucs.ox.ac.uk Sat Oct 2 09:58:40 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Sat, 2 Oct 2010 14:58:40 +0100 Subject: [tei-council] Fwd: bug report for Council, if you like In-Reply-To: <A0E28E2D-2F72-4888-9B0F-8E91EC3FE718@inria.fr> References: <799139389.626181.1285991675368.JavaMail.root@zmbs3.inria.fr> <A0E28E2D-2F72-4888-9B0F-8E91EC3FE718@inria.fr> Message-ID: <E7132405-A909-48F7-9869-D271965FA354@oucs.ox.ac.uk> >> >> Personally, I think the best way to go is to define a TEI >> datatype (data.point) as >> xsd:token { pattern = "[0-9]+,[0-9]+" } >> and then use >> >> <datatype minOccurs="3" maxOccurs="unbounded"> >> <rng:ref name="data.point"/> >> </datatype> I do agree with Syd that this is much more readable. However, it (and the existing pattern) fail to take account of the fact that the other attributes in att.coordinated (x1,y1,x2,y2) are expressed as data.numeric, which expands to <rng:choice> <rng:data type="double"/> <rng:data type="token"> <rng:param name="pattern">(\-?[\d]+/\-?[\d]+)</rng:param> </rng:data> <rng:data type="decimal"/> </rng:choice> I do think we must be consistent here, and allow @points to contain negative and fractional numbers. Another worry, which I wonder if we ever discussed, is whether the path describes by @points has to close itself or not. I really am gobsmacked that we let this through without a test file. -- Sebastian Rahtz Information and Support Group Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From mholmes at uvic.ca Sat Oct 2 12:03:28 2010 From: mholmes at uvic.ca (Martin Holmes) Date: Sat, 02 Oct 2010 09:03:28 -0700 Subject: [tei-council] Fwd: bug report for Council, if you like In-Reply-To: <E7132405-A909-48F7-9869-D271965FA354@oucs.ox.ac.uk> References: <799139389.626181.1285991675368.JavaMail.root@zmbs3.inria.fr> <A0E28E2D-2F72-4888-9B0F-8E91EC3FE718@inria.fr> <E7132405-A909-48F7-9869-D271965FA354@oucs.ox.ac.uk> Message-ID: <4CA757D0.1000504@uvic.ca> > I do think we must be consistent here, and allow @points to contain > negative and fractional numbers. I agree on this, both for consistency and because I can imagine use-cases for both. Cheers, Martin On 10-10-02 06:58 AM, Sebastian Rahtz wrote: >>> >>> Personally, I think the best way to go is to define a TEI >>> datatype (data.point) as >>> xsd:token { pattern = "[0-9]+,[0-9]+" } >>> and then use >>> >>> <datatype minOccurs="3" maxOccurs="unbounded"> >>> <rng:ref name="data.point"/> >>> </datatype> > > I do agree with Syd that this is much more readable. However, > it (and the existing pattern) fail to take account of the fact that the > other attributes in att.coordinated (x1,y1,x2,y2) are expressed > as data.numeric, which expands to > > <rng:choice> > <rng:data type="double"/> > <rng:data type="token"> > <rng:param name="pattern">(\-?[\d]+/\-?[\d]+)</rng:param> > </rng:data> > <rng:data type="decimal"/> > </rng:choice> > > I do think we must be consistent here, and allow @points to contain > negative and fractional numbers. > > Another worry, which I wonder if we ever discussed, is whether the path > describes by @points has to close itself or not. > > I really am gobsmacked that we let this through without a test file. > -- > Sebastian Rahtz > Information and Support Group Manager, Oxford University Computing Services > 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 > > S?lo le pido a Dios > que el futuro no me sea indiferente > > > > > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council From sebastian.rahtz at oucs.ox.ac.uk Sat Oct 2 12:20:03 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Sat, 2 Oct 2010 17:20:03 +0100 Subject: [tei-council] Fwd: bug report for Council, if you like In-Reply-To: <4CA757D0.1000504@uvic.ca> References: <799139389.626181.1285991675368.JavaMail.root@zmbs3.inria.fr> <A0E28E2D-2F72-4888-9B0F-8E91EC3FE718@inria.fr> <E7132405-A909-48F7-9869-D271965FA354@oucs.ox.ac.uk> <4CA757D0.1000504@uvic.ca> Message-ID: <0D3FA853-FE6A-4B63-AD7A-8C2A3E285937@oucs.ox.ac.uk> On 2 Oct 2010, at 17:03, Martin Holmes wrote: >> I do think we must be consistent here, and allow @points to contain >> negative and fractional numbers. > > I agree on this, both for consistency and because I can imagine > use-cases for both. > c can you supply an example file, Martin, which exercises negative numbers? what do you think about closing the path? -- Sebastian Rahtz Information and Support Group Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From mholmes at uvic.ca Sun Oct 3 14:13:58 2010 From: mholmes at uvic.ca (Martin Holmes) Date: Sun, 03 Oct 2010 11:13:58 -0700 Subject: [tei-council] Fwd: bug report for Council, if you like In-Reply-To: <0D3FA853-FE6A-4B63-AD7A-8C2A3E285937@oucs.ox.ac.uk> References: <799139389.626181.1285991675368.JavaMail.root@zmbs3.inria.fr> <A0E28E2D-2F72-4888-9B0F-8E91EC3FE718@inria.fr> <E7132405-A909-48F7-9869-D271965FA354@oucs.ox.ac.uk> <4CA757D0.1000504@uvic.ca> <0D3FA853-FE6A-4B63-AD7A-8C2A3E285937@oucs.ox.ac.uk> Message-ID: <4CA8C7E6.8070204@uvic.ca> Hi Sebastian, On 10-10-02 09:20 AM, Sebastian Rahtz wrote: > > On 2 Oct 2010, at 17:03, Martin Holmes wrote: > >>> I do think we must be consistent here, and allow @points to contain >>> negative and fractional numbers. >> >> I agree on this, both for consistency and because I can imagine >> use-cases for both. >> c > > can you supply an example file, Martin, which exercises > negative numbers? I don't have an example of my own, but I could imagine (for instance) a series of <surface> elements that are treated as separate from because there are visible boundaries between them, but which are contiguous, and a <zone> which would run over the boundary between two <surface> elements; you might want to represent the <zone> on the <surface> which contains the largest area of it, and capture the fact that it extends onto a <surface> to the left by using negative coordinates. > what do you think about closing the path? I seem to recall a discussion about this before. Did we not decide that if a path is not closed, it would be deemed closed as if the first point were re-iterated as the last? Cheers, Martin > -- > Sebastian Rahtz > Information and Support Group Manager, Oxford University Computing Services > 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 > > S?lo le pido a Dios > que el futuro no me sea indiferente > > > > > From laurent.romary at inria.fr Mon Oct 4 01:46:41 2010 From: laurent.romary at inria.fr (Laurent Romary) Date: Mon, 4 Oct 2010 07:46:41 +0200 Subject: [tei-council] Fwd: bug report for Council, if you like In-Reply-To: <934077435.652337.1286129642091.JavaMail.root@zmbs3.inria.fr> References: <799139389.626181.1285991675368.JavaMail.root@zmbs3.inria.fr> <A0E28E2D-2F72-4888-9B0F-8E91EC3FE718@inria.fr> <E7132405-A909-48F7-9869-D271965FA354@oucs.ox.ac.uk> <4CA757D0.1000504@uvic.ca> <0D3FA853-FE6A-4B63-AD7A-8C2A3E285937@oucs.ox.ac.uk> <934077435.652337.1286129642091.JavaMail.root@zmbs3.inria.fr> Message-ID: <8BD61CC4-9193-4072-8CF1-67E3A24B0C48@inria.fr> Just pointing to it to confirm this would be the most sensible way to rpoceed. Laurent Le 3 oct. 10 ? 20:14, Martin Holmes a ?crit : >> what do you think about closing the path? > > I seem to recall a discussion about this before. Did we not decide > that > if a path is not closed, it would be deemed closed as if the first > point > were re-iterated as the last? Laurent Romary INRIA & HUB-IDSL laurent.romary at inria.fr From mholmes at uvic.ca Mon Oct 4 13:11:04 2010 From: mholmes at uvic.ca (Martin Holmes) Date: Mon, 4 Oct 2010 10:11:04 -0700 Subject: [tei-council] Fwd: bug report for Council, if you like In-Reply-To: <8BD61CC4-9193-4072-8CF1-67E3A24B0C48@inria.fr> References: <799139389.626181.1285991675368.JavaMail.root@zmbs3.inria.fr> <A0E28E2D-2F72-4888-9B0F-8E91EC3FE718@inria.fr> <E7132405-A909-48F7-9869-D271965FA354@oucs.ox.ac.uk> <4CA757D0.1000504@uvic.ca> <0D3FA853-FE6A-4B63-AD7A-8C2A3E285937@oucs.ox.ac.uk> <934077435.652337.1286129642091.JavaMail.root@zmbs3.inria.fr> <8BD61CC4-9193-4072-8CF1-67E3A24B0C48@inria.fr> Message-ID: <4CAA0AA8.7000806@uvic.ca> I believe I've dredged up the history of this. On the TEI Graphics SIG, in April, I posted this: [quote] HI all, Yesterday I worked out a simple regular expression to validate the content of the proposed @points: [\d]+,[\d]+([\s]+[\d]+,[\d]+){2,} meaning: each point consists of two integers separated by a comma; a points value consists of three or more of these points, separated by a whitespace. However, going back to look at the specification for @svg:points, which was our original model, I realize that it allows negative values as well as positive, and floating-point values as well as integers. Since @ulx and friends are defined as data.numeric, which also allows negatives and floating-point numbers, it would make sense to me that @points allows this too. This is the definition of data.numeric: data.numeric = xsd:double | token { pattern = "(\-?[\d]+/\-?[\d]+)" } | xsd:decimal <http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-data.numeric.html> In view of this, I think @points should be defined as three or more instances of data.numeric, separated by whitespace. What do you think? [/quote] So it seems that I'm the source of the erroneous regexp, but in fact I wasn't proposing that it be adopted; I favoured using three+ instances of data.numeric instead. Both Sebastian and Conal agreed with this. However, on the SF feature request discussion, this doesn't seem to have been considered (presumably my fault -- I did include my faulty regexp in the discussion, but neglected to bring over the resulting discussion from the GRAPHICS SIG. Cheers, Martin Cheers, Martin On 10-10-03 10:46 PM, Laurent Romary wrote: > Just pointing to it to confirm this would be the most sensible way to > rpoceed. > Laurent > > Le 3 oct. 10 ? 20:14, Martin Holmes a ?crit : > >>> what do you think about closing the path? >> >> I seem to recall a discussion about this before. Did we not decide >> that >> if a path is not closed, it would be deemed closed as if the first >> point >> were re-iterated as the last? > > Laurent Romary > INRIA& HUB-IDSL > laurent.romary at inria.fr > > > > -- Martin Holmes University of Victoria Humanities Computing and Media Centre (mholmes at uvic.ca) From mholmes at uvic.ca Mon Oct 4 14:03:00 2010 From: mholmes at uvic.ca (Martin Holmes) Date: Mon, 4 Oct 2010 11:03:00 -0700 Subject: [tei-council] Fwd: bug report for Council, if you like In-Reply-To: <B75D8A15-24ED-4C5C-BD26-70CD2DD5AC5A@retired.ox.ac.uk> References: <799139389.626181.1285991675368.JavaMail.root@zmbs3.inria.fr> <A0E28E2D-2F72-4888-9B0F-8E91EC3FE718@inria.fr> <E7132405-A909-48F7-9869-D271965FA354@oucs.ox.ac.uk> <4CA757D0.1000504@uvic.ca> <0D3FA853-FE6A-4B63-AD7A-8C2A3E285937@oucs.ox.ac.uk> <934077435.652337.1286129642091.JavaMail.root@zmbs3.inria.fr> <8BD61CC4-9193-4072-8CF1-67E3A24B0C48@inria.fr> <4CAA0AA8.7000806@uvic.ca> <B75D8A15-24ED-4C5C-BD26-70CD2DD5AC5A@retired.ox.ac.uk> Message-ID: <4CAA16D4.1040501@uvic.ca> I think we need to decide whether the idea to use data.numeric is a good one or not. Does anyone see any objections? Cheers, Martin On 10-10-04 10:34 AM, Lou Burnard wrote: > thanks for clarifying the history martin... do you think you could update the ticket syd has just submitted with a proposed fix? > > from the pad > > > On 4 Oct 2010, at 18:11, "Martin Holmes"<mholmes at uvic.ca> wrote: > >> I believe I've dredged up the history of this. On the TEI Graphics SIG, >> in April, I posted this: >> >> [quote] >> HI all, >> >> Yesterday I worked out a simple regular expression to validate the >> content of the proposed @points: >> >> [\d]+,[\d]+([\s]+[\d]+,[\d]+){2,} >> >> meaning: >> >> each point consists of two integers separated by a comma; a points value >> consists of three or more of these points, separated by a whitespace. >> >> However, going back to look at the specification for @svg:points, which >> was our original model, I realize that it allows negative values as well >> as positive, and floating-point values as well as integers. >> >> Since @ulx and friends are defined as data.numeric, which also allows >> negatives and floating-point numbers, it would make sense to me that >> @points allows this too. This is the definition of data.numeric: >> >> data.numeric = >> xsd:double | token { pattern = "(\-?[\d]+/\-?[\d]+)" } | xsd:decimal >> >> <http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-data.numeric.html> >> >> In view of this, I think @points should be defined as three or more >> instances of data.numeric, separated by whitespace. What do you think? >> [/quote] >> >> So it seems that I'm the source of the erroneous regexp, but in fact I >> wasn't proposing that it be adopted; I favoured using three+ instances >> of data.numeric instead. Both Sebastian and Conal agreed with this. >> However, on the SF feature request discussion, this doesn't seem to have >> been considered (presumably my fault -- I did include my faulty regexp >> in the discussion, but neglected to bring over the resulting discussion >> from the GRAPHICS SIG. >> >> Cheers, >> Martin >> >> Cheers, >> Martin >> >> >> >> On 10-10-03 10:46 PM, Laurent Romary wrote: >>> Just pointing to it to confirm this would be the most sensible way to >>> rpoceed. >>> Laurent >>> >>> Le 3 oct. 10 ? 20:14, Martin Holmes a ?crit : >>> >>>>> what do you think about closing the path? >>>> >>>> I seem to recall a discussion about this before. Did we not decide >>>> that >>>> if a path is not closed, it would be deemed closed as if the first >>>> point >>>> were re-iterated as the last? >>> >>> Laurent Romary >>> INRIA& HUB-IDSL >>> laurent.romary at inria.fr >>> >>> >>> >>> >> >> -- >> Martin Holmes >> University of Victoria Humanities Computing and Media Centre >> (mholmes at uvic.ca) >> _______________________________________________ >> tei-council mailing list >> tei-council at lists.village.Virginia.EDU >> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council -- Martin Holmes University of Victoria Humanities Computing and Media Centre (mholmes at uvic.ca) From mholmes at uvic.ca Mon Oct 4 15:53:46 2010 From: mholmes at uvic.ca (Martin Holmes) Date: Mon, 4 Oct 2010 12:53:46 -0700 Subject: [tei-council] Fwd: bug report for Council, if you like In-Reply-To: <E98F2222-F6FB-46CC-940C-862B629845A2@retired.ox.ac.uk> References: <799139389.626181.1285991675368.JavaMail.root@zmbs3.inria.fr> <A0E28E2D-2F72-4888-9B0F-8E91EC3FE718@inria.fr> <E7132405-A909-48F7-9869-D271965FA354@oucs.ox.ac.uk> <4CA757D0.1000504@uvic.ca> <0D3FA853-FE6A-4B63-AD7A-8C2A3E285937@oucs.ox.ac.uk> <934077435.652337.1286129642091.JavaMail.root@zmbs3.inria.fr> <8BD61CC4-9193-4072-8CF1-67E3A24B0C48@inria.fr> <4CAA0AA8.7000806@uvic.ca> <B75D8A15-24ED-4C5C-BD26-70CD2DD5AC5A@retired.ox.ac.uk> <4CAA16D4.1040501@uvic.ca> <E98F2222-F6FB-46CC-940C-862B629845A2@retired.ox.ac.uk> Message-ID: <4CAA30CA.7050408@uvic.ca> On 10-10-04 12:43 PM, Lou Burnard wrote: > as noted before using data.numeric would be consistent with > svg:points and also with what we currently allow for coordinate > points on zone etc. so i say go for that. Right. So the only remaining question is one Sebastian raised, and which I couldn't find the answer to in our previous correspondence: do we: a) Require that the last component of a polygon be identical to the first, thus closing the polygon, and deem the attribute value invalid if this is not the case; or b) Deem any attribute value whose final coordinate is not identical to its first to be closed anyway, thus assuming the existence of the final point where it is not explicit; or c) Allow that some shapes may not be closed (in other words, they may be paths), and therefore assume that any shape not explicitly closed is open. Thoughts? My instinct is to be permissive and choose c), but then we have the issue of possible conflict between the definition of a <zone> and the idea of a path. That's somewhat moot anyway, because the current definition of a <zone> is inconsistent with @points: <zone> defines a rectangular area contained within a surface element. Cheers, Martin > > > from the pad > > > On 4 Oct 2010, at 19:03, "Martin Holmes"<mholmes at uvic.ca> wrote: > >> I think we need to decide whether the idea to use data.numeric is a >> good one or not. Does anyone see any objections? >> >> Cheers, Martin >> >> On 10-10-04 10:34 AM, Lou Burnard wrote: >>> thanks for clarifying the history martin... do you think you >>> could update the ticket syd has just submitted with a proposed >>> fix? >>> >>> from the pad >>> >>> >>> On 4 Oct 2010, at 18:11, "Martin Holmes"<mholmes at uvic.ca> >>> wrote: >>> >>>> I believe I've dredged up the history of this. On the TEI >>>> Graphics SIG, in April, I posted this: >>>> >>>> [quote] HI all, >>>> >>>> Yesterday I worked out a simple regular expression to validate >>>> the content of the proposed @points: >>>> >>>> [\d]+,[\d]+([\s]+[\d]+,[\d]+){2,} >>>> >>>> meaning: >>>> >>>> each point consists of two integers separated by a comma; a >>>> points value consists of three or more of these points, >>>> separated by a whitespace. >>>> >>>> However, going back to look at the specification for >>>> @svg:points, which was our original model, I realize that it >>>> allows negative values as well as positive, and floating-point >>>> values as well as integers. >>>> >>>> Since @ulx and friends are defined as data.numeric, which also >>>> allows negatives and floating-point numbers, it would make >>>> sense to me that @points allows this too. This is the >>>> definition of data.numeric: >>>> >>>> data.numeric = xsd:double | token { pattern = >>>> "(\-?[\d]+/\-?[\d]+)" } | xsd:decimal >>>> >>>> <http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-data.numeric.html> >>>> >>>> >>>> In view of this, I think @points should be defined as three or more >>>> instances of data.numeric, separated by whitespace. What do you >>>> think? [/quote] >>>> >>>> So it seems that I'm the source of the erroneous regexp, but in >>>> fact I wasn't proposing that it be adopted; I favoured using >>>> three+ instances of data.numeric instead. Both Sebastian and >>>> Conal agreed with this. However, on the SF feature request >>>> discussion, this doesn't seem to have been considered >>>> (presumably my fault -- I did include my faulty regexp in the >>>> discussion, but neglected to bring over the resulting >>>> discussion from the GRAPHICS SIG. >>>> >>>> Cheers, Martin >>>> >>>> Cheers, Martin >>>> >>>> >>>> >>>> On 10-10-03 10:46 PM, Laurent Romary wrote: >>>>> Just pointing to it to confirm this would be the most >>>>> sensible way to rpoceed. Laurent >>>>> >>>>> Le 3 oct. 10 ? 20:14, Martin Holmes a ?crit : >>>>> >>>>>>> what do you think about closing the path? >>>>>> >>>>>> I seem to recall a discussion about this before. Did we not >>>>>> decide that if a path is not closed, it would be deemed >>>>>> closed as if the first point were re-iterated as the last? >>>>> >>>>> Laurent Romary INRIA& HUB-IDSL laurent.romary at inria.fr >>>>> >>>>> >>>>> >>>>> >>>> >>>> -- Martin Holmes University of Victoria Humanities Computing >>>> and Media Centre (mholmes at uvic.ca) >>>> _______________________________________________ tei-council >>>> mailing list tei-council at lists.village.Virginia.EDU >>>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council >> >> -- Martin Holmes University of Victoria Humanities Computing and >> Media Centre (mholmes at uvic.ca) >> _______________________________________________ tei-council mailing >> list tei-council at lists.village.Virginia.EDU >> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council -- Martin Holmes University of Victoria Humanities Computing and Media Centre (mholmes at uvic.ca) From sebastian.rahtz at oucs.ox.ac.uk Mon Oct 4 17:33:28 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 4 Oct 2010 22:33:28 +0100 Subject: [tei-council] Fwd: bug report for Council, if you like In-Reply-To: <4CAA0AA8.7000806@uvic.ca> References: <799139389.626181.1285991675368.JavaMail.root@zmbs3.inria.fr> <A0E28E2D-2F72-4888-9B0F-8E91EC3FE718@inria.fr> <E7132405-A909-48F7-9869-D271965FA354@oucs.ox.ac.uk> <4CA757D0.1000504@uvic.ca> <0D3FA853-FE6A-4B63-AD7A-8C2A3E285937@oucs.ox.ac.uk> <934077435.652337.1286129642091.JavaMail.root@zmbs3.inria.fr> <8BD61CC4-9193-4072-8CF1-67E3A24B0C48@inria.fr> <4CAA0AA8.7000806@uvic.ca> Message-ID: <843CCA7F-0496-46D1-94C2-0D370A0312A3@oucs.ox.ac.uk> surely you don't mean 3+ instances of data.numeric? because each instance must be a _pair_, not a single number. I think Syd's suggestion of a data.point parallel to data.numeric is cleaner. -- Sebastian Rahtz Information and Support Group Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From sebastian.rahtz at oucs.ox.ac.uk Mon Oct 4 17:42:03 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 4 Oct 2010 22:42:03 +0100 Subject: [tei-council] Fwd: bug report for Council, if you like In-Reply-To: <4CAA30CA.7050408@uvic.ca> References: <799139389.626181.1285991675368.JavaMail.root@zmbs3.inria.fr> <A0E28E2D-2F72-4888-9B0F-8E91EC3FE718@inria.fr> <E7132405-A909-48F7-9869-D271965FA354@oucs.ox.ac.uk> <4CA757D0.1000504@uvic.ca> <0D3FA853-FE6A-4B63-AD7A-8C2A3E285937@oucs.ox.ac.uk> <934077435.652337.1286129642091.JavaMail.root@zmbs3.inria.fr> <8BD61CC4-9193-4072-8CF1-67E3A24B0C48@inria.fr> <4CAA0AA8.7000806@uvic.ca> <B75D8A15-24ED-4C5C-BD26-70CD2DD5AC5A@retired.ox.ac.uk> <4CAA16D4.1040501@uvic.ca> <E98F2222-F6FB-46CC-940C-862B629845A2@retired.ox.ac.uk> <4CAA30CA.7050408@uvic.ca> Message-ID: <7D9F3FC1-1A59-4B16-AAC1-0BE921D7EC92@oucs.ox.ac.uk> On 4 Oct 2010, at 20:53, Martin Holmes wrote: > a) Require that the last component of a polygon be identical to the > first, thus closing the polygon, and deem the attribute value invalid if > this is not the case; or > > b) Deem any attribute value whose final coordinate is not identical to > its first to be closed anyway, thus assuming the existence of the final > point where it is not explicit; or > > c) Allow that some shapes may not be closed (in other words, they may be > paths), and therefore assume that any shape not explicitly closed is open. My inclination is b), for common sense. If we need to add paths later, we can do so, but at the moment we are dealing with enclosing shapes. I think the "close all paths" rule is fairly common and unlikely to surprise anyone. Its also the way SVG polygons work, which is our model. -- Sebastian Rahtz Information and Support Group Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From sebastian.rahtz at oucs.ox.ac.uk Mon Oct 4 17:45:37 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 4 Oct 2010 22:45:37 +0100 Subject: [tei-council] Fwd: bug report for Council, if you like In-Reply-To: <94EF3C68-A483-4F1C-86B2-ECD55A646863@retired.ox.ac.uk> References: <799139389.626181.1285991675368.JavaMail.root@zmbs3.inria.fr> <A0E28E2D-2F72-4888-9B0F-8E91EC3FE718@inria.fr> <E7132405-A909-48F7-9869-D271965FA354@oucs.ox.ac.uk> <4CA757D0.1000504@uvic.ca> <0D3FA853-FE6A-4B63-AD7A-8C2A3E285937@oucs.ox.ac.uk> <934077435.652337.1286129642091.JavaMail.root@zmbs3.inria.fr> <8BD61CC4-9193-4072-8CF1-67E3A24B0C48@inria.fr> <4CAA0AA8.7000806@uvic.ca> <843CCA7F-0496-46D1-94C2-0D370A0312A3@oucs.ox.ac.uk> <94EF3C68-A483-4F1C-86B2-ECD55A646863@retired.ox.ac.uk> Message-ID: <19F99974-17FF-4DDD-8656-1CAD3F0C9F92@oucs.ox.ac.uk> On 4 Oct 2010, at 22:40, Lou Burnard wrote: > doh. yes indeed. so we define data.point as a pair of data.numeric values, and we define @points as at least three data.points yes. a point is a pair of comma-separated data.numerics > > i think the geneticians want to use this attribute to record wavy lines as well as polygons, so maybe we should not assume that it is necessarily a closed shape? don't confuse the attribute with the container * zone/@points defines an enclosing shape *WhatEverGeneticsWants/@points can define a line but we should not allow Geneticist's to use <surface> for their line, I would suggest. Either way, the definition of @points is not affected. -- Sebastian Rahtz Information and Support Group Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From mholmes at uvic.ca Mon Oct 4 18:37:05 2010 From: mholmes at uvic.ca (Martin Holmes) Date: Mon, 4 Oct 2010 15:37:05 -0700 Subject: [tei-council] Fwd: bug report for Council, if you like In-Reply-To: <843CCA7F-0496-46D1-94C2-0D370A0312A3@oucs.ox.ac.uk> References: <799139389.626181.1285991675368.JavaMail.root@zmbs3.inria.fr> <A0E28E2D-2F72-4888-9B0F-8E91EC3FE718@inria.fr> <E7132405-A909-48F7-9869-D271965FA354@oucs.ox.ac.uk> <4CA757D0.1000504@uvic.ca> <0D3FA853-FE6A-4B63-AD7A-8C2A3E285937@oucs.ox.ac.uk> <934077435.652337.1286129642091.JavaMail.root@zmbs3.inria.fr> <8BD61CC4-9193-4072-8CF1-67E3A24B0C48@inria.fr> <4CAA0AA8.7000806@uvic.ca> <843CCA7F-0496-46D1-94C2-0D370A0312A3@oucs.ox.ac.uk> Message-ID: <4CAA5711.6070909@uvic.ca> On 10-10-04 02:33 PM, Sebastian Rahtz wrote: > surely you don't mean 3+ instances of data.numeric? because each instance must be a _pair_, not a single number. No, of course -- 3+ pairs of data.numeric. Cheers, Martin > I think Syd's suggestion of a data.point parallel to data.numeric is cleaner. > -- > Sebastian Rahtz > Information and Support Group Manager, Oxford University Computing Services > 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 > > S?lo le pido a Dios > que el futuro no me sea indiferente > > > > > > -- Martin Holmes University of Victoria Humanities Computing and Media Centre (mholmes at uvic.ca) From James.Cummings at oucs.ox.ac.uk Mon Oct 4 18:55:32 2010 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Mon, 04 Oct 2010 23:55:32 +0100 Subject: [tei-council] Fwd: bug report for Council, if you like In-Reply-To: <4CAA30CA.7050408@uvic.ca> References: <799139389.626181.1285991675368.JavaMail.root@zmbs3.inria.fr> <A0E28E2D-2F72-4888-9B0F-8E91EC3FE718@inria.fr> <E7132405-A909-48F7-9869-D271965FA354@oucs.ox.ac.uk> <4CA757D0.1000504@uvic.ca> <0D3FA853-FE6A-4B63-AD7A-8C2A3E285937@oucs.ox.ac.uk> <934077435.652337.1286129642091.JavaMail.root@zmbs3.inria.fr> <8BD61CC4-9193-4072-8CF1-67E3A24B0C48@inria.fr> <4CAA0AA8.7000806@uvic.ca> <B75D8A15-24ED-4C5C-BD26-70CD2DD5AC5A@retired.ox.ac.uk> <4CAA16D4.1040501@uvic.ca> <E98F2222-F6FB-46CC-940C-862B629845A2@retired.ox.ac.uk> <4CAA30CA.7050408@uvic.ca> Message-ID: <4CAA5B64.6030308@oucs.ox.ac.uk> On 04/10/10 20:53, Martin Holmes wrote: > Right. So the only remaining question is one Sebastian raised, and which > I couldn't find the answer to in our previous correspondence: do we: > > a) Require that the last component of a polygon be identical to the > first, thus closing the polygon, and deem the attribute value invalid if > this is not the case; or > > b) Deem any attribute value whose final coordinate is not identical to > its first to be closed anyway, thus assuming the existence of the final > point where it is not explicit; or > > c) Allow that some shapes may not be closed (in other words, they may be > paths), and therefore assume that any shape not explicitly closed is open. > > Thoughts? My instinct is to be permissive and choose c), but then we > have the issue of possible conflict between the definition of a<zone> > and the idea of a path. That's somewhat moot anyway, because the current > definition of a<zone> is inconsistent with @points: I would also say c). I think the TEI should be providing the general solution here for both paths and areas. I think having a) or b) is a matter for local encoding guidelines and/or processing. I recognise that b) is probably the most common way it would be used, but don't see how it really benefits us to make this a requirement rather than just a common practice. -James -- Dr James Cummings Research Technologies Service, University of Oxford From sebastian.rahtz at oucs.ox.ac.uk Mon Oct 4 19:04:06 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 5 Oct 2010 00:04:06 +0100 Subject: [tei-council] Fwd: bug report for Council, if you like In-Reply-To: <4CAA5B64.6030308@oucs.ox.ac.uk> References: <799139389.626181.1285991675368.JavaMail.root@zmbs3.inria.fr> <A0E28E2D-2F72-4888-9B0F-8E91EC3FE718@inria.fr> <E7132405-A909-48F7-9869-D271965FA354@oucs.ox.ac.uk> <4CA757D0.1000504@uvic.ca> <0D3FA853-FE6A-4B63-AD7A-8C2A3E285937@oucs.ox.ac.uk> <934077435.652337.1286129642091.JavaMail.root@zmbs3.inria.fr> <8BD61CC4-9193-4072-8CF1-67E3A24B0C48@inria.fr> <4CAA0AA8.7000806@uvic.ca> <B75D8A15-24ED-4C5C-BD26-70CD2DD5AC5A@retired.ox.ac.uk> <4CAA16D4.1040501@uvic.ca> <E98F2222-F6FB-46CC-940C-862B629845A2@retired.ox.ac.uk> <4CAA30CA.7050408@uvic.ca> <4CAA5B64.6030308@oucs.ox.ac.uk> Message-ID: <2D39B494-5B5B-4523-AB4F-88D2131BAD51@oucs.ox.ac.uk> > > I would also say c). I think the TEI should be providing the general > solution here for both paths and areas. I think having a) or b) is a > matter for local encoding guidelines and/or processing. I recognise > that b) is probably the most common way it would be used, but don't see > how it really benefits us to make this a requirement rather than just a > common practice. A vote for c) for zone means extra work for you in all xising situations, adding that final point... Spqr From laurent.romary at inria.fr Tue Oct 5 09:30:48 2010 From: laurent.romary at inria.fr (Laurent Romary) Date: Tue, 5 Oct 2010 15:30:48 +0200 Subject: [tei-council] Adopt a feature! Outstanding work items for Council consideration Message-ID: <6494CDC6-0D3F-4930-9406-6DB91473BED2@inria.fr> Dear all, Here's a list of about a dozen short items which need some further thought and discussion before they can be implemented (or not) as updates to the Guidelines. If we were having a FTF meeting, I'd suggest breakout groups to deal with them, but since I don't see any such meeting in the near future, instead I propose a CALL FOR NUNCLES. A NUNCLE takes responsibility for looking at an item, and in consultation with his or her FELLOW NUNCLE then makes a specific recommendation for change (or not) which the rest of the council can vote on. There are 12 Council members, so if each volunteers to NUNCLE twice, it should be possible easily to fill each of the nine slots below with at least two nuncles. 1. further attributes for imprecise numerical values 3060909: add attribute for non-numeric characterisation of precision 3060919: add way of expressing confidence for att.ranging values 2. further features for personographies 3060874: @source and @code for <faith> 3060867: Grouping elements for traitlike, statelike, and eventlike elements 3. proposed clarificatory text for some tecnical issues 3051750: Form of words needs to be proposed (schema langs) 2493417: Ibid (idno) 4. bibliographic issues 2976715: resp -> model.respLike in biblStruct. and other things. 2987832: date within biblStruct Further recommendations arising from the working paper on bibliographic description 5. ODD issues 2994685: att.global shd be explicit in ODD source 1933481: @status attribute to indicate deprecated elements 6. multimedia issues 2724992: features for alignment of audio and video 2507305: alignment and documentation of sound files 7. New "object" element 2811239: "object" element 8. Generic dating class 2925145: generic dating class 9. Specific recommendations arising from the Genetic Editing workpaper 2834511: make more spanning elements And yes, my English has improved a lot recently ;-) Laurent Laurent Romary INRIA & HUB-IDSL laurent.romary at inria.fr From mholmes at uvic.ca Tue Oct 5 11:28:20 2010 From: mholmes at uvic.ca (Martin Holmes) Date: Tue, 5 Oct 2010 08:28:20 -0700 Subject: [tei-council] Adopt a feature! Outstanding work items for Council consideration In-Reply-To: <6494CDC6-0D3F-4930-9406-6DB91473BED2@inria.fr> References: <6494CDC6-0D3F-4930-9406-6DB91473BED2@inria.fr> Message-ID: <4CAB4414.6020806@uvic.ca> I would think that Kevin and I could take the bibliographic items, but I'm not sure what stage our previous work is at. IIRC we're waiting for Lou to make some changes and then kick back several issues to us so that we can make more specific proposals for revisions, but I haven't heard anything about this process for a while. Cheers, Martin On 10-10-05 06:30 AM, Laurent Romary wrote: > Dear all, > > Here's a list of about a dozen short items which need some further > thought > and discussion before they can be implemented (or not) as updates to > the Guidelines. > > If we were having a FTF meeting, I'd suggest breakout groups to deal > with them, but since I don't see any such meeting in the near future, > instead I propose a CALL FOR NUNCLES. A NUNCLE takes responsibility for > looking at an item, and in consultation with his or her FELLOW NUNCLE > then makes a specific recommendation for change (or not) which the rest > of the council can vote on. > > There are 12 Council members, so if each volunteers to NUNCLE twice, > it should be possible easily to fill each of the nine slots below with > at least two nuncles. > > > 1. further attributes for imprecise numerical values > > 3060909: add attribute for non-numeric characterisation of precision > 3060919: add way of expressing confidence for att.ranging values > > 2. further features for personographies > > 3060874: @source and @code for<faith> > 3060867: Grouping elements for traitlike, statelike, and eventlike > elements > > 3. proposed clarificatory text for some tecnical issues > > 3051750: Form of words needs to be proposed (schema langs) > 2493417: Ibid (idno) > > 4. bibliographic issues > > 2976715: resp -> model.respLike in biblStruct. and other things. > 2987832: date within biblStruct > Further recommendations arising from the working paper on > bibliographic description > > 5. ODD issues > > 2994685: att.global shd be explicit in ODD source > 1933481: @status attribute to indicate deprecated elements > > 6. multimedia issues > > 2724992: features for alignment of audio and video > 2507305: alignment and documentation of sound files > > 7. New "object" element > > 2811239: "object" element > > 8. Generic dating class > > 2925145: generic dating class > > 9. Specific recommendations arising from the Genetic Editing workpaper > > 2834511: make more spanning elements > > > And yes, my English has improved a lot recently ;-) > Laurent > > > Laurent Romary > INRIA& HUB-IDSL > laurent.romary at inria.fr > > > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > . > -- Martin Holmes University of Victoria Humanities Computing and Media Centre (mholmes at uvic.ca) From gabriel.bodard at kcl.ac.uk Tue Oct 5 13:39:25 2010 From: gabriel.bodard at kcl.ac.uk (Gabriel Bodard) Date: Tue, 5 Oct 2010 18:39:25 +0100 Subject: [tei-council] Fwd: bug report for Council, if you like In-Reply-To: <4CAA5B64.6030308@oucs.ox.ac.uk> References: <799139389.626181.1285991675368.JavaMail.root@zmbs3.inria.fr> <A0E28E2D-2F72-4888-9B0F-8E91EC3FE718@inria.fr> <E7132405-A909-48F7-9869-D271965FA354@oucs.ox.ac.uk> <4CA757D0.1000504@uvic.ca> <0D3FA853-FE6A-4B63-AD7A-8C2A3E285937@oucs.ox.ac.uk> <934077435.652337.1286129642091.JavaMail.root@zmbs3.inria.fr> <8BD61CC4-9193-4072-8CF1-67E3A24B0C48@inria.fr> <4CAA0AA8.7000806@uvic.ca> <B75D8A15-24ED-4C5C-BD26-70CD2DD5AC5A@retired.ox.ac.uk> <4CAA16D4.1040501@uvic.ca> <E98F2222-F6FB-46CC-940C-862B629845A2@retired.ox.ac.uk> <4CAA30CA.7050408@uvic.ca> <4CAA5B64.6030308@oucs.ox.ac.uk> Message-ID: <4CAB62CD.6000308@kcl.ac.uk> I think my instinct would be to go with (b) and, as Sebastian says, worry about paths when and if they're needed. But perhaps the easiest is just to say definitely not (a) (so no validation), but allow individual implementations to assume (b) or (c) as appropriate. On 04/10/2010 23:55, James Cummings wrote: > On 04/10/10 20:53, Martin Holmes wrote: >> Right. So the only remaining question is one Sebastian raised, and which >> I couldn't find the answer to in our previous correspondence: do we: >> >> a) Require that the last component of a polygon be identical to the >> first, thus closing the polygon, and deem the attribute value invalid if >> this is not the case; or >> >> b) Deem any attribute value whose final coordinate is not identical to >> its first to be closed anyway, thus assuming the existence of the final >> point where it is not explicit; or >> >> c) Allow that some shapes may not be closed (in other words, they may be >> paths), and therefore assume that any shape not explicitly closed is open. >> >> Thoughts? My instinct is to be permissive and choose c), but then we >> have the issue of possible conflict between the definition of a<zone> >> and the idea of a path. That's somewhat moot anyway, because the current >> definition of a<zone> is inconsistent with @points: > > I would also say c). I think the TEI should be providing the general > solution here for both paths and areas. I think having a) or b) is a > matter for local encoding guidelines and/or processing. I recognise > that b) is probably the most common way it would be used, but don't see > how it really benefits us to make this a requirement rather than just a > common practice. > > -James > -- Dr Gabriel BODARD (Epigrapher, Digital Classicist, Pirate) Centre for Computing in the Humanities King's College London 26-29 Drury Lane London WC2B 5RL Email: gabriel.bodard at kcl.ac.uk Tel: +44 (0)20 7848 1388 Fax: +44 (0)20 7848 2980 http://www.digitalclassicist.org/ http://www.currentepigraphy.org/ From James.Cummings at oucs.ox.ac.uk Tue Oct 5 13:42:34 2010 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Tue, 05 Oct 2010 18:42:34 +0100 Subject: [tei-council] Fwd: bug report for Council, if you like In-Reply-To: <2D39B494-5B5B-4523-AB4F-88D2131BAD51@oucs.ox.ac.uk> References: <799139389.626181.1285991675368.JavaMail.root@zmbs3.inria.fr> <A0E28E2D-2F72-4888-9B0F-8E91EC3FE718@inria.fr> <E7132405-A909-48F7-9869-D271965FA354@oucs.ox.ac.uk> <4CA757D0.1000504@uvic.ca> <0D3FA853-FE6A-4B63-AD7A-8C2A3E285937@oucs.ox.ac.uk> <934077435.652337.1286129642091.JavaMail.root@zmbs3.inria.fr> <8BD61CC4-9193-4072-8CF1-67E3A24B0C48@inria.fr> <4CAA0AA8.7000806@uvic.ca> <B75D8A15-24ED-4C5C-BD26-70CD2DD5AC5A@retired.ox.ac.uk> <4CAA16D4.1040501@uvic.ca> <E98F2222-F6FB-46CC-940C-862B629845A2@retired.ox.ac.uk> <4CAA30CA.7050408@uvic.ca> <4CAA5B64.6030308@oucs.ox.ac.uk> <2D39B494-5B5B-4523-AB4F-88D2131BAD51@oucs.ox.ac.uk> Message-ID: <4CAB638A.3060608@oucs.ox.ac.uk> On 05/10/10 00:04, Sebastian Rahtz wrote: > > >> >> I would also say c). I think the TEI should be providing the general >> solution here for both paths and areas. I think having a) or b) is a >> matter for local encoding guidelines and/or processing. I recognise >> that b) is probably the most common way it would be used, but don't see >> how it really benefits us to make this a requirement rather than just a >> common practice. > > A vote for c) for zone means extra work for you in all xising situations, adding that final point... I recognise that, but I still feel it is the more general solutions and fits more with the way TEI tends to do something. Ok, *I* might add a schematron rule that insists that last point be the same as the first.. and in fact I think that would be a good example to have available to the community...but in my old age I get worried about nailing things down too tight. -James -- Dr James Cummings Research Technologies Service, University of Oxford From sebastian.rahtz at oucs.ox.ac.uk Tue Oct 5 13:45:21 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 5 Oct 2010 18:45:21 +0100 Subject: [tei-council] Fwd: bug report for Council, if you like In-Reply-To: <4CAB62CD.6000308@kcl.ac.uk> References: <799139389.626181.1285991675368.JavaMail.root@zmbs3.inria.fr> <A0E28E2D-2F72-4888-9B0F-8E91EC3FE718@inria.fr> <E7132405-A909-48F7-9869-D271965FA354@oucs.ox.ac.uk> <4CA757D0.1000504@uvic.ca> <0D3FA853-FE6A-4B63-AD7A-8C2A3E285937@oucs.ox.ac.uk> <934077435.652337.1286129642091.JavaMail.root@zmbs3.inria.fr> <8BD61CC4-9193-4072-8CF1-67E3A24B0C48@inria.fr> <4CAA0AA8.7000806@uvic.ca> <B75D8A15-24ED-4C5C-BD26-70CD2DD5AC5A@retired.ox.ac.uk> <4CAA16D4.1040501@uvic.ca> <E98F2222-F6FB-46CC-940C-862B629845A2@retired.ox.ac.uk> <4CAA30CA.7050408@uvic.ca> <4CAA5B64.6030308@oucs.ox.ac.uk> <4CAB62CD.6000308@kcl.ac.uk> Message-ID: <14B040A5-61CD-4AB2-BC11-D5DBA014B8D5@oucs.ox.ac.uk> On 5 Oct 2010, at 18:39, Gabriel Bodard wrote: > I think my instinct would be to go with (b) and, as Sebastian says, > worry about paths when and if they're needed. But perhaps the easiest is > just to say definitely not (a) (so no validation), but allow individual > implementations to assume (b) or (c) as appropriate. I'd go with this - ie let sleeping dogges lie. Much the easiest solution. -- Sebastian Rahtz Information and Support Group Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From sebastian.rahtz at oucs.ox.ac.uk Tue Oct 5 13:46:01 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 5 Oct 2010 18:46:01 +0100 Subject: [tei-council] Adopt a feature! Outstanding work items for Council consideration In-Reply-To: <6494CDC6-0D3F-4930-9406-6DB91473BED2@inria.fr> References: <6494CDC6-0D3F-4930-9406-6DB91473BED2@inria.fr> Message-ID: <B53F83C9-9013-4F99-BE2D-1BBB83F2E823@oucs.ox.ac.uk> With the caveat that we should not expect to have this work completed in time for the November release, I think? -- Sebastian Rahtz Information and Support Group Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From James.Cummings at oucs.ox.ac.uk Tue Oct 5 13:47:31 2010 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Tue, 05 Oct 2010 18:47:31 +0100 Subject: [tei-council] Fwd: bug report for Council, if you like In-Reply-To: <14B040A5-61CD-4AB2-BC11-D5DBA014B8D5@oucs.ox.ac.uk> References: <799139389.626181.1285991675368.JavaMail.root@zmbs3.inria.fr> <A0E28E2D-2F72-4888-9B0F-8E91EC3FE718@inria.fr> <E7132405-A909-48F7-9869-D271965FA354@oucs.ox.ac.uk> <4CA757D0.1000504@uvic.ca> <0D3FA853-FE6A-4B63-AD7A-8C2A3E285937@oucs.ox.ac.uk> <934077435.652337.1286129642091.JavaMail.root@zmbs3.inria.fr> <8BD61CC4-9193-4072-8CF1-67E3A24B0C48@inria.fr> <4CAA0AA8.7000806@uvic.ca> <B75D8A15-24ED-4C5C-BD26-70CD2DD5AC5A@retired.ox.ac.uk> <4CAA16D4.1040501@uvic.ca> <E98F2222-F6FB-46CC-940C-862B629845A2@retired.ox.ac.uk> <4CAA30CA.7050408@uvic.ca> <4CAA5B64.6030308@oucs.ox.ac.uk> <4CAB62CD.6000308@kcl.ac.uk> <14B040A5-61CD-4AB2-BC11-D5DBA014B8D5@oucs.ox.ac.uk> Message-ID: <4CAB64B3.1040700@oucs.ox.ac.uk> On 05/10/10 18:45, Sebastian Rahtz wrote: > > On 5 Oct 2010, at 18:39, Gabriel Bodard wrote: > >> I think my instinct would be to go with (b) and, as Sebastian says, >> worry about paths when and if they're needed. But perhaps the easiest is >> just to say definitely not (a) (so no validation), but allow individual >> implementations to assume (b) or (c) as appropriate. > > > I'd go with this - ie let sleeping dogges lie. Much the easiest solution. I'm amenable to that. Though I should think at note should make this clear. -James -- Dr James Cummings Research Technologies Service, University of Oxford From James.Cummings at oucs.ox.ac.uk Tue Oct 5 13:50:37 2010 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Tue, 05 Oct 2010 18:50:37 +0100 Subject: [tei-council] Adopt a feature! Outstanding work items for Council consideration In-Reply-To: <6494CDC6-0D3F-4930-9406-6DB91473BED2@inria.fr> References: <6494CDC6-0D3F-4930-9406-6DB91473BED2@inria.fr> Message-ID: <4CAB656D.8060200@oucs.ox.ac.uk> On 05/10/10 14:30, Laurent Romary wrote: > There are 12 Council members, so if each volunteers to NUNCLE twice, > it should be possible easily to fill each of the nine slots below with > at least two nuncles. I volunteer for: > 5. ODD issues > > 2994685: att.global shd be explicit in ODD source > 1933481: @status attribute to indicate deprecated elements -James -- Dr James Cummings Research Technologies Service, University of Oxford From sebastian.rahtz at oucs.ox.ac.uk Tue Oct 5 18:17:30 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 5 Oct 2010 23:17:30 +0100 Subject: [tei-council] Adopt a feature! Outstanding work items for Council consideration In-Reply-To: <6494CDC6-0D3F-4930-9406-6DB91473BED2@inria.fr> References: <6494CDC6-0D3F-4930-9406-6DB91473BED2@inria.fr> Message-ID: <A79568CD-89F4-47BD-A13F-CDA7F6AE0154@oucs.ox.ac.uk> On 5 Oct 2010, at 14:30, Laurent Romary wrote: > > 2. further features for personographies > > 3060874: @source and @code for <faith> > 3060867: Grouping elements for traitlike, statelike, and eventlike > elements > I can imagine looking at these -- Sebastian Rahtz Information and Support Group Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From lou.burnard at oucs.ox.ac.uk Wed Oct 6 06:25:35 2010 From: lou.burnard at oucs.ox.ac.uk (Lou Burnard) Date: Wed, 06 Oct 2010 11:25:35 +0100 Subject: [tei-council] Adopt a feature! Outstanding work items for Council consideration In-Reply-To: <B53F83C9-9013-4F99-BE2D-1BBB83F2E823@oucs.ox.ac.uk> References: <6494CDC6-0D3F-4930-9406-6DB91473BED2@inria.fr> <B53F83C9-9013-4F99-BE2D-1BBB83F2E823@oucs.ox.ac.uk> Message-ID: <4CAC4E9F.6020001@oucs.ox.ac.uk> On 05/10/10 18:46, Sebastian Rahtz wrote: > With the caveat that we should not expect to have this work completed in time for the November release, I think? > -- That's true for some of these, but not all I think. And since some of these issues have been sitting around in limbo for a very long time. I think we should at least be able to characterise each of them (i.e. either implemented , to be implemented, or definitively to be kicked into the long grass) in time for the next release. Wouldn't it be nice to say at the Members Meeting "here's the list of areas we're going to be acting on in the near future" as well as "here's the list of bug fixes"? I note that those of you who have volunteered so far have only volunteered for one item. I think the master plan was for everyone to volunteer for TWO nuncleships, so that everyone dealing with a given issue would have at least one other person to talk to. Myself, I'm up for: 2. further features for personographies 9. Specific recommendations arising from the Genetic Editing workpaper There's also the four or five items which we didn't agree on during the last voting round. From julianne.nyhan at gmail.com Wed Oct 6 07:42:04 2010 From: julianne.nyhan at gmail.com (Julianne Nyhan) Date: Wed, 6 Oct 2010 12:42:04 +0100 Subject: [tei-council] Adopt a feature! Outstanding work items for Council consideration In-Reply-To: <4CAC4E9F.6020001@oucs.ox.ac.uk> References: <6494CDC6-0D3F-4930-9406-6DB91473BED2@inria.fr> <B53F83C9-9013-4F99-BE2D-1BBB83F2E823@oucs.ox.ac.uk> <4CAC4E9F.6020001@oucs.ox.ac.uk> Message-ID: <AANLkTikPdxAygOeW8zx2LccM3hG3MQjTTe_GespwjTwy@mail.gmail.com> Hi, I'm up for: 3. proposed clarificatory text for some tecnical issues 3051750: Form of words needs to be proposed (schema langs) 2493417: Ibid (idno) Best, Julianne On Wed, Oct 6, 2010 at 11:25 AM, Lou Burnard <lou.burnard at oucs.ox.ac.uk>wrote: > On 05/10/10 18:46, Sebastian Rahtz wrote: > > With the caveat that we should not expect to have this work completed in > time for the November release, I think? > > -- > > That's true for some of these, but not all I think. And since some of > these issues have been sitting around in limbo for a very long time. I > think we should at least be able to characterise each of them (i.e. > either implemented , to be implemented, or definitively to be kicked > into the long grass) in time for the next release. Wouldn't it be nice > to say at the Members Meeting "here's the list of areas we're going to > be acting on in the near future" as well as "here's the list of bug fixes"? > > I note that those of you who have volunteered so far have only > volunteered for one item. I think the master plan was for everyone to > volunteer for TWO nuncleships, so that everyone dealing with a given > issue would have at least one other person to talk to. > > Myself, I'm up for: > > 2. further features for personographies > > 9. Specific recommendations arising from the Genetic Editing workpaper > > There's also the four or five items which we didn't agree on during the > last voting round. > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > -- Dr Julianne Nyhan, Kompetenzzentrum f?r elektronische Erschlie?ungs- und Publikationsverfahren in den Geisteswissenschaften Universit?t Trier Fachbereich II / Germanistik Universit?tsring 15 54286 Trier + 49 (0)651 201-3358 http://germazope.uni-trier.de/Projects/KoZe2/ http://epu.ucc.ie/theses/jnyhan/ http://maney.co.uk/index.php/journals/isr/ http://www.tei-c.org/Activities/SIG/Education/index.xml From gabriel.bodard at kcl.ac.uk Wed Oct 6 08:04:21 2010 From: gabriel.bodard at kcl.ac.uk (Gabriel Bodard) Date: Wed, 6 Oct 2010 13:04:21 +0100 Subject: [tei-council] Adopt a feature! Outstanding work items for Council consideration In-Reply-To: <6494CDC6-0D3F-4930-9406-6DB91473BED2@inria.fr> References: <6494CDC6-0D3F-4930-9406-6DB91473BED2@inria.fr> Message-ID: <4CAC65C5.5080308@kcl.ac.uk> I'll volunteer to nuncle 1. (imprecise numerical values) and perhaps 2. (personographies). Thought I shouldn't nuncle my own ticket, I would like to contribute to the discussion of 7. (object) if the two nucles involved want to get in touch. G On 05/10/2010 14:30, Laurent Romary wrote: > Dear all, > > Here's a list of about a dozen short items which need some further > thought > and discussion before they can be implemented (or not) as updates to > the Guidelines. > > If we were having a FTF meeting, I'd suggest breakout groups to deal > with them, but since I don't see any such meeting in the near future, > instead I propose a CALL FOR NUNCLES. A NUNCLE takes responsibility for > looking at an item, and in consultation with his or her FELLOW NUNCLE > then makes a specific recommendation for change (or not) which the rest > of the council can vote on. > > There are 12 Council members, so if each volunteers to NUNCLE twice, > it should be possible easily to fill each of the nine slots below with > at least two nuncles. > > > 1. further attributes for imprecise numerical values > > 3060909: add attribute for non-numeric characterisation of precision > 3060919: add way of expressing confidence for att.ranging values > > 2. further features for personographies > > 3060874: @source and @code for<faith> > 3060867: Grouping elements for traitlike, statelike, and eventlike > elements > > 3. proposed clarificatory text for some tecnical issues > > 3051750: Form of words needs to be proposed (schema langs) > 2493417: Ibid (idno) > > 4. bibliographic issues > > 2976715: resp -> model.respLike in biblStruct. and other things. > 2987832: date within biblStruct > Further recommendations arising from the working paper on > bibliographic description > > 5. ODD issues > > 2994685: att.global shd be explicit in ODD source > 1933481: @status attribute to indicate deprecated elements > > 6. multimedia issues > > 2724992: features for alignment of audio and video > 2507305: alignment and documentation of sound files > > 7. New "object" element > > 2811239: "object" element > > 8. Generic dating class > > 2925145: generic dating class > > 9. Specific recommendations arising from the Genetic Editing workpaper > > 2834511: make more spanning elements > > > And yes, my English has improved a lot recently ;-) > Laurent > > > Laurent Romary > INRIA& HUB-IDSL > laurent.romary at inria.fr > > > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council -- Dr Gabriel BODARD (Epigrapher, Digital Classicist, Pirate) Centre for Computing in the Humanities King's College London 26-29 Drury Lane London WC2B 5RL Email: gabriel.bodard at kcl.ac.uk Tel: +44 (0)20 7848 1388 Fax: +44 (0)20 7848 2980 http://www.digitalclassicist.org/ http://www.currentepigraphy.org/ From dot.porter at gmail.com Wed Oct 6 08:19:50 2010 From: dot.porter at gmail.com (Dot Porter) Date: Wed, 6 Oct 2010 08:19:50 -0400 Subject: [tei-council] Adopt a feature! Outstanding work items for Council consideration In-Reply-To: <4CAC65C5.5080308@kcl.ac.uk> References: <6494CDC6-0D3F-4930-9406-6DB91473BED2@inria.fr> <4CAC65C5.5080308@kcl.ac.uk> Message-ID: <AANLkTinzcMKN3n-n=ek4-3fMKS9dQca6z-j7ROXfFH-1@mail.gmail.com> I'll nuncle 7. New "object" element 2811239: "object" element 9. Specific recommendations arising from the Genetic Editing workpaper 2834511: make more spanning elements Gabby, myself and the other nuncle for #7 (I don't think anyone else has volunteered for that one yet) will be in touch with you! Dot On Wed, Oct 6, 2010 at 8:04 AM, Gabriel Bodard <gabriel.bodard at kcl.ac.uk> wrote: > I'll volunteer to nuncle 1. (imprecise numerical values) and perhaps 2. > (personographies). > > Thought I shouldn't nuncle my own ticket, I would like to contribute to > the discussion of 7. (object) if the two nucles involved want to get in > touch. > > G > > On 05/10/2010 14:30, Laurent Romary wrote: >> Dear all, >> >> Here's a list of about a dozen short items which need some further >> thought >> and discussion before they can be implemented (or not) as updates to >> the Guidelines. >> >> If we were having a FTF meeting, I'd suggest breakout groups to deal >> with them, but since I don't see any such meeting in the near future, >> instead I propose a CALL FOR NUNCLES. A NUNCLE takes responsibility for >> looking at an item, and in consultation with his or her FELLOW NUNCLE >> then makes a specific recommendation for change (or not) which the rest >> of the council can vote on. >> >> There are 12 Council members, so if each volunteers to NUNCLE twice, >> it should be possible easily to fill each of the nine slots below with >> at least two nuncles. >> >> >> 1. further attributes for imprecise numerical values >> >> 3060909: add attribute for non-numeric characterisation of precision >> 3060919: add way of expressing confidence for att.ranging values >> >> 2. further features for personographies >> >> 3060874: @source and @code for<faith> >> 3060867: Grouping elements for traitlike, statelike, and eventlike >> elements >> >> 3. proposed clarificatory text for some tecnical issues >> >> 3051750: Form of words needs to be proposed (schema langs) >> 2493417: Ibid (idno) >> >> 4. bibliographic issues >> >> 2976715: resp -> ?model.respLike in biblStruct. and other things. >> 2987832: date within biblStruct >> Further recommendations arising from the working paper on >> bibliographic description >> >> 5. ODD issues >> >> 2994685: att.global shd be explicit in ODD source >> 1933481: @status attribute to indicate deprecated elements >> >> 6. multimedia issues >> >> 2724992: features for alignment of audio and video >> 2507305: alignment and documentation of sound files >> >> 7. New "object" element >> >> 2811239: "object" element >> >> 8. Generic dating class >> >> 2925145: generic dating class >> >> 9. Specific recommendations arising from the Genetic Editing workpaper >> >> 2834511: make more spanning elements >> >> >> And yes, my English has improved a lot recently ;-) >> Laurent >> >> >> Laurent Romary >> INRIA& ?HUB-IDSL >> laurent.romary at inria.fr >> >> >> >> _______________________________________________ >> tei-council mailing list >> tei-council at lists.village.Virginia.EDU >> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > > -- > Dr Gabriel BODARD > (Epigrapher, Digital Classicist, Pirate) > > Centre for Computing in the Humanities > King's College London > 26-29 Drury Lane > London WC2B 5RL > Email: gabriel.bodard at kcl.ac.uk > Tel: +44 (0)20 7848 1388 > Fax: +44 (0)20 7848 2980 > > http://www.digitalclassicist.org/ > http://www.currentepigraphy.org/ > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > -- *~*~*~*~*~*~*~*~*~*~* Dot Porter (MA, MSLS) Digital Medievalist, Digital Librarian Email: dot.porter at gmail.com *~*~*~*~*~*~*~*~*~*~* From bbarney2 at unlnotes.unl.edu Wed Oct 6 12:56:49 2010 From: bbarney2 at unlnotes.unl.edu (Brett Barney) Date: Wed, 6 Oct 2010 11:56:49 -0500 Subject: [tei-council] Fw: Adopt a feature! Outstanding work items for Council consideration Message-ID: <OFC10E349C.C0791C93-ON862577B4.005D07FA-862577B4.005D17DA@unl.edu> Lou's comment made me realize that my reply must have gone to Laurent rather than to the list. Sorry. Brett ----- Forwarded by Brett Barney/Library/UNL/UNEBR on 10/06/2010 11:16 AM ----- |------------> | From: | |------------> >--------------------------------------------------------------------------------------------------------------------------------------------------| |Brett Barney/Library/UNL/UNEBR | >--------------------------------------------------------------------------------------------------------------------------------------------------| |------------> | To: | |------------> >--------------------------------------------------------------------------------------------------------------------------------------------------| |Laurent Romary <laurent.romary at inria.fr> | >--------------------------------------------------------------------------------------------------------------------------------------------------| |------------> | Date: | |------------> >--------------------------------------------------------------------------------------------------------------------------------------------------| |10/05/2010 05:05 PM | >--------------------------------------------------------------------------------------------------------------------------------------------------| |------------> | Subject: | |------------> >--------------------------------------------------------------------------------------------------------------------------------------------------| |Re: [tei-council] Adopt a feature! Outstanding work items for Council consideration | >--------------------------------------------------------------------------------------------------------------------------------------------------| I could be persuaded to work on #3 and #7. Brett |------------> | From: | |------------> >--------------------------------------------------------------------------------------------------------------------------------------------------| |Laurent Romary <laurent.romary at inria.fr> | >--------------------------------------------------------------------------------------------------------------------------------------------------| |------------> | To: | |------------> >--------------------------------------------------------------------------------------------------------------------------------------------------| |TEI Council <tei-council at lists.village.Virginia.EDU> | >--------------------------------------------------------------------------------------------------------------------------------------------------| |------------> | Date: | |------------> >--------------------------------------------------------------------------------------------------------------------------------------------------| |10/05/2010 08:31 AM | >--------------------------------------------------------------------------------------------------------------------------------------------------| |------------> | Subject: | |------------> >--------------------------------------------------------------------------------------------------------------------------------------------------| |[tei-council] Adopt a feature! Outstanding work items for Council consideration | >--------------------------------------------------------------------------------------------------------------------------------------------------| Dear all, Here's a list of about a dozen short items which need some further thought and discussion before they can be implemented (or not) as updates to the Guidelines. If we were having a FTF meeting, I'd suggest breakout groups to deal with them, but since I don't see any such meeting in the near future, instead I propose a CALL FOR NUNCLES. A NUNCLE takes responsibility for looking at an item, and in consultation with his or her FELLOW NUNCLE then makes a specific recommendation for change (or not) which the rest of the council can vote on. There are 12 Council members, so if each volunteers to NUNCLE twice, it should be possible easily to fill each of the nine slots below with at least two nuncles. 1. further attributes for imprecise numerical values 3060909: add attribute for non-numeric characterisation of precision 3060919: add way of expressing confidence for att.ranging values 2. further features for personographies 3060874: @source and @code for <faith> 3060867: Grouping elements for traitlike, statelike, and eventlike elements 3. proposed clarificatory text for some tecnical issues 3051750: Form of words needs to be proposed (schema langs) 2493417: Ibid (idno) 4. bibliographic issues 2976715: resp -> model.respLike in biblStruct. and other things. 2987832: date within biblStruct Further recommendations arising from the working paper on bibliographic description 5. ODD issues 2994685: att.global shd be explicit in ODD source 1933481: @status attribute to indicate deprecated elements 6. multimedia issues 2724992: features for alignment of audio and video 2507305: alignment and documentation of sound files 7. New "object" element 2811239: "object" element 8. Generic dating class 2925145: generic dating class 9. Specific recommendations arising from the Genetic Editing workpaper 2834511: make more spanning elements And yes, my English has improved a lot recently ;-) Laurent Laurent Romary INRIA & HUB-IDSL laurent.romary at inria.fr _______________________________________________ tei-council mailing list tei-council at lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council -------------- next part -------------- A non-text attachment was scrubbed... Name: ecblank.gif Type: image/gif Size: 45 bytes Desc: not available Url : http://lists.village.Virginia.EDU/pipermail/tei-council/attachments/20101006/74d6e6e9/attachment.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: graycol.gif Type: image/gif Size: 105 bytes Desc: not available Url : http://lists.village.Virginia.EDU/pipermail/tei-council/attachments/20101006/74d6e6e9/attachment-0001.gif From bbarney2 at unlnotes.unl.edu Wed Oct 6 12:58:15 2010 From: bbarney2 at unlnotes.unl.edu (Brett Barney) Date: Wed, 6 Oct 2010 11:58:15 -0500 Subject: [tei-council] Nuncle? Message-ID: <OFF01EBFAB.F7053C1E-ON862577B4.005D209A-862577B4.005D3988@unl.edu> I'm having trouble sending to the list (pilot error, no doubt), but in the event this goes through: Would someone mind glossing this word? I have an uneasy feeling that it might mean something to my European colleagues beyond what it means to me, and I want to have as clear an understanding of my role as possible. Thanks, Brett From kevin.s.hawkins at ultraslavonic.info Wed Oct 6 13:00:17 2010 From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins) Date: Wed, 06 Oct 2010 13:00:17 -0400 Subject: [tei-council] Nuncle? In-Reply-To: <OFF01EBFAB.F7053C1E-ON862577B4.005D209A-862577B4.005D3988@unl.edu> References: <OFF01EBFAB.F7053C1E-ON862577B4.005D209A-862577B4.005D3988@unl.edu> Message-ID: <4CACAB21.70708@ultraslavonic.info> I'll second that motion. I've been wondering how come Laurent now speaks English better than I do! On 10/6/2010 12:58 PM, Brett Barney wrote: > > > I'm having trouble sending to the list (pilot error, no doubt), but in the > event this goes through: Would someone mind glossing this word? I have an > uneasy feeling that it might mean something to my European colleagues > beyond what it means to me, and I want to have as clear an understanding of > my role as possible. > > Thanks, > Brett > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council From lou.burnard at oucs.ox.ac.uk Wed Oct 6 13:04:38 2010 From: lou.burnard at oucs.ox.ac.uk (Lou) Date: Wed, 06 Oct 2010 18:04:38 +0100 Subject: [tei-council] Nuncle? In-Reply-To: <4CACAB21.70708@ultraslavonic.info> References: <OFF01EBFAB.F7053C1E-ON862577B4.005D209A-862577B4.005D3988@unl.edu> <4CACAB21.70708@ultraslavonic.info> Message-ID: <4CACAC26.20000@oucs.ox.ac.uk> http://www.thefreedictionary.com/nuncle (though the OED is rather more informative) Kevin Hawkins wrote: > I'll second that motion. I've been wondering how come Laurent now > speaks English better than I do! > > On 10/6/2010 12:58 PM, Brett Barney wrote: >> >> I'm having trouble sending to the list (pilot error, no doubt), but in the >> event this goes through: Would someone mind glossing this word? I have an >> uneasy feeling that it might mean something to my European colleagues >> beyond what it means to me, and I want to have as clear an understanding of >> my role as possible. >> >> Thanks, >> Brett >> _______________________________________________ >> tei-council mailing list >> tei-council at lists.village.Virginia.EDU >> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council From lou.burnard at oucs.ox.ac.uk Wed Oct 6 13:06:23 2010 From: lou.burnard at oucs.ox.ac.uk (Lou) Date: Wed, 06 Oct 2010 18:06:23 +0100 Subject: [tei-council] Nuncle? In-Reply-To: <4CACAC26.20000@oucs.ox.ac.uk> References: <OFF01EBFAB.F7053C1E-ON862577B4.005D209A-862577B4.005D3988@unl.edu> <4CACAB21.70708@ultraslavonic.info> <4CACAC26.20000@oucs.ox.ac.uk> Message-ID: <4CACAC8F.7000707@oucs.ox.ac.uk> see also http://www.urbandictionary.com/define.php?term=Nuncle Lou wrote: > http://www.thefreedictionary.com/nuncle > > (though the OED is rather more informative) > > > > Kevin Hawkins wrote: >> I'll second that motion. I've been wondering how come Laurent now >> speaks English better than I do! >> >> On 10/6/2010 12:58 PM, Brett Barney wrote: >>> I'm having trouble sending to the list (pilot error, no doubt), but in the >>> event this goes through: Would someone mind glossing this word? I have an >>> uneasy feeling that it might mean something to my European colleagues >>> beyond what it means to me, and I want to have as clear an understanding of >>> my role as possible. >>> >>> Thanks, >>> Brett >>> _______________________________________________ >>> tei-council mailing list >>> tei-council at lists.village.Virginia.EDU >>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council >> _______________________________________________ >> tei-council mailing list >> tei-council at lists.village.Virginia.EDU >> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council From laurent.romary at inria.fr Wed Oct 6 14:31:16 2010 From: laurent.romary at inria.fr (Laurent Romary) Date: Wed, 6 Oct 2010 20:31:16 +0200 Subject: [tei-council] Nuncle? In-Reply-To: <588886926.1111170.1286384444577.JavaMail.root@zmbs3.inria.fr> References: <OFF01EBFAB.F7053C1E-ON862577B4.005D209A-862577B4.005D3988@unl.edu> <588886926.1111170.1286384444577.JavaMail.root@zmbs3.inria.fr> Message-ID: <FBEC3A84-2550-4C59-B08C-244CE6CAE5BE@inria.fr> You're mean Kevin ;-) and you know I have a very good margin of progression... Le 6 oct. 10 ? 19:00, Kevin Hawkins a ?crit : > I'll second that motion. I've been wondering how come Laurent now > speaks English better than I do! > > On 10/6/2010 12:58 PM, Brett Barney wrote: >> >> >> I'm having trouble sending to the list (pilot error, no doubt), but >> in the >> event this goes through: Would someone mind glossing this word? I >> have an >> uneasy feeling that it might mean something to my European colleagues >> beyond what it means to me, and I want to have as clear an >> understanding of >> my role as possible. >> >> Thanks, >> Brett >> _______________________________________________ >> tei-council mailing list >> tei-council at lists.village.Virginia.EDU >> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Laurent Romary INRIA & HUB-IDSL laurent.romary at inria.fr From mjd at hum.ku.dk Wed Oct 6 14:49:00 2010 From: mjd at hum.ku.dk (Matthew James Driscoll) Date: Wed, 6 Oct 2010 20:49:00 +0200 Subject: [tei-council] Nuncle? In-Reply-To: <4CACAB21.70708@ultraslavonic.info> References: <OFF01EBFAB.F7053C1E-ON862577B4.005D209A-862577B4.005D3988@unl.edu>, <4CACAB21.70708@ultraslavonic.info> Message-ID: <CF2BD0FB82A2624EA40D0EE4379C896D7925DB3906@post> Well, its old King Lear, ennit? (And an example of the same phenomenon as we get in the nicknames Nan, Ned etc.) Now me, I'd be happy to be anybody's nuncle, but I'm about to embark on an epic journey to faraway Madison, Wisconsin, from whence I may never return (I mean, one never knows). But I'll see what I can do. Matthew ________________________________________ From: tei-council-bounces at lists.village.Virginia.EDU [tei-council-bounces at lists.village.Virginia.EDU] On Behalf Of Kevin Hawkins [kevin.s.hawkins at ultraslavonic.info] Sent: 06 October 2010 19:00 To: tei-council at lists.village.Virginia.EDU Subject: Re: [tei-council] Nuncle? I'll second that motion. I've been wondering how come Laurent now speaks English better than I do! On 10/6/2010 12:58 PM, Brett Barney wrote: > > > I'm having trouble sending to the list (pilot error, no doubt), but in the > event this goes through: Would someone mind glossing this word? I have an > uneasy feeling that it might mean something to my European colleagues > beyond what it means to me, and I want to have as clear an understanding of > my role as possible. > > Thanks, > Brett > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council _______________________________________________ tei-council mailing list tei-council at lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council From daniel.odonnell at uleth.ca Wed Oct 6 16:31:08 2010 From: daniel.odonnell at uleth.ca (O'Donnell, Dan) Date: Wed, 06 Oct 2010 14:31:08 -0600 Subject: [tei-council] Nuncle? In-Reply-To: <CF2BD0FB82A2624EA40D0EE4379C896D7925DB3906@post> References: <OFF01EBFAB.F7053C1E-ON862577B4.005D209A-862577B4.005D3988@unl.edu>, <4CACAB21.70708@ultraslavonic.info> <CF2BD0FB82A2624EA40D0EE4379C896D7925DB3906@post> Message-ID: <4CACDC8C.9050900@uleth.ca> Don't do it Matthew. Nobody ever returns from Madison... at least not as the same person they were going out. On 10-10-06 12:49 PM, Matthew James Driscoll wrote: > Well, its old King Lear, ennit? (And an example of the same phenomenon as we get in the nicknames Nan, Ned etc.) > > Now me, I'd be happy to be anybody's nuncle, but I'm about to embark on an epic journey to faraway Madison, Wisconsin, from whence I may never return (I mean, one never knows). > > But I'll see what I can do. > > Matthew > ________________________________________ > From: tei-council-bounces at lists.village.Virginia.EDU [tei-council-bounces at lists.village.Virginia.EDU] On Behalf Of Kevin Hawkins [kevin.s.hawkins at ultraslavonic.info] > Sent: 06 October 2010 19:00 > To: tei-council at lists.village.Virginia.EDU > Subject: Re: [tei-council] Nuncle? > > I'll second that motion. I've been wondering how come Laurent now > speaks English better than I do! > > On 10/6/2010 12:58 PM, Brett Barney wrote: > >> >> I'm having trouble sending to the list (pilot error, no doubt), but in the >> event this goes through: Would someone mind glossing this word? I have an >> uneasy feeling that it might mean something to my European colleagues >> beyond what it means to me, and I want to have as clear an understanding of >> my role as possible. >> >> Thanks, >> Brett >> _______________________________________________ >> tei-council mailing list >> tei-council at lists.village.Virginia.EDU >> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council >> > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > -- Daniel Paul O'Donnell Professor of English University of Lethbridge Chair and CEO, Text Encoding Initiative (http://www.tei-c.org/) Co-Chair, Digital Initiatives Advisory Board, Medieval Academy of America President-elect (English), Society for Digital Humanities/Soci?t? pour l'?tude des m?dias interactifs (http://sdh-semi.org/) Founding Director (2003-2009), Digital Medievalist Project (http://www.digitalmedievalist.org/) Vox: +1 403 329-2377 Fax: +1 403 382-7191 (non-confidential) Home Page: http://people.uleth.ca/~daniel.odonnell/ From sebastian.rahtz at oucs.ox.ac.uk Wed Oct 6 17:04:52 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Wed, 6 Oct 2010 22:04:52 +0100 Subject: [tei-council] Adopt a feature! Outstanding work items for Council consideration In-Reply-To: <4CAC4E9F.6020001@oucs.ox.ac.uk> References: <6494CDC6-0D3F-4930-9406-6DB91473BED2@inria.fr> <B53F83C9-9013-4F99-BE2D-1BBB83F2E823@oucs.ox.ac.uk> <4CAC4E9F.6020001@oucs.ox.ac.uk> Message-ID: <A1B8A30C-C359-42F3-B62C-598384F25C26@oucs.ox.ac.uk> On 6 Oct 2010, at 11:25, Lou Burnard wrote: > On 05/10/10 18:46, Sebastian Rahtz wrote: >> With the caveat that we should not expect to have this work completed in time for the November release, I think? >> -- > > That's true for some of these, but not all I think. So long as we remember that the current drop dead date is October 15th; all right for you folk with all the leisure in the world, but for others..... > And since some of > these issues have been sitting around in limbo for a very long time. I > think we should at least be able to characterise each of them (i.e. > either implemented , to be implemented, or definitively to be kicked > into the long grass) in time for the next release. I do agree with that > Wouldn't it be nice > to say at the Members Meeting "here's the list of areas we're going to > be acting on in the near future" as well as "here's the list of bug fixes"? Indeed. Does Laurent have a script ready to deliver at Zadar? will it have more Shaykespehereean jokes? is someone collating these nuncle land grabs? -- Sebastian Rahtz Information and Support Group Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From lou.burnard at oucs.ox.ac.uk Wed Oct 6 17:14:03 2010 From: lou.burnard at oucs.ox.ac.uk (Lou Burnard) Date: Wed, 06 Oct 2010 22:14:03 +0100 Subject: [tei-council] Adopt a feature! Outstanding work items for Council consideration In-Reply-To: <A1B8A30C-C359-42F3-B62C-598384F25C26@oucs.ox.ac.uk> References: <6494CDC6-0D3F-4930-9406-6DB91473BED2@inria.fr> <B53F83C9-9013-4F99-BE2D-1BBB83F2E823@oucs.ox.ac.uk> <4CAC4E9F.6020001@oucs.ox.ac.uk> <A1B8A30C-C359-42F3-B62C-598384F25C26@oucs.ox.ac.uk> Message-ID: <4CACE69B.50802@oucs.ox.ac.uk> On 06/10/10 22:04, Sebastian Rahtz wrote: > > is someone collating these nuncle land grabs? yuss, me. From sebastian.rahtz at oucs.ox.ac.uk Wed Oct 6 17:15:07 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Wed, 6 Oct 2010 22:15:07 +0100 Subject: [tei-council] Adopt a feature! Outstanding work items for Council consideration In-Reply-To: <4CACE69B.50802@oucs.ox.ac.uk> References: <6494CDC6-0D3F-4930-9406-6DB91473BED2@inria.fr> <B53F83C9-9013-4F99-BE2D-1BBB83F2E823@oucs.ox.ac.uk> <4CAC4E9F.6020001@oucs.ox.ac.uk> <A1B8A30C-C359-42F3-B62C-598384F25C26@oucs.ox.ac.uk> <4CACE69B.50802@oucs.ox.ac.uk> Message-ID: <A226694C-1F73-42BE-81DF-60EE587E7D08@oucs.ox.ac.uk> On 6 Oct 2010, at 22:14, Lou Burnard wrote: > On 06/10/10 22:04, Sebastian Rahtz wrote: >> >> is someone collating these nuncle land grabs? > > yuss, me. > the Mrs Joyful prize for raffia work is on its way -- Sebastian Rahtz Information and Support Group Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From sebastian.rahtz at oucs.ox.ac.uk Wed Oct 6 17:24:07 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Wed, 6 Oct 2010 22:24:07 +0100 Subject: [tei-council] Adopt a feature! Outstanding work items for Council consideration In-Reply-To: <4CACE736.2040406@oucs.ox.ac.uk> References: <6494CDC6-0D3F-4930-9406-6DB91473BED2@inria.fr> <B53F83C9-9013-4F99-BE2D-1BBB83F2E823@oucs.ox.ac.uk> <4CAC4E9F.6020001@oucs.ox.ac.uk> <A1B8A30C-C359-42F3-B62C-598384F25C26@oucs.ox.ac.uk> <4CACE69B.50802@oucs.ox.ac.uk> <A226694C-1F73-42BE-81DF-60EE587E7D08@oucs.ox.ac.uk> <4CACE736.2040406@oucs.ox.ac.uk> Message-ID: <18D98C63-6DA4-4C30-9427-7A25397D4411@oucs.ox.ac.uk> Some amongst you may need to consult http://everything2.com/title/Nigel+Molesworth to understand my remark about Mrs Joyful. The Molesworth books are essential reading for anyone who wishes to understand what makes Lou and I the way we are today. -- Sebastian Rahtz Information and Support Group Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From elena.pierazzo at kcl.ac.uk Thu Oct 7 12:29:11 2010 From: elena.pierazzo at kcl.ac.uk (Elena Pierazzo) Date: Thu, 7 Oct 2010 17:29:11 +0100 Subject: [tei-council] Adopt a feature! Outstanding work items for Council consideration In-Reply-To: <6494CDC6-0D3F-4930-9406-6DB91473BED2@inria.fr> References: <6494CDC6-0D3F-4930-9406-6DB91473BED2@inria.fr> Message-ID: <4CADF557.7090304@kcl.ac.uk> Better late than never, I suppose. Sorry for my silence this days, fighting for not drowning! > 7. New "object" element > > 2811239: "object" element and > 9. Specific recommendations arising from the Genetic Editing workpaper > > 2834511: make more spanning elements > > Here are my NUNCLES Elena -- Dr Elena Pierazzo Research Associate Centre for Computing in the Humanities King's College London 26-29 Drury Lane London WC2B 5RL Phone: 0207-848-1949 Fax: 0207-848-2980 elena.pierazzo[at]kcl.ac.uk www.kcl.ac.uk/cch From gabriel.bodard at kcl.ac.uk Wed Oct 13 11:56:06 2010 From: gabriel.bodard at kcl.ac.uk (Gabriel Bodard) Date: Wed, 13 Oct 2010 16:56:06 +0100 Subject: [tei-council] Two music FRs Message-ID: <4CB5D696.6050305@kcl.ac.uk> The TEI Music SIG have just submitted two Feature Requests via SourceForge (https://sourceforge.net/tracker/?func=detail&aid=3086720&group_id=106328&atid=644065 and https://sourceforge.net/tracker/?func=detail&aid=3086726&group_id=106328&atid=644065). Is it two late to get these included in the discussion in the next couple weeks? Gabby -- Dr Gabriel BODARD (Epigrapher, Digital Classicist, Pirate) Centre for Computing in the Humanities King's College London 26-29 Drury Lane London WC2B 5RL Email: gabriel.bodard at kcl.ac.uk Tel: +44 (0)20 7848 1388 Fax: +44 (0)20 7848 2980 http://www.digitalclassicist.org/ http://www.currentepigraphy.org/ From James.Cummings at oucs.ox.ac.uk Wed Oct 13 12:21:37 2010 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Wed, 13 Oct 2010 17:21:37 +0100 Subject: [tei-council] Two music FRs In-Reply-To: <4CB5D696.6050305@kcl.ac.uk> References: <4CB5D696.6050305@kcl.ac.uk> Message-ID: <4CB5DC91.1020603@oucs.ox.ac.uk> Gabriel Bodard wrote: > The TEI Music SIG have just submitted two Feature Requests via > SourceForge > (https://sourceforge.net/tracker/?func=detail&aid=3086720&group_id=106328&atid=644065 > and > https://sourceforge.net/tracker/?func=detail&aid=3086726&group_id=106328&atid=644065). > Is it two late to get these included in the discussion in the next > couple weeks? One of these is fairly uncontroversial (the first) which the MEI people are adamant that the 'musicNotation' element is really mis-named. It contains a description of the musical notation in the manuscript and not music notation itself. They argue that in parallel to its siblings (like sealDesc, bindingDesc, etc.) that this really should be either musicDesc or musicNotationDesc. The latter of these is preferred by them because it is a description of the music notation (since manuscripts don't contain music, they only contain music notation... ignoring embedding mp3s in modern manuscripts for now). I think that is either a yes/no based on how serious a breakage of backwards compatibility this is. The second of these is more complicated... to add an entirely new element to contain music notation as a figure-like element (and they suggest part of the figures module). The intention is to give a way to describe music notation as it appears in a text(or document?) and alternatively for this to be used as a place to replace the content with references to MEI elements in a TEI customization much like some do with figure+svg or formula+mathml. (We have already created a basic functioning TEI+MEI ODD which embeds certain MEI elements at different levels, but this certainly needs more work.) The MEI is now expressed as an ODD, and though it contains much that is directly lifted from TEI currently these are all in the MEI namespace. Having this as a starting place would certainly be a good move in rationalising TEI and MEI. However, if we were to do this it seems to me that figure and this new element should be added to a class of model.figureLike and any place figure is specified it be replaced with model.figureLike. Moreover, the naming of the element is slightly problematic. Ideally, they would want it called musicNotation since we'd be freeing up that name if we agree to the first feature request...but that might be confusing and have backwards-compatibility implications, so they also suggest musicalNotation. 'music' sadly doesn't really make sense, since semantically what is in the document is notation rather than music itself. I have no problem with us discussing it in the next two weeks, but want to make sure that we don't rush things and 'get it right' because I think further incorporation of MEI into the TEI where reasonable to be a good thing. -James -- Dr James Cummings, Research Technologies Service OUCS, University of Oxford From susan.schreibman at gmail.com Thu Oct 14 05:42:34 2010 From: susan.schreibman at gmail.com (Susan Schreibman) Date: Thu, 14 Oct 2010 10:42:34 +0100 Subject: [tei-council] new SIG proposal Message-ID: <4CB6D08A.1040702@gmail.com> Dear Council members, I recently received a proposal from Piotr B?nskito begin a new Linguistic SIG. They would like to meet during the MM in Zadar, so please let me know your thoughts on this as soon as possible so if the proposal is approved, we can get the SIG up and running in time for the MM. This SIG does share common concerns with other SIGs (ontologies and tools) but equally important does address an important user community not currently served well by existing SIGs. with all best wishes Susan -- Susan Schreibman, PhD Director Digital Humanities Observatory Pembroke House 28-32 Upper Pembroke Street Dublin 2, Ireland -- A Project of the Royal Irish Academy -- Phone: +353 1 234 2440 Fax: +353 1 234 2400 Mobile: +353 86 049 1966 Email: susan.schreibman at gmail.com Email: s.schreibman at ria.ie http://dho.ie http://irith.org http://macgreevy.org http://v-machine.org -------------- next part -------------- A non-text attachment was scrubbed... Name: SIG_application.pdf Type: application/pdf Size: 65880 bytes Desc: not available Url : http://lists.village.Virginia.EDU/pipermail/tei-council/attachments/20101014/538aa109/attachment.pdf From laurent.romary at inria.fr Thu Oct 14 05:46:56 2010 From: laurent.romary at inria.fr (Laurent Romary) Date: Thu, 14 Oct 2010 11:46:56 +0200 Subject: [tei-council] new SIG proposal In-Reply-To: <712380369.84583.1287049378893.JavaMail.root@zmbs3.inria.fr> References: <712380369.84583.1287049378893.JavaMail.root@zmbs3.inria.fr> Message-ID: <35C53B84-58EA-4FE5-A655-71841832BA6E@inria.fr> I am personally a fan of this initiative, which is not a surprise, but I have already experienced that the persons behind want to be very active. Could you tell me if you have real concerns with regards your proposal and also if one of you would like to act as liaison to it. Best wishes, Laurent Le 14 oct. 10 ? 11:42, Susan Schreibman a ?crit : > Dear Council members, > > I recently received a proposal from Piotr B?nski to begin a new > Linguistic SIG. They would like to meet during the MM in Zadar, so > please let me know your thoughts on this as soon as possible so if > the proposal is approved, we can get the SIG up and running in time > for the MM. > > This SIG does share common concerns with other SIGs (ontologies and > tools) but equally important does address an important user > community not currently served well by existing SIGs. > > with all best wishes > > Susan > > -- > Susan Schreibman, PhD > Director > Digital Humanities Observatory > Pembroke House > 28-32 Upper Pembroke Street > Dublin 2, Ireland > > -- A Project of the Royal Irish Academy -- > > > Phone: +353 1 234 2440 > Fax: +353 1 234 2400 > Mobile: +353 86 049 1966 > Email: susan.schreibman at gmail.com > Email: s.schreibman at ria.ie > > http://dho.ie > http://irith.org > http://macgreevy.org > http://v-machine.org > > <SIG_application.pdf>_______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Laurent Romary INRIA & HUB-IDSL laurent.romary at inria.fr From lou.burnard at oucs.ox.ac.uk Thu Oct 14 05:50:17 2010 From: lou.burnard at oucs.ox.ac.uk (Lou Burnard) Date: Thu, 14 Oct 2010 10:50:17 +0100 Subject: [tei-council] new SIG proposal In-Reply-To: <35C53B84-58EA-4FE5-A655-71841832BA6E@inria.fr> References: <712380369.84583.1287049378893.JavaMail.root@zmbs3.inria.fr> <35C53B84-58EA-4FE5-A655-71841832BA6E@inria.fr> Message-ID: <4CB6D259.8070207@oucs.ox.ac.uk> I share Laurent's enthusiasm for this proposition and would be delighted to work with the SIG Laurent Romary wrote: > I am personally a fan of this initiative, which is not a surprise, but > I have already experienced that the persons behind want to be very > active. > Could you tell me if you have real concerns with regards your proposal > and also if one of you would like to act as liaison to it. > Best wishes, > Laurent > > Le 14 oct. 10 ? 11:42, Susan Schreibman a ?crit : > > >> Dear Council members, >> >> I recently received a proposal from Piotr B?nski to begin a new >> Linguistic SIG. They would like to meet during the MM in Zadar, so >> please let me know your thoughts on this as soon as possible so if >> the proposal is approved, we can get the SIG up and running in time >> for the MM. >> >> This SIG does share common concerns with other SIGs (ontologies and >> tools) but equally important does address an important user >> community not currently served well by existing SIGs. >> >> with all best wishes >> >> Susan >> >> -- >> Susan Schreibman, PhD >> Director >> Digital Humanities Observatory >> Pembroke House >> 28-32 Upper Pembroke Street >> Dublin 2, Ireland >> >> -- A Project of the Royal Irish Academy -- >> >> >> Phone: +353 1 234 2440 >> Fax: +353 1 234 2400 >> Mobile: +353 86 049 1966 >> Email: susan.schreibman at gmail.com >> Email: s.schreibman at ria.ie >> >> http://dho.ie >> http://irith.org >> http://macgreevy.org >> http://v-machine.org >> >> <SIG_application.pdf>_______________________________________________ >> tei-council mailing list >> tei-council at lists.village.Virginia.EDU >> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council >> > > Laurent Romary > INRIA & HUB-IDSL > laurent.romary at inria.fr > > > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > From James.Cummings at oucs.ox.ac.uk Thu Oct 14 06:32:55 2010 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Thu, 14 Oct 2010 11:32:55 +0100 Subject: [tei-council] new SIG proposal In-Reply-To: <4CB6D08A.1040702@gmail.com> References: <4CB6D08A.1040702@gmail.com> Message-ID: <4CB6DC57.9010407@oucs.ox.ac.uk> Susan Schreibman wrote: > Dear Council members, > > I recently received a proposal from Piotr B?nskito begin a new > Linguistic SIG. They would like to meet during the MM in Zadar, so > please let me know your thoughts on this as soon as possible so if the > proposal is approved, we can get the SIG up and running in time for the MM. > > This SIG does share common concerns with other SIGs (ontologies and > tools) but equally important does address an important user community > not currently served well by existing SIGs. The proposal seems sane to me, I can't think of any reason not to let it form officially. -James -- Dr James Cummings, Research Technologies Service OUCS, University of Oxford From julianne.nyhan at gmail.com Thu Oct 14 06:41:31 2010 From: julianne.nyhan at gmail.com (Julianne Nyhan) Date: Thu, 14 Oct 2010 11:41:31 +0100 Subject: [tei-council] new SIG proposal In-Reply-To: <4CB6DC57.9010407@oucs.ox.ac.uk> References: <4CB6D08A.1040702@gmail.com> <4CB6DC57.9010407@oucs.ox.ac.uk> Message-ID: <AANLkTinkRC+FN22J0opijnvZN1di-N8X5L0F9xZrH-LD@mail.gmail.com> I too am very much in favour of this proposed SIG. Best, Julianne On Thu, Oct 14, 2010 at 11:32 AM, James Cummings < James.Cummings at oucs.ox.ac.uk> wrote: > Susan Schreibman wrote: > > Dear Council members, > > > > I recently received a proposal from Piotr B?nskito begin a new > > Linguistic SIG. They would like to meet during the MM in Zadar, so > > please let me know your thoughts on this as soon as possible so if the > > proposal is approved, we can get the SIG up and running in time for the > MM. > > > > This SIG does share common concerns with other SIGs (ontologies and > > tools) but equally important does address an important user community > > not currently served well by existing SIGs. > > The proposal seems sane to me, I can't think of any reason not to > let it form officially. > > -James > > -- > Dr James Cummings, Research Technologies Service > OUCS, University of Oxford > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > -- Dr Julianne Nyhan, Kompetenzzentrum f?r elektronische Erschlie?ungs- und Publikationsverfahren in den Geisteswissenschaften Universit?t Trier Fachbereich II / Germanistik Universit?tsring 15 54286 Trier + 49 (0)651 201-3358 http://germazope.uni-trier.de/Projects/KoZe2/ http://epu.ucc.ie/theses/jnyhan/ http://maney.co.uk/index.php/journals/isr/ http://www.tei-c.org/Activities/SIG/Education/index.xml From elena.pierazzo at kcl.ac.uk Thu Oct 14 06:51:14 2010 From: elena.pierazzo at kcl.ac.uk (Pierazzo, Elena) Date: Thu, 14 Oct 2010 11:51:14 +0100 Subject: [tei-council] new SIG proposal In-Reply-To: <4CB6D08A.1040702@gmail.com> References: <4CB6D08A.1040702@gmail.com> Message-ID: <908139793CE13A4AB5B14781BE0F27C92B16527839@KCL-MAIL04.kclad.ds.kcl.ac.uk> I am delighted by the proposal: I have personally encouraged Piotr during DH2010 to create such a SIG and now I am very pleased byt the fact that this idea has become reality! Elena ________________________________________ From: tei-council-bounces at lists.village.Virginia.EDU [tei-council-bounces at lists.village.Virginia.EDU] On Behalf Of Susan Schreibman [susan.schreibman at gmail.com] Sent: 14 October 2010 10:42 To: TEI Council Subject: [tei-council] new SIG proposal Dear Council members, I recently received a proposal from Piotr B?nskito begin a new Linguistic SIG. They would like to meet during the MM in Zadar, so please let me know your thoughts on this as soon as possible so if the proposal is approved, we can get the SIG up and running in time for the MM. This SIG does share common concerns with other SIGs (ontologies and tools) but equally important does address an important user community not currently served well by existing SIGs. with all best wishes Susan -- Susan Schreibman, PhD Director Digital Humanities Observatory Pembroke House 28-32 Upper Pembroke Street Dublin 2, Ireland -- A Project of the Royal Irish Academy -- Phone: +353 1 234 2440 Fax: +353 1 234 2400 Mobile: +353 86 049 1966 Email: susan.schreibman at gmail.com Email: s.schreibman at ria.ie http://dho.ie http://irith.org http://macgreevy.org http://v-machine.org From daniel.odonnell at uleth.ca Thu Oct 14 14:25:06 2010 From: daniel.odonnell at uleth.ca (O'Donnell, Dan) Date: Thu, 14 Oct 2010 12:25:06 -0600 Subject: [tei-council] new SIG proposal In-Reply-To: <908139793CE13A4AB5B14781BE0F27C92B16527839@KCL-MAIL04.kclad.ds.kcl.ac.uk> References: <4CB6D08A.1040702@gmail.com> <908139793CE13A4AB5B14781BE0F27C92B16527839@KCL-MAIL04.kclad.ds.kcl.ac.uk> Message-ID: <4CB74B02.7080203@uleth.ca> Me too and very keeping with the focus of the meeting. We should publicise its meeting so people realise, since it isn't actually standing right now. On 10-10-14 04:51 AM, Pierazzo, Elena wrote: > I am delighted by the proposal: I have personally encouraged Piotr during DH2010 to create such a SIG and now I am very pleased byt the fact that this idea has become reality! > Elena > ________________________________________ > From: tei-council-bounces at lists.village.Virginia.EDU [tei-council-bounces at lists.village.Virginia.EDU] On Behalf Of Susan Schreibman [susan.schreibman at gmail.com] > Sent: 14 October 2010 10:42 > To: TEI Council > Subject: [tei-council] new SIG proposal > > Dear Council members, > > I recently received a proposal from Piotr B?nskito begin a new > Linguistic SIG. They would like to meet during the MM in Zadar, so > please let me know your thoughts on this as soon as possible so if the > proposal is approved, we can get the SIG up and running in time for the MM. > > This SIG does share common concerns with other SIGs (ontologies and > tools) but equally important does address an important user community > not currently served well by existing SIGs. > > with all best wishes > > Susan > > -- > Susan Schreibman, PhD > Director > Digital Humanities Observatory > Pembroke House > 28-32 Upper Pembroke Street > Dublin 2, Ireland > > -- A Project of the Royal Irish Academy -- > > > Phone: +353 1 234 2440 > Fax: +353 1 234 2400 > Mobile: +353 86 049 1966 > Email: susan.schreibman at gmail.com > Email: s.schreibman at ria.ie > > http://dho.ie > http://irith.org > http://macgreevy.org > http://v-machine.org > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > -- Daniel Paul O'Donnell Professor of English University of Lethbridge Chair and CEO, Text Encoding Initiative (http://www.tei-c.org/) Co-Chair, Digital Initiatives Advisory Board, Medieval Academy of America President-elect (English), Society for Digital Humanities/Soci?t? pour l'?tude des m?dias interactifs (http://sdh-semi.org/) Founding Director (2003-2009), Digital Medievalist Project (http://www.digitalmedievalist.org/) Vox: +1 403 329-2377 Fax: +1 403 382-7191 (non-confidential) Home Page: http://people.uleth.ca/~daniel.odonnell/ From susan.schreibman at gmail.com Fri Oct 15 05:18:07 2010 From: susan.schreibman at gmail.com (Susan Schreibman) Date: Fri, 15 Oct 2010 10:18:07 +0100 Subject: [tei-council] new SIG proposal In-Reply-To: <4CB74B02.7080203@uleth.ca> References: <4CB6D08A.1040702@gmail.com> <908139793CE13A4AB5B14781BE0F27C92B16527839@KCL-MAIL04.kclad.ds.kcl.ac.uk> <4CB74B02.7080203@uleth.ca> Message-ID: <4CB81C4F.5080309@gmail.com> Ok -- I think I have heard five yeas and no nays -- if you would like to vote, please let us know by 2.00 GMT today. After that if there are no strenuous objections I'll take this as having passed. susan On 14/10/2010 19:25, O'Donnell, Dan wrote: > Me too and very keeping with the focus of the meeting. We should > publicise its meeting so people realise, since it isn't actually > standing right now. > > On 10-10-14 04:51 AM, Pierazzo, Elena wrote: >> I am delighted by the proposal: I have personally encouraged Piotr during DH2010 to create such a SIG and now I am very pleased byt the fact that this idea has become reality! >> Elena >> ________________________________________ >> From: tei-council-bounces at lists.village.Virginia.EDU [tei-council-bounces at lists.village.Virginia.EDU] On Behalf Of Susan Schreibman [susan.schreibman at gmail.com] >> Sent: 14 October 2010 10:42 >> To: TEI Council >> Subject: [tei-council] new SIG proposal >> >> Dear Council members, >> >> I recently received a proposal from Piotr B?nskito begin a new >> Linguistic SIG. They would like to meet during the MM in Zadar, so >> please let me know your thoughts on this as soon as possible so if the >> proposal is approved, we can get the SIG up and running in time for the MM. >> >> This SIG does share common concerns with other SIGs (ontologies and >> tools) but equally important does address an important user community >> not currently served well by existing SIGs. >> >> with all best wishes >> >> Susan >> >> -- >> Susan Schreibman, PhD >> Director >> Digital Humanities Observatory >> Pembroke House >> 28-32 Upper Pembroke Street >> Dublin 2, Ireland >> >> -- A Project of the Royal Irish Academy -- >> >> >> Phone: +353 1 234 2440 >> Fax: +353 1 234 2400 >> Mobile: +353 86 049 1966 >> Email: susan.schreibman at gmail.com >> Email: s.schreibman at ria.ie >> >> http://dho.ie >> http://irith.org >> http://macgreevy.org >> http://v-machine.org >> >> _______________________________________________ >> tei-council mailing list >> tei-council at lists.village.Virginia.EDU >> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council >> -- Susan Schreibman, PhD Director Digital Humanities Observatory Pembroke House 28-32 Upper Pembroke Street Dublin 2, Ireland -- A Project of the Royal Irish Academy -- Phone: +353 1 234 2440 Fax: +353 1 234 2400 Mobile: +353 86 049 1966 Email: susan.schreibman at gmail.com Email: s.schreibman at ria.ie http://dho.ie http://irith.org http://macgreevy.org http://v-machine.org From gabriel.bodard at kcl.ac.uk Fri Oct 15 06:07:39 2010 From: gabriel.bodard at kcl.ac.uk (Gabriel Bodard) Date: Fri, 15 Oct 2010 11:07:39 +0100 Subject: [tei-council] new SIG proposal In-Reply-To: <4CB81C4F.5080309@gmail.com> References: <4CB6D08A.1040702@gmail.com> <908139793CE13A4AB5B14781BE0F27C92B16527839@KCL-MAIL04.kclad.ds.kcl.ac.uk> <4CB74B02.7080203@uleth.ca> <4CB81C4F.5080309@gmail.com> Message-ID: <4CB827EB.5070403@kcl.ac.uk> In favour. On 15/10/2010 10:18, Susan Schreibman wrote: > Ok -- I think I have heard five yeas and no nays -- if you would like > to vote, please let us know by 2.00 GMT today. After that if there are > no strenuous objections I'll take this as having passed. > > susan > > On 14/10/2010 19:25, O'Donnell, Dan wrote: >> Me too and very keeping with the focus of the meeting. We should >> publicise its meeting so people realise, since it isn't actually >> standing right now. >> >> On 10-10-14 04:51 AM, Pierazzo, Elena wrote: >>> I am delighted by the proposal: I have personally encouraged Piotr during DH2010 to create such a SIG and now I am very pleased byt the fact that this idea has become reality! >>> Elena >>> ________________________________________ >>> From: tei-council-bounces at lists.village.Virginia.EDU [tei-council-bounces at lists.village.Virginia.EDU] On Behalf Of Susan Schreibman [susan.schreibman at gmail.com] >>> Sent: 14 October 2010 10:42 >>> To: TEI Council >>> Subject: [tei-council] new SIG proposal >>> >>> Dear Council members, >>> >>> I recently received a proposal from Piotr B?nskito begin a new >>> Linguistic SIG. They would like to meet during the MM in Zadar, so >>> please let me know your thoughts on this as soon as possible so if the >>> proposal is approved, we can get the SIG up and running in time for the MM. >>> >>> This SIG does share common concerns with other SIGs (ontologies and >>> tools) but equally important does address an important user community >>> not currently served well by existing SIGs. >>> >>> with all best wishes >>> >>> Susan >>> >>> -- >>> Susan Schreibman, PhD >>> Director >>> Digital Humanities Observatory >>> Pembroke House >>> 28-32 Upper Pembroke Street >>> Dublin 2, Ireland >>> >>> -- A Project of the Royal Irish Academy -- >>> >>> >>> Phone: +353 1 234 2440 >>> Fax: +353 1 234 2400 >>> Mobile: +353 86 049 1966 >>> Email: susan.schreibman at gmail.com >>> Email: s.schreibman at ria.ie >>> >>> http://dho.ie >>> http://irith.org >>> http://macgreevy.org >>> http://v-machine.org >>> >>> _______________________________________________ >>> tei-council mailing list >>> tei-council at lists.village.Virginia.EDU >>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council >>> > -- Dr Gabriel BODARD (Epigrapher, Digital Classicist, Pirate) Centre for Computing in the Humanities King's College London 26-29 Drury Lane London WC2B 5RL Email: gabriel.bodard at kcl.ac.uk Tel: +44 (0)20 7848 1388 Fax: +44 (0)20 7848 2980 http://www.digitalclassicist.org/ http://www.currentepigraphy.org/ From dot.porter at gmail.com Fri Oct 15 06:33:23 2010 From: dot.porter at gmail.com (Dot Porter) Date: Fri, 15 Oct 2010 06:33:23 -0400 Subject: [tei-council] new SIG proposal In-Reply-To: <4CB827EB.5070403@kcl.ac.uk> References: <4CB6D08A.1040702@gmail.com> <908139793CE13A4AB5B14781BE0F27C92B16527839@KCL-MAIL04.kclad.ds.kcl.ac.uk> <4CB74B02.7080203@uleth.ca> <4CB81C4F.5080309@gmail.com> <4CB827EB.5070403@kcl.ac.uk> Message-ID: <AANLkTi=TEchb+36ZtTQa2xQaUQr6WtfJdEvDKasG1Mzc@mail.gmail.com> Aye. On Fri, Oct 15, 2010 at 6:07 AM, Gabriel Bodard <gabriel.bodard at kcl.ac.uk> wrote: > In favour. > > On 15/10/2010 10:18, Susan Schreibman wrote: >> ? ?Ok -- I think I have heard five yeas and no nays -- if you would like >> to vote, please let us know by 2.00 GMT today. After that if there are >> no strenuous objections I'll take this as having passed. >> >> susan >> >> On 14/10/2010 19:25, O'Donnell, Dan wrote: >>> Me too and very keeping with the focus of the meeting. We should >>> publicise its meeting so people realise, since it isn't actually >>> standing right now. >>> >>> On 10-10-14 04:51 AM, Pierazzo, Elena wrote: >>>> I am delighted by the proposal: I have personally encouraged Piotr during DH2010 to create such a SIG and now I am very pleased byt the fact that this idea has become reality! >>>> Elena >>>> ________________________________________ >>>> From: tei-council-bounces at lists.village.Virginia.EDU [tei-council-bounces at lists.village.Virginia.EDU] On Behalf Of Susan Schreibman [susan.schreibman at gmail.com] >>>> Sent: 14 October 2010 10:42 >>>> To: TEI Council >>>> Subject: [tei-council] new SIG proposal >>>> >>>> ? ? ?Dear Council members, >>>> >>>> I recently received a proposal from Piotr B?nskito begin a new >>>> Linguistic SIG. They would like to meet during the MM in Zadar, so >>>> please let me know your thoughts on this as soon as possible so if the >>>> proposal is approved, we can get the SIG up and running in time for the MM. >>>> >>>> This SIG does ?share common concerns with other SIGs (ontologies and >>>> tools) but equally important does address an important user community >>>> not currently served well by existing SIGs. >>>> >>>> with all best wishes >>>> >>>> Susan >>>> >>>> -- >>>> Susan Schreibman, PhD >>>> Director >>>> Digital Humanities Observatory >>>> Pembroke House >>>> 28-32 Upper Pembroke Street >>>> Dublin 2, Ireland >>>> >>>> -- A Project of the Royal Irish Academy -- >>>> >>>> >>>> Phone: +353 1 234 2440 >>>> Fax: +353 1 234 2400 >>>> Mobile: +353 86 049 1966 >>>> Email: susan.schreibman at gmail.com >>>> Email: s.schreibman at ria.ie >>>> >>>> http://dho.ie >>>> http://irith.org >>>> http://macgreevy.org >>>> http://v-machine.org >>>> >>>> _______________________________________________ >>>> tei-council mailing list >>>> tei-council at lists.village.Virginia.EDU >>>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council >>>> >> > > -- > Dr Gabriel BODARD > (Epigrapher, Digital Classicist, Pirate) > > Centre for Computing in the Humanities > King's College London > 26-29 Drury Lane > London WC2B 5RL > Email: gabriel.bodard at kcl.ac.uk > Tel: +44 (0)20 7848 1388 > Fax: +44 (0)20 7848 2980 > > http://www.digitalclassicist.org/ > http://www.currentepigraphy.org/ > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > -- *~*~*~*~*~*~*~*~*~*~* Dot Porter (MA, MSLS) Digital Medievalist, Digital Librarian Email: dot.porter at gmail.com *~*~*~*~*~*~*~*~*~*~* From susan.schreibman at gmail.com Fri Oct 15 11:32:15 2010 From: susan.schreibman at gmail.com (Susan Schreibman) Date: Fri, 15 Oct 2010 16:32:15 +0100 Subject: [tei-council] Linguistics SIG Message-ID: <4CB873FF.2070605@gmail.com> thanks for all your quick responses. I'll take this as 'passed'. susan -- Susan Schreibman, PhD Director Digital Humanities Observatory Pembroke House 28-32 Upper Pembroke Street Dublin 2, Ireland -- A Project of the Royal Irish Academy -- Phone: +353 1 234 2440 Fax: +353 1 234 2400 Mobile: +353 86 049 1966 Email: susan.schreibman at gmail.com Email: s.schreibman at ria.ie http://dho.ie http://irith.org http://macgreevy.org http://v-machine.org From laurent.romary at inria.fr Fri Oct 15 11:45:24 2010 From: laurent.romary at inria.fr (Laurent Romary) Date: Fri, 15 Oct 2010 17:45:24 +0200 Subject: [tei-council] Linguistics SIG In-Reply-To: <2144429177.228841.1287156774207.JavaMail.root@zmbs3.inria.fr> References: <2144429177.228841.1287156774207.JavaMail.root@zmbs3.inria.fr> Message-ID: <6A7FAF7E-F060-4537-B10D-132E99D29EE9@inria.fr> Absolutely! Laurent Le 15 oct. 10 ? 17:32, Susan Schreibman a ?crit : > thanks for all your quick responses. I'll take this as 'passed'. > > > susan > > -- > Susan Schreibman, PhD > Director > Digital Humanities Observatory > Pembroke House > 28-32 Upper Pembroke Street > Dublin 2, Ireland > > -- A Project of the Royal Irish Academy -- > > > Phone: +353 1 234 2440 > Fax: +353 1 234 2400 > Mobile: +353 86 049 1966 > Email: susan.schreibman at gmail.com > Email: s.schreibman at ria.ie > > http://dho.ie > http://irith.org > http://macgreevy.org > http://v-machine.org > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Laurent Romary INRIA & HUB-IDSL laurent.romary at inria.fr From sebastian.rahtz at oucs.ox.ac.uk Sun Oct 17 13:18:17 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Sun, 17 Oct 2010 18:18:17 +0100 Subject: [tei-council] Roma Message-ID: <8062A67B-3FF0-4864-BF5E-50D724F5CCEE@oucs.ox.ac.uk> I have updated the Roma at http://tei.oucs.ox.ac.uk/Roma/ (and its associated OxGarage) to a state where I believe it can offer an adequate service to replace the old Roma. But it needs more testing and poking. If you can try it, please do, and report any errors to me ASAP. Unless I absolutely have to, I do not propose to work again on Roma or the ODD processing in 2010, so speak now if you find it unfit for purpose.... -- Sebastian Rahtz Information and Support Group Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From sebastian.rahtz at oucs.ox.ac.uk Sun Oct 17 18:53:59 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Sun, 17 Oct 2010 23:53:59 +0100 Subject: [tei-council] @points again, in relaxng Message-ID: <DCC3B7D8-8589-41AC-ABA1-5693100E5468@oucs.ox.ac.uk> We agreed a few weeks ago that we wanted @points to accept 3 or more comma-separated pairs of numbers. So in RELAXNG that may be xsd:token { pattern = "[0-9]+,[0-9]+" } but then we said we also wanted real numbers and negative numbers. So how exactly _does_ one say that in regexp land? lord help us, is it -?[0-9]+\.?[0-9]*,-?[0-9]+\.?[0-9]* or am I being dense? -- Sebastian Rahtz Information and Support Group Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From lou.burnard at oucs.ox.ac.uk Sun Oct 17 19:15:11 2010 From: lou.burnard at oucs.ox.ac.uk (Lou Burnard) Date: Mon, 18 Oct 2010 00:15:11 +0100 Subject: [tei-council] @points again, in relaxng In-Reply-To: <DCC3B7D8-8589-41AC-ABA1-5693100E5468@oucs.ox.ac.uk> References: <DCC3B7D8-8589-41AC-ABA1-5693100E5468@oucs.ox.ac.uk> Message-ID: <4CBB837F.6040105@oucs.ox.ac.uk> To be more exact I think we actually said we wanted pairs of data.numerics (which allows real numbers and negative numbers and lord save us vulgar fractions too) so surely we shouldn't be defining a specific pattern here? On 17/10/10 23:53, Sebastian Rahtz wrote: > We agreed a few weeks ago that we wanted @points to accept 3 or more comma-separated pairs of > numbers. So in RELAXNG that may be > > xsd:token { pattern = "[0-9]+,[0-9]+" } > > but then we said we also wanted real numbers and negative numbers. > > So how exactly _does_ one say that in regexp land? > > lord help us, is it > > -?[0-9]+\.?[0-9]*,-?[0-9]+\.?[0-9]* > > or am I being dense? > -- > Sebastian Rahtz > Information and Support Group Manager, Oxford University Computing Services > 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 > > S?lo le pido a Dios > que el futuro no me sea indiferente > > > > > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council From laurent.romary at inria.fr Mon Oct 18 00:05:59 2010 From: laurent.romary at inria.fr (Laurent Romary) Date: Mon, 18 Oct 2010 06:05:59 +0200 Subject: [tei-council] @points again, in relaxng In-Reply-To: <1009245531.1160907.1287357298907.JavaMail.root@zmbs3.inria.fr> References: <DCC3B7D8-8589-41AC-ABA1-5693100E5468@oucs.ox.ac.uk> <1009245531.1160907.1287357298907.JavaMail.root@zmbs3.inria.fr> Message-ID: <21F9DD0F-5E63-4482-ACCE-AF64B14ACC0B@inria.fr> I am with Lou here. Laurent Le 18 oct. 10 ? 01:14, Lou Burnard a ?crit : > To be more exact I think we actually said we wanted pairs of > data.numerics (which allows real numbers and negative numbers and lord > save us vulgar fractions too) > > so surely we shouldn't be defining a specific pattern here? > > > On 17/10/10 23:53, Sebastian Rahtz wrote: >> We agreed a few weeks ago that we wanted @points to accept 3 or >> more comma-separated pairs of >> numbers. So in RELAXNG that may be >> >> xsd:token { pattern = "[0-9]+,[0-9]+" } >> >> but then we said we also wanted real numbers and negative numbers. >> >> So how exactly _does_ one say that in regexp land? >> >> lord help us, is it >> >> -?[0-9]+\.?[0-9]*,-?[0-9]+\.?[0-9]* >> >> or am I being dense? >> -- >> Sebastian Rahtz >> Information and Support Group Manager, Oxford University Computing >> Services >> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 >> >> S?lo le pido a Dios >> que el futuro no me sea indiferente >> >> >> >> >> >> _______________________________________________ >> tei-council mailing list >> tei-council at lists.village.Virginia.EDU >> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Laurent Romary INRIA & HUB-IDSL laurent.romary at inria.fr From lou.burnard at oucs.ox.ac.uk Mon Oct 18 12:25:09 2010 From: lou.burnard at oucs.ox.ac.uk (Lou) Date: Mon, 18 Oct 2010 17:25:09 +0100 Subject: [tei-council] nuncling ... help needed! Message-ID: <4CBC74E5.5060101@oucs.ox.ac.uk> Further to Laurent's call for volunteers a week or two back, and with apologies for the delay, here are the collated results of said appeal. As you can see, we need a few more volunteers. Specifically (a) #1 has only one nuncle (b) #4 has no nuncles other than its onlie begetters (c) #5 has only one nuncle (d) #6 has no nuncle at all :-( (e) #8 has no nuncle at all :-( Please could I urge all signed up nuncles to contact each other as soon as possible and agree a plan of campaign? It would be really good to have a preliminary statement of each problem area and a balanced review of the possible resolutions circulated to council by this time next week. In some cases this is easier than others of course. 1. further attributes for imprecise numerical values -------- 3060909: add attribute for non-numeric characterisation of precision 3060919: add way of expressing confidence for att.ranging values GB 2. further features for personographies ---------------------- 3060874: @source and @code for <faith> 3060867: Grouping elements for traitlike, statelike, and eventlike elements SR LB GB (perhaps) 3. proposed clarificatory text for some tecnical issues ------ 3051750: Form of words needs to be proposed (schema langs) 2493417: Ibid (idno) JN BB 4. bibliographic issues -------------------------------------- 2976715: resp -> model.respLike in biblStruct. and other things. 2987832: date within biblStruct Further recommendations arising from the working paper on bibliographic description MH, KH 5. ODD issues ------------------------------------------------ 2994685: att.global shd be explicit in ODD source 1933481: @status attribute to indicate deprecated elements JC 6. multimedia issues --------------------------------------- 2724992: features for alignment of audio and video 2507305: alignment and documentation of sound files 7. New "object" element ------------------------------------ 2811239: "object" element GB DP BB EP 8. Generic dating class ----------------------------------- 2925145: generic dating class 9. Specific recommendations arising from the Genetic Editing workpaper 2834511: make more spanning elements LB DP EP From gabriel.bodard at kcl.ac.uk Mon Oct 18 12:38:16 2010 From: gabriel.bodard at kcl.ac.uk (Gabriel Bodard) Date: Mon, 18 Oct 2010 17:38:16 +0100 Subject: [tei-council] nuncling ... help needed! In-Reply-To: <4CBC74E5.5060101@oucs.ox.ac.uk> References: <4CBC74E5.5060101@oucs.ox.ac.uk> Message-ID: <4CBC77F8.9090307@kcl.ac.uk> If I'm not wanted on #2, I suppose I could co-nuncle #8 if someone else is willing to talk over the possibilities. (Is this the point at which we all give a Paddington Stare at anyone who hasn't volunteered to nuncle anything yet?) On 18/10/2010 17:25, Lou wrote: > Further to Laurent's call for volunteers a week or two back, and with > apologies for the delay, here are the collated results of said appeal. > > As you can see, we need a few more volunteers. Specifically > > (a) #1 has only one nuncle > (b) #4 has no nuncles other than its onlie begetters > (c) #5 has only one nuncle > (d) #6 has no nuncle at all :-( > (e) #8 has no nuncle at all :-( > > Please could I urge all signed up nuncles to contact each other as soon > as possible and agree a plan of campaign? > > It would be really good to have a preliminary statement of each problem > area and a balanced review of the possible resolutions circulated to > council by this time next week. In some cases this is easier than others > of course. > > 1. further attributes for imprecise numerical values -------- > > 3060909: add attribute for non-numeric characterisation of precision > 3060919: add way of expressing confidence for att.ranging values > > GB > > 2. further features for personographies ---------------------- > > 3060874: @source and @code for<faith> > 3060867: Grouping elements for traitlike, statelike, and eventlike > elements > > SR > LB > GB (perhaps) > > 3. proposed clarificatory text for some tecnical issues ------ > > 3051750: Form of words needs to be proposed (schema langs) > 2493417: Ibid (idno) > > JN > BB > > > 4. bibliographic issues -------------------------------------- > > 2976715: resp -> model.respLike in biblStruct. and other things. > 2987832: date within biblStruct > Further recommendations arising from the working paper on > bibliographic description > > MH, KH > > 5. ODD issues ------------------------------------------------ > > 2994685: att.global shd be explicit in ODD source > 1933481: @status attribute to indicate deprecated elements > > JC > > 6. multimedia issues --------------------------------------- > > 2724992: features for alignment of audio and video > 2507305: alignment and documentation of sound files > > 7. New "object" element ------------------------------------ > > 2811239: "object" element > > GB > DP > BB > EP > > > 8. Generic dating class ----------------------------------- > > 2925145: generic dating class > > 9. Specific recommendations arising from the Genetic Editing workpaper > > 2834511: make more spanning elements > > LB > DP > EP > > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council -- Dr Gabriel BODARD (Epigrapher, Digital Classicist, Pirate) Centre for Computing in the Humanities King's College London 26-29 Drury Lane London WC2B 5RL Email: gabriel.bodard at kcl.ac.uk Tel: +44 (0)20 7848 1388 Fax: +44 (0)20 7848 2980 http://www.digitalclassicist.org/ http://www.currentepigraphy.org/ From sebastian.rahtz at oucs.ox.ac.uk Mon Oct 18 12:52:19 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 18 Oct 2010 17:52:19 +0100 Subject: [tei-council] nuncling ... help needed! In-Reply-To: <4CBC74E5.5060101@oucs.ox.ac.uk> References: <4CBC74E5.5060101@oucs.ox.ac.uk> Message-ID: <6A2EA214-DD8B-4789-A2E8-706551F7C2DD@oucs.ox.ac.uk> Please add me to #8 and #5 -- Sebastian Rahtz Information and Support Group Manager Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From sebastian.rahtz at oucs.ox.ac.uk Tue Oct 19 06:19:58 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 19 Oct 2010 11:19:58 +0100 Subject: [tei-council] nuncling ... help needed! In-Reply-To: <4CBC74E5.5060101@oucs.ox.ac.uk> References: <4CBC74E5.5060101@oucs.ox.ac.uk> Message-ID: <E0825B1B-8A47-485F-8E7E-ED3FC6A57EF4@oucs.ox.ac.uk> used as I am to the new-fangled idea that is hyperlinking on the web, I felt obliged to create http://tei.oucs.ox.ac.uk/fr.html to allow folks to click on numbers and see the tickets this uses the original subject lines, not Lou's human-readable variants -- Sebastian Rahtz Information and Support Group Manager Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From gabriel.bodard at kcl.ac.uk Tue Oct 19 06:23:46 2010 From: gabriel.bodard at kcl.ac.uk (Gabriel Bodard) Date: Tue, 19 Oct 2010 11:23:46 +0100 Subject: [tei-council] nuncling ... help needed! In-Reply-To: <E0825B1B-8A47-485F-8E7E-ED3FC6A57EF4@oucs.ox.ac.uk> References: <4CBC74E5.5060101@oucs.ox.ac.uk> <E0825B1B-8A47-485F-8E7E-ED3FC6A57EF4@oucs.ox.ac.uk> Message-ID: <4CBD71B2.9070509@kcl.ac.uk> Should we maybe put this in a wiki page somewhere, so that we can add our names to the appropriate tickets etc. (and maybe group them by nuncling categories)? Is there a quiet corner of the TEI Wiki we can appropriate for this? On 19/10/2010 11:19, Sebastian Rahtz wrote: > used as I am to the new-fangled idea that is hyperlinking on the web, > I felt obliged to create http://tei.oucs.ox.ac.uk/fr.html > to allow folks to click on numbers and see the tickets > > this uses the original subject lines, not Lou's human-readable variants > > -- > Sebastian Rahtz > Information and Support Group Manager > Oxford University Computing Services > 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 > > S?lo le pido a Dios > que el futuro no me sea indiferente > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council -- Dr Gabriel BODARD (Epigrapher, Digital Classicist, Pirate) Centre for Computing in the Humanities King's College London 26-29 Drury Lane London WC2B 5RL Email: gabriel.bodard at kcl.ac.uk Tel: +44 (0)20 7848 1388 Fax: +44 (0)20 7848 2980 http://www.digitalclassicist.org/ http://www.currentepigraphy.org/ From lou.burnard at oucs.ox.ac.uk Tue Oct 19 06:26:30 2010 From: lou.burnard at oucs.ox.ac.uk (Lou Burnard) Date: Tue, 19 Oct 2010 11:26:30 +0100 Subject: [tei-council] nuncling ... help needed! In-Reply-To: <4CBD71B2.9070509@kcl.ac.uk> References: <4CBC74E5.5060101@oucs.ox.ac.uk> <E0825B1B-8A47-485F-8E7E-ED3FC6A57EF4@oucs.ox.ac.uk> <4CBD71B2.9070509@kcl.ac.uk> Message-ID: <4CBD7256.2040604@oucs.ox.ac.uk> Or should we maybe concentrate on the work that needs doing instead of the process whereby doing the work is facilitated? Ah the age old dilemma of the digital humanities.... On 19/10/10 11:23, Gabriel Bodard wrote: > Should we maybe put this in a wiki page somewhere, so that we can add > our names to the appropriate tickets etc. (and maybe group them by > nuncling categories)? Is there a quiet corner of the TEI Wiki we can > appropriate for this? > > On 19/10/2010 11:19, Sebastian Rahtz wrote: >> used as I am to the new-fangled idea that is hyperlinking on the web, >> I felt obliged to create http://tei.oucs.ox.ac.uk/fr.html >> to allow folks to click on numbers and see the tickets >> >> this uses the original subject lines, not Lou's human-readable variants >> >> -- >> Sebastian Rahtz >> Information and Support Group Manager >> Oxford University Computing Services >> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 >> >> S?lo le pido a Dios >> que el futuro no me sea indiferente >> >> _______________________________________________ >> tei-council mailing list >> tei-council at lists.village.Virginia.EDU >> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > From sebastian.rahtz at oucs.ox.ac.uk Tue Oct 19 06:26:59 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 19 Oct 2010 11:26:59 +0100 Subject: [tei-council] nuncling ... help needed! In-Reply-To: <4CBD71B2.9070509@kcl.ac.uk> References: <4CBC74E5.5060101@oucs.ox.ac.uk> <E0825B1B-8A47-485F-8E7E-ED3FC6A57EF4@oucs.ox.ac.uk> <4CBD71B2.9070509@kcl.ac.uk> Message-ID: <2106FF4A-232A-42A7-B925-612AF1CD2241@oucs.ox.ac.uk> On 19 Oct 2010, at 11:23, Gabriel Bodard wrote: > Should we maybe put this in a wiki page somewhere, so that we can add > our names to the appropriate tickets etc. (and maybe group them by > nuncling categories)? Is there a quiet corner of the TEI Wiki we can > appropriate for this? sure, probably better on a wiki. should be trivial to convert to wiki-language, its very minimal HTML -- Sebastian Rahtz Information and Support Group Manager Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From sebastian.rahtz at oucs.ox.ac.uk Tue Oct 19 06:28:47 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 19 Oct 2010 11:28:47 +0100 Subject: [tei-council] nuncling ... help needed! In-Reply-To: <2106FF4A-232A-42A7-B925-612AF1CD2241@oucs.ox.ac.uk> References: <4CBC74E5.5060101@oucs.ox.ac.uk> <E0825B1B-8A47-485F-8E7E-ED3FC6A57EF4@oucs.ox.ac.uk> <4CBD71B2.9070509@kcl.ac.uk> <2106FF4A-232A-42A7-B925-612AF1CD2241@oucs.ox.ac.uk> Message-ID: <234AA3EE-ECFD-4F9E-B8D3-F910FACCE9FB@oucs.ox.ac.uk> > > > sure, probably better on a wiki. should be trivial to convert to wiki-language, its very minimal HTML I hasten to add that I am not volunteering to do this :-} -- Sebastian Rahtz Information and Support Group Manager Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From sebastian.rahtz at oucs.ox.ac.uk Tue Oct 19 06:32:45 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 19 Oct 2010 11:32:45 +0100 Subject: [tei-council] nuncling ... help needed! In-Reply-To: <4CBD7256.2040604@oucs.ox.ac.uk> References: <4CBC74E5.5060101@oucs.ox.ac.uk> <E0825B1B-8A47-485F-8E7E-ED3FC6A57EF4@oucs.ox.ac.uk> <4CBD71B2.9070509@kcl.ac.uk> <4CBD7256.2040604@oucs.ox.ac.uk> Message-ID: <6D795BF9-04FD-4074-B347-8064AD26B99F@oucs.ox.ac.uk> On 19 Oct 2010, at 11:26, Lou Burnard wrote: > Or should we maybe concentrate on the work that needs doing instead of > the process whereby doing the work is facilitated? if Sourceforge bug trackers were easier to use, I'd agree with you. But I really do a find a genuine barrier between reading a bare 2925145 in a mail message and finding the relevant words in SF (though that is sometimes so terse that I wonder we did not knock these FRs out of court ages back?) -- Sebastian Rahtz Information and Support Group Manager Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From gabriel.bodard at kcl.ac.uk Tue Oct 19 06:35:42 2010 From: gabriel.bodard at kcl.ac.uk (Gabriel Bodard) Date: Tue, 19 Oct 2010 11:35:42 +0100 Subject: [tei-council] nuncling ... help needed! In-Reply-To: <234AA3EE-ECFD-4F9E-B8D3-F910FACCE9FB@oucs.ox.ac.uk> References: <4CBC74E5.5060101@oucs.ox.ac.uk> <E0825B1B-8A47-485F-8E7E-ED3FC6A57EF4@oucs.ox.ac.uk> <4CBD71B2.9070509@kcl.ac.uk> <2106FF4A-232A-42A7-B925-612AF1CD2241@oucs.ox.ac.uk> <234AA3EE-ECFD-4F9E-B8D3-F910FACCE9FB@oucs.ox.ac.uk> Message-ID: <4CBD747E.1020209@kcl.ac.uk> I'll do it. I see Lou's point that this is a distraction from doing the actual work, but in the last version of this we saw, not all tickets that I was looking at had co-nuncles (and I thought discussion was meant to be the point), and not all new volunteerings were reflected in the HTML. With a wiki, there's at least a chance I'll know whom I'm meant to be talking with! Will post the Wiki page here shortly. G On 19/10/2010 11:28, Sebastian Rahtz wrote: > >> >> >> sure, probably better on a wiki. should be trivial to convert to wiki-language, its very minimal HTML > I hasten to add that I am not volunteering to do this :-} > > -- > Sebastian Rahtz > Information and Support Group Manager > Oxford University Computing Services > 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 > > S?lo le pido a Dios > que el futuro no me sea indiferente > -- Dr Gabriel BODARD (Epigrapher, Digital Classicist, Pirate) Centre for Computing in the Humanities King's College London 26-29 Drury Lane London WC2B 5RL Email: gabriel.bodard at kcl.ac.uk Tel: +44 (0)20 7848 1388 Fax: +44 (0)20 7848 2980 http://www.digitalclassicist.org/ http://www.currentepigraphy.org/ From gabriel.bodard at kcl.ac.uk Tue Oct 19 06:54:31 2010 From: gabriel.bodard at kcl.ac.uk (Gabriel Bodard) Date: Tue, 19 Oct 2010 11:54:31 +0100 Subject: [tei-council] nuncling ... help needed! In-Reply-To: <4CBD747E.1020209@kcl.ac.uk> References: <4CBC74E5.5060101@oucs.ox.ac.uk> <E0825B1B-8A47-485F-8E7E-ED3FC6A57EF4@oucs.ox.ac.uk> <4CBD71B2.9070509@kcl.ac.uk> <2106FF4A-232A-42A7-B925-612AF1CD2241@oucs.ox.ac.uk> <234AA3EE-ECFD-4F9E-B8D3-F910FACCE9FB@oucs.ox.ac.uk> <4CBD747E.1020209@kcl.ac.uk> Message-ID: <4CBD78E7.5040200@kcl.ac.uk> Done. http://wiki.tei-c.org/index.php/Council_FR_assignments As far as I can see, volunteers still needed for 1 and 6. On 19/10/2010 11:35, Gabriel Bodard wrote: > I'll do it. I see Lou's point that this is a distraction from doing the > actual work, but in the last version of this we saw, not all tickets > that I was looking at had co-nuncles (and I thought discussion was meant > to be the point), and not all new volunteerings were reflected in the > HTML. With a wiki, there's at least a chance I'll know whom I'm meant to > be talking with! > > Will post the Wiki page here shortly. > > G > > On 19/10/2010 11:28, Sebastian Rahtz wrote: >> >>> >>> >>> sure, probably better on a wiki. should be trivial to convert to wiki-language, its very minimal HTML >> I hasten to add that I am not volunteering to do this :-} >> >> -- >> Sebastian Rahtz >> Information and Support Group Manager >> Oxford University Computing Services >> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 >> >> S?lo le pido a Dios >> que el futuro no me sea indiferente >> > -- Dr Gabriel BODARD (Epigrapher, Digital Classicist, Pirate) Centre for Computing in the Humanities King's College London 26-29 Drury Lane London WC2B 5RL Email: gabriel.bodard at kcl.ac.uk Tel: +44 (0)20 7848 1388 Fax: +44 (0)20 7848 2980 http://www.digitalclassicist.org/ http://www.currentepigraphy.org/ From lou.burnard at oucs.ox.ac.uk Tue Oct 19 07:04:03 2010 From: lou.burnard at oucs.ox.ac.uk (Lou) Date: Tue, 19 Oct 2010 12:04:03 +0100 Subject: [tei-council] nuncling ... help needed! In-Reply-To: <4CBD78E7.5040200@kcl.ac.uk> References: <4CBC74E5.5060101@oucs.ox.ac.uk> <E0825B1B-8A47-485F-8E7E-ED3FC6A57EF4@oucs.ox.ac.uk> <4CBD71B2.9070509@kcl.ac.uk> <2106FF4A-232A-42A7-B925-612AF1CD2241@oucs.ox.ac.uk> <234AA3EE-ECFD-4F9E-B8D3-F910FACCE9FB@oucs.ox.ac.uk> <4CBD747E.1020209@kcl.ac.uk> <4CBD78E7.5040200@kcl.ac.uk> Message-ID: <4CBD7B23.2090805@oucs.ox.ac.uk> Thanks Gabby: I will try to keep this page up to date (if the collective fails to do so) and re-use it for the next such exercise. Sorry if my earlier comment sounded a bit grouchy! Gabriel Bodard wrote: > Done. > > http://wiki.tei-c.org/index.php/Council_FR_assignments > > As far as I can see, volunteers still needed for 1 and 6. > > On 19/10/2010 11:35, Gabriel Bodard wrote: >> I'll do it. I see Lou's point that this is a distraction from doing the >> actual work, but in the last version of this we saw, not all tickets >> that I was looking at had co-nuncles (and I thought discussion was meant >> to be the point), and not all new volunteerings were reflected in the >> HTML. With a wiki, there's at least a chance I'll know whom I'm meant to >> be talking with! >> >> Will post the Wiki page here shortly. >> >> G >> >> On 19/10/2010 11:28, Sebastian Rahtz wrote: >>>> >>>> sure, probably better on a wiki. should be trivial to convert to wiki-language, its very minimal HTML >>> I hasten to add that I am not volunteering to do this :-} >>> >>> -- >>> Sebastian Rahtz >>> Information and Support Group Manager >>> Oxford University Computing Services >>> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 >>> >>> S?lo le pido a Dios >>> que el futuro no me sea indiferente >>> > From sebastian.rahtz at oucs.ox.ac.uk Tue Oct 19 07:09:53 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 19 Oct 2010 12:09:53 +0100 Subject: [tei-council] nuncling ... help needed! In-Reply-To: <4CBD78E7.5040200@kcl.ac.uk> References: <4CBC74E5.5060101@oucs.ox.ac.uk> <E0825B1B-8A47-485F-8E7E-ED3FC6A57EF4@oucs.ox.ac.uk> <4CBD71B2.9070509@kcl.ac.uk> <2106FF4A-232A-42A7-B925-612AF1CD2241@oucs.ox.ac.uk> <234AA3EE-ECFD-4F9E-B8D3-F910FACCE9FB@oucs.ox.ac.uk> <4CBD747E.1020209@kcl.ac.uk> <4CBD78E7.5040200@kcl.ac.uk> Message-ID: <FCBE283C-4FA6-4AF3-BA9B-946356FE4AA5@oucs.ox.ac.uk> On 19 Oct 2010, at 11:54, Gabriel Bodard wrote: > > http://wiki.tei-c.org/index.php/Council_FR_assignments > it would make sense if the subcommittees recorded their discussion here as well -- Sebastian Rahtz Information and Support Group Manager Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From sebastian.rahtz at oucs.ox.ac.uk Tue Oct 19 12:33:27 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 19 Oct 2010 17:33:27 +0100 Subject: [tei-council] constraintSpec inside macroSpec Message-ID: <F760CD8A-AB97-4D49-8AB5-50993CC33627@oucs.ox.ac.uk> I just changed the content model of <macroSpec> to allow it to have a <constraintSpec> child. It seemed like a corrigible oversight for it not to mirror the other *Spec. Does anyone have an objection or a memory of why we did not do this before? -- Sebastian Rahtz Information and Support Group Manager Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From julianne.nyhan at gmail.com Tue Oct 19 17:15:48 2010 From: julianne.nyhan at gmail.com (Julianne Nyhan) Date: Tue, 19 Oct 2010 22:15:48 +0100 Subject: [tei-council] nuncling ... help needed! In-Reply-To: <4CBD78E7.5040200@kcl.ac.uk> References: <4CBC74E5.5060101@oucs.ox.ac.uk> <E0825B1B-8A47-485F-8E7E-ED3FC6A57EF4@oucs.ox.ac.uk> <4CBD71B2.9070509@kcl.ac.uk> <2106FF4A-232A-42A7-B925-612AF1CD2241@oucs.ox.ac.uk> <234AA3EE-ECFD-4F9E-B8D3-F910FACCE9FB@oucs.ox.ac.uk> <4CBD747E.1020209@kcl.ac.uk> <4CBD78E7.5040200@kcl.ac.uk> Message-ID: <AANLkTin6A09t1mV_g-iaewyOUik7m-UV6CxMM50Fb-pQ@mail.gmail.com> Dear all, ok, then I'll volunteer for #1 too. Best, Julianne On Tue, Oct 19, 2010 at 11:54 AM, Gabriel Bodard <gabriel.bodard at kcl.ac.uk>wrote: > Done. > > http://wiki.tei-c.org/index.php/Council_FR_assignments > > As far as I can see, volunteers still needed for 1 and 6. > > On 19/10/2010 11:35, Gabriel Bodard wrote: > > I'll do it. I see Lou's point that this is a distraction from doing the > > actual work, but in the last version of this we saw, not all tickets > > that I was looking at had co-nuncles (and I thought discussion was meant > > to be the point), and not all new volunteerings were reflected in the > > HTML. With a wiki, there's at least a chance I'll know whom I'm meant to > > be talking with! > > > > Will post the Wiki page here shortly. > > > > G > > > > On 19/10/2010 11:28, Sebastian Rahtz wrote: > >> > >>> > >>> > >>> sure, probably better on a wiki. should be trivial to convert to > wiki-language, its very minimal HTML > >> I hasten to add that I am not volunteering to do this :-} > >> > >> -- > >> Sebastian Rahtz > >> Information and Support Group Manager > >> Oxford University Computing Services > >> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 > >> > >> S?lo le pido a Dios > >> que el futuro no me sea indiferente > >> > > > > -- > Dr Gabriel BODARD > (Epigrapher, Digital Classicist, Pirate) > > Centre for Computing in the Humanities > King's College London > 26-29 Drury Lane > London WC2B 5RL > Email: gabriel.bodard at kcl.ac.uk > Tel: +44 (0)20 7848 1388 > Fax: +44 (0)20 7848 2980 > > http://www.digitalclassicist.org/ > http://www.currentepigraphy.org/ > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > -- Dr Julianne Nyhan, Kompetenzzentrum f?r elektronische Erschlie?ungs- und Publikationsverfahren in den Geisteswissenschaften Universit?t Trier Fachbereich II / Germanistik Universit?tsring 15 54286 Trier + 49 (0)651 201-3358 http://germazope.uni-trier.de/Projects/KoZe2/ http://epu.ucc.ie/theses/jnyhan/ http://maney.co.uk/index.php/journals/isr/ http://www.tei-c.org/Activities/SIG/Education/index.xml From sebastian.rahtz at oucs.ox.ac.uk Wed Oct 20 09:17:16 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Wed, 20 Oct 2010 14:17:16 +0100 Subject: [tei-council] copy of message added to ticket 2994685 - att.global Message-ID: <06B41933-6D4C-40AF-8A62-7A39C6F5F970@oucs.ox.ac.uk> As requested by TEI Council, James Cummings and I met to discuss this ticket. We concluded that the advantages of a special global attribute class are outweighed by the considerable decrease in special-casing in ODD-processing, and ambiguity about when att.global applies. Increased transparency will pay off in the long term, though we think we need to investigate the effect on some existing ODDs. We recommend that the Council endorse the proposal. -- Sebastian Rahtz Information and Support Group Manager Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From lou.burnard at oucs.ox.ac.uk Wed Oct 20 09:21:00 2010 From: lou.burnard at oucs.ox.ac.uk (Lou Burnard) Date: Wed, 20 Oct 2010 14:21:00 +0100 Subject: [tei-council] copy of message added to ticket 2994685 - att.global In-Reply-To: <06B41933-6D4C-40AF-8A62-7A39C6F5F970@oucs.ox.ac.uk> References: <06B41933-6D4C-40AF-8A62-7A39C6F5F970@oucs.ox.ac.uk> Message-ID: <4CBEECBC.20902@oucs.ox.ac.uk> Did your discussion touch on what the advantages of special casing the global attribute class might be? or don't you see that there are any? I note that we also have a so-called model.global which isn't actually global, precisely because it's not special-cased of course. On 20/10/10 14:17, Sebastian Rahtz wrote: > As requested by TEI Council, James Cummings and I met to discuss this ticket. We concluded that the advantages of a special global attribute class are outweighed by the considerable decrease in special-casing in ODD-processing, and ambiguity about when att.global applies. Increased transparency will pay off in the long term, though we think we need to investigate the effect on some existing ODDs. We recommend that the Council endorse the proposal. > -- > Sebastian Rahtz > Information and Support Group Manager > Oxford University Computing Services > 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 > > S?lo le pido a Dios > que el futuro no me sea indiferente > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council From sebastian.rahtz at oucs.ox.ac.uk Wed Oct 20 09:29:39 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Wed, 20 Oct 2010 14:29:39 +0100 Subject: [tei-council] copy of messaged added to SF ticket 1933481 - deprecation attribute Message-ID: <0A60C791-5D55-4E03-98CC-635B7855BAD9@oucs.ox.ac.uk> as requested by TEI Council, James Cummings and I met to discuss this. We concluded that a documentary attriibute on *Spec will not be hard to maintain, and will allow the TEIC or 3rd parties to build services in the future (eg showing deprecated elements in red on a web page). To get better value from @status, we propose three allowed values - deprecated: this object will disappear one day - unstable: this object is new, and may change rapidly - changed: this object has changed in some way since the last release the implicit default of course is "stable" This will allow tools to support "dont include deprecated or unstable objects", and allow for list of changed objects to be created. We believe that the status attribute should be accompanied by adding *Spec to att.datable, to allow finer-grained control. so @from indicates when the status changed to deprecated or unstable @to indicates when an object is scheduled to die or become stable @when (or @period, which may refer to releases) indicates when the object as a whole changed @notAfter and @notBefore mean something vaguer :-} these are all optional! All this does NOT mandate the TEIC to use all or any of these features now, but allows for gradual imprrovement in working practices. Particularly the use of status='changed' needs some technical work to automate it. -- Sebastian Rahtz Information and Support Group Manager Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From sebastian.rahtz at oucs.ox.ac.uk Wed Oct 20 09:34:49 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Wed, 20 Oct 2010 14:34:49 +0100 Subject: [tei-council] copy of message added to ticket 2994685 - att.global In-Reply-To: <4CBEECBC.20902@oucs.ox.ac.uk> References: <06B41933-6D4C-40AF-8A62-7A39C6F5F970@oucs.ox.ac.uk> <4CBEECBC.20902@oucs.ox.ac.uk> Message-ID: <E716EBA3-053F-43C9-B2DB-E920C521906E@oucs.ox.ac.uk> On 20 Oct 2010, at 14:21, Lou Burnard wrote: > Did your discussion touch on what the advantages of special casing the > global attribute class might be? or don't you see that there are any? sorry, I forgot to note that yes, there are arguments in favour of fixed global attributes (any TEI encoder can always be sure they add @id and @lang); but in that case we must retract the ability to remove them (which can easily be done at present). Stopping them being removed requires even more magic juju in the processing. At present they are magic but also vulnerable. the alternative is to add a boolean attribute @changeable to *Spec, so that the magic is more explicit and traceable. > > I note that we also have a so-called model.global which isn't actually > global, precisely because it's not special-cased of course. true. surely another argument against att.global?. -- Sebastian Rahtz Information and Support Group Manager Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From lou.burnard at oucs.ox.ac.uk Wed Oct 20 09:36:18 2010 From: lou.burnard at oucs.ox.ac.uk (Lou Burnard) Date: Wed, 20 Oct 2010 14:36:18 +0100 Subject: [tei-council] Genetic editing thoughts (item 9 on the nuncling sheet) Message-ID: <4CBEF052.6080209@oucs.ox.ac.uk> Dot, Elena, and I are agreed that the concrete proposals in the genetic editing document can be largely simplified to produce three specific feature requests which I list below and have also added to the wiki (but I messed up the formatting a bit, sozz) a) New element <document> to be added to model.resourceLike ; new element <line> to be added to model.zonePart; new element <patch> allowed within <surface> Together with existing <surface> and <zone> elements, these allow theory neutral transcription of the physicality of document b) several new elements to be added to model.pPart.transcriptional (<mod>, <modSpan>, <metaMark>, <used>, <undo>, <redo>, <rewrite>, <transposeGrp>, <transpose>) These allow more detailed documentation of the writing process than previously possible. c) New <stageNotes> within the existing <creation> element containing new <stageNote> elements to document identified "writing stages" in genesis of a text. New att.staged class to supply @stage attributes for elements which can be assigned to a given writing stage These allow marked up elements to be assigned to particular stages in the genesis of a text, or the writing of a document, or both! I propose to formulate these as feature requests in sourceforge as soon as possible. There will also be an opportunity to discuss and revise the proposals more generally at the workshop Elena is giving in Zadar! From sebastian.rahtz at oucs.ox.ac.uk Wed Oct 20 09:40:10 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Wed, 20 Oct 2010 14:40:10 +0100 Subject: [tei-council] Genetic editing thoughts (item 9 on the nuncling sheet) In-Reply-To: <4CBEF052.6080209@oucs.ox.ac.uk> References: <4CBEF052.6080209@oucs.ox.ac.uk> Message-ID: <12FFAAAB-5432-46CE-ACE3-A8F2E93CF4CC@oucs.ox.ac.uk> Presumably the good thing about all these new elements is that the drafting is largely done. Which module would they go in? scattered around exisiting containers, or a new one? -- Sebastian Rahtz Information and Support Group Manager Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From lou.burnard at oucs.ox.ac.uk Wed Oct 20 09:45:57 2010 From: lou.burnard at oucs.ox.ac.uk (Lou Burnard) Date: Wed, 20 Oct 2010 14:45:57 +0100 Subject: [tei-council] Genetic editing thoughts (item 9 on the nuncling sheet) In-Reply-To: <12FFAAAB-5432-46CE-ACE3-A8F2E93CF4CC@oucs.ox.ac.uk> References: <4CBEF052.6080209@oucs.ox.ac.uk> <12FFAAAB-5432-46CE-ACE3-A8F2E93CF4CC@oucs.ox.ac.uk> Message-ID: <4CBEF295.2060709@oucs.ox.ac.uk> Yes, the drafting and exemplars and everything is all done and in the sourceforge repository (and on the website in HTML form) I am not sure about which modules would be affected. Presumably (b) would go into the existing PH, which could also accomodate (a), but (c) could go in HD or in PH. My personal view is that we don't need a separate module for this, but this is certainly open to debate. On 20/10/10 14:40, Sebastian Rahtz wrote: > Presumably the good thing about all these new elements is that the drafting is largely done. > Which module would they go in? scattered around exisiting containers, or a new one? > > -- > Sebastian Rahtz > Information and Support Group Manager > Oxford University Computing Services > 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 > > S?lo le pido a Dios > que el futuro no me sea indiferente > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council From sebastian.rahtz at oucs.ox.ac.uk Wed Oct 20 09:49:44 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Wed, 20 Oct 2010 14:49:44 +0100 Subject: [tei-council] Genetic editing thoughts (item 9 on the nuncling sheet) In-Reply-To: <4CBEF295.2060709@oucs.ox.ac.uk> References: <4CBEF052.6080209@oucs.ox.ac.uk> <12FFAAAB-5432-46CE-ACE3-A8F2E93CF4CC@oucs.ox.ac.uk> <4CBEF295.2060709@oucs.ox.ac.uk> Message-ID: <A01393B4-18FD-4CF5-90C6-AFBE87193E26@oucs.ox.ac.uk> On 20 Oct 2010, at 14:45, Lou Burnard wrote: > > My personal view is that we don't need a separate module for this, but > this is certainly open to debate. so the default position, I guess, is that these are simply additions to existing toolsets, and that the disruption for most people is pretty small. Good! can we make efficiency savings by cutting the number of new elements by 40%? <note>**UK joke**</note> -- Sebastian Rahtz Information and Support Group Manager Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From kevin.s.hawkins at ultraslavonic.info Wed Oct 20 09:50:45 2010 From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins) Date: Wed, 20 Oct 2010 09:50:45 -0400 Subject: [tei-council] discussion open tickets: please use SourceForge! Message-ID: <4CBEF3B5.3040605@ultraslavonic.info> Folks, I'd like to take a moment to be grouchy by requesting that those "nuncling" tickets post their sythesis as a comment on the ticket. This keeps the decision-making process transparent to non-Council members and makes it easier for the rest of us to see the latest on any ticket so that next time we're asked to vote on a proposal, we can look only at the ticket and not have to do data mining on our email folders. Thanks, Kevin From sebastian.rahtz at oucs.ox.ac.uk Wed Oct 20 09:52:15 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Wed, 20 Oct 2010 14:52:15 +0100 Subject: [tei-council] discussion open tickets: please use SourceForge! In-Reply-To: <4CBEF3B5.3040605@ultraslavonic.info> References: <4CBEF3B5.3040605@ultraslavonic.info> Message-ID: <9E8A87E5-A254-45C1-AF53-A03C659C1EB3@oucs.ox.ac.uk> On 20 Oct 2010, at 14:50, Kevin Hawkins wrote: > > > I'd like to take a moment to be grouchy by requesting that those > "nuncling" tickets post their sythesis as a comment on the ticket. if it wasn't obvious, the two I posted were also on the SF ticket -- Sebastian Rahtz Information and Support Group Manager Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From lou.burnard at oucs.ox.ac.uk Wed Oct 20 09:54:56 2010 From: lou.burnard at oucs.ox.ac.uk (Lou Burnard) Date: Wed, 20 Oct 2010 14:54:56 +0100 Subject: [tei-council] discussion open tickets: please use SourceForge! In-Reply-To: <4CBEF3B5.3040605@ultraslavonic.info> References: <4CBEF3B5.3040605@ultraslavonic.info> Message-ID: <4CBEF4B0.1090200@oucs.ox.ac.uk> I dont think that's particularly grouchy -- sounds like common sense where a ticket already exists. In the case of the comment about genetic editing stuff which I just made here and on the wiki page, there wasn't any ticket to attach it to -- since the discussion was about creating new tickets of course! On 20/10/10 14:50, Kevin Hawkins wrote: > Folks, > > I'd like to take a moment to be grouchy by requesting that those > "nuncling" tickets post their sythesis as a comment on the ticket. This > keeps the decision-making process transparent to non-Council members and > makes it easier for the rest of us to see the latest on any ticket so > that next time we're asked to vote on a proposal, we can look only at > the ticket and not have to do data mining on our email folders. Thanks, > > Kevin > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council From elena.pierazzo at kcl.ac.uk Wed Oct 20 10:09:11 2010 From: elena.pierazzo at kcl.ac.uk (Elena Pierazzo) Date: Wed, 20 Oct 2010 15:09:11 +0100 Subject: [tei-council] Genetic editing thoughts (item 9 on the nuncling sheet) In-Reply-To: <A01393B4-18FD-4CF5-90C6-AFBE87193E26@oucs.ox.ac.uk> References: <4CBEF052.6080209@oucs.ox.ac.uk> <12FFAAAB-5432-46CE-ACE3-A8F2E93CF4CC@oucs.ox.ac.uk> <4CBEF295.2060709@oucs.ox.ac.uk> <A01393B4-18FD-4CF5-90C6-AFBE87193E26@oucs.ox.ac.uk> Message-ID: <4CBEF807.8060603@kcl.ac.uk> >> My personal view is that we don't need a separate module for this, but >> this is certainly open to debate. > > so the default position, I guess, is that these are simply additions to > existing toolsets, and that the disruption for most people is pretty small. > Good! > Yes, that was also the vision of the Working group. > can we make efficiency savings by cutting the number of new elements by 40%? > <note>**UK joke**</note> Ah! It would be very funny if it wasn't so very true... Dr Elena Pierazzo Research Associate Centre for Computing in the Humanities King's College London 26-29 Drury Lane London WC2B 5RL Phone: 0207-848-1949 Fax: 0207-848-2980 elena.pierazzo[at]kcl.ac.uk www.kcl.ac.uk/cch From mholmes at uvic.ca Mon Oct 25 11:00:58 2010 From: mholmes at uvic.ca (Martin Holmes) Date: Mon, 25 Oct 2010 08:00:58 -0700 Subject: [tei-council] Biblio tickets be-nuncled Message-ID: <4CC59BAA.70504@uvic.ca> Kevin, Laurent and I have all now agreed on a recommended course of action for all of the four tickets we're nuncling, and added them as comments to the tickets. Cheers, Martin -- Martin Holmes University of Victoria Humanities Computing and Media Centre (mholmes at uvic.ca) From daniel.odonnell at uleth.ca Mon Oct 25 13:51:16 2010 From: daniel.odonnell at uleth.ca (O'Donnell, Dan) Date: Mon, 25 Oct 2010 11:51:16 -0600 Subject: [tei-council] Anybody have experience with 15-16 people on a Skype call? Message-ID: <4CC5C394.9030200@uleth.ca> Hi all, Currently I donate a teleconference service to the TEI for conference calls. When I first subscribed, it was used by various groups almost weekly (I also donated it to Digital Medievalist and used it for my own projects). Nowadays, just about the only people who use it are Council. With improvements to Skype and the arrival of Google Voice, I'm beginning to wonder if it is worth maintaining. According to some blogs I've read, Skype can now handle up to 25 callers (e.g. http://www.buzzle.com/articles/skype-conference-call-how-to-make-skype-conference-call.html), although some things I've read suggest that that is only using Windows clients. Google voice seems to be able to handle a max of 4 people at the moment. Does anybody have experience using Skype for calls with groups about the size of Council--say 15-16 people all told? Is it robust enough that I could consider dropping my account at Hi-Speed Conferencing? -dan -- Daniel Paul O'Donnell Professor of English University of Lethbridge Chair and CEO, Text Encoding Initiative (http://www.tei-c.org/) Co-Chair, Digital Initiatives Advisory Board, Medieval Academy of America President-elect (English), Society for Digital Humanities/Soci?t? pour l'?tude des m?dias interactifs (http://sdh-semi.org/) Founding Director (2003-2009), Digital Medievalist Project (http://www.digitalmedievalist.org/) Vox: +1 403 329-2377 Fax: +1 403 382-7191 (non-confidential) Home Page: http://people.uleth.ca/~daniel.odonnell/ From sebastian.rahtz at oucs.ox.ac.uk Mon Oct 25 16:35:14 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 25 Oct 2010 21:35:14 +0100 Subject: [tei-council] Anybody have experience with 15-16 people on a Skype call? In-Reply-To: <4CC5C394.9030200@uleth.ca> References: <4CC5C394.9030200@uleth.ca> Message-ID: <B3B65F8A-B02A-40E4-94BE-EF9BB6F046D0@oucs.ox.ac.uk> What is the Board using instead? I must say, I can't recall a Council telco in the last 6 months anyway..... Our local advice is always the same about eg Skype - it all depends on getting folks to have the right setup and equipment. It can work very well, or be a disaster. Certainly a dozen people using Skype just by talking at their netbooks is likely to be bad. -- Sebastian Rahtz Information and Support Group Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From daniel.odonnell at uleth.ca Mon Oct 25 16:52:00 2010 From: daniel.odonnell at uleth.ca (O'Donnell, Dan) Date: Mon, 25 Oct 2010 14:52:00 -0600 Subject: [tei-council] Anybody have experience with 15-16 people on a Skype call? In-Reply-To: <B3B65F8A-B02A-40E4-94BE-EF9BB6F046D0@oucs.ox.ac.uk> References: <4CC5C394.9030200@uleth.ca> <B3B65F8A-B02A-40E4-94BE-EF9BB6F046D0@oucs.ox.ac.uk> Message-ID: <4CC5EDF0.7030009@uleth.ca> At the board we've been doing most business lately by email as well. On 10-10-25 02:35 PM, Sebastian Rahtz wrote: > What is the Board using instead? > > I must say, I can't recall a Council telco in the last 6 months anyway..... > > Our local advice is always the same about eg Skype - it all depends on > getting folks to have the right setup and equipment. It can work very > well, or be a disaster. Certainly a dozen people using Skype just > by talking at their netbooks is likely to be bad. > -- > Sebastian Rahtz > Information and Support Group Manager, Oxford University Computing Services > 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 > > S?lo le pido a Dios > que el futuro no me sea indiferente > > > > > > -- Daniel Paul O'Donnell Professor of English University of Lethbridge Chair and CEO, Text Encoding Initiative (http://www.tei-c.org/) Co-Chair, Digital Initiatives Advisory Board, Medieval Academy of America President-elect (English), Society for Digital Humanities/Soci?t? pour l'?tude des m?dias interactifs (http://sdh-semi.org/) Founding Director (2003-2009), Digital Medievalist Project (http://www.digitalmedievalist.org/) Vox: +1 403 329-2377 Fax: +1 403 382-7191 (non-confidential) Home Page: http://people.uleth.ca/~daniel.odonnell/ From sebastian.rahtz at oucs.ox.ac.uk Tue Oct 26 04:32:53 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 26 Oct 2010 09:32:53 +0100 Subject: [tei-council] approaching lockdown on P5 1.8 Message-ID: <CC0C4F33-B220-4196-AF7B-F52AE467B67F@oucs.ox.ac.uk> If (as I assume) we are announcing a new release at the TEI MM in Zadar, I need to start closing the P5 sources next week. I am leaving for Zadar on 7th, so I have to make the release on 5th. This means that if you want some of the currently debated items to make it onto the statute book, you need to get them agreed this week. I assume that Laurent is collating the catalogue of agreed changes for 1.9? under current model, that would come out in February 2011. -- Sebastian Rahtz Information and Support Group Manager Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From lou.burnard at oucs.ox.ac.uk Tue Oct 26 08:36:48 2010 From: lou.burnard at oucs.ox.ac.uk (Lou Burnard) Date: Tue, 26 Oct 2010 13:36:48 +0100 Subject: [tei-council] approaching lockdown on P5 1.8 In-Reply-To: <CC0C4F33-B220-4196-AF7B-F52AE467B67F@oucs.ox.ac.uk> References: <CC0C4F33-B220-4196-AF7B-F52AE467B67F@oucs.ox.ac.uk> Message-ID: <4CC6CB60.6010805@oucs.ox.ac.uk> By this weekend, I propose to implement at least the following GREEN category tickets (unless anyone on Council wishes to object) which will therefore all make it into 1.8 3045672 : constrain content model of <altIdent> 2987241 : permit <bibl> within <bibl>; add discussion of what this means 3080658 : revise text of DI to refer to "lexical resource" passim 3090867 : change @targets to @target on <link> example 3093047 : clarify <date> within <imprint> 3064014 : provide examples for rs at type Plus whatever other tickets we manage to reach consensus on before then as well of course. The bibliographical nuncles have done a great job ... how about the rest of you? On 26/10/10 09:32, Sebastian Rahtz wrote: > If (as I assume) we are announcing a new release at the TEI MM in Zadar, I need to start closing the P5 sources > next week. I am leaving for Zadar on 7th, so I have to make the release on 5th. > > This means that if you want some of the currently debated items to make it onto the statute book, you need > to get them agreed this week. > > I assume that Laurent is collating the catalogue of agreed changes for 1.9? under current model, that would come > out in February 2011. > -- > Sebastian Rahtz > Information and Support Group Manager > Oxford University Computing Services > 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 > > S?lo le pido a Dios > que el futuro no me sea indiferente > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council From sebastian.rahtz at oucs.ox.ac.uk Mon Nov 1 07:06:32 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 1 Nov 2010 11:06:32 +0000 Subject: [tei-council] nuncles and releases and TEI MM Message-ID: <057F689E-88C3-4684-AB77-D90AD180DF23@oucs.ox.ac.uk> I am not sure Laurent said how he proposed to take the next stage in his nuncllng? what happens now that quite a lot of the work is done? Which brings me to TEI 1.8. If any new features are to be agreed for this release, it needs to happen very much NOW, in the next day or two. if some of the changes at http://wiki.tei-c.org/index.php/Council_FR_assignments are really holding up work, speak now? Which brings to the TEI MM. In the past, I think we have discussed the Council Chair's speech and its promises to the electorate. It would be nice to do the same this year? And one more thing - a quick council meet in Zadar to resolve some of these outstanding tickets? -- Sebastian Rahtz Information and Support Group Manager Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From laurent.romary at inria.fr Mon Nov 1 08:05:03 2010 From: laurent.romary at inria.fr (Laurent Romary) Date: Mon, 1 Nov 2010 13:05:03 +0100 Subject: [tei-council] nuncles and releases and TEI MM In-Reply-To: <276353783.95079.1288609597532.JavaMail.root@zmbs3.inria.fr> References: <276353783.95079.1288609597532.JavaMail.root@zmbs3.inria.fr> Message-ID: <8A3C7A12-52C0-4BFD-ACBB-58BFA4220052@inria.fr> Hi Sebastian, As a team work, the idea is that nunclers (like the bib gang) actually signal when their tickets are ready to be implemented and the editorial support takes this over. As to the speech... I have been more swanp recently than last year and you have taken the bad habit of me being early in preparing something, but since you ask, I would certainly receive highlights to mention (I would probably mention the changes to come with new host structure... I guess you could give me some hints on things I should say). As to Zadar, complex, since I have understood not everyone will be there. We should at least book a lunch to go through hot points. Thursday? Laurent Le 1 nov. 10 ? 12:06, Sebastian Rahtz a ?crit : > I am not sure Laurent said how he proposed to take the next stage in > his nuncllng? what happens now that > quite a lot of the work is done? > > Which brings me to TEI 1.8. If any new features are to be agreed > for this release, > it needs to happen very much NOW, in the next day or two. if some > of the changes at > http://wiki.tei-c.org/index.php/Council_FR_assignments are really > holding up work, > speak now? > > Which brings to the TEI MM. In the past, I think we have discussed > the Council Chair's > speech and its promises to the electorate. It would be nice to do > the same this year? > > And one more thing - a quick council meet in Zadar to resolve some > of these outstanding tickets? > -- > Sebastian Rahtz > Information and Support Group Manager > Oxford University Computing Services > 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 > > S?lo le pido a Dios > que el futuro no me sea indiferente > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Laurent Romary INRIA & HUB-IDSL laurent.romary at inria.fr From sebastian.rahtz at oucs.ox.ac.uk Mon Nov 1 08:18:32 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 1 Nov 2010 12:18:32 +0000 Subject: [tei-council] nuncles and releases and TEI MM In-Reply-To: <8A3C7A12-52C0-4BFD-ACBB-58BFA4220052@inria.fr> References: <276353783.95079.1288609597532.JavaMail.root@zmbs3.inria.fr> <8A3C7A12-52C0-4BFD-ACBB-58BFA4220052@inria.fr> Message-ID: <15DB2220-A3D6-417A-A12E-DB7E08749BDA@oucs.ox.ac.uk> On 1 Nov 2010, at 12:05, Laurent Romary wrote: > > As a team work, the idea is that nunclers (like the bib gang) actually > signal when their tickets are ready to be implemented and the > editorial support takes this over. but surely the teams were briefed to discuss the topic and make a recommendation back to the rest of the council to decide on? not simply to decide and then have it done. > > As to the speech... I have been more swanp recently than last year and > you have taken the bad habit of me being early in preparing something, > but since you ask, I would certainly receive highlights to mention (I > would probably mention the changes to come with new host structure... > I guess you could give me some hints on things I should say). i suspect people would like to hear a description for what work the council will do in the coming year, which is why we need the nuncling results clear. Obviously we cannot now implement most of the changes before January/February, but it would show willing to list and explain them. -- Sebastian Rahtz Information and Support Group Manager Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From mholmes at uvic.ca Mon Nov 1 12:07:28 2010 From: mholmes at uvic.ca (Martin Holmes) Date: Mon, 1 Nov 2010 09:07:28 -0700 Subject: [tei-council] nuncles and releases and TEI MM In-Reply-To: <057F689E-88C3-4684-AB77-D90AD180DF23@oucs.ox.ac.uk> References: <057F689E-88C3-4684-AB77-D90AD180DF23@oucs.ox.ac.uk> Message-ID: <4CCEE5C0.5040902@uvic.ca> We (the biblio gang) posted our final recommendations to the council as comments on the tickets. We assumed that the council would simply vote on our recommendations, but on one of them, Lou has made further comments, which seems to suggest that he believes we should continue to debate them. Personally, I think we should just vote on the nuncles' recommendations. For the biblio tickets, we're waiting to see the outcome of the votes before we can continue with our larger review. Cheers, Martin On 10-11-01 04:06 AM, Sebastian Rahtz wrote: > I am not sure Laurent said how he proposed to take the next stage in his nuncllng? what happens now that > quite a lot of the work is done? > > Which brings me to TEI 1.8. If any new features are to be agreed for this release, > it needs to happen very much NOW, in the next day or two. if some of the changes at > http://wiki.tei-c.org/index.php/Council_FR_assignments are really holding up work, > speak now? > > Which brings to the TEI MM. In the past, I think we have discussed the Council Chair's > speech and its promises to the electorate. It would be nice to do the same this year? > > And one more thing - a quick council meet in Zadar to resolve some of these outstanding tickets? > -- > Sebastian Rahtz > Information and Support Group Manager > Oxford University Computing Services > 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 > > S?lo le pido a Dios > que el futuro no me sea indiferente > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > -- Martin Holmes University of Victoria Humanities Computing and Media Centre (mholmes at uvic.ca) From lou.burnard at oucs.ox.ac.uk Mon Nov 1 13:34:10 2010 From: lou.burnard at oucs.ox.ac.uk (Lou Burnard) Date: Mon, 01 Nov 2010 17:34:10 +0000 Subject: [tei-council] nuncles and releases and TEI MM In-Reply-To: <4CCEE5C0.5040902@uvic.ca> References: <057F689E-88C3-4684-AB77-D90AD180DF23@oucs.ox.ac.uk> <4CCEE5C0.5040902@uvic.ca> Message-ID: <4CCEFA12.7000103@oucs.ox.ac.uk> Hi Martin Are you referring to ticket *2976715? If so, my comment was just to point out that I disagreed with the recommendation, and hadn't been involved in its most recent formulation, despite what it says on the ticket. This doesn't seem like an inappropriate comment to me, and certainly isn't meant to preclude anyone else expressing their opinion! I do think this particular issue needs proper discussion, as the current situation is clearly unsatisfactory. If your "gang" has discussed it, maybe you could summarize that discussion to show what has led you to make your recommendation? Lou * Martin Holmes wrote: > We (the biblio gang) posted our final recommendations to the council as > comments on the tickets. We assumed that the council would simply vote > on our recommendations, but on one of them, Lou has made further > comments, which seems to suggest that he believes we should continue to > debate them. Personally, I think we should just vote on the nuncles' > recommendations. For the biblio tickets, we're waiting to see the > outcome of the votes before we can continue with our larger review. > > Cheers, > Martin > > On 10-11-01 04:06 AM, Sebastian Rahtz wrote: > >> I am not sure Laurent said how he proposed to take the next stage in his nuncllng? what happens now that >> quite a lot of the work is done? >> >> Which brings me to TEI 1.8. If any new features are to be agreed for this release, >> it needs to happen very much NOW, in the next day or two. if some of the changes at >> http://wiki.tei-c.org/index.php/Council_FR_assignments are really holding up work, >> speak now? >> >> Which brings to the TEI MM. In the past, I think we have discussed the Council Chair's >> speech and its promises to the electorate. It would be nice to do the same this year? >> >> And one more thing - a quick council meet in Zadar to resolve some of these outstanding tickets? >> -- >> Sebastian Rahtz >> Information and Support Group Manager >> Oxford University Computing Services >> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 >> >> S?lo le pido a Dios >> que el futuro no me sea indiferente >> >> _______________________________________________ >> tei-council mailing list >> tei-council at lists.village.Virginia.EDU >> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council >> >> > > From mholmes at uvic.ca Mon Nov 1 14:14:18 2010 From: mholmes at uvic.ca (Martin Holmes) Date: Mon, 1 Nov 2010 11:14:18 -0700 Subject: [tei-council] nuncles and releases and TEI MM In-Reply-To: <4CCEFA12.7000103@oucs.ox.ac.uk> References: <057F689E-88C3-4684-AB77-D90AD180DF23@oucs.ox.ac.uk> <4CCEE5C0.5040902@uvic.ca> <4CCEFA12.7000103@oucs.ox.ac.uk> Message-ID: <4CCF037A.2080709@uvic.ca> Hi Lou, Yes, it's 2976715. The discussion we had is more or less covered by the comments. We all agree on the need for <distributor>, <principal>, <funder> and <sponsor> to be available in <analytic>, <monogr> and <series>, and the cleanest way to do that seems to us to be adding <distributor> to model.respLike, and then replacing explicit references to <author>, <editor> and <respStmt> with references to model.respLike. Kevin also believes that model.respLike needs some work, but that's beyond the scope of this ticket, and would almost certainly involve breaking backward compatibility, so we've stuck with a recommendation that solves the immediate problem and gives us a better starting point for later work on model.respLike, should that be necessary. I'd have to go back through a lot of email to compile an extra summary, but I don't think you'd see anything that would convince you. I think you just disagree with us on this, and it should go to a vote. It was my mistake typing "LB" instead of "LR", but there doesn't seem to be any way to edit a comment on SF, so there was nothing I could do to fix it -- does anyone know a way to do that? Cheers, Martin On 10-11-01 10:34 AM, Lou Burnard wrote: > Hi Martin > > Are you referring to ticket *2976715? If so, my comment was just to > point out that I disagreed with the recommendation, and hadn't been > involved in its most recent formulation, despite what it says on the > ticket. This doesn't seem like an inappropriate comment to me, and > certainly isn't meant to preclude anyone else expressing their opinion! > > I do think this particular issue needs proper discussion, as the current > situation is clearly unsatisfactory. If your "gang" has discussed it, > maybe you could summarize that discussion to show what has led you to > make your recommendation? > > Lou > > * Martin Holmes wrote: >> We (the biblio gang) posted our final recommendations to the council as >> comments on the tickets. We assumed that the council would simply vote >> on our recommendations, but on one of them, Lou has made further >> comments, which seems to suggest that he believes we should continue to >> debate them. Personally, I think we should just vote on the nuncles' >> recommendations. For the biblio tickets, we're waiting to see the >> outcome of the votes before we can continue with our larger review. >> >> Cheers, >> Martin >> >> On 10-11-01 04:06 AM, Sebastian Rahtz wrote: >> >>> I am not sure Laurent said how he proposed to take the next stage in his nuncllng? what happens now that >>> quite a lot of the work is done? >>> >>> Which brings me to TEI 1.8. If any new features are to be agreed for this release, >>> it needs to happen very much NOW, in the next day or two. if some of the changes at >>> http://wiki.tei-c.org/index.php/Council_FR_assignments are really holding up work, >>> speak now? >>> >>> Which brings to the TEI MM. In the past, I think we have discussed the Council Chair's >>> speech and its promises to the electorate. It would be nice to do the same this year? >>> >>> And one more thing - a quick council meet in Zadar to resolve some of these outstanding tickets? >>> -- >>> Sebastian Rahtz >>> Information and Support Group Manager >>> Oxford University Computing Services >>> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 >>> >>> S?lo le pido a Dios >>> que el futuro no me sea indiferente >>> >>> _______________________________________________ >>> tei-council mailing list >>> tei-council at lists.village.Virginia.EDU >>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council >>> >>> >> >> > -- Martin Holmes University of Victoria Humanities Computing and Media Centre (mholmes at uvic.ca) From sebastian.rahtz at oucs.ox.ac.uk Fri Nov 5 12:16:41 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Fri, 5 Nov 2010 16:16:41 +0000 Subject: [tei-council] TEI 1.8.0 release Message-ID: <36AC0374-5579-4212-98B1-09A87D9A7852@oucs.ox.ac.uk> Now up on Sourceforge and web site, and as Debian packages. The downside is that the web site is bust - I suspect because Shayne is trying to install OxGarage for me. Release notice to TEI-L on Monday -- Sebastian Rahtz Information and Support Group Manager Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From sebastian.rahtz at oucs.ox.ac.uk Mon Nov 8 10:50:56 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 8 Nov 2010 15:50:56 +0000 Subject: [tei-council] OxGarage rules.... Message-ID: <C97D96FA-B712-4FD5-AA71-83B53F103E80@oucs.ox.ac.uk> on the Virginia server, at http://www.tei-c.org/ege-webclient/ Not all there yet, but it does the main goods. -- Sebastian Rahtz Information and Support Group Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From sebastian.rahtz at oucs.ox.ac.uk Tue Nov 9 04:16:30 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 9 Nov 2010 09:16:30 +0000 Subject: [tei-council] test new roma Message-ID: <5CB0D718-9B17-4A3F-B392-B2C68431093D@oucs.ox.ac.uk> see http://www.tei-c.org/Roma2/index.html for a revised Roma which is based on OxGarage behind the scenes. -- Sebastian Rahtz Information and Support Group Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From laurent.romary at inria.fr Wed Nov 10 00:48:43 2010 From: laurent.romary at inria.fr (Laurent Romary) Date: Wed, 10 Nov 2010 06:48:43 +0100 Subject: [tei-council] Council report Message-ID: <D9772CDD-36C8-4DE9-B14A-186B0BC50807@inria.fr> Hi council, Before flying off to Zadar, I have put together some slides to illustrate our activity so far. I am planning to shaw SF live, so that people get a concrete view at what's going on behind the scenes. The slides are just there to give some snapshots here and there. Please have a look at the attached files and if you want, provide suggestions for improvement. Thanks, Laurent -------------- next part -------------- A non-text attachment was scrubbed... Name: CouncilReportNovember2010.pptx Type: application/vnd.openxmlformats-officedocument.presentationml.presentation Size: 57067 bytes Desc: not available Url : http://lists.village.Virginia.EDU/pipermail/tei-council/attachments/20101110/285a8275/attachment.bin -------------- next part -------------- Laurent Romary INRIA & HUB-IDSL laurent.romary at inria.fr From laurent.romary at inria.fr Wed Nov 10 00:50:04 2010 From: laurent.romary at inria.fr (Laurent Romary) Date: Wed, 10 Nov 2010 06:50:04 +0100 Subject: [tei-council] Council report - pdf version In-Reply-To: <189340340.417734.1289368137116.JavaMail.root@zmbs3.inria.fr> References: <189340340.417734.1289368137116.JavaMail.root@zmbs3.inria.fr> Message-ID: <2F2D691D-2750-4E96-869B-A50ED931F020@inria.fr> A non-text attachment was scrubbed... Name: CouncilReportNovember2010.pdf Type: application/pdf Size: 255861 bytes Desc: not available Url : http://lists.village.Virginia.EDU/pipermail/tei-council/attachments/20101110/7f43312c/attachment.pdf -------------- next part -------------- Le 10 nov. 10 ? 06:48, Laurent Romary a ?crit : > Hi council, > Before flying off to Zadar, I have put together some slides to > illustrate our activity so far. I am planning to shaw SF live, so > that people get a concrete view at what's going on behind the > scenes. The slides are just there to give some snapshots here and > there. > Please have a look at the attached files and if you want, provide > suggestions for improvement. > Thanks, > Laurent > <CouncilReportNovember2010.pptx> > > > > Laurent Romary > INRIA & HUB-IDSL > laurent.romary at inria.fr > > > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Laurent Romary INRIA & HUB-IDSL laurent.romary at inria.fr From julianne.nyhan at gmail.com Wed Nov 10 11:10:41 2010 From: julianne.nyhan at gmail.com (Julianne Nyhan) Date: Wed, 10 Nov 2010 11:10:41 -0500 Subject: [tei-council] Council report - pdf version In-Reply-To: <2F2D691D-2750-4E96-869B-A50ED931F020@inria.fr> References: <189340340.417734.1289368137116.JavaMail.root@zmbs3.inria.fr> <2F2D691D-2750-4E96-869B-A50ED931F020@inria.fr> Message-ID: <AANLkTim-a=bnS+81GE-pFjjZTtnGx9fnfxZR4VaLJ3HX@mail.gmail.com> Dear Laurent, Thank you for the slides - they give a good overview of the year's work. I hope you and other Council members who can make it have an enjoyable and productive time in Zadar. Yours, Julianne On Wed, Nov 10, 2010 at 12:50 AM, Laurent Romary <laurent.romary at inria.fr>wrote: > > > Le 10 nov. 10 ? 06:48, Laurent Romary a ?crit : > > Hi council, >> Before flying off to Zadar, I have put together some slides to illustrate >> our activity so far. I am planning to shaw SF live, so that people get a >> concrete view at what's going on behind the scenes. The slides are just >> there to give some snapshots here and there. >> Please have a look at the attached files and if you want, provide >> suggestions for improvement. >> Thanks, >> Laurent >> <CouncilReportNovember2010.pptx> >> >> >> >> Laurent Romary >> INRIA & HUB-IDSL >> laurent.romary at inria.fr >> >> >> >> _______________________________________________ >> tei-council mailing list >> tei-council at lists.village.Virginia.EDU >> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council >> > > Laurent Romary > INRIA & HUB-IDSL > laurent.romary at inria.fr > > > > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > > -- Dr Julianne Nyhan, (UCL & Universitaet Trier) *Direct Line:* +44 (0)20 7679 7206) *Fax:* +44 (0)20 7383 0557) *Office:* G15a, Department of Information Studies, Foster Court, University College London, WC1E 6BT, U.K. http://www.ucl.ac.uk/infostudies/julianne-nyhan/ http://germazope.uni-trier.de/Projects/KoZe2/ http://epu.ucc.ie/theses/jnyhan/ http://maney.co.uk/index.php/journals/isr/ From laurent.romary at inria.fr Thu Nov 11 05:15:08 2010 From: laurent.romary at inria.fr (Laurent Romary) Date: Thu, 11 Nov 2010 11:15:08 +0100 Subject: [tei-council] Early dinner in Zadar Message-ID: <68BCA373-7CC6-48EA-863E-D6EB109D5B6F@inria.fr> Would some of you want to have a council dinner in Zadar tonight. We could go out for drinks and food after the business meeting tonight. Anyone would suggest a good place? Laurent Romary INRIA & HUB-IDSL laurent.romary at inria.fr From sebastian.rahtz at oucs.ox.ac.uk Thu Nov 11 05:23:07 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Thu, 11 Nov 2010 10:23:07 +0000 Subject: [tei-council] Early dinner in Zadar In-Reply-To: <68BCA373-7CC6-48EA-863E-D6EB109D5B6F@inria.fr> References: <68BCA373-7CC6-48EA-863E-D6EB109D5B6F@inria.fr> Message-ID: <03BD5DAA-B24D-468F-863B-68FA2EB89BFB@oucs.ox.ac.uk> On 11 Nov 2010, at 11:15, Laurent Romary wrote: > Would some of you want to have a council dinner in Zadar tonight. We > could go out for drinks and food after the business meeting tonight. > Anyone would suggest a good place? small restaurant at Pet Bunari (http://www.google.co.uk/search?sourceid=chrome&ie=UTF-8&q=pet+bunari+zadar) is possibility. -- Sebastian Rahtz Information and Support Group Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From laurent.romary at inria.fr Thu Nov 11 05:40:53 2010 From: laurent.romary at inria.fr (Laurent Romary) Date: Thu, 11 Nov 2010 11:40:53 +0100 Subject: [tei-council] Early dinner in Zadar In-Reply-To: <1732241793.466646.1289470989000.JavaMail.root@zmbs3.inria.fr> References: <68BCA373-7CC6-48EA-863E-D6EB109D5B6F@inria.fr> <1732241793.466646.1289470989000.JavaMail.root@zmbs3.inria.fr> Message-ID: <81C47E9A-3DCE-495F-9AFC-5854C51DA873@inria.fr> OK. We'll follow you. Le 11 nov. 10 ? 11:23, Sebastian Rahtz a ?crit : > > On 11 Nov 2010, at 11:15, Laurent Romary wrote: > >> Would some of you want to have a council dinner in Zadar tonight. We >> could go out for drinks and food after the business meeting tonight. >> Anyone would suggest a good place? > > > small restaurant at Pet Bunari (http://www.google.co.uk/search?sourceid=chrome&ie=UTF-8&q=pet+bunari+zadar > ) > is possibility. > -- > Sebastian Rahtz > Information and Support Group Manager, Oxford University Computing > Services > 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 > > S?lo le pido a Dios > que el futuro no me sea indiferente > > > > > Laurent Romary INRIA & HUB-IDSL laurent.romary at inria.fr From sebastian.rahtz at oucs.ox.ac.uk Thu Nov 11 05:49:07 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Thu, 11 Nov 2010 10:49:07 +0000 Subject: [tei-council] Early dinner in Zadar In-Reply-To: <81C47E9A-3DCE-495F-9AFC-5854C51DA873@inria.fr> References: <68BCA373-7CC6-48EA-863E-D6EB109D5B6F@inria.fr> <1732241793.466646.1289470989000.JavaMail.root@zmbs3.inria.fr> <81C47E9A-3DCE-495F-9AFC-5854C51DA873@inria.fr> Message-ID: <3305AF07-F463-482C-98F9-6E068FAB648D@oucs.ox.ac.uk> see http://www.petbunara.hr/indexeng.html - James and Lou know it well. possibly will need booking at lunchtime - how many people? -- Sebastian Rahtz Information and Support Group Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From laurent.romary at inria.fr Thu Nov 11 05:57:09 2010 From: laurent.romary at inria.fr (Laurent Romary) Date: Thu, 11 Nov 2010 11:57:09 +0100 Subject: [tei-council] Early dinner in Zadar In-Reply-To: <1887457086.467116.1289472549640.JavaMail.root@zmbs3.inria.fr> References: <68BCA373-7CC6-48EA-863E-D6EB109D5B6F@inria.fr> <1732241793.466646.1289470989000.JavaMail.root@zmbs3.inria.fr> <81C47E9A-3DCE-495F-9AFC-5854C51DA873@inria.fr> <1887457086.467116.1289472549640.JavaMail.root@zmbs3.inria.fr> Message-ID: <E7C9E8E2-A5AD-4C9D-8B3D-58E0D857E96F@inria.fr> @dan: will we know who the newcomers will be? Le 11 nov. 10 ? 11:49, Sebastian Rahtz a ?crit : > see http://www.petbunara.hr/indexeng.html - James and Lou know it > well. > > possibly will need booking at lunchtime - how many people? > > -- > Sebastian Rahtz > Information and Support Group Manager, Oxford University Computing > Services > 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 > > S?lo le pido a Dios > que el futuro no me sea indiferente > > > > > Laurent Romary INRIA & HUB-IDSL laurent.romary at inria.fr From James.Cummings at oucs.ox.ac.uk Thu Nov 11 08:41:15 2010 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Thu, 11 Nov 2010 14:41:15 +0100 Subject: [tei-council] Early dinner in Zadar In-Reply-To: <68BCA373-7CC6-48EA-863E-D6EB109D5B6F@inria.fr> References: <68BCA373-7CC6-48EA-863E-D6EB109D5B6F@inria.fr> Message-ID: <4CDBF27B.9090607@oucs.ox.ac.uk> Sounds good to me and if Pet Bunara has room that would be suitable. -j On 11/11/10 11:15, Laurent Romary wrote: > Would some of you want to have a council dinner in Zadar tonight. We > could go out for drinks and food after the business meeting tonight. > Anyone would suggest a good place? > > > Laurent Romary > INRIA& HUB-IDSL > laurent.romary at inria.fr > > > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council -- Dr James Cummings Research Technologies Service, University of Oxford From laurent.romary at inria.fr Thu Nov 11 08:44:11 2010 From: laurent.romary at inria.fr (Laurent Romary) Date: Thu, 11 Nov 2010 14:44:11 +0100 Subject: [tei-council] Early dinner in Zadar In-Reply-To: <1026601576.469459.1289482878104.JavaMail.root@zmbs3.inria.fr> References: <68BCA373-7CC6-48EA-863E-D6EB109D5B6F@inria.fr> <1026601576.469459.1289482878104.JavaMail.root@zmbs3.inria.fr> Message-ID: <54CBE2CD-F4C4-4A4E-804A-D89997F4F792@inria.fr> Booking made already! Le 11 nov. 10 ? 14:41, James Cummings a ?crit : > > Sounds good to me and if Pet Bunara has room that would be suitable. > > -j > > > On 11/11/10 11:15, Laurent Romary wrote: >> Would some of you want to have a council dinner in Zadar tonight. We >> could go out for drinks and food after the business meeting tonight. >> Anyone would suggest a good place? >> >> >> Laurent Romary >> INRIA& HUB-IDSL >> laurent.romary at inria.fr >> >> >> >> _______________________________________________ >> tei-council mailing list >> tei-council at lists.village.Virginia.EDU >> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > > > -- > Dr James Cummings > Research Technologies Service, University of Oxford Laurent Romary INRIA & HUB-IDSL laurent.romary at inria.fr From mjd at hum.ku.dk Thu Nov 11 08:47:44 2010 From: mjd at hum.ku.dk (Matthew James Driscoll) Date: Thu, 11 Nov 2010 14:47:44 +0100 Subject: [tei-council] Early dinner in Zadar In-Reply-To: <54CBE2CD-F4C4-4A4E-804A-D89997F4F792@inria.fr> References: <68BCA373-7CC6-48EA-863E-D6EB109D5B6F@inria.fr> <1026601576.469459.1289482878104.JavaMail.root@zmbs3.inria.fr> <54CBE2CD-F4C4-4A4E-804A-D89997F4F792@inria.fr> Message-ID: <CF2BD0FB82A2624EA40D0EE4379C896D7925F23B33@post> Sorry I'm not able to join you. Have some bijelo vino for me. Matthew -----Oprindelig meddelelse----- Fra: tei-council-bounces at lists.village.Virginia.EDU [mailto:tei-council-bounces at lists.village.Virginia.EDU] P? vegne af Laurent Romary Sendt: 11. november 2010 14:44 Til: James.Cummings at oucs.ox.ac.uk Cc: TEI Council Emne: Re: [tei-council] Early dinner in Zadar Booking made already! Le 11 nov. 10 ? 14:41, James Cummings a ?crit : > > Sounds good to me and if Pet Bunara has room that would be suitable. > > -j > > > On 11/11/10 11:15, Laurent Romary wrote: >> Would some of you want to have a council dinner in Zadar tonight. We >> could go out for drinks and food after the business meeting tonight. >> Anyone would suggest a good place? >> >> >> Laurent Romary >> INRIA& HUB-IDSL >> laurent.romary at inria.fr >> >> >> >> _______________________________________________ >> tei-council mailing list >> tei-council at lists.village.Virginia.EDU >> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > > > -- > Dr James Cummings > Research Technologies Service, University of Oxford Laurent Romary INRIA & HUB-IDSL laurent.romary at inria.fr _______________________________________________ tei-council mailing list tei-council at lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council From dot.porter at gmail.com Thu Nov 11 10:07:44 2010 From: dot.porter at gmail.com (Dot Porter) Date: Thu, 11 Nov 2010 16:07:44 +0100 Subject: [tei-council] Early dinner in Zadar In-Reply-To: <CF2BD0FB82A2624EA40D0EE4379C896D7925F23B33@post> References: <68BCA373-7CC6-48EA-863E-D6EB109D5B6F@inria.fr> <1026601576.469459.1289482878104.JavaMail.root@zmbs3.inria.fr> <54CBE2CD-F4C4-4A4E-804A-D89997F4F792@inria.fr> <CF2BD0FB82A2624EA40D0EE4379C896D7925F23B33@post> Message-ID: <AANLkTikxmzD1+4CWVR_8a7R_oRp4S5RU60FK6X6A86oD@mail.gmail.com> Laurent I checked my email! I am coming! Matthew sad you are not here :-( Dot On Thu, Nov 11, 2010 at 2:47 PM, Matthew James Driscoll <mjd at hum.ku.dk> wrote: > Sorry I'm not able to join you. Have some bijelo vino for me. > > Matthew > > -----Oprindelig meddelelse----- > Fra: tei-council-bounces at lists.village.Virginia.EDU [mailto:tei-council-bounces at lists.village.Virginia.EDU] P? vegne af Laurent Romary > Sendt: 11. november 2010 14:44 > Til: James.Cummings at oucs.ox.ac.uk > Cc: TEI Council > Emne: Re: [tei-council] Early dinner in Zadar > > Booking made already! > > Le 11 nov. 10 ? 14:41, James Cummings a ?crit : > >> >> Sounds good to me and if Pet Bunara has room that would be suitable. >> >> -j >> >> >> On 11/11/10 11:15, Laurent Romary wrote: >>> Would some of you want to have a council dinner in Zadar tonight. We >>> could go out for drinks and food after the business meeting tonight. >>> Anyone would suggest a good place? >>> >>> >>> Laurent Romary >>> INRIA& ?HUB-IDSL >>> laurent.romary at inria.fr >>> >>> >>> >>> _______________________________________________ >>> tei-council mailing list >>> tei-council at lists.village.Virginia.EDU >>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council >> >> >> -- >> Dr James Cummings >> Research Technologies Service, University of Oxford > > Laurent Romary > INRIA & HUB-IDSL > laurent.romary at inria.fr > > > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > -- *~*~*~*~*~*~*~*~*~*~* Dot Porter (MA, MSLS) Digital Medievalist, Digital Librarian Email: dot.porter at gmail.com *~*~*~*~*~*~*~*~*~*~* From laurent.romary at inria.fr Thu Nov 11 10:25:23 2010 From: laurent.romary at inria.fr (Laurent Romary) Date: Thu, 11 Nov 2010 16:25:23 +0100 Subject: [tei-council] Fwd: [ tei-Feature Requests-3095637 ] New <document> <patch> <line> elements for genetic view References: <989254717.469960.1289484485373.JavaMail.root@zmbs3.inria.fr> Message-ID: <6386A022-456C-472B-85C5-F5D4AD0FF482@inria.fr> Folks, It looks like a clear issue. Could people having a view check it is OK and people to shout if it is indeed unsatisfactory. In depth comments in SF please! Laurent D?but du message r?exp?di? : > De : "SourceForge.net" <noreply at sourceforge.net> > Date : 11 novembre 2010 15:08:05 GMT+01:00 > ? : Laurent.Romary at loria.fr > Objet : [ tei-Feature Requests-3095637 ] New <document> <patch> > <line> elements for genetic view > > Feature Requests item #3095637, was opened at 2010-10-26 09:57 > Message generated for change (Comment added) made by dot_porter > You can respond by visiting: > https://sourceforge.net/tracker/?func=detail&atid=644065&aid=3095637&group_id=106328 > > Please note that this message will contain a full copy of the > comment thread, > including the initial issue submission, for this request, > not just the latest update. > Category: TEI: New or Changed Element > Group: AMBER > Status: Open > Resolution: None > Priority: 5 > Private: No > Submitted By: Lou Burnard (louburnard) > Assigned to: Nobody/Anonymous (nobody) > Summary: New <document> <patch> <line> elements for genetic view > > Initial Comment: > New element <document> to be added to model.resourceLike ; new > element <line> to be added to model.zonePart; new element <patch> > allowed within <surface>. Together with existing <surface> and > <zone> elements, these allow theory-neutral transcription of the > physicality of document. > > Justification, element specs, and examples are in the Genetic WG > document at http://www.tei-c.org/Activities/Council/Working/ > tcw19.html (derived from http://tei.svn.sourceforge.net/viewvc/tei/trunk/genetic/) > > > ---------------------------------------------------------------------- > > Comment By: Dot Porter (dot_porter) > Date: 2010-11-11 09:08 > > Message: > I would like to see these added to the TEI, as described in the > Genetic WG > document. I would very much like to see also recommendations for > stand-off > document-centric markup, but that is a separate issue. > > ---------------------------------------------------------------------- > > You can respond by visiting: > https://sourceforge.net/tracker/?func=detail&atid=644065&aid=3095637&group_id=106328 Laurent Romary INRIA & HUB-IDSL laurent.romary at inria.fr From sebastian.rahtz at oucs.ox.ac.uk Fri Nov 12 09:14:51 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Fri, 12 Nov 2010 14:14:51 +0000 Subject: [tei-council] Fwd: [ tei-Feature Requests-3095637 ] New <document> <patch> <line> elements for genetic view In-Reply-To: <6386A022-456C-472B-85C5-F5D4AD0FF482@inria.fr> References: <989254717.469960.1289484485373.JavaMail.root@zmbs3.inria.fr> <6386A022-456C-472B-85C5-F5D4AD0FF482@inria.fr> Message-ID: <D40CBD8C-815E-4D0D-A31B-2759AC3257BD@oucs.ox.ac.uk> I am perfectly ok with these elements entering the TEI element-bank in theory, but I think it would be a capital mistake to do so without accompanying prose in the Guidelines. We don't have a proposal here as to which modules the new elements would belong, and which chapter they would yet. So I would say the proposal is incomplete at this point. -- Sebastian Rahtz Information and Support Group Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From elena.pierazzo at kcl.ac.uk Sat Nov 13 05:15:13 2010 From: elena.pierazzo at kcl.ac.uk (Elena Pierazzo) Date: Sat, 13 Nov 2010 10:15:13 +0000 Subject: [tei-council] Fwd: [ tei-Feature Requests-3095637 ] New <document> <patch> <line> elements for genetic view In-Reply-To: <D40CBD8C-815E-4D0D-A31B-2759AC3257BD@oucs.ox.ac.uk> References: <989254717.469960.1289484485373.JavaMail.root@zmbs3.inria.fr> <6386A022-456C-472B-85C5-F5D4AD0FF482@inria.fr> <D40CBD8C-815E-4D0D-A31B-2759AC3257BD@oucs.ox.ac.uk> Message-ID: <AF798CA6-B470-47CC-882F-2A675FB0B42B@kcl.ac.uk> The prose is present in the ODD file within sourceForge at http://tei.svn.sourceforge.net/viewvc/tei/trunk/genetic/ (file called geneticTEI.xml) About where to put it, I think we already discussed to put it within the representation of primary source, just after the discussion after facsimile. Elena On 12 Nov 2010, at 14:14, Sebastian Rahtz wrote: > I am perfectly ok with these elements entering the TEI element-bank > in theory, but I think it would > be a capital mistake to do so without accompanying prose in the > Guidelines. We don't > have a proposal here as to which modules the new elements would > belong, and > which chapter they would yet. > > So I would say the proposal is incomplete at this point. > -- > Sebastian Rahtz > Information and Support Group Manager, Oxford University Computing > Services > 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 > > S?lo le pido a Dios > que el futuro no me sea indiferente > > > > > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council -- Dr Elena Pierazzo Research Associate Centre for Computing in the Humanities King's College London 26-29 Drury Lane London WC2B 5RL Phone: 0207-848-1949 Fax: 0207-848-2980 elena.pierazzo at kcl.ac.uk www.kcl.ac.uk From mholmes at uvic.ca Thu Nov 25 11:13:15 2010 From: mholmes at uvic.ca (Martin Holmes) Date: Thu, 25 Nov 2010 08:13:15 -0800 Subject: [tei-council] What happened to the nuncling? Message-ID: <4CEE8B1B.7070509@uvic.ca> Hi folks, Just wondering what happened to the nuncling activity -- are we ready to vote on the recommendations? Cheers, Martin -- Martin Holmes University of Victoria Humanities Computing and Media Centre (mholmes at uvic.ca) From laurent.romary at inria.fr Thu Nov 25 11:19:21 2010 From: laurent.romary at inria.fr (Laurent Romary) Date: Thu, 25 Nov 2010 17:19:21 +0100 Subject: [tei-council] What happened to the nuncling? In-Reply-To: <4CEE8B1B.7070509@uvic.ca> References: <4CEE8B1B.7070509@uvic.ca> Message-ID: <D1794EB3-9438-4D91-84A3-F3C602C674B0@inria.fr> I have seen many things being consensual on the tickets and, I think, some implemented by Lou. Lou, can you provide an update on the unresolved issues? Cheers, Laurent Le 25 nov. 10 ? 17:13, Martin Holmes a ?crit : > Hi folks, > > Just wondering what happened to the nuncling activity -- are we > ready to > vote on the recommendations? > > Cheers, > Martin > -- > Martin Holmes > University of Victoria Humanities Computing and Media Centre > (mholmes at uvic.ca) > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Laurent Romary INRIA & HUB-IDSL laurent.romary at inria.fr From gabriel.bodard at kcl.ac.uk Thu Nov 25 12:06:23 2010 From: gabriel.bodard at kcl.ac.uk (Gabriel Bodard) Date: Thu, 25 Nov 2010 17:06:23 +0000 Subject: [tei-council] What happened to the nuncling? In-Reply-To: <D1794EB3-9438-4D91-84A3-F3C602C674B0@inria.fr> References: <4CEE8B1B.7070509@uvic.ca> <D1794EB3-9438-4D91-84A3-F3C602C674B0@inria.fr> Message-ID: <4CEE978F.6010007@kcl.ac.uk> I know that both of the tickets for which I was a nuncle (plus the one in on which I was sitting) have had some discussion, but are maybe not quite ready for voting. A very small amount of further discussion on all of them would probably make them ready. Did we vote on any of the ones that are already implemented, or were they considered passed through lack of objections? G On 25/11/2010 16:19, Laurent Romary wrote: > I have seen many things being consensual on the tickets and, I think, > some implemented by Lou. > Lou, can you provide an update on the unresolved issues? > Cheers, > Laurent > > Le 25 nov. 10 ? 17:13, Martin Holmes a ?crit : > >> Hi folks, >> >> Just wondering what happened to the nuncling activity -- are we >> ready to >> vote on the recommendations? >> >> Cheers, >> Martin >> -- >> Martin Holmes >> University of Victoria Humanities Computing and Media Centre >> (mholmes at uvic.ca) >> _______________________________________________ >> tei-council mailing list >> tei-council at lists.village.Virginia.EDU >> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > > Laurent Romary > INRIA& HUB-IDSL > laurent.romary at inria.fr > > > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council -- Dr Gabriel BODARD (Epigrapher, Digital Classicist, Pirate) Centre for Computing in the Humanities King's College London 26-29 Drury Lane London WC2B 5RL Email: gabriel.bodard at kcl.ac.uk Tel: +44 (0)20 7848 1388 Fax: +44 (0)20 7848 2980 http://www.digitalclassicist.org/ http://www.currentepigraphy.org/ From laurent.romary at inria.fr Thu Nov 25 12:52:53 2010 From: laurent.romary at inria.fr (Laurent Romary) Date: Thu, 25 Nov 2010 18:52:53 +0100 Subject: [tei-council] What happened to the nuncling? In-Reply-To: <4CEE978F.6010007@kcl.ac.uk> References: <4CEE8B1B.7070509@uvic.ca> <D1794EB3-9438-4D91-84A3-F3C602C674B0@inria.fr> <4CEE978F.6010007@kcl.ac.uk> Message-ID: <4B82E530-62A4-4E2A-BC72-A476304D9AF8@inria.fr> Le 25 nov. 10 ? 18:06, Gabriel Bodard a ?crit : > I know that both of the tickets for which I was a nuncle (plus the one > in on which I was sitting) have had some discussion, but are maybe not > quite ready for voting. A very small amount of further discussion on > all > of them would probably make them ready. Can you reforward these to the council, so that we may get some new insights. > > Did we vote on any of the ones that are already implemented, or were > they considered passed through lack of objections? Those who passed were straightforward. I think Martin refers to a couple of these for which the discussion is left opened. @Martin, maybe we could also ask the council for wisdom there. > > G > > On 25/11/2010 16:19, Laurent Romary wrote: >> I have seen many things being consensual on the tickets and, I think, >> some implemented by Lou. >> Lou, can you provide an update on the unresolved issues? >> Cheers, >> Laurent >> >> Le 25 nov. 10 ? 17:13, Martin Holmes a ?crit : >> >>> Hi folks, >>> >>> Just wondering what happened to the nuncling activity -- are we >>> ready to >>> vote on the recommendations? >>> >>> Cheers, >>> Martin >>> -- >>> Martin Holmes >>> University of Victoria Humanities Computing and Media Centre >>> (mholmes at uvic.ca) >>> _______________________________________________ >>> tei-council mailing list >>> tei-council at lists.village.Virginia.EDU >>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council >> >> Laurent Romary >> INRIA& HUB-IDSL >> laurent.romary at inria.fr >> >> >> >> _______________________________________________ >> tei-council mailing list >> tei-council at lists.village.Virginia.EDU >> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > > -- > Dr Gabriel BODARD > (Epigrapher, Digital Classicist, Pirate) > > Centre for Computing in the Humanities > King's College London > 26-29 Drury Lane > London WC2B 5RL > Email: gabriel.bodard at kcl.ac.uk > Tel: +44 (0)20 7848 1388 > Fax: +44 (0)20 7848 2980 > > http://www.digitalclassicist.org/ > http://www.currentepigraphy.org/ > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Laurent Romary INRIA & HUB-IDSL laurent.romary at inria.fr From mholmes at uvic.ca Thu Nov 25 13:15:41 2010 From: mholmes at uvic.ca (Martin Holmes) Date: Thu, 25 Nov 2010 10:15:41 -0800 Subject: [tei-council] What happened to the nuncling? In-Reply-To: <4B82E530-62A4-4E2A-BC72-A476304D9AF8@inria.fr> References: <4CEE8B1B.7070509@uvic.ca> <D1794EB3-9438-4D91-84A3-F3C602C674B0@inria.fr> <4CEE978F.6010007@kcl.ac.uk> <4B82E530-62A4-4E2A-BC72-A476304D9AF8@inria.fr> Message-ID: <4CEEA7CD.6010808@uvic.ca> Of the four items we looked at: <http://wiki.tei-c.org/index.php/Council_FR_assignments> One is marked "Postponed", which is what we recommended, but the others are still "Open". All have recommendations from us, waiting to be voted on by the rest of the council. Cheers, Martin On 10-11-25 09:52 AM, Laurent Romary wrote: > > Le 25 nov. 10 ? 18:06, Gabriel Bodard a ?crit : > >> I know that both of the tickets for which I was a nuncle (plus the one >> in on which I was sitting) have had some discussion, but are maybe not >> quite ready for voting. A very small amount of further discussion on >> all >> of them would probably make them ready. > > Can you reforward these to the council, so that we may get some new > insights. > >> >> Did we vote on any of the ones that are already implemented, or were >> they considered passed through lack of objections? > > Those who passed were straightforward. I think Martin refers to a > couple of these for which the discussion is left opened. > @Martin, maybe we could also ask the council for wisdom there. > > >> >> G >> >> On 25/11/2010 16:19, Laurent Romary wrote: >>> I have seen many things being consensual on the tickets and, I think, >>> some implemented by Lou. >>> Lou, can you provide an update on the unresolved issues? >>> Cheers, >>> Laurent >>> >>> Le 25 nov. 10 ? 17:13, Martin Holmes a ?crit : >>> >>>> Hi folks, >>>> >>>> Just wondering what happened to the nuncling activity -- are we >>>> ready to >>>> vote on the recommendations? >>>> >>>> Cheers, >>>> Martin >>>> -- >>>> Martin Holmes >>>> University of Victoria Humanities Computing and Media Centre >>>> (mholmes at uvic.ca) >>>> _______________________________________________ >>>> tei-council mailing list >>>> tei-council at lists.village.Virginia.EDU >>>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council >>> >>> Laurent Romary >>> INRIA& HUB-IDSL >>> laurent.romary at inria.fr >>> >>> >>> >>> _______________________________________________ >>> tei-council mailing list >>> tei-council at lists.village.Virginia.EDU >>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council >> >> -- >> Dr Gabriel BODARD >> (Epigrapher, Digital Classicist, Pirate) >> >> Centre for Computing in the Humanities >> King's College London >> 26-29 Drury Lane >> London WC2B 5RL >> Email: gabriel.bodard at kcl.ac.uk >> Tel: +44 (0)20 7848 1388 >> Fax: +44 (0)20 7848 2980 >> >> http://www.digitalclassicist.org/ >> http://www.currentepigraphy.org/ >> _______________________________________________ >> tei-council mailing list >> tei-council at lists.village.Virginia.EDU >> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > > Laurent Romary > INRIA& HUB-IDSL > laurent.romary at inria.fr > > > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > . > -- Martin Holmes University of Victoria Humanities Computing and Media Centre (mholmes at uvic.ca) From laurent.romary at inria.fr Thu Nov 25 13:27:34 2010 From: laurent.romary at inria.fr (Laurent Romary) Date: Thu, 25 Nov 2010 19:27:34 +0100 Subject: [tei-council] What happened to the nuncling? In-Reply-To: <4CEEA7CD.6010808@uvic.ca> References: <4CEE8B1B.7070509@uvic.ca> <D1794EB3-9438-4D91-84A3-F3C602C674B0@inria.fr> <4CEE978F.6010007@kcl.ac.uk> <4B82E530-62A4-4E2A-BC72-A476304D9AF8@inria.fr> <4CEEA7CD.6010808@uvic.ca> Message-ID: <9B7C61CD-6C52-4CDF-9C6A-332CC1506371@inria.fr> OK. The one where there is no agreement with Lou is: 2976715 Maybe others would like to have a look and comment. 2987832 would probably require a further comment from you. and we do have a nice proposal for 2987241 which sounds unproblematic. My rule of thumb is that when there is no contention, the proposal is deemed to be implementable. Le 25 nov. 10 ? 19:15, Martin Holmes a ?crit : > Of the four items we looked at: > > <http://wiki.tei-c.org/index.php/Council_FR_assignments> > > One is marked "Postponed", which is what we recommended, but the > others > are still "Open". All have recommendations from us, waiting to be > voted > on by the rest of the council. > > Cheers, > Martin > > On 10-11-25 09:52 AM, Laurent Romary wrote: >> >> Le 25 nov. 10 ? 18:06, Gabriel Bodard a ?crit : >> >>> I know that both of the tickets for which I was a nuncle (plus the >>> one >>> in on which I was sitting) have had some discussion, but are maybe >>> not >>> quite ready for voting. A very small amount of further discussion on >>> all >>> of them would probably make them ready. >> >> Can you reforward these to the council, so that we may get some new >> insights. >> >>> >>> Did we vote on any of the ones that are already implemented, or were >>> they considered passed through lack of objections? >> >> Those who passed were straightforward. I think Martin refers to a >> couple of these for which the discussion is left opened. >> @Martin, maybe we could also ask the council for wisdom there. >> >> >>> >>> G >>> >>> On 25/11/2010 16:19, Laurent Romary wrote: >>>> I have seen many things being consensual on the tickets and, I >>>> think, >>>> some implemented by Lou. >>>> Lou, can you provide an update on the unresolved issues? >>>> Cheers, >>>> Laurent >>>> >>>> Le 25 nov. 10 ? 17:13, Martin Holmes a ?crit : >>>> >>>>> Hi folks, >>>>> >>>>> Just wondering what happened to the nuncling activity -- are we >>>>> ready to >>>>> vote on the recommendations? >>>>> >>>>> Cheers, >>>>> Martin >>>>> -- >>>>> Martin Holmes >>>>> University of Victoria Humanities Computing and Media Centre >>>>> (mholmes at uvic.ca) >>>>> _______________________________________________ >>>>> tei-council mailing list >>>>> tei-council at lists.village.Virginia.EDU >>>>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council >>>> >>>> Laurent Romary >>>> INRIA& HUB-IDSL >>>> laurent.romary at inria.fr >>>> >>>> >>>> >>>> _______________________________________________ >>>> tei-council mailing list >>>> tei-council at lists.village.Virginia.EDU >>>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council >>> >>> -- >>> Dr Gabriel BODARD >>> (Epigrapher, Digital Classicist, Pirate) >>> >>> Centre for Computing in the Humanities >>> King's College London >>> 26-29 Drury Lane >>> London WC2B 5RL >>> Email: gabriel.bodard at kcl.ac.uk >>> Tel: +44 (0)20 7848 1388 >>> Fax: +44 (0)20 7848 2980 >>> >>> http://www.digitalclassicist.org/ >>> http://www.currentepigraphy.org/ >>> _______________________________________________ >>> tei-council mailing list >>> tei-council at lists.village.Virginia.EDU >>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council >> >> Laurent Romary >> INRIA& HUB-IDSL >> laurent.romary at inria.fr >> >> >> >> _______________________________________________ >> tei-council mailing list >> tei-council at lists.village.Virginia.EDU >> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council >> . >> > > -- > Martin Holmes > University of Victoria Humanities Computing and Media Centre > (mholmes at uvic.ca) > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Laurent Romary INRIA & HUB-IDSL laurent.romary at inria.fr From kevin.s.hawkins at ultraslavonic.info Mon Dec 13 22:08:58 2010 From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins) Date: Mon, 13 Dec 2010 22:08:58 -0500 Subject: [tei-council] update from the TEI Tite task force Message-ID: <4D06DFCA.3050304@ultraslavonic.info> Colleagues, a happy holiday season to you. A brief report on progress by the task force that Laurent charged with aligning the TEI Tite schema maintained by Council (and hosted on tei-c.org) with that in use by Apex CoVantage in the AccessTEI program. Recall that the task force members are: * Perry Trolard (author of Tite and representative of the Mellon-funded project that created Tite) * Greg Spurlock (of Apex CoVantage) * Kevin Hawkins (of the TEI Council) I've copied Perry and Greg on this message for their information, but please remember that they won't receive messages sent only to tei-council and likewise can't post to the list themselves. First some notes on aligning the two versions and then on additional changes to consider making (to both versions). = Aligning the two versions = Before AccessTEI was launched, Apex reviewed Tite 1.0 closely and provided a number of suggestions to Dan O'Donnell (perhaps also directly to others), which were passed along to Laurent and Lou in February 2010. These changes were deemed uncontroversial, so no Council vote was held on them; instead, Apex was allowed to implement them. Perry shared a summary of these with me, and I have entered them into SourceForge for our consideration. If we implement them, we will bring the Council's Tite closer in line with Apex's derived version. 1. removing a bunch of unnecesary elements and attributes: http://sourceforge.net/tracker/?func=detail&aid=3136934&group_id=106328&atid=644062 (includes as a comment one more change discovered by Lou, not by Apex) 2. adding <add> and <del>: http://sourceforge.net/tracker/?func=detail&aid=3136935&group_id=106328&atid=644065 3. Adding @facs to <pb/>: http://sourceforge.net/tracker/?func=detail&aid=3136936&group_id=106328&atid=644065 For (2) and (3), apparently Lou provided some notes in February that provide the basis for changes to the prose to accompany these schema changes. If someone can find these, we will save ourselves time in redoing this work. In addition, Dan mentioned in May that while we met in Dublin, he received the last set of suggestions from Apex. Requests to Dan and Apex to see these have not yielded anything, but I would like to find these and add these items to SourceForge before the Council begins considering the other tickets in SourceForge that I have created dealing with issues I have discovered on my own that are problems with both versions of Tite. If someone can provide these to me, I'll be grateful. Once we get these documents incorporated into SourceForge tickets, we can have a Council vote (or call for objections) and then ask the Oxford editorial team to implement these changes. = Additional changes to make = The other bug reports and feature requests in SourceForge are about things that I detected in both canonical Tite on tei-c.org and in the Apex Tite documentation. While a few people have commented on them, I think we should wrap up all of the issues already identified first in order to make the schema in use by Apex identical (in theory) to the latest version at tei-c.org. *Then* we can discuss ways in which both are deficient. Questions? Comments? Kevin From sebastian.rahtz at oucs.ox.ac.uk Tue Dec 14 05:11:42 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 14 Dec 2010 10:11:42 +0000 Subject: [tei-council] update from the TEI Tite task force In-Reply-To: <4D06DFCA.3050304@ultraslavonic.info> References: <4D06DFCA.3050304@ultraslavonic.info> Message-ID: <B34DD7EC-400E-45F7-8308-5E9F03EE37A7@oucs.ox.ac.uk> On 14 Dec 2010, at 03:08, Kevin Hawkins wrote: > > First some notes on aligning the two versions and then on additional > changes to consider making (to both versions). I am puzzling by a thread running through the message, which seems to imply that we will carry on with two versions. Why are we not targetting one central version which everyone uses? What is the long-term plan for maintenance? -- Sebastian Rahtz Information and Support Group Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From laurent.romary at inria.fr Tue Dec 14 05:16:26 2010 From: laurent.romary at inria.fr (Laurent Romary) Date: Tue, 14 Dec 2010 11:16:26 +0100 Subject: [tei-council] update from the TEI Tite task force In-Reply-To: <B34DD7EC-400E-45F7-8308-5E9F03EE37A7@oucs.ox.ac.uk> References: <4D06DFCA.3050304@ultraslavonic.info> <B34DD7EC-400E-45F7-8308-5E9F03EE37A7@oucs.ox.ac.uk> Message-ID: <FA0E84E2-2396-4E42-A33F-723E934978D9@inria.fr> I guess it's because you're not speaking the same language (US-en vs. UK-en probably ;-), but who am I to judge). The mission letter of the group was clear in this respect (see copy of the mail I sent before the summer to all). Cheers, Laurent -------------- next part -------------- An embedded message was scrubbed... From: Laurent Romary <laurent.romary at inria.fr> Subject: [tei-council] Tite - maintenance scheme Date: Wed, 8 Sep 2010 15:40:19 +0200 Size: 4282 Url: http://lists.village.Virginia.EDU/pipermail/tei-council/attachments/20101214/823104f7/attachment.eml -------------- next part -------------- Le 14 d?c. 10 ? 11:11, Sebastian Rahtz a ?crit : > > On 14 Dec 2010, at 03:08, Kevin Hawkins wrote: >> >> First some notes on aligning the two versions and then on additional >> changes to consider making (to both versions). > > I am puzzling by a thread running through the message, which > seems to imply that we will carry on with two versions. Why > are we not targetting one central version which everyone uses? > > What is the long-term plan for maintenance? > > -- > Sebastian Rahtz > Information and Support Group Manager, Oxford University Computing > Services > 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 > > S?lo le pido a Dios > que el futuro no me sea indiferente > > > > > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Laurent Romary INRIA & HUB-IDSL laurent.romary at inria.fr From sebastian.rahtz at oucs.ox.ac.uk Tue Dec 14 08:24:23 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 14 Dec 2010 13:24:23 +0000 Subject: [tei-council] update from the TEI Tite task force In-Reply-To: <FA0E84E2-2396-4E42-A33F-723E934978D9@inria.fr> References: <4D06DFCA.3050304@ultraslavonic.info> <B34DD7EC-400E-45F7-8308-5E9F03EE37A7@oucs.ox.ac.uk> <FA0E84E2-2396-4E42-A33F-723E934978D9@inria.fr> Message-ID: <64F75208-DE56-4CB2-9CC0-113F486BF81C@oucs.ox.ac.uk> On 14 Dec 2010, at 10:16, Laurent Romary wrote: > I guess it's because you're not speaking the same language I often find that :-} -- Sebastian Rahtz Information and Support Group Manager Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From kevin.s.hawkins at ultraslavonic.info Tue Dec 14 08:46:23 2010 From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins) Date: Tue, 14 Dec 2010 08:46:23 -0500 Subject: [tei-council] update from the TEI Tite task force In-Reply-To: <B34DD7EC-400E-45F7-8308-5E9F03EE37A7@oucs.ox.ac.uk> References: <4D06DFCA.3050304@ultraslavonic.info> <B34DD7EC-400E-45F7-8308-5E9F03EE37A7@oucs.ox.ac.uk> Message-ID: <4D07752F.9090105@ultraslavonic.info> On 12/14/2010 5:11 AM, Sebastian Rahtz wrote: > > On 14 Dec 2010, at 03:08, Kevin Hawkins wrote: >> >> First some notes on aligning the two versions and then on additional >> changes to consider making (to both versions). > > I am puzzling by a thread running through the message, which > seems to imply that we will carry on with two versions. Why > are we not targetting one central version which everyone uses? My statement was misleading. The plan is to converge on a single canonical version of Tite, to be hosted at tei-c.org. However, Apex has always told Dan that they will likely not be able to keep up with our incremental improvements to Tite, instead using a DTD snapshot of the schema and retraining their staff only periodically to use a later version. --Kevin From sebastian.rahtz at oucs.ox.ac.uk Tue Dec 14 08:49:42 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 14 Dec 2010 13:49:42 +0000 Subject: [tei-council] update from the TEI Tite task force In-Reply-To: <4D07752F.9090105@ultraslavonic.info> References: <4D06DFCA.3050304@ultraslavonic.info> <B34DD7EC-400E-45F7-8308-5E9F03EE37A7@oucs.ox.ac.uk> <4D07752F.9090105@ultraslavonic.info> Message-ID: <ED5C012B-757F-4F1A-B313-75B5ABB90E93@oucs.ox.ac.uk> > However, Apex has always told Dan that they will > likely not be able to keep up with our incremental improvements to Tite, > instead using a DTD snapshot of the schema and retraining their staff > only periodically to use a later version. fair enough. and if we use the specific element inclusion, the number of nasty surprises will be less anyway. -- Sebastian Rahtz Information and Support Group Manager Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From sebastian.rahtz at oucs.ox.ac.uk Tue Dec 14 08:50:45 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 14 Dec 2010 13:50:45 +0000 Subject: [tei-council] update from the TEI Tite task force In-Reply-To: <ED5C012B-757F-4F1A-B313-75B5ABB90E93@oucs.ox.ac.uk> References: <4D06DFCA.3050304@ultraslavonic.info> <B34DD7EC-400E-45F7-8308-5E9F03EE37A7@oucs.ox.ac.uk> <4D07752F.9090105@ultraslavonic.info> <ED5C012B-757F-4F1A-B313-75B5ABB90E93@oucs.ox.ac.uk> Message-ID: <E1AA5735-9F9A-4370-AD76-EBA277B9AB01@oucs.ox.ac.uk> > and if we use the specific element inclusion, the number of nasty > surprises will be less anyway. > s/less/fewer/ -- Sebastian Rahtz Information and Support Group Manager Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From sebastian.rahtz at oucs.ox.ac.uk Tue Dec 14 08:57:27 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 14 Dec 2010 13:57:27 +0000 Subject: [tei-council] update from the TEI Tite task force In-Reply-To: <4D077723.9010402@retired.ox.ac.uk> References: <4D06DFCA.3050304@ultraslavonic.info> <B34DD7EC-400E-45F7-8308-5E9F03EE37A7@oucs.ox.ac.uk> <4D07752F.9090105@ultraslavonic.info> <ED5C012B-757F-4F1A-B313-75B5ABB90E93@oucs.ox.ac.uk> <4D077723.9010402@retired.ox.ac.uk> Message-ID: <E67B1D5D-891A-4D4B-B4FF-668B08CB8D16@oucs.ox.ac.uk> > > (b) you need to include the module "tei" to get the basic class > declarations, used in all content models you don't _have_ to, you could include all the <classSpec> individually; but that could get unwieldy perhaps once you've switched to the new method, you feel much cleaner?.. -- Sebastian Rahtz Information and Support Group Manager Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From sebastian.rahtz at oucs.ox.ac.uk Tue Dec 14 08:58:22 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 14 Dec 2010 13:58:22 +0000 Subject: [tei-council] update from the TEI Tite task force In-Reply-To: <4D077774.1030300@retired.ox.ac.uk> References: <4D06DFCA.3050304@ultraslavonic.info> <B34DD7EC-400E-45F7-8308-5E9F03EE37A7@oucs.ox.ac.uk> <4D07752F.9090105@ultraslavonic.info> <ED5C012B-757F-4F1A-B313-75B5ABB90E93@oucs.ox.ac.uk> <E1AA5735-9F9A-4370-AD76-EBA277B9AB01@oucs.ox.ac.uk> <4D077774.1030300@retired.ox.ac.uk> Message-ID: <3CD510FF-D0AE-4E37-BE8E-8875928EC2C5@oucs.ox.ac.uk> On 14 Dec 2010, at 13:56, Lou Burnard wrote: >> > actually i think you were right the first time -- the *number* will be > less, though the surprises will be fewer > aaaaaaaaaaaaaaaaaaargh -- a dead man walking From dsewell at virginia.edu Tue Dec 14 09:56:12 2010 From: dsewell at virginia.edu (David Sewell) Date: Tue, 14 Dec 2010 09:56:12 -0500 (EST) Subject: [tei-council] update from the TEI Tite task force In-Reply-To: <4D06DFCA.3050304@ultraslavonic.info> References: <4D06DFCA.3050304@ultraslavonic.info> Message-ID: <alpine.OSX.2.00.1012140946140.1341@lister.ei.virginia.edu> Council people, I would suggest that before any final decisions are taken on canonical TEI Tite, feedback should be requested from the membership via TEI-L, particularly to solicit input from people who have actually been using TEI Tite for encoding projects (with or without conversion vendors). I'm reasonably sure, for example, that we've asked a conversion vendor to use some of the "unnecessary elements and attributes" mentioned in Sourceforge ticket 3136934 in an encoding based on TEI Tite. As we have in fact already customized Tite for our local practice (this is not a project going via AccessTEI), it might not be a hardship to revise our ODD later to explicitly include anything we need to use. But I think Council/Board need to decide whether (1) TEI Tite is a customization primarily designed to meet the needs of AccessTEI/Apex CoVantage plus anyone else who wants to adopt their precise encoding practice, or (2) TEI Tite is a customization to provide a lingua franca for use between TEI-based projects and conversion vendors, including but not limited to formal AccessTEI work. (Or has that decision already been made and documented somewhere?) David On Mon, 13 Dec 2010, Kevin Hawkins wrote: > Colleagues, a happy holiday season to you. > > A brief report on progress by the task force that Laurent charged with > aligning the TEI Tite schema maintained by Council (and hosted on > tei-c.org) with that in use by Apex CoVantage in the AccessTEI program. > Recall that the task force members are: > > * Perry Trolard (author of Tite and representative of the Mellon-funded > project that created Tite) > * Greg Spurlock (of Apex CoVantage) > * Kevin Hawkins (of the TEI Council) > > I've copied Perry and Greg on this message for their information, but > please remember that they won't receive messages sent only to > tei-council and likewise can't post to the list themselves. > > First some notes on aligning the two versions and then on additional > changes to consider making (to both versions). > > = Aligning the two versions = > > Before AccessTEI was launched, Apex reviewed Tite 1.0 closely and > provided a number of suggestions to Dan O'Donnell (perhaps also directly > to others), which were passed along to Laurent and Lou in February 2010. > These changes were deemed uncontroversial, so no Council vote was held > on them; instead, Apex was allowed to implement them. > > Perry shared a summary of these with me, and I have entered them into > SourceForge for our consideration. If we implement them, we will bring > the Council's Tite closer in line with Apex's derived version. > > 1. removing a bunch of unnecesary elements and attributes: > > http://sourceforge.net/tracker/?func=detail&aid=3136934&group_id=106328&atid=644062 > > (includes as a comment one more change discovered by Lou, not by Apex) > > 2. adding <add> and <del>: > > http://sourceforge.net/tracker/?func=detail&aid=3136935&group_id=106328&atid=644065 > > 3. Adding @facs to <pb/>: > > http://sourceforge.net/tracker/?func=detail&aid=3136936&group_id=106328&atid=644065 > > For (2) and (3), apparently Lou provided some notes in February that > provide the basis for changes to the prose to accompany these schema > changes. If someone can find these, we will save ourselves time in > redoing this work. > > In addition, Dan mentioned in May that while we met in Dublin, he > received the last set of suggestions from Apex. Requests to Dan and > Apex to see these have not yielded anything, but I would like to find > these and add these items to SourceForge before the Council begins > considering the other tickets in SourceForge that I have created dealing > with issues I have discovered on my own that are problems with both > versions of Tite. If someone can provide these to me, I'll be grateful. > > Once we get these documents incorporated into SourceForge tickets, we > can have a Council vote (or call for objections) and then ask the Oxford > editorial team to implement these changes. > > = Additional changes to make = > > The other bug reports and feature requests in SourceForge are about > things that I detected in both canonical Tite on tei-c.org and in the > Apex Tite documentation. While a few people have commented on them, I > think we should wrap up all of the issues already identified first in > order to make the schema in use by Apex identical (in theory) to the > latest version at tei-c.org. *Then* we can discuss ways in which both > are deficient. > > Questions? Comments? > > Kevin > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > -- David Sewell, Editorial and Technical Manager ROTUNDA, The University of Virginia Press PO Box 400314, Charlottesville, VA 22904-4314 USA Email: dsewell at virginia.edu Tel: +1 434 924 9973 Web: http://rotunda.upress.virginia.edu/ From laurent.romary at inria.fr Tue Dec 14 10:04:49 2010 From: laurent.romary at inria.fr (Laurent Romary) Date: Tue, 14 Dec 2010 16:04:49 +0100 Subject: [tei-council] update from the TEI Tite task force In-Reply-To: <alpine.OSX.2.00.1012140946140.1341@lister.ei.virginia.edu> References: <4D06DFCA.3050304@ultraslavonic.info> <alpine.OSX.2.00.1012140946140.1341@lister.ei.virginia.edu> Message-ID: <0F69132B-DDBA-4623-9DB2-08414353199D@inria.fr> I agree that we need to be cautious with the changes we implement on Tite at TEI (as I named it in early mail exchanges before the summer). The sourceforge ticket is in particular there for people to react on things which we may drop and which, beyond the idiosyncrasies of specific projects, would be worth keeping. On your last point, we are combining 1) and 2), in the sense that Tite at TEI is intended to be a reference customization for interactions between TEI-based projects and conversion vendors, but also, since Access-TEI is a major initiative for the consortium, we want to make sure that the schema we maintain is straightforwardly useful for this program. @Kevin: would you want top ask the TEI-L for feedback on some of the tickets? Laurent Le 14 d?c. 10 ? 15:56, David Sewell a ?crit : > Council people, > > I would suggest that before any final decisions are taken on canonical > TEI Tite, feedback should be requested from the membership via TEI-L, > particularly to solicit input from people who have actually been using > TEI Tite for encoding projects (with or without conversion vendors). > > I'm reasonably sure, for example, that we've asked a conversion vendor > to use some of the "unnecessary elements and attributes" mentioned in > Sourceforge ticket 3136934 in an encoding based on TEI Tite. As we > have > in fact already customized Tite for our local practice (this is not a > project going via AccessTEI), it might not be a hardship to revise our > ODD later to explicitly include anything we need to use. > > But I think Council/Board need to decide whether (1) TEI Tite is a > customization primarily designed to meet the needs of AccessTEI/Apex > CoVantage plus anyone else who wants to adopt their precise encoding > practice, or (2) TEI Tite is a customization to provide a lingua > franca > for use between TEI-based projects and conversion vendors, including > but > not limited to formal AccessTEI work. (Or has that decision already > been > made and documented somewhere?) > > David > > On Mon, 13 Dec 2010, Kevin Hawkins wrote: > >> Colleagues, a happy holiday season to you. >> >> A brief report on progress by the task force that Laurent charged >> with >> aligning the TEI Tite schema maintained by Council (and hosted on >> tei-c.org) with that in use by Apex CoVantage in the AccessTEI >> program. >> Recall that the task force members are: >> >> * Perry Trolard (author of Tite and representative of the Mellon- >> funded >> project that created Tite) >> * Greg Spurlock (of Apex CoVantage) >> * Kevin Hawkins (of the TEI Council) >> >> I've copied Perry and Greg on this message for their information, but >> please remember that they won't receive messages sent only to >> tei-council and likewise can't post to the list themselves. >> >> First some notes on aligning the two versions and then on additional >> changes to consider making (to both versions). >> >> = Aligning the two versions = >> >> Before AccessTEI was launched, Apex reviewed Tite 1.0 closely and >> provided a number of suggestions to Dan O'Donnell (perhaps also >> directly >> to others), which were passed along to Laurent and Lou in February >> 2010. >> These changes were deemed uncontroversial, so no Council vote was >> held >> on them; instead, Apex was allowed to implement them. >> >> Perry shared a summary of these with me, and I have entered them into >> SourceForge for our consideration. If we implement them, we will >> bring >> the Council's Tite closer in line with Apex's derived version. >> >> 1. removing a bunch of unnecesary elements and attributes: >> >> http://sourceforge.net/tracker/?func=detail&aid=3136934&group_id=106328&atid=644062 >> >> (includes as a comment one more change discovered by Lou, not by >> Apex) >> >> 2. adding <add> and <del>: >> >> http://sourceforge.net/tracker/?func=detail&aid=3136935&group_id=106328&atid=644065 >> >> 3. Adding @facs to <pb/>: >> >> http://sourceforge.net/tracker/?func=detail&aid=3136936&group_id=106328&atid=644065 >> >> For (2) and (3), apparently Lou provided some notes in February that >> provide the basis for changes to the prose to accompany these schema >> changes. If someone can find these, we will save ourselves time in >> redoing this work. >> >> In addition, Dan mentioned in May that while we met in Dublin, he >> received the last set of suggestions from Apex. Requests to Dan and >> Apex to see these have not yielded anything, but I would like to find >> these and add these items to SourceForge before the Council begins >> considering the other tickets in SourceForge that I have created >> dealing >> with issues I have discovered on my own that are problems with both >> versions of Tite. If someone can provide these to me, I'll be >> grateful. >> >> Once we get these documents incorporated into SourceForge tickets, we >> can have a Council vote (or call for objections) and then ask the >> Oxford >> editorial team to implement these changes. >> >> = Additional changes to make = >> >> The other bug reports and feature requests in SourceForge are about >> things that I detected in both canonical Tite on tei-c.org and in the >> Apex Tite documentation. While a few people have commented on >> them, I >> think we should wrap up all of the issues already identified first in >> order to make the schema in use by Apex identical (in theory) to the >> latest version at tei-c.org. *Then* we can discuss ways in which >> both >> are deficient. >> >> Questions? Comments? >> >> Kevin >> _______________________________________________ >> tei-council mailing list >> tei-council at lists.village.Virginia.EDU >> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council >> > > -- > David Sewell, Editorial and Technical Manager > ROTUNDA, The University of Virginia Press > PO Box 400314, Charlottesville, VA 22904-4314 USA > Email: dsewell at virginia.edu Tel: +1 434 924 9973 > Web: http://rotunda.upress.virginia.edu/ > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Laurent Romary INRIA & HUB-IDSL laurent.romary at inria.fr From kevin.s.hawkins at ultraslavonic.info Tue Dec 14 17:52:44 2010 From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins) Date: Tue, 14 Dec 2010 17:52:44 -0500 Subject: [tei-council] draft message to TEI-L on removing elements and attribute from Tite (was Re: update from the TEI Tite task force) In-Reply-To: <0F69132B-DDBA-4623-9DB2-08414353199D@inria.fr> References: <4D06DFCA.3050304@ultraslavonic.info> <alpine.OSX.2.00.1012140946140.1341@lister.ei.virginia.edu> <0F69132B-DDBA-4623-9DB2-08414353199D@inria.fr> Message-ID: <4D07F53C.9040401@ultraslavonic.info> On 12/14/2010 10:04 AM, Laurent Romary wrote: > @Kevin: would you want top ask the TEI-L for feedback on some of the > tickets? Before I sent to TEI-L, please make sure I've got the message correct. ### Colleagues, A working group commissioned by the TEI Council is proposing revisions to the TEI Tite specification in order to reconcile the derived version used by Apex CoVantage as part of the AccessTEI program and the canonical version on the TEI-C website. We are also investigating bugs and feature requests detected by users (so far, just me) which are being collected in SourceForge so that these can be considered by Council as well. This work involves going through some notes on Tite provided to us by Apex as they established AccessTEI, as well as some notes on oversights detected by Perry Trolard and Lou Burnard since version 1.0 of Tite was published on the TEI-C website. There are a number of elements and attributes not referenced in the prose documentation which were accidentally included in the TEI Tite schema. Since we believe none of these are used by AccessTEI, we are considering removing them from the canonical Tite schema. However, it has been pointed out that doing so risks breaking backwards compatibility for anyone using Tite (or a derived schema) outside of AccessTEI. *If you use Tite outside of AccessTEI*, please check over the list of elements and attributes at: http://sourceforge.net/tracker/?func=detail&aid=3136934&group_id=106328&atid=644062 and comment on the ticket if you use any of these. This will help Council determine which elements and attributes to "save from the chopping block". Context is most helpful: does a vendor uses these elements or attributes when encoding for you? Do you use Tite as the basis for an in-house schema of some sort? Do you have another situation not described by one of these two scenarios? Thank you in advance, Kevin From laurent.romary at inria.fr Wed Dec 15 01:38:14 2010 From: laurent.romary at inria.fr (Laurent Romary) Date: Wed, 15 Dec 2010 07:38:14 +0100 Subject: [tei-council] draft message to TEI-L on removing elements and attribute from Tite (was Re: update from the TEI Tite task force) In-Reply-To: <4D07F53C.9040401@ultraslavonic.info> References: <4D06DFCA.3050304@ultraslavonic.info> <alpine.OSX.2.00.1012140946140.1341@lister.ei.virginia.edu> <0F69132B-DDBA-4623-9DB2-08414353199D@inria.fr> <4D07F53C.9040401@ultraslavonic.info> Message-ID: <B4EF561A-63B0-4D46-A52E-24516937BB41@inria.fr> Thanks a lot Kevin. Your wording may also provide us with the opportunity of getting a picture on who is actually using Tite. Wait until the end of the day (your time) to let council members react and if none shouts loud, you can issue the message. Laurent Le 14 d?c. 10 ? 23:52, Kevin Hawkins a ?crit : > On 12/14/2010 10:04 AM, Laurent Romary wrote: >> @Kevin: would you want top ask the TEI-L for feedback on some of the >> tickets? > > Before I sent to TEI-L, please make sure I've got the message correct. > > ### > > Colleagues, > > A working group commissioned by the TEI Council is proposing revisions > to the TEI Tite specification in order to reconcile the derived > version > used by Apex CoVantage as part of the AccessTEI program and the > canonical version on the TEI-C website. We are also investigating > bugs > and feature requests detected by users (so far, just me) which are > being > collected in SourceForge so that these can be considered by Council > as well. > > This work involves going through some notes on Tite provided to us by > Apex as they established AccessTEI, as well as some notes on > oversights > detected by Perry Trolard and Lou Burnard since version 1.0 of Tite > was > published on the TEI-C website. > > There are a number of elements and attributes not referenced in the > prose documentation which were accidentally included in the TEI Tite > schema. Since we believe none of these are used by AccessTEI, we are > considering removing them from the canonical Tite schema. However, it > has been pointed out that doing so risks breaking backwards > compatibility for anyone using Tite (or a derived schema) outside of > AccessTEI. > > *If you use Tite outside of AccessTEI*, please check over the list of > elements and attributes at: > > http://sourceforge.net/tracker/?func=detail&aid=3136934&group_id=106328&atid=644062 > > and comment on the ticket if you use any of these. This will help > Council determine which elements and attributes to "save from the > chopping block". Context is most helpful: does a vendor uses these > elements or attributes when encoding for you? Do you use Tite as the > basis for an in-house schema of some sort? Do you have another > situation not described by one of these two scenarios? > > Thank you in advance, > > Kevin > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Laurent Romary INRIA & HUB-IDSL laurent.romary at inria.fr From lou.burnard at retired.ox.ac.uk Wed Dec 15 06:32:33 2010 From: lou.burnard at retired.ox.ac.uk (Lou Burnard) Date: Wed, 15 Dec 2010 11:32:33 +0000 Subject: [tei-council] editorial services Message-ID: <4D08A751.1030900@retired.ox.ac.uk> Dear Council As you all probably know, I retired from OUCS at the end of October, and cannot therefore directly contribute to the "editorial services" which Oxford has hitherto been supplying to the TEI via me, Sebastian, and James, as part of its role as a TEI Host. By coincidence, at more or less the same time, it was decided at Board level to issue a new call for TEI Hosts, which gave us the opportunity to rethink the situation. We don't yet know who will be TEI "partners" (the new name for "TEI Host") nor what services they will be willing to offer. But it seems like a good time to make a clear statement about what services are essential to the continued development of the TEI. This note is to ask the Council's help in deciding the best way forward for the continued maintenance and development of the Guidelines. It's not to identify who should do what; rather we need to identify the costs associated with our current activity, and the most cost-effective way of going forward with the TEI's work. The ideas presented here have been discussed briefly amongst myself, Laurent, Sebastian, and James but they're by no means complete or decisive, so anything is up for discussion and your input is highly valued. Once we have a consensus as to the best way forward, Laurent will take this to the Board. 1. What are the "editorial services"? We start by distinguishing: * Release engineering (producing and distributing new releases from the SVN repository) * Source updates (any kind of update to the SVN repository, ranging from minor modifications to existing specifications or prose to the addition of entirely new specifications or sections in the Guidelines) * Software maintenance (bug fixing and maintaining the existing TEI software environment -- stylesheets, Roma, etc. -- to continue to be able to produce new releases as operating systems etc develop) 2. What is needed for a Release? The pattern that seems to have emerged over the last few years allows us to do three releases a year, usually in October, February, and June. Originally one of these (in October) was a "provisional" one for the members' meeting. However many of them there are, and whenever they happen, over the last two years a full release has usually required something like 50 to 60 days effort: * 5 days contributed by the editorial team in testing, validation, packaging, distribution * 15 days contributed by the editorial team in monitoring, implementing, and testing feature requests and bug reports; making textual and schema mods approved by Council * 25-35 days contributed by council members reviewing, discussing, deciding on issues, currently partly by email, partly at face to face or telephone meetings. * 5 days coordination provided by council chair The "release engineering" is now more or less automated, if fiddly. It could be improved by investing effort in a more modern set of tools to facilitate better working within a "continuous integration" paradigm. The other parts cannot readily be further automated as long as we maintain our current working practice. To move to a proper CI environment would require (I think) quite a bit more development of our current test suite, which at present is at best sketchy in its enforcement of those areas of TEI conformance which are vaguely hinted at or informally stated in the Guidelines but not enforced e.g. as schematron rules. And defining such rules would certainly imply a significant amount of user consultation and discussion. 3. What is needed for Software maintenance? Sebastian has estimated that he spends about three days a year maintaining the Roma tools and Stylesheet test suite in their current state; these are currently essential to the whole process of generating and testing new versions. This aspect (software maintenance) should be distinguished from development of new complementary TEI applications, of course. There is an outstanding need to provide additional ODD processing tools, if only to meet the common W3C requirement for dual implementation. This should be organised as a distinct project, however. 4. How cost-effective is this method? If we cost in Council members' time, as we have above, the cost of a release organised in this way is high -- 50 to 60 days FTE. In practice, it is difficult to estimate the cost: some Council members contribute disproportionately more time than others, depending on their other committments and the nature of their jobs. Our experience is that telephone conferences are a good way of confirming decisions and monitoring progress, but they are not as effective as face to face meetings for issues which require prolonged discussion or reflection. Moreover, it is unreasonable to expect busy people to contribute significant levels of effort without some kind of focus or motivation for that effort, such as participation in a specific meeting. Council meetings are currently only held once a year, and they are not therefore directly linked to the release cycle, which is faster. The travel costs associated with a ftf meeting should be regarded in the context of the cost of the effort provided by meeting participants (which is not charged for): although it may cost 20k to bring ten people together for a two day meeting, the resulting 20 person-days of productive work do not cost the TEI anything more. 5. How should we proceed? We should formalise and cost the procedure of making a new release. Here is a (rough) proposal for such a procedure, based on the assumption that we want to retain more or less our current working practices: a. Triage of support tickets - Green tickets: it's clear what needs doing; and an implementation is proposed on the ticket, which will normally be implemented after 5 days, unless a majority of Council members veto it before the deadline. - Amber tickets: it's clear what needs doing, but the implementation needs extra input (e.g. more examples, more text). Implementation is held for 20 days, pending receipt of the additional material, after which the ticket becomes green. - Red tickets: it's not clear what needs doing. Within 15 days, the task is allocated to a subgroup of Council to debate and formulate possible resolution. b. Review of externally-developed proposals (e.g. from SIGs) - A Council subgroup should normally "nuncle" such proposals, transforming them into groups of related tickets if possible c. Timetable - A ftf meeting should be held to finalise each release, 15 days before the release itself. - A triage of outstanding tickets should be made 40 days before each release. 6. How many releases can we do each year? We currently do three. If the frequency is too low, there is a risk that we will not be able to process all the proposals that accumulate in the course of a year; if too high, there is a risk that we will not have enough proposals to warrant the effort of a release. We propose two, one in the spring, and one in the autumn before the Members Annual Meeting (but not in conjunction with it). 7. How should this work be resourced? Council members may need to justify to their employers the work time they devote to the TEI. In some cases, no justification is needed, because such work is regarded as in the employing institution's interest, as contributing to the individual's career development etc.; in other cases the amount of such work needs to be carefully specified (as we have tried to do here) so that a good case can be made. However, it seems reasonable to hope that people do not stand for election to Council without expecting to have to commit some effort, either on behalf of their employer or in their own right. As we've argued above, we need to make the best use we can of such time as they can commit. There remains a residue of 25 days FTE (about half or a third of the total) for each release which is arguably a different kind of work, requiring specialist knowledge of the existing system and arguably also benefitting from continuity. It is essential that it should be the Council as a whole which decides how the TEI should develop and change and which makes the technical decisions about how each change should be implemented (or not). So far, the model has been for the Council to delegate responsibility for actual implementation to a centralised agency, providing "editorial services". As mentioned above, these services have till now been provided by Oxford, partly as a host contribution, and partly paid for by the TEI. If Oxford decides to tender as a "TEI Partner", it may wish to continue to contribute some part of that effort, or it might prefer to contribute to the TEI in some other way, for example by further software development, but that is not for me to say. The Council Chair has the responsibility of deciding where these services are to be obtained -- they might be provided by existing Council members, by TEI partners, or by private contractor -- and of doing so in the most cost-effective and practical manner, so I won't pronounce on that either. I will however say that I would like to go on contributing to the development of the TEI provided that an appropriate means of doing so can be found. Lou p.s. In case you were wondering, there's no immediate probability of my withdrawing from TEI activities entirely! I have just signed a contract with the French ADONIS project to assist in the development of an active TEI community in France. But that's another story. From lou.burnard at retired.ox.ac.uk Wed Dec 15 06:33:46 2010 From: lou.burnard at retired.ox.ac.uk (Lou Burnard) Date: Wed, 15 Dec 2010 11:33:46 +0000 Subject: [tei-council] Fwd: Re: update from the TEI Tite task force Message-ID: <4D08A79A.2080507@retired.ox.ac.uk> [ delayed by my change of identity... ] -------- Original Message -------- Subject: Re: [tei-council] update from the TEI Tite task force Date: Tue, 14 Dec 2010 13:54:43 +0000 From: Lou Burnard <lou.burnard at retired.ox.ac.uk> To: Sebastian Rahtz <sebastian.rahtz at oucs.ox.ac.uk> CC: Kevin Hawkins <kevin.s.hawkins at ultraslavonic.info>, "tei-council at lists.village.virginia.edu" <tei-council at lists.village.virginia.edu>, "gsuprock at apexcovantage.com" <gsuprock at apexcovantage.com>, "ptrolard at artsci.wustl.edu" <ptrolard at artsci.wustl.edu> Sebastian Rahtz wrote: >> However, Apex has always told Dan that they will >> likely not be able to keep up with our incremental improvements to Tite, >> instead using a DTD snapshot of the schema and retraining their staff >> only periodically to use a later version. >> > > > > fair enough. > > and if we use the specific element inclusion, the number of nasty > surprises will be less anyway. > -- > exactly! cf my comment on the SF ticket. There are incidentally two ways of doing this: you could say <moduleRef key="core" include="all the elements we want from core"/> or just <elementRef key="all"/> <elementRef key="the"/> <elementRef key="elements"/> etc. I like the second myself, because it's easier and clearer to maintain but Sebastian points out that (a) it's not currently supported by the Roma web application (tho the stylesheets do support it) (b) you need to include the module "tei" to get the basic class declarations, used in all content models (c) if you want to include any class declarations specific to a particular module, you need to include a <classRef> for it (or include the module) From James.Cummings at oucs.ox.ac.uk Wed Dec 15 06:46:13 2010 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Wed, 15 Dec 2010 11:46:13 +0000 Subject: [tei-council] editorial services In-Reply-To: <4D08A751.1030900@retired.ox.ac.uk> References: <4D08A751.1030900@retired.ox.ac.uk> Message-ID: <4D08AA85.5060009@oucs.ox.ac.uk> Should we expand this list to include all those things done by other hosts? -James On 15/12/10 11:32, Lou Burnard wrote: > Dear Council > > As you all probably know, I retired from OUCS at the end of October, and > cannot therefore directly contribute to the "editorial services" which > Oxford has hitherto been supplying to the TEI via me, Sebastian, and > James, as part of its role as a TEI Host. By coincidence, at more or > less the same time, it was decided at Board level to issue a new call > for TEI Hosts, which gave us the opportunity to rethink the situation. > We don't yet know who will be TEI "partners" (the new name for "TEI > Host") nor what services they will be willing to offer. But it seems > like a good time to make a clear statement about what services are > essential to the continued development of the TEI. > > This note is to ask the Council's help in deciding the best way forward > for the continued maintenance and development of the Guidelines. It's > not to identify who should do what; rather we need to identify the costs > associated with our current activity, and the most cost-effective way of > going forward with the TEI's work. The ideas presented here have been > discussed briefly amongst myself, Laurent, Sebastian, and James but > they're by no means complete or decisive, so anything is up for > discussion and your input is highly valued. Once we have a consensus as > to the best way forward, Laurent will take this to the Board. > > 1. What are the "editorial services"? > > We start by distinguishing: > > * Release engineering (producing and distributing new releases from the > SVN repository) > * Source updates (any kind of update to the SVN repository, ranging from > minor modifications to existing specifications or prose to the addition > of entirely new specifications or sections in the Guidelines) > * Software maintenance (bug fixing and maintaining the existing TEI > software environment -- stylesheets, Roma, etc. -- to continue to be > able to produce new releases as operating systems etc develop) > > 2. What is needed for a Release? > > The pattern that seems to have emerged over the last few years allows us > to do three releases a year, usually in October, February, and June. > Originally one of these (in October) was a "provisional" one for the > members' meeting. However many of them there are, and whenever they > happen, over the last two years a full release has usually required > something like 50 to 60 days effort: > > * 5 days contributed by the editorial team in testing, validation, > packaging, distribution > * 15 days contributed by the editorial team in monitoring, implementing, > and testing feature requests and bug reports; making textual and schema > mods approved by Council > * 25-35 days contributed by council members reviewing, discussing, > deciding on issues, currently partly by email, partly at face to face or > telephone meetings. > * 5 days coordination provided by council chair > > The "release engineering" is now more or less automated, if fiddly. It > could be improved by investing effort in a more modern set of tools to > facilitate better working within a "continuous integration" paradigm. > The other parts cannot readily be further automated as long as we > maintain our current working practice. To move to a proper CI > environment would require (I think) quite a bit more development of our > current test suite, which at present is at best sketchy in its > enforcement of those areas of TEI conformance which are vaguely hinted > at or informally stated in the Guidelines but not enforced e.g. as > schematron rules. And defining such rules would certainly imply a > significant amount of user consultation and discussion. > > 3. What is needed for Software maintenance? > > Sebastian has estimated that he spends about three days a year > maintaining the Roma tools and Stylesheet test suite in their current > state; these are currently essential to the whole process of generating > and testing new versions. This aspect (software maintenance) should be > distinguished from development of new complementary TEI applications, of > course. > > There is an outstanding need to provide additional ODD processing tools, > if only to meet the common W3C requirement for dual implementation. This > should be organised as a distinct project, however. > > > 4. How cost-effective is this method? > > If we cost in Council members' time, as we have above, the cost of a > release organised in this way is high -- 50 to 60 days FTE. In practice, > it is difficult to estimate the cost: some Council members contribute > disproportionately more time than others, depending on their other > committments and the nature of their jobs. > > Our experience is that telephone conferences are a good way of > confirming decisions and monitoring progress, but they are not as > effective as face to face meetings for issues which require prolonged > discussion or reflection. Moreover, it is unreasonable to expect busy > people to contribute significant levels of effort without some kind of > focus or motivation for that effort, such as participation in a specific > meeting. > > Council meetings are currently only held once a year, and they are not > therefore directly linked to the release cycle, which is faster. The > travel costs associated with a ftf meeting should be regarded in the > context of the cost of the effort provided by meeting participants > (which is not charged for): although it may cost 20k to bring ten people > together for a two day meeting, the resulting 20 person-days of > productive work do not cost the TEI anything more. > > 5. How should we proceed? > > We should formalise and cost the procedure of making a new release. Here > is a (rough) proposal for such a procedure, based on the assumption that > we want to retain more or less our current working practices: > > a. Triage of support tickets > - Green tickets: it's clear what needs doing; and an implementation > is proposed on the ticket, which will normally be implemented after 5 > days, unless a majority of Council members veto it before the deadline. > - Amber tickets: it's clear what needs doing, but the implementation > needs extra input (e.g. more examples, more text). Implementation is > held for 20 days, pending receipt of the additional material, after > which the ticket becomes green. > - Red tickets: it's not clear what needs doing. Within 15 days, the > task is allocated to a subgroup of Council to debate and formulate > possible resolution. > > b. Review of externally-developed proposals (e.g. from SIGs) > - A Council subgroup should normally "nuncle" such proposals, > transforming them into groups of related tickets if possible > > c. Timetable > > - A ftf meeting should be held to finalise each release, 15 days before > the release itself. > - A triage of outstanding tickets should be made 40 days before each > release. > > 6. How many releases can we do each year? > > We currently do three. If the frequency is too low, there is a risk that > we will not be able to process all the proposals that accumulate in the > course of a year; if too high, there is a risk that we will not have > enough proposals to warrant the effort of a release. We propose two, one > in the spring, and one in the autumn before the Members Annual Meeting > (but not in conjunction with it). > > 7. How should this work be resourced? > > Council members may need to justify to their employers the work time > they devote to the TEI. In some cases, no justification is needed, > because such work is regarded as in the employing institution's > interest, as contributing to the individual's career development etc.; > in other cases the amount of such work needs to be carefully specified > (as we have tried to do here) so that a good case can be made. However, > it seems reasonable to hope that people do not stand for election to > Council without expecting to have to commit some effort, either on > behalf of their employer or in their own right. As we've argued above, > we need to make the best use we can of such time as they can commit. > > There remains a residue of 25 days FTE (about half or a third of the > total) for each release which is arguably a different kind of work, > requiring specialist knowledge of the existing system and arguably also > benefitting from continuity. It is essential that it should be the > Council as a whole which decides how the TEI should develop and change > and which makes the technical decisions about how each change should be > implemented (or not). > > So far, the model has been for the Council to delegate responsibility > for actual implementation to a centralised agency, providing "editorial > services". As mentioned above, these services have till now been > provided by Oxford, partly as a host contribution, and partly paid for > by the TEI. If Oxford decides to tender as a "TEI Partner", it may wish > to continue to contribute some part of that effort, or it might prefer > to contribute to the TEI in some other way, for example by further > software development, but that is not for me to say. > > The Council Chair has the responsibility of deciding where > these services are to be obtained -- they might be provided by existing > Council members, by TEI partners, or by private contractor -- and of > doing so in the most cost-effective and practical manner, so I won't > pronounce on that either. I will however say that I would like to go on > contributing to the development of the TEI provided that an appropriate > means of doing so can be found. > > > Lou > > p.s. In case you were wondering, there's no immediate probability of my > withdrawing from TEI activities entirely! I have just signed a contract > with the French ADONIS project to assist in the development of an active > TEI community in France. But that's another story. > > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council -- Dr James Cummings, Research Technologies Service OUCS, University of Oxford From laurent.romary at inria.fr Wed Dec 15 07:28:22 2010 From: laurent.romary at inria.fr (Laurent Romary) Date: Wed, 15 Dec 2010 13:28:22 +0100 Subject: [tei-council] editorial services In-Reply-To: <4D08AA85.5060009@oucs.ox.ac.uk> References: <4D08A751.1030900@retired.ox.ac.uk> <4D08AA85.5060009@oucs.ox.ac.uk> Message-ID: <800EF3BA-B670-40DF-B853-575C42593A92@inria.fr> Hi James, Not sure I understand the question here, but we are discussing here what impacts on the maintenance of the guidelines and the council work. What did you have in mind? Laurent Le 15 d?c. 10 ? 12:46, James Cummings a ?crit : > > Should we expand this list to include all those things done by > other hosts? > > -James > > On 15/12/10 11:32, Lou Burnard wrote: >> Dear Council >> >> As you all probably know, I retired from OUCS at the end of >> October, and >> cannot therefore directly contribute to the "editorial services" >> which >> Oxford has hitherto been supplying to the TEI via me, Sebastian, and >> James, as part of its role as a TEI Host. By coincidence, at more or >> less the same time, it was decided at Board level to issue a new call >> for TEI Hosts, which gave us the opportunity to rethink the >> situation. >> We don't yet know who will be TEI "partners" (the new name for "TEI >> Host") nor what services they will be willing to offer. But it seems >> like a good time to make a clear statement about what services are >> essential to the continued development of the TEI. >> >> This note is to ask the Council's help in deciding the best way >> forward >> for the continued maintenance and development of the Guidelines. It's >> not to identify who should do what; rather we need to identify the >> costs >> associated with our current activity, and the most cost-effective >> way of >> going forward with the TEI's work. The ideas presented here have been >> discussed briefly amongst myself, Laurent, Sebastian, and James but >> they're by no means complete or decisive, so anything is up for >> discussion and your input is highly valued. Once we have a >> consensus as >> to the best way forward, Laurent will take this to the Board. >> >> 1. What are the "editorial services"? >> >> We start by distinguishing: >> >> * Release engineering (producing and distributing new releases from >> the >> SVN repository) >> * Source updates (any kind of update to the SVN repository, ranging >> from >> minor modifications to existing specifications or prose to the >> addition >> of entirely new specifications or sections in the Guidelines) >> * Software maintenance (bug fixing and maintaining the existing TEI >> software environment -- stylesheets, Roma, etc. -- to continue to be >> able to produce new releases as operating systems etc develop) >> >> 2. What is needed for a Release? >> >> The pattern that seems to have emerged over the last few years >> allows us >> to do three releases a year, usually in October, February, and June. >> Originally one of these (in October) was a "provisional" one for the >> members' meeting. However many of them there are, and whenever they >> happen, over the last two years a full release has usually required >> something like 50 to 60 days effort: >> >> * 5 days contributed by the editorial team in testing, validation, >> packaging, distribution >> * 15 days contributed by the editorial team in monitoring, >> implementing, >> and testing feature requests and bug reports; making textual and >> schema >> mods approved by Council >> * 25-35 days contributed by council members reviewing, discussing, >> deciding on issues, currently partly by email, partly at face to >> face or >> telephone meetings. >> * 5 days coordination provided by council chair >> >> The "release engineering" is now more or less automated, if fiddly. >> It >> could be improved by investing effort in a more modern set of tools >> to >> facilitate better working within a "continuous integration" paradigm. >> The other parts cannot readily be further automated as long as we >> maintain our current working practice. To move to a proper CI >> environment would require (I think) quite a bit more development of >> our >> current test suite, which at present is at best sketchy in its >> enforcement of those areas of TEI conformance which are vaguely >> hinted >> at or informally stated in the Guidelines but not enforced e.g. as >> schematron rules. And defining such rules would certainly imply a >> significant amount of user consultation and discussion. >> >> 3. What is needed for Software maintenance? >> >> Sebastian has estimated that he spends about three days a year >> maintaining the Roma tools and Stylesheet test suite in their current >> state; these are currently essential to the whole process of >> generating >> and testing new versions. This aspect (software maintenance) should >> be >> distinguished from development of new complementary TEI >> applications, of >> course. >> >> There is an outstanding need to provide additional ODD processing >> tools, >> if only to meet the common W3C requirement for dual implementation. >> This >> should be organised as a distinct project, however. >> >> >> 4. How cost-effective is this method? >> >> If we cost in Council members' time, as we have above, the cost of a >> release organised in this way is high -- 50 to 60 days FTE. In >> practice, >> it is difficult to estimate the cost: some Council members contribute >> disproportionately more time than others, depending on their other >> committments and the nature of their jobs. >> >> Our experience is that telephone conferences are a good way of >> confirming decisions and monitoring progress, but they are not as >> effective as face to face meetings for issues which require prolonged >> discussion or reflection. Moreover, it is unreasonable to expect busy >> people to contribute significant levels of effort without some kind >> of >> focus or motivation for that effort, such as participation in a >> specific >> meeting. >> >> Council meetings are currently only held once a year, and they are >> not >> therefore directly linked to the release cycle, which is faster. The >> travel costs associated with a ftf meeting should be regarded in the >> context of the cost of the effort provided by meeting participants >> (which is not charged for): although it may cost 20k to bring ten >> people >> together for a two day meeting, the resulting 20 person-days of >> productive work do not cost the TEI anything more. >> >> 5. How should we proceed? >> >> We should formalise and cost the procedure of making a new release. >> Here >> is a (rough) proposal for such a procedure, based on the assumption >> that >> we want to retain more or less our current working practices: >> >> a. Triage of support tickets >> - Green tickets: it's clear what needs doing; and an implementation >> is proposed on the ticket, which will normally be implemented after 5 >> days, unless a majority of Council members veto it before the >> deadline. >> - Amber tickets: it's clear what needs doing, but the implementation >> needs extra input (e.g. more examples, more text). Implementation is >> held for 20 days, pending receipt of the additional material, after >> which the ticket becomes green. >> - Red tickets: it's not clear what needs doing. Within 15 days, the >> task is allocated to a subgroup of Council to debate and formulate >> possible resolution. >> >> b. Review of externally-developed proposals (e.g. from SIGs) >> - A Council subgroup should normally "nuncle" such proposals, >> transforming them into groups of related tickets if possible >> >> c. Timetable >> >> - A ftf meeting should be held to finalise each release, 15 days >> before >> the release itself. >> - A triage of outstanding tickets should be made 40 days before each >> release. >> >> 6. How many releases can we do each year? >> >> We currently do three. If the frequency is too low, there is a risk >> that >> we will not be able to process all the proposals that accumulate in >> the >> course of a year; if too high, there is a risk that we will not have >> enough proposals to warrant the effort of a release. We propose >> two, one >> in the spring, and one in the autumn before the Members Annual >> Meeting >> (but not in conjunction with it). >> >> 7. How should this work be resourced? >> >> Council members may need to justify to their employers the work time >> they devote to the TEI. In some cases, no justification is needed, >> because such work is regarded as in the employing institution's >> interest, as contributing to the individual's career development >> etc.; >> in other cases the amount of such work needs to be carefully >> specified >> (as we have tried to do here) so that a good case can be made. >> However, >> it seems reasonable to hope that people do not stand for election to >> Council without expecting to have to commit some effort, either on >> behalf of their employer or in their own right. As we've argued >> above, >> we need to make the best use we can of such time as they can commit. >> >> There remains a residue of 25 days FTE (about half or a third of the >> total) for each release which is arguably a different kind of work, >> requiring specialist knowledge of the existing system and arguably >> also >> benefitting from continuity. It is essential that it should be the >> Council as a whole which decides how the TEI should develop and >> change >> and which makes the technical decisions about how each change >> should be >> implemented (or not). >> >> So far, the model has been for the Council to delegate responsibility >> for actual implementation to a centralised agency, providing >> "editorial >> services". As mentioned above, these services have till now been >> provided by Oxford, partly as a host contribution, and partly paid >> for >> by the TEI. If Oxford decides to tender as a "TEI Partner", it may >> wish >> to continue to contribute some part of that effort, or it might >> prefer >> to contribute to the TEI in some other way, for example by further >> software development, but that is not for me to say. >> >> The Council Chair has the responsibility of deciding where >> these services are to be obtained -- they might be provided by >> existing >> Council members, by TEI partners, or by private contractor -- and of >> doing so in the most cost-effective and practical manner, so I won't >> pronounce on that either. I will however say that I would like to >> go on >> contributing to the development of the TEI provided that an >> appropriate >> means of doing so can be found. >> >> >> Lou >> >> p.s. In case you were wondering, there's no immediate probability >> of my >> withdrawing from TEI activities entirely! I have just signed a >> contract >> with the French ADONIS project to assist in the development of an >> active >> TEI community in France. But that's another story. >> >> >> _______________________________________________ >> tei-council mailing list >> tei-council at lists.village.Virginia.EDU >> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > > > -- > Dr James Cummings, Research Technologies Service > OUCS, University of Oxford > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Laurent Romary INRIA & HUB-IDSL laurent.romary at inria.fr From sebastian.rahtz at oucs.ox.ac.uk Wed Dec 15 11:41:45 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Wed, 15 Dec 2010 16:41:45 +0000 Subject: [tei-council] editorial services In-Reply-To: <4D08A751.1030900@retired.ox.ac.uk> References: <4D08A751.1030900@retired.ox.ac.uk> Message-ID: <0C497CEC-8364-4B13-9D3E-9E0347129C64@oucs.ox.ac.uk> Just to note: > services". As mentioned above, these services have till now been > provided by Oxford, partly as a host contribution, and partly paid for > by the TEI. If Oxford decides to tender as a "TEI Partner", it may wish > to continue to contribute some part of that effort, or it might prefer > to contribute to the TEI in some other way, for example by further > software development, Oxford is in fact minded to take the latter route, ie to offer itself as a TEI Partner specializing in TEI-related publishing software, and ad hoc development. -- Sebastian Rahtz Information and Support Group Manager Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From daniel.odonnell at uleth.ca Wed Dec 15 13:21:59 2010 From: daniel.odonnell at uleth.ca (O'Donnell, Dan) Date: Wed, 15 Dec 2010 11:21:59 -0700 Subject: [tei-council] Fwd: Re: update from the TEI Tite task force In-Reply-To: <4D08A79A.2080507@retired.ox.ac.uk> References: <4D08A79A.2080507@retired.ox.ac.uk> Message-ID: <4D090747.4070601@uleth.ca> I remember this as being very much the motivation for changing things to positive inclusion rather than exclusion; also the ability to reference specific iterations of arbitrary schemas. The Apex discussion was very much in the context of the old method of doing things--i.e. when things were being excluded. I think the positive approach may mitigate this a lot, since it means that changes to the core TEI modules won't inadvertently introduce new things in Tite. -dan P.S. Kevin: sorry about not ccing perry here: I have a new computer and my address book isn't working for some reason. On 10-12-15 04:33 AM, Lou Burnard wrote: > > [ delayed by my change of identity... ] > > -------- Original Message -------- > Subject: Re: [tei-council] update from the TEI Tite task force > Date: Tue, 14 Dec 2010 13:54:43 +0000 > From: Lou Burnard<lou.burnard at retired.ox.ac.uk> > To: Sebastian Rahtz<sebastian.rahtz at oucs.ox.ac.uk> > CC: Kevin Hawkins<kevin.s.hawkins at ultraslavonic.info>, > "tei-council at lists.village.virginia.edu" > <tei-council at lists.village.virginia.edu>, "gsuprock at apexcovantage.com" > <gsuprock at apexcovantage.com>, "ptrolard at artsci.wustl.edu" > <ptrolard at artsci.wustl.edu> > > Sebastian Rahtz wrote: >>> However, Apex has always told Dan that they will >>> likely not be able to keep up with our incremental improvements to Tite, >>> instead using a DTD snapshot of the schema and retraining their staff >>> only periodically to use a later version. >>> >> >> >> >> fair enough. >> >> and if we use the specific element inclusion, the number of nasty >> surprises will be less anyway. >> -- >> > exactly! cf my comment on the SF ticket. > > There are incidentally two ways of doing this: > > you could say > > <moduleRef key="core" include="all the elements we want from core"/> > > or just > > <elementRef key="all"/> > <elementRef key="the"/> > <elementRef key="elements"/> > > etc. > > I like the second myself, because it's easier and clearer to maintain > but Sebastian points out that > > (a) it's not currently supported by the Roma web application (tho the > stylesheets do support it) > > (b) you need to include the module "tei" to get the basic class > declarations, used in all content models > > (c) if you want to include any class declarations specific to a > particular module, you need to include a<classRef> for it (or include > the module) > > > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council From James.Cummings at oucs.ox.ac.uk Wed Dec 15 14:54:22 2010 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Wed, 15 Dec 2010 19:54:22 +0000 Subject: [tei-council] editorial services In-Reply-To: <800EF3BA-B670-40DF-B853-575C42593A92@inria.fr> References: <4D08A751.1030900@retired.ox.ac.uk> <4D08AA85.5060009@oucs.ox.ac.uk> <800EF3BA-B670-40DF-B853-575C42593A92@inria.fr> Message-ID: <4D091CEE.4000000@oucs.ox.ac.uk> On 15/12/10 12:28, Laurent Romary wrote: > Hi James, > Not sure I understand the question here, but we are discussing here > what impacts on the maintenance of the guidelines and the council > work. What did you have in mind? I guess I was misunderstaning, but I'll explain what I meant. Lou had said: > But it seems > like a good time to make a clear statement about what services are > essential to the continued development of the TEI. To my understanding the TEI hosts provide services that I consider essential to the continued development of the TEI. I.e. Virginia's provision of the website and hosting of the non-dev version of Roma, wiki, SIG-space, and...this very mailing list. Nevermind the infrastructure (etc.) that the other hosts provide. While the editorial services currently provided by Oxford are crucial to the continued development and releases of the TEI, they are not the only thing. (E.g. Lou's message includes the work done by the council members as well, but not, for example, the financial admin done after a f2f meeting.) If we are carving up what current things TEI Hosts provide to form a basis for a list of possible things that TEI Partners could provide the TEI-C as a whole, then I just don't want these activities that are less technical but still required for development to be ignored. We can debate whether we need them on the list though (e.g. SourceForge could provide us with this mailing list if no Partner wanted to do so), but just wanted to remind people that they exist. We can of course ignore them assuming that the Board will ensure that some partner is willing to host the website (for example). -James >>> We start by distinguishing: >>> >>> * Release engineering (producing and distributing new releases from >>> the >>> SVN repository) >>> * Source updates (any kind of update to the SVN repository, ranging >>> from >>> minor modifications to existing specifications or prose to the >>> addition >>> of entirely new specifications or sections in the Guidelines) >>> * Software maintenance (bug fixing and maintaining the existing TEI >>> software environment -- stylesheets, Roma, etc. -- to continue to be >>> able to produce new releases as operating systems etc develop) >>> >>> 2. What is needed for a Release? >>> >>> The pattern that seems to have emerged over the last few years >>> allows us >>> to do three releases a year, usually in October, February, and June. >>> Originally one of these (in October) was a "provisional" one for the >>> members' meeting. However many of them there are, and whenever they >>> happen, over the last two years a full release has usually required >>> something like 50 to 60 days effort: >>> >>> * 5 days contributed by the editorial team in testing, validation, >>> packaging, distribution >>> * 15 days contributed by the editorial team in monitoring, >>> implementing, >>> and testing feature requests and bug reports; making textual and >>> schema >>> mods approved by Council >>> * 25-35 days contributed by council members reviewing, discussing, >>> deciding on issues, currently partly by email, partly at face to >>> face or >>> telephone meetings. >>> * 5 days coordination provided by council chair >>> >>> The "release engineering" is now more or less automated, if fiddly. >>> It >>> could be improved by investing effort in a more modern set of tools >>> to >>> facilitate better working within a "continuous integration" paradigm. >>> The other parts cannot readily be further automated as long as we >>> maintain our current working practice. To move to a proper CI >>> environment would require (I think) quite a bit more development of >>> our >>> current test suite, which at present is at best sketchy in its >>> enforcement of those areas of TEI conformance which are vaguely >>> hinted >>> at or informally stated in the Guidelines but not enforced e.g. as >>> schematron rules. And defining such rules would certainly imply a >>> significant amount of user consultation and discussion. >>> >>> 3. What is needed for Software maintenance? >>> >>> Sebastian has estimated that he spends about three days a year >>> maintaining the Roma tools and Stylesheet test suite in their current >>> state; these are currently essential to the whole process of >>> generating >>> and testing new versions. This aspect (software maintenance) should >>> be >>> distinguished from development of new complementary TEI >>> applications, of >>> course. >>> >>> There is an outstanding need to provide additional ODD processing >>> tools, >>> if only to meet the common W3C requirement for dual implementation. >>> This >>> should be organised as a distinct project, however. >>> >>> >>> 4. How cost-effective is this method? >>> >>> If we cost in Council members' time, as we have above, the cost of a >>> release organised in this way is high -- 50 to 60 days FTE. In >>> practice, >>> it is difficult to estimate the cost: some Council members contribute >>> disproportionately more time than others, depending on their other >>> committments and the nature of their jobs. >>> >>> Our experience is that telephone conferences are a good way of >>> confirming decisions and monitoring progress, but they are not as >>> effective as face to face meetings for issues which require prolonged >>> discussion or reflection. Moreover, it is unreasonable to expect busy >>> people to contribute significant levels of effort without some kind >>> of >>> focus or motivation for that effort, such as participation in a >>> specific >>> meeting. >>> >>> Council meetings are currently only held once a year, and they are >>> not >>> therefore directly linked to the release cycle, which is faster. The >>> travel costs associated with a ftf meeting should be regarded in the >>> context of the cost of the effort provided by meeting participants >>> (which is not charged for): although it may cost 20k to bring ten >>> people >>> together for a two day meeting, the resulting 20 person-days of >>> productive work do not cost the TEI anything more. >>> >>> 5. How should we proceed? >>> >>> We should formalise and cost the procedure of making a new release. >>> Here >>> is a (rough) proposal for such a procedure, based on the assumption >>> that >>> we want to retain more or less our current working practices: >>> >>> a. Triage of support tickets >>> - Green tickets: it's clear what needs doing; and an implementation >>> is proposed on the ticket, which will normally be implemented after 5 >>> days, unless a majority of Council members veto it before the >>> deadline. >>> - Amber tickets: it's clear what needs doing, but the implementation >>> needs extra input (e.g. more examples, more text). Implementation is >>> held for 20 days, pending receipt of the additional material, after >>> which the ticket becomes green. >>> - Red tickets: it's not clear what needs doing. Within 15 days, the >>> task is allocated to a subgroup of Council to debate and formulate >>> possible resolution. >>> >>> b. Review of externally-developed proposals (e.g. from SIGs) >>> - A Council subgroup should normally "nuncle" such proposals, >>> transforming them into groups of related tickets if possible >>> >>> c. Timetable >>> >>> - A ftf meeting should be held to finalise each release, 15 days >>> before >>> the release itself. >>> - A triage of outstanding tickets should be made 40 days before each >>> release. >>> >>> 6. How many releases can we do each year? >>> >>> We currently do three. If the frequency is too low, there is a risk >>> that >>> we will not be able to process all the proposals that accumulate in >>> the >>> course of a year; if too high, there is a risk that we will not have >>> enough proposals to warrant the effort of a release. We propose >>> two, one >>> in the spring, and one in the autumn before the Members Annual >>> Meeting >>> (but not in conjunction with it). >>> >>> 7. How should this work be resourced? >>> >>> Council members may need to justify to their employers the work time >>> they devote to the TEI. In some cases, no justification is needed, >>> because such work is regarded as in the employing institution's >>> interest, as contributing to the individual's career development >>> etc.; >>> in other cases the amount of such work needs to be carefully >>> specified >>> (as we have tried to do here) so that a good case can be made. >>> However, >>> it seems reasonable to hope that people do not stand for election to >>> Council without expecting to have to commit some effort, either on >>> behalf of their employer or in their own right. As we've argued >>> above, >>> we need to make the best use we can of such time as they can commit. >>> >>> There remains a residue of 25 days FTE (about half or a third of the >>> total) for each release which is arguably a different kind of work, >>> requiring specialist knowledge of the existing system and arguably >>> also >>> benefitting from continuity. It is essential that it should be the >>> Council as a whole which decides how the TEI should develop and >>> change >>> and which makes the technical decisions about how each change >>> should be >>> implemented (or not). >>> >>> So far, the model has been for the Council to delegate responsibility >>> for actual implementation to a centralised agency, providing >>> "editorial >>> services". As mentioned above, these services have till now been >>> provided by Oxford, partly as a host contribution, and partly paid >>> for >>> by the TEI. If Oxford decides to tender as a "TEI Partner", it may >>> wish >>> to continue to contribute some part of that effort, or it might >>> prefer >>> to contribute to the TEI in some other way, for example by further >>> software development, but that is not for me to say. >>> >>> The Council Chair has the responsibility of deciding where >>> these services are to be obtained -- they might be provided by >>> existing >>> Council members, by TEI partners, or by private contractor -- and of >>> doing so in the most cost-effective and practical manner, so I won't >>> pronounce on that either. I will however say that I would like to >>> go on >>> contributing to the development of the TEI provided that an >>> appropriate >>> means of doing so can be found. >>> >>> >>> Lou >>> >>> p.s. In case you were wondering, there's no immediate probability >>> of my >>> withdrawing from TEI activities entirely! I have just signed a >>> contract >>> with the French ADONIS project to assist in the development of an >>> active >>> TEI community in France. But that's another story. >>> >>> >>> _______________________________________________ >>> tei-council mailing list >>> tei-council at lists.village.Virginia.EDU >>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council >> >> >> -- >> Dr James Cummings, Research Technologies Service >> OUCS, University of Oxford >> _______________________________________________ >> tei-council mailing list >> tei-council at lists.village.Virginia.EDU >> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > > Laurent Romary > INRIA& HUB-IDSL > laurent.romary at inria.fr > > > -- Dr James Cummings, Research Technology Service Oxford University Computing Services University of Oxford From kevin.s.hawkins at ultraslavonic.info Wed Dec 15 17:58:22 2010 From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins) Date: Wed, 15 Dec 2010 17:58:22 -0500 Subject: [tei-council] editorial services In-Reply-To: <4D08A751.1030900@retired.ox.ac.uk> References: <4D08A751.1030900@retired.ox.ac.uk> Message-ID: <4D09480E.6060406@ultraslavonic.info> Below I make some tentative clarifications to Lou's message and ask for corrections when I've misunderstood: > 1. What are the "editorial services"? > > We start by distinguishing: > > * Release engineering (producing and distributing new releases from the > SVN repository) > * Source updates (any kind of update to the SVN repository, ranging from > minor modifications to existing specifications or prose to the addition > of entirely new specifications or sections in the Guidelines) > * Software maintenance (bug fixing and maintaining the existing TEI > software environment -- stylesheets, Roma, etc. -- to continue to be > able to produce new releases as operating systems etc develop) We should be careful to split "source updates" into two activities: (a) editing prose when specific revisions are not spelled out in a ticket or other proposal adopted by Council and (b) making prose and schema changes to the ODDs in SourceForge. While it's most convenient if one person can do both technical writing and maintain ODDs, it can be hard to find someone sufficiently skilled in both, so we should be willing to consider these as separate activities in case they need to be divided between people. > 2. What is needed for a Release? > > The pattern that seems to have emerged over the last few years allows us > to do three releases a year, usually in October, February, and June. > Originally one of these (in October) was a "provisional" one for the > members' meeting. However many of them there are, and whenever they > happen, over the last two years a full release has usually required > something like 50 to 60 days effort: > > * 5 days contributed by the editorial team in testing, validation, > packaging, distribution > * 15 days contributed by the editorial team in monitoring, implementing, > and testing feature requests and bug reports; making textual and schema > mods approved by Council > * 25-35 days contributed by council members reviewing, discussing, > deciding on issues, currently partly by email, partly at face to face or > telephone meetings. > * 5 days coordination provided by council chair From what Lou says below, these do not include weekends. But they represent elapsed days, not necessarily full days of work. That is, 25-35 work days pass while Council is working, but Council members are not all putting in approximately eight hours per day. > 5. How should we proceed? > > We should formalise and cost the procedure of making a new release. Here > is a (rough) proposal for such a procedure, based on the assumption that > we want to retain more or less our current working practices: > > a. Triage of support tickets > - Green tickets: it's clear what needs doing; and an implementation > is proposed on the ticket, which will normally be implemented after 5 > days, unless a majority of Council members veto it before the deadline. > - Amber tickets: it's clear what needs doing, but the implementation > needs extra input (e.g. more examples, more text). Implementation is > held for 20 days, pending receipt of the additional material, after > which the ticket becomes green. > - Red tickets: it's not clear what needs doing. Within 15 days, the > task is allocated to a subgroup of Council to debate and formulate > possible resolution. The trick is to decide who will assign a color to a ticket and to keep people aprised of which tickets are currently in their window for input. Are you imaginging this all happening on a rolling basis, or Council members be asked twice a year to comment on all green tickets within the next five days, all ambert tickets within the next 20, etc.? > b. Review of externally-developed proposals (e.g. from SIGs) > - A Council subgroup should normally "nuncle" such proposals, > transforming them into groups of related tickets if possible For the newcomers to Council: while "nuncle" as a noun has certain meanings in British English, it has come to be used in Council to be used as a verb for "to steward". If this usage sticks (and I hope it doesn't because we should avoid jargon to make our work more accessible to newcomers), we should add this to the Council FAQ on the wiki. > c. Timetable > > - A ftf meeting should be held to finalise each release, 15 days before > the release itself. A face-to-face meeting of the whole Council? > - A triage of outstanding tickets should be made 40 days before each > release. > > 6. How many releases can we do each year? > > We currently do three. If the frequency is too low, there is a risk that > we will not be able to process all the proposals that accumulate in the > course of a year; if too high, there is a risk that we will not have > enough proposals to warrant the effort of a release. We propose two, one > in the spring, and one in the autumn before the Members Annual Meeting > (but not in conjunction with it). Unless I'm mistaken from above statements, this would require increasing the frequency of Council meetings (back) to two per year. *** Incidentally, Lou said that the TEI hosts are to be called TEI partners. Didn't see that in the proposed Bylaw revisions. And, incidentally, we heard on TEI-L that since quorum was not reached on the vote by TEI member institutions, the Board at its meeting in Zadar adopted those changes it could make on its own without needing approval by members. Will the Bylaws be updated on tei-c.org to reflect what changes were in fact made at that meeting in Zadar? From sebastian.rahtz at oucs.ox.ac.uk Wed Dec 15 18:36:16 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Wed, 15 Dec 2010 23:36:16 +0000 Subject: [tei-council] editorial services In-Reply-To: <4D09480E.6060406@ultraslavonic.info> References: <4D08A751.1030900@retired.ox.ac.uk> <4D09480E.6060406@ultraslavonic.info> Message-ID: <68E76DE1-1D87-4B19-AB8D-063BC341C033@oucs.ox.ac.uk> On 15 Dec 2010, at 22:58, Kevin Hawkins wrote: > We should be careful to split "source updates" into two activities: (a) > editing prose when specific revisions are not spelled out in a ticket or > other proposal adopted by Council and (b) making prose and schema > changes to the ODDs in SourceForge. you are distinguishing the running prose from the reference material? They are different skills, I agree; but I would make other distinctions too - eg between changes which involve simple additions or subtractions, and ones which involve class manipulation and understand the changes which may result in a DTD/schema. there's a lot of technical writing skill in making ref documentation, I would claim > > For the newcomers to Council: while "nuncle" as a noun has certain > meanings in British English, it has come to be used in Council to be > used as a verb for "to steward". If this usage sticks (and I hope it > doesn't amen to that. I think its a horrible word! > Incidentally, Lou said that the TEI hosts are to be called TEI partners. > Didn't see that in the proposed Bylaw revisions. the change was made at the Board meeting to introduce this concept. > And, incidentally, > we heard on TEI-L that since quorum was not reached on the vote by TEI > member institutions, the Board at its meeting in Zadar adopted those > changes it could make on its own without needing approval by members. which was, in fact, more or less everything. no serious decisions were left unattended, I believe (and if you wonder why I comment, its because I attended the first part of the meeting, unexpectedly) > Will the Bylaws be updated on tei-c.org to reflect what changes were in > fact made at that meeting in Zadar? undoubtedly! -- Sebastian Rahtz Information and Support Group Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From kevin.s.hawkins at ultraslavonic.info Wed Dec 15 21:52:36 2010 From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins) Date: Wed, 15 Dec 2010 21:52:36 -0500 Subject: [tei-council] editorial services In-Reply-To: <68E76DE1-1D87-4B19-AB8D-063BC341C033@oucs.ox.ac.uk> References: <4D08A751.1030900@retired.ox.ac.uk> <4D09480E.6060406@ultraslavonic.info> <68E76DE1-1D87-4B19-AB8D-063BC341C033@oucs.ox.ac.uk> Message-ID: <4D097EF4.3020304@ultraslavonic.info> Sebastian Rahtz wrote: > On 15 Dec 2010, at 22:58, Kevin Hawkins wrote: >> We should be careful to split "source updates" into two activities: (a) >> editing prose when specific revisions are not spelled out in a ticket or >> other proposal adopted by Council and (b) making prose and schema >> changes to the ODDs in SourceForge. > > you are distinguishing the running prose from the reference > material? They are different skills, I agree; but I would > make other distinctions too - eg between changes which > involve simple additions or subtractions, and ones which > involve class manipulation and understand the changes which > may result in a DTD/schema. You could divide it that way, but I was actually thinking of the difference between knowing how to write clear prose for the guidelines and knowing how to edit an ODD file. In the latter I include not only understanding the class system and schema languages but even the tag set used within the ODD (like <gi>). >> And, incidentally, >> we heard on TEI-L that since quorum was not reached on the vote by TEI >> member institutions, the Board at its meeting in Zadar adopted those >> changes it could make on its own without needing approval by members. > > which was, in fact, more or less everything. no serious decisions were > left unattended, I believe (and if you wonder why I comment, its > because I attended the first part of the meeting, unexpectedly) > >> Will the Bylaws be updated on tei-c.org to reflect what changes were in >> fact made at that meeting in Zadar? > > > undoubtedly! No foul play suspected. I just know how these things slip through the cracks. My modus operandi is to nag people about the things they said they would do but then never did. (Just ask Dan or Laurent ...) In this case, I'm not sure who to nag. From sebastian.rahtz at oucs.ox.ac.uk Thu Dec 16 03:29:28 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Thu, 16 Dec 2010 08:29:28 +0000 Subject: [tei-council] editorial services In-Reply-To: <4D097EF4.3020304@ultraslavonic.info> References: <4D08A751.1030900@retired.ox.ac.uk> <4D09480E.6060406@ultraslavonic.info> <68E76DE1-1D87-4B19-AB8D-063BC341C033@oucs.ox.ac.uk> <4D097EF4.3020304@ultraslavonic.info> Message-ID: <41ACEF64-B5A0-4DBC-A2D4-865E4CE5D4C7@oucs.ox.ac.uk> On 16 Dec 2010, at 02:52, Kevin Hawkins wrote: > You could divide it that way, but I was actually thinking of the > difference between knowing how to write clear prose for the guidelines > and knowing how to edit an ODD file. In the latter I include not only > understanding the class system and schema languages but even the tag set > used within the ODD (like <gi>). just to be clear, all the TEI Guidelines are one (ODD) doc, and the usage of tags like <gi> is uniform across running prose and tech doc. The chapter parts of the of the gidlines do require you to grok eg specDesc, specList, egXML, tag, att and friends. But the discipline is not the same as writing *Spec, I agree > My modus operandi is to nag people about the things they said > they would do but then never did. (Just ask Dan or Laurent ...) In > this case, I'm not sure who to nag. Dan, I suspect. -- Sebastian Rahtz Information and Support Group Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From lou.burnard at retired.ox.ac.uk Thu Dec 16 06:03:35 2010 From: lou.burnard at retired.ox.ac.uk (Lou Burnard) Date: Thu, 16 Dec 2010 11:03:35 +0000 Subject: [tei-council] editorial services In-Reply-To: <4D09480E.6060406@ultraslavonic.info> References: <4D08A751.1030900@retired.ox.ac.uk> <4D09480E.6060406@ultraslavonic.info> Message-ID: <4D09F207.5090706@retired.ox.ac.uk> Thanks for the comments Kevin. Clarifications and comments below > We should be careful to split "source updates" into two activities: (a) > editing prose when specific revisions are not spelled out in a ticket or > other proposal adopted by Council and (b) making prose and schema > changes to the ODDs in SourceForge. While it's most convenient if one > person can do both technical writing and maintain ODDs, it can be hard > to find someone sufficiently skilled in both, so we should be willing to > consider these as separate activities in case they need to be divided > between people. While I agree that updating the prose requires different skills than changing membership of an element in a class, and that finding a good example for something requires a different skillset again, the whole purpose of ODD, and the whole way that the Guidelines is constructed, requires one to think of these things all together. Changes you make -- or fail to make -- to an element spec (notably for example its description) affect what appears in the running prose, for example. So I don't think I accept the distinction you seem to want to make between "technical writing" and "maintaining ODDs". I think they are complementary. > From what Lou says below, these do not include weekends. But they > represent elapsed days, not necessarily full days of work. That is, > 25-35 work days pass while Council is working, but Council members are > not all putting in approximately eight hours per day. My "days" are no more than indicative approximations of working time spent/required. They don't take into account weekends, elapsed time, hours per day, sickness or national holidays! Just figures plucked out of the air really, to give some sense of the scale we're talking. > For the newcomers to Council: while "nuncle" as a noun has certain > meanings in British English, it has come to be used in Council to be > used as a verb for "to steward". If this usage sticks (and I hope it > doesn't because we should avoid jargon to make our work more accessible > to newcomers), we should add this to the Council FAQ on the wiki. Fair enough. Usage will determine its survival, or not! (But don't you think "steward" might require just as much explanation?) > > > c. Timetable > > > > - A ftf meeting should be held to finalise each release, 15 days before > > the release itself. > > A face-to-face meeting of the whole Council? Yes. > > Unless I'm mistaken from above statements, this would require increasing > the frequency of Council meetings (back) to two per year. Yes > Will the Bylaws be updated on tei-c.org to reflect what changes were in > fact made at that meeting in Zadar? As Sebastian has already noted, the Board meeting in Zadar raised but did not resolve many important issues. We are all standing by for news on several related fronts. My posting however was intended to start addressing the one that I personally consider to be the most important of the many challenges facing the TEI -- proposing an effective way to continue maintenance and development of the Guidelines, which I persist in believing to be the main purpose for the TEI's existence. Other things (as James noted) also need to be considered, but one has to start somewhere. From gabriel.bodard at kcl.ac.uk Thu Dec 16 07:46:06 2010 From: gabriel.bodard at kcl.ac.uk (Gabriel Bodard) Date: Thu, 16 Dec 2010 12:46:06 +0000 Subject: [tei-council] editorial services In-Reply-To: <68E76DE1-1D87-4B19-AB8D-063BC341C033@oucs.ox.ac.uk> References: <4D08A751.1030900@retired.ox.ac.uk> <4D09480E.6060406@ultraslavonic.info> <68E76DE1-1D87-4B19-AB8D-063BC341C033@oucs.ox.ac.uk> Message-ID: <4D0A0A0E.6090307@kcl.ac.uk> >> For the newcomers to Council: while "nuncle" as a noun has certain >> meanings in British English, it has come to be used in Council to be >> used as a verb for "to steward". If this usage sticks (and I hope it >> doesn't > amen to that. I think its a horrible word! Oh I quite like the word "nuncle"; it has a kind of bucolic charm that tickles me, and I'm happy to see archaic words brought back into use (albeit with idiosyncratic meanings). I do take the point about it being jargon, however (although I didn't think it had the status of a technical term in our community). If we need a technical term, is "steward", "sponsor", "adopt", "usher" any better? > you are distinguishing the running prose from the reference > material? They are different skills, I agree; but I would > make other distinctions too - eg between changes which > involve simple additions or subtractions, and ones which > involve class manipulation and understand the changes which > may result in a DTD/schema. The distinction I would make would be between writing prose (including basic markup such as <p> <gi> <att> and so forth), which we should expect all Council members (+ SIG volunteers etc.) to be able to do, and editing schemaSpecs and the like, which takes a certain amount of technical know-how, which most Council members can (or could, if they pushed themselves to learn[*]) probably do, but nevertheless probably needs significant oversight. ([*] I include myself in the "need to push self" category.) Cheers, G -- Dr Gabriel BODARD (Research Associate in Digital Epigraphy) Centre for Computing in the Humanities King's College London 26-29 Drury Lane London WC2B 5RL Email: gabriel.bodard at kcl.ac.uk Tel: +44 (0)20 7848 1388 Fax: +44 (0)20 7848 2980 http://www.digitalclassicist.org/ http://www.currentepigraphy.org/ From gabriel.bodard at kcl.ac.uk Fri Dec 17 06:32:28 2010 From: gabriel.bodard at kcl.ac.uk (Gabriel Bodard) Date: Fri, 17 Dec 2010 11:32:28 +0000 Subject: [tei-council] editorial services In-Reply-To: <731E0C64-AD12-4533-B3B4-9AD16B25A1DD@oucs.ox.ac.uk> References: <4D08A751.1030900@retired.ox.ac.uk> <4D09480E.6060406@ultraslavonic.info> <68E76DE1-1D87-4B19-AB8D-063BC341C033@oucs.ox.ac.uk> <4D0A0A0E.6090307@kcl.ac.uk> <731E0C64-AD12-4533-B3B4-9AD16B25A1DD@oucs.ox.ac.uk> Message-ID: <4D0B4A4C.8040309@kcl.ac.uk> I guess there are different kinds of difficulty, too. Anyone can write, but maybe not everyone can write well. (And it may be harder or more time-consuming to write really well to a particular end.) On the other hand, not anyone can pick up the *Spec part of an ODD and immediately know how to do what they want to with it. (But when they do, it may be easier--or less time-consuming--to do it properly.) On 16/12/2010 23:11, Sebastian Rahtz wrote: >> The distinction I would make would be between writing prose (including >> basic markup such as<p> <gi> <att> and so forth), which we should >> expect all Council members (+ SIG volunteers etc.) to be able to do, and >> editing schemaSpecs and the like, which takes a certain amount of >> technical know-how, which most Council members can (or could, if they >> pushed themselves to learn[*]) probably do, but nevertheless probably >> needs significant > > Interesting. I see it the other way around. Doing the *Spec is sort of mechanical > and testable - if you make a mistake, the tests will catch it, especially if we put > some effort into a CI setup. Whereas writing clear long-term prose is often harder. > if we stick with the 18th century discursive style of P5 ..... > > Moral is that different things are hard for different people, and it's hard to predict what. > > Sebastian -- Dr Gabriel BODARD (Research Associate in Digital Epigraphy) Centre for Computing in the Humanities King's College London 26-29 Drury Lane London WC2B 5RL Email: gabriel.bodard at kcl.ac.uk Tel: +44 (0)20 7848 1388 Fax: +44 (0)20 7848 2980 http://www.digitalclassicist.org/ http://www.currentepigraphy.org/ From kevin.s.hawkins at ultraslavonic.info Sun Dec 19 16:00:56 2010 From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins) Date: Sun, 19 Dec 2010 16:00:56 -0500 Subject: [tei-council] how to encode a hyphen at the end of a line, column, or page when you are encoding hyphens Message-ID: <4D0E7288.6010006@ultraslavonic.info> Martin Mueller's message to TEI-L this week reminds me that, despite all our discussion in Dublin and on tei-council between May 21 and June 28, I'm not sure we've reached a conclusion on how to encode a hyphen (when you not simply discarding hyphens in your encoding) that occurs at a line, column, or page break and whose status with respect to breaking a word is unclear. I also don't believe any changes have actually made to P5. :( Let me summarize my understanding of where the discussion stands. (It's quite a long summary, I'm afraid, but the point is to keep you from having to spend hours pulling together past emails, as I just have!) There are three suggested directions (below, A, B, and C) for handling this situation. == (A) encode using attributes on pb, lb, and cb == In Dublin we had settled on not leaving any character to represent the hyphen as character data but type= and rend= to convey this information. P5 currently says the following in the note for the definition <lb/> ( http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-lb.html ): "The type attribute may be used to characterize the line break in any respect, but its most common use is to specify that the presence of the line break does not imply the end of the word in which it is embedded. A value such as 'inWord' or 'nobreak' is recommended for this purpose, but encoders are free to choose whichever values are appropriate." I find "inWord" and "nobreak" entirely non-intuitive, but Lou explained these values (and a third he suggested) as such: * inWord: the tokeniser needs to combine the string before the linebreak with the string after it to form a single token * betweenWords: the string before the linebreak and the string after it are two separate tokens * wordBreakStatusUnknown: it could be either of the other two and we're unwilling or unable to decide I prefer these values for type=: * lexicalBoundary * noLexicalBoundary * uncertainLexicalBoundary However, these may not be expressive enough for everything you'd like to encode. Paul Schaffner provided the following examples (which I've annotated): a) street<lb/>walker -- line break between components of a usually non-hyphenated compound b) bag-<lb/>lady -- line break and hyphen between components of a usually hyphenated compound c) win-<lb/>some -- line break and hyphen between syllables (or morphemes) in a single word d) iP-<lb/>hone -- line break and hyphen within a word but misplaced according to usual rules of breaking words across lines e) gentle-<lb/>man -- line break and hyphen inside of a something that may or may not be regarded as a compound f) abusive-<lb/tagger -- line break between words; hyphen included for unclear reasons As for values of rend=, we might have: * hyphen * duplicatedLetter (for cases like Old Irish, Dutch, and German) or any other appropriate description of how the break is rendered. Whatever value you give for rend=, you would not leave the hyphen, duplicated character, etc. in the character data of the XML document. == (B) Allow certainty, precision, etc. as content of pb, lb, and cb (cf. gap and space) == Gabby suggested that we do to <lb/>, <cb/>, and <pb/> what has already been done to <gap> and <space>: allow <certainty>, <precision>, etc. as content. That way if you are *unsure whether a break actually occurs*, you could have something like: <lb> <certainty locus="break" degree="0.5"/> </lb> leaving the following way to express that we're *uncertain of the type of hyphen*: <p>Some people say TEI is a mark-<lb type="uncertain"/>up language.</p> Elena supported Gabby's change to content models since it would also work to handle missing, corrected, and incorrect page or line numbers, but Lou, Martin Holmes, and Dot said to use <fw> for representing numbering -- especially errors in the numbering -- as it appears in the source. I'm having trouble imagining ever being uncertain whether a line, column, or page break actually *occurs* in a source, so it seems that the only reason you would ever want to use <certainty> etc. within <lb/>, <pb/>, and <cb/> is with locus=. Is this troubling to anyone else besides me? Otherwise, I'm okay with this solution. == (C) Use <w>, <phr>, and other phrase-level elements to encode the context of a page break, line break, or column break == Martin Holmes said: "I still think that the linebreak tag is the wrong place to supply information about whatever-it-is-that-is-being-broken (word, phrase or whatever) and whatever-it-is-that-is-signalling-the-break (hyphen or whatever). The linebreak tag says there is a linebreak in the text. The context, and the glyph that precedes the linebreak, are not attributes of the linebreak. I think it would be better to encourage the use of <w>, <phr> and other phrase-level tags to mark the context of the linebreak. Even if such tags are not being used for any other purpose in a text -- or perhaps _especially_ if they aren't -- they could be used for exactly this purpose, and it's easy for a processor to detect when a linebreak-signalling glyph or a linebreak tag occur within such contexts and process accordingly." Martin Holmes said he'd encode Paul Schaffner's examples (again, with my annotations) like this: a) <phr>street<lb/>walker</phr> -- line break between components of a usually non-hyphenated compound b) <phr type="hyphenated">bag-<lb/>lady</phr> -- line break and hyphen between components of a usually hyphenated compound c) <w>win-<lb/>some</w> -- line break and hyphen between syllables (or morphemes) in a single word d) <w>iP-<lb/>hone</w> -- line break and hyphen within a word but misplaced according to usual rules of breaking words across lines e) <choice><orig>gentle-man</orig><corr>gentleman</corr></choice> -- line break and hyphen inside of a something that may or may not be regarded as a compound f) <w>abusive</w>-<lb/><w>tagger</w> -- line break between words; hyphen included for unclear reasons Perhaps he also meant to include type="hyphenated" on <w> in (c), <w> in (d), <orig> in (e). We need to keep in mind that if we recommend encoding use of hyphens on <w>, <phr>, or other phrase-level elements without specifying which one(s), we will reduce the ability to interchange TEI documents. Martin Mueller would surely not be happy with us for that. *** I support (A) or (B) but with a new section of the Guidelines explaining how to do this (replacing the brief information currently given at http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-lb.html ). Let me also reiterate my request to Lou (and the rest of you) to edit the minutes from Dublin at http://wiki.tei-c.org/index.php/Draft_minutes_of_2010-04_Council_meeting#hyphenation_.28and_orthographical_changes_at_line_breaks.29 to set the record straight on what we actually discussed. --Kevin From laurent.romary at inria.fr Mon Dec 20 10:21:22 2010 From: laurent.romary at inria.fr (Laurent Romary) Date: Mon, 20 Dec 2010 16:21:22 +0100 Subject: [tei-council] update on spring 2011 council meeting Message-ID: <059B06B1-E1C1-453D-AD02-C7B44D3FCB43@inria.fr> Dear Council members, Please reserve 11-13 April 2011 for a Council meeting at the Big Ten Center near Chicago O'Hare International Airport. We will have a one-day symposium on Monday followed by a two-day Council meeting on Tuesday and Wednesday. More details to follow! Laurent Laurent Romary INRIA & HUB-IDSL laurent.romary at inria.fr From lou.burnard at oucs.ox.ac.uk Mon Dec 20 11:50:21 2010 From: lou.burnard at oucs.ox.ac.uk (Lou Burnard) Date: Mon, 20 Dec 2010 16:50:21 +0000 Subject: [tei-council] update on spring 2011 council meeting In-Reply-To: <059B06B1-E1C1-453D-AD02-C7B44D3FCB43@inria.fr> References: <059B06B1-E1C1-453D-AD02-C7B44D3FCB43@inria.fr> Message-ID: <4D0F894D.6030308@oucs.ox.ac.uk> This is good news, but how should it affect our release cycle? I haven't seen much comment on my message of last week, but if we agree with what is stated there, we will be using this meeting to sign off on the next P5 release. Or are we planning to squeeze in a release *before* it? wOn 20/12/10 15:21, Laurent Romary wrote: > Dear Council members, > > Please reserve 11-13 April 2011 for a Council meeting at the Big Ten > Center near Chicago O'Hare International Airport. We will have a one-day > symposium on Monday followed by a two-day Council meeting on Tuesday and > Wednesday. More details to follow! > > Laurent > > > Laurent Romary > INRIA& HUB-IDSL > laurent.romary at inria.fr > > > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council From sebastian.rahtz at oucs.ox.ac.uk Mon Dec 20 12:05:38 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 20 Dec 2010 17:05:38 +0000 Subject: [tei-council] update on spring 2011 council meeting In-Reply-To: <4D0F894D.6030308@oucs.ox.ac.uk> References: <059B06B1-E1C1-453D-AD02-C7B44D3FCB43@inria.fr> <4D0F894D.6030308@oucs.ox.ac.uk> Message-ID: <A6164E5B-BCEE-49C5-92C9-DD253791CE7B@oucs.ox.ac.uk> On 20 Dec 2010, at 16:50, Lou Burnard wrote: > This is good news, but how should it affect our release cycle? > > I haven't seen much comment on my message of last week, but if we agree > with what is stated there, we will be using this meeting to sign off on > the next P5 release. Or are we planning to squeeze in a release > *before* it? I suppose there are three possibilities: a) we make a release in early feb using editorial resources owed from last year, and implementing decisions effectively made earlier this year (viz genetic stuff), and then move to a May and November release (if we can afford two meetings) b) we build up from now to a giant release in May c) we reject the premise of your message, and continue to release 3 times a year with whatever is available, using whatever time and resources anyone wants to commit if we could get anywhere with the current large set of requests which are between 50% and 90% discussed, I suggest that it would be well worth while doing a february release under the Old Dispensation, otherwise the burden will become too great. -- Sebastian Rahtz Information and Support Group Manager Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From mholmes at uvic.ca Mon Dec 20 12:14:01 2010 From: mholmes at uvic.ca (Martin Holmes) Date: Mon, 20 Dec 2010 09:14:01 -0800 Subject: [tei-council] update on spring 2011 council meeting In-Reply-To: <059B06B1-E1C1-453D-AD02-C7B44D3FCB43@inria.fr> References: <059B06B1-E1C1-453D-AD02-C7B44D3FCB43@inria.fr> Message-ID: <4D0F8ED9.1020208@uvic.ca> The 11th clashes with a vacation I've booked, but I may be able to cancel it. Cheers, Martin Laurent Romary wrote: > Dear Council members, > > Please reserve 11-13 April 2011 for a Council meeting at the Big Ten > Center near Chicago O'Hare International Airport. We will have a one-day > symposium on Monday followed by a two-day Council meeting on Tuesday and > Wednesday. More details to follow! > > Laurent > > > Laurent Romary > INRIA & HUB-IDSL > laurent.romary at inria.fr > > > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council From lou.burnard at oucs.ox.ac.uk Mon Dec 20 12:35:43 2010 From: lou.burnard at oucs.ox.ac.uk (Lou Burnard) Date: Mon, 20 Dec 2010 17:35:43 +0000 Subject: [tei-council] how to encode a hyphen at the end of a line, column, or page when you are encoding hyphens In-Reply-To: <4D0E7288.6010006@ultraslavonic.info> References: <4D0E7288.6010006@ultraslavonic.info> Message-ID: <4D0F93EF.3060100@oucs.ox.ac.uk> Thanks for reminding us about this partially unresolved issue. If I may, I'll just nit pick on a few bits of your helpful summary, hoping that we can reach consensus on this issue quite quickly. On 19/12/10 21:00, Kevin Hawkins wrote: > word is unclear. I also don't believe any changes have actually made to > P5. :( There were some changes in wording following the last time but one this was raised (by Gabriel and other epidockers) > > == (A) encode using attributes on pb, lb, and cb == > > In Dublin we had settled on not leaving any character to represent the > hyphen as character data but type= and rend= to convey this information. I am not sure that we all agreed with that as a recommendation (i.e. that hyphens should always be removed). I do think we agreed that if that encoding policy were adopted, the Guidelines should provide a clear mechanism for recording where removed hyphens (etc.) had been. > > I find "inWord" and "nobreak" entirely non-intuitive "inWord" seems fairly obvious to me. More significantly perhaps, it was the value which the Epidockers agreed on after a fairly heated debate. Maybe "inToken" or "internal" ? > I prefer these values for type=: > > * lexicalBoundary > * noLexicalBoundary > * uncertainLexicalBoundary > I am not comfortable with "lexical" here, because where I come from "lexical entries" may include multiple "tokens". If I treat "apple pie" as a lexical entry, and there happens to be a <lb/> between the "apple" and the "pie" I don't think I'd mark the <lb/> any different from any other. I think we should stick with the idea that line-end hyphenation (or not) is to do with simple minded orthographic tokens, not tricky things like lexical items. > However, these may not be expressive enough for everything you'd like to > encode. Paul Schaffner provided the following examples (which I've > annotated): > > a) street<lb/>walker -- line break between components of a usually > non-hyphenated compound Not sure what a "compound" is here. For me, the critical point is whether elsewhere in this text I find, or expect to find, "streetwalker" (in which case the <lb/> is "inWord") or "street walker" (in which case it isn't). And if I don't want to take a stand either way, then it is "undecided". > > b) bag-<lb/>lady -- line break and hyphen between components of a > usually hyphenated compound > > c) win-<lb/>some -- line break and hyphen between syllables (or > morphemes) in a single word > > d) iP-<lb/>hone -- line break and hyphen within a word but misplaced > according to usual rules of breaking words across lines > > e) gentle-<lb/>man -- line break and hyphen inside of a something that > may or may not be regarded as a compound > > f) abusive-<lb/tagger -- line break between words; hyphen included for > unclear reasons These all seem to evince a desire to do much more about characterising the text than seems appropriate for <lb/> (which is sort of Martin's point, I think) -- in my (possibly addled by snow) mind, it's a fairly simple issue: usually an automatic tokenisation can safely assume that the presence of an <lb/> should be treated in the same way as the presence of white space; the "inWord" attribute value just cancels that assumption. There may also be real white space hanging around on either side of the <lb/> of course; the tokeniser will then have to decide for itself what it wants to do about that, but in principle I think the sequence characters + whitespace + <lb type="inWord"/> + characters is probably an error (assuming that characters and whitespace are mutually exclusive for most tokenisation purposes!) > > As for values of rend=, we might have: > > * hyphen > * duplicatedLetter (for cases like Old Irish, Dutch, and German) I don't know enough about these languages to know whether just saying "duplicated letter" would be enough. I think during the discussion we felt that there were tricky cases which might need the full pomp and majesty of <choice> or some such > == (B) Allow certainty, precision, etc. as content of pb, lb, and cb > (cf. gap and space) == This seems to me an orthogonal issue. On the grounds of simplicity, I am quite reluctant to complexify the use of <lb/> in this way -- a gazillion stylesheet developers will not thank us for making it a non-empty element, especially if the only use case is the somewhat esoteric example cited so far. Uncertainty about the locus of a milestone can also be done by pointing at it, after all. O blimey, it's started snowing again. Definitely time for another cup of tea. Lou From laurent.romary at inria.fr Wed Dec 22 09:38:09 2010 From: laurent.romary at inria.fr (Laurent Romary) Date: Wed, 22 Dec 2010 15:38:09 +0100 Subject: [tei-council] update on spring 2011 council meeting In-Reply-To: <4D0F894D.6030308@oucs.ox.ac.uk> References: <059B06B1-E1C1-453D-AD02-C7B44D3FCB43@inria.fr> <4D0F894D.6030308@oucs.ox.ac.uk> Message-ID: <CAFDF6BF-4327-485A-8A62-7579683BAFCA@inria.fr> Sorry for the delay in treating everything there.... but I would suggest to actually start implementing the outline you gave (with comments received) right away, i.e. using this meeting as a release preparation operation. That's what you mean? Before it would not be reasonable. We should take the corresponding time putting everything on tracks. Le 20 d?c. 10 ? 17:50, Lou Burnard a ?crit : > This is good news, but how should it affect our release cycle? > > I haven't seen much comment on my message of last week, but if we > agree > with what is stated there, we will be using this meeting to sign > off on > the next P5 release. Or are we planning to squeeze in a release > *before* it? > > > > wOn 20/12/10 15:21, Laurent Romary wrote: >> Dear Council members, >> >> Please reserve 11-13 April 2011 for a Council meeting at the Big Ten >> Center near Chicago O'Hare International Airport. We will have a >> one-day >> symposium on Monday followed by a two-day Council meeting on >> Tuesday and >> Wednesday. More details to follow! >> >> Laurent >> >> >> Laurent Romary >> INRIA& HUB-IDSL >> laurent.romary at inria.fr >> >> >> >> _______________________________________________ >> tei-council mailing list >> tei-council at lists.village.Virginia.EDU >> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Laurent Romary INRIA & HUB-IDSL laurent.romary at inria.fr From laurent.romary at inria.fr Wed Dec 22 09:41:37 2010 From: laurent.romary at inria.fr (Laurent Romary) Date: Wed, 22 Dec 2010 15:41:37 +0100 Subject: [tei-council] update on spring 2011 council meeting In-Reply-To: <A6164E5B-BCEE-49C5-92C9-DD253791CE7B@oucs.ox.ac.uk> References: <059B06B1-E1C1-453D-AD02-C7B44D3FCB43@inria.fr> <4D0F894D.6030308@oucs.ox.ac.uk> <A6164E5B-BCEE-49C5-92C9-DD253791CE7B@oucs.ox.ac.uk> Message-ID: <73EA6997-751A-480B-8450-438FCA6C9E61@inria.fr> I see you suggest a) - a transient strategy. What does the council think actually? Le 20 d?c. 10 ? 18:05, Sebastian Rahtz a ?crit : > > On 20 Dec 2010, at 16:50, Lou Burnard wrote: > >> This is good news, but how should it affect our release cycle? >> >> I haven't seen much comment on my message of last week, but if we >> agree >> with what is stated there, we will be using this meeting to sign >> off on >> the next P5 release. Or are we planning to squeeze in a release >> *before* it? > > I suppose there are three possibilities: > > a) we make a release in early feb using editorial resources owed > from last year, and implementing decisions > effectively made earlier this year (viz genetic stuff), and then > move to a May and November release > (if we can afford two meetings) > > b) we build up from now to a giant release in May > > c) we reject the premise of your message, and continue > to release 3 times a year with whatever is available, > using whatever time and resources anyone wants to commit > > if we could get anywhere with the current large set of requests > which are between 50% and 90% > discussed, I suggest that it would be well worth while doing a > february release under the Old > Dispensation, otherwise the burden will become too great. > -- > Sebastian Rahtz > Information and Support Group Manager > Oxford University Computing Services > 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 > > S?lo le pido a Dios > que el futuro no me sea indiferente > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Laurent Romary INRIA & HUB-IDSL laurent.romary at inria.fr From sebastian.rahtz at oucs.ox.ac.uk Wed Dec 22 09:49:42 2010 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Wed, 22 Dec 2010 14:49:42 +0000 Subject: [tei-council] update on spring 2011 council meeting In-Reply-To: <73EA6997-751A-480B-8450-438FCA6C9E61@inria.fr> References: <059B06B1-E1C1-453D-AD02-C7B44D3FCB43@inria.fr> <4D0F894D.6030308@oucs.ox.ac.uk> <A6164E5B-BCEE-49C5-92C9-DD253791CE7B@oucs.ox.ac.uk> <73EA6997-751A-480B-8450-438FCA6C9E61@inria.fr> Message-ID: <E9A5CD71-41FF-4EE4-A431-DB93C115D0E5@oucs.ox.ac.uk> On 22 Dec 2010, at 14:41, Laurent Romary wrote: > I see you suggest a) - a transient strategy. but only if we get some decisions made fairly rapidly. as things stand, we have no changes ready to roll for an end of Jan release. Assuming we're mostly now off work until early January, that would give us about 3 weeks in January to resolve the outstanding issues and then get the changes made. also, if you want to move to the meeting+release procedure, we'd have to answer the other issues raised in Lou's note? -- Sebastian Rahtz Information and Support Group Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From kevin.s.hawkins at ultraslavonic.info Mon Dec 27 20:51:01 2010 From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins) Date: Mon, 27 Dec 2010 20:51:01 -0500 Subject: [tei-council] how to encode a hyphen at the end of a line, column, or page when you are encoding hyphens In-Reply-To: <4D0F93EF.3060100@oucs.ox.ac.uk> References: <4D0E7288.6010006@ultraslavonic.info> <4D0F93EF.3060100@oucs.ox.ac.uk> Message-ID: <4D194285.8010804@ultraslavonic.info> Finally getting back to this! See below ... Lou Burnard wrote: >> I find "inWord" and "nobreak" entirely non-intuitive > > "inWord" seems fairly obvious to me. More significantly perhaps, it was > the value which the Epidockers agreed on after a fairly heated debate. My problem with "inWord" is that, without further explanation, I'm not sure whether it only applies to cases like: UTF-8 is a char- acter encoding for Unicode. or also to: This is not a run- on sentence. That is, I'm not sure whether we're talking about orthographic or lexical words. If some explanation can be added to P5 on this point, I'll probably be much happier with it. > Maybe "inToken" or "internal" ? Without further explanation, I find these opaque too. You see, "inWord" sounds like something internal to a word, and if that's true, how is "internal" different? >> I prefer these values for type=: >> >> * lexicalBoundary >> * noLexicalBoundary >> * uncertainLexicalBoundary >> > > I am not comfortable with "lexical" here, because where I come from > "lexical entries" may include multiple "tokens". If I treat "apple pie" > as a lexical entry, and there happens to be a <lb/> between the "apple" > and the "pie" I don't think I'd mark the <lb/> any different from any > other. I think we should stick with the idea that line-end hyphenation > (or not) is to do with simple minded orthographic tokens, not tricky > things like lexical items. Point taken. >> However, these may not be expressive enough for everything you'd like to >> encode. Paul Schaffner provided the following examples (which I've >> annotated): >> >> a) street<lb/>walker -- line break between components of a usually >> non-hyphenated compound > > Not sure what a "compound" is here. For me, the critical point is > whether elsewhere in this text I find, or expect to find, > "streetwalker" (in which case the <lb/> is "inWord") or "street walker" > (in which case it isn't). And if I don't want to take a stand either > way, then it is "undecided". By "compound", I meant a compound word, such as "policeman", "must-have", "ice cream", or "street walker". Aside from this, my recollection of Dublin has faded significantly, and I don't have any strong feelings on this except to give people clear instructions they can follow that tells them what to do. I think that's what Martin Mueller is looking for as well. Kevin From gabriel.bodard at kcl.ac.uk Fri Dec 31 08:30:49 2010 From: gabriel.bodard at kcl.ac.uk (Gabriel BODARD) Date: Fri, 31 Dec 2010 13:30:49 +0000 Subject: [tei-council] FR nuncles: new element tei:objectType Message-ID: <4D1DDB09.40904@kcl.ac.uk> Brett, Dot, Elena and I were tasked with nuncling SourceForge FR ticket #2811239 (http://bit.ly/fRK857). This was delayed a little, partly by the need to consult the Ontology SIG, but the results and our proposal are now available for Council's perusal in the comments on that ticket. In brief: "We therefore propose that Council create a new element tei:objectType, which have the same content model and attribute classes as tei:material." If Council members have any comments/objections, please share on the ticket. (I'm posting today, because I believe tomorrow Dot will no longer be on Council...) Best, Gabby -- Dr Gabriel BODARD (Research Associate in Digital Epigraphy) Centre for Computing in the Humanities King's College London 26-29 Drury Lane London WC2B 5RL Email: gabriel.bodard at kcl.ac.uk Tel: +44 (0)20 7848 1388 Fax: +44 (0)20 7848 2980 http://www.digitalclassicist.org/ http://www.currentepigraphy.org/ From mholmes at uvic.ca Fri Dec 31 13:48:15 2010 From: mholmes at uvic.ca (Martin Holmes) Date: Fri, 31 Dec 2010 10:48:15 -0800 Subject: [tei-council] FR nuncles: new element tei:objectType In-Reply-To: <4D1DDB09.40904@kcl.ac.uk> References: <4D1DDB09.40904@kcl.ac.uk> Message-ID: <4D1E256F.1000800@uvic.ca> I vote yes on this. Cheers, Martin On 10-12-31 05:30 AM, Gabriel BODARD wrote: > Brett, Dot, Elena and I were tasked with nuncling SourceForge FR ticket > #2811239 (http://bit.ly/fRK857). This was delayed a little, partly by > the need to consult the Ontology SIG, but the results and our proposal > are now available for Council's perusal in the comments on that ticket. > > In brief: > > "We therefore propose that Council create a new element tei:objectType, > which have the same content model and attribute classes as tei:material." > > If Council members have any comments/objections, please share on the ticket. > > (I'm posting today, because I believe tomorrow Dot will no longer be on > Council...) > > Best, > > Gabby >