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