From kevin.s.hawkins at ultraslavonic.info Tue Jan 3 19:30:25 2012 From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins) Date: Tue, 03 Jan 2012 19:30:25 -0500 Subject: [tei-council] namespaces and customization In-Reply-To: <9CDC2137-B222-4CAD-8AB5-9266A4CE050E@oucs.ox.ac.uk> References: <4EEE7722.7090407@ultraslavonic.info> <4EEEAF50.6080902@uvic.ca> <4EEEFCA9.4070007@oucs.ox.ac.uk> <9CDC2137-B222-4CAD-8AB5-9266A4CE050E@oucs.ox.ac.uk> Message-ID: <4F039DA1.6000503@ultraslavonic.info> On 12/19/11 4:11 AM, Sebastian Rahtz wrote: > > On 19 Dec 2011, at 08:58, James Cummings wrote: >> TEI, unless these attributes are in a non-TEI namespace. So you could >> add @my:type and @my:subtype to 'eg' and be perfectly TEI conformant, >> but adding att.typed to 'eg' is an unclean change and thus should be >> signalled by a namespace. > > > Amen to that. > > Why do want @type on anyway? consider using the excellent wrapper > for the job instead. I was just using the example given in P5 section 23.2.1.4 (#MDMDAL). I didn't want to confuse the matter by introducing a different use case. However, if @type on is nonsensical, then I think a revision of 32.2.1.4 is in order. From kevin.s.hawkins at ultraslavonic.info Tue Jan 3 19:41:27 2012 From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins) Date: Tue, 03 Jan 2012 19:41:27 -0500 Subject: [tei-council] namespaces and customization In-Reply-To: <2F747CFF-96AF-41AC-9EA3-A4A0127F63EB@inria.fr> References: <4EEE7722.7090407@ultraslavonic.info> <4EEEAF50.6080902@uvic.ca> <4EEEFCA9.4070007@oucs.ox.ac.uk> <2F747CFF-96AF-41AC-9EA3-A4A0127F63EB@inria.fr> Message-ID: <4F03A037.7050903@ultraslavonic.info> Like James, I read the intention of P5 that way: that you're supposed to use a namespace for anything that's not a pure subset. But it's not entirely clear to me that this was really the intention -- see my original message in this thread. I questioned this reading because I share Martin's questioning that every simple modification -- say, of adding a @type to an element -- requires moving it out of the TEI namespace. At the least I would like to see the intention clarified in P5, and at the most I would like us to revisit the intention. I'm not sure the intention is wrong, but I'm not sure it's right either. If we are revisiting the intention, it would be worth talking to Bryan Pytlik-Zillig and/or others who have done work on normalizing documents. I wonder whether they would find use of a new namespace useful or a hassle. On 12/19/11 4:05 AM, Laurent Romary wrote: > Still, I understand Martin's worry and if we think formally of cleanness as subsumption (along a relation is-more constrained-than) than adding eg to att.typed could be seen as clean (any processor with a TEI-all coverage would not have a problem with this, it would just not "see" the corresponding attributes). I let the future council chair to lead this discussion next year :-} > Laurent > > Le 19 d?c. 2011 ? 09:58, James Cummings a ?crit : > >> On 19/12/11 03:28, Martin Holmes wrote: >>> That's a very good question. Personally, I wouldn't have thought that >>> customizing an existing element would require moving it to a new >>> namespace -- unless you changed it beyond all recognition, but in that >>> case I would have thought giving it a new name would make more sense. >>> Surely just adding tei:eg to att,typed wouldn't require moving it out of >>> the tei: namespace? >> >> I think that is exactly the intention. If you add something to an >> element making it not a pure subset of the original element (conformant) >> or automatically able to be cleanly reversed (conformable) then it is no >> longer the TEI element as the TEI has defined it. Thus should be in a >> new namespace. You don't want to have something that purports to be a >> TEI 'eg' element but has lots of attributes which it doesn't have in the >> TEI, unless these attributes are in a non-TEI namespace. So you could >> add @my:type and @my:subtype to 'eg' and be perfectly TEI conformant, >> but adding att.typed to 'eg' is an unclean change and thus should be >> signalled by a namespace. >> >> I believe that was the thinking at least, >> >> -James >> >> >>> >>> Cheers, >>> Martin >>> >>> On 11-12-18 03:28 PM, Kevin Hawkins wrote: >>>> From reading chapter 23 of the Guidelines, I'm unclear on whether you >>>> are supposed to define a new namespace for every element or attribute >>>> affected by an unclean customization. I don't see it explicitly stated, >>>> but it sounds that way. For example, in section 23.2.1.5, is >>>> modified to add it to att.typed, but as I understand it, the element >>>> then moves into a new namespace (http://example.com/ns). So each >>>> instance of should actually be instead of >>>> . Is that right? >>>> >>>> Furthermore, I see this sentence in section 23.2.2, after a discussion >>>> of definining a namespace: >>>> >>>> "Similar methods may be used if a modification (clean or unclean) is >>>> made to the content model or some other aspect of an element, or if it >>>> declares a new element." >>>> >>>> In what cases would you define a new namespace for a clean customization >>>> of an element? >>>> >>>> --Kevin >> >> >> -- >> Dr James Cummings, InfoDev, >> Computing Services, University of Oxford >> -- >> tei-council mailing list >> tei-council at lists.village.Virginia.EDU >> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council >> >> PLEASE NOTE: postings to this list are publicly archived > > Laurent Romary > INRIA& HUB-IDSL > laurent.romary at inria.fr > > > From sebastian.rahtz at oucs.ox.ac.uk Wed Jan 4 05:44:47 2012 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Wed, 4 Jan 2012 10:44:47 +0000 Subject: [tei-council] namespaces and customization In-Reply-To: <4F03A037.7050903@ultraslavonic.info> References: <4EEE7722.7090407@ultraslavonic.info> <4EEEAF50.6080902@uvic.ca> <4EEEFCA9.4070007@oucs.ox.ac.uk> <2F747CFF-96AF-41AC-9EA3-A4A0127F63EB@inria.fr> <4F03A037.7050903@ultraslavonic.info> Message-ID: <979AA259-8B0D-4559-8189-190EC010F46E@oucs.ox.ac.uk> On 4 Jan 2012, at 00:41, Kevin Hawkins wrote: > At the least I would like to see the intention clarified in P5, and at > the most I would like us to revisit the intention. I'm not sure the > intention is wrong, but I'm not sure it's right either. If we are > revisiting the intention, it would be worth talking to Bryan > Pytlik-Zillig and/or others who have done work on normalizing documents. > I wonder whether they would find use of a new namespace useful or a > hassle. surely large-scale normalization projects such as that which B P-Z works on should be the last to make casual modifications to TEI, however simple? they have the time and the resource to do it right, ie work out with the TEI what the best way to work is, and to get changes in the TEI if needed. As TCP is doing now (belatedly, sorry, Paul and Rebecca!). -- Stormageddon Rahtz Head of Information and Support Group, Oxford University Computing Services 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 Jan 4 05:49:05 2012 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Wed, 4 Jan 2012 10:49:05 +0000 Subject: [tei-council] namespaces and customization In-Reply-To: <4F039DA1.6000503@ultraslavonic.info> References: <4EEE7722.7090407@ultraslavonic.info> <4EEEAF50.6080902@uvic.ca> <4EEEFCA9.4070007@oucs.ox.ac.uk> <9CDC2137-B222-4CAD-8AB5-9266A4CE050E@oucs.ox.ac.uk> <4F039DA1.6000503@ultraslavonic.info> Message-ID: <07238135-C143-48A2-9A26-CA7586D7F090@oucs.ox.ac.uk> On 4 Jan 2012, at 00:30, Kevin Hawkins wrote: > I was just using the example given in P5 section 23.2.1.4 (#MDMDAL). I > didn't want to confuse the matter by introducing a different use case. > > However, if @type on is nonsensical, then I think a revision of > 32.2.1.4 is in order. I looked at 33.2.1 today, and see that the relevant example is which is a bit worrying, as a) it does not work, and b) is probably barking up the wrong tree. do we really think we can move to a different namespace like this, in change mode? but the ostensible reading there _does_ say that the changed will not be in the TEI namespace.... I am looking to see why it does not work. -- Stormageddon Rahtz Head of Information and Support Group, Oxford University Computing Services 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 Jan 4 05:53:47 2012 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Wed, 4 Jan 2012 10:53:47 +0000 Subject: [tei-council] namespaces and customization In-Reply-To: <07238135-C143-48A2-9A26-CA7586D7F090@oucs.ox.ac.uk> References: <4EEE7722.7090407@ultraslavonic.info> <4EEEAF50.6080902@uvic.ca> <4EEEFCA9.4070007@oucs.ox.ac.uk> <9CDC2137-B222-4CAD-8AB5-9266A4CE050E@oucs.ox.ac.uk> <4F039DA1.6000503@ultraslavonic.info> <07238135-C143-48A2-9A26-CA7586D7F090@oucs.ox.ac.uk> Message-ID: On 4 Jan 2012, at 10:49, Sebastian Rahtz wrote: > I looked at 33.2.1 today, and see that the relevant example is > > ident="eg" > module="tagdocs" > mode="change" > ns="http://example.com/ns"> > > > > this is not, I now understand, doing what it might appear. I claim it says that "the element which is in the namespace http://example.com/ns is to changed". NOT " the element is to be changed to appear in the namespace http://example.com/ns". Big difference. Do others agree that this is how that @ns should be read? its now I have implemented it at least. -- Stormageddon Rahtz Head of Information and Support Group, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From laurent.romary at inria.fr Wed Jan 4 06:10:48 2012 From: laurent.romary at inria.fr (Laurent Romary) Date: Wed, 4 Jan 2012 12:10:48 +0100 Subject: [tei-council] Au revoir! Message-ID: Hi there, This is 4 days overdue, but I need to leave now ;-) (David, can you plug me out?) Many, many thanks to everyone for the excellent work carried out over the last 4 years and in particular for all the things I have learnt in your presence. The most enriching experience ever... Laurent From lou.burnard at retired.ox.ac.uk Wed Jan 4 06:16:06 2012 From: lou.burnard at retired.ox.ac.uk (Lou Burnard) Date: Wed, 04 Jan 2012 11:16:06 +0000 Subject: [tei-council] namespaces and customization In-Reply-To: References: <4EEE7722.7090407@ultraslavonic.info> <4EEEAF50.6080902@uvic.ca> <4EEEFCA9.4070007@oucs.ox.ac.uk> <9CDC2137-B222-4CAD-8AB5-9266A4CE050E@oucs.ox.ac.uk> <4F039DA1.6000503@ultraslavonic.info> <07238135-C143-48A2-9A26-CA7586D7F090@oucs.ox.ac.uk> Message-ID: <4F0434F6.9080904@retired.ox.ac.uk> On 04/01/12 10:53, Sebastian Rahtz wrote: > > On 4 Jan 2012, at 10:49, Sebastian Rahtz wrote: > >> I looked at 33.2.1 today, and see that the relevant example is >> >> > ident="eg" >> module="tagdocs" >> mode="change" >> ns="http://example.com/ns"> >> >> >> >> > > > > this is not, I now understand, doing what it might appear. I claim > it says that "the element which is in the namespace http://example.com/ns > is to changed". NOT " the element is to be changed to appear in the > namespace http://example.com/ns". Big difference. > > Do others agree that this is how that @ns should be read? its now > I have implemented it at least. > Yes, I can see the logic of this, and I think you are probably right. However, it leaves us with an outstanding requirement: how do I say "this new element in this name space is cloned from an existing TEI element but has these modifications"? This is not an unreasonable requirement. We could say "tough, you have to copy the existing spec and tweak it" but that won't win us any friends. From sebastian.rahtz at oucs.ox.ac.uk Wed Jan 4 07:08:35 2012 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Wed, 4 Jan 2012 12:08:35 +0000 Subject: [tei-council] namespaces and customization In-Reply-To: <4F0434F6.9080904@retired.ox.ac.uk> References: <4EEE7722.7090407@ultraslavonic.info> <4EEEAF50.6080902@uvic.ca> <4EEEFCA9.4070007@oucs.ox.ac.uk> <9CDC2137-B222-4CAD-8AB5-9266A4CE050E@oucs.ox.ac.uk> <4F039DA1.6000503@ultraslavonic.info> <07238135-C143-48A2-9A26-CA7586D7F090@oucs.ox.ac.uk> <4F0434F6.9080904@retired.ox.ac.uk> Message-ID: <55D02CD2-121F-467E-9F9E-F3C29FE2FD97@oucs.ox.ac.uk> On 4 Jan 2012, at 11:16, Lou Burnard wrote: > However, it leaves us with an outstanding requirement: how do I say > "this new element in this name space is cloned from an existing TEI > element but has these modifications"? This is not an unreasonable > requirement. We could say "tough, you have to copy the existing spec and > tweak it" but that won't win us any friends. ah, now if we had a requirements document for ODD, we'd be in a lot stronger position. But lets make what we've got now internally consistent. If you agree with my interpretation of elementSpec/@ns, then the Gidlines example is very very misleading (not _wrong_, exactly...) which of us wrote that passage which confused Kevin? it talks about how to add an element to att.typed as an example, but fails to point out that this makes the doc non-TEI (or so some of us claim). -- Stormageddon Rahtz Head of Information and Support Group, Oxford University Computing Services 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 Jan 4 10:37:15 2012 From: dsewell at virginia.edu (David Sewell) Date: Wed, 4 Jan 2012 10:37:15 -0500 (EST) Subject: [tei-council] TEI Council webpage updated Message-ID: Dear Council members, I have updated the TEI Council page at http://www.tei-c.org/Activities/Council/index.xml to reflect the changes in membership for 2012. Could everyone please check their listing and send me any corrections (including the hyperlinks)? Also, for consistency, it would be preferable to provide a title + affiliation for everyone, so let me know how you would like to be listed (e.g.: "John Doe, Professor of Overlapping Hierarchies, University of Southern North Dakota at Hoople"). Thanks, David -- David Sewell, Editorial and Technical Manager ROTUNDA, The University of Virginia Press PO Box 400314, Charlottesville, VA 22904-4314 USA Email: dsewell at virginia.edu Tel: +1 434 924 9973 Web: http://rotunda.upress.virginia.edu/ From lou.burnard at retired.ox.ac.uk Thu Jan 5 14:44:30 2012 From: lou.burnard at retired.ox.ac.uk (Lou Burnard) Date: Thu, 05 Jan 2012 19:44:30 +0000 Subject: [tei-council] namespaces and customization In-Reply-To: <55D02CD2-121F-467E-9F9E-F3C29FE2FD97@oucs.ox.ac.uk> References: <4EEE7722.7090407@ultraslavonic.info> <4EEEAF50.6080902@uvic.ca> <4EEEFCA9.4070007@oucs.ox.ac.uk> <9CDC2137-B222-4CAD-8AB5-9266A4CE050E@oucs.ox.ac.uk> <4F039DA1.6000503@ultraslavonic.info> <07238135-C143-48A2-9A26-CA7586D7F090@oucs.ox.ac.uk> <4F0434F6.9080904@retired.ox.ac.uk> <55D02CD2-121F-467E-9F9E-F3C29FE2FD97@oucs.ox.ac.uk> Message-ID: <4F05FD9E.7080102@retired.ox.ac.uk> On 04/01/12 12:08, Sebastian Rahtz wrote: > > On 4 Jan 2012, at 11:16, Lou Burnard wrote: > >> However, it leaves us with an outstanding requirement: how do I say >> "this new element in this name space is cloned from an existing TEI >> element but has these modifications"? This is not an unreasonable >> requirement. We could say "tough, you have to copy the existing spec and >> tweak it" but that won't win us any friends. > > ah, now if we had a requirements document for ODD, > we'd be in a lot stronger position. I dont think you need much of a reqts doc to understand that people might reasonably want to use the TEI class system in this way But lets make what we've got now > internally consistent. If you agree with my interpretation of elementSpec/@ns, > then the Gidlines example is very very misleading (not _wrong_, exactly...) > Agree on that. But it *is* misleading -- unless you now also claim that the flopsy example (in #MDNS) is wrong, we have a situation where @ns means one thing when @mode="add" and another, quite different, thing when it doesnt. > which of us wrote that passage which confused Kevin? it talks > about how to add an element to att.typed as an example, but > fails to point out that this makes the doc non-TEI (or so some > of us claim). Who knows. Probably me, sigh, but I bet you had a hand in it too. From sebastian.rahtz at oucs.ox.ac.uk Thu Jan 5 14:59:02 2012 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Thu, 5 Jan 2012 19:59:02 +0000 Subject: [tei-council] namespaces and customization In-Reply-To: <4F05FD9E.7080102@retired.ox.ac.uk> References: <4EEE7722.7090407@ultraslavonic.info> <4EEEAF50.6080902@uvic.ca> <4EEEFCA9.4070007@oucs.ox.ac.uk> <9CDC2137-B222-4CAD-8AB5-9266A4CE050E@oucs.ox.ac.uk> <4F039DA1.6000503@ultraslavonic.info> <07238135-C143-48A2-9A26-CA7586D7F090@oucs.ox.ac.uk> <4F0434F6.9080904@retired.ox.ac.uk> <55D02CD2-121F-467E-9F9E-F3C29FE2FD97@oucs.ox.ac.uk> <4F05FD9E.7080102@retired.ox.ac.uk> Message-ID: <9B23E49F-89F9-4579-A76A-4FF43F1E28C2@oucs.ox.ac.uk> On 5 Jan 2012, at 19:44, Lou Burnard wrote: > > Agree on that. But it *is* misleading -- unless you now also claim that > the flopsy example (in #MDNS) is wrong, we have a situation where @ns > means one thing when @mode="add" and another, quite different, thing > when it doesnt. tricky. I don't see an easy way to resolve that. but I take consolation from the fact that no-one has noticed the problem so far as we know. -- Stormageddon Rahtz Head of Information and Support Group, Oxford University Computing Services 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 Fri Jan 6 21:26:29 2012 From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins) Date: Fri, 06 Jan 2012 21:26:29 -0500 Subject: [tei-council] namespaces and customization In-Reply-To: <979AA259-8B0D-4559-8189-190EC010F46E@oucs.ox.ac.uk> References: <4EEE7722.7090407@ultraslavonic.info> <4EEEAF50.6080902@uvic.ca> <4EEEFCA9.4070007@oucs.ox.ac.uk> <2F747CFF-96AF-41AC-9EA3-A4A0127F63EB@inria.fr> <4F03A037.7050903@ultraslavonic.info> <979AA259-8B0D-4559-8189-190EC010F46E@oucs.ox.ac.uk> Message-ID: <4F07AD55.3040009@ultraslavonic.info> On 1/4/12 5:44 AM, Sebastian Rahtz wrote: > > On 4 Jan 2012, at 00:41, Kevin Hawkins wrote: > >> At the least I would like to see the intention clarified in P5, and at >> the most I would like us to revisit the intention. I'm not sure the >> intention is wrong, but I'm not sure it's right either. If we are >> revisiting the intention, it would be worth talking to Bryan >> Pytlik-Zillig and/or others who have done work on normalizing documents. >> I wonder whether they would find use of a new namespace useful or a >> hassle. > > surely large-scale normalization projects such as that which B P-Z > works on should be the last to make casual modifications to TEI, however > simple? they have the time and the resource to do it right, ie work out > with the TEI what the best way to work is, and to get changes in the TEI > if needed. As TCP is doing now (belatedly, sorry, Paul and Rebecca!). What I meant is to suppose that Brian inherited a few sets of documents using a customization of the TEI. Some customized but used the TEI namespace for everything, whereas others created a new namespace for every non-subsetting customization. Which would be preferrable to someone normalizing these various sets of documents to do data mining across the sets? From kevin.s.hawkins at ultraslavonic.info Fri Jan 6 21:33:27 2012 From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins) Date: Fri, 06 Jan 2012 21:33:27 -0500 Subject: [tei-council] namespaces and customization In-Reply-To: References: <4EEE7722.7090407@ultraslavonic.info> <4EEEAF50.6080902@uvic.ca> <4EEEFCA9.4070007@oucs.ox.ac.uk> <9CDC2137-B222-4CAD-8AB5-9266A4CE050E@oucs.ox.ac.uk> <4F039DA1.6000503@ultraslavonic.info> <07238135-C143-48A2-9A26-CA7586D7F090@oucs.ox.ac.uk> Message-ID: <4F07AEF7.3050704@ultraslavonic.info> There's a few typos here, so I want to check that I'm understanding them correctly ... On 1/4/12 5:53 AM, Sebastian Rahtz wrote: > > On 4 Jan 2012, at 10:49, Sebastian Rahtz wrote: > >> I looked at 33.2.1 today, and see that the relevant example is >> >> > ident="eg" >> module="tagdocs" >> mode="change" >> ns="http://example.com/ns"> >> >> >> >> > > > > this is not, I now understand, doing what it might appear. I claim > it says that "the element which is in the namespace http://example.com/ns > is to changed". NOT " the element is to be changed to appear in the > namespace http://example.com/ns". Big difference. I think this should read "which is in the namespace http://example.com/ns is to BE changed". > Do others agree that this is how that @ns should be read? its now > I have implemented it at least. I also read it the first way, not the second. I think the second sentence should read "it's how I have implemented it at least". From mholmes at uvic.ca Mon Jan 9 08:55:01 2012 From: mholmes at uvic.ca (Martin Holmes) Date: Mon, 09 Jan 2012 05:55:01 -0800 Subject: [tei-council] Report on 2011 Message-ID: <4F0AF1B5.7030005@uvic.ca> Hi all, I guess we have to provide a Report on Current Work for 2011: It looks like this is usually presented to the board by the chair. James, are you going to do this, and if so, is there anything we can do to help? Cheers, Martin From dsewell at virginia.edu Mon Jan 9 09:11:47 2012 From: dsewell at virginia.edu (David Sewell) Date: Mon, 9 Jan 2012 09:11:47 -0500 (EST) Subject: [tei-council] Report on 2011 In-Reply-To: <4F0AF1B5.7030005@uvic.ca> References: <4F0AF1B5.7030005@uvic.ca> Message-ID: Actually, Dan O'Donnell has provided the slides from the report presented at the Members Meeting: http://www.tei-c.org/Membership/Meetings/2011/BusinessMeeting_Hosts.pdf I neglected to add the link to it from the Reports page. I will do that now. David On Mon, 9 Jan 2012, Martin Holmes wrote: > Hi all, > > I guess we have to provide a Report on Current Work for 2011: > > > > It looks like this is usually presented to the board by the chair. > James, are you going to do this, and if so, is there anything we can do > to help? > > Cheers, > Martin > -- David Sewell, Editorial and Technical Manager ROTUNDA, The University of Virginia Press PO Box 400314, Charlottesville, VA 22904-4314 USA Email: dsewell at virginia.edu Tel: +1 434 924 9973 Web: http://rotunda.upress.virginia.edu/ From lou.burnard at retired.ox.ac.uk Mon Jan 9 09:13:16 2012 From: lou.burnard at retired.ox.ac.uk (Lou Burnard) Date: Mon, 09 Jan 2012 14:13:16 +0000 Subject: [tei-council] Report on 2011 In-Reply-To: References: <4F0AF1B5.7030005@uvic.ca> Message-ID: <4F0AF5FC.1030800@retired.ox.ac.uk> But that's the Board report, not the Council report, shirley? On 09/01/12 14:11, David Sewell wrote: > Actually, Dan O'Donnell has provided the slides from the report presented at the > Members Meeting: > > http://www.tei-c.org/Membership/Meetings/2011/BusinessMeeting_Hosts.pdf > > I neglected to add the link to it from the Reports page. I will do that now. > > David > > On Mon, 9 Jan 2012, Martin Holmes wrote: > >> Hi all, >> >> I guess we have to provide a Report on Current Work for 2011: >> >> >> >> It looks like this is usually presented to the board by the chair. >> James, are you going to do this, and if so, is there anything we can do >> to help? >> >> Cheers, >> Martin >> > From dsewell at virginia.edu Mon Jan 9 09:17:02 2012 From: dsewell at virginia.edu (David Sewell) Date: Mon, 9 Jan 2012 09:17:02 -0500 (EST) Subject: [tei-council] Report on 2011 In-Reply-To: <4F0AF5FC.1030800@retired.ox.ac.uk> References: <4F0AF1B5.7030005@uvic.ca> <4F0AF5FC.1030800@retired.ox.ac.uk> Message-ID: Sorry, coffee has not kicked in yet this morning. The proper link is to http://www.tei-c.org/Membership/Meetings/2011/TEICouncilReport2011.pdf and it is now up on the Reports page http://www.tei-c.org/Activities/Council/Reports/ On Mon, 9 Jan 2012, Lou Burnard wrote: > But that's the Board report, not the Council report, shirley? > > On 09/01/12 14:11, David Sewell wrote: >> Actually, Dan O'Donnell has provided the slides from the report presented at the >> Members Meeting: >> >> http://www.tei-c.org/Membership/Meetings/2011/BusinessMeeting_Hosts.pdf >> >> I neglected to add the link to it from the Reports page. I will do that now. >> >> David >> >> On Mon, 9 Jan 2012, Martin Holmes wrote: >> >>> Hi all, >>> >>> I guess we have to provide a Report on Current Work for 2011: >>> >>> >>> >>> It looks like this is usually presented to the board by the chair. >>> James, are you going to do this, and if so, is there anything we can do >>> to help? >>> >>> Cheers, >>> Martin >>> >> > > -- David Sewell, Editorial and Technical Manager ROTUNDA, The University of Virginia Press PO Box 400314, Charlottesville, VA 22904-4314 USA Email: dsewell at virginia.edu Tel: +1 434 924 9973 Web: http://rotunda.upress.virginia.edu/ From gabriel.bodard at kcl.ac.uk Tue Jan 10 11:30:30 2012 From: gabriel.bodard at kcl.ac.uk (Gabriel Bodard) Date: Tue, 10 Jan 2012 16:30:30 +0000 Subject: [tei-council] Bug: make geo declaring Message-ID: <4F0C67A6.4010400@kcl.ac.uk> Dear Councillors, A reminder of a bug ticket that was submitted last November (just too late to make it into the last release, apparently), suggesting that be added to att.declaring: http://purl.org/TEI/BUGS/3440771 If everyone is agreeable, I'm happy to go ahead and make this change in the source. (I know it won't be released for a while now, but if I do it now we won't forget in future.) Best, Gabby -- Dr Gabriel BODARD (Research Associate in Digital Epigraphy) Department of Digital 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 Jan 10 18:25:00 2012 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Tue, 10 Jan 2012 23:25:00 +0000 Subject: [tei-council] TEI Technical Council Budget 2012 Message-ID: <4F0CC8CC.7070700@oucs.ox.ac.uk> Dear TEI Technical Council, This afternoon at the TEI Board teleconference our proposed budget for two council meetings got (as far as I could tell) unanimous support. In fact it was decided that (as had been proposed at the w?rzburg meeting) that Council would be given a $38K USD budget, with the understanding that around ~22K of this would be spent on travel and subsistence for the two Council meetings as we had budgeted, and that we/I would prepare a more detailed budget for what we wanted to spend the rest on. This is good news in that we now know for sure that our two planned meetings will go ahead (and we can start making more arrangements) and that we should be able to funding some additional development work or meetings. The 'other potential activities' that I very vaguely described were: a) Paying for some additional people to attend the Ann Arbor meeting specifically if we needed more input on ECCO/EEBO-TCP conversion/rationalization (I was thinking MartinM or BrianPZ but have not approached them), but I wonder if this is still as important as we've solved a lot of the problems. b) Subsidising a couple extra nights of hotel for several people to participate in a workshop designing improvements for ODD3 after DH2012. (I have put in a Future of ODD panel session that includes Lou Burnard, Syd Baumann, Bertrand Gaiffe, Sebastian Rahtz, and Laurent Romary/Piotr Ba?ski). If that is accepted then we'd try to get these and some others as well and offer to pay a couple nights hotel (if needed) to keep them on a couple days and maybe room costs if we can't get one free. c) Web-Roma redevelopment bounty. This was the idea that we need a new community-developed web-roma (not developed/maintained by Oxford) and that we might put some money towards encouraging/kickstarting a group in creating this. d) Another idea was to try to fund an entirely new processing implementation of ODD2+ that is completely independent of the existing XSLT. But this is problematic to budget. e) General code bounty: We could come up with a list of much smaller development or other technical projects that are much more easily implemented and sufficiently useful to the TEI-C or Community. f) Any other ideas? I'm quite in favour of b) and c) as I believe these respectively lead to the future development of the TEI and its ongoing sustainability. Thoughts? -James -- Dr James Cummings, InfoDev, Computing Services, University of Oxford From sebastian.rahtz at oucs.ox.ac.uk Wed Jan 11 12:13:45 2012 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Wed, 11 Jan 2012 17:13:45 +0000 Subject: [tei-council] adblock / msad Message-ID: assuming you all read TEI-L. maybe we should rewrite all the ID/IDREFS in generated HTML to put "tei_" in front of them? -- Stormageddon Rahtz Head of Information and Support Group Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From lou.burnard at retired.ox.ac.uk Wed Jan 11 13:53:38 2012 From: lou.burnard at retired.ox.ac.uk (Lou Burnard) Date: Wed, 11 Jan 2012 18:53:38 +0000 Subject: [tei-council] adblock / msad In-Reply-To: References: Message-ID: <4F0DDAB2.5010503@retired.ox.ac.uk> On 11/01/12 17:13, Sebastian Rahtz wrote: > assuming you all read TEI-L. > > maybe we should rewrite all the ID/IDREFS in generated HTML to put "tei_" in front of them? > -- Sounds like a very simple and effective solution to me. I say go for it, Stormy. (I don't remember who it was said that the ID values in the XML source followed a consistent pattern, but I'll have some of what they've been drinking.) From syeates at gmail.com Wed Jan 11 14:08:22 2012 From: syeates at gmail.com (Stuart A. Yeates) Date: Thu, 12 Jan 2012 08:08:22 +1300 Subject: [tei-council] adblock / msad In-Reply-To: <4F0DDAB2.5010503@retired.ox.ac.uk> References: <4F0DDAB2.5010503@retired.ox.ac.uk> Message-ID: On Thu, Jan 12, 2012 at 7:53 AM, Lou Burnard wrote: > On 11/01/12 17:13, Sebastian Rahtz wrote: >> assuming you all read TEI-L. >> >> maybe we should rewrite all the ID/IDREFS in generated HTML to put "tei_" in front of them? >> -- > > Sounds like a very simple and effective solution to me. I say go for it, > Stormy. > > > (I don't remember who it was said that the ID values in the XML source > followed a consistent pattern, but I'll have some of what they've been > drinking.) Sounds good to me. cheers stuart From James.Cummings at oucs.ox.ac.uk Wed Jan 11 17:09:20 2012 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Wed, 11 Jan 2012 22:09:20 +0000 Subject: [tei-council] adblock / msad In-Reply-To: References: <4F0DDAB2.5010503@retired.ox.ac.uk> Message-ID: <4F0E0890.40706@oucs.ox.ac.uk> As Martin has posted on TEI-L the AdBlock filter creators seem to be responsive in changing the filter. However, it might be a good idea to do this in any case. However, my devil's advocate caveat still stands as a warning: We would be 'breaking' an awful lot of existing URLs that people might have bookmarked or referenced in publications. 'Breaking' because they'll still get the page, just not the right place on it. -James On 11/01/12 19:08, Stuart A. Yeates wrote: > On Thu, Jan 12, 2012 at 7:53 AM, Lou Burnard > wrote: >> On 11/01/12 17:13, Sebastian Rahtz wrote: >>> assuming you all read TEI-L. >>> >>> maybe we should rewrite all the ID/IDREFS in generated HTML to put "tei_" in front of them? >>> -- >> >> Sounds like a very simple and effective solution to me. I say go for it, >> Stormy. >> >> >> (I don't remember who it was said that the ID values in the XML source >> followed a consistent pattern, but I'll have some of what they've been >> drinking.) > > Sounds good to me. > > cheers > stuart -- Dr James Cummings, InfoDev, Computing Services, University of Oxford From kevin.s.hawkins at ultraslavonic.info Wed Jan 11 19:18:21 2012 From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins) Date: Wed, 11 Jan 2012 19:18:21 -0500 Subject: [tei-council] TEI Technical Council Budget 2012 In-Reply-To: <4F0CC8CC.7070700@oucs.ox.ac.uk> References: <4F0CC8CC.7070700@oucs.ox.ac.uk> Message-ID: <4F0E26CD.1000101@ultraslavonic.info> James, Thanks for the update. My thoughts ... On 1/10/12 6:25 PM, James Cummings wrote: > a) Paying for some additional people to attend the Ann Arbor meeting > specifically if we needed more input on ECCO/EEBO-TCP > conversion/rationalization (I was thinking MartinM or BrianPZ but have > not approached them), but I wonder if this is still as important as > we've solved a lot of the problems. My recollection is that we did indeed solve most of the problems. Even if there are outstanding issues about rationalization that Paul Schaffner (who will be attending as a Council member) can't answer for us, I imagine we could get Martin Mueller or Brian Pytlik Zillig on the phone or Skype to answer those questions. They're both only one time zone away from Ann Arbor, so I can't imagine this will be difficult. > b) Subsidising a couple extra nights of hotel for several people to > participate in a workshop designing improvements for ODD3 after DH2012. > (I have put in a Future of ODD panel session that includes Lou Burnard, > Syd Baumann, Bertrand Gaiffe, Sebastian Rahtz, and Laurent Romary/Piotr > Ba?ski). If that is accepted then we'd try to get these and some others > as well and offer to pay a couple nights hotel (if needed) to keep them > on a couple days and maybe room costs if we can't get one free. > > c) Web-Roma redevelopment bounty. This was the idea that we need a new > community-developed web-roma (not developed/maintained by Oxford) and > that we might put some money towards encouraging/kickstarting a group in > creating this. Like James, I am most interested in (b) and (c), but I am more interested in (c). I believe that the TEI-C should better support the current ODD framework before we jump into developing another framework. > d) Another idea was to try to fund an entirely new processing > implementation of ODD2+ that is completely independent of the existing > XSLT. But this is problematic to budget. You mean fund a complete rewrite of Roma rather than a better Roma, as in (c)? > e) General code bounty: We could come up with a list of much smaller > development or other technical projects that are much more easily > implemented and sufficiently useful to the TEI-C or Community. We might suggest a few ideas, but opening this to the community for suggestions would be good too. Kind of like the TEI community grants. Of course, with the community grants already out there, there might not really be a need to do (e) at all. --Kevin From bansp at o2.pl Thu Jan 12 03:21:09 2012 From: bansp at o2.pl (=?ISO-8859-2?Q?Piotr_Ba=F1ski?=) Date: Thu, 12 Jan 2012 09:21:09 +0100 Subject: [tei-council] TEI Technical Council Budget 2012 In-Reply-To: <4F0E26CD.1000101@ultraslavonic.info> References: <4F0CC8CC.7070700@oucs.ox.ac.uk> <4F0E26CD.1000101@ultraslavonic.info> Message-ID: <4F0E97F5.20601@o2.pl> Just to add my 2 cents on top of this: * +1 for (c), * ODD2+ funding may present a clearer picture after Hamburg, if we ever learn about DH's qualification results. P. On 12/01/12 01:18, Kevin Hawkins wrote: > James, > > Thanks for the update. My thoughts ... > > On 1/10/12 6:25 PM, James Cummings wrote: >> a) Paying for some additional people to attend the Ann Arbor meeting >> specifically if we needed more input on ECCO/EEBO-TCP >> conversion/rationalization (I was thinking MartinM or BrianPZ but have >> not approached them), but I wonder if this is still as important as >> we've solved a lot of the problems. > > My recollection is that we did indeed solve most of the problems. Even > if there are outstanding issues about rationalization that Paul > Schaffner (who will be attending as a Council member) can't answer for > us, I imagine we could get Martin Mueller or Brian Pytlik Zillig on the > phone or Skype to answer those questions. They're both only one time > zone away from Ann Arbor, so I can't imagine this will be difficult. > >> b) Subsidising a couple extra nights of hotel for several people to >> participate in a workshop designing improvements for ODD3 after DH2012. >> (I have put in a Future of ODD panel session that includes Lou Burnard, >> Syd Baumann, Bertrand Gaiffe, Sebastian Rahtz, and Laurent Romary/Piotr >> Ba?ski). If that is accepted then we'd try to get these and some others >> as well and offer to pay a couple nights hotel (if needed) to keep them >> on a couple days and maybe room costs if we can't get one free. >> >> c) Web-Roma redevelopment bounty. This was the idea that we need a new >> community-developed web-roma (not developed/maintained by Oxford) and >> that we might put some money towards encouraging/kickstarting a group in >> creating this. > > Like James, I am most interested in (b) and (c), but I am more > interested in (c). I believe that the TEI-C should better support the > current ODD framework before we jump into developing another framework. > >> d) Another idea was to try to fund an entirely new processing >> implementation of ODD2+ that is completely independent of the existing >> XSLT. But this is problematic to budget. > > You mean fund a complete rewrite of Roma rather than a better Roma, as > in (c)? > >> e) General code bounty: We could come up with a list of much smaller >> development or other technical projects that are much more easily >> implemented and sufficiently useful to the TEI-C or Community. > > We might suggest a few ideas, but opening this to the community for > suggestions would be good too. Kind of like the TEI community grants. > Of course, with the community grants already out there, there might not > really be a need to do (e) at all. > > --Kevin From sebastian.rahtz at oucs.ox.ac.uk Thu Jan 12 04:12:23 2012 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Thu, 12 Jan 2012 09:12:23 +0000 Subject: [tei-council] TEI Technical Council Budget 2012 In-Reply-To: <4F0E26CD.1000101@ultraslavonic.info> References: <4F0CC8CC.7070700@oucs.ox.ac.uk> <4F0E26CD.1000101@ultraslavonic.info> Message-ID: <2CADFB7D-C525-40A8-9012-B32A52E4A5E8@oucs.ox.ac.uk> On 12 Jan 2012, at 00:18, Kevin Hawkins wrote: > My recollection is that we did indeed solve most of the problems. Even > if there are outstanding issues about rationalization that Paul > Schaffner (who will be attending as a Council member) can't answer for > us, I imagine we could get Martin Mueller or Brian Pytlik Zillig on the > phone or Skype to answer those questions. They're both only one time > zone away from Ann Arbor, so I can't imagine this will be difficult. I agree, it probably doesnt need a full-scale session with MM and BPZ; but we really should revisit the issue. There are certainly unsolved parts of the equation - is one of those. Asking MM/BPZ to test 2.0.1 on their conversions now would be important. >> d) Another idea was to try to fund an entirely new processing >> implementation of ODD2+ that is completely independent of the existing >> XSLT. But this is problematic to budget. > > You mean fund a complete rewrite of Roma rather than a better Roma, as > in ?? We need to agree on terminology here. I think of "roma" as meaning "user interface to ODD, with facilities to create and edit and odd, and call ODD -> XX processing". Note the "call" there. All the Roma-ish tools we have now (Roma web, command-line, oxgarage, oxygen) all call the same underlying XSLT library. James' (d) is a rewrite of that backend library, but his c) is a new Roma web (probably). personally, I go for c), on the grounds that Web Roma is _definitely_ incomplete and has errors, and definitely has real users, now. -- Stormageddon Rahtz Head of Information and Support Group Oxford University Computing Services 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 Thu Jan 12 06:44:50 2012 From: gabriel.bodard at kcl.ac.uk (Gabriel Bodard) Date: Thu, 12 Jan 2012 11:44:50 +0000 Subject: [tei-council] Bug: make geo declaring In-Reply-To: <4F0C67A6.4010400@kcl.ac.uk> References: <4F0C67A6.4010400@kcl.ac.uk> Message-ID: <4F0EC7B2.4020002@kcl.ac.uk> There's been a little bit of discussion on the ticket, and it looks like we're more or less agreed that we could reasonable make both and members of att.declaring. I'll implement this today if no one objects, but I thought I'd ask here if anyone wants to weigh in on the minor debate between Martin and myself first... Cheers, Gabby On 2012-01-10 16:30, Gabriel Bodard wrote: > Dear Councillors, > > A reminder of a bug ticket that was submitted last November (just too > late to make it into the last release, apparently), suggesting that > be added to att.declaring: > > http://purl.org/TEI/BUGS/3440771 > > If everyone is agreeable, I'm happy to go ahead and make this change in > the source. (I know it won't be released for a while now, but if I do it > now we won't forget in future.) > > Best, > > Gabby > -- Dr Gabriel BODARD (Research Associate in Digital Epigraphy) Department of Digital 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 Thu Jan 12 08:17:57 2012 From: mholmes at uvic.ca (Martin Holmes) Date: Thu, 12 Jan 2012 05:17:57 -0800 Subject: [tei-council] TEI Technical Council Budget 2012 In-Reply-To: <4F0E97F5.20601@o2.pl> References: <4F0CC8CC.7070700@oucs.ox.ac.uk> <4F0E26CD.1000101@ultraslavonic.info> <4F0E97F5.20601@o2.pl> Message-ID: <4F0EDD85.2000308@uvic.ca> +1 for (c) too. b) would be nice if I were going to DH2012, but I'm not (no funds); still, I should be able to attend virtually. I think I like the idea of a code bounty too. One possible pilot for this is the XPointer implementations that our little XPointer group is talking about, although we don't seem to be able to agree on how or where such implementations might be done (XInclude processor? Pure XSLT? Saxon?). Cheers, Martin On 12-01-12 12:21 AM, Piotr Ba?ski wrote: > Just to add my 2 cents on top of this: > > * +1 for (c), > * ODD2+ funding may present a clearer picture after Hamburg, if we ever > learn about DH's qualification results. > > P. > > On 12/01/12 01:18, Kevin Hawkins wrote: >> James, >> >> Thanks for the update. My thoughts ... >> >> On 1/10/12 6:25 PM, James Cummings wrote: >>> a) Paying for some additional people to attend the Ann Arbor meeting >>> specifically if we needed more input on ECCO/EEBO-TCP >>> conversion/rationalization (I was thinking MartinM or BrianPZ but have >>> not approached them), but I wonder if this is still as important as >>> we've solved a lot of the problems. >> >> My recollection is that we did indeed solve most of the problems. Even >> if there are outstanding issues about rationalization that Paul >> Schaffner (who will be attending as a Council member) can't answer for >> us, I imagine we could get Martin Mueller or Brian Pytlik Zillig on the >> phone or Skype to answer those questions. They're both only one time >> zone away from Ann Arbor, so I can't imagine this will be difficult. >> >>> b) Subsidising a couple extra nights of hotel for several people to >>> participate in a workshop designing improvements for ODD3 after DH2012. >>> (I have put in a Future of ODD panel session that includes Lou Burnard, >>> Syd Baumann, Bertrand Gaiffe, Sebastian Rahtz, and Laurent Romary/Piotr >>> Ba?ski). If that is accepted then we'd try to get these and some others >>> as well and offer to pay a couple nights hotel (if needed) to keep them >>> on a couple days and maybe room costs if we can't get one free. >>> >>> c) Web-Roma redevelopment bounty. This was the idea that we need a new >>> community-developed web-roma (not developed/maintained by Oxford) and >>> that we might put some money towards encouraging/kickstarting a group in >>> creating this. >> >> Like James, I am most interested in (b) and (c), but I am more >> interested in (c). I believe that the TEI-C should better support the >> current ODD framework before we jump into developing another framework. >> >>> d) Another idea was to try to fund an entirely new processing >>> implementation of ODD2+ that is completely independent of the existing >>> XSLT. But this is problematic to budget. >> >> You mean fund a complete rewrite of Roma rather than a better Roma, as >> in (c)? >> >>> e) General code bounty: We could come up with a list of much smaller >>> development or other technical projects that are much more easily >>> implemented and sufficiently useful to the TEI-C or Community. >> >> We might suggest a few ideas, but opening this to the community for >> suggestions would be good too. Kind of like the TEI community grants. >> Of course, with the community grants already out there, there might not >> really be a need to do (e) at all. >> >> --Kevin > From mholmes at uvic.ca Thu Jan 12 08:21:33 2012 From: mholmes at uvic.ca (Martin Holmes) Date: Thu, 12 Jan 2012 05:21:33 -0800 Subject: [tei-council] TEI Technical Council Budget 2012 In-Reply-To: <2CADFB7D-C525-40A8-9012-B32A52E4A5E8@oucs.ox.ac.uk> References: <4F0CC8CC.7070700@oucs.ox.ac.uk> <4F0E26CD.1000101@ultraslavonic.info> <2CADFB7D-C525-40A8-9012-B32A52E4A5E8@oucs.ox.ac.uk> Message-ID: <4F0EDE5D.7030901@uvic.ca> > We need to agree on terminology here. I think of "roma" as meaning > "user interface to ODD, with facilities to create and edit and odd, and > call ODD -> XX processing". Note the "call" there. All the Roma-ish tools we > have now (Roma web, command-line, oxgarage, oxygen) all call the same > underlying XSLT library. James' (d) is a rewrite of that backend library, but his > c) is a new Roma web (probably). > > personally, I go for c), on the grounds that Web Roma is _definitely_ incomplete > and has errors, and definitely has real users, now. That's exactly how I feel. Web Roma is most people's interface to TEI, when they first start to create their own project (as opposed to working on someone else's, where the schema is already done). The slicker and more reliable it is, the better the initial experience, and the more positive people feel towards using TEI. Cheers, Martin On 12-01-12 01:12 AM, Sebastian Rahtz wrote: > > On 12 Jan 2012, at 00:18, Kevin Hawkins wrote: >> My recollection is that we did indeed solve most of the problems. Even >> if there are outstanding issues about rationalization that Paul >> Schaffner (who will be attending as a Council member) can't answer for >> us, I imagine we could get Martin Mueller or Brian Pytlik Zillig on the >> phone or Skype to answer those questions. They're both only one time >> zone away from Ann Arbor, so I can't imagine this will be difficult. > > I agree, it probably doesnt need a full-scale session with MM and BPZ; > but we really should revisit the issue. There are certainly unsolved parts of the > equation - is one of those. Asking MM/BPZ to test 2.0.1 on their > conversions now would be important. > >>> d) Another idea was to try to fund an entirely new processing >>> implementation of ODD2+ that is completely independent of the existing >>> XSLT. But this is problematic to budget. >> >> You mean fund a complete rewrite of Roma rather than a better Roma, as >> in ?? > > We need to agree on terminology here. I think of "roma" as meaning > "user interface to ODD, with facilities to create and edit and odd, and > call ODD -> XX processing". Note the "call" there. All the Roma-ish tools we > have now (Roma web, command-line, oxgarage, oxygen) all call the same > underlying XSLT library. James' (d) is a rewrite of that backend library, but his > c) is a new Roma web (probably). > > personally, I go for c), on the grounds that Web Roma is _definitely_ incomplete > and has errors, and definitely has real users, now. > > -- > Stormageddon Rahtz > Head of Information and Support Group > Oxford University Computing Services > 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 Jan 12 12:39:33 2012 From: mholmes at uvic.ca (Martin Holmes) Date: Thu, 12 Jan 2012 09:39:33 -0800 Subject: [tei-council] version 2.0.1 p5subset.xml states "edition 2.0.0" In-Reply-To: <48F7E21F-4B77-4865-AB90-47F6AA73ADBF@edirom.de> References: <48F7E21F-4B77-4865-AB90-47F6AA73ADBF@edirom.de> Message-ID: <4F0F1AD5.4070101@uvic.ca> Hi all, I think we need to release a 2.0.2 soon, during which we again run through the instructions, after adding the tagging instruction. Should we do a quick trawl through the tickets and decide which ones might be polished off quickly without controversy? Can I be the one to go through the release steps this time? Cheers, Martin On 12-01-12 08:27 AM, Peter Stadler wrote: > Dear geeks again, > > again wondering: just downloaded the current release 2.0.1 from sourceforge (tei-2.0.1.zip) and the editionStmt at tei-2.0.1/xml/tei/p5subset.xml reads2.0.0 Last updated on16th December 2011. > > Does that mean it wasn't updated at all or is just the editionStmt wrong? > > Many thanks again > Peter > -- Martin Holmes University of Victoria Humanities Computing and Media Centre (mholmes at uvic.ca) From sebastian.rahtz at oucs.ox.ac.uk Thu Jan 12 12:44:52 2012 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Thu, 12 Jan 2012 17:44:52 +0000 Subject: [tei-council] version 2.0.1 p5subset.xml states "edition 2.0.0" In-Reply-To: <4F0F1AD5.4070101@uvic.ca> References: <48F7E21F-4B77-4865-AB90-47F6AA73ADBF@edirom.de> <4F0F1AD5.4070101@uvic.ca> Message-ID: <72C9A5F5-636A-4825-8F4D-61FB296317BF@oucs.ox.ac.uk> On 12 Jan 2012, at 17:39, Martin Holmes wrote: > Hi all, > > I think we need to release a 2.0.2 soon, during which we again run > through the instructions, after adding the tagging instruction. I have a script maketag which says svn cp -m "create tag of P5 release $1" -r "{$2}" \ https://tei.svn.sourceforge.net/svnroot/tei/trunk/P5 \ https://tei.svn.sourceforge.net/svnroot/tei/tags/P5_release_$1/ as in sh ../maketag 2.0.1 2011-12-22 for retrospective addition of tags. better done on the way without the -r > Should > we do a quick trawl through the tickets and decide which ones might be > polished off quickly without controversy? if they change the content model, we'd go to 2.1.0?. > > Can I be the one to go through the release steps this time? we have not resolved the Debian issue yet. the sticking point is updating repo on a Fedora box -- Stormageddon Rahtz Head of Information and Support Group Oxford University Computing Services 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 Thu Jan 12 12:45:12 2012 From: gabriel.bodard at kcl.ac.uk (Gabriel Bodard) Date: Thu, 12 Jan 2012 17:45:12 +0000 Subject: [tei-council] version 2.0.1 p5subset.xml states "edition 2.0.0" In-Reply-To: <4F0F1AD5.4070101@uvic.ca> References: <48F7E21F-4B77-4865-AB90-47F6AA73ADBF@edirom.de> <4F0F1AD5.4070101@uvic.ca> Message-ID: <4F0F1C28.9050608@kcl.ac.uk> In that case, could I slip geo -> att.declaring into this one? Or would that be rude for a sub-decimal release? G On 2012-01-12 17:39, Martin Holmes wrote: > Hi all, > > I think we need to release a 2.0.2 soon, during which we again run > through the instructions, after adding the tagging instruction. Should > we do a quick trawl through the tickets and decide which ones might be > polished off quickly without controversy? > > Can I be the one to go through the release steps this time? > > Cheers, > Martin > > On 12-01-12 08:27 AM, Peter Stadler wrote: >> Dear geeks again, >> >> again wondering: just downloaded the current release 2.0.1 from sourceforge (tei-2.0.1.zip) and the editionStmt at tei-2.0.1/xml/tei/p5subset.xml reads2.0.0 Last updated on16th December 2011. >> >> Does that mean it wasn't updated at all or is just the editionStmt wrong? >> >> Many thanks again >> Peter >> > -- Dr Gabriel BODARD (Research Associate in Digital Epigraphy) Department of Digital 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 retired.ox.ac.uk Thu Jan 12 12:50:11 2012 From: lou.burnard at retired.ox.ac.uk (Lou Burnard) Date: Thu, 12 Jan 2012 17:50:11 +0000 Subject: [tei-council] version 2.0.1 p5subset.xml states "edition 2.0.0" In-Reply-To: <4F0F1C28.9050608@kcl.ac.uk> References: <48F7E21F-4B77-4865-AB90-47F6AA73ADBF@edirom.de> <4F0F1AD5.4070101@uvic.ca> <4F0F1C28.9050608@kcl.ac.uk> Message-ID: <4F0F1D53.4010306@retired.ox.ac.uk> As noted on the ticket, I think that's a straightforward error fix. And it doesn't change any content models. Just do it. ( now there's a catchy phrase, wonder if I can sell it) On 12/01/12 17:45, Gabriel Bodard wrote: > In that case, could I slip geo -> att.declaring into this one? Or would > that be rude for a sub-decimal release? > > G > > On 2012-01-12 17:39, Martin Holmes wrote: >> Hi all, >> >> I think we need to release a 2.0.2 soon, during which we again run >> through the instructions, after adding the tagging instruction. Should >> we do a quick trawl through the tickets and decide which ones might be >> polished off quickly without controversy? >> >> Can I be the one to go through the release steps this time? >> >> Cheers, >> Martin >> >> On 12-01-12 08:27 AM, Peter Stadler wrote: >>> Dear geeks again, >>> >>> again wondering: just downloaded the current release 2.0.1 from sourceforge (tei-2.0.1.zip) and the editionStmt at tei-2.0.1/xml/tei/p5subset.xml reads2.0.0 Last updated on16th December 2011. >>> >>> Does that mean it wasn't updated at all or is just the editionStmt wrong? >>> >>> Many thanks again >>> Peter >>> >> > From mholmes at uvic.ca Thu Jan 12 12:51:16 2012 From: mholmes at uvic.ca (Martin Holmes) Date: Thu, 12 Jan 2012 09:51:16 -0800 Subject: [tei-council] version 2.0.1 p5subset.xml states "edition 2.0.0" In-Reply-To: <4F0F1C28.9050608@kcl.ac.uk> References: <48F7E21F-4B77-4865-AB90-47F6AA73ADBF@edirom.de> <4F0F1AD5.4070101@uvic.ca> <4F0F1C28.9050608@kcl.ac.uk> Message-ID: <4F0F1D94.3050705@uvic.ca> > In that case, could I slip geo -> att.declaring into this one? Or would > that be rude for a sub-decimal release? I think that would be uncontroversial. The only arguments are over whether deserves it too (Syd, and now I, say yes, Lou says no), but the argument for is convincing. I would like to aim for a release next week, in which all the trivial typos that have been reported have been fixed (I've been trying to do those as they come in), and other simple issues like this are done. Then we'd be able to review the remaining tickets and raise new issues in preparation for the April meeting. Cheers, Martin On 12-01-12 09:45 AM, Gabriel Bodard wrote: > G > > On 2012-01-12 17:39, Martin Holmes wrote: >> Hi all, >> >> I think we need to release a 2.0.2 soon, during which we again run >> through the instructions, after adding the tagging instruction. Should >> we do a quick trawl through the tickets and decide which ones might be >> polished off quickly without controversy? >> >> Can I be the one to go through the release steps this time? >> >> Cheers, >> Martin >> >> On 12-01-12 08:27 AM, Peter Stadler wrote: >>> Dear geeks again, >>> >>> again wondering: just downloaded the current release 2.0.1 from sourceforge (tei-2.0.1.zip) and the editionStmt at tei-2.0.1/xml/tei/p5subset.xml reads2.0.0 Last updated on16th December 2011. >>> >>> Does that mean it wasn't updated at all or is just the editionStmt wrong? >>> >>> Many thanks again >>> Peter >>> >> > -- Martin Holmes University of Victoria Humanities Computing and Media Centre (mholmes at uvic.ca) From gabriel.bodard at kcl.ac.uk Thu Jan 12 12:53:22 2012 From: gabriel.bodard at kcl.ac.uk (Gabriel Bodard) Date: Thu, 12 Jan 2012 17:53:22 +0000 Subject: [tei-council] version 2.0.1 p5subset.xml states "edition 2.0.0" In-Reply-To: <4F0F1D53.4010306@retired.ox.ac.uk> References: <48F7E21F-4B77-4865-AB90-47F6AA73ADBF@edirom.de> <4F0F1AD5.4070101@uvic.ca> <4F0F1C28.9050608@kcl.ac.uk> <4F0F1D53.4010306@retired.ox.ac.uk> Message-ID: <4F0F1E12.6010004@kcl.ac.uk> Well, it adds @decl to one element. Is that not a content model change? Or do attributes not count? On 2012-01-12 17:50, Lou Burnard wrote: > As noted on the ticket, I think that's a straightforward error fix. And > it doesn't change any content models. Just do it. ( now there's a catchy > phrase, wonder if I can sell it) > > On 12/01/12 17:45, Gabriel Bodard wrote: >> In that case, could I slip geo -> att.declaring into this one? Or would >> that be rude for a sub-decimal release? >> >> G >> >> On 2012-01-12 17:39, Martin Holmes wrote: >>> Hi all, >>> >>> I think we need to release a 2.0.2 soon, during which we again run >>> through the instructions, after adding the tagging instruction. Should >>> we do a quick trawl through the tickets and decide which ones might be >>> polished off quickly without controversy? >>> >>> Can I be the one to go through the release steps this time? >>> >>> Cheers, >>> Martin >>> >>> On 12-01-12 08:27 AM, Peter Stadler wrote: >>>> Dear geeks again, >>>> >>>> again wondering: just downloaded the current release 2.0.1 from sourceforge (tei-2.0.1.zip) and the editionStmt at tei-2.0.1/xml/tei/p5subset.xml reads2.0.0 Last updated on16th December 2011. >>>> >>>> Does that mean it wasn't updated at all or is just the editionStmt wrong? >>>> >>>> Many thanks again >>>> Peter >>>> >>> >> > -- Dr Gabriel BODARD (Research Associate in Digital Epigraphy) Department of Digital 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 Jan 12 13:01:42 2012 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Thu, 12 Jan 2012 18:01:42 +0000 Subject: [tei-council] TEI Technical Council Budget 2012 In-Reply-To: <4F0EDE5D.7030901@uvic.ca> References: <4F0CC8CC.7070700@oucs.ox.ac.uk> <4F0E26CD.1000101@ultraslavonic.info> <2CADFB7D-C525-40A8-9012-B32A52E4A5E8@oucs.ox.ac.uk> <4F0EDE5D.7030901@uvic.ca> Message-ID: <4F0F2006.9040902@oucs.ox.ac.uk> If I summarise back the consensus I seem to hear is to do b) (ODD3 workshop) and c) (New Web Roma). I think we can do both those things (depending on how much you think 'c' will cost). And potentially have some money left over for additional things. (Which we can decide on and budget for later.) We'll invite MartinM and Brian (and anyone else people care to suggest) to participate in the Ann Arbor meeting (but remotely). I'll work up a slightly more detailed budget but wait for the result of the DH panel to see if it is accepted before submitting it to the board. -James On 12/01/12 13:21, Martin Holmes wrote: > >> We need to agree on terminology here. I think of "roma" as meaning >> "user interface to ODD, with facilities to create and edit and odd, and >> call ODD -> XX processing". Note the "call" there. All the Roma-ish tools we >> have now (Roma web, command-line, oxgarage, oxygen) all call the same >> underlying XSLT library. James' (d) is a rewrite of that backend library, but his >> c) is a new Roma web (probably). >> >> personally, I go for c), on the grounds that Web Roma is _definitely_ incomplete >> and has errors, and definitely has real users, now. > > That's exactly how I feel. Web Roma is most people's interface to TEI, > when they first start to create their own project (as opposed to working > on someone else's, where the schema is already done). The slicker and > more reliable it is, the better the initial experience, and the more > positive people feel towards using TEI. > > Cheers, > Martin > > On 12-01-12 01:12 AM, Sebastian Rahtz wrote: >> >> On 12 Jan 2012, at 00:18, Kevin Hawkins wrote: >>> My recollection is that we did indeed solve most of the problems. Even >>> if there are outstanding issues about rationalization that Paul >>> Schaffner (who will be attending as a Council member) can't answer for >>> us, I imagine we could get Martin Mueller or Brian Pytlik Zillig on the >>> phone or Skype to answer those questions. They're both only one time >>> zone away from Ann Arbor, so I can't imagine this will be difficult. >> >> I agree, it probably doesnt need a full-scale session with MM and BPZ; >> but we really should revisit the issue. There are certainly unsolved parts of the >> equation - is one of those. Asking MM/BPZ to test 2.0.1 on their >> conversions now would be important. >> >>>> d) Another idea was to try to fund an entirely new processing >>>> implementation of ODD2+ that is completely independent of the existing >>>> XSLT. But this is problematic to budget. >>> >>> You mean fund a complete rewrite of Roma rather than a better Roma, as >>> in ?? >> >> We need to agree on terminology here. I think of "roma" as meaning >> "user interface to ODD, with facilities to create and edit and odd, and >> call ODD -> XX processing". Note the "call" there. All the Roma-ish tools we >> have now (Roma web, command-line, oxgarage, oxygen) all call the same >> underlying XSLT library. James' (d) is a rewrite of that backend library, but his >> c) is a new Roma web (probably). >> >> personally, I go for c), on the grounds that Web Roma is _definitely_ incomplete >> and has errors, and definitely has real users, now. >> >> -- >> Stormageddon Rahtz >> Head of Information and Support Group >> Oxford University Computing 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 James Cummings, InfoDev, Computing Services, University of Oxford From kevin.s.hawkins at ultraslavonic.info Thu Jan 12 15:42:22 2012 From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins) Date: Thu, 12 Jan 2012 15:42:22 -0500 Subject: [tei-council] Bug: make geo declaring In-Reply-To: <4F0EC7B2.4020002@kcl.ac.uk> References: <4F0C67A6.4010400@kcl.ac.uk> <4F0EC7B2.4020002@kcl.ac.uk> Message-ID: <4F0F45AE.9010202@ultraslavonic.info> Is there really consensus to make a member of att.declaring? I don't see that. --Kevin On 1/12/12 6:44 AM, Gabriel Bodard wrote: > There's been a little bit of discussion on the ticket, and it looks like > we're more or less agreed that we could reasonable make both and > members of att.declaring. I'll implement this today if no one > objects, but I thought I'd ask here if anyone wants to weigh in on the > minor debate between Martin and myself first... > > Cheers, > > Gabby > > On 2012-01-10 16:30, Gabriel Bodard wrote: >> Dear Councillors, >> >> A reminder of a bug ticket that was submitted last November (just too >> late to make it into the last release, apparently), suggesting that >> be added to att.declaring: >> >> http://purl.org/TEI/BUGS/3440771 >> >> If everyone is agreeable, I'm happy to go ahead and make this change in >> the source. (I know it won't be released for a while now, but if I do it >> now we won't forget in future.) >> >> Best, >> >> Gabby >> > From mholmes at uvic.ca Thu Jan 12 16:17:48 2012 From: mholmes at uvic.ca (Martin Holmes) Date: Thu, 12 Jan 2012 13:17:48 -0800 Subject: [tei-council] Bug: make geo declaring In-Reply-To: <4F0F45AE.9010202@ultraslavonic.info> References: <4F0C67A6.4010400@kcl.ac.uk> <4F0EC7B2.4020002@kcl.ac.uk> <4F0F45AE.9010202@ultraslavonic.info> Message-ID: <4F0F4DFC.1040304@uvic.ca> No, the consensus is on only. We're still arguing about . But the ticket requests "multiple tags in a element (which AFAIK has always been permitted), and the removal of the restriction for all tags to use the same coordinate system. This change would accomplish that. Of course, before closing the ticket we should check that all references and descriptive text are appropriately updated, but the addition of to att.declaring alone answers the ticket, I think, and should solve the submitter's problem. Cheers, Martin On 12-01-12 12:42 PM, Kevin Hawkins wrote: > Is there really consensus to make a member of att.declaring? > I don't see that. --Kevin > > On 1/12/12 6:44 AM, Gabriel Bodard wrote: >> There's been a little bit of discussion on the ticket, and it looks like >> we're more or less agreed that we could reasonable make both and >> members of att.declaring. I'll implement this today if no one >> objects, but I thought I'd ask here if anyone wants to weigh in on the >> minor debate between Martin and myself first... >> >> Cheers, >> >> Gabby >> >> On 2012-01-10 16:30, Gabriel Bodard wrote: >>> Dear Councillors, >>> >>> A reminder of a bug ticket that was submitted last November (just too >>> late to make it into the last release, apparently), suggesting that >>> be added to att.declaring: >>> >>> http://purl.org/TEI/BUGS/3440771 >>> >>> If everyone is agreeable, I'm happy to go ahead and make this change in >>> the source. (I know it won't be released for a while now, but if I do it >>> now we won't forget in future.) >>> >>> Best, >>> >>> Gabby >>> >> -- Martin Holmes University of Victoria Humanities Computing and Media Centre (mholmes at uvic.ca) From sebastian.rahtz at oucs.ox.ac.uk Fri Jan 13 04:32:56 2012 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Fri, 13 Jan 2012 09:32:56 +0000 Subject: [tei-council] Minor error in Guidelines In-Reply-To: <4F0FBAA5.2090706@uvic.ca> References: <4F0F9F9F.3050408@gmail.com> <4F0FBAA5.2090706@uvic.ca> Message-ID: <97AE8F42-0EDB-41CC-8FE1-984EE9E495D4@oucs.ox.ac.uk> On 13 Jan 2012, at 05:01, Martin Holmes wrote: > I've put in a bug report for this: > > > > The basic problem is that in the web view of the Guidelines, figures > within each chapter are numbered 1, 2, 3, 4 etc., but in the PDF output, > they're numbered 11.1, 11.2, 11.3? > there are two issues here. a) the use of dangerous markup like "figure 4 above", which should be changed into a to avoid this sort of problem b) the different numbering schemes for the latter, which do we want for the Guidelines? by chapter, or sequential throughout? for the former, I found 3 occurrences of this, and changed them to . am testing before committing. -- Stormageddon Rahtz Head of Information and Support Group Oxford University Computing Services 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 Fri Jan 13 04:41:50 2012 From: james.cummings at oucs.ox.ac.uk (James Cummings) Date: Fri, 13 Jan 2012 09:41:50 +0000 Subject: [tei-council] @source and @version for versioning an ODD Message-ID: I'd agree that if the genetic stuff is all implemented then the release is a major bump. JamesC -- James Cummings, InfoDev, OUCS, University of Oxford (via phone) Lou Burnard wrote: From james.cummings at oucs.ox.ac.uk Fri Jan 13 04:47:59 2012 From: james.cummings at oucs.ox.ac.uk (James Cummings) Date: Fri, 13 Jan 2012 09:47:59 +0000 Subject: [tei-council] @source and @version for versioning an ODD Message-ID: Apologies my phone just seemed to send an old draft message. Weird. JamesC -- James Cummings, InfoDev, OUCS, University of Oxford (via phone) James Cummings wrote: I'd agree that if the genetic stuff is all implemented then the release is a major bump. JamesC -- James Cummings, InfoDev, OUCS, University of Oxford (via phone) Lou Burnard wrote: -- tei-council mailing list tei-council at lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council PLEASE NOTE: postings to this list are publicly archived From gabriel.bodard at kcl.ac.uk Fri Jan 13 06:00:18 2012 From: gabriel.bodard at kcl.ac.uk (Gabriel Bodard) Date: Fri, 13 Jan 2012 11:00:18 +0000 Subject: [tei-council] Bug: make geo declaring In-Reply-To: <4F0F45AE.9010202@ultraslavonic.info> References: <4F0C67A6.4010400@kcl.ac.uk> <4F0EC7B2.4020002@kcl.ac.uk> <4F0F45AE.9010202@ultraslavonic.info> Message-ID: <4F100EC2.5020801@kcl.ac.uk> No, you're right. When I wrote that email it looked much more like a consensus (at least that adding @decls to was harmless) than it did by the time it hit the list. I've added decls to geo, but not to location, for now, pending further discussion. Will look at the surrounding prose and report here what I think needs clarified/changed. G On 2012-01-12 20:42, Kevin Hawkins wrote: > Is there really consensus to make a member of att.declaring? > I don't see that. --Kevin > > On 1/12/12 6:44 AM, Gabriel Bodard wrote: >> There's been a little bit of discussion on the ticket, and it looks like >> we're more or less agreed that we could reasonable make both and >> members of att.declaring. I'll implement this today if no one >> objects, but I thought I'd ask here if anyone wants to weigh in on the >> minor debate between Martin and myself first... >> >> Cheers, >> >> Gabby >> >> On 2012-01-10 16:30, Gabriel Bodard wrote: >>> Dear Councillors, >>> >>> A reminder of a bug ticket that was submitted last November (just too >>> late to make it into the last release, apparently), suggesting that >>> be added to att.declaring: >>> >>> http://purl.org/TEI/BUGS/3440771 >>> >>> If everyone is agreeable, I'm happy to go ahead and make this change in >>> the source. (I know it won't be released for a while now, but if I do it >>> now we won't forget in future.) >>> >>> Best, >>> >>> Gabby >>> >> -- Dr Gabriel BODARD (Research Associate in Digital Epigraphy) Department of Digital Humanities King's College London 26-29 Drury Lane London WC2B 5RL Email: gabriel.bodard at kcl.ac.uk Tel: +44 (0)20 7848 1388 Fax: +44 (0)20 7848 2980 http://www.digitalclassicist.org/ http://www.currentepigraphy.org/ From gabriel.bodard at kcl.ac.uk Fri Jan 13 06:38:44 2012 From: gabriel.bodard at kcl.ac.uk (Gabriel Bodard) Date: Fri, 13 Jan 2012 11:38:44 +0000 Subject: [tei-council] Bug: make geo declaring In-Reply-To: <4F0F4DFC.1040304@uvic.ca> References: <4F0C67A6.4010400@kcl.ac.uk> <4F0EC7B2.4020002@kcl.ac.uk> <4F0F45AE.9010202@ultraslavonic.info> <4F0F4DFC.1040304@uvic.ca> Message-ID: <4F1017C4.4020101@kcl.ac.uk> Now that I look at it, I'm not clear exactly what we do want to say about the content/format of . As Martin says, we obviously want to get rid of the note as written, which says: 1. all in a document need to use the same coordinate system; 2. in absence of , this is assumed to be a space-delimited pair of coords (lat followed by long) "according to the World Geodetic System." The first part obviously needs to go; do we need to think some more about the format we want to encourage as the default? It's true that a coordinate pair will be the most common content, but what do we want to recommend for people who want, like Martin, to represent a polygon or polyline? I was thinking that a useful rule might be to follow an existing standard like gml:posList, but that expects coordinate pairs to be comma-delimited, and lines/polygons to be made up of a space-delimited list of such pairs. This is the opposite of what we seem to suggest now, and would therefore break a lot of people's usage. Any other suggestions? (Final question: do we also want to give some guidance under about how to define more than one datum and refer back to them?) G On 2012-01-12 21:17, Martin Holmes wrote: > No, the consensus is on only. We're still arguing about > . But the ticket requests "multiple tags in a > element (which AFAIK has always been permitted), and the removal of the > restriction for all tags to use the same coordinate system. This > change would accomplish that. Of course, before closing the ticket we > should check that all references and descriptive text are appropriately > updated, but the addition of to att.declaring alone answers the > ticket, I think, and should solve the submitter's problem. > > Cheers, > Martin > > On 12-01-12 12:42 PM, Kevin Hawkins wrote: >> Is there really consensus to make a member of att.declaring? >> I don't see that. --Kevin >> >> On 1/12/12 6:44 AM, Gabriel Bodard wrote: >>> There's been a little bit of discussion on the ticket, and it looks like >>> we're more or less agreed that we could reasonable make both and >>> members of att.declaring. I'll implement this today if no one >>> objects, but I thought I'd ask here if anyone wants to weigh in on the >>> minor debate between Martin and myself first... >>> >>> Cheers, >>> >>> Gabby >>> >>> On 2012-01-10 16:30, Gabriel Bodard wrote: >>>> Dear Councillors, >>>> >>>> A reminder of a bug ticket that was submitted last November (just too >>>> late to make it into the last release, apparently), suggesting that >>>> be added to att.declaring: >>>> >>>> http://purl.org/TEI/BUGS/3440771 >>>> >>>> If everyone is agreeable, I'm happy to go ahead and make this change in >>>> the source. (I know it won't be released for a while now, but if I do it >>>> now we won't forget in future.) >>>> >>>> Best, >>>> >>>> Gabby >>>> >>> > -- Dr Gabriel BODARD (Research Associate in Digital Epigraphy) Department of Digital 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 13 11:17:16 2012 From: mholmes at uvic.ca (Martin Holmes) Date: Fri, 13 Jan 2012 08:17:16 -0800 Subject: [tei-council] Minor error in Guidelines In-Reply-To: <97AE8F42-0EDB-41CC-8FE1-984EE9E495D4@oucs.ox.ac.uk> References: <4F0F9F9F.3050408@gmail.com> <4F0FBAA5.2090706@uvic.ca> <97AE8F42-0EDB-41CC-8FE1-984EE9E495D4@oucs.ox.ac.uk> Message-ID: <4F10590C.50904@uvic.ca> Could you clarify what the difference is between using and in the guidelines? Cheers, Martin On 12-01-13 01:32 AM, Sebastian Rahtz wrote: > > On 13 Jan 2012, at 05:01, Martin Holmes wrote: > >> I've put in a bug report for this: >> >> >> >> The basic problem is that in the web view of the Guidelines, figures >> within each chapter are numbered 1, 2, 3, 4 etc., but in the PDF output, >> they're numbered 11.1, 11.2, 11.3? >> > there are two issues here. > > a) the use of dangerous markup like "figure 4 above", which should be changed into a to avoid this sort of problem > b) the different numbering schemes > > for the latter, which do we want for the Guidelines? by chapter, or sequential throughout? > > for the former, I found 3 occurrences of this, and changed them to. am testing before committing. > -- > Stormageddon Rahtz > Head of Information and Support Group > Oxford University Computing Services > 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 > > S?lo le pido a Dios > que el futuro no me sea indiferente > -- Martin Holmes University of Victoria Humanities Computing and Media Centre (mholmes at uvic.ca) From James.Cummings at oucs.ox.ac.uk Fri Jan 13 11:19:45 2012 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Fri, 13 Jan 2012 16:19:45 +0000 Subject: [tei-council] Minor error in Guidelines In-Reply-To: <4F10590C.50904@uvic.ca> References: <4F0F9F9F.3050408@gmail.com> <4F0FBAA5.2090706@uvic.ca> <97AE8F42-0EDB-41CC-8FE1-984EE9E495D4@oucs.ox.ac.uk> <4F10590C.50904@uvic.ca> Message-ID: <4F1059A1.4060206@oucs.ox.ac.uk> On 13/01/12 16:17, Martin Holmes wrote: > Could you clarify what the difference is between using and > in the guidelines? I'm assuming that Sebastian's point (ha ha) is that contains text which may become outdated, whereas in processing a we generate the link text based on the content of the @target or whatever it points at. -James -- Dr James Cummings, InfoDev, Computing Services, University of Oxford From lou.burnard at retired.ox.ac.uk Fri Jan 13 11:19:53 2012 From: lou.burnard at retired.ox.ac.uk (Lou Burnard) Date: Fri, 13 Jan 2012 16:19:53 +0000 Subject: [tei-council] Minor error in Guidelines In-Reply-To: <4F10590C.50904@uvic.ca> References: <4F0F9F9F.3050408@gmail.com> <4F0FBAA5.2090706@uvic.ca> <97AE8F42-0EDB-41CC-8FE1-984EE9E495D4@oucs.ox.ac.uk> <4F10590C.50904@uvic.ca> Message-ID: <4F1059A9.1000709@retired.ox.ac.uk> In the Guidelines, as elsewhere, section foo means: generate a link to #foo and represent it by the text "section foo". means: generate a link to #foo and represent it by whatever text your processor chooses to generate On 13/01/12 16:17, Martin Holmes wrote: > Could you clarify what the difference is between using and > in the guidelines? > > Cheers, > Martin > > On 12-01-13 01:32 AM, Sebastian Rahtz wrote: >> >> On 13 Jan 2012, at 05:01, Martin Holmes wrote: >> >>> I've put in a bug report for this: >>> >>> >>> >>> The basic problem is that in the web view of the Guidelines, figures >>> within each chapter are numbered 1, 2, 3, 4 etc., but in the PDF output, >>> they're numbered 11.1, 11.2, 11.3? >>> >> there are two issues here. >> >> a) the use of dangerous markup like "figure 4 above", which should be changed into a to avoid this sort of problem >> b) the different numbering schemes >> >> for the latter, which do we want for the Guidelines? by chapter, or sequential throughout? >> >> for the former, I found 3 occurrences of this, and changed them to. am testing before committing. >> -- >> Stormageddon Rahtz >> Head of Information and Support Group >> Oxford University Computing Services >> 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 Jan 13 11:26:38 2012 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Fri, 13 Jan 2012 16:26:38 +0000 Subject: [tei-council] Minor error in Guidelines In-Reply-To: <4F10590C.50904@uvic.ca> References: <4F0F9F9F.3050408@gmail.com> <4F0FBAA5.2090706@uvic.ca> <97AE8F42-0EDB-41CC-8FE1-984EE9E495D4@oucs.ox.ac.uk> <4F10590C.50904@uvic.ca> Message-ID: <80387C30-DACA-44C1-9EBF-B87E703CE753@oucs.ox.ac.uk> On 13 Jan 2012, at 16:17, Martin Holmes wrote: > Could you clarify what the difference is between using and > in the guidelines? if you use , you (the author) dictate what the cross-reference text is. If you use , it is calculated for you. so generates "Figure 11.1" or whatever. I would seldom use myself in born-digital writing. W3C never seemed to cotton on to this sort of thing. They probably still believe in "follow this link". -- Stormageddon Rahtz Head of Information and Support Group Oxford University Computing Services 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 Jan 13 12:27:09 2012 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Fri, 13 Jan 2012 17:27:09 +0000 Subject: [tei-council] figure 11.2 etc Message-ID: folks may like to examine http://bits.nsms.ox.ac.uk:8080/jenkins/job/TEIP5-Documentation/lastSuccessfulBuild/artifact/Guidelines-web/en/html/PH.html and see if they are happy with rendering of table captions and cross-refs now. I have corrected the stylesheets, and changed the source to use -- Stormageddon Rahtz Head of Information and Support Group Oxford University Computing Services 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 13 12:34:28 2012 From: mholmes at uvic.ca (Martin Holmes) Date: Fri, 13 Jan 2012 09:34:28 -0800 Subject: [tei-council] figure 11.2 etc In-Reply-To: References: Message-ID: <4F106B24.9020700@uvic.ca> That looks great to me. If everyone's happy, I'll close the ticket. Cheers, Martin On 12-01-13 09:27 AM, Sebastian Rahtz wrote: > folks may like to examine http://bits.nsms.ox.ac.uk:8080/jenkins/job/TEIP5-Documentation/lastSuccessfulBuild/artifact/Guidelines-web/en/html/PH.html and see if they are happy with rendering of table captions and cross-refs now. I have corrected the stylesheets, > and changed the source to use > -- > Stormageddon Rahtz > Head of Information and Support Group > Oxford University Computing Services > 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 > > S?lo le pido a Dios > que el futuro no me sea indiferente > -- Martin Holmes University of Victoria Humanities Computing and Media Centre (mholmes at uvic.ca) From gabriel.bodard at kcl.ac.uk Tue Jan 17 11:11:45 2012 From: gabriel.bodard at kcl.ac.uk (Gabriel Bodard) Date: Tue, 17 Jan 2012 16:11:45 +0000 Subject: [tei-council] version 2.0.1 p5subset.xml states "edition 2.0.0" In-Reply-To: <4F0F1AD5.4070101@uvic.ca> References: <48F7E21F-4B77-4865-AB90-47F6AA73ADBF@edirom.de> <4F0F1AD5.4070101@uvic.ca> Message-ID: <4F159DC1.4010001@kcl.ac.uk> Has there been any consensus on when 2.0.2 might be put out? (I ask because, if it's soon I won't both hacking the EpiDoc schema to allow geo/@decl; I'll just wait for TEI to introduce it and regenerate the schema properly. :-) ) G On 2012-01-12 17:39, Martin Holmes wrote: > Hi all, > > I think we need to release a 2.0.2 soon, during which we again run > through the instructions, after adding the tagging instruction. Should > we do a quick trawl through the tickets and decide which ones might be > polished off quickly without controversy? > > Can I be the one to go through the release steps this time? > > Cheers, > Martin > > On 12-01-12 08:27 AM, Peter Stadler wrote: >> Dear geeks again, >> >> again wondering: just downloaded the current release 2.0.1 from sourceforge (tei-2.0.1.zip) and the editionStmt at tei-2.0.1/xml/tei/p5subset.xml reads2.0.0 Last updated on16th December 2011. >> >> Does that mean it wasn't updated at all or is just the editionStmt wrong? >> >> Many thanks again >> Peter >> > -- Dr Gabriel BODARD (Research Associate in Digital Epigraphy) Department of Digital 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 Jan 17 19:13:10 2012 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Wed, 18 Jan 2012 00:13:10 +0000 Subject: [tei-council] version 2.0.1 p5subset.xml states "edition 2.0.0" In-Reply-To: <4F159DC1.4010001@kcl.ac.uk> References: <48F7E21F-4B77-4865-AB90-47F6AA73ADBF@edirom.de> <4F0F1AD5.4070101@uvic.ca> <4F159DC1.4010001@kcl.ac.uk> Message-ID: <4F160E96.2010202@oucs.ox.ac.uk> Hi all, Since no one else has piped up, can I suggest a schedule: 31 January midnight GMT: submission deadline of significant changes 1 February: Whole Day for council to proofread and correct typos. 2nd February: Release (Codename: Groundhog Day) Since Martin asked, I suggest him as release technician. Any reasons why these dates are wholly unsuitable? -James On 17/01/12 16:11, Gabriel Bodard wrote: > Has there been any consensus on when 2.0.2 might be put out? > > (I ask because, if it's soon I won't both hacking the EpiDoc schema to > allow geo/@decl; I'll just wait for TEI to introduce it and regenerate > the schema properly. :-) ) > > G > > On 2012-01-12 17:39, Martin Holmes wrote: >> Hi all, >> >> I think we need to release a 2.0.2 soon, during which we again run >> through the instructions, after adding the tagging instruction. Should >> we do a quick trawl through the tickets and decide which ones might beS >> polished off quickly without controversy? >> >> Can I be the one to go through the release steps this time? >> >> Cheers, >> Martin >> >> On 12-01-12 08:27 AM, Peter Stadler wrote: >>> Dear geeks again, >>> >>> again wondering: just downloaded the current release 2.0.1 from sourceforge (tei-2.0.1.zip) and the editionStmt at tei-2.0.1/xml/tei/p5subset.xml reads2.0.0 Last updated on16th December 2011. >>> >>> Does that mean it wasn't updated at all or is just the editionStmt wrong? >>> >>> Many thanks again >>> Peter >>> >> > -- Dr James Cummings, InfoDev, Computing Services, University of Oxford From sebastian.rahtz at oucs.ox.ac.uk Wed Jan 18 07:24:36 2012 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Wed, 18 Jan 2012 12:24:36 +0000 Subject: [tei-council] version 2.0.1 p5subset.xml states "edition 2.0.0" In-Reply-To: <4F160E96.2010202@oucs.ox.ac.uk> References: <48F7E21F-4B77-4865-AB90-47F6AA73ADBF@edirom.de> <4F0F1AD5.4070101@uvic.ca> <4F159DC1.4010001@kcl.ac.uk> <4F160E96.2010202@oucs.ox.ac.uk> Message-ID: no problem with dates. I'll need to do a new stylesheet release before then, to get the Guidelines formatting right. we have not resolved the issue about AdBlock and "msad". can we choose between 1. ignore it. caveat blockor. 2. rejig our IDs to use "mss" instead of "ms" (a pain, and breaks published links). would it work? 3. rejig the stylesheets to rewrite all refs as tei_$whatever (needs dev work, breaks published links) My personal preference is in the order above. -- Stormageddon Rahtz Head of Information and Support Group Oxford University Computing Services 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 Wed Jan 18 07:42:40 2012 From: gabriel.bodard at kcl.ac.uk (Gabriel Bodard) Date: Wed, 18 Jan 2012 12:42:40 +0000 Subject: [tei-council] version 2.0.1 p5subset.xml states "edition 2.0.0" In-Reply-To: References: <48F7E21F-4B77-4865-AB90-47F6AA73ADBF@edirom.de> <4F0F1AD5.4070101@uvic.ca> <4F159DC1.4010001@kcl.ac.uk> <4F160E96.2010202@oucs.ox.ac.uk> Message-ID: <4F16BE40.1030308@kcl.ac.uk> Given that a subset of 1. "ignore it" is potentially partly resolved by all of us (right?) having requested an exception to whatever ABP filter we use, it's not the worst option in the world. 2 & 3 both have the problem that is bothering Sebastian, but 3 is of course much worse in this case (2 being in practice (a) easy and (b) relatively minor inconvenience to anybody). I don't suppose you can write a rewrite rule for file fragments, can you? My preferences, therefore, are (in order): 2 - 1 - 3. Gabby On 2012-01-18 12:24, Sebastian Rahtz wrote: > no problem with dates. I'll need to do a new stylesheet release before then, to > get the Guidelines formatting right. > > we have not resolved the issue about AdBlock and "msad". can we choose > between > > 1. ignore it. caveat blockor. > 2. rejig our IDs to use "mss" instead of "ms" (a pain, and breaks published links). would it work? > 3. rejig the stylesheets to rewrite all refs as tei_$whatever (needs dev work, breaks published links) > > My personal preference is in the order above. > > -- > Stormageddon Rahtz > Head of Information and Support Group > Oxford University Computing 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 (Research Associate in Digital Epigraphy) Department of Digital 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 Wed Jan 18 07:54:46 2012 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Wed, 18 Jan 2012 12:54:46 +0000 Subject: [tei-council] version 2.0.1 p5subset.xml states "edition 2.0.0" In-Reply-To: <4F16BE40.1030308@kcl.ac.uk> References: <48F7E21F-4B77-4865-AB90-47F6AA73ADBF@edirom.de> <4F0F1AD5.4070101@uvic.ca> <4F159DC1.4010001@kcl.ac.uk> <4F160E96.2010202@oucs.ox.ac.uk> <4F16BE40.1030308@kcl.ac.uk> Message-ID: <1B7AE77F-D916-41EC-833C-CC01F8BDCB66@oucs.ox.ac.uk> On 18 Jan 2012, at 12:42, Gabriel Bodard wrote: > > 2 & 3 both have the problem that is bothering Sebastian, but 3 is of > course much worse in this case (2 being in practice (a) easy and (b) > relatively minor inconvenience to anybody). I don't suppose you can > write a rewrite rule for file fragments, can you? yes, given careful thought, I think we could trap #msad and rewrite to #mssad. I'm not volunteering, mind, you can spend whole days understanding Apache mod_rewrite :-} -- Stormageddon Rahtz Head of Information and Support Group Oxford University Computing Services 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 Jan 18 08:07:39 2012 From: mholmes at uvic.ca (Martin Holmes) Date: Wed, 18 Jan 2012 05:07:39 -0800 Subject: [tei-council] version 2.0.1 p5subset.xml states "edition 2.0.0" In-Reply-To: <4F160E96.2010202@oucs.ox.ac.uk> References: <48F7E21F-4B77-4865-AB90-47F6AA73ADBF@edirom.de> <4F0F1AD5.4070101@uvic.ca> <4F159DC1.4010001@kcl.ac.uk> <4F160E96.2010202@oucs.ox.ac.uk> Message-ID: <4F16C41B.2050709@uvic.ca> Works for me. :-) On 12-01-17 04:13 PM, James Cummings wrote: > > Hi all, > > Since no one else has piped up, can I suggest a schedule: > > 31 January midnight GMT: submission deadline of significant changes > 1 February: Whole Day for council to proofread and correct typos. > 2nd February: Release (Codename: Groundhog Day) > > Since Martin asked, I suggest him as release technician. > > Any reasons why these dates are wholly unsuitable? > > -James > > On 17/01/12 16:11, Gabriel Bodard wrote: >> Has there been any consensus on when 2.0.2 might be put out? >> >> (I ask because, if it's soon I won't both hacking the EpiDoc schema to >> allow geo/@decl; I'll just wait for TEI to introduce it and regenerate >> the schema properly. :-) ) >> >> G >> >> On 2012-01-12 17:39, Martin Holmes wrote: >>> Hi all, >>> >>> I think we need to release a 2.0.2 soon, during which we again run >>> through the instructions, after adding the tagging instruction. Should >>> we do a quick trawl through the tickets and decide which ones might beS >>> polished off quickly without controversy? >>> >>> Can I be the one to go through the release steps this time? >>> >>> Cheers, >>> Martin >>> >>> On 12-01-12 08:27 AM, Peter Stadler wrote: >>>> Dear geeks again, >>>> >>>> again wondering: just downloaded the current release 2.0.1 from sourceforge (tei-2.0.1.zip) and the editionStmt at tei-2.0.1/xml/tei/p5subset.xml reads2.0.0 Last updated on16th December 2011. >>>> >>>> Does that mean it wasn't updated at all or is just the editionStmt wrong? >>>> >>>> Many thanks again >>>> Peter >>>> >>> >> > > From mholmes at uvic.ca Wed Jan 18 08:33:21 2012 From: mholmes at uvic.ca (Martin Holmes) Date: Wed, 18 Jan 2012 05:33:21 -0800 Subject: [tei-council] version 2.0.1 p5subset.xml states "edition 2.0.0" In-Reply-To: References: <48F7E21F-4B77-4865-AB90-47F6AA73ADBF@edirom.de> <4F0F1AD5.4070101@uvic.ca> <4F159DC1.4010001@kcl.ac.uk> <4F160E96.2010202@oucs.ox.ac.uk> Message-ID: <4F16CA21.5060105@uvic.ca> My preference is for #1 now, and #3 for a future major release. Cheers, Martin On 12-01-18 04:24 AM, Sebastian Rahtz wrote: > no problem with dates. I'll need to do a new stylesheet release before then, to > get the Guidelines formatting right. > > we have not resolved the issue about AdBlock and "msad". can we choose > between > > 1. ignore it. caveat blockor. > 2. rejig our IDs to use "mss" instead of "ms" (a pain, and breaks published links). would it work? > 3. rejig the stylesheets to rewrite all refs as tei_$whatever (needs dev work, breaks published links) > > My personal preference is in the order above. > > -- > Stormageddon Rahtz > Head of Information and Support Group > Oxford University Computing Services > 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 Jan 18 08:50:22 2012 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Wed, 18 Jan 2012 13:50:22 +0000 Subject: [tei-council] version 2.0.1 p5subset.xml states "edition 2.0.0" In-Reply-To: <1B7AE77F-D916-41EC-833C-CC01F8BDCB66@oucs.ox.ac.uk> References: <48F7E21F-4B77-4865-AB90-47F6AA73ADBF@edirom.de> <4F0F1AD5.4070101@uvic.ca> <4F159DC1.4010001@kcl.ac.uk> <4F160E96.2010202@oucs.ox.ac.uk> <4F16BE40.1030308@kcl.ac.uk> <1B7AE77F-D916-41EC-833C-CC01F8BDCB66@oucs.ox.ac.uk> Message-ID: <4F16CE1E.5080609@oucs.ox.ac.uk> On 18/01/12 12:54, Sebastian Rahtz wrote: >> 2& 3 both have the problem that is bothering Sebastian, but 3 is of >> course much worse in this case (2 being in practice (a) easy and (b) >> relatively minor inconvenience to anybody). I don't suppose you can >> write a rewrite rule for file fragments, can you? > yes, given careful thought, I think we could trap #msad and rewrite to #mssad. > I'm not volunteering, mind, you can spend whole days understanding > Apache mod_rewrite :-} Any disagreements that this is the right course of action? I'm assuming we are: a) Changing the source to make @xml:id 'msad' and the child @xml:id's for that section into 'mssad' and similar. (So people looking at latest version or making new bookmarks have no problem.) b) Changing any internal references we have to any of these sections c) trap any url that has #msad* in and replace that matching bit with #mssad* in an apache rewrite rule. d) What about changing historical versions in the vault? Should we just leave these? -James -- Dr James Cummings, InfoDev, Computing Services, University of Oxford From sebastian.rahtz at oucs.ox.ac.uk Wed Jan 18 08:57:41 2012 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Wed, 18 Jan 2012 13:57:41 +0000 Subject: [tei-council] version 2.0.1 p5subset.xml states "edition 2.0.0" In-Reply-To: <4F16CE1E.5080609@oucs.ox.ac.uk> References: <48F7E21F-4B77-4865-AB90-47F6AA73ADBF@edirom.de> <4F0F1AD5.4070101@uvic.ca> <4F159DC1.4010001@kcl.ac.uk> <4F160E96.2010202@oucs.ox.ac.uk> <4F16BE40.1030308@kcl.ac.uk> <1B7AE77F-D916-41EC-833C-CC01F8BDCB66@oucs.ox.ac.uk> <4F16CE1E.5080609@oucs.ox.ac.uk> Message-ID: <778FBF03-1354-4F83-A17D-009F88F1AB30@oucs.ox.ac.uk> well, it does mean the IDs are out of sync with the file name. it is no coincidence the thing is called MS-ManuscriptDescription.xml, and generates MS.html should it change to MSS.html? > c) trap any url that has #msad* in and replace that matching bit > with #mssad* in an apache rewrite rule. is that a volunteer to write the rule? :-} > d) What about changing historical versions in the vault? Should > we just leave these? gosh yes. tinkering with all the generating HTML would be vile, and regenerating almost impossible. -- Stormageddon Rahtz Head of Information and Support Group Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From PFSchaffner at umich.edu Wed Jan 18 10:38:04 2012 From: PFSchaffner at umich.edu (Paul F. Schaffner) Date: Wed, 18 Jan 2012 10:38:04 -0500 (EST) Subject: [tei-council] version 2.0.1 p5subset.xml states "edition 2.0.0" In-Reply-To: <4F16CE1E.5080609@oucs.ox.ac.uk> References: <48F7E21F-4B77-4865-AB90-47F6AA73ADBF@edirom.de> <4F0F1AD5.4070101@uvic.ca> <4F159DC1.4010001@kcl.ac.uk> <4F160E96.2010202@oucs.ox.ac.uk> <4F16BE40.1030308@kcl.ac.uk> <1B7AE77F-D916-41EC-833C-CC01F8BDCB66@oucs.ox.ac.uk> <4F16CE1E.5080609@oucs.ox.ac.uk> Message-ID: On Wed, 18 Jan 2012, James Cummings wrote: > On 18/01/12 12:54, Sebastian Rahtz wrote: > >> 2& 3 both have the problem that is bothering Sebastian, but 3 is of > >> course much worse in this case (2 being in practice (a) easy and (b) > >> relatively minor inconvenience to anybody). I don't suppose you can > >> write a rewrite rule for file fragments, can you? > > yes, given careful thought, I think we could trap #msad and rewrite to #mssad. > > I'm not volunteering, mind, you can spend whole days understanding > > Apache mod_rewrite :-} > > Any disagreements that this is the right course of action? If I had to vote, I'd go with 'do nothing.' People who filter content have to know that the filters are imperfect--that they may be trapping dolphins with their catch of tuna. pfs -------------------------------------------------------------------- Paul Schaffner | PFSchaffner at umich.edu | http://www.umich.edu/~pfs/ 316-C Hatcher Library N, Univ. of Michigan, Ann Arbor MI 48109-1190 -------------------------------------------------------------------- From lou.burnard at retired.ox.ac.uk Wed Jan 18 10:53:54 2012 From: lou.burnard at retired.ox.ac.uk (Lou Burnard) Date: Wed, 18 Jan 2012 15:53:54 +0000 Subject: [tei-council] version 2.0.1 p5subset.xml states "edition 2.0.0" In-Reply-To: References: <48F7E21F-4B77-4865-AB90-47F6AA73ADBF@edirom.de> <4F0F1AD5.4070101@uvic.ca> <4F159DC1.4010001@kcl.ac.uk> <4F160E96.2010202@oucs.ox.ac.uk> <4F16BE40.1030308@kcl.ac.uk> <1B7AE77F-D916-41EC-833C-CC01F8BDCB66@oucs.ox.ac.uk> <4F16CE1E.5080609@oucs.ox.ac.uk> Message-ID: <4F16EB12.5030900@retired.ox.ac.uk> On 18/01/12 15:38, Paul F. Schaffner wrote: > On Wed, 18 Jan 2012, James Cummings wrote: > >> On 18/01/12 12:54, Sebastian Rahtz wrote: >>>> 2& 3 both have the problem that is bothering Sebastian, but 3 is of >>>> course much worse in this case (2 being in practice (a) easy and (b) >>>> relatively minor inconvenience to anybody). I don't suppose you can >>>> write a rewrite rule for file fragments, can you? >>> yes, given careful thought, I think we could trap #msad and rewrite to #mssad. >>> I'm not volunteering, mind, you can spend whole days understanding >>> Apache mod_rewrite :-} >> >> Any disagreements that this is the right course of action? > > If I had to vote, I'd go with 'do nothing.' People who filter content > have to know that the filters are imperfect--that they may be trapping > dolphins with their catch of tuna. > I would also vote for doing nothing. I really dont see any good reason to over-react in this way, especially since (if I understand correctly) this problem was rectified by the filtering agency within 48 hours of our reporting the problem. We would introduce a whole load of broken links to counter a non-existent problem which only ever affected a small number of people. If we are serious about wanting to rationalise the identifiers, then we should do it properly, once for all, not in a piece meal haphazard fashion. That just looks silly. From gabriel.bodard at kcl.ac.uk Wed Jan 18 11:17:04 2012 From: gabriel.bodard at kcl.ac.uk (Gabriel Bodard) Date: Wed, 18 Jan 2012 16:17:04 +0000 Subject: [tei-council] version 2.0.1 p5subset.xml states "edition 2.0.0" In-Reply-To: <4F16EB12.5030900@retired.ox.ac.uk> References: <48F7E21F-4B77-4865-AB90-47F6AA73ADBF@edirom.de> <4F0F1AD5.4070101@uvic.ca> <4F159DC1.4010001@kcl.ac.uk> <4F160E96.2010202@oucs.ox.ac.uk> <4F16BE40.1030308@kcl.ac.uk> <1B7AE77F-D916-41EC-833C-CC01F8BDCB66@oucs.ox.ac.uk> <4F16CE1E.5080609@oucs.ox.ac.uk> <4F16EB12.5030900@retired.ox.ac.uk> Message-ID: <4F16F080.5080105@kcl.ac.uk> For the record it's still not fixed for me. When I look at in Firefox, I see no section 10.9. (There are several filters in use in ABP--the only one that we have confirmation have approved an exception for this is the one Martin made the request to...) If we could fix this with a rewrite, then it would be invisible to most people, and therefore not look silly at all. G On 2012-01-18 15:53, Lou Burnard wrote: > I would also vote for doing nothing. I really dont see any good reason > to over-react in this way, especially since (if I understand correctly) > this problem was rectified by the filtering agency within 48 hours of > our reporting the problem. We would introduce a whole load of broken > links to counter a non-existent problem which only ever affected a small > number of people. If we are serious about wanting to rationalise the > identifiers, then we should do it properly, once for all, not in a piece > meal haphazard fashion. That just looks silly. -- Dr Gabriel BODARD (Research Associate in Digital Epigraphy) Department of Digital 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 Wed Jan 18 12:13:00 2012 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Wed, 18 Jan 2012 17:13:00 +0000 Subject: [tei-council] version 2.0.1 p5subset.xml states "edition 2.0.0" In-Reply-To: <4F16EB12.5030900@retired.ox.ac.uk> References: <48F7E21F-4B77-4865-AB90-47F6AA73ADBF@edirom.de> <4F0F1AD5.4070101@uvic.ca> <4F159DC1.4010001@kcl.ac.uk> <4F160E96.2010202@oucs.ox.ac.uk> <4F16BE40.1030308@kcl.ac.uk> <1B7AE77F-D916-41EC-833C-CC01F8BDCB66@oucs.ox.ac.uk> <4F16CE1E.5080609@oucs.ox.ac.uk> <4F16EB12.5030900@retired.ox.ac.uk> Message-ID: <1FB0CF37-4883-42F7-B3BA-F4D382DF3F43@oucs.ox.ac.uk> On 18 Jan 2012, at 15:53, Lou Burnard wrote: > our reporting the problem. We would introduce a whole load of broken > links to counter a non-existent problem which only ever affected a small > number of people. If we are serious about wanting to rationalise the > identifiers, then we should do it properly, once for all, not in a piece > meal haphazard fashion. That just looks silly. You're right, but I think you are over-egging it. a) the broken link problem is really minimal (and solvable if we need to), and b) change the rule for MS that we use the suffix "mss" instead of "ms" is perfectly rational and not a change to practice. I still vote for "do nothing" as well, but shan't cry if we go for rational ID rename. -- Stormageddon Rahtz Head of Information and Support Group Oxford University Computing Services 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 Jan 18 12:14:58 2012 From: mholmes at uvic.ca (Martin Holmes) Date: Wed, 18 Jan 2012 09:14:58 -0800 Subject: [tei-council] version 2.0.1 p5subset.xml states "edition 2.0.0" In-Reply-To: <4F16EB12.5030900@retired.ox.ac.uk> References: <48F7E21F-4B77-4865-AB90-47F6AA73ADBF@edirom.de> <4F0F1AD5.4070101@uvic.ca> <4F159DC1.4010001@kcl.ac.uk> <4F160E96.2010202@oucs.ox.ac.uk> <4F16BE40.1030308@kcl.ac.uk> <1B7AE77F-D916-41EC-833C-CC01F8BDCB66@oucs.ox.ac.uk> <4F16CE1E.5080609@oucs.ox.ac.uk> <4F16EB12.5030900@retired.ox.ac.uk> Message-ID: <4F16FE12.3010406@uvic.ca> On 12-01-18 07:53 AM, Lou Burnard wrote: > On 18/01/12 15:38, Paul F. Schaffner wrote: >> On Wed, 18 Jan 2012, James Cummings wrote: >> >>> On 18/01/12 12:54, Sebastian Rahtz wrote: >>>>> 2& 3 both have the problem that is bothering Sebastian, but 3 is of >>>>> course much worse in this case (2 being in practice (a) easy and (b) >>>>> relatively minor inconvenience to anybody). I don't suppose you can >>>>> write a rewrite rule for file fragments, can you? >>>> yes, given careful thought, I think we could trap #msad and rewrite to #mssad. >>>> I'm not volunteering, mind, you can spend whole days understanding >>>> Apache mod_rewrite :-} >>> >>> Any disagreements that this is the right course of action? >> >> If I had to vote, I'd go with 'do nothing.' People who filter content >> have to know that the filters are imperfect--that they may be trapping >> dolphins with their catch of tuna. >> > > I would also vote for doing nothing. I really dont see any good reason > to over-react in this way, especially since (if I understand correctly) > this problem was rectified by the filtering agency within 48 hours of > our reporting the problem. We would introduce a whole load of broken > links to counter a non-existent problem which only ever affected a small > number of people. If we are serious about wanting to rationalise the > identifiers, then we should do it properly, once for all, not in a piece > meal haphazard fashion. That just looks silly. The EasyList maintainer fixed the problem immediately, but the Fanboy list maintainer has ignored my false-positive report completely (and has meanwhile been updating his/her block list regularly). So there probably are users out there still suffering from this problem, and other block lists we don't know about that include it. That's why I like #3 as a long-term option. Someday some ad company might decide to prefix all of its ids with "tei_". However, in that case, we would at least see a consistent and dramatic effect, and we could take more concerted steps to get the false-positives fixed, as well as recommending publicly that users avoid specific lists we know have the problem. When it's just a question of a single div in a single chapter, it's not worth worrying about, I don't think. Cheers, Martin -- Martin Holmes University of Victoria Humanities Computing and Media Centre (mholmes at uvic.ca) From mholmes at uvic.ca Wed Jan 18 12:16:05 2012 From: mholmes at uvic.ca (Martin Holmes) Date: Wed, 18 Jan 2012 09:16:05 -0800 Subject: [tei-council] version 2.0.1 p5subset.xml states "edition 2.0.0" In-Reply-To: <4F16F080.5080105@kcl.ac.uk> References: <48F7E21F-4B77-4865-AB90-47F6AA73ADBF@edirom.de> <4F0F1AD5.4070101@uvic.ca> <4F159DC1.4010001@kcl.ac.uk> <4F160E96.2010202@oucs.ox.ac.uk> <4F16BE40.1030308@kcl.ac.uk> <1B7AE77F-D916-41EC-833C-CC01F8BDCB66@oucs.ox.ac.uk> <4F16CE1E.5080609@oucs.ox.ac.uk> <4F16EB12.5030900@retired.ox.ac.uk> <4F16F080.5080105@kcl.ac.uk> Message-ID: <4F16FE55.2020304@uvic.ca> Which blocklist are you using? We should go after that one too. Cheers, Martin On 12-01-18 08:17 AM, Gabriel Bodard wrote: > For the record it's still not fixed for me. When I look at > in > Firefox, I see no section 10.9. > > (There are several filters in use in ABP--the only one that we have > confirmation have approved an exception for this is the one Martin made > the request to...) > > If we could fix this with a rewrite, then it would be invisible to most > people, and therefore not look silly at all. > > G > > On 2012-01-18 15:53, Lou Burnard wrote: >> I would also vote for doing nothing. I really dont see any good reason >> to over-react in this way, especially since (if I understand correctly) >> this problem was rectified by the filtering agency within 48 hours of >> our reporting the problem. We would introduce a whole load of broken >> links to counter a non-existent problem which only ever affected a small >> number of people. If we are serious about wanting to rationalise the >> identifiers, then we should do it properly, once for all, not in a piece >> meal haphazard fashion. That just looks silly. > -- Martin Holmes University of Victoria Humanities Computing and Media Centre (mholmes at uvic.ca) From sebastian.rahtz at oucs.ox.ac.uk Wed Jan 18 13:41:56 2012 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Wed, 18 Jan 2012 18:41:56 +0000 Subject: [tei-council] Ann Arbor spring meeting In-Reply-To: References: Message-ID: <8D7B6E12-1923-4DFB-B676-DF361DE81C40@oucs.ox.ac.uk> On 22 Dec 2011, at 14:12, Rebecca Welzenbach wrote: > Dear colleagues, > > Most of you have filled out the MeetingWizard poll to determine a time > to meet this spring, and so far there is one possibility that works > for all those who have responded (Christmas miracle!): Monday, April > 16-Wednesday April 18. is this confirmed now? trying to make family holiday plans. -- Stormageddon Rahtz Head of Information and Support Group, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From rwelzenbach at gmail.com Fri Jan 20 11:32:47 2012 From: rwelzenbach at gmail.com (Rebecca Welzenbach) Date: Fri, 20 Jan 2012 11:32:47 -0500 Subject: [tei-council] Ann Arbor spring meeting In-Reply-To: <8D7B6E12-1923-4DFB-B676-DF361DE81C40@oucs.ox.ac.uk> References: <8D7B6E12-1923-4DFB-B676-DF361DE81C40@oucs.ox.ac.uk> Message-ID: Hi all, I recommend that we confirm April 16-18 as the dates for our meeting. James and I had some communication about this last week and I proposed this to him, but I haven't heard back since then, and wasn't sure if he should give the go-ahead to move forward. Becky On Wed, Jan 18, 2012 at 1:41 PM, Sebastian Rahtz wrote: > > On 22 Dec 2011, at 14:12, Rebecca Welzenbach wrote: > >> Dear colleagues, >> >> Most of you have filled out the MeetingWizard poll to determine a time >> to meet this spring, and so far there is one possibility that works >> for all those who have responded (Christmas miracle!): Monday, April >> 16-Wednesday April 18. > > > > is this confirmed now? trying to make family holiday plans. > -- > Stormageddon Rahtz > Head of Information and Support Group, Oxford University Computing Services > 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 20 11:41:31 2012 From: mholmes at uvic.ca (Martin Holmes) Date: Fri, 20 Jan 2012 08:41:31 -0800 Subject: [tei-council] Ann Arbor spring meeting In-Reply-To: References: <8D7B6E12-1923-4DFB-B676-DF361DE81C40@oucs.ox.ac.uk> Message-ID: <4F19993B.5040606@uvic.ca> The sooner the better, I think -- plane tickets get more expensive as we get closer. Cheers, Martin On 12-01-20 08:32 AM, Rebecca Welzenbach wrote: > Hi all, > > I recommend that we confirm April 16-18 as the dates for our meeting. > James and I had some communication about this last week and I proposed > this to him, but I haven't heard back since then, and wasn't sure if > he should give the go-ahead to move forward. > > Becky > > > On Wed, Jan 18, 2012 at 1:41 PM, Sebastian Rahtz > wrote: >> >> On 22 Dec 2011, at 14:12, Rebecca Welzenbach wrote: >> >>> Dear colleagues, >>> >>> Most of you have filled out the MeetingWizard poll to determine a time >>> to meet this spring, and so far there is one possibility that works >>> for all those who have responded (Christmas miracle!): Monday, April >>> 16-Wednesday April 18. >> >> >> >> is this confirmed now? trying to make family holiday plans. >> -- >> Stormageddon Rahtz >> Head of Information and Support Group, Oxford University Computing Services >> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 >> >> S?lo le pido a Dios >> que el futuro no me sea indiferente >> -- Martin Holmes University of Victoria Humanities Computing and Media Centre (mholmes at uvic.ca) From James.Cummings at oucs.ox.ac.uk Fri Jan 20 11:51:56 2012 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Fri, 20 Jan 2012 16:51:56 +0000 Subject: [tei-council] Ann Arbor spring meeting In-Reply-To: References: <8D7B6E12-1923-4DFB-B676-DF361DE81C40@oucs.ox.ac.uk> Message-ID: <4F199BAC.6090007@oucs.ox.ac.uk> On 20/01/12 16:32, Rebecca Welzenbach wrote: > Hi all, > > I recommend that we confirm April 16-18 as the dates for our meeting. > James and I had some communication about this last week and I proposed > this to him, but I haven't heard back since then, and wasn't sure if > he should give the go-ahead to move forward. Hi, Sorry about that. Yes, I say we confirm those dates and everyone put them in their diary RIGHT NOW! So that is travel on the 15th, Meetings on the 16/17/18 with potentially travel home on evening of the 18th. At least that is what I'm going to try to find in our flight booking system if possible. (One can of course stay longer, but TEI-C won't cover your accommodation.) -James -- Dr James Cummings, InfoDev, Computing Services, University of Oxford From mholmes at uvic.ca Fri Jan 20 13:36:50 2012 From: mholmes at uvic.ca (Martin Holmes) Date: Fri, 20 Jan 2012 10:36:50 -0800 Subject: [tei-council] Ann Arbor spring meeting In-Reply-To: <4F199BAC.6090007@oucs.ox.ac.uk> References: <8D7B6E12-1923-4DFB-B676-DF361DE81C40@oucs.ox.ac.uk> <4F199BAC.6090007@oucs.ox.ac.uk> Message-ID: <4F19B442.8030301@uvic.ca> Re leaving on the 18th: how do we stand on staying the night of the 18th and travelling back the next day? I think I'd have to leave pretty early to get back to Victoria without overnighting somewhere, so the 18th wouldn't be much of a work day. Cheers, Martin On 12-01-20 08:51 AM, James Cummings wrote: > On 20/01/12 16:32, Rebecca Welzenbach wrote: >> Hi all, >> >> I recommend that we confirm April 16-18 as the dates for our meeting. >> James and I had some communication about this last week and I proposed >> this to him, but I haven't heard back since then, and wasn't sure if >> he should give the go-ahead to move forward. > > Hi, > > Sorry about that. Yes, I say we confirm those dates and everyone > put them in their diary RIGHT NOW! So that is travel on the > 15th, Meetings on the 16/17/18 with potentially travel home on > evening of the 18th. At least that is what I'm going to try to > find in our flight booking system if possible. (One can of > course stay longer, but TEI-C won't cover your accommodation.) > > -James > -- Martin Holmes University of Victoria Humanities Computing and Media Centre (mholmes at uvic.ca) From James.Cummings at oucs.ox.ac.uk Fri Jan 20 13:55:06 2012 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Fri, 20 Jan 2012 18:55:06 +0000 Subject: [tei-council] Ann Arbor spring meeting In-Reply-To: <4F19B442.8030301@uvic.ca> References: <8D7B6E12-1923-4DFB-B676-DF361DE81C40@oucs.ox.ac.uk> <4F199BAC.6090007@oucs.ox.ac.uk> <4F19B442.8030301@uvic.ca> Message-ID: <4F19B88A.8090802@oucs.ox.ac.uk> On 20/01/12 18:36, Martin Holmes wrote: > Re leaving on the 18th: how do we stand on staying the night of the 18th > and travelling back the next day? I think I'd have to leave pretty early > to get back to Victoria without overnighting somewhere, so the 18th > wouldn't be much of a work day. We probably have some degree flexibility on this, especially if everyone doesn't need it. The draft budget was done assuming 3 nights hotel at each meeting. But we might be able to get discounts which could offset some people staying for a fourth night. (of course, in interest of saving more of the budget for other work, I remind council members if they know of any institutional or other funding for such things as travel to start applying for them now. ;-) ) -James > > Cheers, > Martin > > On 12-01-20 08:51 AM, James Cummings wrote: >> On 20/01/12 16:32, Rebecca Welzenbach wrote: >>> Hi all, >>> >>> I recommend that we confirm April 16-18 as the dates for our meeting. >>> James and I had some communication about this last week and I proposed >>> this to him, but I haven't heard back since then, and wasn't sure if >>> he should give the go-ahead to move forward. >> >> Hi, >> >> Sorry about that. Yes, I say we confirm those dates and everyone >> put them in their diary RIGHT NOW! So that is travel on the >> 15th, Meetings on the 16/17/18 with potentially travel home on >> evening of the 18th. At least that is what I'm going to try to >> find in our flight booking system if possible. (One can of >> course stay longer, but TEI-C won't cover your accommodation.) >> >> -James >> > -- Dr James Cummings, InfoDev, Computing Services, University of Oxford From kevin.s.hawkins at ultraslavonic.info Sun Jan 22 11:47:26 2012 From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins) Date: Sun, 22 Jan 2012 11:47:26 -0500 Subject: [tei-council] version 2.0.1 p5subset.xml states "edition 2.0.0" In-Reply-To: <72C9A5F5-636A-4825-8F4D-61FB296317BF@oucs.ox.ac.uk> References: <48F7E21F-4B77-4865-AB90-47F6AA73ADBF@edirom.de> <4F0F1AD5.4070101@uvic.ca> <72C9A5F5-636A-4825-8F4D-61FB296317BF@oucs.ox.ac.uk> Message-ID: <4F1C3D9E.7060205@ultraslavonic.info> It looks like http://www.tei-c.org/Activities/Council/Working/tcw20.xml still needs to be edited to add two steps: a) update b) create tags in subversion James mentioned he would update this document over the holidays perhaps hasn't committed his changes in OpenCMS. As for making these fixes in time for the next release, Martin created a ticket about (a): http://purl.org/TEI/BUGS/3472984 whereas for (b), I believe the tags Sebastian created ( http://listserv.brown.edu/archives/cgi-bin/wa?A2=ind1201&L=TEI-L&P=R5601 ) are for 2.0.1, not the next release. So that will need to be done as well. --K. On 1/12/12 12:44 PM, Sebastian Rahtz wrote: > > On 12 Jan 2012, at 17:39, Martin Holmes wrote: > >> Hi all, >> >> I think we need to release a 2.0.2 soon, during which we again run >> through the instructions, after adding the tagging instruction. > > I have a script maketag which says > > svn cp -m "create tag of P5 release $1" -r "{$2}" \ > https://tei.svn.sourceforge.net/svnroot/tei/trunk/P5 \ > https://tei.svn.sourceforge.net/svnroot/tei/tags/P5_release_$1/ > > as in > > sh ../maketag 2.0.1 2011-12-22 > > for retrospective addition of tags. better done on the way without the -r > >> Should >> we do a quick trawl through the tickets and decide which ones might be >> polished off quickly without controversy? > if they change the content model, we'd go to 2.1.0?. > >> >> Can I be the one to go through the release steps this time? > > > we have not resolved the Debian issue yet. the sticking point > is updating repo on a Fedora box > -- > Stormageddon Rahtz > Head of Information and Support Group > Oxford University Computing Services > 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 23 11:20:51 2012 From: mholmes at uvic.ca (Martin Holmes) Date: Mon, 23 Jan 2012 08:20:51 -0800 Subject: [tei-council] version 2.0.1 p5subset.xml states "edition 2.0.0" In-Reply-To: <4F1C3D9E.7060205@ultraslavonic.info> References: <48F7E21F-4B77-4865-AB90-47F6AA73ADBF@edirom.de> <4F0F1AD5.4070101@uvic.ca> <72C9A5F5-636A-4825-8F4D-61FB296317BF@oucs.ox.ac.uk> <4F1C3D9E.7060205@ultraslavonic.info> Message-ID: <4F1D88E3.7010708@uvic.ca> With regard to a) below, the issue is that the p5subset.xml file ended up with the wrong version number. As far as I can tell from reading the Makefile, p5subset.xml is created like this: ${SAXON} ${SAXON_ARGS} -o:p5subset.xml ${DRIVER} Utilities/subset.xsl where $(DRIVER) DRIVER=${SOURCETREE}/guidelines-${INPUTLANGUAGE}.xml, presumably meaning guidelines-en.xml. So the output info comes from the tag in the guidelines-en.xml file, and that's what should be edited right at the beginning of the process. The first section in this part of tcw20.xml says: [quote] Creating a new file release First edit the file VERSION, and make it say what you are about to release... [/quote] Would it be sufficient to add this: "At the same time, edit P5/Source/guidelines-en.xml to update the information in the / tag to match the VERSION file." Cheers, Martin On 12-01-22 08:47 AM, Kevin Hawkins wrote: > It looks like > > http://www.tei-c.org/Activities/Council/Working/tcw20.xml > > still needs to be edited to add two steps: > > a) update > > b) create tags in subversion > > James mentioned he would update this document over the holidays perhaps > hasn't committed his changes in OpenCMS. > > As for making these fixes in time for the next release, Martin created a > ticket about (a): > > http://purl.org/TEI/BUGS/3472984 > > whereas for (b), I believe the tags Sebastian created ( > http://listserv.brown.edu/archives/cgi-bin/wa?A2=ind1201&L=TEI-L&P=R5601 > ) are for 2.0.1, not the next release. So that will need to be done as > well. > > --K. > > On 1/12/12 12:44 PM, Sebastian Rahtz wrote: >> >> On 12 Jan 2012, at 17:39, Martin Holmes wrote: >> >>> Hi all, >>> >>> I think we need to release a 2.0.2 soon, during which we again run >>> through the instructions, after adding the tagging instruction. >> >> I have a script maketag which says >> >> svn cp -m "create tag of P5 release $1" -r "{$2}" \ >> https://tei.svn.sourceforge.net/svnroot/tei/trunk/P5 \ >> https://tei.svn.sourceforge.net/svnroot/tei/tags/P5_release_$1/ >> >> as in >> >> sh ../maketag 2.0.1 2011-12-22 >> >> for retrospective addition of tags. better done on the way without the -r >> >>> Should >>> we do a quick trawl through the tickets and decide which ones might be >>> polished off quickly without controversy? >> if they change the content model, we'd go to 2.1.0?. >> >>> >>> Can I be the one to go through the release steps this time? >> >> >> we have not resolved the Debian issue yet. the sticking point >> is updating repo on a Fedora box >> -- >> Stormageddon Rahtz >> Head of Information and Support Group >> Oxford University Computing Services >> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 >> >> S?lo le pido a Dios >> que el futuro no me sea indiferente >> -- Martin Holmes University of Victoria Humanities Computing and Media Centre (mholmes at uvic.ca) From sebastian.rahtz at oucs.ox.ac.uk Mon Jan 23 11:50:51 2012 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 23 Jan 2012 16:50:51 +0000 Subject: [tei-council] version 2.0.1 p5subset.xml states "edition 2.0.0" In-Reply-To: <4F1D88E3.7010708@uvic.ca> References: <48F7E21F-4B77-4865-AB90-47F6AA73ADBF@edirom.de> <4F0F1AD5.4070101@uvic.ca> <72C9A5F5-636A-4825-8F4D-61FB296317BF@oucs.ox.ac.uk> <4F1C3D9E.7060205@ultraslavonic.info> <4F1D88E3.7010708@uvic.ca> Message-ID: <9E3A94AC-64C6-4B4E-8258-C271EC350D78@oucs.ox.ac.uk> On 23 Jan 2012, at 16:20, Martin Holmes wrote: > Would it be sufficient to add this: > > "At the same time, edit P5/Source/guidelines-en.xml to update the > information in the / tag to match the VERSION file." > is it all in editionStmt? i.e. date and version? but yes, that sounds right -- Stormageddon Rahtz Head of Information and Support Group Oxford University Computing Services 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 23 11:59:03 2012 From: mholmes at uvic.ca (Martin Holmes) Date: Mon, 23 Jan 2012 08:59:03 -0800 Subject: [tei-council] version 2.0.1 p5subset.xml states "edition 2.0.0" In-Reply-To: <9E3A94AC-64C6-4B4E-8258-C271EC350D78@oucs.ox.ac.uk> References: <48F7E21F-4B77-4865-AB90-47F6AA73ADBF@edirom.de> <4F0F1AD5.4070101@uvic.ca> <72C9A5F5-636A-4825-8F4D-61FB296317BF@oucs.ox.ac.uk> <4F1C3D9E.7060205@ultraslavonic.info> <4F1D88E3.7010708@uvic.ca> <9E3A94AC-64C6-4B4E-8258-C271EC350D78@oucs.ox.ac.uk> Message-ID: <4F1D91D7.80102@uvic.ca> Yes, it looks like this: 2.0.1 Last updated on 22nd December 2011. If no-one objects, I'll add this to the tcw. Cheers, Martin On 12-01-23 08:50 AM, Sebastian Rahtz wrote: > > On 23 Jan 2012, at 16:20, Martin Holmes wrote: >> Would it be sufficient to add this: >> >> "At the same time, edit P5/Source/guidelines-en.xml to update the >> information in the/ tag to match the VERSION file." >> > is it all in editionStmt? i.e. date and version? but yes, that sounds right > > -- > Stormageddon Rahtz > Head of Information and Support Group > Oxford University Computing Services > 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 > > S?lo le pido a Dios > que el futuro no me sea indiferente > > -- Martin Holmes University of Victoria Humanities Computing and Media Centre (mholmes at uvic.ca) From James.Cummings at oucs.ox.ac.uk Mon Jan 23 12:17:02 2012 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Mon, 23 Jan 2012 17:17:02 +0000 Subject: [tei-council] version 2.0.1 p5subset.xml states "edition 2.0.0" In-Reply-To: <4F1D91D7.80102@uvic.ca> References: <48F7E21F-4B77-4865-AB90-47F6AA73ADBF@edirom.de> <4F0F1AD5.4070101@uvic.ca> <72C9A5F5-636A-4825-8F4D-61FB296317BF@oucs.ox.ac.uk> <4F1C3D9E.7060205@ultraslavonic.info> <4F1D88E3.7010708@uvic.ca> <9E3A94AC-64C6-4B4E-8258-C271EC350D78@oucs.ox.ac.uk> <4F1D91D7.80102@uvic.ca> Message-ID: <4F1D960E.8020203@oucs.ox.ac.uk> Hi all, See now, I thought I changed that when doing 2.0.1 (and there it is changed)... How come the DTD fragments (was that it?) didn't get changed? Is there another place I was supposed to change it that I didn't? I didn't update tcw20 because there wasn't much different, in fact the process was all very smooth and seemed to be fine. I'll write up a step by step list for Martin to check through when he does it to double-check. -James On 23/01/12 16:59, Martin Holmes wrote: > Yes, it looks like this: > > > 2.0.1 Last updated on22nd > December 2011. > > > If no-one objects, I'll add this to the tcw. > > Cheers, > Martin > > On 12-01-23 08:50 AM, Sebastian Rahtz wrote: >> >> On 23 Jan 2012, at 16:20, Martin Holmes wrote: >>> Would it be sufficient to add this: >>> >>> "At the same time, edit P5/Source/guidelines-en.xml to update the >>> information in the/ tag to match the VERSION file." >>> >> is it all in editionStmt? i.e. date and version? but yes, that sounds right >> >> -- >> Stormageddon Rahtz >> Head of Information and Support Group >> Oxford University Computing 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 James Cummings, InfoDev, Computing Services, University of Oxford From mholmes at uvic.ca Mon Jan 23 13:12:07 2012 From: mholmes at uvic.ca (Martin Holmes) Date: Mon, 23 Jan 2012 10:12:07 -0800 Subject: [tei-council] version 2.0.1 p5subset.xml states "edition 2.0.0" In-Reply-To: <4F1D91D7.80102@uvic.ca> References: <48F7E21F-4B77-4865-AB90-47F6AA73ADBF@edirom.de> <4F0F1AD5.4070101@uvic.ca> <72C9A5F5-636A-4825-8F4D-61FB296317BF@oucs.ox.ac.uk> <4F1C3D9E.7060205@ultraslavonic.info> <4F1D88E3.7010708@uvic.ca> <9E3A94AC-64C6-4B4E-8258-C271EC350D78@oucs.ox.ac.uk> <4F1D91D7.80102@uvic.ca> Message-ID: <4F1DA2F7.2020802@uvic.ca> That's done. Next is the bit about creating tags in SVN. Cheers, Martin On 12-01-23 08:59 AM, Martin Holmes wrote: > Yes, it looks like this: > > > 2.0.1 Last updated on22nd > December 2011. > > > If no-one objects, I'll add this to the tcw. > > Cheers, > Martin > > On 12-01-23 08:50 AM, Sebastian Rahtz wrote: >> >> On 23 Jan 2012, at 16:20, Martin Holmes wrote: >>> Would it be sufficient to add this: >>> >>> "At the same time, edit P5/Source/guidelines-en.xml to update the >>> information in the/ tag to match the VERSION file." >>> >> is it all in editionStmt? i.e. date and version? but yes, that sounds right >> >> -- >> Stormageddon Rahtz >> Head of Information and Support Group >> Oxford University Computing Services >> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 >> >> S?lo le pido a Dios >> que el futuro no me sea indiferente >> >> > -- Martin Holmes University of Victoria Humanities Computing and Media Centre (mholmes at uvic.ca) From mholmes at uvic.ca Mon Jan 23 13:15:03 2012 From: mholmes at uvic.ca (Martin Holmes) Date: Mon, 23 Jan 2012 10:15:03 -0800 Subject: [tei-council] version 2.0.1 p5subset.xml states "edition 2.0.0" In-Reply-To: <4F1D960E.8020203@oucs.ox.ac.uk> References: <48F7E21F-4B77-4865-AB90-47F6AA73ADBF@edirom.de> <4F0F1AD5.4070101@uvic.ca> <72C9A5F5-636A-4825-8F4D-61FB296317BF@oucs.ox.ac.uk> <4F1C3D9E.7060205@ultraslavonic.info> <4F1D88E3.7010708@uvic.ca> <9E3A94AC-64C6-4B4E-8258-C271EC350D78@oucs.ox.ac.uk> <4F1D91D7.80102@uvic.ca> <4F1D960E.8020203@oucs.ox.ac.uk> Message-ID: <4F1DA3A7.90905@uvic.ca> Do you want to add the svn tags bit to tcw20.xml while you're at it? Then I can slavishly follow the steps there, and we'll see if everything works this time around. Cheers, Martin On 12-01-23 09:17 AM, James Cummings wrote: > Hi all, > > See now, I thought I changed that when doing 2.0.1 (and there it > is changed)... How come the DTD fragments (was that it?) didn't > get changed? Is there another place I was supposed to change it > that I didn't? > > I didn't update tcw20 because there wasn't much different, in > fact the process was all very smooth and seemed to be fine. I'll > write up a step by step list for Martin to check through when he > does it to double-check. > > -James > > On 23/01/12 16:59, Martin Holmes wrote: >> Yes, it looks like this: >> >> >> 2.0.1 Last updated on22nd >> December 2011. >> >> >> If no-one objects, I'll add this to the tcw. >> >> Cheers, >> Martin >> >> On 12-01-23 08:50 AM, Sebastian Rahtz wrote: >>> >>> On 23 Jan 2012, at 16:20, Martin Holmes wrote: >>>> Would it be sufficient to add this: >>>> >>>> "At the same time, edit P5/Source/guidelines-en.xml to update the >>>> information in the/ tag to match the VERSION file." >>>> >>> is it all in editionStmt? i.e. date and version? but yes, that sounds right >>> >>> -- >>> Stormageddon Rahtz >>> Head of Information and Support Group >>> Oxford University Computing Services >>> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 >>> >>> S?lo le pido a Dios >>> que el futuro no me sea indiferente >>> >>> >> > > -- Martin Holmes University of Victoria Humanities Computing and Media Centre (mholmes at uvic.ca) From James.Cummings at oucs.ox.ac.uk Tue Jan 24 06:15:00 2012 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Tue, 24 Jan 2012 11:15:00 +0000 Subject: [tei-council] Ann Arbor spring meeting In-Reply-To: <4F19B88A.8090802@oucs.ox.ac.uk> References: <8D7B6E12-1923-4DFB-B676-DF361DE81C40@oucs.ox.ac.uk> <4F199BAC.6090007@oucs.ox.ac.uk> <4F19B442.8030301@uvic.ca> <4F19B88A.8090802@oucs.ox.ac.uk> Message-ID: <4F1E92B4.2060809@oucs.ox.ac.uk> I've been looking at booking a flight from LHR to DTW for this meeting and the cheapest I could find for Sunday - Wednesday was 1045 pounds. However, if I included the Saturday, then the cheapest was around 538 pounds. I find the bizarre notion that one must include a Saturday (or be penalised by doubling the price) a strange one. The only 'overnight' flights I could find involved 15 hour layovers. Gaby, Piotr, Sebastian, Lou: Does it make sense then for those of us crossing the Atlantic to fly into DTW on Saturday? Charging the TEI for an extra day of hotel seems offset by the difference in flight cost. Let me know what you think, -James On 20/01/12 18:55, James Cummings wrote: > On 20/01/12 18:36, Martin Holmes wrote: >> Re leaving on the 18th: how do we stand on staying the night of the 18th >> and travelling back the next day? I think I'd have to leave pretty early >> to get back to Victoria without overnighting somewhere, so the 18th >> wouldn't be much of a work day. > > We probably have some degree flexibility on this, especially if everyone > doesn't need it. The draft budget was done assuming 3 nights hotel at > each meeting. But we might be able to get discounts which could offset > some people staying for a fourth night. > > (of course, in interest of saving more of the budget for other work, I > remind council members if they know of any institutional or other > funding for such things as travel to start applying for them now. ;-) ) > > -James > >> >> Cheers, >> Martin >> >> On 12-01-20 08:51 AM, James Cummings wrote: >>> On 20/01/12 16:32, Rebecca Welzenbach wrote: >>>> Hi all, >>>> >>>> I recommend that we confirm April 16-18 as the dates for our meeting. >>>> James and I had some communication about this last week and I proposed >>>> this to him, but I haven't heard back since then, and wasn't sure if >>>> he should give the go-ahead to move forward. >>> >>> Hi, >>> >>> Sorry about that. Yes, I say we confirm those dates and everyone >>> put them in their diary RIGHT NOW! So that is travel on the >>> 15th, Meetings on the 16/17/18 with potentially travel home on >>> evening of the 18th. At least that is what I'm going to try to >>> find in our flight booking system if possible. (One can of >>> course stay longer, but TEI-C won't cover your accommodation.) >>> >>> -James >>> >> > > -- Dr James Cummings, InfoDev, Computing Services, University of Oxford From gabriel.bodard at kcl.ac.uk Tue Jan 24 07:02:51 2012 From: gabriel.bodard at kcl.ac.uk (Gabriel Bodard) Date: Tue, 24 Jan 2012 12:02:51 +0000 Subject: [tei-council] Ann Arbor spring meeting In-Reply-To: <4F1E92B4.2060809@oucs.ox.ac.uk> References: <8D7B6E12-1923-4DFB-B676-DF361DE81C40@oucs.ox.ac.uk> <4F199BAC.6090007@oucs.ox.ac.uk> <4F19B442.8030301@uvic.ca> <4F19B88A.8090802@oucs.ox.ac.uk> <4F1E92B4.2060809@oucs.ox.ac.uk> Message-ID: <4F1E9DEB.2000601@kcl.ac.uk> That's pretty common, and what I'd expect. Shall we try to come up with something "useful" to do on the Sunday to make it worth the TEI's while? (I'd like to pin Sebastian down to talk about EpiDoc guidelines generation stuff, for starters... :-) ) Or will we just be catching up on sleep / jet-lag and thus making ourself more efficient and lively for the three days of the meeting? G On 2012-01-24 11:15, James Cummings wrote: > > I've been looking at booking a flight from LHR to DTW for this > meeting and the cheapest I could find for Sunday - Wednesday was > 1045 pounds. However, if I included the Saturday, then the > cheapest was around 538 pounds. I find the bizarre notion that > one must include a Saturday (or be penalised by doubling the > price) a strange one. The only 'overnight' flights I could find > involved 15 hour layovers. > > Gaby, Piotr, Sebastian, Lou: Does it make sense then for those > of us crossing the Atlantic to fly into DTW on Saturday? > Charging the TEI for an extra day of hotel seems offset by the > difference in flight cost. > > Let me know what you think, > > -James > > On 20/01/12 18:55, James Cummings wrote: >> On 20/01/12 18:36, Martin Holmes wrote: >>> Re leaving on the 18th: how do we stand on staying the night of the 18th >>> and travelling back the next day? I think I'd have to leave pretty early >>> to get back to Victoria without overnighting somewhere, so the 18th >>> wouldn't be much of a work day. >> >> We probably have some degree flexibility on this, especially if everyone >> doesn't need it. The draft budget was done assuming 3 nights hotel at >> each meeting. But we might be able to get discounts which could offset >> some people staying for a fourth night. >> >> (of course, in interest of saving more of the budget for other work, I >> remind council members if they know of any institutional or other >> funding for such things as travel to start applying for them now. ;-) ) >> >> -James >> >>> >>> Cheers, >>> Martin >>> >>> On 12-01-20 08:51 AM, James Cummings wrote: >>>> On 20/01/12 16:32, Rebecca Welzenbach wrote: >>>>> Hi all, >>>>> >>>>> I recommend that we confirm April 16-18 as the dates for our meeting. >>>>> James and I had some communication about this last week and I proposed >>>>> this to him, but I haven't heard back since then, and wasn't sure if >>>>> he should give the go-ahead to move forward. >>>> >>>> Hi, >>>> >>>> Sorry about that. Yes, I say we confirm those dates and everyone >>>> put them in their diary RIGHT NOW! So that is travel on the >>>> 15th, Meetings on the 16/17/18 with potentially travel home on >>>> evening of the 18th. At least that is what I'm going to try to >>>> find in our flight booking system if possible. (One can of >>>> course stay longer, but TEI-C won't cover your accommodation.) >>>> >>>> -James >>>> >>> >> >> > > -- Dr Gabriel BODARD (Research Associate in Digital Epigraphy) Department of Digital 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 Jan 24 07:14:44 2012 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 24 Jan 2012 12:14:44 +0000 Subject: [tei-council] Ann Arbor spring meeting In-Reply-To: <4F1E9DEB.2000601@kcl.ac.uk> References: <8D7B6E12-1923-4DFB-B676-DF361DE81C40@oucs.ox.ac.uk> <4F199BAC.6090007@oucs.ox.ac.uk> <4F19B442.8030301@uvic.ca> <4F19B88A.8090802@oucs.ox.ac.uk> <4F1E92B4.2060809@oucs.ox.ac.uk> <4F1E9DEB.2000601@kcl.ac.uk> Message-ID: <3128560C-412E-48E2-B5F7-10C4423DD364@oucs.ox.ac.uk> if we could find meeting rooms, I'd be all in favour of starting the meeting after lunch on the Sunday... -- Stormageddon Rahtz Head of Information and Support Group Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From bansp at o2.pl Tue Jan 24 07:47:36 2012 From: bansp at o2.pl (=?ISO-8859-2?Q?Piotr_Ba=F1ski?=) Date: Tue, 24 Jan 2012 13:47:36 +0100 Subject: [tei-council] Ann Arbor spring meeting In-Reply-To: <4F1E92B4.2060809@oucs.ox.ac.uk> References: <8D7B6E12-1923-4DFB-B676-DF361DE81C40@oucs.ox.ac.uk> <4F199BAC.6090007@oucs.ox.ac.uk> <4F19B442.8030301@uvic.ca> <4F19B88A.8090802@oucs.ox.ac.uk> <4F1E92B4.2060809@oucs.ox.ac.uk> Message-ID: <4F1EA868.1060101@o2.pl> Hi James, Most probably I'll be in Detroit on Sunday afternoon only, transferring locally -- I planned to arrive some three days earlier to adjust and to satisfy the Saturday condition. I wasn't planning on getting these extra nights reimbursed, of course. And, to be sure, I'm not showing up without my tracker tickets handled, I'm embarrassed enough with my delay as it is. Best, Piotr On 24/01/12 12:15, James Cummings wrote: > > I've been looking at booking a flight from LHR to DTW for this > meeting and the cheapest I could find for Sunday - Wednesday was > 1045 pounds. However, if I included the Saturday, then the > cheapest was around 538 pounds. I find the bizarre notion that > one must include a Saturday (or be penalised by doubling the > price) a strange one. The only 'overnight' flights I could find > involved 15 hour layovers. > > Gaby, Piotr, Sebastian, Lou: Does it make sense then for those > of us crossing the Atlantic to fly into DTW on Saturday? > Charging the TEI for an extra day of hotel seems offset by the > difference in flight cost. > > Let me know what you think, > > -James > > On 20/01/12 18:55, James Cummings wrote: >> On 20/01/12 18:36, Martin Holmes wrote: >>> Re leaving on the 18th: how do we stand on staying the night of the 18th >>> and travelling back the next day? I think I'd have to leave pretty early >>> to get back to Victoria without overnighting somewhere, so the 18th >>> wouldn't be much of a work day. >> >> We probably have some degree flexibility on this, especially if everyone >> doesn't need it. The draft budget was done assuming 3 nights hotel at >> each meeting. But we might be able to get discounts which could offset >> some people staying for a fourth night. >> >> (of course, in interest of saving more of the budget for other work, I >> remind council members if they know of any institutional or other >> funding for such things as travel to start applying for them now. ;-) ) >> >> -James >> >>> >>> Cheers, >>> Martin >>> >>> On 12-01-20 08:51 AM, James Cummings wrote: >>>> On 20/01/12 16:32, Rebecca Welzenbach wrote: >>>>> Hi all, >>>>> >>>>> I recommend that we confirm April 16-18 as the dates for our meeting. >>>>> James and I had some communication about this last week and I proposed >>>>> this to him, but I haven't heard back since then, and wasn't sure if >>>>> he should give the go-ahead to move forward. >>>> >>>> Hi, >>>> >>>> Sorry about that. Yes, I say we confirm those dates and everyone >>>> put them in their diary RIGHT NOW! So that is travel on the >>>> 15th, Meetings on the 16/17/18 with potentially travel home on >>>> evening of the 18th. At least that is what I'm going to try to >>>> find in our flight booking system if possible. (One can of >>>> course stay longer, but TEI-C won't cover your accommodation.) >>>> >>>> -James >>>> >>> >> >> > > From kevin.s.hawkins at ultraslavonic.info Tue Jan 24 09:42:07 2012 From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins) Date: Tue, 24 Jan 2012 09:42:07 -0500 Subject: [tei-council] Ann Arbor spring meeting In-Reply-To: <4F1E92B4.2060809@oucs.ox.ac.uk> References: <8D7B6E12-1923-4DFB-B676-DF361DE81C40@oucs.ox.ac.uk> <4F199BAC.6090007@oucs.ox.ac.uk> <4F19B442.8030301@uvic.ca> <4F19B88A.8090802@oucs.ox.ac.uk> <4F1E92B4.2060809@oucs.ox.ac.uk> Message-ID: <4F1EC33F.3070901@ultraslavonic.info> Flights within the US are commonly priced like this. It's an old arrangement between the airlines and hotels to encourage you to stay through the weekend wherever you're going. I don't think it applies to flights to and from the US, but perhaps you have a connection in the US causing this. So the situation might apply to those traveling from within the US as well. I'm sure the TEI's treasurer would agree that it saves the Consortium money for James (and anyone else in a similar situation) to arrive on Saturday and stay in a hotel the extra night. That is, you end up saving money, even with the hotel and per-diem. In the future, we might consider planning meetings to begin on a Sunday or end on a Saturday because of the likelihood of saving money. It shortens our weekends, of course, but it also is less likely to disrupt someone's teaching schedule (as has been the problem for some Council members in the past). --K. On 1/24/2012 6:15 AM, James Cummings wrote: > > I've been looking at booking a flight from LHR to DTW for this > meeting and the cheapest I could find for Sunday - Wednesday was > 1045 pounds. However, if I included the Saturday, then the > cheapest was around 538 pounds. I find the bizarre notion that > one must include a Saturday (or be penalised by doubling the > price) a strange one. The only 'overnight' flights I could find > involved 15 hour layovers. > > Gaby, Piotr, Sebastian, Lou: Does it make sense then for those > of us crossing the Atlantic to fly into DTW on Saturday? > Charging the TEI for an extra day of hotel seems offset by the > difference in flight cost. > > Let me know what you think, > > -James > > On 20/01/12 18:55, James Cummings wrote: >> On 20/01/12 18:36, Martin Holmes wrote: >>> Re leaving on the 18th: how do we stand on staying the night of the 18th >>> and travelling back the next day? I think I'd have to leave pretty early >>> to get back to Victoria without overnighting somewhere, so the 18th >>> wouldn't be much of a work day. >> >> We probably have some degree flexibility on this, especially if everyone >> doesn't need it. The draft budget was done assuming 3 nights hotel at >> each meeting. But we might be able to get discounts which could offset >> some people staying for a fourth night. >> >> (of course, in interest of saving more of the budget for other work, I >> remind council members if they know of any institutional or other >> funding for such things as travel to start applying for them now. ;-) ) >> >> -James >> >>> >>> Cheers, >>> Martin >>> >>> On 12-01-20 08:51 AM, James Cummings wrote: >>>> On 20/01/12 16:32, Rebecca Welzenbach wrote: >>>>> Hi all, >>>>> >>>>> I recommend that we confirm April 16-18 as the dates for our meeting. >>>>> James and I had some communication about this last week and I proposed >>>>> this to him, but I haven't heard back since then, and wasn't sure if >>>>> he should give the go-ahead to move forward. >>>> >>>> Hi, >>>> >>>> Sorry about that. Yes, I say we confirm those dates and everyone >>>> put them in their diary RIGHT NOW! So that is travel on the >>>> 15th, Meetings on the 16/17/18 with potentially travel home on >>>> evening of the 18th. At least that is what I'm going to try to >>>> find in our flight booking system if possible. (One can of >>>> course stay longer, but TEI-C won't cover your accommodation.) >>>> >>>> -James >>>> >>> >> >> > > From James.Cummings at oucs.ox.ac.uk Tue Jan 24 10:04:59 2012 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Tue, 24 Jan 2012 15:04:59 +0000 Subject: [tei-council] Ann Arbor spring meeting In-Reply-To: <4F1EC33F.3070901@ultraslavonic.info> References: <8D7B6E12-1923-4DFB-B676-DF361DE81C40@oucs.ox.ac.uk> <4F199BAC.6090007@oucs.ox.ac.uk> <4F19B442.8030301@uvic.ca> <4F19B88A.8090802@oucs.ox.ac.uk> <4F1E92B4.2060809@oucs.ox.ac.uk> <4F1EC33F.3070901@ultraslavonic.info> Message-ID: <4F1EC89B.3000006@oucs.ox.ac.uk> On 24/01/12 14:42, Kevin Hawkins wrote: > Flights within the US are commonly priced like this. It's an old > arrangement between the airlines and hotels to encourage you to stay > through the weekend wherever you're going. I don't think it applies to > flights to and from the US, but perhaps you have a connection in the US > causing this. Nope, direct flight from Heathrow. This is always the case when travelling to the US if you don't include a Saturday. It has affected me a number of times (and year I always forget it until it does). So I think this arrangement is implemented across the board. > So the situation might apply to those traveling from within the US as > well. I'm sure the TEI's treasurer would agree that it saves the > Consortium money for James (and anyone else in a similar situation) to > arrive on Saturday and stay in a hotel the extra night. That is, you > end up saving money, even with the hotel and per-diem. I agree, and would encourage people to book tickets accordingly. > In the future, we might consider planning meetings to begin on a Sunday > or end on a Saturday because of the likelihood of saving money. It > shortens our weekends, of course, but it also is less likely to disrupt > someone's teaching schedule (as has been the problem for some Council > members in the past). That is a good idea, but depends on local hosting arrangements. I know, for example, that it is quite difficult for us to have people in the building on a Sunday here at OUCS. (Though we could find other meeting space where that wasn't the case.) I'll consider it when planning the Oxford meeting. Becky: Do you know if we might be able to get the same meeting space on the Sunday as well? If we can, I propose that we deal with the slight vague other useful TEI stuff that Gaby suggests. (I.e. there would be no requirement for others to be there, but we'd set aside the time to work on decided TEI tickets, TEI infrastructure, EpiDoc etc.) -James -- Dr James Cummings, InfoDev, Computing Services, University of Oxford From sebastian.rahtz at oucs.ox.ac.uk Tue Jan 24 10:07:31 2012 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 24 Jan 2012 15:07:31 +0000 Subject: [tei-council] Ann Arbor spring meeting In-Reply-To: <4F1EC89B.3000006@oucs.ox.ac.uk> References: <8D7B6E12-1923-4DFB-B676-DF361DE81C40@oucs.ox.ac.uk> <4F199BAC.6090007@oucs.ox.ac.uk> <4F19B442.8030301@uvic.ca> <4F19B88A.8090802@oucs.ox.ac.uk> <4F1E92B4.2060809@oucs.ox.ac.uk> <4F1EC33F.3070901@ultraslavonic.info> <4F1EC89B.3000006@oucs.ox.ac.uk> Message-ID: <3f4cd7cd-2539-4dd2-af78-557960b2074a@exht04.ad.oak.ox.ac.uk> On 24 Jan 2012, at 15:04, James Cummings wrote: > > Becky: Do you know if we might be able to get the same meeting > space on the Sunday as well? > > If we can, I propose that we deal with the slight vague other > useful TEI stuff that Gaby suggests. (I.e. there would be no > requirement for others to be there, but we'd set aside the time > to work on decided TEI tickets, TEI infrastructure, EpiDoc etc.) I strongly suspect many of us will arrive with some "baggage" in terms of things we meant to get done before the meeting. an afternoons optional communal hacking would likely be very productive. if we get bored we can write Roma2 -- Stormageddon Rahtz Head of Information and Support Group Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From bansp at o2.pl Tue Jan 24 11:46:47 2012 From: bansp at o2.pl (=?ISO-8859-2?Q?Piotr_Ba=F1ski?=) Date: Tue, 24 Jan 2012 17:46:47 +0100 Subject: [tei-council] Ann Arbor spring meeting In-Reply-To: <4F1EC89B.3000006@oucs.ox.ac.uk> References: <8D7B6E12-1923-4DFB-B676-DF361DE81C40@oucs.ox.ac.uk> <4F199BAC.6090007@oucs.ox.ac.uk> <4F19B442.8030301@uvic.ca> <4F19B88A.8090802@oucs.ox.ac.uk> <4F1E92B4.2060809@oucs.ox.ac.uk> <4F1EC33F.3070901@ultraslavonic.info> <4F1EC89B.3000006@oucs.ox.ac.uk> Message-ID: <4F1EE077.4020202@o2.pl> I'd happily take part. Haven't bought my ticket yet because tomorrow is a discount day for the Polish airlines, so if I manage to see a suitable connection, I'll try to be there around noon instead of later in the day. The more so if Becky manages to confirm the available space (but I realise that the notice is rather short). Best, P. On 24/01/12 16:04, James Cummings wrote: [...] > Becky: Do you know if we might be able to get the same meeting > space on the Sunday as well? > > If we can, I propose that we deal with the slight vague other > useful TEI stuff that Gaby suggests. (I.e. there would be no > requirement for others to be there, but we'd set aside the time > to work on decided TEI tickets, TEI infrastructure, EpiDoc etc.) > > -James > From kevin.s.hawkins at ultraslavonic.info Tue Jan 24 11:50:46 2012 From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins) Date: Tue, 24 Jan 2012 11:50:46 -0500 Subject: [tei-council] Ann Arbor spring meeting In-Reply-To: <4F1EE077.4020202@o2.pl> References: <8D7B6E12-1923-4DFB-B676-DF361DE81C40@oucs.ox.ac.uk> <4F199BAC.6090007@oucs.ox.ac.uk> <4F19B442.8030301@uvic.ca> <4F19B88A.8090802@oucs.ox.ac.uk> <4F1E92B4.2060809@oucs.ox.ac.uk> <4F1EC33F.3070901@ultraslavonic.info> <4F1EC89B.3000006@oucs.ox.ac.uk> <4F1EE077.4020202@o2.pl> Message-ID: <4F1EE166.1030808@ultraslavonic.info> I can see the availability of the room Becky reserved for Monday-Wednesday and see that it's available on Sunday as well. Nobody ever uses that room on the weekend, and the building opens on Sundays at 10 a.m., so I'm sure it will be available all day for us to use. On 1/24/2012 11:46 AM, Piotr Ba?ski wrote: > I'd happily take part. Haven't bought my ticket yet because tomorrow is > a discount day for the Polish airlines, so if I manage to see a suitable > connection, I'll try to be there around noon instead of later in the > day. The more so if Becky manages to confirm the available space (but I > realise that the notice is rather short). > > Best, > > P. > > On 24/01/12 16:04, James Cummings wrote: > [...] >> Becky: Do you know if we might be able to get the same meeting >> space on the Sunday as well? >> >> If we can, I propose that we deal with the slight vague other >> useful TEI stuff that Gaby suggests. (I.e. there would be no >> requirement for others to be there, but we'd set aside the time >> to work on decided TEI tickets, TEI infrastructure, EpiDoc etc.) >> >> -James >> > From sebastian.rahtz at oucs.ox.ac.uk Tue Jan 24 11:51:06 2012 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 24 Jan 2012 16:51:06 +0000 Subject: [tei-council] Ann Arbor spring meeting In-Reply-To: <4F1EE077.4020202@o2.pl> References: <8D7B6E12-1923-4DFB-B676-DF361DE81C40@oucs.ox.ac.uk> <4F199BAC.6090007@oucs.ox.ac.uk> <4F19B442.8030301@uvic.ca> <4F19B88A.8090802@oucs.ox.ac.uk> <4F1E92B4.2060809@oucs.ox.ac.uk> <4F1EC33F.3070901@ultraslavonic.info> <4F1EC89B.3000006@oucs.ox.ac.uk> <4F1EE077.4020202@o2.pl> Message-ID: <5018475B-D8DD-42E9-B548-84F4E1849BB1@oucs.ox.ac.uk> On 24 Jan 2012, at 16:46, Piotr Ba?ski wrote: > The more so if Becky manages to confirm the available space (but I > realise that the notice is rather short). the worst we can do is all occupy someone's bedroom?.. -- Stormageddon Rahtz Head of Information and Support Group Oxford University Computing Services 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 Jan 24 13:32:39 2012 From: mholmes at uvic.ca (Martin Holmes) Date: Tue, 24 Jan 2012 10:32:39 -0800 Subject: [tei-council] Ann Arbor spring meeting In-Reply-To: <5018475B-D8DD-42E9-B548-84F4E1849BB1@oucs.ox.ac.uk> References: <8D7B6E12-1923-4DFB-B676-DF361DE81C40@oucs.ox.ac.uk> <4F199BAC.6090007@oucs.ox.ac.uk> <4F19B442.8030301@uvic.ca> <4F19B88A.8090802@oucs.ox.ac.uk> <4F1E92B4.2060809@oucs.ox.ac.uk> <4F1EC33F.3070901@ultraslavonic.info> <4F1EC89B.3000006@oucs.ox.ac.uk> <4F1EE077.4020202@o2.pl> <5018475B-D8DD-42E9-B548-84F4E1849BB1@oucs.ox.ac.uk> Message-ID: <4F1EF947.1030407@uvic.ca> I'm checking flight costs for myself to see if coming Saturday would be cheaper too. Is there any recommendation on where to stay? Cheers, Martin On 12-01-24 08:51 AM, Sebastian Rahtz wrote: > > On 24 Jan 2012, at 16:46, Piotr Ba?ski wrote: > >> The more so if Becky manages to confirm the available space (but I >> realise that the notice is rather short). > > > > the worst we can do is all occupy someone's bedroom?.. > -- > Stormageddon Rahtz > Head of Information and Support Group > Oxford University Computing Services > 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 > > S?lo le pido a Dios > que el futuro no me sea indiferente > -- Martin Holmes University of Victoria Humanities Computing and Media Centre (mholmes at uvic.ca) From james.cummings at oucs.ox.ac.uk Tue Jan 24 14:01:25 2012 From: james.cummings at oucs.ox.ac.uk (James Cummings) Date: Tue, 24 Jan 2012 19:01:25 +0000 Subject: [tei-council] Ann Arbor spring meeting Message-ID: Becky is looking into block booking. Let's leave accommodation until she reports back. JamesC -- James Cummings, InfoDev, OUCS, University of Oxford (via phone) Martin Holmes wrote: I'm checking flight costs for myself to see if coming Saturday would be cheaper too. Is there any recommendation on where to stay? Cheers, Martin On 12-01-24 08:51 AM, Sebastian Rahtz wrote: > > On 24 Jan 2012, at 16:46, Piotr Ba?ski wrote: > >> The more so if Becky manages to confirm the available space (but I >> realise that the notice is rather short). > > > > the worst we can do is all occupy someone's bedroom?.. > -- > Stormageddon Rahtz > Head of Information and Support Group > Oxford University Computing 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) -- tei-council mailing list tei-council at lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council PLEASE NOTE: postings to this list are publicly archived From mholmes at uvic.ca Tue Jan 24 15:51:47 2012 From: mholmes at uvic.ca (Martin Holmes) Date: Tue, 24 Jan 2012 12:51:47 -0800 Subject: [tei-council] Ann Arbor spring meeting In-Reply-To: References: Message-ID: <4F1F19E3.1000401@uvic.ca> Travelling on Saturday makes virtually no difference to my flight costs. But if it turns out that most of us are coming in on Saturday, and work will be done on Sunday, should I come on the Saturday too? Cheers, Martin On 12-01-24 11:01 AM, James Cummings wrote: > > Becky is looking into block booking. Let's leave accommodation until she reports back. > JamesC > -- > James Cummings, InfoDev, OUCS, University of Oxford (via phone) > > Martin Holmes wrote: > > > I'm checking flight costs for myself to see if coming Saturday would be > cheaper too. > > Is there any recommendation on where to stay? > > Cheers, > Martin > > On 12-01-24 08:51 AM, Sebastian Rahtz wrote: >> >> On 24 Jan 2012, at 16:46, Piotr Ba?ski wrote: >> >>> The more so if Becky manages to confirm the available space (but I >>> realise that the notice is rather short). >> >> >> >> the worst we can do is all occupy someone's bedroom?.. >> -- >> Stormageddon Rahtz >> Head of Information and Support Group >> Oxford University Computing 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) > -- > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > > PLEASE NOTE: postings to this list are publicly archived -- Martin Holmes University of Victoria Humanities Computing and Media Centre (mholmes at uvic.ca) From mholmes at uvic.ca Tue Jan 24 16:12:36 2012 From: mholmes at uvic.ca (Martin Holmes) Date: Tue, 24 Jan 2012 13:12:36 -0800 Subject: [tei-council] Ann Arbor spring meeting In-Reply-To: <4F1F19E3.1000401@uvic.ca> References: <4F1F19E3.1000401@uvic.ca> Message-ID: <4F1F1EC4.3010301@uvic.ca> I was just checking out the wifi access at UMich: "Wireless access Council members not affiliated with the University of Michigan can use MGuest. If the limited access is insufficient, the local organizers can ask Desktop Support Services to provide temporary uniqnames." The MGuest services is quite restrictive: [quote] MGuest is limited to web (http), secure web (https) secure mail services (IMAPS, POPS, SMTPS) and VPN services: HTTP 80 HTTPS 443 (TLS/SSL) POP3s 995 (TLS/SSL) IMAPs 993 (TLS/SSL) SMTPs 465 (TLS/SSL) Secure Shell (SSH) port 22 VPN access via the following ports is allowed: Protocol 47, 50 and 51 port 500 port 1701 UDP port 4500 UDP port 10000 MGuest is rate limited to 1Mbps down and 384kbps upload speeds. MGuest is treated like a non-UM network; some U-M resource such as library journals cannot be accessed. [/quote] That would presumably make my Jenkins server inaccessible, because it runs on port 8080: And we have other projects running on other ports not on the MGuest list. If it's possible to get temporary logins to the main network, MWireless, I'd be happier. I'm assuming that UMich doesn't support eduroam? Something called "Internet2, Ann Arbor" does, but I don't see any mention on the main university site. Cheers, Martin -- Martin Holmes University of Victoria Humanities Computing and Media Centre (mholmes at uvic.ca) From lou.burnard at retired.ox.ac.uk Tue Jan 24 16:47:38 2012 From: lou.burnard at retired.ox.ac.uk (Lou Burnard) Date: Tue, 24 Jan 2012 21:47:38 +0000 Subject: [tei-council] Ann Arbor spring meeting In-Reply-To: <4F1F19E3.1000401@uvic.ca> References: <4F1F19E3.1000401@uvic.ca> Message-ID: <4F1F26FA.8030203@retired.ox.ac.uk> also, if we're changing the sunday into a work day, can we go home early on the wednesday? On 24/01/12 20:51, Martin Holmes wrote: > Travelling on Saturday makes virtually no difference to my flight costs. > But if it turns out that most of us are coming in on Saturday, and work > will be done on Sunday, should I come on the Saturday too? > > Cheers, > Martin > > On 12-01-24 11:01 AM, James Cummings wrote: >> >> Becky is looking into block booking. Let's leave accommodation until she reports back. >> JamesC >> -- >> James Cummings, InfoDev, OUCS, University of Oxford (via phone) >> >> Martin Holmes wrote: >> >> >> I'm checking flight costs for myself to see if coming Saturday would be >> cheaper too. >> >> Is there any recommendation on where to stay? >> >> Cheers, >> Martin >> >> On 12-01-24 08:51 AM, Sebastian Rahtz wrote: >>> >>> On 24 Jan 2012, at 16:46, Piotr Ba?ski wrote: >>> >>>> The more so if Becky manages to confirm the available space (but I >>>> realise that the notice is rather short). >>> >>> >>> >>> the worst we can do is all occupy someone's bedroom?.. >>> -- >>> Stormageddon Rahtz >>> Head of Information and Support Group >>> Oxford University Computing 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) >> -- >> tei-council mailing list >> tei-council at lists.village.Virginia.EDU >> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council >> >> PLEASE NOTE: postings to this list are publicly archived > From mholmes at uvic.ca Tue Jan 24 17:27:21 2012 From: mholmes at uvic.ca (Martin Holmes) Date: Tue, 24 Jan 2012 14:27:21 -0800 Subject: [tei-council] Ann Arbor spring meeting In-Reply-To: <4F1F26FA.8030203@retired.ox.ac.uk> References: <4F1F19E3.1000401@uvic.ca> <4F1F26FA.8030203@retired.ox.ac.uk> Message-ID: <4F1F3049.9000804@uvic.ca> That would work for me. I'm guessing the people who actually live in Ann Arbor might get some push-back from family, though, if we turn Sunday into a work day. Cheers, Martin On 12-01-24 01:47 PM, Lou Burnard wrote: > also, if we're changing the sunday into a work day, can we go home early > on the wednesday? > > > On 24/01/12 20:51, Martin Holmes wrote: >> Travelling on Saturday makes virtually no difference to my flight costs. >> But if it turns out that most of us are coming in on Saturday, and work >> will be done on Sunday, should I come on the Saturday too? >> >> Cheers, >> Martin >> >> On 12-01-24 11:01 AM, James Cummings wrote: >>> >>> Becky is looking into block booking. Let's leave accommodation until she reports back. >>> JamesC >>> -- >>> James Cummings, InfoDev, OUCS, University of Oxford (via phone) >>> >>> Martin Holmes wrote: >>> >>> >>> I'm checking flight costs for myself to see if coming Saturday would be >>> cheaper too. >>> >>> Is there any recommendation on where to stay? >>> >>> Cheers, >>> Martin >>> >>> On 12-01-24 08:51 AM, Sebastian Rahtz wrote: >>>> >>>> On 24 Jan 2012, at 16:46, Piotr Ba?ski wrote: >>>> >>>>> The more so if Becky manages to confirm the available space (but I >>>>> realise that the notice is rather short). >>>> >>>> >>>> >>>> the worst we can do is all occupy someone's bedroom?.. >>>> -- >>>> Stormageddon Rahtz >>>> Head of Information and Support Group >>>> Oxford University Computing 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) >>> -- >>> tei-council mailing list >>> tei-council at lists.village.Virginia.EDU >>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council >>> >>> PLEASE NOTE: postings to this list are publicly archived >> > -- Martin Holmes University of Victoria Humanities Computing and Media Centre (mholmes at uvic.ca) From kevin.s.hawkins at ultraslavonic.info Tue Jan 24 18:51:11 2012 From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins) Date: Tue, 24 Jan 2012 18:51:11 -0500 Subject: [tei-council] Ann Arbor spring meeting In-Reply-To: <4F1F1EC4.3010301@uvic.ca> References: <4F1F19E3.1000401@uvic.ca> <4F1F1EC4.3010301@uvic.ca> Message-ID: <4F1F43EF.8090904@ultraslavonic.info> Martin, thanks for investigating what MGuest offers and what we need. You're right that it's insufficient for our needs, so we'll need to get temporary accounts for everyone. This is similar to what we did for the 2009 conference and it shouldn't be a problem. (U-M is testing eduRoam, but it's not functional yet.) On 1/24/2012 4:12 PM, Martin Holmes wrote: > I was just checking out the wifi access at UMich: > > "Wireless access > Council members not affiliated with the University of Michigan can use > MGuest. If the limited access is insufficient, the local organizers can > ask Desktop Support Services to provide temporary uniqnames." > > The MGuest services is quite restrictive: > > [quote] > MGuest is limited to web (http), secure web (https) secure mail services > (IMAPS, POPS, SMTPS) and VPN services: > > HTTP 80 > HTTPS 443 (TLS/SSL) > POP3s 995 (TLS/SSL) > IMAPs 993 (TLS/SSL) > SMTPs 465 (TLS/SSL) > Secure Shell (SSH) port 22 > > VPN access via the following ports is allowed: > > Protocol 47, 50 and 51 > port 500 > port 1701 > UDP port 4500 > UDP port 10000 > > MGuest is rate limited to 1Mbps down and 384kbps upload speeds. > > MGuest is treated like a non-UM network; some U-M resource such as > library journals cannot be accessed. > [/quote] > > That would presumably make my Jenkins server inaccessible, because it > runs on port 8080: > > > > And we have other projects running on other ports not on the MGuest > list. If it's possible to get temporary logins to the main network, > MWireless, I'd be happier. I'm assuming that UMich doesn't support > eduroam? Something called "Internet2, Ann Arbor" does, but I don't see > any mention on the main university site. > > Cheers, > Martin > From rwelzenbach at gmail.com Wed Jan 25 09:01:49 2012 From: rwelzenbach at gmail.com (Rebecca Welzenbach) Date: Wed, 25 Jan 2012 09:01:49 -0500 Subject: [tei-council] Ann Arbor spring meeting In-Reply-To: <4F1F43EF.8090904@ultraslavonic.info> References: <4F1F19E3.1000401@uvic.ca> <4F1F1EC4.3010301@uvic.ca> <4F1F43EF.8090904@ultraslavonic.info> Message-ID: Hi all, As Kevin has suggested, it should be no problem to book our meeting room for Sunday, in case those who have arrived want to use it. I'm working now with the Bell Tower Inn (http://www.belltowerhotel.com/) to reserve a group of rooms. There's a discount (about 15%) if the rooms are paid for by the University of Michigan instead of by individuals--I'm working on whether we can get approval to do this. However, if several people expect to stay for some extra, un-reimbursed time, or arrive and depart on different days, this might be too complicated to handle as a single transaction. Based on the discussion above, it looks to me like there are now a maximum of five nights eligible for reimbursement: Saturday, April 14 through Wednesday, April 18 (checking out Thursday morning). Is that right, or are we dropping Wednesday in exchange for Saturday, and not reimbursing for any stay after Tuesday night? (Or allowing four nights, *either* Saturday, *or* Wednesday?) I'm making plans based on our needing seven rooms--please let me know if I've missed anyone or if plans have suddenly changed and you don't expect to come: * James Cummings * Lou Burnard * Piotr Banski * Sebastian Rahtz * Brett Barney * Gabriel Bodard * Martin Holmes If you could reply, adding your expected arrival and departure dates after your name, that will help me with securing accommodations. Becky On Tue, Jan 24, 2012 at 6:51 PM, Kevin Hawkins wrote: > Martin, thanks for investigating what MGuest offers and what we need. > You're right that it's insufficient for our needs, so we'll need to get > temporary accounts for everyone. ?This is similar to what we did for the > 2009 conference and it shouldn't be a problem. > > (U-M is testing eduRoam, but it's not functional yet.) > > On 1/24/2012 4:12 PM, Martin Holmes wrote: >> I was just checking out the wifi access at UMich: >> >> "Wireless access >> Council members not affiliated with the University of Michigan can use >> MGuest. If the limited access is insufficient, the local organizers can >> ask Desktop Support Services to provide temporary uniqnames." >> >> The MGuest services is quite restrictive: >> >> [quote] >> MGuest is limited to web (http), secure web (https) secure mail services >> (IMAPS, POPS, SMTPS) and VPN services: >> >> ? ? ? HTTP 80 >> ? ? ? HTTPS 443 (TLS/SSL) >> ? ? ? POP3s 995 (TLS/SSL) >> ? ? ? IMAPs 993 (TLS/SSL) >> ? ? ? SMTPs 465 (TLS/SSL) >> ? ? ? Secure Shell (SSH) port 22 >> >> VPN access via the following ports is allowed: >> >> ? ? ? Protocol 47, 50 and 51 >> ? ? ? port 500 >> ? ? ? port 1701 >> ? ? ? UDP port 4500 >> ? ? ? UDP port 10000 >> >> MGuest is rate limited to 1Mbps down and 384kbps upload speeds. >> >> MGuest is treated like a non-UM network; some U-M resource such as >> library journals cannot be accessed. >> [/quote] >> >> That would presumably make my Jenkins server inaccessible, because it >> runs on port 8080: >> >> >> >> And we have other projects running on other ports not on the MGuest >> list. If it's possible to get temporary logins to the main network, >> MWireless, I'd be happier. I'm assuming that UMich doesn't support >> eduroam? Something called "Internet2, Ann Arbor" does, but I don't see >> any mention on the main university site. >> >> Cheers, >> Martin >> > -- > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > > PLEASE NOTE: postings to this list are publicly archived From lou.burnard at retired.ox.ac.uk Wed Jan 25 11:41:24 2012 From: lou.burnard at retired.ox.ac.uk (Lou Burnard) Date: Wed, 25 Jan 2012 16:41:24 +0000 Subject: [tei-council] Ann Arbor spring meeting In-Reply-To: References: <4F1F19E3.1000401@uvic.ca> <4F1F1EC4.3010301@uvic.ca> <4F1F43EF.8090904@ultraslavonic.info> Message-ID: <4F2030B4.7070605@retired.ox.ac.uk> On 25/01/12 14:01, Rebecca Welzenbach wrote: > > > I'm working now with the Bell Tower Inn > (http://www.belltowerhotel.com/) to reserve a group of rooms. Hoorah! I liked the Bell Tower when I stayed there back in the 20th century some time. > * Lou Burnard expects to be arriving on Saturday, leaving on Wednesday From mholmes at uvic.ca Wed Jan 25 11:47:34 2012 From: mholmes at uvic.ca (Martin Holmes) Date: Wed, 25 Jan 2012 08:47:34 -0800 Subject: [tei-council] Ann Arbor spring meeting In-Reply-To: References: <4F1F19E3.1000401@uvic.ca> <4F1F1EC4.3010301@uvic.ca> <4F1F43EF.8090904@ultraslavonic.info> Message-ID: <4F203226.10901@uvic.ca> I think we need to decide if the real meeting dates are Sunday 15th through Tuesday 17th. Looking at the list of attendees, there are only two of us travelling from elsewhere in North America (Brett and myself); I presume that for all the Europeans, a Saturday arrival would be better, so I would vote for changing the meeting dates to 15th-17th. If we do that, we can all head for home on the 18th (or even at the end of the 17th, if flights permit). How do the local hosts feel about losing their Sunday? Cheers, Martin On 12-01-25 06:01 AM, Rebecca Welzenbach wrote: > Hi all, > > As Kevin has suggested, it should be no problem to book our meeting > room for Sunday, in case those who have arrived want to use it. > > I'm working now with the Bell Tower Inn > (http://www.belltowerhotel.com/) to reserve a group of rooms. There's > a discount (about 15%) if the rooms are paid for by the University of > Michigan instead of by individuals--I'm working on whether we can get > approval to do this. However, if several people expect to stay for > some extra, un-reimbursed time, or arrive and depart on different > days, this might be too complicated to handle as a single transaction. > > Based on the discussion above, it looks to me like there are now a > maximum of five nights eligible for reimbursement: Saturday, April 14 > through Wednesday, April 18 (checking out Thursday morning). Is that > right, or are we dropping Wednesday in exchange for Saturday, and not > reimbursing for any stay after Tuesday night? (Or allowing four > nights, *either* Saturday, *or* Wednesday?) > > I'm making plans based on our needing seven rooms--please let me know > if I've missed anyone or if plans have suddenly changed and you don't > expect to come: > * James Cummings > * Lou Burnard > * Piotr Banski > * Sebastian Rahtz > * Brett Barney > * Gabriel Bodard > * Martin Holmes > > If you could reply, adding your expected arrival and departure dates > after your name, that will help me with securing accommodations. > > Becky > > > On Tue, Jan 24, 2012 at 6:51 PM, Kevin Hawkins > wrote: >> Martin, thanks for investigating what MGuest offers and what we need. >> You're right that it's insufficient for our needs, so we'll need to get >> temporary accounts for everyone. This is similar to what we did for the >> 2009 conference and it shouldn't be a problem. >> >> (U-M is testing eduRoam, but it's not functional yet.) >> >> On 1/24/2012 4:12 PM, Martin Holmes wrote: >>> I was just checking out the wifi access at UMich: >>> >>> "Wireless access >>> Council members not affiliated with the University of Michigan can use >>> MGuest. If the limited access is insufficient, the local organizers can >>> ask Desktop Support Services to provide temporary uniqnames." >>> >>> The MGuest services is quite restrictive: >>> >>> [quote] >>> MGuest is limited to web (http), secure web (https) secure mail services >>> (IMAPS, POPS, SMTPS) and VPN services: >>> >>> HTTP 80 >>> HTTPS 443 (TLS/SSL) >>> POP3s 995 (TLS/SSL) >>> IMAPs 993 (TLS/SSL) >>> SMTPs 465 (TLS/SSL) >>> Secure Shell (SSH) port 22 >>> >>> VPN access via the following ports is allowed: >>> >>> Protocol 47, 50 and 51 >>> port 500 >>> port 1701 >>> UDP port 4500 >>> UDP port 10000 >>> >>> MGuest is rate limited to 1Mbps down and 384kbps upload speeds. >>> >>> MGuest is treated like a non-UM network; some U-M resource such as >>> library journals cannot be accessed. >>> [/quote] >>> >>> That would presumably make my Jenkins server inaccessible, because it >>> runs on port 8080: >>> >>> >>> >>> And we have other projects running on other ports not on the MGuest >>> list. If it's possible to get temporary logins to the main network, >>> MWireless, I'd be happier. I'm assuming that UMich doesn't support >>> eduroam? Something called "Internet2, Ann Arbor" does, but I don't see >>> any mention on the main university site. >>> >>> Cheers, >>> Martin >>> >> -- >> tei-council mailing list >> tei-council at lists.village.Virginia.EDU >> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council >> >> PLEASE NOTE: postings to this list are publicly archived -- Martin Holmes University of Victoria Humanities Computing and Media Centre (mholmes at uvic.ca) From James.Cummings at oucs.ox.ac.uk Wed Jan 25 11:58:25 2012 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Wed, 25 Jan 2012 16:58:25 +0000 Subject: [tei-council] Ann Arbor spring meeting In-Reply-To: <4F203226.10901@uvic.ca> References: <4F1F19E3.1000401@uvic.ca> <4F1F1EC4.3010301@uvic.ca> <4F1F43EF.8090904@ultraslavonic.info> <4F203226.10901@uvic.ca> Message-ID: <4F2034B1.7030608@oucs.ox.ac.uk> For the record I have just booked a flight: Departing: Saturday 14 April 09:05 from LHR Arriving: Saturday 14 April 12:45 at DTW Delta Airlines 19 then Departing: Wednesday 18 April 18:45 from DTW Arriving: Thursday 19 April 07:40 at LHR Delta Airlines 18 I mention it in case either of my UK colleagues want to be on the same flight. So I'd need hotel Sat/Sun/Mon/Tues nights. If everyone is going to be there by the Sunday, then I'm not adverse to starting early. The Wednesday could be made optional for those who really need to fly home on the Tuesday night. -James On 25/01/12 16:47, Martin Holmes wrote: > I think we need to decide if the real meeting dates are Sunday 15th > through Tuesday 17th. Looking at the list of attendees, there are only > two of us travelling from elsewhere in North America (Brett and myself); > I presume that for all the Europeans, a Saturday arrival would be > better, so I would vote for changing the meeting dates to 15th-17th. If > we do that, we can all head for home on the 18th (or even at the end of > the 17th, if flights permit). > > How do the local hosts feel about losing their Sunday? > > Cheers, > Martin > > On 12-01-25 06:01 AM, Rebecca Welzenbach wrote: >> Hi all, >> >> As Kevin has suggested, it should be no problem to book our meeting >> room for Sunday, in case those who have arrived want to use it. >> >> I'm working now with the Bell Tower Inn >> (http://www.belltowerhotel.com/) to reserve a group of rooms. There's >> a discount (about 15%) if the rooms are paid for by the University of >> Michigan instead of by individuals--I'm working on whether we can get >> approval to do this. However, if several people expect to stay for >> some extra, un-reimbursed time, or arrive and depart on different >> days, this might be too complicated to handle as a single transaction. >> >> Based on the discussion above, it looks to me like there are now a >> maximum of five nights eligible for reimbursement: Saturday, April 14 >> through Wednesday, April 18 (checking out Thursday morning). Is that >> right, or are we dropping Wednesday in exchange for Saturday, and not >> reimbursing for any stay after Tuesday night? (Or allowing four >> nights, *either* Saturday, *or* Wednesday?) >> >> I'm making plans based on our needing seven rooms--please let me know >> if I've missed anyone or if plans have suddenly changed and you don't >> expect to come: >> * James Cummings >> * Lou Burnard >> * Piotr Banski >> * Sebastian Rahtz >> * Brett Barney >> * Gabriel Bodard >> * Martin Holmes >> >> If you could reply, adding your expected arrival and departure dates >> after your name, that will help me with securing accommodations. >> >> Becky >> >> >> On Tue, Jan 24, 2012 at 6:51 PM, Kevin Hawkins >> wrote: >>> Martin, thanks for investigating what MGuest offers and what we need. >>> You're right that it's insufficient for our needs, so we'll need to get >>> temporary accounts for everyone. This is similar to what we did for the >>> 2009 conference and it shouldn't be a problem. >>> >>> (U-M is testing eduRoam, but it's not functional yet.) >>> >>> On 1/24/2012 4:12 PM, Martin Holmes wrote: >>>> I was just checking out the wifi access at UMich: >>>> >>>> "Wireless access >>>> Council members not affiliated with the University of Michigan can use >>>> MGuest. If the limited access is insufficient, the local organizers can >>>> ask Desktop Support Services to provide temporary uniqnames." >>>> >>>> The MGuest services is quite restrictive: >>>> >>>> [quote] >>>> MGuest is limited to web (http), secure web (https) secure mail services >>>> (IMAPS, POPS, SMTPS) and VPN services: >>>> >>>> HTTP 80 >>>> HTTPS 443 (TLS/SSL) >>>> POP3s 995 (TLS/SSL) >>>> IMAPs 993 (TLS/SSL) >>>> SMTPs 465 (TLS/SSL) >>>> Secure Shell (SSH) port 22 >>>> >>>> VPN access via the following ports is allowed: >>>> >>>> Protocol 47, 50 and 51 >>>> port 500 >>>> port 1701 >>>> UDP port 4500 >>>> UDP port 10000 >>>> >>>> MGuest is rate limited to 1Mbps down and 384kbps upload speeds. >>>> >>>> MGuest is treated like a non-UM network; some U-M resource such as >>>> library journals cannot be accessed. >>>> [/quote] >>>> >>>> That would presumably make my Jenkins server inaccessible, because it >>>> runs on port 8080: >>>> >>>> >>>> >>>> And we have other projects running on other ports not on the MGuest >>>> list. If it's possible to get temporary logins to the main network, >>>> MWireless, I'd be happier. I'm assuming that UMich doesn't support >>>> eduroam? Something called "Internet2, Ann Arbor" does, but I don't see >>>> any mention on the main university site. >>>> >>>> Cheers, >>>> Martin >>>> >>> -- >>> tei-council mailing list >>> tei-council at lists.village.Virginia.EDU >>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council >>> >>> PLEASE NOTE: postings to this list are publicly archived > -- Dr James Cummings, InfoDev, Computing Services, University of Oxford From bansp at o2.pl Wed Jan 25 12:22:49 2012 From: bansp at o2.pl (=?ISO-8859-2?Q?Piotr_Ba=F1ski?=) Date: Wed, 25 Jan 2012 18:22:49 +0100 Subject: [tei-council] Ann Arbor spring meeting In-Reply-To: <4F203226.10901@uvic.ca> References: <4F1F19E3.1000401@uvic.ca> <4F1F1EC4.3010301@uvic.ca> <4F1F43EF.8090904@ultraslavonic.info> <4F203226.10901@uvic.ca> Message-ID: <4F203A69.6000500@o2.pl> Hi, I also plan to fly to Detroit from within the States, on Sunday. I will try to find a morning flight but can't promise I will find one, so I'd rather treat Sunday afternoon as an extra, rather than as part of the meeting proper. Best, Piotr On 25/01/12 17:47, Martin Holmes wrote: > I think we need to decide if the real meeting dates are Sunday 15th > through Tuesday 17th. Looking at the list of attendees, there are only > two of us travelling from elsewhere in North America (Brett and myself); > I presume that for all the Europeans, a Saturday arrival would be > better, so I would vote for changing the meeting dates to 15th-17th. If > we do that, we can all head for home on the 18th (or even at the end of > the 17th, if flights permit). > > How do the local hosts feel about losing their Sunday? > > Cheers, > Martin > > On 12-01-25 06:01 AM, Rebecca Welzenbach wrote: >> Hi all, >> >> As Kevin has suggested, it should be no problem to book our meeting >> room for Sunday, in case those who have arrived want to use it. >> >> I'm working now with the Bell Tower Inn >> (http://www.belltowerhotel.com/) to reserve a group of rooms. There's >> a discount (about 15%) if the rooms are paid for by the University of >> Michigan instead of by individuals--I'm working on whether we can get >> approval to do this. However, if several people expect to stay for >> some extra, un-reimbursed time, or arrive and depart on different >> days, this might be too complicated to handle as a single transaction. >> >> Based on the discussion above, it looks to me like there are now a >> maximum of five nights eligible for reimbursement: Saturday, April 14 >> through Wednesday, April 18 (checking out Thursday morning). Is that >> right, or are we dropping Wednesday in exchange for Saturday, and not >> reimbursing for any stay after Tuesday night? (Or allowing four >> nights, *either* Saturday, *or* Wednesday?) >> >> I'm making plans based on our needing seven rooms--please let me know >> if I've missed anyone or if plans have suddenly changed and you don't >> expect to come: >> * James Cummings >> * Lou Burnard >> * Piotr Banski >> * Sebastian Rahtz >> * Brett Barney >> * Gabriel Bodard >> * Martin Holmes >> >> If you could reply, adding your expected arrival and departure dates >> after your name, that will help me with securing accommodations. >> >> Becky >> >> >> On Tue, Jan 24, 2012 at 6:51 PM, Kevin Hawkins >> wrote: >>> Martin, thanks for investigating what MGuest offers and what we need. >>> You're right that it's insufficient for our needs, so we'll need to get >>> temporary accounts for everyone. This is similar to what we did for the >>> 2009 conference and it shouldn't be a problem. >>> >>> (U-M is testing eduRoam, but it's not functional yet.) >>> >>> On 1/24/2012 4:12 PM, Martin Holmes wrote: >>>> I was just checking out the wifi access at UMich: >>>> >>>> "Wireless access >>>> Council members not affiliated with the University of Michigan can use >>>> MGuest. If the limited access is insufficient, the local organizers can >>>> ask Desktop Support Services to provide temporary uniqnames." >>>> >>>> The MGuest services is quite restrictive: >>>> >>>> [quote] >>>> MGuest is limited to web (http), secure web (https) secure mail services >>>> (IMAPS, POPS, SMTPS) and VPN services: >>>> >>>> HTTP 80 >>>> HTTPS 443 (TLS/SSL) >>>> POP3s 995 (TLS/SSL) >>>> IMAPs 993 (TLS/SSL) >>>> SMTPs 465 (TLS/SSL) >>>> Secure Shell (SSH) port 22 >>>> >>>> VPN access via the following ports is allowed: >>>> >>>> Protocol 47, 50 and 51 >>>> port 500 >>>> port 1701 >>>> UDP port 4500 >>>> UDP port 10000 >>>> >>>> MGuest is rate limited to 1Mbps down and 384kbps upload speeds. >>>> >>>> MGuest is treated like a non-UM network; some U-M resource such as >>>> library journals cannot be accessed. >>>> [/quote] >>>> >>>> That would presumably make my Jenkins server inaccessible, because it >>>> runs on port 8080: >>>> >>>> >>>> >>>> And we have other projects running on other ports not on the MGuest >>>> list. If it's possible to get temporary logins to the main network, >>>> MWireless, I'd be happier. I'm assuming that UMich doesn't support >>>> eduroam? Something called "Internet2, Ann Arbor" does, but I don't see >>>> any mention on the main university site. >>>> >>>> Cheers, >>>> Martin >>>> >>> -- >>> tei-council mailing list >>> tei-council at lists.village.Virginia.EDU >>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council >>> >>> PLEASE NOTE: postings to this list are publicly archived > From bansp at o2.pl Wed Jan 25 17:44:48 2012 From: bansp at o2.pl (=?ISO-8859-2?Q?Piotr_Ba=F1ski?=) Date: Wed, 25 Jan 2012 23:44:48 +0100 Subject: [tei-council] Ann Arbor spring meeting In-Reply-To: <4F203A69.6000500@o2.pl> References: <4F1F19E3.1000401@uvic.ca> <4F1F1EC4.3010301@uvic.ca> <4F1F43EF.8090904@ultraslavonic.info> <4F203226.10901@uvic.ca> <4F203A69.6000500@o2.pl> Message-ID: <4F2085E0.2070506@o2.pl> FWIW, I'm scheduled to be in Detroit at 12:43 on Sunday, so I hope to join the afternoon activities. Best, P. On 25/01/12 18:22, Piotr Ba?ski wrote: > Hi, > > I also plan to fly to Detroit from within the States, on Sunday. I will > try to find a morning flight but can't promise I will find one, so I'd > rather treat Sunday afternoon as an extra, rather than as part of the > meeting proper. > > Best, > > Piotr > > On 25/01/12 17:47, Martin Holmes wrote: >> I think we need to decide if the real meeting dates are Sunday 15th >> through Tuesday 17th. Looking at the list of attendees, there are only >> two of us travelling from elsewhere in North America (Brett and myself); >> I presume that for all the Europeans, a Saturday arrival would be >> better, so I would vote for changing the meeting dates to 15th-17th. If >> we do that, we can all head for home on the 18th (or even at the end of >> the 17th, if flights permit). >> >> How do the local hosts feel about losing their Sunday? >> >> Cheers, >> Martin >> >> On 12-01-25 06:01 AM, Rebecca Welzenbach wrote: >>> Hi all, >>> >>> As Kevin has suggested, it should be no problem to book our meeting >>> room for Sunday, in case those who have arrived want to use it. >>> >>> I'm working now with the Bell Tower Inn >>> (http://www.belltowerhotel.com/) to reserve a group of rooms. There's >>> a discount (about 15%) if the rooms are paid for by the University of >>> Michigan instead of by individuals--I'm working on whether we can get >>> approval to do this. However, if several people expect to stay for >>> some extra, un-reimbursed time, or arrive and depart on different >>> days, this might be too complicated to handle as a single transaction. >>> >>> Based on the discussion above, it looks to me like there are now a >>> maximum of five nights eligible for reimbursement: Saturday, April 14 >>> through Wednesday, April 18 (checking out Thursday morning). Is that >>> right, or are we dropping Wednesday in exchange for Saturday, and not >>> reimbursing for any stay after Tuesday night? (Or allowing four >>> nights, *either* Saturday, *or* Wednesday?) >>> >>> I'm making plans based on our needing seven rooms--please let me know >>> if I've missed anyone or if plans have suddenly changed and you don't >>> expect to come: >>> * James Cummings >>> * Lou Burnard >>> * Piotr Banski >>> * Sebastian Rahtz >>> * Brett Barney >>> * Gabriel Bodard >>> * Martin Holmes >>> >>> If you could reply, adding your expected arrival and departure dates >>> after your name, that will help me with securing accommodations. >>> >>> Becky >>> >>> >>> On Tue, Jan 24, 2012 at 6:51 PM, Kevin Hawkins >>> wrote: >>>> Martin, thanks for investigating what MGuest offers and what we need. >>>> You're right that it's insufficient for our needs, so we'll need to get >>>> temporary accounts for everyone. This is similar to what we did for the >>>> 2009 conference and it shouldn't be a problem. >>>> >>>> (U-M is testing eduRoam, but it's not functional yet.) >>>> >>>> On 1/24/2012 4:12 PM, Martin Holmes wrote: >>>>> I was just checking out the wifi access at UMich: >>>>> >>>>> "Wireless access >>>>> Council members not affiliated with the University of Michigan can use >>>>> MGuest. If the limited access is insufficient, the local organizers can >>>>> ask Desktop Support Services to provide temporary uniqnames." >>>>> >>>>> The MGuest services is quite restrictive: >>>>> >>>>> [quote] >>>>> MGuest is limited to web (http), secure web (https) secure mail services >>>>> (IMAPS, POPS, SMTPS) and VPN services: >>>>> >>>>> HTTP 80 >>>>> HTTPS 443 (TLS/SSL) >>>>> POP3s 995 (TLS/SSL) >>>>> IMAPs 993 (TLS/SSL) >>>>> SMTPs 465 (TLS/SSL) >>>>> Secure Shell (SSH) port 22 >>>>> >>>>> VPN access via the following ports is allowed: >>>>> >>>>> Protocol 47, 50 and 51 >>>>> port 500 >>>>> port 1701 >>>>> UDP port 4500 >>>>> UDP port 10000 >>>>> >>>>> MGuest is rate limited to 1Mbps down and 384kbps upload speeds. >>>>> >>>>> MGuest is treated like a non-UM network; some U-M resource such as >>>>> library journals cannot be accessed. >>>>> [/quote] >>>>> >>>>> That would presumably make my Jenkins server inaccessible, because it >>>>> runs on port 8080: >>>>> >>>>> >>>>> >>>>> And we have other projects running on other ports not on the MGuest >>>>> list. If it's possible to get temporary logins to the main network, >>>>> MWireless, I'd be happier. I'm assuming that UMich doesn't support >>>>> eduroam? Something called "Internet2, Ann Arbor" does, but I don't see >>>>> any mention on the main university site. >>>>> >>>>> Cheers, >>>>> Martin From mholmes at uvic.ca Wed Jan 25 17:54:59 2012 From: mholmes at uvic.ca (Martin Holmes) Date: Wed, 25 Jan 2012 14:54:59 -0800 Subject: [tei-council] Ann Arbor spring meeting In-Reply-To: <4F203A69.6000500@o2.pl> References: <4F1F19E3.1000401@uvic.ca> <4F1F1EC4.3010301@uvic.ca> <4F1F43EF.8090904@ultraslavonic.info> <4F203226.10901@uvic.ca> <4F203A69.6000500@o2.pl> Message-ID: <4F208843.205@uvic.ca> So, given these choices: 1. Arrive Saturday, leave relatively early Wednesday (working days Sunday, Monday, Tuesday, and a bit of Wed) 2. Arrive Sunday, leave Thursday (working days Monday, Tuesday, Wednesday) 3. Arrive Saturday, leave Thursday (working days Sun, Mon, Tue, Wed, but one extra night in hotel) which should I choose? #3 gives me maximum working time but costs the TEI an extra night. If nobody cares, and James thinks the TEI can afford it, I'll choose #3, but if cost matters, would #1 or #2 be better? Cheers, Martin On 12-01-25 09:22 AM, Piotr Ba?ski wrote: > Hi, > > I also plan to fly to Detroit from within the States, on Sunday. I will > try to find a morning flight but can't promise I will find one, so I'd > rather treat Sunday afternoon as an extra, rather than as part of the > meeting proper. > > Best, > > Piotr > > On 25/01/12 17:47, Martin Holmes wrote: >> I think we need to decide if the real meeting dates are Sunday 15th >> through Tuesday 17th. Looking at the list of attendees, there are only >> two of us travelling from elsewhere in North America (Brett and myself); >> I presume that for all the Europeans, a Saturday arrival would be >> better, so I would vote for changing the meeting dates to 15th-17th. If >> we do that, we can all head for home on the 18th (or even at the end of >> the 17th, if flights permit). >> >> How do the local hosts feel about losing their Sunday? >> >> Cheers, >> Martin >> >> On 12-01-25 06:01 AM, Rebecca Welzenbach wrote: >>> Hi all, >>> >>> As Kevin has suggested, it should be no problem to book our meeting >>> room for Sunday, in case those who have arrived want to use it. >>> >>> I'm working now with the Bell Tower Inn >>> (http://www.belltowerhotel.com/) to reserve a group of rooms. There's >>> a discount (about 15%) if the rooms are paid for by the University of >>> Michigan instead of by individuals--I'm working on whether we can get >>> approval to do this. However, if several people expect to stay for >>> some extra, un-reimbursed time, or arrive and depart on different >>> days, this might be too complicated to handle as a single transaction. >>> >>> Based on the discussion above, it looks to me like there are now a >>> maximum of five nights eligible for reimbursement: Saturday, April 14 >>> through Wednesday, April 18 (checking out Thursday morning). Is that >>> right, or are we dropping Wednesday in exchange for Saturday, and not >>> reimbursing for any stay after Tuesday night? (Or allowing four >>> nights, *either* Saturday, *or* Wednesday?) >>> >>> I'm making plans based on our needing seven rooms--please let me know >>> if I've missed anyone or if plans have suddenly changed and you don't >>> expect to come: >>> * James Cummings >>> * Lou Burnard >>> * Piotr Banski >>> * Sebastian Rahtz >>> * Brett Barney >>> * Gabriel Bodard >>> * Martin Holmes >>> >>> If you could reply, adding your expected arrival and departure dates >>> after your name, that will help me with securing accommodations. >>> >>> Becky >>> >>> >>> On Tue, Jan 24, 2012 at 6:51 PM, Kevin Hawkins >>> wrote: >>>> Martin, thanks for investigating what MGuest offers and what we need. >>>> You're right that it's insufficient for our needs, so we'll need to get >>>> temporary accounts for everyone. This is similar to what we did for the >>>> 2009 conference and it shouldn't be a problem. >>>> >>>> (U-M is testing eduRoam, but it's not functional yet.) >>>> >>>> On 1/24/2012 4:12 PM, Martin Holmes wrote: >>>>> I was just checking out the wifi access at UMich: >>>>> >>>>> "Wireless access >>>>> Council members not affiliated with the University of Michigan can use >>>>> MGuest. If the limited access is insufficient, the local organizers can >>>>> ask Desktop Support Services to provide temporary uniqnames." >>>>> >>>>> The MGuest services is quite restrictive: >>>>> >>>>> [quote] >>>>> MGuest is limited to web (http), secure web (https) secure mail services >>>>> (IMAPS, POPS, SMTPS) and VPN services: >>>>> >>>>> HTTP 80 >>>>> HTTPS 443 (TLS/SSL) >>>>> POP3s 995 (TLS/SSL) >>>>> IMAPs 993 (TLS/SSL) >>>>> SMTPs 465 (TLS/SSL) >>>>> Secure Shell (SSH) port 22 >>>>> >>>>> VPN access via the following ports is allowed: >>>>> >>>>> Protocol 47, 50 and 51 >>>>> port 500 >>>>> port 1701 >>>>> UDP port 4500 >>>>> UDP port 10000 >>>>> >>>>> MGuest is rate limited to 1Mbps down and 384kbps upload speeds. >>>>> >>>>> MGuest is treated like a non-UM network; some U-M resource such as >>>>> library journals cannot be accessed. >>>>> [/quote] >>>>> >>>>> That would presumably make my Jenkins server inaccessible, because it >>>>> runs on port 8080: >>>>> >>>>> >>>>> >>>>> And we have other projects running on other ports not on the MGuest >>>>> list. If it's possible to get temporary logins to the main network, >>>>> MWireless, I'd be happier. I'm assuming that UMich doesn't support >>>>> eduroam? Something called "Internet2, Ann Arbor" does, but I don't see >>>>> any mention on the main university site. >>>>> >>>>> Cheers, >>>>> Martin >>>>> >>>> -- >>>> tei-council mailing list >>>> tei-council at lists.village.Virginia.EDU >>>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council >>>> >>>> PLEASE NOTE: postings to this list are publicly archived >> > -- Martin Holmes University of Victoria Humanities Computing and Media Centre (mholmes at uvic.ca) From kevin.s.hawkins at ultraslavonic.info Wed Jan 25 18:01:45 2012 From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins) Date: Wed, 25 Jan 2012 18:01:45 -0500 Subject: [tei-council] Ann Arbor spring meeting In-Reply-To: <4F208843.205@uvic.ca> References: <4F1F19E3.1000401@uvic.ca> <4F1F1EC4.3010301@uvic.ca> <4F1F43EF.8090904@ultraslavonic.info> <4F203226.10901@uvic.ca> <4F203A69.6000500@o2.pl> <4F208843.205@uvic.ca> Message-ID: <4F2089D9.2050405@ultraslavonic.info> I think we're in a situation where no one is prepared to unilaterally declare which days are the official working days of the Council meeting. Since there was interest in having a group hacking session before the official sessions start, I suggest we keep Sunday as the optional attendance day and keep Monday, Tuesday, and Wednesday as the real work days. I live closer to the university than Paul or Becky, so I don't mind opening the meeting room on Sunday and hanging out with whoever joins me there. It is often the case that people need to leave early on the third working day, so I suggest leaving that late afternoon or evening if it works in your schedule. If it doesn't for some reason, stay an extra night. Does this work for everyone? Kevin From sebastian.rahtz at oucs.ox.ac.uk Wed Jan 25 18:11:09 2012 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Wed, 25 Jan 2012 23:11:09 +0000 Subject: [tei-council] Ann Arbor spring meeting In-Reply-To: <4F2089D9.2050405@ultraslavonic.info> References: <4F1F19E3.1000401@uvic.ca> <4F1F1EC4.3010301@uvic.ca> <4F1F43EF.8090904@ultraslavonic.info> <4F203226.10901@uvic.ca> <4F203A69.6000500@o2.pl> <4F208843.205@uvic.ca> <4F2089D9.2050405@ultraslavonic.info> Message-ID: On 25 Jan 2012, at 23:01, Kevin Hawkins wrote: > I think we're in a situation where no one is prepared to unilaterally > declare which days are the official working days of the Council meeting. > Since there was interest in having a group hacking session before the > official sessions start, I suggest we keep Sunday as the optional > attendance day and keep Monday, Tuesday, and Wednesday as the real work > days. I agree. Planning to complete by (say) 4pm on Wednesday. -- Stormageddon Rahtz Head of Information and Support Group, Oxford University Computing Services 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 Jan 25 18:19:44 2012 From: mholmes at uvic.ca (Martin Holmes) Date: Wed, 25 Jan 2012 15:19:44 -0800 Subject: [tei-council] Ann Arbor spring meeting In-Reply-To: <4F2089D9.2050405@ultraslavonic.info> References: <4F1F19E3.1000401@uvic.ca> <4F1F1EC4.3010301@uvic.ca> <4F1F43EF.8090904@ultraslavonic.info> <4F203226.10901@uvic.ca> <4F203A69.6000500@o2.pl> <4F208843.205@uvic.ca> <4F2089D9.2050405@ultraslavonic.info> Message-ID: <4F208E10.8030204@uvic.ca> Works for me. If there are no strenuous objections overnight, I'll go for the five-night option. I promise to do the minutes for at least one day as recompense. Cheers, Martin On 12-01-25 03:01 PM, Kevin Hawkins wrote: > I think we're in a situation where no one is prepared to unilaterally > declare which days are the official working days of the Council meeting. > Since there was interest in having a group hacking session before the > official sessions start, I suggest we keep Sunday as the optional > attendance day and keep Monday, Tuesday, and Wednesday as the real work > days. I live closer to the university than Paul or Becky, so I don't > mind opening the meeting room on Sunday and hanging out with whoever > joins me there. > > It is often the case that people need to leave early on the third > working day, so I suggest leaving that late afternoon or evening if it > works in your schedule. If it doesn't for some reason, stay an extra night. > > Does this work for everyone? > > Kevin -- Martin Holmes University of Victoria Humanities Computing and Media Centre (mholmes at uvic.ca) From James.Cummings at oucs.ox.ac.uk Thu Jan 26 04:54:28 2012 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Thu, 26 Jan 2012 09:54:28 +0000 Subject: [tei-council] Ann Arbor spring meeting In-Reply-To: <4F2089D9.2050405@ultraslavonic.info> References: <4F1F19E3.1000401@uvic.ca> <4F1F1EC4.3010301@uvic.ca> <4F1F43EF.8090904@ultraslavonic.info> <4F203226.10901@uvic.ca> <4F203A69.6000500@o2.pl> <4F208843.205@uvic.ca> <4F2089D9.2050405@ultraslavonic.info> Message-ID: <4F2122D4.7050209@oucs.ox.ac.uk> On 25/01/12 23:01, Kevin Hawkins wrote: > I think we're in a situation where no one is prepared to unilaterally > declare which days are the official working days of the Council meeting. I think you'll find I am. As I suggested before, but will now do in my detail I believe the schedule should be as follows: Sunday: TEI Hackfest (optional: those that are there promise to dedicate their time to do things that are useful to the TEI) Monday: Meeting Day 1 Tuesday: Meeting Day 2 Wednesday: Meeting Day 3 with early departure. (Those that need to leave, try to stay until at least noon. I would _only_ suggest those people who achieve a significant saving to come earlier (i.e. those getting penalised for not including a saturday). The saving must be more than an extra night's hotel and per diem of food. Are there any serious objections to that? Remember that the more we spend the less money is left over for funding things like a potential web-Roma2 implementation. > days. I live closer to the university than Paul or Becky, so I don't > mind opening the meeting room on Sunday and hanging out with whoever > joins me there. Thanks Kevin, I appreciate that. I certainly will be there (and from the sounds of it some others). I've put up a doodle for people to record what nights they will need hotel. This will be useful for Becky if doing a block booking, and/or all of us to know who is arriving/departing when. Since I'm arriving on the Sat and leaving on the Wednesday, I've checked Sat/Sun/Mon/Tues Nights. Could everyone needing hotel fill it out? -James -- Dr James Cummings, InfoDev, Computing Services, University of Oxford From James.Cummings at oucs.ox.ac.uk Thu Jan 26 04:57:51 2012 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Thu, 26 Jan 2012 09:57:51 +0000 Subject: [tei-council] Ann Arbor spring meeting In-Reply-To: <4F2122D4.7050209@oucs.ox.ac.uk> References: <4F1F19E3.1000401@uvic.ca> <4F1F1EC4.3010301@uvic.ca> <4F1F43EF.8090904@ultraslavonic.info> <4F203226.10901@uvic.ca> <4F203A69.6000500@o2.pl> <4F208843.205@uvic.ca> <4F2089D9.2050405@ultraslavonic.info> <4F2122D4.7050209@oucs.ox.ac.uk> Message-ID: <4F21239F.5070501@oucs.ox.ac.uk> On 26/01/12 09:54, James Cummings wrote: > I've put up a doodle for people to record what nights they will > need hotel. This will be useful for Becky if doing a block > booking, and/or all of us to know who is arriving/departing when. > Since I'm arriving on the Sat and leaving on the Wednesday, > I've checked Sat/Sun/Mon/Tues Nights. Could everyone needing > hotel fill it out? Of course it would be better if I included the URL. (*doh*) http://www.doodle.com/9dunbbdcngadff68 > > -James > -- Dr James Cummings, InfoDev, Computing Services, University of Oxford From rwelzenbach at gmail.com Thu Jan 26 08:57:43 2012 From: rwelzenbach at gmail.com (Rebecca Welzenbach) Date: Thu, 26 Jan 2012 08:57:43 -0500 Subject: [tei-council] Ann Arbor spring meeting In-Reply-To: <4F21239F.5070501@oucs.ox.ac.uk> References: <4F1F19E3.1000401@uvic.ca> <4F1F1EC4.3010301@uvic.ca> <4F1F43EF.8090904@ultraslavonic.info> <4F203226.10901@uvic.ca> <4F203A69.6000500@o2.pl> <4F208843.205@uvic.ca> <4F2089D9.2050405@ultraslavonic.info> <4F2122D4.7050209@oucs.ox.ac.uk> <4F21239F.5070501@oucs.ox.ac.uk> Message-ID: Great idea--thanks, James. On Thu, Jan 26, 2012 at 4:57 AM, James Cummings wrote: > On 26/01/12 09:54, James Cummings wrote: >> I've put up a doodle for people to record what nights they will >> need hotel. This will be useful for Becky if doing a block >> booking, and/or all of us to know who is arriving/departing when. >> ? ?Since I'm arriving on the Sat and leaving on the Wednesday, >> I've checked Sat/Sun/Mon/Tues Nights. Could everyone needing >> hotel fill it out? > > Of course it would be better if I included the URL. (*doh*) > > http://www.doodle.com/9dunbbdcngadff68 > > > >> >> -James >> > > > -- > Dr James Cummings, InfoDev, > Computing Services, University of Oxford > -- > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > > PLEASE NOTE: postings to this list are publicly archived From kevin.s.hawkins at ultraslavonic.info Thu Jan 26 20:13:43 2012 From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins) Date: Thu, 26 Jan 2012 20:13:43 -0500 Subject: [tei-council] Minor error in Guidelines In-Reply-To: <4F1059A9.1000709@retired.ox.ac.uk> References: <4F0F9F9F.3050408@gmail.com> <4F0FBAA5.2090706@uvic.ca> <97AE8F42-0EDB-41CC-8FE1-984EE9E495D4@oucs.ox.ac.uk> <4F10590C.50904@uvic.ca> <4F1059A9.1000709@retired.ox.ac.uk> Message-ID: <4F21FA47.2050800@ultraslavonic.info> I'm wondering whether others feel that we should add a bit to http://www.tei-c.org/Activities/Council/Working/tcw20.xml or perhaps more properly P5/Source/Guidelines/en/style-guide.txt stating this distinction. There might be other things that those who have been editing the Guidelines keep in mind but haven't written down for the rest of us. Such a passage would be similar to this, which I found in tcw20 and is similarly prescriptive about encoding practice: ### In most chapters, the two character code is also used as a prefix for the @xml:id values given to each
element. Note that every
element carries an @xml:id value, whether or not it is actually referenced explicitly elewhere in the Guidelines. ### Is this worthwhile, or would none of us ever remember to consult this anyway? --K. On 1/13/12 11:19 AM, Lou Burnard wrote: > In the Guidelines, as elsewhere, > > section foo means: generate a link to #foo and > represent it by the text "section foo". > > means: generate a link to #foo and represent it by > whatever text your processor chooses to generate > > > > On 13/01/12 16:17, Martin Holmes wrote: >> Could you clarify what the difference is between using and >> in the guidelines? >> >> Cheers, >> Martin >> >> On 12-01-13 01:32 AM, Sebastian Rahtz wrote: >>> >>> On 13 Jan 2012, at 05:01, Martin Holmes wrote: >>> >>>> I've put in a bug report for this: >>>> >>>> >>>> >>>> The basic problem is that in the web view of the Guidelines, figures >>>> within each chapter are numbered 1, 2, 3, 4 etc., but in the PDF output, >>>> they're numbered 11.1, 11.2, 11.3? >>>> >>> there are two issues here. >>> >>> a) the use of dangerous markup like "figure 4 above", which should be changed into a to avoid this sort of problem >>> b) the different numbering schemes >>> >>> for the latter, which do we want for the Guidelines? by chapter, or sequential throughout? >>> >>> for the former, I found 3 occurrences of this, and changed them to. am testing before committing. >>> -- >>> Stormageddon Rahtz >>> Head of Information and Support Group >>> Oxford University Computing Services >>> 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 Jan 27 06:22:34 2012 From: gabriel.bodard at kcl.ac.uk (Gabriel Bodard) Date: Fri, 27 Jan 2012 11:22:34 +0000 Subject: [tei-council] Redundant note in Message-ID: <4F2288FA.3070405@kcl.ac.uk> As far as I can see, the note at the bottom of the page must date from when these elements were in SGML, since it warns coders to use an explicit end-tag, which has long been required for all elements in XML anyway. Any objection if I just delete this note from the source? G -- Dr Gabriel BODARD (Research Associate in Digital Epigraphy) Department of Digital 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 Jan 27 06:27:26 2012 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Fri, 27 Jan 2012 11:27:26 +0000 Subject: [tei-council] Redundant note in In-Reply-To: <4F2288FA.3070405@kcl.ac.uk> References: <4F2288FA.3070405@kcl.ac.uk> Message-ID: <2D5E2DDD-9E07-4EA8-B9FA-BEC64A60E141@oucs.ox.ac.uk> On 27 Jan 2012, at 11:22, Gabriel Bodard wrote: > As far as I can see, the note at the bottom of the page > > must date from when these elements were in SGML, since it warns coders > to use an explicit end-tag, which has long been required for all > elements in XML anyway. > > Any objection if I just delete this note from the source? +1 (or is it -1?) to agree with you -- Stormageddon Rahtz Head of Information and Support Group Oxford University Computing Services 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 Fri Jan 27 06:27:30 2012 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Fri, 27 Jan 2012 11:27:30 +0000 Subject: [tei-council] Redundant note in In-Reply-To: <4F2288FA.3070405@kcl.ac.uk> References: <4F2288FA.3070405@kcl.ac.uk> Message-ID: <4F228A22.8090502@oucs.ox.ac.uk> On 27/01/12 11:22, Gabriel Bodard wrote: > As far as I can see, the note at the bottom of the page > > must date from when these elements were in SGML, since it warns coders > to use an explicit end-tag, which has long been required for all > elements in XML anyway. > > Any objection if I just delete this note from the source? That seems reasonable to me. -James -- Dr James Cummings, InfoDev, Computing Services, University of Oxford From gabriel.bodard at kcl.ac.uk Fri Jan 27 06:39:50 2012 From: gabriel.bodard at kcl.ac.uk (Gabriel Bodard) Date: Fri, 27 Jan 2012 11:39:50 +0000 Subject: [tei-council] Redundant note in In-Reply-To: <4F228A22.8090502@oucs.ox.ac.uk> References: <4F2288FA.3070405@kcl.ac.uk> <4F228A22.8090502@oucs.ox.ac.uk> Message-ID: <4F228D06.3060201@kcl.ac.uk> There's also a commented out section in here: Can anyone make head or tail of that? Delete it? Act on it? Or what? I guess the question is, is the CDATA section in the supposed to be visible? Otherwise, I'm not sure this example expresses very well how is different from ... G On 2012-01-27 11:27, James Cummings wrote: > On 27/01/12 11:22, Gabriel Bodard wrote: >> As far as I can see, the note at the bottom of the page >> >> must date from when these elements were in SGML, since it warns coders >> to use an explicit end-tag, which has long been required for all >> elements in XML anyway. >> >> Any objection if I just delete this note from the source? > > That seems reasonable to me. > > -James > > -- Dr Gabriel BODARD (Research Associate in Digital Epigraphy) Department of Digital 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 Jan 27 07:12:43 2012 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Fri, 27 Jan 2012 12:12:43 +0000 Subject: [tei-council] Redundant note in In-Reply-To: <4F228D06.3060201@kcl.ac.uk> References: <4F2288FA.3070405@kcl.ac.uk> <4F228A22.8090502@oucs.ox.ac.uk> <4F228D06.3060201@kcl.ac.uk> Message-ID: i think you can kill that archaeological artefact, entertaining as it is. it relates to SGML. -- Stormageddon Rahtz Head of Information and Support Group Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From rwelzenbach at gmail.com Fri Jan 27 12:38:22 2012 From: rwelzenbach at gmail.com (Rebecca Welzenbach) Date: Fri, 27 Jan 2012 12:38:22 -0500 Subject: [tei-council] Minor error in Guidelines In-Reply-To: <4F21FA47.2050800@ultraslavonic.info> References: <4F0F9F9F.3050408@gmail.com> <4F0FBAA5.2090706@uvic.ca> <97AE8F42-0EDB-41CC-8FE1-984EE9E495D4@oucs.ox.ac.uk> <4F10590C.50904@uvic.ca> <4F1059A9.1000709@retired.ox.ac.uk> <4F21FA47.2050800@ultraslavonic.info> Message-ID: I would certainly find it valuable! On Thu, Jan 26, 2012 at 8:13 PM, Kevin Hawkins wrote: > I'm wondering whether others feel that we should add a bit to > > http://www.tei-c.org/Activities/Council/Working/tcw20.xml > > or perhaps more properly > > P5/Source/Guidelines/en/style-guide.txt > > stating this distinction. ?There might be other things that those who > have been editing the Guidelines keep in mind but haven't written down > for the rest of us. > > Such a passage would be similar to this, which I found in tcw20 and is > similarly prescriptive about encoding practice: > > ### > > In most chapters, the two character code is also used as a prefix for > the @xml:id values given to each
element. Note that every
> element carries an @xml:id value, whether or not it is actually > referenced explicitly elewhere in the Guidelines. > > ### > > Is this worthwhile, or would none of us ever remember to consult this > anyway? > > --K. > > On 1/13/12 11:19 AM, Lou Burnard wrote: >> In the Guidelines, as elsewhere, >> >> section foo ?means: generate a link to #foo and >> represent it by the text "section foo". >> >> ?means: generate a link to #foo and represent it by >> whatever text your processor chooses to generate >> >> >> >> On 13/01/12 16:17, Martin Holmes wrote: >>> Could you clarify what the difference is between using ? and >>> in the guidelines? >>> >>> Cheers, >>> Martin >>> >>> On 12-01-13 01:32 AM, Sebastian Rahtz wrote: >>>> >>>> On 13 Jan 2012, at 05:01, Martin Holmes wrote: >>>> >>>>> I've put in a bug report for this: >>>>> >>>>> >>>>> >>>>> The basic problem is that in the web view of the Guidelines, figures >>>>> within each chapter are numbered 1, 2, 3, 4 etc., but in the PDF output, >>>>> they're numbered 11.1, 11.2, 11.3? >>>>> >>>> there are two issues here. >>>> >>>> ? ? ?a) the use of dangerous markup like "figure 4 above", which should be changed into a ? ?to avoid this sort of problem >>>> ? ? ?b) the different numbering schemes >>>> >>>> for the latter, which do we want for the Guidelines? by chapter, or sequential throughout? >>>> >>>> for the former, I found 3 occurrences of this, and changed them to. am testing before committing. >>>> -- >>>> Stormageddon Rahtz >>>> Head of Information and Support Group >>>> Oxford University Computing 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 > > PLEASE NOTE: postings to this list are publicly archived From James.Cummings at oucs.ox.ac.uk Tue Jan 31 10:01:50 2012 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Tue, 31 Jan 2012 15:01:50 +0000 Subject: [tei-council] Next Release; Codename: GroundHog Day In-Reply-To: <4F160E96.2010202@oucs.ox.ac.uk> References: <48F7E21F-4B77-4865-AB90-47F6AA73ADBF@edirom.de> <4F0F1AD5.4070101@uvic.ca> <4F159DC1.4010001@kcl.ac.uk> <4F160E96.2010202@oucs.ox.ac.uk> Message-ID: <4F28025E.9050603@oucs.ox.ac.uk> Just a reminder that any bugs, typos, corrections, and schema-affecting changes you've spotted in the Guidelines should be fixed by midnight tonight. This gives us all of Wednesday 1st of Feb for proofreading and corrections of any additional typos we find, with an intended release by MartinH on Thursday 2 February. Is the next release going to be 2.1.0 or 2.0.2? Correct me if I'm wrong but If there have been schema-affecting changes then the second number is meant to increment. Have there been schema-affecting changes since 2.0.1? -James On 18/01/12 00:13, James Cummings wrote: > > Hi all, > > Since no one else has piped up, can I suggest a schedule: > > 31 January midnight GMT: submission deadline of significant changes > 1 February: Whole Day for council to proofread and correct typos. > 2nd February: Release (Codename: Groundhog Day) > > Since Martin asked, I suggest him as release technician. > > Any reasons why these dates are wholly unsuitable? > > -James > > On 17/01/12 16:11, Gabriel Bodard wrote: >> Has there been any consensus on when 2.0.2 might be put out? >> >> (I ask because, if it's soon I won't both hacking the EpiDoc schema to >> allow geo/@decl; I'll just wait for TEI to introduce it and regenerate >> the schema properly. :-) ) >> >> G >> >> On 2012-01-12 17:39, Martin Holmes wrote: >>> Hi all, >>> >>> I think we need to release a 2.0.2 soon, during which we again run >>> through the instructions, after adding the tagging instruction. Should >>> we do a quick trawl through the tickets and decide which ones might beS >>> polished off quickly without controversy? >>> >>> Can I be the one to go through the release steps this time? >>> >>> Cheers, >>> Martin >>> >>> On 12-01-12 08:27 AM, Peter Stadler wrote: >>>> Dear geeks again, >>>> >>>> again wondering: just downloaded the current release 2.0.1 from sourceforge (tei-2.0.1.zip) and the editionStmt at tei-2.0.1/xml/tei/p5subset.xml reads2.0.0 Last updated on16th December 2011. >>>> >>>> Does that mean it wasn't updated at all or is just the editionStmt wrong? >>>> >>>> Many thanks again >>>> Peter >>>> >>> >> > > -- Dr James Cummings, InfoDev, Computing Services, University of Oxford From mholmes at uvic.ca Tue Jan 31 11:02:56 2012 From: mholmes at uvic.ca (Martin Holmes) Date: Tue, 31 Jan 2012 08:02:56 -0800 Subject: [tei-council] Next Release; Codename: GroundHog Day In-Reply-To: <4F28025E.9050603@oucs.ox.ac.uk> References: <48F7E21F-4B77-4865-AB90-47F6AA73ADBF@edirom.de> <4F0F1AD5.4070101@uvic.ca> <4F159DC1.4010001@kcl.ac.uk> <4F160E96.2010202@oucs.ox.ac.uk> <4F28025E.9050603@oucs.ox.ac.uk> Message-ID: <4F2810B0.2020303@uvic.ca> I think there has been at least one schema-affecting change: ------------------------------------------------------------------------ r10035 | gabrielbodard | 2012-01-12 09:54:18 -0800 (Thu, 12 Jan 2012) | 1 line added to att.declaring So I guess we should be going for 2.1.0. Cheers, Martin On 12-01-31 07:01 AM, James Cummings wrote: > > Just a reminder that any bugs, typos, corrections, and > schema-affecting changes you've spotted in the Guidelines should > be fixed by midnight tonight. This gives us all of Wednesday 1st > of Feb for proofreading and corrections of any additional typos > we find, with an intended release by MartinH on Thursday 2 February. > > Is the next release going to be 2.1.0 or 2.0.2? Correct me if > I'm wrong but If there have been schema-affecting changes then > the second number is meant to increment. Have there been > schema-affecting changes since 2.0.1? > > -James > > On 18/01/12 00:13, James Cummings wrote: >> >> Hi all, >> >> Since no one else has piped up, can I suggest a schedule: >> >> 31 January midnight GMT: submission deadline of significant changes >> 1 February: Whole Day for council to proofread and correct typos. >> 2nd February: Release (Codename: Groundhog Day) >> >> Since Martin asked, I suggest him as release technician. >> >> Any reasons why these dates are wholly unsuitable? >> >> -James >> >> On 17/01/12 16:11, Gabriel Bodard wrote: >>> Has there been any consensus on when 2.0.2 might be put out? >>> >>> (I ask because, if it's soon I won't both hacking the EpiDoc schema to >>> allow geo/@decl; I'll just wait for TEI to introduce it and regenerate >>> the schema properly. :-) ) >>> >>> G >>> >>> On 2012-01-12 17:39, Martin Holmes wrote: >>>> Hi all, >>>> >>>> I think we need to release a 2.0.2 soon, during which we again run >>>> through the instructions, after adding the tagging instruction. Should >>>> we do a quick trawl through the tickets and decide which ones might beS >>>> polished off quickly without controversy? >>>> >>>> Can I be the one to go through the release steps this time? >>>> >>>> Cheers, >>>> Martin >>>> >>>> On 12-01-12 08:27 AM, Peter Stadler wrote: >>>>> Dear geeks again, >>>>> >>>>> again wondering: just downloaded the current release 2.0.1 from sourceforge (tei-2.0.1.zip) and the editionStmt at tei-2.0.1/xml/tei/p5subset.xml reads2.0.0 Last updated on16th December 2011. >>>>> >>>>> Does that mean it wasn't updated at all or is just the editionStmt wrong? >>>>> >>>>> Many thanks again >>>>> Peter >>>>> >>>> >>> >> >> > > -- Martin Holmes University of Victoria Humanities Computing and Media Centre (mholmes at uvic.ca) From mholmes at uvic.ca Tue Jan 31 11:56:17 2012 From: mholmes at uvic.ca (Martin Holmes) Date: Tue, 31 Jan 2012 08:56:17 -0800 Subject: [tei-council] Use of @cRef Message-ID: <4F281D31.5020206@uvic.ca> Hi all, The attribute @cRef (which appears on , , and ) is currently a bit of a mess. I've started a bug for this: Changes have to be made to @cRef -- for one thing, the attribute is separately defined for each element, with different datatypes. It has been suggested that we no longer actually need it, because its original function (storing a canonical reference from a scheme defined in a element in the TEI header) can perfectly well be handled using @target, using a private URI scheme. However, it's arguable that having an attribute whose purpose is explicitly to handle private URI schemes (as opposed to official IANA-registered schemes) might be useful. If we were to switch to recommending @target and private URI schemes, I think we'd have to encourage people to provide resolution patterns for such schemes as we currently do with @cRef. It would be helpful to get a sense of what people are currently doing with @cRef, and how changes are likely to affect existing projects. I thought about a little survey we could circulate to TEI-L -- something like this: What do you think about this? (Assuming you can see the survey -- I'm not sure exactly how SurveyMonkey works in this regard, never having used it before. If you can't see it, let me know and I'll copy/paste the questions into an email.) I'd like to make some decisions about @cRef at the April meeting if that's possible, so a bit of prep now seems like a good idea. Cheers, Martin -- Martin Holmes University of Victoria Humanities Computing and Media Centre (mholmes at uvic.ca) From gabriel.bodard at kcl.ac.uk Tue Jan 31 12:28:01 2012 From: gabriel.bodard at kcl.ac.uk (Gabriel Bodard) Date: Tue, 31 Jan 2012 17:28:01 +0000 Subject: [tei-council] Next Release; Codename: GroundHog Day In-Reply-To: <4F2810B0.2020303@uvic.ca> References: <48F7E21F-4B77-4865-AB90-47F6AA73ADBF@edirom.de> <4F0F1AD5.4070101@uvic.ca> <4F159DC1.4010001@kcl.ac.uk> <4F160E96.2010202@oucs.ox.ac.uk> <4F28025E.9050603@oucs.ox.ac.uk> <4F2810B0.2020303@uvic.ca> Message-ID: <4F2824A1.3060001@kcl.ac.uk> I have no strong feelings either way, but my understanding was that it was argued the addition of geo to att.declaring was an obvious bug-fix, and so shouldn't require a 2.1. (If I'm mistaken, or even if I'm correct but people disagree with this argument, then go ahead and name it 2.1.0.) G On 2012-01-31 16:02, Martin Holmes wrote: > I think there has been at least one schema-affecting change: > > ------------------------------------------------------------------------ > r10035 | gabrielbodard | 2012-01-12 09:54:18 -0800 (Thu, 12 Jan 2012) | > 1 line > > added to att.declaring > > So I guess we should be going for 2.1.0. > > Cheers, > Martin > > > On 12-01-31 07:01 AM, James Cummings wrote: >> >> Just a reminder that any bugs, typos, corrections, and >> schema-affecting changes you've spotted in the Guidelines should >> be fixed by midnight tonight. This gives us all of Wednesday 1st >> of Feb for proofreading and corrections of any additional typos >> we find, with an intended release by MartinH on Thursday 2 February. >> >> Is the next release going to be 2.1.0 or 2.0.2? Correct me if >> I'm wrong but If there have been schema-affecting changes then >> the second number is meant to increment. Have there been >> schema-affecting changes since 2.0.1? >> >> -James >> >> On 18/01/12 00:13, James Cummings wrote: >>> >>> Hi all, >>> >>> Since no one else has piped up, can I suggest a schedule: >>> >>> 31 January midnight GMT: submission deadline of significant changes >>> 1 February: Whole Day for council to proofread and correct typos. >>> 2nd February: Release (Codename: Groundhog Day) >>> >>> Since Martin asked, I suggest him as release technician. >>> >>> Any reasons why these dates are wholly unsuitable? >>> >>> -James >>> >>> On 17/01/12 16:11, Gabriel Bodard wrote: >>>> Has there been any consensus on when 2.0.2 might be put out? >>>> >>>> (I ask because, if it's soon I won't both hacking the EpiDoc schema to >>>> allow geo/@decl; I'll just wait for TEI to introduce it and regenerate >>>> the schema properly. :-) ) >>>> >>>> G >>>> >>>> On 2012-01-12 17:39, Martin Holmes wrote: >>>>> Hi all, >>>>> >>>>> I think we need to release a 2.0.2 soon, during which we again run >>>>> through the instructions, after adding the tagging instruction. Should >>>>> we do a quick trawl through the tickets and decide which ones might beS >>>>> polished off quickly without controversy? >>>>> >>>>> Can I be the one to go through the release steps this time? >>>>> >>>>> Cheers, >>>>> Martin >>>>> >>>>> On 12-01-12 08:27 AM, Peter Stadler wrote: >>>>>> Dear geeks again, >>>>>> >>>>>> again wondering: just downloaded the current release 2.0.1 from sourceforge (tei-2.0.1.zip) and the editionStmt at tei-2.0.1/xml/tei/p5subset.xml reads2.0.0 Last updated on16th December 2011. >>>>>> >>>>>> Does that mean it wasn't updated at all or is just the editionStmt wrong? >>>>>> >>>>>> Many thanks again >>>>>> Peter >>>>>> >>>>> >>>> >>> >>> >> >> > -- Dr Gabriel BODARD (Research Associate in Digital Epigraphy) Department of Digital 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 Wed Feb 1 05:10:25 2012 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Wed, 1 Feb 2012 10:10:25 +0000 Subject: [tei-council] Use of @cRef In-Reply-To: <4F281D31.5020206@uvic.ca> References: <4F281D31.5020206@uvic.ca> Message-ID: I like the idea of the survey; my working assumption is that we only flush out 3 people using cRef, and it'll turn out they still use P4 anyway :-} I have commented on ticket -- Stormageddon Rahtz Head of Information and Support Group Oxford University Computing Services 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 Feb 1 05:21:02 2012 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Wed, 01 Feb 2012 10:21:02 +0000 Subject: [tei-council] Use of @cRef In-Reply-To: <4F281D31.5020206@uvic.ca> References: <4F281D31.5020206@uvic.ca> Message-ID: <4F29120E.5090603@oucs.ox.ac.uk> I like the survey, but should it be explained that data.pointer can take a URI of the form foo:blort etc? i.e. that their @cRefs probably can be easily represented as pointers? -James On 31/01/12 16:56, Martin Holmes wrote: > Hi all, > > The attribute @cRef (which appears on,, and) > is currently a bit of a mess. I've started a bug for this: > > > > Changes have to be made to @cRef -- for one thing, the attribute is > separately defined for each element, with different datatypes. It has > been suggested that we no longer actually need it, because its original > function (storing a canonical reference from a scheme defined in a > element in the TEI header) can perfectly well be handled > using @target, using a private URI scheme. However, it's arguable that > having an attribute whose purpose is explicitly to handle private URI > schemes (as opposed to official IANA-registered schemes) might be > useful. If we were to switch to recommending @target and private URI > schemes, I think we'd have to encourage people to provide resolution > patterns for such schemes as we currently do with @cRef. > > It would be helpful to get a sense of what people are currently doing > with @cRef, and how changes are likely to affect existing projects. I > thought about a little survey we could circulate to TEI-L -- something > like this: > > > > What do you think about this? (Assuming you can see the survey -- I'm > not sure exactly how SurveyMonkey works in this regard, never having > used it before. If you can't see it, let me know and I'll copy/paste the > questions into an email.) > > I'd like to make some decisions about @cRef at the April meeting if > that's possible, so a bit of prep now seems like a good idea. > > Cheers, > Martin -- Dr James Cummings, InfoDev, Computing Services, University of Oxford From James.Cummings at oucs.ox.ac.uk Wed Feb 1 07:48:56 2012 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Wed, 01 Feb 2012 12:48:56 +0000 Subject: [tei-council] Next Release; Codename: GroundHog Day In-Reply-To: <4F2824A1.3060001@kcl.ac.uk> References: <48F7E21F-4B77-4865-AB90-47F6AA73ADBF@edirom.de> <4F0F1AD5.4070101@uvic.ca> <4F159DC1.4010001@kcl.ac.uk> <4F160E96.2010202@oucs.ox.ac.uk> <4F28025E.9050603@oucs.ox.ac.uk> <4F2810B0.2020303@uvic.ca> <4F2824A1.3060001@kcl.ac.uk> Message-ID: <4F2934B8.9080108@oucs.ox.ac.uk> A reminder that we are meant to be proofreading the release today. So have a look at http://teijenkins.hcmc.uvic.ca:8080/job/TEIP5-Documentation/ws/ and http://teijenkins.hcmc.uvic.ca:8080/job/TEIP5-Documentation/ws/Guidelines-web/en/html/index.html And point out anything (except for version and date) which are wrong. If you are able to and believe it is a corrigible error then go and fix it and commit them by midnight tonight. Otherwise comment to the list for someone else to do so. If you can each spend an hour or so today looking at it, hopefully will pick up some additional errors. -James On 31/01/12 17:28, Gabriel Bodard wrote: > I have no strong feelings either way, but my understanding was that it > was argued the addition of geo to att.declaring was an obvious bug-fix, > and so shouldn't require a 2.1. (If I'm mistaken, or even if I'm correct > but people disagree with this argument, then go ahead and name it 2.1.0.) > > G > > On 2012-01-31 16:02, Martin Holmes wrote: >> I think there has been at least one schema-affecting change: >> >> ------------------------------------------------------------------------ >> r10035 | gabrielbodard | 2012-01-12 09:54:18 -0800 (Thu, 12 Jan 2012) | >> 1 line >> >> added to att.declaring >> >> So I guess we should be going for 2.1.0. >> >> Cheers, >> Martin >> >> >> On 12-01-31 07:01 AM, James Cummings wrote: >>> >>> Just a reminder that any bugs, typos, corrections, and >>> schema-affecting changes you've spotted in the Guidelines should >>> be fixed by midnight tonight. This gives us all of Wednesday 1st >>> of Feb for proofreading and corrections of any additional typos >>> we find, with an intended release by MartinH on Thursday 2 February. >>> >>> Is the next release going to be 2.1.0 or 2.0.2? Correct me if >>> I'm wrong but If there have been schema-affecting changes then >>> the second number is meant to increment. Have there been >>> schema-affecting changes since 2.0.1? >>> >>> -James >>> >>> On 18/01/12 00:13, James Cummings wrote: >>>> >>>> Hi all, >>>> >>>> Since no one else has piped up, can I suggest a schedule: >>>> >>>> 31 January midnight GMT: submission deadline of significant changes >>>> 1 February: Whole Day for council to proofread and correct typos. >>>> 2nd February: Release (Codename: Groundhog Day) >>>> >>>> Since Martin asked, I suggest him as release technician. >>>> >>>> Any reasons why these dates are wholly unsuitable? >>>> >>>> -James >>>> >>>> On 17/01/12 16:11, Gabriel Bodard wrote: >>>>> Has there been any consensus on when 2.0.2 might be put out? >>>>> >>>>> (I ask because, if it's soon I won't both hacking the EpiDoc schema to >>>>> allow geo/@decl; I'll just wait for TEI to introduce it and regenerate >>>>> the schema properly. :-) ) >>>>> >>>>> G >>>>> >>>>> On 2012-01-12 17:39, Martin Holmes wrote: >>>>>> Hi all, >>>>>> >>>>>> I think we need to release a 2.0.2 soon, during which we again run >>>>>> through the instructions, after adding the tagging instruction. Should >>>>>> we do a quick trawl through the tickets and decide which ones might beS >>>>>> polished off quickly without controversy? >>>>>> >>>>>> Can I be the one to go through the release steps this time? >>>>>> >>>>>> Cheers, >>>>>> Martin >>>>>> >>>>>> On 12-01-12 08:27 AM, Peter Stadler wrote: >>>>>>> Dear geeks again, >>>>>>> >>>>>>> again wondering: just downloaded the current release 2.0.1 from sourceforge (tei-2.0.1.zip) and the editionStmt at tei-2.0.1/xml/tei/p5subset.xml reads2.0.0 Last updated on16th December 2011. >>>>>>> >>>>>>> Does that mean it wasn't updated at all or is just the editionStmt wrong? >>>>>>> >>>>>>> Many thanks again >>>>>>> Peter >>>>>>> >>>>>> >>>>> >>>> >>>> >>> >>> >> > -- Dr James Cummings, InfoDev, Computing Services, University of Oxford From mholmes at uvic.ca Wed Feb 1 08:24:14 2012 From: mholmes at uvic.ca (Martin Holmes) Date: Wed, 01 Feb 2012 05:24:14 -0800 Subject: [tei-council] Use of @cRef In-Reply-To: <4F29120E.5090603@oucs.ox.ac.uk> References: <4F281D31.5020206@uvic.ca> <4F29120E.5090603@oucs.ox.ac.uk> Message-ID: <4F293CFE.8090003@uvic.ca> I'm not sure whether I want to introduce the explanation of private URI schemes into the survey; it's really just trying to discover what people are currently doing with @cRef, and presumably nobody is using it that way; if they know about private URI schemes, they would naturally tend to put them into @target, I think. But the issue of private URI schemes is definitely something else we have to deal with. Whatever we do with @cRef, I think we should be encouraging people using private URI schemes to provide the same sort of canonical resolution pattern for any private scheme used in e.g. @target as they would when using @cRef in the traditional way. @target="foo:blort" is no less cryptic than @cRef="blort". This might require that we review at least the name of , turning it into , , or something like that. Not that I'm complying with this myself, of course. I'm guilty of using both @target="foo:blort" and @cRef="blort" without a , and I should be ashamed of myself. Cheers, Martin On 12-02-01 02:21 AM, James Cummings wrote: > > I like the survey, but should it be explained that data.pointer > can take a URI of the form foo:blort etc? i.e. that their @cRefs > probably can be easily represented as pointers? > > -James > > > On 31/01/12 16:56, Martin Holmes wrote: >> Hi all, >> >> The attribute @cRef (which appears on,, and) >> is currently a bit of a mess. I've started a bug for this: >> >> >> >> Changes have to be made to @cRef -- for one thing, the attribute is >> separately defined for each element, with different datatypes. It has >> been suggested that we no longer actually need it, because its original >> function (storing a canonical reference from a scheme defined in a >> element in the TEI header) can perfectly well be handled >> using @target, using a private URI scheme. However, it's arguable that >> having an attribute whose purpose is explicitly to handle private URI >> schemes (as opposed to official IANA-registered schemes) might be >> useful. If we were to switch to recommending @target and private URI >> schemes, I think we'd have to encourage people to provide resolution >> patterns for such schemes as we currently do with @cRef. >> >> It would be helpful to get a sense of what people are currently doing >> with @cRef, and how changes are likely to affect existing projects. I >> thought about a little survey we could circulate to TEI-L -- something >> like this: >> >> >> >> What do you think about this? (Assuming you can see the survey -- I'm >> not sure exactly how SurveyMonkey works in this regard, never having >> used it before. If you can't see it, let me know and I'll copy/paste the >> questions into an email.) >> >> I'd like to make some decisions about @cRef at the April meeting if >> that's possible, so a bit of prep now seems like a good idea. >> >> Cheers, >> Martin > > From mholmes at uvic.ca Wed Feb 1 08:25:11 2012 From: mholmes at uvic.ca (Martin Holmes) Date: Wed, 01 Feb 2012 05:25:11 -0800 Subject: [tei-council] Use of @cRef In-Reply-To: References: <4F281D31.5020206@uvic.ca> Message-ID: <4F293D37.3080801@uvic.ca> I hope you're right about the numbers, because my free account on Survey Monkey only allows for 100 responses to the survey. :-) On 12-02-01 02:10 AM, Sebastian Rahtz wrote: > I like the idea of the survey; my working assumption is that we only flush out 3 people using cRef, > and it'll turn out they still use P4 anyway :-} > > I have commented on ticket > -- > Stormageddon Rahtz > Head of Information and Support Group > Oxford University Computing Services > 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 Feb 1 11:30:52 2012 From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins) Date: Wed, 01 Feb 2012 11:30:52 -0500 Subject: [tei-council] Use of @cRef In-Reply-To: <4F293CFE.8090003@uvic.ca> References: <4F281D31.5020206@uvic.ca> <4F29120E.5090603@oucs.ox.ac.uk> <4F293CFE.8090003@uvic.ca> Message-ID: <4F2968BC.10908@ultraslavonic.info> It seems to me that private URI schemes relates to the question of private URN schemes and the future of @key. See: http://sourceforge.net/tracker/index.php?func=detail&group_id=106328&atid=644065&aid=3437509 Do we dare ask about people's use of @key as well? On 2/1/2012 8:24 AM, Martin Holmes wrote: > I'm not sure whether I want to introduce the explanation of private URI > schemes into the survey; it's really just trying to discover what people > are currently doing with @cRef, and presumably nobody is using it that > way; if they know about private URI schemes, they would naturally tend > to put them into @target, I think. > > But the issue of private URI schemes is definitely something else we > have to deal with. Whatever we do with @cRef, I think we should be > encouraging people using private URI schemes to provide the same sort of > canonical resolution pattern for any private scheme used in e.g. @target > as they would when using @cRef in the traditional way. > @target="foo:blort" is no less cryptic than @cRef="blort". This might > require that we review at least the name of, turning it > into,, or something like that. > > Not that I'm complying with this myself, of course. I'm guilty of using > both @target="foo:blort" and @cRef="blort" without a, and I > should be ashamed of myself. > > Cheers, > Martin > > On 12-02-01 02:21 AM, James Cummings wrote: >> >> I like the survey, but should it be explained that data.pointer >> can take a URI of the form foo:blort etc? i.e. that their @cRefs >> probably can be easily represented as pointers? >> >> -James >> >> >> On 31/01/12 16:56, Martin Holmes wrote: >>> Hi all, >>> >>> The attribute @cRef (which appears on,, and) >>> is currently a bit of a mess. I've started a bug for this: >>> >>> >>> >>> Changes have to be made to @cRef -- for one thing, the attribute is >>> separately defined for each element, with different datatypes. It has >>> been suggested that we no longer actually need it, because its original >>> function (storing a canonical reference from a scheme defined in a >>> element in the TEI header) can perfectly well be handled >>> using @target, using a private URI scheme. However, it's arguable that >>> having an attribute whose purpose is explicitly to handle private URI >>> schemes (as opposed to official IANA-registered schemes) might be >>> useful. If we were to switch to recommending @target and private URI >>> schemes, I think we'd have to encourage people to provide resolution >>> patterns for such schemes as we currently do with @cRef. >>> >>> It would be helpful to get a sense of what people are currently doing >>> with @cRef, and how changes are likely to affect existing projects. I >>> thought about a little survey we could circulate to TEI-L -- something >>> like this: >>> >>> >>> >>> What do you think about this? (Assuming you can see the survey -- I'm >>> not sure exactly how SurveyMonkey works in this regard, never having >>> used it before. If you can't see it, let me know and I'll copy/paste the >>> questions into an email.) >>> >>> I'd like to make some decisions about @cRef at the April meeting if >>> that's possible, so a bit of prep now seems like a good idea. >>> >>> Cheers, >>> Martin >> >> From mholmes at uvic.ca Wed Feb 1 12:20:57 2012 From: mholmes at uvic.ca (Martin Holmes) Date: Wed, 1 Feb 2012 09:20:57 -0800 Subject: [tei-council] Use of @cRef In-Reply-To: <4F2968BC.10908@ultraslavonic.info> References: <4F281D31.5020206@uvic.ca> <4F29120E.5090603@oucs.ox.ac.uk> <4F293CFE.8090003@uvic.ca> <4F2968BC.10908@ultraslavonic.info> Message-ID: <4F297479.4000109@uvic.ca> That's a great point. I knew there was something else bearing on this issue, but I couldn't recall what it was. It might be good to handle the two attributes separately, because if as Stormy and I suspect hardly anyone is using @cRef, we might be able to quietly remove it without much fuss; @key is not like that, though. Also, if the process of removing @cRef (or deprecating it) forces us to create a proper strategy and documentation for the use of private URI schemes, then we'll be in a better position when we come to deal with @key. Cheers, Martin On 12-02-01 08:30 AM, Kevin Hawkins wrote: > It seems to me that private URI schemes relates to the question of > private URN schemes and the future of @key. See: > > http://sourceforge.net/tracker/index.php?func=detail&group_id=106328&atid=644065&aid=3437509 > > Do we dare ask about people's use of @key as well? > > On 2/1/2012 8:24 AM, Martin Holmes wrote: >> I'm not sure whether I want to introduce the explanation of private URI >> schemes into the survey; it's really just trying to discover what people >> are currently doing with @cRef, and presumably nobody is using it that >> way; if they know about private URI schemes, they would naturally tend >> to put them into @target, I think. >> >> But the issue of private URI schemes is definitely something else we >> have to deal with. Whatever we do with @cRef, I think we should be >> encouraging people using private URI schemes to provide the same sort of >> canonical resolution pattern for any private scheme used in e.g. @target >> as they would when using @cRef in the traditional way. >> @target="foo:blort" is no less cryptic than @cRef="blort". This might >> require that we review at least the name of, turning it >> into,, or something like that. >> >> Not that I'm complying with this myself, of course. I'm guilty of using >> both @target="foo:blort" and @cRef="blort" without a, and I >> should be ashamed of myself. >> >> Cheers, >> Martin >> >> On 12-02-01 02:21 AM, James Cummings wrote: >>> >>> I like the survey, but should it be explained that data.pointer >>> can take a URI of the form foo:blort etc? i.e. that their @cRefs >>> probably can be easily represented as pointers? >>> >>> -James >>> >>> >>> On 31/01/12 16:56, Martin Holmes wrote: >>>> Hi all, >>>> >>>> The attribute @cRef (which appears on,, and) >>>> is currently a bit of a mess. I've started a bug for this: >>>> >>>> >>>> >>>> Changes have to be made to @cRef -- for one thing, the attribute is >>>> separately defined for each element, with different datatypes. It has >>>> been suggested that we no longer actually need it, because its original >>>> function (storing a canonical reference from a scheme defined in a >>>> element in the TEI header) can perfectly well be handled >>>> using @target, using a private URI scheme. However, it's arguable that >>>> having an attribute whose purpose is explicitly to handle private URI >>>> schemes (as opposed to official IANA-registered schemes) might be >>>> useful. If we were to switch to recommending @target and private URI >>>> schemes, I think we'd have to encourage people to provide resolution >>>> patterns for such schemes as we currently do with @cRef. >>>> >>>> It would be helpful to get a sense of what people are currently doing >>>> with @cRef, and how changes are likely to affect existing projects. I >>>> thought about a little survey we could circulate to TEI-L -- something >>>> like this: >>>> >>>> >>>> >>>> What do you think about this? (Assuming you can see the survey -- I'm >>>> not sure exactly how SurveyMonkey works in this regard, never having >>>> used it before. If you can't see it, let me know and I'll copy/paste the >>>> questions into an email.) >>>> >>>> I'd like to make some decisions about @cRef at the April meeting if >>>> that's possible, so a bit of prep now seems like a good idea. >>>> >>>> Cheers, >>>> Martin >>> >>> -- Martin Holmes University of Victoria Humanities Computing and Media Centre (mholmes at uvic.ca) From mholmes at uvic.ca Wed Feb 1 12:32:39 2012 From: mholmes at uvic.ca (Martin Holmes) Date: Wed, 1 Feb 2012 09:32:39 -0800 Subject: [tei-council] Release notes for the new release Message-ID: <4F297737.5030208@uvic.ca> HI all, We're winding up for a release tomorrow, and there are a couple of things I'd like to confirm: 1. We've decided, haven't we, that this release should be 2.0.2, not 2.1.0, because there are no schema-busting changes? 2. I've been looking at the readme/release notes. For 2.0.1, James did this:

The 2.0.1 release is a minor release fixing a number of bugs pointed out with the 2.0.0 release. However, since that was such a large release, its release notes are copied below.

That seems a good policy to me, and I propose to do the same thing, although I will trawl through the svn logs after 2.0.1 to identify anything I think is worthy of mention (adding to att.declaring is one thing that I think should be there). Is there anything else anyone would like to see in the release notes? Cheers, Martin -- Martin Holmes University of Victoria Humanities Computing and Media Centre (mholmes at uvic.ca) From James.Cummings at oucs.ox.ac.uk Wed Feb 1 17:39:55 2012 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Wed, 01 Feb 2012 22:39:55 +0000 Subject: [tei-council] nym/@parts Message-ID: <4F29BF3B.7020109@oucs.ox.ac.uk> Hiya, In reading through things (and correcting non-schema things relating to an old bug assigned to me) I happened to notice: http://teijenkins.hcmc.uvic.ca:8080/job/TEIP5-Documentation/ws/Guidelines-web/en/html/ref-nym.html The @parts attribute on is limited to 1 - 100 occurrences of data.pointer. Although I can't picture a good use case for more than 50 myself... there are plenty of places where we allow 1 - infinity pointers as an attribute value. Why are we so specific that there can't be more than 100 on nym/@part in specific? I ask this in full knowledge that I have hazy recollection of being part of the working group that introduced , but no recollection of the seemingly arbitrary limit in itself. Just curious, -James -- Dr James Cummings, InfoDev, Computing Services, University of Oxford From mholmes at uvic.ca Wed Feb 1 18:06:40 2012 From: mholmes at uvic.ca (Martin Holmes) Date: Wed, 1 Feb 2012 15:06:40 -0800 Subject: [tei-council] nym/@parts In-Reply-To: <4F29BF3B.7020109@oucs.ox.ac.uk> References: <4F29BF3B.7020109@oucs.ox.ac.uk> Message-ID: <4F29C580.5060208@uvic.ca> At first I thought it must be a typo -- someone copying from one-to-infinity on another attribute and misreading it as 1-100 -- but SVN says different: ------------------------------------------------------------------------ r2418 | louburnard | 2007-05-07 14:36:57 -0700 (Mon, 07 May 2007) | 2 lines removing @old on handShift; allowing up to 100 targets for nym at parts Lou, do you remember why? Cheers, Martin On 12-02-01 02:39 PM, James Cummings wrote: > > Hiya, > > In reading through things (and correcting non-schema things > relating to an old bug assigned to me) I happened to notice: > > http://teijenkins.hcmc.uvic.ca:8080/job/TEIP5-Documentation/ws/Guidelines-web/en/html/ref-nym.html > > The @parts attribute on is limited to 1 - 100 occurrences > of data.pointer. Although I can't picture a good use case for > more than 50 myself... there are plenty of places where we allow > 1 - infinity pointers as an attribute value. Why are we so > specific that there can't be more than 100 on nym/@part in specific? > > I ask this in full knowledge that I have hazy recollection of > being part of the working group that introduced, but no > recollection of the seemingly arbitrary limit in itself. > > Just curious, > > -James > -- Martin Holmes University of Victoria Humanities Computing and Media Centre (mholmes at uvic.ca) From lou.burnard at retired.ox.ac.uk Wed Feb 1 18:31:32 2012 From: lou.burnard at retired.ox.ac.uk (Lou Burnard) Date: Wed, 01 Feb 2012 23:31:32 +0000 Subject: [tei-council] nym/@parts In-Reply-To: <4F29C580.5060208@uvic.ca> References: <4F29BF3B.7020109@oucs.ox.ac.uk> <4F29C580.5060208@uvic.ca> Message-ID: <4F29CB54.1030109@retired.ox.ac.uk> Nope, don't remember why. Presumably someone thought, not implausibly, that allowing more than 100 values was rather silly, as James suggests. On 01/02/12 23:06, Martin Holmes wrote: > At first I thought it must be a typo -- someone copying from > one-to-infinity on another attribute and misreading it as 1-100 -- but > SVN says different: > > ------------------------------------------------------------------------ > r2418 | louburnard | 2007-05-07 14:36:57 -0700 (Mon, 07 May 2007) | 2 lines > > removing @old on handShift; allowing up to 100 targets for nym at parts > > > Lou, do you remember why? > > Cheers, > Martin > > On 12-02-01 02:39 PM, James Cummings wrote: >> >> Hiya, >> >> In reading through things (and correcting non-schema things >> relating to an old bug assigned to me) I happened to notice: >> >> http://teijenkins.hcmc.uvic.ca:8080/job/TEIP5-Documentation/ws/Guidelines-web/en/html/ref-nym.html >> >> The @parts attribute on is limited to 1 - 100 occurrences >> of data.pointer. Although I can't picture a good use case for >> more than 50 myself... there are plenty of places where we allow >> 1 - infinity pointers as an attribute value. Why are we so >> specific that there can't be more than 100 on nym/@part in specific? >> >> I ask this in full knowledge that I have hazy recollection of >> being part of the working group that introduced, but no >> recollection of the seemingly arbitrary limit in itself. >> >> Just curious, >> >> -James >> > From mholmes at uvic.ca Wed Feb 1 18:43:49 2012 From: mholmes at uvic.ca (Martin Holmes) Date: Wed, 1 Feb 2012 15:43:49 -0800 Subject: [tei-council] nym/@parts In-Reply-To: <4F29CB54.1030109@retired.ox.ac.uk> References: <4F29BF3B.7020109@oucs.ox.ac.uk> <4F29C580.5060208@uvic.ca> <4F29CB54.1030109@retired.ox.ac.uk> Message-ID: <4F29CE35.60307@uvic.ca> As a general rule, whenever you create a fixed array of a size you think is more than anyone could need, a need immediately arises for more. One-to-infinite is easier than explaining why a limit exists at all. I vote for change. Cheers, Martin On 12-02-01 03:31 PM, Lou Burnard wrote: > Nope, don't remember why. Presumably someone thought, not implausibly, > that allowing more than 100 values was rather silly, as James suggests. > > > On 01/02/12 23:06, Martin Holmes wrote: >> At first I thought it must be a typo -- someone copying from >> one-to-infinity on another attribute and misreading it as 1-100 -- but >> SVN says different: >> >> ------------------------------------------------------------------------ >> r2418 | louburnard | 2007-05-07 14:36:57 -0700 (Mon, 07 May 2007) | 2 lines >> >> removing @old on handShift; allowing up to 100 targets for nym at parts >> >> >> Lou, do you remember why? >> >> Cheers, >> Martin >> >> On 12-02-01 02:39 PM, James Cummings wrote: >>> >>> Hiya, >>> >>> In reading through things (and correcting non-schema things >>> relating to an old bug assigned to me) I happened to notice: >>> >>> http://teijenkins.hcmc.uvic.ca:8080/job/TEIP5-Documentation/ws/Guidelines-web/en/html/ref-nym.html >>> >>> The @parts attribute on is limited to 1 - 100 occurrences >>> of data.pointer. Although I can't picture a good use case for >>> more than 50 myself... there are plenty of places where we allow >>> 1 - infinity pointers as an attribute value. Why are we so >>> specific that there can't be more than 100 on nym/@part in specific? >>> >>> I ask this in full knowledge that I have hazy recollection of >>> being part of the working group that introduced, but no >>> recollection of the seemingly arbitrary limit in itself. >>> >>> Just curious, >>> >>> -James >>> >> > -- Martin Holmes University of Victoria Humanities Computing and Media Centre (mholmes at uvic.ca) From kevin.s.hawkins at ultraslavonic.info Wed Feb 1 18:44:58 2012 From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins) Date: Wed, 01 Feb 2012 18:44:58 -0500 Subject: [tei-council] nym/@parts In-Reply-To: <4F29CE35.60307@uvic.ca> References: <4F29BF3B.7020109@oucs.ox.ac.uk> <4F29C580.5060208@uvic.ca> <4F29CB54.1030109@retired.ox.ac.uk> <4F29CE35.60307@uvic.ca> Message-ID: <4F29CE7A.2090805@ultraslavonic.info> +1 On 2/1/12 6:43 PM, Martin Holmes wrote: > As a general rule, whenever you create a fixed array of a size you think > is more than anyone could need, a need immediately arises for more. > One-to-infinite is easier than explaining why a limit exists at all. I > vote for change. > > Cheers, > Martin > > On 12-02-01 03:31 PM, Lou Burnard wrote: >> Nope, don't remember why. Presumably someone thought, not implausibly, >> that allowing more than 100 values was rather silly, as James suggests. >> >> >> On 01/02/12 23:06, Martin Holmes wrote: >>> At first I thought it must be a typo -- someone copying from >>> one-to-infinity on another attribute and misreading it as 1-100 -- but >>> SVN says different: >>> >>> ------------------------------------------------------------------------ >>> r2418 | louburnard | 2007-05-07 14:36:57 -0700 (Mon, 07 May 2007) | 2 lines >>> >>> removing @old on handShift; allowing up to 100 targets for nym at parts >>> >>> >>> Lou, do you remember why? >>> >>> Cheers, >>> Martin >>> >>> On 12-02-01 02:39 PM, James Cummings wrote: >>>> >>>> Hiya, >>>> >>>> In reading through things (and correcting non-schema things >>>> relating to an old bug assigned to me) I happened to notice: >>>> >>>> http://teijenkins.hcmc.uvic.ca:8080/job/TEIP5-Documentation/ws/Guidelines-web/en/html/ref-nym.html >>>> >>>> The @parts attribute on is limited to 1 - 100 occurrences >>>> of data.pointer. Although I can't picture a good use case for >>>> more than 50 myself... there are plenty of places where we allow >>>> 1 - infinity pointers as an attribute value. Why are we so >>>> specific that there can't be more than 100 on nym/@part in specific? >>>> >>>> I ask this in full knowledge that I have hazy recollection of >>>> being part of the working group that introduced, but no >>>> recollection of the seemingly arbitrary limit in itself. >>>> >>>> Just curious, >>>> >>>> -James >>>> >>> >> > From rwelzenbach at gmail.com Wed Feb 1 23:11:59 2012 From: rwelzenbach at gmail.com (Rebecca Welzenbach) Date: Wed, 1 Feb 2012 23:11:59 -0500 Subject: [tei-council] Next Release; Codename: GroundHog Day In-Reply-To: <4F2934B8.9080108@oucs.ox.ac.uk> References: <48F7E21F-4B77-4865-AB90-47F6AA73ADBF@edirom.de> <4F0F1AD5.4070101@uvic.ca> <4F159DC1.4010001@kcl.ac.uk> <4F160E96.2010202@oucs.ox.ac.uk> <4F28025E.9050603@oucs.ox.ac.uk> <4F2810B0.2020303@uvic.ca> <4F2824A1.3060001@kcl.ac.uk> <4F2934B8.9080108@oucs.ox.ac.uk> Message-ID: Hi folks, I know I'm late--it's before midnight here, but not where the rest of you are--but found one typo: In 1.3.1 Attribute Classes, the sentence "This class is however a subclass of the att.pointing class, from which its members also inherit the attributes type and evaluate." ought to be, I think, "This class is however a subclass of the att.pointing class, from which its members also inherit the attributes *target* and evaluate." also submitted to sourceforge as a bug report. On Wed, Feb 1, 2012 at 7:48 AM, James Cummings wrote: > > A reminder that we are meant to be proofreading the release > today. So have a look at > http://teijenkins.hcmc.uvic.ca:8080/job/TEIP5-Documentation/ws/ > and > http://teijenkins.hcmc.uvic.ca:8080/job/TEIP5-Documentation/ws/Guidelines-web/en/html/index.html > > And point out anything (except for version and date) which are > wrong. ?If you are able to and believe it is a corrigible error > then go and fix it and commit them by midnight tonight. > Otherwise comment to the list for someone else to do so. > > If you can each spend an hour or so today looking at it, > hopefully will pick up some additional errors. > > -James > > On 31/01/12 17:28, Gabriel Bodard wrote: >> I have no strong feelings either way, but my understanding was that it >> was argued the addition of geo to att.declaring was an obvious bug-fix, >> and so shouldn't require a 2.1. (If I'm mistaken, or even if I'm correct >> but people disagree with this argument, then go ahead and name it 2.1.0.) >> >> G >> >> On 2012-01-31 16:02, Martin Holmes wrote: >>> I think there has been at least one schema-affecting change: >>> >>> ------------------------------------------------------------------------ >>> r10035 | gabrielbodard | 2012-01-12 09:54:18 -0800 (Thu, 12 Jan 2012) | >>> 1 line >>> >>> added ? to att.declaring >>> >>> So I guess we should be going for 2.1.0. >>> >>> Cheers, >>> Martin >>> >>> >>> On 12-01-31 07:01 AM, James Cummings wrote: >>>> >>>> Just a reminder that any bugs, typos, corrections, and >>>> schema-affecting changes you've spotted in the Guidelines should >>>> be fixed by midnight tonight. ?This gives us all of Wednesday 1st >>>> of Feb for proofreading and corrections of any additional typos >>>> we find, with an intended release by MartinH on Thursday 2 February. >>>> >>>> Is the next release going to be 2.1.0 or 2.0.2? ?Correct me if >>>> I'm wrong but If there have been schema-affecting changes then >>>> the second number is meant to increment. Have there been >>>> schema-affecting changes since 2.0.1? >>>> >>>> -James >>>> >>>> On 18/01/12 00:13, James Cummings wrote: >>>>> >>>>> Hi all, >>>>> >>>>> Since no one else has piped up, can I suggest a schedule: >>>>> >>>>> 31 January midnight GMT: submission deadline of significant changes >>>>> 1 February: Whole Day for council to proofread and correct typos. >>>>> 2nd February: Release (Codename: Groundhog Day) >>>>> >>>>> Since Martin asked, I suggest him as release technician. >>>>> >>>>> Any reasons why these dates are wholly unsuitable? >>>>> >>>>> -James >>>>> >>>>> On 17/01/12 16:11, Gabriel Bodard wrote: >>>>>> Has there been any consensus on when 2.0.2 might be put out? >>>>>> >>>>>> (I ask because, if it's soon I won't both hacking the EpiDoc schema to >>>>>> allow geo/@decl; I'll just wait for TEI to introduce it and regenerate >>>>>> the schema properly. :-) ) >>>>>> >>>>>> G >>>>>> >>>>>> On 2012-01-12 17:39, Martin Holmes wrote: >>>>>>> Hi all, >>>>>>> >>>>>>> I think we need to release a 2.0.2 soon, during which we again run >>>>>>> through the instructions, after adding the tagging instruction. Should >>>>>>> we do a quick trawl through the tickets and decide which ones might beS >>>>>>> polished off quickly without controversy? >>>>>>> >>>>>>> Can I be the one to go through the release steps this time? >>>>>>> >>>>>>> Cheers, >>>>>>> Martin >>>>>>> >>>>>>> On 12-01-12 08:27 AM, Peter Stadler wrote: >>>>>>>> Dear geeks again, >>>>>>>> >>>>>>>> again wondering: just downloaded the current release 2.0.1 from sourceforge (tei-2.0.1.zip) and the editionStmt at tei-2.0.1/xml/tei/p5subset.xml reads2.0.0 Last updated on16th December 2011. >>>>>>>> >>>>>>>> Does that mean it wasn't updated at all or is just the editionStmt wrong? >>>>>>>> >>>>>>>> Many thanks again >>>>>>>> Peter >>>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>> >> > > > -- > Dr James Cummings, InfoDev, > Computing Services, University of Oxford > -- > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > > PLEASE NOTE: postings to this list are publicly archived From sebastian.rahtz at oucs.ox.ac.uk Thu Feb 2 04:51:17 2012 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Thu, 2 Feb 2012 09:51:17 +0000 Subject: [tei-council] Next Release; Codename: GroundHog Day In-Reply-To: References: <48F7E21F-4B77-4865-AB90-47F6AA73ADBF@edirom.de> <4F0F1AD5.4070101@uvic.ca> <4F159DC1.4010001@kcl.ac.uk> <4F160E96.2010202@oucs.ox.ac.uk> <4F28025E.9050603@oucs.ox.ac.uk> <4F2810B0.2020303@uvic.ca> <4F2824A1.3060001@kcl.ac.uk> <4F2934B8.9080108@oucs.ox.ac.uk> Message-ID: <40a553c3-dcb5-4279-99a1-be8d40b2cfe9@exht04.ad.oak.ox.ac.uk> On 2 Feb 2012, at 04:11, Rebecca Welzenbach wrote: > In 1.3.1 Attribute Classes, the sentence > > "This class is however a subclass of the att.pointing class, from > which its members also inherit the attributes type and evaluate." > > ought to be, I think, > > "This class is however a subclass of the att.pointing class, from > which its members also inherit the attributes *target* and evaluate." > what I can see is "also inherit the attributes @type and @evaluate", which is how attribute names are displayed. That's right, surely? what rendering are you looking at? -- Stormageddon Rahtz Head of Information and Support Group Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From lou.burnard at retired.ox.ac.uk Thu Feb 2 04:53:53 2012 From: lou.burnard at retired.ox.ac.uk (Lou Burnard) Date: Thu, 02 Feb 2012 09:53:53 +0000 Subject: [tei-council] Next Release; Codename: GroundHog Day In-Reply-To: <40a553c3-dcb5-4279-99a1-be8d40b2cfe9@exht04.ad.oak.ox.ac.uk> References: <48F7E21F-4B77-4865-AB90-47F6AA73ADBF@edirom.de> <4F0F1AD5.4070101@uvic.ca> <4F159DC1.4010001@kcl.ac.uk> <4F160E96.2010202@oucs.ox.ac.uk> <4F28025E.9050603@oucs.ox.ac.uk> <4F2810B0.2020303@uvic.ca> <4F2824A1.3060001@kcl.ac.uk> <4F2934B8.9080108@oucs.ox.ac.uk> <40a553c3-dcb5-4279-99a1-be8d40b2cfe9@exht04.ad.oak.ox.ac.uk> Message-ID: <4F2A5D31.7090002@retired.ox.ac.uk> On 02/02/12 09:51, Sebastian Rahtz wrote: > > On 2 Feb 2012, at 04:11, Rebecca Welzenbach wrote: > >> In 1.3.1 Attribute Classes, the sentence >> >> "This class is however a subclass of the att.pointing class, from >> which its members also inherit the attributes type and evaluate." >> >> ought to be, I think, >> >> "This class is however a subclass of the att.pointing class, from >> which its members also inherit the attributes *target* and evaluate." >> > > what I can see is "also inherit the attributes @type and @evaluate", which is how attribute > names are displayed. That's right, surely? > > what rendering are you looking at? > > I think Rebecca's point is (correctly) that @type is not inherited form the att.pointing class, whereas @target is. Nothing to do with the rendering. Am fixing. From sebastian.rahtz at oucs.ox.ac.uk Thu Feb 2 04:55:03 2012 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Thu, 2 Feb 2012 09:55:03 +0000 Subject: [tei-council] Next Release; Codename: GroundHog Day In-Reply-To: <4F2A5D31.7090002@retired.ox.ac.uk> References: <48F7E21F-4B77-4865-AB90-47F6AA73ADBF@edirom.de> <4F0F1AD5.4070101@uvic.ca> <4F159DC1.4010001@kcl.ac.uk> <4F160E96.2010202@oucs.ox.ac.uk> <4F28025E.9050603@oucs.ox.ac.uk> <4F2810B0.2020303@uvic.ca> <4F2824A1.3060001@kcl.ac.uk> <4F2934B8.9080108@oucs.ox.ac.uk> <40a553c3-dcb5-4279-99a1-be8d40b2cfe9@exht04.ad.oak.ox.ac.uk> <4F2A5D31.7090002@retired.ox.ac.uk> Message-ID: >> > I think Rebecca's point is (correctly) that @type is not inherited form > the att.pointing class, whereas @target is. Nothing to do with the > rendering. ah, sorry, Rebecca, was reading too fast. -- Stormageddon Rahtz Head of Information and Support Group Oxford University Computing Services 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 Feb 2 04:57:32 2012 From: james.cummings at oucs.ox.ac.uk (James Cummings) Date: Thu, 2 Feb 2012 09:57:32 +0000 Subject: [tei-council] Next Release; Codename: GroundHog Day Message-ID: I believe Becky is arguing that it should be target not type. JamesC -- James Cummings, InfoDev, OUCS, University of Oxford (via phone) Sebastian Rahtz wrote: On 2 Feb 2012, at 04:11, Rebecca Welzenbach wrote: > In 1.3.1 Attribute Classes, the sentence > > "This class is however a subclass of the att.pointing class, from > which its members also inherit the attributes type and evaluate." > > ought to be, I think, > > "This class is however a subclass of the att.pointing class, from > which its members also inherit the attributes *target* and evaluate." > what I can see is "also inherit the attributes @type and @evaluate", which is how attribute names are displayed. That's right, surely? what rendering are you looking at? -- Stormageddon Rahtz Head of Information and Support Group Oxford University Computing 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 PLEASE NOTE: postings to this list are publicly archived From James.Cummings at oucs.ox.ac.uk Thu Feb 2 05:14:39 2012 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Thu, 02 Feb 2012 10:14:39 +0000 Subject: [tei-council] Next Release; Codename: GroundHog Day In-Reply-To: References: Message-ID: <4F2A620F.4080201@oucs.ox.ac.uk> On 02/02/12 09:57, James Cummings wrote: > > I believe Becky is arguing that it should be target not type. And I was slower than Lou in pointing it out, and indeed fixing it in SVN. On the topic of TEI Guidelines releases over the last couple days I've updated tcw20.xml with a list of steps for a 'release technician', who is the person in charge of making the release (in this case Martin), with a list of steps that the technician must ensure are completed. Martin, Sebastian, and I have talked through some of them which are a bit vague at the moment (like "Ensure that the oxygen-tei project is updated"), but if I've left out any steps do please let me know (or add them to the list if you are able). We may break out 'How to release the TEI Guidelines' as a separate document from its current place in 'How to edit the TEI Guidelines' eventually. As it is about 10am here that means it is about 2am in Vancouver. When Martin wakes up (this afternoon for my timezone) he will begin going through those steps. *If* all goes smoothly then I *believe* that this may be the first release of TEI P5 that has not been pushed live by someone affiliated in some way with Oxford. (Correct me if I'm wrong Lou?) If that is indeed the case I'd like to include it in the announcement to TEI-L as an indication of how the TEI is becoming increasingly a distributed open source project, etc. (Not that it wasn't before but it is good if it is seen as such.) -James -- Dr James Cummings, InfoDev, Computing Services, University of Oxford From James.Cummings at oucs.ox.ac.uk Thu Feb 2 05:33:59 2012 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Thu, 02 Feb 2012 10:33:59 +0000 Subject: [tei-council] TEI Council TeleConference Message-ID: <4F2A6697.8000409@oucs.ox.ac.uk> Hi all, One of the things we mentioned at our last f2f meeting was that we should have more regular teleconferences. To this end I'd like to schedule on one of the 27/28/29th. The times that are best for outliers like MartinH and StuartY I believe are 18:00/19:00/20:00 UTC. (Which it good for people in Ann Arbor, but an evening call for us in Europe.) If everyone can fill in this doodle poll: http://www.doodle.com/6akx9cqy2zdcbdkn with your availability. I've enabled 'time-zone support' so hopefully it should show you what those times are in your own location, but you may wish to double-check that at: http://timeanddate.com/worldclock/meetingtime.html?iso=20120228&p1=136&p2=256&p3=264&p4=37&p5=77 Teleconferencing system to be decided. (John Unsworth has one he has been trialling and has set me up on it.) Many thanks, James -- Dr James Cummings, InfoDev, Computing Services, University of Oxford From mholmes at uvic.ca Thu Feb 2 08:17:03 2012 From: mholmes at uvic.ca (Martin Holmes) Date: Thu, 02 Feb 2012 05:17:03 -0800 Subject: [tei-council] Next Release; Codename: GroundHog Day In-Reply-To: <4F2A620F.4080201@oucs.ox.ac.uk> References: <4F2A620F.4080201@oucs.ox.ac.uk> Message-ID: <4F2A8CCF.8080304@uvic.ca> I'm up and beginning work on it now. I'm currently working with Sebastian to get my Jenkins server in sync with his, and I'm writing the release notes. Hoping to get those done, and VERSION updated, before breakfast, then during the time when I'm going to work, the Jenkins servers will do their thing and I'll have release packages ready by the time I get to the office. Then I'll carry on from there. Cheers, Martin On 12-02-02 02:14 AM, James Cummings wrote: > On 02/02/12 09:57, James Cummings wrote: >> >> I believe Becky is arguing that it should be target not type. > > And I was slower than Lou in pointing it out, and indeed fixing > it in SVN. > > On the topic of TEI Guidelines releases over the last couple days > I've updated tcw20.xml with a list of steps for a 'release > technician', who is the person in charge of making the release > (in this case Martin), with a list of steps that the technician > must ensure are completed. > > Martin, Sebastian, and I have talked through some of them which > are a bit vague at the moment (like "Ensure that the oxygen-tei > project is updated"), but if I've left out any steps do please > let me know (or add them to the list if you are able). We may > break out 'How to release the TEI Guidelines' as a separate > document from its current place in 'How to edit the TEI > Guidelines' eventually. > > As it is about 10am here that means it is about 2am in Vancouver. > When Martin wakes up (this afternoon for my timezone) he will > begin going through those steps. *If* all goes smoothly then I > *believe* that this may be the first release of TEI P5 that has > not been pushed live by someone affiliated in some way with > Oxford. (Correct me if I'm wrong Lou?) If that is indeed the > case I'd like to include it in the announcement to TEI-L as an > indication of how the TEI is becoming increasingly a distributed > open source project, etc. (Not that it wasn't before but it is > good if it is seen as such.) > > -James > From mholmes at uvic.ca Thu Feb 2 08:36:23 2012 From: mholmes at uvic.ca (Martin Holmes) Date: Thu, 02 Feb 2012 05:36:23 -0800 Subject: [tei-council] Next Release; Codename: GroundHog Day In-Reply-To: <4F2A8CCF.8080304@uvic.ca> References: <4F2A620F.4080201@oucs.ox.ac.uk> <4F2A8CCF.8080304@uvic.ca> Message-ID: <4F2A9157.1080308@uvic.ca> OK, Jenkins is updated, and the VERSION file, readme and guidelines-* files have been done. Waiting for the Jinkses to do their thing. Could we hold off on commits for the rest of the day, just to keep things simple? Cheers, Martin On 12-02-02 05:17 AM, Martin Holmes wrote: > I'm up and beginning work on it now. I'm currently working with > Sebastian to get my Jenkins server in sync with his, and I'm writing the > release notes. Hoping to get those done, and VERSION updated, before > breakfast, then during the time when I'm going to work, the Jenkins > servers will do their thing and I'll have release packages ready by the > time I get to the office. Then I'll carry on from there. > > Cheers, > Martin > > On 12-02-02 02:14 AM, James Cummings wrote: >> On 02/02/12 09:57, James Cummings wrote: >>> >>> I believe Becky is arguing that it should be target not type. >> >> And I was slower than Lou in pointing it out, and indeed fixing >> it in SVN. >> >> On the topic of TEI Guidelines releases over the last couple days >> I've updated tcw20.xml with a list of steps for a 'release >> technician', who is the person in charge of making the release >> (in this case Martin), with a list of steps that the technician >> must ensure are completed. >> >> Martin, Sebastian, and I have talked through some of them which >> are a bit vague at the moment (like "Ensure that the oxygen-tei >> project is updated"), but if I've left out any steps do please >> let me know (or add them to the list if you are able). We may >> break out 'How to release the TEI Guidelines' as a separate >> document from its current place in 'How to edit the TEI >> Guidelines' eventually. >> >> As it is about 10am here that means it is about 2am in Vancouver. >> When Martin wakes up (this afternoon for my timezone) he will >> begin going through those steps. *If* all goes smoothly then I >> *believe* that this may be the first release of TEI P5 that has >> not been pushed live by someone affiliated in some way with >> Oxford. (Correct me if I'm wrong Lou?) If that is indeed the >> case I'd like to include it in the announcement to TEI-L as an >> indication of how the TEI is becoming increasingly a distributed >> open source project, etc. (Not that it wasn't before but it is >> good if it is seen as such.) >> >> -James >> From James.Cummings at oucs.ox.ac.uk Thu Feb 2 08:54:00 2012 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Thu, 02 Feb 2012 13:54:00 +0000 Subject: [tei-council] Next Release; Codename: GroundHog Day In-Reply-To: <4F2A9157.1080308@uvic.ca> References: <4F2A620F.4080201@oucs.ox.ac.uk> <4F2A8CCF.8080304@uvic.ca> <4F2A9157.1080308@uvic.ca> Message-ID: <4F2A9578.3060205@oucs.ox.ac.uk> On 02/02/12 13:36, Martin Holmes wrote: > OK, Jenkins is updated, and the VERSION file, readme and guidelines-* > files have been done. Waiting for the Jinkses to do their thing. Could > we hold off on commits for the rest of the day, just to keep things simple? For those following along a home, this is Martin doing step 4 of: http://www.tei-c.org/Activities/Council/Working/tcw20.xml#release-steps in announcing a temporary freeze on commits to SVN to the council mailing list. (Because, of course, if you commit something, Jenkins fires off again and we have to wait through the entire build again.) -James > > Cheers, > Martin > > On 12-02-02 05:17 AM, Martin Holmes wrote: >> I'm up and beginning work on it now. I'm currently working with >> Sebastian to get my Jenkins server in sync with his, and I'm writing the >> release notes. Hoping to get those done, and VERSION updated, before >> breakfast, then during the time when I'm going to work, the Jenkins >> servers will do their thing and I'll have release packages ready by the >> time I get to the office. Then I'll carry on from there. >> >> Cheers, >> Martin >> >> On 12-02-02 02:14 AM, James Cummings wrote: >>> On 02/02/12 09:57, James Cummings wrote: >>>> >>>> I believe Becky is arguing that it should be target not type. >>> >>> And I was slower than Lou in pointing it out, and indeed fixing >>> it in SVN. >>> >>> On the topic of TEI Guidelines releases over the last couple days >>> I've updated tcw20.xml with a list of steps for a 'release >>> technician', who is the person in charge of making the release >>> (in this case Martin), with a list of steps that the technician >>> must ensure are completed. >>> >>> Martin, Sebastian, and I have talked through some of them which >>> are a bit vague at the moment (like "Ensure that the oxygen-tei >>> project is updated"), but if I've left out any steps do please >>> let me know (or add them to the list if you are able). We may >>> break out 'How to release the TEI Guidelines' as a separate >>> document from its current place in 'How to edit the TEI >>> Guidelines' eventually. >>> >>> As it is about 10am here that means it is about 2am in Vancouver. >>> When Martin wakes up (this afternoon for my timezone) he will >>> begin going through those steps. *If* all goes smoothly then I >>> *believe* that this may be the first release of TEI P5 that has >>> not been pushed live by someone affiliated in some way with >>> Oxford. (Correct me if I'm wrong Lou?) If that is indeed the >>> case I'd like to include it in the announcement to TEI-L as an >>> indication of how the TEI is becoming increasingly a distributed >>> open source project, etc. (Not that it wasn't before but it is >>> good if it is seen as such.) >>> >>> -James >>> -- Dr James Cummings, InfoDev, Computing Services, University of Oxford From mholmes at uvic.ca Thu Feb 2 11:00:32 2012 From: mholmes at uvic.ca (Martin Holmes) Date: Thu, 2 Feb 2012 08:00:32 -0800 Subject: [tei-council] Next Release; Codename: GroundHog Day In-Reply-To: <4F2A9578.3060205@oucs.ox.ac.uk> References: <4F2A620F.4080201@oucs.ox.ac.uk> <4F2A8CCF.8080304@uvic.ca> <4F2A9157.1080308@uvic.ca> <4F2A9578.3060205@oucs.ox.ac.uk> Message-ID: <4F2AB320.3040503@uvic.ca> The freeze doesn't apply to fixing the error in the readme file that I added in step 1, of course. :-) There will now be a short interlude while the Jinkses rebuild the broken documentation.... Cheers, Martin On 12-02-02 05:54 AM, James Cummings wrote: > On 02/02/12 13:36, Martin Holmes wrote: >> OK, Jenkins is updated, and the VERSION file, readme and guidelines-* >> files have been done. Waiting for the Jinkses to do their thing. Could >> we hold off on commits for the rest of the day, just to keep things simple? > > For those following along a home, this is Martin doing step 4 of: > > http://www.tei-c.org/Activities/Council/Working/tcw20.xml#release-steps > > in announcing a temporary freeze on commits to SVN to the council > mailing list. > > (Because, of course, if you commit something, Jenkins fires off > again and we have to wait through the entire build again.) > > -James > >> >> Cheers, >> Martin >> >> On 12-02-02 05:17 AM, Martin Holmes wrote: >>> I'm up and beginning work on it now. I'm currently working with >>> Sebastian to get my Jenkins server in sync with his, and I'm writing the >>> release notes. Hoping to get those done, and VERSION updated, before >>> breakfast, then during the time when I'm going to work, the Jenkins >>> servers will do their thing and I'll have release packages ready by the >>> time I get to the office. Then I'll carry on from there. >>> >>> Cheers, >>> Martin >>> >>> On 12-02-02 02:14 AM, James Cummings wrote: >>>> On 02/02/12 09:57, James Cummings wrote: >>>>> >>>>> I believe Becky is arguing that it should be target not type. >>>> >>>> And I was slower than Lou in pointing it out, and indeed fixing >>>> it in SVN. >>>> >>>> On the topic of TEI Guidelines releases over the last couple days >>>> I've updated tcw20.xml with a list of steps for a 'release >>>> technician', who is the person in charge of making the release >>>> (in this case Martin), with a list of steps that the technician >>>> must ensure are completed. >>>> >>>> Martin, Sebastian, and I have talked through some of them which >>>> are a bit vague at the moment (like "Ensure that the oxygen-tei >>>> project is updated"), but if I've left out any steps do please >>>> let me know (or add them to the list if you are able). We may >>>> break out 'How to release the TEI Guidelines' as a separate >>>> document from its current place in 'How to edit the TEI >>>> Guidelines' eventually. >>>> >>>> As it is about 10am here that means it is about 2am in Vancouver. >>>> When Martin wakes up (this afternoon for my timezone) he will >>>> begin going through those steps. *If* all goes smoothly then I >>>> *believe* that this may be the first release of TEI P5 that has >>>> not been pushed live by someone affiliated in some way with >>>> Oxford. (Correct me if I'm wrong Lou?) If that is indeed the >>>> case I'd like to include it in the announcement to TEI-L as an >>>> indication of how the TEI is becoming increasingly a distributed >>>> open source project, etc. (Not that it wasn't before but it is >>>> good if it is seen as such.) >>>> >>>> -James >>>> > > -- Martin Holmes University of Victoria Humanities Computing and Media Centre (mholmes at uvic.ca) From mholmes at uvic.ca Thu Feb 2 12:59:19 2012 From: mholmes at uvic.ca (Martin Holmes) Date: Thu, 2 Feb 2012 09:59:19 -0800 Subject: [tei-council] Slight glitch with the release Message-ID: <4F2ACEF7.9070706@uvic.ca> Hi all, Just letting everyone know we've hit a minor issue: the install script that grabs the newly-built release from the Jenkins server and puts it on the TEI site is failing to do the grabbing. I suspect this is a permissions issue relating to my account on the TEI server, but I'm not sure yet. This sort of thing isn't entirely unexpected. One of the reasons for my doing this release as opposed to James or Sebastian is so we can find out about glitches like this, and document everything more thoroughly. Cheers, Martin -- Martin Holmes University of Victoria Humanities Computing and Media Centre (mholmes at uvic.ca) From mholmes at uvic.ca Thu Feb 2 13:36:02 2012 From: mholmes at uvic.ca (Martin Holmes) Date: Thu, 2 Feb 2012 10:36:02 -0800 Subject: [tei-council] So far so good, but... Message-ID: <4F2AD792.5060508@uvic.ca> James gave me write permission to the relevant directory, so I've been able to run the scripts on the server, as well as creating the SVN tag and setting 2.0.2 as the default download. The main TEI site now has 2.0.2 (which I determined by checking that is a member of att.declaring -- there seems to be no easy way to see what version of the Guidelines you're looking at on the server). I'm now at this stage: ------ Add an announcement to the SourceForge news feed Someone with admin privileges on the SourceForge site creates an announcement. Make sure the announcement is categorized as "News" on SourceForge so that it will appear under "TEI-C News" on the TEI website. ------- but I don't seem to have any way to post an announcement to the blog (which is the WordPress install on SF): I'm still digging around, but I see no "post" button when logged in as martindholmes (my SF user, which is a project admin). Still working on this. James, do I need special permission or am I just missing the obvious as usual? Cheers, Martin -- Martin Holmes University of Victoria Humanities Computing and Media Centre (mholmes at uvic.ca) From dsewell at virginia.edu Thu Feb 2 13:41:12 2012 From: dsewell at virginia.edu (David Sewell) Date: Thu, 2 Feb 2012 13:41:12 -0500 (EST) Subject: [tei-council] So far so good, but... In-Reply-To: <4F2AD792.5060508@uvic.ca> References: <4F2AD792.5060508@uvic.ca> Message-ID: Martin, I just changed your Wordpress user role to "Editor", so try logging out & logging back in On Thu, 2 Feb 2012, Martin Holmes wrote: > James gave me write permission to the relevant directory, so I've been > able to run the scripts on the server, as well as creating the SVN tag > and setting 2.0.2 as the default download. The main TEI site now has > 2.0.2 (which I determined by checking that is a member of > att.declaring -- there seems to be no easy way to see what version of > the Guidelines you're looking at on the server). > > I'm now at this stage: > > ------ > Add an announcement to the SourceForge news feed > > Someone with admin privileges on the SourceForge site creates an > announcement. Make sure the announcement is categorized as "News" on > SourceForge so that it will appear under "TEI-C News" on the TEI website. > ------- > > but I don't seem to have any way to post an announcement to the blog > (which is the WordPress install on SF): > > > > I'm still digging around, but I see no "post" button when logged in as > martindholmes (my SF user, which is a project admin). Still working on > this. James, do I need special permission or am I just missing the > obvious as usual? > > Cheers, > Martin > -- David Sewell, Editorial and Technical Manager ROTUNDA, The University of Virginia Press PO Box 400314, Charlottesville, VA 22904-4314 USA Email: dsewell at virginia.edu Tel: +1 434 924 9973 Web: http://rotunda.upress.virginia.edu/ From James.Cummings at oucs.ox.ac.uk Thu Feb 2 13:49:49 2012 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Thu, 02 Feb 2012 18:49:49 +0000 Subject: [tei-council] So far so good, but... In-Reply-To: <4F2AD792.5060508@uvic.ca> References: <4F2AD792.5060508@uvic.ca> Message-ID: <4F2ADACD.7060109@oucs.ox.ac.uk> On 02/02/12 18:36, Martin Holmes wrote: > James gave me write permission to the relevant directory, so I've been > able to run the scripts on the server, as well as creating the SVN tag > and setting 2.0.2 as the default download. The main TEI site now has > 2.0.2 (which I determined by checking that is a member of > att.declaring -- there seems to be no easy way to see what version of > the Guidelines you're looking at on the server). Use the footer, Luke. -James > I'm now at this stage: Which is why I had step 13 be to ask the Council Chair to do this for you (so that not every release technician has to get SF blog editing permissions just to make a release). ;-) -James -- Dr James Cummings, InfoDev Oxford University Computing Services University of Oxford From James.Cummings at oucs.ox.ac.uk Thu Feb 2 14:43:19 2012 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Thu, 02 Feb 2012 19:43:19 +0000 Subject: [tei-council] So far so good, but... In-Reply-To: <4F2ADACD.7060109@oucs.ox.ac.uk> References: <4F2AD792.5060508@uvic.ca> <4F2ADACD.7060109@oucs.ox.ac.uk> Message-ID: <4F2AE757.3000703@oucs.ox.ac.uk> Just to say, that aside from the slight permissions error, the release of TEI P5 2.0.2 seems to have gone well. Thank you Martin for being a Guinea Pig (Or is that Groundhog?). People can go back to committing to the SVN repository! :-) We discovered that it might be better to move the installation scripts on the tei-c.org machine to somewhere central (e.g. /home/tei/) and run them from there, and some other small corrections to the list of steps that Martin will add in due course. -James -- Dr James Cummings, InfoDev Oxford University Computing Services University of Oxford From mholmes at uvic.ca Thu Feb 2 14:52:43 2012 From: mholmes at uvic.ca (Martin Holmes) Date: Thu, 2 Feb 2012 11:52:43 -0800 Subject: [tei-council] So far so good In-Reply-To: <4F2AE757.3000703@oucs.ox.ac.uk> References: <4F2AD792.5060508@uvic.ca> <4F2ADACD.7060109@oucs.ox.ac.uk> <4F2AE757.3000703@oucs.ox.ac.uk> Message-ID: <4F2AE98B.3080901@uvic.ca> We'll spin off the release instructions into their own page, and expand them with a lot more detail. As usual, what's obvious to someone who's done it once is not necessarily obvious to a first-timer. Thanks to James, David, and Sebastian for necessary hand-holding. :-) Cheers, Martin On 12-02-02 11:43 AM, James Cummings wrote: > > Just to say, that aside from the slight permissions error, the > release of TEI P5 2.0.2 seems to have gone well. Thank you Martin > for being a Guinea Pig (Or is that Groundhog?). People can go > back to committing to the SVN repository! :-) > > We discovered that it might be better to move the installation > scripts on the tei-c.org machine to somewhere central (e.g. > /home/tei/) and run them from there, and some other small > corrections to the list of steps that Martin will add in due course. > > -James > -- Martin Holmes University of Victoria Humanities Computing and Media Centre (mholmes at uvic.ca) From mholmes at uvic.ca Thu Feb 2 23:42:43 2012 From: mholmes at uvic.ca (Martin Holmes) Date: Thu, 02 Feb 2012 20:42:43 -0800 Subject: [tei-council] New document describing release steps Message-ID: <4F2B65C3.8070201@uvic.ca> Following my thrilling day of first-times (first time releasing TEI, first time retweeting someone else's tweet, first time using IRC), I've put together a more detailed set of instructions for future release technicians: I've taken the core information in TCW20 relating to building a release, and elaborated and extended it to include things we didn't know we didn't know until today. I've also tried to explain why you take each step and how it works, so you don't find yourself blindly following mysterious instructions. Please take a look through the document. If you've done a release before, check to make sure I haven't left anything out or got anything wrong. If you haven't done one, read it and see if you think it would be clear and detailed enough to help you through the process. I haven't made any changes to TWC20, but if the new document is acceptable, I propose removing all those bits from TCW20 and replacing them with a reference to the new doc. I haven't published the new doc yet, so it doesn't appear on the TEI site menu. I shall close with the now-traditional expression of hatred for the CMS system, which I must utter every time I have to interact with it. GRRR. ;-) Cheers, Martin From sebastian.rahtz at oucs.ox.ac.uk Fri Feb 3 04:41:32 2012 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Fri, 3 Feb 2012 09:41:32 +0000 Subject: [tei-council] New document describing release steps In-Reply-To: <4F2B65C3.8070201@uvic.ca> References: <4F2B65C3.8070201@uvic.ca> Message-ID: <81DCE54E-2A35-4C9C-906B-09A1F6058BB6@oucs.ox.ac.uk> On 3 Feb 2012, at 04:42, Martin Holmes wrote: > Following my thrilling day of first-times (first time releasing TEI, > first time retweeting someone else's tweet, first time using IRC), I've > put together a more detailed set of instructions for future release > technicians: > > I'm getting a 500 error I am afraid -- Stormageddon Rahtz Head of Information and Support Group Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From lou.burnard at retired.ox.ac.uk Fri Feb 3 04:42:50 2012 From: lou.burnard at retired.ox.ac.uk (Lou Burnard) Date: Fri, 03 Feb 2012 09:42:50 +0000 Subject: [tei-council] New document describing release steps In-Reply-To: <4F2B65C3.8070201@uvic.ca> References: <4F2B65C3.8070201@uvic.ca> Message-ID: <4F2BAC1A.207@retired.ox.ac.uk> On 03/02/12 04:42, Martin Holmes wrote: > I shall close with the now-traditional expression of hatred for the CMS > system, which I must utter every time I have to interact with it. GRRR. ;-) It seems to be taking its revenge. At any rate the URL you quote doesnt work for me! From James.Cummings at oucs.ox.ac.uk Fri Feb 3 05:01:42 2012 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Fri, 03 Feb 2012 10:01:42 +0000 Subject: [tei-council] New document describing release steps In-Reply-To: <4F2BAC1A.207@retired.ox.ac.uk> References: <4F2B65C3.8070201@uvic.ca> <4F2BAC1A.207@retired.ox.ac.uk> Message-ID: <4F2BB086.3090501@oucs.ox.ac.uk> If Martin hasn't published it, it will not be visible unless you have already logged into openCMS. (Martin: Publishing it isn't what makes it appear in the list... that is just by adding it to index.xml. If you did want something to appear in the left-hand navigation you had to do so intentionally, by right-clicking on it and look at its 'properties' where you can 'add it to navigation'.) I've 'stolen lock' from Martin and published it, but not added it to index.xml yet. So you should be able to see it now at: http://www.tei-c.org/Activities/Council/Working/tcw22.xml Don't get me started on OpenCMS... -James On 03/02/12 09:42, Lou Burnard wrote: > On 03/02/12 04:42, Martin Holmes wrote: > >> I shall close with the now-traditional expression of hatred for the CMS >> system, which I must utter every time I have to interact with it. GRRR. ;-) > > It seems to be taking its revenge. At any rate the URL you quote > > > > doesnt work for me! > > > -- Dr James Cummings, InfoDev, Computing Services, University of Oxford From gabriel.bodard at kcl.ac.uk Fri Feb 3 07:57:50 2012 From: gabriel.bodard at kcl.ac.uk (Gabriel Bodard) Date: Fri, 3 Feb 2012 12:57:50 +0000 Subject: [tei-council] New document describing release steps In-Reply-To: <4F2B65C3.8070201@uvic.ca> References: <4F2B65C3.8070201@uvic.ca> Message-ID: <4F2BD9CE.9090907@kcl.ac.uk> Thanks and congratulations to Martin for carrying out this release and for taking pains to improve the documentation thereof. I wouldn't mind trying to out myself at some future occasion (I presume we're not planning to release every couple weeks from now on!). The rationale for this (beyond my desire for self-improvement) would be that I am a lot stupider and a *lot* less technically adept than Martin, so this would be a sterner test of the foolproofness of the documentation and process. G On 2012-02-03 04:42, Martin Holmes wrote: > Following my thrilling day of first-times (first time releasing TEI, > first time retweeting someone else's tweet, first time using IRC), I've > put together a more detailed set of instructions for future release > technicians: > > > > I've taken the core information in TCW20 relating to building a release, > and elaborated and extended it to include things we didn't know we > didn't know until today. I've also tried to explain why you take each > step and how it works, so you don't find yourself blindly following > mysterious instructions. > > Please take a look through the document. If you've done a release > before, check to make sure I haven't left anything out or got anything > wrong. If you haven't done one, read it and see if you think it would be > clear and detailed enough to help you through the process. > > I haven't made any changes to TWC20, but if the new document is > acceptable, I propose removing all those bits from TCW20 and replacing > them with a reference to the new doc. I haven't published the new doc > yet, so it doesn't appear on the TEI site menu. > > I shall close with the now-traditional expression of hatred for the CMS > system, which I must utter every time I have to interact with it. GRRR. ;-) > > Cheers, > Martin -- Dr Gabriel BODARD (Research Associate in Digital Epigraphy) Department of Digital 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 Feb 3 08:09:35 2012 From: mholmes at uvic.ca (Martin Holmes) Date: Fri, 03 Feb 2012 05:09:35 -0800 Subject: [tei-council] New document describing release steps In-Reply-To: <4F2BB086.3090501@oucs.ox.ac.uk> References: <4F2B65C3.8070201@uvic.ca> <4F2BAC1A.207@retired.ox.ac.uk> <4F2BB086.3090501@oucs.ox.ac.uk> Message-ID: <4F2BDC8F.1010105@uvic.ca> I had published it, actually, but that was right before the third time it crashed my browser. When I restarted the browser I was able to see it, so I assumed it was successfully published, but I guess it hadn't completed and had just kept my own session alive so it worked for me. GRRR. Cheers, Martin On 12-02-03 02:01 AM, James Cummings wrote: > > If Martin hasn't published it, it will not be visible unless you > have already logged into openCMS. (Martin: Publishing it isn't > what makes it appear in the list... that is just by adding it to > index.xml. If you did want something to appear in the left-hand > navigation you had to do so intentionally, by right-clicking on > it and look at its 'properties' where you can 'add it to > navigation'.) > > I've 'stolen lock' from Martin and published it, but not added it > to index.xml yet. > > So you should be able to see it now at: > > http://www.tei-c.org/Activities/Council/Working/tcw22.xml > > Don't get me started on OpenCMS... > -James > > On 03/02/12 09:42, Lou Burnard wrote: >> On 03/02/12 04:42, Martin Holmes wrote: >> >>> I shall close with the now-traditional expression of hatred for the CMS >>> system, which I must utter every time I have to interact with it. GRRR. ;-) >> >> It seems to be taking its revenge. At any rate the URL you quote >> >> >> >> doesnt work for me! >> >> >> > > From James.Cummings at oucs.ox.ac.uk Fri Feb 3 08:11:00 2012 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Fri, 03 Feb 2012 13:11:00 +0000 Subject: [tei-council] New document describing release steps In-Reply-To: <4F2BDC8F.1010105@uvic.ca> References: <4F2B65C3.8070201@uvic.ca> <4F2BAC1A.207@retired.ox.ac.uk> <4F2BB086.3090501@oucs.ox.ac.uk> <4F2BDC8F.1010105@uvic.ca> Message-ID: <4F2BDCE4.8030401@oucs.ox.ac.uk> As I said before: >> Don't get me started on OpenCMS... -James On 03/02/12 13:09, Martin Holmes wrote: > I had published it, actually, but that was right before the third time > it crashed my browser. When I restarted the browser I was able to see > it, so I assumed it was successfully published, but I guess it hadn't > completed and had just kept my own session alive so it worked for me. > > GRRR. > > Cheers, > Martin > > On 12-02-03 02:01 AM, James Cummings wrote: >> >> If Martin hasn't published it, it will not be visible unless you >> have already logged into openCMS. (Martin: Publishing it isn't >> what makes it appear in the list... that is just by adding it to >> index.xml. If you did want something to appear in the left-hand >> navigation you had to do so intentionally, by right-clicking on >> it and look at its 'properties' where you can 'add it to >> navigation'.) >> >> I've 'stolen lock' from Martin and published it, but not added it >> to index.xml yet. >> >> So you should be able to see it now at: >> >> http://www.tei-c.org/Activities/Council/Working/tcw22.xml >> >> Don't get me started on OpenCMS... >> -James >> >> On 03/02/12 09:42, Lou Burnard wrote: >>> On 03/02/12 04:42, Martin Holmes wrote: >>> >>>> I shall close with the now-traditional expression of hatred for the CMS >>>> system, which I must utter every time I have to interact with it. GRRR. ;-) >>> >>> It seems to be taking its revenge. At any rate the URL you quote >>> >>> >>> >>> doesnt work for me! >>> >>> >>> >> >> -- Dr James Cummings, InfoDev, Computing Services, University of Oxford From sebastian.rahtz at oucs.ox.ac.uk Fri Feb 3 08:11:17 2012 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Fri, 3 Feb 2012 13:11:17 +0000 Subject: [tei-council] New document describing release steps In-Reply-To: <4F2BD9CE.9090907@kcl.ac.uk> References: <4F2B65C3.8070201@uvic.ca> <4F2BD9CE.9090907@kcl.ac.uk> Message-ID: <9C086D37-5F84-4145-9AE1-1036C510A4D6@oucs.ox.ac.uk> some notes on http://www.tei-c.org/Activities/Council/Working/tcw22.xml 1) the command "make changelog" in the P5 sources remakes the file ReleaseNotes/ChangeLog which contains a human-readable summary of changes from SVN. I am wondering how to automate this 9) the reason for running "tei-database-rebuild" is to refresh the eXist database used by Roma. important to note this, I think. 14) worth suggesting you visit http://www.tei-c.org/Roma/, click on defaults, and check that a) it works, and b) the version number is right in the footer -- Stormageddon Rahtz Head of Information and Support Group Oxford University Computing Services 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 Fri Feb 3 08:16:59 2012 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Fri, 03 Feb 2012 13:16:59 +0000 Subject: [tei-council] New document describing release steps In-Reply-To: <4F2BD9CE.9090907@kcl.ac.uk> References: <4F2B65C3.8070201@uvic.ca> <4F2BD9CE.9090907@kcl.ac.uk> Message-ID: <4F2BDE4B.7020307@oucs.ox.ac.uk> That sounds like a volunteer to me! Barring major or urgent bugs and such, I had mentally timetabled that a release should happen awhile after our April meeting. End of June start of July? Does that seem like a good idea? The idea being we would decide a lot of problematic tickets at the face 2 face and then have a deadline about a month and a bit later to have completed the work arising. It might be a bit biased of me to suggest that we aim for 1 July and call this release Codename: Canada Day http://en.wikipedia.org/wiki/Canada_Day ... It is probably not a good idea to tie the codename of the release (so we know which one we're talking about) to a specific date. While this is a bit of fun, any suggestions on a naming strategy for such codenames? -James On 03/02/12 12:57, Gabriel Bodard wrote: > Thanks and congratulations to Martin for carrying out this release and > for taking pains to improve the documentation thereof. > > I wouldn't mind trying to out myself at some future occasion (I presume > we're not planning to release every couple weeks from now on!). The > rationale for this (beyond my desire for self-improvement) would be that > I am a lot stupider and a *lot* less technically adept than Martin, so > this would be a sterner test of the foolproofness of the documentation > and process. > > G > > On 2012-02-03 04:42, Martin Holmes wrote: >> Following my thrilling day of first-times (first time releasing TEI, >> first time retweeting someone else's tweet, first time using IRC), I've >> put together a more detailed set of instructions for future release >> technicians: >> >> >> >> I've taken the core information in TCW20 relating to building a release, >> and elaborated and extended it to include things we didn't know we >> didn't know until today. I've also tried to explain why you take each >> step and how it works, so you don't find yourself blindly following >> mysterious instructions. >> >> Please take a look through the document. If you've done a release >> before, check to make sure I haven't left anything out or got anything >> wrong. If you haven't done one, read it and see if you think it would be >> clear and detailed enough to help you through the process. >> >> I haven't made any changes to TWC20, but if the new document is >> acceptable, I propose removing all those bits from TCW20 and replacing >> them with a reference to the new doc. I haven't published the new doc >> yet, so it doesn't appear on the TEI site menu. >> >> I shall close with the now-traditional expression of hatred for the CMS >> system, which I must utter every time I have to interact with it. GRRR. ;-) >> >> Cheers, >> Martin > -- Dr James Cummings, InfoDev, Computing Services, University of Oxford From lou.burnard at retired.ox.ac.uk Fri Feb 3 08:20:30 2012 From: lou.burnard at retired.ox.ac.uk (Lou Burnard) Date: Fri, 03 Feb 2012 13:20:30 +0000 Subject: [tei-council] New document describing release steps In-Reply-To: <9C086D37-5F84-4145-9AE1-1036C510A4D6@oucs.ox.ac.uk> References: <4F2B65C3.8070201@uvic.ca> <4F2BD9CE.9090907@kcl.ac.uk> <9C086D37-5F84-4145-9AE1-1036C510A4D6@oucs.ox.ac.uk> Message-ID: <4F2BDF1E.8020503@retired.ox.ac.uk> On 03/02/12 13:11, Sebastian Rahtz wrote: > some notes on http://www.tei-c.org/Activities/Council/Working/tcw22.xml > > 1) the command "make changelog" in the P5 sources remakes the file ReleaseNotes/ChangeLog which contains a human-readable summary of changes from SVN. I am wondering how to automate this > It's also perhaps worth noting somewhere that the ChangeLog isnot the same as the human-readable readme files included in the release. I have always hand-crafted the former from the latter and I don't see any obvious way of automating that process. From lou.burnard at retired.ox.ac.uk Fri Feb 3 08:21:42 2012 From: lou.burnard at retired.ox.ac.uk (Lou Burnard) Date: Fri, 03 Feb 2012 13:21:42 +0000 Subject: [tei-council] New document describing release steps In-Reply-To: <4F2BDF1E.8020503@retired.ox.ac.uk> References: <4F2B65C3.8070201@uvic.ca> <4F2BD9CE.9090907@kcl.ac.uk> <9C086D37-5F84-4145-9AE1-1036C510A4D6@oucs.ox.ac.uk> <4F2BDF1E.8020503@retired.ox.ac.uk> Message-ID: <4F2BDF66.5090206@retired.ox.ac.uk> On 03/02/12 13:20, Lou Burnard wrote: > On 03/02/12 13:11, Sebastian Rahtz wrote: >> some notes on http://www.tei-c.org/Activities/Council/Working/tcw22.xml >> >> 1) the command "make changelog" in the P5 sources remakes the file ReleaseNotes/ChangeLog which contains a human-readable summary of changes from SVN. I am wondering how to automate this >> > > It's also perhaps worth noting somewhere that the ChangeLog isnot the > same as the human-readable readme files included in the release. I have > always hand-crafted the former from the latter and I don't see any > obvious way of automating that process. > I meant, of course, "handcrafted the latter from the former" :-) From mholmes at uvic.ca Fri Feb 3 08:27:35 2012 From: mholmes at uvic.ca (Martin Holmes) Date: Fri, 03 Feb 2012 05:27:35 -0800 Subject: [tei-council] New document describing release steps In-Reply-To: <9C086D37-5F84-4145-9AE1-1036C510A4D6@oucs.ox.ac.uk> References: <4F2B65C3.8070201@uvic.ca> <4F2BD9CE.9090907@kcl.ac.uk> <9C086D37-5F84-4145-9AE1-1036C510A4D6@oucs.ox.ac.uk> Message-ID: <4F2BE0C7.5030204@uvic.ca> Hi there, On 12-02-03 05:11 AM, Sebastian Rahtz wrote: > some notes on > http://www.tei-c.org/Activities/Council/Working/tcw22.xml > > 1) the command "make changelog" in the P5 sources remakes the file > ReleaseNotes/ChangeLog which contains a human-readable summary of > changes from SVN. I am wondering how to automate this I never realized that. I just tried it, and it gives me a changelog from now back to 2003; I wonder if we could make it detect the last release date and give you only the relevant bits? > 9) the reason for running "tei-database-rebuild" is to refresh the > eXist database used by Roma. important to note this, I think. Good point. I've added that. > 14) worth suggesting you visit http://www.tei-c.org/Roma/, click on > defaults, and check that a) it works, and b) the version number is > right in the footer -- Also added. I've uploaded the changes. Note to self: when the CMS stalls on the "Uploading data..." dialog box, wait a bit, then click on the folder in the folder tree again. Then you can republish. Any other operation seems to crash Firefox. Cheers, Martin > Stormageddon Rahtz Head of Information and > Support Group Oxford University Computing Services 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 Feb 3 08:30:35 2012 From: mholmes at uvic.ca (Martin Holmes) Date: Fri, 03 Feb 2012 05:30:35 -0800 Subject: [tei-council] New document describing release steps In-Reply-To: <4F2BDF1E.8020503@retired.ox.ac.uk> References: <4F2B65C3.8070201@uvic.ca> <4F2BD9CE.9090907@kcl.ac.uk> <9C086D37-5F84-4145-9AE1-1036C510A4D6@oucs.ox.ac.uk> <4F2BDF1E.8020503@retired.ox.ac.uk> Message-ID: <4F2BE17B.1090401@uvic.ca> I agree; I think only a human can determine which SVN changes deserve mention in the release notes and which don't. Unless, of course, we adopt a rigorous convention for SVN commit messages that would enable them to be processed mechanically. But that seems far-fetched. That "XML 101, Martin..." message is going to haunt me for ever. :-) Cheers, Martin On 12-02-03 05:20 AM, Lou Burnard wrote: > On 03/02/12 13:11, Sebastian Rahtz wrote: >> some notes on http://www.tei-c.org/Activities/Council/Working/tcw22.xml >> >> 1) the command "make changelog" in the P5 sources remakes the file ReleaseNotes/ChangeLog which contains a human-readable summary of changes from SVN. I am wondering how to automate this >> > > It's also perhaps worth noting somewhere that the ChangeLog isnot the > same as the human-readable readme files included in the release. I have > always hand-crafted the former from the latter and I don't see any > obvious way of automating that process. > From sebastian.rahtz at oucs.ox.ac.uk Fri Feb 3 08:33:18 2012 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Fri, 3 Feb 2012 13:33:18 +0000 Subject: [tei-council] New document describing release steps In-Reply-To: <4F2BE17B.1090401@uvic.ca> References: <4F2B65C3.8070201@uvic.ca> <4F2BD9CE.9090907@kcl.ac.uk> <9C086D37-5F84-4145-9AE1-1036C510A4D6@oucs.ox.ac.uk> <4F2BDF1E.8020503@retired.ox.ac.uk> <4F2BE17B.1090401@uvic.ca> Message-ID: <6590E34F-2A79-4C69-88B3-20CF3F22C8E8@oucs.ox.ac.uk> On 3 Feb 2012, at 13:30, Martin Holmes wrote: > > That "XML 101, Martin..." message is going to haunt me for ever. :-) oh, sorry about that, just my bit of fun. feel free to hand edit the changelog! -- Stormageddon Rahtz Head of Information and Support Group Oxford University Computing Services 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 Feb 3 08:39:03 2012 From: mholmes at uvic.ca (Martin Holmes) Date: Fri, 03 Feb 2012 05:39:03 -0800 Subject: [tei-council] New document describing release steps In-Reply-To: <4F2BD9CE.9090907@kcl.ac.uk> References: <4F2B65C3.8070201@uvic.ca> <4F2BD9CE.9090907@kcl.ac.uk> Message-ID: <4F2BE377.5050306@uvic.ca> On 12-02-03 04:57 AM, Gabriel Bodard wrote: > Thanks and congratulations to Martin for carrying out this release and > for taking pains to improve the documentation thereof. > > I wouldn't mind trying to out myself at some future occasion (I presume > we're not planning to release every couple weeks from now on!). The > rationale for this (beyond my desire for self-improvement) would be that > I am a lot stupider and a *lot* less technically adept than Martin, so > this would be a sterner test of the foolproofness of the documentation > and process. That's very kind, but I bet you've never pasted a bunch of content before the XML declaration in a file, committed the result without validating it, and then gone off to have a leisurely breakfast while the Jinks servers choked and spat it out. On release day. :-) Cheers, Martin > > G > > On 2012-02-03 04:42, Martin Holmes wrote: >> Following my thrilling day of first-times (first time releasing TEI, >> first time retweeting someone else's tweet, first time using IRC), I've >> put together a more detailed set of instructions for future release >> technicians: >> >> >> >> I've taken the core information in TCW20 relating to building a release, >> and elaborated and extended it to include things we didn't know we >> didn't know until today. I've also tried to explain why you take each >> step and how it works, so you don't find yourself blindly following >> mysterious instructions. >> >> Please take a look through the document. If you've done a release >> before, check to make sure I haven't left anything out or got anything >> wrong. If you haven't done one, read it and see if you think it would be >> clear and detailed enough to help you through the process. >> >> I haven't made any changes to TWC20, but if the new document is >> acceptable, I propose removing all those bits from TCW20 and replacing >> them with a reference to the new doc. I haven't published the new doc >> yet, so it doesn't appear on the TEI site menu. >> >> I shall close with the now-traditional expression of hatred for the CMS >> system, which I must utter every time I have to interact with it. GRRR. ;-) >> >> Cheers, >> Martin > From sebastian.rahtz at oucs.ox.ac.uk Fri Feb 3 08:43:58 2012 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Fri, 3 Feb 2012 13:43:58 +0000 Subject: [tei-council] New document describing release steps In-Reply-To: <4F2BE377.5050306@uvic.ca> References: <4F2B65C3.8070201@uvic.ca> <4F2BD9CE.9090907@kcl.ac.uk> <4F2BE377.5050306@uvic.ca> Message-ID: <5FD1076D-A6C4-48C0-A665-EF2B9E09CED9@oucs.ox.ac.uk> On 3 Feb 2012, at 13:39, Martin Holmes wrote: > That's very kind, but I bet you've never pasted a bunch of content > before the XML declaration in a file, committed the result without > validating it, and then gone off to have a leisurely breakfast while the > Jinks servers choked and spat it out. I have to admit, it took me a good ten minutes to understand what had happened after I saw the error message. It was really quite obscure. -- Stormageddon Rahtz Head of Information and Support Group Oxford University Computing Services 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 3 10:52:11 2012 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Fri, 3 Feb 2012 15:52:11 +0000 Subject: [tei-council] oxygen-tei release Message-ID: <4FF1ABFA-4F94-41EF-9E5F-91EE4FDA2E66@oucs.ox.ac.uk> I have copied all the latest and greatest to http://code.google.com/p/oxygen-tei/ for reference, one has to - check out the source using Subversion - copy all the xml tree from the current release - copy in an oxygen.jar from current oxygen - build the zip with Ant - upload the zip to googlecode scriptable, in due course, but I feel weak today. -- Stormageddon Rahtz Head of Information and Support Group Oxford University Computing Services 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 Fri Feb 3 10:57:23 2012 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Fri, 03 Feb 2012 15:57:23 +0000 Subject: [tei-council] New document describing release steps In-Reply-To: <5FD1076D-A6C4-48C0-A665-EF2B9E09CED9@oucs.ox.ac.uk> References: <4F2B65C3.8070201@uvic.ca> <4F2BD9CE.9090907@kcl.ac.uk> <4F2BE377.5050306@uvic.ca> <5FD1076D-A6C4-48C0-A665-EF2B9E09CED9@oucs.ox.ac.uk> Message-ID: <4F2C03E3.1060505@oucs.ox.ac.uk> On 03/02/12 13:43, Sebastian Rahtz wrote: > I have to admit, it took me a good ten minutes to understand what > had happened after I saw the error message. It was really quite obscure. Whereas I suspected immediately what it was... having had the exact same error message from doing something similar (but not on release) at one point. :-) -James -- Dr James Cummings, InfoDev, Computing Services, University of Oxford From mholmes at uvic.ca Fri Feb 3 11:57:25 2012 From: mholmes at uvic.ca (Martin Holmes) Date: Fri, 3 Feb 2012 08:57:25 -0800 Subject: [tei-council] oxygen-tei release In-Reply-To: <4FF1ABFA-4F94-41EF-9E5F-91EE4FDA2E66@oucs.ox.ac.uk> References: <4FF1ABFA-4F94-41EF-9E5F-91EE4FDA2E66@oucs.ox.ac.uk> Message-ID: <4F2C11F5.9040001@uvic.ca> I guess the question is whether we want the release technician to take care of this (in which case a script would be great, but there would also be the issue of permissions to upload to Google Code), or whether we view it as peripheral to the main release, and hope Sebastian is happy to continue doing it. A middle ground would be for three or four of us to have the know-how and rights to do this, so it doesn't always have to be Sebastian. Cheers, Martin On 12-02-03 07:52 AM, Sebastian Rahtz wrote: > I have copied all the latest and greatest to http://code.google.com/p/oxygen-tei/ > > for reference, one has to > > - check out the source using Subversion > - copy all the xml tree from the current release > - copy in an oxygen.jar from current oxygen > - build the zip with Ant > - upload the zip to googlecode > > scriptable, in due course, but I feel weak today. > -- > Stormageddon Rahtz > Head of Information and Support Group > Oxford University Computing Services > 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 > > S?lo le pido a Dios > que el futuro no me sea indiferente > -- Martin Holmes University of Victoria Humanities Computing and Media Centre (mholmes at uvic.ca) From rwelzenbach at gmail.com Fri Feb 3 16:54:07 2012 From: rwelzenbach at gmail.com (Rebecca Welzenbach) Date: Fri, 3 Feb 2012 16:54:07 -0500 Subject: [tei-council] Ann Arbor spring meeting In-Reply-To: References: <4F1F19E3.1000401@uvic.ca> <4F1F1EC4.3010301@uvic.ca> <4F1F43EF.8090904@ultraslavonic.info> <4F203226.10901@uvic.ca> <4F203A69.6000500@o2.pl> <4F208843.205@uvic.ca> <4F2089D9.2050405@ultraslavonic.info> <4F2122D4.7050209@oucs.ox.ac.uk> <4F21239F.5070501@oucs.ox.ac.uk> Message-ID: Hi all, Just an update: a block of rooms has been reserved at the Bell Tower Inn, and I've just heard this afternoon that the University of Michigan Library will indeed be able to pay for this transaction, and then apply for reimbursement from TEI-C, which will save us a bit of money. (Around $650--Lobsters and champagne for everyone!) Because the transaction will be between the hotel and UM, you do *not* need to make your own reservation, but I *do* need a firm list of exactly who will be here when, to give to both the hotel and our finance office. Thanks to James' poll, I have this information from everyone but Gaby, whom I've just bugged separately. So we're set for accommodations, and you don't need to do anything at this point. Becky On Thu, Jan 26, 2012 at 8:57 AM, Rebecca Welzenbach wrote: > Great idea--thanks, James. > > On Thu, Jan 26, 2012 at 4:57 AM, James Cummings > wrote: >> On 26/01/12 09:54, James Cummings wrote: >>> I've put up a doodle for people to record what nights they will >>> need hotel. This will be useful for Becky if doing a block >>> booking, and/or all of us to know who is arriving/departing when. >>> ? ?Since I'm arriving on the Sat and leaving on the Wednesday, >>> I've checked Sat/Sun/Mon/Tues Nights. Could everyone needing >>> hotel fill it out? >> >> Of course it would be better if I included the URL. (*doh*) >> >> http://www.doodle.com/9dunbbdcngadff68 >> >> >> >>> >>> -James >>> >> >> >> -- >> Dr James Cummings, InfoDev, >> Computing Services, University of Oxford >> -- >> tei-council mailing list >> tei-council at lists.village.Virginia.EDU >> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council >> >> PLEASE NOTE: postings to this list are publicly archived From syeates at gmail.com Sun Feb 5 21:17:55 2012 From: syeates at gmail.com (stuart yeates) Date: Mon, 06 Feb 2012 15:17:55 +1300 Subject: [tei-council] New document describing release steps In-Reply-To: <4F2B65C3.8070201@uvic.ca> References: <4F2B65C3.8070201@uvic.ca> Message-ID: <4F2F3853.2090600@gmail.com> On 03/02/12 17:42, Martin Holmes wrote: > Following my thrilling day of first-times (first time releasing TEI, > first time retweeting someone else's tweet, first time using IRC), I've > put together a more detailed set of instructions for future release > technicians: > > The line: svn log -r {2011-12-12}:{2012-02-12} can be replaced by the slightly simpler: svn log -r {2011-12-14}:HEAD which requires only one date to be filled. --- Could the line: ./tei-install.sh --package=TEIP5 --version=X.X.X --sfuser=username not be simplified by having the script look in P5/VERSION for the version number? Then it'd be one less thing with a chance to go wrong / out of sync. --- It's not 100% clear to me which machine steps 9 and 11 are executed on. --- Other than that it looks really good. cheers stuart From sebastian.rahtz at oucs.ox.ac.uk Mon Feb 6 04:14:34 2012 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 6 Feb 2012 09:14:34 +0000 Subject: [tei-council] New document describing release steps In-Reply-To: <4F2F3853.2090600@gmail.com> References: <4F2B65C3.8070201@uvic.ca> <4F2F3853.2090600@gmail.com> Message-ID: On 6 Feb 2012, at 02:17, stuart yeates wrote: > Could the line: > > ./tei-install.sh --package=TEIP5 --version=X.X.X --sfuser=username > > not be simplified by having the script look in P5/VERSION for the > version number? Then it'd be one less thing with a chance to go wrong / > out of sync. No, because the script is not running with a copy of P5 in front of it. It uses the --version to know which file to grab from the Jenkins server which has prepared the release. The script itself does no building, it just pulls zip files and unpacks them in the right place. -- Stormageddon Rahtz Head of Information and Support Group, Oxford University Computing Services 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 6 08:44:33 2012 From: mholmes at uvic.ca (Martin Holmes) Date: Mon, 06 Feb 2012 05:44:33 -0800 Subject: [tei-council] New document describing release steps In-Reply-To: <4F2F3853.2090600@gmail.com> References: <4F2B65C3.8070201@uvic.ca> <4F2F3853.2090600@gmail.com> Message-ID: <4F2FD941.4030205@uvic.ca> I've made those changes, except the one to the tei-install.sh script. I agree that it's a good idea, but I'm slightly worried about what might happen if someone had inadvertently failed to update P5/VERSION correctly, and then ran the script. We should think about that a bit. I've now published the document on the site. (GRRR.) Does anyone have any objections to my editing TCW20 to remove the old release instructions and point to the new file? Cheers, Martin On 12-02-05 06:17 PM, stuart yeates wrote: > On 03/02/12 17:42, Martin Holmes wrote: >> Following my thrilling day of first-times (first time releasing TEI, >> first time retweeting someone else's tweet, first time using IRC), I've >> put together a more detailed set of instructions for future release >> technicians: >> >> > > > The line: > > svn log -r {2011-12-12}:{2012-02-12} > > can be replaced by the slightly simpler: > > svn log -r {2011-12-14}:HEAD > > which requires only one date to be filled. > > --- > > Could the line: > > ./tei-install.sh --package=TEIP5 --version=X.X.X --sfuser=username > > not be simplified by having the script look in P5/VERSION for the > version number? Then it'd be one less thing with a chance to go wrong / > out of sync. > > --- > > It's not 100% clear to me which machine steps 9 and 11 are executed on. > > --- > > Other than that it looks really good. > > cheers > stuart > > From mholmes at uvic.ca Mon Feb 6 11:41:14 2012 From: mholmes at uvic.ca (Martin Holmes) Date: Mon, 6 Feb 2012 08:41:14 -0800 Subject: [tei-council] New document describing release steps In-Reply-To: References: <4F2B65C3.8070201@uvic.ca> <4F2F3853.2090600@gmail.com> Message-ID: <4F3002AA.3050803@uvic.ca> Hi there, It just occurred to me that the script could curl P5/VERSION from the SF repo to get the version info, couldn't it? Cheers, Martin On 12-02-06 01:14 AM, Sebastian Rahtz wrote: > > On 6 Feb 2012, at 02:17, stuart yeates wrote: > >> Could the line: >> >> ./tei-install.sh --package=TEIP5 --version=X.X.X --sfuser=username >> >> not be simplified by having the script look in P5/VERSION for the >> version number? Then it'd be one less thing with a chance to go wrong / >> out of sync. > No, because the script is not running with a copy of P5 in front of it. It uses the --version > to know which file to grab from the Jenkins server which has prepared the release. > The script itself does no building, it just pulls zip files and unpacks them > in the right place. > > -- > Stormageddon Rahtz > Head of Information and Support Group, Oxford University Computing Services > 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 > > S?lo le pido a Dios > que el futuro no me sea indiferente > -- Martin Holmes University of Victoria Humanities Computing and Media Centre (mholmes at uvic.ca) From sebastian.rahtz at oucs.ox.ac.uk Mon Feb 6 11:43:55 2012 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 6 Feb 2012 16:43:55 +0000 Subject: [tei-council] New document describing release steps In-Reply-To: <4F3002AA.3050803@uvic.ca> References: <4F2B65C3.8070201@uvic.ca> <4F2F3853.2090600@gmail.com> <4F3002AA.3050803@uvic.ca> Message-ID: <7BAFF5B1-7D6D-4171-8847-DA86CC94EBCD@oucs.ox.ac.uk> On 6 Feb 2012, at 16:41, Martin Holmes wrote: > > It just occurred to me that the script could curl P5/VERSION from the SF > repo to get the version info, couldn't it? if you think its worth the trouble. I'd still leave the option there of overriding it if needed. -- Stormageddon Rahtz Head of Information and Support Group Oxford University Computing Services 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 7 08:47:47 2012 From: mholmes at uvic.ca (Martin Holmes) Date: Tue, 07 Feb 2012 05:47:47 -0800 Subject: [tei-council] @cRef survey Message-ID: <4F312B83.8020801@uvic.ca> Hi all, I've had only nine responses to my @cRef survey so far, which suggests it's not in very wide use. People using it tend to be using it slightly incorrectly -- sometimes they're using canonical references with spaces in them, or they're using #id-in-different-document or #id-which-dunt-exist, and in no case has anyone created a . So if we deprecated it, we'd annoy a small number of people, but there's no fix we could make to it that would bring them all into the fold of correct usage anyway. Usage is as much of a mess as the definitions are. To deal with this issue, as well as that of @key, I think we need to take three steps: 1. Develop a proper strategy for the use of private URI schemes (with something similar to where people can properly document how their private schemes are to be dereferenced or understood). This should divert a large proportion of the current usage of @cRef (and @key) over to @ref and @target. 2. Decide whether we want to keep @key and @cRef, or deprecate one or both. 3. If we're keeping them, decide what their datatypes should be. In the case of @cRef, create a proper class for it. 4. If we're not keeping them, do we need replacement attribute(s) for their use-cases? Cheers, Martin From James.Cummings at oucs.ox.ac.uk Tue Feb 7 10:19:12 2012 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Tue, 07 Feb 2012 15:19:12 +0000 Subject: [tei-council] New document describing release steps In-Reply-To: <7BAFF5B1-7D6D-4171-8847-DA86CC94EBCD@oucs.ox.ac.uk> References: <4F2B65C3.8070201@uvic.ca> <4F2F3853.2090600@gmail.com> <4F3002AA.3050803@uvic.ca> <7BAFF5B1-7D6D-4171-8847-DA86CC94EBCD@oucs.ox.ac.uk> Message-ID: <4F3140F0.1000408@oucs.ox.ac.uk> The tei user on tei-c.org now has a /home/tei/svn/ directory, which updates from sourceforge svn once an hour. So there should be a local copy available. Why not just update this (as part of the script) and check the VERSION file. (Ok, leave as an option that can be overridden as well...) I've also moved the relevant release and update scripts into /home/tei/bin/ -James On 06/02/12 16:43, Sebastian Rahtz wrote: > > On 6 Feb 2012, at 16:41, Martin Holmes wrote: > >> >> It just occurred to me that the script could curl P5/VERSION from the SF >> repo to get the version info, couldn't it? > > > if you think its worth the trouble. I'd still leave the option there of overriding it > if needed. > -- > Stormageddon Rahtz > Head of Information and Support Group > Oxford University Computing 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 James Cummings, InfoDev, Computing Services, University of Oxford From James.Cummings at oucs.ox.ac.uk Tue Feb 7 10:21:32 2012 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Tue, 07 Feb 2012 15:21:32 +0000 Subject: [tei-council] @cRef survey In-Reply-To: <4F312B83.8020801@uvic.ca> References: <4F312B83.8020801@uvic.ca> Message-ID: <4F31417C.4070702@oucs.ox.ac.uk> Could you make sure that the Library SIG people circulate it? Not sure if they use it at all, but one of the comments on my P4 Survey results were that many Library people probably don't see it because they don't read TEI-L. (I don't think this will change your results in the slightest however...) -James On 07/02/12 13:47, Martin Holmes wrote: > Hi all, > > I've had only nine responses to my @cRef survey so far, which suggests > it's not in very wide use. People using it tend to be using it slightly > incorrectly -- sometimes they're using canonical references with spaces > in them, or they're using #id-in-different-document or > #id-which-dunt-exist, and in no case has anyone created a. > > So if we deprecated it, we'd annoy a small number of people, but there's > no fix we could make to it that would bring them all into the fold of > correct usage anyway. Usage is as much of a mess as the definitions are. > > To deal with this issue, as well as that of @key, I think we need to > take three steps: > > 1. Develop a proper strategy for the use of private URI schemes (with > something similar to where people can properly document > how their private schemes are to be dereferenced or understood). This > should divert a large proportion of the current usage of @cRef (and > @key) over to @ref and @target. > > 2. Decide whether we want to keep @key and @cRef, or deprecate one or both. > > 3. If we're keeping them, decide what their datatypes should be. In the > case of @cRef, create a proper class for it. > > 4. If we're not keeping them, do we need replacement attribute(s) for > their use-cases? > > Cheers, > Martin -- Dr James Cummings, InfoDev, Computing Services, University of Oxford From kevin.s.hawkins at ultraslavonic.info Tue Feb 7 11:14:24 2012 From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins) Date: Tue, 07 Feb 2012 11:14:24 -0500 Subject: [tei-council] @cRef survey In-Reply-To: <4F31417C.4070702@oucs.ox.ac.uk> References: <4F312B83.8020801@uvic.ca> <4F31417C.4070702@oucs.ox.ac.uk> Message-ID: <4F314DE0.7070508@ultraslavonic.info> Okay, I will post to the Library SIG list. On 2/7/2012 10:21 AM, James Cummings wrote: > > Could you make sure that the Library SIG people circulate it? Not > sure if they use it at all, but one of the comments on my P4 > Survey results were that many Library people probably don't see > it because they don't read TEI-L. (I don't think this will > change your results in the slightest however...) > > -James > > > On 07/02/12 13:47, Martin Holmes wrote: >> Hi all, >> >> I've had only nine responses to my @cRef survey so far, which suggests >> it's not in very wide use. People using it tend to be using it slightly >> incorrectly -- sometimes they're using canonical references with spaces >> in them, or they're using #id-in-different-document or >> #id-which-dunt-exist, and in no case has anyone created a. >> >> So if we deprecated it, we'd annoy a small number of people, but there's >> no fix we could make to it that would bring them all into the fold of >> correct usage anyway. Usage is as much of a mess as the definitions are. >> >> To deal with this issue, as well as that of @key, I think we need to >> take three steps: >> >> 1. Develop a proper strategy for the use of private URI schemes (with >> something similar to where people can properly document >> how their private schemes are to be dereferenced or understood). This >> should divert a large proportion of the current usage of @cRef (and >> @key) over to @ref and @target. >> >> 2. Decide whether we want to keep @key and @cRef, or deprecate one or both. >> >> 3. If we're keeping them, decide what their datatypes should be. In the >> case of @cRef, create a proper class for it. >> >> 4. If we're not keeping them, do we need replacement attribute(s) for >> their use-cases? >> >> Cheers, >> Martin > > From mholmes at uvic.ca Tue Feb 7 11:46:27 2012 From: mholmes at uvic.ca (Martin Holmes) Date: Tue, 7 Feb 2012 08:46:27 -0800 Subject: [tei-council] @cRef survey In-Reply-To: <4F31417C.4070702@oucs.ox.ac.uk> References: <4F312B83.8020801@uvic.ca> <4F31417C.4070702@oucs.ox.ac.uk> Message-ID: <4F315563.2080205@uvic.ca> Kevin, I think you're a convener of that SIG, aren't you? Could you point people at: Cheers, Martin On 12-02-07 07:21 AM, James Cummings wrote: > > Could you make sure that the Library SIG people circulate it? Not > sure if they use it at all, but one of the comments on my P4 > Survey results were that many Library people probably don't see > it because they don't read TEI-L. (I don't think this will > change your results in the slightest however...) > > -James > > > On 07/02/12 13:47, Martin Holmes wrote: >> Hi all, >> >> I've had only nine responses to my @cRef survey so far, which suggests >> it's not in very wide use. People using it tend to be using it slightly >> incorrectly -- sometimes they're using canonical references with spaces >> in them, or they're using #id-in-different-document or >> #id-which-dunt-exist, and in no case has anyone created a. >> >> So if we deprecated it, we'd annoy a small number of people, but there's >> no fix we could make to it that would bring them all into the fold of >> correct usage anyway. Usage is as much of a mess as the definitions are. >> >> To deal with this issue, as well as that of @key, I think we need to >> take three steps: >> >> 1. Develop a proper strategy for the use of private URI schemes (with >> something similar to where people can properly document >> how their private schemes are to be dereferenced or understood). This >> should divert a large proportion of the current usage of @cRef (and >> @key) over to @ref and @target. >> >> 2. Decide whether we want to keep @key and @cRef, or deprecate one or both. >> >> 3. If we're keeping them, decide what their datatypes should be. In the >> case of @cRef, create a proper class for it. >> >> 4. If we're not keeping them, do we need replacement attribute(s) for >> their use-cases? >> >> Cheers, >> Martin > > -- Martin Holmes University of Victoria Humanities Computing and Media Centre (mholmes at uvic.ca) From mholmes at uvic.ca Tue Feb 7 23:33:54 2012 From: mholmes at uvic.ca (Martin Holmes) Date: Tue, 07 Feb 2012 20:33:54 -0800 Subject: [tei-council] Question about attribute definitions and descriptions Message-ID: <4F31FB32.6040808@uvic.ca> HI all, As part of working on , I built myself this little table of TEI attributes, and how they're defined and described: Could you take a look at rows 286 to 289 (it's OK, they're numbered), which all have @scheme attributes? I'm a bit puzzled by the slight variation in descriptions (att/@scheme has "identifier" while the others have "name"), but more by the differences in the valLists. The first two are open and the last two closed. I can see why constraintSpec/@scheme should have a closed list, but I don't see why tag/@scheme should be. It seems to me that it should be open, like gi/@scheme. Am I missing something? Cheers, Martin -- Martin Holmes mholmes at uvic.ca UVic Humanities Computing and Media Centre From lou.burnard at retired.ox.ac.uk Wed Feb 8 05:10:58 2012 From: lou.burnard at retired.ox.ac.uk (Lou Burnard) Date: Wed, 08 Feb 2012 10:10:58 +0000 Subject: [tei-council] Question about attribute definitions and descriptions In-Reply-To: <4F31FB32.6040808@uvic.ca> References: <4F31FB32.6040808@uvic.ca> Message-ID: <4F324A32.2050600@retired.ox.ac.uk> On 08/02/12 04:33, Martin Holmes wrote: > closed. I can see why constraintSpec/@scheme should have a closed list, > but I don't see why tag/@scheme should be. It seems to me that it should > be open, like gi/@scheme. > I would say that's a corrigible bug. and should behave in the same way -- it should be an open valList in both cases. Probably and should have the same suggested vallist too. Thanks for this splendid list, perusal of which will probably throw up many more such inconsistencies. From mholmes at uvic.ca Wed Feb 8 08:38:56 2012 From: mholmes at uvic.ca (Martin Holmes) Date: Wed, 08 Feb 2012 05:38:56 -0800 Subject: [tei-council] Question about attribute definitions and descriptions In-Reply-To: <4F324A32.2050600@retired.ox.ac.uk> References: <4F31FB32.6040808@uvic.ca> <4F324A32.2050600@retired.ox.ac.uk> Message-ID: <4F327AF0.4090900@uvic.ca> I've made the change to an open valList and made the suggested values for the same as for . But now I'm wondering why has a and doesn't. In fact, I'm wondering why so many attributes in the list lack a datatype. They all seem to be attributes which should be data.enumerated. Is this just a historical accident, or is there some reason or pattern to it? Cheers, Martin On 12-02-08 02:10 AM, Lou Burnard wrote: > On 08/02/12 04:33, Martin Holmes wrote: > >> closed. I can see why constraintSpec/@scheme should have a closed list, >> but I don't see why tag/@scheme should be. It seems to me that it should >> be open, like gi/@scheme. >> > > I would say that's a corrigible bug. and should behave in > the same way -- it should be an open valList in both cases. > > Probably and should have the same suggested vallist too. > > Thanks for this splendid list, perusal of which will probably throw up > many more such inconsistencies. > > From James.Cummings at oucs.ox.ac.uk Wed Feb 8 12:24:50 2012 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Wed, 08 Feb 2012 17:24:50 +0000 Subject: [tei-council] Question about attribute definitions and descriptions In-Reply-To: <4F327AF0.4090900@uvic.ca> References: <4F31FB32.6040808@uvic.ca> <4F324A32.2050600@retired.ox.ac.uk> <4F327AF0.4090900@uvic.ca> Message-ID: <4F32AFE2.60606@oucs.ox.ac.uk> On 08/02/12 13:38, Martin Holmes wrote: > But now I'm wondering why has a and doesn't. In > fact, I'm wondering why so many attributes in the list lack a datatype. > They all seem to be attributes which should be data.enumerated. It does seem to happen with attributes which I would suspect should be data.enumerated. > Is this just a historical accident, or is there some reason or pattern > to it? In all the cases I looked at the attribute values were a closed value list with very specific values. Perhaps these should be made data.enumerated with a closed value list? -James -- Dr James Cummings, InfoDev, Computing Services, University of Oxford From mholmes at uvic.ca Wed Feb 8 14:26:28 2012 From: mholmes at uvic.ca (Martin Holmes) Date: Wed, 8 Feb 2012 11:26:28 -0800 Subject: [tei-council] Question about attribute definitions and descriptions In-Reply-To: <4F32AFE2.60606@oucs.ox.ac.uk> References: <4F31FB32.6040808@uvic.ca> <4F324A32.2050600@retired.ox.ac.uk> <4F327AF0.4090900@uvic.ca> <4F32AFE2.60606@oucs.ox.ac.uk> Message-ID: <4F32CC64.5040005@uvic.ca> > In all the cases I looked at the attribute values were a closed > value list with very specific values. Perhaps these should be > made data.enumerated with a closed value list? You're mostly right, but see the list below for one or two exceptions (marked with arrows). Numbers refer to . This raises some questions: 1. Should all attributes with a closed valList be specified as data.enumerated? "data.enumerated defines the range of attribute values expressed as a single XML name taken from a list of documented possibilities." This (to my reading) doesn't specify whether the list of possibilities is closed or open, so I think it can/should apply to closed valLists as well. If it doesn't, we need another datatype that does, because I think an attribute without a datatype is not a good thing. 2. rendition/@scope has no @type on its valList. It should have one, I think, and it looks like it ought to be closed, because the values are taken from CSS pseudo-classes. 3. moduleSpec/@type has only been partially defined. the valDesc suggests it should be a closed valList, but there is no valList. It looks as though work on this was interrupted half-way through. ===========ATTRIBUTES WITH NO DATATYPE====================== 63 @dim valList (closed) 74 @eol valList (closed) 75 @evaluate att.pointing valList (closed) 86 @feature valList (closed) 92 @form [no valDesc or valList; deprecated] 102 @full att.personal valList (closed) 143 @level valList (closed) 148 @location <variantEncoding> valList (closed) 165- @method <correction>, valList (closed) 167 <normalization>, <variantEncoding> 172- @mode <channel>, valList (closed) 177 <alt>, <altGrp>, <classes>, <memberOf>, att.combinable 207 @ord <tree> valList (closed) 213- @org att.divLike, valList (closed) 216 <vColl>, <vMerge>, <attList> 225- @part att.divLike, valList (closed) 228 att.segLike, <l>, <ab> 275 @sample att.divLike valList (closed) 278 @scheme <rendition> valList (closed) 288 @scheme <tag> valList (open) <---------- 289 @scheme <constraintSpec> valList (closed) 291 @scope att.handFeatures valList (closed) 292 @scope <rendition> valList () <---------- 293 @scope <join> valList (closed) 320- @status <availability>, valList (closed) 322 <correction>, att.identified 353 @trans <u> valList (closed) 376, @type <tech>, valList (closed) 377, <recording>, 394, <constitution>, 397, <factuality>, 398, <interaction> 408, <tag> 410, <classSpec> 411, <macroSpec> 412 <valList> 409 @type <moduleSpec> valDesc: A closed <---------- set of keywords yet to be defined 426 @usage <attDef> valList (closed) 427 @valid <egXML> valList (closed) 467 @xml:space att.global valList (closed) ===================================================== Cheers, Martin On 12-02-08 09:24 AM, James Cummings wrote: > On 08/02/12 13:38, Martin Holmes wrote: >> But now I'm wondering why<gi> has a<datatype> and<tag> doesn't. In >> fact, I'm wondering why so many attributes in the list lack a datatype. >> They all seem to be attributes which should be data.enumerated. > > It does seem to happen with attributes which I would suspect > should be data.enumerated. > >> Is this just a historical accident, or is there some reason or pattern >> to it? > > In all the cases I looked at the attribute values were a closed > value list with very specific values. Perhaps these should be > made data.enumerated with a closed value list? > > -James > -- Martin Holmes University of Victoria Humanities Computing and Media Centre (mholmes at uvic.ca) From James.Cummings at oucs.ox.ac.uk Thu Feb 9 05:58:29 2012 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Thu, 09 Feb 2012 10:58:29 +0000 Subject: [tei-council] Question about attribute definitions and descriptions In-Reply-To: <4F32CC64.5040005@uvic.ca> References: <4F31FB32.6040808@uvic.ca> <4F324A32.2050600@retired.ox.ac.uk> <4F327AF0.4090900@uvic.ca> <4F32AFE2.60606@oucs.ox.ac.uk> <4F32CC64.5040005@uvic.ca> Message-ID: <4F33A6D5.2000604@oucs.ox.ac.uk> On 08/02/12 19:26, Martin Holmes wrote: > 1. Should all attributes with a closed valList be specified as > data.enumerated? "data.enumerated defines the range of attribute values > expressed as a single XML name taken from a list of documented > possibilities." This (to my reading) doesn't specify whether the list of > possibilities is closed or open, so I think it can/should apply to > closed valLists as well. If it doesn't, we need another datatype that > does, because I think an attribute without a datatype is not a good thing. IMHO, all attributes, where they aren't some other datatype for some reason, but consist of a documented list of XML names should be data.enumerated. I.e. if they are something else, fine. If they aren't a documented list, then they are data.word or something, for the datatype it doesn't matter if the list is open or closed. Having a datatype is definitely better than not having one. > 2. rendition/@scope has no @type on its valList. It should have one, I > think, and it looks like it ought to be closed, because the values are > taken from CSS pseudo-classes. Currently the reference page says 'Sample values include' because it isn't closed. If we do make this closed, it would have to contain all the CSS pseudo-elements from any version of the CSS spec. I *think* this is limited to:active, after, before, first-child, first-letter, first-line, focus, hover, lang(en), link, and visited. However, I think we'd need a volunteer to go back to the CSS specs and make sure I'm not missing any. The thing to decide, I guess, is whether it is an error to supply a value here which is not one of those? > 3. moduleSpec/@type has only been partially defined. the valDesc > suggests it should be a closed valList, but there is no valList. It > looks as though work on this was interrupted half-way through. I'm not sure. Although the TEI may have need for a closed set of values here, remember that ODD can be used entirely separate from the TEI. Is there a consistent set of moduleSpec type categorisations which don't limit other uses of it? As far as I can tell the TEI itself, in the production of the Guidelines or our exemplar ODDs, do not use @type on moduleSpec. (Can someone correct me on this?) <gap reason="snipped"><desc>list of attributes without dataypes snipped</desc></gap> -James -- Dr James Cummings, InfoDev, Computing Services, University of Oxford From mholmes at uvic.ca Thu Feb 9 08:30:56 2012 From: mholmes at uvic.ca (Martin Holmes) Date: Thu, 09 Feb 2012 05:30:56 -0800 Subject: [tei-council] Question about attribute definitions and descriptions In-Reply-To: <4F33A6D5.2000604@oucs.ox.ac.uk> References: <4F31FB32.6040808@uvic.ca> <4F324A32.2050600@retired.ox.ac.uk> <4F327AF0.4090900@uvic.ca> <4F32AFE2.60606@oucs.ox.ac.uk> <4F32CC64.5040005@uvic.ca> <4F33A6D5.2000604@oucs.ox.ac.uk> Message-ID: <4F33CA90.1040102@uvic.ca> On 12-02-09 02:58 AM, James Cummings wrote: > On 08/02/12 19:26, Martin Holmes wrote: >> 1. Should all attributes with a closed valList be specified as >> data.enumerated? "data.enumerated defines the range of attribute values >> expressed as a single XML name taken from a list of documented >> possibilities." This (to my reading) doesn't specify whether the list of >> possibilities is closed or open, so I think it can/should apply to >> closed valLists as well. If it doesn't, we need another datatype that >> does, because I think an attribute without a datatype is not a good thing. > > IMHO, all attributes, where they aren't some other datatype for > some reason, but consist of a documented list of XML names should > be data.enumerated. I.e. if they are something else, fine. If > they aren't a documented list, then they are data.word or > something, for the datatype it doesn't matter if the list is open > or closed. Having a datatype is definitely better than not > having one. In that case, I'll go through them all and make them data.enumerated, unless anyone raises an objection in the next few hours. >> 2. rendition/@scope has no @type on its valList. It should have one, I >> think, and it looks like it ought to be closed, because the values are >> taken from CSS pseudo-classes. > > Currently the reference page says 'Sample values include' because > it isn't closed. If we do make this closed, it would have to > contain all the CSS pseudo-elements from any version of the CSS > spec. I *think* this is limited to:active, after, before, > first-child, first-letter, first-line, focus, hover, lang(en), > link, and visited. However, I think we'd need a volunteer to go > back to the CSS specs and make sure I'm not missing any. The > thing to decide, I guess, is whether it is an error to supply a > value here which is not one of those? Given the ref page text, I guess I was wrong; it should be open. CSS pseudo elements are likely to proliferate, so it would be potentially obstructive to close the list. >> 3. moduleSpec/@type has only been partially defined. the valDesc >> suggests it should be a closed valList, but there is no valList. It >> looks as though work on this was interrupted half-way through. > > I'm not sure. Although the TEI may have need for a closed set of > values here, remember that ODD can be used entirely separate from > the TEI. Is there a consistent set of moduleSpec type > categorisations which don't limit other uses of it? As far as I > can tell the TEI itself, in the production of the Guidelines or > our exemplar ODDs, do not use @type on moduleSpec. (Can someone > correct me on this?) I take the point, but it seems unintuitive to specify that the list is closed, and yet not be able or willing to provide the values. Surely if someone else can take the ODD spec and do something different with it, and they need to use their own values, then the list is actually open? Cheers, Martin > <gap reason="snipped"><desc>list of attributes without dataypes > snipped</desc></gap> > > -James > > From sebastian.rahtz at oucs.ox.ac.uk Thu Feb 9 08:53:16 2012 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Thu, 9 Feb 2012 13:53:16 +0000 Subject: [tei-council] Question about attribute definitions and descriptions In-Reply-To: <4F33CA90.1040102@uvic.ca> References: <4F31FB32.6040808@uvic.ca> <4F324A32.2050600@retired.ox.ac.uk> <4F327AF0.4090900@uvic.ca> <4F32AFE2.60606@oucs.ox.ac.uk> <4F32CC64.5040005@uvic.ca> <4F33A6D5.2000604@oucs.ox.ac.uk> <4F33CA90.1040102@uvic.ca> Message-ID: <4567BE20-DE9D-4407-BFA0-D0FB36E3BF53@oucs.ox.ac.uk> we have one instance of moduleSpec/@type, viz <moduleSpec xml:id="DSTTEI2" ident="tei" type="core"> I suggest removing the valDesc and simply make moduleSpec a member of att. typed. I agree that it looks like unfinished work, and in its present state is confusing -- Stormageddon Rahtz Head of Information and Support Group Oxford University Computing Services 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 9 13:04:10 2012 From: mholmes at uvic.ca (Martin Holmes) Date: Thu, 9 Feb 2012 10:04:10 -0800 Subject: [tei-council] Question about attribute definitions and descriptions In-Reply-To: <4F33CA90.1040102@uvic.ca> References: <4F31FB32.6040808@uvic.ca> <4F324A32.2050600@retired.ox.ac.uk> <4F327AF0.4090900@uvic.ca> <4F32AFE2.60606@oucs.ox.ac.uk> <4F32CC64.5040005@uvic.ca> <4F33A6D5.2000604@oucs.ox.ac.uk> <4F33CA90.1040102@uvic.ca> Message-ID: <4F340A9A.4050806@uvic.ca> I've added datatypes to all the non-controversial ones. The one outstanding issue is moduleSpec, as Sebastian says: > we have one instance of moduleSpec/@type, viz > > <moduleSpec xml:id="DSTTEI2" ident="tei" type="core"> > > I suggest removing the valDesc and simply make moduleSpec a member of att. typed. > I agree that it looks like unfinished work, and in its present state is confusing I'm going to raise a ticket for that, because it's potentially a bit thorny. Can't tell at the moment whether my changes have broken anything, because builds are currently broken anyway -- Sebastian, shall we revert your changes to Makefile to allow builds to go ahead, while we figure out a different solution to the p5subset.xml problem? Cheers, Martin On 12-02-09 05:30 AM, Martin Holmes wrote: > On 12-02-09 02:58 AM, James Cummings wrote: >> On 08/02/12 19:26, Martin Holmes wrote: >>> 1. Should all attributes with a closed valList be specified as >>> data.enumerated? "data.enumerated defines the range of attribute values >>> expressed as a single XML name taken from a list of documented >>> possibilities." This (to my reading) doesn't specify whether the list of >>> possibilities is closed or open, so I think it can/should apply to >>> closed valLists as well. If it doesn't, we need another datatype that >>> does, because I think an attribute without a datatype is not a good thing. >> >> IMHO, all attributes, where they aren't some other datatype for >> some reason, but consist of a documented list of XML names should >> be data.enumerated. I.e. if they are something else, fine. If >> they aren't a documented list, then they are data.word or >> something, for the datatype it doesn't matter if the list is open >> or closed. Having a datatype is definitely better than not >> having one. > > In that case, I'll go through them all and make them data.enumerated, > unless anyone raises an objection in the next few hours. > >>> 2. rendition/@scope has no @type on its valList. It should have one, I >>> think, and it looks like it ought to be closed, because the values are >>> taken from CSS pseudo-classes. >> >> Currently the reference page says 'Sample values include' because >> it isn't closed. If we do make this closed, it would have to >> contain all the CSS pseudo-elements from any version of the CSS >> spec. I *think* this is limited to:active, after, before, >> first-child, first-letter, first-line, focus, hover, lang(en), >> link, and visited. However, I think we'd need a volunteer to go >> back to the CSS specs and make sure I'm not missing any. The >> thing to decide, I guess, is whether it is an error to supply a >> value here which is not one of those? > > Given the ref page text, I guess I was wrong; it should be open. CSS > pseudo elements are likely to proliferate, so it would be potentially > obstructive to close the list. > >>> 3. moduleSpec/@type has only been partially defined. the valDesc >>> suggests it should be a closed valList, but there is no valList. It >>> looks as though work on this was interrupted half-way through. >> >> I'm not sure. Although the TEI may have need for a closed set of >> values here, remember that ODD can be used entirely separate from >> the TEI. Is there a consistent set of moduleSpec type >> categorisations which don't limit other uses of it? As far as I >> can tell the TEI itself, in the production of the Guidelines or >> our exemplar ODDs, do not use @type on moduleSpec. (Can someone >> correct me on this?) > > I take the point, but it seems unintuitive to specify that the list is > closed, and yet not be able or willing to provide the values. Surely if > someone else can take the ODD spec and do something different with it, > and they need to use their own values, then the list is actually open? > > Cheers, > Martin > >> <gap reason="snipped"><desc>list of attributes without dataypes >> snipped</desc></gap> >> >> -James >> >> -- Martin Holmes University of Victoria Humanities Computing and Media Centre (mholmes at uvic.ca) From sebastian.rahtz at oucs.ox.ac.uk Thu Feb 9 18:04:20 2012 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Thu, 9 Feb 2012 23:04:20 +0000 Subject: [tei-council] Question about attribute definitions and descriptions In-Reply-To: <4F340A9A.4050806@uvic.ca> References: <4F31FB32.6040808@uvic.ca> <4F324A32.2050600@retired.ox.ac.uk> <4F327AF0.4090900@uvic.ca> <4F32AFE2.60606@oucs.ox.ac.uk> <4F32CC64.5040005@uvic.ca> <4F33A6D5.2000604@oucs.ox.ac.uk> <4F33CA90.1040102@uvic.ca> <4F340A9A.4050806@uvic.ca> Message-ID: <BC036331-45E7-4AC1-B808-12B97FB6A107@oucs.ox.ac.uk> On 9 Feb 2012, at 18:04, Martin Holmes wrote: > > Can't tell at the moment whether my changes have broken anything, > because builds are currently broken anyway -- Sebastian, shall we revert > your changes to Makefile to allow builds to go ahead, while we figure > out a different solution to the p5subset.xml problem? > just trying to fix that now -- Stormageddon Rahtz Head of Information and Support Group, Oxford University Computing Services 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 10 12:37:33 2012 From: gabriel.bodard at kcl.ac.uk (Gabriel Bodard) Date: Fri, 10 Feb 2012 17:37:33 +0000 Subject: [tei-council] TEI-C irc channel Message-ID: <4F3555DD.8080308@kcl.ac.uk> Hey, for the first time I've noticed in the ten months I've been regularly signed into the TEI-C irc channel (irc://freenode/TEI-C), two non-council users have logged in today to ask technical questions. At least one was someone who is not on TEI-L and claimed not to like mailing lists. If this is starting to become a habit, it might be useful if other Council members hung around from time to time, because many of you will be better able to answer some questions than I am. (Although James is usually in there too, today he was apparently busy elsewhere.) Seem reasonable? Or a one-off? G -- Dr Gabriel BODARD (Research Associate in Digital Epigraphy) Department of Digital 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 Sat Feb 11 05:06:27 2012 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Sat, 11 Feb 2012 10:06:27 +0000 Subject: [tei-council] TEI-C irc channel In-Reply-To: <4F3555DD.8080308@kcl.ac.uk> References: <4F3555DD.8080308@kcl.ac.uk> Message-ID: <4F363DA3.80409@oucs.ox.ac.uk> Hi Gaby (et al.), Yes, I'm auto-logged into that IRC channel _most_ of the time. Even when I'm asleep. So quite often I'm not physically present. ;-) Those logging in who are not related to board/council does happen sometimes and I think should be encouraged. I know I've answered questions there occasionally from people on freenode.net wanting to know something about the TEI. (One of the users that Gaby so deftly answered has definitely popped in before to ask questions.) Information on the TEI-C IRC channel and how to use it is available on the wiki at: http://wiki.tei-c.org/index.php/IRC (feel free to update... I wrote most of it in 2005....) Although IRC is a fairly erm... mature... technology, lots of software packages and other markup languages (e.g. docbook) have channels on freenode.net for public discussion and support. -James On 10/02/12 17:37, Gabriel Bodard wrote: > Hey, for the first time I've noticed in the ten months I've been > regularly signed into the TEI-C irc channel (irc://freenode/TEI-C), two > non-council users have logged in today to ask technical questions. At > least one was someone who is not on TEI-L and claimed not to like > mailing lists. > > If this is starting to become a habit, it might be useful if other > Council members hung around from time to time, because many of you will > be better able to answer some questions than I am. (Although James is > usually in there too, today he was apparently busy elsewhere.) > > Seem reasonable? Or a one-off? > > G > -- Dr James Cummings, InfoDev, Computing Services, University of Oxford From James.Cummings at oucs.ox.ac.uk Sat Feb 11 07:55:16 2012 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Sat, 11 Feb 2012 12:55:16 +0000 Subject: [tei-council] TEI Council Teleconference: 28 Feb 18:00 GMT Message-ID: <4F366534.7050501@oucs.ox.ac.uk> Dear all, According to the doodle poll http://www.doodle.com/6akx9cqy2zdcbdkn the best dateTime for a teleconference is Tuesday 28 February at 18:00 GMT. Please triple check what time and date this is for you at http://www.timeanddate.com/worldclock/fixedtime.html?msg=TEI+Council+Teleconference&iso=20120228T18&p1=1233 I'll circulate details of the conferencing system closer to the date. If anyone has suggestions for items for the agenda, feel free to either email me or the mailing list. -James -- Dr James Cummings, InfoDev, Computing Services, University of Oxford From kevin.s.hawkins at ultraslavonic.info Sun Feb 12 10:44:17 2012 From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins) Date: Sun, 12 Feb 2012 10:44:17 -0500 Subject: [tei-council] updated list of Council members etc. for P5 Message-ID: <4F37DE51.4020509@ultraslavonic.info> Colleagues, I am finally getting around to implementing FR 3041605: http://purl.org/TEI/fr/3041605 I've just posted two comments on the ticket with my proposed changes. There are a few outstanding questions there that someone with good institutional memory (I'm looking at you, Lou) might be able to help with: * Which members were on the Board by virtue of being Board Chair and which there there as appointed members? * Was Alejandro Bia replaced when he resigned? * When were the positions of Editors created? This whole thing has led me to wonder how exactly we ended up electing 6 and 4 Council members in alternating years. This practice dates to 2002, but I can't figure out how it got started. --Kevin From sebastian.rahtz at oucs.ox.ac.uk Sun Feb 12 11:08:42 2012 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Sun, 12 Feb 2012 16:08:42 +0000 Subject: [tei-council] updated list of Council members etc. for P5 In-Reply-To: <4F37DE51.4020509@ultraslavonic.info> References: <4F37DE51.4020509@ultraslavonic.info> Message-ID: <252F6DCE-AECF-453D-9B75-F118D5A8E138@oucs.ox.ac.uk> On 12 Feb 2012, at 15:44, Kevin Hawkins wrote: > > * Which members were on the Board by virtue of being Board Chair and > which there there as appointed members? I was the sole appointed member from 2001 to 2009. John, Julia, Matt, Dan and Martin were as council chairs > > * Was Alejandro Bia replaced when he resigned? > that I cant remember > * When were the positions of Editors created? > in the formation of TEI-C in 2000. > This whole thing has led me to wonder how exactly we ended up electing 6 > and 4 Council members in alternating years. This practice dates to > 2002, but I can't figure out how it got started. > I fear I cant remember offhand -- Stormageddon Rahtz Head of Information and Support Group, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From lou.burnard at retired.ox.ac.uk Sun Feb 12 12:59:20 2012 From: lou.burnard at retired.ox.ac.uk (Lou Burnard) Date: Sun, 12 Feb 2012 17:59:20 +0000 Subject: [tei-council] updated list of Council members etc. for P5 In-Reply-To: <252F6DCE-AECF-453D-9B75-F118D5A8E138@oucs.ox.ac.uk> References: <4F37DE51.4020509@ultraslavonic.info> <252F6DCE-AECF-453D-9B75-F118D5A8E138@oucs.ox.ac.uk> Message-ID: <4F37FDF8.5090800@retired.ox.ac.uk> On 12/02/12 16:08, Sebastian Rahtz wrote: > > On 12 Feb 2012, at 15:44, Kevin Hawkins wrote: > >> >> * Which members were on the Board by virtue of being Board Chair and >> which there there as appointed members? > > I was the sole appointed member from 2001 to 2009. John, Julia, Matt, Dan and Martin were > as council chairs I think my esteemed colleague means to say "Sebastian was appointed to the Council by the Board; John Julia Matt Dan and Martin as Board chairs were ex officio members of the Council" > >> >> * Was Alejandro Bia replaced when he resigned? >> > that I cant remember I think he was, but I cannot remember by whom. This would require some research... is it important? > >> * When were the positions of Editors created? >> > in the formation of TEI-C in 2000. Nonsense. The position of TEI Editor predates the existence of the Consortium by many many years. > >> This whole thing has led me to wonder how exactly we ended up electing 6 >> and 4 Council members in alternating years. This practice dates to >> 2002, but I can't figure out how it got started. >> > I fear I cant remember offhand Which "whole thing" would that be? I think it's probably a consequence of the number of vacancies in year x being different from that in year y, coupled with the term of office? > > -- > Stormageddon Rahtz > Head of Information and Support Group, Oxford University Computing Services > 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 12 13:28:24 2012 From: mholmes at uvic.ca (Martin Holmes) Date: Sun, 12 Feb 2012 10:28:24 -0800 Subject: [tei-council] updated list of Council members etc. for P5 In-Reply-To: <4F37DE51.4020509@ultraslavonic.info> References: <4F37DE51.4020509@ultraslavonic.info> Message-ID: <4F3804C8.6070200@uvic.ca> I see I also had a task on this ticket, which I've shamefully neglected. As far as figuring out how to encode a person-base, I don't think there's anything complicated involved, but I think everyone (past and present members) will have to agree on what information about them may be included, and we'll need a mechanism for updating the info periodically. I'll try to have something ready for the teleconference. Cheers, Martin On 12-02-12 07:44 AM, Kevin Hawkins wrote: > Colleagues, > > I am finally getting around to implementing FR 3041605: > > http://purl.org/TEI/fr/3041605 > > I've just posted two comments on the ticket with my proposed changes. > There are a few outstanding questions there that someone with good > institutional memory (I'm looking at you, Lou) might be able to help with: > > * Which members were on the Board by virtue of being Board Chair and > which there there as appointed members? > > * Was Alejandro Bia replaced when he resigned? > > * When were the positions of Editors created? > > This whole thing has led me to wonder how exactly we ended up electing 6 > and 4 Council members in alternating years. This practice dates to > 2002, but I can't figure out how it got started. > > --Kevin From sebastian.rahtz at oucs.ox.ac.uk Sun Feb 12 14:21:26 2012 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Sun, 12 Feb 2012 19:21:26 +0000 Subject: [tei-council] updated list of Council members etc. for P5 In-Reply-To: <4F37FDF8.5090800@retired.ox.ac.uk> References: <4F37DE51.4020509@ultraslavonic.info> <252F6DCE-AECF-453D-9B75-F118D5A8E138@oucs.ox.ac.uk> <4F37FDF8.5090800@retired.ox.ac.uk> Message-ID: <3C89BE68-D1D3-4241-BC28-6013BBD16632@oucs.ox.ac.uk> On 12 Feb 2012, at 17:59, Lou Burnard wrote: > I think my esteemed colleague means to say > > "Sebastian was appointed to the Council by the Board; John Julia Matt > Dan and Martin as Board chairs were ex officio members of the Council" > krekt >> in the formation of TEI-C in 2000. > > Nonsense. The position of TEI Editor predates the existence of the > Consortium by many many years. > yes. but the pre-TEIC editors were in a different world. what I meant was that the editors were built into TEIC from its start -- Stormageddon Rahtz Head of Information and Support Group, Oxford University Computing Services 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 Feb 12 15:43:18 2012 From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins) Date: Sun, 12 Feb 2012 15:43:18 -0500 Subject: [tei-council] updated list of Council members etc. for P5 In-Reply-To: <3C89BE68-D1D3-4241-BC28-6013BBD16632@oucs.ox.ac.uk> References: <4F37DE51.4020509@ultraslavonic.info> <252F6DCE-AECF-453D-9B75-F118D5A8E138@oucs.ox.ac.uk> <4F37FDF8.5090800@retired.ox.ac.uk> <3C89BE68-D1D3-4241-BC28-6013BBD16632@oucs.ox.ac.uk> Message-ID: <4F382466.6070506@ultraslavonic.info> Thanks for the quick responses ... On 2/12/12 12:59 PM, Lou Burnard wrote: >>> * Was Alejandro Bia replaced when he resigned? >>> >> that I cant remember > > I think he was, but I cannot remember by whom. This would require some > research... is it important? Only because I want to make sure that if someone filled out his term, this is acknowledged in the list. >>> This whole thing has led me to wonder how exactly we ended up electing 6 >>> and 4 Council members in alternating years. This practice dates to >>> 2002, but I can't figure out how it got started. >>> >> I fear I cant remember offhand > > > Which "whole thing" would that be? I think it's probably a consequence > of the number of vacancies in year x being different from that in year > y, coupled with the term of office? The "whole thing" is revising FM1. In going through the TEI-L archives and especially minutes of past business meetings, I see that we've alternated between 6 and 4 people from as far back as I can find record of elections to Council. It implies that when the Council was first constituted, we didn't evenly divide its membership into one- and two-year terms. I find this suspicious and wonder if the solution could reveal an error of some sort in the list of Council members in FM1. But I'm not going to worry about it. On 2/12/12 2:21 PM, Sebastian Rahtz wrote: >>> in the formation of TEI-C in 2000. >> >> Nonsense. The position of TEI Editor predates the existence of the >> Consortium by many many years. >> > yes. but the pre-TEIC editors were in a different world. what I meant was that the editors > were built into TEIC from its start Right, the sentence in need of revision deals with editors serving ex officio on the Council. Were the editors (2000-08) appointed by the Board? Elected by the TEI-C membership? Something else? This affects how I would revise the sentence for clarity. From mholmes at uvic.ca Mon Feb 13 10:47:59 2012 From: mholmes at uvic.ca (Martin Holmes) Date: Mon, 13 Feb 2012 07:47:59 -0800 Subject: [tei-council] Release process documentation Message-ID: <4F3930AF.5040701@uvic.ca> Hi all, I've made one more change to the release process documentation document, TCW22, to add a 17th step relating to the Stylesheets, and arising out of our experience cleaning up after the last release. I've also edited TCW20 to remove the content of the section on Building a Release, and replace it with a link to the new document. The two working papers are here: <http://www.tei-c.org/Activities/Council/Working/tcw20.xml> <http://www.tei-c.org/Activities/Council/Working/tcw22.xml> I think that concludes the work arising out of the 2.0.2 release, and I think we're now in good shape for Gaby to work through TWC22 when he does the next one. Because it's so tricky (well, it's impossible, really) to fully test the process without actually doing it for real, we won't be really sure that the changes we made to avoid the problems we had last time are really effective until the next release, but it should be much smoother next time around. Cheers, Martin From bansp at o2.pl Mon Feb 13 11:00:37 2012 From: bansp at o2.pl (=?ISO-8859-2?Q?Piotr_Ba=F1ski?=) Date: Mon, 13 Feb 2012 17:00:37 +0100 Subject: [tei-council] Release process documentation In-Reply-To: <4F3930AF.5040701@uvic.ca> References: <4F3930AF.5040701@uvic.ca> Message-ID: <4F3933A5.4030301@o2.pl> Hi Martin, Thanks for putting the doc together, it's going to be very useful. I wonder, maybe it makes sense to encourage local validation before waiting for Jenkins to finish, as in the e-mail by Sebastian: http://lists.village.virginia.edu/pipermail/tei-council/2011/013232.html Best, P. On 13/02/12 16:47, Martin Holmes wrote: > Hi all, > > I've made one more change to the release process documentation document, > TCW22, to add a 17th step relating to the Stylesheets, and arising out > of our experience cleaning up after the last release. I've also edited > TCW20 to remove the content of the section on Building a Release, and > replace it with a link to the new document. The two working papers are here: > > <http://www.tei-c.org/Activities/Council/Working/tcw20.xml> > <http://www.tei-c.org/Activities/Council/Working/tcw22.xml> > > I think that concludes the work arising out of the 2.0.2 release, and I > think we're now in good shape for Gaby to work through TWC22 when he > does the next one. Because it's so tricky (well, it's impossible, > really) to fully test the process without actually doing it for real, we > won't be really sure that the changes we made to avoid the problems we > had last time are really effective until the next release, but it should > be much smoother next time around. > > Cheers, > Martin From bansp at o2.pl Mon Feb 13 11:18:50 2012 From: bansp at o2.pl (=?ISO-8859-2?Q?Piotr_Ba=F1ski?=) Date: Mon, 13 Feb 2012 17:18:50 +0100 Subject: [tei-council] Release process documentation In-Reply-To: <4F3933A5.4030301@o2.pl> References: <4F3930AF.5040701@uvic.ca> <4F3933A5.4030301@o2.pl> Message-ID: <4F3937EA.4080600@o2.pl> Or maybe this info belongs rather at http://www.tei-c.org/Activities/Council/Working/tcw20.xml#body.1_div.4 where p5odds.rnc is mentioned, but it doesn't say how to derive it ("make oddschema"). P. On 13/02/12 17:00, Piotr Ba?ski wrote: > Hi Martin, > > Thanks for putting the doc together, it's going to be very useful. I > wonder, maybe it makes sense to encourage local validation before > waiting for Jenkins to finish, as in the e-mail by Sebastian: > > http://lists.village.virginia.edu/pipermail/tei-council/2011/013232.html > > Best, > > P. > > On 13/02/12 16:47, Martin Holmes wrote: >> Hi all, >> >> I've made one more change to the release process documentation document, >> TCW22, to add a 17th step relating to the Stylesheets, and arising out >> of our experience cleaning up after the last release. I've also edited >> TCW20 to remove the content of the section on Building a Release, and >> replace it with a link to the new document. The two working papers are here: >> >> <http://www.tei-c.org/Activities/Council/Working/tcw20.xml> >> <http://www.tei-c.org/Activities/Council/Working/tcw22.xml> >> >> I think that concludes the work arising out of the 2.0.2 release, and I >> think we're now in good shape for Gaby to work through TWC22 when he >> does the next one. Because it's so tricky (well, it's impossible, >> really) to fully test the process without actually doing it for real, we >> won't be really sure that the changes we made to avoid the problems we >> had last time are really effective until the next release, but it should >> be much smoother next time around. >> >> Cheers, >> Martin > From sebastian.rahtz at oucs.ox.ac.uk Mon Feb 13 11:26:33 2012 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 13 Feb 2012 16:26:33 +0000 Subject: [tei-council] Release process documentation In-Reply-To: <4F3937EA.4080600@o2.pl> References: <4F3930AF.5040701@uvic.ca> <4F3933A5.4030301@o2.pl> <4F3937EA.4080600@o2.pl> Message-ID: <CE44EE83-DB13-4D76-877B-613B4AD45BE3@oucs.ox.ac.uk> On 13 Feb 2012, at 16:18, Piotr Ba?ski wrote: > Or maybe this info belongs rather at > > http://www.tei-c.org/Activities/Council/Working/tcw20.xml#body.1_div.4 > > where p5odds.rnc is mentioned, but it doesn't say how to derive it > ("make oddschema"). I now think we should tweak P5 to deliver p5odds.rnc, so that its referenceable from www.tei-c.org. I'll look at that for the next release. but it does say how to derive it - "make oddschema" mean type the command "make oddschema" in the P5 source directory, on a *Nix command line -- Stormageddon Rahtz Head of Information and Support Group Oxford University Computing Services 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 13 11:29:22 2012 From: mholmes at uvic.ca (Martin Holmes) Date: Mon, 13 Feb 2012 08:29:22 -0800 Subject: [tei-council] Release process documentation In-Reply-To: <4F3933A5.4030301@o2.pl> References: <4F3930AF.5040701@uvic.ca> <4F3933A5.4030301@o2.pl> Message-ID: <4F393A62.8080609@uvic.ca> Hi Piotr, I thought about this, but there is some risk that a local installation of the TEI infrastructure might not be fully updated. Sebastian releases regular updates to the Debian and Oxygen packages, and obviously keeps his Jenkins server updated; he also informs me about any changes such as new packages which need to be added, and I try to keep mine in sync too, so the two act as a check on each other. If someone did a local build, and encountered errors, they wouldn't necessarily know whether the errors were caused by their local install of TEI being slightly out of sync, or whether the errors were real. So on balance, relying on the Jinks servers (especially now there are two of them) seems the more solid option. Cheers, Martin On 12-02-13 08:00 AM, Piotr Ba?ski wrote: > Hi Martin, > > Thanks for putting the doc together, it's going to be very useful. I > wonder, maybe it makes sense to encourage local validation before > waiting for Jenkins to finish, as in the e-mail by Sebastian: > > http://lists.village.virginia.edu/pipermail/tei-council/2011/013232.html > > Best, > > P. > > On 13/02/12 16:47, Martin Holmes wrote: >> Hi all, >> >> I've made one more change to the release process documentation document, >> TCW22, to add a 17th step relating to the Stylesheets, and arising out >> of our experience cleaning up after the last release. I've also edited >> TCW20 to remove the content of the section on Building a Release, and >> replace it with a link to the new document. The two working papers are here: >> >> <http://www.tei-c.org/Activities/Council/Working/tcw20.xml> >> <http://www.tei-c.org/Activities/Council/Working/tcw22.xml> >> >> I think that concludes the work arising out of the 2.0.2 release, and I >> think we're now in good shape for Gaby to work through TWC22 when he >> does the next one. Because it's so tricky (well, it's impossible, >> really) to fully test the process without actually doing it for real, we >> won't be really sure that the changes we made to avoid the problems we >> had last time are really effective until the next release, but it should >> be much smoother next time around. >> >> Cheers, >> Martin > From bansp at o2.pl Mon Feb 13 12:56:12 2012 From: bansp at o2.pl (=?ISO-8859-2?Q?Piotr_Ba=F1ski?=) Date: Mon, 13 Feb 2012 18:56:12 +0100 Subject: [tei-council] Release process documentation In-Reply-To: <4F393A62.8080609@uvic.ca> References: <4F3930AF.5040701@uvic.ca> <4F3933A5.4030301@o2.pl> <4F393A62.8080609@uvic.ca> Message-ID: <4F394EBC.3000402@o2.pl> Frankly, being mostly an end user of SVN, with its sacred policy of "sync before you start your work", I'm a bit lost when it comes to the interaction of SVN and continuous integration. I'm just wondering whether, if we neglect telling the user (Council member, etc.) to sync before work, we risk that other people's additions may get lost, given that they go via SVN. I really don't see the whole picture here -- maybe it's worth a note by a specialist, for paranoid half-trained types like myself. :-) Piotr On 13/02/12 17:29, Martin Holmes wrote: > Hi Piotr, > > I thought about this, but there is some risk that a local installation > of the TEI infrastructure might not be fully updated. Sebastian releases > regular updates to the Debian and Oxygen packages, and obviously keeps > his Jenkins server updated; he also informs me about any changes such as > new packages which need to be added, and I try to keep mine in sync too, > so the two act as a check on each other. > > If someone did a local build, and encountered errors, they wouldn't > necessarily know whether the errors were caused by their local install > of TEI being slightly out of sync, or whether the errors were real. So > on balance, relying on the Jinks servers (especially now there are two > of them) seems the more solid option. > > Cheers, > Martin > > On 12-02-13 08:00 AM, Piotr Ba?ski wrote: >> Hi Martin, >> >> Thanks for putting the doc together, it's going to be very useful. I >> wonder, maybe it makes sense to encourage local validation before >> waiting for Jenkins to finish, as in the e-mail by Sebastian: >> >> http://lists.village.virginia.edu/pipermail/tei-council/2011/013232.html >> >> Best, >> >> P. >> >> On 13/02/12 16:47, Martin Holmes wrote: >>> Hi all, >>> >>> I've made one more change to the release process documentation document, >>> TCW22, to add a 17th step relating to the Stylesheets, and arising out >>> of our experience cleaning up after the last release. I've also edited >>> TCW20 to remove the content of the section on Building a Release, and >>> replace it with a link to the new document. The two working papers are here: >>> >>> <http://www.tei-c.org/Activities/Council/Working/tcw20.xml> >>> <http://www.tei-c.org/Activities/Council/Working/tcw22.xml> >>> >>> I think that concludes the work arising out of the 2.0.2 release, and I >>> think we're now in good shape for Gaby to work through TWC22 when he >>> does the next one. Because it's so tricky (well, it's impossible, >>> really) to fully test the process without actually doing it for real, we >>> won't be really sure that the changes we made to avoid the problems we >>> had last time are really effective until the next release, but it should >>> be much smoother next time around. >>> >>> Cheers, >>> Martin >> From bansp at o2.pl Mon Feb 13 12:58:15 2012 From: bansp at o2.pl (=?ISO-8859-2?Q?Piotr_Ba=F1ski?=) Date: Mon, 13 Feb 2012 18:58:15 +0100 Subject: [tei-council] Release process documentation In-Reply-To: <CE44EE83-DB13-4D76-877B-613B4AD45BE3@oucs.ox.ac.uk> References: <4F3930AF.5040701@uvic.ca> <4F3933A5.4030301@o2.pl> <4F3937EA.4080600@o2.pl> <CE44EE83-DB13-4D76-877B-613B4AD45BE3@oucs.ox.ac.uk> Message-ID: <4F394F37.8070909@o2.pl> On 13/02/12 17:26, Sebastian Rahtz wrote: > but it does say how to derive it - "make oddschema" mean > type the command "make oddschema" in the P5 source directory, > on a *Nix command line But "it says" so in your e-mail, not in those docs :-) (I should have phrased it clearer -- the "make oddschema" was my suggested addition) P. From mholmes at uvic.ca Mon Feb 13 13:25:44 2012 From: mholmes at uvic.ca (Martin Holmes) Date: Mon, 13 Feb 2012 10:25:44 -0800 Subject: [tei-council] Release process documentation In-Reply-To: <4F394EBC.3000402@o2.pl> References: <4F3930AF.5040701@uvic.ca> <4F3933A5.4030301@o2.pl> <4F393A62.8080609@uvic.ca> <4F394EBC.3000402@o2.pl> Message-ID: <4F3955A8.9010708@uvic.ca> Hi Piotr, We would expect anyone managing a release to be fully comfortable with editing the source and syncing with SVN. They have to commit changes to the VERSION file anyway, to start the process, so if their source tree was out of sync, there would be an error there. If they want to build locally before committing changes, then that's fine, but there's no need for it when we have the Jinks servers. I'd also rather not get into giving instructions for setting up a build environment on your local machine (which might be Windows, Mac or Linux), when all that's actually needed is SVN. Cheers, Martin On 12-02-13 09:56 AM, Piotr Ba?ski wrote: > Frankly, being mostly an end user of SVN, with its sacred policy of > "sync before you start your work", I'm a bit lost when it comes to the > interaction of SVN and continuous integration. I'm just wondering > whether, if we neglect telling the user (Council member, etc.) to sync > before work, we risk that other people's additions may get lost, given > that they go via SVN. I really don't see the whole picture here -- maybe > it's worth a note by a specialist, for paranoid half-trained types like > myself. > > :-) > > Piotr > > On 13/02/12 17:29, Martin Holmes wrote: >> Hi Piotr, >> >> I thought about this, but there is some risk that a local installation >> of the TEI infrastructure might not be fully updated. Sebastian releases >> regular updates to the Debian and Oxygen packages, and obviously keeps >> his Jenkins server updated; he also informs me about any changes such as >> new packages which need to be added, and I try to keep mine in sync too, >> so the two act as a check on each other. >> >> If someone did a local build, and encountered errors, they wouldn't >> necessarily know whether the errors were caused by their local install >> of TEI being slightly out of sync, or whether the errors were real. So >> on balance, relying on the Jinks servers (especially now there are two >> of them) seems the more solid option. >> >> Cheers, >> Martin >> >> On 12-02-13 08:00 AM, Piotr Ba?ski wrote: >>> Hi Martin, >>> >>> Thanks for putting the doc together, it's going to be very useful. I >>> wonder, maybe it makes sense to encourage local validation before >>> waiting for Jenkins to finish, as in the e-mail by Sebastian: >>> >>> http://lists.village.virginia.edu/pipermail/tei-council/2011/013232.html >>> >>> Best, >>> >>> P. >>> >>> On 13/02/12 16:47, Martin Holmes wrote: >>>> Hi all, >>>> >>>> I've made one more change to the release process documentation document, >>>> TCW22, to add a 17th step relating to the Stylesheets, and arising out >>>> of our experience cleaning up after the last release. I've also edited >>>> TCW20 to remove the content of the section on Building a Release, and >>>> replace it with a link to the new document. The two working papers are here: >>>> >>>> <http://www.tei-c.org/Activities/Council/Working/tcw20.xml> >>>> <http://www.tei-c.org/Activities/Council/Working/tcw22.xml> >>>> >>>> I think that concludes the work arising out of the 2.0.2 release, and I >>>> think we're now in good shape for Gaby to work through TWC22 when he >>>> does the next one. Because it's so tricky (well, it's impossible, >>>> really) to fully test the process without actually doing it for real, we >>>> won't be really sure that the changes we made to avoid the problems we >>>> had last time are really effective until the next release, but it should >>>> be much smoother next time around. >>>> >>>> Cheers, >>>> Martin >>> > From sebastian.rahtz at oucs.ox.ac.uk Mon Feb 13 13:32:58 2012 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 13 Feb 2012 18:32:58 +0000 Subject: [tei-council] Release process documentation In-Reply-To: <4F394EBC.3000402@o2.pl> References: <4F3930AF.5040701@uvic.ca> <4F3933A5.4030301@o2.pl> <4F393A62.8080609@uvic.ca> <4F394EBC.3000402@o2.pl> Message-ID: <66126A59-A2CE-4550-93E9-8AB4489E3A55@oucs.ox.ac.uk> On 13 Feb 2012, at 17:56, Piotr Ba?ski wrote: > Frankly, being mostly an end user of SVN, with its sacred policy of > "sync before you start your work", I'm a bit lost when it comes to the > interaction of SVN and continuous integration. I'm just wondering > whether, if we neglect telling the user (Council member, etc.) to sync > before work, we risk that other people's additions may get lost, given > that they go via SVN. I Using SVN to edit the sources is separately from building. All the normal disciplines apply, like syncing before you start. SVN won't ever lose your work if you commit it - if it fails to commit, it will tell you why, and you'll need to recover. if you check out P5, and edit it over a period of a week Monday to Friday without committing changes, then you run a risk that I will have done work on Tuesday, and committed it the same day, so when you come to commit on Friday you may have a conflict. But this is normal version control stuff. -- Stormageddon Rahtz Head of Information and Support Group, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From lou.burnard at retired.ox.ac.uk Mon Feb 13 13:40:14 2012 From: lou.burnard at retired.ox.ac.uk (Lou Burnard) Date: Mon, 13 Feb 2012 18:40:14 +0000 Subject: [tei-council] Release process documentation In-Reply-To: <66126A59-A2CE-4550-93E9-8AB4489E3A55@oucs.ox.ac.uk> References: <4F3930AF.5040701@uvic.ca> <4F3933A5.4030301@o2.pl> <4F393A62.8080609@uvic.ca> <4F394EBC.3000402@o2.pl> <66126A59-A2CE-4550-93E9-8AB4489E3A55@oucs.ox.ac.uk> Message-ID: <4F39590E.3030807@retired.ox.ac.uk> Personally, I find it very useful to be able to do a test build on my local machine before committing changes. The chances that some other change will have taken place that might affect the parts I am messing with, although not neglible, is still less than the probability that I will have messed up those parts in some embarrassingly obvious way which I'd rather not expose to the rest of the developer community :-) But, to coin a phrase, your mileage may very well vary. And now that we have a pair of Jinxes I am finding the number of embarrassingly obvious errors I do have to expose is considerably reduced. On 13/02/12 18:32, Sebastian Rahtz wrote: > > On 13 Feb 2012, at 17:56, Piotr Ba?ski wrote: > >> Frankly, being mostly an end user of SVN, with its sacred policy of >> "sync before you start your work", I'm a bit lost when it comes to the >> interaction of SVN and continuous integration. I'm just wondering >> whether, if we neglect telling the user (Council member, etc.) to sync >> before work, we risk that other people's additions may get lost, given >> that they go via SVN. I > > Using SVN to edit the sources is separately from building. > All the normal disciplines apply, like syncing before you start. > SVN won't ever lose your work if you commit it - if it fails to commit, > it will tell you why, and you'll need to recover. > > if you check out P5, and edit it over a period of a week Monday to Friday > without committing changes, then you run a risk that I will have > done work on Tuesday, and committed it the same day, so when you > come to commit on Friday you may have a conflict. But this is normal > version control stuff. > -- > Stormageddon Rahtz > Head of Information and Support Group, Oxford University Computing Services > 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 13 13:52:26 2012 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 13 Feb 2012 18:52:26 +0000 Subject: [tei-council] Release process documentation In-Reply-To: <4F39590E.3030807@retired.ox.ac.uk> References: <4F3930AF.5040701@uvic.ca> <4F3933A5.4030301@o2.pl> <4F393A62.8080609@uvic.ca> <4F394EBC.3000402@o2.pl> <66126A59-A2CE-4550-93E9-8AB4489E3A55@oucs.ox.ac.uk> <4F39590E.3030807@retired.ox.ac.uk> Message-ID: <2290631C-9755-446D-B396-0920F8BC08BE@oucs.ox.ac.uk> On 13 Feb 2012, at 18:40, Lou Burnard wrote: > Personally, I find it very useful to be able to do a test build on my > local machine before committing changes. The chances that some other > change will have taken place that might affect the parts I am messing > with, although not neglible, is still less than the probability that I > will have messed up those parts in some embarrassingly obvious way which > I'd rather not expose to the rest of the developer community :-) Yes indeed, me too. And its vitally important that the build process be entirely open and reproducible by relatively ordinary people. Worth remembering that the Jinxes do more than validating. They also assemble and package deliverables, doing things that most people can't be bothered with, and running over the tedious tests like validating all the separate HTML files generated. -- Stormageddon Rahtz Head of Information and Support Group, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From bansp at o2.pl Mon Feb 13 14:06:10 2012 From: bansp at o2.pl (=?ISO-8859-2?Q?Piotr_Ba=F1ski?=) Date: Mon, 13 Feb 2012 20:06:10 +0100 Subject: [tei-council] Release process documentation In-Reply-To: <4F3955A8.9010708@uvic.ca> References: <4F3930AF.5040701@uvic.ca> <4F3933A5.4030301@o2.pl> <4F393A62.8080609@uvic.ca> <4F394EBC.3000402@o2.pl> <4F3955A8.9010708@uvic.ca> Message-ID: <4F395F22.9050109@o2.pl> Hi again, Ah, I think I see where the misunderstanding was: I meant only "a bit of building" ;-), namely making sure to have the p5odds schema alone, which is obviously useful for editing with validation on the fly, which in turn eliminates the need to wait for Jenkins to discover that I forgot something half-obvious, like element ordering, obligatory attribute, etc. And which helps in content completion. But if Sebastian goes with what he suggested earlier in this thread, namely making the current p5odds referenceable from outside, as it were, all my problems will be forgotten, and the world will be green and dreamy... Best, P. On 13/02/12 19:25, Martin Holmes wrote: > Hi Piotr, > > We would expect anyone managing a release to be fully comfortable with > editing the source and syncing with SVN. They have to commit changes to > the VERSION file anyway, to start the process, so if their source tree > was out of sync, there would be an error there. > > If they want to build locally before committing changes, then that's > fine, but there's no need for it when we have the Jinks servers. I'd > also rather not get into giving instructions for setting up a build > environment on your local machine (which might be Windows, Mac or > Linux), when all that's actually needed is SVN. > > Cheers, > Martin > > On 12-02-13 09:56 AM, Piotr Ba?ski wrote: >> Frankly, being mostly an end user of SVN, with its sacred policy of >> "sync before you start your work", I'm a bit lost when it comes to the >> interaction of SVN and continuous integration. I'm just wondering >> whether, if we neglect telling the user (Council member, etc.) to sync >> before work, we risk that other people's additions may get lost, given >> that they go via SVN. I really don't see the whole picture here -- maybe >> it's worth a note by a specialist, for paranoid half-trained types like >> myself. >> >> :-) >> >> Piotr >> >> On 13/02/12 17:29, Martin Holmes wrote: >>> Hi Piotr, >>> >>> I thought about this, but there is some risk that a local installation >>> of the TEI infrastructure might not be fully updated. Sebastian releases >>> regular updates to the Debian and Oxygen packages, and obviously keeps >>> his Jenkins server updated; he also informs me about any changes such as >>> new packages which need to be added, and I try to keep mine in sync too, >>> so the two act as a check on each other. >>> >>> If someone did a local build, and encountered errors, they wouldn't >>> necessarily know whether the errors were caused by their local install >>> of TEI being slightly out of sync, or whether the errors were real. So >>> on balance, relying on the Jinks servers (especially now there are two >>> of them) seems the more solid option. >>> >>> Cheers, >>> Martin >>> >>> On 12-02-13 08:00 AM, Piotr Ba?ski wrote: >>>> Hi Martin, >>>> >>>> Thanks for putting the doc together, it's going to be very useful. I >>>> wonder, maybe it makes sense to encourage local validation before >>>> waiting for Jenkins to finish, as in the e-mail by Sebastian: >>>> >>>> http://lists.village.virginia.edu/pipermail/tei-council/2011/013232.html >>>> >>>> Best, >>>> >>>> P. >>>> >>>> On 13/02/12 16:47, Martin Holmes wrote: >>>>> Hi all, >>>>> >>>>> I've made one more change to the release process documentation document, >>>>> TCW22, to add a 17th step relating to the Stylesheets, and arising out >>>>> of our experience cleaning up after the last release. I've also edited >>>>> TCW20 to remove the content of the section on Building a Release, and >>>>> replace it with a link to the new document. The two working papers are here: >>>>> >>>>> <http://www.tei-c.org/Activities/Council/Working/tcw20.xml> >>>>> <http://www.tei-c.org/Activities/Council/Working/tcw22.xml> >>>>> >>>>> I think that concludes the work arising out of the 2.0.2 release, and I >>>>> think we're now in good shape for Gaby to work through TWC22 when he >>>>> does the next one. Because it's so tricky (well, it's impossible, >>>>> really) to fully test the process without actually doing it for real, we >>>>> won't be really sure that the changes we made to avoid the problems we >>>>> had last time are really effective until the next release, but it should >>>>> be much smoother next time around. >>>>> >>>>> Cheers, >>>>> Martin >>>> >> From sebastian.rahtz at oucs.ox.ac.uk Mon Feb 13 14:34:52 2012 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 13 Feb 2012 19:34:52 +0000 Subject: [tei-council] Release process documentation In-Reply-To: <4F395F22.9050109@o2.pl> References: <4F3930AF.5040701@uvic.ca> <4F3933A5.4030301@o2.pl> <4F393A62.8080609@uvic.ca> <4F394EBC.3000402@o2.pl> <4F3955A8.9010708@uvic.ca> <4F395F22.9050109@o2.pl> Message-ID: <714EF1F4-8452-42EB-AB4B-B493FF736919@oucs.ox.ac.uk> On 13 Feb 2012, at 19:06, Piotr Ba?ski wrote: > > But if Sebastian goes with what he suggested earlier in this thread, > namely making the current p5odds referenceable from outside, as it were, > all my problems will be forgotten, and the world will be green and dreamy... I've just made that changes, seems uncontroversial. -- Stormageddon Rahtz Head of Information and Support Group, Oxford University Computing Services 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 Feb 18 18:13:02 2012 From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins) Date: Sat, 18 Feb 2012 18:13:02 -0500 Subject: [tei-council] for 28 Feb. conf call: background on Best Practice for TEI in Libraries Message-ID: <4F40307E.6080807@ultraslavonic.info> All, James has asked me to provide some background on the conf call agenda items that I put forward so that we can focus on discussion rather than providing background information during the call. To that end, I'll send two emails: one giving background on the brief reports (forthcoming once I find out a bit more about what my collaborators are up to) and this one, which gives background on the *Best Practices for TEI in Libraries* (BP). The BP was created by members of the SIG on Libraries and consists of a set of ODD files in a GitHub project, plus a few shell scripts and such for compilation into unified documentation. It was released as version 3.0 (having superseded earlier documents with similar names), and a snapshot of the full documentation is stored in the SIG's webspace on tei-c.org ( http://www.tei-c.org/SIG/Libraries/teiinlibraries/ ). There are a few pages in the TEI wiki containing notes on recommended revisions to the document. While it would make sense for the SIG on Libraries to review the BP occasionally in light of new releases of the TEI and in response to community needs, only been a handful of SIG members have found time to contribute to the BP. I hosted two SIG meetings this fall (in Wuerzburg and at the Digital Library Federation Forum in Baltimore) and informally fished for successors to Michelle Dalmau and me, who led development of the BP, but wasn't finding any. So we would like to institutionalize support for the BP's development for fear that will fall into neglect. If the Council takes a role in the maintenance of this and other community-driven customizations, the Council can ensure coherence across them and attempt to recruit assistance from specialists for complex matters. Maintenance by the Council would help ensure (though somewhat indirectly) that the BP customizations are available through Roma and in oxygen-tei. However, I need to offer a few disclaimers about the BP: a) The encoding prescribed in the BP for Levels 1 and 2 is definitely not TEI-conformant; I'm unsure about Levels 3 and 4. Not sure whether this would disqualify it. b) If Council feels that materials under its stewardship must be in Sourceforge, the content would need to be moved there from GitHub and the appropriate wiki pages. This isn't a problem, but note that the idea of moving all TEI content out of Sourceforge into GitHub has occasionally been suggested. Regardless of whether the Council takes over or contributes to maintenance of the BP, I would like to see the BP added to the appropriate section of http://www.tei-c.org/Guidelines/Customization/ . Currently that webpage says to email editors at tei-c.org to request that a customization be added, but I'm not sure that's correct since there are no longer editors of the TEI. Perhaps if you have any clarifying questions, I can try to answer them now; otherwise, we can simply discuss on 28 February. Kevin From kevin.s.hawkins at ultraslavonic.info Sat Feb 18 18:33:21 2012 From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins) Date: Sat, 18 Feb 2012 18:33:21 -0500 Subject: [tei-council] Minor error in Guidelines In-Reply-To: <CAA2irtLG+Rqeh5=buxRqog0-JRnxuwmgfGg5vWUnQKSLBmCJWQ@mail.gmail.com> References: <4F0F9F9F.3050408@gmail.com> <4F0FBAA5.2090706@uvic.ca> <97AE8F42-0EDB-41CC-8FE1-984EE9E495D4@oucs.ox.ac.uk> <4F10590C.50904@uvic.ca> <4F1059A9.1000709@retired.ox.ac.uk> <4F21FA47.2050800@ultraslavonic.info> <CAA2irtLG+Rqeh5=buxRqog0-JRnxuwmgfGg5vWUnQKSLBmCJWQ@mail.gmail.com> Message-ID: <4F403541.5050107@ultraslavonic.info> Good, I've updated http://www.tei-c.org/Activities/Council/Working/tcw20.xml . On 1/27/12 12:38 PM, Rebecca Welzenbach wrote: > I would certainly find it valuable! > > On Thu, Jan 26, 2012 at 8:13 PM, Kevin Hawkins > <kevin.s.hawkins at ultraslavonic.info> wrote: >> I'm wondering whether others feel that we should add a bit to >> >> http://www.tei-c.org/Activities/Council/Working/tcw20.xml >> >> or perhaps more properly >> >> P5/Source/Guidelines/en/style-guide.txt >> >> stating this distinction. There might be other things that those who >> have been editing the Guidelines keep in mind but haven't written down >> for the rest of us. >> >> Such a passage would be similar to this, which I found in tcw20 and is >> similarly prescriptive about encoding practice: >> >> ### >> >> In most chapters, the two character code is also used as a prefix for >> the @xml:id values given to each<div> element. Note that every<div> >> element carries an @xml:id value, whether or not it is actually >> referenced explicitly elewhere in the Guidelines. >> >> ### >> >> Is this worthwhile, or would none of us ever remember to consult this >> anyway? >> >> --K. >> >> On 1/13/12 11:19 AM, Lou Burnard wrote: >>> In the Guidelines, as elsewhere, >>> >>> <ref target="#foo">section foo</ref> means: generate a link to #foo and >>> represent it by the text "section foo". >>> >>> <ptr target="#foo"/> means: generate a link to #foo and represent it by >>> whatever text your processor chooses to generate >>> >>> >>> >>> On 13/01/12 16:17, Martin Holmes wrote: >>>> Could you clarify what the difference is between using<ref> and<ptr> >>>> in the guidelines? >>>> >>>> Cheers, >>>> Martin >>>> >>>> On 12-01-13 01:32 AM, Sebastian Rahtz wrote: >>>>> >>>>> On 13 Jan 2012, at 05:01, Martin Holmes wrote: >>>>> >>>>>> I've put in a bug report for this: >>>>>> >>>>>> <http://purl.org/TEI/BUGS/3473329> >>>>>> >>>>>> The basic problem is that in the web view of the Guidelines, figures >>>>>> within each chapter are numbered 1, 2, 3, 4 etc., but in the PDF output, >>>>>> they're numbered 11.1, 11.2, 11.3? >>>>>> >>>>> there are two issues here. >>>>> >>>>> a) the use of dangerous markup like "<ref target="#sleeprs">figure 4 above</ref>", which should be changed into a<ptr> to avoid this sort of problem >>>>> b) the different numbering schemes >>>>> >>>>> for the latter, which do we want for the Guidelines? by chapter, or sequential throughout? >>>>> >>>>> for the former, I found 3 occurrences of this, and changed them to<ptr>. am testing before committing. >>>>> -- >>>>> Stormageddon Rahtz >>>>> Head of Information and Support Group >>>>> Oxford University Computing 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 >> >> PLEASE NOTE: postings to this list are publicly archived From kevin.s.hawkins at ultraslavonic.info Sat Feb 18 19:03:42 2012 From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins) Date: Sat, 18 Feb 2012 19:03:42 -0500 Subject: [tei-council] updated list of Council members etc. for P5 In-Reply-To: <3C89BE68-D1D3-4241-BC28-6013BBD16632@oucs.ox.ac.uk> References: <4F37DE51.4020509@ultraslavonic.info> <252F6DCE-AECF-453D-9B75-F118D5A8E138@oucs.ox.ac.uk> <4F37FDF8.5090800@retired.ox.ac.uk> <3C89BE68-D1D3-4241-BC28-6013BBD16632@oucs.ox.ac.uk> Message-ID: <4F403C5E.1030301@ultraslavonic.info> Okay, I've implemented most of this. Notes on remaining questions are in the ticket: http://purl.org/TEI/fr/3041605 From mholmes at uvic.ca Sat Feb 18 19:21:39 2012 From: mholmes at uvic.ca (Martin Holmes) Date: Sat, 18 Feb 2012 16:21:39 -0800 Subject: [tei-council] updated list of Council members etc. for P5 In-Reply-To: <4F403C5E.1030301@ultraslavonic.info> References: <4F37DE51.4020509@ultraslavonic.info> <252F6DCE-AECF-453D-9B75-F118D5A8E138@oucs.ox.ac.uk> <4F37FDF8.5090800@retired.ox.ac.uk> <3C89BE68-D1D3-4241-BC28-6013BBD16632@oucs.ox.ac.uk> <4F403C5E.1030301@ultraslavonic.info> Message-ID: <4F404093.5040708@uvic.ca> Does anyone think we really need a formal "personbase"? I've been trying to think of what sort of information might be worth collecting from people, and I can't think of much that would be useful without already being public and obvious (where people currently work and their terms on the Board or the Council), or raising privacy issues (DOB, qualifications, employment history etc.). Cheers, Martin On 12-02-18 04:03 PM, Kevin Hawkins wrote: > Okay, I've implemented most of this. Notes on remaining questions are > in the ticket: > > http://purl.org/TEI/fr/3041605 From syeates at gmail.com Sat Feb 18 22:07:30 2012 From: syeates at gmail.com (stuart yeates) Date: Sun, 19 Feb 2012 16:07:30 +1300 Subject: [tei-council] updated list of Council members etc. for P5 In-Reply-To: <4F404093.5040708@uvic.ca> References: <4F37DE51.4020509@ultraslavonic.info> <252F6DCE-AECF-453D-9B75-F118D5A8E138@oucs.ox.ac.uk> <4F37FDF8.5090800@retired.ox.ac.uk> <3C89BE68-D1D3-4241-BC28-6013BBD16632@oucs.ox.ac.uk> <4F403C5E.1030301@ultraslavonic.info> <4F404093.5040708@uvic.ca> Message-ID: <4F406772.2070608@gmail.com> On 19/02/12 13:21, Martin Holmes wrote: > Does anyone think we really need a formal "personbase"? I've been trying > to think of what sort of information might be worth collecting from > people, and I can't think of much that would be useful without already > being public and obvious (where people currently work and their terms on > the Board or the Council), or raising privacy issues (DOB, > qualifications, employment history etc.). As I understand it, an attribution-based copyright license requires tracking people who have made contributions. cheers stuart From mholmes at uvic.ca Sat Feb 18 23:30:35 2012 From: mholmes at uvic.ca (Martin Holmes) Date: Sat, 18 Feb 2012 20:30:35 -0800 Subject: [tei-council] updated list of Council members etc. for P5 In-Reply-To: <4F406772.2070608@gmail.com> References: <4F37DE51.4020509@ultraslavonic.info> <252F6DCE-AECF-453D-9B75-F118D5A8E138@oucs.ox.ac.uk> <4F37FDF8.5090800@retired.ox.ac.uk> <3C89BE68-D1D3-4241-BC28-6013BBD16632@oucs.ox.ac.uk> <4F403C5E.1030301@ultraslavonic.info> <4F404093.5040708@uvic.ca> <4F406772.2070608@gmail.com> Message-ID: <4F407AEB.6090200@uvic.ca> On 12-02-18 07:07 PM, stuart yeates wrote: > On 19/02/12 13:21, Martin Holmes wrote: >> Does anyone think we really need a formal "personbase"? I've been trying >> to think of what sort of information might be worth collecting from >> people, and I can't think of much that would be useful without already >> being public and obvious (where people currently work and their terms on >> the Board or the Council), or raising privacy issues (DOB, >> qualifications, employment history etc.). > > As I understand it, an attribution-based copyright license requires > tracking people who have made contributions. This caused me to go back to the original minutes and check the context in which we decided this was a good idea: <quote> 3041605: Update list of Council members. The Council agrees that the current list of members should be updated, and that a complete list of current and former Council members should be maintained and included in the Guidelines. KH will collect info from LB and elsewhere to create the list, and MH will then take over to create a more robust and formal collection of info based on a <listPerson> ; a template <person> can be sent out to TEI-L. LB reminds us about privacy concerns. </quote> I think the reason we decided to go with <listPerson> was simply so that we could include the list in the Guidelines in such a way that we could easily link to individuals through @xml:ids. So the question then becomes: what do we need to know about people? I had originally imagined something simple like this: <person role="teiCouncil"> <persName> <forename>Martin</forename> <surname>Holmes</surname> </persName> <affiliation>University of Victoria Humanities Computing and Media Centre</affiliation> </person> However, someone could have had multiple affiliations with different dates, and been on the Council for a couple of years and the Board for a year. So: <person> <persName> <forename>Martin</forename> <surname>Holmes</surname> </persName> <affiliation notBefore="1998">University of Victoria HCMC</affiliation> <affiliation role="council_elected" notBefore="2010">TEI</affiliation> </person> We should be able to devise a system in which it's possible to encode all the various configurations of service to the TEI (Council, Board, elected, appointed, committees, workgroups, etc.) in the affiliation/@role attribute (possibly with multiple TEI-related <affiliations>, if necessary); and then we should be able to generate at least some of the FM1 page automatically from the list; all we then have to do is make sure we keep the list up to date, and Council members at least can keep their own <person> entry updated in SF. Does this make sense? Is it worth the trouble? Cheers, Martin From sebastian.rahtz at oucs.ox.ac.uk Sun Feb 19 07:24:09 2012 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Sun, 19 Feb 2012 12:24:09 +0000 Subject: [tei-council] updated list of Council members etc. for P5 In-Reply-To: <4F406772.2070608@gmail.com> References: <4F37DE51.4020509@ultraslavonic.info> <252F6DCE-AECF-453D-9B75-F118D5A8E138@oucs.ox.ac.uk> <4F37FDF8.5090800@retired.ox.ac.uk> <3C89BE68-D1D3-4241-BC28-6013BBD16632@oucs.ox.ac.uk> <4F403C5E.1030301@ultraslavonic.info> <4F404093.5040708@uvic.ca> <4F406772.2070608@gmail.com> Message-ID: <E70FC133-D9A8-4710-A8D9-DFC1C9E10F27@oucs.ox.ac.uk> On 19 Feb 2012, at 03:07, stuart yeates wrote: > > As I understand it, an attribution-based copyright license requires > tracking people who have made contributions. > that is raising an interesting issue, over whether contributors to the TEI are retaining their own copyright, or giving it to the Consortium. My view has always been that we are all giving up our copyright, but not surprisingly that has never been enforced or documented. Back when we had editors who were (as it were) paid employees of the Consortium, it was probably clearer that the copyright belonged to the Consortium. of course, the membership of the Council is not the same as the role of committers to the TEI :-} If you wonder, by the way, who the committers are, this list might help: Brett Barney David Sewell Eve Radermacher Gabriel Bodard J-L Benoit James Cummings Kevin Hawkins Laurent Romary Lou Burnard Martin Holmes Perry Trolard Piotr Banski Sebastian Rahtz Stuart Yeates Syd Bauman -- Stormageddon Rahtz Head of Information and Support Group, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From sebastian.rahtz at oucs.ox.ac.uk Sun Feb 19 07:32:32 2012 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Sun, 19 Feb 2012 12:32:32 +0000 Subject: [tei-council] updated list of Council members etc. for P5 In-Reply-To: <4F407AEB.6090200@uvic.ca> References: <4F37DE51.4020509@ultraslavonic.info> <252F6DCE-AECF-453D-9B75-F118D5A8E138@oucs.ox.ac.uk> <4F37FDF8.5090800@retired.ox.ac.uk> <3C89BE68-D1D3-4241-BC28-6013BBD16632@oucs.ox.ac.uk> <4F403C5E.1030301@ultraslavonic.info> <4F404093.5040708@uvic.ca> <4F406772.2070608@gmail.com> <4F407AEB.6090200@uvic.ca> Message-ID: <E65B40B9-6802-46BF-8632-54A09A03967D@oucs.ox.ac.uk> On 19 Feb 2012, at 04:30, Martin Holmes wrote: > <person> > <persName> > <forename>Martin</forename> > <surname>Holmes</surname> > </persName> > <affiliation notBefore="1998">University of Victoria HCMC</affiliation> > <affiliation role="council_elected" notBefore="2010">TEI</affiliation> > </person> > I don't think this is too over the top, it should be possible to keep something as minimal as this up to date. -- Stormageddon Rahtz Head of Information and Support Group, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From sebastian.rahtz at oucs.ox.ac.uk Sun Feb 19 07:47:54 2012 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Sun, 19 Feb 2012 12:47:54 +0000 Subject: [tei-council] for 28 Feb. conf call: background on Best Practice for TEI in Libraries In-Reply-To: <4F40307E.6080807@ultraslavonic.info> References: <4F40307E.6080807@ultraslavonic.info> Message-ID: <EBB790FD-70DA-40F9-BFF0-7C84F3E173B9@oucs.ox.ac.uk> > > a) The encoding prescribed in the BP for Levels 1 and 2 is definitely > not TEI-conformant; I'm unsure about Levels 3 and 4. Not sure whether > this would disqualify it. > maybe you can give some background here. are levels 1 and 2 a) non-TEI deliberately, b) only non-TEI pending resolution of feature requests, or c) non-TEI by accident, pending some editorial work ? it would seem fairly weird for us to deliberately maintain customizations which are not TEI-conformant. -- Stormageddon Rahtz Head of Information and Support Group, Oxford University Computing Services 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 Feb 19 09:53:42 2012 From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins) Date: Sun, 19 Feb 2012 09:53:42 -0500 Subject: [tei-council] for 28 Feb. conf call: background on Best Practice for TEI in Libraries In-Reply-To: <EBB790FD-70DA-40F9-BFF0-7C84F3E173B9@oucs.ox.ac.uk> References: <4F40307E.6080807@ultraslavonic.info> <EBB790FD-70DA-40F9-BFF0-7C84F3E173B9@oucs.ox.ac.uk> Message-ID: <4F410CF6.4040804@ultraslavonic.info> The answer is mostly (a). But I misremembered the specifics from Syd and didn't think till now to consult the ODDs where Syd explains these things, so it turns out Level 2 might actually be conformant. But in both cases we're talking about conformance to the TEI's abtract model, not syntactic conformance. Level 1 is not conformant because <ab> is abused to include the OCR text of the entire document, not something at the level of a paragraph. Level 2 is possibly not conformant depending on whether you think the Guidelines say that encoding of <p>s is mandatory. On 2/19/12 7:47 AM, Sebastian Rahtz wrote: >> >> a) The encoding prescribed in the BP for Levels 1 and 2 is definitely >> not TEI-conformant; I'm unsure about Levels 3 and 4. Not sure whether >> this would disqualify it. >> > maybe you can give some background here. are levels 1 and 2 > > a) non-TEI deliberately, > b) only non-TEI pending resolution of feature requests, or > c) non-TEI by accident, pending some editorial work > ? > > it would seem fairly weird for us to deliberately maintain customizations which are > not TEI-conformant. > -- > Stormageddon Rahtz > Head of Information and Support Group, Oxford University Computing Services > 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 > > S?lo le pido a Dios > que el futuro no me sea indiferente > From sebastian.rahtz at oucs.ox.ac.uk Sun Feb 19 11:57:55 2012 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Sun, 19 Feb 2012 16:57:55 +0000 Subject: [tei-council] for 28 Feb. conf call: background on Best Practice for TEI in Libraries In-Reply-To: <4F410CF6.4040804@ultraslavonic.info> References: <4F40307E.6080807@ultraslavonic.info> <EBB790FD-70DA-40F9-BFF0-7C84F3E173B9@oucs.ox.ac.uk> <4F410CF6.4040804@ultraslavonic.info> Message-ID: <EBF08744-1474-4712-A41A-10D2DFF1042D@oucs.ox.ac.uk> On 19 Feb 2012, at 14:53, Kevin Hawkins wrote: > The answer is mostly (a) [ a) non-TEI deliberately ] So we'd end up with the TEI Consortium owning some customizations labelled "Best Practice" which contradicted its own Guidelines. That would be pretty weird! But seriously, isn't the question of whether the TEIC should take over maintenance of these BPs something the TEI Board should be debating, not the Council? obviously if the Board accepted the task then the Council could work out the technicalities. -- Stormageddon Rahtz Head of Information and Support Group, Oxford University Computing Services 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 19 15:15:19 2012 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Sun, 19 Feb 2012 20:15:19 +0000 Subject: [tei-council] for 28 Feb. conf call: background on Best Practice for TEI in Libraries In-Reply-To: <4F40307E.6080807@ultraslavonic.info> References: <4F40307E.6080807@ultraslavonic.info> Message-ID: <4F415857.6050601@oucs.ox.ac.uk> On 18/02/12 23:13, Kevin Hawkins wrote: > James has asked me to provide some background on the conf call agenda > items that I put forward so that we can focus on discussion rather than > providing background information during the call. For others on the list, the draft agenda is available at: http://wiki.tei-c.org/index.php/Council Specifically: http://wiki.tei-c.org/index.php/Council#Teleconference_-_Tuesday_28_February_2012_at_18:00_GMT -James -- Dr James Cummings, InfoDev Oxford University Computing Services University of Oxford From James.Cummings at oucs.ox.ac.uk Sun Feb 19 15:26:21 2012 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Sun, 19 Feb 2012 20:26:21 +0000 Subject: [tei-council] for 28 Feb. conf call: background on Best Practice for TEI in Libraries In-Reply-To: <EBF08744-1474-4712-A41A-10D2DFF1042D@oucs.ox.ac.uk> References: <4F40307E.6080807@ultraslavonic.info> <EBB790FD-70DA-40F9-BFF0-7C84F3E173B9@oucs.ox.ac.uk> <4F410CF6.4040804@ultraslavonic.info> <EBF08744-1474-4712-A41A-10D2DFF1042D@oucs.ox.ac.uk> Message-ID: <4F415AED.6000100@oucs.ox.ac.uk> On 19/02/12 16:57, Sebastian Rahtz wrote: > So we'd end up with the TEI Consortium owning some customizations > labelled "Best Practice" which contradicted its own Guidelines. That would > be pretty weird! It does strike me as weird as well, and I can understand why people might be confused as to how something can be 'non-Conformant' and 'Best Practice' at the same time. > But seriously, isn't the question of whether the TEIC should take over > maintenance of these BPs something the TEI Board > should be debating, not the Council? obviously if the Board > accepted the task then the Council could work out the technicalities. This is, if memory serves, what happened with TEI Tite (which would serve as an example of another non-conformant TEI extension which we at least provide as an exemplar if not have shared custody of). If the idea of the council maintaining this BP was presented to the Board, I would not feel I was doing my duty if I did not present the Council's position on this to the Board. (Nor would the Board correspondingly be doing their duty if they didn't ask for the technical perspective of the Council if substantial technical queries were raised.) In that case I would only have to return to the Council list in an attempt to get a consensus in any case. I think it is best if this goes to the Board that the Council position (if indeed we are able to agree on one) is already understood. If we aren't able to agree that this would be a good or bad thing, then equally the lack of consensus should be mentioned to the Board to inform their own discussions. -James -- Dr James Cummings, InfoDev Oxford University Computing Services University of Oxford From sebastian.rahtz at oucs.ox.ac.uk Sun Feb 19 18:02:29 2012 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Sun, 19 Feb 2012 23:02:29 +0000 Subject: [tei-council] for 28 Feb. conf call: background on Best Practice for TEI in Libraries In-Reply-To: <4F415AED.6000100@oucs.ox.ac.uk> References: <4F40307E.6080807@ultraslavonic.info> <EBB790FD-70DA-40F9-BFF0-7C84F3E173B9@oucs.ox.ac.uk> <4F410CF6.4040804@ultraslavonic.info> <EBF08744-1474-4712-A41A-10D2DFF1042D@oucs.ox.ac.uk> <4F415AED.6000100@oucs.ox.ac.uk> Message-ID: <1f2b0fcc-944d-46d7-ad1f-53ff54d886d8@HUB01.ad.oak.ox.ac.uk> On 19 Feb 2012, at 20:26, James Cummings wrote: > > If the idea of the council maintaining this BP was presented to > the Board, I would not feel I was doing my duty if I did not > present the Council's position on this to the Board. fair do's. Speaking for the implementation side of it, I think we need to bear in mind that the BPs are not Exemplars like most of what we have, so I suggest it would not make sense for them to show up in Roma, for example. Maybe we need to maintain a separate family of Canned Schemas, containing Lite and Tite at present, distinct from the Exemplars. It could be a useful exercise for that Sunday afternoon in Michigan for one of us to sit down and understand how the oXygen TEI framework is put together, so we can get the templates there better under our control. -- Stormageddon Rahtz Head of Information and Support Group, Oxford University Computing Services 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 20 12:16:38 2012 From: mholmes at uvic.ca (Martin Holmes) Date: Mon, 20 Feb 2012 09:16:38 -0800 Subject: [tei-council] updated list of Council members etc. for P5 In-Reply-To: <E65B40B9-6802-46BF-8632-54A09A03967D@oucs.ox.ac.uk> References: <4F37DE51.4020509@ultraslavonic.info> <252F6DCE-AECF-453D-9B75-F118D5A8E138@oucs.ox.ac.uk> <4F37FDF8.5090800@retired.ox.ac.uk> <3C89BE68-D1D3-4241-BC28-6013BBD16632@oucs.ox.ac.uk> <4F403C5E.1030301@ultraslavonic.info> <4F404093.5040708@uvic.ca> <4F406772.2070608@gmail.com> <4F407AEB.6090200@uvic.ca> <E65B40B9-6802-46BF-8632-54A09A03967D@oucs.ox.ac.uk> Message-ID: <4F427FF6.40309@uvic.ca> So the next stage is to figure out what all the roles are. We need to distinguish TEI <affiliations>s from other <affiliation>s, which could be done, as in my previous example, simply by having "TEI" as the text content of any <affiliation> tag. But that leaves only the @role attribute to distinguish all the different roles (since <affiliation> isn't a member of att.typed, for instance). However, <roleName> is also available as a child of <affiliation>, and it's a member of att.typed, so we could have: <affiliation role="tei"> <roleName type="council_member" subtype="elected"> </affiliation> This would enable us to find all TEI affiliations (affiliation/@role="tei"), all council members (roleName/@type) and the nature of the appointment (roleName/@subtype). The text content of <affiliation> could be used to provide a more detailed explanation of the person's role in human-readable form. We would presumably have the following types: council_member council_chair board_member board_chair board_representative (non-voting partner reps) board_treasurer board_secretary committer editor webmaster workgroup_chair workgroup_member sig_convener and the following subtypes: elected appointed Is there anything else to add? Cheers, Martin On 12-02-19 04:32 AM, Sebastian Rahtz wrote: > > On 19 Feb 2012, at 04:30, Martin Holmes wrote: > >> <person> >> <persName> >> <forename>Martin</forename> >> <surname>Holmes</surname> >> </persName> >> <affiliation notBefore="1998">University of Victoria HCMC</affiliation> >> <affiliation role="council_elected" notBefore="2010">TEI</affiliation> >> </person> >> > I don't think this is too over the top, it should be possible to keep something as minimal > as this up to date. > > -- > Stormageddon Rahtz > Head of Information and Support Group, Oxford University Computing Services > 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 > > S?lo le pido a Dios > que el futuro no me sea indiferente > > -- Martin Holmes University of Victoria Humanities Computing and Media Centre (mholmes at uvic.ca) From James.Cummings at oucs.ox.ac.uk Thu Feb 23 11:38:02 2012 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Thu, 23 Feb 2012 16:38:02 +0000 Subject: [tei-council] TEI Telco February 2012 Message-ID: <4F466B6A.5060107@oucs.ox.ac.uk> Hi all, For the teleconference on Tuesday 28 February at 18:00 GMT, we'll be dialling into a conferencing service run by economyconferencecall.com. This should allow you to dial in toll-free and is using an account set-up by John Unsworth that is being used for the Board as well and the TEI-C will pay for the toll-free calls. (Though the cost is per call so I'll try to convince Sebastian to share a conference phone with me.) I'm not entirely sure where all of you will be on Tuesday, so I've retrieved the toll free numbers for: US and Canada: 866-906-0040 France (excl. Monaco): 0-800-916-758 Germany: 0-800-182-0270 New Zealand: 0-800-446-259 Poland: 00-800-112-4271 (0.35 zloty charge) UK: 0-800-635-0541 Dial the appropriate number, and then enter the access code: 4614041 followed by the # button. You'll be asked to give your name. I'm told you can mute/unmute your line using *6 but have never tried it myself. I have a draft agenda at http://wiki.tei-c.org/index.php/Council Can I have a volunteer to take minutes? -James -- Dr James Cummings, InfoDev Oxford University Computing Services University of Oxford From mholmes at uvic.ca Thu Feb 23 12:47:05 2012 From: mholmes at uvic.ca (Martin Holmes) Date: Thu, 23 Feb 2012 09:47:05 -0800 Subject: [tei-council] TEI Telco February 2012 In-Reply-To: <4F466B6A.5060107@oucs.ox.ac.uk> References: <4F466B6A.5060107@oucs.ox.ac.uk> Message-ID: <4F467B99.2060400@uvic.ca> Is it OK to Skype into these numbers? It's easier to do things with headphones on than prop a phone against your shoulder. Cheers, Martin On 12-02-23 08:38 AM, James Cummings wrote: > Hi all, > > For the teleconference on Tuesday 28 February at 18:00 GMT, we'll > be dialling into a conferencing service run by > economyconferencecall.com. This should allow you to dial in > toll-free and is using an account set-up by John Unsworth that is > being used for the Board as well and the TEI-C will pay for the > toll-free calls. (Though the cost is per call so I'll try to > convince Sebastian to share a conference phone with me.) > > I'm not entirely sure where all of you will be on Tuesday, so > I've retrieved the toll free numbers for: > > US and Canada: 866-906-0040 > France (excl. Monaco): 0-800-916-758 > Germany: 0-800-182-0270 > New Zealand: 0-800-446-259 > Poland: 00-800-112-4271 (0.35 zloty charge) > UK: 0-800-635-0541 > > Dial the appropriate number, and then enter the access code: > 4614041 followed by the # button. You'll be asked to give your > name. I'm told you can mute/unmute your line using *6 but have > never tried it myself. > > I have a draft agenda at http://wiki.tei-c.org/index.php/Council > > Can I have a volunteer to take minutes? > > -James > -- Martin Holmes University of Victoria Humanities Computing and Media Centre (mholmes at uvic.ca) From bansp at o2.pl Thu Feb 23 19:07:23 2012 From: bansp at o2.pl (=?ISO-8859-2?Q?Piotr_Ba=F1ski?=) Date: Fri, 24 Feb 2012 01:07:23 +0100 Subject: [tei-council] TEI Telco February 2012 In-Reply-To: <4F466B6A.5060107@oucs.ox.ac.uk> References: <4F466B6A.5060107@oucs.ox.ac.uk> Message-ID: <4F46D4BB.4010604@o2.pl> Hi James, So toll-free is not free but funded by TEI-C? I was wondering: why not just skype -- it's worked for conference organisation and lots of other meetings. Or are skype conferences non-free as well? There is a web service that some projects have used, and that is free for sure, but I think one has to reserve the time for more intensive telcos; it has video (yay) and it saves the conferences so that they can be replayed later. Would that be in any way interesting as an alternative, or not really? Not sure if I should research that. So long, P. On 23/02/12 17:38, James Cummings wrote: > Hi all, > > For the teleconference on Tuesday 28 February at 18:00 GMT, we'll > be dialling into a conferencing service run by > economyconferencecall.com. This should allow you to dial in > toll-free and is using an account set-up by John Unsworth that is > being used for the Board as well and the TEI-C will pay for the > toll-free calls. (Though the cost is per call so I'll try to > convince Sebastian to share a conference phone with me.) > > I'm not entirely sure where all of you will be on Tuesday, so > I've retrieved the toll free numbers for: > > US and Canada: 866-906-0040 > France (excl. Monaco): 0-800-916-758 > Germany: 0-800-182-0270 > New Zealand: 0-800-446-259 > Poland: 00-800-112-4271 (0.35 zloty charge) > UK: 0-800-635-0541 > > Dial the appropriate number, and then enter the access code: > 4614041 followed by the # button. You'll be asked to give your > name. I'm told you can mute/unmute your line using *6 but have > never tried it myself. > > I have a draft agenda at http://wiki.tei-c.org/index.php/Council > > Can I have a volunteer to take minutes? > > -James > From kevin.s.hawkins at ultraslavonic.info Thu Feb 23 20:04:58 2012 From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins) Date: Thu, 23 Feb 2012 20:04:58 -0500 Subject: [tei-council] P5 releases: changes to boilerplate HTML code Message-ID: <4F46E23A.2030509@ultraslavonic.info> I recall that when a new release of the TEI is made, all of the stuff at the top of each HTML page -- the TEI logo, the navbar, the search box, and the phrase "P5: Guidelines for Electronic Text Encoding and Interchange" -- is inserted at time of compilation. Somewhere there is a file that stores the bits of HTML code needed for this. Related to that, a few things: a) This code is in need of updating: the menu options have not kept up with things being used on the TEI website. b) We should note the location of the code in tcw22 and make a note to compare against what's currently in use on the TEI website and adjust as necessary. c) Currently the P5 version number is in fine print at the bottom of the page, along with the last updated information. To a casual visitor, this looks like a version number for the particular HTML file, not the full guidelines. Furthermore, a casual visitor is unlikely to ever see this. Therefore, I'd like to request that we modify the code to insert the current version number somewhere near "P5: Guidelines for Electronic Text Encoding and Interchange". Right now there's no straightforward way for someone to know that there are versions of P5 and to know which they are looking at, and I think this would make it obvious that the Guidelines are in fact under constant evolution. --Kevin From bansp at o2.pl Fri Feb 24 04:13:06 2012 From: bansp at o2.pl (=?ISO-8859-2?Q?Piotr_Ba=F1ski?=) Date: Fri, 24 Feb 2012 10:13:06 +0100 Subject: [tei-council] TEI Telco February 2012 In-Reply-To: <4F46D4BB.4010604@o2.pl> References: <4F466B6A.5060107@oucs.ox.ac.uk> <4F46D4BB.4010604@o2.pl> Message-ID: <4F4754A2.3020909@o2.pl> Here's the URL, for the record. I know that various projects have had regular meetings via this system. http://fm.ea-tel.eu/help.html From James.Cummings at oucs.ox.ac.uk Fri Feb 24 05:48:27 2012 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Fri, 24 Feb 2012 10:48:27 +0000 Subject: [tei-council] TEI ODD meeting after DH2012 Message-ID: <4F476AFB.5040700@oucs.ox.ac.uk> Dear Council, Good news that our panel on TEI ODD was accepted at DH2012. As you know it is my suggestion that we organise a working meeting immediately after the conference (the Saturday/Sunday) and that the TEI-C would provide money towards a couple extra nights of hotel for those speakers who need it. Depending on whether there are costs for rental of the room, and how many of them need a couple nights extra hotel, we might also be able to invite specific other people to stay on after the conference (e.g. from the council) and contribute to a couple night's hotel for them. (Food will not be covered.) Since I know people book flights and accommodation quickly, I want move as swiftly as possible on this. If you are attending DH anyway, could you let me know: a) whether you are want to and are able to attend the sat/sun meeting? (if so, make your travel plans accordingly) b) whether you need whatever flat rate I can get out of the TEI-C for one or two nights? c) suggestions of other people to invite (potentially paying their hotel a well) When I have an idea of the figures I'll be approaching the Board with the more detailed budget for this event. Many thanks, -James -- Dr James Cummings, InfoDev, Computing Services, University of Oxford From James.Cummings at oucs.ox.ac.uk Fri Feb 24 06:38:46 2012 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Fri, 24 Feb 2012 11:38:46 +0000 Subject: [tei-council] TEI Telco February 2012 In-Reply-To: <4F467B99.2060400@uvic.ca> References: <4F466B6A.5060107@oucs.ox.ac.uk> <4F467B99.2060400@uvic.ca> Message-ID: <4F4776C6.4000705@oucs.ox.ac.uk> On 23/02/12 17:47, Martin Holmes wrote: > Is it OK to Skype into these numbers? It's easier to do things with > headphones on than prop a phone against your shoulder. I believe this may work. Go ahead and phone the number to test (just don't put in the conference ID when prompted...) -James > > Cheers, > Martin > > On 12-02-23 08:38 AM, James Cummings wrote: >> Hi all, >> >> For the teleconference on Tuesday 28 February at 18:00 GMT, we'll >> be dialling into a conferencing service run by >> economyconferencecall.com. This should allow you to dial in >> toll-free and is using an account set-up by John Unsworth that is >> being used for the Board as well and the TEI-C will pay for the >> toll-free calls. (Though the cost is per call so I'll try to >> convince Sebastian to share a conference phone with me.) >> >> I'm not entirely sure where all of you will be on Tuesday, so >> I've retrieved the toll free numbers for: >> >> US and Canada: 866-906-0040 >> France (excl. Monaco): 0-800-916-758 >> Germany: 0-800-182-0270 >> New Zealand: 0-800-446-259 >> Poland: 00-800-112-4271 (0.35 zloty charge) >> UK: 0-800-635-0541 >> >> Dial the appropriate number, and then enter the access code: >> 4614041 followed by the # button. You'll be asked to give your >> name. I'm told you can mute/unmute your line using *6 but have >> never tried it myself. >> >> I have a draft agenda at http://wiki.tei-c.org/index.php/Council >> >> Can I have a volunteer to take minutes? >> >> -James >> > -- Dr James Cummings, InfoDev, Computing Services, University of Oxford From James.Cummings at oucs.ox.ac.uk Fri Feb 24 06:51:38 2012 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Fri, 24 Feb 2012 11:51:38 +0000 Subject: [tei-council] TEI Telco February 2012 In-Reply-To: <4F46D4BB.4010604@o2.pl> References: <4F466B6A.5060107@oucs.ox.ac.uk> <4F46D4BB.4010604@o2.pl> Message-ID: <4F4779CA.1090700@oucs.ox.ac.uk> On 24/02/12 00:07, Piotr Ba?ski wrote: > Hi James, > > So toll-free is not free but funded by TEI-C? I was wondering: why not > just skype -- it's worked for conference organisation and lots of other > meetings. Or are skype conferences non-free as well? If skype conversations are all held by people are a computer they are free. However, in the past it has often been found that the quality of the call seems to degrade depending on very unpredictable conditions. (e.g. the local bandwidth, individuals computers, whether they mute themselves etc.) While all of this is also true with non-skype teleconferences, it seems less frequent. The board used this service for a teleconference recently (minutes here http://www.tei-c.org/Board/bm44.xml) and it seemed to go smoothly. The costs are not great, the Board meeting of about an hour cost "$113.49 (about $21 of which is taxes)" according to JohnU. So for simplicity I suggest we try this for parallel with the Board. If it turns out to not work, or be much more expensive, then we can look at other options. With this system it is _possible_ to record the conversation, I'm told, but I don't know if this incurs additional charges. The idea of being able to record them to then write up minutes afterwards is attractive though. Speaking of which, I have yet to have any volunteers to take minutes during the conference call. I don't want to pick someone at random (but will)...how about I say that if you do the minutes this time, I won't make you do them next time? -James > There is a web service that some projects have used, and that is free > for sure, but I think one has to reserve the time for more intensive > telcos; it has video (yay) and it saves the conferences so that they can > be replayed later. > > Would that be in any way interesting as an alternative, or not really? > Not sure if I should research that. > > So long, > > P. > > On 23/02/12 17:38, James Cummings wrote: >> Hi all, >> >> For the teleconference on Tuesday 28 February at 18:00 GMT, we'll >> be dialling into a conferencing service run by >> economyconferencecall.com. This should allow you to dial in >> toll-free and is using an account set-up by John Unsworth that is >> being used for the Board as well and the TEI-C will pay for the >> toll-free calls. (Though the cost is per call so I'll try to >> convince Sebastian to share a conference phone with me.) >> >> I'm not entirely sure where all of you will be on Tuesday, so >> I've retrieved the toll free numbers for: >> >> US and Canada: 866-906-0040 >> France (excl. Monaco): 0-800-916-758 >> Germany: 0-800-182-0270 >> New Zealand: 0-800-446-259 >> Poland: 00-800-112-4271 (0.35 zloty charge) >> UK: 0-800-635-0541 >> >> Dial the appropriate number, and then enter the access code: >> 4614041 followed by the # button. You'll be asked to give your >> name. I'm told you can mute/unmute your line using *6 but have >> never tried it myself. >> >> I have a draft agenda at http://wiki.tei-c.org/index.php/Council >> >> Can I have a volunteer to take minutes? >> >> -James >> > -- Dr James Cummings, InfoDev, Computing Services, University of Oxford From James.Cummings at oucs.ox.ac.uk Fri Feb 24 06:53:02 2012 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Fri, 24 Feb 2012 11:53:02 +0000 Subject: [tei-council] TEI Telco February 2012 In-Reply-To: <4F4779CA.1090700@oucs.ox.ac.uk> References: <4F466B6A.5060107@oucs.ox.ac.uk> <4F46D4BB.4010604@o2.pl> <4F4779CA.1090700@oucs.ox.ac.uk> Message-ID: <4F477A1E.6010006@oucs.ox.ac.uk> On 24/02/12 11:51, James Cummings wrote: > If skype conversations are all held by people are a computer they > are free. However, in the past it has often been found that the s/are a computer/who are on a computer/ *sigh* -James -- Dr James Cummings, InfoDev, Computing Services, University of Oxford From mholmes at uvic.ca Fri Feb 24 08:29:32 2012 From: mholmes at uvic.ca (Martin Holmes) Date: Fri, 24 Feb 2012 05:29:32 -0800 Subject: [tei-council] Glines problem with model.persStateLike Message-ID: <4F4790BC.5090809@uvic.ca> Hi all, Jens has submitted another detailed list of Guidelines problems which I'm working through: http://purl.org/TEI/BUGS/3492947 One refers to this section: <http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ND.html#NDPERSEpc> The list of elements which are supposed to be members of model.persStateLike appears to be incorrect: <state> and <trait> are missing, although they are both discussed later. I think they should be added to the list. <langKnown> appears not to be a member of model.persStateLike, and as far as I can tell from SVN, never has been. It's a child of <langKnowledge>, which is a member. Its inclusion in the list is therefore a bit misleading. It is discussed as part of the discussion of <langKnowledge>, its parent. Therefore I propose removing <langKnown> and adding <state> and <trait> to the list. Any objections? Cheers, Martin From James.Cummings at oucs.ox.ac.uk Fri Feb 24 10:27:47 2012 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Fri, 24 Feb 2012 15:27:47 +0000 Subject: [tei-council] Glines problem with model.persStateLike In-Reply-To: <4F4790BC.5090809@uvic.ca> References: <4F4790BC.5090809@uvic.ca> Message-ID: <4F47AC73.7030707@oucs.ox.ac.uk> On 24/02/12 13:29, Martin Holmes wrote: > <http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ND.html#NDPERSEpc> > > The list of elements which are supposed to be members of > model.persStateLike appears to be incorrect: > > <state> and<trait> are missing, although they are both discussed later. > I think they should be added to the list. Yes, this is probably an omission on my part from the rationalisation of state and trait to make state the default from a previous ticket. > Therefore I propose removing<langKnown> and adding<state> and<trait> > to the list. Any objections? <langKnown> needs to be mentioned at some point near there because it is a child element of <langKnowledge>, as seen in the examples just a bit down. -James -- Dr James Cummings, InfoDev, Computing Services, University of Oxford From mholmes at uvic.ca Fri Feb 24 11:02:44 2012 From: mholmes at uvic.ca (Martin Holmes) Date: Fri, 24 Feb 2012 08:02:44 -0800 Subject: [tei-council] Glines problem with model.persStateLike In-Reply-To: <4F47AC73.7030707@oucs.ox.ac.uk> References: <4F4790BC.5090809@uvic.ca> <4F47AC73.7030707@oucs.ox.ac.uk> Message-ID: <4F47B4A4.1060407@uvic.ca> OK, that's done: <langKnown> commented out, and <state> and <trait> added. <langKnown> is discussed in the context of <langKnowledge>, so it's in the text, but it's not true to say it's a member of model.persStateLike. Cheers, Martin On 12-02-24 07:27 AM, James Cummings wrote: > On 24/02/12 13:29, Martin Holmes wrote: >> <http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ND.html#NDPERSEpc> >> >> The list of elements which are supposed to be members of >> model.persStateLike appears to be incorrect: >> >> <state> and<trait> are missing, although they are both discussed later. >> I think they should be added to the list. > > Yes, this is probably an omission on my part from the > rationalisation of state and trait to make state the default from > a previous ticket. > > >> Therefore I propose removing<langKnown> and adding<state> and<trait> >> to the list. Any objections? > > <langKnown> needs to be mentioned at some point near there > because it is a child element of<langKnowledge>, as seen in the > examples just a bit down. > > -James > > -- Martin Holmes University of Victoria Humanities Computing and Media Centre (mholmes at uvic.ca) From lou.burnard at retired.ox.ac.uk Fri Feb 24 13:34:37 2012 From: lou.burnard at retired.ox.ac.uk (Lou Burnard) Date: Fri, 24 Feb 2012 18:34:37 +0000 Subject: [tei-council] unmarked for gender Message-ID: <4F47D83D.7050404@retired.ox.ac.uk> Martin writes in response to a recent sf ticket (3492947) > "and the encoder" => "and encoders" (cf. "their" below). > This is a use of "their" for a 3rd-person singular unmarked for gender > (instead of "his/her", which is felt to be ungainly). I think this is > now probably acceptable in formal written English. Maybe someone would like to record in our stylistic guidelines that this usage is not just "probably acceptable" but actually our preferred practice? Certainly it's mine! From mholmes at uvic.ca Fri Feb 24 13:44:08 2012 From: mholmes at uvic.ca (Martin Holmes) Date: Fri, 24 Feb 2012 10:44:08 -0800 Subject: [tei-council] unmarked for gender In-Reply-To: <4F47D83D.7050404@retired.ox.ac.uk> References: <4F47D83D.7050404@retired.ox.ac.uk> Message-ID: <4F47DA78.1080601@uvic.ca> Done. I've added a new section to the "Editing the Guidelines" document: <http://www.tei-c.org/Activities/Council/Working/tcw20.xml#house-style-usage> called "House style: notes on usage". We can use this to collect together snippets and preferences like this, until we reach a point where we create a formal style guide. Cheers, Martin On 12-02-24 10:34 AM, Lou Burnard wrote: > Martin writes in response to a recent sf ticket (3492947) > > > "and the encoder" => "and encoders" (cf. "their" below). > > This is a use of "their" for a 3rd-person singular unmarked for gender > > (instead of "his/her", which is felt to be ungainly). I think this is > > now probably acceptable in formal written English. > > Maybe someone would like to record in our stylistic guidelines that this > usage is not just "probably acceptable" but actually our preferred > practice? Certainly it's mine! > > > > -- Martin Holmes University of Victoria Humanities Computing and Media Centre (mholmes at uvic.ca) From mholmes at uvic.ca Sat Feb 25 13:18:17 2012 From: mholmes at uvic.ca (Martin Holmes) Date: Sat, 25 Feb 2012 10:18:17 -0800 Subject: [tei-council] Standardi[s|z]ation Message-ID: <4F4925E9.8020105@uvic.ca> Hi all, One of Jens's excellent proofing reports suggests that we standardize spellings ending in -ise/-ize. I'm inclined to agree, and with -ise looking a bit beleaguered these days, I think it should be -ize. Lou agrees, on the ticket. So I ran this regex to see what we have: is((e[d|s]*)|(ing))\b It found 1529 instances, most of which aren't relevant ("otherwise", "raise" etc.). But amongst those which are, they don't all seem clear cut to me, though. I think these are uncontroversial: standardise normalise capitalise specialise summarise computerise italicise recognise regularise categorise But what about these? I feel instinctively less happy with changing these to z, for some reason: harmonise compromise analyse exercise utilise and I think these cannot be changed to z, even though, in many cases, variants with z are attested: comprise revise devise advise excise So what do your instincts tell you about these? Should we basically make a list of words which should use z, and put it in our style guide? Making the changes will be a significant job, because there are instances of similar words in French that mustn't be changed ("utilise", for instance). I think it'll best be done with XSLT (which can be language-aware, and ignore the French) and some very precise regexes. Cheers, Martin From lou.burnard at retired.ox.ac.uk Sat Feb 25 13:42:52 2012 From: lou.burnard at retired.ox.ac.uk (Lou Burnard) Date: Sat, 25 Feb 2012 18:42:52 +0000 Subject: [tei-council] Standardi[s|z]ation In-Reply-To: <4F4925E9.8020105@uvic.ca> References: <4F4925E9.8020105@uvic.ca> Message-ID: <4F492BAC.2080904@retired.ox.ac.uk> Michael Quinnion is good on this, (as on many other things) http://www.worldwidewords.org/qa/qa-ise1.htm The -IZE suffix only applize to words which (etymologically speaking) come to use from a Latinized version of a Greek suffix. That's the rationale given by the OED anyway. I don't think we should be guided by "instinct" here. Look em up. On 25/02/12 18:18, Martin Holmes wrote: > Hi all, > > One of Jens's excellent proofing reports suggests that we standardize > spellings ending in -ise/-ize. I'm inclined to agree, and with -ise > looking a bit beleaguered these days, I think it should be -ize. Lou > agrees, on the ticket. > > So I ran this regex to see what we have: > > is((e[d|s]*)|(ing))\b > > It found 1529 instances, most of which aren't relevant ("otherwise", > "raise" etc.). But amongst those which are, they don't all seem clear > cut to me, though. I think these are uncontroversial: > > standardise > normalise > capitalise > specialise > summarise > computerise > italicise > recognise > regularise > categorise > > But what about these? I feel instinctively less happy with changing > these to z, for some reason: > > harmonise > compromise > analyse > exercise > utilise > > and I think these cannot be changed to z, even though, in many cases, > variants with z are attested: > > comprise > revise > devise > advise > excise > > So what do your instincts tell you about these? Should we basically make > a list of words which should use z, and put it in our style guide? > > Making the changes will be a significant job, because there are > instances of similar words in French that mustn't be changed ("utilise", > for instance). I think it'll best be done with XSLT (which can be > language-aware, and ignore the French) and some very precise regexes. > > Cheers, > Martin From kevin.s.hawkins at ultraslavonic.info Sat Feb 25 19:12:40 2012 From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins) Date: Sat, 25 Feb 2012 19:12:40 -0500 Subject: [tei-council] some brief reports to save time during our upcoming conf call Message-ID: <4F4978F8.205@ultraslavonic.info> Gang, This is the second of two promised emails. This one gives summaries of a couple of activities I've been involved in -- all on the agenda under "brief reports". I'm sending these in advance so that we can use the time during our call for discussion of these. = Bibliographic Citations = Martin Holmes, Laurent Romary, and I (a.k.a. "the biblio gang") have been trying to clarify the Guidelines in matters relating to bibliographic citations. Some clarifying copyedits were made after the Dublin meeting, and tickets were created on the substantial changes. Those tickets have all been discussed and resolved by Council except one: bug 2714682, in which we are wrestling with four related issues: a) whether biblScope should have different semantics depending on its parent element b) whether the Guidelines should be more explicit on whether to use biblScope as a child of <imprint> and what it means if it is a child of <imprint> c) whether to add <biblScope> as an allowed child of <analytic> d) whether we should distinguish between two types of page ranges: those pages cited, and the whole range of the item The three of us are currently discussing these questions by email and are converging on a proposed solution, which we will post to the ticket and bring back to the Council for consideration. = TEI Tite = In September 2010, Laurent appointed me, Greg Suprock (of Apex CoVantage), and Perry Trolard (author of Tite) to a workgroup to realign the version of Tite used by Apex CoVantage with the canonical version maintained in SourceForge and to oversee ongoing evolution of Tite. Since Apex only maintains a DTD, changes that they made had to be recreated in the master ODD in SourceForge. I believe I've reconciled everything, but I have not yet made the time to generate a DTD from the latest ODD and check for discrepancies with Apex's version. This will be complicated by the fact that any changes to P5 since Apex first created their DTD may filter through when I create a DTD using Roma. Next up will be taking up various bugs and feature requests related to Tite in SourceForge. These changes would need to be made not only in the Tite ODD but also communicated to Apex so that they begin using them in their encoding. = Google Books = In September 2011, Laurent charged James Cummings, Martin Holmes, me, and himself with providing guidance to an engineer from Google who is working on adding TEI as an export format for Google Books. We've been in occasional contact with the engineer, who produced some sample documents and asked for feedback. In addition to our feedback, he used a schema for Level 3 of the Best Practices for TEI in Libraries in order to check his output (though mixing in Level-4 elements when has the data to do so) and was in contact with the Google Books Library Partners about how useful the TEI output would be. He reported earlier this month that "The code has been reviewed and checked in but we're still working on some questions related to integrating the code in our production pipeline." He said he might come back for help as they get closer to deploying and encouraged us to check back in. The importance of this for the TEI's PR can't really be understated. We, or the Board, might want to give some thought about whether to do anything more once Google deloys this code than simply announce it on TEI-L with shouts of hurrah/hooray/huzzah. = Physical Bibliography = While in Paris, we dealt with a feature request to handle encoding of a printer, distributor, etc. This led someone to suggest we revive the Physical Bibliography Work Group, which never completed its work. Some of its recommendations were included in the manuscript description module, but other parts were never fully resolved. We decided that I would ask Paul Schaffner and Markus Flatscher if they would be willing to revive this group. I never heard back from either of them. However, at the 2011 HASTAC conference, one panel included some papers from grad students on physical bibliography, which included discussion of the inadequacies of TEI markup in that area. In short: if you want to physical/descriptive bibliography of printed books, the elements you need are children of msDesc, but the description of this element and its children refer to handwritten manuscripts only. I spoke to the presenters afterwards and asked take over the group with guidance from me. They were quite enthusiastic but have since decided that they don't have the time to lead the effort but would still like to participate. They shared their papers with me. Coincidentally, Sebastiaan Verweij posted to TEI-L in late January with very similar concerns to those of the HASTAC presenters. I've never met Sebastiaan at all, but if Council thinks it's appropriate, I'd like to approach him to ask him to lead the revival of the Physical Bibliography Work Group (with input from the HASTAC presenters and guidance from me and anyone else interested in participating). --Kevin From lou.burnard at retired.ox.ac.uk Sun Feb 26 09:34:12 2012 From: lou.burnard at retired.ox.ac.uk (Lou Burnard) Date: Sun, 26 Feb 2012 14:34:12 +0000 Subject: [tei-council] Standardi[s|z]ation In-Reply-To: <4F492BAC.2080904@retired.ox.ac.uk> References: <4F4925E9.8020105@uvic.ca> <4F492BAC.2080904@retired.ox.ac.uk> Message-ID: <4F4A42E4.9050203@retired.ox.ac.uk> Further to my rather cryptic comment below: my recommendation is a) look up the word in the OED b) if it says that both -IZE and -ISE forms are usable, use the -IZE form. c) otherwise use the -ISE form. n 25/02/12 18:42, Lou Burnard wrote: > Michael Quinnion is good on this, (as on many other things) > > http://www.worldwidewords.org/qa/qa-ise1.htm > > The -IZE suffix only applize to words which (etymologically speaking) > come to use from a Latinized version of a Greek suffix. That's the > rationale given by the OED anyway. > > I don't think we should be guided by "instinct" here. Look em up. > > > On 25/02/12 18:18, Martin Holmes wrote: >> Hi all, >> >> One of Jens's excellent proofing reports suggests that we standardize >> spellings ending in -ise/-ize. I'm inclined to agree, and with -ise >> looking a bit beleaguered these days, I think it should be -ize. Lou >> agrees, on the ticket. >> >> So I ran this regex to see what we have: >> >> is((e[d|s]*)|(ing))\b >> >> It found 1529 instances, most of which aren't relevant ("otherwise", >> "raise" etc.). But amongst those which are, they don't all seem clear >> cut to me, though. I think these are uncontroversial: >> >> standardise >> normalise >> capitalise >> specialise >> summarise >> computerise >> italicise >> recognise >> regularise >> categorise >> >> But what about these? I feel instinctively less happy with changing >> these to z, for some reason: >> >> harmonise >> compromise >> analyse >> exercise >> utilise >> >> and I think these cannot be changed to z, even though, in many cases, >> variants with z are attested: >> >> comprise >> revise >> devise >> advise >> excise >> >> So what do your instincts tell you about these? Should we basically make >> a list of words which should use z, and put it in our style guide? >> >> Making the changes will be a significant job, because there are >> instances of similar words in French that mustn't be changed ("utilise", >> for instance). I think it'll best be done with XSLT (which can be >> language-aware, and ignore the French) and some very precise regexes. >> >> Cheers, >> Martin > From kevin.s.hawkins at ultraslavonic.info Sun Feb 26 09:50:27 2012 From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins) Date: Sun, 26 Feb 2012 09:50:27 -0500 Subject: [tei-council] Standardi[s|z]ation In-Reply-To: <4F4A42E4.9050203@retired.ox.ac.uk> References: <4F4925E9.8020105@uvic.ca> <4F492BAC.2080904@retired.ox.ac.uk> <4F4A42E4.9050203@retired.ox.ac.uk> Message-ID: <4F4A46B3.9010508@ultraslavonic.info> This seems like good policy to add to http://www.tei-c.org/Activities/Council/Working/tcw20.xml#house-style-orthography and I think also to P5/Source/Guidelines/en/style-guide.txt . It continues to bother me that we repeat information in these two documents, which could easily fall out of sync. I would suggest having one point to the other, but I'm not sure which should be primary. Thoughts? On 2/26/12 9:34 AM, Lou Burnard wrote: > Further to my rather cryptic comment below: my recommendation is > > a) look up the word in the OED > b) if it says that both -IZE and -ISE forms are usable, use the -IZE form. > c) otherwise use the -ISE form. > > > n 25/02/12 18:42, Lou Burnard wrote: >> Michael Quinnion is good on this, (as on many other things) >> >> http://www.worldwidewords.org/qa/qa-ise1.htm >> >> The -IZE suffix only applize to words which (etymologically speaking) >> come to use from a Latinized version of a Greek suffix. That's the >> rationale given by the OED anyway. >> >> I don't think we should be guided by "instinct" here. Look em up. >> >> >> On 25/02/12 18:18, Martin Holmes wrote: >>> Hi all, >>> >>> One of Jens's excellent proofing reports suggests that we standardize >>> spellings ending in -ise/-ize. I'm inclined to agree, and with -ise >>> looking a bit beleaguered these days, I think it should be -ize. Lou >>> agrees, on the ticket. >>> >>> So I ran this regex to see what we have: >>> >>> is((e[d|s]*)|(ing))\b >>> >>> It found 1529 instances, most of which aren't relevant ("otherwise", >>> "raise" etc.). But amongst those which are, they don't all seem clear >>> cut to me, though. I think these are uncontroversial: >>> >>> standardise >>> normalise >>> capitalise >>> specialise >>> summarise >>> computerise >>> italicise >>> recognise >>> regularise >>> categorise >>> >>> But what about these? I feel instinctively less happy with changing >>> these to z, for some reason: >>> >>> harmonise >>> compromise >>> analyse >>> exercise >>> utilise >>> >>> and I think these cannot be changed to z, even though, in many cases, >>> variants with z are attested: >>> >>> comprise >>> revise >>> devise >>> advise >>> excise >>> >>> So what do your instincts tell you about these? Should we basically make >>> a list of words which should use z, and put it in our style guide? >>> >>> Making the changes will be a significant job, because there are >>> instances of similar words in French that mustn't be changed ("utilise", >>> for instance). I think it'll best be done with XSLT (which can be >>> language-aware, and ignore the French) and some very precise regexes. >>> >>> Cheers, >>> Martin >> > From kevin.s.hawkins at ultraslavonic.info Sun Feb 26 11:41:11 2012 From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins) Date: Sun, 26 Feb 2012 11:41:11 -0500 Subject: [tei-council] P5 releases: changes to boilerplate HTML code In-Reply-To: <4F46E23A.2030509@ultraslavonic.info> References: <4F46E23A.2030509@ultraslavonic.info> Message-ID: <4F4A60A7.1050809@ultraslavonic.info> One more suggestion: d) In the "Declaration" section of each element definition, there's an HTML button that says "Compact to XML format". If you click on it, the button label changes to say "XML format to compact". These labels are confusing, so I'd like to suggest changing as follows: "Compact to XML format" --> "Switch to XML format" XML format to compact" --> "Switch to compact format" On 2/23/12 8:04 PM, Kevin Hawkins wrote: > I recall that when a new release of the TEI is made, all of the stuff at > the top of each HTML page -- the TEI logo, the navbar, the search box, > and the phrase "P5: Guidelines for Electronic Text Encoding and > Interchange" -- is inserted at time of compilation. Somewhere there is a > file that stores the bits of HTML code needed for this. > > Related to that, a few things: > > a) This code is in need of updating: the menu options have not kept up > with things being used on the TEI website. > > b) We should note the location of the code in tcw22 and make a note to > compare against what's currently in use on the TEI website and adjust as > necessary. > > c) Currently the P5 version number is in fine print at the bottom of the > page, along with the last updated information. To a casual visitor, this > looks like a version number for the particular HTML file, not the full > guidelines. Furthermore, a casual visitor is unlikely to ever see this. > Therefore, I'd like to request that we modify the code to insert the > current version number somewhere near "P5: Guidelines for Electronic > Text Encoding and Interchange". Right now there's no straightforward way > for someone to know that there are versions of P5 and to know which they > are looking at, and I think this would make it obvious that the > Guidelines are in fact under constant evolution. > > --Kevin From sebastian.rahtz at oucs.ox.ac.uk Sun Feb 26 12:21:41 2012 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Sun, 26 Feb 2012 17:21:41 +0000 Subject: [tei-council] P5 releases: changes to boilerplate HTML code In-Reply-To: <4F4A60A7.1050809@ultraslavonic.info> References: <4F46E23A.2030509@ultraslavonic.info> <4F4A60A7.1050809@ultraslavonic.info> Message-ID: <4201B678-EDB6-46F3-9E4D-2E746FFEBB58@oucs.ox.ac.uk> On 26 Feb 2012, at 16:41, Kevin Hawkins wrote: > One more suggestion: > > d) In the "Declaration" section of each element definition, there's an > HTML button that says "Compact to XML format". If you click on it, the > button label changes to say "XML format to compact". These labels are > confusing, so I'd like to suggest changing as follows: > > "Compact to XML format" --> "Switch to XML format" > > XML format to compact" --> "Switch to compact format" This is easier than it sounds. We'd have to get re-translations of the phrase for each language. I don't mind, but whats the evidence that the existing words are confusing? its not been questioned in the ?6-7 years we've had the facility. -- Stormageddon Rahtz Head of Information and Support Group, Oxford University Computing Services 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 26 12:30:58 2012 From: mholmes at uvic.ca (Martin Holmes) Date: Sun, 26 Feb 2012 09:30:58 -0800 Subject: [tei-council] Standardi[s|z]ation In-Reply-To: <4F4A46B3.9010508@ultraslavonic.info> References: <4F4925E9.8020105@uvic.ca> <4F492BAC.2080904@retired.ox.ac.uk> <4F4A42E4.9050203@retired.ox.ac.uk> <4F4A46B3.9010508@ultraslavonic.info> Message-ID: <4F4A6C52.6060906@uvic.ca> I think we should spin off the styleguide into a separate Working Paper (since it's definitely a work in progress), and point to it from both locations. There's a lot of work to do here, assuming that we're going to maintain our own styleguide rather than adopt an existing one. It deserves its own document. Cheers, Martin On 12-02-26 06:50 AM, Kevin Hawkins wrote: > This seems like good policy to add to > http://www.tei-c.org/Activities/Council/Working/tcw20.xml#house-style-orthography > and I think also to P5/Source/Guidelines/en/style-guide.txt . > > It continues to bother me that we repeat information in these two > documents, which could easily fall out of sync. I would suggest having > one point to the other, but I'm not sure which should be primary. Thoughts? > > On 2/26/12 9:34 AM, Lou Burnard wrote: >> Further to my rather cryptic comment below: my recommendation is >> >> a) look up the word in the OED >> b) if it says that both -IZE and -ISE forms are usable, use the -IZE form. >> c) otherwise use the -ISE form. >> >> >> n 25/02/12 18:42, Lou Burnard wrote: >>> Michael Quinnion is good on this, (as on many other things) >>> >>> http://www.worldwidewords.org/qa/qa-ise1.htm >>> >>> The -IZE suffix only applize to words which (etymologically speaking) >>> come to use from a Latinized version of a Greek suffix. That's the >>> rationale given by the OED anyway. >>> >>> I don't think we should be guided by "instinct" here. Look em up. >>> >>> >>> On 25/02/12 18:18, Martin Holmes wrote: >>>> Hi all, >>>> >>>> One of Jens's excellent proofing reports suggests that we standardize >>>> spellings ending in -ise/-ize. I'm inclined to agree, and with -ise >>>> looking a bit beleaguered these days, I think it should be -ize. Lou >>>> agrees, on the ticket. >>>> >>>> So I ran this regex to see what we have: >>>> >>>> is((e[d|s]*)|(ing))\b >>>> >>>> It found 1529 instances, most of which aren't relevant ("otherwise", >>>> "raise" etc.). But amongst those which are, they don't all seem clear >>>> cut to me, though. I think these are uncontroversial: >>>> >>>> standardise >>>> normalise >>>> capitalise >>>> specialise >>>> summarise >>>> computerise >>>> italicise >>>> recognise >>>> regularise >>>> categorise >>>> >>>> But what about these? I feel instinctively less happy with changing >>>> these to z, for some reason: >>>> >>>> harmonise >>>> compromise >>>> analyse >>>> exercise >>>> utilise >>>> >>>> and I think these cannot be changed to z, even though, in many cases, >>>> variants with z are attested: >>>> >>>> comprise >>>> revise >>>> devise >>>> advise >>>> excise >>>> >>>> So what do your instincts tell you about these? Should we basically make >>>> a list of words which should use z, and put it in our style guide? >>>> >>>> Making the changes will be a significant job, because there are >>>> instances of similar words in French that mustn't be changed ("utilise", >>>> for instance). I think it'll best be done with XSLT (which can be >>>> language-aware, and ignore the French) and some very precise regexes. >>>> >>>> Cheers, >>>> Martin >>> >> -- Martin Holmes mholmes at uvic.ca UVic Humanities Computing and Media Centre From kevin.s.hawkins at ultraslavonic.info Sun Feb 26 12:43:05 2012 From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins) Date: Sun, 26 Feb 2012 12:43:05 -0500 Subject: [tei-council] P5 releases: changes to boilerplate HTML code In-Reply-To: <4201B678-EDB6-46F3-9E4D-2E746FFEBB58@oucs.ox.ac.uk> References: <4F46E23A.2030509@ultraslavonic.info> <4F4A60A7.1050809@ultraslavonic.info> <4201B678-EDB6-46F3-9E4D-2E746FFEBB58@oucs.ox.ac.uk> Message-ID: <4F4A6F29.8030500@ultraslavonic.info> On 2/26/12 12:21 PM, Sebastian Rahtz wrote: > > On 26 Feb 2012, at 16:41, Kevin Hawkins wrote: > >> One more suggestion: >> >> d) In the "Declaration" section of each element definition, there's an >> HTML button that says "Compact to XML format". If you click on it, the >> button label changes to say "XML format to compact". These labels are >> confusing, so I'd like to suggest changing as follows: >> >> "Compact to XML format" --> "Switch to XML format" >> >> XML format to compact" --> "Switch to compact format" > > This is easier than it sounds. We'd have to get re-translations of the > phrase for each language. I don't mind, but whats the evidence > that the existing words are confusing? its not been questioned > in the ?6-7 years we've had the facility. I confess that until this morning, I read "Compact to XML format" as "if you click this, it will compact what you see into an XML format". But clicking on it gives you something more verbose, which is counter-intuitive. Likewise, I read "XML format to compact" as "if you click this, it will give you an XML format, which you can compact", but it in fact gives you RelaxNG compact format. It's true that those who need to figure things out without questioning, but I'd like us to continue to strive for ease of use in everything we provide. This includes clear labeling. From sebastian.rahtz at oucs.ox.ac.uk Sun Feb 26 15:38:20 2012 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Sun, 26 Feb 2012 20:38:20 +0000 Subject: [tei-council] P5 releases: changes to boilerplate HTML code In-Reply-To: <4F46E23A.2030509@ultraslavonic.info> References: <4F46E23A.2030509@ultraslavonic.info> Message-ID: <05D6A411-463E-4350-9A79-BEF71FA51479@oucs.ox.ac.uk> On 24 Feb 2012, at 01:04, Kevin Hawkins wrote: > I recall that when a new release of the TEI is made, all of the stuff at > the top of each HTML page -- the TEI logo, the navbar, the search box, > and the phrase "P5: Guidelines for Electronic Text Encoding and > Interchange" -- is inserted at time of compilation. Somewhere there is > a file that stores the bits of HTML code needed for this. indeed. its in P5/Utilities/staticnav.xml in Sourceforge for Guldelines. Any of us can edit this in the usual way and it'll get picked up at the next build. > c) Currently the P5 version number is in fine print at the bottom of the > page, along with the last updated information. To a casual visitor, > this looks like a version number for the particular HTML file, not the > full guidelines. I have inserted "TEI Guidelines " before the word "Version" (P5/Utilities/guidelines.xsl.model), does that help? > Therefore, I'd like to request that we modify the code to insert > the current version number somewhere near "P5: Guidelines for Electronic > Text Encoding and Interchange". I have added it inside a <p> after the <h1> of the "P5: ...", is that OK? -- Stormageddon Rahtz Head of Information and Support Group, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From lou.burnard at retired.ox.ac.uk Sun Feb 26 18:08:24 2012 From: lou.burnard at retired.ox.ac.uk (Lou Burnard) Date: Sun, 26 Feb 2012 23:08:24 +0000 Subject: [tei-council] Standardi[s|z]ation In-Reply-To: <4F4A6C52.6060906@uvic.ca> References: <4F4925E9.8020105@uvic.ca> <4F492BAC.2080904@retired.ox.ac.uk> <4F4A42E4.9050203@retired.ox.ac.uk> <4F4A46B3.9010508@ultraslavonic.info> <4F4A6C52.6060906@uvic.ca> Message-ID: <4F4ABB68.6060909@retired.ox.ac.uk> Well, P5/Source/Guidelines/en/style-guide.txt is really only the beginnings of a style guide. I copied the whole of it into tcw20.xml because it seemed convenient to have everything in one place. By all means let's work on elaborating it (and perhaps, when it gets bigger, replacing it by a link in tcw20), but there's no need to maintain this information in THREE places surely? the On 26/02/12 17:30, Martin Holmes wrote: > I think we should spin off the styleguide into a separate Working Paper > (since it's definitely a work in progress), and point to it from both > locations. There's a lot of work to do here, assuming that we're going > to maintain our own styleguide rather than adopt an existing one. It > deserves its own document. > > Cheers, > Martin > > On 12-02-26 06:50 AM, Kevin Hawkins wrote: >> This seems like good policy to add to >> http://www.tei-c.org/Activities/Council/Working/tcw20.xml#house-style-orthography >> and I think also to P5/Source/Guidelines/en/style-guide.txt . >> >> It continues to bother me that we repeat information in these two >> documents, which could easily fall out of sync. I would suggest having >> one point to the other, but I'm not sure which should be primary. Thoughts? >> >> On 2/26/12 9:34 AM, Lou Burnard wrote: >>> Further to my rather cryptic comment below: my recommendation is >>> >>> a) look up the word in the OED >>> b) if it says that both -IZE and -ISE forms are usable, use the -IZE form. >>> c) otherwise use the -ISE form. >>> >>> >>> n 25/02/12 18:42, Lou Burnard wrote: >>>> Michael Quinnion is good on this, (as on many other things) >>>> >>>> http://www.worldwidewords.org/qa/qa-ise1.htm >>>> >>>> The -IZE suffix only applize to words which (etymologically speaking) >>>> come to use from a Latinized version of a Greek suffix. That's the >>>> rationale given by the OED anyway. >>>> >>>> I don't think we should be guided by "instinct" here. Look em up. >>>> >>>> >>>> On 25/02/12 18:18, Martin Holmes wrote: >>>>> Hi all, >>>>> >>>>> One of Jens's excellent proofing reports suggests that we standardize >>>>> spellings ending in -ise/-ize. I'm inclined to agree, and with -ise >>>>> looking a bit beleaguered these days, I think it should be -ize. Lou >>>>> agrees, on the ticket. >>>>> >>>>> So I ran this regex to see what we have: >>>>> >>>>> is((e[d|s]*)|(ing))\b >>>>> >>>>> It found 1529 instances, most of which aren't relevant ("otherwise", >>>>> "raise" etc.). But amongst those which are, they don't all seem clear >>>>> cut to me, though. I think these are uncontroversial: >>>>> >>>>> standardise >>>>> normalise >>>>> capitalise >>>>> specialise >>>>> summarise >>>>> computerise >>>>> italicise >>>>> recognise >>>>> regularise >>>>> categorise >>>>> >>>>> But what about these? I feel instinctively less happy with changing >>>>> these to z, for some reason: >>>>> >>>>> harmonise >>>>> compromise >>>>> analyse >>>>> exercise >>>>> utilise >>>>> >>>>> and I think these cannot be changed to z, even though, in many cases, >>>>> variants with z are attested: >>>>> >>>>> comprise >>>>> revise >>>>> devise >>>>> advise >>>>> excise >>>>> >>>>> So what do your instincts tell you about these? Should we basically make >>>>> a list of words which should use z, and put it in our style guide? >>>>> >>>>> Making the changes will be a significant job, because there are >>>>> instances of similar words in French that mustn't be changed ("utilise", >>>>> for instance). I think it'll best be done with XSLT (which can be >>>>> language-aware, and ignore the French) and some very precise regexes. >>>>> >>>>> Cheers, >>>>> Martin >>>> >>> > From kevin.s.hawkins at ultraslavonic.info Sun Feb 26 21:34:45 2012 From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins) Date: Sun, 26 Feb 2012 21:34:45 -0500 Subject: [tei-council] P5 releases: changes to boilerplate HTML code In-Reply-To: <05D6A411-463E-4350-9A79-BEF71FA51479@oucs.ox.ac.uk> References: <4F46E23A.2030509@ultraslavonic.info> <05D6A411-463E-4350-9A79-BEF71FA51479@oucs.ox.ac.uk> Message-ID: <4F4AEBC5.4060708@ultraslavonic.info> On 2/26/12 3:38 PM, Sebastian Rahtz wrote: >> c) Currently the P5 version number is in fine print at the bottom of the >> page, along with the last updated information. To a casual visitor, >> this looks like a version number for the particular HTML file, not the >> full guidelines. > I have inserted "TEI Guidelines " before the word "Version" (P5/Utilities/guidelines.xsl.model), > does that help? Yes. >> Therefore, I'd like to request that we modify the code to insert >> the current version number somewhere near "P5: Guidelines for Electronic >> Text Encoding and Interchange". > > I have added it inside a<p> after the<h1> of the "P5: ...", is that OK? Yes, except that the <p> is aligned left whereas the <h1> is aligned right. Is it safe to just edit guidelines.css in the same directory to pretty things up? --K. From sebastian.rahtz at oucs.ox.ac.uk Mon Feb 27 04:05:55 2012 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 27 Feb 2012 09:05:55 +0000 Subject: [tei-council] P5 releases: changes to boilerplate HTML code In-Reply-To: <4F4AEBC5.4060708@ultraslavonic.info> References: <4F46E23A.2030509@ultraslavonic.info> <05D6A411-463E-4350-9A79-BEF71FA51479@oucs.ox.ac.uk> <4F4AEBC5.4060708@ultraslavonic.info> Message-ID: <925769A7-2F5B-4EFF-8B29-42CCE3C70C7A@oucs.ox.ac.uk> > Yes, except that the <p> is aligned left whereas the <h1> is aligned > right. Is it safe to just edit guidelines.css in the same directory to > pretty things up? yes, definitely. that <p> should be addressable OK? -- Stormageddon Rahtz Head of Information and Support Group Oxford University Computing Services 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 27 08:50:47 2012 From: mholmes at uvic.ca (Martin Holmes) Date: Mon, 27 Feb 2012 05:50:47 -0800 Subject: [tei-council] TEI telco Agenda In-Reply-To: <4F3C533D.9060403@uvic.ca> References: <4F3C3442.9010801@oucs.ox.ac.uk> <4F3C533D.9060403@uvic.ca> Message-ID: <4F4B8A37.7010801@uvic.ca> Hi all, Following Kevin's example, I'm presenting quick outlines of the things I'm supposed to be reporting on at the telco: On 16/02/12 00:52, Martin Holmes wrote: 1.3. TEI and AdBlock (MH) (Would be good to get a recap of where things stand and what we decided) This is bug <http://purl.org/TEI/BUGS/3472477>. The original problem arose when we discovered that one section of the Guidelines was invisible to some readers. It turned out that its @id attribute, "msad", was on a list of ids being blocked by AdBlock Plus. AdBlock Plus behaviour is controlled by any of many different blocking lists, to which people subscribe. The two most common lists are EasyList and Fanboy's List. I filed a bug with EasyList, and their maintainer fixed the problem within 24 hours. I also filed a bug with Fanboy's List, but that has been ignored. In preparation for the Telco, I've taken a look through a sampling of about ten of the filters listed here: http://adblockplus.org/en/subscriptions None of them have the specific element id "msad", although the server "msads.net" crops up frequently. It may be the case at this point that only Fanboy's list has the problem, but the maintainer is completely unresponsive. It would be impractical to check all the lists on the page manually, although it could be automated. There is nothing to prevent a similar problem appearing in future, with any of the @xml:ids which give rise to @xhtml:ids in the web version of the Guidelines. In view of this, Sebastian suggested changing the output XSLT to prefix all ids with "tei_". Lou thought this was a good idea, but you warned that it would break some existing links to anchors on the web. It would not break links to pages, only to anchors within pages. Personally I think it's worth breaking the links, so we should ask Sebastian to make the change the stylesheets, but perhaps this is a change that should only be made when we move to 2.1, since it may partially break some existing links on the web. During the Telco, perhaps we can make a decision on this. 1.6. Attribute Datatypes (MH) This relates to the following bug reports: <http://purl.org/TEI/BUGS/3441933> <http://purl.org/TEI/BUGS/3455686> The basic issue was that some textual descriptions of attributes did not match their actual formal datatypes; in investigating this, we discovered that many attributes didn't actually have formal datatypes. All of the initial problems have been fixed. A table showing the current state of attributes is here: <http://web.uvic.ca/lancenrd/martin/tei/valdescs.htm> The remaining attributes without datatypes (92 and 409 in that table) were intrinsically problematic (the first deprecated, the second not fully defined). The latter was given its own ticket: <http://purl.org/TEI/BUGS/3486352> which is now closed, because that issue is fixed. So the only remaining issue is the deprecated attribute quotation/@form, which has no datatype. For the sake of completeness, we could assign it one, or we could just ignore it. 1.8. TEI Release Process Document (MH) During the last release, several of us worked to revise a detailed version of the Process Release Document "Building a TEI Release", which is a working paper here: <http://www.tei-c.org/Activities/Council/Working/tcw22.xml> We now believe this is pretty much as comprehensive as it can be, and should be able to guide anyone through the process of making a release, but please read through it and bring any comments to the Telco. There were also a couple of post-release problems with the db that handles Roma, which we hope are now fixed, but we won't know for sure until another release has been done. Gabriel has volunteered to be the next release engineer. There is one more issue I'm scheduled to speak on: 2. @ref/key/cRef & Private URI Schemes (MH) and I'm still working on an outline of that. Cheers, Martin From kevin.s.hawkins at ultraslavonic.info Mon Feb 27 09:57:57 2012 From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins) Date: Mon, 27 Feb 2012 09:57:57 -0500 Subject: [tei-council] P5 releases: changes to boilerplate HTML code In-Reply-To: <925769A7-2F5B-4EFF-8B29-42CCE3C70C7A@oucs.ox.ac.uk> References: <4F46E23A.2030509@ultraslavonic.info> <05D6A411-463E-4350-9A79-BEF71FA51479@oucs.ox.ac.uk> <4F4AEBC5.4060708@ultraslavonic.info> <925769A7-2F5B-4EFF-8B29-42CCE3C70C7A@oucs.ox.ac.uk> Message-ID: <4F4B99F5.10501@ultraslavonic.info> On 2/27/2012 4:05 AM, Sebastian Rahtz wrote: >> Yes, except that the<p> is aligned left whereas the<h1> is aligned >> right. Is it safe to just edit guidelines.css in the same directory to >> pretty things up? > > > yes, definitely. that<p> should be addressable OK? I think you are asking whether the <p> for the version number is addressable by CSS -- that is, can I create a rule that will affect the display of only this <p>. I've made this change (revision 10121) and am waiting for Jenkins to finish to make sure it actually displays as intended. From mholmes at uvic.ca Mon Feb 27 11:31:12 2012 From: mholmes at uvic.ca (Martin Holmes) Date: Mon, 27 Feb 2012 08:31:12 -0800 Subject: [tei-council] Standardi[s|z]ation In-Reply-To: <4F4ABB68.6060909@retired.ox.ac.uk> References: <4F4925E9.8020105@uvic.ca> <4F492BAC.2080904@retired.ox.ac.uk> <4F4A42E4.9050203@retired.ox.ac.uk> <4F4A46B3.9010508@ultraslavonic.info> <4F4A6C52.6060906@uvic.ca> <4F4ABB68.6060909@retired.ox.ac.uk> Message-ID: <4F4BAFD0.7060703@uvic.ca> The question really is whether it's best to maintain this information in a text file in the Guidelines source code, or as a more public document on the TEI website. In the latter case, it would be in P5 and benefit from transformation into richer XHTML, with links etc. working. I like the P5 option. It's currently part of TCW20 because it doesn't consist of much, but it's going to get bigger as we go along, so I think it deserves a document to itself. Cheers, Martin On 12-02-26 03:08 PM, Lou Burnard wrote: > Well, P5/Source/Guidelines/en/style-guide.txt is really only the > beginnings of a style guide. I copied the whole of it into tcw20.xml > because it seemed convenient to have everything in one place. By all > means let's work on elaborating it (and perhaps, when it gets bigger, > replacing it by a link in tcw20), but there's no need to maintain this > information in THREE places surely? > > > > the On 26/02/12 17:30, Martin Holmes wrote: >> I think we should spin off the styleguide into a separate Working Paper >> (since it's definitely a work in progress), and point to it from both >> locations. There's a lot of work to do here, assuming that we're going >> to maintain our own styleguide rather than adopt an existing one. It >> deserves its own document. >> >> Cheers, >> Martin >> >> On 12-02-26 06:50 AM, Kevin Hawkins wrote: >>> This seems like good policy to add to >>> http://www.tei-c.org/Activities/Council/Working/tcw20.xml#house-style-orthography >>> and I think also to P5/Source/Guidelines/en/style-guide.txt . >>> >>> It continues to bother me that we repeat information in these two >>> documents, which could easily fall out of sync. I would suggest having >>> one point to the other, but I'm not sure which should be primary. Thoughts? >>> >>> On 2/26/12 9:34 AM, Lou Burnard wrote: >>>> Further to my rather cryptic comment below: my recommendation is >>>> >>>> a) look up the word in the OED >>>> b) if it says that both -IZE and -ISE forms are usable, use the -IZE form. >>>> c) otherwise use the -ISE form. >>>> >>>> >>>> n 25/02/12 18:42, Lou Burnard wrote: >>>>> Michael Quinnion is good on this, (as on many other things) >>>>> >>>>> http://www.worldwidewords.org/qa/qa-ise1.htm >>>>> >>>>> The -IZE suffix only applize to words which (etymologically speaking) >>>>> come to use from a Latinized version of a Greek suffix. That's the >>>>> rationale given by the OED anyway. >>>>> >>>>> I don't think we should be guided by "instinct" here. Look em up. >>>>> >>>>> >>>>> On 25/02/12 18:18, Martin Holmes wrote: >>>>>> Hi all, >>>>>> >>>>>> One of Jens's excellent proofing reports suggests that we standardize >>>>>> spellings ending in -ise/-ize. I'm inclined to agree, and with -ise >>>>>> looking a bit beleaguered these days, I think it should be -ize. Lou >>>>>> agrees, on the ticket. >>>>>> >>>>>> So I ran this regex to see what we have: >>>>>> >>>>>> is((e[d|s]*)|(ing))\b >>>>>> >>>>>> It found 1529 instances, most of which aren't relevant ("otherwise", >>>>>> "raise" etc.). But amongst those which are, they don't all seem clear >>>>>> cut to me, though. I think these are uncontroversial: >>>>>> >>>>>> standardise >>>>>> normalise >>>>>> capitalise >>>>>> specialise >>>>>> summarise >>>>>> computerise >>>>>> italicise >>>>>> recognise >>>>>> regularise >>>>>> categorise >>>>>> >>>>>> But what about these? I feel instinctively less happy with changing >>>>>> these to z, for some reason: >>>>>> >>>>>> harmonise >>>>>> compromise >>>>>> analyse >>>>>> exercise >>>>>> utilise >>>>>> >>>>>> and I think these cannot be changed to z, even though, in many cases, >>>>>> variants with z are attested: >>>>>> >>>>>> comprise >>>>>> revise >>>>>> devise >>>>>> advise >>>>>> excise >>>>>> >>>>>> So what do your instincts tell you about these? Should we basically make >>>>>> a list of words which should use z, and put it in our style guide? >>>>>> >>>>>> Making the changes will be a significant job, because there are >>>>>> instances of similar words in French that mustn't be changed ("utilise", >>>>>> for instance). I think it'll best be done with XSLT (which can be >>>>>> language-aware, and ignore the French) and some very precise regexes. >>>>>> >>>>>> Cheers, >>>>>> Martin >>>>> >>>> >> > -- Martin Holmes University of Victoria Humanities Computing and Media Centre (mholmes at uvic.ca) From gabriel.bodard at kcl.ac.uk Mon Feb 27 11:32:48 2012 From: gabriel.bodard at kcl.ac.uk (Gabriel Bodard) Date: Mon, 27 Feb 2012 16:32:48 +0000 Subject: [tei-council] P5 releases: changes to boilerplate HTML code In-Reply-To: <4201B678-EDB6-46F3-9E4D-2E746FFEBB58@oucs.ox.ac.uk> References: <4F46E23A.2030509@ultraslavonic.info> <4F4A60A7.1050809@ultraslavonic.info> <4201B678-EDB6-46F3-9E4D-2E746FFEBB58@oucs.ox.ac.uk> Message-ID: <4F4BB030.7000801@kcl.ac.uk> On 2012-02-26 17:21, Sebastian Rahtz wrote: >> "Compact to XML format" --> "Switch to XML format" >> >> XML format to compact" --> "Switch to compact format" > > This is easier than it sounds. We'd have to get re-translations of the > phrase for each language. I don't mind, but whats the evidence > that the existing words are confusing? its not been questioned > in the ?6-7 years we've had the facility. It's sure as hell confusing to me. I always have to squint at it to figure out which way round it should be. I'd be inclined to suggest two tabs, one ("compact") obviously "selected", and the other a button reading "XML" (and vice versa). But failing that I like Kevin's suggestion. (That no one has complained before is no indication that it's not a problem. You know how much people prefer to keep quiet, especially if doing otherwise might make them look ignorant.) I would also suggest that we change this in English asap, regardless of whether or not the other language versions are changed. The text supplied by some of the other i18n groups might not be confusing, after all, if the phrasing is quite different. G -- Dr Gabriel BODARD (Research Associate in Digital Epigraphy) Department of Digital 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 bansp at o2.pl Mon Feb 27 14:36:34 2012 From: bansp at o2.pl (=?ISO-8859-2?Q?Piotr_Ba=F1ski?=) Date: Mon, 27 Feb 2012 20:36:34 +0100 Subject: [tei-council] telco - probable absence Message-ID: <4F4BDB42.4040201@o2.pl> Dear All, It looks like the yellow in my '(yes)' option in the doodle was leaning more towards red than I expected, at the time when James was making sure that the date+hour was OK with me. I'll try to be there tomorrow, but don't be surprised if I don't turn up. (Conditional) apologies in advance, Piotr From mholmes at uvic.ca Mon Feb 27 14:42:00 2012 From: mholmes at uvic.ca (Martin Holmes) Date: Mon, 27 Feb 2012 11:42:00 -0800 Subject: [tei-council] Magic tokens, private URIs, and canonical references Message-ID: <4F4BDC88.8040506@uvic.ca> The final topic I'm supposed to cover during the Telco relates to the big mess surrounding several attributes: @cRef @key @lemma @loc metSym/@value The current tickets are these: <http://purl.org/TEI/BUGS/3480650> ("@cRef is a mess") <http://purl.org/TEI/BUGS/3413346> ("Deprecation of data.key and data.word attributes") The basic issue is this: Historically, we have encouraged the use of what might be termed "magic tokens" in attributes such as @key: <name key="bloggs_f">Fred Bloggs</name> where the @key value is used to look up or point to a more detailed record for the thing being referred to. The syntax or format of @key has not been prescribed: "@key provides an externally-defined means of identifying the entity (or entities) being named, using a coded value of some kind." and it has been left up to encoders to devise their own schemes for dereferencing their @key values (usually turning them into fully-qualified URLs, XPaths, database queries etc.), and to document them in their own way. In some cases, such as @cRef, a more formal methodology for dereferencing has been prescribed. Here is how @cRef is defined on <term>: <quote> @cRef identifies the associated gloss element using a canonical reference from a scheme defined in a refsDecl element in the TEI header Status: Optional Datatype: data.pointer Values the result of applying the algorithm for the resolution of canonical references (described in section 16.2.5 Canonical References) should be a valid URI reference that resolves to a gloss element Note The refsDecl to use may be indicated with the decls attribute. </quote> The element <cRefPattern> is available for documenting the resolution algorithm. Recently we have become rightly uncomfortable with "magic key" values, and have been looking for more formal ways for people to specify this kind of pointer. The most commonly-advanced approach is to use what's called a "private URI scheme", which essentially means an idiosyncratic, unregistered prefix, followed by a unique identifier. For instance, in our project "Map of London", we use private URIs like this: <name type="person" ref="mol:HOLM3">Martin Holmes</name> The advantage of private URI schemes is that they can be used in attributes such as @ref and @target, which expect one or more URIs. However, it's pretty obvious that these are still actually magic tokens. There's no way for anyone to know what "mol:HOLM3" points at without proper documentation and/or an algorithm for dereferencing it. It's my belief that we should: 1. Provide a formal mechanism by which private URIs can be documented, and where an algorithm for dereferencing them (converting them to some sort of universal pointer such as an absolute web URI) can be specified. 2. Once we have done this, rewrite relevant parts of the guidelines to encourage the use of attributes such as @ref and @target in place of the old "magic token" attributes such as @key. 3. Deprecate some or all of these attributes. 4. Address the mess which is @cRef (see the relevant ticket). It will be easier to do this after 1-3 are completed. During the Telco, I'd like to get a sense of whether people agree with me on #1. If they don't -- if everyone is happy that private URIs should be used as magic tokens have historically been used, without any formal recommendation for documentation -- then the second ticket can be closed; the issue of @cRef is still problematic, but we could even choose to ignore that if we wish. If there is some agreement with #1, then I think we should put together a small working group to create a recommendation. Cheers, Martin -- Martin Holmes University of Victoria Humanities Computing and Media Centre (mholmes at uvic.ca) From sebastian.rahtz at oucs.ox.ac.uk Mon Feb 27 16:06:18 2012 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 27 Feb 2012 21:06:18 +0000 Subject: [tei-council] P5 releases: changes to boilerplate HTML code In-Reply-To: <4F4BB030.7000801@kcl.ac.uk> References: <4F46E23A.2030509@ultraslavonic.info> <4F4A60A7.1050809@ultraslavonic.info> <4201B678-EDB6-46F3-9E4D-2E746FFEBB58@oucs.ox.ac.uk> <4F4BB030.7000801@kcl.ac.uk> Message-ID: <BC5D5ACD-7C4B-4954-8BC6-AAF3A0A11196@oucs.ox.ac.uk> On 27 Feb 2012, at 16:32, Gabriel Bodard wrote: > I'd be inclined to suggest two > tabs, one ("compact") obviously "selected", and the other a button > reading "XML" (and vice versa). that would be nice, I agree. Do any of you have a webby person who could knock up the appropriate bit of HTML and jQuery which I could drop directly[1] in? it will be a while before I have the time to concentrate on this for an hour (it probably needs less...) > (That no one has complained before is no indication that > it's not a problem. You know how much people prefer to keep quiet, > especially if doing otherwise might make them look ignorant.) but its also true that we shouldn't make changes just because two people ask for it..... [1] strangely, it doesn't solve the problem to be told "package XX does all this, we use it all the time"..... -- Stormageddon Rahtz Head of Information and Support Group, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From rwelzenbach at gmail.com Mon Feb 27 22:51:29 2012 From: rwelzenbach at gmail.com (Rebecca Welzenbach) Date: Mon, 27 Feb 2012 22:51:29 -0500 Subject: [tei-council] TEI Telco February 2012 In-Reply-To: <4F4779CA.1090700@oucs.ox.ac.uk> References: <4F466B6A.5060107@oucs.ox.ac.uk> <4F46D4BB.4010604@o2.pl> <4F4779CA.1090700@oucs.ox.ac.uk> Message-ID: <CAA2irtLfXcAGv2h4DSXZznHW7kTei7PM9iq874-P16oMLP4Pyg@mail.gmail.com> I can do the minutes, unless James has already picked someone else and feels committed to his choice. Speak to you tomorrow... Becky > Speaking of which, I have yet to have any volunteers to take > minutes during the conference call. ?I don't want to pick someone > at random (but will)...how about I say that if you do the minutes > this time, I won't make you do them next time? From rwelzenbach at gmail.com Tue Feb 28 00:06:12 2012 From: rwelzenbach at gmail.com (Rebecca Welzenbach) Date: Tue, 28 Feb 2012 00:06:12 -0500 Subject: [tei-council] P5 releases: changes to boilerplate HTML code In-Reply-To: <BC5D5ACD-7C4B-4954-8BC6-AAF3A0A11196@oucs.ox.ac.uk> References: <4F46E23A.2030509@ultraslavonic.info> <4F4A60A7.1050809@ultraslavonic.info> <4201B678-EDB6-46F3-9E4D-2E746FFEBB58@oucs.ox.ac.uk> <4F4BB030.7000801@kcl.ac.uk> <BC5D5ACD-7C4B-4954-8BC6-AAF3A0A11196@oucs.ox.ac.uk> Message-ID: <CAA2irtJjWjetvObrBzZBpwogReReyagDo-606KoKL3OBUq8Tbg@mail.gmail.com> I agree with Kevin and Gabby. For me, the problem is that the current phrasing is missing a clear verb. "Switch", "go," "toggle," or whatever action will take place when you click the button, is implied rather than stated explicitly. This makes it easy to incorrectly read other words in the phrase as the verbs: "click here to compact" and "click here to format." I think this is how one arrives at something like Kevin's interpretation above. Gabby's button solution seems the least ambiguous, and perhaps also easiest to export to other languages, since you just need the two labels, "XML view" and "Compact view." All syntactic messiness is neatly avoided. But Kevin's suggestion seems perfectly clear to me as well. Becky On Mon, Feb 27, 2012 at 4:06 PM, Sebastian Rahtz <sebastian.rahtz at oucs.ox.ac.uk> wrote: > > On 27 Feb 2012, at 16:32, Gabriel Bodard wrote: > > >> I'd be inclined to suggest two >> tabs, one ("compact") obviously "selected", and the other a button >> reading "XML" (and vice versa). > > that would be nice, I agree. ?Do any of you have a webby person > who could knock up the appropriate bit of HTML and jQuery which I could drop > directly[1] in? ?it will be a while before I have the time to concentrate on this for an hour > (it probably needs less...) > > >> (That no one has complained before is no indication that >> it's not a problem. You know how much people prefer to keep quiet, >> especially if doing otherwise might make them look ignorant.) > > but its also true that we shouldn't make changes just because > two people ask for it..... > > [1] strangely, it doesn't solve the problem to be told "package XX does all this, > we use it all the time"..... > -- > Stormageddon Rahtz > Head of Information and Support Group, Oxford University Computing 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 > > PLEASE NOTE: postings to this list are publicly archived From James.Cummings at oucs.ox.ac.uk Tue Feb 28 06:31:27 2012 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Tue, 28 Feb 2012 11:31:27 +0000 Subject: [tei-council] TEI Telco February 2012 In-Reply-To: <CAA2irtLfXcAGv2h4DSXZznHW7kTei7PM9iq874-P16oMLP4Pyg@mail.gmail.com> References: <4F466B6A.5060107@oucs.ox.ac.uk> <4F46D4BB.4010604@o2.pl> <4F4779CA.1090700@oucs.ox.ac.uk> <CAA2irtLfXcAGv2h4DSXZznHW7kTei7PM9iq874-P16oMLP4Pyg@mail.gmail.com> Message-ID: <4F4CBB0F.6030206@oucs.ox.ac.uk> Hi Becky, In this case Lou has volunteered to take the minutes (thank you Lou!), but I'll put your name as a reserve on the list (with Martin) ... we will always need minute takers at the Ann Arbor meeting as well. :-) I'll try to make sure the burden gets spread around. -James On 28/02/12 03:51, Rebecca Welzenbach wrote: > I can do the minutes, unless James has already picked someone else and > feels committed to his choice. > > Speak to you tomorrow... -- Dr James Cummings, InfoDev, Computing Services, University of Oxford From gabriel.bodard at kcl.ac.uk Tue Feb 28 12:38:47 2012 From: gabriel.bodard at kcl.ac.uk (Gabriel Bodard) Date: Tue, 28 Feb 2012 17:38:47 +0000 Subject: [tei-council] TEI Telco February 2012 In-Reply-To: <4F477A1E.6010006@oucs.ox.ac.uk> References: <4F466B6A.5060107@oucs.ox.ac.uk> <4F46D4BB.4010604@o2.pl> <4F4779CA.1090700@oucs.ox.ac.uk> <4F477A1E.6010006@oucs.ox.ac.uk> Message-ID: <4F4D1127.5000101@kcl.ac.uk> Even though we're not using Skype for the conference call, would it be worthwhile having a skype window open with all of us chatting, so we can do things like pass around URLs and other text quickly and easily during the call? I'll try to set up a chat, but there may be a few people whose contacts I don't have yet. If you're one of those, could you try to share your details with me (I'm "gabrielbodard", predictably enough...)? G On 2012-02-24 11:53, James Cummings wrote: > On 24/02/12 11:51, James Cummings wrote: >> If skype conversations are all held by people are a computer they >> are free. However, in the past it has often been found that the > > s/are a computer/who are on a computer/ > > *sigh* > > -James > -- Dr Gabriel BODARD (Research Associate in Digital Epigraphy) Department of Digital 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 28 12:44:31 2012 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Tue, 28 Feb 2012 17:44:31 +0000 Subject: [tei-council] TEI Telco February 2012 In-Reply-To: <4F4D1127.5000101@kcl.ac.uk> References: <4F466B6A.5060107@oucs.ox.ac.uk> <4F46D4BB.4010604@o2.pl> <4F4779CA.1090700@oucs.ox.ac.uk> <4F477A1E.6010006@oucs.ox.ac.uk> <4F4D1127.5000101@kcl.ac.uk> Message-ID: <4F4D127F.6080600@oucs.ox.ac.uk> Sounds like a good idea to me. (Other alternative being IRC, but of course more people have skype already set up, so let's use that!) -James On 28/02/12 17:38, Gabriel Bodard wrote: > Even though we're not using Skype for the conference call, would it be > worthwhile having a skype window open with all of us chatting, so we can > do things like pass around URLs and other text quickly and easily during > the call? > > I'll try to set up a chat, but there may be a few people whose contacts > I don't have yet. If you're one of those, could you try to share your > details with me (I'm "gabrielbodard", predictably enough...)? > > G > > On 2012-02-24 11:53, James Cummings wrote: >> On 24/02/12 11:51, James Cummings wrote: >>> If skype conversations are all held by people are a computer they >>> are free. However, in the past it has often been found that the >> >> s/are a computer/who are on a computer/ >> >> *sigh* >> >> -James >> > -- Dr James Cummings, InfoDev, Computing Services, University of Oxford From gabriel.bodard at kcl.ac.uk Tue Feb 28 12:49:07 2012 From: gabriel.bodard at kcl.ac.uk (Gabriel Bodard) Date: Tue, 28 Feb 2012 17:49:07 +0000 Subject: [tei-council] TEI Telco February 2012 In-Reply-To: <4F4D127F.6080600@oucs.ox.ac.uk> References: <4F466B6A.5060107@oucs.ox.ac.uk> <4F46D4BB.4010604@o2.pl> <4F4779CA.1090700@oucs.ox.ac.uk> <4F477A1E.6010006@oucs.ox.ac.uk> <4F4D1127.5000101@kcl.ac.uk> <4F4D127F.6080600@oucs.ox.ac.uk> Message-ID: <4F4D1393.7060006@kcl.ac.uk> IRC's not a bad idea, especially as there is a web interface to that. (http://webchat.freenode.net/) But if everyone has Skype, then we're probably okay. On 2012-02-28 17:44, James Cummings wrote: > > Sounds like a good idea to me. (Other alternative being IRC, but > of course more people have skype already set up, so let's use that!) > > -James > > > On 28/02/12 17:38, Gabriel Bodard wrote: >> Even though we're not using Skype for the conference call, would it be >> worthwhile having a skype window open with all of us chatting, so we can >> do things like pass around URLs and other text quickly and easily during >> the call? >> >> I'll try to set up a chat, but there may be a few people whose contacts >> I don't have yet. If you're one of those, could you try to share your >> details with me (I'm "gabrielbodard", predictably enough...)? >> >> G >> >> On 2012-02-24 11:53, James Cummings wrote: >>> On 24/02/12 11:51, James Cummings wrote: >>>> If skype conversations are all held by people are a computer they >>>> are free. However, in the past it has often been found that the >>> >>> s/are a computer/who are on a computer/ >>> >>> *sigh* >>> >>> -James >>> >> > > -- Dr Gabriel BODARD (Research Associate in Digital Epigraphy) Department of Digital 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 rwelzenbach at gmail.com Tue Feb 28 12:51:29 2012 From: rwelzenbach at gmail.com (Rebecca Welzenbach) Date: Tue, 28 Feb 2012 12:51:29 -0500 Subject: [tei-council] TEI Telco February 2012 In-Reply-To: <4F4D1393.7060006@kcl.ac.uk> References: <4F466B6A.5060107@oucs.ox.ac.uk> <4F46D4BB.4010604@o2.pl> <4F4779CA.1090700@oucs.ox.ac.uk> <4F477A1E.6010006@oucs.ox.ac.uk> <4F4D1127.5000101@kcl.ac.uk> <4F4D127F.6080600@oucs.ox.ac.uk> <4F4D1393.7060006@kcl.ac.uk> Message-ID: <CAA2irtJtcA1h=Haaju1u4LXQtnfQDri6CfO1HMz=6TEw5N-tFA@mail.gmail.com> I will be on Skype: rwelzenb On Tue, Feb 28, 2012 at 12:49 PM, Gabriel Bodard <gabriel.bodard at kcl.ac.uk> wrote: > IRC's not a bad idea, especially as there is a web interface to that. > (http://webchat.freenode.net/) But if everyone has Skype, then we're > probably okay. > > On 2012-02-28 17:44, James Cummings wrote: >> >> Sounds like a good idea to me. ?(Other alternative being IRC, but >> of course more people have skype already set up, so let's use that!) >> >> -James >> >> >> On 28/02/12 17:38, Gabriel Bodard wrote: >>> Even though we're not using Skype for the conference call, would it be >>> worthwhile having a skype window open with all of us chatting, so we can >>> do things like pass around URLs and other text quickly and easily during >>> the call? >>> >>> I'll try to set up a chat, but there may be a few people whose contacts >>> I don't have yet. If you're one of those, could you try to share your >>> details with me (I'm "gabrielbodard", predictably enough...)? >>> >>> G >>> >>> On 2012-02-24 11:53, James Cummings wrote: >>>> On 24/02/12 11:51, James Cummings wrote: >>>>> If skype conversations are all held by people are a computer they >>>>> are free. However, in the past it has often been found that the >>>> >>>> s/are a computer/who are on a computer/ >>>> >>>> *sigh* >>>> >>>> -James >>>> >>> >> >> > > -- > Dr Gabriel BODARD > (Research Associate in Digital Epigraphy) > > Department of Digital Humanities > King's College London > 26-29 Drury Lane > London WC2B 5RL > > Email: gabriel.bodard at kcl.ac.uk > Tel: +44 (0)20 7848 1388 > Fax: +44 (0)20 7848 2980 > > http://www.digitalclassicist.org/ > http://www.currentepigraphy.org/ > -- > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > > PLEASE NOTE: postings to this list are publicly archived From gabriel.bodard at kcl.ac.uk Tue Feb 28 14:00:34 2012 From: gabriel.bodard at kcl.ac.uk (Gabriel Bodard) Date: Tue, 28 Feb 2012 19:00:34 +0000 Subject: [tei-council] XPointer working group Message-ID: <4F4D2452.4020902@kcl.ac.uk> The XPointer ad hoc working group (myself, Martin, Piotr, Laurent, Syd Baumann and Hugh Cayless) is using the old "Stand-off markup" mailing list (archives at <http://listserv.brown.edu/archives/cgi-bin/wa?A0=TEI-SOM>) to discuss possible approaches to making TEI XPointer schemes more useful. Possible recommendations at the end of the day might include: * completely abandon XPointer and recommend (or develop) some other scheme; * drop most of the obscurer functions and keep only xpath() and/or xpath2() * leave everything alone, but possibly do something about improving the implementation I have asked the workgroup to come up with a self-imposed deadline to report back to Council. G -- Dr Gabriel BODARD (Research Associate in Digital Epigraphy) Department of Digital 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 syeates at gmail.com Tue Feb 28 14:11:29 2012 From: syeates at gmail.com (Stuart A. Yeates) Date: Wed, 29 Feb 2012 08:11:29 +1300 Subject: [tei-council] some brief reports to save time during our upcoming conf call In-Reply-To: <4F4978F8.205@ultraslavonic.info> References: <4F4978F8.205@ultraslavonic.info> Message-ID: <CAC_Lu0a4ddMsKdqTfofgJA9XmLvFpJ_FC8LQAy9X0rBBiDTAQw@mail.gmail.com> On Sun, Feb 26, 2012 at 1:12 PM, Kevin Hawkins <kevin.s.hawkins at ultraslavonic.info> wrote: > = Google Books = > The importance of this for the TEI's PR can't really be understated. > We, or the Board, might want to give some thought about whether to do > anything more once Google deloys this code than simply announce it on > TEI-L with shouts of hurrah/hooray/huzzah. I think it might be productive to have a few paragraphs contrasting TEI texts and underlying openness to the closed and propriety nature of formats currently in use by Amazon and OverDrive. I'm happy to write these, maybe with Kevin giving me some feedback? cheers stuart From kevin.s.hawkins at ultraslavonic.info Tue Feb 28 22:31:55 2012 From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins) Date: Tue, 28 Feb 2012 22:31:55 -0500 Subject: [tei-council] Standardi[s|z]ation In-Reply-To: <4F4BAFD0.7060703@uvic.ca> References: <4F4925E9.8020105@uvic.ca> <4F492BAC.2080904@retired.ox.ac.uk> <4F4A42E4.9050203@retired.ox.ac.uk> <4F4A46B3.9010508@ultraslavonic.info> <4F4A6C52.6060906@uvic.ca> <4F4ABB68.6060909@retired.ox.ac.uk> <4F4BAFD0.7060703@uvic.ca> Message-ID: <4F4D9C2B.1060904@ultraslavonic.info> Lou, I don't think Martin was suggesting that we duplicate the information in three places. Instead, he suggested replacing P5/Source/Guidelines/en/style-guide.txt and the relevant section of tcw20 with a link to the new document, which would be a TEI document named tcw23 or the next available "tcw" number at the time of creation. I agree with this strategy. Perhaps one of our newer members would like to take on the task of composing tcw23? Martin or I can handle updating tcw20 and style-guide.txt once the new document is in place. On 2/27/12 11:31 AM, Martin Holmes wrote: > The question really is whether it's best to maintain this information in > a text file in the Guidelines source code, or as a more public document > on the TEI website. In the latter case, it would be in P5 and benefit > from transformation into richer XHTML, with links etc. working. > > I like the P5 option. It's currently part of TCW20 because it doesn't > consist of much, but it's going to get bigger as we go along, so I think > it deserves a document to itself. > > Cheers, > Martin > > On 12-02-26 03:08 PM, Lou Burnard wrote: >> Well, P5/Source/Guidelines/en/style-guide.txt is really only the >> beginnings of a style guide. I copied the whole of it into tcw20.xml >> because it seemed convenient to have everything in one place. By all >> means let's work on elaborating it (and perhaps, when it gets bigger, >> replacing it by a link in tcw20), but there's no need to maintain this >> information in THREE places surely? >> >> >> >> the On 26/02/12 17:30, Martin Holmes wrote: >>> I think we should spin off the styleguide into a separate Working Paper >>> (since it's definitely a work in progress), and point to it from both >>> locations. There's a lot of work to do here, assuming that we're going >>> to maintain our own styleguide rather than adopt an existing one. It >>> deserves its own document. >>> >>> Cheers, >>> Martin >>> >>> On 12-02-26 06:50 AM, Kevin Hawkins wrote: >>>> This seems like good policy to add to >>>> http://www.tei-c.org/Activities/Council/Working/tcw20.xml#house-style-orthography >>>> and I think also to P5/Source/Guidelines/en/style-guide.txt . >>>> >>>> It continues to bother me that we repeat information in these two >>>> documents, which could easily fall out of sync. I would suggest having >>>> one point to the other, but I'm not sure which should be primary. Thoughts? >>>> >>>> On 2/26/12 9:34 AM, Lou Burnard wrote: >>>>> Further to my rather cryptic comment below: my recommendation is >>>>> >>>>> a) look up the word in the OED >>>>> b) if it says that both -IZE and -ISE forms are usable, use the -IZE form. >>>>> c) otherwise use the -ISE form. >>>>> >>>>> >>>>> n 25/02/12 18:42, Lou Burnard wrote: >>>>>> Michael Quinnion is good on this, (as on many other things) >>>>>> >>>>>> http://www.worldwidewords.org/qa/qa-ise1.htm >>>>>> >>>>>> The -IZE suffix only applize to words which (etymologically speaking) >>>>>> come to use from a Latinized version of a Greek suffix. That's the >>>>>> rationale given by the OED anyway. >>>>>> >>>>>> I don't think we should be guided by "instinct" here. Look em up. >>>>>> >>>>>> >>>>>> On 25/02/12 18:18, Martin Holmes wrote: >>>>>>> Hi all, >>>>>>> >>>>>>> One of Jens's excellent proofing reports suggests that we standardize >>>>>>> spellings ending in -ise/-ize. I'm inclined to agree, and with -ise >>>>>>> looking a bit beleaguered these days, I think it should be -ize. Lou >>>>>>> agrees, on the ticket. >>>>>>> >>>>>>> So I ran this regex to see what we have: >>>>>>> >>>>>>> is((e[d|s]*)|(ing))\b >>>>>>> >>>>>>> It found 1529 instances, most of which aren't relevant ("otherwise", >>>>>>> "raise" etc.). But amongst those which are, they don't all seem clear >>>>>>> cut to me, though. I think these are uncontroversial: >>>>>>> >>>>>>> standardise >>>>>>> normalise >>>>>>> capitalise >>>>>>> specialise >>>>>>> summarise >>>>>>> computerise >>>>>>> italicise >>>>>>> recognise >>>>>>> regularise >>>>>>> categorise >>>>>>> >>>>>>> But what about these? I feel instinctively less happy with changing >>>>>>> these to z, for some reason: >>>>>>> >>>>>>> harmonise >>>>>>> compromise >>>>>>> analyse >>>>>>> exercise >>>>>>> utilise >>>>>>> >>>>>>> and I think these cannot be changed to z, even though, in many cases, >>>>>>> variants with z are attested: >>>>>>> >>>>>>> comprise >>>>>>> revise >>>>>>> devise >>>>>>> advise >>>>>>> excise >>>>>>> >>>>>>> So what do your instincts tell you about these? Should we basically make >>>>>>> a list of words which should use z, and put it in our style guide? >>>>>>> >>>>>>> Making the changes will be a significant job, because there are >>>>>>> instances of similar words in French that mustn't be changed ("utilise", >>>>>>> for instance). I think it'll best be done with XSLT (which can be >>>>>>> language-aware, and ignore the French) and some very precise regexes. >>>>>>> >>>>>>> Cheers, >>>>>>> Martin >>>>>> >>>>> >>> >> > From rwelzenbach at gmail.com Thu Mar 1 14:50:19 2012 From: rwelzenbach at gmail.com (Rebecca Welzenbach) Date: Thu, 1 Mar 2012 14:50:19 -0500 Subject: [tei-council] Standardi[s|z]ation In-Reply-To: <4F4D9C2B.1060904@ultraslavonic.info> References: <4F4925E9.8020105@uvic.ca> <4F492BAC.2080904@retired.ox.ac.uk> <4F4A42E4.9050203@retired.ox.ac.uk> <4F4A46B3.9010508@ultraslavonic.info> <4F4A6C52.6060906@uvic.ca> <4F4ABB68.6060909@retired.ox.ac.uk> <4F4BAFD0.7060703@uvic.ca> <4F4D9C2B.1060904@ultraslavonic.info> Message-ID: <CAA2irt+2RsPLXnAf2K=atjtAnwnFXt6f-h5tV22UwNuR2AHEgA@mail.gmail.com> I would be happy to do this. On Tue, Feb 28, 2012 at 10:31 PM, Kevin Hawkins <kevin.s.hawkins at ultraslavonic.info> wrote: > Lou, I don't think Martin was suggesting that we duplicate the > information in three places. ?Instead, he suggested replacing > P5/Source/Guidelines/en/style-guide.txt and the relevant section of > tcw20 with a link to the new document, which would be a TEI document > named tcw23 or the next available "tcw" number at the time of creation. > ?I agree with this strategy. > > Perhaps one of our newer members would like to take on the task of > composing tcw23? ?Martin or I can handle updating tcw20 and > style-guide.txt once the new document is in place. > > On 2/27/12 11:31 AM, Martin Holmes wrote: >> The question really is whether it's best to maintain this information in >> a text file in the Guidelines source code, or as a more public document >> on the TEI website. In the latter case, it would be in P5 and benefit >> from transformation into richer XHTML, with links etc. working. >> >> I like the P5 option. It's currently part of TCW20 because it doesn't >> consist of much, but it's going to get bigger as we go along, so I think >> it deserves a document to itself. >> >> Cheers, >> Martin >> >> On 12-02-26 03:08 PM, Lou Burnard wrote: >>> Well, P5/Source/Guidelines/en/style-guide.txt is really only the >>> beginnings of a style guide. I copied the whole of it into tcw20.xml >>> because it seemed convenient to have everything in one place. By all >>> means let's work on elaborating it (and perhaps, when it gets bigger, >>> replacing it by a link in tcw20), but there's no need to maintain this >>> information in ?THREE places surely? >>> >>> >>> >>> the On 26/02/12 17:30, Martin Holmes wrote: >>>> I think we should spin off the styleguide into a separate Working Paper >>>> (since it's definitely a work in progress), and point to it from both >>>> locations. There's a lot of work to do here, assuming that we're going >>>> to maintain our own styleguide rather than adopt an existing one. It >>>> deserves its own document. >>>> >>>> Cheers, >>>> Martin >>>> >>>> On 12-02-26 06:50 AM, Kevin Hawkins wrote: >>>>> This seems like good policy to add to >>>>> http://www.tei-c.org/Activities/Council/Working/tcw20.xml#house-style-orthography >>>>> and I think also to P5/Source/Guidelines/en/style-guide.txt . >>>>> >>>>> It continues to bother me that we repeat information in these two >>>>> documents, which could easily fall out of sync. ?I would suggest having >>>>> one point to the other, but I'm not sure which should be primary. ?Thoughts? >>>>> >>>>> On 2/26/12 9:34 AM, Lou Burnard wrote: >>>>>> Further to my rather cryptic comment below: my recommendation is >>>>>> >>>>>> a) look up the word in the OED >>>>>> b) if it says that both -IZE and -ISE forms are usable, use the -IZE form. >>>>>> c) otherwise use the -ISE form. >>>>>> >>>>>> >>>>>> n 25/02/12 18:42, Lou Burnard wrote: >>>>>>> Michael Quinnion is good on this, (as on many other things) >>>>>>> >>>>>>> ? ? ? ? http://www.worldwidewords.org/qa/qa-ise1.htm >>>>>>> >>>>>>> The -IZE suffix only applize to words which (etymologically speaking) >>>>>>> come to use from a Latinized version of a Greek suffix. That's the >>>>>>> rationale given by the OED anyway. >>>>>>> >>>>>>> I don't think we should be guided by "instinct" here. Look em up. >>>>>>> >>>>>>> >>>>>>> On 25/02/12 18:18, Martin Holmes wrote: >>>>>>>> Hi all, >>>>>>>> >>>>>>>> One of Jens's excellent proofing reports suggests that we standardize >>>>>>>> spellings ending in -ise/-ize. I'm inclined to agree, and with -ise >>>>>>>> looking a bit beleaguered these days, I think it should be -ize. Lou >>>>>>>> agrees, on the ticket. >>>>>>>> >>>>>>>> So I ran this regex to see what we have: >>>>>>>> >>>>>>>> is((e[d|s]*)|(ing))\b >>>>>>>> >>>>>>>> It found 1529 instances, most of which aren't relevant ("otherwise", >>>>>>>> "raise" etc.). But amongst those which are, they don't all seem clear >>>>>>>> cut to me, though. I think these are uncontroversial: >>>>>>>> >>>>>>>> standardise >>>>>>>> normalise >>>>>>>> capitalise >>>>>>>> specialise >>>>>>>> summarise >>>>>>>> computerise >>>>>>>> italicise >>>>>>>> recognise >>>>>>>> regularise >>>>>>>> categorise >>>>>>>> >>>>>>>> But what about these? I feel instinctively less happy with changing >>>>>>>> these to z, for some reason: >>>>>>>> >>>>>>>> harmonise >>>>>>>> compromise >>>>>>>> analyse >>>>>>>> exercise >>>>>>>> utilise >>>>>>>> >>>>>>>> and I think these cannot be changed to z, even though, in many cases, >>>>>>>> variants with z are attested: >>>>>>>> >>>>>>>> comprise >>>>>>>> revise >>>>>>>> devise >>>>>>>> advise >>>>>>>> excise >>>>>>>> >>>>>>>> So what do your instincts tell you about these? Should we basically make >>>>>>>> a list of words which should use z, and put it in our style guide? >>>>>>>> >>>>>>>> Making the changes will be a significant job, because there are >>>>>>>> instances of similar words in French that mustn't be changed ("utilise", >>>>>>>> for instance). I think it'll best be done with XSLT (which can be >>>>>>>> language-aware, and ignore the French) and some very precise regexes. >>>>>>>> >>>>>>>> Cheers, >>>>>>>> Martin >>>>>>> >>>>>> >>>> >>> >> > -- > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > > PLEASE NOTE: postings to this list are publicly archived From kevin.s.hawkins at ultraslavonic.info Sun Mar 4 22:45:24 2012 From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins) Date: Sun, 04 Mar 2012 22:45:24 -0500 Subject: [tei-council] PR for TEI in Google Books (was Re: some brief reports to save time during our upcoming conf call) In-Reply-To: <CAC_Lu0a4ddMsKdqTfofgJA9XmLvFpJ_FC8LQAy9X0rBBiDTAQw@mail.gmail.com> References: <4F4978F8.205@ultraslavonic.info> <CAC_Lu0a4ddMsKdqTfofgJA9XmLvFpJ_FC8LQAy9X0rBBiDTAQw@mail.gmail.com> Message-ID: <4F5436D4.8040605@ultraslavonic.info> On 2/28/12 2:11 PM, Stuart A. Yeates wrote: > On Sun, Feb 26, 2012 at 1:12 PM, Kevin Hawkins > <kevin.s.hawkins at ultraslavonic.info> wrote: >> = Google Books = >> The importance of this for the TEI's PR can't really be understated. >> We, or the Board, might want to give some thought about whether to do >> anything more once Google deloys this code than simply announce it on >> TEI-L with shouts of hurrah/hooray/huzzah. > > I think it might be productive to have a few paragraphs contrasting > TEI texts and underlying openness to the closed and propriety nature > of formats currently in use by Amazon and OverDrive. > > I'm happy to write these, maybe with Kevin giving me some feedback? > > cheers > stuart I believe the teleconference discussion did not reach a conclusion on whether, once Google deploys their code, the TEI-C should (a) ride a way of publicity that might be generated in the community, (b) seek to create a wave, or (c) do nothing. In any case, I plan to act as a private citizen (not in my role as a Council member) in publicizing this since I personally believe it's significant, even if Google turns out TEI files that many of us think aren't all that usable. But in the case of (a) or (b), it would be good to have a text drafted by Stuart and me, with input from the rest of you, ready for when the appointed hour arrives. However, I don't know who should make an official statement on behalf of the TEI-C. Perhaps we don't need an official statement: instead, someone posts their own private announcement to TEI-L and then it gets added to the news feed on www.tei-c.org. Pretty soon it gets tweeted and then picked up by Digital Humanities Now, ProfHacker, the Times (London and New York), CNN, Fox News, Sky News, and of course the Sunday Sun, in which Mr. Murdoch is no doubt anxious to promote an open, non-proprietary format for interchange of digital text! --Kevin From gabriel.bodard at kcl.ac.uk Mon Mar 5 05:43:59 2012 From: gabriel.bodard at kcl.ac.uk (Gabriel Bodard) Date: Mon, 5 Mar 2012 10:43:59 +0000 Subject: [tei-council] PR for TEI in Google Books (was Re: some brief reports to save time during our upcoming conf call) In-Reply-To: <4F5436D4.8040605@ultraslavonic.info> References: <4F4978F8.205@ultraslavonic.info> <CAC_Lu0a4ddMsKdqTfofgJA9XmLvFpJ_FC8LQAy9X0rBBiDTAQw@mail.gmail.com> <4F5436D4.8040605@ultraslavonic.info> Message-ID: <4F5498EF.90001@kcl.ac.uk> For what it's worth, although Council may not have reached a conclusion, I am very much in favour of preparing to publicize this event. Even in the worst-case scenario where the TEI produced by Google is really really bad (or contains bad OCR), the fact that TEI is a format chosen to encode many many thousands of public domain texts is something that we can and should make a loud noise about. (And even if it's so bad, (a) that isn't our fault, and (b) hopefully someone will work to improve it.) In short: +1 G On 2012-03-05 03:45, Kevin Hawkins wrote: > On 2/28/12 2:11 PM, Stuart A. Yeates wrote: >> On Sun, Feb 26, 2012 at 1:12 PM, Kevin Hawkins >> <kevin.s.hawkins at ultraslavonic.info> wrote: >>> = Google Books = >>> The importance of this for the TEI's PR can't really be understated. >>> We, or the Board, might want to give some thought about whether to do >>> anything more once Google deloys this code than simply announce it on >>> TEI-L with shouts of hurrah/hooray/huzzah. >> >> I think it might be productive to have a few paragraphs contrasting >> TEI texts and underlying openness to the closed and propriety nature >> of formats currently in use by Amazon and OverDrive. >> >> I'm happy to write these, maybe with Kevin giving me some feedback? >> >> cheers >> stuart > > I believe the teleconference discussion did not reach a conclusion on > whether, once Google deploys their code, the TEI-C should (a) ride a way > of publicity that might be generated in the community, (b) seek to > create a wave, or (c) do nothing. In any case, I plan to act as a > private citizen (not in my role as a Council member) in publicizing this > since I personally believe it's significant, even if Google turns out > TEI files that many of us think aren't all that usable. > > But in the case of (a) or (b), it would be good to have a text drafted > by Stuart and me, with input from the rest of you, ready for when the > appointed hour arrives. However, I don't know who should make an > official statement on behalf of the TEI-C. Perhaps we don't need an > official statement: instead, someone posts their own private > announcement to TEI-L and then it gets added to the news feed on > www.tei-c.org. Pretty soon it gets tweeted and then picked up by > Digital Humanities Now, ProfHacker, the Times (London and New York), > CNN, Fox News, Sky News, and of course the Sunday Sun, in which Mr. > Murdoch is no doubt anxious to promote an open, non-proprietary format > for interchange of digital text! > > --Kevin -- Dr Gabriel BODARD (Research Associate in Digital Epigraphy) Department of Digital 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 Mar 5 05:50:31 2012 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 5 Mar 2012 10:50:31 +0000 Subject: [tei-council] PR for TEI in Google Books (was Re: some brief reports to save time during our upcoming conf call) In-Reply-To: <4F5498EF.90001@kcl.ac.uk> References: <4F4978F8.205@ultraslavonic.info> <CAC_Lu0a4ddMsKdqTfofgJA9XmLvFpJ_FC8LQAy9X0rBBiDTAQw@mail.gmail.com> <4F5436D4.8040605@ultraslavonic.info> <4F5498EF.90001@kcl.ac.uk> Message-ID: <10B41F85-FE85-4EC0-9301-A732FF929434@oucs.ox.ac.uk> On 5 Mar 2012, at 10:43, Gabriel Bodard wrote: > really really bad (or contains bad OCR), the fact that TEI is a format > chosen to encode many many thousands of public domain texts it would really be a big deal if Google released these texts as public domain?. but I don't think thats what you mean :-} -- Stormageddon Rahtz Head of Information and Support Group Oxford University Computing Services 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 Mon Mar 5 05:54:12 2012 From: gabriel.bodard at kcl.ac.uk (Gabriel Bodard) Date: Mon, 5 Mar 2012 10:54:12 +0000 Subject: [tei-council] PR for TEI in Google Books (was Re: some brief reports to save time during our upcoming conf call) In-Reply-To: <10B41F85-FE85-4EC0-9301-A732FF929434@oucs.ox.ac.uk> References: <4F4978F8.205@ultraslavonic.info> <CAC_Lu0a4ddMsKdqTfofgJA9XmLvFpJ_FC8LQAy9X0rBBiDTAQw@mail.gmail.com> <4F5436D4.8040605@ultraslavonic.info> <4F5498EF.90001@kcl.ac.uk> <10B41F85-FE85-4EC0-9301-A732FF929434@oucs.ox.ac.uk> Message-ID: <4F549B54.2040108@kcl.ac.uk> Well, the texts themselves are public domain. Do we know what license Google normally attach to otherwise PD texts that they release? (E.g. page scans.) I wonder what would be the point of releasing TEI versions of texts without licensing them for some kind of re-use...? Kevin, any insight on this? Any value in pushing in this direction? G On 2012-03-05 10:50, Sebastian Rahtz wrote: > > On 5 Mar 2012, at 10:43, Gabriel Bodard wrote: > >> really really bad (or contains bad OCR), the fact that TEI is a format >> chosen to encode many many thousands of public domain texts > > it would really be a big deal if Google released these texts > as public domain?. but I don't think thats what you mean :-} > > -- > Stormageddon Rahtz > Head of Information and Support Group > Oxford University Computing 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 (Research Associate in Digital Epigraphy) Department of Digital 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 retired.ox.ac.uk Mon Mar 5 05:57:46 2012 From: lou.burnard at retired.ox.ac.uk (Lou Burnard) Date: Mon, 05 Mar 2012 10:57:46 +0000 Subject: [tei-council] PR for TEI in Google Books (was Re: some brief reports to save time during our upcoming conf call) In-Reply-To: <4F549B54.2040108@kcl.ac.uk> References: <4F4978F8.205@ultraslavonic.info> <CAC_Lu0a4ddMsKdqTfofgJA9XmLvFpJ_FC8LQAy9X0rBBiDTAQw@mail.gmail.com> <4F5436D4.8040605@ultraslavonic.info> <4F5498EF.90001@kcl.ac.uk> <10B41F85-FE85-4EC0-9301-A732FF929434@oucs.ox.ac.uk> <4F549B54.2040108@kcl.ac.uk> Message-ID: <4F549C2A.1010406@retired.ox.ac.uk> I think Kevin did give us this impression during the teleconf. Certainly that's what the minutes (which I sent to James last night) say! I suspect my esteemed colleague Rahtz is trolling on the use of the phrase "public domain" On 05/03/12 10:54, Gabriel Bodard wrote: > Well, the texts themselves are public domain. Do we know what license > Google normally attach to otherwise PD texts that they release? (E.g. > page scans.) I wonder what would be the point of releasing TEI versions > of texts without licensing them for some kind of re-use...? > > Kevin, any insight on this? Any value in pushing in this direction? > > G > > On 2012-03-05 10:50, Sebastian Rahtz wrote: >> >> On 5 Mar 2012, at 10:43, Gabriel Bodard wrote: >> >>> really really bad (or contains bad OCR), the fact that TEI is a format >>> chosen to encode many many thousands of public domain texts >> >> it would really be a big deal if Google released these texts >> as public domain?. but I don't think thats what you mean :-} >> >> -- >> Stormageddon Rahtz >> Head of Information and Support Group >> Oxford University Computing Services >> 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 5 06:02:18 2012 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 5 Mar 2012 11:02:18 +0000 Subject: [tei-council] PR for TEI in Google Books (was Re: some brief reports to save time during our upcoming conf call) In-Reply-To: <4F549C2A.1010406@retired.ox.ac.uk> References: <4F4978F8.205@ultraslavonic.info> <CAC_Lu0a4ddMsKdqTfofgJA9XmLvFpJ_FC8LQAy9X0rBBiDTAQw@mail.gmail.com> <4F5436D4.8040605@ultraslavonic.info> <4F5498EF.90001@kcl.ac.uk> <10B41F85-FE85-4EC0-9301-A732FF929434@oucs.ox.ac.uk> <4F549B54.2040108@kcl.ac.uk> <4F549C2A.1010406@retired.ox.ac.uk> Message-ID: <2596d7e0-fbcf-491c-b823-d39cff890d35@HUB01.ad.oak.ox.ac.uk> "You may not sell, rent, lease, distribute, broadcast, transfer or assign your rights to the Google Digital Content or any part of it to any third party except as expressly permitted by Google " so I suspect there are no rights to re-use. -- Stormageddon Rahtz Head of Information and Support Group Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From kevin.s.hawkins at ultraslavonic.info Mon Mar 5 09:04:26 2012 From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins) Date: Mon, 05 Mar 2012 09:04:26 -0500 Subject: [tei-council] PR for TEI in Google Books (was Re: some brief reports to save time during our upcoming conf call) In-Reply-To: <4F549C2A.1010406@retired.ox.ac.uk> References: <4F4978F8.205@ultraslavonic.info> <CAC_Lu0a4ddMsKdqTfofgJA9XmLvFpJ_FC8LQAy9X0rBBiDTAQw@mail.gmail.com> <4F5436D4.8040605@ultraslavonic.info> <4F5498EF.90001@kcl.ac.uk> <10B41F85-FE85-4EC0-9301-A732FF929434@oucs.ox.ac.uk> <4F549B54.2040108@kcl.ac.uk> <4F549C2A.1010406@retired.ox.ac.uk> Message-ID: <4F54C7EA.6090006@ultraslavonic.info> While Google might plan to prepare TEI documents of in-copyright books scanned by their partners (to give back to the partners along with page images and OCR), I am concerned with the deployment of code to books.google.com for public-domain titles. This is what the general public would see. Here is a title that I believe everyone (even those outside of the US) can see in full: http://books.google.com/books?id=7nsCAAAAQAAJ If you click "Preview this book" and then click the gear icon in the upper right, you can choose to "Download PDF". They PDF that is generated has a page at the front which explains a bit about it and asks (though does not require) that you use it for non-commercial purposes. I expect that Google would do the same for a TEI document. As Gabby said, the work itself is in the public domain, and in the US you can't receive copyright protection for a reproduction of a public-domain work that doesn't involve new creative work. While reprints of public domain titles can sometimes receive copyright protection in some other countries, I doubt Google would assert such rights in specific countries. In short, we're talking about Google releasing these TEI documents into the public domain. On 3/5/12 5:57 AM, Lou Burnard wrote: > I think Kevin did give us this impression during the teleconf. Certainly > that's what the minutes (which I sent to James last night) say! > > I suspect my esteemed colleague Rahtz is trolling on the use of the > phrase "public domain" > > On 05/03/12 10:54, Gabriel Bodard wrote: >> Well, the texts themselves are public domain. Do we know what license >> Google normally attach to otherwise PD texts that they release? (E.g. >> page scans.) I wonder what would be the point of releasing TEI versions >> of texts without licensing them for some kind of re-use...? >> >> Kevin, any insight on this? Any value in pushing in this direction? >> >> G >> >> On 2012-03-05 10:50, Sebastian Rahtz wrote: >>> >>> On 5 Mar 2012, at 10:43, Gabriel Bodard wrote: >>> >>>> really really bad (or contains bad OCR), the fact that TEI is a format >>>> chosen to encode many many thousands of public domain texts >>> >>> it would really be a big deal if Google released these texts >>> as public domain?. but I don't think thats what you mean :-} >>> >>> -- >>> Stormageddon Rahtz >>> Head of Information and Support Group >>> Oxford University Computing Services >>> 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 5 09:18:12 2012 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 5 Mar 2012 14:18:12 +0000 Subject: [tei-council] PR for TEI in Google Books (was Re: some brief reports to save time during our upcoming conf call) In-Reply-To: <4F54C7EA.6090006@ultraslavonic.info> References: <4F4978F8.205@ultraslavonic.info> <CAC_Lu0a4ddMsKdqTfofgJA9XmLvFpJ_FC8LQAy9X0rBBiDTAQw@mail.gmail.com> <4F5436D4.8040605@ultraslavonic.info> <4F5498EF.90001@kcl.ac.uk> <10B41F85-FE85-4EC0-9301-A732FF929434@oucs.ox.ac.uk> <4F549B54.2040108@kcl.ac.uk> <4F549C2A.1010406@retired.ox.ac.uk> <4F54C7EA.6090006@ultraslavonic.info> Message-ID: <67EECFD4-BF42-4348-9937-170B965A0BB0@oucs.ox.ac.uk> I am not convinced. That PDF is just a set of images, isn't it? The TEI-ed XML version _would_ attract copyright, as there is substantial intellectual effort being put into the work. If you can show me a google book with the actual OCRed text being given to me with a free license, then I may believe?.. -- Stormageddon Rahtz Head of Information and Support Group Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From kevin.s.hawkins at ultraslavonic.info Mon Mar 5 09:29:26 2012 From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins) Date: Mon, 05 Mar 2012 09:29:26 -0500 Subject: [tei-council] PR for TEI in Google Books (was Re: some brief reports to save time during our upcoming conf call) In-Reply-To: <67EECFD4-BF42-4348-9937-170B965A0BB0@oucs.ox.ac.uk> References: <4F4978F8.205@ultraslavonic.info> <CAC_Lu0a4ddMsKdqTfofgJA9XmLvFpJ_FC8LQAy9X0rBBiDTAQw@mail.gmail.com> <4F5436D4.8040605@ultraslavonic.info> <4F5498EF.90001@kcl.ac.uk> <10B41F85-FE85-4EC0-9301-A732FF929434@oucs.ox.ac.uk> <4F549B54.2040108@kcl.ac.uk> <4F549C2A.1010406@retired.ox.ac.uk> <4F54C7EA.6090006@ultraslavonic.info> <67EECFD4-BF42-4348-9937-170B965A0BB0@oucs.ox.ac.uk> Message-ID: <4F54CDC6.8000806@ultraslavonic.info> Creative work is not the same as "sweat of the brow" in US copyright case law. It takes a lot of effort to compile a telephone book, but there's no creativity in its arrangement. So it is not copyrightable. Google has developed algorithms for inserting markup, but no TEI document created using this algorithm requires creativity. So the algorithm is copyrightable but not the documents it produces. In any case, no need to trust me. Let's just be ready with the PR announcement in case Google does not attach a copyright notice to the TEI document. If they do attach a copyright notice, I'll be ready to argue with the Google engineer that it's a spurious claim. On 3/5/12 9:18 AM, Sebastian Rahtz wrote: > I am not convinced. That PDF is just a set of images, isn't it? The TEI-ed XML version _would_ attract copyright, as there > is substantial intellectual effort being put into the work. If you can show me a google book with the actual OCRed text being > given to me with a free license, then I may believe?.. > -- > Stormageddon Rahtz > Head of Information and Support Group > Oxford University Computing Services > 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 > > S?lo le pido a Dios > que el futuro no me sea indiferente > From lou.burnard at retired.ox.ac.uk Mon Mar 5 09:44:04 2012 From: lou.burnard at retired.ox.ac.uk (Lou Burnard) Date: Mon, 05 Mar 2012 14:44:04 +0000 Subject: [tei-council] PR for TEI in Google Books (was Re: some brief reports to save time during our upcoming conf call) In-Reply-To: <4F54CDC6.8000806@ultraslavonic.info> References: <4F4978F8.205@ultraslavonic.info> <CAC_Lu0a4ddMsKdqTfofgJA9XmLvFpJ_FC8LQAy9X0rBBiDTAQw@mail.gmail.com> <4F5436D4.8040605@ultraslavonic.info> <4F5498EF.90001@kcl.ac.uk> <10B41F85-FE85-4EC0-9301-A732FF929434@oucs.ox.ac.uk> <4F549B54.2040108@kcl.ac.uk> <4F549C2A.1010406@retired.ox.ac.uk> <4F54C7EA.6090006@ultraslavonic.info> <67EECFD4-BF42-4348-9937-170B965A0BB0@oucs.ox.ac.uk> <4F54CDC6.8000806@ultraslavonic.info> Message-ID: <4F54D134.1010303@retired.ox.ac.uk> I was talking about this with another TEI Board member at lunch today, and she said "Of course what we really want is for it to be possible to export/import TEI format in Google Docs." That does seems like an interesting prospect worth raising with Mr Google, if we have the opportunity. Though I suppose that the part concerned with Google Docs and the part concerned with Google Books rarely meet. On 05/03/12 14:29, Kevin Hawkins wrote: > Creative work is not the same as "sweat of the brow" in US copyright > case law. It takes a lot of effort to compile a telephone book, but > there's no creativity in its arrangement. So it is not copyrightable. > > Google has developed algorithms for inserting markup, but no TEI > document created using this algorithm requires creativity. So the > algorithm is copyrightable but not the documents it produces. > > In any case, no need to trust me. Let's just be ready with the PR > announcement in case Google does not attach a copyright notice to the > TEI document. If they do attach a copyright notice, I'll be ready to > argue with the Google engineer that it's a spurious claim. > > On 3/5/12 9:18 AM, Sebastian Rahtz wrote: >> I am not convinced. That PDF is just a set of images, isn't it? The TEI-ed XML version _would_ attract copyright, as there >> is substantial intellectual effort being put into the work. If you can show me a google book with the actual OCRed text being >> given to me with a free license, then I may believe?.. >> -- >> Stormageddon Rahtz >> Head of Information and Support Group >> Oxford University Computing Services >> 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 5 10:14:34 2012 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 5 Mar 2012 15:14:34 +0000 Subject: [tei-council] PR for TEI in Google Books (was Re: some brief reports to save time during our upcoming conf call) In-Reply-To: <4F54D134.1010303@retired.ox.ac.uk> References: <4F4978F8.205@ultraslavonic.info> <CAC_Lu0a4ddMsKdqTfofgJA9XmLvFpJ_FC8LQAy9X0rBBiDTAQw@mail.gmail.com> <4F5436D4.8040605@ultraslavonic.info> <4F5498EF.90001@kcl.ac.uk> <10B41F85-FE85-4EC0-9301-A732FF929434@oucs.ox.ac.uk> <4F549B54.2040108@kcl.ac.uk> <4F549C2A.1010406@retired.ox.ac.uk> <4F54C7EA.6090006@ultraslavonic.info> <67EECFD4-BF42-4348-9937-170B965A0BB0@oucs.ox.ac.uk> <4F54CDC6.8000806@ultraslavonic.info> <4F54D134.1010303@retired.ox.ac.uk> Message-ID: <d8286125-0e61-403d-937b-ecb163af81c0@HUB01.ad.oak.ox.ac.uk> On 5 Mar 2012, at 14:44, Lou Burnard wrote: > I was talking about this with another TEI Board member at lunch today, > and she said "Of course what we really want is for it to be possible to > export/import TEI format in Google Docs." She wants a mare's nest? Google Docs is a weak imitation of Microsoft Word, with all the concomitant issues of lack of nesting. you can of course convert TEI to/from word-processor formats using OxGarage, and use the results in GiggleDocs, if thats your wish. But I agree with your surmise, that the different parts of Google are quite unlikely to talk to each other. -- Stormageddon Rahtz Head of Information and Support Group Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From kevin.s.hawkins at ultraslavonic.info Mon Mar 5 12:23:00 2012 From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins) Date: Mon, 05 Mar 2012 12:23:00 -0500 Subject: [tei-council] Proposal to clarify and rationalize encoding of pagination in bibliographic citations Message-ID: <4F54F674.6030404@ultraslavonic.info> Folks, As I mentioned during our conf call, the Ad-Hoc Commmittee on Encoding of Bibliographic Citations has been working on a proposal to handle the remaining thorny issue for citations: clarifying and rationalizing encoding of pagination in bibliographic citations. Since the comment thread on the open ticket in SourceForge had grown quite long, we have formulated a full, clean, unified proposal: http://www.tei-c.org/Activities/Council/Working/tcw23.xml I've started a new SourceForge feature request to allow for a public discussion: http://purl.org/TEI/fr/3497079 I hope we'll be able to consider this at the meeting in Ann Arbor, if not before. Kevin From James.Cummings at oucs.ox.ac.uk Mon Mar 5 16:40:16 2012 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Mon, 05 Mar 2012 21:40:16 +0000 Subject: [tei-council] PR for TEI in Google Books (was Re: some brief reports to save time during our upcoming conf call) In-Reply-To: <4F5436D4.8040605@ultraslavonic.info> References: <4F4978F8.205@ultraslavonic.info> <CAC_Lu0a4ddMsKdqTfofgJA9XmLvFpJ_FC8LQAy9X0rBBiDTAQw@mail.gmail.com> <4F5436D4.8040605@ultraslavonic.info> Message-ID: <4F5532C0.60909@oucs.ox.ac.uk> On 05/03/12 03:45, Kevin Hawkins wrote: > I believe the teleconference discussion did not reach a conclusion on > whether, once Google deploys their code, the TEI-C should (a) ride a way > of publicity that might be generated in the community, (b) seek to > create a wave, or (c) do nothing. In any case, I plan to act as a > private citizen (not in my role as a Council member) in publicizing this > since I personally believe it's significant, even if Google turns out > TEI files that many of us think aren't all that usable. Although some had reservations about the quality of the TEI that Google would be producing, I don' think anyone doubts that Google making any large number of texts available in some form of TEI is potentially beneficial to the TEI. I would support the TEI-C using this publicity to attract people to the TEI who might not have heard of it. > appointed hour arrives. However, I don't know who should make an > official statement on behalf of the TEI-C. I'm of the opinion that official press releases on behalf of the consortium or such should come from the Board via the Chair. I hope that we'll have some warning before this comes about and they'll have time to draft something. I'll mention it to JohnU as an item to discuss at the next board meeting. But yes, this does not stop anyone talking about it in a private capacity. I'm of the opinion that when any of us are posting (e.g. to TEI-L) that we're doing so in such a capacity unless we say something like "The TEI Technical Council asks that....". > Perhaps we don't need an > official statement: instead, someone posts their own private > announcement to TEI-L and then it gets added to the news feed on > www.tei-c.org. Only thanks to David Sewell and the helpful band of news posters, I only mention it to take any opportunity to thank them. -James -- Dr James Cummings, InfoDev Oxford University Computing Services University of Oxford From James.Cummings at oucs.ox.ac.uk Mon Mar 5 16:48:42 2012 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Mon, 05 Mar 2012 21:48:42 +0000 Subject: [tei-council] Minutes of 2012-02-28 telco Message-ID: <4F5534BA.5030803@oucs.ox.ac.uk> The minutes for the 2012-02-28 teleconference are up at: http://www.tei-c.org/Activities/Council/Meetings/tcm49.xml Let me (or Lou) know of any changes or corrections. Best, -James -- Dr James Cummings, InfoDev Oxford University Computing Services University of Oxford From James.Cummings at oucs.ox.ac.uk Tue Mar 6 16:34:48 2012 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Tue, 06 Mar 2012 21:34:48 +0000 Subject: [tei-council] Programme Committee for TEI Members' Meeting and Conference Message-ID: <4F5682F8.60902@oucs.ox.ac.uk> Hi all, Can I ask for a volunteer to join me on the Board's ad hoc Programme/Organizational Committee for this year's TEI Conference? This will be hosted at Texas A&M University, and it might make sense if it was someone who was planning to attend. Best, -James -- Dr James Cummings, InfoDev Oxford University Computing Services University of Oxford From kevin.s.hawkins at ultraslavonic.info Tue Mar 6 19:35:40 2012 From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins) Date: Tue, 06 Mar 2012 19:35:40 -0500 Subject: [tei-council] PR for TEI in Google Books (was Re: some brief reports to save time during our upcoming conf call) In-Reply-To: <4F54D134.1010303@retired.ox.ac.uk> References: <4F4978F8.205@ultraslavonic.info> <CAC_Lu0a4ddMsKdqTfofgJA9XmLvFpJ_FC8LQAy9X0rBBiDTAQw@mail.gmail.com> <4F5436D4.8040605@ultraslavonic.info> <4F5498EF.90001@kcl.ac.uk> <10B41F85-FE85-4EC0-9301-A732FF929434@oucs.ox.ac.uk> <4F549B54.2040108@kcl.ac.uk> <4F549C2A.1010406@retired.ox.ac.uk> <4F54C7EA.6090006@ultraslavonic.info> <67EECFD4-BF42-4348-9937-170B965A0BB0@oucs.ox.ac.uk> <4F54CDC6.8000806@ultraslavonic.info> <4F54D134.1010303@retired.ox.ac.uk> Message-ID: <4F56AD5C.2040008@ultraslavonic.info> I've asked our Google contact and suggested a couple of ways we might move forward on this. The worst he can do is say no! On 3/5/2012 9:44 AM, Lou Burnard wrote: > I was talking about this with another TEI Board member at lunch today, > and she said "Of course what we really want is for it to be possible to > export/import TEI format in Google Docs." > > That does seems like an interesting prospect worth raising with Mr > Google, if we have the opportunity. Though I suppose that the part > concerned with Google Docs and the part concerned with Google Books > rarely meet. From kevin.s.hawkins at ultraslavonic.info Tue Mar 6 21:40:03 2012 From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins) Date: Tue, 06 Mar 2012 21:40:03 -0500 Subject: [tei-council] Fwd: Re: Google Books > TEI In-Reply-To: <CAHScxsXxO188J7bFBH929-r2btB1ajB8Fv=ESNPerXjVgEb24g@mail.gmail.com> References: <CAHScxsXxO188J7bFBH929-r2btB1ajB8Fv=ESNPerXjVgEb24g@mail.gmail.com> Message-ID: <4F56CA83.8050704@ultraslavonic.info> All, I'm forwarding two messages from our contact at Google (cc'd here), where he answers the questions that came up during our last conference call with some requests for further information from us. He accidentally sent the second message sent only to me rather than to our whole committee, so I'm copying Laurent as well since he's no longer on the TEI Council. (Ranjith, to prevent spam, only members can post to tei-council, but I can forward messages from you to the group.) ---Kevin -------- Original Message -------- Subject: Re: Google Books > TEI Date: Mon, 5 Mar 2012 15:43:13 -0800 From: Ranjith Unnikrishnan <ranjith at google.com> To: Kevin Hawkins <kevin.s.hawkins at ultraslavonic.info> CC: James.Cummings at oucs.ox.ac.uk, mholmes at uvic.ca, laurent.romary at inria.fr Hi Kevin, Responses are inline. 1. Would Google be willing to release the code used for the transformation from Google's internal data format to TEI? We realize the code might wouldn't be useful to anyone without the underlying data, but it might help users who are trying to understand what you produce and what errors are likely. I personally don't think this is likely because (i) in addition to the source material we'd have to open-source our internal data format for the code to make any sense, and (ii) during the course of processing, the code interacts with many internal storage systems that cannot be made publicly accessible. That said, the significant errors originate not from the process of converting our internal data format to TEI, but from poor OCR and/or structure analysis. So I'm not convinced that looking at the conversion code would serve the purpose of better understanding the errors. The bulk of the OCR work is done using the Tesseract OCR engine, which is open-source and is updated periodically, and so may be a better place for interested parties to look. 2. Will there be a mechanism for users to report errors in the TEI files or submit revised TEI files? This might relate to the work you're doing with James Cummings and others on matching TEI documents with scanned editions of the same source document. This was my hope and intention from the start, but we don't have a feedback mechanism for this at the moment and I'm not sure what the best scalable solution is. In fact I'm eager to get your ideas on this since, as both stewards and users of the format, you are in a better position than us to guide and drive this correction process in the community of TEI users. I'm not sure of the document matching work that you're referring to, but I am working with James to import some public-domain material that he can provide. My end of the work requires setting up the infrastructure to ingest ePub files directly into our corpus so that it is freely available to a broader audience via the Google Books website. In that respect, the work could relate to your comment as it should result in a way to import whole corrected TEI files (via an intermediate conversion to ePub). On a related note, you may be aware of an early stage project out of Texas A&M University that is aimed at digitizing 18th century books via crowd-sourcing in combination with OCR. I've been trying to motivate them to use TEI as an input/output format so that when we eventually provide TEI files for public domain books, they will have a free source of input material to correct, and secondly if they wish to return the corrected TEI files to us to make freely available on Google Books then it will benefit everyone and every community involved. I don't know if they're completely on board with this vision, but I do know that some of the tools they plan to use do accept TEI. ~Ranjith -------- Original Message -------- Subject: Re: scope of Google Books > TEI Date: Tue, 6 Mar 2012 17:36:31 -0800 From: Ranjith Unnikrishnan <ranjith at google.com> To: Kevin Hawkins <kevin.s.hawkins at ultraslavonic.info> Actually, I'd like to turn that question around if you don't mind. Can you give some convincing arguments as to why such a release, if it were to happen, would be useful to the community? The reason I'm asking is that we're still in early days and at this point I'm one of the few voices advocating making TEI files available in the manner you describe. If you can provide me some arguments, preferably with some backing numbers, around the impact you anticipate this having, it would help bolster my position and help move this forward. On Tue, Mar 6, 2012 at 4:26 PM, Kevin Hawkins <kevin.s.hawkins at ultraslavonic.info <mailto:kevin.s.hawkins at ultraslavonic.info>> wrote: One more question, Ranjith: will this code, once deployed, make TEI available as a download format for all material in the public domain in the user's location? Do you have a sense of how many titles this will affect in Google Books? The TEI Consortium would like to be ready to generate publicity around this, so having some stats will help. From kevin.s.hawkins at ultraslavonic.info Tue Mar 6 22:00:14 2012 From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins) Date: Tue, 06 Mar 2012 22:00:14 -0500 Subject: [tei-council] Programme Committee for TEI Members' Meeting and Conference In-Reply-To: <4F5682F8.60902@oucs.ox.ac.uk> References: <4F5682F8.60902@oucs.ox.ac.uk> Message-ID: <4F56CF3E.6030301@ultraslavonic.info> James, has it been decided -- or are you at liberty to say yet -- what dates the conference will be held? I imagine that will affect who is planning to attend. --Kevin On 3/6/12 4:34 PM, James Cummings wrote: > > Hi all, > > Can I ask for a volunteer to join me on the Board's ad hoc > Programme/Organizational Committee for this year's TEI > Conference? This will be hosted at Texas A&M University, and it > might make sense if it was someone who was planning to attend. > > Best, > > -James > From kevin.s.hawkins at ultraslavonic.info Tue Mar 6 22:49:22 2012 From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins) Date: Tue, 06 Mar 2012 22:49:22 -0500 Subject: [tei-council] Fwd: Re: TEI for Google Docs? In-Reply-To: <4F56BDF3.5020909@uvic.ca> References: <4F56BDF3.5020909@uvic.ca> Message-ID: <4F56DAC2.5070308@ultraslavonic.info> Another message where we could use broader input than what our small group, formed to offer technical advice on samples, can come up with on our own. -------- Original Message -------- Subject: Re: TEI for Google Docs? Date: Tue, 6 Mar 2012 17:46:27 -0800 From: Martin Holmes <mholmes at uvic.ca> Reply-To: mholmes at uvic.ca Organization: UVic HCMC To: Ranjith Unnikrishnan <ranjith at google.com> CC: Kevin Hawkins <kevin.s.hawkins at ultraslavonic.info>, "James.Cummings at oucs.ox.ac.uk" <James.Cummings at oucs.ox.ac.uk>, "laurent.romary at inria.fr" <laurent.romary at inria.fr> On 12-03-06 05:38 PM, Ranjith Unnikrishnan wrote: > Interesting suggestion. I'm not sure if the Docs team would be > interested in supporting export to TEI but can ask. What would the use > of such functionality be? One example: Various journals and conferences in our field use TEI as the format for abstracts and papers. People would be able to author these documents in Google Docs and save them in TEI. Cheers, Martin > On Tue, Mar 6, 2012 at 4:34 PM, Kevin Hawkins > <kevin.s.hawkins at ultraslavonic.info > <mailto:kevin.s.hawkins at ultraslavonic.info>> wrote: > > Hi again Ranjith, > > I've been hearing of interest in our community of having Google Docs > export in TEI. I think this would actually be fairly easy. There > are two ways we could proceed: > > a) Produce a Google Docs file that includes at least one instance of > every paragraph style, list style, and formatting (bold, italic, > etc.). Then one of us produces this same document encoded in TEI for > you. > > b) Produce a mapping of every paragraph style, list style, and > formatting (bold, italic, etc.) in Google Docs to TEI elements, > explaining how to build the hierarchy. > > Please let us know if either of these would work for you! > > Kevin > > -- Martin Holmes University of Victoria Humanities Computing and Media Centre (mholmes at uvic.ca) From rwelzenbach at gmail.com Wed Mar 7 09:48:33 2012 From: rwelzenbach at gmail.com (Rebecca Welzenbach) Date: Wed, 7 Mar 2012 09:48:33 -0500 Subject: [tei-council] Fwd: Re: Google Books > TEI In-Reply-To: <4F56CA83.8050704@ultraslavonic.info> References: <CAHScxsXxO188J7bFBH929-r2btB1ajB8Fv=ESNPerXjVgEb24g@mail.gmail.com> <4F56CA83.8050704@ultraslavonic.info> Message-ID: <CAA2irtJs0PfM8=FgJdRC3FxK7Oqu_U9_=8R3PRLbFOam6qka0w@mail.gmail.com> Thanks for all of this Kevin....very interesting. More thoughts and questions below.... Becky > ? ?2. Will there be a mechanism for users to report errors in the TEI > ? ?files or submit revised TEI files? ?This might relate to the work > ? ?you're doing with James Cummings and others on matching TEI > ? ?documents with scanned editions of the same source document. > > > This was my hope and intention from the start, but we don't have a > feedback mechanism for this at the moment and I'm not sure what the best > scalable solution is. In fact I'm eager to get your ideas on this since, > as both stewards and users of the format, you are in a better position > than us to guide and drive this correction process in the community of > TEI users. Ranjith's commet is in line with my (admittedly vague) sense of what Google currently allows: that you can report errors, but this simply puts the reported book back on a queue to be re-scanned and re-OCRed. One challenge here may be that Google doesn't want corrections inserted in the middle or at the end of their workflow, because if the book is ever re-processed, by accident or on purpose, those changes would be lost. > > I'm not sure of the document matching work that you're referring to, but > I am working with James to import some public-domain material that he > can provide. My end of the work requires setting up the infrastructure > to ingest ePub files directly into our corpus so that it is freely > available to a broader audience via the Google Books website. In that > respect, the work could relate to your comment as it should result in a > way to import whole corrected TEI files (via an intermediate conversion > to ePub). James, these are the ECCO-TCP texts (and perhaps other Oxford Text Archive texts), right? If matching the texts up to scanned books is *not* part of this work, does that mean that from Google's perspective these works would only consist of electronic text, and no page images? That's the part that seemed to me like it might tie in with the development of a text feedback mechanism, because it implies a workflow where the electronic text is the original object, rather than the output of another process (in contrast with the current scan + OCR model). If text is 1) going to be accepted from the outside in the first place and 2) Not going to be generated or overwritten by a Google engine, building a way to make or recommend corrections to the text starts to look more reasonable. > > On a related note, you may be aware of an early stage project out of > Texas A&M University that is aimed at digitizing 18th century books via > crowd-sourcing in combination with OCR. I've been trying to motivate > them to use TEI as an input/output format so that when we eventually > provide TEI files for public domain books, they will have a free source > of input material to correct, and secondly if they wish to return the > corrected TEI files to us to make freely available on Google Books then > it will benefit everyone and every community involved. I don't know if > they're completely on board with this vision, but I do know that some of > the tools they plan to use do accept TEI. Very interesting! I'm aware of the work at Texas A&M (the TCP has provided lots of 18th-century texts to them for testing this OCR) and glad to hear that they're in touch with Google about it. I agree it would be nice if they could generate TEI as an output, but I'm not sure I understand what is meant by TEI as an input. Since this work involves OCR, isn't the desired input format just the page images? My understanding of the project at Texas A&M is that the goal is to train OCR to successfully capture characters in books/fonts where this is currently still too hard to do. If this project is successful, it would be great if the tool they build could be used to generate more accurate OCR for older books in Google's corpus. But I'm not sure that crowdsourced correction of existing electronic text fits into the mission of their project. > Actually, I'd like to turn that question around if you don't mind. Can > you give some convincing arguments as to why such a release, if it were > to happen, would be useful to the community? > The reason I'm asking is that we're still in early days and at this > point I'm one of the few voices advocating making TEI files available in > the manner you describe. If you can provide me some arguments, > preferably with some backing numbers, around the impact you anticipate > this having, it would help bolster my position and help move this forward. > > > On Tue, Mar 6, 2012 at 4:26 PM, Kevin Hawkins > <kevin.s.hawkins at ultraslavonic.info > <mailto:kevin.s.hawkins at ultraslavonic.info>> wrote: > > ? ?One more question, Ranjith: will this code, once deployed, make TEI > ? ?available as a download format for all material in the public domain > ? ?in the user's location? ?Do you have a sense of how many titles this > ? ?will affect in Google Books? ?The TEI Consortium would like to be > ? ?ready to generate publicity around this, so having some stats will help. > I'm not sure I understand what Ranjith wants here. Is this a request for justification of making the TEI available for download, or justification for doing TEI at all? If the TEI files would not be available for download, what's the point of producing it? From James.Cummings at oucs.ox.ac.uk Wed Mar 7 10:32:04 2012 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Wed, 07 Mar 2012 15:32:04 +0000 Subject: [tei-council] Programme Committee for TEI Members' Meeting and Conference In-Reply-To: <4F56CF3E.6030301@ultraslavonic.info> References: <4F5682F8.60902@oucs.ox.ac.uk> <4F56CF3E.6030301@ultraslavonic.info> Message-ID: <4F577F74.6040507@oucs.ox.ac.uk> On 07/03/12 03:00, Kevin Hawkins wrote: > James, has it been decided -- or are you at liberty to say yet -- what > dates the conference will be held? I imagine that will affect who is > planning to attend. --Kevin It certainly isn't my place to announce the details. Hypothetically, an educated guess would probably expect it to be on (and the days surrounding) say 10 November or so. Are you volunteering Kevin? -James -- Dr James Cummings, InfoDev, Computing Services, University of Oxford From kevin.s.hawkins at ultraslavonic.info Wed Mar 7 10:43:46 2012 From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins) Date: Wed, 07 Mar 2012 10:43:46 -0500 Subject: [tei-council] Programme Committee for TEI Members' Meeting and Conference In-Reply-To: <4F577F74.6040507@oucs.ox.ac.uk> References: <4F5682F8.60902@oucs.ox.ac.uk> <4F56CF3E.6030301@ultraslavonic.info> <4F577F74.6040507@oucs.ox.ac.uk> Message-ID: <4F578232.8090303@ultraslavonic.info> On 3/7/2012 10:32 AM, James Cummings wrote: > On 07/03/12 03:00, Kevin Hawkins wrote: >> James, has it been decided -- or are you at liberty to say yet -- what >> dates the conference will be held? I imagine that will affect who is >> planning to attend. --Kevin > > It certainly isn't my place to announce the details. > Hypothetically, an educated guess would probably expect it to be > on (and the days surrounding) say 10 November or so. > > Are you volunteering Kevin? No. :( Just asking in order to move the discussion forward. From rwelzenbach at gmail.com Wed Mar 7 11:00:00 2012 From: rwelzenbach at gmail.com (Rebecca Welzenbach) Date: Wed, 7 Mar 2012 11:00:00 -0500 Subject: [tei-council] Programme Committee for TEI Members' Meeting and Conference In-Reply-To: <4F578232.8090303@ultraslavonic.info> References: <4F5682F8.60902@oucs.ox.ac.uk> <4F56CF3E.6030301@ultraslavonic.info> <4F577F74.6040507@oucs.ox.ac.uk> <4F578232.8090303@ultraslavonic.info> Message-ID: <CAA2irt+mbgVCfgnx+yxaJkL7ELsKRDGiA=DKJb7XNkxiwkopyg@mail.gmail.com> I would be happy to be on the program committee. I intend to make attending the TEI Meeting a priority this year, but (as Kevin suggests), I guess I won't know for sure until we know the dates. Becky On Wed, Mar 7, 2012 at 10:43 AM, Kevin Hawkins <kevin.s.hawkins at ultraslavonic.info> wrote: > On 3/7/2012 10:32 AM, James Cummings wrote: >> On 07/03/12 03:00, Kevin Hawkins wrote: >>> James, has it been decided -- or are you at liberty to say yet -- what >>> dates the conference will be held? ?I imagine that will affect who is >>> planning to attend. ?--Kevin >> >> It certainly isn't my place to announce the details. >> Hypothetically, an educated guess would probably expect it to be >> on (and the days surrounding) say 10 November or so. >> >> Are you volunteering Kevin? > > No. ?:( ?Just asking in order to move the discussion forward. > -- > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > > PLEASE NOTE: postings to this list are publicly archived From James.Cummings at oucs.ox.ac.uk Wed Mar 7 12:13:07 2012 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Wed, 07 Mar 2012 17:13:07 +0000 Subject: [tei-council] Fwd: Re: Google Books > TEI In-Reply-To: <CAA2irtJs0PfM8=FgJdRC3FxK7Oqu_U9_=8R3PRLbFOam6qka0w@mail.gmail.com> References: <CAHScxsXxO188J7bFBH929-r2btB1ajB8Fv=ESNPerXjVgEb24g@mail.gmail.com> <4F56CA83.8050704@ultraslavonic.info> <CAA2irtJs0PfM8=FgJdRC3FxK7Oqu_U9_=8R3PRLbFOam6qka0w@mail.gmail.com> Message-ID: <4F579723.8080706@oucs.ox.ac.uk> On 07/03/12 14:48, Rebecca Welzenbach wrote: > James, these are the ECCO-TCP texts (and perhaps other Oxford Text > Archive texts), right? Yes, I believe these would be ECCO-TCP and eventually potentially EEBO-TCP conversions along with other texts from the OTA converted to TEI P5 and then to EPub. > If matching the texts up to scanned books is > *not* part of this work, does that mean that from Google's perspective > these works would only consist of electronic text, and no page images? The idea, from my point of view, might be that you could download the EPub on your android phone using the google Books application. Presumably, the matching up would mean that where there was a Google Books scanned book of this, they could offer the EPub as an alternative to download or something. > That's the part that seemed to me like it might tie in with the > development of a text feedback mechanism, because it implies a > workflow where the electronic text is the original object, rather than > the output of another process (in contrast with the current scan + OCR > model). If text is 1) going to be accepted from the outside in the > first place and 2) Not going to be generated or overwritten by a > Google engine, building a way to make or recommend corrections to the > text starts to look more reasonable. I think this would be treated as a separate but related object. -James -- Dr James Cummings, InfoDev, Computing Services, University of Oxford From James.Cummings at oucs.ox.ac.uk Fri Mar 9 12:30:56 2012 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Fri, 09 Mar 2012 17:30:56 +0000 Subject: [tei-council] Fwd: Re: Google Books > TEI In-Reply-To: <CAHScxsWcSq5Yp=xcmJbTGW3cKrKBrVdpJuhj1cG_=+AS-NvJcA@mail.gmail.com> References: <CAHScxsXxO188J7bFBH929-r2btB1ajB8Fv=ESNPerXjVgEb24g@mail.gmail.com> <4F56CA83.8050704@ultraslavonic.info> <CAA2irtJs0PfM8=FgJdRC3FxK7Oqu_U9_=8R3PRLbFOam6qka0w@mail.gmail.com> <CAHScxsWcSq5Yp=xcmJbTGW3cKrKBrVdpJuhj1cG_=+AS-NvJcA@mail.gmail.com> Message-ID: <4F5A3E50.7020508@oucs.ox.ac.uk> On 07/03/12 18:48, Ranjith Unnikrishnan wrote: > I'm looking for formal justification from you for our producing > and making TEI files available for download on Google Books. Both > require our commitment of several resources for the long term eg. > for updating and maintaining code, making necessary changes in > our processing pipeline, maintaining the download functionality > for the lifetime of Google Books, committing to the extra storage > space and computation etc. I have some anecdotal knowledge of why > TEI is important, and have already spent a substantial amount of > personal time writing the code and vetting the converted TEI > output along with various interested parties; so we know it is > possible and obviously I have an interest in seeing this all the > way through. But since this will be "product"-level decision, > there are others who will need to be convinced and will ask the > big questions such as: Hi Ranjith, I'm more than happy to work with you in coming up with some executive summary kind of answers to these questions if that will help. How about I share a google doc with you and some of the others of the ad hoc working group. > Hope that makes sense. I'm just trying to move this effort > forward with your input. We really appreciate that and all your hard work. We're more than happy to work with you in any way to benefit TEI users. I'll share a google doc link from my gapps account soon. -James -- Dr James Cummings, InfoDev, Computing Services, University of Oxford From mholmes at uvic.ca Tue Mar 13 14:21:15 2012 From: mholmes at uvic.ca (Martin Holmes) Date: Tue, 13 Mar 2012 11:21:15 -0700 Subject: [tei-council] Question about an attribute definition Message-ID: <4F5F901B.2090608@uvic.ca> This is relevant to <http://purl.org/TEI/BUGS/3455686>. I was looking at att.global.analytic, and noticed this: [quote] ana (analysis) Datatype 1?? occurrences of data.pointer separated by whitespace Values one or more valid identifiers of one or more interpretive elements (usually fs or interp), separated by white space. [/quote] I'm not really sure whether the valDesc reflects the datatype properly in this case. Is "valid identifiers" really the same thing as data.pointers? Cheers, Martin -- Martin Holmes University of Victoria Humanities Computing and Media Centre (mholmes at uvic.ca) From PFSchaffner at umich.edu Wed Mar 14 12:00:39 2012 From: PFSchaffner at umich.edu (Paul F. Schaffner) Date: Wed, 14 Mar 2012 12:00:39 -0400 (EDT) Subject: [tei-council] Ann Arbor <-> DTW transportation In-Reply-To: <4F5F901B.2090608@uvic.ca> References: <4F5F901B.2090608@uvic.ca> Message-ID: <Pine.LNX.4.64.1203141154150.16107@goldenaxe.gpcc.itd.umich.edu> In case it went unnoticed and might prove useful to some, I should point out that a cheaper and more frequent bus service between Detroit Metro Airport (DTW) and central Ann Arbor is scheduled to begin on 2 April: http://michiganflyer.com/ann-arbor-airride-schedules.asp http://www.theride.org/PRAirRide.asp I will also be glad to provide pickup service. (Even at the Windsor railway station, Lou.) pfs -------------------------------------------------------------------- Paul Schaffner | PFSchaffner at umich.edu | http://www.umich.edu/~pfs/ 316-C Hatcher Library N, Univ. of Michigan, Ann Arbor MI 48109-1190 -------------------------------------------------------------------- From mholmes at uvic.ca Wed Mar 14 12:36:42 2012 From: mholmes at uvic.ca (Martin Holmes) Date: Wed, 14 Mar 2012 09:36:42 -0700 Subject: [tei-council] Ann Arbor <-> DTW transportation In-Reply-To: <Pine.LNX.4.64.1203141154150.16107@goldenaxe.gpcc.itd.umich.edu> References: <4F5F901B.2090608@uvic.ca> <Pine.LNX.4.64.1203141154150.16107@goldenaxe.gpcc.itd.umich.edu> Message-ID: <4F60C91A.7080501@uvic.ca> This looks handy. I'm arriving about 5.30pm on the Sunday -- I'm assuming these buses run on Sundays -- so I could be on the 6.30. Of the three final stops: Kensington Hotel AA/BTC Blake Transit Ctr AA/CCTC Central Campus which is best for where we're staying? Cheers, Martin On 12-03-14 09:00 AM, Paul F. Schaffner wrote: > In case it went unnoticed and might prove useful to some, I should > point out that a cheaper and more frequent bus service between Detroit > Metro Airport (DTW) and central Ann Arbor is scheduled to begin on 2 > April: > > http://michiganflyer.com/ann-arbor-airride-schedules.asp > > http://www.theride.org/PRAirRide.asp > > I will also be glad to provide pickup service. (Even at the > Windsor railway station, Lou.) > > pfs > -------------------------------------------------------------------- > Paul Schaffner | PFSchaffner at umich.edu | http://www.umich.edu/~pfs/ > 316-C Hatcher Library N, Univ. of Michigan, Ann Arbor MI 48109-1190 > -------------------------------------------------------------------- -- Martin Holmes University of Victoria Humanities Computing and Media Centre (mholmes at uvic.ca) From lou.burnard at retired.ox.ac.uk Wed Mar 14 15:48:51 2012 From: lou.burnard at retired.ox.ac.uk (Lou Burnard) Date: Wed, 14 Mar 2012 19:48:51 +0000 Subject: [tei-council] Ann Arbor <-> DTW transportation In-Reply-To: <Pine.LNX.4.64.1203141154150.16107@goldenaxe.gpcc.itd.umich.edu> References: <4F5F901B.2090608@uvic.ca> <Pine.LNX.4.64.1203141154150.16107@goldenaxe.gpcc.itd.umich.edu> Message-ID: <4F60F623.3070105@retired.ox.ac.uk> On 14/03/12 16:00, Paul F. Schaffner wrote: > I will also be glad to provide pickup service. (Even at the > Windsor railway station, Lou.) > Thanks for this generous offer, but I've revised my travel plans -- I'm now spending the Friday night in Chicago and catching the Wolverine all the way down to Ann Arbor on Saturday! Though I might need some help getting to DTW in time for a 1922 departure on Wednesday (only way I could get a reasonable open jaw fare) From mholmes at uvic.ca Wed Mar 14 16:25:00 2012 From: mholmes at uvic.ca (Martin Holmes) Date: Wed, 14 Mar 2012 13:25:00 -0700 Subject: [tei-council] Ann Arbor <-> DTW transportation In-Reply-To: <4F60F623.3070105@retired.ox.ac.uk> References: <4F5F901B.2090608@uvic.ca> <Pine.LNX.4.64.1203141154150.16107@goldenaxe.gpcc.itd.umich.edu> <4F60F623.3070105@retired.ox.ac.uk> Message-ID: <4F60FE9C.4090708@uvic.ca> I'm leaving on a 6pm plane on Wednesday, so I'll have to take off before you do. We could share transport if you're willing to leave early. Cheers, Martin On 12-03-14 12:48 PM, Lou Burnard wrote: > On 14/03/12 16:00, Paul F. Schaffner wrote: > >> I will also be glad to provide pickup service. (Even at the >> Windsor railway station, Lou.) >> > > Thanks for this generous offer, but I've revised my travel plans -- I'm > now spending the Friday night in Chicago and catching the Wolverine all > the way down to Ann Arbor on Saturday! > > Though I might need some help getting to DTW in time for a 1922 > departure on Wednesday (only way I could get a reasonable open jaw fare) > > -- Martin Holmes University of Victoria Humanities Computing and Media Centre (mholmes at uvic.ca) From PFSchaffner at umich.edu Wed Mar 14 16:35:40 2012 From: PFSchaffner at umich.edu (Paul F. Schaffner) Date: Wed, 14 Mar 2012 16:35:40 -0400 (EDT) Subject: [tei-council] Ann Arbor <-> DTW transportation In-Reply-To: <4F60C91A.7080501@uvic.ca> References: <4F5F901B.2090608@uvic.ca> <Pine.LNX.4.64.1203141154150.16107@goldenaxe.gpcc.itd.umich.edu> <4F60C91A.7080501@uvic.ca> Message-ID: <Pine.LNX.4.64.1203141545160.952@rygar.gpcc.itd.umich.edu> On Wed, 14 Mar 2012, Martin Holmes wrote: > This looks handy. I'm arriving about 5.30pm on the Sunday -- I'm > assuming these buses run on Sundays Since the service is new, I'd assume nothing. But we'll keep watch to find out! > Kensington Hotel > AA/BTC Blake Transit Ctr > AA/CCTC Central Campus > which is best for where we're staying? The last of these three. The first is 2.5 miles to the south (out by the interstate); the second is a ten-minute walk to the west; and the third is a five-minute walk to the east from the Bell Tower Hotel. Hmm, I haven't tried this mapmaking site before, but maybe it will work: http://www.communitywalk.com/map/index/1488824#101 at 0010742.13if8-83.2dSP0 pfs -------------------------------------------------------------------- Paul Schaffner | PFSchaffner at umich.edu | http://www.umich.edu/~pfs/ 316-C Hatcher Library N, Univ. of Michigan, Ann Arbor MI 48109-1190 -------------------------------------------------------------------- From lou.burnard at retired.ox.ac.uk Sun Mar 18 15:47:12 2012 From: lou.burnard at retired.ox.ac.uk (Lou Burnard) Date: Sun, 18 Mar 2012 19:47:12 +0000 Subject: [tei-council] ticket triage Message-ID: <4F663BC0.5080902@retired.ox.ac.uk> A quick look at http://www.tei-c.org/Activities/Council/Working/tcw17.html shows the following state of play... GREEN tickets (11 bugs; 5 Feature Requests) May I suggest that Council members should take a quick look initially at the GREEN tickets? As far as I can tell, what needs to be done is fairly self evident in each case (that's the definition of GREEN, after all). Furthermore, each GREEN ticket (with one exception, see below) has been assigned to someone for action. All you need do therefore is post a message to the list if you disagree with the action being proposed for the ticket. The exception is bug 3437782. This is a ticket I created and on which no-one has commented so far; I am reluctant to assign it to myself and just do it, even though I think it should just be done. So please express your views on that one! AMBER tickets (18 bugs; 13 Feature requests) Several of them are on overlapping topics (e.g. we have three or four talking about <wit>, and more than one worrying about the use of <idno>) so I think we should be able to group them together and dispose of quite a few in Chicago. I'll have a shot at doing that (the grouping) next, in consultation with James when he comes back from his hols. RED tickets (4 red; 11 feature requests) Some of these are quite old (the oldest goes back to 2007) so maybe we should find some way of indicating topics that we are giving up on for the moment. Feel free, of course, to add comments on any ticket if you think the discussion is in need of it. From sebastian.rahtz at oucs.ox.ac.uk Sun Mar 18 19:24:58 2012 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Sun, 18 Mar 2012 23:24:58 +0000 Subject: [tei-council] ticket triage In-Reply-To: <4F663BC0.5080902@retired.ox.ac.uk> References: <4F663BC0.5080902@retired.ox.ac.uk> Message-ID: <7668ea3a-de70-490b-964b-f134bb6ea3fa@HUB02.ad.oak.ox.ac.uk> On 18 Mar 2012, at 19:47, Lou Burnard wrote: > May I suggest that Council members should take a quick look initially at > the GREEN tickets? added some comments where i can > > The exception is bug 3437782. This is a ticket I created and on which > no-one has commented so far; I am reluctant to assign it to myself and > just do it, even though I think it should just be done. So please > express your views on that one! have done so, with a heavy heart -- Stormageddon Rahtz Head of Information and Support Group, Oxford University Computing Services 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 20 05:55:55 2012 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 20 Mar 2012 09:55:55 +0000 Subject: [tei-council] ticket triage In-Reply-To: <4F663BC0.5080902@retired.ox.ac.uk> References: <4F663BC0.5080902@retired.ox.ac.uk> Message-ID: <a76cce4d-9319-42a3-9ac9-552591e2e69a@HUB04.ad.oak.ox.ac.uk> On 18 Mar 2012, at 19:47, Lou Burnard wrote: > May I suggest that Council members should take a quick look initially at > the GREEN tickets? added some comments where i can > > The exception is bug 3437782. This is a ticket I created and on which > no-one has commented so far; I am reluctant to assign it to myself and > just do it, even though I think it should just be done. So please > express your views on that one! have done so, with a heavy heart -- Stormageddon Rahtz Head of Information and Support Group, Oxford University Computing Services 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 Mar 23 14:16:42 2012 From: mholmes at uvic.ca (Martin Holmes) Date: Fri, 23 Mar 2012 11:16:42 -0700 Subject: [tei-council] <egXML> example Message-ID: <4F6CBE0A.6050307@uvic.ca> Hi there, Why is the first example on this page flagged as incorrect? <http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-egXML.html> I don't actually see what's wrong with it, but even if it is wrong, it's mightily confusing to have as the first example of an element proclaiming itself as incorrect, surely? What am I missing? Cheers, Martin -- Martin Holmes University of Victoria Humanities Computing and Media Centre (mholmes at uvic.ca) From PFSchaffner at umich.edu Fri Mar 23 15:20:48 2012 From: PFSchaffner at umich.edu (Paul F. Schaffner) Date: Fri, 23 Mar 2012 15:20:48 -0400 (EDT) Subject: [tei-council] <egXML> example In-Reply-To: <4F6CBE0A.6050307@uvic.ca> References: <4F6CBE0A.6050307@uvic.ca> Message-ID: <Pine.LNX.4.64.1203231519030.15262@zaxxon.gpcc.itd.umich.edu> Umm, because "fr" does not stand for "English" ? pfs On Fri, 23 Mar 2012, Martin Holmes wrote: > Hi there, > > Why is the first example on this page flagged as incorrect? > > <http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-egXML.html> > > I don't actually see what's wrong with it, but even if it is wrong, it's > mightily confusing to have as the first example of an element > proclaiming itself as incorrect, surely? What am I missing? > > Cheers, > Martin > > -- > Martin Holmes > University of Victoria Humanities Computing and Media Centre > (mholmes at uvic.ca) > -- > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > > PLEASE NOTE: postings to this list are publicly archived > > > -------------------------------------------------------------------- Paul Schaffner | PFSchaffner at umich.edu | http://www.umich.edu/~pfs/ 316-C Hatcher Library N, Univ. of Michigan, Ann Arbor MI 48109-1190 -------------------------------------------------------------------- From lou.burnard at retired.ox.ac.uk Fri Mar 23 15:39:35 2012 From: lou.burnard at retired.ox.ac.uk (Lou Burnard) Date: Fri, 23 Mar 2012 19:39:35 +0000 Subject: [tei-council] <egXML> example In-Reply-To: <Pine.LNX.4.64.1203231519030.15262@zaxxon.gpcc.itd.umich.edu> References: <4F6CBE0A.6050307@uvic.ca>, <Pine.LNX.4.64.1203231519030.15262@zaxxon.gpcc.itd.umich.edu> Message-ID: <5C0990DE-01B4-4C56-859B-7CD0066EF2C0@retired.ox.ac.uk> I think Martins question wasnt so much what's wrong as why is a wrong example here. The answer is because we wanted to test the mechanism which renders wrong examples colourfully I believe. Sent from my HTC ----- Reply message ----- From: "Paul F. Schaffner" <PFSchaffner at umich.edu> To: "Martin Holmes" <mholmes at uvic.ca> Cc: "TEI Council" <tei-council at lists.village.virginia.edu> Subject: [tei-council] <egXML> example Date: Fri, Mar 23, 2012 19:20 Umm, because "fr" does not stand for "English" ? pfs On Fri, 23 Mar 2012, Martin Holmes wrote: > Hi there, > > Why is the first example on this page flagged as incorrect? > > <http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-egXML.html> > > I don't actually see what's wrong with it, but even if it is wrong, it's > mightily confusing to have as the first example of an element > proclaiming itself as incorrect, surely? What am I missing? > > Cheers, > Martin > > -- > Martin Holmes > University of Victoria Humanities Computing and Media Centre > (mholmes at uvic.ca) > -- > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > > PLEASE NOTE: postings to this list are publicly archived > > > -------------------------------------------------------------------- Paul Schaffner | PFSchaffner at umich.edu | http://www.umich.edu/~pfs/ 316-C Hatcher Library N, Univ. of Michigan, Ann Arbor MI 48109-1190 -------------------------------------------------------------------- -- tei-council mailing list tei-council at lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council PLEASE NOTE: postings to this list are publicly archived From rwelzenbach at gmail.com Fri Mar 23 15:56:10 2012 From: rwelzenbach at gmail.com (Rebecca Welzenbach) Date: Fri, 23 Mar 2012 15:56:10 -0400 Subject: [tei-council] <egXML> example In-Reply-To: <5C0990DE-01B4-4C56-859B-7CD0066EF2C0@retired.ox.ac.uk> References: <4F6CBE0A.6050307@uvic.ca> <Pine.LNX.4.64.1203231519030.15262@zaxxon.gpcc.itd.umich.edu> <5C0990DE-01B4-4C56-859B-7CD0066EF2C0@retired.ox.ac.uk> Message-ID: <CAA2irtJaayR2ejZd9O8KrvVEsvLYM_11XfwBm7uo2sewxNgM3A@mail.gmail.com> Part of Martin's question seems easy: in cases like this can we just flip the examples around so a correct one appears first and an incorrect one second (so we don't say what not to do without first saying what to do). But I am also confused about why this example is flagged as incorrect. Although <language ident="fr">English</language> is clearly wrong, I would expect an example identified as "incorrect" to be wrong in the way it uses the element it is demonstrating--not to have some other error inside of it. Is there something wrong with how <egXML> is being used in this example? Becky On Fri, Mar 23, 2012 at 3:39 PM, Lou Burnard <lou.burnard at retired.ox.ac.uk> wrote: > I think Martins question wasnt so much what's wrong as why is a wrong example here. ? The answer is because we wanted to test the mechanism which renders wrong examples colourfully I believe. > Sent from my HTC > > ----- Reply message ----- > From: "Paul F. Schaffner" <PFSchaffner at umich.edu> > To: "Martin Holmes" <mholmes at uvic.ca> > Cc: "TEI Council" <tei-council at lists.village.virginia.edu> > Subject: [tei-council] <egXML> example > Date: Fri, Mar 23, 2012 19:20 > > > > > Umm, because "fr" does not stand for "English" ? > > pfs > > > On Fri, 23 Mar 2012, Martin Holmes wrote: > >> Hi there, >> >> Why is the first example on this page flagged as incorrect? >> >> <http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-egXML.html> >> >> I don't actually see what's wrong with it, but even if it is wrong, it's >> mightily confusing to have as the first example of an element >> proclaiming itself as incorrect, surely? What am I missing? >> >> Cheers, >> Martin >> >> -- >> Martin Holmes >> University of Victoria Humanities Computing and Media Centre >> (mholmes at uvic.ca) >> -- >> tei-council mailing list >> tei-council at lists.village.Virginia.EDU >> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council >> >> PLEASE NOTE: postings to this list are publicly archived >> >> >> > > -------------------------------------------------------------------- > Paul Schaffner | PFSchaffner at umich.edu | http://www.umich.edu/~pfs/ > 316-C Hatcher Library N, Univ. of Michigan, Ann Arbor MI 48109-1190 > -------------------------------------------------------------------- > -- > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > > PLEASE NOTE: postings to this list are publicly archived > -- > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > > PLEASE NOTE: postings to this list are publicly archived From mholmes at uvic.ca Fri Mar 23 16:38:11 2012 From: mholmes at uvic.ca (Martin Holmes) Date: Fri, 23 Mar 2012 13:38:11 -0700 Subject: [tei-council] <egXML> example In-Reply-To: <CAA2irtJaayR2ejZd9O8KrvVEsvLYM_11XfwBm7uo2sewxNgM3A@mail.gmail.com> References: <4F6CBE0A.6050307@uvic.ca> <Pine.LNX.4.64.1203231519030.15262@zaxxon.gpcc.itd.umich.edu> <5C0990DE-01B4-4C56-859B-7CD0066EF2C0@retired.ox.ac.uk> <CAA2irtJaayR2ejZd9O8KrvVEsvLYM_11XfwBm7uo2sewxNgM3A@mail.gmail.com> Message-ID: <4F6CDF33.5010706@uvic.ca> This is actually more complex than we thought: I'd actually missed the language mismatch error, because I was looking for something that was wrong with the use of <egXML>. But now I've looked at the source, I see this: <exemplum xml:lang="en"> <egXML xmlns="http://www.tei-c.org/ns/Examples" xml:lang="und" valid="false"> <![CDATA[ <egXML xmlns="http://www.tei-c.org/ns/Examples"> <langUsage> <language ident="fr">English</language> </langUsage> </egXML> <!-- Though syntactically valid, this example is incorrect --> ]]> </egXML> </exemplum> The purpose of the "incorrect" example seems to be to demonstrate the usage of the @valid attribute, here set to false. However, there's a use-mention problem in the rendering of the page, and the result is that instead of seeing how to flag an incorrect example as invalid, the example itself is flagged as invalid. At this point, my heart goes out to Sebastian, whose stylesheets are expected to be able to tell the difference between using an attribute designed to show that examples are invalid, on an example of an example, and exemplifying the use of that attribute. Ye gods and little fishes, as me old dad used to say. Cheers, Martin On 12-03-23 12:56 PM, Rebecca Welzenbach wrote: > Part of Martin's question seems easy: in cases like this can we just > flip the examples around so a correct one appears first and an > incorrect one second (so we don't say what not to do without first > saying what to do). > But I am also confused about why this example is flagged as incorrect. > Although<language ident="fr">English</language> is clearly wrong, I > would expect an example identified as "incorrect" to be wrong in the > way it uses the element it is demonstrating--not to have some other > error inside of it. Is there something wrong with how<egXML> is being > used in this example? > > Becky > > On Fri, Mar 23, 2012 at 3:39 PM, Lou Burnard > <lou.burnard at retired.ox.ac.uk> wrote: >> I think Martins question wasnt so much what's wrong as why is a wrong example here. The answer is because we wanted to test the mechanism which renders wrong examples colourfully I believe. >> Sent from my HTC >> >> ----- Reply message ----- >> From: "Paul F. Schaffner"<PFSchaffner at umich.edu> >> To: "Martin Holmes"<mholmes at uvic.ca> >> Cc: "TEI Council"<tei-council at lists.village.virginia.edu> >> Subject: [tei-council]<egXML> example >> Date: Fri, Mar 23, 2012 19:20 >> >> >> >> >> Umm, because "fr" does not stand for "English" ? >> >> pfs >> >> >> On Fri, 23 Mar 2012, Martin Holmes wrote: >> >>> Hi there, >>> >>> Why is the first example on this page flagged as incorrect? >>> >>> <http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-egXML.html> >>> >>> I don't actually see what's wrong with it, but even if it is wrong, it's >>> mightily confusing to have as the first example of an element >>> proclaiming itself as incorrect, surely? What am I missing? >>> >>> Cheers, >>> Martin >>> >>> -- >>> Martin Holmes >>> University of Victoria Humanities Computing and Media Centre >>> (mholmes at uvic.ca) >>> -- >>> tei-council mailing list >>> tei-council at lists.village.Virginia.EDU >>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council >>> >>> PLEASE NOTE: postings to this list are publicly archived >>> >>> >>> >> >> -------------------------------------------------------------------- >> Paul Schaffner | PFSchaffner at umich.edu | http://www.umich.edu/~pfs/ >> 316-C Hatcher Library N, Univ. of Michigan, Ann Arbor MI 48109-1190 >> -------------------------------------------------------------------- >> -- >> tei-council mailing list >> tei-council at lists.village.Virginia.EDU >> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council >> >> PLEASE NOTE: postings to this list are publicly archived >> -- >> tei-council mailing list >> tei-council at lists.village.Virginia.EDU >> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council >> >> PLEASE NOTE: postings to this list are publicly archived > . > -- Martin Holmes University of Victoria Humanities Computing and Media Centre (mholmes at uvic.ca) From mholmes at uvic.ca Fri Mar 23 16:56:17 2012 From: mholmes at uvic.ca (Martin Holmes) Date: Fri, 23 Mar 2012 13:56:17 -0700 Subject: [tei-council] <egXML> example In-Reply-To: <4F6CDF33.5010706@uvic.ca> References: <4F6CBE0A.6050307@uvic.ca> <Pine.LNX.4.64.1203231519030.15262@zaxxon.gpcc.itd.umich.edu> <5C0990DE-01B4-4C56-859B-7CD0066EF2C0@retired.ox.ac.uk> <CAA2irtJaayR2ejZd9O8KrvVEsvLYM_11XfwBm7uo2sewxNgM3A@mail.gmail.com> <4F6CDF33.5010706@uvic.ca> Message-ID: <4F6CE371.9000003@uvic.ca> I just tried to submit a bug for this, and the Tracker appeared to accept it, but now it doesn't appear anywhere. I wonder if it's because I quoted the egXML code which has a CDATA section in it? I'll try again later. Cheers, Martin On 12-03-23 01:38 PM, Martin Holmes wrote: > This is actually more complex than we thought: > > I'd actually missed the language mismatch error, because I was looking > for something that was wrong with the use of<egXML>. But now I've > looked at the source, I see this: > > <exemplum xml:lang="en"> > <egXML xmlns="http://www.tei-c.org/ns/Examples" xml:lang="und" > valid="false"> > <![CDATA[ > <egXML xmlns="http://www.tei-c.org/ns/Examples"> > <langUsage> > <language ident="fr">English</language> > </langUsage> > </egXML> > <!-- Though syntactically valid, this example is incorrect --> > ]]> > </egXML> > </exemplum> > > The purpose of the "incorrect" example seems to be to demonstrate the > usage of the @valid attribute, here set to false. However, there's a > use-mention problem in the rendering of the page, and the result is that > instead of seeing how to flag an incorrect example as invalid, the > example itself is flagged as invalid. > > At this point, my heart goes out to Sebastian, whose stylesheets are > expected to be able to tell the difference between using an attribute > designed to show that examples are invalid, on an example of an example, > and exemplifying the use of that attribute. Ye gods and little fishes, > as me old dad used to say. > > Cheers, > Martin > > > On 12-03-23 12:56 PM, Rebecca Welzenbach wrote: >> Part of Martin's question seems easy: in cases like this can we just >> flip the examples around so a correct one appears first and an >> incorrect one second (so we don't say what not to do without first >> saying what to do). > >> But I am also confused about why this example is flagged as incorrect. >> Although<language ident="fr">English</language> is clearly wrong, I >> would expect an example identified as "incorrect" to be wrong in the >> way it uses the element it is demonstrating--not to have some other >> error inside of it. Is there something wrong with how<egXML> is being >> used in this example? >> >> Becky >> >> On Fri, Mar 23, 2012 at 3:39 PM, Lou Burnard >> <lou.burnard at retired.ox.ac.uk> wrote: >>> I think Martins question wasnt so much what's wrong as why is a wrong example here. The answer is because we wanted to test the mechanism which renders wrong examples colourfully I believe. >>> Sent from my HTC >>> >>> ----- Reply message ----- >>> From: "Paul F. Schaffner"<PFSchaffner at umich.edu> >>> To: "Martin Holmes"<mholmes at uvic.ca> >>> Cc: "TEI Council"<tei-council at lists.village.virginia.edu> >>> Subject: [tei-council]<egXML> example >>> Date: Fri, Mar 23, 2012 19:20 >>> >>> >>> >>> >>> Umm, because "fr" does not stand for "English" ? >>> >>> pfs >>> >>> >>> On Fri, 23 Mar 2012, Martin Holmes wrote: >>> >>>> Hi there, >>>> >>>> Why is the first example on this page flagged as incorrect? >>>> >>>> <http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-egXML.html> >>>> >>>> I don't actually see what's wrong with it, but even if it is wrong, it's >>>> mightily confusing to have as the first example of an element >>>> proclaiming itself as incorrect, surely? What am I missing? >>>> >>>> Cheers, >>>> Martin >>>> >>>> -- >>>> Martin Holmes >>>> University of Victoria Humanities Computing and Media Centre >>>> (mholmes at uvic.ca) >>>> -- >>>> tei-council mailing list >>>> tei-council at lists.village.Virginia.EDU >>>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council >>>> >>>> PLEASE NOTE: postings to this list are publicly archived >>>> >>>> >>>> >>> >>> -------------------------------------------------------------------- >>> Paul Schaffner | PFSchaffner at umich.edu | http://www.umich.edu/~pfs/ >>> 316-C Hatcher Library N, Univ. of Michigan, Ann Arbor MI 48109-1190 >>> -------------------------------------------------------------------- >>> -- >>> tei-council mailing list >>> tei-council at lists.village.Virginia.EDU >>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council >>> >>> PLEASE NOTE: postings to this list are publicly archived >>> -- >>> tei-council mailing list >>> tei-council at lists.village.Virginia.EDU >>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council >>> >>> PLEASE NOTE: postings to this list are publicly archived >> . >> > -- Martin Holmes University of Victoria Humanities Computing and Media Centre (mholmes at uvic.ca) From mholmes at uvic.ca Fri Mar 23 16:57:35 2012 From: mholmes at uvic.ca (Martin Holmes) Date: Fri, 23 Mar 2012 13:57:35 -0700 Subject: [tei-council] <egXML> example In-Reply-To: <4F6CE371.9000003@uvic.ca> References: <4F6CBE0A.6050307@uvic.ca> <Pine.LNX.4.64.1203231519030.15262@zaxxon.gpcc.itd.umich.edu> <5C0990DE-01B4-4C56-859B-7CD0066EF2C0@retired.ox.ac.uk> <CAA2irtJaayR2ejZd9O8KrvVEsvLYM_11XfwBm7uo2sewxNgM3A@mail.gmail.com> <4F6CDF33.5010706@uvic.ca> <4F6CE371.9000003@uvic.ca> Message-ID: <4F6CE3BF.7030407@uvic.ca> The missing bug mysteriously appeared: <http://purl.org/TEI/BUGS/3510653> Cheers, Martin On 12-03-23 01:56 PM, Martin Holmes wrote: > I just tried to submit a bug for this, and the Tracker appeared to > accept it, but now it doesn't appear anywhere. I wonder if it's because > I quoted the egXML code which has a CDATA section in it? > > I'll try again later. > > Cheers, > Martin > > On 12-03-23 01:38 PM, Martin Holmes wrote: >> This is actually more complex than we thought: >> >> I'd actually missed the language mismatch error, because I was looking >> for something that was wrong with the use of<egXML>. But now I've >> looked at the source, I see this: >> >> <exemplum xml:lang="en"> >> <egXML xmlns="http://www.tei-c.org/ns/Examples" xml:lang="und" >> valid="false"> >> <![CDATA[ >> <egXML xmlns="http://www.tei-c.org/ns/Examples"> >> <langUsage> >> <language ident="fr">English</language> >> </langUsage> >> </egXML> >> <!-- Though syntactically valid, this example is incorrect --> >> ]]> >> </egXML> >> </exemplum> >> >> The purpose of the "incorrect" example seems to be to demonstrate the >> usage of the @valid attribute, here set to false. However, there's a >> use-mention problem in the rendering of the page, and the result is that >> instead of seeing how to flag an incorrect example as invalid, the >> example itself is flagged as invalid. >> >> At this point, my heart goes out to Sebastian, whose stylesheets are >> expected to be able to tell the difference between using an attribute >> designed to show that examples are invalid, on an example of an example, >> and exemplifying the use of that attribute. Ye gods and little fishes, >> as me old dad used to say. >> >> Cheers, >> Martin >> >> >> On 12-03-23 12:56 PM, Rebecca Welzenbach wrote: >>> Part of Martin's question seems easy: in cases like this can we just >>> flip the examples around so a correct one appears first and an >>> incorrect one second (so we don't say what not to do without first >>> saying what to do). >> >>> But I am also confused about why this example is flagged as incorrect. >>> Although<language ident="fr">English</language> is clearly wrong, I >>> would expect an example identified as "incorrect" to be wrong in the >>> way it uses the element it is demonstrating--not to have some other >>> error inside of it. Is there something wrong with how<egXML> is being >>> used in this example? >>> >>> Becky >>> >>> On Fri, Mar 23, 2012 at 3:39 PM, Lou Burnard >>> <lou.burnard at retired.ox.ac.uk> wrote: >>>> I think Martins question wasnt so much what's wrong as why is a wrong example here. The answer is because we wanted to test the mechanism which renders wrong examples colourfully I believe. >>>> Sent from my HTC >>>> >>>> ----- Reply message ----- >>>> From: "Paul F. Schaffner"<PFSchaffner at umich.edu> >>>> To: "Martin Holmes"<mholmes at uvic.ca> >>>> Cc: "TEI Council"<tei-council at lists.village.virginia.edu> >>>> Subject: [tei-council]<egXML> example >>>> Date: Fri, Mar 23, 2012 19:20 >>>> >>>> >>>> >>>> >>>> Umm, because "fr" does not stand for "English" ? >>>> >>>> pfs >>>> >>>> >>>> On Fri, 23 Mar 2012, Martin Holmes wrote: >>>> >>>>> Hi there, >>>>> >>>>> Why is the first example on this page flagged as incorrect? >>>>> >>>>> <http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-egXML.html> >>>>> >>>>> I don't actually see what's wrong with it, but even if it is wrong, it's >>>>> mightily confusing to have as the first example of an element >>>>> proclaiming itself as incorrect, surely? What am I missing? >>>>> >>>>> Cheers, >>>>> Martin >>>>> >>>>> -- >>>>> Martin Holmes >>>>> University of Victoria Humanities Computing and Media Centre >>>>> (mholmes at uvic.ca) >>>>> -- >>>>> tei-council mailing list >>>>> tei-council at lists.village.Virginia.EDU >>>>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council >>>>> >>>>> PLEASE NOTE: postings to this list are publicly archived >>>>> >>>>> >>>>> >>>> >>>> -------------------------------------------------------------------- >>>> Paul Schaffner | PFSchaffner at umich.edu | http://www.umich.edu/~pfs/ >>>> 316-C Hatcher Library N, Univ. of Michigan, Ann Arbor MI 48109-1190 >>>> -------------------------------------------------------------------- >>>> -- >>>> tei-council mailing list >>>> tei-council at lists.village.Virginia.EDU >>>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council >>>> >>>> PLEASE NOTE: postings to this list are publicly archived >>>> -- >>>> tei-council mailing list >>>> tei-council at lists.village.Virginia.EDU >>>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council >>>> >>>> PLEASE NOTE: postings to this list are publicly archived >>> . >>> >> > -- Martin Holmes University of Victoria Humanities Computing and Media Centre (mholmes at uvic.ca) From sebastian.rahtz at oucs.ox.ac.uk Sat Mar 24 09:45:39 2012 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Sat, 24 Mar 2012 13:45:39 +0000 Subject: [tei-council] <egXML> example In-Reply-To: <4F6CDF33.5010706@uvic.ca> References: <4F6CBE0A.6050307@uvic.ca> <Pine.LNX.4.64.1203231519030.15262@zaxxon.gpcc.itd.umich.edu> <5C0990DE-01B4-4C56-859B-7CD0066EF2C0@retired.ox.ac.uk> <CAA2irtJaayR2ejZd9O8KrvVEsvLYM_11XfwBm7uo2sewxNgM3A@mail.gmail.com> <4F6CDF33.5010706@uvic.ca> Message-ID: <0C8224DC-3A7D-4D6A-BC0A-4444CDF4DE0B@oucs.ox.ac.uk> this thing does seem extraordinary. if we revert to <exemplum xml:lang="en"> <egXML xmlns="http://www.tei-c.org/ns/Examples" xml:lang="und"> <![CDATA[<egXML xmlns="http://www.tei-c.org/ns/Examples"> <langUsage> <language ident="fr">French</language> </langUsage> </egXML>]]> </egXML> </exemplum> it is entirely valid, but misleading, cos the XML is not XML just looks like it. so I feel inclined to keep "valid=false", lose the comment, and correct the semantics. if you wonder its in CDATA to avoid the whole thing being processed. -- Sebastian Rahtz Head of Information and Support Group, Oxford University Computing Services 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 Mar 24 10:50:59 2012 From: mholmes at uvic.ca (Martin Holmes) Date: Sat, 24 Mar 2012 07:50:59 -0700 Subject: [tei-council] <egXML> example In-Reply-To: <0C8224DC-3A7D-4D6A-BC0A-4444CDF4DE0B@oucs.ox.ac.uk> References: <4F6CBE0A.6050307@uvic.ca> <Pine.LNX.4.64.1203231519030.15262@zaxxon.gpcc.itd.umich.edu> <5C0990DE-01B4-4C56-859B-7CD0066EF2C0@retired.ox.ac.uk> <CAA2irtJaayR2ejZd9O8KrvVEsvLYM_11XfwBm7uo2sewxNgM3A@mail.gmail.com> <4F6CDF33.5010706@uvic.ca> <0C8224DC-3A7D-4D6A-BC0A-4444CDF4DE0B@oucs.ox.ac.uk> Message-ID: <4F6DDF53.5000601@uvic.ca> I think I just had an aha moment: If the purpose of the example is to illustrate the use of @valid, then @valid needs also to be on the embedded CDATA <egXML> as well as the outer one: <exemplum xml:lang="en"> <egXML xmlns="http://www.tei-c.org/ns/Examples" xml:lang="und" valid="false"> <![CDATA[ <egXML xmlns="http://www.tei-c.org/ns/Examples" valid="false"> <langUsage> <language ident="fr">English</language> </langUsage> </egXML> <!-- Though syntactically valid, this example is incorrect --> ]]> </egXML> </exemplum> The comment also needs to point out what is being illustrated: <!-- Though syntactically valid, this example is incorrect because the text of the <language> element does not match its @ident value. Therefore the attribute @valid is set to false. --> Now, if I'm right, the purpose of the example will be apparent. I've implemented that change and we'll see what the result looks like when Jinks has finished with it in an hour or so: <http://teijenkins.hcmc.uvic.ca:8080/job/TEIP5-Documentation/lastSuccessfulBuild/artifact/Guidelines-web/en/html/ref-egXML.html> I'm still not sure if we should have that as the first example of <egXML>, but that's a different question. Cheers, Martin On 12-03-24 06:45 AM, Sebastian Rahtz wrote: > this thing does seem extraordinary. if we revert to > > <exemplum xml:lang="en"> > <egXML xmlns="http://www.tei-c.org/ns/Examples" xml:lang="und"> > <![CDATA[<egXML xmlns="http://www.tei-c.org/ns/Examples"> > <langUsage> > <language ident="fr">French</language> > </langUsage> > </egXML>]]> > </egXML> > </exemplum> > > it is entirely valid, but misleading, cos the XML is not XML just > looks like it. so I feel inclined to keep "valid=false", lose the comment, > and correct the semantics. > > if you wonder its in CDATA to avoid the whole thing being processed. > -- > Sebastian Rahtz > Head of Information and Support Group, Oxford University Computing Services > 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 > > S?lo le pido a Dios > que el futuro no me sea indiferente > > > From lou.burnard at retired.ox.ac.uk Sat Mar 24 11:25:39 2012 From: lou.burnard at retired.ox.ac.uk (Lou Burnard) Date: Sat, 24 Mar 2012 15:25:39 +0000 Subject: [tei-council] <egXML> example In-Reply-To: <4F6DDF53.5000601@uvic.ca> References: <4F6CBE0A.6050307@uvic.ca> <Pine.LNX.4.64.1203231519030.15262@zaxxon.gpcc.itd.umich.edu> <5C0990DE-01B4-4C56-859B-7CD0066EF2C0@retired.ox.ac.uk> <CAA2irtJaayR2ejZd9O8KrvVEsvLYM_11XfwBm7uo2sewxNgM3A@mail.gmail.com> <4F6CDF33.5010706@uvic.ca> <0C8224DC-3A7D-4D6A-BC0A-4444CDF4DE0B@oucs.ox.ac.uk> <4F6DDF53.5000601@uvic.ca> Message-ID: <4F6DE773.3040904@retired.ox.ac.uk> Dear Alan Partridge [joke for brits only] Your aha moment is plausible, though I think in fact the purpose of the @valid was just to check whether the colour change introduced by its presence at the outer level worked: i.e. to test the stylesheets, not exemplify the use of this attribute. But your changes seem like an improvement. On 24/03/12 14:50, Martin Holmes wrote: > I think I just had an aha moment: > > If the purpose of the example is to illustrate the use of @valid, then > @valid needs also to be on the embedded CDATA<egXML> as well as the > outer one: > > <exemplum xml:lang="en"> > <egXML xmlns="http://www.tei-c.org/ns/Examples" xml:lang="und" > valid="false"> > <![CDATA[ > <egXML xmlns="http://www.tei-c.org/ns/Examples" valid="false"> > <langUsage> > <language ident="fr">English</language> > </langUsage> > </egXML> > <!-- Though syntactically valid, this example is incorrect --> > ]]> > </egXML> > </exemplum> > > The comment also needs to point out what is being illustrated: > > <!-- Though syntactically valid, this example is incorrect because > the text of the<language> element does not match its @ident > value. Therefore the attribute @valid is set to false. --> > > Now, if I'm right, the purpose of the example will be apparent. I've > implemented that change and we'll see what the result looks like when > Jinks has finished with it in an hour or so: > > <http://teijenkins.hcmc.uvic.ca:8080/job/TEIP5-Documentation/lastSuccessfulBuild/artifact/Guidelines-web/en/html/ref-egXML.html> > > I'm still not sure if we should have that as the first example of > <egXML>, but that's a different question. > > Cheers, > Martin > > On 12-03-24 06:45 AM, Sebastian Rahtz wrote: >> this thing does seem extraordinary. if we revert to >> >> <exemplum xml:lang="en"> >> <egXML xmlns="http://www.tei-c.org/ns/Examples" xml:lang="und"> >> <![CDATA[<egXML xmlns="http://www.tei-c.org/ns/Examples"> >> <langUsage> >> <language ident="fr">French</language> >> </langUsage> >> </egXML>]]> >> </egXML> >> </exemplum> >> >> it is entirely valid, but misleading, cos the XML is not XML just >> looks like it. so I feel inclined to keep "valid=false", lose the comment, >> and correct the semantics. >> >> if you wonder its in CDATA to avoid the whole thing being processed. >> -- >> Sebastian Rahtz >> Head of Information and Support Group, Oxford University Computing Services >> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 >> >> S?lo le pido a Dios >> que el futuro no me sea indiferente >> >> >> From sebastian.rahtz at oucs.ox.ac.uk Sat Mar 24 12:53:40 2012 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Sat, 24 Mar 2012 16:53:40 +0000 Subject: [tei-council] <egXML> example In-Reply-To: <4F6DE773.3040904@retired.ox.ac.uk> References: <4F6CBE0A.6050307@uvic.ca> <Pine.LNX.4.64.1203231519030.15262@zaxxon.gpcc.itd.umich.edu> <5C0990DE-01B4-4C56-859B-7CD0066EF2C0@retired.ox.ac.uk> <CAA2irtJaayR2ejZd9O8KrvVEsvLYM_11XfwBm7uo2sewxNgM3A@mail.gmail.com> <4F6CDF33.5010706@uvic.ca> <0C8224DC-3A7D-4D6A-BC0A-4444CDF4DE0B@oucs.ox.ac.uk> <4F6DDF53.5000601@uvic.ca> <4F6DE773.3040904@retired.ox.ac.uk> Message-ID: <DC755EEB-B5A0-4443-BA02-B17E35B2531A@oucs.ox.ac.uk> I am a little worried, as the point of valid=true|false|feasible was about XML validity, not semantic validity. It would be better to make the example syntactically invalid. I have submitted another change in which I have - added an example of valid=feasible - make the invalid one invalid - reordered the examples which I hope makes sense -- Sebastian Rahtz Head of Information and Support Group, Oxford University Computing Services 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 Mar 24 20:02:52 2012 From: mholmes at uvic.ca (Martin Holmes) Date: Sat, 24 Mar 2012 17:02:52 -0700 Subject: [tei-council] <egXML> example In-Reply-To: <DC755EEB-B5A0-4443-BA02-B17E35B2531A@oucs.ox.ac.uk> References: <4F6CBE0A.6050307@uvic.ca> <Pine.LNX.4.64.1203231519030.15262@zaxxon.gpcc.itd.umich.edu> <5C0990DE-01B4-4C56-859B-7CD0066EF2C0@retired.ox.ac.uk> <CAA2irtJaayR2ejZd9O8KrvVEsvLYM_11XfwBm7uo2sewxNgM3A@mail.gmail.com> <4F6CDF33.5010706@uvic.ca> <0C8224DC-3A7D-4D6A-BC0A-4444CDF4DE0B@oucs.ox.ac.uk> <4F6DDF53.5000601@uvic.ca> <4F6DE773.3040904@retired.ox.ac.uk> <DC755EEB-B5A0-4443-BA02-B17E35B2531A@oucs.ox.ac.uk> Message-ID: <4F6E60AC.1020202@uvic.ca> I think this works well. It does bring up another issue that I've been thinking about for a while, though: a single specification file contains not only its element but also any attributes which are defined on the element, and which may be unique to it. There's no way (to my knowledge) to specify that any given example is focused on the use of the element or one of its attributes. It would be helpful if there were a way to specify what an example is supposed to be exemplifying. We could always do this with comments inside the example, of course. Cheers, Martin On 12-03-24 09:53 AM, Sebastian Rahtz wrote: > I am a little worried, as the point of valid=true|false|feasible was about XML validity, not semantic > validity. It would be better to make the example syntactically invalid. > > I have submitted another change in which I have > > - added an example of valid=feasible > - make the invalid one invalid > - reordered the examples > > which I hope makes sense > -- > Sebastian Rahtz > Head of Information and Support Group, Oxford University Computing Services > 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 Mar 24 23:28:32 2012 From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins) Date: Sat, 24 Mar 2012 23:28:32 -0400 Subject: [tei-council] summary of Council taking on a role in maintenance of Best Practices for TEI in Libraries In-Reply-To: <1f2b0fcc-944d-46d7-ad1f-53ff54d886d8@HUB01.ad.oak.ox.ac.uk> References: <4F40307E.6080807@ultraslavonic.info> <EBB790FD-70DA-40F9-BFF0-7C84F3E173B9@oucs.ox.ac.uk> <4F410CF6.4040804@ultraslavonic.info> <EBF08744-1474-4712-A41A-10D2DFF1042D@oucs.ox.ac.uk> <4F415AED.6000100@oucs.ox.ac.uk> <1f2b0fcc-944d-46d7-ad1f-53ff54d886d8@HUB01.ad.oak.ox.ac.uk> Message-ID: <4F6E90E0.9060005@ultraslavonic.info> All, We didn't have time during our 28 February conf call to discuss the role of the TEI-C in maintaining the Best Practices for TEI in Libraries. Lou's minutes of our call say that we decided to defer this to the next meeting, but my notes were that we would resume discussion on the email list. Let me try to summarize our recent discussion (see the tei-council thread "for 28 Feb. conf call: background on Best Practice for TEI in Libraries") since this could be useful whether we continue to discuss by email or as the basis for a discussion during our next meeting. The BP was created by members of the SIG on Libraries and consists of a set of ODD files in a GitHub project, plus a few shell scripts and such for compilation into unified documentation. It was released as version 3.0 (having superseded earlier documents with similar names), and a snapshot of the full documentation is stored in the SIG's webspace on tei-c.org ( http://www.tei-c.org/SIG/Libraries/teiinlibraries/ ). There are a few pages in the TEI wiki containing notes on recommended revisions to the document. While it would make sense for the SIG on Libraries to review the BP occasionally in light of new releases of the TEI and in response to community needs, only been a handful of SIG members have found time to contribute to the BP. I hosted two SIG meetings this fall (in Wuerzburg and at the Digital Library Federation Forum in Baltimore) and informally fished for successors to Michelle Dalmau and me, who led development of the BP, but wasn't finding any. So Michelle and I would like to institutionalize support for the BP's development for fear that will fall into neglect. If the Council takes a role in the maintenance of this and other community-driven customizations, the Council can ensure coherence across them and attempt to recruit assistance from specialists for complex matters. Maintenance by the Council would help ensure (though somewhat indirectly) that the BP customizations are available in oxygen-tei. However, I need to offer a few disclaimers about the BP: a) The encoding prescribed in the BP for Level 1 does not conform to the TEI's abstract model because it requires a single <ab> to be the only child element of <div> or <div1>, which in turn is the required single child of <body>. Level 2 is possibly not conferment to the abstract model depending on whether you think the Guidelines say that encoding of <p>s is mandatory. I'm unsure about Levels 3 and 4. So there is a paradox of the Council maintaining something that is a "best practice" yet non-conformant according to the TEI Guidelines. b) If Council feels that materials under its stewardship must be in Sourceforge, the content would need to be moved there from GitHub and the appropriate wiki pages. This isn't a problem, but note that the idea of moving all TEI content out of Sourceforge into GitHub has occasionally been suggested. Regardless of whether the Council takes over or contributes to maintenance of the BP, I would like to see the BP added to the appropriate section of http://www.tei-c.org/Guidelines/Customization/ . Currently that webpage says to email editors at tei-c.org to request that a customization be added, but I'm not sure that's correct since there are no longer editors of the TEI. It has been suggested that the question is actually not whether the Council should maintain but whether the TEI-C should maintain, and that this is really a decision for the Board, not Council. However, James said that if the question came before the Board, he would like to present Council's position on this. Sebastian has suggested that Lite, Tite, and the BP be made into a family of "canned schemas" that are distinct from the Exemplars and therefore not included in Roma (but still in oxygen-tei). This seems reasonable to me. --Kevin From sebastian.rahtz at oucs.ox.ac.uk Sun Mar 25 09:52:59 2012 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Sun, 25 Mar 2012 13:52:59 +0000 Subject: [tei-council] <egXML> example In-Reply-To: <4F6E60AC.1020202@uvic.ca> References: <4F6CBE0A.6050307@uvic.ca> <Pine.LNX.4.64.1203231519030.15262@zaxxon.gpcc.itd.umich.edu> <5C0990DE-01B4-4C56-859B-7CD0066EF2C0@retired.ox.ac.uk> <CAA2irtJaayR2ejZd9O8KrvVEsvLYM_11XfwBm7uo2sewxNgM3A@mail.gmail.com> <4F6CDF33.5010706@uvic.ca> <0C8224DC-3A7D-4D6A-BC0A-4444CDF4DE0B@oucs.ox.ac.uk> <4F6DDF53.5000601@uvic.ca> <4F6DE773.3040904@retired.ox.ac.uk> <DC755EEB-B5A0-4443-BA02-B17E35B2531A@oucs.ox.ac.uk> <4F6E60AC.1020202@uvic.ca> Message-ID: <21715821-AC0C-4C60-B415-B6A761B7A37A@oucs.ox.ac.uk> On 25 Mar 2012, at 00:02, Martin Holmes wrote: > > It does bring up another issue that I've been thinking about for a while, though: a single specification file contains not only its element but also any attributes which are defined on the element, and which may be unique to it. There's no way (to my knowledge) to specify that any given example is focused on the use of the element or one of its attributes. It would be helpful if there were a way to specify what an example is supposed to be exemplifying. it's a fair point. Back in the olden days when I was working on http://www.amazon.com/LaTeX-Graphics-Companion-The-Edition/dp/0321508920, we tagged each example with a list of macro names (in that case) for which we wanted an entry in the index at this point. The same technique would apply here - yes, it shows a <p>, but its not an especially interesting use of <p> worth showing people. One could literally use index terms for the job, inside <exemplum> But the amount of retrofitting work needed is fearsome. -- Sebastian Rahtz Head of Information and Support Group, Oxford University Computing Services 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 Mar 25 09:53:39 2012 From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins) Date: Sun, 25 Mar 2012 09:53:39 -0400 Subject: [tei-council] ticket triage In-Reply-To: <4F663BC0.5080902@retired.ox.ac.uk> References: <4F663BC0.5080902@retired.ox.ac.uk> Message-ID: <4F6F2363.1080803@ultraslavonic.info> Gang, I have just revised tcw17 to explain the use of color coding for tickets (since this has been a point of confusion in the past). I have also changed http://purl.org/TEI/fr/3305016 from "pending" to "open" (and from green to amber) so that it now appears linked from tcw17. This ticket was nearly resolved in the past, but a new discussion has arisen. --Kevin On 3/18/12 3:47 PM, Lou Burnard wrote: > A quick look at > http://www.tei-c.org/Activities/Council/Working/tcw17.html shows the > following state of play... > > GREEN tickets (11 bugs; 5 Feature Requests) > > May I suggest that Council members should take a quick look initially at > the GREEN tickets? As far as I can tell, what needs to be done is > fairly self evident in each case (that's the definition of GREEN, after > all). Furthermore, each GREEN ticket (with one exception, see below) has > been assigned to someone for action. All you need do therefore is post a > message to the list if you disagree with the action being proposed for > the ticket. > > The exception is bug 3437782. This is a ticket I created and on which > no-one has commented so far; I am reluctant to assign it to myself and > just do it, even though I think it should just be done. So please > express your views on that one! > > AMBER tickets (18 bugs; 13 Feature requests) > > Several of them are on overlapping topics (e.g. we have three or four > talking about<wit>, and more than one worrying about the use of<idno>) > so I think we should be able to group them together and dispose of quite > a few in Chicago. I'll have a shot at doing that (the grouping) next, in > consultation with James when he comes back from his hols. > > RED tickets (4 red; 11 feature requests) > > Some of these are quite old (the oldest goes back to 2007) so maybe we > should find some way of indicating topics that we are giving up on for > the moment. > > Feel free, of course, to add comments on any ticket if you think the > discussion is in need of it. From sebastian.rahtz at oucs.ox.ac.uk Sun Mar 25 10:19:41 2012 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Sun, 25 Mar 2012 14:19:41 +0000 Subject: [tei-council] summary of Council taking on a role in maintenance of Best Practices for TEI in Libraries In-Reply-To: <4F6E90E0.9060005@ultraslavonic.info> References: <4F40307E.6080807@ultraslavonic.info> <EBB790FD-70DA-40F9-BFF0-7C84F3E173B9@oucs.ox.ac.uk> <4F410CF6.4040804@ultraslavonic.info> <EBF08744-1474-4712-A41A-10D2DFF1042D@oucs.ox.ac.uk> <4F415AED.6000100@oucs.ox.ac.uk> <1f2b0fcc-944d-46d7-ad1f-53ff54d886d8@HUB01.ad.oak.ox.ac.uk> <4F6E90E0.9060005@ultraslavonic.info> Message-ID: <2B77E136-DAEF-4CFE-A013-827678785CA9@oucs.ox.ac.uk> My fundamental problem with this is: > I hosted two SIG meetings this fall (in Wuerzburg > and at the Digital Library Federation Forum in Baltimore) and informally > fished for successors to Michelle Dalmau and me, who led development of > the BP, but wasn't finding any. So Michelle and I would like to > institutionalize support for the BP's development for fear that will > fall into neglect. because if the community of users does not interested in maintaining the BP, doesn't that suggest that it is not needed? If we have a BP which the library community has lost interested in, then just let it die; if the library community is all behind it, then why would they not look after it? This seems like the very essence of a SIG, that it develops and maintains the specialist knowledge and experience that the general purpose Council, changing every few years, cannot reliably have. if the Council maintained the BP, it would presumably expect to make the decisions about it, but on what basis? One of the strengths of the BP is that it is NOT dictated by the TEI-C from above, but reflects real practice (well, I assume thats what it does...). I think the mess with Tite, whereby we have the tension between TEI-C and Apex about ownership and changes, shows we should _not_ take on BP. But others may have the opposite opinions :-} -- Sebastian Rahtz Head of Information and Support Group, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From lou.burnard at retired.ox.ac.uk Sun Mar 25 15:12:29 2012 From: lou.burnard at retired.ox.ac.uk (Lou Burnard) Date: Sun, 25 Mar 2012 20:12:29 +0100 Subject: [tei-council] open tickets : proposed groupings Message-ID: <4F6F6E1D.6060407@retired.ox.ac.uk> In an attempt to help structure the agenda for the Chicago meeting, I've now grouped together currently open AMBER and RED tickets under approx 9 headings as follows. Some of these are quite specialised (e.g. the crit app tickets); some are quite varied (e.g. New proposals). In the past we've divided into small groups meeting in parallel to thrash out proposals aimed at dealing with several tickets at once, and I think that would probably work equally well this time, unless our chair has a better proposal. -----A: Obscurities in crit app------ http://purl.org/tei/bugs/3497369 TEI Guidelines, p. 396 - XPath http://purl.org/tei/bugs/3497356 TEI Guidelines, p. 394 - external apparatus http://purl.org/tei/bugs/3496998 TEI Guidelines, p. 393 - <lacunaEnd> http://purl.org/tei/bugs/3496958 Guidelines, p. 384 - number of <rdg> in <app> http://purl.org/tei/bugs/3496954 Guidelines, p. 390-3 - "where no witness exists" http://purl.org/tei/bugs/3496951 Guidelines, p. 389-2 - @wit on <rdgGrp> http://purl.org/tei/bugs/3496949 Guidelines, p. 388 - "<wit>[unattested]</wit>" -------B: Policy/style issues------- http://purl.org/tei/bugs/3454814 Prune comments from TEI source http://purl.org/tei/bugs/3454803 Review of language, script and region code recommendations http://purl.org/tei/bugs/3432216 i18n revision due http://purl.org/tei/bugs/3223636 @xml:space vs. CDATA for blocks of code http://purl.org/tei/bugs/3393781 @version in examples -----C: Misc content model queries---- http://purl.org/tei/bugs/3475748 Inaccurate example in dictionary chapter http://purl.org/tei/bugs/3440771 Multiple <geo> tags in <location> http://purl.org/tei/bugs/3439980 content model of <signed> http://purl.org/tei/bugs/3458222 <choice> as child of <pc> http://purl.org/tei/bugs/3500088 French example of <metDecl> seems wrong -----D: Usage of magic tokens-------- http://purl.org/tei/bugs/3480650 @cRef is a mess http://purl.org/tei/bugs/3413346 Deprecation of data.key and data.word attributes ----E: New proposals------- http://purl.org/tei/fr/3504690 floatingDiv proposal http://purl.org/tei/fr/3490054 Split off 'Dates and Times' to new TEI chapter http://purl.org/tei/fr/3423686 an <object> element http://purl.org/tei/fr/3475007 New section on encoding text directionality http://purl.org/tei/fr/3288293 creat @refLang, add it to att.pointing http://purl.org/tei/fr/2724997 Cater for audio/video facsimile http://purl.org/tei/fr/2507305 Alignment and documentation of sound files ----F: Usage of idno------- http://purl.org/tei/fr/3439587 Problems introduced by content models of bibl and imprint. http://purl.org/tei/fr/3500566 revise handling of ISBNs in <idno> http://purl.org/tei/fr/3497079 clarify and rationalize encoding of pagination in bibliograp http://purl.org/tei/fr/3440977 Add idno to person (maybe also place) http://purl.org/tei/fr/2493417 <idno> coverage http://purl.org/tei/fr/3480057 Allow <idno> inside <monogr> without restrictions ----G: Class tweaks-------- http://purl.org/tei/fr/3496494 make attributes from and to (as pointers) part of a class http://purl.org/tei/fr/3495987 members of model.respLike should be members of att.declarabl http://purl.org/tei/fr/2834511 Add more elements to att.spanning with schematron constraint http://purl.org/tei/fr/3291540 att.editLike should not bring att.dimensions and att.ranging http://purl.org/tei/fr/3284816 att.canonical for model.persTraitLike ----H: Minor content model tweaks-------- http://purl.org/tei/fr/3434990 require minimum of two lines or lg inside lg http://purl.org/tei/fr/3305016 make <graphic> available within <table> and ... http://purl.org/tei/fr/3416130 Allow certainty etc. inside milestoneLike elements http://purl.org/tei/bugs/337683 macro.paraContent out of place in <gram> etc [cf <u> discussion] ---J: ODD related----- http://purl.org/tei/fr/3415801 Allow modification of attributes belonging to a class http://purl.org/tei/fr/3118435 classes in interleave mode and cardinality membership. http://purl.org/tei/fr/3426828 more coherence on mode attribute on classes and attList http://purl.org/tei/fr/1650195 Need Header element to reference or embed schema/odd From James.Cummings at oucs.ox.ac.uk Tue Mar 27 08:40:01 2012 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Tue, 27 Mar 2012 13:40:01 +0100 Subject: [tei-council] <egXML> example In-Reply-To: <21715821-AC0C-4C60-B415-B6A761B7A37A@oucs.ox.ac.uk> References: <4F6CBE0A.6050307@uvic.ca> <Pine.LNX.4.64.1203231519030.15262@zaxxon.gpcc.itd.umich.edu> <5C0990DE-01B4-4C56-859B-7CD0066EF2C0@retired.ox.ac.uk> <CAA2irtJaayR2ejZd9O8KrvVEsvLYM_11XfwBm7uo2sewxNgM3A@mail.gmail.com> <4F6CDF33.5010706@uvic.ca> <0C8224DC-3A7D-4D6A-BC0A-4444CDF4DE0B@oucs.ox.ac.uk> <4F6DDF53.5000601@uvic.ca> <4F6DE773.3040904@retired.ox.ac.uk> <DC755EEB-B5A0-4443-BA02-B17E35B2531A@oucs.ox.ac.uk> <4F6E60AC.1020202@uvic.ca> <21715821-AC0C-4C60-B415-B6A761B7A37A@oucs.ox.ac.uk> Message-ID: <4F71B521.8040904@oucs.ox.ac.uk> On 25/03/12 14:52, Sebastian Rahtz wrote: > On 25 Mar 2012, at 00:02, Martin Holmes wrote: > it's a fair point. Back in the olden days when I was working on http://www.amazon.com/LaTeX-Graphics-Companion-The-Edition/dp/0321508920, > we tagged each example with a list of macro names (in that case) for which we wanted an entry in the index at this point. The same > technique would apply here - yes, it shows a<p>, but its not an especially interesting use of<p> worth showing people. > One could literally use index terms for the job, inside<exemplum> > But the amount of retrofitting work needed is fearsome. There are all sorts of ways we could be making better use of our examples. I had already added TEI Examples to the agenda for the face2face, so we should at least have a quick discussion about it then. I do think it is something we need to investigate a bit first and come to a decision about the best way to organise, re-use and process our examples rather than just bolting on more workarounds. (But use of index terms might indeed be a good way to do this.) -James -- Dr James Cummings, InfoDev, Computing Services, University of Oxford From bansp at o2.pl Tue Mar 27 10:00:49 2012 From: bansp at o2.pl (=?ISO-8859-2?Q?Piotr_Ba=F1ski?=) Date: Tue, 27 Mar 2012 16:00:49 +0200 Subject: [tei-council] summary of Council taking on a role in maintenance of Best Practices for TEI in Libraries In-Reply-To: <2B77E136-DAEF-4CFE-A013-827678785CA9@oucs.ox.ac.uk> References: <4F40307E.6080807@ultraslavonic.info> <EBB790FD-70DA-40F9-BFF0-7C84F3E173B9@oucs.ox.ac.uk> <4F410CF6.4040804@ultraslavonic.info> <EBF08744-1474-4712-A41A-10D2DFF1042D@oucs.ox.ac.uk> <4F415AED.6000100@oucs.ox.ac.uk> <1f2b0fcc-944d-46d7-ad1f-53ff54d886d8@HUB01.ad.oak.ox.ac.uk> <4F6E90E0.9060005@ultraslavonic.info> <2B77E136-DAEF-4CFE-A013-827678785CA9@oucs.ox.ac.uk> Message-ID: <4F71C811.8080908@o2.pl> I think Sebastian's points are very strong. An admittedly extreme reading of Kevin's post is: "no one in the SIG cares, so let's push this onto the Council". I know you didn't mean it that way, but that would be the net effect. SIGs are the creatures of the Council and/or the Board, depending on their nature (I'm not talking about the formal relationship but rather the factual relationship). In this case, I would think, as an outsider to the Libraries SIG, that part of its raison d'etre was/is the maintenance of the BP doc, in sync with the Council (to be sure: the syncing is the SIG's responsibility, I'd hope). If the SIG doesn't want to do that, then what is the SIG for? Another question is: maybe the SIG doesn't *need* to modify the BP for now because it's acceptable as it is? So maybe it's not a general lack of interest, but just a lack of interest in fixing what ain't broke? (I realise that these may be naive questions, I stress that I'm asking them as an outsider.) Again, to follow Kevin's suggestion ad absurdum (again begging forgiveness for the rhetorical device): > If the Council takes a role in the maintenance of this and other > community-driven customizations, the Council can ensure coherence across > them and attempt to recruit assistance from specialists for complex > matters. if the Council accepts this role, the Council may eventually choke on that. Unless we're lucky to make this part of our jobs, we're all taking time away from our jobs when we can (I'm an embarrassed example that sometimes we just can't), to push the cart forward. Getting busy with syncing all specialist customizations would saturate the time available to the Council members for Council work, I'm afraid. I think de-centralization (as Sebastian notes), i.e. making the SIG responsible for syncing with the Council, is not just the right way, but possibly the only way to handle this coherently across-the-board. Once again, forgive the possible naivety in my direct questions about the Libraries SIG, they are not meant as an attack of any sort, rather as a way to shed some light at the possible end of the proposed path, so to say. Best, Piotr On 25/03/12 16:19, Sebastian Rahtz wrote: > My fundamental problem with this is: > >> I hosted two SIG meetings this fall (in Wuerzburg >> and at the Digital Library Federation Forum in Baltimore) and informally >> fished for successors to Michelle Dalmau and me, who led development of >> the BP, but wasn't finding any. So Michelle and I would like to >> institutionalize support for the BP's development for fear that will >> fall into neglect. > > > because if the community of users does not interested in maintaining the BP, > doesn't that suggest that it is not needed? If we have a BP which > the library community has lost interested in, then just let it die; if > the library community is all behind it, then why would they not look after it? > > This seems like the very essence of a SIG, that it develops > and maintains the specialist knowledge and experience that > the general purpose Council, changing every few years, cannot > reliably have. if the Council maintained the BP, it would presumably > expect to make the decisions about it, but on what basis? > > One of the strengths of the BP is that it is NOT dictated by the TEI-C > from above, but reflects real practice (well, I assume thats what it does...). > > I think the mess with Tite, whereby we have the tension between > TEI-C and Apex about ownership and changes, shows we should > _not_ take on BP. > > But others may have the opposite opinions :-} > > -- > Sebastian Rahtz > Head of Information and Support Group, Oxford University Computing Services > 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 > > S?lo le pido a Dios > que el futuro no me sea indiferente > > > > From syeates at gmail.com Tue Mar 27 16:14:36 2012 From: syeates at gmail.com (Stuart A. Yeates) Date: Wed, 28 Mar 2012 09:14:36 +1300 Subject: [tei-council] summary of Council taking on a role in maintenance of Best Practices for TEI in Libraries In-Reply-To: <4F71C811.8080908@o2.pl> References: <4F40307E.6080807@ultraslavonic.info> <EBB790FD-70DA-40F9-BFF0-7C84F3E173B9@oucs.ox.ac.uk> <4F410CF6.4040804@ultraslavonic.info> <EBF08744-1474-4712-A41A-10D2DFF1042D@oucs.ox.ac.uk> <4F415AED.6000100@oucs.ox.ac.uk> <1f2b0fcc-944d-46d7-ad1f-53ff54d886d8@HUB01.ad.oak.ox.ac.uk> <4F6E90E0.9060005@ultraslavonic.info> <2B77E136-DAEF-4CFE-A013-827678785CA9@oucs.ox.ac.uk> <4F71C811.8080908@o2.pl> Message-ID: <CAC_Lu0Zvw70pXVUC7=3hZKXFvbdT8g2qLVceuRqcaBc-JEA9VQ@mail.gmail.com> I think the key point here is what is meant by the term 'maintenance' If 'maintenance' means hosting the documentation, schemas, etc; providing technical methods for community members to make minor corrections (typos, links to discussions for clarifications, etc); migrating schemas, etc across different versions of tools (roma, etc); then that seems like something the council might take on. If 'maintenance' means any more than this, it seems like the kind of thing that we should not. cheers stuart From kevin.s.hawkins at ultraslavonic.info Tue Mar 27 20:04:23 2012 From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins) Date: Tue, 27 Mar 2012 20:04:23 -0400 Subject: [tei-council] summary of Council taking on a role in maintenance of Best Practices for TEI in Libraries In-Reply-To: <4F71C811.8080908@o2.pl> References: <4F40307E.6080807@ultraslavonic.info> <EBB790FD-70DA-40F9-BFF0-7C84F3E173B9@oucs.ox.ac.uk> <4F410CF6.4040804@ultraslavonic.info> <EBF08744-1474-4712-A41A-10D2DFF1042D@oucs.ox.ac.uk> <4F415AED.6000100@oucs.ox.ac.uk> <1f2b0fcc-944d-46d7-ad1f-53ff54d886d8@HUB01.ad.oak.ox.ac.uk> <4F6E90E0.9060005@ultraslavonic.info> <2B77E136-DAEF-4CFE-A013-827678785CA9@oucs.ox.ac.uk> <4F71C811.8080908@o2.pl> Message-ID: <4F725587.7040303@ultraslavonic.info> Thank you all for your thoughtful responses so far. On this point ... On 3/27/12 10:00 AM, Piotr Ba?ski wrote: > Another question is: maybe the SIG doesn't *need* to modify the BP for > now because it's acceptable as it is? So maybe it's not a general lack > of interest, but just a lack of interest in fixing what ain't broke? (I > realise that these may be naive questions, I stress that I'm asking them > as an outsider.) ... I can say that we've already accumulated quite a list of things to change: http://wiki.tei-c.org/index.php/Future_changes_to_Best_Practices_for_TEI_in_Libraries Some were noted between April 2008 (when we started work on the BP) and October 2011 (when we released it) but set aside because the problems were too complicated or because the solution depended on work that was underway in the TEI community as a whole. Others have arisen because of changes that Council has made to P5 since this fall. --Kevin From sebastian.rahtz at oucs.ox.ac.uk Wed Mar 28 08:32:22 2012 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Wed, 28 Mar 2012 12:32:22 +0000 Subject: [tei-council] summary of Council taking on a role in maintenance of Best Practices for TEI in Libraries In-Reply-To: <4F725587.7040303@ultraslavonic.info> References: <4F40307E.6080807@ultraslavonic.info> <EBB790FD-70DA-40F9-BFF0-7C84F3E173B9@oucs.ox.ac.uk> <4F410CF6.4040804@ultraslavonic.info> <EBF08744-1474-4712-A41A-10D2DFF1042D@oucs.ox.ac.uk> <4F415AED.6000100@oucs.ox.ac.uk> <1f2b0fcc-944d-46d7-ad1f-53ff54d886d8@HUB01.ad.oak.ox.ac.uk> <4F6E90E0.9060005@ultraslavonic.info> <2B77E136-DAEF-4CFE-A013-827678785CA9@oucs.ox.ac.uk> <4F71C811.8080908@o2.pl> <4F725587.7040303@ultraslavonic.info> Message-ID: <AA9987A3-CDE7-46B9-BF46-7C8906E83F66@oucs.ox.ac.uk> On 28 Mar 2012, at 01:04, Kevin Hawkins wrote: > ... I can say that we've already accumulated quite a list of things to > change: > > http://wiki.tei-c.org/index.php/Future_changes_to_Best_Practices_for_TEI_in_Libraries > This intensifies my concern. It is an interesting and fairly complex list, to resolve which needs real work. The obvious solution would be to form a subcommittee to examine the issues in details, and work out what to do; and that subcommittee would pull in external experts, and then waddya know, we'd have a SIG :-} Comes back to the same problem. If there was someone here on Council who was the natural lead to revise the BP, they'd already have volunteered. Handing the job to the committee-as-a-whole is just not going to work. One way forward could be to stop treating TEI in libraries as some sort of special case, and merge the whole BP thing into the Guidelines for everyone. i.e. make the Guidelines more prescriptive across the board than they already are. So effectively the current BP is the draft of new sections of the Guidelines. It would arguably be a good use of money (had we any) to pay someone to work on this for 3-6 months. -- Stormageddon Rahtz Head of Information and Support Group Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From kevin.s.hawkins at ultraslavonic.info Mon Apr 2 21:09:17 2012 From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins) Date: Mon, 02 Apr 2012 21:09:17 -0400 Subject: [tei-council] summary of Council taking on a role in maintenance of Best Practices for TEI in Libraries In-Reply-To: <AA9987A3-CDE7-46B9-BF46-7C8906E83F66@oucs.ox.ac.uk> References: <4F40307E.6080807@ultraslavonic.info> <EBB790FD-70DA-40F9-BFF0-7C84F3E173B9@oucs.ox.ac.uk> <4F410CF6.4040804@ultraslavonic.info> <EBF08744-1474-4712-A41A-10D2DFF1042D@oucs.ox.ac.uk> <4F415AED.6000100@oucs.ox.ac.uk> <1f2b0fcc-944d-46d7-ad1f-53ff54d886d8@HUB01.ad.oak.ox.ac.uk> <4F6E90E0.9060005@ultraslavonic.info> <2B77E136-DAEF-4CFE-A013-827678785CA9@oucs.ox.ac.uk> <4F71C811.8080908@o2.pl> <4F725587.7040303@ultraslavonic.info> <AA9987A3-CDE7-46B9-BF46-7C8906E83F66@oucs.ox.ac.uk> Message-ID: <4F7A4DBD.6040006@ultraslavonic.info> On 3/28/12 8:32 AM, Sebastian Rahtz wrote: > One way forward could be to stop treating TEI in libraries > as some sort of special case, and merge the whole BP thing > into the Guidelines for everyone. i.e. make the Guidelines > more prescriptive across the board than they already are. > So effectively the current BP is the draft of new sections > of the Guidelines. > > It would arguably be a good use of money (had we any) to > pay someone to work on this for 3-6 months. This is an intriguing idea and one that jives with longstanding complaints by some that the Guidelines don't foster as much interchange as claimed. But it's also controversial since others feel that the Guidelines should allow for certain types of variation. Even with the BP, which had as a principle that we should choose a single solution when possible, stalemates left us with alternative ways of doing certain things. Perhaps in Ann Arbor we can get a sense of which parts of the BP, if any, Council is likely to support assimilating into the Guidelines. I wouldn't want to waste a grant applicaiton and months of work if the whole thing is dead on arrival. From kevin.s.hawkins at ultraslavonic.info Sat Apr 7 22:42:35 2012 From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins) Date: Sat, 07 Apr 2012 22:42:35 -0400 Subject: [tei-council] namespaces and customization In-Reply-To: <9B23E49F-89F9-4579-A76A-4FF43F1E28C2@oucs.ox.ac.uk> References: <4EEE7722.7090407@ultraslavonic.info> <4EEEAF50.6080902@uvic.ca> <4EEEFCA9.4070007@oucs.ox.ac.uk> <9CDC2137-B222-4CAD-8AB5-9266A4CE050E@oucs.ox.ac.uk> <4F039DA1.6000503@ultraslavonic.info> <07238135-C143-48A2-9A26-CA7586D7F090@oucs.ox.ac.uk> <E5EA2A75-8908-42C6-8422-F32824FBFCB6@oucs.ox.ac.uk> <4F0434F6.9080904@retired.ox.ac.uk> <55D02CD2-121F-467E-9F9E-F3C29FE2FD97@oucs.ox.ac.uk> <4F05FD9E.7080102@retired.ox.ac.uk> <9B23E49F-89F9-4579-A76A-4FF43F1E28C2@oucs.ox.ac.uk> Message-ID: <4F80FB1B.5070806@ultraslavonic.info> On 1/5/12 2:59 PM, Sebastian Rahtz wrote: > On 5 Jan 2012, at 19:44, Lou Burnard wrote: > >> >> Agree on that. But it *is* misleading -- unless you now also claim that >> the flopsy example (in #MDNS) is wrong, we have a situation where @ns >> means one thing when @mode="add" and another, quite different, thing >> when it doesnt. > > tricky. I don't see an easy way to resolve that. > > but I take consolation from the fact that no-one has > noticed the problem so far as we know. I take no consolation and have therefore filed a bug report: http://purl.org/TEI/bug/3515805 From kevin.s.hawkins at ultraslavonic.info Sat Apr 7 22:56:50 2012 From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins) Date: Sat, 07 Apr 2012 22:56:50 -0400 Subject: [tei-council] namespaces and customization In-Reply-To: <55D02CD2-121F-467E-9F9E-F3C29FE2FD97@oucs.ox.ac.uk> References: <4EEE7722.7090407@ultraslavonic.info> <4EEEAF50.6080902@uvic.ca> <4EEEFCA9.4070007@oucs.ox.ac.uk> <9CDC2137-B222-4CAD-8AB5-9266A4CE050E@oucs.ox.ac.uk> <4F039DA1.6000503@ultraslavonic.info> <07238135-C143-48A2-9A26-CA7586D7F090@oucs.ox.ac.uk> <E5EA2A75-8908-42C6-8422-F32824FBFCB6@oucs.ox.ac.uk> <4F0434F6.9080904@retired.ox.ac.uk> <55D02CD2-121F-467E-9F9E-F3C29FE2FD97@oucs.ox.ac.uk> Message-ID: <4F80FE72.40007@ultraslavonic.info> My problem wasn't that the Guidelines didn't point out that the example in section 23.2.1.5 would make this an unclean customization but rather that the role of namespaces as a whole is a bit unclear. I have just posted a bug report: http://purl.org/TEI/bug/3515806 and also mentioned on TEI-L, where I began this discussion. (Just tying up loose ends here for anyone digging through the archives some day.) On 1/4/12 7:08 AM, Sebastian Rahtz wrote: > which of us wrote that passage which confused Kevin? it talks > about how to add an element to att.typed as an example, but > fails to point out that this makes the doc non-TEI (or so some > of us claim). From kevin.s.hawkins at ultraslavonic.info Tue Apr 10 12:08:06 2012 From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins) Date: Tue, 10 Apr 2012 12:08:06 -0400 Subject: [tei-council] sunday hack session Message-ID: <4F845AE6.7010509@ultraslavonic.info> All, I'd like to have a sense of how early I should show up on Sunday for the hack session, and and how late those of us there should stay to meet any late arrivals. If you're planning to come, please let me know. Well, let us all know so no one thinks they're going to have to spend an awkward afternoon alone with me. :) An update on logistics will probably be coming from Becky this week, but let me say now that the Sunday hack session, just like the working meetings on Monday through Wednesday, will be in the Shapiro Library on U-M's central campus. This is next door to the Hatcher Library, where the 2009 conference was held. The folks at the hotel reception desk can tell you how to find it. We'll be in the Turkish-American Friendship Room, which is on the fourth floor. Follow the signs once you're in the building. Some of you will recall this room as one that was used for various meetings held before, during, and after the 2009 conference. See you soon! From gabriel.bodard at kcl.ac.uk Tue Apr 10 13:28:14 2012 From: gabriel.bodard at kcl.ac.uk (Gabriel BODARD) Date: Tue, 10 Apr 2012 18:28:14 +0100 Subject: [tei-council] No show [was Re: sunday hack session] In-Reply-To: <4F845AE6.7010509@ultraslavonic.info> References: <4F845AE6.7010509@ultraslavonic.info> Message-ID: <4F846DAE.5080304@kcl.ac.uk> Dear all, As James and Becky already know, I'm not going to make it to Ann Arbor in the flesh next week, but I will be attending all day Monday-Wednesday as a disembodied presence via Skype and IRC, and I've set aside those three days to work on odd/schema/guidelines related things. Very sorry that I won't be seeing you all in person there (especially those of you I've not met yet), but looking forward to the working sessions nevertheless. Cheers, Gabby On 10/04/2012 17:08, Kevin Hawkins wrote: > All, > > I'd like to have a sense of how early I should show up on Sunday for the > hack session, and and how late those of us there should stay to meet any > late arrivals. If you're planning to come, please let me know. Well, > let us all know so no one thinks they're going to have to spend an > awkward afternoon alone with me. :) > > An update on logistics will probably be coming from Becky this week, but > let me say now that the Sunday hack session, just like the working > meetings on Monday through Wednesday, will be in the Shapiro Library on > U-M's central campus. This is next door to the Hatcher Library, where > the 2009 conference was held. The folks at the hotel reception desk can > tell you how to find it. > > We'll be in the Turkish-American Friendship Room, which is on the fourth > floor. Follow the signs once you're in the building. Some of you will > recall this room as one that was used for various meetings held before, > during, and after the 2009 conference. > > See you soon! -- Dr Gabriel BODARD (Research Associate in Digital Epigraphy) Department of Digital 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 Tue Apr 10 13:29:09 2012 From: mholmes at uvic.ca (Martin Holmes) Date: Tue, 10 Apr 2012 10:29:09 -0700 Subject: [tei-council] sunday hack session In-Reply-To: <4F845AE6.7010509@ultraslavonic.info> References: <4F845AE6.7010509@ultraslavonic.info> Message-ID: <4F846DE5.30606@uvic.ca> I won't get there till the evening, unfortunately. But I'll be hungry when I do get there -- any plan for food on Sunday night? Cheers, Martin On 12-04-10 09:08 AM, Kevin Hawkins wrote: > All, > > I'd like to have a sense of how early I should show up on Sunday for the > hack session, and and how late those of us there should stay to meet any > late arrivals. If you're planning to come, please let me know. Well, > let us all know so no one thinks they're going to have to spend an > awkward afternoon alone with me. :) > > An update on logistics will probably be coming from Becky this week, but > let me say now that the Sunday hack session, just like the working > meetings on Monday through Wednesday, will be in the Shapiro Library on > U-M's central campus. This is next door to the Hatcher Library, where > the 2009 conference was held. The folks at the hotel reception desk can > tell you how to find it. > > We'll be in the Turkish-American Friendship Room, which is on the fourth > floor. Follow the signs once you're in the building. Some of you will > recall this room as one that was used for various meetings held before, > during, and after the 2009 conference. > > See you soon! -- Martin Holmes University of Victoria Humanities Computing and Media Centre (mholmes at uvic.ca) From sebastian.rahtz at oucs.ox.ac.uk Tue Apr 10 13:37:35 2012 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 10 Apr 2012 17:37:35 +0000 Subject: [tei-council] sunday hack session In-Reply-To: <4F845AE6.7010509@ultraslavonic.info> References: <4F845AE6.7010509@ultraslavonic.info> Message-ID: <D957117C-E9E0-43A0-A1C1-BC2A37DDB3C5@oucs.ox.ac.uk> I am up for Sunday working. Can anyone remind me of something I said I'd make work on that day? I think there is some problem of ODD processing in a pending ticket which I said was doable with some concentration - was it the idea of redeclaration of attributes (i.e. datatypes) in the P5 source itself? Sebastian From sebastian.rahtz at oucs.ox.ac.uk Tue Apr 10 13:38:46 2012 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 10 Apr 2012 17:38:46 +0000 Subject: [tei-council] sunday hack session In-Reply-To: <4F845AE6.7010509@ultraslavonic.info> References: <4F845AE6.7010509@ultraslavonic.info> Message-ID: <32DC54C3-C98F-4A3F-A926-DB53171EFC4E@oucs.ox.ac.uk> PS > > I'd like to have a sense of how early I should show up on Sunday for the > hack session, and and how late those of us there should stay to meet any > late arrivals. I'm thinking 9.30 am? Sebastian From kevin.s.hawkins at ultraslavonic.info Tue Apr 10 13:58:51 2012 From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins) Date: Tue, 10 Apr 2012 13:58:51 -0400 Subject: [tei-council] sunday hack session In-Reply-To: <32DC54C3-C98F-4A3F-A926-DB53171EFC4E@oucs.ox.ac.uk> References: <4F845AE6.7010509@ultraslavonic.info> <32DC54C3-C98F-4A3F-A926-DB53171EFC4E@oucs.ox.ac.uk> Message-ID: <4F8474DB.5070204@ultraslavonic.info> Oh, wow! The building only opens at 10 a.m. on Sundays, so we can't begin earlier than then. I could meet at 10 a.m. to open the room for Sebastian at that time but might then leave for brunch with friends before returning in the afternoon. (Planning my social calendar got me thinking about this.) In any case, you all should have my mobile phone number in case you're trying to meet me: +1 734 255 7458. Note that I can only receive text messages from non-US carriers listed at: http://businessportals.verizonwireless.com/international/Text_Messaging/index.html --Kevin On 4/10/2012 1:38 PM, Sebastian Rahtz wrote: > PS > >> >> I'd like to have a sense of how early I should show up on Sunday for the >> hack session, and and how late those of us there should stay to meet any >> late arrivals. > > I'm thinking 9.30 am? > > Sebastian From sebastian.rahtz at oucs.ox.ac.uk Tue Apr 10 14:08:14 2012 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 10 Apr 2012 18:08:14 +0000 Subject: [tei-council] sunday hack session In-Reply-To: <4F8474DB.5070204@ultraslavonic.info> References: <4F845AE6.7010509@ultraslavonic.info> <32DC54C3-C98F-4A3F-A926-DB53171EFC4E@oucs.ox.ac.uk> <4F8474DB.5070204@ultraslavonic.info> Message-ID: <166F1EC3-CFAE-44A1-936C-D679AB9486AA@oucs.ox.ac.uk> On 10 Apr 2012, at 18:58, Kevin Hawkins wrote: > Oh, wow! The building only opens at 10 a.m. on Sundays, so we can't > begin earlier than then. I could meet at 10 a.m. to open the room for > Sebastian at that time but might then leave for brunch with friends > before returning in the afternoon. 10am is fine :-} can you comment on food and drink around that place during the day? is this a god-fearing, everything-closed, sort of place? Sebastian From lou.burnard at retired.ox.ac.uk Tue Apr 10 15:45:34 2012 From: lou.burnard at retired.ox.ac.uk (Lou Burnard) Date: Tue, 10 Apr 2012 19:45:34 +0000 Subject: [tei-council] sunday hack session In-Reply-To: <166F1EC3-CFAE-44A1-936C-D679AB9486AA@oucs.ox.ac.uk> References: <4F845AE6.7010509@ultraslavonic.info> <32DC54C3-C98F-4A3F-A926-DB53171EFC4E@oucs.ox.ac.uk> <4F8474DB.5070204@ultraslavonic.info>, <166F1EC3-CFAE-44A1-936C-D679AB9486AA@oucs.ox.ac.uk> Message-ID: <5149f753-4ce9-44fb-9dbf-1298e4344f28@HUB04.ad.oak.ox.ac.uk> >From memory its a short walk to a typical street of campus restaurants. I will be arriving sat pm so happy to research the options. Sent from my HTC ----- Reply message ----- From: "Sebastian Rahtz" <sebastian.rahtz at oucs.ox.ac.uk> To: "Kevin Hawkins" <kevin.s.hawkins at ultraslavonic.info> Cc: "TEI Council" <tei-council at lists.village.Virginia.EDU> Subject: [tei-council] sunday hack session Date: Tue, Apr 10, 2012 19:08 On 10 Apr 2012, at 18:58, Kevin Hawkins wrote: > Oh, wow! The building only opens at 10 a.m. on Sundays, so we can't > begin earlier than then. I could meet at 10 a.m. to open the room for > Sebastian at that time but might then leave for brunch with friends > before returning in the afternoon. 10am is fine :-} can you comment on food and drink around that place during the day? is this a god-fearing, everything-closed, sort of place? Sebastian -- tei-council mailing list tei-council at lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council PLEASE NOTE: postings to this list are publicly archived From kevin.s.hawkins at ultraslavonic.info Tue Apr 10 15:50:43 2012 From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins) Date: Tue, 10 Apr 2012 15:50:43 -0400 Subject: [tei-council] sunday hack session In-Reply-To: <166F1EC3-CFAE-44A1-936C-D679AB9486AA@oucs.ox.ac.uk> References: <4F845AE6.7010509@ultraslavonic.info> <32DC54C3-C98F-4A3F-A926-DB53171EFC4E@oucs.ox.ac.uk> <4F8474DB.5070204@ultraslavonic.info> <166F1EC3-CFAE-44A1-936C-D679AB9486AA@oucs.ox.ac.uk> Message-ID: <4F848F13.4090204@ultraslavonic.info> On 4/10/2012 2:08 PM, Sebastian Rahtz wrote: > 10am is fine :-} Good, see you there. > can you comment on food and drink around that place during the day? is this a god-fearing, everything-closed, sort of place? Plenty of options within a short walk. From kevin.s.hawkins at ultraslavonic.info Tue Apr 10 15:53:42 2012 From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins) Date: Tue, 10 Apr 2012 15:53:42 -0400 Subject: [tei-council] sunday hack session In-Reply-To: <D957117C-E9E0-43A0-A1C1-BC2A37DDB3C5@oucs.ox.ac.uk> References: <4F845AE6.7010509@ultraslavonic.info> <D957117C-E9E0-43A0-A1C1-BC2A37DDB3C5@oucs.ox.ac.uk> Message-ID: <4F848FC6.2050704@ultraslavonic.info> The only thing I find in my email archive that Sebastian has suggested is to write roma2 if we get bored. I've started a list of possibilities: http://wiki.tei-c.org/index.php/Council#Sunday_15_April_10:00-.3F On 4/10/2012 1:37 PM, Sebastian Rahtz wrote: > I am up for Sunday working. Can anyone remind me of something I said I'd make work on that day? > I think there is some problem of ODD processing in a pending ticket which I said was doable > with some concentration - was it the idea of redeclaration of attributes (i.e. datatypes) in the P5 source itself? > > > Sebastian From kevin.s.hawkins at ultraslavonic.info Tue Apr 10 15:59:19 2012 From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins) Date: Tue, 10 Apr 2012 15:59:19 -0400 Subject: [tei-council] sunday hack session In-Reply-To: <4F846DE5.30606@uvic.ca> References: <4F845AE6.7010509@ultraslavonic.info> <4F846DE5.30606@uvic.ca> Message-ID: <4F849117.2090700@ultraslavonic.info> I suggest that those who are in town on Sunday self-organize at the hackathon. So you could come to the meeting room to find us or give me a call to figure out where we are at that point. On 4/10/2012 1:29 PM, Martin Holmes wrote: > I won't get there till the evening, unfortunately. But I'll be hungry > when I do get there -- any plan for food on Sunday night? > > Cheers, > Martin > > On 12-04-10 09:08 AM, Kevin Hawkins wrote: >> All, >> >> I'd like to have a sense of how early I should show up on Sunday for the >> hack session, and and how late those of us there should stay to meet any >> late arrivals. If you're planning to come, please let me know. Well, >> let us all know so no one thinks they're going to have to spend an >> awkward afternoon alone with me. :) >> >> An update on logistics will probably be coming from Becky this week, but >> let me say now that the Sunday hack session, just like the working >> meetings on Monday through Wednesday, will be in the Shapiro Library on >> U-M's central campus. This is next door to the Hatcher Library, where >> the 2009 conference was held. The folks at the hotel reception desk can >> tell you how to find it. >> >> We'll be in the Turkish-American Friendship Room, which is on the fourth >> floor. Follow the signs once you're in the building. Some of you will >> recall this room as one that was used for various meetings held before, >> during, and after the 2009 conference. >> >> See you soon! > From sebastian.rahtz at oucs.ox.ac.uk Tue Apr 10 16:06:20 2012 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 10 Apr 2012 20:06:20 +0000 Subject: [tei-council] sunday hack session In-Reply-To: <4F848FC6.2050704@ultraslavonic.info> References: <4F845AE6.7010509@ultraslavonic.info> <D957117C-E9E0-43A0-A1C1-BC2A37DDB3C5@oucs.ox.ac.uk> <4F848FC6.2050704@ultraslavonic.info> Message-ID: <05C940C0-4D03-4FCE-A996-3DC6A625D028@oucs.ox.ac.uk> On 10 Apr 2012, at 20:53, Kevin Hawkins wrote: > The only thing I find in my email archive that Sebastian has suggested > is to write roma2 if we get bored. phew, no chance of that, luckily :-} though, as some of you know, James and I have submitted a small funding bid to JISC in the UK for a project which would make a good start on a new Roma Sebastian From James.Cummings at oucs.ox.ac.uk Wed Apr 11 05:01:17 2012 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Wed, 11 Apr 2012 10:01:17 +0100 Subject: [tei-council] TEI ODD meeting after DH2012 Message-ID: <4F85485D.5060907@oucs.ox.ac.uk> Dear TEI Council, In interests of transparency I just sent this update on my planning of the TEI ODD meeting after DH2012 to the Board list. I don't believe there is anything confidential in it so circulate it here as well. I wasn't able to invite/subsidise everyone suggested, but hopefully some of them will still be able to make it. -James ==== Dear TEI-C Board, As an update on the planning for this TEI ODD meeting after DH2012: a total of 15 people who were invited can make it, 8 of which need up to 15 nights of hotel. 3 invitations are still outstanding (but I don't expect to hear back from 2 of them). About 10 suggested people were unable to be invited/subsidised without increasing the budget, however, I will make sure those people are invited in a non-subsidised manner. The conference is charging 200 EUR for renting the room including "for cleaning, use of fixed equipment (projector), and admin: EUR 200 / day". I've said that they should go ahead and we can have them invoice the TEI-C for that charge. I'll give Dot a list of names of those that have said that they need hotel to be subsidised and can claim up to two nights hotel. I'll also provide those people with instructions on how to do so. Within the next week I'll start announcing it publicly on TEI-L (etc.) as an open meeting for others with their own means able to attend should they wish. Best, James Cummings -- Dr James Cummings, InfoDev, Computing Services, University of Oxford From James.Cummings at oucs.ox.ac.uk Wed Apr 11 06:46:47 2012 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Wed, 11 Apr 2012 11:46:47 +0100 Subject: [tei-council] Draft Agenda for AnnArbor2012 face2face meeting Message-ID: <4F856117.6090104@oucs.ox.ac.uk> Hi All, I've put a draft agenda up on the wiki at: http://wiki.tei-c.org/index.php/Council Now is the time to shout, re-order stuff, add stuff, etc. Feel free to change it (and/or add more detail) as you feel appropriate. My suggestion is that we organise each day to structurally alternate between other business and bugs/FR. e.g. warming up by talking about some of the issues/actions that have been raised, then work through bugs/FR, have lunch, talk about other issues, then work on bugs/FR. You'll notice the 'open lunch' on Tuesday. Kevin and Becky can tell us more about that. (psst, that is a cue.) I'm hoping because of Lou's triaging work (see http://www.tei-c.org/Activities/Council/Working/tcw17.html) we can progress through the Green bugs/FR very quickly and move on to the Amber ones. HOMEWORK: I would like *every* council member to spend some time (if you have not already) looking through *every* Green and then Amber Bug/FR. If you have any objections or comments, add it to the SF ticket for the item. If you think the right conclusion has been reached (e.g. on an Amber one), add it to the ticket. In the meeting *no* Bug/FR should come as a surprise to you! (Well, except perhaps ones submitted between now and then!) Minutes: Martin and Becky have volunteered to take minutes, and Kevin has arranged for a UM student to gain some experience by converting them to TEI. Flights: Can I confirm who amongst us needs to depart early on the Wednesday and by what time? Sebastian and my flight doesn't leave until about 10pm now, I believe. Remote Participants: I believe it is StuartY and GabyB that are participating remotely. Can you make sure that some of us have your skype usernames (and I know both of you know how to use the IRC channel). -James -- Dr James Cummings, InfoDev, Computing Services, University of Oxford From James.Cummings at oucs.ox.ac.uk Wed Apr 11 07:07:15 2012 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Wed, 11 Apr 2012 12:07:15 +0100 Subject: [tei-council] Draft Agenda for AnnArbor2012 face2face meeting In-Reply-To: <4F856117.6090104@oucs.ox.ac.uk> References: <4F856117.6090104@oucs.ox.ac.uk> Message-ID: <4F8565E3.9080600@oucs.ox.ac.uk> On 11/04/12 11:46, James Cummings wrote: > I've put a draft agenda up on the wiki at: > > http://wiki.tei-c.org/index.php/Council > > Now is the time to shout, re-order stuff, add stuff, etc. Feel > free to change it (and/or add more detail) as you feel appropriate. If you've forgotten your username and/or password and/or email or have other problems logging into the wiki do feel free to email me, Kevin, or Piotr all of whom have power to changes these things. > I'm hoping because of Lou's triaging work (see > http://www.tei-c.org/Activities/Council/Working/tcw17.html) we > can progress through the Green bugs/FR very quickly and move on > to the Amber ones. Fair warning here however, I intend to plough through the Green bugs/FR quickly... making the homework below more crucial if you think you might disagree with any of them. > HOMEWORK: I would like *every* council member to spend some time > (if you have not already) looking through *every* Green and then > Amber Bug/FR. If you have any objections or comments, add it to > the SF ticket for the item. If you think the right conclusion > has been reached (e.g. on an Amber one), add it to the ticket. In > the meeting *no* Bug/FR should come as a surprise to you! (Well, > except perhaps ones submitted between now and then!) -James -- Dr James Cummings, InfoDev, Computing Services, University of Oxford From rwelzenbach at gmail.com Wed Apr 11 09:18:10 2012 From: rwelzenbach at gmail.com (Rebecca Welzenbach) Date: Wed, 11 Apr 2012 09:18:10 -0400 Subject: [tei-council] sunday hack session In-Reply-To: <05C940C0-4D03-4FCE-A996-3DC6A625D028@oucs.ox.ac.uk> References: <4F845AE6.7010509@ultraslavonic.info> <D957117C-E9E0-43A0-A1C1-BC2A37DDB3C5@oucs.ox.ac.uk> <4F848FC6.2050704@ultraslavonic.info> <05C940C0-4D03-4FCE-A996-3DC6A625D028@oucs.ox.ac.uk> Message-ID: <CAA2irtLhNN4obsW=Z41rCrRGU90OfVeLLXEcehPegahr7VsrZw@mail.gmail.com> Hi all, Looking forward to seeing you soon. Some details that may be of interest as you arrive and get settled (will add them to the Google doc as well): *Transport* Last week I used the new AirRide shuttle that Paul mentioned, and recommend it, if you still need to make arrangements to get from the airport to campus. It was on time, comfortable, clean, runs frequently, etc., and is certainly the cheapest option. You can make reservations in advance here: http://www.myairride.com/. If you do this, be sure to print out everything and bring it with you. I think they also take walk-ons, for a slightly higher fee. You'll want to take the shuttle to the Central Campus Transit Center, which is a short walk from the hotel. *Maps* * From the shuttle station to the hotel: http://g.co/maps/8du2f * Hotel location and surrounding area: http://www.belltowerhotel.com/location.html * Map of central campus: http://www.umich.edu/~info/pdf/central.pdf * Map of the 4th floor of the Shapiro Library, where we'll be meeting: http://www.lib.umich.edu/navigator/shapiro4.html Note that, confusingly, the library map is oriented with north in the lower right hand corner. The big white square to the right of the map is our meeting room. The oddly shaped taupe area just above is where Kevin's and my office is. *food* You won't have any trouble finding places to eat and drink within walking distance of the hotel or the library, and most or all will be open on Sunday. * I believe your hotel reservation includes free continental breakfast (as well as in-room wireless), but I'll confirm this. * There's also a restaurant in the hotel, but I have no idea what it is like: http://www.mercysrestaurant.com/menu * There's a coffee shop on the first floor of the library, which has light (pre-made) fare like sandwiches, salads, and sushi as well as coffee and pastries: http://uunions.umich.edu/berts/ * Espresso Royale has locations close to the hotel and the library: http://www.espressoroyale.com/location.php?id=20 * Or if you prefer gourmet coffee and really excellent pastries, there is Comet Coffee: http://www.yelp.com/biz/comet-coffee-ann-arbor *Wireless* Non-UM-ers who will be on site will be assigned a temporary log-in so you can access the "MWireless" network used by faculty, staff, and students (the open "MGuest" network won't be sufficient for our work). Library Desktop Support is working now on setting up your accounts--hopefully they or I will be able to get the info to you before the end of the week. I'll also bring the details with me on Sunday, just in case. They know we need to be up and running over the weekend. I'm about to look over James' agenda, but want to note that on Tuesday we plan to have lunch catered in the library, and invite interested staff and other local people who might be interested to join us. Planning to order a variety of foods from http://www.jerusalemgarden.net/. Hopefully this will at least get you here, fed and rested--let me know if you have questions, and see you soon. Becky On Tue, Apr 10, 2012 at 4:06 PM, Sebastian Rahtz <sebastian.rahtz at oucs.ox.ac.uk> wrote: > > On 10 Apr 2012, at 20:53, Kevin Hawkins wrote: > >> The only thing I find in my email archive that Sebastian has suggested >> is to write roma2 if we get bored. > > phew, no chance of that, luckily :-} > > though, as some of you know, James and I have submitted a small funding > bid to JISC in the UK for a project which would make a good start > on a new Roma > > Sebastian > -- > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > > PLEASE NOTE: postings to this list are publicly archived From mholmes at uvic.ca Wed Apr 11 11:15:14 2012 From: mholmes at uvic.ca (Martin Holmes) Date: Wed, 11 Apr 2012 08:15:14 -0700 Subject: [tei-council] Draft Agenda for AnnArbor2012 face2face meeting In-Reply-To: <4F856117.6090104@oucs.ox.ac.uk> References: <4F856117.6090104@oucs.ox.ac.uk> Message-ID: <4F85A002.6050602@uvic.ca> HI James, I thought we were going to discuss the issue of @ref/key/cRef & Private URI Schemes. It was on the agenda for the February telco, but would have taken too long to address fully then, and I thought we agreed to move it forward to the ftf. I think it's important, and it's not something that can be captured in a single bug (although it's intrinsic to bugs 3480650 and 3413346). Cheers, Martin On 12-04-11 03:46 AM, James Cummings wrote: > Hi All, > > I've put a draft agenda up on the wiki at: > > http://wiki.tei-c.org/index.php/Council > > Now is the time to shout, re-order stuff, add stuff, etc. Feel > free to change it (and/or add more detail) as you feel appropriate. > > My suggestion is that we organise each day to structurally > alternate between other business and bugs/FR. e.g. warming up by > talking about some of the issues/actions that have been raised, > then work through bugs/FR, have lunch, talk about other issues, > then work on bugs/FR. > > You'll notice the 'open lunch' on Tuesday. Kevin and Becky can > tell us more about that. (psst, that is a cue.) > > I'm hoping because of Lou's triaging work (see > http://www.tei-c.org/Activities/Council/Working/tcw17.html) we > can progress through the Green bugs/FR very quickly and move on > to the Amber ones. > > HOMEWORK: I would like *every* council member to spend some time > (if you have not already) looking through *every* Green and then > Amber Bug/FR. If you have any objections or comments, add it to > the SF ticket for the item. If you think the right conclusion > has been reached (e.g. on an Amber one), add it to the ticket. In > the meeting *no* Bug/FR should come as a surprise to you! (Well, > except perhaps ones submitted between now and then!) > > Minutes: Martin and Becky have volunteered to take minutes, and > Kevin has arranged for a UM student to gain some experience by > converting them to TEI. > > Flights: Can I confirm who amongst us needs to depart early on > the Wednesday and by what time? Sebastian and my flight doesn't > leave until about 10pm now, I believe. > > Remote Participants: I believe it is StuartY and GabyB that are > participating remotely. Can you make sure that some of us have > your skype usernames (and I know both of you know how to use the > IRC channel). > > -James > -- > Dr James Cummings, InfoDev, > Computing Services, University of Oxford -- Martin Holmes University of Victoria Humanities Computing and Media Centre (mholmes at uvic.ca) From mholmes at uvic.ca Wed Apr 11 12:37:06 2012 From: mholmes at uvic.ca (Martin Holmes) Date: Wed, 11 Apr 2012 09:37:06 -0700 Subject: [tei-council] sunday hack session In-Reply-To: <CAA2irtLhNN4obsW=Z41rCrRGU90OfVeLLXEcehPegahr7VsrZw@mail.gmail.com> References: <4F845AE6.7010509@ultraslavonic.info> <D957117C-E9E0-43A0-A1C1-BC2A37DDB3C5@oucs.ox.ac.uk> <4F848FC6.2050704@ultraslavonic.info> <05C940C0-4D03-4FCE-A996-3DC6A625D028@oucs.ox.ac.uk> <CAA2irtLhNN4obsW=Z41rCrRGU90OfVeLLXEcehPegahr7VsrZw@mail.gmail.com> Message-ID: <4F85B332.3000303@uvic.ca> I just tried to book the AirRide shuttle, but it declined my credit card. Has anyone successfully completed a booking with a non-US credit card? Cheers, Martin On 12-04-11 06:18 AM, Rebecca Welzenbach wrote: > Hi all, > > Looking forward to seeing you soon. Some details that may be of > interest as you arrive and get settled (will add them to the Google > doc as well): > > *Transport* > Last week I used the new AirRide shuttle that Paul mentioned, and > recommend it, if you still need to make arrangements to get from the > airport to campus. It was on time, comfortable, clean, runs > frequently, etc., and is certainly the cheapest option. You can make > reservations in advance here: http://www.myairride.com/. If you do > this, be sure to print out everything and bring it with you. > I think they also take walk-ons, for a slightly higher fee. You'll > want to take the shuttle to the Central Campus Transit Center, which > is a short walk from the hotel. > > *Maps* > * From the shuttle station to the hotel: http://g.co/maps/8du2f > * Hotel location and surrounding area: > http://www.belltowerhotel.com/location.html > * Map of central campus: http://www.umich.edu/~info/pdf/central.pdf > * Map of the 4th floor of the Shapiro Library, where we'll be meeting: > http://www.lib.umich.edu/navigator/shapiro4.html > > Note that, confusingly, the library map is oriented with north in the > lower right hand corner. The big white square to the right of the map > is our meeting room. The oddly shaped taupe area just above is where > Kevin's and my office is. > > *food* > You won't have any trouble finding places to eat and drink within > walking distance of the hotel or the library, and most or all will be > open on Sunday. > > * I believe your hotel reservation includes free continental breakfast > (as well as in-room wireless), but I'll confirm this. > * There's also a restaurant in the hotel, but I have no idea what it > is like: http://www.mercysrestaurant.com/menu > * There's a coffee shop on the first floor of the library, which has > light (pre-made) fare like sandwiches, salads, and sushi as well as > coffee and pastries: http://uunions.umich.edu/berts/ > * Espresso Royale has locations close to the hotel and the library: > http://www.espressoroyale.com/location.php?id=20 > * Or if you prefer gourmet coffee and really excellent pastries, there > is Comet Coffee: http://www.yelp.com/biz/comet-coffee-ann-arbor > > *Wireless* > Non-UM-ers who will be on site will be assigned a temporary log-in so > you can access the "MWireless" network used by faculty, staff, and > students (the open "MGuest" network won't be sufficient for our work). > Library Desktop Support is working now on setting up your > accounts--hopefully they or I will be able to get the info to you > before the end of the week. I'll also bring the details with me on > Sunday, just in case. They know we need to be up and running over the > weekend. > > I'm about to look over James' agenda, but want to note that on Tuesday > we plan to have lunch catered in the library, and invite interested > staff and other local people who might be interested to join us. > Planning to order a variety of foods from > http://www.jerusalemgarden.net/. > > Hopefully this will at least get you here, fed and rested--let me know > if you have questions, and see you soon. > > Becky > > > On Tue, Apr 10, 2012 at 4:06 PM, Sebastian Rahtz > <sebastian.rahtz at oucs.ox.ac.uk> wrote: >> >> On 10 Apr 2012, at 20:53, Kevin Hawkins wrote: >> >>> The only thing I find in my email archive that Sebastian has suggested >>> is to write roma2 if we get bored. >> >> phew, no chance of that, luckily :-} >> >> though, as some of you know, James and I have submitted a small funding >> bid to JISC in the UK for a project which would make a good start >> on a new Roma >> >> Sebastian >> -- >> tei-council mailing list >> tei-council at lists.village.Virginia.EDU >> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council >> >> PLEASE NOTE: postings to this list are publicly archived -- Martin Holmes University of Victoria Humanities Computing and Media Centre (mholmes at uvic.ca) From James.Cummings at oucs.ox.ac.uk Thu Apr 12 05:59:03 2012 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Thu, 12 Apr 2012 10:59:03 +0100 Subject: [tei-council] Draft Agenda for AnnArbor2012 face2face meeting In-Reply-To: <4F85A002.6050602@uvic.ca> References: <4F856117.6090104@oucs.ox.ac.uk> <4F85A002.6050602@uvic.ca> Message-ID: <4F86A767.9010601@oucs.ox.ac.uk> Hi Martin, (et al.) You are right. I had entirely forgotten that. I've added on the first day as 'TEI and URIs' since it will affect how we deal with those tickets. Moving release process discussion to Weds since I don't think there is much to say about, Gaby (our next proposed release technician) won't be there, etc. If there are other things I've forgotten, do make sure to add them to the agenda. -James On 11/04/12 16:15, Martin Holmes wrote: > HI James, > > I thought we were going to discuss the issue of @ref/key/cRef & > Private URI Schemes. It was on the agenda for the February telco, > but would have taken too long to address fully then, and I > thought we agreed to move it forward to the ftf. I think it's > important, and it's not something that can be captured in a > single bug (although it's intrinsic to bugs 3480650 and 3413346). > > Cheers, > Martin > > On 12-04-11 03:46 AM, James Cummings wrote: >> Hi All, >> >> I've put a draft agenda up on the wiki at: >> >> http://wiki.tei-c.org/index.php/Council >> >> Now is the time to shout, re-order stuff, add stuff, etc. Feel >> free to change it (and/or add more detail) as you feel >> appropriate. >> >> My suggestion is that we organise each day to structurally >> alternate between other business and bugs/FR. e.g. warming up by >> talking about some of the issues/actions that have been raised, >> then work through bugs/FR, have lunch, talk about other issues, >> then work on bugs/FR. >> >> You'll notice the 'open lunch' on Tuesday. Kevin and Becky can >> tell us more about that. (psst, that is a cue.) >> >> I'm hoping because of Lou's triaging work (see >> http://www.tei-c.org/Activities/Council/Working/tcw17.html) we >> can progress through the Green bugs/FR very quickly and move on >> to the Amber ones. >> >> HOMEWORK: I would like *every* council member to spend some time >> (if you have not already) looking through *every* Green and then >> Amber Bug/FR. If you have any objections or comments, add it to >> the SF ticket for the item. If you think the right conclusion >> has been reached (e.g. on an Amber one), add it to the ticket. In >> the meeting *no* Bug/FR should come as a surprise to you! (Well, >> except perhaps ones submitted between now and then!) >> >> Minutes: Martin and Becky have volunteered to take minutes, and >> Kevin has arranged for a UM student to gain some experience by >> converting them to TEI. >> >> Flights: Can I confirm who amongst us needs to depart early on >> the Wednesday and by what time? Sebastian and my flight doesn't >> leave until about 10pm now, I believe. >> >> Remote Participants: I believe it is StuartY and GabyB that are >> participating remotely. Can you make sure that some of us have >> your skype usernames (and I know both of you know how to use the >> IRC channel). >> >> -James >> -- >> Dr James Cummings, InfoDev, >> Computing Services, University of Oxford > -- Dr James Cummings, InfoDev, Computing Services, University of Oxford From James.Cummings at oucs.ox.ac.uk Thu Apr 12 08:00:55 2012 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Thu, 12 Apr 2012 13:00:55 +0100 Subject: [tei-council] sunday hack session In-Reply-To: <4F85B332.3000303@uvic.ca> References: <4F845AE6.7010509@ultraslavonic.info> <D957117C-E9E0-43A0-A1C1-BC2A37DDB3C5@oucs.ox.ac.uk> <4F848FC6.2050704@ultraslavonic.info> <05C940C0-4D03-4FCE-A996-3DC6A625D028@oucs.ox.ac.uk> <CAA2irtLhNN4obsW=Z41rCrRGU90OfVeLLXEcehPegahr7VsrZw@mail.gmail.com> <4F85B332.3000303@uvic.ca> Message-ID: <4F86C3F7.1050300@oucs.ox.ac.uk> On 11/04/12 17:37, Martin Holmes wrote: > I just tried to book the AirRide shuttle, but it declined my credit > card. Has anyone successfully completed a booking with a non-US credit card? I didn't try because I'm never confident of airline schedules, or other opportunities, etc. I figured the difference in price was minimal ($12 vs $15 for a single) and that I'd be billing it to Oxford rather than the TEI-C. However, I've just watched The Millionaire Tour: http://www.imdb.com/title/tt1937388/ so I'm unlikely to be jumping in any strange taxis touting for business. ;-) -James > > Cheers, > Martin > > On 12-04-11 06:18 AM, Rebecca Welzenbach wrote: >> Hi all, >> >> Looking forward to seeing you soon. Some details that may be of >> interest as you arrive and get settled (will add them to the Google >> doc as well): >> >> *Transport* >> Last week I used the new AirRide shuttle that Paul mentioned, and >> recommend it, if you still need to make arrangements to get from the >> airport to campus. It was on time, comfortable, clean, runs >> frequently, etc., and is certainly the cheapest option. You can make >> reservations in advance here: http://www.myairride.com/. If you do >> this, be sure to print out everything and bring it with you. >> I think they also take walk-ons, for a slightly higher fee. You'll >> want to take the shuttle to the Central Campus Transit Center, which >> is a short walk from the hotel. >> >> *Maps* >> * From the shuttle station to the hotel: http://g.co/maps/8du2f >> * Hotel location and surrounding area: >> http://www.belltowerhotel.com/location.html >> * Map of central campus: http://www.umich.edu/~info/pdf/central.pdf >> * Map of the 4th floor of the Shapiro Library, where we'll be meeting: >> http://www.lib.umich.edu/navigator/shapiro4.html >> >> Note that, confusingly, the library map is oriented with north in the >> lower right hand corner. The big white square to the right of the map >> is our meeting room. The oddly shaped taupe area just above is where >> Kevin's and my office is. >> >> *food* >> You won't have any trouble finding places to eat and drink within >> walking distance of the hotel or the library, and most or all will be >> open on Sunday. >> >> * I believe your hotel reservation includes free continental breakfast >> (as well as in-room wireless), but I'll confirm this. >> * There's also a restaurant in the hotel, but I have no idea what it >> is like: http://www.mercysrestaurant.com/menu >> * There's a coffee shop on the first floor of the library, which has >> light (pre-made) fare like sandwiches, salads, and sushi as well as >> coffee and pastries: http://uunions.umich.edu/berts/ >> * Espresso Royale has locations close to the hotel and the library: >> http://www.espressoroyale.com/location.php?id=20 >> * Or if you prefer gourmet coffee and really excellent pastries, there >> is Comet Coffee: http://www.yelp.com/biz/comet-coffee-ann-arbor >> >> *Wireless* >> Non-UM-ers who will be on site will be assigned a temporary log-in so >> you can access the "MWireless" network used by faculty, staff, and >> students (the open "MGuest" network won't be sufficient for our work). >> Library Desktop Support is working now on setting up your >> accounts--hopefully they or I will be able to get the info to you >> before the end of the week. I'll also bring the details with me on >> Sunday, just in case. They know we need to be up and running over the >> weekend. >> >> I'm about to look over James' agenda, but want to note that on Tuesday >> we plan to have lunch catered in the library, and invite interested >> staff and other local people who might be interested to join us. >> Planning to order a variety of foods from >> http://www.jerusalemgarden.net/. >> >> Hopefully this will at least get you here, fed and rested--let me know >> if you have questions, and see you soon. >> >> Becky >> >> >> On Tue, Apr 10, 2012 at 4:06 PM, Sebastian Rahtz >> <sebastian.rahtz at oucs.ox.ac.uk> wrote: >>> >>> On 10 Apr 2012, at 20:53, Kevin Hawkins wrote: >>> >>>> The only thing I find in my email archive that Sebastian has suggested >>>> is to write roma2 if we get bored. >>> >>> phew, no chance of that, luckily :-} >>> >>> though, as some of you know, James and I have submitted a small funding >>> bid to JISC in the UK for a project which would make a good start >>> on a new Roma >>> >>> Sebastian >>> -- >>> tei-council mailing list >>> tei-council at lists.village.Virginia.EDU >>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council >>> >>> PLEASE NOTE: postings to this list are publicly archived > -- Dr James Cummings, InfoDev, Computing Services, University of Oxford From PFSchaffner at umich.edu Thu Apr 12 21:35:37 2012 From: PFSchaffner at umich.edu (Paul F. Schaffner) Date: Thu, 12 Apr 2012 21:35:37 -0400 (EDT) Subject: [tei-council] sunday hack session In-Reply-To: <4F85B332.3000303@uvic.ca> References: <4F845AE6.7010509@ultraslavonic.info> <D957117C-E9E0-43A0-A1C1-BC2A37DDB3C5@oucs.ox.ac.uk> <4F848FC6.2050704@ultraslavonic.info> <05C940C0-4D03-4FCE-A996-3DC6A625D028@oucs.ox.ac.uk> <CAA2irtLhNN4obsW=Z41rCrRGU90OfVeLLXEcehPegahr7VsrZw@mail.gmail.com> <4F85B332.3000303@uvic.ca> Message-ID: <Pine.LNX.4.64.1204122126070.16325@zaxxon.gpcc.itd.umich.edu> If anyone needs a local contact for any reason, transport or otherwise, please feel free to phone me. Mobile = 1 734 709 9144. I see that Mr. B. will be at The Ark on both Saturday and Sunday night (The Ark = the last of the folkie clubs, and a good visit; Mr. B. = Ann Arbor blues piano virtuoso.) http://theark.org/3066.html with the rest of the schedule here http://theark.org/search/results133428055489282.html pfs On Wed, 11 Apr 2012, Martin Holmes wrote: > I just tried to book the AirRide shuttle, but it declined my credit > card. Has anyone successfully completed a booking with a non-US credit card? > > Cheers, > Martin > > On 12-04-11 06:18 AM, Rebecca Welzenbach wrote: >> Hi all, >> >> Looking forward to seeing you soon. Some details that may be of >> interest as you arrive and get settled (will add them to the Google >> doc as well): >> >> *Transport* >> Last week I used the new AirRide shuttle that Paul mentioned, and >> recommend it, if you still need to make arrangements to get from the >> airport to campus. It was on time, comfortable, clean, runs >> frequently, etc., and is certainly the cheapest option. You can make >> reservations in advance here: http://www.myairride.com/. If you do >> this, be sure to print out everything and bring it with you. >> I think they also take walk-ons, for a slightly higher fee. You'll >> want to take the shuttle to the Central Campus Transit Center, which >> is a short walk from the hotel. >> >> *Maps* >> * From the shuttle station to the hotel: http://g.co/maps/8du2f >> * Hotel location and surrounding area: >> http://www.belltowerhotel.com/location.html >> * Map of central campus: http://www.umich.edu/~info/pdf/central.pdf >> * Map of the 4th floor of the Shapiro Library, where we'll be meeting: >> http://www.lib.umich.edu/navigator/shapiro4.html >> >> Note that, confusingly, the library map is oriented with north in the >> lower right hand corner. The big white square to the right of the map >> is our meeting room. The oddly shaped taupe area just above is where >> Kevin's and my office is. >> >> *food* >> You won't have any trouble finding places to eat and drink within >> walking distance of the hotel or the library, and most or all will be >> open on Sunday. >> >> * I believe your hotel reservation includes free continental breakfast >> (as well as in-room wireless), but I'll confirm this. >> * There's also a restaurant in the hotel, but I have no idea what it >> is like: http://www.mercysrestaurant.com/menu >> * There's a coffee shop on the first floor of the library, which has >> light (pre-made) fare like sandwiches, salads, and sushi as well as >> coffee and pastries: http://uunions.umich.edu/berts/ >> * Espresso Royale has locations close to the hotel and the library: >> http://www.espressoroyale.com/location.php?id=20 >> * Or if you prefer gourmet coffee and really excellent pastries, there >> is Comet Coffee: http://www.yelp.com/biz/comet-coffee-ann-arbor >> >> *Wireless* >> Non-UM-ers who will be on site will be assigned a temporary log-in so >> you can access the "MWireless" network used by faculty, staff, and >> students (the open "MGuest" network won't be sufficient for our work). >> Library Desktop Support is working now on setting up your >> accounts--hopefully they or I will be able to get the info to you >> before the end of the week. I'll also bring the details with me on >> Sunday, just in case. They know we need to be up and running over the >> weekend. >> >> I'm about to look over James' agenda, but want to note that on Tuesday >> we plan to have lunch catered in the library, and invite interested >> staff and other local people who might be interested to join us. >> Planning to order a variety of foods from >> http://www.jerusalemgarden.net/. >> >> Hopefully this will at least get you here, fed and rested--let me know >> if you have questions, and see you soon. >> >> Becky >> >> >> On Tue, Apr 10, 2012 at 4:06 PM, Sebastian Rahtz >> <sebastian.rahtz at oucs.ox.ac.uk> wrote: >>> >>> On 10 Apr 2012, at 20:53, Kevin Hawkins wrote: >>> >>>> The only thing I find in my email archive that Sebastian has suggested >>>> is to write roma2 if we get bored. >>> >>> phew, no chance of that, luckily :-} >>> >>> though, as some of you know, James and I have submitted a small funding >>> bid to JISC in the UK for a project which would make a good start >>> on a new Roma >>> >>> Sebastian >>> -- >>> tei-council mailing list >>> tei-council at lists.village.Virginia.EDU >>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council >>> >>> PLEASE NOTE: postings to this list are publicly archived > > -- > Martin Holmes > University of Victoria Humanities Computing and Media Centre > (mholmes at uvic.ca) > -- > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > > PLEASE NOTE: postings to this list are publicly archived > > > -------------------------------------------------------------------- Paul Schaffner | PFSchaffner at umich.edu | http://www.umich.edu/~pfs/ 316-C Hatcher Library N, Univ. of Michigan, Ann Arbor MI 48109-1190 -------------------------------------------------------------------- From kevin.s.hawkins at ultraslavonic.info Sat Apr 14 14:04:27 2012 From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins) Date: Sat, 14 Apr 2012 14:04:27 -0400 Subject: [tei-council] medical advice for our upcoming meeting Message-ID: <4F89BC2B.7090609@ultraslavonic.info> Since the next few days will involve a lot of problem-solving, I encourage you all to take this medical advice into account: http://www.medicaldaily.com/news/20120411/9496/alcohol-solving-skills-analytical-thinking-creativity-study.htm ;-) From mholmes at uvic.ca Sat Apr 14 14:34:32 2012 From: mholmes at uvic.ca (Martin Holmes) Date: Sat, 14 Apr 2012 11:34:32 -0700 Subject: [tei-council] medical advice for our upcoming meeting In-Reply-To: <4F89BC2B.7090609@ultraslavonic.info> References: <4F89BC2B.7090609@ultraslavonic.info> Message-ID: <4F89C338.9060600@uvic.ca> Oh good. I just started drinking again after teetotalling the first three months of the year. :-) I remember a very nice bar in Ann Arbor that served dozens of great beers and allowed you to try test sets of six or so in little glasses. Is it still there? Cheers, Martin On 12-04-14 11:04 AM, Kevin Hawkins wrote: > Since the next few days will involve a lot of problem-solving, I > encourage you all to take this medical advice into account: > > http://www.medicaldaily.com/news/20120411/9496/alcohol-solving-skills-analytical-thinking-creativity-study.htm > > ;-) From kevin.s.hawkins at ultraslavonic.info Sat Apr 14 14:42:47 2012 From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins) Date: Sat, 14 Apr 2012 14:42:47 -0400 Subject: [tei-council] medical advice for our upcoming meeting In-Reply-To: <4F89C338.9060600@uvic.ca> References: <4F89BC2B.7090609@ultraslavonic.info> <4F89C338.9060600@uvic.ca> Message-ID: <4F89C527.3060807@ultraslavonic.info> You might have been at Ashley's, which is right near Central Campus. Huge selection and probably offer samplers/flights. There are plenty of other options in town, some of which brew their own beer. I'm a big fan of the Jolly Pumpkin, which specializes in sour Belgian ales. The food is better there too. On 4/14/12 2:34 PM, Martin Holmes wrote: > Oh good. I just started drinking again after teetotalling the first > three months of the year. :-) > > I remember a very nice bar in Ann Arbor that served dozens of great > beers and allowed you to try test sets of six or so in little glasses. > Is it still there? > > Cheers, > Martin > > On 12-04-14 11:04 AM, Kevin Hawkins wrote: >> Since the next few days will involve a lot of problem-solving, I >> encourage you all to take this medical advice into account: >> >> http://www.medicaldaily.com/news/20120411/9496/alcohol-solving-skills-analytical-thinking-creativity-study.htm >> >> >> ;-) From James.Cummings at oucs.ox.ac.uk Sat Apr 14 17:34:51 2012 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Sat, 14 Apr 2012 17:34:51 -0400 Subject: [tei-council] Per Diem Rates; Supper Saturday Message-ID: <4F89ED7B.3000403@oucs.ox.ac.uk> Just a reminder that the Per Diem Rates for meals that the TEI-C uses for meals, in Ann Arbor are: 70% of $56 = $39 Specifically: Breakfast | 25% = $10 Lunch | 35% = $14 Dinner | 40% = $15 The original budget was for 3 days-worth of food. However, this budget included Gaby attending, which he now isn't. So I propose that those of us who are attending the optional TEI hackfest on Sunday also have food covered at the same per diem rate as above for that day as well. On a related note, Sebastian and I will be in the Belltower Hotel's lobby at 6pm'ish this evening before going somewhere for supper. Email us if you are around and want us to wait. -James -- Dr James Cummings, InfoDev, Computing Services, University of Oxford From sebastian.rahtz at oucs.ox.ac.uk Sat Apr 14 17:58:22 2012 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Sat, 14 Apr 2012 21:58:22 +0000 Subject: [tei-council] Per Diem Rates; Supper Saturday In-Reply-To: <4F89ED7B.3000403@oucs.ox.ac.uk> References: <4F89ED7B.3000403@oucs.ox.ac.uk> Message-ID: <543e7c7d-87ee-4e55-8f78-a7e0d5b4d3cd@HUB03.ad.oak.ox.ac.uk> breakfast at the hotel is included, and I hear Mr Crazy Joe's Blimbyburger is jolly fine, so thats a nice big lunch? sebastian From rwelzenbach at gmail.com Sat Apr 14 18:25:10 2012 From: rwelzenbach at gmail.com (Rebecca Welzenbach) Date: Sat, 14 Apr 2012 18:25:10 -0400 Subject: [tei-council] Per Diem Rates; Supper Saturday In-Reply-To: <543e7c7d-87ee-4e55-8f78-a7e0d5b4d3cd@HUB03.ad.oak.ox.ac.uk> References: <4F89ED7B.3000403@oucs.ox.ac.uk> <543e7c7d-87ee-4e55-8f78-a7e0d5b4d3cd@HUB03.ad.oak.ox.ac.uk> Message-ID: <CAA2irtLp8T5ayHA=iMaPJ86QM27=mKm9C4NikN2CiKDN9p0xDw@mail.gmail.com> Glad to hear you're beginning to arrive--I trust everything went smoothly at the hotel? I've got your temporary usernames and passwords for the MWireless network, and will bring them with me to the library tomorrow at 10 a.m. Becky On Sat, Apr 14, 2012 at 5:58 PM, Sebastian Rahtz <sebastian.rahtz at oucs.ox.ac.uk> wrote: > breakfast at the hotel is included, and I hear Mr ?Crazy Joe's Blimbyburger is jolly fine, so thats a nice big lunch? > > sebastian > -- > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > > PLEASE NOTE: postings to this list are publicly archived From sebastian.rahtz at oucs.ox.ac.uk Sun Apr 15 07:57:28 2012 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Sun, 15 Apr 2012 11:57:28 +0000 Subject: [tei-council] Per Diem Rates; Supper Saturday In-Reply-To: <CAA2irtLp8T5ayHA=iMaPJ86QM27=mKm9C4NikN2CiKDN9p0xDw@mail.gmail.com> References: <4F89ED7B.3000403@oucs.ox.ac.uk> <543e7c7d-87ee-4e55-8f78-a7e0d5b4d3cd@HUB03.ad.oak.ox.ac.uk>, <CAA2irtLp8T5ayHA=iMaPJ86QM27=mKm9C4NikN2CiKDN9p0xDw@mail.gmail.com> Message-ID: <5585cf8f-9abd-4fc1-b025-618044daf329@HUB06.ad.oak.ox.ac.uk> Yes, hotel is nice. I hear rain outside.. Carved in stone on my iPad From lou.burnard at retired.ox.ac.uk Sun Apr 15 08:30:36 2012 From: lou.burnard at retired.ox.ac.uk (Lou Burnard) Date: Sun, 15 Apr 2012 13:30:36 +0100 Subject: [tei-council] Per Diem Rates; Supper Saturday In-Reply-To: <5585cf8f-9abd-4fc1-b025-618044daf329@HUB06.ad.oak.ox.ac.uk> References: <4F89ED7B.3000403@oucs.ox.ac.uk> <543e7c7d-87ee-4e55-8f78-a7e0d5b4d3cd@HUB03.ad.oak.ox.ac.uk>, <CAA2irtLp8T5ayHA=iMaPJ86QM27=mKm9C4NikN2CiKDN9p0xDw@mail.gmail.com> <5585cf8f-9abd-4fc1-b025-618044daf329@HUB06.ad.oak.ox.ac.uk> Message-ID: <4F8ABF6C.50205@retired.ox.ac.uk> On 15/04/12 12:57, Sebastian Rahtz (wrote: > Yes, hotel is nice. I hear rain outside.. > > Carved in stone on my iPad > A masterly non-sequitur if ever I saw one. I assume that what woke me this morning was what CNN was bleating on about yesterday "severe weather conditions predicted for the great plains area" From kevin.s.hawkins at ultraslavonic.info Sun Apr 15 08:34:33 2012 From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins) Date: Sun, 15 Apr 2012 08:34:33 -0400 Subject: [tei-council] Per Diem Rates; Supper Saturday In-Reply-To: <4F8ABF6C.50205@retired.ox.ac.uk> References: <4F89ED7B.3000403@oucs.ox.ac.uk> <543e7c7d-87ee-4e55-8f78-a7e0d5b4d3cd@HUB03.ad.oak.ox.ac.uk>, <CAA2irtLp8T5ayHA=iMaPJ86QM27=mKm9C4NikN2CiKDN9p0xDw@mail.gmail.com> <5585cf8f-9abd-4fc1-b025-618044daf329@HUB06.ad.oak.ox.ac.uk> <4F8ABF6C.50205@retired.ox.ac.uk> Message-ID: <4F8AC059.20204@ultraslavonic.info> On 4/15/12 8:30 AM, Lou Burnard wrote: > I assume that what woke me this morning was what CNN was bleating on > about yesterday "severe weather conditions predicted for the great > plains area" That was a thunderclap. Actual severe weather was found last night in the actual Great Plains. I'm sure CNN's got the crews on the ground to show the wreckage. From PFSchaffner at umich.edu Sun Apr 15 19:56:28 2012 From: PFSchaffner at umich.edu (Paul F. Schaffner) Date: Sun, 15 Apr 2012 19:56:28 -0400 (EDT) Subject: [tei-council] Examples of <head>s containing <l> In-Reply-To: <4F8ABF6C.50205@retired.ox.ac.uk> References: <4F89ED7B.3000403@oucs.ox.ac.uk> <543e7c7d-87ee-4e55-8f78-a7e0d5b4d3cd@HUB03.ad.oak.ox.ac.uk>, <CAA2irtLp8T5ayHA=iMaPJ86QM27=mKm9C4NikN2CiKDN9p0xDw@mail.gmail.com> <5585cf8f-9abd-4fc1-b025-618044daf329@HUB06.ad.oak.ox.ac.uk> <4F8ABF6C.50205@retired.ox.ac.uk> Message-ID: <Pine.LNX.4.64.1204151954320.14120@punchout.gpcc.itd.umich.edu> At Lou's request (in conversation). http://www.lib.umich.edu/tcp/docs/dox/verse_in_head.html Some (though not all) can be squeezed into <argument> rather than <head>, but I think that the most natural tagging for most, if not all, of these examples, is <head> <l>...</l> <l>...</l> See if you agree. pfs -------------------------------------------------------------------- Paul Schaffner | PFSchaffner at umich.edu | http://www.umich.edu/~pfs/ 316-C Hatcher Library N, Univ. of Michigan, Ann Arbor MI 48109-1190 -------------------------------------------------------------------- From rwelzenbach at gmail.com Mon Apr 16 09:11:35 2012 From: rwelzenbach at gmail.com (Rebecca Welzenbach) Date: Mon, 16 Apr 2012 09:11:35 -0400 Subject: [tei-council] Fwd: TEI Council Face 2 Face Ann Arbor 2012 - Minutes (mholmes@uvic.ca) In-Reply-To: <4F86C73C.5090503@uvic.ca> References: <20cf305495f3df5d8e04bd79f030@google.com> <4F86C73C.5090503@uvic.ca> Message-ID: <CAA2irt+xnEPkPzymb_kfSxjhy55Nx_SQ0FP6a=-teG5F97kRjg@mail.gmail.com> Here's the link to the "minutes" google doc ---------- Forwarded message ---------- From: Martin Holmes <mholmes at uvic.ca> Date: Thu, Apr 12, 2012 at 8:14 AM Subject: Re: TEI Council Face 2 Face Ann Arbor 2012 - Minutes (mholmes at uvic.ca) To: "James Cummings (Google Docs)" <james at blushingbunny.net> Cc: "rwelzenb at umich.edu" <rwelzenb at umich.edu> Tested and working. On 12-04-12 04:48 AM, James Cummings (Google Docs) wrote: > > ? ? ? ?I've shared TEI Council Face 2 Face Ann Arbor 2012 - Minutes > <https://docs.google.com/document/d/15kJ22QBO6B5M_YuMHUD3_cLE3rOFU_wkCkugwvWl6-4/edit> > > Click to open: > > ?* TEI Council Face 2 Face Ann Arbor 2012 - Minutes > ? ?<https://docs.google.com/document/d/15kJ22QBO6B5M_YuMHUD3_cLE3rOFU_wkCkugwvWl6-4/edit> > > > Google Docs makes it easy to create, store and share online documents, > spreadsheets and presentations. > Logo for Google Docs <https://docs.google.com> From PFSchaffner at umich.edu Mon Apr 16 19:08:03 2012 From: PFSchaffner at umich.edu (Paul F. Schaffner) Date: Mon, 16 Apr 2012 19:08:03 -0400 (EDT) Subject: [tei-council] SIGNED Message-ID: <Pine.LNX.4.64.1204161906130.15944@punchout.gpcc.itd.umich.edu> I've unearthed the three messages I sent to Council back in November, not because they change the discussion much, but because one of them at least contains numerous examples that may serve as test cases for whatever scheme (if any) that we end up adopting. I'll reforward them to the list, and you may delete at your pleasure pfs -------------------------------------------------------------------- Paul Schaffner | PFSchaffner at umich.edu | http://www.umich.edu/~pfs/ 316-C Hatcher Library N, Univ. of Michigan, Ann Arbor MI 48109-1190 -------------------------------------------------------------------- From PFSchaffner at umich.edu Mon Apr 16 19:08:18 2012 From: PFSchaffner at umich.edu (Paul F. Schaffner) Date: Mon, 16 Apr 2012 19:08:18 -0400 (EDT) Subject: [tei-council] signed/list (fwd) Message-ID: <Pine.LNX.4.64.1204161908120.15944@punchout.gpcc.itd.umich.edu> -------------------------------------------------------------------- Paul Schaffner | PFSchaffner at umich.edu | http://www.umich.edu/~pfs/ 316-C Hatcher Library N, Univ. of Michigan, Ann Arbor MI 48109-1190 -------------------------------------------------------------------- ---------- Forwarded message ---------- Date: Mon, 21 Nov 2011 18:33:43 -0500 (EST) From: Paul F. Schaffner <PFSchaffner at umich.edu> To: Lou Burnard <lou.burnard at retired.ox.ac.uk> Cc: "tei-council at lists.village.virginia.edu" <tei-council at lists.village.virginia.edu> Subject: Re: [tei-council] signed/list On Sat, 19 Nov 2011, Lou Burnard wrote: > Hi Paul > > On 19/11/11 00:02, Paul F. Schaffner wrote: > >> -- to be honest, the 'narrow' definition just doesn't make >> any sense to me, for reasons I have explained before, >> and virtually impossible to apply. > > I'm curious as to what makes you say that, and apologetic for having > forgotten your previous explanation. Lou, My difficulty was that I could find no ready way to distinguish -- or rationale for distinguishing -- those phrases descriptive of the signer which belonged in signed from those that did not. Here is a reprint of part of my message on the subject from September of 2010, which I think explains the problem as I saw it. ---snip--- I think there were a few factors ... that led to our interpretation of <signed> as a container for all the 'yours truly' sort of phrases (to my mind, 'signing phrases,' not 'greeting phrases'). The most important was perhaps that in writing instructions for data-conversion firms, I could find no tenable rule by which to tell them to distinguish between many grammatically and semantically similar constructions, as splitting them between <signed> and <salute> seemed to require. E.g.: (1) Everyone agrees (I think) that the first three examples below belong entirely in <signed>. But I could see no essential difference between those and the fourth and fifth examples, which some would divide between <signed> and <salute>: #1 <CLOSER> <SIGNED>John</SIGNED> </CLOSER> #2 <CLOSER> <SIGNED>John, lieutenant of the Tower</SIGNED> </CLOSER> #3 <CLOSER> <SIGNED>John, lieutenant of the Tower and servant of God</SIGNED> </CLOSER> #4 <CLOSER> <SIGNED>John, lieutenant, etc., and your obedient servant</SIGNED> </CLOSER> #5 <CLOSER> <SIGNED>Your obedient servant, John, lieutenant of the Tower.</SIGNED> </CLOSER> (2) Likewise, I could see no essential difference between phrases, all descriptive of the signatory, that happened to refer to the addressee and those that did not. I gather that some would put the former (#2 below) in <salute> but not the latter (#1 below). Nor could I see what to do--or how to tell my keyers what to do--when both kinds of phrases were combined (#3 below). #1 <CLOSER> <SIGNED>A Public Servant</SIGNED> </CLOSER> #2 <CLOSER> <SIGNED>Your obedient Servant</SIGNED> </CLOSER> #3 <CLOSER> <SIGNED>A Friend to Humanity and to your Welfare</SIGNED> </CLOSER> -- Someone in this thread suggested that every <signed> must contain a name (or at least a nom de plume). We tag many abbreviated ones that do not, usu.of the form <signed>Yours truly, &c.</signed> Surely this falls under the definition of <signed> as 'a closing salutation'! -- Below is a random and generous selection of <signed> tags (and a few <salute>s) from the 5,546 found in my current review batch. Tag them as you will! See how much variety, or unanimity, arises (n.b., you will see that we allow <list> within <signed>, a local customization.) pfs Samples ======= <SIGNED>Jeremiah Rich.</SIGNED> <SIGNED>Yours (desirous particularly to be engaged yours to serve you,) <HI>JOHN LILBURN.</HI></SIGNED> <SIGNED>Your assured loving friend and servant, EDWARD WOLBY.</SIGNED> <SIGNED>A Faithfull Servant to all Lovers of <HI>Musick,</HI> JOHN PLAYFORD.</SIGNED> <SIGNED><HI>Your Lordship</HI>'s <HI>most Faithful and most Obedient Servant,</HI> Stephen Willoughby.</SIGNED> <SIGNED>Your servant till Death. <HI>Captaine</HI> John Williams.</SIGNED> <SIGNED>From a Sufferer for the Truth and Righteousness sake, known to many of you by the Name of <HI>Isabel Wails.</HI> </SIGNED> <SIGNED><HI>Jo. Radford</HI> Foreman of the Mineral Grand Jury there, with his fellows. <LIST> <ITEM><HI>Walter Webb.</HI></ITEM> <ITEM><HI>Richard Franke.</HI></ITEM> <ITEM><HI>Richard Adams.</HI></ITEM> <ITEM><HI>Jahn Phelps.</HI></ITEM> <ITEM><HI>Thomas Younge.</HI></ITEM> <ITEM><HI>William Dowling.</HI></ITEM> <ITEM><HI>Alexandor Cuer.</HI></ITEM> <ITEM><HI>William Hopkins.</HI></ITEM> <ITEM><HI>Jonas Lexstond.</HI></ITEM> <ITEM><HI>John House.</HI></ITEM> <ITEM><HI>Richard Ayrer.</HI></ITEM> </LIST></SIGNED> <SIGNED>A True Lover of his Countries Honour, <HI>W. W.</HI> </SIGNED> <SIGNED><HI>Your most affectionately devoted Brethren in Christ,</HI> <LIST> <ITEM>Commissioners of the Church of <HI>Scotland.</HI> <LIST> <ITEM><HI>Jo. Maitland,</HI></ITEM> <ITEM><HI>A. Jhonston,</HI></ITEM> <ITEM><HI>Alex. Henderson,</HI></ITEM> <ITEM><HI>Sam. Rutherfurd,</HI></ITEM> <ITEM><HI>Rob. Bailyie.</HI></ITEM> <ITEM><HI>Geo. Gillespie.</HI></ITEM> </LIST> </ITEM> <ITEM><HI>William Twisse,</HI> Prolocutor,</ITEM> <ITEM><HI>Cornel. Burges,</HI> Assessor,</ITEM> <ITEM><HI>Jo. White,</HI> Assessor,</ITEM> <ITEM><HI>Henry Robrough,</HI> Scribe,</ITEM> <ITEM><HI>Adoniram Byfield,</HI> Scribe.</ITEM> </LIST></SIGNED> <SIGNED>H. Elsynge, Cler. Parl. D. Com.</SIGNED> <SIGNED>Wholly and intirely your most affectionate Kinsman and humble servant. <HI>F. W.</HI></SIGNED> <SIGNED>Thy most Affectionate and Faithful Husband, and their most loving Father, <HI>J. H.</HI></SIGNED> <SIGNED>Thy souls well-wisher, <HI>Richard Kentish.</HI></SIGNED> <SIGNED><LIST> <ITEM><HI>Adam Samuel Hartman,</HI> Pastor of the Church of <HI>Lesna</HI> in <HI>Poland,</HI> and Rector of the famous University there.</ITEM> <ITEM><HI>Paul Cyril</HI> a late Member of the Univer&s;ity of <HI>Ly&s;na.</HI></ITEM></LIST></SIGNED> <SALUTE>SIR,</SALUTE> <SIGNED>An Admirer of your indefatigable industry and rare abilities, JOHN TRAPP.</SIGNED> <DATELINE>Written in the true fear of the Lord,</DATELINE> <SIGNED>by me his Servant, Anthony Tompkins.</SIGNED> <DATELINE><DATE>The 2d day of the 11th Moneth, 68.</DATE></DATELINE> <SIGNED>Yours, The Inhabitants of the County of Rutland.</SIGNED> <DATELINE>Written in <HI>York</HI> Castle,</DATELINE> <SIGNED>by your dear Brother, and lover of your souls, known unto you by the name of <HI>Samuel Thornton.</HI></SIGNED> <SIGNED>Your Maiesties faithfull Subiects and Servants. <LIST> <ITEM>Earle <HI>Lothian.</HI></ITEM> <ITEM>Earle <HI>Lindesay.</HI></ITEM> <ITEM>Lord <HI>Balmerino.</HI></ITEM> <ITEM>Sir <HI>Thomas Morton.</HI></ITEM> <ITEM>Sir <HI>Thomas Hope.</HI></ITEM> <ITEM>Sir <HI>Archibauld Johnston</HI></ITEM> <ITEM>Burgesses.</ITEM> <ITEM>Sir <HI>Iohn Smith.</HI></ITEM> <ITEM>Master <HI>Robert Barklay.</HI></ITEM> <ITEM>Master <HI>Patrick Bell.</HI></ITEM> </LIST></SIGNED> <SALUTE>VALE LECTOR, & fruere.</SALUTE> <SALUTE>Adieu Madam.</SALUTE> <SIGNED>Your Servant, <HI>&c.</HI></SIGNED> <SIGNED>So help me God. <HI>DANIEL SCARGILL.</HI></SIGNED> <SIGNED>Your sorrowfull friend, and brother in Christ, <HI>Thomas Sweet.</HI></SIGNED> <SIGNED>Your Worships affectionate Kinsman and Servant.</SIGNED> <SIGNED>Your Lordship's Most Passionate Admirer And Most Devoted Humble Servant.</SIGNED> <SIGNED>Your true friend and Cosen, <HI>Nathanael Warters.</HI></SIGNED> <SIGNED>We subscribe our selves, Your Brethren in the Faith and Fellowship of the Gospel, <LIST> <ITEM><HI>William Kiffin,</HI></ITEM> <ITEM><HI>George Barrett,</HI></ITEM> <ITEM><HI>Robert Steed,</HI></ITEM> <ITEM><HI>Edward Man.</HI></ITEM> </LIST></SIGNED> <SIGNED>Thine to serve thee for the Publike good, G. A.</SIGNED> <SALUTE>>MY LORD!</SALUTE> <SIGNED>Your <HI>Highness,</HI> though unknown, yet most humble servant.</SIGNED> <SIGNED><HI>From thy Friend, and all Peoples, In Sincerity and Truth,</HI> Thomas Rudd.</SIGNED> <SIGNED><HI>one</HI> of the meanest of Your Servants for Christ, and this Commonwealth. <HI>JO. ROGERS.</HI></SIGNED> <SIGNED>Your affectionate fellow Apprentices of Bridge Ward within.</SIGNED> <DATELINE><HI>Dated</HI> <DATE>the 17 <HI>of</HI> May, 1649. <HI>the first year of Englands hopeful Restauration, through the blessing of God, to its primitive Liberty.</HI></DATE></DATELINE> <SALUTE>My Lord, </SALUTE> <SIGNED><HI>Your Most Humble and Most Obedient Servants, the Agents General of the Clergy of</HI> France. <HI>The Abbot</HI> de VILLARS. <HI>The Abbot</HI> PHILYPEA&V;X.</SIGNED> <DATELINE><HI>Paris</HI> <DATE>this <HI>2d. of</HI> October, <HI>1688.</HI></DATE></DATELINE> <SIGNED>By the Contriver of the Citizens Protestation, here following.</SIGNED> <SIGNED><HI>Yours unfeignedly, in the right way of the Gospel to serve you faithfully, according to my measure in the things of Jesus Christ,</HI> THO: LAMBE.</SIGNED> <SALUTE>(SIR,)</SALUTE> <SIGNED>Your most affectionate Friend, heartily to serve you [being yet as much an English man as ever I was] <HI>JOHN LILBURN, Semper idem</HI></SIGNED> <DATELINE>From my delightfull dwelling in Bruges, <DATE>Saturday, Novemb. the 9. 1652. New stile.</DATE></DATELINE> <TRAILER>The End.</TRAILER> <SIGNED><HI>I subscribe myself Your Fellow-Citizen,</HI> A FRIEND TO HUMANITY.</SIGNED> <SIGNED>Your servant, S--l C--h, forever.</SIGNED> <SIGNED>THOMAS GORDON, Attorney in fact for WILLIAM CUNNINGHAM & Co.</SIGNED> <SIGNED>WM. GIBBONS, <HI>President and Delegate from Chatham.</HI> </SIGNED> <SIGNED>Thomas Gozaeus a Bellomonte, sacrae Theologiae Professor, & authoritate Pontificis librorum approbator.</SIGNED> <SIGNED>Your Honours obliged servant though unworthiest among the Ministers of Christ. <HI>THO. MARRIOT.</HI></SIGNED> From PFSchaffner at umich.edu Mon Apr 16 19:08:28 2012 From: PFSchaffner at umich.edu (Paul F. Schaffner) Date: Mon, 16 Apr 2012 19:08:28 -0400 (EDT) Subject: [tei-council] signed/list (fwd) Message-ID: <Pine.LNX.4.64.1204161908220.15944@punchout.gpcc.itd.umich.edu> -------------------------------------------------------------------- Paul Schaffner | PFSchaffner at umich.edu | http://www.umich.edu/~pfs/ 316-C Hatcher Library N, Univ. of Michigan, Ann Arbor MI 48109-1190 -------------------------------------------------------------------- ---------- Forwarded message ---------- Date: Mon, 21 Nov 2011 19:21:49 -0500 (EST) From: Paul F. Schaffner <PFSchaffner at umich.edu> To: Lou Burnard <lou.burnard at retired.ox.ac.uk> Cc: "tei-council at lists.village.virginia.edu" <tei-council at lists.village.virginia.edu> Subject: Re: [tei-council] signed/list Of course the *other* inconsistency with <signed> is between the prose definition ('closing salutation') and the scheme, which allows it in both div.top and div.bottom. We followed the scheme rather than the prose which (given the variety of epistolary form, among other things) seemed the reasonable course. And it allows us to break formulaic openers like these into <signed> and <salute> blocks: <OPENER> <SIGNED>JAMES the Second, By the Grace of God, King of England, Scotland, France and Ireland, Defender of the Faith, &c.</SIGNED> <SALUTE>TO ALL and Singular Archbishops, Bishops, Archdeacons, Deans, and their Officials, Parsons, Vicars, Curates, and all other Spiritual Persons: And also to all Iustices of the Peace, Mayors, Sheriffs, Bayliffs, Constables, Churchwardens, Chappelwardens, Headboroughs, Collectors for the Poor, and their Overseers: And also to all Officers of Cities, Boroughs, and Towns Corporate, and to all other Our Officers, Ministers and Subjects whatsoever they be, as well within Liberties as without, to whom these Presents shall come, Greeting.</SALUTE> </OPENER> pfs From PFSchaffner at umich.edu Mon Apr 16 19:08:46 2012 From: PFSchaffner at umich.edu (Paul F. Schaffner) Date: Mon, 16 Apr 2012 19:08:46 -0400 (EDT) Subject: [tei-council] signed/list (fwd) Message-ID: <Pine.LNX.4.64.1204161908380.15944@punchout.gpcc.itd.umich.edu> -------------------------------------------------------------------- Paul Schaffner | PFSchaffner at umich.edu | http://www.umich.edu/~pfs/ 316-C Hatcher Library N, Univ. of Michigan, Ann Arbor MI 48109-1190 -------------------------------------------------------------------- ---------- Forwarded message ---------- Date: Tue, 22 Nov 2011 16:47:08 -0500 (EST) From: Paul F. Schaffner <PFSchaffner at umich.edu> To: Lou Burnard <lou.burnard at retired.ox.ac.uk> Cc: "tei-council at lists.village.virginia.edu" <tei-council at lists.village.virginia.edu> Subject: Re: [tei-council] signed/list Yes, that is a good summary. And I know that there are still ambiguous and intermingled cases -- but I find that this approach reduces them to a manageable number. I suspect that (multiple signatories aside), we are not that far apart: it is just that I have come to regard 'your servant' 'your darling John' etc. as, in effect, part of the signer's name -- name in the sense of 'self-designation' -- not different in kind from 'dei gratia rex angliae'. pfs On Tue, 22 Nov 2011, Lou Burnard wrote: > Many thanks for this florilegium ... which entirely persuades me (if there > were any doubt) that the current statements in the Guidelines about the > intended usage of these elements are in serious need of revision. > > Leaving aside syntactic questions, would it be fair to say that for you at > least the distinction between "signature" and "salute" is that the latter is > always in the vocative -- it is ostensibly addressed to someone -- while the > former is always (is there such a word?) "presentative" -- it always > ostensibly presents the identity of the writer or signatory ? > > This seems a plausible distinction, but even there it's easy to imagine (or > to find) cases where the two are almost inextricably mixed. > > I am (dear sir) your very humble servant > > Lou > > p.s. and I apologise again for not having paid more attention to your note > back in september 2010 -- it was obviously too interesting to deal with at > the time > > > On 21/11/11 23:33, Paul F. Schaffner wrote: > > > -------------------------------------------------------------------- Paul Schaffner | PFSchaffner at umich.edu | http://www.umich.edu/~pfs/ 316-C Hatcher Library N, Univ. of Michigan, Ann Arbor MI 48109-1190 -------------------------------------------------------------------- From James.Cummings at oucs.ox.ac.uk Mon Apr 16 22:33:25 2012 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Mon, 16 Apr 2012 22:33:25 -0400 Subject: [tei-council] per diem rate for Council meetings In-Reply-To: <35D067FC-AF14-4708-90EE-4A7FBE6C1BBC@virginia.edu> References: <35D067FC-AF14-4708-90EE-4A7FBE6C1BBC@virginia.edu> Message-ID: <4F8CD675.9080505@oucs.ox.ac.uk> Dear Council, Several of you asked me to check that the rates I had mentioned were correct. I've not emailed Sarah again, but here is her original message below. I might note that Breakfast is included with the hotel, so perhaps that amount of money might be used towards dinner. I've included the same system's rates for Oxford demonstrating that the state department eats well when abroad and barely when in Ann Arbor. -James -------- Original Message -------- Subject: Re: [tei-council] per diem rate for Council meetings Date: Fri, 11 Nov 2011 17:12:22 +0000 From: Sarah Wells <spw4s at virginia.edu> To: James Cummings <james.cummings at oucs.ox.ac.uk> Dear James, For Ann Arbor, 70% of $56 = $39 Breakfast | 25% = $10 Lunch | 35% = $14 Dinner | 40% = $15 For Oxford, 70% of $177 = $124 Breakfast | 25% = $30 Lunch | 35% = $44 Dinner | 40% = $50 Yrs, Sarah From PFSchaffner at umich.edu Tue Apr 17 08:43:41 2012 From: PFSchaffner at umich.edu (Paul F. Schaffner) Date: Tue, 17 Apr 2012 08:43:41 -0400 (EDT) Subject: [tei-council] floating divs In-Reply-To: <Pine.LNX.4.64.1204161908380.15944@punchout.gpcc.itd.umich.edu> References: <Pine.LNX.4.64.1204161908380.15944@punchout.gpcc.itd.umich.edu> Message-ID: <Pine.LNX.4.64.1204170843150.8707@punchout.gpcc.itd.umich.edu> Hastily assembled examples, not the best and mostly (Martin's favorite) songs in drama. <STAGE>Arrived at the Scene againe and meaning to reascend, <HI>MERCVRY</HI> finding some impedi|ment <PB N="7" REF="5"> by the way of question adresses himselfe to the Company.</STAGE> <P><TEXT> <BODY> <DIV1 TYPE="song"> <HEAD>The third Song.</HEAD> <SP> <SPEAKER>MERCVRY.</SPEAKER> <L>What mak's me so vnnimbly ryse,</L> <L>That did descend so fleete?</L> <L>There is no vp-hill in the skyes;</L> <L>Clouds stay not feathered feete.</L> </SP> <SP> <SPEAKER>CHORVS.</SPEAKER> <L>Thy wings are sing'd: and thou canst fly</L> <L>But slowly now, swift <HI>MERCVRY.</HI></L> </SP> <SP> <SPEAKER>MERCVRY.</SPEAKER> <L>Some Lady heere, is sure too blame</L> <L>That from Loves starry skyes,</L> <L>Hath shot some Beame, or sent some flame,</L> <L>Like Lghtning, from her Eyes.</L> </SP> <SP> <SPEAKER>CHORVS.</SPEAKER> <L>Taxe not the Starrs, with what the Sunne,</L> <L>Too neere aproch't (insens't) hath done.</L> </SP> <SP> <SPEAKER>MERCVRY.</SPEAKER> <L>I'le rowle me in Auroras Dew,</L> <L>Or lye in Tethis bed;</L> <L>Or from coole Iris begge a few,</L> <L>Pure Opale shewrs new shed.</L> </SP> <SP> <PB N="8" REF="6"> <SPEAKER>CHORVS.</SPEAKER> <L>Nor Dew, nor shewers, nor sea can slake</L> <L>Thy quenchlesse heate, but Lethes lake.</L> </SP> </DIV1> </BODY> </TEXT></P> </DIV2> </DIV1> <DIV1 TYPE="scene"> ------------------ I will propound an Obiection, which seemeth to make for the Papists, at least in Popish sence and mea|ning.</P> <P><TEXT LANG="eng"> <BODY> <DIV1 TYPE="objection"> <HEAD>The Obiection.</HEAD> <P>Two <HI>adequate</HI> bodies may be in one place at once, and yet neither the place be deuided into two places, nor yet the <PB N="53" REF="33" MS="y"> bodies transformed or confounded into one body: Ergo, à <HI>simili,</HI> one body may be in two places at once (as Christs body in many thousand Altars at popish Masse,) and yet neyther the body deuided into two places, neyther the two places contracted into one.</P> </DIV1> </BODY> </TEXT></P> </SP> <SP> <SPEAKER>T. B.</SPEAKER> <P>When you (O Iesuite) shall be able to proue the Ante|cedent, which will be <HI>ad Calendas Graecas,</HI> when men vse to clip Pigges and Rats) I will yeeld vnto you.</P> </SP> ------------------ <SP> <SPEAKER>Ai.</SPEAKER> <P>Why the Devil don't you then? Gad, I fancy you are as fond of being ask'd as I. Why, you &s;ing almo&s;t as well as I do. Come, let's &s;ing the la&s;t Dialogue our Ma&s;ter &s;et.</P> </SP> <P><TEXT> <BODY> <DIV1 TYPE="song"> <HEAD>DIALOGUE.</HEAD> <SP> <SPEAKER>Man.</SPEAKER> <L>Hark you, Madam, can't I move you? </L> <L>why the Devil do you run?</L> <L><PB N="42" REF="28">Ha'n't I told you twice I love you? </L> <L>come then, ki&s;s me, or I'm gone.</L> </SP> <SP> <SPEAKER>Wom.</SPEAKER> <L>Foh! I hate a Raki&s;h Lover, </L> <L>Do not di&s;compo&s;e my Dre&s;s:</L> <L>Good familiar Spark, give over! </L> <L>how on Quality you pre&s;s!</L> </SP> <SP> <SPEAKER>Man.</SPEAKER> <L>From the Counte&s;s to the Cit, </L> <L>ev'ry Beauty for me dies:</L> <L>Demme, why &s;hould I &s;ubmit</L> <L> to do at on <HI>this</HI> Woman's Eyes!</L> </SP> <SP> <SPEAKER>Wom.</SPEAKER> <L>Fifty Beaux expire for me, </L> <L>ogling, &s;ighing all the Day;</L> <L>Yet not one dares be &s;o free, </L> <L>tho they let me win at Play.</L> </SP> <SP> <SPEAKER>Man.</SPEAKER> <L>Sure we Rakes can better move you; </L> <L>&s;ee this Shape and Leg, my Dear!</L> <L>In one Minute more I'll love you </L> <L>than tho&s;e Fops can in a Year.</L> </SP> <SP> <SPEAKER>Wom.</SPEAKER> <L>But your Love will &s;oon be over.</L> </SP> <SP> <SPEAKER>Man.</SPEAKER> <L>Then you'll get a fre&s;her Lover.</L> <L>Come, to Bed! I long t'embrace.</L> </SP> <SP> <SPEAKER>Wom.</SPEAKER> <L>Leave my Hand!</L> </SP> <SP> <SPEAKER>Man.</SPEAKER> <L>—Then lend your Face!</L> <L>Fir&s;t the Hand, and then the Face,</L> <L>Then the Brea&s;t,</L> <L>And then the re&s;t,</L> <L>Then the Breast, and then—</L> </SP> <SP> <SPEAKER>Wom.</SPEAKER> <L>—The Face.</L> </SP> <STAGE>Gives him a &s;lap 'othe Face.</STAGE> <SP> <SPEAKER>Man.</SPEAKER> <L>'s Death, I've a good mind to beat you;</L> <L>No; to vex you more, I'llgo.</L> <L>Thus I puff you—I'll go &s;ay,</L> <L>I refus'd your Love to Day.</L> </SP> <SP> <SPEAKER>Wom.</SPEAKER> <L>Then I'll &s;ay how I did treat you.</L> </SP> <STAGE>Both together</STAGE> <SP> <SPEAKER> Man.</SPEAKER> <L>None will believe you cou'd do &s;o.</L> </SP> <SP> <SPEAKER>Wom.</SPEAKER> <L>All will believe I us'd you &s;o.</L> </SP> </DIV1> </BODY> </TEXT></P> <SP> <PB N="43" REF="28"> <SPEAKER>Ai.</SPEAKER> <P>Pretty well, pretty well, all but that damn'd Slap on the Face—Well, I &s;hall run mad for you in Two Days, that's certain.</P> </SP> -------------- <STAGE>Enter Mr. <HI>Redding</HI> in a Smith's Habit, a Bottle in his hand. He &s;ings; &s;eemingly drunk.</STAGE> <P><TEXT> <BODY> <DIV1 TYPE="song"> <HEAD>SONG.</HEAD> <SP> <SPEAKER>Man.</SPEAKER> <L>SHou'd I not lead a happy Life&punc; </L> <L>Were but my Bottle like my Wife! </L> <L>My Bottle empties when I &s;will, </L> <L>But my Wife &s;wells up when we bill.</L> <L><PB N="19" REF="16">Wou'd (when I drink) my Bottle fill, </L> <L>And (when I ki&s;s) my Wife not &s;well, </L> <L>All wou'd be well: </L> <L>I wou'd &s;o bill, </L> <L>So fill, &s;o &s;will,</L> <L> That daily gaily I wou'd &s;pend my Life, </L> <L>Sucking, filling, </L> <L>Hugging, billing, </L> <L>My merry Bottle and my Wife.</L> </SP> <STAGE> Drinks; then throws away his Bottle, and takes up a Quart Pot.</STAGE> <STAGE> <HI>Enter Mr.</HI> Lee <HI>dre&s;t as the Smith's Wife and big-bellied.</HI></STAGE> </DIV1> <DIV1 TYPE="song"> <HEAD>DIALOGUE.</HEAD> <SP> <SPEAKER>Wom.</SPEAKER> <L>STill at your Pot, </L> <L>You drunken Sot? </L> <L>You till I come </L> <L>Will ne're go home; </L> <L>And when you're there, </L> <L>You cur&s;e and &s;wear; </L> <L>Then prove a Bed </L> <L>A lump of Lead.</L> </SP> <SP> <SPEAKER>Man.</SPEAKER> <L>D' you think, you Scold, </L> <L>I'll be controul'd? </L> <L>No more be &s;aid: </L> <L>Or at your Head, </L> <L>As I'm a Sot, </L> <L>Sou&s;e flys the Pot! </L> <L>But fir&s;t, I think, </L> <L>I'll &s;ave the Drink.</L> </SP> <STAGE>Drinks.</STAGE> <SP> <SPEAKER>Wom.</SPEAKER> <L>Hold, leave a &s;up, </L> <L>Don't drink all up.</L> </SP> <SP> <SPEAKER>Man.</SPEAKER> <L>Here, ta&s;te and know </L> <L>Why I'll not go.</L> </SP> <STAGE>He gives her the Drink, &s;he drinks.</STAGE> <SP> <PB N="20" REF="17"> <SPEAKER>Wom.</SPEAKER> <L>How &s;weet! oh how it chears my heart!</L> <L>O dear! methinks I &s;uck my Mother.</L> <L>Here's t'you, my Love! have t' other Quart, </L> <L>And then—</L> </SP> <SP> <SPEAKER>Man.</SPEAKER> <P>—What then?</P> </SP> <SP> <SPEAKER>Wom.</SPEAKER> <L>—And then another.</L> </SP> <SP> <SPEAKER>Both.</SPEAKER> <L>Come, now we're Friends, and all is right.</L> </SP> <SP> <SPEAKER>Man.</SPEAKER> <L>Drink, drink all day:</L> </SP> <SP> <SPEAKER>Wom.</SPEAKER> <L>———But love at night.</L> </SP> <SP> <SPEAKER>Both.</SPEAKER> <L>Drink, drink all day, but love at night.</L> </SP> <STAGE>Both going off lovingly.</STAGE> </DIV1> </BODY> </TEXT></P> <SP> <SPEAKER>Sir Top.</SPEAKER> <P>Now this is &s;omething like a Tanzy: here Friends, there's a couple of Shillings for you to drink.</P> </SP> --------------- <P>So I de&s;ire all you that be Schollars, that either reads it, or hears it read, let it be a good in&s;truction for you all, in the fir&s;t place to <PB N="19" REF="11"> learn to &s;erve God: &s;econdly, to give honour and obedience to thy Parents: thirdly, let not thy heart over-&s;lip thée with <GAP DESC="illegible" RESP="apex" EXTENT="1 letter">nvy and ha|tred towards thy Neighbour; but be always ready with diligence to do any thing for them which lyeth in thy power to do; not wrong|ing thy Parents nor thy &s;elf. The duty of a Scholar is, if thou méet any man or woman in the &s;tréet, thou art to carry thy &s;elf very ci|villy, to put off thy hat, and to give them the time of the day, for in &s;o doing thou &s;hewe&s;t thy bréeding: more-over there will be &s;ome &s;ign of grace in thy old age, for as y^e Scripture &s;aith, <HI>Train up a child in the way he &s;hould go and when he is old he will not depart from it.</HI> And I pray God give every child grace to lead his life in his youth, that he may have joy and comfort both in this world, and in the world to come without end, <HI>Amen.</HI></P> <P>A &s;hort Prayer for every Schollar to learn every morning before he goes to School, o<GAP DESC="illegible" RESP="apex" EXTENT="1 letter"> beginneth any labour, then after this y^e Lord<GAP DESC="illegible" RESP="apex" EXTENT="1 letter"> Prayer.</P> <FLOATEXT LANG="eng" TYPE="prayer"> <HEAD>A Prayer for the morning.</HEAD> <P>O Mo&s;t gracious Lord God; thou that &s;itte<GAP DESC="illegible" RESP="apex" EXTENT="1 letter"> upon thy throne, and &s;ee&s;t into all the co<GAP DESC="illegible" RESP="apex" EXTENT="1 letter">+ners <PB N="20" REF="12"> of the World; thou mad'&s;t the heaven and the earth, and all things belonging thereto: thou art a God of mercy, thou art a God of favour and love; and even &s;o thou art a God of ju&s;t<GAP DESC="illegible" RESP="apex" EXTENT="1 letter">ce and wrath, yet &s;low to anger, or el&s;e what would become of poor &s;inners; O Lord, I do give thee humble and hearty thanks for this good ble&s;&s;ing which thou ha&s;t be&s;towed upon me this night pa&s;t, in giving me &s;uch quiet re&s;t and &s;leep; O Lord I confe&s;s thou mighte&s;t have made my bed of ea&s;e a bed of death: But O Lord, &s;eeing it hath plea&s;ed thee to pre&s;erve my life a little lon|ger: &s;o O Lord I do de&s;ire thee out of thy ten|der mercy to give me this day, a heart of true Repent<GAP DESC="illegible" RESP="apex" EXTENT="1 letter">nce, that I may truely repent me of my &s;ins, and lament for all my tran&s;gre&s;&s;ions. O God thou knowe&s;t the fle&s;h of man is weak and frail, yet we know thou art able to put &s;trength into the weake&s;t &s;oul: therefore I be&s;eech thee out of thy tender mercy for to &s;trengthen my faith; put grace and wi&s;dome into my heart, that I may do nothing but what is plea&s;ing to thy &s;ight. And gr<GAP DESC="illegible" RESP="apex" EXTENT="1 letter">nt O mo&s;t merciful Father, that what&s;oever. I &s;hall think, or &s;peak, or take in hand, it may tend to thy glory the good of my friends and neigh|bours&punc; and for the joy and comfort of my poor &s;oul, and that for thy Son, our Lord and Saviours &s;ake, I will farther call upon thee, in that mo&s;t <PB N="21" REF="12"> holy and perfect prayer which thou taught thy Di&s;ciples, in that holy place of Scripture, <HI>Mat.</HI> 6. 9. where he &s;aid to his Di&s;ciple, <HI><GAP DESC="illegible" RESP="apex" EXTENT="2 letters"> you pray, pray thus, &s;aying,</HI> Our Father, &c.</P> </FLOATEXT> <P><HI>La&s;tly, when thou ha&s;t &s;pent the day, call into thy mind how thou ha&s;t &s;pent it; and if thou ha&s;t done any thing which thy con&s;ci|ence telleth thée is not right, then fall on thy knées, and de&s;ire the Lord to forgive thée, and that with a true heart, and then no doubt but the Lord will hear thy prayers.</HI></P> <FLOATEXT LANG="eng" TYPE="prayer"> <HEAD>A &s;hort Prayer for the Evening.</HEAD> <P>O Lord God, Heavenly Father, I be&s;eech thee hear my prayer, and let my cry come unto thee, con&s;ider my prayer, O Lord my God, lighten thou mine eyes, le&s;t I &s;leep the &s;leep of death, and &s;o be utterly lo&s;t: I cannot but confe&s;s I have &s;inned again&s;t thee: but O Lord I know thou art merciful, and will &s;hew mercy to all &s;uch as will con&s;e&s;s their faults, and truely repent them of their &s;ins, and &s;trive to for&s;ake their wicked ways, and turn to the Lord and live: therefore turn me O Lord, and I &s;hall be turned: make me to know the way to righteou&s;ne&s;s, and give me thy &s;piritual grace, that I may flye from the way of <PB N="22" REF="13"> the wicked, and turn unto thee for &s;alvation: O Lord my God, and my redeemer; and as it hath plea&s;ed thee to give me this day liberty to follow my calling which thou ha&s;t called me unto, &s;o O Lord I be&s;eech thee to give me thy favour and countenance this night, &s;et thou a guard of An|gels about me, that no evil &s;pirit have power to entice my poor weak and &s;inful &s;oul, that by thy power and protection I may take quiet &s;leep, and re&s;t under the &s;hadow of thy wings, that when I &s;leep, I may not &s;leep unto death, but &s;leep unto life everla&s;ting, and all for thy Son our Lord and Saviour, in his words I pray farther, &s;aying:</P> <P><HI>Our Father which art in heaven, hallowed be thy Name, thy Kingdom come, thy will be done on earth as it is in heaven, give us this day, our daily bread, and forgive us our tre&s;|pa&s;&s;es, as we forgive them that tre&s;pa&s;s a|gain&s;t us, and lead us not into temptation, but deliver us from evil,</HI> Amen.</P> </FLOATEXT> -------------------------------------------------------------------- Paul Schaffner | PFSchaffner at umich.edu | http://www.umich.edu/~pfs/ 316-C Hatcher Library N, Univ. of Michigan, Ann Arbor MI 48109-1190 -------------------------------------------------------------------- From James.Cummings at oucs.ox.ac.uk Tue Apr 17 14:03:38 2012 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Tue, 17 Apr 2012 14:03:38 -0400 Subject: [tei-council] Fwd: Re: Council meals at Ann Arbor Meeting In-Reply-To: <4F8D7025.5010203@virginia.edu> References: <4F8D7025.5010203@virginia.edu> Message-ID: <4F8DB07A.2070906@oucs.ox.ac.uk> Just to forward on Sarah's latest message: ==== Hey there! Group meals are no problem. Kevin and/or Paul should submit a receipt & a list of who attended the meal. There are instructions for that in the reimbursement form (http://www.tei-c.org/Admin/TEI_travel_form.pdf). And, of course, that meal shouldn't be counted towards anyone else's expenses! For the rate, we've used the 70% formula for other locations, but the sticking point is probably that the other locations were non-U.S. But, if the reality is that daily meal costs are in fact closer to $56, then I think we should use that. The formula isn't really written in stone, and while there is a time & a place for a $5 Subway sandwich for dinner, this is perhaps not that time & place. It would work out to: For Ann Arbor, $56 Breakfast | 25% = $14 Lunch | 35% = $20 Dinner | 40% = $22 If this still doesn't reflect reality in the mean streets of Ann Arbor, we should revisit it. Of course, we're assuming that you aren't having hummingbird tongues for lunch and flamingo chops for dinner. I mean, we all know that the Council is where it's happening, so I kinda envision you guys as hanging out in a biker bar, slurping down cheap beer & burgers and comparing your tatoos. Right? Yrs, Sarah From lou.burnard at retired.ox.ac.uk Wed Apr 18 09:28:31 2012 From: lou.burnard at retired.ox.ac.uk (Lou Burnard) Date: Wed, 18 Apr 2012 14:28:31 +0100 Subject: [tei-council] Fwd: Important encoded information for the council... Message-ID: <4F8EC17F.7080505@retired.ox.ac.uk> -------- Original Message -------- Subject: Important encoded information for the council... Date: Wed, 18 Apr 2012 15:23:26 +0200 From: Laurent Romary <laurent.romary at inria.fr> To: Lou Burnard <lou.burnard at tge-adonis.fr> <person> <persName> <forenametype="first">Nathan</forename> <forenametype="middle">Zacharie</forename> <surname>Alt</surname> </persName> <birthwhen="2012-04-18"/> <sex>Male</sex> </person> Laurent Romary INRIA & HUB-IDSL laurent.romary at inria.fr <mailto:laurent.romary at inria.fr> From gabriel.bodard at kcl.ac.uk Wed Apr 18 09:32:32 2012 From: gabriel.bodard at kcl.ac.uk (Gabriel BODARD) Date: Wed, 18 Apr 2012 14:32:32 +0100 Subject: [tei-council] Fwd: Important encoded information for the council... In-Reply-To: <4F8EC17F.7080505@retired.ox.ac.uk> References: <4F8EC17F.7080505@retired.ox.ac.uk> Message-ID: <4F8EC270.1040701@kcl.ac.uk> Brilliant. Congratulations, Laurent! (And welcome to the TEI Council, Nathan...) On 18/04/2012 14:28, Lou Burnard wrote: > > > -------- Original Message -------- > Subject: Important encoded information for the council... > Date: Wed, 18 Apr 2012 15:23:26 +0200 > From: Laurent Romary<laurent.romary at inria.fr> > To: Lou Burnard<lou.burnard at tge-adonis.fr> > > > > <person> > <persName> > <forename type="first">Nathan</forename> > <forename type="middle">Zacharie</forename> > <surname>Alt</surname> > </persName> > <birth when="2012-04-18"/> > <sex>Male</sex> > </person> > > > Laurent Romary > INRIA& HUB-IDSL > laurent.romary at inria.fr<mailto:laurent.romary at inria.fr> > > > -- Dr Gabriel BODARD (Research Associate in Digital Epigraphy) Department of Digital 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 Wed Apr 18 15:13:16 2012 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Wed, 18 Apr 2012 19:13:16 +0000 Subject: [tei-council] 'ware massive change Message-ID: <112EA18B-9AC2-43F5-BBCF-EADD2B7A9845@oucs.ox.ac.uk> I have just changed everyone and his sister to switch from use of @version to @versionDate, as per Council decision. this effects more or less every element/class/macro specification. Sebastian From sebastian.rahtz at oucs.ox.ac.uk Wed Apr 18 15:15:07 2012 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Wed, 18 Apr 2012 19:15:07 +0000 Subject: [tei-council] 'ware massive change In-Reply-To: <112EA18B-9AC2-43F5-BBCF-EADD2B7A9845@oucs.ox.ac.uk> References: <112EA18B-9AC2-43F5-BBCF-EADD2B7A9845@oucs.ox.ac.uk> Message-ID: <7D85202C-7293-444F-9C1C-9F4FC32CE962@oucs.ox.ac.uk> On 18 Apr 2012, at 15:13, Sebastian Rahtz wrote: > this effects more or less every element/class/macro specification. > more obviously, it affects them as well sebastian From sebastian.rahtz at oucs.ox.ac.uk Thu Apr 19 11:16:35 2012 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Thu, 19 Apr 2012 15:16:35 +0000 Subject: [tei-council] f2f @ Ann Arbor Message-ID: <6FB346F8-7E6A-439B-9CB7-795EA2904CE9@oucs.ox.ac.uk> Just to record my thanks to Kevin, Becky and Paul for their exemplary hosting this last week. The purchase of cushions sets a standard of care it will be hard to surpass... -- Stormageddon Rahtz Head of Information and Support Group Oxford University Computing Services 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 Apr 19 14:00:02 2012 From: mholmes at uvic.ca (Martin Holmes) Date: Thu, 19 Apr 2012 11:00:02 -0700 Subject: [tei-council] f2f @ Ann Arbor In-Reply-To: <6FB346F8-7E6A-439B-9CB7-795EA2904CE9@oucs.ox.ac.uk> References: <6FB346F8-7E6A-439B-9CB7-795EA2904CE9@oucs.ox.ac.uk> Message-ID: <4F9052A2.8070802@uvic.ca> +1 from me. That was a great meeting. And special thanks for giving up your evenings to find us good food and eat with us. Cheers, Martin On 12-04-19 08:16 AM, Sebastian Rahtz wrote: > Just to record my thanks to Kevin, Becky and Paul for their exemplary hosting > this last week. The purchase of cushions sets a standard of care it will be hard > to surpass... > -- > Stormageddon Rahtz > Head of Information and Support Group > Oxford University Computing Services > 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 > > S?lo le pido a Dios > que el futuro no me sea indiferente > -- Martin Holmes University of Victoria Humanities Computing and Media Centre (mholmes at uvic.ca) From bansp at o2.pl Thu Apr 19 17:09:51 2012 From: bansp at o2.pl (=?ISO-8859-2?Q?Piotr_Ba=F1ski?=) Date: Thu, 19 Apr 2012 23:09:51 +0200 Subject: [tei-council] f2f @ Ann Arbor In-Reply-To: <4F9052A2.8070802@uvic.ca> References: <6FB346F8-7E6A-439B-9CB7-795EA2904CE9@oucs.ox.ac.uk> <4F9052A2.8070802@uvic.ca> Message-ID: <4F907F1F.50803@o2.pl> Come on, Martin: being so ultracool, we are all surely a reciprocal superpleasure to eat with... Many thanks from me as well to the UM team -- you've been terrific from before it started (I appreciate the info on transportation and the hotel arrangement, which is usually such a pain and this time it was just a pleasure, and thank you, thank you for being so generous about using your cards for us at the meals -- another headache not materializing). But I would also like to acknowledge the extra work by Becky and Martin on the minutes -- being mono-threaded attention-wise myself, and prone to any distraction, I really admire people able to do this sort of work, and so well at that. Last but not least, thanks to James for managing the agenda to squeeze out the last bit of efficiency from this meeting -- nice d?but there! I've learned quite a bit during these three days, that feels really good. Best, Piotr On 19/04/12 20:00, Martin Holmes wrote: > +1 from me. That was a great meeting. And special thanks for giving up > your evenings to find us good food and eat with us. > > Cheers, > Martin > > On 12-04-19 08:16 AM, Sebastian Rahtz wrote: >> Just to record my thanks to Kevin, Becky and Paul for their exemplary hosting >> this last week. The purchase of cushions sets a standard of care it will be hard >> to surpass... >> -- >> Stormageddon Rahtz >> Head of Information and Support Group >> Oxford University Computing Services >> 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 Apr 19 17:27:22 2012 From: mholmes at uvic.ca (Martin Holmes) Date: Thu, 19 Apr 2012 14:27:22 -0700 Subject: [tei-council] style-guide.txt deleted Message-ID: <4F90833A.4030504@uvic.ca> Hi all, I've removed style-guide.txt from SVN in accordance with our decision on Monday. Just for the record, here are (were) its contents: STYLESHEET FOR TEI GUIDELINES USAGES ==================================== This file contains a working list of usages for spelling of various terms used in the TEI Guidelines. Version History: 2008-01-31 Created, David Sewell Reference Abbreviations: CMS: Chicago Manual of Style, 15th ed. MW: Merriam-Webster's Collegiate Dictionary, 11th ed. OED: Oxford English Dictionary, 2d ed. online (dictionary.oed.com) ODE: Oxford Dictionary of English (aka NODE), 2d ed. ORDS: O'Reilly Default Stylesheet, http://www.oreilly.com/oreilly/author/stylesheet.html UCG: Unicode Consortium Glossary, http://unicode.org/glossary/ W3CXML: W3C XML Recommendation, http://www.w3.org/TR/xml/ Word or Term Authority/explanation ============ ===================== code point (n.) UCG [discussed on TEI Council list] code-point (adj.) cross-reference MW, OED data set OED datatype [OED, ORDS have 'data type', but Guidelines consistently use single word dozens of places] end-tag ORDS high-level (adj.) MW, OED line break lowercase/uppercase MW, ORDS proofread MW, OED start-tag ORDS stylesheet ORDS typeface MW the Web ORDS web page ORDS web site ORDS, OED well-formed W3CXML (even in a predicate usage: "the XML is well-formed") whitespace ORDS /* vim: set ai ts=8 sw=8 expandtab tw=78: */ Cheers, Martin -- Martin Holmes University of Victoria Humanities Computing and Media Centre (mholmes at uvic.ca) From mholmes at uvic.ca Thu Apr 19 18:18:10 2012 From: mholmes at uvic.ca (Martin Holmes) Date: Thu, 19 Apr 2012 15:18:10 -0700 Subject: [tei-council] Attributes without examples Message-ID: <4F908F22.4070908@uvic.ca> Following on from our discussion of examples for attributes, a quick-and-dirty XSLT seems to show that there are only 19 attributes with their own examples, and 450 without. This is not to say that those without are unexemplified, because the example code for their parent elements in the elementSpec may show examples of them; I'll refine the XSLT and make that apparent. Here's the list: ATTRIBUTE DEFINITIONS LACKING EXAMPLES AS OF 2012-04-19T15:12:34.968-07:00 1. status (att.identified) 2. type (interaction) 3. value (sex) 4. scale (graphic) 5. scale (binaryObject) 6. weights (alt) 7. hand (att.damaged) 8. agent (gap) 9. predeclare (att.identified) 10. degree (att.damaged) 11. module (att.identified) 12. ident (att.identified) 13. height (graphic) 14. height (binaryObject) 15. width (graphic) 16. width (binaryObject) 17. encoding (binaryObject) 18. version (teiCorpus) 19. hand (unclear) 20. agent (unclear) 21. feature (shift) 22. type (preparedness) 23. type (abbr) 24. commodity (att.measurement) 25. agent (att.damaged) 26. type (derivation) 27. type (domain) 28. type (factuality) 29. type (idno) 30. type (relation) 31. type (sound) 32. type (tech) 33. type (castItem) 34. type (att.typed) 35. type (move) 36. script (att.handFeatures) 37. class (msItemStruct) 38. class (msItem) 39. class (msContents) 40. type (form) 41. cause (att.textCritical) 42. type (gram) 43. type (lbl) 44. type (att.textCritical) 45. type (title) 46. type (titlePage) 47. type (usg) 48. type (app) 49. columns (layout) 50. valueDatcat (att.datcat) 51. datcat (att.datcat) 52. contemporary (seal) 53. contemporary (binding) 54. from (locus) 55. type (list) 56. result (joinGrp) 57. medium (att.handFeatures) 58. type (graph) 59. type (witDetail) 60. origin (timeline) 61. function (att.segLike) 62. form (objectDesc) 63. mergedIn (att.lexicographic) 64. type (fsDecl) 65. scribe (att.handFeatures) 66. degree (node) 67. extent (orth) 68. from (arc) 69. to (arc) 70. inDegree (node) 71. arity (tree) 72. baseTypes (fsDecl) 73. level (sense) 74. order (tree) 75. outDegree (iNode) 76. outDegree (node) 77. outDegree (root) 78. reason (gap) 79. type (orth) 80. when (docDate) 81. split (att.lexicographic) 82. code (socecStatus) 83. code (occupation) 84. decls (att.declaring) 85. cRef (term) 86. from (app) 87. scheme (catRef) 88. scheme (occupation) 89. scheme (classCode) 90. scheme (socecStatus) 91. scheme (keywords) 92. to (app) 93. baseForm (m) 94. new (handShift) 95. passive (relation) 96. since (when) 97. type (fsdLink) 98. type (biblScope) 99. type (listForest) 100. type (forest) 101. hand (gap) 102. given (certainty) 103. locus (certainty) 104. type (rs) 105. source (normalization) 106. level (title) 107. degree (certainty) 108. status (correction) 109. degree (precision) 110. spanTo (att.spanning) 111. to (att.datable.w3c) 112. to-iso (att.datable.iso) 113. force (pc) 114. reason (surplus) 115. type (stage) 116. type (oRef) 117. type (oVar) 118. method (correction) 119. method (normalization) 120. name (fDecl) 121. evidence (att.editLike) 122. rows (table) 123. org (vMerge) 124. who (att.ascribed) 125. locus (respons) 126. from-custom (att.datable.custom) 127. from (att.datable.w3c) 128. from-iso (att.datable.iso) 129. type (xr) 130. type (iType) 131. type (num) 132. type (att.entryLike) 133. type (att.interpLike) 134. unit (refState) 135. notation (pron) 136. break (att.breaking) 137. iterated (kinesic) 138. iterated (vocal) 139. optional (fDecl) 140. default (att.declarable) 141. location (variantEncoding) 142. anchored (note) 143. full (att.personal) 144. type (metDecl) 145. extent (pron) 146. discrete (sound) 147. scope (join) 148. gradual (writing) 149. sample (att.divLike) 150. type (classSpec) 151. pre (pc) 152. type (dimensions) 153. method (variantEncoding) 154. type (macroSpec) 155. reason (supplied) 156. to (locus) 157. rows (att.tableDecoration) 158. writtenLines (layout) 159. ruledLines (layout) 160. location (att.lexicographic) 161. hands (handDesc) 162. material (supportDesc) 163. notation (formula) 164. unit (att.dimensions) 165. ns (attDef) 166. ns (elementSpec) 167. domains (att.pointing.group) 168. part (att.segLike) 169. source (writing) 170. ref (g) 171. scribeRef (att.handFeatures) 172. scriptRef (att.handFeatures) 173. copyOf (att.global.linking) 174. sameAs (att.global.linking) 175. exclude (att.global.linking) 176. targetEnd (note) 177. next (att.global.linking) 178. target (relatedItem) 179. unit (milestone) 180. label (rhyme) 181. lemma (w) 182. children (iNode) 183. children (root) 184. name (f) 185. unit (pc) 186. value (leaf) 187. type (node) 188. key (att.canonical) 189. follow (iNode) 190. follow (leaf) 191. parent (leaf) 192. parent (iNode) 193. value (node) 194. value (triangle) 195. value (eLeaf) 196. value (eTree) 197. value (iNode) 198. value (root) 199. quantity (att.measurement) 200. role (att.tableDecoration) 201. scheme (att) 202. select (att.global.linking) 203. xml:space (att.global) 204. hand (att.textCritical) 205. subtype (att.typed) 206. prefix (schemaSpec) 207. prefix (elementSpec) 208. type (purpose) 209. role (org) 210. role (person) 211. matchPattern (cRefPattern) 212. replacementPattern (cRefPattern) 213. age (person) 214. start (schemaSpec) 215. form (quotation) 216. time (distinct) 217. social (distinct) 218. space (distinct) 219. type (constitution) 220. scope (att.handFeatures) 221. age (personGrp) 222. usage (language) 223. ident (valItem) 224. from (span) 225. value (metSym) 226. versionDate (att.translatable) 227. target (att.pointing) 228. where (move) 229. notBefore (att.datable.w3c) 230. notBefore-custom (att.datable.custom) 231. notBefore-iso (att.datable.iso) 232. mode (classes) 233. mode (att.combinable) 234. mode (memberOf) 235. to (span) 236. to (biblScope) 237. type (valList) 238. degree (purpose) 239. length (refState) 240. render (tagUsage) 241. targets (alt) 242. targets (join) 243. targets (link) 244. type (teiHeader) 245. notAfter (att.datable.w3c) 246. notAfter-custom (att.datable.custom) 247. notAfter-iso (att.datable.iso) 248. version (TEI) 249. mode (channel) 250. result (join) 251. new (shift) 252. active (interaction) 253. occurs (tagUsage) 254. passive (interaction) 255. interval (when) 256. interval (timeline) 257. usage (attDef) 258. role (personGrp) 259. type (titlePart) 260. sex (personGrp) 261. sex (person) 262. size (personGrp) 263. from (biblScope) 264. type (distinct) 265. type (measure) 266. type (fs) 267. unit (timeline) 268. unit (when) 269. version (unicodeName) 270. type (divGen) 271. part (ab) 272. part (att.divLike) 273. part (l) 274. terminal (metSym) 275. trunc (numeric) 276. order (graph) 277. size (graph) 278. mode (alt) 279. mode (altGrp) 280. value (binary) 281. status (availability) 282. datum (geoDecl) 283. value (numeric) 284. name (relation) 285. name (vLabel) 286. indexName (index) 287. stdDeviation (precision) 288. absolute (when) 289. max (numeric) 290. scheme (constraintSpec) 291. scheme (tag) 292. scheme (gi) 293. value (symbol) 294. value (num) 295. scheme (locusGrp) 296. scheme (locus) 297. name (namespace) 298. type (recording) 299. unit (att.measurement) 300. value (att.lexicographic) 301. scope (att.dimensions) 302. evaluate (att.pointing) 303. active (relation) 304. to-custom (att.datable.custom) 305. mutual (relation) 306. dur-iso (att.duration.iso) 307. instant (att.editLike) 308. function (metamark) 309. attachment (surface) 310. cause (att.transcriptional) 311. target (metamark) 312. rotate (zone) 313. target (redo) 314. target (undo) 315. except (moduleRef) 316. include (moduleRef) 317. datingMethod (att.datable.custom) 318. datingPoint (att.datable.custom) 319. key (moduleRef) 320. url (moduleRef) 321. mimeType (att.internetMedia) 322. version (application) 323. ident (application) 324. confidence (att.ranging) 325. level (langKnown) 326. adj (node) 327. adjFrom (node) 328. adjTo (node) 329. ana (att.global.analytic) 330. group (att.damaged) 331. cRef (gloss) 332. cRef (ptr) 333. cRef (ref) 334. cert (att.responsibility) 335. cert (certainty) 336. precision (precision) 337. precision (att.dimensions) 338. type (fw) 339. cols (table) 340. cols (att.tableDecoration) 341. source (att.editLike) 342. autoPrefix (content) 343. corresp (att.global.linking) 344. delim (refState) 345. dim (space) 346. docLang (schemaSpec) 347. dur (att.duration.w3c) 348. ed (att.sourced) 349. gi (tagUsage) 350. eol (hyphenation) 351. enjamb (att.enjamb) 352. facs (att.global.facs) 353. fVal (f) 354. feats (fs) 355. lang (code) 356. atMost (att.ranging) 357. atLeast (att.ranging) 358. lrx (att.coordinated) 359. ulx (att.coordinated) 360. lry (att.coordinated) 361. uly (att.coordinated) 362. xml:id (att.global) 363. ident (language) 364. scheme (rendition) 365. status (att.transcriptional) 366. where (event) 367. start (att.timed) 368. end (att.timed) 369. type (tag) 370. defective (att.msExcerpt) 371. generate (classSpec) 372. inst (att.interpLike) 373. xml:lang (att.global) 374. loc (app) 375. mainLang (textLang) 376. maxOccurs (datatype) 377. type (q) 378. direct (said) 379. aloud (said) 380. met (att.metrical) 381. real (att.metrical) 382. minOccurs (datatype) 383. name (equiv) 384. ns (schemaSpec) 385. n (att.global) 386. opt (att.lexicographic) 387. ord (iNode) 388. ord (root) 389. ord (tree) 390. sort (att.personal) 391. org (attList) 392. org (vColl) 393. org (att.divLike) 394. orig (att.lexicographic) 395. otherLangs (textLang) 396. perf (move) 397. perf (tech) 398. target (specGrpRef) 399. parts (nym) 400. change (att.global.change) 401. target (change) 402. prev (att.global.linking) 403. lemmaRef (w) 404. marks (quotation) 405. ref (att.canonical) 406. nymRef (att.naming) 407. filter (equiv) 408. pattern (metDecl) 409. resp (respons) 410. resp (att.responsibility) 411. resp (space) 412. rhyme (att.metrical) 413. seq (att.transcriptional) 414. hand (att.transcriptional) 415. prefix (moduleRef) 416. key (memberOf) 417. quantity (att.dimensions) 418. value (age) 419. target (fsdLink) 420. period (att.datable) 421. tag (langKnown) 422. tags (langKnowledge) 423. max (memberOf) 424. min (memberOf) 425. synch (att.global.linking) 426. targFunc (att.pointing.group) 427. targetLang (schemaSpec) 428. key (classRef) 429. key (elementRef) 430. key (macroRef) 431. name (attRef) 432. trans (u) 433. uri (equiv) 434. url (graphic) 435. varSeq (att.textCritical) 436. scope (rendition) 437. max (att.ranging) 438. min (att.ranging) 439. withId (tagUsage) 440. wit (att.witnessed) 441. wit (att.rdgPart) 442. wit (witDetail) 443. status (att.docStatus) 444. points (zone) 445. start (att.coordinated) 446. valid (egXML) 447. ordered (listChange) 448. role (att.naming) 449. source (att.readFrom) 450. flipping (surface) ATTRIBUTE DEFINITIONS WHICH HAVE EXAMPLES AS OF 2012-04-19T15:12:34.968-07:00 1. place (att.placement) 2. expand (att.lexicographic) 3. extent (att.dimensions) 4. calendar (att.datable) 5. reason (unclear) 6. target (att.scoping) 7. xml:base (att.global) 8. assertedValue (certainty) 9. refLang (att.pointing) 10. match (att.scoping) 11. sortKey (att.sortable) 12. atts (specDesc) 13. key (specDesc) 14. norm (att.lexicographic) 15. rendition (att.global) 16. rend (att.global) 17. when-iso (att.datable.iso) 18. when-custom (att.datable.custom) 19. when (att.datable.w3c) -- Martin Holmes University of Victoria Humanities Computing and Media Centre (mholmes at uvic.ca) From mholmes at uvic.ca Thu Apr 19 20:27:30 2012 From: mholmes at uvic.ca (Martin Holmes) Date: Thu, 19 Apr 2012 17:27:30 -0700 Subject: [tei-council] Attributes without examples In-Reply-To: <4F908F22.4070908@uvic.ca> References: <4F908F22.4070908@uvic.ca> Message-ID: <4F90AD72.10605@uvic.ca> Below is another slightly shorter list. These are attributes which do not appear on any examples in the <elementSpec> or <classSpec> in which they're defined. Not that this doesn't mean there are no examples at all for them; there may be an example somewhere in the Guidelines text, or the attribute may be defined in a <classSpec> for an attribute class, and then show up in an example in an <elementSpec> for an element which belongs to that class. An example of the latter is @agent (att.damaged), which has no example in the att.damaged <classSpec>, but happens to show up in an example for the <damage> element. Nevertheless, I think it would be a good idea to try to provide examples for all these attributes, in the files which define them. ATTRIBUTES WHICH DO NOT SHOW UP ON ANY EXAMPLE IN THEIR elementSpec OR classSpec AS OF 2012-04-19T17:19:17.315-07:00 1. absolute (when) 2. adj (node) 3. adjFrom (node) 4. adjTo (node) 5. age (personGrp) 6. agent (att.damaged) 7. agent (gap) 8. agent (unclear) 9. ana (att.global.analytic) 10. atLeast (att.ranging) 11. atMost (att.ranging) 12. attachment (surface) 13. autoPrefix (content) 14. baseTypes (fsDecl) 15. break (att.breaking) 16. cRef (gloss) 17. cRef (ptr) 18. cRef (ref) 19. cRef (term) 20. cause (att.textCritical) 21. cause (att.transcriptional) 22. cert (att.responsibility) 23. change (att.global.change) 24. class (msContents) 25. cols (att.tableDecoration) 26. confidence (att.ranging) 27. contemporary (seal) 28. copyOf (att.global.linking) 29. corresp (att.global.linking) 30. datingMethod (att.datable.custom) 31. datingPoint (att.datable.custom) 32. decls (att.declaring) 33. default (att.declarable) 34. defective (att.msExcerpt) 35. degree (att.damaged) 36. degree (node) 37. dim (space) 38. direct (said) 39. docLang (schemaSpec) 40. domains (att.pointing.group) 41. dur (att.duration.w3c) 42. dur-iso (att.duration.iso) 43. encoding (binaryObject) 44. end (att.timed) 45. enjamb (att.enjamb) 46. evaluate (att.pointing) 47. evidence (att.editLike) 48. except (moduleRef) 49. exclude (att.global.linking) 50. expand (att.lexicographic) 51. extent (orth) 52. fVal (f) 53. facs (att.global.facs) 54. feats (fs) 55. filter (equiv) 56. flipping (surface) 57. follow (leaf) 58. force (pc) 59. from (app) 60. from (att.datable.w3c) 61. from-custom (att.datable.custom) 62. from-iso (att.datable.iso) 63. full (att.personal) 64. function (att.segLike) 65. generate (classSpec) 66. gradual (writing) 67. group (att.damaged) 68. hand (att.damaged) 69. hand (att.textCritical) 70. hand (att.transcriptional) 71. hand (gap) 72. hand (unclear) 73. height (binaryObject) 74. height (graphic) 75. ident (att.identified) 76. inst (att.interpLike) 77. instant (att.editLike) 78. key (att.canonical) 79. key (classRef) 80. key (macroRef) 81. level (sense) 82. level (title) 83. loc (app) 84. location (att.lexicographic) 85. lrx (att.coordinated) 86. lry (att.coordinated) 87. match (att.scoping) 88. material (supportDesc) 89. max (att.ranging) 90. max (memberOf) 91. medium (att.handFeatures) 92. mergedIn (att.lexicographic) 93. met (att.metrical) 94. method (correction) 95. mimeType (att.internetMedia) 96. min (att.ranging) 97. min (memberOf) 98. mode (att.combinable) 99. mode (classes) 100. mode (memberOf) 101. module (att.identified) 102. new (handShift) 103. next (att.global.linking) 104. notAfter-custom (att.datable.custom) 105. notAfter-iso (att.datable.iso) 106. notBefore-custom (att.datable.custom) 107. notBefore-iso (att.datable.iso) 108. notation (pron) 109. ns (attDef) 110. ns (elementSpec) 111. ns (schemaSpec) 112. nymRef (att.naming) 113. opt (att.lexicographic) 114. optional (fDecl) 115. ord (iNode) 116. ord (root) 117. org (att.divLike) 118. org (attList) 119. orig (att.lexicographic) 120. part (ab) 121. part (att.divLike) 122. part (att.segLike) 123. parts (nym) 124. perf (tech) 125. period (att.datable) 126. pre (pc) 127. precision (att.dimensions) 128. predeclare (att.identified) 129. prefix (elementSpec) 130. prefix (moduleRef) 131. prev (att.global.linking) 132. quantity (att.dimensions) 133. real (att.metrical) 134. ref (att.canonical) 135. refLang (att.pointing) 136. resp (att.responsibility) 137. resp (space) 138. rhyme (att.metrical) 139. role (att.naming) 140. role (att.tableDecoration) 141. role (org) 142. rotate (zone) 143. rows (att.tableDecoration) 144. sameAs (att.global.linking) 145. sample (att.divLike) 146. scale (binaryObject) 147. scale (graphic) 148. scheme (catRef) 149. scheme (locus) 150. scheme (locusGrp) 151. scheme (tag) 152. scope (att.dimensions) 153. scope (att.handFeatures) 154. scribe (att.handFeatures) 155. scribeRef (att.handFeatures) 156. script (att.handFeatures) 157. scriptRef (att.handFeatures) 158. select (att.global.linking) 159. seq (att.transcriptional) 160. social (distinct) 161. sort (att.personal) 162. source (att.editLike) 163. source (att.readFrom) 164. source (writing) 165. space (distinct) 166. spanTo (att.spanning) 167. split (att.lexicographic) 168. start (att.coordinated) 169. start (att.timed) 170. status (att.identified) 171. status (att.transcriptional) 172. status (correction) 173. stdDeviation (precision) 174. subtype (att.typed) 175. synch (att.global.linking) 176. targFunc (att.pointing.group) 177. target (change) 178. target (relatedItem) 179. targetEnd (note) 180. targetLang (schemaSpec) 181. targets (alt) 182. targets (join) 183. targets (link) 184. time (distinct) 185. to (app) 186. to (att.datable.w3c) 187. to-custom (att.datable.custom) 188. to-iso (att.datable.iso) 189. type (abbr) 190. type (att.entryLike) 191. type (att.interpLike) 192. type (att.textCritical) 193. type (att.typed) 194. type (form) 195. type (q) 196. type (sound) 197. ulx (att.coordinated) 198. uly (att.coordinated) 199. unit (att.dimensions) 200. unit (pc) 201. unit (when) 202. url (moduleRef) 203. value (att.lexicographic) 204. value (eTree) 205. value (iNode) 206. value (leaf) 207. value (node) 208. value (root) 209. value (triangle) 210. varSeq (att.textCritical) 211. version (unicodeName) 212. versionDate (att.translatable) 213. when (docDate) 214. where (event) 215. who (att.ascribed) 216. width (binaryObject) 217. width (graphic) 218. wit (att.rdgPart) 219. wit (att.witnessed) 220. xml:base (att.global) 221. xml:id (att.global) 222. xml:lang (att.global) 223. xml:space (att.global) Cheers, Martin On 12-04-19 03:18 PM, Martin Holmes wrote: > Following on from our discussion of examples for attributes, a > quick-and-dirty XSLT seems to show that there are only 19 attributes > with their own examples, and 450 without. This is not to say that those > without are unexemplified, because the example code for their parent > elements in the elementSpec may show examples of them; I'll refine the > XSLT and make that apparent. > > Here's the list: > > ATTRIBUTE DEFINITIONS LACKING EXAMPLES AS OF 2012-04-19T15:12:34.968-07:00 > > 1. status (att.identified) > 2. type (interaction) > 3. value (sex) > 4. scale (graphic) > 5. scale (binaryObject) > 6. weights (alt) > 7. hand (att.damaged) > 8. agent (gap) > 9. predeclare (att.identified) > 10. degree (att.damaged) > 11. module (att.identified) > 12. ident (att.identified) > 13. height (graphic) > 14. height (binaryObject) > 15. width (graphic) > 16. width (binaryObject) > 17. encoding (binaryObject) > 18. version (teiCorpus) > 19. hand (unclear) > 20. agent (unclear) > 21. feature (shift) > 22. type (preparedness) > 23. type (abbr) > 24. commodity (att.measurement) > 25. agent (att.damaged) > 26. type (derivation) > 27. type (domain) > 28. type (factuality) > 29. type (idno) > 30. type (relation) > 31. type (sound) > 32. type (tech) > 33. type (castItem) > 34. type (att.typed) > 35. type (move) > 36. script (att.handFeatures) > 37. class (msItemStruct) > 38. class (msItem) > 39. class (msContents) > 40. type (form) > 41. cause (att.textCritical) > 42. type (gram) > 43. type (lbl) > 44. type (att.textCritical) > 45. type (title) > 46. type (titlePage) > 47. type (usg) > 48. type (app) > 49. columns (layout) > 50. valueDatcat (att.datcat) > 51. datcat (att.datcat) > 52. contemporary (seal) > 53. contemporary (binding) > 54. from (locus) > 55. type (list) > 56. result (joinGrp) > 57. medium (att.handFeatures) > 58. type (graph) > 59. type (witDetail) > 60. origin (timeline) > 61. function (att.segLike) > 62. form (objectDesc) > 63. mergedIn (att.lexicographic) > 64. type (fsDecl) > 65. scribe (att.handFeatures) > 66. degree (node) > 67. extent (orth) > 68. from (arc) > 69. to (arc) > 70. inDegree (node) > 71. arity (tree) > 72. baseTypes (fsDecl) > 73. level (sense) > 74. order (tree) > 75. outDegree (iNode) > 76. outDegree (node) > 77. outDegree (root) > 78. reason (gap) > 79. type (orth) > 80. when (docDate) > 81. split (att.lexicographic) > 82. code (socecStatus) > 83. code (occupation) > 84. decls (att.declaring) > 85. cRef (term) > 86. from (app) > 87. scheme (catRef) > 88. scheme (occupation) > 89. scheme (classCode) > 90. scheme (socecStatus) > 91. scheme (keywords) > 92. to (app) > 93. baseForm (m) > 94. new (handShift) > 95. passive (relation) > 96. since (when) > 97. type (fsdLink) > 98. type (biblScope) > 99. type (listForest) > 100. type (forest) > 101. hand (gap) > 102. given (certainty) > 103. locus (certainty) > 104. type (rs) > 105. source (normalization) > 106. level (title) > 107. degree (certainty) > 108. status (correction) > 109. degree (precision) > 110. spanTo (att.spanning) > 111. to (att.datable.w3c) > 112. to-iso (att.datable.iso) > 113. force (pc) > 114. reason (surplus) > 115. type (stage) > 116. type (oRef) > 117. type (oVar) > 118. method (correction) > 119. method (normalization) > 120. name (fDecl) > 121. evidence (att.editLike) > 122. rows (table) > 123. org (vMerge) > 124. who (att.ascribed) > 125. locus (respons) > 126. from-custom (att.datable.custom) > 127. from (att.datable.w3c) > 128. from-iso (att.datable.iso) > 129. type (xr) > 130. type (iType) > 131. type (num) > 132. type (att.entryLike) > 133. type (att.interpLike) > 134. unit (refState) > 135. notation (pron) > 136. break (att.breaking) > 137. iterated (kinesic) > 138. iterated (vocal) > 139. optional (fDecl) > 140. default (att.declarable) > 141. location (variantEncoding) > 142. anchored (note) > 143. full (att.personal) > 144. type (metDecl) > 145. extent (pron) > 146. discrete (sound) > 147. scope (join) > 148. gradual (writing) > 149. sample (att.divLike) > 150. type (classSpec) > 151. pre (pc) > 152. type (dimensions) > 153. method (variantEncoding) > 154. type (macroSpec) > 155. reason (supplied) > 156. to (locus) > 157. rows (att.tableDecoration) > 158. writtenLines (layout) > 159. ruledLines (layout) > 160. location (att.lexicographic) > 161. hands (handDesc) > 162. material (supportDesc) > 163. notation (formula) > 164. unit (att.dimensions) > 165. ns (attDef) > 166. ns (elementSpec) > 167. domains (att.pointing.group) > 168. part (att.segLike) > 169. source (writing) > 170. ref (g) > 171. scribeRef (att.handFeatures) > 172. scriptRef (att.handFeatures) > 173. copyOf (att.global.linking) > 174. sameAs (att.global.linking) > 175. exclude (att.global.linking) > 176. targetEnd (note) > 177. next (att.global.linking) > 178. target (relatedItem) > 179. unit (milestone) > 180. label (rhyme) > 181. lemma (w) > 182. children (iNode) > 183. children (root) > 184. name (f) > 185. unit (pc) > 186. value (leaf) > 187. type (node) > 188. key (att.canonical) > 189. follow (iNode) > 190. follow (leaf) > 191. parent (leaf) > 192. parent (iNode) > 193. value (node) > 194. value (triangle) > 195. value (eLeaf) > 196. value (eTree) > 197. value (iNode) > 198. value (root) > 199. quantity (att.measurement) > 200. role (att.tableDecoration) > 201. scheme (att) > 202. select (att.global.linking) > 203. xml:space (att.global) > 204. hand (att.textCritical) > 205. subtype (att.typed) > 206. prefix (schemaSpec) > 207. prefix (elementSpec) > 208. type (purpose) > 209. role (org) > 210. role (person) > 211. matchPattern (cRefPattern) > 212. replacementPattern (cRefPattern) > 213. age (person) > 214. start (schemaSpec) > 215. form (quotation) > 216. time (distinct) > 217. social (distinct) > 218. space (distinct) > 219. type (constitution) > 220. scope (att.handFeatures) > 221. age (personGrp) > 222. usage (language) > 223. ident (valItem) > 224. from (span) > 225. value (metSym) > 226. versionDate (att.translatable) > 227. target (att.pointing) > 228. where (move) > 229. notBefore (att.datable.w3c) > 230. notBefore-custom (att.datable.custom) > 231. notBefore-iso (att.datable.iso) > 232. mode (classes) > 233. mode (att.combinable) > 234. mode (memberOf) > 235. to (span) > 236. to (biblScope) > 237. type (valList) > 238. degree (purpose) > 239. length (refState) > 240. render (tagUsage) > 241. targets (alt) > 242. targets (join) > 243. targets (link) > 244. type (teiHeader) > 245. notAfter (att.datable.w3c) > 246. notAfter-custom (att.datable.custom) > 247. notAfter-iso (att.datable.iso) > 248. version (TEI) > 249. mode (channel) > 250. result (join) > 251. new (shift) > 252. active (interaction) > 253. occurs (tagUsage) > 254. passive (interaction) > 255. interval (when) > 256. interval (timeline) > 257. usage (attDef) > 258. role (personGrp) > 259. type (titlePart) > 260. sex (personGrp) > 261. sex (person) > 262. size (personGrp) > 263. from (biblScope) > 264. type (distinct) > 265. type (measure) > 266. type (fs) > 267. unit (timeline) > 268. unit (when) > 269. version (unicodeName) > 270. type (divGen) > 271. part (ab) > 272. part (att.divLike) > 273. part (l) > 274. terminal (metSym) > 275. trunc (numeric) > 276. order (graph) > 277. size (graph) > 278. mode (alt) > 279. mode (altGrp) > 280. value (binary) > 281. status (availability) > 282. datum (geoDecl) > 283. value (numeric) > 284. name (relation) > 285. name (vLabel) > 286. indexName (index) > 287. stdDeviation (precision) > 288. absolute (when) > 289. max (numeric) > 290. scheme (constraintSpec) > 291. scheme (tag) > 292. scheme (gi) > 293. value (symbol) > 294. value (num) > 295. scheme (locusGrp) > 296. scheme (locus) > 297. name (namespace) > 298. type (recording) > 299. unit (att.measurement) > 300. value (att.lexicographic) > 301. scope (att.dimensions) > 302. evaluate (att.pointing) > 303. active (relation) > 304. to-custom (att.datable.custom) > 305. mutual (relation) > 306. dur-iso (att.duration.iso) > 307. instant (att.editLike) > 308. function (metamark) > 309. attachment (surface) > 310. cause (att.transcriptional) > 311. target (metamark) > 312. rotate (zone) > 313. target (redo) > 314. target (undo) > 315. except (moduleRef) > 316. include (moduleRef) > 317. datingMethod (att.datable.custom) > 318. datingPoint (att.datable.custom) > 319. key (moduleRef) > 320. url (moduleRef) > 321. mimeType (att.internetMedia) > 322. version (application) > 323. ident (application) > 324. confidence (att.ranging) > 325. level (langKnown) > 326. adj (node) > 327. adjFrom (node) > 328. adjTo (node) > 329. ana (att.global.analytic) > 330. group (att.damaged) > 331. cRef (gloss) > 332. cRef (ptr) > 333. cRef (ref) > 334. cert (att.responsibility) > 335. cert (certainty) > 336. precision (precision) > 337. precision (att.dimensions) > 338. type (fw) > 339. cols (table) > 340. cols (att.tableDecoration) > 341. source (att.editLike) > 342. autoPrefix (content) > 343. corresp (att.global.linking) > 344. delim (refState) > 345. dim (space) > 346. docLang (schemaSpec) > 347. dur (att.duration.w3c) > 348. ed (att.sourced) > 349. gi (tagUsage) > 350. eol (hyphenation) > 351. enjamb (att.enjamb) > 352. facs (att.global.facs) > 353. fVal (f) > 354. feats (fs) > 355. lang (code) > 356. atMost (att.ranging) > 357. atLeast (att.ranging) > 358. lrx (att.coordinated) > 359. ulx (att.coordinated) > 360. lry (att.coordinated) > 361. uly (att.coordinated) > 362. xml:id (att.global) > 363. ident (language) > 364. scheme (rendition) > 365. status (att.transcriptional) > 366. where (event) > 367. start (att.timed) > 368. end (att.timed) > 369. type (tag) > 370. defective (att.msExcerpt) > 371. generate (classSpec) > 372. inst (att.interpLike) > 373. xml:lang (att.global) > 374. loc (app) > 375. mainLang (textLang) > 376. maxOccurs (datatype) > 377. type (q) > 378. direct (said) > 379. aloud (said) > 380. met (att.metrical) > 381. real (att.metrical) > 382. minOccurs (datatype) > 383. name (equiv) > 384. ns (schemaSpec) > 385. n (att.global) > 386. opt (att.lexicographic) > 387. ord (iNode) > 388. ord (root) > 389. ord (tree) > 390. sort (att.personal) > 391. org (attList) > 392. org (vColl) > 393. org (att.divLike) > 394. orig (att.lexicographic) > 395. otherLangs (textLang) > 396. perf (move) > 397. perf (tech) > 398. target (specGrpRef) > 399. parts (nym) > 400. change (att.global.change) > 401. target (change) > 402. prev (att.global.linking) > 403. lemmaRef (w) > 404. marks (quotation) > 405. ref (att.canonical) > 406. nymRef (att.naming) > 407. filter (equiv) > 408. pattern (metDecl) > 409. resp (respons) > 410. resp (att.responsibility) > 411. resp (space) > 412. rhyme (att.metrical) > 413. seq (att.transcriptional) > 414. hand (att.transcriptional) > 415. prefix (moduleRef) > 416. key (memberOf) > 417. quantity (att.dimensions) > 418. value (age) > 419. target (fsdLink) > 420. period (att.datable) > 421. tag (langKnown) > 422. tags (langKnowledge) > 423. max (memberOf) > 424. min (memberOf) > 425. synch (att.global.linking) > 426. targFunc (att.pointing.group) > 427. targetLang (schemaSpec) > 428. key (classRef) > 429. key (elementRef) > 430. key (macroRef) > 431. name (attRef) > 432. trans (u) > 433. uri (equiv) > 434. url (graphic) > 435. varSeq (att.textCritical) > 436. scope (rendition) > 437. max (att.ranging) > 438. min (att.ranging) > 439. withId (tagUsage) > 440. wit (att.witnessed) > 441. wit (att.rdgPart) > 442. wit (witDetail) > 443. status (att.docStatus) > 444. points (zone) > 445. start (att.coordinated) > 446. valid (egXML) > 447. ordered (listChange) > 448. role (att.naming) > 449. source (att.readFrom) > 450. flipping (surface) > > > ATTRIBUTE DEFINITIONS WHICH HAVE EXAMPLES AS OF > 2012-04-19T15:12:34.968-07:00 > > 1. place (att.placement) > 2. expand (att.lexicographic) > 3. extent (att.dimensions) > 4. calendar (att.datable) > 5. reason (unclear) > 6. target (att.scoping) > 7. xml:base (att.global) > 8. assertedValue (certainty) > 9. refLang (att.pointing) > 10. match (att.scoping) > 11. sortKey (att.sortable) > 12. atts (specDesc) > 13. key (specDesc) > 14. norm (att.lexicographic) > 15. rendition (att.global) > 16. rend (att.global) > 17. when-iso (att.datable.iso) > 18. when-custom (att.datable.custom) > 19. when (att.datable.w3c) > > -- > Martin Holmes > University of Victoria Humanities Computing and Media Centre > (mholmes at uvic.ca) > -- > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > > PLEASE NOTE: postings to this list are publicly archived > . > -- Martin Holmes University of Victoria Humanities Computing and Media Centre (mholmes at uvic.ca) From mholmes at uvic.ca Thu Apr 19 21:01:58 2012 From: mholmes at uvic.ca (Martin Holmes) Date: Thu, 19 Apr 2012 18:01:58 -0700 Subject: [tei-council] New council members and SourceForge Message-ID: <4F90B586.3010308@uvic.ca> One thing we should have done at the ftf is to get the new Council members set up with SourceForge accounts and add them to the project, so that we can assign tickets to them. Neither Becky nor Paul are members of the TEI project on SF yet. Do either of you have a SourceForge account? If not, could you set one up: <https://sourceforge.net/user/registration> Once you have an id, let me know and I'll add you to the list, and then you can start getting tickets dumped on you by the likes of us. :-) Cheers, Martin -- Martin Holmes University of Victoria Humanities Computing and Media Centre (mholmes at uvic.ca) From PFSchaffner at umich.edu Thu Apr 19 21:07:41 2012 From: PFSchaffner at umich.edu (Paul F. Schaffner) Date: Thu, 19 Apr 2012 21:07:41 -0400 (EDT) Subject: [tei-council] New council members and SourceForge In-Reply-To: <4F90B586.3010308@uvic.ca> References: <4F90B586.3010308@uvic.ca> Message-ID: <Pine.LNX.4.64.1204192106340.9625@zaxxon.gpcc.itd.umich.edu> Martin, my sourceforge ID is 'pfschaffner'. It's old but still works -- like me :) pfs On Thu, 19 Apr 2012, Martin Holmes wrote: > One thing we should have done at the ftf is to get the new Council > members set up with SourceForge accounts and add them to the project, so > that we can assign tickets to them. Neither Becky nor Paul are members > of the TEI project on SF yet. Do either of you have a SourceForge > account? If not, could you set one up: > > <https://sourceforge.net/user/registration> > > Once you have an id, let me know and I'll add you to the list, and then > you can start getting tickets dumped on you by the likes of us. :-) > > Cheers, > Martin > -- > Martin Holmes > University of Victoria Humanities Computing and Media Centre > (mholmes at uvic.ca) > -- > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > > PLEASE NOTE: postings to this list are publicly archived > > > -------------------------------------------------------------------- Paul Schaffner | PFSchaffner at umich.edu | http://www.umich.edu/~pfs/ 316-C Hatcher Library N, Univ. of Michigan, Ann Arbor MI 48109-1190 -------------------------------------------------------------------- From syeates at gmail.com Fri Apr 20 02:33:22 2012 From: syeates at gmail.com (stuart yeates) Date: Fri, 20 Apr 2012 18:33:22 +1200 Subject: [tei-council] Links in examples Message-ID: <4F910332.4000701@gmail.com> http://www.tei-c.org/release/doc/tei-p5-doc/fr/html/examples-lg.html contains an example with the line "Les amoureux fervents et les savants aust?res" the example links to http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-lg.html but is should link to http://www.tei-c.org/release/doc/tei-p5-doc/fr/html/ref-lg.html (i.e. it should link to the fr version not the en version). I tripped over this doing new examples for https://secure.wikimedia.org/wikipedia/en/wiki/Text_Encoding_Initiative Is that a trivial fix, or should I open a ticket about it? cheers stuart From syeates at gmail.com Fri Apr 20 02:33:37 2012 From: syeates at gmail.com (stuart yeates) Date: Fri, 20 Apr 2012 18:33:37 +1200 Subject: [tei-council] removing and renaming XML files Message-ID: <4F910341.8070906@gmail.com> The following XML files appear to no longer in use, I would like to remove them (preserving them in the subversion history, naturally): P5/Source/Guidelines/en/SH-OtherMetadataStandards.xml P5/Source/Guidelines/en/TE-TerminologicalDatabases.xml P5/Source/Guidelines/en/PARTIND.xml P5/Source/Guidelines/en/DT-ObtainingSchemas.xml P5/Source/Guidelines/en/IN-RulesForInterchange.xml I would also like to rename: P5/Source/Guidelines/*/DI-PrintDictionaries.xml to P5/Source/Guidelines/*/DI-Dictionaries.xml because this chapter covers born-digital dictionaries too. I don't believe that this will change the resulting output, but may change the way that we think about it. The name would also need to be updated in: Documents/Editing/tcw-editing.xml P5/Source/guidelines-*.xml cheers stuart From sebastian.rahtz at oucs.ox.ac.uk Fri Apr 20 05:11:40 2012 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Fri, 20 Apr 2012 09:11:40 +0000 Subject: [tei-council] Links in examples In-Reply-To: <4F910332.4000701@gmail.com> References: <4F910332.4000701@gmail.com> Message-ID: <9EA071A6-7C11-42C5-A021-8EB7092349B9@oucs.ox.ac.uk> On 20 Apr 2012, at 07:33, stuart yeates wrote: > > http://www.tei-c.org/release/doc/tei-p5-doc/fr/html/examples-lg.html > contains an example with the line "Les amoureux fervents et les savants > aust?res" the example links to > http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-lg.html but is > should link to > http://www.tei-c.org/release/doc/tei-p5-doc/fr/html/ref-lg.html (i.e. it > should link to the fr version not the en version). > ... > Is that a trivial fix, or should I open a ticket about it? potentially trivial. do you want to have a look and see if you can fix it? -- Stormageddon Rahtz Head of Information and Support Group Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From syeates at gmail.com Fri Apr 20 06:11:27 2012 From: syeates at gmail.com (stuart yeates) Date: Fri, 20 Apr 2012 22:11:27 +1200 Subject: [tei-council] Links in examples In-Reply-To: <9EA071A6-7C11-42C5-A021-8EB7092349B9@oucs.ox.ac.uk> References: <4F910332.4000701@gmail.com> <9EA071A6-7C11-42C5-A021-8EB7092349B9@oucs.ox.ac.uk> Message-ID: <4F91364F.60907@gmail.com> On 20/04/12 21:11, Sebastian Rahtz wrote: > > On 20 Apr 2012, at 07:33, stuart yeates wrote: > >> >> http://www.tei-c.org/release/doc/tei-p5-doc/fr/html/examples-lg.html >> contains an example with the line "Les amoureux fervents et les savants >> aust?res" the example links to >> http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-lg.html but is >> should link to >> http://www.tei-c.org/release/doc/tei-p5-doc/fr/html/ref-lg.html (i.e. it >> should link to the fr version not the en version). >> ... >> Is that a trivial fix, or should I open a ticket about it? > > > potentially trivial. do you want to have a look and see if you can > fix it? I've just had a crack at it, which ought to work, and jenkins didn't choke on it. cheers stuart From sebastian.rahtz at oucs.ox.ac.uk Fri Apr 20 06:30:08 2012 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Fri, 20 Apr 2012 10:30:08 +0000 Subject: [tei-council] Links in examples In-Reply-To: <4F91364F.60907@gmail.com> References: <4F910332.4000701@gmail.com> <9EA071A6-7C11-42C5-A021-8EB7092349B9@oucs.ox.ac.uk> <4F91364F.60907@gmail.com> Message-ID: <22D632AD-9695-4657-AA50-106FA7D0AA8E@oucs.ox.ac.uk> On 20 Apr 2012, at 11:11, stuart yeates wrote: > > I've just had a crack at it, which ought to work, and jenkins didn't choke on it. > and that prompted me to wonder why Jenkins had not built new documentation after your change (which should be fine, from what I could see). the answer is that after all the changes this week, Jenkins thinks P5 is unstable (because of too many failed builds, even though current is OK), so it did not pass on to later stages. I have told it to do so. -- Stormageddon Rahtz Head of Information and Support Group Oxford University Computing Services 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 Apr 20 06:35:09 2012 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Fri, 20 Apr 2012 10:35:09 +0000 Subject: [tei-council] removing and renaming XML files In-Reply-To: <4F910341.8070906@gmail.com> References: <4F910341.8070906@gmail.com> Message-ID: <00B92B20-1069-4A53-A8BE-F18703C4003A@oucs.ox.ac.uk> On 20 Apr 2012, at 07:33, stuart yeates wrote: > The following XML files appear to no longer in use, I would like to > remove them (preserving them in the subversion history, naturally): > > P5/Source/Guidelines/en/SH-OtherMetadataStandards.xml > P5/Source/Guidelines/en/TE-TerminologicalDatabases.xml > P5/Source/Guidelines/en/PARTIND.xml > P5/Source/Guidelines/en/DT-ObtainingSchemas.xml > P5/Source/Guidelines/en/IN-RulesForInterchange.xml > you could move them into Source/Specs-unused perhaps for now. thats where other similar things are. > > I would also like to rename: > > P5/Source/Guidelines/*/DI-PrintDictionaries.xml > > to > > P5/Source/Guidelines/*/DI-Dictionaries.xml seems good to me -- Stormageddon Rahtz Head of Information and Support Group Oxford University Computing Services 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 Apr 20 07:49:44 2012 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Fri, 20 Apr 2012 11:49:44 +0000 Subject: [tei-council] Links in examples In-Reply-To: <4F910332.4000701@gmail.com> References: <4F910332.4000701@gmail.com> Message-ID: <C69C38D5-CD5C-4B47-B993-348054B504A2@oucs.ox.ac.uk> see http://bits.nsms.ox.ac.uk:8080/jenkins/job/TEIP5-Documentation/lastSuccessfulBuild/artifact/Guidelines-web/fr/html/examples-lg.html now after Stuart's changes. Seems right -- Stormageddon Rahtz Head of Information and Support Group Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From bansp at o2.pl Fri Apr 20 09:14:09 2012 From: bansp at o2.pl (=?ISO-8859-2?Q?Piotr_Ba=F1ski?=) Date: Fri, 20 Apr 2012 15:14:09 +0200 Subject: [tei-council] removing and renaming XML files In-Reply-To: <4F910341.8070906@gmail.com> References: <4F910341.8070906@gmail.com> Message-ID: <4F916121.3040808@o2.pl> On 20/04/12 08:33, stuart yeates wrote: [..] > I would also like to rename: > > P5/Source/Guidelines/*/DI-PrintDictionaries.xml > > to > > P5/Source/Guidelines/*/DI-Dictionaries.xml > > because this chapter covers born-digital dictionaries too. I don't > believe that this will change the resulting output, but may change the > way that we think about it. The name would also need to be updated in: > > Documents/Editing/tcw-editing.xml > P5/Source/guidelines-*.xml > I thought that this change was not happening because the individual chapters are often linked from many places. Is there a chance to leave DI-PrintDictionaries.xml as an alias to the new filename, not to break too many links out there? P. From mholmes at uvic.ca Fri Apr 20 10:18:33 2012 From: mholmes at uvic.ca (Martin Holmes) Date: Fri, 20 Apr 2012 07:18:33 -0700 Subject: [tei-council] removing and renaming XML files In-Reply-To: <4F916121.3040808@o2.pl> References: <4F910341.8070906@gmail.com> <4F916121.3040808@o2.pl> Message-ID: <4F917039.9060903@uvic.ca> Better to break the links and fix them, I think, since we're winding up to a "major" release, and if the tei_ prefix in anchors is included in it, lots of existing links will break anyway. But this really ought to be a policy issue. Under what circumstances is it acceptable to break existing links to a) pages in the Guidelines, and b) anchors on pages? And when we do break them with a new release, what are our obligations in terms of supporting the old links? Cheers, Martin On 12-04-20 06:14 AM, Piotr Ba?ski wrote: > On 20/04/12 08:33, stuart yeates wrote: > [..] >> I would also like to rename: >> >> P5/Source/Guidelines/*/DI-PrintDictionaries.xml >> >> to >> >> P5/Source/Guidelines/*/DI-Dictionaries.xml >> >> because this chapter covers born-digital dictionaries too. I don't >> believe that this will change the resulting output, but may change the >> way that we think about it. The name would also need to be updated in: >> >> Documents/Editing/tcw-editing.xml >> P5/Source/guidelines-*.xml >> > > I thought that this change was not happening because the individual > chapters are often linked from many places. Is there a chance to leave > DI-PrintDictionaries.xml as an alias to the new filename, not to break > too many links out there? > > P. From sebastian.rahtz at oucs.ox.ac.uk Fri Apr 20 11:34:06 2012 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Fri, 20 Apr 2012 15:34:06 +0000 Subject: [tei-council] removing and renaming XML files In-Reply-To: <4F917039.9060903@uvic.ca> References: <4F910341.8070906@gmail.com> <4F916121.3040808@o2.pl> <4F917039.9060903@uvic.ca> Message-ID: <EAEC2C8D-5BE0-41DE-A35A-F59244891DF1@oucs.ox.ac.uk> On 20 Apr 2012, at 15:18, Martin Holmes wrote: > Better to break the links and fix them, I think, since we're winding up > to a "major" release, and if the tei_ prefix in anchors is included in > it, lots of existing links will break anyway. > but the link to the _files_ mustn't change. i.e. it will still be DI-PrintDictionaries.html not tei_DI-PrintDictionaries.html > But this really ought to be a policy issue. Under what circumstances is > it acceptable to break existing links to a) pages in the Guidelines, and > b) anchors on pages? a) not many, but if the alternatives are worse, so be it b) when it seems sensible > And when we do break them with a new release, what > are our obligations in terms of supporting the old links? as much as is reasonably possible. if all the tei_ exercise changes is anchors on pages, I'd not worry about it -- Stormageddon Rahtz Head of Information and Support Group Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From lou.burnard at retired.ox.ac.uk Fri Apr 20 13:41:21 2012 From: lou.burnard at retired.ox.ac.uk (Lou Burnard) Date: Fri, 20 Apr 2012 18:41:21 +0100 Subject: [tei-council] removing and renaming XML files In-Reply-To: <4F916121.3040808@o2.pl> References: <4F910341.8070906@gmail.com> <4F916121.3040808@o2.pl> Message-ID: <4F919FC1.2030400@retired.ox.ac.uk> On 20/04/12 14:14, Piotr Ba?ski wrote: > On 20/04/12 08:33, stuart yeates wrote: > [..] >> I would also like to rename: >> >> P5/Source/Guidelines/*/DI-PrintDictionaries.xml >> >> to >> >> P5/Source/Guidelines/*/DI-Dictionaries.xml >> >> because this chapter covers born-digital dictionaries too. I don't think changing the filename of this chapter is warranted as yet. There was some discussion about extending its coverage so as to deliver more specifically on the promise made in its first chapter that its content could also be applied to non-print dictionaries, but so far that extension hasn't happened yet. Unless and until it does, I think this change would be a needless additional complication, needlessly messing up links to the chapter (of which there are probably many more than there are links to its component sections). People use the content of the msDescription chapter to describe things that aren't manuscripts too. From rwelzenbach at gmail.com Fri Apr 20 15:00:18 2012 From: rwelzenbach at gmail.com (Rebecca Welzenbach) Date: Fri, 20 Apr 2012 15:00:18 -0400 Subject: [tei-council] New council members and SourceForge In-Reply-To: <Pine.LNX.4.64.1204192106340.9625@zaxxon.gpcc.itd.umich.edu> References: <4F90B586.3010308@uvic.ca> <Pine.LNX.4.64.1204192106340.9625@zaxxon.gpcc.itd.umich.edu> Message-ID: <CAA2irt+dK_g6GXe=P+QUEN3DAu0DWJXBBTyrYmJssN2Q_uzbPA@mail.gmail.com> Thanks for doing this, Martin. My sourceforge ID is 'rwelzenb'. It is as-yet untested, but ready to be assigned something--like me. Becky P.S. I see Paul and I are still not in agreement on the issue of spaces around parenthetical em dashes. On Thu, Apr 19, 2012 at 9:07 PM, Paul F. Schaffner <PFSchaffner at umich.edu> wrote: > > Martin, my sourceforge ID is 'pfschaffner'. It's old but still > works -- like me :) > > pfs > > On Thu, 19 Apr 2012, Martin Holmes wrote: > >> One thing we should have done at the ftf is to get the new Council >> members set up with SourceForge accounts and add them to the project, so >> that we can assign tickets to them. Neither Becky nor Paul are members >> of the TEI project on SF yet. Do either of you have a SourceForge >> account? If not, could you set one up: >> >> <https://sourceforge.net/user/registration> >> >> Once you have an id, let me know and I'll add you to the list, and then >> you can start getting tickets dumped on you by the likes of us. :-) >> >> Cheers, >> Martin >> -- >> Martin Holmes >> University of Victoria Humanities Computing and Media Centre >> (mholmes at uvic.ca) >> -- >> tei-council mailing list >> tei-council at lists.village.Virginia.EDU >> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council >> >> PLEASE NOTE: postings to this list are publicly archived >> >> >> > > -------------------------------------------------------------------- > Paul Schaffner | PFSchaffner at umich.edu | http://www.umich.edu/~pfs/ > 316-C Hatcher Library N, Univ. of Michigan, Ann Arbor MI 48109-1190 > -------------------------------------------------------------------- > -- > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > > PLEASE NOTE: postings to this list are publicly archived From kevin.s.hawkins at ultraslavonic.info Fri Apr 20 15:24:15 2012 From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins) Date: Fri, 20 Apr 2012 15:24:15 -0400 Subject: [tei-council] removing and renaming XML files In-Reply-To: <4F919FC1.2030400@retired.ox.ac.uk> References: <4F910341.8070906@gmail.com> <4F916121.3040808@o2.pl> <4F919FC1.2030400@retired.ox.ac.uk> Message-ID: <4F91B7DF.2080209@ultraslavonic.info> On 4/20/2012 1:41 PM, Lou Burnard wrote: > On 20/04/12 14:14, Piotr Ba?ski wrote: >> On 20/04/12 08:33, stuart yeates wrote: >> [..] >>> I would also like to rename: >>> >>> P5/Source/Guidelines/*/DI-PrintDictionaries.xml >>> >>> to >>> >>> P5/Source/Guidelines/*/DI-Dictionaries.xml >>> >>> because this chapter covers born-digital dictionaries too. > > > I don't think changing the filename of this chapter is warranted as yet. > There was some discussion about extending its coverage so as to deliver > more specifically on the promise made in its first chapter that its > content could also be applied to non-print dictionaries, but so far that > extension hasn't happened yet. Lou, do you mean "the promise made in the first section of this chapter"? The title of the chapter given in the HTML and PDF versions of the Guidelines is already "Dictionaries", not "Print Dictionaries", so I think Piotr is suggesting renaming the file to match the human-readable form actually in use. > Unless and until it does, I think this > change would be a needless additional complication, needlessly messing > up links to the chapter (of which there are probably many more than > there are links to its component sections). > > People use the content of the msDescription chapter to describe things > that aren't manuscripts too. Yes, and this causes confusion because people who are working with printed works aren't sure whether to use this chapter. On this note, I think I've found a chair for a rechartered physical bibliography group who can lead the many people who have expressed interest in the group but been unwilling to lead the effort. I asked her to draft a new charter that I could share with Council before the group gets started (in case we feel they are headed in entirely the wrong direction). From syeates at gmail.com Fri Apr 20 15:49:22 2012 From: syeates at gmail.com (stuart yeates) Date: Sat, 21 Apr 2012 07:49:22 +1200 Subject: [tei-council] removing and renaming XML files In-Reply-To: <4F917039.9060903@uvic.ca> References: <4F910341.8070906@gmail.com> <4F916121.3040808@o2.pl> <4F917039.9060903@uvic.ca> Message-ID: <4F91BDC2.9020802@gmail.com> On 21/04/12 02:18, Martin Holmes wrote: > Better to break the links and fix them, I think, since we're winding up > to a "major" release, and if the tei_ prefix in anchors is included in > it, lots of existing links will break anyway. Only the "DI" part is included in the anchors (or the ones I checked, anyway). I don't believe that this will break any links and should not be supported / should be actively rolled back if it is later found to be breaking them. > But this really ought to be a policy issue. Under what circumstances is > it acceptable to break existing links to a) pages in the Guidelines, and > b) anchors on pages? And when we do break them with a new release, what > are our obligations in terms of supporting the old links? I'd support not deliberately breaking links until P6. cheers stuart From mholmes at uvic.ca Fri Apr 20 15:55:35 2012 From: mholmes at uvic.ca (Martin Holmes) Date: Fri, 20 Apr 2012 12:55:35 -0700 Subject: [tei-council] New council members and SourceForge In-Reply-To: <CAA2irt+dK_g6GXe=P+QUEN3DAu0DWJXBBTyrYmJssN2Q_uzbPA@mail.gmail.com> References: <4F90B586.3010308@uvic.ca> <Pine.LNX.4.64.1204192106340.9625@zaxxon.gpcc.itd.umich.edu> <CAA2irt+dK_g6GXe=P+QUEN3DAu0DWJXBBTyrYmJssN2Q_uzbPA@mail.gmail.com> Message-ID: <4F91BF37.5010100@uvic.ca> Hi Rebecca, I've added you as a Technician on Bugs and Feature Requests, and assigned you this ticket: <http://purl.org/TEI/BUGS/3471119> You can close it when you've set up the style guide document and copied the relevant bits into it from the ticket. Cheers, Martin On 12-04-20 12:00 PM, Rebecca Welzenbach wrote: > Thanks for doing this, Martin. My sourceforge ID is 'rwelzenb'. It is > as-yet untested, but ready to be assigned something--like me. > > Becky > > P.S. I see Paul and I are still not in agreement on the issue of > spaces around parenthetical em dashes. > > > > On Thu, Apr 19, 2012 at 9:07 PM, Paul F. Schaffner > <PFSchaffner at umich.edu> wrote: >> >> Martin, my sourceforge ID is 'pfschaffner'. It's old but still >> works -- like me :) >> >> pfs >> >> On Thu, 19 Apr 2012, Martin Holmes wrote: >> >>> One thing we should have done at the ftf is to get the new Council >>> members set up with SourceForge accounts and add them to the project, so >>> that we can assign tickets to them. Neither Becky nor Paul are members >>> of the TEI project on SF yet. Do either of you have a SourceForge >>> account? If not, could you set one up: >>> >>> <https://sourceforge.net/user/registration> >>> >>> Once you have an id, let me know and I'll add you to the list, and then >>> you can start getting tickets dumped on you by the likes of us. :-) >>> >>> Cheers, >>> Martin >>> -- >>> Martin Holmes >>> University of Victoria Humanities Computing and Media Centre >>> (mholmes at uvic.ca) >>> -- >>> tei-council mailing list >>> tei-council at lists.village.Virginia.EDU >>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council >>> >>> PLEASE NOTE: postings to this list are publicly archived >>> >>> >>> >> >> -------------------------------------------------------------------- >> Paul Schaffner | PFSchaffner at umich.edu | http://www.umich.edu/~pfs/ >> 316-C Hatcher Library N, Univ. of Michigan, Ann Arbor MI 48109-1190 >> -------------------------------------------------------------------- >> -- >> tei-council mailing list >> tei-council at lists.village.Virginia.EDU >> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council >> >> PLEASE NOTE: postings to this list are publicly archived From PFSchaffner at umich.edu Fri Apr 20 16:06:15 2012 From: PFSchaffner at umich.edu (Paul F. Schaffner) Date: Fri, 20 Apr 2012 16:06:15 -0400 (EDT) Subject: [tei-council] New council members and SourceForge In-Reply-To: <4F91BF37.5010100@uvic.ca> References: <4F90B586.3010308@uvic.ca> <Pine.LNX.4.64.1204192106340.9625@zaxxon.gpcc.itd.umich.edu> <CAA2irt+dK_g6GXe=P+QUEN3DAu0DWJXBBTyrYmJssN2Q_uzbPA@mail.gmail.com> <4F91BF37.5010100@uvic.ca> Message-ID: <Pine.LNX.4.64.1204201600080.6689@rygar.gpcc.itd.umich.edu> Paul wrote: >> It's old but still works -- like me. Becky wrote: >> ... ready to be assigned something--like me. >> P.S. I see Paul and I are still not in agreement on the issue of >> spaces around parenthetical em dashes. Examining my own usage--always a perilous thing--I find that I close up the spaces in more formal prose, and where the dashes are truly parenthetical; but in more liberated settings, or when leaping from a sentence into a concluding exclamation, or on Fridays -- well then, the em-dashes require a little room around them to breathe! This should not be construed as a feature request. pfs -------------------------------------------------------------------- Paul Schaffner | PFSchaffner at umich.edu | http://www.umich.edu/~pfs/ 316-C Hatcher Library N, Univ. of Michigan, Ann Arbor MI 48109-1190 -------------------------------------------------------------------- From mholmes at uvic.ca Fri Apr 20 17:40:41 2012 From: mholmes at uvic.ca (Martin Holmes) Date: Fri, 20 Apr 2012 14:40:41 -0700 Subject: [tei-council] New council members and SourceForge In-Reply-To: <Pine.LNX.4.64.1204201600080.6689@rygar.gpcc.itd.umich.edu> References: <4F90B586.3010308@uvic.ca> <Pine.LNX.4.64.1204192106340.9625@zaxxon.gpcc.itd.umich.edu> <CAA2irt+dK_g6GXe=P+QUEN3DAu0DWJXBBTyrYmJssN2Q_uzbPA@mail.gmail.com> <4F91BF37.5010100@uvic.ca> <Pine.LNX.4.64.1204201600080.6689@rygar.gpcc.itd.umich.edu> Message-ID: <4F91D7D9.4040906@uvic.ca> I think we decided re spaces around em dashes. We go with Chicago, and don't permit them. However, I've left them in non-English language text, as well as in quotations, egXMLs, and bibliographic items such as ISO document titles, on the grounds that when you're quoting something else, you'll quote its spacing as well. Cheers, Martin On 12-04-20 01:06 PM, Paul F. Schaffner wrote: > Paul wrote: >>> It's old but still works -- like me. > Becky wrote: >>> ... ready to be assigned something--like me. >>> P.S. I see Paul and I are still not in agreement on the issue of >>> spaces around parenthetical em dashes. > > Examining my own usage--always a perilous thing--I find that I > close up the spaces in more formal prose, and where the dashes > are truly parenthetical; but in more liberated settings, or when > leaping from a sentence into a concluding exclamation, or on > Fridays -- well then, the em-dashes require a little room around > them to breathe! > > This should not be construed as a feature request. > > pfs > -------------------------------------------------------------------- > Paul Schaffner | PFSchaffner at umich.edu | http://www.umich.edu/~pfs/ > 316-C Hatcher Library N, Univ. of Michigan, Ann Arbor MI 48109-1190 > -------------------------------------------------------------------- From lou.burnard at retired.ox.ac.uk Fri Apr 20 18:19:37 2012 From: lou.burnard at retired.ox.ac.uk (Lou Burnard) Date: Fri, 20 Apr 2012 23:19:37 +0100 Subject: [tei-council] removing and renaming XML files In-Reply-To: <4F91B7DF.2080209@ultraslavonic.info> References: <4F910341.8070906@gmail.com> <4F916121.3040808@o2.pl> <4F919FC1.2030400@retired.ox.ac.uk> <4F91B7DF.2080209@ultraslavonic.info> Message-ID: <4F91E0F9.4050205@retired.ox.ac.uk> On 20/04/12 20:24, Kevin Hawkins wrote: > On 4/20/2012 1:41 PM, Lou Burnard wrote: >> On 20/04/12 14:14, Piotr Ba?ski wrote: >>> On 20/04/12 08:33, stuart yeates wrote: >>> [..] >>>> I would also like to rename: >>>> >>>> P5/Source/Guidelines/*/DI-PrintDictionaries.xml >>>> >>>> to >>>> >>>> P5/Source/Guidelines/*/DI-Dictionaries.xml >>>> >>>> because this chapter covers born-digital dictionaries too. >> >> >> I don't think changing the filename of this chapter is warranted as yet. >> There was some discussion about extending its coverage so as to deliver >> more specifically on the promise made in its first chapter that its >> content could also be applied to non-print dictionaries, but so far that >> extension hasn't happened yet. > > Lou, do you mean "the promise made in the first section of this chapter"? Indeed I do. Sorry about the tyupo. > > The title of the chapter given in the HTML and PDF versions of the > Guidelines is already "Dictionaries", not "Print Dictionaries", so I > think Piotr is suggesting renaming the file to match the human-readable > form actually in use. > Good point. I had forgotten that. > > Unless and until it does, I think this >> change would be a needless additional complication, needlessly messing >> up links to the chapter (of which there are probably many more than >> there are links to its component sections). >> I still think that on balance it's not worth the effort of renaming the chapter file. But then I was also the one who wanted to leave it with the name "DI,xml" on the grounds that introducing more information into file names would only lead to tears before bedtime. And lo... From syeates at gmail.com Fri Apr 20 19:03:21 2012 From: syeates at gmail.com (stuart yeates) Date: Sat, 21 Apr 2012 11:03:21 +1200 Subject: [tei-council] Links in examples In-Reply-To: <C69C38D5-CD5C-4B47-B993-348054B504A2@oucs.ox.ac.uk> References: <4F910332.4000701@gmail.com> <C69C38D5-CD5C-4B47-B993-348054B504A2@oucs.ox.ac.uk> Message-ID: <4F91EB39.70902@gmail.com> On 20/04/12 23:49, Sebastian Rahtz wrote: > see http://bits.nsms.ox.ac.uk:8080/jenkins/job/TEIP5-Documentation/lastSuccessfulBuild/artifact/Guidelines-web/fr/html/examples-lg.html > now after Stuart's changes. Seems right On the third attempt I appear to have fixed this properly. Jenkins proved very useful in getting this right. cheers stuart From mholmes at uvic.ca Sat Apr 21 02:42:07 2012 From: mholmes at uvic.ca (Martin Holmes) Date: Sat, 21 Apr 2012 02:42:07 -0400 Subject: [tei-council] Attributes without examples In-Reply-To: <4F90AEBC.6000608@ultraslavonic.info> References: <4F908F22.4070908@uvic.ca> <4F90AD72.10605@uvic.ca> <4F90AEBC.6000608@ultraslavonic.info> Message-ID: <4F9256BF.5050406@uvic.ca> I'll do this on Monday, but before I do: does everyone have an account on the wiki? Cheers, Martin On 12-04-19 08:33 PM, Kevin Hawkins wrote: > Would you be able to output as a table with a third column for people to > sign up, either in MediaWiki or HTML syntax, for a page in the wiki? > > On 4/19/12 8:27 PM, Martin Holmes wrote: >> Below is another slightly shorter list. These are attributes which do >> not appear on any examples in the<elementSpec> or<classSpec> in which >> they're defined. Not that this doesn't mean there are no examples at all >> for them; there may be an example somewhere in the Guidelines text, or >> the attribute may be defined in a<classSpec> for an attribute class, >> and then show up in an example in an<elementSpec> for an element which >> belongs to that class. An example of the latter is @agent (att.damaged), >> which has no example in the att.damaged<classSpec>, but happens to show >> up in an example for the<damage> element. >> >> Nevertheless, I think it would be a good idea to try to provide examples >> for all these attributes, in the files which define them. >> >> ATTRIBUTES WHICH DO NOT SHOW UP ON ANY EXAMPLE IN THEIR elementSpec OR >> classSpec AS OF 2012-04-19T17:19:17.315-07:00 >> >> 1. absolute (when) >> 2. adj (node) >> 3. adjFrom (node) >> 4. adjTo (node) >> 5. age (personGrp) >> 6. agent (att.damaged) >> 7. agent (gap) >> 8. agent (unclear) >> 9. ana (att.global.analytic) >> 10. atLeast (att.ranging) >> 11. atMost (att.ranging) >> 12. attachment (surface) >> 13. autoPrefix (content) >> 14. baseTypes (fsDecl) >> 15. break (att.breaking) >> 16. cRef (gloss) >> 17. cRef (ptr) >> 18. cRef (ref) >> 19. cRef (term) >> 20. cause (att.textCritical) >> 21. cause (att.transcriptional) >> 22. cert (att.responsibility) >> 23. change (att.global.change) >> 24. class (msContents) >> 25. cols (att.tableDecoration) >> 26. confidence (att.ranging) >> 27. contemporary (seal) >> 28. copyOf (att.global.linking) >> 29. corresp (att.global.linking) >> 30. datingMethod (att.datable.custom) >> 31. datingPoint (att.datable.custom) >> 32. decls (att.declaring) >> 33. default (att.declarable) >> 34. defective (att.msExcerpt) >> 35. degree (att.damaged) >> 36. degree (node) >> 37. dim (space) >> 38. direct (said) >> 39. docLang (schemaSpec) >> 40. domains (att.pointing.group) >> 41. dur (att.duration.w3c) >> 42. dur-iso (att.duration.iso) >> 43. encoding (binaryObject) >> 44. end (att.timed) >> 45. enjamb (att.enjamb) >> 46. evaluate (att.pointing) >> 47. evidence (att.editLike) >> 48. except (moduleRef) >> 49. exclude (att.global.linking) >> 50. expand (att.lexicographic) >> 51. extent (orth) >> 52. fVal (f) >> 53. facs (att.global.facs) >> 54. feats (fs) >> 55. filter (equiv) >> 56. flipping (surface) >> 57. follow (leaf) >> 58. force (pc) >> 59. from (app) >> 60. from (att.datable.w3c) >> 61. from-custom (att.datable.custom) >> 62. from-iso (att.datable.iso) >> 63. full (att.personal) >> 64. function (att.segLike) >> 65. generate (classSpec) >> 66. gradual (writing) >> 67. group (att.damaged) >> 68. hand (att.damaged) >> 69. hand (att.textCritical) >> 70. hand (att.transcriptional) >> 71. hand (gap) >> 72. hand (unclear) >> 73. height (binaryObject) >> 74. height (graphic) >> 75. ident (att.identified) >> 76. inst (att.interpLike) >> 77. instant (att.editLike) >> 78. key (att.canonical) >> 79. key (classRef) >> 80. key (macroRef) >> 81. level (sense) >> 82. level (title) >> 83. loc (app) >> 84. location (att.lexicographic) >> 85. lrx (att.coordinated) >> 86. lry (att.coordinated) >> 87. match (att.scoping) >> 88. material (supportDesc) >> 89. max (att.ranging) >> 90. max (memberOf) >> 91. medium (att.handFeatures) >> 92. mergedIn (att.lexicographic) >> 93. met (att.metrical) >> 94. method (correction) >> 95. mimeType (att.internetMedia) >> 96. min (att.ranging) >> 97. min (memberOf) >> 98. mode (att.combinable) >> 99. mode (classes) >> 100. mode (memberOf) >> 101. module (att.identified) >> 102. new (handShift) >> 103. next (att.global.linking) >> 104. notAfter-custom (att.datable.custom) >> 105. notAfter-iso (att.datable.iso) >> 106. notBefore-custom (att.datable.custom) >> 107. notBefore-iso (att.datable.iso) >> 108. notation (pron) >> 109. ns (attDef) >> 110. ns (elementSpec) >> 111. ns (schemaSpec) >> 112. nymRef (att.naming) >> 113. opt (att.lexicographic) >> 114. optional (fDecl) >> 115. ord (iNode) >> 116. ord (root) >> 117. org (att.divLike) >> 118. org (attList) >> 119. orig (att.lexicographic) >> 120. part (ab) >> 121. part (att.divLike) >> 122. part (att.segLike) >> 123. parts (nym) >> 124. perf (tech) >> 125. period (att.datable) >> 126. pre (pc) >> 127. precision (att.dimensions) >> 128. predeclare (att.identified) >> 129. prefix (elementSpec) >> 130. prefix (moduleRef) >> 131. prev (att.global.linking) >> 132. quantity (att.dimensions) >> 133. real (att.metrical) >> 134. ref (att.canonical) >> 135. refLang (att.pointing) >> 136. resp (att.responsibility) >> 137. resp (space) >> 138. rhyme (att.metrical) >> 139. role (att.naming) >> 140. role (att.tableDecoration) >> 141. role (org) >> 142. rotate (zone) >> 143. rows (att.tableDecoration) >> 144. sameAs (att.global.linking) >> 145. sample (att.divLike) >> 146. scale (binaryObject) >> 147. scale (graphic) >> 148. scheme (catRef) >> 149. scheme (locus) >> 150. scheme (locusGrp) >> 151. scheme (tag) >> 152. scope (att.dimensions) >> 153. scope (att.handFeatures) >> 154. scribe (att.handFeatures) >> 155. scribeRef (att.handFeatures) >> 156. script (att.handFeatures) >> 157. scriptRef (att.handFeatures) >> 158. select (att.global.linking) >> 159. seq (att.transcriptional) >> 160. social (distinct) >> 161. sort (att.personal) >> 162. source (att.editLike) >> 163. source (att.readFrom) >> 164. source (writing) >> 165. space (distinct) >> 166. spanTo (att.spanning) >> 167. split (att.lexicographic) >> 168. start (att.coordinated) >> 169. start (att.timed) >> 170. status (att.identified) >> 171. status (att.transcriptional) >> 172. status (correction) >> 173. stdDeviation (precision) >> 174. subtype (att.typed) >> 175. synch (att.global.linking) >> 176. targFunc (att.pointing.group) >> 177. target (change) >> 178. target (relatedItem) >> 179. targetEnd (note) >> 180. targetLang (schemaSpec) >> 181. targets (alt) >> 182. targets (join) >> 183. targets (link) >> 184. time (distinct) >> 185. to (app) >> 186. to (att.datable.w3c) >> 187. to-custom (att.datable.custom) >> 188. to-iso (att.datable.iso) >> 189. type (abbr) >> 190. type (att.entryLike) >> 191. type (att.interpLike) >> 192. type (att.textCritical) >> 193. type (att.typed) >> 194. type (form) >> 195. type (q) >> 196. type (sound) >> 197. ulx (att.coordinated) >> 198. uly (att.coordinated) >> 199. unit (att.dimensions) >> 200. unit (pc) >> 201. unit (when) >> 202. url (moduleRef) >> 203. value (att.lexicographic) >> 204. value (eTree) >> 205. value (iNode) >> 206. value (leaf) >> 207. value (node) >> 208. value (root) >> 209. value (triangle) >> 210. varSeq (att.textCritical) >> 211. version (unicodeName) >> 212. versionDate (att.translatable) >> 213. when (docDate) >> 214. where (event) >> 215. who (att.ascribed) >> 216. width (binaryObject) >> 217. width (graphic) >> 218. wit (att.rdgPart) >> 219. wit (att.witnessed) >> 220. xml:base (att.global) >> 221. xml:id (att.global) >> 222. xml:lang (att.global) >> 223. xml:space (att.global) >> >> Cheers, >> Martin >> >> On 12-04-19 03:18 PM, Martin Holmes wrote: >>> Following on from our discussion of examples for attributes, a >>> quick-and-dirty XSLT seems to show that there are only 19 attributes >>> with their own examples, and 450 without. This is not to say that those >>> without are unexemplified, because the example code for their parent >>> elements in the elementSpec may show examples of them; I'll refine the >>> XSLT and make that apparent. >>> >>> Here's the list: >>> >>> ATTRIBUTE DEFINITIONS LACKING EXAMPLES AS OF 2012-04-19T15:12:34.968-07:00 >>> >>> 1. status (att.identified) >>> 2. type (interaction) >>> 3. value (sex) >>> 4. scale (graphic) >>> 5. scale (binaryObject) >>> 6. weights (alt) >>> 7. hand (att.damaged) >>> 8. agent (gap) >>> 9. predeclare (att.identified) >>> 10. degree (att.damaged) >>> 11. module (att.identified) >>> 12. ident (att.identified) >>> 13. height (graphic) >>> 14. height (binaryObject) >>> 15. width (graphic) >>> 16. width (binaryObject) >>> 17. encoding (binaryObject) >>> 18. version (teiCorpus) >>> 19. hand (unclear) >>> 20. agent (unclear) >>> 21. feature (shift) >>> 22. type (preparedness) >>> 23. type (abbr) >>> 24. commodity (att.measurement) >>> 25. agent (att.damaged) >>> 26. type (derivation) >>> 27. type (domain) >>> 28. type (factuality) >>> 29. type (idno) >>> 30. type (relation) >>> 31. type (sound) >>> 32. type (tech) >>> 33. type (castItem) >>> 34. type (att.typed) >>> 35. type (move) >>> 36. script (att.handFeatures) >>> 37. class (msItemStruct) >>> 38. class (msItem) >>> 39. class (msContents) >>> 40. type (form) >>> 41. cause (att.textCritical) >>> 42. type (gram) >>> 43. type (lbl) >>> 44. type (att.textCritical) >>> 45. type (title) >>> 46. type (titlePage) >>> 47. type (usg) >>> 48. type (app) >>> 49. columns (layout) >>> 50. valueDatcat (att.datcat) >>> 51. datcat (att.datcat) >>> 52. contemporary (seal) >>> 53. contemporary (binding) >>> 54. from (locus) >>> 55. type (list) >>> 56. result (joinGrp) >>> 57. medium (att.handFeatures) >>> 58. type (graph) >>> 59. type (witDetail) >>> 60. origin (timeline) >>> 61. function (att.segLike) >>> 62. form (objectDesc) >>> 63. mergedIn (att.lexicographic) >>> 64. type (fsDecl) >>> 65. scribe (att.handFeatures) >>> 66. degree (node) >>> 67. extent (orth) >>> 68. from (arc) >>> 69. to (arc) >>> 70. inDegree (node) >>> 71. arity (tree) >>> 72. baseTypes (fsDecl) >>> 73. level (sense) >>> 74. order (tree) >>> 75. outDegree (iNode) >>> 76. outDegree (node) >>> 77. outDegree (root) >>> 78. reason (gap) >>> 79. type (orth) >>> 80. when (docDate) >>> 81. split (att.lexicographic) >>> 82. code (socecStatus) >>> 83. code (occupation) >>> 84. decls (att.declaring) >>> 85. cRef (term) >>> 86. from (app) >>> 87. scheme (catRef) >>> 88. scheme (occupation) >>> 89. scheme (classCode) >>> 90. scheme (socecStatus) >>> 91. scheme (keywords) >>> 92. to (app) >>> 93. baseForm (m) >>> 94. new (handShift) >>> 95. passive (relation) >>> 96. since (when) >>> 97. type (fsdLink) >>> 98. type (biblScope) >>> 99. type (listForest) >>> 100. type (forest) >>> 101. hand (gap) >>> 102. given (certainty) >>> 103. locus (certainty) >>> 104. type (rs) >>> 105. source (normalization) >>> 106. level (title) >>> 107. degree (certainty) >>> 108. status (correction) >>> 109. degree (precision) >>> 110. spanTo (att.spanning) >>> 111. to (att.datable.w3c) >>> 112. to-iso (att.datable.iso) >>> 113. force (pc) >>> 114. reason (surplus) >>> 115. type (stage) >>> 116. type (oRef) >>> 117. type (oVar) >>> 118. method (correction) >>> 119. method (normalization) >>> 120. name (fDecl) >>> 121. evidence (att.editLike) >>> 122. rows (table) >>> 123. org (vMerge) >>> 124. who (att.ascribed) >>> 125. locus (respons) >>> 126. from-custom (att.datable.custom) >>> 127. from (att.datable.w3c) >>> 128. from-iso (att.datable.iso) >>> 129. type (xr) >>> 130. type (iType) >>> 131. type (num) >>> 132. type (att.entryLike) >>> 133. type (att.interpLike) >>> 134. unit (refState) >>> 135. notation (pron) >>> 136. break (att.breaking) >>> 137. iterated (kinesic) >>> 138. iterated (vocal) >>> 139. optional (fDecl) >>> 140. default (att.declarable) >>> 141. location (variantEncoding) >>> 142. anchored (note) >>> 143. full (att.personal) >>> 144. type (metDecl) >>> 145. extent (pron) >>> 146. discrete (sound) >>> 147. scope (join) >>> 148. gradual (writing) >>> 149. sample (att.divLike) >>> 150. type (classSpec) >>> 151. pre (pc) >>> 152. type (dimensions) >>> 153. method (variantEncoding) >>> 154. type (macroSpec) >>> 155. reason (supplied) >>> 156. to (locus) >>> 157. rows (att.tableDecoration) >>> 158. writtenLines (layout) >>> 159. ruledLines (layout) >>> 160. location (att.lexicographic) >>> 161. hands (handDesc) >>> 162. material (supportDesc) >>> 163. notation (formula) >>> 164. unit (att.dimensions) >>> 165. ns (attDef) >>> 166. ns (elementSpec) >>> 167. domains (att.pointing.group) >>> 168. part (att.segLike) >>> 169. source (writing) >>> 170. ref (g) >>> 171. scribeRef (att.handFeatures) >>> 172. scriptRef (att.handFeatures) >>> 173. copyOf (att.global.linking) >>> 174. sameAs (att.global.linking) >>> 175. exclude (att.global.linking) >>> 176. targetEnd (note) >>> 177. next (att.global.linking) >>> 178. target (relatedItem) >>> 179. unit (milestone) >>> 180. label (rhyme) >>> 181. lemma (w) >>> 182. children (iNode) >>> 183. children (root) >>> 184. name (f) >>> 185. unit (pc) >>> 186. value (leaf) >>> 187. type (node) >>> 188. key (att.canonical) >>> 189. follow (iNode) >>> 190. follow (leaf) >>> 191. parent (leaf) >>> 192. parent (iNode) >>> 193. value (node) >>> 194. value (triangle) >>> 195. value (eLeaf) >>> 196. value (eTree) >>> 197. value (iNode) >>> 198. value (root) >>> 199. quantity (att.measurement) >>> 200. role (att.tableDecoration) >>> 201. scheme (att) >>> 202. select (att.global.linking) >>> 203. xml:space (att.global) >>> 204. hand (att.textCritical) >>> 205. subtype (att.typed) >>> 206. prefix (schemaSpec) >>> 207. prefix (elementSpec) >>> 208. type (purpose) >>> 209. role (org) >>> 210. role (person) >>> 211. matchPattern (cRefPattern) >>> 212. replacementPattern (cRefPattern) >>> 213. age (person) >>> 214. start (schemaSpec) >>> 215. form (quotation) >>> 216. time (distinct) >>> 217. social (distinct) >>> 218. space (distinct) >>> 219. type (constitution) >>> 220. scope (att.handFeatures) >>> 221. age (personGrp) >>> 222. usage (language) >>> 223. ident (valItem) >>> 224. from (span) >>> 225. value (metSym) >>> 226. versionDate (att.translatable) >>> 227. target (att.pointing) >>> 228. where (move) >>> 229. notBefore (att.datable.w3c) >>> 230. notBefore-custom (att.datable.custom) >>> 231. notBefore-iso (att.datable.iso) >>> 232. mode (classes) >>> 233. mode (att.combinable) >>> 234. mode (memberOf) >>> 235. to (span) >>> 236. to (biblScope) >>> 237. type (valList) >>> 238. degree (purpose) >>> 239. length (refState) >>> 240. render (tagUsage) >>> 241. targets (alt) >>> 242. targets (join) >>> 243. targets (link) >>> 244. type (teiHeader) >>> 245. notAfter (att.datable.w3c) >>> 246. notAfter-custom (att.datable.custom) >>> 247. notAfter-iso (att.datable.iso) >>> 248. version (TEI) >>> 249. mode (channel) >>> 250. result (join) >>> 251. new (shift) >>> 252. active (interaction) >>> 253. occurs (tagUsage) >>> 254. passive (interaction) >>> 255. interval (when) >>> 256. interval (timeline) >>> 257. usage (attDef) >>> 258. role (personGrp) >>> 259. type (titlePart) >>> 260. sex (personGrp) >>> 261. sex (person) >>> 262. size (personGrp) >>> 263. from (biblScope) >>> 264. type (distinct) >>> 265. type (measure) >>> 266. type (fs) >>> 267. unit (timeline) >>> 268. unit (when) >>> 269. version (unicodeName) >>> 270. type (divGen) >>> 271. part (ab) >>> 272. part (att.divLike) >>> 273. part (l) >>> 274. terminal (metSym) >>> 275. trunc (numeric) >>> 276. order (graph) >>> 277. size (graph) >>> 278. mode (alt) >>> 279. mode (altGrp) >>> 280. value (binary) >>> 281. status (availability) >>> 282. datum (geoDecl) >>> 283. value (numeric) >>> 284. name (relation) >>> 285. name (vLabel) >>> 286. indexName (index) >>> 287. stdDeviation (precision) >>> 288. absolute (when) >>> 289. max (numeric) >>> 290. scheme (constraintSpec) >>> 291. scheme (tag) >>> 292. scheme (gi) >>> 293. value (symbol) >>> 294. value (num) >>> 295. scheme (locusGrp) >>> 296. scheme (locus) >>> 297. name (namespace) >>> 298. type (recording) >>> 299. unit (att.measurement) >>> 300. value (att.lexicographic) >>> 301. scope (att.dimensions) >>> 302. evaluate (att.pointing) >>> 303. active (relation) >>> 304. to-custom (att.datable.custom) >>> 305. mutual (relation) >>> 306. dur-iso (att.duration.iso) >>> 307. instant (att.editLike) >>> 308. function (metamark) >>> 309. attachment (surface) >>> 310. cause (att.transcriptional) >>> 311. target (metamark) >>> 312. rotate (zone) >>> 313. target (redo) >>> 314. target (undo) >>> 315. except (moduleRef) >>> 316. include (moduleRef) >>> 317. datingMethod (att.datable.custom) >>> 318. datingPoint (att.datable.custom) >>> 319. key (moduleRef) >>> 320. url (moduleRef) >>> 321. mimeType (att.internetMedia) >>> 322. version (application) >>> 323. ident (application) >>> 324. confidence (att.ranging) >>> 325. level (langKnown) >>> 326. adj (node) >>> 327. adjFrom (node) >>> 328. adjTo (node) >>> 329. ana (att.global.analytic) >>> 330. group (att.damaged) >>> 331. cRef (gloss) >>> 332. cRef (ptr) >>> 333. cRef (ref) >>> 334. cert (att.responsibility) >>> 335. cert (certainty) >>> 336. precision (precision) >>> 337. precision (att.dimensions) >>> 338. type (fw) >>> 339. cols (table) >>> 340. cols (att.tableDecoration) >>> 341. source (att.editLike) >>> 342. autoPrefix (content) >>> 343. corresp (att.global.linking) >>> 344. delim (refState) >>> 345. dim (space) >>> 346. docLang (schemaSpec) >>> 347. dur (att.duration.w3c) >>> 348. ed (att.sourced) >>> 349. gi (tagUsage) >>> 350. eol (hyphenation) >>> 351. enjamb (att.enjamb) >>> 352. facs (att.global.facs) >>> 353. fVal (f) >>> 354. feats (fs) >>> 355. lang (code) >>> 356. atMost (att.ranging) >>> 357. atLeast (att.ranging) >>> 358. lrx (att.coordinated) >>> 359. ulx (att.coordinated) >>> 360. lry (att.coordinated) >>> 361. uly (att.coordinated) >>> 362. xml:id (att.global) >>> 363. ident (language) >>> 364. scheme (rendition) >>> 365. status (att.transcriptional) >>> 366. where (event) >>> 367. start (att.timed) >>> 368. end (att.timed) >>> 369. type (tag) >>> 370. defective (att.msExcerpt) >>> 371. generate (classSpec) >>> 372. inst (att.interpLike) >>> 373. xml:lang (att.global) >>> 374. loc (app) >>> 375. mainLang (textLang) >>> 376. maxOccurs (datatype) >>> 377. type (q) >>> 378. direct (said) >>> 379. aloud (said) >>> 380. met (att.metrical) >>> 381. real (att.metrical) >>> 382. minOccurs (datatype) >>> 383. name (equiv) >>> 384. ns (schemaSpec) >>> 385. n (att.global) >>> 386. opt (att.lexicographic) >>> 387. ord (iNode) >>> 388. ord (root) >>> 389. ord (tree) >>> 390. sort (att.personal) >>> 391. org (attList) >>> 392. org (vColl) >>> 393. org (att.divLike) >>> 394. orig (att.lexicographic) >>> 395. otherLangs (textLang) >>> 396. perf (move) >>> 397. perf (tech) >>> 398. target (specGrpRef) >>> 399. parts (nym) >>> 400. change (att.global.change) >>> 401. target (change) >>> 402. prev (att.global.linking) >>> 403. lemmaRef (w) >>> 404. marks (quotation) >>> 405. ref (att.canonical) >>> 406. nymRef (att.naming) >>> 407. filter (equiv) >>> 408. pattern (metDecl) >>> 409. resp (respons) >>> 410. resp (att.responsibility) >>> 411. resp (space) >>> 412. rhyme (att.metrical) >>> 413. seq (att.transcriptional) >>> 414. hand (att.transcriptional) >>> 415. prefix (moduleRef) >>> 416. key (memberOf) >>> 417. quantity (att.dimensions) >>> 418. value (age) >>> 419. target (fsdLink) >>> 420. period (att.datable) >>> 421. tag (langKnown) >>> 422. tags (langKnowledge) >>> 423. max (memberOf) >>> 424. min (memberOf) >>> 425. synch (att.global.linking) >>> 426. targFunc (att.pointing.group) >>> 427. targetLang (schemaSpec) >>> 428. key (classRef) >>> 429. key (elementRef) >>> 430. key (macroRef) >>> 431. name (attRef) >>> 432. trans (u) >>> 433. uri (equiv) >>> 434. url (graphic) >>> 435. varSeq (att.textCritical) >>> 436. scope (rendition) >>> 437. max (att.ranging) >>> 438. min (att.ranging) >>> 439. withId (tagUsage) >>> 440. wit (att.witnessed) >>> 441. wit (att.rdgPart) >>> 442. wit (witDetail) >>> 443. status (att.docStatus) >>> 444. points (zone) >>> 445. start (att.coordinated) >>> 446. valid (egXML) >>> 447. ordered (listChange) >>> 448. role (att.naming) >>> 449. source (att.readFrom) >>> 450. flipping (surface) >>> >>> >>> ATTRIBUTE DEFINITIONS WHICH HAVE EXAMPLES AS OF >>> 2012-04-19T15:12:34.968-07:00 >>> >>> 1. place (att.placement) >>> 2. expand (att.lexicographic) >>> 3. extent (att.dimensions) >>> 4. calendar (att.datable) >>> 5. reason (unclear) >>> 6. target (att.scoping) >>> 7. xml:base (att.global) >>> 8. assertedValue (certainty) >>> 9. refLang (att.pointing) >>> 10. match (att.scoping) >>> 11. sortKey (att.sortable) >>> 12. atts (specDesc) >>> 13. key (specDesc) >>> 14. norm (att.lexicographic) >>> 15. rendition (att.global) >>> 16. rend (att.global) >>> 17. when-iso (att.datable.iso) >>> 18. when-custom (att.datable.custom) >>> 19. when (att.datable.w3c) >>> >>> -- >>> Martin Holmes >>> University of Victoria Humanities Computing and Media Centre >>> (mholmes at uvic.ca) >>> -- >>> tei-council mailing list >>> tei-council at lists.village.Virginia.EDU >>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council >>> >>> PLEASE NOTE: postings to this list are publicly archived >>> . >>> >> -- Martin Holmes mholmes at uvic.ca UVic Humanities Computing and Media Centre From sebastian.rahtz at oucs.ox.ac.uk Sat Apr 21 07:03:53 2012 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Sat, 21 Apr 2012 11:03:53 +0000 Subject: [tei-council] next release? Message-ID: <0F18A249-5480-42D9-BFF2-538AC7B9E1EB@oucs.ox.ac.uk> something we forgot to debate in Ann Arbor was a timetable for the next release, I think? i.e. what is the due date for everyone to complete their ticket work so that Sir Gabriel of B'odard can undertake his Quest. speaking for myself, if I don't do my assignments more or less immediately I will not get to them for ages, so I favour a short window (say, 3 weeks). Sebastian From bansp at o2.pl Sat Apr 21 12:17:51 2012 From: bansp at o2.pl (=?ISO-8859-2?Q?Piotr_Ba=F1ski?=) Date: Sat, 21 Apr 2012 18:17:51 +0200 Subject: [tei-council] Grouping traitlike, statelike, and eventlike elements - ID: 3060867 Message-ID: <4F92DDAF.4050900@o2.pl> May I ask the Council to have a look at a ticket that was set to pending and this is probably why it didn't make it onto Lou's list (and I wasn't nagged by SF even once about it): http://sourceforge.net/tracker/index.php?func=detail&aid=3060867&group_id=106328&atid=644065 I thought the implementation would be as quick as Lou's summary of what we decided in Paris, but things do not seem that easy (the schema becomes non-deterministic), unless we decide to split the not-so-easy-to-implement listState into listOrgState, listPersState, and listPlaceState (listPlaceStateLike? OhMyGoodness...). I summarised the way I see this in my recent comment on the ticket. If this reasoning is found correct, the practical question for the Council is: do I have green light to implement the three above-mentioned list elements? Or do we take a different route, for example the route proposed tentatively by Sebastian (let me stress that he wrote in a hurry from the airport and kept to the logic of the decision made in Paris): > I think I'd > > * make a class model.stateLike > * make trait a direct member of that > * make the other stateLike classes members of it too > * refer to stateLike in listState > > does that work? > which I think has the semantic problem of mixing three kinds of stateLike elements (and thus making it possible to talk about the climate of a person and the sex of a place). Thanks, P. From mholmes at uvic.ca Sat Apr 21 13:50:05 2012 From: mholmes at uvic.ca (Martin Holmes) Date: Sat, 21 Apr 2012 10:50:05 -0700 Subject: [tei-council] next release? In-Reply-To: <0F18A249-5480-42D9-BFF2-538AC7B9E1EB@oucs.ox.ac.uk> References: <0F18A249-5480-42D9-BFF2-538AC7B9E1EB@oucs.ox.ac.uk> Message-ID: <4F92F34D.2040103@uvic.ca> Three weeks will be a bit tough for me, and a couple of the tickets I have might turn out to have unpredicted side-effects (like the tei_ prefix). As long as we have the option to launch without the change if it proves difficult, we could go with three weeks. The attributes-without-examples problem is so large that we'll just have to hack away at it steadily. Cheers, Martin On 12-04-21 04:03 AM, Sebastian Rahtz wrote: > something we forgot to debate in Ann Arbor was a timetable > for the next release, I think? i.e. what is the due date for > everyone to complete their ticket work so that Sir Gabriel > of B'odard can undertake his Quest. > > speaking for myself, if I don't do my assignments > more or less immediately I will not get to them for ages, > so I favour a short window (say, 3 weeks). > > Sebastian From syeates at gmail.com Sat Apr 21 17:46:04 2012 From: syeates at gmail.com (stuart yeates) Date: Sun, 22 Apr 2012 09:46:04 +1200 Subject: [tei-council] Grouping traitlike, statelike, and eventlike elements - ID: 3060867 In-Reply-To: <4F92DDAF.4050900@o2.pl> References: <4F92DDAF.4050900@o2.pl> Message-ID: <4F932A9C.7070904@gmail.com> On 22/04/12 04:17, Piotr Ba?ski wrote: > May I ask the Council to have a look at a ticket that was set to pending > and this is probably why it didn't make it onto Lou's list (and I wasn't > nagged by SF even once about it): > > http://sourceforge.net/tracker/index.php?func=detail&aid=3060867&group_id=106328&atid=644065 > > I thought the implementation would be as quick as Lou's summary of what > we decided in Paris, but things do not seem that easy (the schema > becomes non-deterministic), unless we decide to split the > not-so-easy-to-implement listState into listOrgState, > listPersState, and listPlaceState (listPlaceStateLike? OhMyGoodness...). > > I summarised the way I see this in my recent comment on the ticket. If > this reasoning is found correct, the practical question for the Council > is: do I have green light to implement the three above-mentioned list > elements? > > Or do we take a different route, for example the route proposed > tentatively by Sebastian (let me stress that he wrote in a hurry from > the airport and kept to the logic of the decision made in Paris): > >> I think I'd >> >> * make a class model.stateLike >> * make trait a direct member of that >> * make the other stateLike classes members of it too >> * refer to stateLike in listState >> >> does that work? >> > > which I think has the semantic problem of mixing three kinds of > stateLike elements (and thus making it possible to talk about the > climate of a person and the sex of a place). Splitting these is the sane approach, I think. cheers stuart From mholmes at uvic.ca Sat Apr 21 19:58:48 2012 From: mholmes at uvic.ca (Martin Holmes) Date: Sat, 21 Apr 2012 16:58:48 -0700 Subject: [tei-council] Ignore my Jenkins for a while... Message-ID: <4F9349B8.7030709@uvic.ca> Hi all, Just writing to warn everybody that I'm working on the configuration of jobs on my Jenkins box, with limited success, so builds are failing for reasons which probably have nothing to do with you. Sebastian says his Jinks is stable, and it looks to be so, so please refer to his when you've committed changes: <http://bits.nsms.ox.ac.uk:8080/jenkins/> rather than mine, which is two butties short of a picnic at the moment: <http://teijenkins.hcmc.uvic.ca:8080/> I'm hoping that normal service will be resumed as soon as possible. Once it's working again, I'll be leaving it well alone, and working on another VM built from Ubuntu Precise. That should ultimately replace this one, and be the model from which you can build your own Jenkins machine should you wish to. Cheers, Martin From James.Cummings at oucs.ox.ac.uk Mon Apr 23 09:11:02 2012 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Mon, 23 Apr 2012 14:11:02 +0100 Subject: [tei-council] TEI-C Expenses for April Face to Face and Meals. Message-ID: <4F9554E6.4080308@oucs.ox.ac.uk> A reminder that TEI-C expense forms should be submitted within 10 days of the end of the meeting (which I count as by this coming weekend). I believe that the following meals were paid for by Kevin, Becky, or Paul and so cannot be claimed for by those present (thanks Kevin for the list): = Sunday evening = Lou Burnard, Piotr Banski, James Cummings, Kevin Hawkins = Monday lunch = everybody = Monday dinner = everybody = Tuesday lunch = everybody = Tuesday dinner = Lou Burnard, Martin Holmes, James Cummings, Sebastian Rahtz, Kevin Hawkins = Wednesday lunch = everybody except Martin Holmes Let me know if there are any mistakes there as I'll be submitting that to the treasurer. -James -- Dr James Cummings, InfoDev, Computing Services, University of Oxford From James.Cummings at oucs.ox.ac.uk Mon Apr 23 09:12:03 2012 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Mon, 23 Apr 2012 14:12:03 +0100 Subject: [tei-council] TEI-C Expenses for April Face to Face and Meals. In-Reply-To: <4F9554E6.4080308@oucs.ox.ac.uk> References: <4F9554E6.4080308@oucs.ox.ac.uk> Message-ID: <4F955523.6060405@oucs.ox.ac.uk> Oh, and the PDF form is available at: http://www.tei-c.org/Admin/TEI_travel_form.pdf Best, James On 23/04/12 14:11, James Cummings wrote: > > A reminder that TEI-C expense forms should be submitted within 10 > days of the end of the meeting (which I count as by this coming > weekend). > > I believe that the following meals were paid for by Kevin, Becky, > or Paul and so cannot be claimed for by those present (thanks > Kevin for the list): > > = Sunday evening = > Lou Burnard, Piotr Banski, James Cummings, Kevin Hawkins > > = Monday lunch = > everybody > > = Monday dinner = > everybody > > = Tuesday lunch = > everybody > > = Tuesday dinner = > Lou Burnard, Martin Holmes, James Cummings, Sebastian Rahtz, > Kevin Hawkins > > = Wednesday lunch = > everybody except Martin Holmes > > > Let me know if there are any mistakes there as I'll be submitting > that to the treasurer. > > -James > -- Dr James Cummings, InfoDev, Computing Services, University of Oxford From mholmes at uvic.ca Mon Apr 23 11:22:39 2012 From: mholmes at uvic.ca (Martin Holmes) Date: Mon, 23 Apr 2012 08:22:39 -0700 Subject: [tei-council] Attributes without examples In-Reply-To: <4F90AEBC.6000608@ultraslavonic.info> References: <4F908F22.4070908@uvic.ca> <4F90AD72.10605@uvic.ca> <4F90AEBC.6000608@ultraslavonic.info> Message-ID: <4F9573BF.1080302@uvic.ca> I've just tried to create a wiki page which has a table listing all these attributes, but I've been prevented from doing so by the sad little spam filter, which won't allow this: att.msExcerpt because it contains "sEx". I seem to remember having spent a frustrating time fighting with this stupidity some time ago. Does anyone remember how to get around this, or is it pointless to try? Cheers, Martin On 12-04-19 05:33 PM, Kevin Hawkins wrote: > Would you be able to output as a table with a third column for people to > sign up, either in MediaWiki or HTML syntax, for a page in the wiki? > > On 4/19/12 8:27 PM, Martin Holmes wrote: >> Below is another slightly shorter list. These are attributes which do >> not appear on any examples in the<elementSpec> or<classSpec> in which >> they're defined. Not that this doesn't mean there are no examples at all >> for them; there may be an example somewhere in the Guidelines text, or >> the attribute may be defined in a<classSpec> for an attribute class, >> and then show up in an example in an<elementSpec> for an element which >> belongs to that class. An example of the latter is @agent (att.damaged), >> which has no example in the att.damaged<classSpec>, but happens to show >> up in an example for the<damage> element. >> >> Nevertheless, I think it would be a good idea to try to provide examples >> for all these attributes, in the files which define them. >> >> ATTRIBUTES WHICH DO NOT SHOW UP ON ANY EXAMPLE IN THEIR elementSpec OR >> classSpec AS OF 2012-04-19T17:19:17.315-07:00 >> >> 1. absolute (when) >> 2. adj (node) >> 3. adjFrom (node) >> 4. adjTo (node) >> 5. age (personGrp) >> 6. agent (att.damaged) >> 7. agent (gap) >> 8. agent (unclear) >> 9. ana (att.global.analytic) >> 10. atLeast (att.ranging) >> 11. atMost (att.ranging) >> 12. attachment (surface) >> 13. autoPrefix (content) >> 14. baseTypes (fsDecl) >> 15. break (att.breaking) >> 16. cRef (gloss) >> 17. cRef (ptr) >> 18. cRef (ref) >> 19. cRef (term) >> 20. cause (att.textCritical) >> 21. cause (att.transcriptional) >> 22. cert (att.responsibility) >> 23. change (att.global.change) >> 24. class (msContents) >> 25. cols (att.tableDecoration) >> 26. confidence (att.ranging) >> 27. contemporary (seal) >> 28. copyOf (att.global.linking) >> 29. corresp (att.global.linking) >> 30. datingMethod (att.datable.custom) >> 31. datingPoint (att.datable.custom) >> 32. decls (att.declaring) >> 33. default (att.declarable) >> 34. defective (att.msExcerpt) >> 35. degree (att.damaged) >> 36. degree (node) >> 37. dim (space) >> 38. direct (said) >> 39. docLang (schemaSpec) >> 40. domains (att.pointing.group) >> 41. dur (att.duration.w3c) >> 42. dur-iso (att.duration.iso) >> 43. encoding (binaryObject) >> 44. end (att.timed) >> 45. enjamb (att.enjamb) >> 46. evaluate (att.pointing) >> 47. evidence (att.editLike) >> 48. except (moduleRef) >> 49. exclude (att.global.linking) >> 50. expand (att.lexicographic) >> 51. extent (orth) >> 52. fVal (f) >> 53. facs (att.global.facs) >> 54. feats (fs) >> 55. filter (equiv) >> 56. flipping (surface) >> 57. follow (leaf) >> 58. force (pc) >> 59. from (app) >> 60. from (att.datable.w3c) >> 61. from-custom (att.datable.custom) >> 62. from-iso (att.datable.iso) >> 63. full (att.personal) >> 64. function (att.segLike) >> 65. generate (classSpec) >> 66. gradual (writing) >> 67. group (att.damaged) >> 68. hand (att.damaged) >> 69. hand (att.textCritical) >> 70. hand (att.transcriptional) >> 71. hand (gap) >> 72. hand (unclear) >> 73. height (binaryObject) >> 74. height (graphic) >> 75. ident (att.identified) >> 76. inst (att.interpLike) >> 77. instant (att.editLike) >> 78. key (att.canonical) >> 79. key (classRef) >> 80. key (macroRef) >> 81. level (sense) >> 82. level (title) >> 83. loc (app) >> 84. location (att.lexicographic) >> 85. lrx (att.coordinated) >> 86. lry (att.coordinated) >> 87. match (att.scoping) >> 88. material (supportDesc) >> 89. max (att.ranging) >> 90. max (memberOf) >> 91. medium (att.handFeatures) >> 92. mergedIn (att.lexicographic) >> 93. met (att.metrical) >> 94. method (correction) >> 95. mimeType (att.internetMedia) >> 96. min (att.ranging) >> 97. min (memberOf) >> 98. mode (att.combinable) >> 99. mode (classes) >> 100. mode (memberOf) >> 101. module (att.identified) >> 102. new (handShift) >> 103. next (att.global.linking) >> 104. notAfter-custom (att.datable.custom) >> 105. notAfter-iso (att.datable.iso) >> 106. notBefore-custom (att.datable.custom) >> 107. notBefore-iso (att.datable.iso) >> 108. notation (pron) >> 109. ns (attDef) >> 110. ns (elementSpec) >> 111. ns (schemaSpec) >> 112. nymRef (att.naming) >> 113. opt (att.lexicographic) >> 114. optional (fDecl) >> 115. ord (iNode) >> 116. ord (root) >> 117. org (att.divLike) >> 118. org (attList) >> 119. orig (att.lexicographic) >> 120. part (ab) >> 121. part (att.divLike) >> 122. part (att.segLike) >> 123. parts (nym) >> 124. perf (tech) >> 125. period (att.datable) >> 126. pre (pc) >> 127. precision (att.dimensions) >> 128. predeclare (att.identified) >> 129. prefix (elementSpec) >> 130. prefix (moduleRef) >> 131. prev (att.global.linking) >> 132. quantity (att.dimensions) >> 133. real (att.metrical) >> 134. ref (att.canonical) >> 135. refLang (att.pointing) >> 136. resp (att.responsibility) >> 137. resp (space) >> 138. rhyme (att.metrical) >> 139. role (att.naming) >> 140. role (att.tableDecoration) >> 141. role (org) >> 142. rotate (zone) >> 143. rows (att.tableDecoration) >> 144. sameAs (att.global.linking) >> 145. sample (att.divLike) >> 146. scale (binaryObject) >> 147. scale (graphic) >> 148. scheme (catRef) >> 149. scheme (locus) >> 150. scheme (locusGrp) >> 151. scheme (tag) >> 152. scope (att.dimensions) >> 153. scope (att.handFeatures) >> 154. scribe (att.handFeatures) >> 155. scribeRef (att.handFeatures) >> 156. script (att.handFeatures) >> 157. scriptRef (att.handFeatures) >> 158. select (att.global.linking) >> 159. seq (att.transcriptional) >> 160. social (distinct) >> 161. sort (att.personal) >> 162. source (att.editLike) >> 163. source (att.readFrom) >> 164. source (writing) >> 165. space (distinct) >> 166. spanTo (att.spanning) >> 167. split (att.lexicographic) >> 168. start (att.coordinated) >> 169. start (att.timed) >> 170. status (att.identified) >> 171. status (att.transcriptional) >> 172. status (correction) >> 173. stdDeviation (precision) >> 174. subtype (att.typed) >> 175. synch (att.global.linking) >> 176. targFunc (att.pointing.group) >> 177. target (change) >> 178. target (relatedItem) >> 179. targetEnd (note) >> 180. targetLang (schemaSpec) >> 181. targets (alt) >> 182. targets (join) >> 183. targets (link) >> 184. time (distinct) >> 185. to (app) >> 186. to (att.datable.w3c) >> 187. to-custom (att.datable.custom) >> 188. to-iso (att.datable.iso) >> 189. type (abbr) >> 190. type (att.entryLike) >> 191. type (att.interpLike) >> 192. type (att.textCritical) >> 193. type (att.typed) >> 194. type (form) >> 195. type (q) >> 196. type (sound) >> 197. ulx (att.coordinated) >> 198. uly (att.coordinated) >> 199. unit (att.dimensions) >> 200. unit (pc) >> 201. unit (when) >> 202. url (moduleRef) >> 203. value (att.lexicographic) >> 204. value (eTree) >> 205. value (iNode) >> 206. value (leaf) >> 207. value (node) >> 208. value (root) >> 209. value (triangle) >> 210. varSeq (att.textCritical) >> 211. version (unicodeName) >> 212. versionDate (att.translatable) >> 213. when (docDate) >> 214. where (event) >> 215. who (att.ascribed) >> 216. width (binaryObject) >> 217. width (graphic) >> 218. wit (att.rdgPart) >> 219. wit (att.witnessed) >> 220. xml:base (att.global) >> 221. xml:id (att.global) >> 222. xml:lang (att.global) >> 223. xml:space (att.global) >> >> Cheers, >> Martin >> >> On 12-04-19 03:18 PM, Martin Holmes wrote: >>> Following on from our discussion of examples for attributes, a >>> quick-and-dirty XSLT seems to show that there are only 19 attributes >>> with their own examples, and 450 without. This is not to say that those >>> without are unexemplified, because the example code for their parent >>> elements in the elementSpec may show examples of them; I'll refine the >>> XSLT and make that apparent. >>> >>> Here's the list: >>> >>> ATTRIBUTE DEFINITIONS LACKING EXAMPLES AS OF 2012-04-19T15:12:34.968-07:00 >>> >>> 1. status (att.identified) >>> 2. type (interaction) >>> 3. value (sex) >>> 4. scale (graphic) >>> 5. scale (binaryObject) >>> 6. weights (alt) >>> 7. hand (att.damaged) >>> 8. agent (gap) >>> 9. predeclare (att.identified) >>> 10. degree (att.damaged) >>> 11. module (att.identified) >>> 12. ident (att.identified) >>> 13. height (graphic) >>> 14. height (binaryObject) >>> 15. width (graphic) >>> 16. width (binaryObject) >>> 17. encoding (binaryObject) >>> 18. version (teiCorpus) >>> 19. hand (unclear) >>> 20. agent (unclear) >>> 21. feature (shift) >>> 22. type (preparedness) >>> 23. type (abbr) >>> 24. commodity (att.measurement) >>> 25. agent (att.damaged) >>> 26. type (derivation) >>> 27. type (domain) >>> 28. type (factuality) >>> 29. type (idno) >>> 30. type (relation) >>> 31. type (sound) >>> 32. type (tech) >>> 33. type (castItem) >>> 34. type (att.typed) >>> 35. type (move) >>> 36. script (att.handFeatures) >>> 37. class (msItemStruct) >>> 38. class (msItem) >>> 39. class (msContents) >>> 40. type (form) >>> 41. cause (att.textCritical) >>> 42. type (gram) >>> 43. type (lbl) >>> 44. type (att.textCritical) >>> 45. type (title) >>> 46. type (titlePage) >>> 47. type (usg) >>> 48. type (app) >>> 49. columns (layout) >>> 50. valueDatcat (att.datcat) >>> 51. datcat (att.datcat) >>> 52. contemporary (seal) >>> 53. contemporary (binding) >>> 54. from (locus) >>> 55. type (list) >>> 56. result (joinGrp) >>> 57. medium (att.handFeatures) >>> 58. type (graph) >>> 59. type (witDetail) >>> 60. origin (timeline) >>> 61. function (att.segLike) >>> 62. form (objectDesc) >>> 63. mergedIn (att.lexicographic) >>> 64. type (fsDecl) >>> 65. scribe (att.handFeatures) >>> 66. degree (node) >>> 67. extent (orth) >>> 68. from (arc) >>> 69. to (arc) >>> 70. inDegree (node) >>> 71. arity (tree) >>> 72. baseTypes (fsDecl) >>> 73. level (sense) >>> 74. order (tree) >>> 75. outDegree (iNode) >>> 76. outDegree (node) >>> 77. outDegree (root) >>> 78. reason (gap) >>> 79. type (orth) >>> 80. when (docDate) >>> 81. split (att.lexicographic) >>> 82. code (socecStatus) >>> 83. code (occupation) >>> 84. decls (att.declaring) >>> 85. cRef (term) >>> 86. from (app) >>> 87. scheme (catRef) >>> 88. scheme (occupation) >>> 89. scheme (classCode) >>> 90. scheme (socecStatus) >>> 91. scheme (keywords) >>> 92. to (app) >>> 93. baseForm (m) >>> 94. new (handShift) >>> 95. passive (relation) >>> 96. since (when) >>> 97. type (fsdLink) >>> 98. type (biblScope) >>> 99. type (listForest) >>> 100. type (forest) >>> 101. hand (gap) >>> 102. given (certainty) >>> 103. locus (certainty) >>> 104. type (rs) >>> 105. source (normalization) >>> 106. level (title) >>> 107. degree (certainty) >>> 108. status (correction) >>> 109. degree (precision) >>> 110. spanTo (att.spanning) >>> 111. to (att.datable.w3c) >>> 112. to-iso (att.datable.iso) >>> 113. force (pc) >>> 114. reason (surplus) >>> 115. type (stage) >>> 116. type (oRef) >>> 117. type (oVar) >>> 118. method (correction) >>> 119. method (normalization) >>> 120. name (fDecl) >>> 121. evidence (att.editLike) >>> 122. rows (table) >>> 123. org (vMerge) >>> 124. who (att.ascribed) >>> 125. locus (respons) >>> 126. from-custom (att.datable.custom) >>> 127. from (att.datable.w3c) >>> 128. from-iso (att.datable.iso) >>> 129. type (xr) >>> 130. type (iType) >>> 131. type (num) >>> 132. type (att.entryLike) >>> 133. type (att.interpLike) >>> 134. unit (refState) >>> 135. notation (pron) >>> 136. break (att.breaking) >>> 137. iterated (kinesic) >>> 138. iterated (vocal) >>> 139. optional (fDecl) >>> 140. default (att.declarable) >>> 141. location (variantEncoding) >>> 142. anchored (note) >>> 143. full (att.personal) >>> 144. type (metDecl) >>> 145. extent (pron) >>> 146. discrete (sound) >>> 147. scope (join) >>> 148. gradual (writing) >>> 149. sample (att.divLike) >>> 150. type (classSpec) >>> 151. pre (pc) >>> 152. type (dimensions) >>> 153. method (variantEncoding) >>> 154. type (macroSpec) >>> 155. reason (supplied) >>> 156. to (locus) >>> 157. rows (att.tableDecoration) >>> 158. writtenLines (layout) >>> 159. ruledLines (layout) >>> 160. location (att.lexicographic) >>> 161. hands (handDesc) >>> 162. material (supportDesc) >>> 163. notation (formula) >>> 164. unit (att.dimensions) >>> 165. ns (attDef) >>> 166. ns (elementSpec) >>> 167. domains (att.pointing.group) >>> 168. part (att.segLike) >>> 169. source (writing) >>> 170. ref (g) >>> 171. scribeRef (att.handFeatures) >>> 172. scriptRef (att.handFeatures) >>> 173. copyOf (att.global.linking) >>> 174. sameAs (att.global.linking) >>> 175. exclude (att.global.linking) >>> 176. targetEnd (note) >>> 177. next (att.global.linking) >>> 178. target (relatedItem) >>> 179. unit (milestone) >>> 180. label (rhyme) >>> 181. lemma (w) >>> 182. children (iNode) >>> 183. children (root) >>> 184. name (f) >>> 185. unit (pc) >>> 186. value (leaf) >>> 187. type (node) >>> 188. key (att.canonical) >>> 189. follow (iNode) >>> 190. follow (leaf) >>> 191. parent (leaf) >>> 192. parent (iNode) >>> 193. value (node) >>> 194. value (triangle) >>> 195. value (eLeaf) >>> 196. value (eTree) >>> 197. value (iNode) >>> 198. value (root) >>> 199. quantity (att.measurement) >>> 200. role (att.tableDecoration) >>> 201. scheme (att) >>> 202. select (att.global.linking) >>> 203. xml:space (att.global) >>> 204. hand (att.textCritical) >>> 205. subtype (att.typed) >>> 206. prefix (schemaSpec) >>> 207. prefix (elementSpec) >>> 208. type (purpose) >>> 209. role (org) >>> 210. role (person) >>> 211. matchPattern (cRefPattern) >>> 212. replacementPattern (cRefPattern) >>> 213. age (person) >>> 214. start (schemaSpec) >>> 215. form (quotation) >>> 216. time (distinct) >>> 217. social (distinct) >>> 218. space (distinct) >>> 219. type (constitution) >>> 220. scope (att.handFeatures) >>> 221. age (personGrp) >>> 222. usage (language) >>> 223. ident (valItem) >>> 224. from (span) >>> 225. value (metSym) >>> 226. versionDate (att.translatable) >>> 227. target (att.pointing) >>> 228. where (move) >>> 229. notBefore (att.datable.w3c) >>> 230. notBefore-custom (att.datable.custom) >>> 231. notBefore-iso (att.datable.iso) >>> 232. mode (classes) >>> 233. mode (att.combinable) >>> 234. mode (memberOf) >>> 235. to (span) >>> 236. to (biblScope) >>> 237. type (valList) >>> 238. degree (purpose) >>> 239. length (refState) >>> 240. render (tagUsage) >>> 241. targets (alt) >>> 242. targets (join) >>> 243. targets (link) >>> 244. type (teiHeader) >>> 245. notAfter (att.datable.w3c) >>> 246. notAfter-custom (att.datable.custom) >>> 247. notAfter-iso (att.datable.iso) >>> 248. version (TEI) >>> 249. mode (channel) >>> 250. result (join) >>> 251. new (shift) >>> 252. active (interaction) >>> 253. occurs (tagUsage) >>> 254. passive (interaction) >>> 255. interval (when) >>> 256. interval (timeline) >>> 257. usage (attDef) >>> 258. role (personGrp) >>> 259. type (titlePart) >>> 260. sex (personGrp) >>> 261. sex (person) >>> 262. size (personGrp) >>> 263. from (biblScope) >>> 264. type (distinct) >>> 265. type (measure) >>> 266. type (fs) >>> 267. unit (timeline) >>> 268. unit (when) >>> 269. version (unicodeName) >>> 270. type (divGen) >>> 271. part (ab) >>> 272. part (att.divLike) >>> 273. part (l) >>> 274. terminal (metSym) >>> 275. trunc (numeric) >>> 276. order (graph) >>> 277. size (graph) >>> 278. mode (alt) >>> 279. mode (altGrp) >>> 280. value (binary) >>> 281. status (availability) >>> 282. datum (geoDecl) >>> 283. value (numeric) >>> 284. name (relation) >>> 285. name (vLabel) >>> 286. indexName (index) >>> 287. stdDeviation (precision) >>> 288. absolute (when) >>> 289. max (numeric) >>> 290. scheme (constraintSpec) >>> 291. scheme (tag) >>> 292. scheme (gi) >>> 293. value (symbol) >>> 294. value (num) >>> 295. scheme (locusGrp) >>> 296. scheme (locus) >>> 297. name (namespace) >>> 298. type (recording) >>> 299. unit (att.measurement) >>> 300. value (att.lexicographic) >>> 301. scope (att.dimensions) >>> 302. evaluate (att.pointing) >>> 303. active (relation) >>> 304. to-custom (att.datable.custom) >>> 305. mutual (relation) >>> 306. dur-iso (att.duration.iso) >>> 307. instant (att.editLike) >>> 308. function (metamark) >>> 309. attachment (surface) >>> 310. cause (att.transcriptional) >>> 311. target (metamark) >>> 312. rotate (zone) >>> 313. target (redo) >>> 314. target (undo) >>> 315. except (moduleRef) >>> 316. include (moduleRef) >>> 317. datingMethod (att.datable.custom) >>> 318. datingPoint (att.datable.custom) >>> 319. key (moduleRef) >>> 320. url (moduleRef) >>> 321. mimeType (att.internetMedia) >>> 322. version (application) >>> 323. ident (application) >>> 324. confidence (att.ranging) >>> 325. level (langKnown) >>> 326. adj (node) >>> 327. adjFrom (node) >>> 328. adjTo (node) >>> 329. ana (att.global.analytic) >>> 330. group (att.damaged) >>> 331. cRef (gloss) >>> 332. cRef (ptr) >>> 333. cRef (ref) >>> 334. cert (att.responsibility) >>> 335. cert (certainty) >>> 336. precision (precision) >>> 337. precision (att.dimensions) >>> 338. type (fw) >>> 339. cols (table) >>> 340. cols (att.tableDecoration) >>> 341. source (att.editLike) >>> 342. autoPrefix (content) >>> 343. corresp (att.global.linking) >>> 344. delim (refState) >>> 345. dim (space) >>> 346. docLang (schemaSpec) >>> 347. dur (att.duration.w3c) >>> 348. ed (att.sourced) >>> 349. gi (tagUsage) >>> 350. eol (hyphenation) >>> 351. enjamb (att.enjamb) >>> 352. facs (att.global.facs) >>> 353. fVal (f) >>> 354. feats (fs) >>> 355. lang (code) >>> 356. atMost (att.ranging) >>> 357. atLeast (att.ranging) >>> 358. lrx (att.coordinated) >>> 359. ulx (att.coordinated) >>> 360. lry (att.coordinated) >>> 361. uly (att.coordinated) >>> 362. xml:id (att.global) >>> 363. ident (language) >>> 364. scheme (rendition) >>> 365. status (att.transcriptional) >>> 366. where (event) >>> 367. start (att.timed) >>> 368. end (att.timed) >>> 369. type (tag) >>> 370. defective (att.msExcerpt) >>> 371. generate (classSpec) >>> 372. inst (att.interpLike) >>> 373. xml:lang (att.global) >>> 374. loc (app) >>> 375. mainLang (textLang) >>> 376. maxOccurs (datatype) >>> 377. type (q) >>> 378. direct (said) >>> 379. aloud (said) >>> 380. met (att.metrical) >>> 381. real (att.metrical) >>> 382. minOccurs (datatype) >>> 383. name (equiv) >>> 384. ns (schemaSpec) >>> 385. n (att.global) >>> 386. opt (att.lexicographic) >>> 387. ord (iNode) >>> 388. ord (root) >>> 389. ord (tree) >>> 390. sort (att.personal) >>> 391. org (attList) >>> 392. org (vColl) >>> 393. org (att.divLike) >>> 394. orig (att.lexicographic) >>> 395. otherLangs (textLang) >>> 396. perf (move) >>> 397. perf (tech) >>> 398. target (specGrpRef) >>> 399. parts (nym) >>> 400. change (att.global.change) >>> 401. target (change) >>> 402. prev (att.global.linking) >>> 403. lemmaRef (w) >>> 404. marks (quotation) >>> 405. ref (att.canonical) >>> 406. nymRef (att.naming) >>> 407. filter (equiv) >>> 408. pattern (metDecl) >>> 409. resp (respons) >>> 410. resp (att.responsibility) >>> 411. resp (space) >>> 412. rhyme (att.metrical) >>> 413. seq (att.transcriptional) >>> 414. hand (att.transcriptional) >>> 415. prefix (moduleRef) >>> 416. key (memberOf) >>> 417. quantity (att.dimensions) >>> 418. value (age) >>> 419. target (fsdLink) >>> 420. period (att.datable) >>> 421. tag (langKnown) >>> 422. tags (langKnowledge) >>> 423. max (memberOf) >>> 424. min (memberOf) >>> 425. synch (att.global.linking) >>> 426. targFunc (att.pointing.group) >>> 427. targetLang (schemaSpec) >>> 428. key (classRef) >>> 429. key (elementRef) >>> 430. key (macroRef) >>> 431. name (attRef) >>> 432. trans (u) >>> 433. uri (equiv) >>> 434. url (graphic) >>> 435. varSeq (att.textCritical) >>> 436. scope (rendition) >>> 437. max (att.ranging) >>> 438. min (att.ranging) >>> 439. withId (tagUsage) >>> 440. wit (att.witnessed) >>> 441. wit (att.rdgPart) >>> 442. wit (witDetail) >>> 443. status (att.docStatus) >>> 444. points (zone) >>> 445. start (att.coordinated) >>> 446. valid (egXML) >>> 447. ordered (listChange) >>> 448. role (att.naming) >>> 449. source (att.readFrom) >>> 450. flipping (surface) >>> >>> >>> ATTRIBUTE DEFINITIONS WHICH HAVE EXAMPLES AS OF >>> 2012-04-19T15:12:34.968-07:00 >>> >>> 1. place (att.placement) >>> 2. expand (att.lexicographic) >>> 3. extent (att.dimensions) >>> 4. calendar (att.datable) >>> 5. reason (unclear) >>> 6. target (att.scoping) >>> 7. xml:base (att.global) >>> 8. assertedValue (certainty) >>> 9. refLang (att.pointing) >>> 10. match (att.scoping) >>> 11. sortKey (att.sortable) >>> 12. atts (specDesc) >>> 13. key (specDesc) >>> 14. norm (att.lexicographic) >>> 15. rendition (att.global) >>> 16. rend (att.global) >>> 17. when-iso (att.datable.iso) >>> 18. when-custom (att.datable.custom) >>> 19. when (att.datable.w3c) >>> >>> -- >>> Martin Holmes >>> University of Victoria Humanities Computing and Media Centre >>> (mholmes at uvic.ca) >>> -- >>> tei-council mailing list >>> tei-council at lists.village.Virginia.EDU >>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council >>> >>> PLEASE NOTE: postings to this list are publicly archived >>> . >>> >> > . > -- Martin Holmes University of Victoria Humanities Computing and Media Centre (mholmes at uvic.ca) From James.Cummings at oucs.ox.ac.uk Mon Apr 23 11:47:44 2012 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Mon, 23 Apr 2012 16:47:44 +0100 Subject: [tei-council] next release? In-Reply-To: <4F92F34D.2040103@uvic.ca> References: <0F18A249-5480-42D9-BFF2-538AC7B9E1EB@oucs.ox.ac.uk> <4F92F34D.2040103@uvic.ca> Message-ID: <4F9579A0.8010002@oucs.ox.ac.uk> How about we set a notional target release date of 25 May? (This is about 5 weeks from now.) If we assume that we want most things completed by the end of Sunday 20th, to allow time for proofreading and error spotting. Does that sounds reasonable to most people? Gaby: Most importantly, does the proposed Release Technician like these dates? -James On 21/04/12 18:50, Martin Holmes wrote: > Three weeks will be a bit tough for me, and a couple of the tickets I > have might turn out to have unpredicted side-effects (like the tei_ > prefix). As long as we have the option to launch without the change if > it proves difficult, we could go with three weeks. > > The attributes-without-examples problem is so large that we'll just have > to hack away at it steadily. > > Cheers, > Martin > > On 12-04-21 04:03 AM, Sebastian Rahtz wrote: >> something we forgot to debate in Ann Arbor was a timetable >> for the next release, I think? i.e. what is the due date for >> everyone to complete their ticket work so that Sir Gabriel >> of B'odard can undertake his Quest. >> >> speaking for myself, if I don't do my assignments >> more or less immediately I will not get to them for ages, >> so I favour a short window (say, 3 weeks). >> >> Sebastian -- Dr James Cummings, InfoDev, Computing Services, University of Oxford From James.Cummings at oucs.ox.ac.uk Mon Apr 23 11:57:55 2012 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Mon, 23 Apr 2012 16:57:55 +0100 Subject: [tei-council] Attributes without examples In-Reply-To: <4F9573BF.1080302@uvic.ca> References: <4F908F22.4070908@uvic.ca> <4F90AD72.10605@uvic.ca> <4F90AEBC.6000608@ultraslavonic.info> <4F9573BF.1080302@uvic.ca> Message-ID: <4F957C03.8090008@oucs.ox.ac.uk> Martin, It is simple but intentionally not documented. Interrupt the spam word with an element. Specifically use <nowiki/> so att.ms<nowiki/>Excerpt will allow you to get around the spam filter. Just don't advertise via<nowiki/>gra too much. -James On 23/04/12 16:22, Martin Holmes wrote: > I've just tried to create a wiki page which has a table listing all > these attributes, but I've been prevented from doing so by the sad > little spam filter, which won't allow this: > > att.msExcerpt > > because it contains "sEx". > > I seem to remember having spent a frustrating time fighting with this > stupidity some time ago. Does anyone remember how to get around this, or > is it pointless to try? > > Cheers, > Martin > > On 12-04-19 05:33 PM, Kevin Hawkins wrote: >> Would you be able to output as a table with a third column for people to >> sign up, either in MediaWiki or HTML syntax, for a page in the wiki? >> >> On 4/19/12 8:27 PM, Martin Holmes wrote: >>> Below is another slightly shorter list. These are attributes which do >>> not appear on any examples in the<elementSpec> or<classSpec> in which >>> they're defined. Not that this doesn't mean there are no examples at all >>> for them; there may be an example somewhere in the Guidelines text, or >>> the attribute may be defined in a<classSpec> for an attribute class, >>> and then show up in an example in an<elementSpec> for an element which >>> belongs to that class. An example of the latter is @agent (att.damaged), >>> which has no example in the att.damaged<classSpec>, but happens to show >>> up in an example for the<damage> element. >>> >>> Nevertheless, I think it would be a good idea to try to provide examples >>> for all these attributes, in the files which define them. >>> >>> ATTRIBUTES WHICH DO NOT SHOW UP ON ANY EXAMPLE IN THEIR elementSpec OR >>> classSpec AS OF 2012-04-19T17:19:17.315-07:00 >>> >>> 1. absolute (when) >>> 2. adj (node) >>> 3. adjFrom (node) >>> 4. adjTo (node) >>> 5. age (personGrp) >>> 6. agent (att.damaged) >>> 7. agent (gap) >>> 8. agent (unclear) >>> 9. ana (att.global.analytic) >>> 10. atLeast (att.ranging) >>> 11. atMost (att.ranging) >>> 12. attachment (surface) >>> 13. autoPrefix (content) >>> 14. baseTypes (fsDecl) >>> 15. break (att.breaking) >>> 16. cRef (gloss) >>> 17. cRef (ptr) >>> 18. cRef (ref) >>> 19. cRef (term) >>> 20. cause (att.textCritical) >>> 21. cause (att.transcriptional) >>> 22. cert (att.responsibility) >>> 23. change (att.global.change) >>> 24. class (msContents) >>> 25. cols (att.tableDecoration) >>> 26. confidence (att.ranging) >>> 27. contemporary (seal) >>> 28. copyOf (att.global.linking) >>> 29. corresp (att.global.linking) >>> 30. datingMethod (att.datable.custom) >>> 31. datingPoint (att.datable.custom) >>> 32. decls (att.declaring) >>> 33. default (att.declarable) >>> 34. defective (att.msExcerpt) >>> 35. degree (att.damaged) >>> 36. degree (node) >>> 37. dim (space) >>> 38. direct (said) >>> 39. docLang (schemaSpec) >>> 40. domains (att.pointing.group) >>> 41. dur (att.duration.w3c) >>> 42. dur-iso (att.duration.iso) >>> 43. encoding (binaryObject) >>> 44. end (att.timed) >>> 45. enjamb (att.enjamb) >>> 46. evaluate (att.pointing) >>> 47. evidence (att.editLike) >>> 48. except (moduleRef) >>> 49. exclude (att.global.linking) >>> 50. expand (att.lexicographic) >>> 51. extent (orth) >>> 52. fVal (f) >>> 53. facs (att.global.facs) >>> 54. feats (fs) >>> 55. filter (equiv) >>> 56. flipping (surface) >>> 57. follow (leaf) >>> 58. force (pc) >>> 59. from (app) >>> 60. from (att.datable.w3c) >>> 61. from-custom (att.datable.custom) >>> 62. from-iso (att.datable.iso) >>> 63. full (att.personal) >>> 64. function (att.segLike) >>> 65. generate (classSpec) >>> 66. gradual (writing) >>> 67. group (att.damaged) >>> 68. hand (att.damaged) >>> 69. hand (att.textCritical) >>> 70. hand (att.transcriptional) >>> 71. hand (gap) >>> 72. hand (unclear) >>> 73. height (binaryObject) >>> 74. height (graphic) >>> 75. ident (att.identified) >>> 76. inst (att.interpLike) >>> 77. instant (att.editLike) >>> 78. key (att.canonical) >>> 79. key (classRef) >>> 80. key (macroRef) >>> 81. level (sense) >>> 82. level (title) >>> 83. loc (app) >>> 84. location (att.lexicographic) >>> 85. lrx (att.coordinated) >>> 86. lry (att.coordinated) >>> 87. match (att.scoping) >>> 88. material (supportDesc) >>> 89. max (att.ranging) >>> 90. max (memberOf) >>> 91. medium (att.handFeatures) >>> 92. mergedIn (att.lexicographic) >>> 93. met (att.metrical) >>> 94. method (correction) >>> 95. mimeType (att.internetMedia) >>> 96. min (att.ranging) >>> 97. min (memberOf) >>> 98. mode (att.combinable) >>> 99. mode (classes) >>> 100. mode (memberOf) >>> 101. module (att.identified) >>> 102. new (handShift) >>> 103. next (att.global.linking) >>> 104. notAfter-custom (att.datable.custom) >>> 105. notAfter-iso (att.datable.iso) >>> 106. notBefore-custom (att.datable.custom) >>> 107. notBefore-iso (att.datable.iso) >>> 108. notation (pron) >>> 109. ns (attDef) >>> 110. ns (elementSpec) >>> 111. ns (schemaSpec) >>> 112. nymRef (att.naming) >>> 113. opt (att.lexicographic) >>> 114. optional (fDecl) >>> 115. ord (iNode) >>> 116. ord (root) >>> 117. org (att.divLike) >>> 118. org (attList) >>> 119. orig (att.lexicographic) >>> 120. part (ab) >>> 121. part (att.divLike) >>> 122. part (att.segLike) >>> 123. parts (nym) >>> 124. perf (tech) >>> 125. period (att.datable) >>> 126. pre (pc) >>> 127. precision (att.dimensions) >>> 128. predeclare (att.identified) >>> 129. prefix (elementSpec) >>> 130. prefix (moduleRef) >>> 131. prev (att.global.linking) >>> 132. quantity (att.dimensions) >>> 133. real (att.metrical) >>> 134. ref (att.canonical) >>> 135. refLang (att.pointing) >>> 136. resp (att.responsibility) >>> 137. resp (space) >>> 138. rhyme (att.metrical) >>> 139. role (att.naming) >>> 140. role (att.tableDecoration) >>> 141. role (org) >>> 142. rotate (zone) >>> 143. rows (att.tableDecoration) >>> 144. sameAs (att.global.linking) >>> 145. sample (att.divLike) >>> 146. scale (binaryObject) >>> 147. scale (graphic) >>> 148. scheme (catRef) >>> 149. scheme (locus) >>> 150. scheme (locusGrp) >>> 151. scheme (tag) >>> 152. scope (att.dimensions) >>> 153. scope (att.handFeatures) >>> 154. scribe (att.handFeatures) >>> 155. scribeRef (att.handFeatures) >>> 156. script (att.handFeatures) >>> 157. scriptRef (att.handFeatures) >>> 158. select (att.global.linking) >>> 159. seq (att.transcriptional) >>> 160. social (distinct) >>> 161. sort (att.personal) >>> 162. source (att.editLike) >>> 163. source (att.readFrom) >>> 164. source (writing) >>> 165. space (distinct) >>> 166. spanTo (att.spanning) >>> 167. split (att.lexicographic) >>> 168. start (att.coordinated) >>> 169. start (att.timed) >>> 170. status (att.identified) >>> 171. status (att.transcriptional) >>> 172. status (correction) >>> 173. stdDeviation (precision) >>> 174. subtype (att.typed) >>> 175. synch (att.global.linking) >>> 176. targFunc (att.pointing.group) >>> 177. target (change) >>> 178. target (relatedItem) >>> 179. targetEnd (note) >>> 180. targetLang (schemaSpec) >>> 181. targets (alt) >>> 182. targets (join) >>> 183. targets (link) >>> 184. time (distinct) >>> 185. to (app) >>> 186. to (att.datable.w3c) >>> 187. to-custom (att.datable.custom) >>> 188. to-iso (att.datable.iso) >>> 189. type (abbr) >>> 190. type (att.entryLike) >>> 191. type (att.interpLike) >>> 192. type (att.textCritical) >>> 193. type (att.typed) >>> 194. type (form) >>> 195. type (q) >>> 196. type (sound) >>> 197. ulx (att.coordinated) >>> 198. uly (att.coordinated) >>> 199. unit (att.dimensions) >>> 200. unit (pc) >>> 201. unit (when) >>> 202. url (moduleRef) >>> 203. value (att.lexicographic) >>> 204. value (eTree) >>> 205. value (iNode) >>> 206. value (leaf) >>> 207. value (node) >>> 208. value (root) >>> 209. value (triangle) >>> 210. varSeq (att.textCritical) >>> 211. version (unicodeName) >>> 212. versionDate (att.translatable) >>> 213. when (docDate) >>> 214. where (event) >>> 215. who (att.ascribed) >>> 216. width (binaryObject) >>> 217. width (graphic) >>> 218. wit (att.rdgPart) >>> 219. wit (att.witnessed) >>> 220. xml:base (att.global) >>> 221. xml:id (att.global) >>> 222. xml:lang (att.global) >>> 223. xml:space (att.global) >>> >>> Cheers, >>> Martin >>> >>> On 12-04-19 03:18 PM, Martin Holmes wrote: >>>> Following on from our discussion of examples for attributes, a >>>> quick-and-dirty XSLT seems to show that there are only 19 attributes >>>> with their own examples, and 450 without. This is not to say that those >>>> without are unexemplified, because the example code for their parent >>>> elements in the elementSpec may show examples of them; I'll refine the >>>> XSLT and make that apparent. >>>> >>>> Here's the list: >>>> >>>> ATTRIBUTE DEFINITIONS LACKING EXAMPLES AS OF 2012-04-19T15:12:34.968-07:00 >>>> >>>> 1. status (att.identified) >>>> 2. type (interaction) >>>> 3. value (sex) >>>> 4. scale (graphic) >>>> 5. scale (binaryObject) >>>> 6. weights (alt) >>>> 7. hand (att.damaged) >>>> 8. agent (gap) >>>> 9. predeclare (att.identified) >>>> 10. degree (att.damaged) >>>> 11. module (att.identified) >>>> 12. ident (att.identified) >>>> 13. height (graphic) >>>> 14. height (binaryObject) >>>> 15. width (graphic) >>>> 16. width (binaryObject) >>>> 17. encoding (binaryObject) >>>> 18. version (teiCorpus) >>>> 19. hand (unclear) >>>> 20. agent (unclear) >>>> 21. feature (shift) >>>> 22. type (preparedness) >>>> 23. type (abbr) >>>> 24. commodity (att.measurement) >>>> 25. agent (att.damaged) >>>> 26. type (derivation) >>>> 27. type (domain) >>>> 28. type (factuality) >>>> 29. type (idno) >>>> 30. type (relation) >>>> 31. type (sound) >>>> 32. type (tech) >>>> 33. type (castItem) >>>> 34. type (att.typed) >>>> 35. type (move) >>>> 36. script (att.handFeatures) >>>> 37. class (msItemStruct) >>>> 38. class (msItem) >>>> 39. class (msContents) >>>> 40. type (form) >>>> 41. cause (att.textCritical) >>>> 42. type (gram) >>>> 43. type (lbl) >>>> 44. type (att.textCritical) >>>> 45. type (title) >>>> 46. type (titlePage) >>>> 47. type (usg) >>>> 48. type (app) >>>> 49. columns (layout) >>>> 50. valueDatcat (att.datcat) >>>> 51. datcat (att.datcat) >>>> 52. contemporary (seal) >>>> 53. contemporary (binding) >>>> 54. from (locus) >>>> 55. type (list) >>>> 56. result (joinGrp) >>>> 57. medium (att.handFeatures) >>>> 58. type (graph) >>>> 59. type (witDetail) >>>> 60. origin (timeline) >>>> 61. function (att.segLike) >>>> 62. form (objectDesc) >>>> 63. mergedIn (att.lexicographic) >>>> 64. type (fsDecl) >>>> 65. scribe (att.handFeatures) >>>> 66. degree (node) >>>> 67. extent (orth) >>>> 68. from (arc) >>>> 69. to (arc) >>>> 70. inDegree (node) >>>> 71. arity (tree) >>>> 72. baseTypes (fsDecl) >>>> 73. level (sense) >>>> 74. order (tree) >>>> 75. outDegree (iNode) >>>> 76. outDegree (node) >>>> 77. outDegree (root) >>>> 78. reason (gap) >>>> 79. type (orth) >>>> 80. when (docDate) >>>> 81. split (att.lexicographic) >>>> 82. code (socecStatus) >>>> 83. code (occupation) >>>> 84. decls (att.declaring) >>>> 85. cRef (term) >>>> 86. from (app) >>>> 87. scheme (catRef) >>>> 88. scheme (occupation) >>>> 89. scheme (classCode) >>>> 90. scheme (socecStatus) >>>> 91. scheme (keywords) >>>> 92. to (app) >>>> 93. baseForm (m) >>>> 94. new (handShift) >>>> 95. passive (relation) >>>> 96. since (when) >>>> 97. type (fsdLink) >>>> 98. type (biblScope) >>>> 99. type (listForest) >>>> 100. type (forest) >>>> 101. hand (gap) >>>> 102. given (certainty) >>>> 103. locus (certainty) >>>> 104. type (rs) >>>> 105. source (normalization) >>>> 106. level (title) >>>> 107. degree (certainty) >>>> 108. status (correction) >>>> 109. degree (precision) >>>> 110. spanTo (att.spanning) >>>> 111. to (att.datable.w3c) >>>> 112. to-iso (att.datable.iso) >>>> 113. force (pc) >>>> 114. reason (surplus) >>>> 115. type (stage) >>>> 116. type (oRef) >>>> 117. type (oVar) >>>> 118. method (correction) >>>> 119. method (normalization) >>>> 120. name (fDecl) >>>> 121. evidence (att.editLike) >>>> 122. rows (table) >>>> 123. org (vMerge) >>>> 124. who (att.ascribed) >>>> 125. locus (respons) >>>> 126. from-custom (att.datable.custom) >>>> 127. from (att.datable.w3c) >>>> 128. from-iso (att.datable.iso) >>>> 129. type (xr) >>>> 130. type (iType) >>>> 131. type (num) >>>> 132. type (att.entryLike) >>>> 133. type (att.interpLike) >>>> 134. unit (refState) >>>> 135. notation (pron) >>>> 136. break (att.breaking) >>>> 137. iterated (kinesic) >>>> 138. iterated (vocal) >>>> 139. optional (fDecl) >>>> 140. default (att.declarable) >>>> 141. location (variantEncoding) >>>> 142. anchored (note) >>>> 143. full (att.personal) >>>> 144. type (metDecl) >>>> 145. extent (pron) >>>> 146. discrete (sound) >>>> 147. scope (join) >>>> 148. gradual (writing) >>>> 149. sample (att.divLike) >>>> 150. type (classSpec) >>>> 151. pre (pc) >>>> 152. type (dimensions) >>>> 153. method (variantEncoding) >>>> 154. type (macroSpec) >>>> 155. reason (supplied) >>>> 156. to (locus) >>>> 157. rows (att.tableDecoration) >>>> 158. writtenLines (layout) >>>> 159. ruledLines (layout) >>>> 160. location (att.lexicographic) >>>> 161. hands (handDesc) >>>> 162. material (supportDesc) >>>> 163. notation (formula) >>>> 164. unit (att.dimensions) >>>> 165. ns (attDef) >>>> 166. ns (elementSpec) >>>> 167. domains (att.pointing.group) >>>> 168. part (att.segLike) >>>> 169. source (writing) >>>> 170. ref (g) >>>> 171. scribeRef (att.handFeatures) >>>> 172. scriptRef (att.handFeatures) >>>> 173. copyOf (att.global.linking) >>>> 174. sameAs (att.global.linking) >>>> 175. exclude (att.global.linking) >>>> 176. targetEnd (note) >>>> 177. next (att.global.linking) >>>> 178. target (relatedItem) >>>> 179. unit (milestone) >>>> 180. label (rhyme) >>>> 181. lemma (w) >>>> 182. children (iNode) >>>> 183. children (root) >>>> 184. name (f) >>>> 185. unit (pc) >>>> 186. value (leaf) >>>> 187. type (node) >>>> 188. key (att.canonical) >>>> 189. follow (iNode) >>>> 190. follow (leaf) >>>> 191. parent (leaf) >>>> 192. parent (iNode) >>>> 193. value (node) >>>> 194. value (triangle) >>>> 195. value (eLeaf) >>>> 196. value (eTree) >>>> 197. value (iNode) >>>> 198. value (root) >>>> 199. quantity (att.measurement) >>>> 200. role (att.tableDecoration) >>>> 201. scheme (att) >>>> 202. select (att.global.linking) >>>> 203. xml:space (att.global) >>>> 204. hand (att.textCritical) >>>> 205. subtype (att.typed) >>>> 206. prefix (schemaSpec) >>>> 207. prefix (elementSpec) >>>> 208. type (purpose) >>>> 209. role (org) >>>> 210. role (person) >>>> 211. matchPattern (cRefPattern) >>>> 212. replacementPattern (cRefPattern) >>>> 213. age (person) >>>> 214. start (schemaSpec) >>>> 215. form (quotation) >>>> 216. time (distinct) >>>> 217. social (distinct) >>>> 218. space (distinct) >>>> 219. type (constitution) >>>> 220. scope (att.handFeatures) >>>> 221. age (personGrp) >>>> 222. usage (language) >>>> 223. ident (valItem) >>>> 224. from (span) >>>> 225. value (metSym) >>>> 226. versionDate (att.translatable) >>>> 227. target (att.pointing) >>>> 228. where (move) >>>> 229. notBefore (att.datable.w3c) >>>> 230. notBefore-custom (att.datable.custom) >>>> 231. notBefore-iso (att.datable.iso) >>>> 232. mode (classes) >>>> 233. mode (att.combinable) >>>> 234. mode (memberOf) >>>> 235. to (span) >>>> 236. to (biblScope) >>>> 237. type (valList) >>>> 238. degree (purpose) >>>> 239. length (refState) >>>> 240. render (tagUsage) >>>> 241. targets (alt) >>>> 242. targets (join) >>>> 243. targets (link) >>>> 244. type (teiHeader) >>>> 245. notAfter (att.datable.w3c) >>>> 246. notAfter-custom (att.datable.custom) >>>> 247. notAfter-iso (att.datable.iso) >>>> 248. version (TEI) >>>> 249. mode (channel) >>>> 250. result (join) >>>> 251. new (shift) >>>> 252. active (interaction) >>>> 253. occurs (tagUsage) >>>> 254. passive (interaction) >>>> 255. interval (when) >>>> 256. interval (timeline) >>>> 257. usage (attDef) >>>> 258. role (personGrp) >>>> 259. type (titlePart) >>>> 260. sex (personGrp) >>>> 261. sex (person) >>>> 262. size (personGrp) >>>> 263. from (biblScope) >>>> 264. type (distinct) >>>> 265. type (measure) >>>> 266. type (fs) >>>> 267. unit (timeline) >>>> 268. unit (when) >>>> 269. version (unicodeName) >>>> 270. type (divGen) >>>> 271. part (ab) >>>> 272. part (att.divLike) >>>> 273. part (l) >>>> 274. terminal (metSym) >>>> 275. trunc (numeric) >>>> 276. order (graph) >>>> 277. size (graph) >>>> 278. mode (alt) >>>> 279. mode (altGrp) >>>> 280. value (binary) >>>> 281. status (availability) >>>> 282. datum (geoDecl) >>>> 283. value (numeric) >>>> 284. name (relation) >>>> 285. name (vLabel) >>>> 286. indexName (index) >>>> 287. stdDeviation (precision) >>>> 288. absolute (when) >>>> 289. max (numeric) >>>> 290. scheme (constraintSpec) >>>> 291. scheme (tag) >>>> 292. scheme (gi) >>>> 293. value (symbol) >>>> 294. value (num) >>>> 295. scheme (locusGrp) >>>> 296. scheme (locus) >>>> 297. name (namespace) >>>> 298. type (recording) >>>> 299. unit (att.measurement) >>>> 300. value (att.lexicographic) >>>> 301. scope (att.dimensions) >>>> 302. evaluate (att.pointing) >>>> 303. active (relation) >>>> 304. to-custom (att.datable.custom) >>>> 305. mutual (relation) >>>> 306. dur-iso (att.duration.iso) >>>> 307. instant (att.editLike) >>>> 308. function (metamark) >>>> 309. attachment (surface) >>>> 310. cause (att.transcriptional) >>>> 311. target (metamark) >>>> 312. rotate (zone) >>>> 313. target (redo) >>>> 314. target (undo) >>>> 315. except (moduleRef) >>>> 316. include (moduleRef) >>>> 317. datingMethod (att.datable.custom) >>>> 318. datingPoint (att.datable.custom) >>>> 319. key (moduleRef) >>>> 320. url (moduleRef) >>>> 321. mimeType (att.internetMedia) >>>> 322. version (application) >>>> 323. ident (application) >>>> 324. confidence (att.ranging) >>>> 325. level (langKnown) >>>> 326. adj (node) >>>> 327. adjFrom (node) >>>> 328. adjTo (node) >>>> 329. ana (att.global.analytic) >>>> 330. group (att.damaged) >>>> 331. cRef (gloss) >>>> 332. cRef (ptr) >>>> 333. cRef (ref) >>>> 334. cert (att.responsibility) >>>> 335. cert (certainty) >>>> 336. precision (precision) >>>> 337. precision (att.dimensions) >>>> 338. type (fw) >>>> 339. cols (table) >>>> 340. cols (att.tableDecoration) >>>> 341. source (att.editLike) >>>> 342. autoPrefix (content) >>>> 343. corresp (att.global.linking) >>>> 344. delim (refState) >>>> 345. dim (space) >>>> 346. docLang (schemaSpec) >>>> 347. dur (att.duration.w3c) >>>> 348. ed (att.sourced) >>>> 349. gi (tagUsage) >>>> 350. eol (hyphenation) >>>> 351. enjamb (att.enjamb) >>>> 352. facs (att.global.facs) >>>> 353. fVal (f) >>>> 354. feats (fs) >>>> 355. lang (code) >>>> 356. atMost (att.ranging) >>>> 357. atLeast (att.ranging) >>>> 358. lrx (att.coordinated) >>>> 359. ulx (att.coordinated) >>>> 360. lry (att.coordinated) >>>> 361. uly (att.coordinated) >>>> 362. xml:id (att.global) >>>> 363. ident (language) >>>> 364. scheme (rendition) >>>> 365. status (att.transcriptional) >>>> 366. where (event) >>>> 367. start (att.timed) >>>> 368. end (att.timed) >>>> 369. type (tag) >>>> 370. defective (att.msExcerpt) >>>> 371. generate (classSpec) >>>> 372. inst (att.interpLike) >>>> 373. xml:lang (att.global) >>>> 374. loc (app) >>>> 375. mainLang (textLang) >>>> 376. maxOccurs (datatype) >>>> 377. type (q) >>>> 378. direct (said) >>>> 379. aloud (said) >>>> 380. met (att.metrical) >>>> 381. real (att.metrical) >>>> 382. minOccurs (datatype) >>>> 383. name (equiv) >>>> 384. ns (schemaSpec) >>>> 385. n (att.global) >>>> 386. opt (att.lexicographic) >>>> 387. ord (iNode) >>>> 388. ord (root) >>>> 389. ord (tree) >>>> 390. sort (att.personal) >>>> 391. org (attList) >>>> 392. org (vColl) >>>> 393. org (att.divLike) >>>> 394. orig (att.lexicographic) >>>> 395. otherLangs (textLang) >>>> 396. perf (move) >>>> 397. perf (tech) >>>> 398. target (specGrpRef) >>>> 399. parts (nym) >>>> 400. change (att.global.change) >>>> 401. target (change) >>>> 402. prev (att.global.linking) >>>> 403. lemmaRef (w) >>>> 404. marks (quotation) >>>> 405. ref (att.canonical) >>>> 406. nymRef (att.naming) >>>> 407. filter (equiv) >>>> 408. pattern (metDecl) >>>> 409. resp (respons) >>>> 410. resp (att.responsibility) >>>> 411. resp (space) >>>> 412. rhyme (att.metrical) >>>> 413. seq (att.transcriptional) >>>> 414. hand (att.transcriptional) >>>> 415. prefix (moduleRef) >>>> 416. key (memberOf) >>>> 417. quantity (att.dimensions) >>>> 418. value (age) >>>> 419. target (fsdLink) >>>> 420. period (att.datable) >>>> 421. tag (langKnown) >>>> 422. tags (langKnowledge) >>>> 423. max (memberOf) >>>> 424. min (memberOf) >>>> 425. synch (att.global.linking) >>>> 426. targFunc (att.pointing.group) >>>> 427. targetLang (schemaSpec) >>>> 428. key (classRef) >>>> 429. key (elementRef) >>>> 430. key (macroRef) >>>> 431. name (attRef) >>>> 432. trans (u) >>>> 433. uri (equiv) >>>> 434. url (graphic) >>>> 435. varSeq (att.textCritical) >>>> 436. scope (rendition) >>>> 437. max (att.ranging) >>>> 438. min (att.ranging) >>>> 439. withId (tagUsage) >>>> 440. wit (att.witnessed) >>>> 441. wit (att.rdgPart) >>>> 442. wit (witDetail) >>>> 443. status (att.docStatus) >>>> 444. points (zone) >>>> 445. start (att.coordinated) >>>> 446. valid (egXML) >>>> 447. ordered (listChange) >>>> 448. role (att.naming) >>>> 449. source (att.readFrom) >>>> 450. flipping (surface) >>>> >>>> >>>> ATTRIBUTE DEFINITIONS WHICH HAVE EXAMPLES AS OF >>>> 2012-04-19T15:12:34.968-07:00 >>>> >>>> 1. place (att.placement) >>>> 2. expand (att.lexicographic) >>>> 3. extent (att.dimensions) >>>> 4. calendar (att.datable) >>>> 5. reason (unclear) >>>> 6. target (att.scoping) >>>> 7. xml:base (att.global) >>>> 8. assertedValue (certainty) >>>> 9. refLang (att.pointing) >>>> 10. match (att.scoping) >>>> 11. sortKey (att.sortable) >>>> 12. atts (specDesc) >>>> 13. key (specDesc) >>>> 14. norm (att.lexicographic) >>>> 15. rendition (att.global) >>>> 16. rend (att.global) >>>> 17. when-iso (att.datable.iso) >>>> 18. when-custom (att.datable.custom) >>>> 19. when (att.datable.w3c) >>>> >>>> -- >>>> Martin Holmes >>>> University of Victoria Humanities Computing and Media Centre >>>> (mholmes at uvic.ca) >>>> -- >>>> tei-council mailing list >>>> tei-council at lists.village.Virginia.EDU >>>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council >>>> >>>> PLEASE NOTE: postings to this list are publicly archived >>>> . >>>> >>> >> . >> > -- Dr James Cummings, InfoDev, Computing Services, University of Oxford From mholmes at uvic.ca Mon Apr 23 12:03:36 2012 From: mholmes at uvic.ca (Martin Holmes) Date: Mon, 23 Apr 2012 09:03:36 -0700 Subject: [tei-council] Ignore my Jenkins for a while... In-Reply-To: <4F9349B8.7030709@uvic.ca> References: <4F9349B8.7030709@uvic.ca> Message-ID: <4F957D58.70600@uvic.ca> I think we're stable again on the UVic Jenkins. Cheers, Martin On 12-04-21 04:58 PM, Martin Holmes wrote: > Hi all, > > Just writing to warn everybody that I'm working on the configuration of > jobs on my Jenkins box, with limited success, so builds are failing for > reasons which probably have nothing to do with you. Sebastian says his > Jinks is stable, and it looks to be so, so please refer to his when > you've committed changes: > > <http://bits.nsms.ox.ac.uk:8080/jenkins/> > > rather than mine, which is two butties short of a picnic at the moment: > > <http://teijenkins.hcmc.uvic.ca:8080/> > > I'm hoping that normal service will be resumed as soon as possible. Once > it's working again, I'll be leaving it well alone, and working on > another VM built from Ubuntu Precise. That should ultimately replace > this one, and be the model from which you can build your own Jenkins > machine should you wish to. > > Cheers, > Martin -- Martin Holmes University of Victoria Humanities Computing and Media Centre (mholmes at uvic.ca) From sebastian.rahtz at oucs.ox.ac.uk Mon Apr 23 12:06:28 2012 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 23 Apr 2012 16:06:28 +0000 Subject: [tei-council] Ignore my Jenkins for a while... In-Reply-To: <4F957D58.70600@uvic.ca> References: <4F9349B8.7030709@uvic.ca> <4F957D58.70600@uvic.ca> Message-ID: <73DE755F-BA7C-401D-A0FE-56DD1B22D86A@oucs.ox.ac.uk> On 23 Apr 2012, at 17:03, Martin Holmes wrote: > I think we're stable again on the UVic Jenkins. and we're back to pure green in Oxford. people should be aware that the Guidelines now build against the current state of Stylesheets, so any changes to the core stylesheets show up in Guidelines immediately. this is a Good Thing (according to MH and SR) -- Stormageddon Rahtz Head of Information and Support Group Oxford University Computing Services 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 Apr 23 12:19:02 2012 From: mholmes at uvic.ca (Martin Holmes) Date: Mon, 23 Apr 2012 09:19:02 -0700 Subject: [tei-council] Attributes without examples In-Reply-To: <4F957C03.8090008@oucs.ox.ac.uk> References: <4F908F22.4070908@uvic.ca> <4F90AD72.10605@uvic.ca> <4F90AEBC.6000608@ultraslavonic.info> <4F9573BF.1080302@uvic.ca> <4F957C03.8090008@oucs.ox.ac.uk> Message-ID: <4F9580F6.4080505@uvic.ca> Thanks James -- that works. I have to write that down somewhere. I wonder why spambots wouldn't use <nowiki/> themselves. Here's the page -- feel free to sign up for one or more attributes by editing it: <http://wiki.tei-c.org/index.php/AttsWithoutEgs> Cheers, Martin On 12-04-23 08:57 AM, James Cummings wrote: > > Martin, > > It is simple but intentionally not documented. Interrupt the spam > word with an element. Specifically use<nowiki/> so > att.ms<nowiki/>Excerpt will allow you to get around the spam filter. > > Just don't advertise via<nowiki/>gra too much. > > -James > > On 23/04/12 16:22, Martin Holmes wrote: >> I've just tried to create a wiki page which has a table listing all >> these attributes, but I've been prevented from doing so by the sad >> little spam filter, which won't allow this: >> >> att.msExcerpt >> >> because it contains "sEx". >> >> I seem to remember having spent a frustrating time fighting with this >> stupidity some time ago. Does anyone remember how to get around this, or >> is it pointless to try? >> >> Cheers, >> Martin >> >> On 12-04-19 05:33 PM, Kevin Hawkins wrote: >>> Would you be able to output as a table with a third column for people to >>> sign up, either in MediaWiki or HTML syntax, for a page in the wiki? >>> >>> On 4/19/12 8:27 PM, Martin Holmes wrote: >>>> Below is another slightly shorter list. These are attributes which do >>>> not appear on any examples in the<elementSpec> or<classSpec> in which >>>> they're defined. Not that this doesn't mean there are no examples at all >>>> for them; there may be an example somewhere in the Guidelines text, or >>>> the attribute may be defined in a<classSpec> for an attribute class, >>>> and then show up in an example in an<elementSpec> for an element which >>>> belongs to that class. An example of the latter is @agent (att.damaged), >>>> which has no example in the att.damaged<classSpec>, but happens to show >>>> up in an example for the<damage> element. >>>> >>>> Nevertheless, I think it would be a good idea to try to provide examples >>>> for all these attributes, in the files which define them. >>>> >>>> ATTRIBUTES WHICH DO NOT SHOW UP ON ANY EXAMPLE IN THEIR elementSpec OR >>>> classSpec AS OF 2012-04-19T17:19:17.315-07:00 >>>> >>>> 1. absolute (when) >>>> 2. adj (node) >>>> 3. adjFrom (node) >>>> 4. adjTo (node) >>>> 5. age (personGrp) >>>> 6. agent (att.damaged) >>>> 7. agent (gap) >>>> 8. agent (unclear) >>>> 9. ana (att.global.analytic) >>>> 10. atLeast (att.ranging) >>>> 11. atMost (att.ranging) >>>> 12. attachment (surface) >>>> 13. autoPrefix (content) >>>> 14. baseTypes (fsDecl) >>>> 15. break (att.breaking) >>>> 16. cRef (gloss) >>>> 17. cRef (ptr) >>>> 18. cRef (ref) >>>> 19. cRef (term) >>>> 20. cause (att.textCritical) >>>> 21. cause (att.transcriptional) >>>> 22. cert (att.responsibility) >>>> 23. change (att.global.change) >>>> 24. class (msContents) >>>> 25. cols (att.tableDecoration) >>>> 26. confidence (att.ranging) >>>> 27. contemporary (seal) >>>> 28. copyOf (att.global.linking) >>>> 29. corresp (att.global.linking) >>>> 30. datingMethod (att.datable.custom) >>>> 31. datingPoint (att.datable.custom) >>>> 32. decls (att.declaring) >>>> 33. default (att.declarable) >>>> 34. defective (att.msExcerpt) >>>> 35. degree (att.damaged) >>>> 36. degree (node) >>>> 37. dim (space) >>>> 38. direct (said) >>>> 39. docLang (schemaSpec) >>>> 40. domains (att.pointing.group) >>>> 41. dur (att.duration.w3c) >>>> 42. dur-iso (att.duration.iso) >>>> 43. encoding (binaryObject) >>>> 44. end (att.timed) >>>> 45. enjamb (att.enjamb) >>>> 46. evaluate (att.pointing) >>>> 47. evidence (att.editLike) >>>> 48. except (moduleRef) >>>> 49. exclude (att.global.linking) >>>> 50. expand (att.lexicographic) >>>> 51. extent (orth) >>>> 52. fVal (f) >>>> 53. facs (att.global.facs) >>>> 54. feats (fs) >>>> 55. filter (equiv) >>>> 56. flipping (surface) >>>> 57. follow (leaf) >>>> 58. force (pc) >>>> 59. from (app) >>>> 60. from (att.datable.w3c) >>>> 61. from-custom (att.datable.custom) >>>> 62. from-iso (att.datable.iso) >>>> 63. full (att.personal) >>>> 64. function (att.segLike) >>>> 65. generate (classSpec) >>>> 66. gradual (writing) >>>> 67. group (att.damaged) >>>> 68. hand (att.damaged) >>>> 69. hand (att.textCritical) >>>> 70. hand (att.transcriptional) >>>> 71. hand (gap) >>>> 72. hand (unclear) >>>> 73. height (binaryObject) >>>> 74. height (graphic) >>>> 75. ident (att.identified) >>>> 76. inst (att.interpLike) >>>> 77. instant (att.editLike) >>>> 78. key (att.canonical) >>>> 79. key (classRef) >>>> 80. key (macroRef) >>>> 81. level (sense) >>>> 82. level (title) >>>> 83. loc (app) >>>> 84. location (att.lexicographic) >>>> 85. lrx (att.coordinated) >>>> 86. lry (att.coordinated) >>>> 87. match (att.scoping) >>>> 88. material (supportDesc) >>>> 89. max (att.ranging) >>>> 90. max (memberOf) >>>> 91. medium (att.handFeatures) >>>> 92. mergedIn (att.lexicographic) >>>> 93. met (att.metrical) >>>> 94. method (correction) >>>> 95. mimeType (att.internetMedia) >>>> 96. min (att.ranging) >>>> 97. min (memberOf) >>>> 98. mode (att.combinable) >>>> 99. mode (classes) >>>> 100. mode (memberOf) >>>> 101. module (att.identified) >>>> 102. new (handShift) >>>> 103. next (att.global.linking) >>>> 104. notAfter-custom (att.datable.custom) >>>> 105. notAfter-iso (att.datable.iso) >>>> 106. notBefore-custom (att.datable.custom) >>>> 107. notBefore-iso (att.datable.iso) >>>> 108. notation (pron) >>>> 109. ns (attDef) >>>> 110. ns (elementSpec) >>>> 111. ns (schemaSpec) >>>> 112. nymRef (att.naming) >>>> 113. opt (att.lexicographic) >>>> 114. optional (fDecl) >>>> 115. ord (iNode) >>>> 116. ord (root) >>>> 117. org (att.divLike) >>>> 118. org (attList) >>>> 119. orig (att.lexicographic) >>>> 120. part (ab) >>>> 121. part (att.divLike) >>>> 122. part (att.segLike) >>>> 123. parts (nym) >>>> 124. perf (tech) >>>> 125. period (att.datable) >>>> 126. pre (pc) >>>> 127. precision (att.dimensions) >>>> 128. predeclare (att.identified) >>>> 129. prefix (elementSpec) >>>> 130. prefix (moduleRef) >>>> 131. prev (att.global.linking) >>>> 132. quantity (att.dimensions) >>>> 133. real (att.metrical) >>>> 134. ref (att.canonical) >>>> 135. refLang (att.pointing) >>>> 136. resp (att.responsibility) >>>> 137. resp (space) >>>> 138. rhyme (att.metrical) >>>> 139. role (att.naming) >>>> 140. role (att.tableDecoration) >>>> 141. role (org) >>>> 142. rotate (zone) >>>> 143. rows (att.tableDecoration) >>>> 144. sameAs (att.global.linking) >>>> 145. sample (att.divLike) >>>> 146. scale (binaryObject) >>>> 147. scale (graphic) >>>> 148. scheme (catRef) >>>> 149. scheme (locus) >>>> 150. scheme (locusGrp) >>>> 151. scheme (tag) >>>> 152. scope (att.dimensions) >>>> 153. scope (att.handFeatures) >>>> 154. scribe (att.handFeatures) >>>> 155. scribeRef (att.handFeatures) >>>> 156. script (att.handFeatures) >>>> 157. scriptRef (att.handFeatures) >>>> 158. select (att.global.linking) >>>> 159. seq (att.transcriptional) >>>> 160. social (distinct) >>>> 161. sort (att.personal) >>>> 162. source (att.editLike) >>>> 163. source (att.readFrom) >>>> 164. source (writing) >>>> 165. space (distinct) >>>> 166. spanTo (att.spanning) >>>> 167. split (att.lexicographic) >>>> 168. start (att.coordinated) >>>> 169. start (att.timed) >>>> 170. status (att.identified) >>>> 171. status (att.transcriptional) >>>> 172. status (correction) >>>> 173. stdDeviation (precision) >>>> 174. subtype (att.typed) >>>> 175. synch (att.global.linking) >>>> 176. targFunc (att.pointing.group) >>>> 177. target (change) >>>> 178. target (relatedItem) >>>> 179. targetEnd (note) >>>> 180. targetLang (schemaSpec) >>>> 181. targets (alt) >>>> 182. targets (join) >>>> 183. targets (link) >>>> 184. time (distinct) >>>> 185. to (app) >>>> 186. to (att.datable.w3c) >>>> 187. to-custom (att.datable.custom) >>>> 188. to-iso (att.datable.iso) >>>> 189. type (abbr) >>>> 190. type (att.entryLike) >>>> 191. type (att.interpLike) >>>> 192. type (att.textCritical) >>>> 193. type (att.typed) >>>> 194. type (form) >>>> 195. type (q) >>>> 196. type (sound) >>>> 197. ulx (att.coordinated) >>>> 198. uly (att.coordinated) >>>> 199. unit (att.dimensions) >>>> 200. unit (pc) >>>> 201. unit (when) >>>> 202. url (moduleRef) >>>> 203. value (att.lexicographic) >>>> 204. value (eTree) >>>> 205. value (iNode) >>>> 206. value (leaf) >>>> 207. value (node) >>>> 208. value (root) >>>> 209. value (triangle) >>>> 210. varSeq (att.textCritical) >>>> 211. version (unicodeName) >>>> 212. versionDate (att.translatable) >>>> 213. when (docDate) >>>> 214. where (event) >>>> 215. who (att.ascribed) >>>> 216. width (binaryObject) >>>> 217. width (graphic) >>>> 218. wit (att.rdgPart) >>>> 219. wit (att.witnessed) >>>> 220. xml:base (att.global) >>>> 221. xml:id (att.global) >>>> 222. xml:lang (att.global) >>>> 223. xml:space (att.global) >>>> >>>> Cheers, >>>> Martin >>>> >>>> On 12-04-19 03:18 PM, Martin Holmes wrote: >>>>> Following on from our discussion of examples for attributes, a >>>>> quick-and-dirty XSLT seems to show that there are only 19 attributes >>>>> with their own examples, and 450 without. This is not to say that those >>>>> without are unexemplified, because the example code for their parent >>>>> elements in the elementSpec may show examples of them; I'll refine the >>>>> XSLT and make that apparent. >>>>> >>>>> Here's the list: >>>>> >>>>> ATTRIBUTE DEFINITIONS LACKING EXAMPLES AS OF 2012-04-19T15:12:34.968-07:00 >>>>> >>>>> 1. status (att.identified) >>>>> 2. type (interaction) >>>>> 3. value (sex) >>>>> 4. scale (graphic) >>>>> 5. scale (binaryObject) >>>>> 6. weights (alt) >>>>> 7. hand (att.damaged) >>>>> 8. agent (gap) >>>>> 9. predeclare (att.identified) >>>>> 10. degree (att.damaged) >>>>> 11. module (att.identified) >>>>> 12. ident (att.identified) >>>>> 13. height (graphic) >>>>> 14. height (binaryObject) >>>>> 15. width (graphic) >>>>> 16. width (binaryObject) >>>>> 17. encoding (binaryObject) >>>>> 18. version (teiCorpus) >>>>> 19. hand (unclear) >>>>> 20. agent (unclear) >>>>> 21. feature (shift) >>>>> 22. type (preparedness) >>>>> 23. type (abbr) >>>>> 24. commodity (att.measurement) >>>>> 25. agent (att.damaged) >>>>> 26. type (derivation) >>>>> 27. type (domain) >>>>> 28. type (factuality) >>>>> 29. type (idno) >>>>> 30. type (relation) >>>>> 31. type (sound) >>>>> 32. type (tech) >>>>> 33. type (castItem) >>>>> 34. type (att.typed) >>>>> 35. type (move) >>>>> 36. script (att.handFeatures) >>>>> 37. class (msItemStruct) >>>>> 38. class (msItem) >>>>> 39. class (msContents) >>>>> 40. type (form) >>>>> 41. cause (att.textCritical) >>>>> 42. type (gram) >>>>> 43. type (lbl) >>>>> 44. type (att.textCritical) >>>>> 45. type (title) >>>>> 46. type (titlePage) >>>>> 47. type (usg) >>>>> 48. type (app) >>>>> 49. columns (layout) >>>>> 50. valueDatcat (att.datcat) >>>>> 51. datcat (att.datcat) >>>>> 52. contemporary (seal) >>>>> 53. contemporary (binding) >>>>> 54. from (locus) >>>>> 55. type (list) >>>>> 56. result (joinGrp) >>>>> 57. medium (att.handFeatures) >>>>> 58. type (graph) >>>>> 59. type (witDetail) >>>>> 60. origin (timeline) >>>>> 61. function (att.segLike) >>>>> 62. form (objectDesc) >>>>> 63. mergedIn (att.lexicographic) >>>>> 64. type (fsDecl) >>>>> 65. scribe (att.handFeatures) >>>>> 66. degree (node) >>>>> 67. extent (orth) >>>>> 68. from (arc) >>>>> 69. to (arc) >>>>> 70. inDegree (node) >>>>> 71. arity (tree) >>>>> 72. baseTypes (fsDecl) >>>>> 73. level (sense) >>>>> 74. order (tree) >>>>> 75. outDegree (iNode) >>>>> 76. outDegree (node) >>>>> 77. outDegree (root) >>>>> 78. reason (gap) >>>>> 79. type (orth) >>>>> 80. when (docDate) >>>>> 81. split (att.lexicographic) >>>>> 82. code (socecStatus) >>>>> 83. code (occupation) >>>>> 84. decls (att.declaring) >>>>> 85. cRef (term) >>>>> 86. from (app) >>>>> 87. scheme (catRef) >>>>> 88. scheme (occupation) >>>>> 89. scheme (classCode) >>>>> 90. scheme (socecStatus) >>>>> 91. scheme (keywords) >>>>> 92. to (app) >>>>> 93. baseForm (m) >>>>> 94. new (handShift) >>>>> 95. passive (relation) >>>>> 96. since (when) >>>>> 97. type (fsdLink) >>>>> 98. type (biblScope) >>>>> 99. type (listForest) >>>>> 100. type (forest) >>>>> 101. hand (gap) >>>>> 102. given (certainty) >>>>> 103. locus (certainty) >>>>> 104. type (rs) >>>>> 105. source (normalization) >>>>> 106. level (title) >>>>> 107. degree (certainty) >>>>> 108. status (correction) >>>>> 109. degree (precision) >>>>> 110. spanTo (att.spanning) >>>>> 111. to (att.datable.w3c) >>>>> 112. to-iso (att.datable.iso) >>>>> 113. force (pc) >>>>> 114. reason (surplus) >>>>> 115. type (stage) >>>>> 116. type (oRef) >>>>> 117. type (oVar) >>>>> 118. method (correction) >>>>> 119. method (normalization) >>>>> 120. name (fDecl) >>>>> 121. evidence (att.editLike) >>>>> 122. rows (table) >>>>> 123. org (vMerge) >>>>> 124. who (att.ascribed) >>>>> 125. locus (respons) >>>>> 126. from-custom (att.datable.custom) >>>>> 127. from (att.datable.w3c) >>>>> 128. from-iso (att.datable.iso) >>>>> 129. type (xr) >>>>> 130. type (iType) >>>>> 131. type (num) >>>>> 132. type (att.entryLike) >>>>> 133. type (att.interpLike) >>>>> 134. unit (refState) >>>>> 135. notation (pron) >>>>> 136. break (att.breaking) >>>>> 137. iterated (kinesic) >>>>> 138. iterated (vocal) >>>>> 139. optional (fDecl) >>>>> 140. default (att.declarable) >>>>> 141. location (variantEncoding) >>>>> 142. anchored (note) >>>>> 143. full (att.personal) >>>>> 144. type (metDecl) >>>>> 145. extent (pron) >>>>> 146. discrete (sound) >>>>> 147. scope (join) >>>>> 148. gradual (writing) >>>>> 149. sample (att.divLike) >>>>> 150. type (classSpec) >>>>> 151. pre (pc) >>>>> 152. type (dimensions) >>>>> 153. method (variantEncoding) >>>>> 154. type (macroSpec) >>>>> 155. reason (supplied) >>>>> 156. to (locus) >>>>> 157. rows (att.tableDecoration) >>>>> 158. writtenLines (layout) >>>>> 159. ruledLines (layout) >>>>> 160. location (att.lexicographic) >>>>> 161. hands (handDesc) >>>>> 162. material (supportDesc) >>>>> 163. notation (formula) >>>>> 164. unit (att.dimensions) >>>>> 165. ns (attDef) >>>>> 166. ns (elementSpec) >>>>> 167. domains (att.pointing.group) >>>>> 168. part (att.segLike) >>>>> 169. source (writing) >>>>> 170. ref (g) >>>>> 171. scribeRef (att.handFeatures) >>>>> 172. scriptRef (att.handFeatures) >>>>> 173. copyOf (att.global.linking) >>>>> 174. sameAs (att.global.linking) >>>>> 175. exclude (att.global.linking) >>>>> 176. targetEnd (note) >>>>> 177. next (att.global.linking) >>>>> 178. target (relatedItem) >>>>> 179. unit (milestone) >>>>> 180. label (rhyme) >>>>> 181. lemma (w) >>>>> 182. children (iNode) >>>>> 183. children (root) >>>>> 184. name (f) >>>>> 185. unit (pc) >>>>> 186. value (leaf) >>>>> 187. type (node) >>>>> 188. key (att.canonical) >>>>> 189. follow (iNode) >>>>> 190. follow (leaf) >>>>> 191. parent (leaf) >>>>> 192. parent (iNode) >>>>> 193. value (node) >>>>> 194. value (triangle) >>>>> 195. value (eLeaf) >>>>> 196. value (eTree) >>>>> 197. value (iNode) >>>>> 198. value (root) >>>>> 199. quantity (att.measurement) >>>>> 200. role (att.tableDecoration) >>>>> 201. scheme (att) >>>>> 202. select (att.global.linking) >>>>> 203. xml:space (att.global) >>>>> 204. hand (att.textCritical) >>>>> 205. subtype (att.typed) >>>>> 206. prefix (schemaSpec) >>>>> 207. prefix (elementSpec) >>>>> 208. type (purpose) >>>>> 209. role (org) >>>>> 210. role (person) >>>>> 211. matchPattern (cRefPattern) >>>>> 212. replacementPattern (cRefPattern) >>>>> 213. age (person) >>>>> 214. start (schemaSpec) >>>>> 215. form (quotation) >>>>> 216. time (distinct) >>>>> 217. social (distinct) >>>>> 218. space (distinct) >>>>> 219. type (constitution) >>>>> 220. scope (att.handFeatures) >>>>> 221. age (personGrp) >>>>> 222. usage (language) >>>>> 223. ident (valItem) >>>>> 224. from (span) >>>>> 225. value (metSym) >>>>> 226. versionDate (att.translatable) >>>>> 227. target (att.pointing) >>>>> 228. where (move) >>>>> 229. notBefore (att.datable.w3c) >>>>> 230. notBefore-custom (att.datable.custom) >>>>> 231. notBefore-iso (att.datable.iso) >>>>> 232. mode (classes) >>>>> 233. mode (att.combinable) >>>>> 234. mode (memberOf) >>>>> 235. to (span) >>>>> 236. to (biblScope) >>>>> 237. type (valList) >>>>> 238. degree (purpose) >>>>> 239. length (refState) >>>>> 240. render (tagUsage) >>>>> 241. targets (alt) >>>>> 242. targets (join) >>>>> 243. targets (link) >>>>> 244. type (teiHeader) >>>>> 245. notAfter (att.datable.w3c) >>>>> 246. notAfter-custom (att.datable.custom) >>>>> 247. notAfter-iso (att.datable.iso) >>>>> 248. version (TEI) >>>>> 249. mode (channel) >>>>> 250. result (join) >>>>> 251. new (shift) >>>>> 252. active (interaction) >>>>> 253. occurs (tagUsage) >>>>> 254. passive (interaction) >>>>> 255. interval (when) >>>>> 256. interval (timeline) >>>>> 257. usage (attDef) >>>>> 258. role (personGrp) >>>>> 259. type (titlePart) >>>>> 260. sex (personGrp) >>>>> 261. sex (person) >>>>> 262. size (personGrp) >>>>> 263. from (biblScope) >>>>> 264. type (distinct) >>>>> 265. type (measure) >>>>> 266. type (fs) >>>>> 267. unit (timeline) >>>>> 268. unit (when) >>>>> 269. version (unicodeName) >>>>> 270. type (divGen) >>>>> 271. part (ab) >>>>> 272. part (att.divLike) >>>>> 273. part (l) >>>>> 274. terminal (metSym) >>>>> 275. trunc (numeric) >>>>> 276. order (graph) >>>>> 277. size (graph) >>>>> 278. mode (alt) >>>>> 279. mode (altGrp) >>>>> 280. value (binary) >>>>> 281. status (availability) >>>>> 282. datum (geoDecl) >>>>> 283. value (numeric) >>>>> 284. name (relation) >>>>> 285. name (vLabel) >>>>> 286. indexName (index) >>>>> 287. stdDeviation (precision) >>>>> 288. absolute (when) >>>>> 289. max (numeric) >>>>> 290. scheme (constraintSpec) >>>>> 291. scheme (tag) >>>>> 292. scheme (gi) >>>>> 293. value (symbol) >>>>> 294. value (num) >>>>> 295. scheme (locusGrp) >>>>> 296. scheme (locus) >>>>> 297. name (namespace) >>>>> 298. type (recording) >>>>> 299. unit (att.measurement) >>>>> 300. value (att.lexicographic) >>>>> 301. scope (att.dimensions) >>>>> 302. evaluate (att.pointing) >>>>> 303. active (relation) >>>>> 304. to-custom (att.datable.custom) >>>>> 305. mutual (relation) >>>>> 306. dur-iso (att.duration.iso) >>>>> 307. instant (att.editLike) >>>>> 308. function (metamark) >>>>> 309. attachment (surface) >>>>> 310. cause (att.transcriptional) >>>>> 311. target (metamark) >>>>> 312. rotate (zone) >>>>> 313. target (redo) >>>>> 314. target (undo) >>>>> 315. except (moduleRef) >>>>> 316. include (moduleRef) >>>>> 317. datingMethod (att.datable.custom) >>>>> 318. datingPoint (att.datable.custom) >>>>> 319. key (moduleRef) >>>>> 320. url (moduleRef) >>>>> 321. mimeType (att.internetMedia) >>>>> 322. version (application) >>>>> 323. ident (application) >>>>> 324. confidence (att.ranging) >>>>> 325. level (langKnown) >>>>> 326. adj (node) >>>>> 327. adjFrom (node) >>>>> 328. adjTo (node) >>>>> 329. ana (att.global.analytic) >>>>> 330. group (att.damaged) >>>>> 331. cRef (gloss) >>>>> 332. cRef (ptr) >>>>> 333. cRef (ref) >>>>> 334. cert (att.responsibility) >>>>> 335. cert (certainty) >>>>> 336. precision (precision) >>>>> 337. precision (att.dimensions) >>>>> 338. type (fw) >>>>> 339. cols (table) >>>>> 340. cols (att.tableDecoration) >>>>> 341. source (att.editLike) >>>>> 342. autoPrefix (content) >>>>> 343. corresp (att.global.linking) >>>>> 344. delim (refState) >>>>> 345. dim (space) >>>>> 346. docLang (schemaSpec) >>>>> 347. dur (att.duration.w3c) >>>>> 348. ed (att.sourced) >>>>> 349. gi (tagUsage) >>>>> 350. eol (hyphenation) >>>>> 351. enjamb (att.enjamb) >>>>> 352. facs (att.global.facs) >>>>> 353. fVal (f) >>>>> 354. feats (fs) >>>>> 355. lang (code) >>>>> 356. atMost (att.ranging) >>>>> 357. atLeast (att.ranging) >>>>> 358. lrx (att.coordinated) >>>>> 359. ulx (att.coordinated) >>>>> 360. lry (att.coordinated) >>>>> 361. uly (att.coordinated) >>>>> 362. xml:id (att.global) >>>>> 363. ident (language) >>>>> 364. scheme (rendition) >>>>> 365. status (att.transcriptional) >>>>> 366. where (event) >>>>> 367. start (att.timed) >>>>> 368. end (att.timed) >>>>> 369. type (tag) >>>>> 370. defective (att.msExcerpt) >>>>> 371. generate (classSpec) >>>>> 372. inst (att.interpLike) >>>>> 373. xml:lang (att.global) >>>>> 374. loc (app) >>>>> 375. mainLang (textLang) >>>>> 376. maxOccurs (datatype) >>>>> 377. type (q) >>>>> 378. direct (said) >>>>> 379. aloud (said) >>>>> 380. met (att.metrical) >>>>> 381. real (att.metrical) >>>>> 382. minOccurs (datatype) >>>>> 383. name (equiv) >>>>> 384. ns (schemaSpec) >>>>> 385. n (att.global) >>>>> 386. opt (att.lexicographic) >>>>> 387. ord (iNode) >>>>> 388. ord (root) >>>>> 389. ord (tree) >>>>> 390. sort (att.personal) >>>>> 391. org (attList) >>>>> 392. org (vColl) >>>>> 393. org (att.divLike) >>>>> 394. orig (att.lexicographic) >>>>> 395. otherLangs (textLang) >>>>> 396. perf (move) >>>>> 397. perf (tech) >>>>> 398. target (specGrpRef) >>>>> 399. parts (nym) >>>>> 400. change (att.global.change) >>>>> 401. target (change) >>>>> 402. prev (att.global.linking) >>>>> 403. lemmaRef (w) >>>>> 404. marks (quotation) >>>>> 405. ref (att.canonical) >>>>> 406. nymRef (att.naming) >>>>> 407. filter (equiv) >>>>> 408. pattern (metDecl) >>>>> 409. resp (respons) >>>>> 410. resp (att.responsibility) >>>>> 411. resp (space) >>>>> 412. rhyme (att.metrical) >>>>> 413. seq (att.transcriptional) >>>>> 414. hand (att.transcriptional) >>>>> 415. prefix (moduleRef) >>>>> 416. key (memberOf) >>>>> 417. quantity (att.dimensions) >>>>> 418. value (age) >>>>> 419. target (fsdLink) >>>>> 420. period (att.datable) >>>>> 421. tag (langKnown) >>>>> 422. tags (langKnowledge) >>>>> 423. max (memberOf) >>>>> 424. min (memberOf) >>>>> 425. synch (att.global.linking) >>>>> 426. targFunc (att.pointing.group) >>>>> 427. targetLang (schemaSpec) >>>>> 428. key (classRef) >>>>> 429. key (elementRef) >>>>> 430. key (macroRef) >>>>> 431. name (attRef) >>>>> 432. trans (u) >>>>> 433. uri (equiv) >>>>> 434. url (graphic) >>>>> 435. varSeq (att.textCritical) >>>>> 436. scope (rendition) >>>>> 437. max (att.ranging) >>>>> 438. min (att.ranging) >>>>> 439. withId (tagUsage) >>>>> 440. wit (att.witnessed) >>>>> 441. wit (att.rdgPart) >>>>> 442. wit (witDetail) >>>>> 443. status (att.docStatus) >>>>> 444. points (zone) >>>>> 445. start (att.coordinated) >>>>> 446. valid (egXML) >>>>> 447. ordered (listChange) >>>>> 448. role (att.naming) >>>>> 449. source (att.readFrom) >>>>> 450. flipping (surface) >>>>> >>>>> >>>>> ATTRIBUTE DEFINITIONS WHICH HAVE EXAMPLES AS OF >>>>> 2012-04-19T15:12:34.968-07:00 >>>>> >>>>> 1. place (att.placement) >>>>> 2. expand (att.lexicographic) >>>>> 3. extent (att.dimensions) >>>>> 4. calendar (att.datable) >>>>> 5. reason (unclear) >>>>> 6. target (att.scoping) >>>>> 7. xml:base (att.global) >>>>> 8. assertedValue (certainty) >>>>> 9. refLang (att.pointing) >>>>> 10. match (att.scoping) >>>>> 11. sortKey (att.sortable) >>>>> 12. atts (specDesc) >>>>> 13. key (specDesc) >>>>> 14. norm (att.lexicographic) >>>>> 15. rendition (att.global) >>>>> 16. rend (att.global) >>>>> 17. when-iso (att.datable.iso) >>>>> 18. when-custom (att.datable.custom) >>>>> 19. when (att.datable.w3c) >>>>> >>>>> -- >>>>> Martin Holmes >>>>> University of Victoria Humanities Computing and Media Centre >>>>> (mholmes at uvic.ca) >>>>> -- >>>>> tei-council mailing list >>>>> tei-council at lists.village.Virginia.EDU >>>>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council >>>>> >>>>> PLEASE NOTE: postings to this list are publicly archived >>>>> . >>>>> >>>> >>> . >>> >> > > > -- > Dr James Cummings, InfoDev, > Computing Services, University of Oxford > -- > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > > PLEASE NOTE: postings to this list are publicly archived > . > -- Martin Holmes University of Victoria Humanities Computing and Media Centre (mholmes at uvic.ca) From James.Cummings at oucs.ox.ac.uk Mon Apr 23 12:30:14 2012 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Mon, 23 Apr 2012 17:30:14 +0100 Subject: [tei-council] Attributes without examples In-Reply-To: <4F9580F6.4080505@uvic.ca> References: <4F908F22.4070908@uvic.ca> <4F90AD72.10605@uvic.ca> <4F90AEBC.6000608@ultraslavonic.info> <4F9573BF.1080302@uvic.ca> <4F957C03.8090008@oucs.ox.ac.uk> <4F9580F6.4080505@uvic.ca> Message-ID: <4F958396.9010304@oucs.ox.ac.uk> On 23/04/12 17:19, Martin Holmes wrote: > Thanks James -- that works. I have to write that down somewhere. > I wonder why spambots wouldn't use <nowiki/> themselves. Sadly, they do. Increasingly, they can also read captchas. > Here's the page -- feel free to sign up for one or more > attributes by editing it: > <http://wiki.tei-c.org/index.php/AttsWithoutEgs> Would it make sense to also look at the attribute's datatype and if it is something like data.pointer consider putting in multiple examples (e.g. one that points locally and one that points to a remote object). -James -- Dr James Cummings, InfoDev, Computing Services, University of Oxford From mholmes at uvic.ca Mon Apr 23 12:35:03 2012 From: mholmes at uvic.ca (Martin Holmes) Date: Mon, 23 Apr 2012 09:35:03 -0700 Subject: [tei-council] Attributes without examples In-Reply-To: <4F9580F6.4080505@uvic.ca> References: <4F908F22.4070908@uvic.ca> <4F90AD72.10605@uvic.ca> <4F90AEBC.6000608@ultraslavonic.info> <4F9573BF.1080302@uvic.ca> <4F957C03.8090008@oucs.ox.ac.uk> <4F9580F6.4080505@uvic.ca> Message-ID: <4F9584B7.3080302@uvic.ca> I've created a ticket for this too, so we don't lose track of it: <http://purl.org/TEI/BUGS/3520704> Cheers, Martin On 12-04-23 09:19 AM, Martin Holmes wrote: > Thanks James -- that works. I have to write that down somewhere. I > wonder why spambots wouldn't use<nowiki/> themselves. > > Here's the page -- feel free to sign up for one or more attributes by > editing it: > > <http://wiki.tei-c.org/index.php/AttsWithoutEgs> > > Cheers, > Martin > > On 12-04-23 08:57 AM, James Cummings wrote: >> >> Martin, >> >> It is simple but intentionally not documented. Interrupt the spam >> word with an element. Specifically use<nowiki/> so >> att.ms<nowiki/>Excerpt will allow you to get around the spam filter. >> >> Just don't advertise via<nowiki/>gra too much. >> >> -James >> >> On 23/04/12 16:22, Martin Holmes wrote: >>> I've just tried to create a wiki page which has a table listing all >>> these attributes, but I've been prevented from doing so by the sad >>> little spam filter, which won't allow this: >>> >>> att.msExcerpt >>> >>> because it contains "sEx". >>> >>> I seem to remember having spent a frustrating time fighting with this >>> stupidity some time ago. Does anyone remember how to get around this, or >>> is it pointless to try? >>> >>> Cheers, >>> Martin >>> >>> On 12-04-19 05:33 PM, Kevin Hawkins wrote: >>>> Would you be able to output as a table with a third column for people to >>>> sign up, either in MediaWiki or HTML syntax, for a page in the wiki? >>>> >>>> On 4/19/12 8:27 PM, Martin Holmes wrote: >>>>> Below is another slightly shorter list. These are attributes which do >>>>> not appear on any examples in the<elementSpec> or<classSpec> in which >>>>> they're defined. Not that this doesn't mean there are no examples at all >>>>> for them; there may be an example somewhere in the Guidelines text, or >>>>> the attribute may be defined in a<classSpec> for an attribute class, >>>>> and then show up in an example in an<elementSpec> for an element which >>>>> belongs to that class. An example of the latter is @agent (att.damaged), >>>>> which has no example in the att.damaged<classSpec>, but happens to show >>>>> up in an example for the<damage> element. >>>>> >>>>> Nevertheless, I think it would be a good idea to try to provide examples >>>>> for all these attributes, in the files which define them. >>>>> >>>>> ATTRIBUTES WHICH DO NOT SHOW UP ON ANY EXAMPLE IN THEIR elementSpec OR >>>>> classSpec AS OF 2012-04-19T17:19:17.315-07:00 >>>>> >>>>> 1. absolute (when) >>>>> 2. adj (node) >>>>> 3. adjFrom (node) >>>>> 4. adjTo (node) >>>>> 5. age (personGrp) >>>>> 6. agent (att.damaged) >>>>> 7. agent (gap) >>>>> 8. agent (unclear) >>>>> 9. ana (att.global.analytic) >>>>> 10. atLeast (att.ranging) >>>>> 11. atMost (att.ranging) >>>>> 12. attachment (surface) >>>>> 13. autoPrefix (content) >>>>> 14. baseTypes (fsDecl) >>>>> 15. break (att.breaking) >>>>> 16. cRef (gloss) >>>>> 17. cRef (ptr) >>>>> 18. cRef (ref) >>>>> 19. cRef (term) >>>>> 20. cause (att.textCritical) >>>>> 21. cause (att.transcriptional) >>>>> 22. cert (att.responsibility) >>>>> 23. change (att.global.change) >>>>> 24. class (msContents) >>>>> 25. cols (att.tableDecoration) >>>>> 26. confidence (att.ranging) >>>>> 27. contemporary (seal) >>>>> 28. copyOf (att.global.linking) >>>>> 29. corresp (att.global.linking) >>>>> 30. datingMethod (att.datable.custom) >>>>> 31. datingPoint (att.datable.custom) >>>>> 32. decls (att.declaring) >>>>> 33. default (att.declarable) >>>>> 34. defective (att.msExcerpt) >>>>> 35. degree (att.damaged) >>>>> 36. degree (node) >>>>> 37. dim (space) >>>>> 38. direct (said) >>>>> 39. docLang (schemaSpec) >>>>> 40. domains (att.pointing.group) >>>>> 41. dur (att.duration.w3c) >>>>> 42. dur-iso (att.duration.iso) >>>>> 43. encoding (binaryObject) >>>>> 44. end (att.timed) >>>>> 45. enjamb (att.enjamb) >>>>> 46. evaluate (att.pointing) >>>>> 47. evidence (att.editLike) >>>>> 48. except (moduleRef) >>>>> 49. exclude (att.global.linking) >>>>> 50. expand (att.lexicographic) >>>>> 51. extent (orth) >>>>> 52. fVal (f) >>>>> 53. facs (att.global.facs) >>>>> 54. feats (fs) >>>>> 55. filter (equiv) >>>>> 56. flipping (surface) >>>>> 57. follow (leaf) >>>>> 58. force (pc) >>>>> 59. from (app) >>>>> 60. from (att.datable.w3c) >>>>> 61. from-custom (att.datable.custom) >>>>> 62. from-iso (att.datable.iso) >>>>> 63. full (att.personal) >>>>> 64. function (att.segLike) >>>>> 65. generate (classSpec) >>>>> 66. gradual (writing) >>>>> 67. group (att.damaged) >>>>> 68. hand (att.damaged) >>>>> 69. hand (att.textCritical) >>>>> 70. hand (att.transcriptional) >>>>> 71. hand (gap) >>>>> 72. hand (unclear) >>>>> 73. height (binaryObject) >>>>> 74. height (graphic) >>>>> 75. ident (att.identified) >>>>> 76. inst (att.interpLike) >>>>> 77. instant (att.editLike) >>>>> 78. key (att.canonical) >>>>> 79. key (classRef) >>>>> 80. key (macroRef) >>>>> 81. level (sense) >>>>> 82. level (title) >>>>> 83. loc (app) >>>>> 84. location (att.lexicographic) >>>>> 85. lrx (att.coordinated) >>>>> 86. lry (att.coordinated) >>>>> 87. match (att.scoping) >>>>> 88. material (supportDesc) >>>>> 89. max (att.ranging) >>>>> 90. max (memberOf) >>>>> 91. medium (att.handFeatures) >>>>> 92. mergedIn (att.lexicographic) >>>>> 93. met (att.metrical) >>>>> 94. method (correction) >>>>> 95. mimeType (att.internetMedia) >>>>> 96. min (att.ranging) >>>>> 97. min (memberOf) >>>>> 98. mode (att.combinable) >>>>> 99. mode (classes) >>>>> 100. mode (memberOf) >>>>> 101. module (att.identified) >>>>> 102. new (handShift) >>>>> 103. next (att.global.linking) >>>>> 104. notAfter-custom (att.datable.custom) >>>>> 105. notAfter-iso (att.datable.iso) >>>>> 106. notBefore-custom (att.datable.custom) >>>>> 107. notBefore-iso (att.datable.iso) >>>>> 108. notation (pron) >>>>> 109. ns (attDef) >>>>> 110. ns (elementSpec) >>>>> 111. ns (schemaSpec) >>>>> 112. nymRef (att.naming) >>>>> 113. opt (att.lexicographic) >>>>> 114. optional (fDecl) >>>>> 115. ord (iNode) >>>>> 116. ord (root) >>>>> 117. org (att.divLike) >>>>> 118. org (attList) >>>>> 119. orig (att.lexicographic) >>>>> 120. part (ab) >>>>> 121. part (att.divLike) >>>>> 122. part (att.segLike) >>>>> 123. parts (nym) >>>>> 124. perf (tech) >>>>> 125. period (att.datable) >>>>> 126. pre (pc) >>>>> 127. precision (att.dimensions) >>>>> 128. predeclare (att.identified) >>>>> 129. prefix (elementSpec) >>>>> 130. prefix (moduleRef) >>>>> 131. prev (att.global.linking) >>>>> 132. quantity (att.dimensions) >>>>> 133. real (att.metrical) >>>>> 134. ref (att.canonical) >>>>> 135. refLang (att.pointing) >>>>> 136. resp (att.responsibility) >>>>> 137. resp (space) >>>>> 138. rhyme (att.metrical) >>>>> 139. role (att.naming) >>>>> 140. role (att.tableDecoration) >>>>> 141. role (org) >>>>> 142. rotate (zone) >>>>> 143. rows (att.tableDecoration) >>>>> 144. sameAs (att.global.linking) >>>>> 145. sample (att.divLike) >>>>> 146. scale (binaryObject) >>>>> 147. scale (graphic) >>>>> 148. scheme (catRef) >>>>> 149. scheme (locus) >>>>> 150. scheme (locusGrp) >>>>> 151. scheme (tag) >>>>> 152. scope (att.dimensions) >>>>> 153. scope (att.handFeatures) >>>>> 154. scribe (att.handFeatures) >>>>> 155. scribeRef (att.handFeatures) >>>>> 156. script (att.handFeatures) >>>>> 157. scriptRef (att.handFeatures) >>>>> 158. select (att.global.linking) >>>>> 159. seq (att.transcriptional) >>>>> 160. social (distinct) >>>>> 161. sort (att.personal) >>>>> 162. source (att.editLike) >>>>> 163. source (att.readFrom) >>>>> 164. source (writing) >>>>> 165. space (distinct) >>>>> 166. spanTo (att.spanning) >>>>> 167. split (att.lexicographic) >>>>> 168. start (att.coordinated) >>>>> 169. start (att.timed) >>>>> 170. status (att.identified) >>>>> 171. status (att.transcriptional) >>>>> 172. status (correction) >>>>> 173. stdDeviation (precision) >>>>> 174. subtype (att.typed) >>>>> 175. synch (att.global.linking) >>>>> 176. targFunc (att.pointing.group) >>>>> 177. target (change) >>>>> 178. target (relatedItem) >>>>> 179. targetEnd (note) >>>>> 180. targetLang (schemaSpec) >>>>> 181. targets (alt) >>>>> 182. targets (join) >>>>> 183. targets (link) >>>>> 184. time (distinct) >>>>> 185. to (app) >>>>> 186. to (att.datable.w3c) >>>>> 187. to-custom (att.datable.custom) >>>>> 188. to-iso (att.datable.iso) >>>>> 189. type (abbr) >>>>> 190. type (att.entryLike) >>>>> 191. type (att.interpLike) >>>>> 192. type (att.textCritical) >>>>> 193. type (att.typed) >>>>> 194. type (form) >>>>> 195. type (q) >>>>> 196. type (sound) >>>>> 197. ulx (att.coordinated) >>>>> 198. uly (att.coordinated) >>>>> 199. unit (att.dimensions) >>>>> 200. unit (pc) >>>>> 201. unit (when) >>>>> 202. url (moduleRef) >>>>> 203. value (att.lexicographic) >>>>> 204. value (eTree) >>>>> 205. value (iNode) >>>>> 206. value (leaf) >>>>> 207. value (node) >>>>> 208. value (root) >>>>> 209. value (triangle) >>>>> 210. varSeq (att.textCritical) >>>>> 211. version (unicodeName) >>>>> 212. versionDate (att.translatable) >>>>> 213. when (docDate) >>>>> 214. where (event) >>>>> 215. who (att.ascribed) >>>>> 216. width (binaryObject) >>>>> 217. width (graphic) >>>>> 218. wit (att.rdgPart) >>>>> 219. wit (att.witnessed) >>>>> 220. xml:base (att.global) >>>>> 221. xml:id (att.global) >>>>> 222. xml:lang (att.global) >>>>> 223. xml:space (att.global) >>>>> >>>>> Cheers, >>>>> Martin >>>>> >>>>> On 12-04-19 03:18 PM, Martin Holmes wrote: >>>>>> Following on from our discussion of examples for attributes, a >>>>>> quick-and-dirty XSLT seems to show that there are only 19 attributes >>>>>> with their own examples, and 450 without. This is not to say that those >>>>>> without are unexemplified, because the example code for their parent >>>>>> elements in the elementSpec may show examples of them; I'll refine the >>>>>> XSLT and make that apparent. >>>>>> >>>>>> Here's the list: >>>>>> >>>>>> ATTRIBUTE DEFINITIONS LACKING EXAMPLES AS OF 2012-04-19T15:12:34.968-07:00 >>>>>> >>>>>> 1. status (att.identified) >>>>>> 2. type (interaction) >>>>>> 3. value (sex) >>>>>> 4. scale (graphic) >>>>>> 5. scale (binaryObject) >>>>>> 6. weights (alt) >>>>>> 7. hand (att.damaged) >>>>>> 8. agent (gap) >>>>>> 9. predeclare (att.identified) >>>>>> 10. degree (att.damaged) >>>>>> 11. module (att.identified) >>>>>> 12. ident (att.identified) >>>>>> 13. height (graphic) >>>>>> 14. height (binaryObject) >>>>>> 15. width (graphic) >>>>>> 16. width (binaryObject) >>>>>> 17. encoding (binaryObject) >>>>>> 18. version (teiCorpus) >>>>>> 19. hand (unclear) >>>>>> 20. agent (unclear) >>>>>> 21. feature (shift) >>>>>> 22. type (preparedness) >>>>>> 23. type (abbr) >>>>>> 24. commodity (att.measurement) >>>>>> 25. agent (att.damaged) >>>>>> 26. type (derivation) >>>>>> 27. type (domain) >>>>>> 28. type (factuality) >>>>>> 29. type (idno) >>>>>> 30. type (relation) >>>>>> 31. type (sound) >>>>>> 32. type (tech) >>>>>> 33. type (castItem) >>>>>> 34. type (att.typed) >>>>>> 35. type (move) >>>>>> 36. script (att.handFeatures) >>>>>> 37. class (msItemStruct) >>>>>> 38. class (msItem) >>>>>> 39. class (msContents) >>>>>> 40. type (form) >>>>>> 41. cause (att.textCritical) >>>>>> 42. type (gram) >>>>>> 43. type (lbl) >>>>>> 44. type (att.textCritical) >>>>>> 45. type (title) >>>>>> 46. type (titlePage) >>>>>> 47. type (usg) >>>>>> 48. type (app) >>>>>> 49. columns (layout) >>>>>> 50. valueDatcat (att.datcat) >>>>>> 51. datcat (att.datcat) >>>>>> 52. contemporary (seal) >>>>>> 53. contemporary (binding) >>>>>> 54. from (locus) >>>>>> 55. type (list) >>>>>> 56. result (joinGrp) >>>>>> 57. medium (att.handFeatures) >>>>>> 58. type (graph) >>>>>> 59. type (witDetail) >>>>>> 60. origin (timeline) >>>>>> 61. function (att.segLike) >>>>>> 62. form (objectDesc) >>>>>> 63. mergedIn (att.lexicographic) >>>>>> 64. type (fsDecl) >>>>>> 65. scribe (att.handFeatures) >>>>>> 66. degree (node) >>>>>> 67. extent (orth) >>>>>> 68. from (arc) >>>>>> 69. to (arc) >>>>>> 70. inDegree (node) >>>>>> 71. arity (tree) >>>>>> 72. baseTypes (fsDecl) >>>>>> 73. level (sense) >>>>>> 74. order (tree) >>>>>> 75. outDegree (iNode) >>>>>> 76. outDegree (node) >>>>>> 77. outDegree (root) >>>>>> 78. reason (gap) >>>>>> 79. type (orth) >>>>>> 80. when (docDate) >>>>>> 81. split (att.lexicographic) >>>>>> 82. code (socecStatus) >>>>>> 83. code (occupation) >>>>>> 84. decls (att.declaring) >>>>>> 85. cRef (term) >>>>>> 86. from (app) >>>>>> 87. scheme (catRef) >>>>>> 88. scheme (occupation) >>>>>> 89. scheme (classCode) >>>>>> 90. scheme (socecStatus) >>>>>> 91. scheme (keywords) >>>>>> 92. to (app) >>>>>> 93. baseForm (m) >>>>>> 94. new (handShift) >>>>>> 95. passive (relation) >>>>>> 96. since (when) >>>>>> 97. type (fsdLink) >>>>>> 98. type (biblScope) >>>>>> 99. type (listForest) >>>>>> 100. type (forest) >>>>>> 101. hand (gap) >>>>>> 102. given (certainty) >>>>>> 103. locus (certainty) >>>>>> 104. type (rs) >>>>>> 105. source (normalization) >>>>>> 106. level (title) >>>>>> 107. degree (certainty) >>>>>> 108. status (correction) >>>>>> 109. degree (precision) >>>>>> 110. spanTo (att.spanning) >>>>>> 111. to (att.datable.w3c) >>>>>> 112. to-iso (att.datable.iso) >>>>>> 113. force (pc) >>>>>> 114. reason (surplus) >>>>>> 115. type (stage) >>>>>> 116. type (oRef) >>>>>> 117. type (oVar) >>>>>> 118. method (correction) >>>>>> 119. method (normalization) >>>>>> 120. name (fDecl) >>>>>> 121. evidence (att.editLike) >>>>>> 122. rows (table) >>>>>> 123. org (vMerge) >>>>>> 124. who (att.ascribed) >>>>>> 125. locus (respons) >>>>>> 126. from-custom (att.datable.custom) >>>>>> 127. from (att.datable.w3c) >>>>>> 128. from-iso (att.datable.iso) >>>>>> 129. type (xr) >>>>>> 130. type (iType) >>>>>> 131. type (num) >>>>>> 132. type (att.entryLike) >>>>>> 133. type (att.interpLike) >>>>>> 134. unit (refState) >>>>>> 135. notation (pron) >>>>>> 136. break (att.breaking) >>>>>> 137. iterated (kinesic) >>>>>> 138. iterated (vocal) >>>>>> 139. optional (fDecl) >>>>>> 140. default (att.declarable) >>>>>> 141. location (variantEncoding) >>>>>> 142. anchored (note) >>>>>> 143. full (att.personal) >>>>>> 144. type (metDecl) >>>>>> 145. extent (pron) >>>>>> 146. discrete (sound) >>>>>> 147. scope (join) >>>>>> 148. gradual (writing) >>>>>> 149. sample (att.divLike) >>>>>> 150. type (classSpec) >>>>>> 151. pre (pc) >>>>>> 152. type (dimensions) >>>>>> 153. method (variantEncoding) >>>>>> 154. type (macroSpec) >>>>>> 155. reason (supplied) >>>>>> 156. to (locus) >>>>>> 157. rows (att.tableDecoration) >>>>>> 158. writtenLines (layout) >>>>>> 159. ruledLines (layout) >>>>>> 160. location (att.lexicographic) >>>>>> 161. hands (handDesc) >>>>>> 162. material (supportDesc) >>>>>> 163. notation (formula) >>>>>> 164. unit (att.dimensions) >>>>>> 165. ns (attDef) >>>>>> 166. ns (elementSpec) >>>>>> 167. domains (att.pointing.group) >>>>>> 168. part (att.segLike) >>>>>> 169. source (writing) >>>>>> 170. ref (g) >>>>>> 171. scribeRef (att.handFeatures) >>>>>> 172. scriptRef (att.handFeatures) >>>>>> 173. copyOf (att.global.linking) >>>>>> 174. sameAs (att.global.linking) >>>>>> 175. exclude (att.global.linking) >>>>>> 176. targetEnd (note) >>>>>> 177. next (att.global.linking) >>>>>> 178. target (relatedItem) >>>>>> 179. unit (milestone) >>>>>> 180. label (rhyme) >>>>>> 181. lemma (w) >>>>>> 182. children (iNode) >>>>>> 183. children (root) >>>>>> 184. name (f) >>>>>> 185. unit (pc) >>>>>> 186. value (leaf) >>>>>> 187. type (node) >>>>>> 188. key (att.canonical) >>>>>> 189. follow (iNode) >>>>>> 190. follow (leaf) >>>>>> 191. parent (leaf) >>>>>> 192. parent (iNode) >>>>>> 193. value (node) >>>>>> 194. value (triangle) >>>>>> 195. value (eLeaf) >>>>>> 196. value (eTree) >>>>>> 197. value (iNode) >>>>>> 198. value (root) >>>>>> 199. quantity (att.measurement) >>>>>> 200. role (att.tableDecoration) >>>>>> 201. scheme (att) >>>>>> 202. select (att.global.linking) >>>>>> 203. xml:space (att.global) >>>>>> 204. hand (att.textCritical) >>>>>> 205. subtype (att.typed) >>>>>> 206. prefix (schemaSpec) >>>>>> 207. prefix (elementSpec) >>>>>> 208. type (purpose) >>>>>> 209. role (org) >>>>>> 210. role (person) >>>>>> 211. matchPattern (cRefPattern) >>>>>> 212. replacementPattern (cRefPattern) >>>>>> 213. age (person) >>>>>> 214. start (schemaSpec) >>>>>> 215. form (quotation) >>>>>> 216. time (distinct) >>>>>> 217. social (distinct) >>>>>> 218. space (distinct) >>>>>> 219. type (constitution) >>>>>> 220. scope (att.handFeatures) >>>>>> 221. age (personGrp) >>>>>> 222. usage (language) >>>>>> 223. ident (valItem) >>>>>> 224. from (span) >>>>>> 225. value (metSym) >>>>>> 226. versionDate (att.translatable) >>>>>> 227. target (att.pointing) >>>>>> 228. where (move) >>>>>> 229. notBefore (att.datable.w3c) >>>>>> 230. notBefore-custom (att.datable.custom) >>>>>> 231. notBefore-iso (att.datable.iso) >>>>>> 232. mode (classes) >>>>>> 233. mode (att.combinable) >>>>>> 234. mode (memberOf) >>>>>> 235. to (span) >>>>>> 236. to (biblScope) >>>>>> 237. type (valList) >>>>>> 238. degree (purpose) >>>>>> 239. length (refState) >>>>>> 240. render (tagUsage) >>>>>> 241. targets (alt) >>>>>> 242. targets (join) >>>>>> 243. targets (link) >>>>>> 244. type (teiHeader) >>>>>> 245. notAfter (att.datable.w3c) >>>>>> 246. notAfter-custom (att.datable.custom) >>>>>> 247. notAfter-iso (att.datable.iso) >>>>>> 248. version (TEI) >>>>>> 249. mode (channel) >>>>>> 250. result (join) >>>>>> 251. new (shift) >>>>>> 252. active (interaction) >>>>>> 253. occurs (tagUsage) >>>>>> 254. passive (interaction) >>>>>> 255. interval (when) >>>>>> 256. interval (timeline) >>>>>> 257. usage (attDef) >>>>>> 258. role (personGrp) >>>>>> 259. type (titlePart) >>>>>> 260. sex (personGrp) >>>>>> 261. sex (person) >>>>>> 262. size (personGrp) >>>>>> 263. from (biblScope) >>>>>> 264. type (distinct) >>>>>> 265. type (measure) >>>>>> 266. type (fs) >>>>>> 267. unit (timeline) >>>>>> 268. unit (when) >>>>>> 269. version (unicodeName) >>>>>> 270. type (divGen) >>>>>> 271. part (ab) >>>>>> 272. part (att.divLike) >>>>>> 273. part (l) >>>>>> 274. terminal (metSym) >>>>>> 275. trunc (numeric) >>>>>> 276. order (graph) >>>>>> 277. size (graph) >>>>>> 278. mode (alt) >>>>>> 279. mode (altGrp) >>>>>> 280. value (binary) >>>>>> 281. status (availability) >>>>>> 282. datum (geoDecl) >>>>>> 283. value (numeric) >>>>>> 284. name (relation) >>>>>> 285. name (vLabel) >>>>>> 286. indexName (index) >>>>>> 287. stdDeviation (precision) >>>>>> 288. absolute (when) >>>>>> 289. max (numeric) >>>>>> 290. scheme (constraintSpec) >>>>>> 291. scheme (tag) >>>>>> 292. scheme (gi) >>>>>> 293. value (symbol) >>>>>> 294. value (num) >>>>>> 295. scheme (locusGrp) >>>>>> 296. scheme (locus) >>>>>> 297. name (namespace) >>>>>> 298. type (recording) >>>>>> 299. unit (att.measurement) >>>>>> 300. value (att.lexicographic) >>>>>> 301. scope (att.dimensions) >>>>>> 302. evaluate (att.pointing) >>>>>> 303. active (relation) >>>>>> 304. to-custom (att.datable.custom) >>>>>> 305. mutual (relation) >>>>>> 306. dur-iso (att.duration.iso) >>>>>> 307. instant (att.editLike) >>>>>> 308. function (metamark) >>>>>> 309. attachment (surface) >>>>>> 310. cause (att.transcriptional) >>>>>> 311. target (metamark) >>>>>> 312. rotate (zone) >>>>>> 313. target (redo) >>>>>> 314. target (undo) >>>>>> 315. except (moduleRef) >>>>>> 316. include (moduleRef) >>>>>> 317. datingMethod (att.datable.custom) >>>>>> 318. datingPoint (att.datable.custom) >>>>>> 319. key (moduleRef) >>>>>> 320. url (moduleRef) >>>>>> 321. mimeType (att.internetMedia) >>>>>> 322. version (application) >>>>>> 323. ident (application) >>>>>> 324. confidence (att.ranging) >>>>>> 325. level (langKnown) >>>>>> 326. adj (node) >>>>>> 327. adjFrom (node) >>>>>> 328. adjTo (node) >>>>>> 329. ana (att.global.analytic) >>>>>> 330. group (att.damaged) >>>>>> 331. cRef (gloss) >>>>>> 332. cRef (ptr) >>>>>> 333. cRef (ref) >>>>>> 334. cert (att.responsibility) >>>>>> 335. cert (certainty) >>>>>> 336. precision (precision) >>>>>> 337. precision (att.dimensions) >>>>>> 338. type (fw) >>>>>> 339. cols (table) >>>>>> 340. cols (att.tableDecoration) >>>>>> 341. source (att.editLike) >>>>>> 342. autoPrefix (content) >>>>>> 343. corresp (att.global.linking) >>>>>> 344. delim (refState) >>>>>> 345. dim (space) >>>>>> 346. docLang (schemaSpec) >>>>>> 347. dur (att.duration.w3c) >>>>>> 348. ed (att.sourced) >>>>>> 349. gi (tagUsage) >>>>>> 350. eol (hyphenation) >>>>>> 351. enjamb (att.enjamb) >>>>>> 352. facs (att.global.facs) >>>>>> 353. fVal (f) >>>>>> 354. feats (fs) >>>>>> 355. lang (code) >>>>>> 356. atMost (att.ranging) >>>>>> 357. atLeast (att.ranging) >>>>>> 358. lrx (att.coordinated) >>>>>> 359. ulx (att.coordinated) >>>>>> 360. lry (att.coordinated) >>>>>> 361. uly (att.coordinated) >>>>>> 362. xml:id (att.global) >>>>>> 363. ident (language) >>>>>> 364. scheme (rendition) >>>>>> 365. status (att.transcriptional) >>>>>> 366. where (event) >>>>>> 367. start (att.timed) >>>>>> 368. end (att.timed) >>>>>> 369. type (tag) >>>>>> 370. defective (att.msExcerpt) >>>>>> 371. generate (classSpec) >>>>>> 372. inst (att.interpLike) >>>>>> 373. xml:lang (att.global) >>>>>> 374. loc (app) >>>>>> 375. mainLang (textLang) >>>>>> 376. maxOccurs (datatype) >>>>>> 377. type (q) >>>>>> 378. direct (said) >>>>>> 379. aloud (said) >>>>>> 380. met (att.metrical) >>>>>> 381. real (att.metrical) >>>>>> 382. minOccurs (datatype) >>>>>> 383. name (equiv) >>>>>> 384. ns (schemaSpec) >>>>>> 385. n (att.global) >>>>>> 386. opt (att.lexicographic) >>>>>> 387. ord (iNode) >>>>>> 388. ord (root) >>>>>> 389. ord (tree) >>>>>> 390. sort (att.personal) >>>>>> 391. org (attList) >>>>>> 392. org (vColl) >>>>>> 393. org (att.divLike) >>>>>> 394. orig (att.lexicographic) >>>>>> 395. otherLangs (textLang) >>>>>> 396. perf (move) >>>>>> 397. perf (tech) >>>>>> 398. target (specGrpRef) >>>>>> 399. parts (nym) >>>>>> 400. change (att.global.change) >>>>>> 401. target (change) >>>>>> 402. prev (att.global.linking) >>>>>> 403. lemmaRef (w) >>>>>> 404. marks (quotation) >>>>>> 405. ref (att.canonical) >>>>>> 406. nymRef (att.naming) >>>>>> 407. filter (equiv) >>>>>> 408. pattern (metDecl) >>>>>> 409. resp (respons) >>>>>> 410. resp (att.responsibility) >>>>>> 411. resp (space) >>>>>> 412. rhyme (att.metrical) >>>>>> 413. seq (att.transcriptional) >>>>>> 414. hand (att.transcriptional) >>>>>> 415. prefix (moduleRef) >>>>>> 416. key (memberOf) >>>>>> 417. quantity (att.dimensions) >>>>>> 418. value (age) >>>>>> 419. target (fsdLink) >>>>>> 420. period (att.datable) >>>>>> 421. tag (langKnown) >>>>>> 422. tags (langKnowledge) >>>>>> 423. max (memberOf) >>>>>> 424. min (memberOf) >>>>>> 425. synch (att.global.linking) >>>>>> 426. targFunc (att.pointing.group) >>>>>> 427. targetLang (schemaSpec) >>>>>> 428. key (classRef) >>>>>> 429. key (elementRef) >>>>>> 430. key (macroRef) >>>>>> 431. name (attRef) >>>>>> 432. trans (u) >>>>>> 433. uri (equiv) >>>>>> 434. url (graphic) >>>>>> 435. varSeq (att.textCritical) >>>>>> 436. scope (rendition) >>>>>> 437. max (att.ranging) >>>>>> 438. min (att.ranging) >>>>>> 439. withId (tagUsage) >>>>>> 440. wit (att.witnessed) >>>>>> 441. wit (att.rdgPart) >>>>>> 442. wit (witDetail) >>>>>> 443. status (att.docStatus) >>>>>> 444. points (zone) >>>>>> 445. start (att.coordinated) >>>>>> 446. valid (egXML) >>>>>> 447. ordered (listChange) >>>>>> 448. role (att.naming) >>>>>> 449. source (att.readFrom) >>>>>> 450. flipping (surface) >>>>>> >>>>>> >>>>>> ATTRIBUTE DEFINITIONS WHICH HAVE EXAMPLES AS OF >>>>>> 2012-04-19T15:12:34.968-07:00 >>>>>> >>>>>> 1. place (att.placement) >>>>>> 2. expand (att.lexicographic) >>>>>> 3. extent (att.dimensions) >>>>>> 4. calendar (att.datable) >>>>>> 5. reason (unclear) >>>>>> 6. target (att.scoping) >>>>>> 7. xml:base (att.global) >>>>>> 8. assertedValue (certainty) >>>>>> 9. refLang (att.pointing) >>>>>> 10. match (att.scoping) >>>>>> 11. sortKey (att.sortable) >>>>>> 12. atts (specDesc) >>>>>> 13. key (specDesc) >>>>>> 14. norm (att.lexicographic) >>>>>> 15. rendition (att.global) >>>>>> 16. rend (att.global) >>>>>> 17. when-iso (att.datable.iso) >>>>>> 18. when-custom (att.datable.custom) >>>>>> 19. when (att.datable.w3c) >>>>>> >>>>>> -- >>>>>> Martin Holmes >>>>>> University of Victoria Humanities Computing and Media Centre >>>>>> (mholmes at uvic.ca) >>>>>> -- >>>>>> tei-council mailing list >>>>>> tei-council at lists.village.Virginia.EDU >>>>>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council >>>>>> >>>>>> PLEASE NOTE: postings to this list are publicly archived >>>>>> . >>>>>> >>>>> >>>> . >>>> >>> >> >> >> -- >> Dr James Cummings, InfoDev, >> Computing Services, University of Oxford >> -- >> tei-council mailing list >> tei-council at lists.village.Virginia.EDU >> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council >> >> PLEASE NOTE: postings to this list are publicly archived >> . >> > > -- > Martin Holmes > University of Victoria Humanities Computing and Media Centre > (mholmes at uvic.ca) > -- > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > > PLEASE NOTE: postings to this list are publicly archived > . > -- Martin Holmes University of Victoria Humanities Computing and Media Centre (mholmes at uvic.ca) From gabriel.bodard at kcl.ac.uk Mon Apr 23 13:35:13 2012 From: gabriel.bodard at kcl.ac.uk (Gabriel BODARD) Date: Mon, 23 Apr 2012 18:35:13 +0100 Subject: [tei-council] next release? In-Reply-To: <4F9579A0.8010002@oucs.ox.ac.uk> References: <0F18A249-5480-42D9-BFF2-538AC7B9E1EB@oucs.ox.ac.uk> <4F92F34D.2040103@uvic.ca> <4F9579A0.8010002@oucs.ox.ac.uk> Message-ID: <4F9592D1.30207@kcl.ac.uk> In terms of doing the release tech, I guess I need to put aside at least a day to work through this, and it doesn't matter much to me when that day is, so that's fine. I'm now just trying to remember if there were any tickets assigned to me in the meantime, and if I'll have time to complete them by May 20. I was going to look into the guidelines-wide impact of something, but I don't recall exactly what. Did someone add a note to the ticket in question? (And in what may be the answer to the same or may be a completely unrelated question, could someone update http://purl.com/tei/fr/3416130 with the current state of Council thinking after Ann Arbor, please?) (Incidentally, I think http://purl.com/TEI/BUGS/3496949 has been erroneously assigned to me--I don't think I know what we're meant to do with this.) Gabby On 23/04/2012 16:47, James Cummings wrote: > > How about we set a notional target release date of 25 May? (This > is about 5 weeks from now.) If we assume that we want most things > completed by the end of Sunday 20th, to allow time for > proofreading and error spotting. > > Does that sounds reasonable to most people? > > Gaby: Most importantly, does the proposed Release Technician like > these dates? > > -James > > > On 21/04/12 18:50, Martin Holmes wrote: >> Three weeks will be a bit tough for me, and a couple of the tickets I >> have might turn out to have unpredicted side-effects (like the tei_ >> prefix). As long as we have the option to launch without the change if >> it proves difficult, we could go with three weeks. >> >> The attributes-without-examples problem is so large that we'll just have >> to hack away at it steadily. >> >> Cheers, >> Martin >> >> On 12-04-21 04:03 AM, Sebastian Rahtz wrote: >>> something we forgot to debate in Ann Arbor was a timetable >>> for the next release, I think? i.e. what is the due date for >>> everyone to complete their ticket work so that Sir Gabriel >>> of B'odard can undertake his Quest. >>> >>> speaking for myself, if I don't do my assignments >>> more or less immediately I will not get to them for ages, >>> so I favour a short window (say, 3 weeks). >>> >>> Sebastian > > -- Dr Gabriel BODARD (Research Associate in Digital Epigraphy) Department of Digital 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 Apr 23 13:38:53 2012 From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins) Date: Mon, 23 Apr 2012 13:38:53 -0400 Subject: [tei-council] next release? In-Reply-To: <4F9592D1.30207@kcl.ac.uk> References: <0F18A249-5480-42D9-BFF2-538AC7B9E1EB@oucs.ox.ac.uk> <4F92F34D.2040103@uvic.ca> <4F9579A0.8010002@oucs.ox.ac.uk> <4F9592D1.30207@kcl.ac.uk> Message-ID: <4F9593AD.2000403@ultraslavonic.info> Whereas in past meetings Lou and/or others would add comments to tickets directly as we discussed them, at this meeting we generally recorded decisions only in the minutes (which are in a Google Docs file that Becky shared a week ago). So you have to look for your initials to find any tasks assigned to you and then see what the decision reached was. On 4/23/2012 1:35 PM, Gabriel BODARD wrote: > In terms of doing the release tech, I guess I need to put aside at least > a day to work through this, and it doesn't matter much to me when that > day is, so that's fine. > > I'm now just trying to remember if there were any tickets assigned to me > in the meantime, and if I'll have time to complete them by May 20. I was > going to look into the guidelines-wide impact of something, but I don't > recall exactly what. Did someone add a note to the ticket in question? > (And in what may be the answer to the same or may be a completely > unrelated question, could someone update http://purl.com/tei/fr/3416130 > with the current state of Council thinking after Ann Arbor, please?) > > (Incidentally, I think http://purl.com/TEI/BUGS/3496949 has been > erroneously assigned to me--I don't think I know what we're meant to do > with this.) > > Gabby > > On 23/04/2012 16:47, James Cummings wrote: >> >> How about we set a notional target release date of 25 May? (This >> is about 5 weeks from now.) If we assume that we want most things >> completed by the end of Sunday 20th, to allow time for >> proofreading and error spotting. >> >> Does that sounds reasonable to most people? >> >> Gaby: Most importantly, does the proposed Release Technician like >> these dates? >> >> -James >> >> >> On 21/04/12 18:50, Martin Holmes wrote: >>> Three weeks will be a bit tough for me, and a couple of the tickets I >>> have might turn out to have unpredicted side-effects (like the tei_ >>> prefix). As long as we have the option to launch without the change if >>> it proves difficult, we could go with three weeks. >>> >>> The attributes-without-examples problem is so large that we'll just have >>> to hack away at it steadily. >>> >>> Cheers, >>> Martin >>> >>> On 12-04-21 04:03 AM, Sebastian Rahtz wrote: >>>> something we forgot to debate in Ann Arbor was a timetable >>>> for the next release, I think? i.e. what is the due date for >>>> everyone to complete their ticket work so that Sir Gabriel >>>> of B'odard can undertake his Quest. >>>> >>>> speaking for myself, if I don't do my assignments >>>> more or less immediately I will not get to them for ages, >>>> so I favour a short window (say, 3 weeks). >>>> >>>> Sebastian >> >> > From mholmes at uvic.ca Mon Apr 23 14:18:01 2012 From: mholmes at uvic.ca (Martin Holmes) Date: Mon, 23 Apr 2012 11:18:01 -0700 Subject: [tei-council] next release? In-Reply-To: <4F9593AD.2000403@ultraslavonic.info> References: <0F18A249-5480-42D9-BFF2-538AC7B9E1EB@oucs.ox.ac.uk> <4F92F34D.2040103@uvic.ca> <4F9579A0.8010002@oucs.ox.ac.uk> <4F9592D1.30207@kcl.ac.uk> <4F9593AD.2000403@ultraslavonic.info> Message-ID: <4F959CD9.8020201@uvic.ca> >> (Incidentally, I think http://purl.com/TEI/BUGS/3496949 has been >> erroneously assigned to me--I don't think I know what we're meant to do >> with this.) IIRC, we (James, Lou and I) assigned it to you because we thought you would have a good knowledge of the topic and clear views on it. Also because you weren't there to object, of course. Lou's comment, I think, records what we felt should be done: "Agreed to revise and expand example: firstly, use a straightforward witness; secondly add an example for the "unattested" case." Cheers, Martin On 12-04-23 10:38 AM, Kevin Hawkins wrote: > Whereas in past meetings Lou and/or others would add comments to tickets > directly as we discussed them, at this meeting we generally recorded > decisions only in the minutes (which are in a Google Docs file that > Becky shared a week ago). So you have to look for your initials to find > any tasks assigned to you and then see what the decision reached was. > > On 4/23/2012 1:35 PM, Gabriel BODARD wrote: >> In terms of doing the release tech, I guess I need to put aside at least >> a day to work through this, and it doesn't matter much to me when that >> day is, so that's fine. >> >> I'm now just trying to remember if there were any tickets assigned to me >> in the meantime, and if I'll have time to complete them by May 20. I was >> going to look into the guidelines-wide impact of something, but I don't >> recall exactly what. Did someone add a note to the ticket in question? >> (And in what may be the answer to the same or may be a completely >> unrelated question, could someone update http://purl.com/tei/fr/3416130 >> with the current state of Council thinking after Ann Arbor, please?) >> >> (Incidentally, I think http://purl.com/TEI/BUGS/3496949 has been >> erroneously assigned to me--I don't think I know what we're meant to do >> with this.) >> >> Gabby >> >> On 23/04/2012 16:47, James Cummings wrote: >>> >>> How about we set a notional target release date of 25 May? (This >>> is about 5 weeks from now.) If we assume that we want most things >>> completed by the end of Sunday 20th, to allow time for >>> proofreading and error spotting. >>> >>> Does that sounds reasonable to most people? >>> >>> Gaby: Most importantly, does the proposed Release Technician like >>> these dates? >>> >>> -James >>> >>> >>> On 21/04/12 18:50, Martin Holmes wrote: >>>> Three weeks will be a bit tough for me, and a couple of the tickets I >>>> have might turn out to have unpredicted side-effects (like the tei_ >>>> prefix). As long as we have the option to launch without the change if >>>> it proves difficult, we could go with three weeks. >>>> >>>> The attributes-without-examples problem is so large that we'll just have >>>> to hack away at it steadily. >>>> >>>> Cheers, >>>> Martin >>>> >>>> On 12-04-21 04:03 AM, Sebastian Rahtz wrote: >>>>> something we forgot to debate in Ann Arbor was a timetable >>>>> for the next release, I think? i.e. what is the due date for >>>>> everyone to complete their ticket work so that Sir Gabriel >>>>> of B'odard can undertake his Quest. >>>>> >>>>> speaking for myself, if I don't do my assignments >>>>> more or less immediately I will not get to them for ages, >>>>> so I favour a short window (say, 3 weeks). >>>>> >>>>> Sebastian >>> >>> >> -- Martin Holmes University of Victoria Humanities Computing and Media Centre (mholmes at uvic.ca) From mholmes at uvic.ca Mon Apr 23 14:48:15 2012 From: mholmes at uvic.ca (Martin Holmes) Date: Mon, 23 Apr 2012 11:48:15 -0700 Subject: [tei-council] Prefacing ids with "tei_" Message-ID: <4F95A3EF.7030509@uvic.ca> I'm planning to make a significant number of changes to Sebastian's stylesheets to implement our decision to preface all ids in the web output with "tei_", in an effort to avoid the problems caused by AdBlock Plus. Before I do, having looked at the code, there are a couple of things I wanted to get some feedback on: 1. Generated ids. There are some places in which ids in the output are generated using the XPath generate-id() function: <xsl:call-template name="makeAnchor"> <xsl:with-param name="name"> <xsl:value-of select="generate-id()"/> </xsl:with-param> </xsl:call-template> These result in ids that look like random sequences of characters. Do we need to preface these with "tei_"? My instinct says yes -- after all, such a random sequence is perfectly likely to end up with content which might trigger an AdBlock filter, so we might as well protect it in the normal way. 2. @n attributes. There's one place where the @n attribute can be used to create an id attribute in the output (in textstructure.xsl, code below). Should this also be prefaced by "tei_"? I'm not sure about this, because depending on the contents of the @n, the result might be puzzling. On the other hand, I don't think that @n can be relied upon to work as an id attribute anyway, can it? <xsl:variable name="identifier"> <xsl:text>App</xsl:text> <xsl:choose> <xsl:when test="@xml:id"> <xsl:value-of select="@xml:id"/> </xsl:when> <xsl:when test="@n"> <xsl:value-of select="@n"/> </xsl:when> <xsl:otherwise> <xsl:number count="tei:app" level="any"/> </xsl:otherwise> </xsl:choose> </xsl:variable> <xsl:choose> <xsl:when test="$footnoteFile='true'"> <a class="notelink" href="{$masterFile}-notes.html#{$identifier}"> <sup> <xsl:call-template name="appN"/> </sup> </a> </xsl:when> <xsl:otherwise> <a class="notelink" href="#{$identifier}"> <sup> <xsl:call-template name="appN"/> </sup> </a> </xsl:otherwise> </xsl:choose> Cheers, Martin -- Martin Holmes University of Victoria Humanities Computing and Media Centre (mholmes at uvic.ca) From bansp at o2.pl Mon Apr 23 17:15:21 2012 From: bansp at o2.pl (=?ISO-8859-2?Q?Piotr_Ba=F1ski?=) Date: Mon, 23 Apr 2012 23:15:21 +0200 Subject: [tei-council] Prefacing ids with "tei_" In-Reply-To: <4F95A3EF.7030509@uvic.ca> References: <4F95A3EF.7030509@uvic.ca> Message-ID: <4F95C669.7040709@o2.pl> Hi Martin, This may be a classic case of my missing the point, but something doesn't click in my mind, so I'd better comment on that, just in case: On 23/04/12 20:48, Martin Holmes wrote: > I'm planning to make a significant number of changes to Sebastian's > stylesheets to implement our decision to preface all ids in the web > output with "tei_", in an effort to avoid the problems caused by AdBlock > Plus. Before I do, having looked at the code, there are a couple of > things I wanted to get some feedback on: > > 1. Generated ids. There are some places in which ids in the output are > generated using the XPath generate-id() function: [..] > These result in ids that look like random sequences of characters. Do we > need to preface these with "tei_"? My instinct says yes -- after all, > such a random sequence is perfectly likely to end up with content which > might trigger an AdBlock filter, so we might as well protect it in the > normal way. I understood that "msad" triggered the false positive, and the (arguable and, IIRC, argued) decision was for the TEI to adjust to AdBlock. But if the problem was the matching of the entire string "msad" only (as opposed to "tei_msad"), then i am led to conclude that a substring match does not trigger the false positive. If that is true, then generated-ids() can't within reasonable probability generate an offensive string, and only that string (without extra characters). As to your second question, I'd say the prefix introduces a layer of safety indeed. But I'm not sure to what extent we as the Council need to bother of someone using silly @n atts as the basis for a silly algorithm of @n->@id. We might end up being overprotective here. Best, P. > > 2. @n attributes. There's one place where the @n attribute can be used > to create an id attribute in the output (in textstructure.xsl, code > below). Should this also be prefaced by "tei_"? I'm not sure about this, > because depending on the contents of the @n, the result might be > puzzling. On the other hand, I don't think that @n can be relied upon to > work as an id attribute anyway, can it? > > <xsl:variable name="identifier"> > <xsl:text>App</xsl:text> > <xsl:choose> > <xsl:when test="@xml:id"> > <xsl:value-of select="@xml:id"/> > </xsl:when> > <xsl:when test="@n"> > <xsl:value-of select="@n"/> > </xsl:when> > <xsl:otherwise> > <xsl:number count="tei:app" level="any"/> > </xsl:otherwise> > </xsl:choose> > </xsl:variable> > > <xsl:choose> > <xsl:when test="$footnoteFile='true'"> > <a class="notelink" href="{$masterFile}-notes.html#{$identifier}"> > <sup> > <xsl:call-template name="appN"/> > </sup> > </a> > </xsl:when> > <xsl:otherwise> > <a class="notelink" href="#{$identifier}"> > <sup> > <xsl:call-template name="appN"/> > </sup> > </a> > </xsl:otherwise> > </xsl:choose> > > Cheers, > Martin From bansp at o2.pl Mon Apr 23 17:20:33 2012 From: bansp at o2.pl (=?ISO-8859-2?Q?Piotr_Ba=F1ski?=) Date: Mon, 23 Apr 2012 23:20:33 +0200 Subject: [tei-council] next release? In-Reply-To: <4F9579A0.8010002@oucs.ox.ac.uk> References: <0F18A249-5480-42D9-BFF2-538AC7B9E1EB@oucs.ox.ac.uk> <4F92F34D.2040103@uvic.ca> <4F9579A0.8010002@oucs.ox.ac.uk> Message-ID: <4F95C7A1.1080707@o2.pl> Hi James, Isn't May 25 roughly in the middle of LREC? Could we shift by a week from then, please? (I actually intend to be ready with my stuff [and possibly more] in advance this time, but I've made some such totally honest promises to myself and to the world recently, several times, and with meager results...) Ah. Will we telco before releasing? Best, P. On 23/04/12 17:47, James Cummings wrote: > > How about we set a notional target release date of 25 May? (This > is about 5 weeks from now.) If we assume that we want most things > completed by the end of Sunday 20th, to allow time for > proofreading and error spotting. > > Does that sounds reasonable to most people? > > Gaby: Most importantly, does the proposed Release Technician like > these dates? > > -James > > > On 21/04/12 18:50, Martin Holmes wrote: >> Three weeks will be a bit tough for me, and a couple of the tickets I >> have might turn out to have unpredicted side-effects (like the tei_ >> prefix). As long as we have the option to launch without the change if >> it proves difficult, we could go with three weeks. >> >> The attributes-without-examples problem is so large that we'll just have >> to hack away at it steadily. >> >> Cheers, >> Martin >> >> On 12-04-21 04:03 AM, Sebastian Rahtz wrote: >>> something we forgot to debate in Ann Arbor was a timetable >>> for the next release, I think? i.e. what is the due date for >>> everyone to complete their ticket work so that Sir Gabriel >>> of B'odard can undertake his Quest. >>> >>> speaking for myself, if I don't do my assignments >>> more or less immediately I will not get to them for ages, >>> so I favour a short window (say, 3 weeks). >>> >>> Sebastian > > From mholmes at uvic.ca Mon Apr 23 17:43:46 2012 From: mholmes at uvic.ca (Martin Holmes) Date: Mon, 23 Apr 2012 14:43:46 -0700 Subject: [tei-council] Prefacing ids with "tei_" In-Reply-To: <4F95C669.7040709@o2.pl> References: <4F95A3EF.7030509@uvic.ca> <4F95C669.7040709@o2.pl> Message-ID: <4F95CD12.9070904@uvic.ca> On 12-04-23 02:15 PM, Piotr Ba?ski wrote: > Hi Martin, > > This may be a classic case of my missing the point, but something > doesn't click in my mind, so I'd better comment on that, just in case: > > On 23/04/12 20:48, Martin Holmes wrote: >> I'm planning to make a significant number of changes to Sebastian's >> stylesheets to implement our decision to preface all ids in the web >> output with "tei_", in an effort to avoid the problems caused by AdBlock >> Plus. Before I do, having looked at the code, there are a couple of >> things I wanted to get some feedback on: >> >> 1. Generated ids. There are some places in which ids in the output are >> generated using the XPath generate-id() function: > [..] >> These result in ids that look like random sequences of characters. Do we >> need to preface these with "tei_"? My instinct says yes -- after all, >> such a random sequence is perfectly likely to end up with content which >> might trigger an AdBlock filter, so we might as well protect it in the >> normal way. > > I understood that "msad" triggered the false positive, and the (arguable > and, IIRC, argued) decision was for the TEI to adjust to AdBlock. Yes, the false positive was triggered by "msad". > But if the problem was the matching of the entire string "msad" only (as > opposed to "tei_msad"), then i am led to conclude that a substring match > does not trigger the false positive. If that is true, then > generated-ids() can't within reasonable probability generate an > offensive string, and only that string (without extra characters). It is possible to use regular expressions in Adblock Plus lists, so partial matches may trigger a block. If this happens, one advantage of our tei_ prefix will be that we can ask filter list writers to refine their regexp to exclude our ids, using the prefix, while still remaining able to block their original target. I think given that option, they'll be more likely to respond to bug reports from us. > As to your second question, I'd say the prefix introduces a layer of > safety indeed. But I'm not sure to what extent we as the Council need to > bother of someone using silly @n atts as the basis for a silly algorithm > of @n->@id. We might end up being overprotective here. True. On consideration, I think we should add the prefix in all cases, for the sake of consistency. Cheers, Martin > Best, > > P. > > > >> >> 2. @n attributes. There's one place where the @n attribute can be used >> to create an id attribute in the output (in textstructure.xsl, code >> below). Should this also be prefaced by "tei_"? I'm not sure about this, >> because depending on the contents of the @n, the result might be >> puzzling. On the other hand, I don't think that @n can be relied upon to >> work as an id attribute anyway, can it? >> >> <xsl:variable name="identifier"> >> <xsl:text>App</xsl:text> >> <xsl:choose> >> <xsl:when test="@xml:id"> >> <xsl:value-of select="@xml:id"/> >> </xsl:when> >> <xsl:when test="@n"> >> <xsl:value-of select="@n"/> >> </xsl:when> >> <xsl:otherwise> >> <xsl:number count="tei:app" level="any"/> >> </xsl:otherwise> >> </xsl:choose> >> </xsl:variable> >> >> <xsl:choose> >> <xsl:when test="$footnoteFile='true'"> >> <a class="notelink" href="{$masterFile}-notes.html#{$identifier}"> >> <sup> >> <xsl:call-template name="appN"/> >> </sup> >> </a> >> </xsl:when> >> <xsl:otherwise> >> <a class="notelink" href="#{$identifier}"> >> <sup> >> <xsl:call-template name="appN"/> >> </sup> >> </a> >> </xsl:otherwise> >> </xsl:choose> >> >> Cheers, >> Martin > -- Martin Holmes University of Victoria Humanities Computing and Media Centre (mholmes at uvic.ca) From sebastian.rahtz at oucs.ox.ac.uk Mon Apr 23 18:18:04 2012 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 23 Apr 2012 22:18:04 +0000 Subject: [tei-council] Prefacing ids with "tei_" In-Reply-To: <4F95A3EF.7030509@uvic.ca> References: <4F95A3EF.7030509@uvic.ca> Message-ID: <2C467D4E-E07E-4BDA-B76A-8EEA113BB12C@oucs.ox.ac.uk> On 23 Apr 2012, at 19:48, Martin Holmes wrote: > > 1. Generated ids. There are some places in which ids in the output are > generated using the XPath generate-id() function: > > <xsl:call-template name="makeAnchor"> > <xsl:with-param name="name"> > <xsl:value-of select="generate-id()"/> > </xsl:with-param> > </xsl:call-template> in practice generate-id() creates a single letter followed by a number, so I think you could leave them alone. If Adblock looks for "MSAD" in the _middle_ of a string, then it will be triggered by "tei_MSAD", after all! > 2. @n attributes. There's one place where the @n attribute can be used > to create an id attribute in the output (in textstructure.xsl, code > below) this looks like a step too far. I have removed that <when> clause. the HTML @id is already prefixed by "App", so no need to change it. Sebastian From syeates at gmail.com Mon Apr 23 19:38:23 2012 From: syeates at gmail.com (Stuart A. Yeates) Date: Tue, 24 Apr 2012 11:38:23 +1200 Subject: [tei-council] Attributes without examples In-Reply-To: <4F9584B7.3080302@uvic.ca> References: <4F908F22.4070908@uvic.ca> <4F90AD72.10605@uvic.ca> <4F90AEBC.6000608@ultraslavonic.info> <4F9573BF.1080302@uvic.ca> <4F957C03.8090008@oucs.ox.ac.uk> <4F9580F6.4080505@uvic.ca> <4F9584B7.3080302@uvic.ca> Message-ID: <CAC_Lu0aeSZBOpxEK6zndQ99jhiV-aMZfcbupkqe8jxmnwOibsw@mail.gmail.com> I've just tarted the wiki page up a little, making the table sortable by arbitrary columns, linking to the ticket, etc. cheers stuart On Tue, Apr 24, 2012 at 4:35 AM, Martin Holmes <mholmes at uvic.ca> wrote: > I've created a ticket for this too, so we don't lose track of it: > > <http://purl.org/TEI/BUGS/3520704> > > Cheers, > Martin > > On 12-04-23 09:19 AM, Martin Holmes wrote: >> Thanks James -- that works. I have to write that down somewhere. I >> wonder why spambots wouldn't use<nowiki/> ?themselves. >> >> Here's the page -- feel free to sign up for one or more attributes by >> editing it: >> >> <http://wiki.tei-c.org/index.php/AttsWithoutEgs> >> >> Cheers, >> Martin >> >> On 12-04-23 08:57 AM, James Cummings wrote: >>> >>> Martin, >>> >>> It is simple but intentionally not documented. Interrupt the spam >>> word with an element. Specifically use<nowiki/> ? so >>> att.ms<nowiki/>Excerpt will allow you to get around the spam filter. >>> >>> Just don't advertise via<nowiki/>gra too much. >>> >>> -James >>> >>> On 23/04/12 16:22, Martin Holmes wrote: >>>> I've just tried to create a wiki page which has a table listing all >>>> these attributes, but I've been prevented from doing so by the sad >>>> little spam filter, which won't allow this: >>>> >>>> att.msExcerpt >>>> >>>> because it contains "sEx". >>>> >>>> I seem to remember having spent a frustrating time fighting with this >>>> stupidity some time ago. Does anyone remember how to get around this, or >>>> is it pointless to try? >>>> >>>> Cheers, >>>> Martin >>>> >>>> On 12-04-19 05:33 PM, Kevin Hawkins wrote: >>>>> Would you be able to output as a table with a third column for people to >>>>> sign up, either in MediaWiki or HTML syntax, for a page in the wiki? >>>>> >>>>> On 4/19/12 8:27 PM, Martin Holmes wrote: >>>>>> Below is another slightly shorter list. These are attributes which do >>>>>> not appear on any examples in the<elementSpec> ? ? ?or<classSpec> ? ? ?in which >>>>>> they're defined. Not that this doesn't mean there are no examples at all >>>>>> for them; there may be an example somewhere in the Guidelines text, or >>>>>> the attribute may be defined in a<classSpec> ? ? ?for an attribute class, >>>>>> and then show up in an example in an<elementSpec> ? ? ?for an element which >>>>>> belongs to that class. An example of the latter is @agent (att.damaged), >>>>>> which has no example in the att.damaged<classSpec>, but happens to show >>>>>> up in an example for the<damage> ? ? ?element. >>>>>> >>>>>> Nevertheless, I think it would be a good idea to try to provide examples >>>>>> for all these attributes, in the files which define them. >>>>>> >>>>>> ATTRIBUTES WHICH DO NOT SHOW UP ON ANY EXAMPLE IN THEIR elementSpec OR >>>>>> classSpec AS OF 2012-04-19T17:19:17.315-07:00 >>>>>> >>>>>> 1. absolute (when) >>>>>> 2. adj (node) >>>>>> 3. adjFrom (node) >>>>>> 4. adjTo (node) >>>>>> 5. age (personGrp) >>>>>> 6. agent (att.damaged) >>>>>> 7. agent (gap) >>>>>> 8. agent (unclear) >>>>>> 9. ana (att.global.analytic) >>>>>> 10. atLeast (att.ranging) >>>>>> 11. atMost (att.ranging) >>>>>> 12. attachment (surface) >>>>>> 13. autoPrefix (content) >>>>>> 14. baseTypes (fsDecl) >>>>>> 15. break (att.breaking) >>>>>> 16. cRef (gloss) >>>>>> 17. cRef (ptr) >>>>>> 18. cRef (ref) >>>>>> 19. cRef (term) >>>>>> 20. cause (att.textCritical) >>>>>> 21. cause (att.transcriptional) >>>>>> 22. cert (att.responsibility) >>>>>> 23. change (att.global.change) >>>>>> 24. class (msContents) >>>>>> 25. cols (att.tableDecoration) >>>>>> 26. confidence (att.ranging) >>>>>> 27. contemporary (seal) >>>>>> 28. copyOf (att.global.linking) >>>>>> 29. corresp (att.global.linking) >>>>>> 30. datingMethod (att.datable.custom) >>>>>> 31. datingPoint (att.datable.custom) >>>>>> 32. decls (att.declaring) >>>>>> 33. default (att.declarable) >>>>>> 34. defective (att.msExcerpt) >>>>>> 35. degree (att.damaged) >>>>>> 36. degree (node) >>>>>> 37. dim (space) >>>>>> 38. direct (said) >>>>>> 39. docLang (schemaSpec) >>>>>> 40. domains (att.pointing.group) >>>>>> 41. dur (att.duration.w3c) >>>>>> 42. dur-iso (att.duration.iso) >>>>>> 43. encoding (binaryObject) >>>>>> 44. end (att.timed) >>>>>> 45. enjamb (att.enjamb) >>>>>> 46. evaluate (att.pointing) >>>>>> 47. evidence (att.editLike) >>>>>> 48. except (moduleRef) >>>>>> 49. exclude (att.global.linking) >>>>>> 50. expand (att.lexicographic) >>>>>> 51. extent (orth) >>>>>> 52. fVal (f) >>>>>> 53. facs (att.global.facs) >>>>>> 54. feats (fs) >>>>>> 55. filter (equiv) >>>>>> 56. flipping (surface) >>>>>> 57. follow (leaf) >>>>>> 58. force (pc) >>>>>> 59. from (app) >>>>>> 60. from (att.datable.w3c) >>>>>> 61. from-custom (att.datable.custom) >>>>>> 62. from-iso (att.datable.iso) >>>>>> 63. full (att.personal) >>>>>> 64. function (att.segLike) >>>>>> 65. generate (classSpec) >>>>>> 66. gradual (writing) >>>>>> 67. group (att.damaged) >>>>>> 68. hand (att.damaged) >>>>>> 69. hand (att.textCritical) >>>>>> 70. hand (att.transcriptional) >>>>>> 71. hand (gap) >>>>>> 72. hand (unclear) >>>>>> 73. height (binaryObject) >>>>>> 74. height (graphic) >>>>>> 75. ident (att.identified) >>>>>> 76. inst (att.interpLike) >>>>>> 77. instant (att.editLike) >>>>>> 78. key (att.canonical) >>>>>> 79. key (classRef) >>>>>> 80. key (macroRef) >>>>>> 81. level (sense) >>>>>> 82. level (title) >>>>>> 83. loc (app) >>>>>> 84. location (att.lexicographic) >>>>>> 85. lrx (att.coordinated) >>>>>> 86. lry (att.coordinated) >>>>>> 87. match (att.scoping) >>>>>> 88. material (supportDesc) >>>>>> 89. max (att.ranging) >>>>>> 90. max (memberOf) >>>>>> 91. medium (att.handFeatures) >>>>>> 92. mergedIn (att.lexicographic) >>>>>> 93. met (att.metrical) >>>>>> 94. method (correction) >>>>>> 95. mimeType (att.internetMedia) >>>>>> 96. min (att.ranging) >>>>>> 97. min (memberOf) >>>>>> 98. mode (att.combinable) >>>>>> 99. mode (classes) >>>>>> 100. mode (memberOf) >>>>>> 101. module (att.identified) >>>>>> 102. new (handShift) >>>>>> 103. next (att.global.linking) >>>>>> 104. notAfter-custom (att.datable.custom) >>>>>> 105. notAfter-iso (att.datable.iso) >>>>>> 106. notBefore-custom (att.datable.custom) >>>>>> 107. notBefore-iso (att.datable.iso) >>>>>> 108. notation (pron) >>>>>> 109. ns (attDef) >>>>>> 110. ns (elementSpec) >>>>>> 111. ns (schemaSpec) >>>>>> 112. nymRef (att.naming) >>>>>> 113. opt (att.lexicographic) >>>>>> 114. optional (fDecl) >>>>>> 115. ord (iNode) >>>>>> 116. ord (root) >>>>>> 117. org (att.divLike) >>>>>> 118. org (attList) >>>>>> 119. orig (att.lexicographic) >>>>>> 120. part (ab) >>>>>> 121. part (att.divLike) >>>>>> 122. part (att.segLike) >>>>>> 123. parts (nym) >>>>>> 124. perf (tech) >>>>>> 125. period (att.datable) >>>>>> 126. pre (pc) >>>>>> 127. precision (att.dimensions) >>>>>> 128. predeclare (att.identified) >>>>>> 129. prefix (elementSpec) >>>>>> 130. prefix (moduleRef) >>>>>> 131. prev (att.global.linking) >>>>>> 132. quantity (att.dimensions) >>>>>> 133. real (att.metrical) >>>>>> 134. ref (att.canonical) >>>>>> 135. refLang (att.pointing) >>>>>> 136. resp (att.responsibility) >>>>>> 137. resp (space) >>>>>> 138. rhyme (att.metrical) >>>>>> 139. role (att.naming) >>>>>> 140. role (att.tableDecoration) >>>>>> 141. role (org) >>>>>> 142. rotate (zone) >>>>>> 143. rows (att.tableDecoration) >>>>>> 144. sameAs (att.global.linking) >>>>>> 145. sample (att.divLike) >>>>>> 146. scale (binaryObject) >>>>>> 147. scale (graphic) >>>>>> 148. scheme (catRef) >>>>>> 149. scheme (locus) >>>>>> 150. scheme (locusGrp) >>>>>> 151. scheme (tag) >>>>>> 152. scope (att.dimensions) >>>>>> 153. scope (att.handFeatures) >>>>>> 154. scribe (att.handFeatures) >>>>>> 155. scribeRef (att.handFeatures) >>>>>> 156. script (att.handFeatures) >>>>>> 157. scriptRef (att.handFeatures) >>>>>> 158. select (att.global.linking) >>>>>> 159. seq (att.transcriptional) >>>>>> 160. social (distinct) >>>>>> 161. sort (att.personal) >>>>>> 162. source (att.editLike) >>>>>> 163. source (att.readFrom) >>>>>> 164. source (writing) >>>>>> 165. space (distinct) >>>>>> 166. spanTo (att.spanning) >>>>>> 167. split (att.lexicographic) >>>>>> 168. start (att.coordinated) >>>>>> 169. start (att.timed) >>>>>> 170. status (att.identified) >>>>>> 171. status (att.transcriptional) >>>>>> 172. status (correction) >>>>>> 173. stdDeviation (precision) >>>>>> 174. subtype (att.typed) >>>>>> 175. synch (att.global.linking) >>>>>> 176. targFunc (att.pointing.group) >>>>>> 177. target (change) >>>>>> 178. target (relatedItem) >>>>>> 179. targetEnd (note) >>>>>> 180. targetLang (schemaSpec) >>>>>> 181. targets (alt) >>>>>> 182. targets (join) >>>>>> 183. targets (link) >>>>>> 184. time (distinct) >>>>>> 185. to (app) >>>>>> 186. to (att.datable.w3c) >>>>>> 187. to-custom (att.datable.custom) >>>>>> 188. to-iso (att.datable.iso) >>>>>> 189. type (abbr) >>>>>> 190. type (att.entryLike) >>>>>> 191. type (att.interpLike) >>>>>> 192. type (att.textCritical) >>>>>> 193. type (att.typed) >>>>>> 194. type (form) >>>>>> 195. type (q) >>>>>> 196. type (sound) >>>>>> 197. ulx (att.coordinated) >>>>>> 198. uly (att.coordinated) >>>>>> 199. unit (att.dimensions) >>>>>> 200. unit (pc) >>>>>> 201. unit (when) >>>>>> 202. url (moduleRef) >>>>>> 203. value (att.lexicographic) >>>>>> 204. value (eTree) >>>>>> 205. value (iNode) >>>>>> 206. value (leaf) >>>>>> 207. value (node) >>>>>> 208. value (root) >>>>>> 209. value (triangle) >>>>>> 210. varSeq (att.textCritical) >>>>>> 211. version (unicodeName) >>>>>> 212. versionDate (att.translatable) >>>>>> 213. when (docDate) >>>>>> 214. where (event) >>>>>> 215. who (att.ascribed) >>>>>> 216. width (binaryObject) >>>>>> 217. width (graphic) >>>>>> 218. wit (att.rdgPart) >>>>>> 219. wit (att.witnessed) >>>>>> 220. xml:base (att.global) >>>>>> 221. xml:id (att.global) >>>>>> 222. xml:lang (att.global) >>>>>> 223. xml:space (att.global) >>>>>> >>>>>> Cheers, >>>>>> Martin >>>>>> >>>>>> On 12-04-19 03:18 PM, Martin Holmes wrote: >>>>>>> Following on from our discussion of examples for attributes, a >>>>>>> quick-and-dirty XSLT seems to show that there are only 19 attributes >>>>>>> with their own examples, and 450 without. This is not to say that those >>>>>>> without are unexemplified, because the example code for their parent >>>>>>> elements in the elementSpec may show examples of them; I'll refine the >>>>>>> XSLT and make that apparent. >>>>>>> >>>>>>> Here's the list: >>>>>>> >>>>>>> ATTRIBUTE DEFINITIONS LACKING EXAMPLES AS OF 2012-04-19T15:12:34.968-07:00 >>>>>>> >>>>>>> 1. status (att.identified) >>>>>>> 2. type (interaction) >>>>>>> 3. value (sex) >>>>>>> 4. scale (graphic) >>>>>>> 5. scale (binaryObject) >>>>>>> 6. weights (alt) >>>>>>> 7. hand (att.damaged) >>>>>>> 8. agent (gap) >>>>>>> 9. predeclare (att.identified) >>>>>>> 10. degree (att.damaged) >>>>>>> 11. module (att.identified) >>>>>>> 12. ident (att.identified) >>>>>>> 13. height (graphic) >>>>>>> 14. height (binaryObject) >>>>>>> 15. width (graphic) >>>>>>> 16. width (binaryObject) >>>>>>> 17. encoding (binaryObject) >>>>>>> 18. version (teiCorpus) >>>>>>> 19. hand (unclear) >>>>>>> 20. agent (unclear) >>>>>>> 21. feature (shift) >>>>>>> 22. type (preparedness) >>>>>>> 23. type (abbr) >>>>>>> 24. commodity (att.measurement) >>>>>>> 25. agent (att.damaged) >>>>>>> 26. type (derivation) >>>>>>> 27. type (domain) >>>>>>> 28. type (factuality) >>>>>>> 29. type (idno) >>>>>>> 30. type (relation) >>>>>>> 31. type (sound) >>>>>>> 32. type (tech) >>>>>>> 33. type (castItem) >>>>>>> 34. type (att.typed) >>>>>>> 35. type (move) >>>>>>> 36. script (att.handFeatures) >>>>>>> 37. class (msItemStruct) >>>>>>> 38. class (msItem) >>>>>>> 39. class (msContents) >>>>>>> 40. type (form) >>>>>>> 41. cause (att.textCritical) >>>>>>> 42. type (gram) >>>>>>> 43. type (lbl) >>>>>>> 44. type (att.textCritical) >>>>>>> 45. type (title) >>>>>>> 46. type (titlePage) >>>>>>> 47. type (usg) >>>>>>> 48. type (app) >>>>>>> 49. columns (layout) >>>>>>> 50. valueDatcat (att.datcat) >>>>>>> 51. datcat (att.datcat) >>>>>>> 52. contemporary (seal) >>>>>>> 53. contemporary (binding) >>>>>>> 54. from (locus) >>>>>>> 55. type (list) >>>>>>> 56. result (joinGrp) >>>>>>> 57. medium (att.handFeatures) >>>>>>> 58. type (graph) >>>>>>> 59. type (witDetail) >>>>>>> 60. origin (timeline) >>>>>>> 61. function (att.segLike) >>>>>>> 62. form (objectDesc) >>>>>>> 63. mergedIn (att.lexicographic) >>>>>>> 64. type (fsDecl) >>>>>>> 65. scribe (att.handFeatures) >>>>>>> 66. degree (node) >>>>>>> 67. extent (orth) >>>>>>> 68. from (arc) >>>>>>> 69. to (arc) >>>>>>> 70. inDegree (node) >>>>>>> 71. arity (tree) >>>>>>> 72. baseTypes (fsDecl) >>>>>>> 73. level (sense) >>>>>>> 74. order (tree) >>>>>>> 75. outDegree (iNode) >>>>>>> 76. outDegree (node) >>>>>>> 77. outDegree (root) >>>>>>> 78. reason (gap) >>>>>>> 79. type (orth) >>>>>>> 80. when (docDate) >>>>>>> 81. split (att.lexicographic) >>>>>>> 82. code (socecStatus) >>>>>>> 83. code (occupation) >>>>>>> 84. decls (att.declaring) >>>>>>> 85. cRef (term) >>>>>>> 86. from (app) >>>>>>> 87. scheme (catRef) >>>>>>> 88. scheme (occupation) >>>>>>> 89. scheme (classCode) >>>>>>> 90. scheme (socecStatus) >>>>>>> 91. scheme (keywords) >>>>>>> 92. to (app) >>>>>>> 93. baseForm (m) >>>>>>> 94. new (handShift) >>>>>>> 95. passive (relation) >>>>>>> 96. since (when) >>>>>>> 97. type (fsdLink) >>>>>>> 98. type (biblScope) >>>>>>> 99. type (listForest) >>>>>>> 100. type (forest) >>>>>>> 101. hand (gap) >>>>>>> 102. given (certainty) >>>>>>> 103. locus (certainty) >>>>>>> 104. type (rs) >>>>>>> 105. source (normalization) >>>>>>> 106. level (title) >>>>>>> 107. degree (certainty) >>>>>>> 108. status (correction) >>>>>>> 109. degree (precision) >>>>>>> 110. spanTo (att.spanning) >>>>>>> 111. to (att.datable.w3c) >>>>>>> 112. to-iso (att.datable.iso) >>>>>>> 113. force (pc) >>>>>>> 114. reason (surplus) >>>>>>> 115. type (stage) >>>>>>> 116. type (oRef) >>>>>>> 117. type (oVar) >>>>>>> 118. method (correction) >>>>>>> 119. method (normalization) >>>>>>> 120. name (fDecl) >>>>>>> 121. evidence (att.editLike) >>>>>>> 122. rows (table) >>>>>>> 123. org (vMerge) >>>>>>> 124. who (att.ascribed) >>>>>>> 125. locus (respons) >>>>>>> 126. from-custom (att.datable.custom) >>>>>>> 127. from (att.datable.w3c) >>>>>>> 128. from-iso (att.datable.iso) >>>>>>> 129. type (xr) >>>>>>> 130. type (iType) >>>>>>> 131. type (num) >>>>>>> 132. type (att.entryLike) >>>>>>> 133. type (att.interpLike) >>>>>>> 134. unit (refState) >>>>>>> 135. notation (pron) >>>>>>> 136. break (att.breaking) >>>>>>> 137. iterated (kinesic) >>>>>>> 138. iterated (vocal) >>>>>>> 139. optional (fDecl) >>>>>>> 140. default (att.declarable) >>>>>>> 141. location (variantEncoding) >>>>>>> 142. anchored (note) >>>>>>> 143. full (att.personal) >>>>>>> 144. type (metDecl) >>>>>>> 145. extent (pron) >>>>>>> 146. discrete (sound) >>>>>>> 147. scope (join) >>>>>>> 148. gradual (writing) >>>>>>> 149. sample (att.divLike) >>>>>>> 150. type (classSpec) >>>>>>> 151. pre (pc) >>>>>>> 152. type (dimensions) >>>>>>> 153. method (variantEncoding) >>>>>>> 154. type (macroSpec) >>>>>>> 155. reason (supplied) >>>>>>> 156. to (locus) >>>>>>> 157. rows (att.tableDecoration) >>>>>>> 158. writtenLines (layout) >>>>>>> 159. ruledLines (layout) >>>>>>> 160. location (att.lexicographic) >>>>>>> 161. hands (handDesc) >>>>>>> 162. material (supportDesc) >>>>>>> 163. notation (formula) >>>>>>> 164. unit (att.dimensions) >>>>>>> 165. ns (attDef) >>>>>>> 166. ns (elementSpec) >>>>>>> 167. domains (att.pointing.group) >>>>>>> 168. part (att.segLike) >>>>>>> 169. source (writing) >>>>>>> 170. ref (g) >>>>>>> 171. scribeRef (att.handFeatures) >>>>>>> 172. scriptRef (att.handFeatures) >>>>>>> 173. copyOf (att.global.linking) >>>>>>> 174. sameAs (att.global.linking) >>>>>>> 175. exclude (att.global.linking) >>>>>>> 176. targetEnd (note) >>>>>>> 177. next (att.global.linking) >>>>>>> 178. target (relatedItem) >>>>>>> 179. unit (milestone) >>>>>>> 180. label (rhyme) >>>>>>> 181. lemma (w) >>>>>>> 182. children (iNode) >>>>>>> 183. children (root) >>>>>>> 184. name (f) >>>>>>> 185. unit (pc) >>>>>>> 186. value (leaf) >>>>>>> 187. type (node) >>>>>>> 188. key (att.canonical) >>>>>>> 189. follow (iNode) >>>>>>> 190. follow (leaf) >>>>>>> 191. parent (leaf) >>>>>>> 192. parent (iNode) >>>>>>> 193. value (node) >>>>>>> 194. value (triangle) >>>>>>> 195. value (eLeaf) >>>>>>> 196. value (eTree) >>>>>>> 197. value (iNode) >>>>>>> 198. value (root) >>>>>>> 199. quantity (att.measurement) >>>>>>> 200. role (att.tableDecoration) >>>>>>> 201. scheme (att) >>>>>>> 202. select (att.global.linking) >>>>>>> 203. xml:space (att.global) >>>>>>> 204. hand (att.textCritical) >>>>>>> 205. subtype (att.typed) >>>>>>> 206. prefix (schemaSpec) >>>>>>> 207. prefix (elementSpec) >>>>>>> 208. type (purpose) >>>>>>> 209. role (org) >>>>>>> 210. role (person) >>>>>>> 211. matchPattern (cRefPattern) >>>>>>> 212. replacementPattern (cRefPattern) >>>>>>> 213. age (person) >>>>>>> 214. start (schemaSpec) >>>>>>> 215. form (quotation) >>>>>>> 216. time (distinct) >>>>>>> 217. social (distinct) >>>>>>> 218. space (distinct) >>>>>>> 219. type (constitution) >>>>>>> 220. scope (att.handFeatures) >>>>>>> 221. age (personGrp) >>>>>>> 222. usage (language) >>>>>>> 223. ident (valItem) >>>>>>> 224. from (span) >>>>>>> 225. value (metSym) >>>>>>> 226. versionDate (att.translatable) >>>>>>> 227. target (att.pointing) >>>>>>> 228. where (move) >>>>>>> 229. notBefore (att.datable.w3c) >>>>>>> 230. notBefore-custom (att.datable.custom) >>>>>>> 231. notBefore-iso (att.datable.iso) >>>>>>> 232. mode (classes) >>>>>>> 233. mode (att.combinable) >>>>>>> 234. mode (memberOf) >>>>>>> 235. to (span) >>>>>>> 236. to (biblScope) >>>>>>> 237. type (valList) >>>>>>> 238. degree (purpose) >>>>>>> 239. length (refState) >>>>>>> 240. render (tagUsage) >>>>>>> 241. targets (alt) >>>>>>> 242. targets (join) >>>>>>> 243. targets (link) >>>>>>> 244. type (teiHeader) >>>>>>> 245. notAfter (att.datable.w3c) >>>>>>> 246. notAfter-custom (att.datable.custom) >>>>>>> 247. notAfter-iso (att.datable.iso) >>>>>>> 248. version (TEI) >>>>>>> 249. mode (channel) >>>>>>> 250. result (join) >>>>>>> 251. new (shift) >>>>>>> 252. active (interaction) >>>>>>> 253. occurs (tagUsage) >>>>>>> 254. passive (interaction) >>>>>>> 255. interval (when) >>>>>>> 256. interval (timeline) >>>>>>> 257. usage (attDef) >>>>>>> 258. role (personGrp) >>>>>>> 259. type (titlePart) >>>>>>> 260. sex (personGrp) >>>>>>> 261. sex (person) >>>>>>> 262. size (personGrp) >>>>>>> 263. from (biblScope) >>>>>>> 264. type (distinct) >>>>>>> 265. type (measure) >>>>>>> 266. type (fs) >>>>>>> 267. unit (timeline) >>>>>>> 268. unit (when) >>>>>>> 269. version (unicodeName) >>>>>>> 270. type (divGen) >>>>>>> 271. part (ab) >>>>>>> 272. part (att.divLike) >>>>>>> 273. part (l) >>>>>>> 274. terminal (metSym) >>>>>>> 275. trunc (numeric) >>>>>>> 276. order (graph) >>>>>>> 277. size (graph) >>>>>>> 278. mode (alt) >>>>>>> 279. mode (altGrp) >>>>>>> 280. value (binary) >>>>>>> 281. status (availability) >>>>>>> 282. datum (geoDecl) >>>>>>> 283. value (numeric) >>>>>>> 284. name (relation) >>>>>>> 285. name (vLabel) >>>>>>> 286. indexName (index) >>>>>>> 287. stdDeviation (precision) >>>>>>> 288. absolute (when) >>>>>>> 289. max (numeric) >>>>>>> 290. scheme (constraintSpec) >>>>>>> 291. scheme (tag) >>>>>>> 292. scheme (gi) >>>>>>> 293. value (symbol) >>>>>>> 294. value (num) >>>>>>> 295. scheme (locusGrp) >>>>>>> 296. scheme (locus) >>>>>>> 297. name (namespace) >>>>>>> 298. type (recording) >>>>>>> 299. unit (att.measurement) >>>>>>> 300. value (att.lexicographic) >>>>>>> 301. scope (att.dimensions) >>>>>>> 302. evaluate (att.pointing) >>>>>>> 303. active (relation) >>>>>>> 304. to-custom (att.datable.custom) >>>>>>> 305. mutual (relation) >>>>>>> 306. dur-iso (att.duration.iso) >>>>>>> 307. instant (att.editLike) >>>>>>> 308. function (metamark) >>>>>>> 309. attachment (surface) >>>>>>> 310. cause (att.transcriptional) >>>>>>> 311. target (metamark) >>>>>>> 312. rotate (zone) >>>>>>> 313. target (redo) >>>>>>> 314. target (undo) >>>>>>> 315. except (moduleRef) >>>>>>> 316. include (moduleRef) >>>>>>> 317. datingMethod (att.datable.custom) >>>>>>> 318. datingPoint (att.datable.custom) >>>>>>> 319. key (moduleRef) >>>>>>> 320. url (moduleRef) >>>>>>> 321. mimeType (att.internetMedia) >>>>>>> 322. version (application) >>>>>>> 323. ident (application) >>>>>>> 324. confidence (att.ranging) >>>>>>> 325. level (langKnown) >>>>>>> 326. adj (node) >>>>>>> 327. adjFrom (node) >>>>>>> 328. adjTo (node) >>>>>>> 329. ana (att.global.analytic) >>>>>>> 330. group (att.damaged) >>>>>>> 331. cRef (gloss) >>>>>>> 332. cRef (ptr) >>>>>>> 333. cRef (ref) >>>>>>> 334. cert (att.responsibility) >>>>>>> 335. cert (certainty) >>>>>>> 336. precision (precision) >>>>>>> 337. precision (att.dimensions) >>>>>>> 338. type (fw) >>>>>>> 339. cols (table) >>>>>>> 340. cols (att.tableDecoration) >>>>>>> 341. source (att.editLike) >>>>>>> 342. autoPrefix (content) >>>>>>> 343. corresp (att.global.linking) >>>>>>> 344. delim (refState) >>>>>>> 345. dim (space) >>>>>>> 346. docLang (schemaSpec) >>>>>>> 347. dur (att.duration.w3c) >>>>>>> 348. ed (att.sourced) >>>>>>> 349. gi (tagUsage) >>>>>>> 350. eol (hyphenation) >>>>>>> 351. enjamb (att.enjamb) >>>>>>> 352. facs (att.global.facs) >>>>>>> 353. fVal (f) >>>>>>> 354. feats (fs) >>>>>>> 355. lang (code) >>>>>>> 356. atMost (att.ranging) >>>>>>> 357. atLeast (att.ranging) >>>>>>> 358. lrx (att.coordinated) >>>>>>> 359. ulx (att.coordinated) >>>>>>> 360. lry (att.coordinated) >>>>>>> 361. uly (att.coordinated) >>>>>>> 362. xml:id (att.global) >>>>>>> 363. ident (language) >>>>>>> 364. scheme (rendition) >>>>>>> 365. status (att.transcriptional) >>>>>>> 366. where (event) >>>>>>> 367. start (att.timed) >>>>>>> 368. end (att.timed) >>>>>>> 369. type (tag) >>>>>>> 370. defective (att.msExcerpt) >>>>>>> 371. generate (classSpec) >>>>>>> 372. inst (att.interpLike) >>>>>>> 373. xml:lang (att.global) >>>>>>> 374. loc (app) >>>>>>> 375. mainLang (textLang) >>>>>>> 376. maxOccurs (datatype) >>>>>>> 377. type (q) >>>>>>> 378. direct (said) >>>>>>> 379. aloud (said) >>>>>>> 380. met (att.metrical) >>>>>>> 381. real (att.metrical) >>>>>>> 382. minOccurs (datatype) >>>>>>> 383. name (equiv) >>>>>>> 384. ns (schemaSpec) >>>>>>> 385. n (att.global) >>>>>>> 386. opt (att.lexicographic) >>>>>>> 387. ord (iNode) >>>>>>> 388. ord (root) >>>>>>> 389. ord (tree) >>>>>>> 390. sort (att.personal) >>>>>>> 391. org (attList) >>>>>>> 392. org (vColl) >>>>>>> 393. org (att.divLike) >>>>>>> 394. orig (att.lexicographic) >>>>>>> 395. otherLangs (textLang) >>>>>>> 396. perf (move) >>>>>>> 397. perf (tech) >>>>>>> 398. target (specGrpRef) >>>>>>> 399. parts (nym) >>>>>>> 400. change (att.global.change) >>>>>>> 401. target (change) >>>>>>> 402. prev (att.global.linking) >>>>>>> 403. lemmaRef (w) >>>>>>> 404. marks (quotation) >>>>>>> 405. ref (att.canonical) >>>>>>> 406. nymRef (att.naming) >>>>>>> 407. filter (equiv) >>>>>>> 408. pattern (metDecl) >>>>>>> 409. resp (respons) >>>>>>> 410. resp (att.responsibility) >>>>>>> 411. resp (space) >>>>>>> 412. rhyme (att.metrical) >>>>>>> 413. seq (att.transcriptional) >>>>>>> 414. hand (att.transcriptional) >>>>>>> 415. prefix (moduleRef) >>>>>>> 416. key (memberOf) >>>>>>> 417. quantity (att.dimensions) >>>>>>> 418. value (age) >>>>>>> 419. target (fsdLink) >>>>>>> 420. period (att.datable) >>>>>>> 421. tag (langKnown) >>>>>>> 422. tags (langKnowledge) >>>>>>> 423. max (memberOf) >>>>>>> 424. min (memberOf) >>>>>>> 425. synch (att.global.linking) >>>>>>> 426. targFunc (att.pointing.group) >>>>>>> 427. targetLang (schemaSpec) >>>>>>> 428. key (classRef) >>>>>>> 429. key (elementRef) >>>>>>> 430. key (macroRef) >>>>>>> 431. name (attRef) >>>>>>> 432. trans (u) >>>>>>> 433. uri (equiv) >>>>>>> 434. url (graphic) >>>>>>> 435. varSeq (att.textCritical) >>>>>>> 436. scope (rendition) >>>>>>> 437. max (att.ranging) >>>>>>> 438. min (att.ranging) >>>>>>> 439. withId (tagUsage) >>>>>>> 440. wit (att.witnessed) >>>>>>> 441. wit (att.rdgPart) >>>>>>> 442. wit (witDetail) >>>>>>> 443. status (att.docStatus) >>>>>>> 444. points (zone) >>>>>>> 445. start (att.coordinated) >>>>>>> 446. valid (egXML) >>>>>>> 447. ordered (listChange) >>>>>>> 448. role (att.naming) >>>>>>> 449. source (att.readFrom) >>>>>>> 450. flipping (surface) >>>>>>> >>>>>>> >>>>>>> ATTRIBUTE DEFINITIONS WHICH HAVE EXAMPLES AS OF >>>>>>> 2012-04-19T15:12:34.968-07:00 >>>>>>> >>>>>>> 1. place (att.placement) >>>>>>> 2. expand (att.lexicographic) >>>>>>> 3. extent (att.dimensions) >>>>>>> 4. calendar (att.datable) >>>>>>> 5. reason (unclear) >>>>>>> 6. target (att.scoping) >>>>>>> 7. xml:base (att.global) >>>>>>> 8. assertedValue (certainty) >>>>>>> 9. refLang (att.pointing) >>>>>>> 10. match (att.scoping) >>>>>>> 11. sortKey (att.sortable) >>>>>>> 12. atts (specDesc) >>>>>>> 13. key (specDesc) >>>>>>> 14. norm (att.lexicographic) >>>>>>> 15. rendition (att.global) >>>>>>> 16. rend (att.global) >>>>>>> 17. when-iso (att.datable.iso) >>>>>>> 18. when-custom (att.datable.custom) >>>>>>> 19. when (att.datable.w3c) >>>>>>> >>>>>>> -- >>>>>>> Martin Holmes >>>>>>> University of Victoria Humanities Computing and Media Centre >>>>>>> (mholmes at uvic.ca) >>>>>>> -- >>>>>>> tei-council mailing list >>>>>>> tei-council at lists.village.Virginia.EDU >>>>>>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council >>>>>>> >>>>>>> PLEASE NOTE: postings to this list are publicly archived >>>>>>> . >>>>>>> >>>>>> >>>>> . >>>>> >>>> >>> >>> >>> -- >>> Dr James Cummings, InfoDev, >>> Computing Services, University of Oxford >>> -- >>> tei-council mailing list >>> tei-council at lists.village.Virginia.EDU >>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council >>> >>> PLEASE NOTE: postings to this list are publicly archived >>> . >>> >> >> -- >> Martin Holmes >> University of Victoria Humanities Computing and Media Centre >> (mholmes at uvic.ca) >> -- >> tei-council mailing list >> tei-council at lists.village.Virginia.EDU >> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council >> >> PLEASE NOTE: postings to this list are publicly archived >> . >> > > -- > Martin Holmes > University of Victoria Humanities Computing and Media Centre > (mholmes at uvic.ca) > -- > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > > PLEASE NOTE: postings to this list are publicly archived From mholmes at uvic.ca Mon Apr 23 20:00:22 2012 From: mholmes at uvic.ca (Martin Holmes) Date: Mon, 23 Apr 2012 17:00:22 -0700 Subject: [tei-council] Attributes without examples In-Reply-To: <CAC_Lu0aeSZBOpxEK6zndQ99jhiV-aMZfcbupkqe8jxmnwOibsw@mail.gmail.com> References: <4F908F22.4070908@uvic.ca> <4F90AD72.10605@uvic.ca> <4F90AEBC.6000608@ultraslavonic.info> <4F9573BF.1080302@uvic.ca> <4F957C03.8090008@oucs.ox.ac.uk> <4F9580F6.4080505@uvic.ca> <4F9584B7.3080302@uvic.ca> <CAC_Lu0aeSZBOpxEK6zndQ99jhiV-aMZfcbupkqe8jxmnwOibsw@mail.gmail.com> Message-ID: <4F95ED16.1010000@uvic.ca> On 12-04-23 04:38 PM, Stuart A. Yeates wrote: > I've just tarted the wiki page up a little, making the table sortable > by arbitrary columns, linking to the ticket, etc. Neat! If I'd known about class="sortable" I'd have used it. Now I do. Cheers, Martin > > cheers > stuart > > On Tue, Apr 24, 2012 at 4:35 AM, Martin Holmes<mholmes at uvic.ca> wrote: >> I've created a ticket for this too, so we don't lose track of it: >> >> <http://purl.org/TEI/BUGS/3520704> >> >> Cheers, >> Martin >> >> On 12-04-23 09:19 AM, Martin Holmes wrote: >>> Thanks James -- that works. I have to write that down somewhere. I >>> wonder why spambots wouldn't use<nowiki/> themselves. >>> >>> Here's the page -- feel free to sign up for one or more attributes by >>> editing it: >>> >>> <http://wiki.tei-c.org/index.php/AttsWithoutEgs> >>> >>> Cheers, >>> Martin >>> >>> On 12-04-23 08:57 AM, James Cummings wrote: >>>> >>>> Martin, >>>> >>>> It is simple but intentionally not documented. Interrupt the spam >>>> word with an element. Specifically use<nowiki/> so >>>> att.ms<nowiki/>Excerpt will allow you to get around the spam filter. >>>> >>>> Just don't advertise via<nowiki/>gra too much. >>>> >>>> -James >>>> >>>> On 23/04/12 16:22, Martin Holmes wrote: >>>>> I've just tried to create a wiki page which has a table listing all >>>>> these attributes, but I've been prevented from doing so by the sad >>>>> little spam filter, which won't allow this: >>>>> >>>>> att.msExcerpt >>>>> >>>>> because it contains "sEx". >>>>> >>>>> I seem to remember having spent a frustrating time fighting with this >>>>> stupidity some time ago. Does anyone remember how to get around this, or >>>>> is it pointless to try? >>>>> >>>>> Cheers, >>>>> Martin >>>>> >>>>> On 12-04-19 05:33 PM, Kevin Hawkins wrote: >>>>>> Would you be able to output as a table with a third column for people to >>>>>> sign up, either in MediaWiki or HTML syntax, for a page in the wiki? >>>>>> >>>>>> On 4/19/12 8:27 PM, Martin Holmes wrote: >>>>>>> Below is another slightly shorter list. These are attributes which do >>>>>>> not appear on any examples in the<elementSpec> or<classSpec> in which >>>>>>> they're defined. Not that this doesn't mean there are no examples at all >>>>>>> for them; there may be an example somewhere in the Guidelines text, or >>>>>>> the attribute may be defined in a<classSpec> for an attribute class, >>>>>>> and then show up in an example in an<elementSpec> for an element which >>>>>>> belongs to that class. An example of the latter is @agent (att.damaged), >>>>>>> which has no example in the att.damaged<classSpec>, but happens to show >>>>>>> up in an example for the<damage> element. >>>>>>> >>>>>>> Nevertheless, I think it would be a good idea to try to provide examples >>>>>>> for all these attributes, in the files which define them. >>>>>>> >>>>>>> ATTRIBUTES WHICH DO NOT SHOW UP ON ANY EXAMPLE IN THEIR elementSpec OR >>>>>>> classSpec AS OF 2012-04-19T17:19:17.315-07:00 >>>>>>> >>>>>>> 1. absolute (when) >>>>>>> 2. adj (node) >>>>>>> 3. adjFrom (node) >>>>>>> 4. adjTo (node) >>>>>>> 5. age (personGrp) >>>>>>> 6. agent (att.damaged) >>>>>>> 7. agent (gap) >>>>>>> 8. agent (unclear) >>>>>>> 9. ana (att.global.analytic) >>>>>>> 10. atLeast (att.ranging) >>>>>>> 11. atMost (att.ranging) >>>>>>> 12. attachment (surface) >>>>>>> 13. autoPrefix (content) >>>>>>> 14. baseTypes (fsDecl) >>>>>>> 15. break (att.breaking) >>>>>>> 16. cRef (gloss) >>>>>>> 17. cRef (ptr) >>>>>>> 18. cRef (ref) >>>>>>> 19. cRef (term) >>>>>>> 20. cause (att.textCritical) >>>>>>> 21. cause (att.transcriptional) >>>>>>> 22. cert (att.responsibility) >>>>>>> 23. change (att.global.change) >>>>>>> 24. class (msContents) >>>>>>> 25. cols (att.tableDecoration) >>>>>>> 26. confidence (att.ranging) >>>>>>> 27. contemporary (seal) >>>>>>> 28. copyOf (att.global.linking) >>>>>>> 29. corresp (att.global.linking) >>>>>>> 30. datingMethod (att.datable.custom) >>>>>>> 31. datingPoint (att.datable.custom) >>>>>>> 32. decls (att.declaring) >>>>>>> 33. default (att.declarable) >>>>>>> 34. defective (att.msExcerpt) >>>>>>> 35. degree (att.damaged) >>>>>>> 36. degree (node) >>>>>>> 37. dim (space) >>>>>>> 38. direct (said) >>>>>>> 39. docLang (schemaSpec) >>>>>>> 40. domains (att.pointing.group) >>>>>>> 41. dur (att.duration.w3c) >>>>>>> 42. dur-iso (att.duration.iso) >>>>>>> 43. encoding (binaryObject) >>>>>>> 44. end (att.timed) >>>>>>> 45. enjamb (att.enjamb) >>>>>>> 46. evaluate (att.pointing) >>>>>>> 47. evidence (att.editLike) >>>>>>> 48. except (moduleRef) >>>>>>> 49. exclude (att.global.linking) >>>>>>> 50. expand (att.lexicographic) >>>>>>> 51. extent (orth) >>>>>>> 52. fVal (f) >>>>>>> 53. facs (att.global.facs) >>>>>>> 54. feats (fs) >>>>>>> 55. filter (equiv) >>>>>>> 56. flipping (surface) >>>>>>> 57. follow (leaf) >>>>>>> 58. force (pc) >>>>>>> 59. from (app) >>>>>>> 60. from (att.datable.w3c) >>>>>>> 61. from-custom (att.datable.custom) >>>>>>> 62. from-iso (att.datable.iso) >>>>>>> 63. full (att.personal) >>>>>>> 64. function (att.segLike) >>>>>>> 65. generate (classSpec) >>>>>>> 66. gradual (writing) >>>>>>> 67. group (att.damaged) >>>>>>> 68. hand (att.damaged) >>>>>>> 69. hand (att.textCritical) >>>>>>> 70. hand (att.transcriptional) >>>>>>> 71. hand (gap) >>>>>>> 72. hand (unclear) >>>>>>> 73. height (binaryObject) >>>>>>> 74. height (graphic) >>>>>>> 75. ident (att.identified) >>>>>>> 76. inst (att.interpLike) >>>>>>> 77. instant (att.editLike) >>>>>>> 78. key (att.canonical) >>>>>>> 79. key (classRef) >>>>>>> 80. key (macroRef) >>>>>>> 81. level (sense) >>>>>>> 82. level (title) >>>>>>> 83. loc (app) >>>>>>> 84. location (att.lexicographic) >>>>>>> 85. lrx (att.coordinated) >>>>>>> 86. lry (att.coordinated) >>>>>>> 87. match (att.scoping) >>>>>>> 88. material (supportDesc) >>>>>>> 89. max (att.ranging) >>>>>>> 90. max (memberOf) >>>>>>> 91. medium (att.handFeatures) >>>>>>> 92. mergedIn (att.lexicographic) >>>>>>> 93. met (att.metrical) >>>>>>> 94. method (correction) >>>>>>> 95. mimeType (att.internetMedia) >>>>>>> 96. min (att.ranging) >>>>>>> 97. min (memberOf) >>>>>>> 98. mode (att.combinable) >>>>>>> 99. mode (classes) >>>>>>> 100. mode (memberOf) >>>>>>> 101. module (att.identified) >>>>>>> 102. new (handShift) >>>>>>> 103. next (att.global.linking) >>>>>>> 104. notAfter-custom (att.datable.custom) >>>>>>> 105. notAfter-iso (att.datable.iso) >>>>>>> 106. notBefore-custom (att.datable.custom) >>>>>>> 107. notBefore-iso (att.datable.iso) >>>>>>> 108. notation (pron) >>>>>>> 109. ns (attDef) >>>>>>> 110. ns (elementSpec) >>>>>>> 111. ns (schemaSpec) >>>>>>> 112. nymRef (att.naming) >>>>>>> 113. opt (att.lexicographic) >>>>>>> 114. optional (fDecl) >>>>>>> 115. ord (iNode) >>>>>>> 116. ord (root) >>>>>>> 117. org (att.divLike) >>>>>>> 118. org (attList) >>>>>>> 119. orig (att.lexicographic) >>>>>>> 120. part (ab) >>>>>>> 121. part (att.divLike) >>>>>>> 122. part (att.segLike) >>>>>>> 123. parts (nym) >>>>>>> 124. perf (tech) >>>>>>> 125. period (att.datable) >>>>>>> 126. pre (pc) >>>>>>> 127. precision (att.dimensions) >>>>>>> 128. predeclare (att.identified) >>>>>>> 129. prefix (elementSpec) >>>>>>> 130. prefix (moduleRef) >>>>>>> 131. prev (att.global.linking) >>>>>>> 132. quantity (att.dimensions) >>>>>>> 133. real (att.metrical) >>>>>>> 134. ref (att.canonical) >>>>>>> 135. refLang (att.pointing) >>>>>>> 136. resp (att.responsibility) >>>>>>> 137. resp (space) >>>>>>> 138. rhyme (att.metrical) >>>>>>> 139. role (att.naming) >>>>>>> 140. role (att.tableDecoration) >>>>>>> 141. role (org) >>>>>>> 142. rotate (zone) >>>>>>> 143. rows (att.tableDecoration) >>>>>>> 144. sameAs (att.global.linking) >>>>>>> 145. sample (att.divLike) >>>>>>> 146. scale (binaryObject) >>>>>>> 147. scale (graphic) >>>>>>> 148. scheme (catRef) >>>>>>> 149. scheme (locus) >>>>>>> 150. scheme (locusGrp) >>>>>>> 151. scheme (tag) >>>>>>> 152. scope (att.dimensions) >>>>>>> 153. scope (att.handFeatures) >>>>>>> 154. scribe (att.handFeatures) >>>>>>> 155. scribeRef (att.handFeatures) >>>>>>> 156. script (att.handFeatures) >>>>>>> 157. scriptRef (att.handFeatures) >>>>>>> 158. select (att.global.linking) >>>>>>> 159. seq (att.transcriptional) >>>>>>> 160. social (distinct) >>>>>>> 161. sort (att.personal) >>>>>>> 162. source (att.editLike) >>>>>>> 163. source (att.readFrom) >>>>>>> 164. source (writing) >>>>>>> 165. space (distinct) >>>>>>> 166. spanTo (att.spanning) >>>>>>> 167. split (att.lexicographic) >>>>>>> 168. start (att.coordinated) >>>>>>> 169. start (att.timed) >>>>>>> 170. status (att.identified) >>>>>>> 171. status (att.transcriptional) >>>>>>> 172. status (correction) >>>>>>> 173. stdDeviation (precision) >>>>>>> 174. subtype (att.typed) >>>>>>> 175. synch (att.global.linking) >>>>>>> 176. targFunc (att.pointing.group) >>>>>>> 177. target (change) >>>>>>> 178. target (relatedItem) >>>>>>> 179. targetEnd (note) >>>>>>> 180. targetLang (schemaSpec) >>>>>>> 181. targets (alt) >>>>>>> 182. targets (join) >>>>>>> 183. targets (link) >>>>>>> 184. time (distinct) >>>>>>> 185. to (app) >>>>>>> 186. to (att.datable.w3c) >>>>>>> 187. to-custom (att.datable.custom) >>>>>>> 188. to-iso (att.datable.iso) >>>>>>> 189. type (abbr) >>>>>>> 190. type (att.entryLike) >>>>>>> 191. type (att.interpLike) >>>>>>> 192. type (att.textCritical) >>>>>>> 193. type (att.typed) >>>>>>> 194. type (form) >>>>>>> 195. type (q) >>>>>>> 196. type (sound) >>>>>>> 197. ulx (att.coordinated) >>>>>>> 198. uly (att.coordinated) >>>>>>> 199. unit (att.dimensions) >>>>>>> 200. unit (pc) >>>>>>> 201. unit (when) >>>>>>> 202. url (moduleRef) >>>>>>> 203. value (att.lexicographic) >>>>>>> 204. value (eTree) >>>>>>> 205. value (iNode) >>>>>>> 206. value (leaf) >>>>>>> 207. value (node) >>>>>>> 208. value (root) >>>>>>> 209. value (triangle) >>>>>>> 210. varSeq (att.textCritical) >>>>>>> 211. version (unicodeName) >>>>>>> 212. versionDate (att.translatable) >>>>>>> 213. when (docDate) >>>>>>> 214. where (event) >>>>>>> 215. who (att.ascribed) >>>>>>> 216. width (binaryObject) >>>>>>> 217. width (graphic) >>>>>>> 218. wit (att.rdgPart) >>>>>>> 219. wit (att.witnessed) >>>>>>> 220. xml:base (att.global) >>>>>>> 221. xml:id (att.global) >>>>>>> 222. xml:lang (att.global) >>>>>>> 223. xml:space (att.global) >>>>>>> >>>>>>> Cheers, >>>>>>> Martin >>>>>>> >>>>>>> On 12-04-19 03:18 PM, Martin Holmes wrote: >>>>>>>> Following on from our discussion of examples for attributes, a >>>>>>>> quick-and-dirty XSLT seems to show that there are only 19 attributes >>>>>>>> with their own examples, and 450 without. This is not to say that those >>>>>>>> without are unexemplified, because the example code for their parent >>>>>>>> elements in the elementSpec may show examples of them; I'll refine the >>>>>>>> XSLT and make that apparent. >>>>>>>> >>>>>>>> Here's the list: >>>>>>>> >>>>>>>> ATTRIBUTE DEFINITIONS LACKING EXAMPLES AS OF 2012-04-19T15:12:34.968-07:00 >>>>>>>> >>>>>>>> 1. status (att.identified) >>>>>>>> 2. type (interaction) >>>>>>>> 3. value (sex) >>>>>>>> 4. scale (graphic) >>>>>>>> 5. scale (binaryObject) >>>>>>>> 6. weights (alt) >>>>>>>> 7. hand (att.damaged) >>>>>>>> 8. agent (gap) >>>>>>>> 9. predeclare (att.identified) >>>>>>>> 10. degree (att.damaged) >>>>>>>> 11. module (att.identified) >>>>>>>> 12. ident (att.identified) >>>>>>>> 13. height (graphic) >>>>>>>> 14. height (binaryObject) >>>>>>>> 15. width (graphic) >>>>>>>> 16. width (binaryObject) >>>>>>>> 17. encoding (binaryObject) >>>>>>>> 18. version (teiCorpus) >>>>>>>> 19. hand (unclear) >>>>>>>> 20. agent (unclear) >>>>>>>> 21. feature (shift) >>>>>>>> 22. type (preparedness) >>>>>>>> 23. type (abbr) >>>>>>>> 24. commodity (att.measurement) >>>>>>>> 25. agent (att.damaged) >>>>>>>> 26. type (derivation) >>>>>>>> 27. type (domain) >>>>>>>> 28. type (factuality) >>>>>>>> 29. type (idno) >>>>>>>> 30. type (relation) >>>>>>>> 31. type (sound) >>>>>>>> 32. type (tech) >>>>>>>> 33. type (castItem) >>>>>>>> 34. type (att.typed) >>>>>>>> 35. type (move) >>>>>>>> 36. script (att.handFeatures) >>>>>>>> 37. class (msItemStruct) >>>>>>>> 38. class (msItem) >>>>>>>> 39. class (msContents) >>>>>>>> 40. type (form) >>>>>>>> 41. cause (att.textCritical) >>>>>>>> 42. type (gram) >>>>>>>> 43. type (lbl) >>>>>>>> 44. type (att.textCritical) >>>>>>>> 45. type (title) >>>>>>>> 46. type (titlePage) >>>>>>>> 47. type (usg) >>>>>>>> 48. type (app) >>>>>>>> 49. columns (layout) >>>>>>>> 50. valueDatcat (att.datcat) >>>>>>>> 51. datcat (att.datcat) >>>>>>>> 52. contemporary (seal) >>>>>>>> 53. contemporary (binding) >>>>>>>> 54. from (locus) >>>>>>>> 55. type (list) >>>>>>>> 56. result (joinGrp) >>>>>>>> 57. medium (att.handFeatures) >>>>>>>> 58. type (graph) >>>>>>>> 59. type (witDetail) >>>>>>>> 60. origin (timeline) >>>>>>>> 61. function (att.segLike) >>>>>>>> 62. form (objectDesc) >>>>>>>> 63. mergedIn (att.lexicographic) >>>>>>>> 64. type (fsDecl) >>>>>>>> 65. scribe (att.handFeatures) >>>>>>>> 66. degree (node) >>>>>>>> 67. extent (orth) >>>>>>>> 68. from (arc) >>>>>>>> 69. to (arc) >>>>>>>> 70. inDegree (node) >>>>>>>> 71. arity (tree) >>>>>>>> 72. baseTypes (fsDecl) >>>>>>>> 73. level (sense) >>>>>>>> 74. order (tree) >>>>>>>> 75. outDegree (iNode) >>>>>>>> 76. outDegree (node) >>>>>>>> 77. outDegree (root) >>>>>>>> 78. reason (gap) >>>>>>>> 79. type (orth) >>>>>>>> 80. when (docDate) >>>>>>>> 81. split (att.lexicographic) >>>>>>>> 82. code (socecStatus) >>>>>>>> 83. code (occupation) >>>>>>>> 84. decls (att.declaring) >>>>>>>> 85. cRef (term) >>>>>>>> 86. from (app) >>>>>>>> 87. scheme (catRef) >>>>>>>> 88. scheme (occupation) >>>>>>>> 89. scheme (classCode) >>>>>>>> 90. scheme (socecStatus) >>>>>>>> 91. scheme (keywords) >>>>>>>> 92. to (app) >>>>>>>> 93. baseForm (m) >>>>>>>> 94. new (handShift) >>>>>>>> 95. passive (relation) >>>>>>>> 96. since (when) >>>>>>>> 97. type (fsdLink) >>>>>>>> 98. type (biblScope) >>>>>>>> 99. type (listForest) >>>>>>>> 100. type (forest) >>>>>>>> 101. hand (gap) >>>>>>>> 102. given (certainty) >>>>>>>> 103. locus (certainty) >>>>>>>> 104. type (rs) >>>>>>>> 105. source (normalization) >>>>>>>> 106. level (title) >>>>>>>> 107. degree (certainty) >>>>>>>> 108. status (correction) >>>>>>>> 109. degree (precision) >>>>>>>> 110. spanTo (att.spanning) >>>>>>>> 111. to (att.datable.w3c) >>>>>>>> 112. to-iso (att.datable.iso) >>>>>>>> 113. force (pc) >>>>>>>> 114. reason (surplus) >>>>>>>> 115. type (stage) >>>>>>>> 116. type (oRef) >>>>>>>> 117. type (oVar) >>>>>>>> 118. method (correction) >>>>>>>> 119. method (normalization) >>>>>>>> 120. name (fDecl) >>>>>>>> 121. evidence (att.editLike) >>>>>>>> 122. rows (table) >>>>>>>> 123. org (vMerge) >>>>>>>> 124. who (att.ascribed) >>>>>>>> 125. locus (respons) >>>>>>>> 126. from-custom (att.datable.custom) >>>>>>>> 127. from (att.datable.w3c) >>>>>>>> 128. from-iso (att.datable.iso) >>>>>>>> 129. type (xr) >>>>>>>> 130. type (iType) >>>>>>>> 131. type (num) >>>>>>>> 132. type (att.entryLike) >>>>>>>> 133. type (att.interpLike) >>>>>>>> 134. unit (refState) >>>>>>>> 135. notation (pron) >>>>>>>> 136. break (att.breaking) >>>>>>>> 137. iterated (kinesic) >>>>>>>> 138. iterated (vocal) >>>>>>>> 139. optional (fDecl) >>>>>>>> 140. default (att.declarable) >>>>>>>> 141. location (variantEncoding) >>>>>>>> 142. anchored (note) >>>>>>>> 143. full (att.personal) >>>>>>>> 144. type (metDecl) >>>>>>>> 145. extent (pron) >>>>>>>> 146. discrete (sound) >>>>>>>> 147. scope (join) >>>>>>>> 148. gradual (writing) >>>>>>>> 149. sample (att.divLike) >>>>>>>> 150. type (classSpec) >>>>>>>> 151. pre (pc) >>>>>>>> 152. type (dimensions) >>>>>>>> 153. method (variantEncoding) >>>>>>>> 154. type (macroSpec) >>>>>>>> 155. reason (supplied) >>>>>>>> 156. to (locus) >>>>>>>> 157. rows (att.tableDecoration) >>>>>>>> 158. writtenLines (layout) >>>>>>>> 159. ruledLines (layout) >>>>>>>> 160. location (att.lexicographic) >>>>>>>> 161. hands (handDesc) >>>>>>>> 162. material (supportDesc) >>>>>>>> 163. notation (formula) >>>>>>>> 164. unit (att.dimensions) >>>>>>>> 165. ns (attDef) >>>>>>>> 166. ns (elementSpec) >>>>>>>> 167. domains (att.pointing.group) >>>>>>>> 168. part (att.segLike) >>>>>>>> 169. source (writing) >>>>>>>> 170. ref (g) >>>>>>>> 171. scribeRef (att.handFeatures) >>>>>>>> 172. scriptRef (att.handFeatures) >>>>>>>> 173. copyOf (att.global.linking) >>>>>>>> 174. sameAs (att.global.linking) >>>>>>>> 175. exclude (att.global.linking) >>>>>>>> 176. targetEnd (note) >>>>>>>> 177. next (att.global.linking) >>>>>>>> 178. target (relatedItem) >>>>>>>> 179. unit (milestone) >>>>>>>> 180. label (rhyme) >>>>>>>> 181. lemma (w) >>>>>>>> 182. children (iNode) >>>>>>>> 183. children (root) >>>>>>>> 184. name (f) >>>>>>>> 185. unit (pc) >>>>>>>> 186. value (leaf) >>>>>>>> 187. type (node) >>>>>>>> 188. key (att.canonical) >>>>>>>> 189. follow (iNode) >>>>>>>> 190. follow (leaf) >>>>>>>> 191. parent (leaf) >>>>>>>> 192. parent (iNode) >>>>>>>> 193. value (node) >>>>>>>> 194. value (triangle) >>>>>>>> 195. value (eLeaf) >>>>>>>> 196. value (eTree) >>>>>>>> 197. value (iNode) >>>>>>>> 198. value (root) >>>>>>>> 199. quantity (att.measurement) >>>>>>>> 200. role (att.tableDecoration) >>>>>>>> 201. scheme (att) >>>>>>>> 202. select (att.global.linking) >>>>>>>> 203. xml:space (att.global) >>>>>>>> 204. hand (att.textCritical) >>>>>>>> 205. subtype (att.typed) >>>>>>>> 206. prefix (schemaSpec) >>>>>>>> 207. prefix (elementSpec) >>>>>>>> 208. type (purpose) >>>>>>>> 209. role (org) >>>>>>>> 210. role (person) >>>>>>>> 211. matchPattern (cRefPattern) >>>>>>>> 212. replacementPattern (cRefPattern) >>>>>>>> 213. age (person) >>>>>>>> 214. start (schemaSpec) >>>>>>>> 215. form (quotation) >>>>>>>> 216. time (distinct) >>>>>>>> 217. social (distinct) >>>>>>>> 218. space (distinct) >>>>>>>> 219. type (constitution) >>>>>>>> 220. scope (att.handFeatures) >>>>>>>> 221. age (personGrp) >>>>>>>> 222. usage (language) >>>>>>>> 223. ident (valItem) >>>>>>>> 224. from (span) >>>>>>>> 225. value (metSym) >>>>>>>> 226. versionDate (att.translatable) >>>>>>>> 227. target (att.pointing) >>>>>>>> 228. where (move) >>>>>>>> 229. notBefore (att.datable.w3c) >>>>>>>> 230. notBefore-custom (att.datable.custom) >>>>>>>> 231. notBefore-iso (att.datable.iso) >>>>>>>> 232. mode (classes) >>>>>>>> 233. mode (att.combinable) >>>>>>>> 234. mode (memberOf) >>>>>>>> 235. to (span) >>>>>>>> 236. to (biblScope) >>>>>>>> 237. type (valList) >>>>>>>> 238. degree (purpose) >>>>>>>> 239. length (refState) >>>>>>>> 240. render (tagUsage) >>>>>>>> 241. targets (alt) >>>>>>>> 242. targets (join) >>>>>>>> 243. targets (link) >>>>>>>> 244. type (teiHeader) >>>>>>>> 245. notAfter (att.datable.w3c) >>>>>>>> 246. notAfter-custom (att.datable.custom) >>>>>>>> 247. notAfter-iso (att.datable.iso) >>>>>>>> 248. version (TEI) >>>>>>>> 249. mode (channel) >>>>>>>> 250. result (join) >>>>>>>> 251. new (shift) >>>>>>>> 252. active (interaction) >>>>>>>> 253. occurs (tagUsage) >>>>>>>> 254. passive (interaction) >>>>>>>> 255. interval (when) >>>>>>>> 256. interval (timeline) >>>>>>>> 257. usage (attDef) >>>>>>>> 258. role (personGrp) >>>>>>>> 259. type (titlePart) >>>>>>>> 260. sex (personGrp) >>>>>>>> 261. sex (person) >>>>>>>> 262. size (personGrp) >>>>>>>> 263. from (biblScope) >>>>>>>> 264. type (distinct) >>>>>>>> 265. type (measure) >>>>>>>> 266. type (fs) >>>>>>>> 267. unit (timeline) >>>>>>>> 268. unit (when) >>>>>>>> 269. version (unicodeName) >>>>>>>> 270. type (divGen) >>>>>>>> 271. part (ab) >>>>>>>> 272. part (att.divLike) >>>>>>>> 273. part (l) >>>>>>>> 274. terminal (metSym) >>>>>>>> 275. trunc (numeric) >>>>>>>> 276. order (graph) >>>>>>>> 277. size (graph) >>>>>>>> 278. mode (alt) >>>>>>>> 279. mode (altGrp) >>>>>>>> 280. value (binary) >>>>>>>> 281. status (availability) >>>>>>>> 282. datum (geoDecl) >>>>>>>> 283. value (numeric) >>>>>>>> 284. name (relation) >>>>>>>> 285. name (vLabel) >>>>>>>> 286. indexName (index) >>>>>>>> 287. stdDeviation (precision) >>>>>>>> 288. absolute (when) >>>>>>>> 289. max (numeric) >>>>>>>> 290. scheme (constraintSpec) >>>>>>>> 291. scheme (tag) >>>>>>>> 292. scheme (gi) >>>>>>>> 293. value (symbol) >>>>>>>> 294. value (num) >>>>>>>> 295. scheme (locusGrp) >>>>>>>> 296. scheme (locus) >>>>>>>> 297. name (namespace) >>>>>>>> 298. type (recording) >>>>>>>> 299. unit (att.measurement) >>>>>>>> 300. value (att.lexicographic) >>>>>>>> 301. scope (att.dimensions) >>>>>>>> 302. evaluate (att.pointing) >>>>>>>> 303. active (relation) >>>>>>>> 304. to-custom (att.datable.custom) >>>>>>>> 305. mutual (relation) >>>>>>>> 306. dur-iso (att.duration.iso) >>>>>>>> 307. instant (att.editLike) >>>>>>>> 308. function (metamark) >>>>>>>> 309. attachment (surface) >>>>>>>> 310. cause (att.transcriptional) >>>>>>>> 311. target (metamark) >>>>>>>> 312. rotate (zone) >>>>>>>> 313. target (redo) >>>>>>>> 314. target (undo) >>>>>>>> 315. except (moduleRef) >>>>>>>> 316. include (moduleRef) >>>>>>>> 317. datingMethod (att.datable.custom) >>>>>>>> 318. datingPoint (att.datable.custom) >>>>>>>> 319. key (moduleRef) >>>>>>>> 320. url (moduleRef) >>>>>>>> 321. mimeType (att.internetMedia) >>>>>>>> 322. version (application) >>>>>>>> 323. ident (application) >>>>>>>> 324. confidence (att.ranging) >>>>>>>> 325. level (langKnown) >>>>>>>> 326. adj (node) >>>>>>>> 327. adjFrom (node) >>>>>>>> 328. adjTo (node) >>>>>>>> 329. ana (att.global.analytic) >>>>>>>> 330. group (att.damaged) >>>>>>>> 331. cRef (gloss) >>>>>>>> 332. cRef (ptr) >>>>>>>> 333. cRef (ref) >>>>>>>> 334. cert (att.responsibility) >>>>>>>> 335. cert (certainty) >>>>>>>> 336. precision (precision) >>>>>>>> 337. precision (att.dimensions) >>>>>>>> 338. type (fw) >>>>>>>> 339. cols (table) >>>>>>>> 340. cols (att.tableDecoration) >>>>>>>> 341. source (att.editLike) >>>>>>>> 342. autoPrefix (content) >>>>>>>> 343. corresp (att.global.linking) >>>>>>>> 344. delim (refState) >>>>>>>> 345. dim (space) >>>>>>>> 346. docLang (schemaSpec) >>>>>>>> 347. dur (att.duration.w3c) >>>>>>>> 348. ed (att.sourced) >>>>>>>> 349. gi (tagUsage) >>>>>>>> 350. eol (hyphenation) >>>>>>>> 351. enjamb (att.enjamb) >>>>>>>> 352. facs (att.global.facs) >>>>>>>> 353. fVal (f) >>>>>>>> 354. feats (fs) >>>>>>>> 355. lang (code) >>>>>>>> 356. atMost (att.ranging) >>>>>>>> 357. atLeast (att.ranging) >>>>>>>> 358. lrx (att.coordinated) >>>>>>>> 359. ulx (att.coordinated) >>>>>>>> 360. lry (att.coordinated) >>>>>>>> 361. uly (att.coordinated) >>>>>>>> 362. xml:id (att.global) >>>>>>>> 363. ident (language) >>>>>>>> 364. scheme (rendition) >>>>>>>> 365. status (att.transcriptional) >>>>>>>> 366. where (event) >>>>>>>> 367. start (att.timed) >>>>>>>> 368. end (att.timed) >>>>>>>> 369. type (tag) >>>>>>>> 370. defective (att.msExcerpt) >>>>>>>> 371. generate (classSpec) >>>>>>>> 372. inst (att.interpLike) >>>>>>>> 373. xml:lang (att.global) >>>>>>>> 374. loc (app) >>>>>>>> 375. mainLang (textLang) >>>>>>>> 376. maxOccurs (datatype) >>>>>>>> 377. type (q) >>>>>>>> 378. direct (said) >>>>>>>> 379. aloud (said) >>>>>>>> 380. met (att.metrical) >>>>>>>> 381. real (att.metrical) >>>>>>>> 382. minOccurs (datatype) >>>>>>>> 383. name (equiv) >>>>>>>> 384. ns (schemaSpec) >>>>>>>> 385. n (att.global) >>>>>>>> 386. opt (att.lexicographic) >>>>>>>> 387. ord (iNode) >>>>>>>> 388. ord (root) >>>>>>>> 389. ord (tree) >>>>>>>> 390. sort (att.personal) >>>>>>>> 391. org (attList) >>>>>>>> 392. org (vColl) >>>>>>>> 393. org (att.divLike) >>>>>>>> 394. orig (att.lexicographic) >>>>>>>> 395. otherLangs (textLang) >>>>>>>> 396. perf (move) >>>>>>>> 397. perf (tech) >>>>>>>> 398. target (specGrpRef) >>>>>>>> 399. parts (nym) >>>>>>>> 400. change (att.global.change) >>>>>>>> 401. target (change) >>>>>>>> 402. prev (att.global.linking) >>>>>>>> 403. lemmaRef (w) >>>>>>>> 404. marks (quotation) >>>>>>>> 405. ref (att.canonical) >>>>>>>> 406. nymRef (att.naming) >>>>>>>> 407. filter (equiv) >>>>>>>> 408. pattern (metDecl) >>>>>>>> 409. resp (respons) >>>>>>>> 410. resp (att.responsibility) >>>>>>>> 411. resp (space) >>>>>>>> 412. rhyme (att.metrical) >>>>>>>> 413. seq (att.transcriptional) >>>>>>>> 414. hand (att.transcriptional) >>>>>>>> 415. prefix (moduleRef) >>>>>>>> 416. key (memberOf) >>>>>>>> 417. quantity (att.dimensions) >>>>>>>> 418. value (age) >>>>>>>> 419. target (fsdLink) >>>>>>>> 420. period (att.datable) >>>>>>>> 421. tag (langKnown) >>>>>>>> 422. tags (langKnowledge) >>>>>>>> 423. max (memberOf) >>>>>>>> 424. min (memberOf) >>>>>>>> 425. synch (att.global.linking) >>>>>>>> 426. targFunc (att.pointing.group) >>>>>>>> 427. targetLang (schemaSpec) >>>>>>>> 428. key (classRef) >>>>>>>> 429. key (elementRef) >>>>>>>> 430. key (macroRef) >>>>>>>> 431. name (attRef) >>>>>>>> 432. trans (u) >>>>>>>> 433. uri (equiv) >>>>>>>> 434. url (graphic) >>>>>>>> 435. varSeq (att.textCritical) >>>>>>>> 436. scope (rendition) >>>>>>>> 437. max (att.ranging) >>>>>>>> 438. min (att.ranging) >>>>>>>> 439. withId (tagUsage) >>>>>>>> 440. wit (att.witnessed) >>>>>>>> 441. wit (att.rdgPart) >>>>>>>> 442. wit (witDetail) >>>>>>>> 443. status (att.docStatus) >>>>>>>> 444. points (zone) >>>>>>>> 445. start (att.coordinated) >>>>>>>> 446. valid (egXML) >>>>>>>> 447. ordered (listChange) >>>>>>>> 448. role (att.naming) >>>>>>>> 449. source (att.readFrom) >>>>>>>> 450. flipping (surface) >>>>>>>> >>>>>>>> >>>>>>>> ATTRIBUTE DEFINITIONS WHICH HAVE EXAMPLES AS OF >>>>>>>> 2012-04-19T15:12:34.968-07:00 >>>>>>>> >>>>>>>> 1. place (att.placement) >>>>>>>> 2. expand (att.lexicographic) >>>>>>>> 3. extent (att.dimensions) >>>>>>>> 4. calendar (att.datable) >>>>>>>> 5. reason (unclear) >>>>>>>> 6. target (att.scoping) >>>>>>>> 7. xml:base (att.global) >>>>>>>> 8. assertedValue (certainty) >>>>>>>> 9. refLang (att.pointing) >>>>>>>> 10. match (att.scoping) >>>>>>>> 11. sortKey (att.sortable) >>>>>>>> 12. atts (specDesc) >>>>>>>> 13. key (specDesc) >>>>>>>> 14. norm (att.lexicographic) >>>>>>>> 15. rendition (att.global) >>>>>>>> 16. rend (att.global) >>>>>>>> 17. when-iso (att.datable.iso) >>>>>>>> 18. when-custom (att.datable.custom) >>>>>>>> 19. when (att.datable.w3c) >>>>>>>> >>>>>>>> -- >>>>>>>> Martin Holmes >>>>>>>> University of Victoria Humanities Computing and Media Centre >>>>>>>> (mholmes at uvic.ca) >>>>>>>> -- >>>>>>>> tei-council mailing list >>>>>>>> tei-council at lists.village.Virginia.EDU >>>>>>>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council >>>>>>>> >>>>>>>> PLEASE NOTE: postings to this list are publicly archived >>>>>>>> . >>>>>>>> >>>>>>> >>>>>> . >>>>>> >>>>> >>>> >>>> >>>> -- >>>> Dr James Cummings, InfoDev, >>>> Computing Services, University of Oxford >>>> -- >>>> tei-council mailing list >>>> tei-council at lists.village.Virginia.EDU >>>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council >>>> >>>> PLEASE NOTE: postings to this list are publicly archived >>>> . >>>> >>> >>> -- >>> Martin Holmes >>> University of Victoria Humanities Computing and Media Centre >>> (mholmes at uvic.ca) >>> -- >>> tei-council mailing list >>> tei-council at lists.village.Virginia.EDU >>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council >>> >>> PLEASE NOTE: postings to this list are publicly archived >>> . >>> >> >> -- >> Martin Holmes >> University of Victoria Humanities Computing and Media Centre >> (mholmes at uvic.ca) >> -- >> tei-council mailing list >> tei-council at lists.village.Virginia.EDU >> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council >> >> PLEASE NOTE: postings to this list are publicly archived -- Martin Holmes University of Victoria Humanities Computing and Media Centre (mholmes at uvic.ca) From James.Cummings at oucs.ox.ac.uk Tue Apr 24 05:36:06 2012 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Tue, 24 Apr 2012 10:36:06 +0100 Subject: [tei-council] next release? In-Reply-To: <4F9592D1.30207@kcl.ac.uk> References: <0F18A249-5480-42D9-BFF2-538AC7B9E1EB@oucs.ox.ac.uk> <4F92F34D.2040103@uvic.ca> <4F9579A0.8010002@oucs.ox.ac.uk> <4F9592D1.30207@kcl.ac.uk> Message-ID: <4F967406.8010304@oucs.ox.ac.uk> Just to say that I'm planning to go through all the tickets discussed in Ann Arbor and note what the minutes say about them and confirm they are assigned to the right person. Maybe this evening.... -James On 23/04/12 18:35, Gabriel BODARD wrote: > In terms of doing the release tech, I guess I need to put aside at least > a day to work through this, and it doesn't matter much to me when that > day is, so that's fine. > > I'm now just trying to remember if there were any tickets assigned to me > in the meantime, and if I'll have time to complete them by May 20. I was > going to look into the guidelines-wide impact of something, but I don't > recall exactly what. Did someone add a note to the ticket in question? > (And in what may be the answer to the same or may be a completely > unrelated question, could someone update http://purl.com/tei/fr/3416130 > with the current state of Council thinking after Ann Arbor, please?) > > (Incidentally, I think http://purl.com/TEI/BUGS/3496949 has been > erroneously assigned to me--I don't think I know what we're meant to do > with this.) > > Gabby > > On 23/04/2012 16:47, James Cummings wrote: >> >> How about we set a notional target release date of 25 May? (This >> is about 5 weeks from now.) If we assume that we want most things >> completed by the end of Sunday 20th, to allow time for >> proofreading and error spotting. >> >> Does that sounds reasonable to most people? >> >> Gaby: Most importantly, does the proposed Release Technician like >> these dates? >> >> -James >> >> >> On 21/04/12 18:50, Martin Holmes wrote: >>> Three weeks will be a bit tough for me, and a couple of the tickets I >>> have might turn out to have unpredicted side-effects (like the tei_ >>> prefix). As long as we have the option to launch without the change if >>> it proves difficult, we could go with three weeks. >>> >>> The attributes-without-examples problem is so large that we'll just have >>> to hack away at it steadily. >>> >>> Cheers, >>> Martin >>> >>> On 12-04-21 04:03 AM, Sebastian Rahtz wrote: >>>> something we forgot to debate in Ann Arbor was a timetable >>>> for the next release, I think? i.e. what is the due date for >>>> everyone to complete their ticket work so that Sir Gabriel >>>> of B'odard can undertake his Quest. >>>> >>>> speaking for myself, if I don't do my assignments >>>> more or less immediately I will not get to them for ages, >>>> so I favour a short window (say, 3 weeks). >>>> >>>> Sebastian >> >> > -- Dr James Cummings, InfoDev, Computing Services, University of Oxford From James.Cummings at oucs.ox.ac.uk Tue Apr 24 05:42:03 2012 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Tue, 24 Apr 2012 10:42:03 +0100 Subject: [tei-council] next release? In-Reply-To: <4F95C7A1.1080707@o2.pl> References: <0F18A249-5480-42D9-BFF2-538AC7B9E1EB@oucs.ox.ac.uk> <4F92F34D.2040103@uvic.ca> <4F9579A0.8010002@oucs.ox.ac.uk> <4F95C7A1.1080707@o2.pl> Message-ID: <4F96756B.1060202@oucs.ox.ac.uk> What do others think? We can of course move releasing back to whenever we've finished a majority of tickets, but I'd prefer sooner rather than later and a deadline that forces us to get stuff done. I'm of the opinion that we probably don't need to telco before this release (we can, after all, conduct business on the mailing list), but would do so shortly after the release to get updates on the longer-term issues and reports from the council working groups. thoughts? -James On 23/04/12 22:20, Piotr Ba?ski wrote: > Hi James, > > Isn't May 25 roughly in the middle of LREC? Could we shift by a week > from then, please? > > (I actually intend to be ready with my stuff [and possibly more] in > advance this time, but I've made some such totally honest promises to > myself and to the world recently, several times, and with meager results...) > > Ah. Will we telco before releasing? > > Best, > > P. > > > > On 23/04/12 17:47, James Cummings wrote: >> >> How about we set a notional target release date of 25 May? (This >> is about 5 weeks from now.) If we assume that we want most things >> completed by the end of Sunday 20th, to allow time for >> proofreading and error spotting. >> >> Does that sounds reasonable to most people? >> >> Gaby: Most importantly, does the proposed Release Technician like >> these dates? >> >> -James >> >> >> On 21/04/12 18:50, Martin Holmes wrote: >>> Three weeks will be a bit tough for me, and a couple of the tickets I >>> have might turn out to have unpredicted side-effects (like the tei_ >>> prefix). As long as we have the option to launch without the change if >>> it proves difficult, we could go with three weeks. >>> >>> The attributes-without-examples problem is so large that we'll just have >>> to hack away at it steadily. >>> >>> Cheers, >>> Martin >>> >>> On 12-04-21 04:03 AM, Sebastian Rahtz wrote: >>>> something we forgot to debate in Ann Arbor was a timetable >>>> for the next release, I think? i.e. what is the due date for >>>> everyone to complete their ticket work so that Sir Gabriel >>>> of B'odard can undertake his Quest. >>>> >>>> speaking for myself, if I don't do my assignments >>>> more or less immediately I will not get to them for ages, >>>> so I favour a short window (say, 3 weeks). >>>> >>>> Sebastian >> >> > -- Dr James Cummings, InfoDev, Computing Services, University of Oxford From bansp at o2.pl Tue Apr 24 07:03:04 2012 From: bansp at o2.pl (=?ISO-8859-2?Q?Piotr_Ba=F1ski?=) Date: Tue, 24 Apr 2012 13:03:04 +0200 Subject: [tei-council] Prefacing ids with "tei_" In-Reply-To: <4F95CD12.9070904@uvic.ca> References: <4F95A3EF.7030509@uvic.ca> <4F95C669.7040709@o2.pl> <4F95CD12.9070904@uvic.ca> Message-ID: <4F968868.5040708@o2.pl> 1. I agree that a positive message "please add to your filters a positive exception for 'tei_.+'" is sociologically better than the negative message "don't reject 'msad' because we happen to use it". It has a better chance of being successful, even if only as courtesy of one open-content developer to another. 2. prefacing all ids with "tei_" indeed seems more consistent, at least it doesn't raise user questions of "why do you prefix here and not there", which may, psychologically, contribute to the impression that the TEI is more complex than it really is (which is quite complex anyway). 3. since (as I understand this) we're talking about an internal change targetting the web Guidelines and related resources (also the kind of output that should not be worked on directly), the results may be tested and quickly fixed if necessary; and "being overprotective", which I didn't like before, is restricted to giving an example of good practice that is not imposed on the individual encoder. So, despite my earlier nitpicks and Sebastian's remarks on why it is not necessary from the point of view of the system to prefix all IDs, I tend to agree that 2 and 3 above may swing the balance towards Martin's uniform solution. P. On 23/04/12 23:43, Martin Holmes wrote: > On 12-04-23 02:15 PM, Piotr Ba?ski wrote: >> Hi Martin, >> >> This may be a classic case of my missing the point, but something >> doesn't click in my mind, so I'd better comment on that, just in case: >> >> On 23/04/12 20:48, Martin Holmes wrote: >>> I'm plan