From dsewell at virginia.edu Mon Jan 3 12:18:36 2011 From: dsewell at virginia.edu (David Sewell) Date: Mon, 3 Jan 2011 12:18:36 -0500 (EST) Subject: [tei-council] Updates to TEI Council web page Message-ID: Dear Council members, I have updated the TEI website Council page http://www.tei-c.org/Activities/Council/index.xml to reflect the new membership. Please let me know if you see any remaining changes that are needed, and can everyone check the wording of their affiliation and their website link (if any) and let me know if you would like to change your own information, or add a website link if you don't have one. Thanks, David S. TEI webmaster -- 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 daniel.odonnell at uleth.ca Mon Jan 3 13:20:41 2011 From: daniel.odonnell at uleth.ca (O'Donnell, Dan) Date: Mon, 03 Jan 2011 11:20:41 -0700 Subject: [tei-council] Updates to TEI Council web page In-Reply-To: References: Message-ID: <4D221379.4060506@uleth.ca> Also, I will be sending out service letters this week (i.e. my annual letter describing and thanking you for your contribution to the TEI for use on activity reports and the like). This is a form letter PDF that I email to you, but I have a field for a a custom sentence or two if there is some particular activity that you'd like me to note. My goal is to work on them tomorrow during a flight, so if you have something let me know before tomorrow. -dan On 11-01-03 10:18 AM, David Sewell wrote: > Dear Council members, > > I have updated the TEI website Council page > > http://www.tei-c.org/Activities/Council/index.xml > > to reflect the new membership. Please let me know if you see any > remaining changes that are needed, and can everyone check the wording of > their affiliation and their website link (if any) and let me know if > you would like to change your own information, or add a website link if > you don't have one. > > Thanks, > > David S. > TEI webmaster > From mholmes at uvic.ca Tue Jan 4 11:08:49 2011 From: mholmes at uvic.ca (Martin Holmes) Date: Tue, 4 Jan 2011 08:08:49 -0800 Subject: [tei-council] update on spring 2011 council meeting In-Reply-To: <059B06B1-E1C1-453D-AD02-C7B44D3FCB43@inria.fr> References: <059B06B1-E1C1-453D-AD02-C7B44D3FCB43@inria.fr> Message-ID: <4D234611.5060409@uvic.ca> Are these dates definite? Cheers, Martin On 10-12-20 07:21 AM, Laurent Romary wrote: > Dear Council members, > > Please reserve 11-13 April 2011 for a Council meeting at the Big Ten > Center near Chicago O'Hare International Airport. We will have a one-day > symposium on Monday followed by a two-day Council meeting on Tuesday and > Wednesday. More details to follow! > > Laurent > > > Laurent Romary > INRIA& HUB-IDSL > laurent.romary at inria.fr > > > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > -- Martin Holmes University of Victoria Humanities Computing and Media Centre (mholmes at uvic.ca) From sebastian.rahtz at oucs.ox.ac.uk Tue Jan 4 11:56:43 2011 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 4 Jan 2011 16:56:43 +0000 Subject: [tei-council] FR nuncles: new element tei:objectType In-Reply-To: <4D1DDB09.40904@kcl.ac.uk> References: <4D1DDB09.40904@kcl.ac.uk> Message-ID: This is strictly for use in MS Desc, right? not intended as a general purpose parallel to , for instance? the sentence "that is it is more flexible way to handle descriptions of objects in running prose (usually in the section), which allows multiple objects for a single text," is confusing me a bit. but assuming so, then the name bothers me. In the example given: Parchment roll with silk ribbons the really looks weird to my eyes. I think, "why not ?"
might be better. but dict hijacked that. I'd stick with meself. -- Sebastian Rahtz Information and Support Group Manager Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From lou.burnard at retired.ox.ac.uk Tue Jan 4 12:03:43 2011 From: lou.burnard at retired.ox.ac.uk (Lou Burnard) Date: Tue, 04 Jan 2011 17:03:43 +0000 Subject: [tei-council] FR nuncles: new element tei:objectType In-Reply-To: References: <4D1DDB09.40904@kcl.ac.uk> Message-ID: <4D2352EF.2020205@retired.ox.ac.uk> As already noted on the ticket, the trouble with "object" is that (to my eyes at least) it is ambiguous between a specific object ("Excalibur") and a class of objects ("ceremonial swords"), in a way that "material" generally isn't. On 04/01/11 16:56, Sebastian Rahtz wrote: ... the name bothers me. In the example given: > > Parchment roll with > silk ribbons > > the really looks weird to my eyes. I think, "why not?" > > might be better. but dict hijacked that. > > I'd stick with meself. > -- > From sebastian.rahtz at oucs.ox.ac.uk Tue Jan 4 12:11:06 2011 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 4 Jan 2011 17:11:06 +0000 Subject: [tei-council] FR nuncles: new element tei:objectType In-Reply-To: <4D2352EF.2020205@retired.ox.ac.uk> References: <4D1DDB09.40904@kcl.ac.uk> <4D2352EF.2020205@retired.ox.ac.uk> Message-ID: On 4 Jan 2011, at 17:03, Lou Burnard wrote: > As already noted on the ticket, the trouble with "object" is that (to my > eyes at least) it is ambiguous between a specific object ("Excalibur") > and a class of objects ("ceremonial swords"), in a way that "material" > generally isn't. true, I can see why the Type was added. But it still jars the eye, considerably. would be analogous to . Excalibur is made of metal in the form of a sword. -- Sebastian Rahtz Information and Support Group Manager Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From lou.burnard at retired.ox.ac.uk Tue Jan 4 12:16:14 2011 From: lou.burnard at retired.ox.ac.uk (Lou Burnard) Date: Tue, 04 Jan 2011 17:16:14 +0000 Subject: [tei-council] FR nuncles: new element tei:objectType In-Reply-To: References: <4D1DDB09.40904@kcl.ac.uk> <4D2352EF.2020205@retired.ox.ac.uk> Message-ID: <4D2355DE.7080905@retired.ox.ac.uk> On 04/01/11 17:11, Sebastian Rahtz wrote: > > On 4 Jan 2011, at 17:03, Lou Burnard wrote: > >> As already noted on the ticket, the trouble with "object" is that (to my >> eyes at least) it is ambiguous between a specific object ("Excalibur") >> and a class of objects ("ceremonial swords"), in a way that "material" >> generally isn't. > > > true, I can see why the Type was added. But it still jars the eye, considerably. > > would be analogous to. Excalibur is made of metal > in the form of a sword. > "form" would be better I agree, but it's already taken vide sup. There is precedent for re-appropriation of element names of course (cf "event" which had been snaffled by the spoken text module before we decided it made more sense in namesdates). Or we could argue that the two senses of "form" are so closely related it's perfectly ok to use it for either a dictionary word form or an object form. Good luck writing the to convey that. From sebastian.rahtz at oucs.ox.ac.uk Tue Jan 4 12:29:37 2011 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 4 Jan 2011 17:29:37 +0000 Subject: [tei-council] FR nuncles: new element tei:objectType In-Reply-To: <4D2355DE.7080905@retired.ox.ac.uk> References: <4D1DDB09.40904@kcl.ac.uk> <4D2352EF.2020205@retired.ox.ac.uk> <4D2355DE.7080905@retired.ox.ac.uk> Message-ID: <9F02758B-A992-4ADB-89BC-F19923C0F6C1@oucs.ox.ac.uk> ? or might even do. annoying. makes me think the route isn't so bad after all. -- Sebastian Rahtz Information and Support Group Manager Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From lou.burnard at retired.ox.ac.uk Tue Jan 4 12:32:21 2011 From: lou.burnard at retired.ox.ac.uk (Lou Burnard) Date: Tue, 04 Jan 2011 17:32:21 +0000 Subject: [tei-council] FR nuncles: new element tei:objectType In-Reply-To: <9F02758B-A992-4ADB-89BC-F19923C0F6C1@oucs.ox.ac.uk> References: <4D1DDB09.40904@kcl.ac.uk> <4D2352EF.2020205@retired.ox.ac.uk> <4D2355DE.7080905@retired.ox.ac.uk> <9F02758B-A992-4ADB-89BC-F19923C0F6C1@oucs.ox.ac.uk> Message-ID: <4D2359A5.6000606@retired.ox.ac.uk> now you're just being silly: "embodiment" forsooth how about "shape" ? On 04/01/11 17:29, Sebastian Rahtz wrote: > ? or might even do. > > annoying. > > makes me think the route isn't so bad after all. > -- > Sebastian Rahtz > Information and Support Group Manager > Oxford University Computing Services > 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 > > S?lo le pido a Dios > que el futuro no me sea indiferente > From sebastian.rahtz at oucs.ox.ac.uk Tue Jan 4 12:37:13 2011 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 4 Jan 2011 17:37:13 +0000 Subject: [tei-council] FR nuncles: new element tei:objectType In-Reply-To: <4D2359A5.6000606@retired.ox.ac.uk> References: <4D1DDB09.40904@kcl.ac.uk> <4D2352EF.2020205@retired.ox.ac.uk> <4D2355DE.7080905@retired.ox.ac.uk> <9F02758B-A992-4ADB-89BC-F19923C0F6C1@oucs.ox.ac.uk> <4D2359A5.6000606@retired.ox.ac.uk> Message-ID: On 4 Jan 2011, at 17:32, Lou Burnard wrote: > > how about "shape" ? > i think we need more examples of use from Gabriel to know whether this fits his pattern of use and . pshaw. -- Sebastian Rahtz Information and Support Group Manager Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From kevin.s.hawkins at ultraslavonic.info Tue Jan 4 21:31:17 2011 From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins) Date: Tue, 04 Jan 2011 21:31:17 -0500 Subject: [tei-council] how to encode a hyphen at the end of a line, column, or page when you are encoding hyphens In-Reply-To: <4D194285.8010804@ultraslavonic.info> References: <4D0E7288.6010006@ultraslavonic.info> <4D0F93EF.3060100@oucs.ox.ac.uk> <4D194285.8010804@ultraslavonic.info> Message-ID: <4D23D7F5.5040009@ultraslavonic.info> So, I fear that Lou is the only current Council member who really understands the issues around hyphenation and that I am the only one who finds the lack of clear guidance on this question in P5 to be a significant problem. (Martin Mueller is an ally but is not on Council.) This has come up a few times over the past few years on TEI-L, with no changes made to P5 except the addition of a suggested value for @type in the note attached to the definition of the lb element. As I mentioned last month, I find "inWord" and "nobreak" (given in the definition of lb) unclear without examples of each. In addition, as a reader I would expect to find in section 3.10.3 and/or 3.2 of P5 a discussion of the three hyphen characters mentioned in 3.2: when to use each and how they could (or should) be used in combination with the lb, cb, and pb elements. Lou, since my summary sent to tei-council last month seemed to proposed solutions to more problems that we need to solve (or simply raises additional problems), could you write a proposal that addresses only the narrow question (which, to be honest, I'm not even sure how to state)? You might be able to start with your 2010-03-24 message to TEI-L. In fact, maybe this is still the best solution, but I think we need to make sure that points raised on TEI-L and at our discussion in Dublin have been taken into account. Not sure whether you want to send to tei-council or TEI-L and whether it should go into SourceForge. I would be be quite grateful! Kevin From laurent.romary at inria.fr Wed Jan 5 00:49:05 2011 From: laurent.romary at inria.fr (Laurent Romary) Date: Wed, 5 Jan 2011 06:49:05 +0100 Subject: [tei-council] update on spring 2011 council meeting In-Reply-To: <4D234611.5060409@uvic.ca> References: <059B06B1-E1C1-453D-AD02-C7B44D3FCB43@inria.fr> <4D234611.5060409@uvic.ca> Message-ID: <4D5FC561-BD6D-4F3F-9881-EE5BC936F2F4@inria.fr> Hi Martin, Yes they are. We are setting the organisaiton of th emeeting step by step. knowing that there are parallel threads (comprising evolution of editorial set-up and council budget). Cheers, Laurent (hardly recovering from current cold...) Le 4 janv. 11 ? 17:08, Martin Holmes a ?crit : > Are these dates definite? > > Cheers, > Martin > > On 10-12-20 07:21 AM, Laurent Romary wrote: >> Dear Council members, >> >> Please reserve 11-13 April 2011 for a Council meeting at the Big Ten >> Center near Chicago O'Hare International Airport. We will have a >> one-day >> symposium on Monday followed by a two-day Council meeting on >> Tuesday and >> Wednesday. More details to follow! >> >> Laurent >> >> >> Laurent Romary >> INRIA& HUB-IDSL >> laurent.romary at inria.fr >> >> >> >> _______________________________________________ >> tei-council mailing list >> tei-council at lists.village.Virginia.EDU >> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council >> > > -- > Martin Holmes > University of Victoria Humanities Computing and Media Centre > (mholmes at uvic.ca) Laurent Romary INRIA & HUB-IDSL laurent.romary at inria.fr From sebastian.rahtz at oucs.ox.ac.uk Wed Jan 5 04:54:24 2011 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Wed, 5 Jan 2011 09:54:24 +0000 Subject: [tei-council] how to encode a hyphen at the end of a line, column, or page when you are encoding hyphens In-Reply-To: <4D23D7F5.5040009@ultraslavonic.info> References: <4D0E7288.6010006@ultraslavonic.info> <4D0F93EF.3060100@oucs.ox.ac.uk> <4D194285.8010804@ultraslavonic.info> <4D23D7F5.5040009@ultraslavonic.info> Message-ID: <10C726D9-029A-43CF-86D5-DD69BD0778DC@oucs.ox.ac.uk> On 5 Jan 2011, at 02:31, Kevin Hawkins wrote: > So, I fear that Lou is the only current Council member who really > understands the issues around hyphenation and that I am the only one who > finds the lack of clear guidance on this question in P5 to be a > significant problem. there are other possible interpretations, related to recent religious festivals? -- Sebastian Rahtz Information and Support Group Manager Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From gabriel.bodard at kcl.ac.uk Wed Jan 5 06:17:47 2011 From: gabriel.bodard at kcl.ac.uk (Gabriel Bodard) Date: Wed, 5 Jan 2011 11:17:47 +0000 Subject: [tei-council] FR nuncles: new element tei:objectType In-Reply-To: References: <4D1DDB09.40904@kcl.ac.uk> <4D2352EF.2020205@retired.ox.ac.uk> <4D2355DE.7080905@retired.ox.ac.uk> <9F02758B-A992-4ADB-89BC-F19923C0F6C1@oucs.ox.ac.uk> <4D2359A5.6000606@retired.ox.ac.uk> Message-ID: <4D24535B.6090707@kcl.ac.uk> I don't think "shape" or "form" (much less "embodiment") are particularly nice names for this element; they don't really say what is being described. This element is encoding the type of object on which the writing is found, not just its shape ("round", "square", "irregular-polygon"). The kinds of object on which writing is found can include: (in epigraphy): panel, statue-base, column, stele, gravestone, wall, seat, table, sundial, spoon, dish, sword, axe-head, statue, doorpost, tablet, balustrade, paving-stone, mountainside, doorstep, sling-stone, drain-cover, mosaic, urn, shield, sarcophagus ... (see http://insaph.kcl.ac.uk/iaph2007/inscriptions/toc/monu/A.html for more examples) (in papyrology): leaf, scroll, codex, ostrakon, lead-tablet, gold-leaf, wooden-tablet, wax-tablet, label, mummy-wrap, cartonnage, shipping-tag ... (in codicology): codex, book, letter, loose-page, scroll, pamphlet, book-binding, leather-flap ... (in modern texts): printed-book, letter-paper, envelope, desk-blotter, shopping-bag, postcard, calendar, box, teeshirt, coffee-mug, wall, door-panel, name-plate, toe-tag, keyboard, wedding-ring, tattoo (human-skin?), note-card, catalog-card, box-file, post-it-note, leaflet, business-card, billboard ... (etc. ad nauseam) As I said in the SF ticket, I prefer "object" as the name for this element (good parallel with "material"), but the Ontology SIG have a good case that they'd like eventually to use this element name to mean something else, so "objectType" seemed a more specific term, if not very pretty. If you can think of any other way to compromise on that, it would be welcome. Best, Gabby On 04/01/2011 17:37, Sebastian Rahtz wrote: > > On 4 Jan 2011, at 17:32, Lou Burnard wrote: > >> >> how about "shape" ? >> > > i think we need more examples of use from Gabriel to know whether > this fits his pattern of use > > and. pshaw. > -- Dr Gabriel BODARD (Research Associate in Digital Epigraphy) Centre for Computing in the Humanities King's College London 26-29 Drury Lane London WC2B 5RL Email: gabriel.bodard at kcl.ac.uk Tel: +44 (0)20 7848 1388 Fax: +44 (0)20 7848 2980 http://www.digitalclassicist.org/ http://www.currentepigraphy.org/ From gabriel.bodard at kcl.ac.uk Wed Jan 5 06:25:39 2011 From: gabriel.bodard at kcl.ac.uk (Gabriel Bodard) Date: Wed, 5 Jan 2011 11:25:39 +0000 Subject: [tei-council] update on spring 2011 council meeting In-Reply-To: <4D5FC561-BD6D-4F3F-9881-EE5BC936F2F4@inria.fr> References: <059B06B1-E1C1-453D-AD02-C7B44D3FCB43@inria.fr> <4D234611.5060409@uvic.ca> <4D5FC561-BD6D-4F3F-9881-EE5BC936F2F4@inria.fr> Message-ID: <4D245533.1050407@kcl.ac.uk> Those dates are going to be inconvenient (at best!) for me, since I am teaching a pre-conference workshop at an event in the north of England starting on April 14th. (Almost any other week in April or May would have been fine.) On 05/01/2011 05:49, Laurent Romary wrote: > Hi Martin, > Yes they are. We are setting the organisaiton of th emeeting step by > step. knowing that there are parallel threads (comprising evolution of > editorial set-up and council budget). > Cheers, > Laurent (hardly recovering from current cold...) > > Le 4 janv. 11 ? 17:08, Martin Holmes a ?crit : > >> Are these dates definite? >> >> Cheers, >> Martin >> >> On 10-12-20 07:21 AM, Laurent Romary wrote: >>> Dear Council members, >>> >>> Please reserve 11-13 April 2011 for a Council meeting at the Big Ten >>> Center near Chicago O'Hare International Airport. We will have a >>> one-day >>> symposium on Monday followed by a two-day Council meeting on >>> Tuesday and >>> Wednesday. More details to follow! >>> >>> Laurent >>> >>> >>> Laurent Romary >>> INRIA& HUB-IDSL >>> laurent.romary at inria.fr >>> >>> >>> >>> _______________________________________________ >>> tei-council mailing list >>> tei-council at lists.village.Virginia.EDU >>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council >>> >> >> -- >> Martin Holmes >> University of Victoria Humanities Computing and Media Centre >> (mholmes at uvic.ca) > > Laurent Romary > INRIA& HUB-IDSL > laurent.romary at inria.fr > > > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council -- Dr Gabriel BODARD (Research Associate in Digital Epigraphy) Centre for Computing in the Humanities King's College London 26-29 Drury Lane London WC2B 5RL Email: gabriel.bodard at kcl.ac.uk Tel: +44 (0)20 7848 1388 Fax: +44 (0)20 7848 2980 http://www.digitalclassicist.org/ http://www.currentepigraphy.org/ From sebastian.rahtz at oucs.ox.ac.uk Wed Jan 5 06:48:33 2011 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Wed, 5 Jan 2011 11:48:33 +0000 Subject: [tei-council] FR nuncles: new element tei:objectType In-Reply-To: <4D24535B.6090707@kcl.ac.uk> References: <4D1DDB09.40904@kcl.ac.uk> <4D2352EF.2020205@retired.ox.ac.uk> <4D2355DE.7080905@retired.ox.ac.uk> <9F02758B-A992-4ADB-89BC-F19923C0F6C1@oucs.ox.ac.uk> <4D2359A5.6000606@retired.ox.ac.uk> <4D24535B.6090707@kcl.ac.uk> Message-ID: <43A1FAAC-D72B-41DA-ADCD-4C988F36E2B1@oucs.ox.ac.uk> thanks, those examples do help. and would be the right word. sorry to be dumb, but remind me why @form on does not cut it? -- Sebastian Rahtz Information and Support Group Manager Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From lou.burnard at oucs.ox.ac.uk Wed Jan 5 06:55:51 2011 From: lou.burnard at oucs.ox.ac.uk (Lou Burnard) Date: Wed, 05 Jan 2011 11:55:51 +0000 Subject: [tei-council] FR nuncles: new element tei:objectType In-Reply-To: <43A1FAAC-D72B-41DA-ADCD-4C988F36E2B1@oucs.ox.ac.uk> References: <4D1DDB09.40904@kcl.ac.uk> <4D2352EF.2020205@retired.ox.ac.uk> <4D2355DE.7080905@retired.ox.ac.uk> <9F02758B-A992-4ADB-89BC-F19923C0F6C1@oucs.ox.ac.uk> <4D2359A5.6000606@retired.ox.ac.uk> <4D24535B.6090707@kcl.ac.uk> <43A1FAAC-D72B-41DA-ADCD-4C988F36E2B1@oucs.ox.ac.uk> Message-ID: <4D245C47.4060808@oucs.ox.ac.uk> On 05/01/11 11:48, Sebastian Rahtz wrote: > thanks, those examples do help. and would be the right word. But still ambiguous. > sorry to be dumb, but remind me why @form on does not cut it? > I wondered the same thing -- presumably it's because they want to use it in other contexts than , as with From mjd at hum.ku.dk Wed Jan 5 06:58:57 2011 From: mjd at hum.ku.dk (Matthew James Driscoll) Date: Wed, 5 Jan 2011 12:58:57 +0100 Subject: [tei-council] FR nuncles: new element tei:objectType In-Reply-To: <4D245C47.4060808@oucs.ox.ac.uk> References: <4D1DDB09.40904@kcl.ac.uk> <4D2352EF.2020205@retired.ox.ac.uk> <4D2355DE.7080905@retired.ox.ac.uk> <9F02758B-A992-4ADB-89BC-F19923C0F6C1@oucs.ox.ac.uk> <4D2359A5.6000606@retired.ox.ac.uk> <4D24535B.6090707@kcl.ac.uk> <43A1FAAC-D72B-41DA-ADCD-4C988F36E2B1@oucs.ox.ac.uk> <4D245C47.4060808@oucs.ox.ac.uk> Message-ID: Now I'm no longer on the council (bet you miss me) and therefore not entitled to an opinion, but I can't see any reason why you couldn't use @form in this way, e.g. But if this is meant to be an element in its own right, rather than an attribute, it should probably have the same name as the attribute, as is the case with material.

Early modern parchment and paper.

 So my suggestion would be to change @form to @objectType and use that also as the name of the element. Matthew -----Original Message----- From: tei-council-bounces at lists.village.Virginia.EDU [mailto:tei-council-bounces at lists.village.Virginia.EDU] On Behalf Of Lou Burnard Sent: 5. januar 2011 12:56 To: TEI Council Subject: Re: [tei-council] FR nuncles: new element tei:objectType On 05/01/11 11:48, Sebastian Rahtz wrote: > thanks, those examples do help. and would be the right word. But still ambiguous. > sorry to be dumb, but remind me why @form on does not cut it? > I wondered the same thing -- presumably it's because they want to use it in other contexts than , as with _______________________________________________ tei-council mailing list tei-council at lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council From laurent.romary at inria.fr Wed Jan 5 07:00:11 2011 From: laurent.romary at inria.fr (Laurent Romary) Date: Wed, 5 Jan 2011 13:00:11 +0100 Subject: [tei-council] FR nuncles: new element tei:objectType In-Reply-To: <4D245C47.4060808@oucs.ox.ac.uk> References: <4D1DDB09.40904@kcl.ac.uk> <4D2352EF.2020205@retired.ox.ac.uk> <4D2355DE.7080905@retired.ox.ac.uk> <9F02758B-A992-4ADB-89BC-F19923C0F6C1@oucs.ox.ac.uk> <4D2359A5.6000606@retired.ox.ac.uk> <4D24535B.6090707@kcl.ac.uk> <43A1FAAC-D72B-41DA-ADCD-4C988F36E2B1@oucs.ox.ac.uk> <4D245C47.4060808@oucs.ox.ac.uk> Message-ID: Le 5 janv. 11 ? 12:55, Lou Burnard a ?crit : > On 05/01/11 11:48, Sebastian Rahtz wrote: >> thanks, those examples do help. and would be the right word. > > But still ambiguous. From the discussion so far, I have not seen any convergence on a fancy alternative. Let us consider that we aim at providing a clear description of the thing called and move along with it. > >> sorry to be dumb, but remind me why @form on does not >> cut it? >> > > I wondered the same thing -- presumably it's because they want to > use it > in other contexts than , as with I think so too. It's a way to have a clearly reified element. Are we set on this? From gabriel.bodard at kcl.ac.uk Wed Jan 5 07:01:06 2011 From: gabriel.bodard at kcl.ac.uk (Gabriel Bodard) Date: Wed, 5 Jan 2011 12:01:06 +0000 Subject: [tei-council] FR nuncles: new element tei:objectType In-Reply-To: <43A1FAAC-D72B-41DA-ADCD-4C988F36E2B1@oucs.ox.ac.uk> References: <4D1DDB09.40904@kcl.ac.uk> <4D2352EF.2020205@retired.ox.ac.uk> <4D2355DE.7080905@retired.ox.ac.uk> <9F02758B-A992-4ADB-89BC-F19923C0F6C1@oucs.ox.ac.uk> <4D2359A5.6000606@retired.ox.ac.uk> <4D24535B.6090707@kcl.ac.uk> <43A1FAAC-D72B-41DA-ADCD-4C988F36E2B1@oucs.ox.ac.uk> Message-ID: <4D245D82.8090706@kcl.ac.uk> Because there may be more than one tei:objectType for any given text (each of which might be described in the prose content of tei:support/tei:p); and because we need to be able to point using @ref to an internal or external taxonomy of object types. (As illustrated on Elli M's DH2010 poster, as I'm sure you all remember!) G On 05/01/2011 11:48, Sebastian Rahtz wrote: > thanks, those examples do help. and would be the right word. > > sorry to be dumb, but remind me why @form on does not cut it? > > -- > Sebastian Rahtz > Information and Support Group Manager > Oxford University Computing Services > 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 > > S?lo le pido a Dios > que el futuro no me sea indiferente > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council -- Dr Gabriel BODARD (Research Associate in Digital Epigraphy) Centre for Computing in the Humanities King's College London 26-29 Drury Lane London WC2B 5RL Email: gabriel.bodard at kcl.ac.uk Tel: +44 (0)20 7848 1388 Fax: +44 (0)20 7848 2980 http://www.digitalclassicist.org/ http://www.currentepigraphy.org/ From gabriel.bodard at kcl.ac.uk Wed Jan 5 07:09:22 2011 From: gabriel.bodard at kcl.ac.uk (Gabriel Bodard) Date: Wed, 5 Jan 2011 12:09:22 +0000 Subject: [tei-council] FR nuncles: new element tei:objectType In-Reply-To: References: <4D1DDB09.40904@kcl.ac.uk> <4D2352EF.2020205@retired.ox.ac.uk> <4D2355DE.7080905@retired.ox.ac.uk> <9F02758B-A992-4ADB-89BC-F19923C0F6C1@oucs.ox.ac.uk> <4D2359A5.6000606@retired.ox.ac.uk> <4D24535B.6090707@kcl.ac.uk> <43A1FAAC-D72B-41DA-ADCD-4C988F36E2B1@oucs.ox.ac.uk> <4D245C47.4060808@oucs.ox.ac.uk> Message-ID: <4D245F72.6020604@kcl.ac.uk> If the argument is between tei:object and tei:objectType (as I think it is), then the reasons in each direction seem to be: (a) for tei:object: GB, LR & SR think it looks nicer; (b) for tei:objectType: LB says it's ambiguous (should refer to object itself, not a type or class of object); SIG may want to use tei:object to denote something broader than this MS Desc context, and closer to the meaning Lou identifies. Personally, although I'm on side (a), I'm pretty convinced (as I believe were the rest of the nuncles) by argument (b). I agree with Laurent however that we need to describe this carefully. G On 05/01/2011 12:00, Laurent Romary wrote: > > Le 5 janv. 11 ? 12:55, Lou Burnard a ?crit : > >> On 05/01/11 11:48, Sebastian Rahtz wrote: >>> thanks, those examples do help. and would be the right word. >> >> But still ambiguous. > > From the discussion so far, I have not seen any convergence on a > fancy alternative. Let us consider that we aim at providing a clear > description of the thing called and move along with it. > >> >>> sorry to be dumb, but remind me why @form on does not >>> cut it? >>> >> >> I wondered the same thing -- presumably it's because they want to >> use it >> in other contexts than, as with > > > I think so too. It's a way to have a clearly reified element. > > > Are we set on this? > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council -- Dr Gabriel BODARD (Research Associate in Digital Epigraphy) Centre for Computing in the Humanities King's College London 26-29 Drury Lane London WC2B 5RL Email: gabriel.bodard at kcl.ac.uk Tel: +44 (0)20 7848 1388 Fax: +44 (0)20 7848 2980 http://www.digitalclassicist.org/ http://www.currentepigraphy.org/ From laurent.romary at inria.fr Wed Jan 5 07:17:22 2011 From: laurent.romary at inria.fr (Laurent Romary) Date: Wed, 5 Jan 2011 13:17:22 +0100 Subject: [tei-council] FR nuncles: new element tei:objectType In-Reply-To: <4D245F72.6020604@kcl.ac.uk> References: <4D1DDB09.40904@kcl.ac.uk> <4D2352EF.2020205@retired.ox.ac.uk> <4D2355DE.7080905@retired.ox.ac.uk> <9F02758B-A992-4ADB-89BC-F19923C0F6C1@oucs.ox.ac.uk> <4D2359A5.6000606@retired.ox.ac.uk> <4D24535B.6090707@kcl.ac.uk> <43A1FAAC-D72B-41DA-ADCD-4C988F36E2B1@oucs.ox.ac.uk> <4D245C47.4060808@oucs.ox.ac.uk> <4D245F72.6020604@kcl.ac.uk> Message-ID: <557B16EE-E217-4860-8107-41F258BACA3B@inria.fr> Let us make a quick ballot on this. I suggest a yes/no answer to adopting . add your initials there: yes: LR no: Le 5 janv. 11 ? 13:09, Gabriel Bodard a ?crit : > If the argument is between tei:object and tei:objectType (as I think > it > is), then the reasons in each direction seem to be: > > (a) for tei:object: GB, LR & SR think it looks nicer; > > (b) for tei:objectType: LB says it's ambiguous (should refer to object > itself, not a type or class of object); SIG may want to use tei:object > to denote something broader than this MS Desc context, and closer to > the > meaning Lou identifies. > > Personally, although I'm on side (a), I'm pretty convinced (as I > believe > were the rest of the nuncles) by argument (b). > > I agree with Laurent however that we need to describe this carefully. > > G > > On 05/01/2011 12:00, Laurent Romary wrote: >> >> Le 5 janv. 11 ? 12:55, Lou Burnard a ?crit : >> >>> On 05/01/11 11:48, Sebastian Rahtz wrote: >>>> thanks, those examples do help. and would be the right >>>> word. >>> >>> But still ambiguous. >> >> From the discussion so far, I have not seen any convergence on a >> fancy alternative. Let us consider that we aim at providing a clear >> description of the thing called and move along with it. >> >>> >>>> sorry to be dumb, but remind me why @form on does not >>>> cut it? >>>> >>> >>> I wondered the same thing -- presumably it's because they want to >>> use it >>> in other contexts than, as with >> >> >> I think so too. It's a way to have a clearly reified element. >> >> >> Are we set on this? >> _______________________________________________ >> tei-council mailing list >> tei-council at lists.village.Virginia.EDU >> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > > -- > Dr Gabriel BODARD > (Research Associate in Digital Epigraphy) > > Centre for Computing in the Humanities > King's College London > 26-29 Drury Lane > London WC2B 5RL > Email: gabriel.bodard at kcl.ac.uk > Tel: +44 (0)20 7848 1388 > Fax: +44 (0)20 7848 2980 > > http://www.digitalclassicist.org/ > http://www.currentepigraphy.org/ > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Laurent Romary INRIA & HUB-IDSL laurent.romary at inria.fr From sebastian.rahtz at oucs.ox.ac.uk Wed Jan 5 07:20:09 2011 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Wed, 5 Jan 2011 12:20:09 +0000 Subject: [tei-council] FR nuncles: new element tei:objectType In-Reply-To: <4D245F72.6020604@kcl.ac.uk> References: <4D1DDB09.40904@kcl.ac.uk> <4D2352EF.2020205@retired.ox.ac.uk> <4D2355DE.7080905@retired.ox.ac.uk> <9F02758B-A992-4ADB-89BC-F19923C0F6C1@oucs.ox.ac.uk> <4D2359A5.6000606@retired.ox.ac.uk> <4D24535B.6090707@kcl.ac.uk> <43A1FAAC-D72B-41DA-ADCD-4C988F36E2B1@oucs.ox.ac.uk> <4D245C47.4060808@oucs.ox.ac.uk> <4D245F72.6020604@kcl.ac.uk> Message-ID: <81382B93-F062-47D3-949D-E1999A6A9A4D@oucs.ox.ac.uk> On 5 Jan 2011, at 12:09, Gabriel Bodard wrote: > > (a) for tei:object: GB, LR & SR think it looks nicer; > > (b) for tei:objectType: LB says it's ambiguous (should refer to object > itself, not a type or class of object); SIG may want to use tei:object > to denote something broader than this MS Desc context, and closer to the > meaning Lou identifies. > > Personally, although I'm on side (a), I'm pretty convinced (as I believe > were the rest of the nuncles) by argument (b). yes, its a good argument. but objectType is so weird. it makes sense when its a descent of but it will start being used elsewhere, as in " I can't get down off the fence" . look at http://www.tei-c.org/release/doc/tei-p5-doc/html/ref-model.pPart.msdesc.html and see where else it may occur. scary. in ?.. my gut feeling is to go with , but maybe we should vote on it. -- Sebastian Rahtz Information and Support Group Manager Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From lou.burnard at oucs.ox.ac.uk Wed Jan 5 08:00:19 2011 From: lou.burnard at oucs.ox.ac.uk (Lou Burnard) Date: Wed, 05 Jan 2011 13:00:19 +0000 Subject: [tei-council] how to encode a hyphen at the end of a line, column, or page when you are encoding hyphens In-Reply-To: <4D23D7F5.5040009@ultraslavonic.info> References: <4D0E7288.6010006@ultraslavonic.info> <4D0F93EF.3060100@oucs.ox.ac.uk> <4D194285.8010804@ultraslavonic.info> <4D23D7F5.5040009@ultraslavonic.info> Message-ID: <4D246B63.2040901@oucs.ox.ac.uk> Well, like Sebastian, I don't think I would attribute the lack of response on this issue to any lack of understanding on the part of Council members! Myself, I am a bit at a loss to understand what it is exactly that needs further explanation. There is a note in the element description for which reads "The type attribute may be used to characterize the line break in any respect, but its most common use is to specify that the presence of the line break does not imply the end of the word in which it is embedded. A value such as inWord or nobreak is recommended for this purpose, but encoders are free to choose whichever values are appropriate. " There is also an example in 3.10.3 (http://www.tei-c.org/release/doc/tei-p5-doc/en/html/CO.html#CORS5) which reads "The type attribute may be used on milestone elements such as lb and pb to categorize them in any way. One particularly useful way is to indicate whether or not these milestone tags are word-breaking. By default it is reasonable to assume that words are not broken across page or line boundaries, and that therefore a sequence such as ...sed imperator dixit... should be tokenized as four words (sed, imp, erator, and dixit). To make explicit that this is not the case, a tagging such as the following is recommended: ...sed imperator dixit... Where hyphenation appears before a line or page break, the encoder may or may not choose to include it, either explicitly using an appropriate Unicode character, or descriptively for example by means of the rend attribute; see further 3.2 Treatment of Punctuation . " However, it's true that the referenced section on Punctuation doesn't seem to mention hyphenation at all, so maybe it would be a good idea to add more discussion there. For me the main issue that needs to be clarified is the interaction between and whitespace with regard to implicit tokenization. The excellent TEI-L posting from one L. Burnard (http://listserv.brown.edu/archives/cgi-bin/wa?A2=ind1003&L=TEI-L&P=R22031) which you mention addresses that at length. Subsequent discussion of the issue on TEI-L seems to support the proposals therein too. So maybe what I should do is rehash that discussion a bit and bung it into 3.2 somewhere. I'll try that anyway, and post a draft here for comment. On 05/01/11 02:31, Kevin Hawkins wrote: > So, I fear that Lou is the only current Council member who really > understands the issues around hyphenation and that I am the only one who > finds the lack of clear guidance on this question in P5 to be a > significant problem. (Martin Mueller is an ally but is not on Council.) > This has come up a few times over the past few years on TEI-L, with no > changes made to P5 except the addition of a suggested value for @type in > the note attached to the definition of the lb element. > > As I mentioned last month, I find "inWord" and "nobreak" (given in the > definition of lb) unclear without examples of each. In addition, as a > reader I would expect to find in section 3.10.3 and/or 3.2 of P5 a > discussion of the three hyphen characters mentioned in 3.2: when to use > each and how they could (or should) be used in combination with the lb, > cb, and pb elements. > > Lou, since my summary sent to tei-council last month seemed to proposed > solutions to more problems that we need to solve (or simply raises > additional problems), could you write a proposal that addresses only the > narrow question (which, to be honest, I'm not even sure how to state)? > You might be able to start with your 2010-03-24 message to TEI-L. In > fact, maybe this is still the best solution, but I think we need to make > sure that points raised on TEI-L and at our discussion in Dublin have > been taken into account. Not sure whether you want to send to > tei-council or TEI-L and whether it should go into SourceForge. > > I would be be quite grateful! > > Kevin > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council From lou.burnard at oucs.ox.ac.uk Wed Jan 5 08:04:57 2011 From: lou.burnard at oucs.ox.ac.uk (Lou Burnard) Date: Wed, 05 Jan 2011 13:04:57 +0000 Subject: [tei-council] FR nuncles: new element tei:objectType In-Reply-To: <81382B93-F062-47D3-949D-E1999A6A9A4D@oucs.ox.ac.uk> References: <4D1DDB09.40904@kcl.ac.uk> <4D2352EF.2020205@retired.ox.ac.uk> <4D2355DE.7080905@retired.ox.ac.uk> <9F02758B-A992-4ADB-89BC-F19923C0F6C1@oucs.ox.ac.uk> <4D2359A5.6000606@retired.ox.ac.uk> <4D24535B.6090707@kcl.ac.uk> <43A1FAAC-D72B-41DA-ADCD-4C988F36E2B1@oucs.ox.ac.uk> <4D245C47.4060808@oucs.ox.ac.uk> <4D245F72.6020604@kcl.ac.uk> <81382B93-F062-47D3-949D-E1999A6A9A4D@oucs.ox.ac.uk> Message-ID: <4D246C79.3060700@oucs.ox.ac.uk> My gut feeling when people start using phrases like "my gut feeling" and "looks weird" is to deplore the disappearance of rational argument. The objection that "objectType" can be used out of meaningful contexts is not relevant to considerations of what its name should be: the same argument would apply whatever it was called. On 05/01/11 12:20, Sebastian Rahtz wrote: > On 5 Jan 2011, at 12:09, Gabriel Bodard wrote: > >> (a) for tei:object: GB, LR& SR think it looks nicer; >> >> (b) for tei:objectType: LB says it's ambiguous (should refer to object >> itself, not a type or class of object); SIG may want to use tei:object >> to denote something broader than this MS Desc context, and closer to the >> meaning Lou identifies. >> >> Personally, although I'm on side (a), I'm pretty convinced (as I believe >> were the rest of the nuncles) by argument (b). > > yes, its a good argument. but objectType is so weird. it makes sense > when its a descent of but it will start being used elsewhere, as > in " I can't get down off thefence" . > > look at http://www.tei-c.org/release/doc/tei-p5-doc/html/ref-model.pPart.msdesc.html > and see where else it may occur. scary. in?.. > > my gut feeling is to go with, but maybe we should vote on it. > -- > Sebastian Rahtz > Information and Support Group Manager > Oxford University Computing Services > 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 > > S?lo le pido a Dios > que el futuro no me sea indiferente > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council From mholmes at uvic.ca Wed Jan 5 08:34:57 2011 From: mholmes at uvic.ca (Martin Holmes) Date: Wed, 05 Jan 2011 05:34:57 -0800 Subject: [tei-council] FR nuncles: new element tei:objectType In-Reply-To: <4D246C79.3060700@oucs.ox.ac.uk> References: <4D1DDB09.40904@kcl.ac.uk> <4D2352EF.2020205@retired.ox.ac.uk> <4D2355DE.7080905@retired.ox.ac.uk> <9F02758B-A992-4ADB-89BC-F19923C0F6C1@oucs.ox.ac.uk> <4D2359A5.6000606@retired.ox.ac.uk> <4D24535B.6090707@kcl.ac.uk> <43A1FAAC-D72B-41DA-ADCD-4C988F36E2B1@oucs.ox.ac.uk> <4D245C47.4060808@oucs.ox.ac.uk> <4D245F72.6020604@kcl.ac.uk> <81382B93-F062-47D3-949D-E1999A6A9A4D@oucs.ox.ac.uk> <4D246C79.3060700@oucs.ox.ac.uk> Message-ID: <4D247381.5010502@uvic.ca> seems the right element name to me; I agree with Lou that where it may occur is a different question. If we're voting simply on the element name, I go for . Cheers, Martin On 11-01-05 05:04 AM, Lou Burnard wrote: > My gut feeling when people start using phrases like "my gut feeling" and > "looks weird" is to deplore the disappearance of rational argument. > > The objection that "objectType" can be used out of meaningful contexts > is not relevant to considerations of what its name should be: the same > argument would apply whatever it was called. > > > > On 05/01/11 12:20, Sebastian Rahtz wrote: >> On 5 Jan 2011, at 12:09, Gabriel Bodard wrote: >> >>> (a) for tei:object: GB, LR& SR think it looks nicer; >>> >>> (b) for tei:objectType: LB says it's ambiguous (should refer to object >>> itself, not a type or class of object); SIG may want to use tei:object >>> to denote something broader than this MS Desc context, and closer to the >>> meaning Lou identifies. >>> >>> Personally, although I'm on side (a), I'm pretty convinced (as I believe >>> were the rest of the nuncles) by argument (b). >> >> yes, its a good argument. but objectType is so weird. it makes sense >> when its a descent of but it will start being used elsewhere, as >> in " I can't get down off thefence" . >> >> look at http://www.tei-c.org/release/doc/tei-p5-doc/html/ref-model.pPart.msdesc.html >> and see where else it may occur. scary. in?.. >> >> my gut feeling is to go with, but maybe we should vote on it. >> -- >> Sebastian Rahtz >> Information and Support Group Manager >> Oxford University Computing Services >> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 >> >> S?lo le pido a Dios >> que el futuro no me sea indiferente >> >> _______________________________________________ >> tei-council mailing list >> tei-council at lists.village.Virginia.EDU >> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council From laurent.romary at inria.fr Wed Jan 5 09:20:52 2011 From: laurent.romary at inria.fr (Laurent Romary) Date: Wed, 5 Jan 2011 15:20:52 +0100 Subject: [tei-council] FR nuncles: new element tei:objectType In-Reply-To: <557B16EE-E217-4860-8107-41F258BACA3B@inria.fr> References: <4D1DDB09.40904@kcl.ac.uk> <4D2352EF.2020205@retired.ox.ac.uk> <4D2355DE.7080905@retired.ox.ac.uk> <9F02758B-A992-4ADB-89BC-F19923C0F6C1@oucs.ox.ac.uk> <4D2359A5.6000606@retired.ox.ac.uk> <4D24535B.6090707@kcl.ac.uk> <43A1FAAC-D72B-41DA-ADCD-4C988F36E2B1@oucs.ox.ac.uk> <4D245C47.4060808@oucs.ox.ac.uk> <4D245F72.6020604@kcl.ac.uk> <557B16EE-E217-4860-8107-41F258BACA3B@inria.fr> Message-ID: <6168DFA5-E2FE-4CA4-AB09-8A2861EB1453@inria.fr> Completing ballot... Le 5 janv. 11 ? 13:17, Laurent Romary a ?crit : > Let us make a quick ballot on this. I suggest a yes/no answer to > adopting . add your initials there: > > yes: LR, GB > no: MH (objectType) > > > Le 5 janv. 11 ? 13:09, Gabriel Bodard a ?crit : > >> If the argument is between tei:object and tei:objectType (as I think >> it >> is), then the reasons in each direction seem to be: >> >> (a) for tei:object: GB, LR & SR think it looks nicer; >> >> (b) for tei:objectType: LB says it's ambiguous (should refer to >> object >> itself, not a type or class of object); SIG may want to use >> tei:object >> to denote something broader than this MS Desc context, and closer to >> the >> meaning Lou identifies. >> >> Personally, although I'm on side (a), I'm pretty convinced (as I >> believe >> were the rest of the nuncles) by argument (b). >> >> I agree with Laurent however that we need to describe this carefully. >> >> G >> >> On 05/01/2011 12:00, Laurent Romary wrote: >>> >>> Le 5 janv. 11 ? 12:55, Lou Burnard a ?crit : >>> >>>> On 05/01/11 11:48, Sebastian Rahtz wrote: >>>>> thanks, those examples do help. and would be the right >>>>> word. >>>> >>>> But still ambiguous. >>> >>> From the discussion so far, I have not seen any convergence on a >>> fancy alternative. Let us consider that we aim at providing a clear >>> description of the thing called and move along with it. >>> >>>> >>>>> sorry to be dumb, but remind me why @form on does >>>>> not >>>>> cut it? >>>>> >>>> >>>> I wondered the same thing -- presumably it's because they want to >>>> use it >>>> in other contexts than, as with >>> >>> >>> I think so too. It's a way to have a clearly reified element. >>> >>> >>> Are we set on this? >>> _______________________________________________ >>> tei-council mailing list >>> tei-council at lists.village.Virginia.EDU >>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council >> >> -- >> Dr Gabriel BODARD >> (Research Associate in Digital Epigraphy) >> >> Centre for Computing in the Humanities >> King's College London >> 26-29 Drury Lane >> London WC2B 5RL >> Email: gabriel.bodard at kcl.ac.uk >> Tel: +44 (0)20 7848 1388 >> Fax: +44 (0)20 7848 2980 >> >> http://www.digitalclassicist.org/ >> http://www.currentepigraphy.org/ >> _______________________________________________ >> tei-council mailing list >> tei-council at lists.village.Virginia.EDU >> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > > Laurent Romary > INRIA & HUB-IDSL > laurent.romary at inria.fr > > > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Laurent Romary INRIA & HUB-IDSL laurent.romary at inria.fr From gabriel.bodard at kcl.ac.uk Wed Jan 5 09:26:30 2011 From: gabriel.bodard at kcl.ac.uk (Gabriel Bodard) Date: Wed, 5 Jan 2011 14:26:30 +0000 Subject: [tei-council] FR nuncles: new element tei:objectType In-Reply-To: <6168DFA5-E2FE-4CA4-AB09-8A2861EB1453@inria.fr> References: <4D1DDB09.40904@kcl.ac.uk> <4D2352EF.2020205@retired.ox.ac.uk> <4D2355DE.7080905@retired.ox.ac.uk> <9F02758B-A992-4ADB-89BC-F19923C0F6C1@oucs.ox.ac.uk> <4D2359A5.6000606@retired.ox.ac.uk> <4D24535B.6090707@kcl.ac.uk> <43A1FAAC-D72B-41DA-ADCD-4C988F36E2B1@oucs.ox.ac.uk> <4D245C47.4060808@oucs.ox.ac.uk> <4D245F72.6020604@kcl.ac.uk> <557B16EE-E217-4860-8107-41F258BACA3B@inria.fr> <6168DFA5-E2FE-4CA4-AB09-8A2861EB1453@inria.fr> Message-ID: <4D247F96.3030508@kcl.ac.uk> No, I 'd give my vote to tei:objectType, as agreed by the 4 nuncles and (I think) Lou. tei:object: LR tei:objectType: MH, GB On 05/01/2011 14:20, Laurent Romary wrote: > Completing ballot... > > Le 5 janv. 11 ? 13:17, Laurent Romary a ?crit : > >> Let us make a quick ballot on this. I suggest a yes/no answer to >> adopting. add your initials there: >> >> yes: LR, GB >> no: MH (objectType) >> >> >> Le 5 janv. 11 ? 13:09, Gabriel Bodard a ?crit : >> >>> If the argument is between tei:object and tei:objectType (as I think >>> it >>> is), then the reasons in each direction seem to be: >>> >>> (a) for tei:object: GB, LR& SR think it looks nicer; >>> >>> (b) for tei:objectType: LB says it's ambiguous (should refer to >>> object >>> itself, not a type or class of object); SIG may want to use >>> tei:object >>> to denote something broader than this MS Desc context, and closer to >>> the >>> meaning Lou identifies. >>> >>> Personally, although I'm on side (a), I'm pretty convinced (as I >>> believe >>> were the rest of the nuncles) by argument (b). >>> >>> I agree with Laurent however that we need to describe this carefully. >>> >>> G >>> >>> On 05/01/2011 12:00, Laurent Romary wrote: >>>> >>>> Le 5 janv. 11 ? 12:55, Lou Burnard a ?crit : >>>> >>>>> On 05/01/11 11:48, Sebastian Rahtz wrote: >>>>>> thanks, those examples do help. and would be the right >>>>>> word. >>>>> >>>>> But still ambiguous. >>>> >>>> From the discussion so far, I have not seen any convergence on a >>>> fancy alternative. Let us consider that we aim at providing a clear >>>> description of the thing called and move along with it. >>>> >>>>> >>>>>> sorry to be dumb, but remind me why @form on does >>>>>> not >>>>>> cut it? >>>>>> >>>>> >>>>> I wondered the same thing -- presumably it's because they want to >>>>> use it >>>>> in other contexts than, as with >>>> >>>> >>>> I think so too. It's a way to have a clearly reified element. >>>> >>>> >>>> Are we set on this? >>>> _______________________________________________ >>>> tei-council mailing list >>>> tei-council at lists.village.Virginia.EDU >>>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council >>> >>> -- >>> Dr Gabriel BODARD >>> (Research Associate in Digital Epigraphy) >>> >>> Centre for Computing in the Humanities >>> King's College London >>> 26-29 Drury Lane >>> London WC2B 5RL >>> Email: gabriel.bodard at kcl.ac.uk >>> Tel: +44 (0)20 7848 1388 >>> Fax: +44 (0)20 7848 2980 >>> >>> http://www.digitalclassicist.org/ >>> http://www.currentepigraphy.org/ >>> _______________________________________________ >>> tei-council mailing list >>> tei-council at lists.village.Virginia.EDU >>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council >> >> Laurent Romary >> INRIA& HUB-IDSL >> laurent.romary at inria.fr >> >> >> >> _______________________________________________ >> tei-council mailing list >> tei-council at lists.village.Virginia.EDU >> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > > Laurent Romary > INRIA& HUB-IDSL > laurent.romary at inria.fr > > > -- Dr Gabriel BODARD (Research Associate in Digital Epigraphy) Centre for Computing in the Humanities King's College London 26-29 Drury Lane London WC2B 5RL Email: gabriel.bodard at kcl.ac.uk Tel: +44 (0)20 7848 1388 Fax: +44 (0)20 7848 2980 http://www.digitalclassicist.org/ http://www.currentepigraphy.org/ From laurent.romary at inria.fr Wed Jan 5 09:34:10 2011 From: laurent.romary at inria.fr (Laurent Romary) Date: Wed, 5 Jan 2011 15:34:10 +0100 Subject: [tei-council] FR nuncles: new element tei:objectType In-Reply-To: <4D247F96.3030508@kcl.ac.uk> References: <4D1DDB09.40904@kcl.ac.uk> <4D2352EF.2020205@retired.ox.ac.uk> <4D2355DE.7080905@retired.ox.ac.uk> <9F02758B-A992-4ADB-89BC-F19923C0F6C1@oucs.ox.ac.uk> <4D2359A5.6000606@retired.ox.ac.uk> <4D24535B.6090707@kcl.ac.uk> <43A1FAAC-D72B-41DA-ADCD-4C988F36E2B1@oucs.ox.ac.uk> <4D245C47.4060808@oucs.ox.ac.uk> <4D245F72.6020604@kcl.ac.uk> <557B16EE-E217-4860-8107-41F258BACA3B@inria.fr> <6168DFA5-E2FE-4CA4-AB09-8A2861EB1453@inria.fr> <4D247F96.3030508@kcl.ac.uk> Message-ID: fine. others? Le 5 janv. 11 ? 15:26, Gabriel Bodard a ?crit : > No, I 'd give my vote to tei:objectType, as agreed by the 4 nuncles > and (I think) Lou. > > tei:object: LR > tei:objectType: MH, GB > > On 05/01/2011 14:20, Laurent Romary wrote: >> Completing ballot... >> >> Le 5 janv. 11 ? 13:17, Laurent Romary a ?crit : >> >>> Let us make a quick ballot on this. I suggest a yes/no answer to >>> adopting. add your initials there: >>> >>> yes: LR, GB >>> no: MH (objectType) >>> >>> >>> Le 5 janv. 11 ? 13:09, Gabriel Bodard a ?crit : >>> >>>> If the argument is between tei:object and tei:objectType (as I >>>> think >>>> it >>>> is), then the reasons in each direction seem to be: >>>> >>>> (a) for tei:object: GB, LR& SR think it looks nicer; >>>> >>>> (b) for tei:objectType: LB says it's ambiguous (should refer to >>>> object >>>> itself, not a type or class of object); SIG may want to use >>>> tei:object >>>> to denote something broader than this MS Desc context, and closer >>>> to >>>> the >>>> meaning Lou identifies. >>>> >>>> Personally, although I'm on side (a), I'm pretty convinced (as I >>>> believe >>>> were the rest of the nuncles) by argument (b). >>>> >>>> I agree with Laurent however that we need to describe this >>>> carefully. >>>> >>>> G >>>> >>>> On 05/01/2011 12:00, Laurent Romary wrote: >>>>> >>>>> Le 5 janv. 11 ? 12:55, Lou Burnard a ?crit : >>>>> >>>>>> On 05/01/11 11:48, Sebastian Rahtz wrote: >>>>>>> thanks, those examples do help. and would be the >>>>>>> right >>>>>>> word. >>>>>> >>>>>> But still ambiguous. >>>>> >>>>> From the discussion so far, I have not seen any convergence on a >>>>> fancy alternative. Let us consider that we aim at providing a >>>>> clear >>>>> description of the thing called and move along with it. >>>>> >>>>>> >>>>>>> sorry to be dumb, but remind me why @form on does >>>>>>> not >>>>>>> cut it? >>>>>>> >>>>>> >>>>>> I wondered the same thing -- presumably it's because they want to >>>>>> use it >>>>>> in other contexts than, as with >>>>> >>>>> >>>>> I think so too. It's a way to have a clearly reified element. >>>>> >>>>> >>>>> Are we set on this? >>>>> _______________________________________________ >>>>> tei-council mailing list >>>>> tei-council at lists.village.Virginia.EDU >>>>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council >>>> >>>> -- >>>> Dr Gabriel BODARD >>>> (Research Associate in Digital Epigraphy) >>>> >>>> Centre for Computing in the Humanities >>>> King's College London >>>> 26-29 Drury Lane >>>> London WC2B 5RL >>>> Email: gabriel.bodard at kcl.ac.uk >>>> Tel: +44 (0)20 7848 1388 >>>> Fax: +44 (0)20 7848 2980 >>>> >>>> http://www.digitalclassicist.org/ >>>> http://www.currentepigraphy.org/ >>>> _______________________________________________ >>>> tei-council mailing list >>>> tei-council at lists.village.Virginia.EDU >>>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council >>> >>> Laurent Romary >>> INRIA& HUB-IDSL >>> laurent.romary at inria.fr >>> >>> >>> >>> _______________________________________________ >>> tei-council mailing list >>> tei-council at lists.village.Virginia.EDU >>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council >> >> Laurent Romary >> INRIA& HUB-IDSL >> laurent.romary at inria.fr >> >> >> > > -- > Dr Gabriel BODARD > (Research Associate in Digital Epigraphy) > > Centre for Computing in the Humanities > King's College London > 26-29 Drury Lane > London WC2B 5RL > Email: gabriel.bodard at kcl.ac.uk > Tel: +44 (0)20 7848 1388 > Fax: +44 (0)20 7848 2980 > > http://www.digitalclassicist.org/ > http://www.currentepigraphy.org/ Laurent Romary INRIA & HUB-IDSL laurent.romary at inria.fr From sebastian.rahtz at oucs.ox.ac.uk Wed Jan 5 09:34:46 2011 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Wed, 5 Jan 2011 14:34:46 +0000 Subject: [tei-council] FR nuncles: new element tei:objectType In-Reply-To: <6168DFA5-E2FE-4CA4-AB09-8A2861EB1453@inria.fr> References: <4D1DDB09.40904@kcl.ac.uk> <4D2352EF.2020205@retired.ox.ac.uk> <4D2355DE.7080905@retired.ox.ac.uk> <9F02758B-A992-4ADB-89BC-F19923C0F6C1@oucs.ox.ac.uk> <4D2359A5.6000606@retired.ox.ac.uk> <4D24535B.6090707@kcl.ac.uk> <43A1FAAC-D72B-41DA-ADCD-4C988F36E2B1@oucs.ox.ac.uk> <4D245C47.4060808@oucs.ox.ac.uk> <4D245F72.6020604@kcl.ac.uk> <557B16EE-E217-4860-8107-41F258BACA3B@inria.fr> <6168DFA5-E2FE-4CA4-AB09-8A2861EB1453@inria.fr> Message-ID: <00C34F77-A058-47D4-A64E-F00259AA47BD@oucs.ox.ac.uk> Yes to -- Sebastian Rahtz Information and Support Group Manager Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From sebastian.rahtz at oucs.ox.ac.uk Wed Jan 5 09:41:23 2011 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Wed, 5 Jan 2011 14:41:23 +0000 Subject: [tei-council] FR nuncles: new element tei:objectType In-Reply-To: <4D246C79.3060700@oucs.ox.ac.uk> References: <4D1DDB09.40904@kcl.ac.uk> <4D2352EF.2020205@retired.ox.ac.uk> <4D2355DE.7080905@retired.ox.ac.uk> <9F02758B-A992-4ADB-89BC-F19923C0F6C1@oucs.ox.ac.uk> <4D2359A5.6000606@retired.ox.ac.uk> <4D24535B.6090707@kcl.ac.uk> <43A1FAAC-D72B-41DA-ADCD-4C988F36E2B1@oucs.ox.ac.uk> <4D245C47.4060808@oucs.ox.ac.uk> <4D245F72.6020604@kcl.ac.uk> <81382B93-F062-47D3-949D-E1999A6A9A4D@oucs.ox.ac.uk> <4D246C79.3060700@oucs.ox.ac.uk> Message-ID: <44BE5D1A-CD1B-4CC8-A0AD-14EBF5E59CBB@oucs.ox.ac.uk> On 5 Jan 2011, at 13:04, Lou Burnard wrote: > My gut feeling when people start using phrases like "my gut feeling" and > "looks weird" is to deplore the disappearance of rational argument. the rational argument is that "objectType" and "material" are not part of the same subset of English. the ambiguity thing bothers me, but then I think of Newport and stop worrying about it. says unamiguously to me that it marks up the word which provides the typology of the "current" object. if the element can only be used in the context of an object, fine, but if it can also be used in general context, it matters. but I do stress that this is not a resigning matter for me, I'll not mention it again if we choose -- Sebastian Rahtz Information and Support Group Manager Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From laurent.romary at inria.fr Wed Jan 5 09:41:43 2011 From: laurent.romary at inria.fr (Laurent Romary) Date: Wed, 5 Jan 2011 15:41:43 +0100 Subject: [tei-council] FR nuncles: new element tei:objectType In-Reply-To: <4D247F96.3030508@kcl.ac.uk> References: <4D1DDB09.40904@kcl.ac.uk> <4D2352EF.2020205@retired.ox.ac.uk> <4D2355DE.7080905@retired.ox.ac.uk> <9F02758B-A992-4ADB-89BC-F19923C0F6C1@oucs.ox.ac.uk> <4D2359A5.6000606@retired.ox.ac.uk> <4D24535B.6090707@kcl.ac.uk> <43A1FAAC-D72B-41DA-ADCD-4C988F36E2B1@oucs.ox.ac.uk> <4D245C47.4060808@oucs.ox.ac.uk> <4D245F72.6020604@kcl.ac.uk> <557B16EE-E217-4860-8107-41F258BACA3B@inria.fr> <6168DFA5-E2FE-4CA4-AB09-8A2861EB1453@inria.fr> <4D247F96.3030508@kcl.ac.uk> Message-ID: tei:object: LR, SR tei:objectType: MH, GB From kevin.s.hawkins at ultraslavonic.info Wed Jan 5 10:17:14 2011 From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins) Date: Wed, 05 Jan 2011 10:17:14 -0500 Subject: [tei-council] how to encode a hyphen at the end of a line, column, or page when you are encoding hyphens In-Reply-To: <4D246B63.2040901@oucs.ox.ac.uk> References: <4D0E7288.6010006@ultraslavonic.info> <4D0F93EF.3060100@oucs.ox.ac.uk> <4D194285.8010804@ultraslavonic.info> <4D23D7F5.5040009@ultraslavonic.info> <4D246B63.2040901@oucs.ox.ac.uk> Message-ID: <4D248B7A.5010400@ultraslavonic.info> While Christmas intervened in our discussion of hyphens, the vigorous discussion of objectType makes me think that all of you workaholics have been reading your email all through the holidays. On 1/5/2011 8:00 AM, Lou Burnard wrote: > Well, like Sebastian, I don't think I would attribute the lack of > response on this issue to any lack of understanding on the part of > Council members! Myself, I am a bit at a loss to understand what it is > exactly that needs further explanation. There is a note in the element > description for which reads > > "The type attribute may be used to characterize the line break in any > respect, but its most common use is to specify that the presence of the > line break does not imply the end of the word in which it is embedded. A > value such as inWord or nobreak is recommended for this purpose, but > encoders are free to choose whichever values are appropriate. " It is not clear to me whether "inWord" and "nobreak" are synonyms that both "specify that the presence of the line break does not imply the end of the word in which it is embedded", or whether only one of these values is suppposed to mean this while the other is not supposed to. Without any context, I don't understand what exactly "inWord" and "nobreak" mean. > There is also an example in 3.10.3 > (http://www.tei-c.org/release/doc/tei-p5-doc/en/html/CO.html#CORS5) > which reads > > "The type attribute may be used on milestone elements such as lb > and pb > to > categorize them in any way. One particularly useful way is to indicate > whether or not these milestone tags are word-breaking. By default it is > reasonable to assume that words are not broken across page or line > boundaries, and that therefore a sequence such as > ...sed imperator dixit... > should be tokenized as four words (sed, imp, erator, and dixit). To make > explicit that this is not the case, a tagging such as the following is > recommended: > ...sed imperator dixit... > Where hyphenation appears before a line or page break, the encoder may > or may not choose to include it, either explicitly using an appropriate > Unicode character, or descriptively for example by means of the rend > attribute; see further 3.2 Treatment of Punctuation > . " The following are unclear to me: a) whether the source document had a hyphen or other indication that "imperator" is to be considered as single word. That is, an image of the source document would be helpful here. b) If the encoder chooses to include hyphenation, either explicitly using an appropriate Unicode character, which Unicode character is appropriate? c) If the encoder chooses to include hyphenation descriptive by means of the rend= attribute, what sorts of value(s) for rend= are recommended? > However, it's true that the referenced section on Punctuation doesn't > seem to mention hyphenation at all, so maybe it would be a good idea to > add more discussion there. The introduction to that section mentions three Unicode characters for "hyphens" but does not give any guidance on the use of them. > For me the main issue that needs to be clarified is the interaction > between and whitespace with regard to implicit tokenization. The > excellent TEI-L posting from one L. Burnard > (http://listserv.brown.edu/archives/cgi-bin/wa?A2=ind1003&L=TEI-L&P=R22031) > which you mention addresses that at length. Subsequent discussion of the > issue on TEI-L seems to support the proposals therein too. So maybe what > I should do is rehash that discussion a bit and bung it into 3.2 > somewhere. I'll try that anyway, and post a draft here for comment. Excellent. From lou.burnard at retired.ox.ac.uk Wed Jan 5 10:17:56 2011 From: lou.burnard at retired.ox.ac.uk (Lou Burnard) Date: Wed, 05 Jan 2011 15:17:56 +0000 Subject: [tei-council] FR nuncles: new element tei:objectType In-Reply-To: <44BE5D1A-CD1B-4CC8-A0AD-14EBF5E59CBB@oucs.ox.ac.uk> References: <4D1DDB09.40904@kcl.ac.uk> <4D2352EF.2020205@retired.ox.ac.uk> <4D2355DE.7080905@retired.ox.ac.uk> <9F02758B-A992-4ADB-89BC-F19923C0F6C1@oucs.ox.ac.uk> <4D2359A5.6000606@retired.ox.ac.uk> <4D24535B.6090707@kcl.ac.uk> <43A1FAAC-D72B-41DA-ADCD-4C988F36E2B1@oucs.ox.ac.uk> <4D245C47.4060808@oucs.ox.ac.uk> <4D245F72.6020604@kcl.ac.uk> <81382B93-F062-47D3-949D-E1999A6A9A4D@oucs.ox.ac.uk> <4D246C79.3060700@oucs.ox.ac.uk> <44BE5D1A-CD1B-4CC8-A0AD-14EBF5E59CBB@oucs.ox.ac.uk> Message-ID: <4D248BA4.8050203@retired.ox.ac.uk> On 05/01/11 14:41, Sebastian Rahtz wrote: > > > the ambiguity thing bothers me, but then I think of > Newport and stop worrying about it. Eh? surely we have both placeName and place precisely to avoid an ambiguity? > > says unamiguously to me that it marks up > the word which provides the typology of the "current" object. ah, I think not. it says to me "my content represents some type of object" . If it's inside some element which says "my content describes some specific object", then it might or might not tell me about that object's type. It might say "once believed to be a hawk, now known to be a handsaw" however > if the element can only be used in the context of an object, fine, > but if it can also be used in general context, it matters. > > but I do stress that this is not a resigning matter for me, I'll > not mention it again if we choose likewise, I'm sure :-) From sebastian.rahtz at oucs.ox.ac.uk Wed Jan 5 10:26:41 2011 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Wed, 5 Jan 2011 15:26:41 +0000 Subject: [tei-council] FR nuncles: new element tei:objectType In-Reply-To: <4D248BA4.8050203@retired.ox.ac.uk> References: <4D1DDB09.40904@kcl.ac.uk> <4D2352EF.2020205@retired.ox.ac.uk> <4D2355DE.7080905@retired.ox.ac.uk> <9F02758B-A992-4ADB-89BC-F19923C0F6C1@oucs.ox.ac.uk> <4D2359A5.6000606@retired.ox.ac.uk> <4D24535B.6090707@kcl.ac.uk> <43A1FAAC-D72B-41DA-ADCD-4C988F36E2B1@oucs.ox.ac.uk> <4D245C47.4060808@oucs.ox.ac.uk> <4D245F72.6020604@kcl.ac.uk> <81382B93-F062-47D3-949D-E1999A6A9A4D@oucs.ox.ac.uk> <4D246C79.3060700@oucs.ox.ac.uk> <44BE5D1A-CD1B-4CC8-A0AD-14EBF5E59CBB@oucs.ox.ac.uk> <4D248BA4.8050203@retired.ox.ac.uk> Message-ID: <855D0478-9A8C-4273-9BF6-4E0801013477@oucs.ox.ac.uk> On 5 Jan 2011, at 15:17, Lou Burnard wrote: > On 05/01/11 14:41, Sebastian Rahtz wrote: >> >> >> the ambiguity thing bothers me, but then I think of >> Newport and stop worrying about it. > > Eh? surely we have both placeName and place precisely to avoid an ambiguity? is different, its not phrase level > > If it's inside some element which says "my content describes > some specific object", then it might or might not tell me about that > object's type. It might say "once believed to be a > hawk, now known to be a > handsaw" however fair enuf. I could live with it > -- Sebastian Rahtz Information and Support Group Manager Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From bbarney2 at unlnotes.unl.edu Wed Jan 5 10:34:52 2011 From: bbarney2 at unlnotes.unl.edu (Brett Barney) Date: Wed, 5 Jan 2011 09:34:52 -0600 Subject: [tei-council] FR nuncles: new element tei:objectType In-Reply-To: References: <4D1DDB09.40904@kcl.ac.uk> <4D2352EF.2020205@retired.ox.ac.uk> <4D2355DE.7080905@retired.ox.ac.uk> <9F02758B-A992-4ADB-89BC-F19923C0F6C1@oucs.ox.ac.uk> <4D2359A5.6000606@retired.ox.ac.uk> <4D24535B.6090707@kcl.ac.uk> <43A1FAAC-D72B-41DA-ADCD-4C988F36E2B1@oucs.ox.ac.uk> <4D245C47.4060808@oucs.ox.ac.uk> <4D245F72.6020604@kcl.ac.uk> <557B16EE-E217-4860-8107-41F258BACA3B@inria.fr> <6168DFA5-E2FE-4CA4-AB09-8A2861EB1453@inria.fr> <4D247F96.3030508@kcl.ac.uk> Message-ID: tei:object: LR, SR tei:objectType: MH, GB, BB _______________________________________________ tei-council mailing list tei-council at lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council From James.Cummings at oucs.ox.ac.uk Wed Jan 5 10:44:08 2011 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Wed, 05 Jan 2011 15:44:08 +0000 Subject: [tei-council] FR nuncles: new element tei:objectType In-Reply-To: References: <4D1DDB09.40904@kcl.ac.uk> <4D2352EF.2020205@retired.ox.ac.uk> <4D2355DE.7080905@retired.ox.ac.uk> <9F02758B-A992-4ADB-89BC-F19923C0F6C1@oucs.ox.ac.uk> <4D2359A5.6000606@retired.ox.ac.uk> <4D24535B.6090707@kcl.ac.uk> <43A1FAAC-D72B-41DA-ADCD-4C988F36E2B1@oucs.ox.ac.uk> <4D245C47.4060808@oucs.ox.ac.uk> <4D245F72.6020604@kcl.ac.uk> <557B16EE-E217-4860-8107-41F258BACA3B@inria.fr> <6168DFA5-E2FE-4CA4-AB09-8A2861EB1453@inria.fr> <4D247F96.3030508@kcl.ac.uk> Message-ID: <4D2491C8.4070004@oucs.ox.ac.uk> On 05/01/11 14:41, Laurent Romary wrote: > tei:object: LR, SR > tei:objectType: MH, GB I've re-read the ticket & comments, and all the emails about it. I would like to express more than the above list of for-one-or-other gives me the ability to. So I've put up a little doodle.com poll that you can all fill in: http://doodle.com/nu49sr76mg9kirdg This allows you to say: - In favour - Could live with this option - Against for each proposed option. In this case I've put in tei:object, tei:objectType and 'neither' (for those who think both are wrong). My vote is: tei:object: Against (because I think that is a really bad name) tei:objectType: In Favour neither: Could live with this option. Doodle.com also happens to use a very similar traffic-light system of green/yellow/red as we do in classifying our tickets. Might I propose that anytime we want to have a quick show of hands we use some system like this rather than having to collate various emails? (We should of course copy the final result back to the mailing list so it is preserved in the archive.) My vote and my two pence, -James -- Dr James Cummings, Research Technologies Service OUCS, University of Oxford From laurent.romary at inria.fr Wed Jan 5 11:13:25 2011 From: laurent.romary at inria.fr (Laurent Romary) Date: Wed, 5 Jan 2011 17:13:25 +0100 Subject: [tei-council] FR nuncles: new element tei:objectType In-Reply-To: <4D2491C8.4070004@oucs.ox.ac.uk> References: <4D1DDB09.40904@kcl.ac.uk> <4D2352EF.2020205@retired.ox.ac.uk> <4D2355DE.7080905@retired.ox.ac.uk> <9F02758B-A992-4ADB-89BC-F19923C0F6C1@oucs.ox.ac.uk> <4D2359A5.6000606@retired.ox.ac.uk> <4D24535B.6090707@kcl.ac.uk> <43A1FAAC-D72B-41DA-ADCD-4C988F36E2B1@oucs.ox.ac.uk> <4D245C47.4060808@oucs.ox.ac.uk> <4D245F72.6020604@kcl.ac.uk> <557B16EE-E217-4860-8107-41F258BACA3B@inria.fr> <6168DFA5-E2FE-4CA4-AB09-8A2861EB1453@inria.fr> <4D247F96.3030508@kcl.ac.uk> <4D2491C8.4070004@oucs.ox.ac.uk> Message-ID: <1FBF12E4-3BFD-42F7-8E6A-CB07044B81B8@inria.fr> ... OK. I'll complete existing votes by hand. Will help me to recover from my flue (ergotherapy, I think). Le 5 janv. 11 ? 16:44, James Cummings a ?crit : > On 05/01/11 14:41, Laurent Romary wrote: >> tei:object: LR, SR >> tei:objectType: MH, GB > > I've re-read the ticket & comments, and all the emails about it. > I would like to express more than the above list of > for-one-or-other gives me the ability to. So I've put up a > little doodle.com poll that you can all fill in: > > http://doodle.com/nu49sr76mg9kirdg > > This allows you to say: > - In favour > - Could live with this option > - Against > for each proposed option. > > In this case I've put in tei:object, tei:objectType and 'neither' > (for those who think both are wrong). > > My vote is: > tei:object: Against (because I think that is a really bad name) > tei:objectType: In Favour > neither: Could live with this option. > > Doodle.com also happens to use a very similar traffic-light > system of green/yellow/red as we do in classifying our tickets. > Might I propose that anytime we want to have a quick show of > hands we use some system like this rather than having to collate > various emails? (We should of course copy the final result back > to the mailing list so it is preserved in the archive.) > > My vote and my two pence, > -James > > -- > Dr James Cummings, Research Technologies Service > OUCS, University of Oxford > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Laurent Romary INRIA & HUB-IDSL laurent.romary at inria.fr From elena.pierazzo at kcl.ac.uk Wed Jan 5 11:59:20 2011 From: elena.pierazzo at kcl.ac.uk (Elena Pierazzo) Date: Wed, 5 Jan 2011 16:59:20 +0000 Subject: [tei-council] FR nuncles: new element tei:objectType In-Reply-To: <1FBF12E4-3BFD-42F7-8E6A-CB07044B81B8@inria.fr> References: <4D1DDB09.40904@kcl.ac.uk> <4D2352EF.2020205@retired.ox.ac.uk> <4D2355DE.7080905@retired.ox.ac.uk> <9F02758B-A992-4ADB-89BC-F19923C0F6C1@oucs.ox.ac.uk> <4D2359A5.6000606@retired.ox.ac.uk> <4D24535B.6090707@kcl.ac.uk> <43A1FAAC-D72B-41DA-ADCD-4C988F36E2B1@oucs.ox.ac.uk> <4D245C47.4060808@oucs.ox.ac.uk> <4D245F72.6020604@kcl.ac.uk> <557B16EE-E217-4860-8107-41F258BACA3B@inria.fr> <6168DFA5-E2FE-4CA4-AB09-8A2861EB1453@inria.fr> <4D247F96.3030508@kcl.ac.uk> <4D2491C8.4070004@oucs.ox.ac.uk> <1FBF12E4-3BFD-42F7-8E6A-CB07044B81B8@inria.fr> Message-ID: <723632EA-780F-45B1-90CD-C2D460972FD9@kcl.ac.uk> I'm for tei:objectDesc as the argument made by the SIG and in particular by ?yvind seems pretty stringent to me. I've also filled my doodle, but I thought to say it anyway (it seemed such a lively party that I wanted to be in it!) Cheers E On 5 Jan 2011, at 16:13, Laurent Romary wrote: > ... OK. I'll complete existing votes by hand. Will help me to recover > from my flue (ergotherapy, I think). > > Le 5 janv. 11 ? 16:44, James Cummings a ?crit : > >> On 05/01/11 14:41, Laurent Romary wrote: >>> tei:object: LR, SR >>> tei:objectType: MH, GB >> >> I've re-read the ticket & comments, and all the emails about it. >> I would like to express more than the above list of >> for-one-or-other gives me the ability to. So I've put up a >> little doodle.com poll that you can all fill in: >> >> http://doodle.com/nu49sr76mg9kirdg >> >> This allows you to say: >> - In favour >> - Could live with this option >> - Against >> for each proposed option. >> >> In this case I've put in tei:object, tei:objectType and 'neither' >> (for those who think both are wrong). >> >> My vote is: >> tei:object: Against (because I think that is a really bad name) >> tei:objectType: In Favour >> neither: Could live with this option. >> >> Doodle.com also happens to use a very similar traffic-light >> system of green/yellow/red as we do in classifying our tickets. >> Might I propose that anytime we want to have a quick show of >> hands we use some system like this rather than having to collate >> various emails? (We should of course copy the final result back >> to the mailing list so it is preserved in the archive.) >> >> My vote and my two pence, >> -James >> >> -- >> Dr James Cummings, Research Technologies Service >> OUCS, University of Oxford >> _______________________________________________ >> tei-council mailing list >> tei-council at lists.village.Virginia.EDU >> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > > Laurent Romary > INRIA & HUB-IDSL > laurent.romary at inria.fr > > > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council -- Dr Elena Pierazzo Lecturer in Digital Humanities Centre for Computing in the Humanities King's College London 26-29 Drury Lane London WC2B 5RL Phone: 0207-848-1949 Fax: 0207-848-2980 elena.pierazzo at kcl.ac.uk www.kcl.ac.uk From mholmes at uvic.ca Wed Jan 5 12:03:59 2011 From: mholmes at uvic.ca (Martin Holmes) Date: Wed, 5 Jan 2011 09:03:59 -0800 Subject: [tei-council] how to encode a hyphen at the end of a line, column, or page when you are encoding hyphens In-Reply-To: <10C726D9-029A-43CF-86D5-DD69BD0778DC@oucs.ox.ac.uk> References: <4D0E7288.6010006@ultraslavonic.info> <4D0F93EF.3060100@oucs.ox.ac.uk> <4D194285.8010804@ultraslavonic.info> <4D23D7F5.5040009@ultraslavonic.info> <10C726D9-029A-43CF-86D5-DD69BD0778DC@oucs.ox.ac.uk> Message-ID: <4D24A47F.3080107@uvic.ca> I'm still interested in this, but it looks as though my proposal (C, with astute corrections from Kevin at the bottom) didn't find any favour, so I'm really waiting for a single coherent suggestion to vote on, or a couple of agreed alternatives to choose between. I think the problems arise because we're actually talking about how to do three different things: provide adequate assistance to a tokenizer (which Lou strongly argues for), categorize the break itself, and specify how the break is rendered (hyphen, repeated letter, nothing at all). So perhaps we could start by answering one simple question: Do we believe that the existence of a hyphen, doubling, etc. should be expressed through character data external to the break, or should it be expressed through @rend? In other words: help-ful or helpful Cheers, Martin On 11-01-05 01:54 AM, Sebastian Rahtz wrote: > > On 5 Jan 2011, at 02:31, Kevin Hawkins wrote: > >> So, I fear that Lou is the only current Council member who really >> understands the issues around hyphenation and that I am the only one who >> finds the lack of clear guidance on this question in P5 to be a >> significant problem. > > there are other possible interpretations, related to recent religious festivals? > > -- > Sebastian Rahtz > Information and Support Group Manager > Oxford University Computing Services > 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 > > S?lo le pido a Dios > que el futuro no me sea indiferente > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > -- Martin Holmes University of Victoria Humanities Computing and Media Centre (mholmes at uvic.ca) From sebastian.rahtz at oucs.ox.ac.uk Wed Jan 5 12:08:20 2011 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Wed, 5 Jan 2011 17:08:20 +0000 Subject: [tei-council] FR nuncles: new element tei:objectType In-Reply-To: <4D2491C8.4070004@oucs.ox.ac.uk> References: <4D1DDB09.40904@kcl.ac.uk> <4D2352EF.2020205@retired.ox.ac.uk> <4D2355DE.7080905@retired.ox.ac.uk> <9F02758B-A992-4ADB-89BC-F19923C0F6C1@oucs.ox.ac.uk> <4D2359A5.6000606@retired.ox.ac.uk> <4D24535B.6090707@kcl.ac.uk> <43A1FAAC-D72B-41DA-ADCD-4C988F36E2B1@oucs.ox.ac.uk> <4D245C47.4060808@oucs.ox.ac.uk> <4D245F72.6020604@kcl.ac.uk> <557B16EE-E217-4860-8107-41F258BACA3B@inria.fr> <6168DFA5-E2FE-4CA4-AB09-8A2861EB1453@inria.fr> <4D247F96.3030508@kcl.ac.uk> <4D2491C8.4070004@oucs.ox.ac.uk> Message-ID: <0712DC58-C536-436C-8A7C-59143AC93CEC@oucs.ox.ac.uk> cant help thinking that MH's attempt to vote 3 times is unsporting :-} -- Sebastian Rahtz Information and Support Group Manager Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From mholmes at uvic.ca Wed Jan 5 12:10:20 2011 From: mholmes at uvic.ca (Martin Holmes) Date: Wed, 5 Jan 2011 09:10:20 -0800 Subject: [tei-council] FR nuncles: new element tei:objectType In-Reply-To: <0712DC58-C536-436C-8A7C-59143AC93CEC@oucs.ox.ac.uk> References: <4D1DDB09.40904@kcl.ac.uk> <4D2352EF.2020205@retired.ox.ac.uk> <4D2355DE.7080905@retired.ox.ac.uk> <9F02758B-A992-4ADB-89BC-F19923C0F6C1@oucs.ox.ac.uk> <4D2359A5.6000606@retired.ox.ac.uk> <4D24535B.6090707@kcl.ac.uk> <43A1FAAC-D72B-41DA-ADCD-4C988F36E2B1@oucs.ox.ac.uk> <4D245C47.4060808@oucs.ox.ac.uk> <4D245F72.6020604@kcl.ac.uk> <557B16EE-E217-4860-8107-41F258BACA3B@inria.fr> <6168DFA5-E2FE-4CA4-AB09-8A2861EB1453@inria.fr> <4D247F96.3030508@kcl.ac.uk> <4D2491C8.4070004@oucs.ox.ac.uk> <0712DC58-C536-436C-8A7C-59143AC93CEC@oucs.ox.ac.uk> Message-ID: <4D24A5FC.6040605@uvic.ca> I just wrote to James about this. I went to the poll and dutifully voted, then realized that someone (James presumably) had already added me, twice. And there seems to be no way for me to delete my vote(s)... Cheers, Martin On 11-01-05 09:08 AM, Sebastian Rahtz wrote: > cant help thinking that MH's attempt to vote 3 times is unsporting :-} > -- > Sebastian Rahtz > Information and Support Group Manager > Oxford University Computing Services > 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 > > S?lo le pido a Dios > que el futuro no me sea indiferente > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > -- Martin Holmes University of Victoria Humanities Computing and Media Centre (mholmes at uvic.ca) From elena.pierazzo at kcl.ac.uk Wed Jan 5 12:17:29 2011 From: elena.pierazzo at kcl.ac.uk (Elena Pierazzo) Date: Wed, 5 Jan 2011 17:17:29 +0000 Subject: [tei-council] how to encode a hyphen at the end of a line, column, or page when you are encoding hyphens In-Reply-To: <4D24A47F.3080107@uvic.ca> References: <4D0E7288.6010006@ultraslavonic.info> <4D0F93EF.3060100@oucs.ox.ac.uk> <4D194285.8010804@ultraslavonic.info> <4D23D7F5.5040009@ultraslavonic.info> <10C726D9-029A-43CF-86D5-DD69BD0778DC@oucs.ox.ac.uk> <4D24A47F.3080107@uvic.ca> Message-ID: <290D6DCD-3CC3-4C70-8BDC-07D434F194D5@kcl.ac.uk> Hi All, > Do we believe that the existence of a hyphen, doubling, etc. should be > expressed through character data external to the break, or should it > be > expressed through @rend? In other words: > > help-ful > > or > > helpful The latter is the choice I have done for most of my projects, but I'm not sure to be honest that this is the best option. While I think that to use a character is very problematic (I won't list all the reasons because we have been already there), I'm not sure about the @rend either. For instance Jane Austen uses a mark at the end of the line and one at the beginning of the line to mark words break and those markers are: - = : variously combined, so we ended up with a very long list of values for the @rend, for instance: double_colon double_equal double_hyphen colon_hyphen hyphen_colon colon_equal equal_colon equal_hyphen etc. I was wondering i there was a more elegant possibility here respect the @rend... In addition, as the mark the *beginning* of the line (or at least that's is what we say in the Guidelines) it seems odd to use the @rend for something that is normally at the end of the line (a part when it is both at the end and beginning as for my example). What about an element? what about ? Elena -- Dr Elena Pierazzo Lecturer in Digital Humanities Centre for Computing in the Humanities King's College London 26-29 Drury Lane London WC2B 5RL Phone: 0207-848-1949 Fax: 0207-848-2980 elena.pierazzo at kcl.ac.uk www.kcl.ac.uk From sebastian.rahtz at oucs.ox.ac.uk Wed Jan 5 12:22:18 2011 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Wed, 5 Jan 2011 17:22:18 +0000 Subject: [tei-council] how to encode a hyphen at the end of a line, column, or page when you are encoding hyphens In-Reply-To: <4D24A47F.3080107@uvic.ca> References: <4D0E7288.6010006@ultraslavonic.info> <4D0F93EF.3060100@oucs.ox.ac.uk> <4D194285.8010804@ultraslavonic.info> <4D23D7F5.5040009@ultraslavonic.info> <10C726D9-029A-43CF-86D5-DD69BD0778DC@oucs.ox.ac.uk> <4D24A47F.3080107@uvic.ca> Message-ID: <525D997E-9851-4819-AD0C-F59C44A249A4@oucs.ox.ac.uk> On 5 Jan 2011, at 17:03, Martin Holmes wrote: > So perhaps we could start by answering one simple question: > > Do we believe that the existence of a hyphen, doubling, etc. should be > expressed through character data external to the break, or should it be > expressed through @rend? In other words: > > help-ful > > or > > helpful I do fear this is shutting the stable door after the horse. Both ways of working are out there in the wild, are "supported" by TEI for 20 years, and each has its merits. I suppose we could recommend afresh, tho, in which case I'd go with the @rend option where possible (bearing in mind I need to commit myself to distinguishing typesetter's hyphenation from author-ial hyphenation.) When I say bed- wetters, are you sure you you know wh- at I mean? A type- setter once hyphen- ated G- od -- Sebastian Rahtz Information and Support Group Manager Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From James.Cummings at oucs.ox.ac.uk Wed Jan 5 12:23:44 2011 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Wed, 05 Jan 2011 17:23:44 +0000 Subject: [tei-council] FR nuncles: new element tei:objectType In-Reply-To: <4D24A5FC.6040605@uvic.ca> References: <4D1DDB09.40904@kcl.ac.uk> <4D2352EF.2020205@retired.ox.ac.uk> <4D2355DE.7080905@retired.ox.ac.uk> <9F02758B-A992-4ADB-89BC-F19923C0F6C1@oucs.ox.ac.uk> <4D2359A5.6000606@retired.ox.ac.uk> <4D24535B.6090707@kcl.ac.uk> <43A1FAAC-D72B-41DA-ADCD-4C988F36E2B1@oucs.ox.ac.uk> <4D245C47.4060808@oucs.ox.ac.uk> <4D245F72.6020604@kcl.ac.uk> <557B16EE-E217-4860-8107-41F258BACA3B@inria.fr> <6168DFA5-E2FE-4CA4-AB09-8A2861EB1453@inria.fr> <4D247F96.3030508@kcl.ac.uk> <4D2491C8.4070004@oucs.ox.ac.uk> <0712DC58-C536-436C-8A7C-59143AC93CEC@oucs.ox.ac.uk> <4D24A5FC.6040605@uvic.ca> Message-ID: <4D24A920.70703@oucs.ox.ac.uk> I have deleted all MH's. I did not add any of them. I assume that was LR trying to tally up what people had already voted for. The administrator for any poll can edit it in any way, (even changing what people voted for), but I will, of course, not do this other than to remove MH's votes. MH... go vote again. ;-) -James On 05/01/11 17:10, Martin Holmes wrote: > I just wrote to James about this. I went to the poll and dutifully > voted, then realized that someone (James presumably) had already added > me, twice. And there seems to be no way for me to delete my vote(s)... > > Cheers, > Martin > > On 11-01-05 09:08 AM, Sebastian Rahtz wrote: >> cant help thinking that MH's attempt to vote 3 times is unsporting :-} >> -- >> Sebastian Rahtz >> Information and Support Group Manager >> Oxford University Computing Services >> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 >> >> S?lo le pido a Dios >> que el futuro no me sea indiferente >> >> _______________________________________________ >> tei-council mailing list >> tei-council at lists.village.Virginia.EDU >> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council >> > -- Dr James Cummings, Research Technologies Service OUCS, University of Oxford From laurent.romary at inria.fr Wed Jan 5 12:27:39 2011 From: laurent.romary at inria.fr (Laurent Romary) Date: Wed, 5 Jan 2011 18:27:39 +0100 Subject: [tei-council] FR nuncles: new element tei:objectType In-Reply-To: <4D24A920.70703@oucs.ox.ac.uk> References: <4D1DDB09.40904@kcl.ac.uk> <4D2352EF.2020205@retired.ox.ac.uk> <4D2355DE.7080905@retired.ox.ac.uk> <9F02758B-A992-4ADB-89BC-F19923C0F6C1@oucs.ox.ac.uk> <4D2359A5.6000606@retired.ox.ac.uk> <4D24535B.6090707@kcl.ac.uk> <43A1FAAC-D72B-41DA-ADCD-4C988F36E2B1@oucs.ox.ac.uk> <4D245C47.4060808@oucs.ox.ac.uk> <4D245F72.6020604@kcl.ac.uk> <557B16EE-E217-4860-8107-41F258BACA3B@inria.fr> <6168DFA5-E2FE-4CA4-AB09-8A2861EB1453@inria.fr> <4D247F96.3030508@kcl.ac.uk> <4D2491C8.4070004@oucs.ox.ac.uk> <0712DC58-C536-436C-8A7C-59143AC93CEC@oucs.ox.ac.uk> <4D24A5FC.6040605@uvic.ca> <4D24A920.70703@oucs.ox.ac.uk> Message-ID: <584F418B-515C-4649-8AE2-DD2817392256@inria.fr> OK. Let us at least decide that we are not over-creative in the middle of a decision process. But I am opend for advice in between them... Le 5 janv. 11 ? 18:23, James Cummings a ?crit : > > I have deleted all MH's. I did not add any of them. I assume > that was LR trying to tally up what people had already voted for. > The administrator for any poll can edit it in any way, (even > changing what people voted for), but I will, of course, not do > this other than to remove MH's votes. > > MH... go vote again. ;-) > > > -James > > On 05/01/11 17:10, Martin Holmes wrote: >> I just wrote to James about this. I went to the poll and dutifully >> voted, then realized that someone (James presumably) had already >> added >> me, twice. And there seems to be no way for me to delete my >> vote(s)... >> >> Cheers, >> Martin >> >> On 11-01-05 09:08 AM, Sebastian Rahtz wrote: >>> cant help thinking that MH's attempt to vote 3 times is >>> unsporting :-} >>> -- >>> Sebastian Rahtz >>> Information and Support Group Manager >>> Oxford University Computing Services >>> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 >>> >>> S?lo le pido a Dios >>> que el futuro no me sea indiferente >>> >>> _______________________________________________ >>> tei-council mailing list >>> tei-council at lists.village.Virginia.EDU >>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council >>> >> > > > -- > Dr James Cummings, Research Technologies Service > OUCS, University of Oxford > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Laurent Romary INRIA & HUB-IDSL laurent.romary at inria.fr From gabriel.bodard at kcl.ac.uk Wed Jan 5 12:51:39 2011 From: gabriel.bodard at kcl.ac.uk (Gabriel Bodard) Date: Wed, 5 Jan 2011 17:51:39 +0000 Subject: [tei-council] how to encode a hyphen at the end of a line, column, or page when you are encoding hyphens In-Reply-To: <290D6DCD-3CC3-4C70-8BDC-07D434F194D5@kcl.ac.uk> References: <4D0E7288.6010006@ultraslavonic.info> <4D0F93EF.3060100@oucs.ox.ac.uk> <4D194285.8010804@ultraslavonic.info> <4D23D7F5.5040009@ultraslavonic.info> <10C726D9-029A-43CF-86D5-DD69BD0778DC@oucs.ox.ac.uk> <4D24A47F.3080107@uvic.ca> <290D6DCD-3CC3-4C70-8BDC-07D434F194D5@kcl.ac.uk> Message-ID: <4D24AFAB.2060506@kcl.ac.uk> I don't know if is the right element for what you suggest; perhaps would be more appropriate (or does tei:pc require the literal hyphen to be included as well?). But yes, having some way to indicate (a) the presence and (b) the form of some explicit hyphenation in the source text is useful. (For example, we might want to mark this hyphenation as "unclear" if the ink is faded or the hyphen could be confused with an elaborate serif.) I expect Sebastian is right however and we have to continue to tolerate the use of simple ASCII '-' in the text, especially if the markup is machine-generated and/or the coder doesn't want to disambiguate between compound words and line-divided words, etc. Martin's three questions are useful: some of them are I think resolved, others are relatively simple (especially if, as here, we allow multiple solutions). I suspect that a series of long emails arguing over various aspects of all three questions at once has put some people off from engaging with the debate. (I confess that was my position before the vacation.) For this question first, therefore, can we agree on a best practice and other acceptable possibilities? On 05/01/2011 17:17, Elena Pierazzo wrote: > Hi All, > >> Do we believe that the existence of a hyphen, doubling, etc. should be >> expressed through character data external to the break, or should it >> be >> expressed through @rend? In other words: >> >> help-ful >> >> or >> >> helpful > > > The latter is the choice I have done for most of my projects, but I'm > not sure to be honest that this is the best option. While I think that > to use a character is very problematic (I won't list all the reasons > because we have been already there), I'm not sure about the @rend > either. > > For instance Jane Austen uses a mark at the end of the line and one at > the beginning of the line to mark words break and those markers are: > - > = > : > > variously combined, so we ended up with a very long list of values for > the @rend, for instance: > > double_colon > double_equal > double_hyphen > colon_hyphen > hyphen_colon > colon_equal > equal_colon > equal_hyphen > etc. > > I was wondering i there was a more elegant possibility here respect > the @rend... > > In addition, as the mark the *beginning* of the line (or at > least that's is what we say in the Guidelines) it seems odd to use the > @rend for something that is normally at the end of the line (a part > when it is both at the end and beginning as for my example). > What about an element? what about? > > Elena > > -- > Dr Elena Pierazzo > Lecturer in Digital Humanities > Centre for Computing in the Humanities > King's College London > 26-29 Drury Lane > London WC2B 5RL > > Phone: 0207-848-1949 > Fax: 0207-848-2980 > elena.pierazzo at kcl.ac.uk > www.kcl.ac.uk > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council -- Dr Gabriel BODARD (Research Associate in Digital Epigraphy) Centre for Computing in the Humanities King's College London 26-29 Drury Lane London WC2B 5RL Email: gabriel.bodard at kcl.ac.uk Tel: +44 (0)20 7848 1388 Fax: +44 (0)20 7848 2980 http://www.digitalclassicist.org/ http://www.currentepigraphy.org/ From lou.burnard at retired.ox.ac.uk Wed Jan 5 16:06:50 2011 From: lou.burnard at retired.ox.ac.uk (Lou Burnard) Date: Wed, 05 Jan 2011 21:06:50 +0000 Subject: [tei-council] how to encode a hyphen at the end of a line, column, or page when you are encoding hyphens In-Reply-To: <4D24A47F.3080107@uvic.ca> References: <4D0E7288.6010006@ultraslavonic.info> <4D0F93EF.3060100@oucs.ox.ac.uk> <4D194285.8010804@ultraslavonic.info> <4D23D7F5.5040009@ultraslavonic.info> <10C726D9-029A-43CF-86D5-DD69BD0778DC@oucs.ox.ac.uk> <4D24A47F.3080107@uvic.ca> Message-ID: <4D24DD6A.8020803@retired.ox.ac.uk> On 05/01/11 17:03, Martin Holmes wrote: > > Do we believe that the existence of a hyphen, doubling, etc. should be > expressed through character data external to the break, or should it be > expressed through @rend? In other words: > > help-ful > > or > > helpful > I fear I don't think this is a question for voting on. It is clear, if you look back through the discussion, that there is simply no consensus in the community. For some people, it's obvious that you must try to preserve the way hyphenation occurs in the text; for others, it's equally obviously either of no importance or entirely counter productive to do so. Very good and persuasive reasons can be amassed on either side, and have been. But this shouldn't depress us! We should simply recognise it is another instance of the generally liberal attitude the Guidelines try to defend. Peoples' needs and priorities vary. I think we can still provide helpful guidance by saying: 1. You should probably not falsify the text, so do distinguish in some way "helpful" which has been split across a line break from "helpful" which has not been so divided 2. It's up to you whether you want to indicate the presence of the "metacharacter" hyphen (or whatever) and there are two ways you could do that: (a) symbolically (@rend="hyphen") (b) explicitly (in which case you need to find the right Unicode character) This is almost exactly what we already recommend for quotation marks: we provide explicit tags to distinguish "quoted" from quoted (several of them, in fact); you can retain the quote marks themselves if you like; you can replace them with a description supplied as the value for @rend. Each of us will have their own preferences, and these may well be different for different types of text or different types of application. I don't think that's a disaster, is it? From sebastian.rahtz at oucs.ox.ac.uk Wed Jan 5 16:22:00 2011 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Wed, 5 Jan 2011 21:22:00 +0000 Subject: [tei-council] how to encode a hyphen at the end of a line, column, or page when you are encoding hyphens In-Reply-To: <4D24BC66.3060707@uvic.ca> References: <4D0E7288.6010006@ultraslavonic.info> <4D0F93EF.3060100@oucs.ox.ac.uk> <4D194285.8010804@ultraslavonic.info> <4D23D7F5.5040009@ultraslavonic.info> <10C726D9-029A-43CF-86D5-DD69BD0778DC@oucs.ox.ac.uk> <4D24A47F.3080107@uvic.ca> <525D997E-9851-4819-AD0C-F59C44A249A4@oucs.ox.ac.uk> <4D24BC66.3060707@uvic.ca> Message-ID: On 5 Jan 2011, at 18:45, Martin Holmes wrote: > >> What about an element? what about ? > > This really does make some sense to me. Combined with a linebreak and > some carefully-crafted values for @type, it would provide support for > all our usage scenarios. Given, e.g., this: > > tittletattle yes, I agree, this looks nice. should be of course.... .... > I didn't quite understand Sebastian's distinction between the > typesetter's hyphenation and the author's -- do you mean that you want > the recommendations to include a method of specifying responsibility for > the hyphenation/breaking, or is there some more obvious dichotomy I'm > missing? I think I was being dumb, actually. all I meant is to preserve is the fact that you write "dumb-waiter" and I write "dumbwaiter"; when that appears in print as dumb- waiter I somehow care that my typesetter added the "-" and yours didn't. all just different values for @type, I guess. -- Sebastian Rahtz Information and Support Group Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From mholmes at uvic.ca Wed Jan 5 18:10:06 2011 From: mholmes at uvic.ca (Martin Holmes) Date: Wed, 5 Jan 2011 15:10:06 -0800 Subject: [tei-council] how to encode a hyphen at the end of a line, column, or page when you are encoding hyphens In-Reply-To: <4D24DD6A.8020803@retired.ox.ac.uk> References: <4D0E7288.6010006@ultraslavonic.info> <4D0F93EF.3060100@oucs.ox.ac.uk> <4D194285.8010804@ultraslavonic.info> <4D23D7F5.5040009@ultraslavonic.info> <10C726D9-029A-43CF-86D5-DD69BD0778DC@oucs.ox.ac.uk> <4D24A47F.3080107@uvic.ca> <4D24DD6A.8020803@retired.ox.ac.uk> Message-ID: <4D24FA4E.3020001@uvic.ca> Hi Lou, On 11-01-05 01:06 PM, Lou Burnard wrote: > Each of us will have their own preferences, and these may well be > different for different types of text or different types of application. > I don't think that's a disaster, is it? Absolutely not. But I think we do have to provide a detailed set of suggestions for (what we consider to be) the most all-round useful and effective way of encoding linebreaks and hyphenation, when those things matter to you. There will be people making decisions about how to encode this kind of thing in TEI who don't really know enough about the implications of their decisions down the road (how easy it will be to tokenize text effectively, for instance). We owe it to those people to find (if we can) a set of practices that we consider to be optimal. Cheers, Martin On 11-01-05 01:06 PM, Lou Burnard wrote: > On 05/01/11 17:03, Martin Holmes wrote: > >> >> Do we believe that the existence of a hyphen, doubling, etc. should be >> expressed through character data external to the break, or should it be >> expressed through @rend? In other words: >> >> help-ful >> >> or >> >> helpful >> > > I fear I don't think this is a question for voting on. It is clear, if > you look back through the discussion, that there is simply no consensus > in the community. For some people, it's obvious that you must try to > preserve the way hyphenation occurs in the text; for others, it's > equally obviously either of no importance or entirely counter productive > to do so. Very good and persuasive reasons can be amassed on either > side, and have been. > > But this shouldn't depress us! We should simply recognise it is another > instance of the generally liberal attitude the Guidelines try to defend. > Peoples' needs and priorities vary. I think we can still provide helpful > guidance by saying: > > 1. You should probably not falsify the text, so do distinguish in some > way "helpful" which has been split across a line break from "helpful" > which has not been so divided > > 2. It's up to you whether you want to indicate the presence of the > "metacharacter" hyphen (or whatever) and there are two ways you could do > that: > > (a) symbolically (@rend="hyphen") > > (b) explicitly (in which case you need to find the right Unicode character) > > This is almost exactly what we already recommend for quotation marks: > we provide explicit tags to distinguish "quoted" from quoted (several of > them, in fact); you can retain the quote marks themselves if you like; > you can replace them with a description supplied as the value for @rend. > > Each of us will have their own preferences, and these may well be > different for different types of text or different types of application. > I don't think that's a disaster, is it? > > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > -- Martin Holmes University of Victoria Humanities Computing and Media Centre (mholmes at uvic.ca) From sebastian.rahtz at oucs.ox.ac.uk Wed Jan 5 18:19:55 2011 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Wed, 5 Jan 2011 23:19:55 +0000 Subject: [tei-council] how to encode a hyphen at the end of a line, column, or page when you are encoding hyphens In-Reply-To: <4D24DD6A.8020803@retired.ox.ac.uk> References: <4D0E7288.6010006@ultraslavonic.info> <4D0F93EF.3060100@oucs.ox.ac.uk> <4D194285.8010804@ultraslavonic.info> <4D23D7F5.5040009@ultraslavonic.info> <10C726D9-029A-43CF-86D5-DD69BD0778DC@oucs.ox.ac.uk> <4D24A47F.3080107@uvic.ca> <4D24DD6A.8020803@retired.ox.ac.uk> Message-ID: > > 1. You should probably not falsify the text, so do distinguish in some > way "helpful" which has been split across a line break from "helpful" > which has not been so divided even this is surely controversial? if I am doing a digital version of a typeset novel, is it "falsifying" to not bother recording the line break and hyphenation decisions of some hack typesetter? but I do agree, there is no one right set of decisions for all texts. -- Sebastian Rahtz Information and Support Group Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From James.Cummings at oucs.ox.ac.uk Fri Jan 7 04:57:13 2011 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Fri, 07 Jan 2011 09:57:13 +0000 Subject: [tei-council] FR nuncles: new element tei:objectType In-Reply-To: <4D2491C8.4070004@oucs.ox.ac.uk> References: <4D1DDB09.40904@kcl.ac.uk> <4D2352EF.2020205@retired.ox.ac.uk> <4D2355DE.7080905@retired.ox.ac.uk> <9F02758B-A992-4ADB-89BC-F19923C0F6C1@oucs.ox.ac.uk> <4D2359A5.6000606@retired.ox.ac.uk> <4D24535B.6090707@kcl.ac.uk> <43A1FAAC-D72B-41DA-ADCD-4C988F36E2B1@oucs.ox.ac.uk> <4D245C47.4060808@oucs.ox.ac.uk> <4D245F72.6020604@kcl.ac.uk> <557B16EE-E217-4860-8107-41F258BACA3B@inria.fr> <6168DFA5-E2FE-4CA4-AB09-8A2861EB1453@inria.fr> <4D247F96.3030508@kcl.ac.uk> <4D2491C8.4070004@oucs.ox.ac.uk> Message-ID: <4D26E379.6090209@oucs.ox.ac.uk> Results so far: Name, tei:object, tei:objectType, neither JC, No, Yes, Maybe LR, Yes, No, No SR, Yes, No, No GB, No, Yes, No BB, No, Yes, No EP, No, Yes, No MH, No, Yes, No This looks to me that tei:objectType is the preferred. -James On 05/01/11 15:44, James Cummings wrote: > On 05/01/11 14:41, Laurent Romary wrote: >> tei:object: LR, SR >> tei:objectType: MH, GB > > I've re-read the ticket& comments, and all the emails about it. > I would like to express more than the above list of > for-one-or-other gives me the ability to. So I've put up a > little doodle.com poll that you can all fill in: > > http://doodle.com/nu49sr76mg9kirdg > > This allows you to say: > - In favour > - Could live with this option > - Against > for each proposed option. > > In this case I've put in tei:object, tei:objectType and 'neither' > (for those who think both are wrong). > > My vote is: > tei:object: Against (because I think that is a really bad name) > tei:objectType: In Favour > neither: Could live with this option. > > Doodle.com also happens to use a very similar traffic-light > system of green/yellow/red as we do in classifying our tickets. > Might I propose that anytime we want to have a quick show of > hands we use some system like this rather than having to collate > various emails? (We should of course copy the final result back > to the mailing list so it is preserved in the archive.) > > My vote and my two pence, > -James > -- Dr James Cummings, Research Technologies Service OUCS, University of Oxford From laurent.romary at inria.fr Fri Jan 7 05:06:54 2011 From: laurent.romary at inria.fr (Laurent Romary) Date: Fri, 7 Jan 2011 11:06:54 +0100 Subject: [tei-council] FR nuncles: new element tei:objectType In-Reply-To: <4D26E379.6090209@oucs.ox.ac.uk> References: <4D1DDB09.40904@kcl.ac.uk> <4D2352EF.2020205@retired.ox.ac.uk> <4D2355DE.7080905@retired.ox.ac.uk> <9F02758B-A992-4ADB-89BC-F19923C0F6C1@oucs.ox.ac.uk> <4D2359A5.6000606@retired.ox.ac.uk> <4D24535B.6090707@kcl.ac.uk> <43A1FAAC-D72B-41DA-ADCD-4C988F36E2B1@oucs.ox.ac.uk> <4D245C47.4060808@oucs.ox.ac.uk> <4D245F72.6020604@kcl.ac.uk> <557B16EE-E217-4860-8107-41F258BACA3B@inria.fr> <6168DFA5-E2FE-4CA4-AB09-8A2861EB1453@inria.fr> <4D247F96.3030508@kcl.ac.uk> <4D2491C8.4070004@oucs.ox.ac.uk> <4D26E379.6090209@oucs.ox.ac.uk> Message-ID: That's for sure. Let's validate this one (the ticket provides more in- depth content). Laurent (no more coughing, and gently recovering). Le 7 janv. 11 ? 10:57, James Cummings a ?crit : > Results so far: > > Name, tei:object, tei:objectType, neither > JC, No, Yes, Maybe > LR, Yes, No, No > SR, Yes, No, No > GB, No, Yes, No > BB, No, Yes, No > EP, No, Yes, No > MH, No, Yes, No > > > This looks to me that tei:objectType is the preferred. > > -James > > > On 05/01/11 15:44, James Cummings wrote: >> On 05/01/11 14:41, Laurent Romary wrote: >>> tei:object: LR, SR >>> tei:objectType: MH, GB >> >> I've re-read the ticket& comments, and all the emails about it. >> I would like to express more than the above list of >> for-one-or-other gives me the ability to. So I've put up a >> little doodle.com poll that you can all fill in: >> >> http://doodle.com/nu49sr76mg9kirdg >> >> This allows you to say: >> - In favour >> - Could live with this option >> - Against >> for each proposed option. >> >> In this case I've put in tei:object, tei:objectType and 'neither' >> (for those who think both are wrong). >> >> My vote is: >> tei:object: Against (because I think that is a really bad name) >> tei:objectType: In Favour >> neither: Could live with this option. >> >> Doodle.com also happens to use a very similar traffic-light >> system of green/yellow/red as we do in classifying our tickets. >> Might I propose that anytime we want to have a quick show of >> hands we use some system like this rather than having to collate >> various emails? (We should of course copy the final result back >> to the mailing list so it is preserved in the archive.) >> >> My vote and my two pence, >> -James >> > > > -- > Dr James Cummings, Research Technologies Service > OUCS, University of Oxford > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Laurent Romary INRIA & HUB-IDSL laurent.romary at inria.fr From James.Cummings at oucs.ox.ac.uk Fri Jan 7 05:51:57 2011 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Fri, 07 Jan 2011 10:51:57 +0000 Subject: [tei-council] how to encode a hyphen at the end of a line, column, or page when you are encoding hyphens In-Reply-To: References: <4D0E7288.6010006@ultraslavonic.info> <4D0F93EF.3060100@oucs.ox.ac.uk> <4D194285.8010804@ultraslavonic.info> <4D23D7F5.5040009@ultraslavonic.info> <10C726D9-029A-43CF-86D5-DD69BD0778DC@oucs.ox.ac.uk> <4D24A47F.3080107@uvic.ca> <4D24DD6A.8020803@retired.ox.ac.uk> Message-ID: <4D26F04D.2040005@oucs.ox.ac.uk> On 05/01/11 23:19, Sebastian Rahtz wrote: >> >> 1. You should probably not falsify the text, so do distinguish in some >> way "helpful" which has been split across a line break from "helpful" >> which has not been so divided > > even this is surely controversial? if I am doing a digital version of a > typeset novel, is it "falsifying" to not bother recording the line break > and hyphenation decisions of some hack typesetter? I'd have to agree with Sebastian here, and additionally would argue that it isn't the TEI's place to tell encoders whether they should be falsifying texts or not. I might *want* to falsify the text. My whole desire in text encoding might be to lead future generations astray by corrupting the source text into my particular reading. (Or indeed, I might be considering my silent editing of the text an editor's prerogative or a form of performance art.) We don't tell editors that they shouldn't falsify the text when transcribing, or translators when they are translating. I don't think we should be telling people what to record, simply providing them some options of "if you want to record X, this is a good way to do it, if instead you want to record Y, here is another way." So in this case explaining that some people use one method, others use another. I think this is the general TEI form of ontological agnosticism, we tell you that if you want to mark up a paragraph use

or for titles but we don't (and I'd argue shouldn't) tell people what paragraphs or titles are. That is their decision. (The TEI is also epistemologically agnostic in that we don't tell you that these things actually exist, only that some people see to think they do.) -James -- Dr James Cummings, Research Technologies Service OUCS, University of Oxford From gabriel.bodard at kcl.ac.uk Fri Jan 7 06:30:18 2011 From: gabriel.bodard at kcl.ac.uk (Gabriel Bodard) Date: Fri, 7 Jan 2011 11:30:18 +0000 Subject: [tei-council] FR nuncles: new element tei:objectType In-Reply-To: <D74BB5CE-A247-41EF-88CF-B92BF984ED37@inria.fr> References: <4D1DDB09.40904@kcl.ac.uk> <DCF242AC-E557-45D7-99CA-EE9D678507E2@oucs.ox.ac.uk> <4D2352EF.2020205@retired.ox.ac.uk> <F65328A6-0D5E-4BFC-A50B-B5F327AF1EBD@oucs.ox.ac.uk> <4D2355DE.7080905@retired.ox.ac.uk> <9F02758B-A992-4ADB-89BC-F19923C0F6C1@oucs.ox.ac.uk> <4D2359A5.6000606@retired.ox.ac.uk> <E005D498-F9A5-4C26-A6FA-923267003AB9@oucs.ox.ac.uk> <4D24535B.6090707@kcl.ac.uk> <43A1FAAC-D72B-41DA-ADCD-4C988F36E2B1@oucs.ox.ac.uk> <4D245C47.4060808@oucs.ox.ac.uk> <F2E5398C-FE05-47B0-9564-C956008C929C@inria.fr> <4D245F72.6020604@kcl.ac.uk> <557B16EE-E217-4860-8107-41F258BACA3B@inria.fr> <6168DFA5-E2FE-4CA4-AB09-8A2861EB1453@inria.fr> <4D247F96.3030508@kcl.ac.uk> <F05F14CA-6813-4531-8885-270DC9DA0317@inria.fr> <4D2491C8.4070004@oucs.ox.ac.uk> <4D26E379.6090209@oucs.ox.ac.uk> <D74BB5CE-A247-41EF-88CF-B92BF984ED37@inria.fr> Message-ID: <4D26F94A.8020408@kcl.ac.uk> I was going to ask, what's the process now for creating this element and its description? I'd be happy to help compose text for the description and examples, if put in touch with whoever is creating the XML. (Or if someone would like me to learn how to edit the relevant bits of XML?) G On 07/01/2011 10:06, Laurent Romary wrote: > That's for sure. Let's validate this one (the ticket provides more in- > depth content). > Laurent (no more coughing, and gently recovering). > > > Le 7 janv. 11 ? 10:57, James Cummings a ?crit : > >> Results so far: >> >> Name, tei:object, tei:objectType, neither >> JC, No, Yes, Maybe >> LR, Yes, No, No >> SR, Yes, No, No >> GB, No, Yes, No >> BB, No, Yes, No >> EP, No, Yes, No >> MH, No, Yes, No >> >> >> This looks to me that tei:objectType is the preferred. >> >> -James >> >> >> On 05/01/11 15:44, James Cummings wrote: >>> On 05/01/11 14:41, Laurent Romary wrote: >>>> tei:object: LR, SR >>>> tei:objectType: MH, GB >>> >>> I've re-read the ticket& comments, and all the emails about it. >>> I would like to express more than the above list of >>> for-one-or-other gives me the ability to. So I've put up a >>> little doodle.com poll that you can all fill in: >>> >>> http://doodle.com/nu49sr76mg9kirdg >>> >>> This allows you to say: >>> - In favour >>> - Could live with this option >>> - Against >>> for each proposed option. >>> >>> In this case I've put in tei:object, tei:objectType and 'neither' >>> (for those who think both are wrong). >>> >>> My vote is: >>> tei:object: Against (because I think that is a really bad name) >>> tei:objectType: In Favour >>> neither: Could live with this option. >>> >>> Doodle.com also happens to use a very similar traffic-light >>> system of green/yellow/red as we do in classifying our tickets. >>> Might I propose that anytime we want to have a quick show of >>> hands we use some system like this rather than having to collate >>> various emails? (We should of course copy the final result back >>> to the mailing list so it is preserved in the archive.) >>> >>> My vote and my two pence, >>> -James >>> >> >> >> -- >> Dr James Cummings, Research Technologies Service >> OUCS, University of Oxford >> _______________________________________________ >> tei-council mailing list >> tei-council at lists.village.Virginia.EDU >> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > > Laurent Romary > INRIA& HUB-IDSL > laurent.romary at inria.fr > > > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council -- Dr Gabriel BODARD (Research Associate in Digital Epigraphy) Centre for Computing in the Humanities King's College London 26-29 Drury Lane London WC2B 5RL Email: gabriel.bodard at kcl.ac.uk Tel: +44 (0)20 7848 1388 Fax: +44 (0)20 7848 2980 http://www.digitalclassicist.org/ http://www.currentepigraphy.org/ From laurent.romary at inria.fr Fri Jan 7 06:44:09 2011 From: laurent.romary at inria.fr (Laurent Romary) Date: Fri, 7 Jan 2011 12:44:09 +0100 Subject: [tei-council] FR nuncles: new element tei:objectType In-Reply-To: <4D26F94A.8020408@kcl.ac.uk> References: <4D1DDB09.40904@kcl.ac.uk> <DCF242AC-E557-45D7-99CA-EE9D678507E2@oucs.ox.ac.uk> <4D2352EF.2020205@retired.ox.ac.uk> <F65328A6-0D5E-4BFC-A50B-B5F327AF1EBD@oucs.ox.ac.uk> <4D2355DE.7080905@retired.ox.ac.uk> <9F02758B-A992-4ADB-89BC-F19923C0F6C1@oucs.ox.ac.uk> <4D2359A5.6000606@retired.ox.ac.uk> <E005D498-F9A5-4C26-A6FA-923267003AB9@oucs.ox.ac.uk> <4D24535B.6090707@kcl.ac.uk> <43A1FAAC-D72B-41DA-ADCD-4C988F36E2B1@oucs.ox.ac.uk> <4D245C47.4060808@oucs.ox.ac.uk> <F2E5398C-FE05-47B0-9564-C956008C929C@inria.fr> <4D245F72.6020604@kcl.ac.uk> <557B16EE-E217-4860-8107-41F258BACA3B@inria.fr> <6168DFA5-E2FE-4CA4-AB09-8A2861EB1453@inria.fr> <4D247F96.3030508@kcl.ac.uk> <F05F14CA-6813-4531-8885-270DC9DA0317@inria.fr> <4D2491C8.4070004@oucs.ox.ac.uk> <4D26E379.6090209@oucs.ox.ac.uk> <D74BB5CE-A247-41EF-88CF-B92BF984ED37@inria.fr> <4D26F94A.8020408@kcl.ac.uk> Message-ID: <D0D692E9-E086-46D0-8C77-2210E3B0AE60@inria.fr> A good opportunity to implement one of the requirements of the new scheme presented by Lou: that the technical awareness is spread to more council members. @Lou: would you want ot make a try and elicit the steps Gabriel should go through? Le 7 janv. 11 ? 12:30, Gabriel Bodard a ?crit : > I was going to ask, what's the process now for creating this element > and > its description? I'd be happy to help compose text for the description > and examples, if put in touch with whoever is creating the XML. > > (Or if someone would like me to learn how to edit the relevant bits > of XML?) > > G > > On 07/01/2011 10:06, Laurent Romary wrote: >> That's for sure. Let's validate this one (the ticket provides more >> in- >> depth content). >> Laurent (no more coughing, and gently recovering). >> >> >> Le 7 janv. 11 ? 10:57, James Cummings a ?crit : >> >>> Results so far: >>> >>> Name, tei:object, tei:objectType, neither >>> JC, No, Yes, Maybe >>> LR, Yes, No, No >>> SR, Yes, No, No >>> GB, No, Yes, No >>> BB, No, Yes, No >>> EP, No, Yes, No >>> MH, No, Yes, No >>> >>> >>> This looks to me that tei:objectType is the preferred. >>> >>> -James >>> >>> >>> On 05/01/11 15:44, James Cummings wrote: >>>> On 05/01/11 14:41, Laurent Romary wrote: >>>>> tei:object: LR, SR >>>>> tei:objectType: MH, GB >>>> >>>> I've re-read the ticket& comments, and all the emails about it. >>>> I would like to express more than the above list of >>>> for-one-or-other gives me the ability to. So I've put up a >>>> little doodle.com poll that you can all fill in: >>>> >>>> http://doodle.com/nu49sr76mg9kirdg >>>> >>>> This allows you to say: >>>> - In favour >>>> - Could live with this option >>>> - Against >>>> for each proposed option. >>>> >>>> In this case I've put in tei:object, tei:objectType and 'neither' >>>> (for those who think both are wrong). >>>> >>>> My vote is: >>>> tei:object: Against (because I think that is a really bad name) >>>> tei:objectType: In Favour >>>> neither: Could live with this option. >>>> >>>> Doodle.com also happens to use a very similar traffic-light >>>> system of green/yellow/red as we do in classifying our tickets. >>>> Might I propose that anytime we want to have a quick show of >>>> hands we use some system like this rather than having to collate >>>> various emails? (We should of course copy the final result back >>>> to the mailing list so it is preserved in the archive.) >>>> >>>> My vote and my two pence, >>>> -James >>>> >>> >>> >>> -- >>> Dr James Cummings, Research Technologies Service >>> OUCS, University of Oxford >>> _______________________________________________ >>> tei-council mailing list >>> tei-council at lists.village.Virginia.EDU >>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council >> >> Laurent Romary >> INRIA& HUB-IDSL >> laurent.romary at inria.fr >> >> >> >> _______________________________________________ >> tei-council mailing list >> tei-council at lists.village.Virginia.EDU >> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > > -- > Dr Gabriel BODARD > (Research Associate in Digital Epigraphy) > > Centre for Computing in the Humanities > King's College London > 26-29 Drury Lane > London WC2B 5RL > Email: gabriel.bodard at kcl.ac.uk > Tel: +44 (0)20 7848 1388 > Fax: +44 (0)20 7848 2980 > > http://www.digitalclassicist.org/ > http://www.currentepigraphy.org/ > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Laurent Romary INRIA & HUB-IDSL laurent.romary at inria.fr From lou.burnard at retired.ox.ac.uk Fri Jan 7 07:00:06 2011 From: lou.burnard at retired.ox.ac.uk (Lou Burnard) Date: Fri, 07 Jan 2011 12:00:06 +0000 Subject: [tei-council] how to encode a hyphen at the end of a line, column, or page when you are encoding hyphens In-Reply-To: <4D26F04D.2040005@oucs.ox.ac.uk> References: <4D0E7288.6010006@ultraslavonic.info> <4D0F93EF.3060100@oucs.ox.ac.uk> <4D194285.8010804@ultraslavonic.info> <4D23D7F5.5040009@ultraslavonic.info> <10C726D9-029A-43CF-86D5-DD69BD0778DC@oucs.ox.ac.uk> <4D24A47F.3080107@uvic.ca> <4D24DD6A.8020803@retired.ox.ac.uk> <A37CC5A3-E2A4-4F52-8655-3F45EBC4BF12@oucs.ox.ac.uk> <4D26F04D.2040005@oucs.ox.ac.uk> Message-ID: <4D270046.3050107@retired.ox.ac.uk> On 07/01/11 10:51, James Cummings wrote: > > > I think this is the general TEI form of ontological agnosticism, > we tell you that if you want to mark up a paragraph use<p> or > <title> for titles but we don't (and I'd argue shouldn't) tell > people what paragraphs or titles are. On the contrary, we do very precisely tell people what "paragraphs" and "titles" are. We leave it to them as to whether or not they choose to observe the distinction, but it is nonsense to say that all the categories defined by the TEI are entirely vacuous. From sebastian.rahtz at oucs.ox.ac.uk Fri Jan 7 07:02:58 2011 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Fri, 7 Jan 2011 12:02:58 +0000 Subject: [tei-council] FR nuncles: new element tei:objectType In-Reply-To: <D0D692E9-E086-46D0-8C77-2210E3B0AE60@inria.fr> References: <4D1DDB09.40904@kcl.ac.uk> <DCF242AC-E557-45D7-99CA-EE9D678507E2@oucs.ox.ac.uk> <4D2352EF.2020205@retired.ox.ac.uk> <F65328A6-0D5E-4BFC-A50B-B5F327AF1EBD@oucs.ox.ac.uk> <4D2355DE.7080905@retired.ox.ac.uk> <9F02758B-A992-4ADB-89BC-F19923C0F6C1@oucs.ox.ac.uk> <4D2359A5.6000606@retired.ox.ac.uk> <E005D498-F9A5-4C26-A6FA-923267003AB9@oucs.ox.ac.uk> <4D24535B.6090707@kcl.ac.uk> <43A1FAAC-D72B-41DA-ADCD-4C988F36E2B1@oucs.ox.ac.uk> <4D245C47.4060808@oucs.ox.ac.uk> <F2E5398C-FE05-47B0-9564-C956008C929C@inria.fr> <4D245F72.6020604@kcl.ac.uk> <557B16EE-E217-4860-8107-41F258BACA3B@inria.fr> <6168DFA5-E2FE-4CA4-AB09-8A2861EB1453@inria.fr> <4D247F96.3030508@kcl.ac.uk> <F05F14CA-6813-4531-8885-270DC9DA0317@inria.fr> <4D2491C8.4070004@oucs.ox.ac.uk> <4D26E379.6090209@oucs.ox.ac.uk> <D74BB5CE-A247-41EF-88CF-B92BF984ED37@inria.fr> <4D26F94A.8020408@kcl.ac.uk> <D0D692E9-E086-46D0-8C77-2210E3B0AE60@inria.fr> Message-ID: <2DBFCD32-D607-4229-A78C-41C63F6E4374@oucs.ox.ac.uk> On 7 Jan 2011, at 11:44, Laurent Romary wrote: > A good opportunity to implement one of the requirements of the new > scheme presented by Lou: it would be nice to have some more discussion and decisions arising from that? I don't recall any conclusions at all. since the new <objectType> is effectively a clone of <material>, if I was doing it I would rename a copy material.xml to objectType.xml and start editing it :-} if you have not already checked out the Sourceforge repository, Gabriel, now is the time. If you can check it out and rebuild the Guidelines from source, you're a huge way forward. -- Sebastian Rahtz Information and Support Group Manager Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From lou.burnard at retired.ox.ac.uk Fri Jan 7 07:07:37 2011 From: lou.burnard at retired.ox.ac.uk (Lou Burnard) Date: Fri, 07 Jan 2011 12:07:37 +0000 Subject: [tei-council] FR nuncles: new element tei:objectType In-Reply-To: <4D26F94A.8020408@kcl.ac.uk> References: <4D1DDB09.40904@kcl.ac.uk> <DCF242AC-E557-45D7-99CA-EE9D678507E2@oucs.ox.ac.uk> <4D2352EF.2020205@retired.ox.ac.uk> <F65328A6-0D5E-4BFC-A50B-B5F327AF1EBD@oucs.ox.ac.uk> <4D2355DE.7080905@retired.ox.ac.uk> <9F02758B-A992-4ADB-89BC-F19923C0F6C1@oucs.ox.ac.uk> <4D2359A5.6000606@retired.ox.ac.uk> <E005D498-F9A5-4C26-A6FA-923267003AB9@oucs.ox.ac.uk> <4D24535B.6090707@kcl.ac.uk> <43A1FAAC-D72B-41DA-ADCD-4C988F36E2B1@oucs.ox.ac.uk> <4D245C47.4060808@oucs.ox.ac.uk> <F2E5398C-FE05-47B0-9564-C956008C929C@inria.fr> <4D245F72.6020604@kcl.ac.uk> <557B16EE-E217-4860-8107-41F258BACA3B@inria.fr> <6168DFA5-E2FE-4CA4-AB09-8A2861EB1453@inria.fr> <4D247F96.3030508@kcl.ac.uk> <F05F14CA-6813-4531-8885-270DC9DA0317@inria.fr> <4D2491C8.4070004@oucs.ox.ac.uk> <4D26E379.6090209@oucs.ox.ac.uk> <D74BB5CE-A247-41EF-88CF-B92BF984ED37@inria.fr> <4D26F94A.8020408@kcl.ac.uk> Message-ID: <4D270209.7050600@retired.ox.ac.uk> The first thing we need is a <elementSpec> for the new element. Take one of the existing ones (Specs/material.xml in this case probably) and hack it, is what I usually do. That will also involve creating some usage examples, thinking about its class memberships, attributes etc. Then I would create a skeleton ODD file in which my new element spec is added to the existing structure and see whether the schemas generated make sense. In my skeleton ODD file I'd start adding some prose to further explain how the new element is meant to be used, and expatiating on the examples a bit. The genetic.xml document is an example of this process in action, though on a rather broader scale than is needed here. On 07/01/11 11:30, Gabriel Bodard wrote: > I was going to ask, what's the process now for creating this element and > its description? I'd be happy to help compose text for the description > and examples, if put in touch with whoever is creating the XML. > > (Or if someone would like me to learn how to edit the relevant bits of XML?) > > G > > On 07/01/2011 10:06, Laurent Romary wrote: >> That's for sure. Let's validate this one (the ticket provides more in- >> depth content). >> Laurent (no more coughing, and gently recovering). >> >> >> Le 7 janv. 11 ? 10:57, James Cummings a ?crit : >> >>> Results so far: >>> >>> Name, tei:object, tei:objectType, neither >>> JC, No, Yes, Maybe >>> LR, Yes, No, No >>> SR, Yes, No, No >>> GB, No, Yes, No >>> BB, No, Yes, No >>> EP, No, Yes, No >>> MH, No, Yes, No >>> >>> >>> This looks to me that tei:objectType is the preferred. >>> >>> -James >>> >>> >>> On 05/01/11 15:44, James Cummings wrote: >>>> On 05/01/11 14:41, Laurent Romary wrote: >>>>> tei:object: LR, SR >>>>> tei:objectType: MH, GB >>>> >>>> I've re-read the ticket& comments, and all the emails about it. >>>> I would like to express more than the above list of >>>> for-one-or-other gives me the ability to. So I've put up a >>>> little doodle.com poll that you can all fill in: >>>> >>>> http://doodle.com/nu49sr76mg9kirdg >>>> >>>> This allows you to say: >>>> - In favour >>>> - Could live with this option >>>> - Against >>>> for each proposed option. >>>> >>>> In this case I've put in tei:object, tei:objectType and 'neither' >>>> (for those who think both are wrong). >>>> >>>> My vote is: >>>> tei:object: Against (because I think that is a really bad name) >>>> tei:objectType: In Favour >>>> neither: Could live with this option. >>>> >>>> Doodle.com also happens to use a very similar traffic-light >>>> system of green/yellow/red as we do in classifying our tickets. >>>> Might I propose that anytime we want to have a quick show of >>>> hands we use some system like this rather than having to collate >>>> various emails? (We should of course copy the final result back >>>> to the mailing list so it is preserved in the archive.) >>>> >>>> My vote and my two pence, >>>> -James >>>> >>> >>> >>> -- >>> Dr James Cummings, Research Technologies Service >>> OUCS, University of Oxford >>> _______________________________________________ >>> tei-council mailing list >>> tei-council at lists.village.Virginia.EDU >>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council >> >> Laurent Romary >> INRIA& HUB-IDSL >> laurent.romary at inria.fr >> >> >> >> _______________________________________________ >> tei-council mailing list >> tei-council at lists.village.Virginia.EDU >> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > From laurent.romary at inria.fr Fri Jan 7 07:08:36 2011 From: laurent.romary at inria.fr (Laurent Romary) Date: Fri, 7 Jan 2011 13:08:36 +0100 Subject: [tei-council] FR nuncles: new element tei:objectType In-Reply-To: <2DBFCD32-D607-4229-A78C-41C63F6E4374@oucs.ox.ac.uk> References: <4D1DDB09.40904@kcl.ac.uk> <DCF242AC-E557-45D7-99CA-EE9D678507E2@oucs.ox.ac.uk> <4D2352EF.2020205@retired.ox.ac.uk> <F65328A6-0D5E-4BFC-A50B-B5F327AF1EBD@oucs.ox.ac.uk> <4D2355DE.7080905@retired.ox.ac.uk> <9F02758B-A992-4ADB-89BC-F19923C0F6C1@oucs.ox.ac.uk> <4D2359A5.6000606@retired.ox.ac.uk> <E005D498-F9A5-4C26-A6FA-923267003AB9@oucs.ox.ac.uk> <4D24535B.6090707@kcl.ac.uk> <43A1FAAC-D72B-41DA-ADCD-4C988F36E2B1@oucs.ox.ac.uk> <4D245C47.4060808@oucs.ox.ac.uk> <F2E5398C-FE05-47B0-9564-C956008C929C@inria.fr> <4D245F72.6020604@kcl.ac.uk> <557B16EE-E217-4860-8107-41F258BACA3B@inria.fr> <6168DFA5-E2FE-4CA4-AB09-8A2861EB1453@inria.fr> <4D247F96.3030508@kcl.ac.uk> <F05F14CA-6813-4531-8885-270DC9DA0317@inria.fr> <4D2491C8.4070004@oucs.ox.ac.uk> <4D26E379.6090209@oucs.ox.ac.uk> <D74BB5CE-A247-41EF-88CF-B92BF984ED37@inria.fr> <4D26F94A.8020408@kcl.ac.uk> <D0D692E9-E086-46D0-8C77-2210E3B0AE60@inria.fr> <2DBFCD32-D607-4229-A78C-41C63F6E4374@oucs.ox.ac.uk> Message-ID: <96A218CD-CE3A-4674-A44E-793212680C90@inria.fr> Do we have a wiki page on how to proceed? If not, Gabriel, could you record the steps you've been through (asking Seb+Lou when needed), so that next time will be even easier. Le 7 janv. 11 ? 13:02, Sebastian Rahtz a ?crit : > > On 7 Jan 2011, at 11:44, Laurent Romary wrote: > >> A good opportunity to implement one of the requirements of the new >> scheme presented by Lou: > > it would be nice to have some more discussion and decisions arising > from that? I don't recall any conclusions at all. > > since the new <objectType> is effectively a clone of <material>, > if I was doing it I would rename a copy material.xml to objectType.xml > and start editing it :-} > > if you have not already checked out the Sourceforge repository, > Gabriel, > now is the time. If you can check it out and rebuild the Guidelines > from source, you're a huge way forward. > > -- > Sebastian Rahtz > Information and Support Group Manager > Oxford University Computing Services > 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 > > S?lo le pido a Dios > que el futuro no me sea indiferente > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Laurent Romary INRIA & HUB-IDSL laurent.romary at inria.fr From gabriel.bodard at kcl.ac.uk Fri Jan 7 07:13:44 2011 From: gabriel.bodard at kcl.ac.uk (Gabriel Bodard) Date: Fri, 7 Jan 2011 12:13:44 +0000 Subject: [tei-council] FR nuncles: new element tei:objectType In-Reply-To: <2DBFCD32-D607-4229-A78C-41C63F6E4374@oucs.ox.ac.uk> References: <4D1DDB09.40904@kcl.ac.uk> <DCF242AC-E557-45D7-99CA-EE9D678507E2@oucs.ox.ac.uk> <4D2352EF.2020205@retired.ox.ac.uk> <F65328A6-0D5E-4BFC-A50B-B5F327AF1EBD@oucs.ox.ac.uk> <4D2355DE.7080905@retired.ox.ac.uk> <9F02758B-A992-4ADB-89BC-F19923C0F6C1@oucs.ox.ac.uk> <4D2359A5.6000606@retired.ox.ac.uk> <E005D498-F9A5-4C26-A6FA-923267003AB9@oucs.ox.ac.uk> <4D24535B.6090707@kcl.ac.uk> <43A1FAAC-D72B-41DA-ADCD-4C988F36E2B1@oucs.ox.ac.uk> <4D245C47.4060808@oucs.ox.ac.uk> <F2E5398C-FE05-47B0-9564-C956008C929C@inria.fr> <4D245F72.6020604@kcl.ac.uk> <557B16EE-E217-4860-8107-41F258BACA3B@inria.fr> <6168DFA5-E2FE-4CA4-AB09-8A2861EB1453@inria.fr> <4D247F96.3030508@kcl.ac.uk> <F05F14CA-6813-4531-8885-270DC9DA0317@inria.fr> <4D2491C8.4070004@oucs.ox.ac.uk> <4D26E379.6090209@oucs.ox.ac.uk> <D74BB5CE-A247-41EF-88CF-B92BF984ED37@inria.fr> <4D26F94A.8020408@kcl.ac.uk> <D0D692E9-E086-46D0-8C77-2210E3B0AE60@inria.fr> <2DBFCD32-D607-4229-A78C-41C63F6E4374@oucs.ox.ac.uk> Message-ID: <4D270378.6050301@kcl.ac.uk> Right. I had in the meantime checked out the P5 directory of SVN and figured out that the first thing I wanted to do was clone material.xml to objectType.xml. I'll start with that, then, and then maybe run it by Lou and/or Sebastian before doing anything else (and obviously before committing anything to trunk). Cheers, G On 07/01/2011 12:02, Sebastian Rahtz wrote: > > On 7 Jan 2011, at 11:44, Laurent Romary wrote: > >> A good opportunity to implement one of the requirements of the new >> scheme presented by Lou: > > it would be nice to have some more discussion and decisions arising > from that? I don't recall any conclusions at all. > > since the new<objectType> is effectively a clone of<material>, > if I was doing it I would rename a copy material.xml to objectType.xml > and start editing it :-} > > if you have not already checked out the Sourceforge repository, Gabriel, > now is the time. If you can check it out and rebuild the Guidelines > from source, you're a huge way forward. > > -- > Sebastian Rahtz > Information and Support Group Manager > Oxford University Computing Services > 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 > > S?lo le pido a Dios > que el futuro no me sea indiferente > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council -- Dr Gabriel BODARD (Research Associate in Digital Epigraphy) Centre for Computing in the Humanities King's College London 26-29 Drury Lane London WC2B 5RL Email: gabriel.bodard at kcl.ac.uk Tel: +44 (0)20 7848 1388 Fax: +44 (0)20 7848 2980 http://www.digitalclassicist.org/ http://www.currentepigraphy.org/ From sebastian.rahtz at oucs.ox.ac.uk Fri Jan 7 07:19:13 2011 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Fri, 7 Jan 2011 12:19:13 +0000 Subject: [tei-council] FR nuncles: new element tei:objectType In-Reply-To: <4D270378.6050301@kcl.ac.uk> References: <4D1DDB09.40904@kcl.ac.uk> <DCF242AC-E557-45D7-99CA-EE9D678507E2@oucs.ox.ac.uk> <4D2352EF.2020205@retired.ox.ac.uk> <F65328A6-0D5E-4BFC-A50B-B5F327AF1EBD@oucs.ox.ac.uk> <4D2355DE.7080905@retired.ox.ac.uk> <9F02758B-A992-4ADB-89BC-F19923C0F6C1@oucs.ox.ac.uk> <4D2359A5.6000606@retired.ox.ac.uk> <E005D498-F9A5-4C26-A6FA-923267003AB9@oucs.ox.ac.uk> <4D24535B.6090707@kcl.ac.uk> <43A1FAAC-D72B-41DA-ADCD-4C988F36E2B1@oucs.ox.ac.uk> <4D245C47.4060808@oucs.ox.ac.uk> <F2E5398C-FE05-47B0-9564-C956008C929C@inria.fr> <4D245F72.6020604@kcl.ac.uk> <557B16EE-E217-4860-8107-41F258BACA3B@inria.fr> <6168DFA5-E2FE-4CA4-AB09-8A2861EB1453@inria.fr> <4D247F96.3030508@kcl.ac.uk> <F05F14CA-6813-4531-8885-270DC9DA0317@inria.fr> <4D2491C8.4070004@oucs.ox.ac.uk> <4D26E379.6090209@oucs.ox.ac.uk> <D74BB5CE-A247-41EF-88CF-B92BF984ED37@inria.fr> <4D26F94A.8020408@kcl.ac.uk> <D0D692E9-E086-46D0-8C77-2210E3B0AE60@inria.fr> <2DBFCD32-D607-4229-A78C-41C63F6E4374@oucs.ox.ac.uk> <4D270378.6050301@kcl.ac.uk> Message-ID: <27166FD1-D436-459A-9775-CE614701F2AC@oucs.ox.ac.uk> On 7 Jan 2011, at 12:13, Gabriel Bodard wrote: > Right. I had in the meantime checked out the P5 directory of SVN and > figured out that the first thing I wanted to do was clone material.xml > to objectType.xml. I'll start with that, then, and then maybe run it by > Lou and/or Sebastian before doing anything else (and obviously before > committing anything to trunk). Lou's advice was good. viz write your objectType.xml and then embed it in a simple ODD file for testing that it does all you need. -- Sebastian Rahtz Information and Support Group Manager Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From sebastian.rahtz at oucs.ox.ac.uk Fri Jan 7 07:23:35 2011 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Fri, 7 Jan 2011 12:23:35 +0000 Subject: [tei-council] FR nuncles: new element tei:objectType In-Reply-To: <96A218CD-CE3A-4674-A44E-793212680C90@inria.fr> References: <4D1DDB09.40904@kcl.ac.uk> <DCF242AC-E557-45D7-99CA-EE9D678507E2@oucs.ox.ac.uk> <4D2352EF.2020205@retired.ox.ac.uk> <F65328A6-0D5E-4BFC-A50B-B5F327AF1EBD@oucs.ox.ac.uk> <4D2355DE.7080905@retired.ox.ac.uk> <9F02758B-A992-4ADB-89BC-F19923C0F6C1@oucs.ox.ac.uk> <4D2359A5.6000606@retired.ox.ac.uk> <E005D498-F9A5-4C26-A6FA-923267003AB9@oucs.ox.ac.uk> <4D24535B.6090707@kcl.ac.uk> <43A1FAAC-D72B-41DA-ADCD-4C988F36E2B1@oucs.ox.ac.uk> <4D245C47.4060808@oucs.ox.ac.uk> <F2E5398C-FE05-47B0-9564-C956008C929C@inria.fr> <4D245F72.6020604@kcl.ac.uk> <557B16EE-E217-4860-8107-41F258BACA3B@inria.fr> <6168DFA5-E2FE-4CA4-AB09-8A2861EB1453@inria.fr> <4D247F96.3030508@kcl.ac.uk> <F05F14CA-6813-4531-8885-270DC9DA0317@inria.fr> <4D2491C8.4070004@oucs.ox.ac.uk> <4D26E379.6090209@oucs.ox.ac.uk> <D74BB5CE-A247-41EF-88CF-B92BF984ED37@inria.fr> <4D26F94A.8020408@kcl.ac.uk> <D0D692E9-E086-46D0-8C77-2210E3B0AE60@inria.fr> <2DBFCD32-D607-4229-A78C-41C63F6E4374@oucs.ox.ac.uk> <96A218CD-CE3A-4674-A44E-793212680C90@inria.fr> Message-ID: <47DBAE31-571E-4354-98D8-348A611F4477@oucs.ox.ac.uk> On 7 Jan 2011, at 12:08, Laurent Romary wrote: > Do we have a wiki page on how to proceed? the doc at http://www.tei-c.org/Guidelines/P5/get.xml#P5 is relevant. unfortunately it is out of date -- Sebastian Rahtz Information and Support Group Manager Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From laurent.romary at inria.fr Fri Jan 7 07:30:16 2011 From: laurent.romary at inria.fr (Laurent Romary) Date: Fri, 7 Jan 2011 13:30:16 +0100 Subject: [tei-council] FR nuncles: new element tei:objectType In-Reply-To: <47DBAE31-571E-4354-98D8-348A611F4477@oucs.ox.ac.uk> References: <4D1DDB09.40904@kcl.ac.uk> <DCF242AC-E557-45D7-99CA-EE9D678507E2@oucs.ox.ac.uk> <4D2352EF.2020205@retired.ox.ac.uk> <F65328A6-0D5E-4BFC-A50B-B5F327AF1EBD@oucs.ox.ac.uk> <4D2355DE.7080905@retired.ox.ac.uk> <9F02758B-A992-4ADB-89BC-F19923C0F6C1@oucs.ox.ac.uk> <4D2359A5.6000606@retired.ox.ac.uk> <E005D498-F9A5-4C26-A6FA-923267003AB9@oucs.ox.ac.uk> <4D24535B.6090707@kcl.ac.uk> <43A1FAAC-D72B-41DA-ADCD-4C988F36E2B1@oucs.ox.ac.uk> <4D245C47.4060808@oucs.ox.ac.uk> <F2E5398C-FE05-47B0-9564-C956008C929C@inria.fr> <4D245F72.6020604@kcl.ac.uk> <557B16EE-E217-4860-8107-41F258BACA3B@inria.fr> <6168DFA5-E2FE-4CA4-AB09-8A2861EB1453@inria.fr> <4D247F96.3030508@kcl.ac.uk> <F05F14CA-6813-4531-8885-270DC9DA0317@inria.fr> <4D2491C8.4070004@oucs.ox.ac.uk> <4D26E379.6090209@oucs.ox.ac.uk> <D74BB5CE-A247-41EF-88CF-B92BF984ED37@inria.fr> <4D26F94A.8020408@kcl.ac.uk> <D0D692E9-E086-46D0-8C77-2210E3B0AE60@inria.fr> <2DBFCD32-D607-4229-A78C-41C63F6E4374@oucs.ox.ac.uk> <96A218CD-CE3A-4674-A44E-793212680C90@inria.fr> <47DBAE31-571E-4354-98D8-348A611F4477@oucs.ox.ac.uk> Message-ID: <512CC0FE-247E-4642-95FF-704950E915C6@inria.fr> Seb, would you want to bring this as a wiki page, ammend the obvious mistakes and let Gabriel put in the feedback from his experience? Thanks, Laurent Le 7 janv. 11 ? 13:23, Sebastian Rahtz a ?crit : > > On 7 Jan 2011, at 12:08, Laurent Romary wrote: > >> Do we have a wiki page on how to proceed? > > the doc at http://www.tei-c.org/Guidelines/P5/get.xml#P5 > is relevant. unfortunately it is out of date > -- > Sebastian Rahtz > Information and Support Group Manager > Oxford University Computing Services > 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 > > S?lo le pido a Dios > que el futuro no me sea indiferente > Laurent Romary INRIA & HUB-IDSL laurent.romary at inria.fr From sebastian.rahtz at oucs.ox.ac.uk Fri Jan 7 07:52:48 2011 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Fri, 7 Jan 2011 12:52:48 +0000 Subject: [tei-council] FR nuncles: new element tei:objectType In-Reply-To: <512CC0FE-247E-4642-95FF-704950E915C6@inria.fr> References: <4D1DDB09.40904@kcl.ac.uk> <DCF242AC-E557-45D7-99CA-EE9D678507E2@oucs.ox.ac.uk> <4D2352EF.2020205@retired.ox.ac.uk> <F65328A6-0D5E-4BFC-A50B-B5F327AF1EBD@oucs.ox.ac.uk> <4D2355DE.7080905@retired.ox.ac.uk> <9F02758B-A992-4ADB-89BC-F19923C0F6C1@oucs.ox.ac.uk> <4D2359A5.6000606@retired.ox.ac.uk> <E005D498-F9A5-4C26-A6FA-923267003AB9@oucs.ox.ac.uk> <4D24535B.6090707@kcl.ac.uk> <43A1FAAC-D72B-41DA-ADCD-4C988F36E2B1@oucs.ox.ac.uk> <4D245C47.4060808@oucs.ox.ac.uk> <F2E5398C-FE05-47B0-9564-C956008C929C@inria.fr> <4D245F72.6020604@kcl.ac.uk> <557B16EE-E217-4860-8107-41F258BACA3B@inria.fr> <6168DFA5-E2FE-4CA4-AB09-8A2861EB1453@inria.fr> <4D247F96.3030508@kcl.ac.uk> <F05F14CA-6813-4531-8885-270DC9DA0317@inria.fr> <4D2491C8.4070004@oucs.ox.ac.uk> <4D26E379.6090209@oucs.ox.ac.uk> <D74BB5CE-A247-41EF-88CF-B92BF984ED37@inria.fr> <4D26F94A.8020408@kcl.ac.uk> <D0D692E9-E086-46D0-8C77-2210E3B0AE60@inria.fr> <2DBFCD32-D607-4229-A78C-41C63F6E4374@oucs.ox.ac.uk> <96A218CD-CE3A-4674-A44E-793212680C90@inria.fr> <47DBAE31-571E-4354-98D8-348A611F4477@oucs.ox.ac.uk> <512CC0FE-247E-4642-95FF-704950E915C6@inria.fr> Message-ID: <E43CEE04-3C21-466F-8C04-9294E33EE678@oucs.ox.ac.uk> On 7 Jan 2011, at 12:30, Laurent Romary wrote: > Seb, would you want to bring this as a wiki page, ammend the obvious > mistakes and let Gabriel put in the feedback from his experience? well, the bald answer is no, I would not _want_ to :-} but seriously, I wonder if I am the best person to do such a thing - I am too close to the setup to be objective enough, and know what needs explaining. which brings me to a more strategic question. I am sure we all agree that building the Guidelines is something that more people should be able to do, and it should be simple and easier to use. so the question for those of you who feel able to comment on the engineering is what framework/setup/workflow/system is best for our stuff? currently its all based around use of the Unix "make" utility. should we move away from this? if so, what to? -- Sebastian Rahtz Information and Support Group Manager Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From lou.burnard at retired.ox.ac.uk Fri Jan 7 07:54:18 2011 From: lou.burnard at retired.ox.ac.uk (Lou Burnard) Date: Fri, 07 Jan 2011 12:54:18 +0000 Subject: [tei-council] Calling all naming experts Message-ID: <4D270CFA.2080005@retired.ox.ac.uk> Now that we seem to have moved on from the naming of objectTypes, could I respectfully draw Council's attention to another proposal for a new element, specifically to see whether anyone has a better idea for its proposed name? The requirement is documented in sf ticket 3147225, from which I quote: ------------ Messages on TEI-L starting 28 Oct 2010 with subject "encoding musical drama" point to the need for some chunk-level element capable of combining multiple <sp> elements into a single unit without needing to open a <div>. A major use case is for passages of dialogue meant to be sung, perhaps with some assciated dialogue which are identified as distinct parts of a dramatic text, for example items labelled as "musical numbers" . Crucially, such items are at the same hierarchic level as the speeches which precede and follow them. The proposal is to define a new <spGrp> element which would stand in more or less the same relation to <sp> as does <lg> to <l> : it would be a member of model.divPart, and have a content model, and have the same content model as <sp> -------------- No-one has actually said this is a bad idea yet, though that's also an option. But assuming it's not a bad idea, I wonder if we can come up with a better name? From sebastian.rahtz at oucs.ox.ac.uk Fri Jan 7 08:17:54 2011 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Fri, 7 Jan 2011 13:17:54 +0000 Subject: [tei-council] Calling all naming experts In-Reply-To: <4D270CFA.2080005@retired.ox.ac.uk> References: <4D270CFA.2080005@retired.ox.ac.uk> Message-ID: <3FE7AFA4-24F5-43CB-8F37-B8F1C9C96863@oucs.ox.ac.uk> On 7 Jan 2011, at 12:54, Lou Burnard wrote: > musical numbers" . Crucially, such items are at the same hierarchic > level as the speeches which precede and follow them. The proposal is to > define a new <spGrp> element which would stand in more or less the same > relation to <sp> as does <lg> to <l> : it would be a member of > model.divPart, and have a content model, and have the same content model > as <sp> you don't mean that, do you? doesn't it content model of "<sp>+" ? the alternative is to extend the generic <ab> to make it a grouping element comparable to HTML's <div>. Or invent a new generic grouper called <block>. It depends on whether this is the thin end of the wedge or not. Otherwise <spGrp> seems fine. -- Sebastian Rahtz Information and Support Group Manager Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From laurent.romary at inria.fr Fri Jan 7 09:02:28 2011 From: laurent.romary at inria.fr (Laurent Romary) Date: Fri, 7 Jan 2011 15:02:28 +0100 Subject: [tei-council] FR nuncles: new element tei:objectType In-Reply-To: <E43CEE04-3C21-466F-8C04-9294E33EE678@oucs.ox.ac.uk> References: <4D1DDB09.40904@kcl.ac.uk> <DCF242AC-E557-45D7-99CA-EE9D678507E2@oucs.ox.ac.uk> <4D2352EF.2020205@retired.ox.ac.uk> <F65328A6-0D5E-4BFC-A50B-B5F327AF1EBD@oucs.ox.ac.uk> <4D2355DE.7080905@retired.ox.ac.uk> <9F02758B-A992-4ADB-89BC-F19923C0F6C1@oucs.ox.ac.uk> <4D2359A5.6000606@retired.ox.ac.uk> <E005D498-F9A5-4C26-A6FA-923267003AB9@oucs.ox.ac.uk> <4D24535B.6090707@kcl.ac.uk> <43A1FAAC-D72B-41DA-ADCD-4C988F36E2B1@oucs.ox.ac.uk> <4D245C47.4060808@oucs.ox.ac.uk> <F2E5398C-FE05-47B0-9564-C956008C929C@inria.fr> <4D245F72.6020604@kcl.ac.uk> <557B16EE-E217-4860-8107-41F258BACA3B@inria.fr> <6168DFA5-E2FE-4CA4-AB09-8A2861EB1453@inria.fr> <4D247F96.3030508@kcl.ac.uk> <F05F14CA-6813-4531-8885-270DC9DA0317@inria.fr> <4D2491C8.4070004@oucs.ox.ac.uk> <4D26E379.6090209@oucs.ox.ac.uk> <D74BB5CE-A247-41EF-88CF-B92BF984ED37@inria.fr> <4D26F94A.8020408@kcl.ac.uk> <D0D692E9-E086-46D0-8C77-2210E3B0AE60@inria.fr> <2DBFCD32-D607-4229-A78C-41C63F6E4374@oucs.ox.ac.uk> <96A218CD-CE3A-4674-A44E-793212680C90@inria.fr> <47DBAE31-571E-4354-98D8-348A611F4477@oucs.ox.ac.uk> <512CC0FE-247E-4642-95FF-704950E915C6@inria.fr> <E43CEE04-3C21-466F-8C04-9294E33EE678@oucs.ox.ac.uk> Message-ID: <E260A4C4-AB54-48A0-829B-B1E9664AC0D9@inria.fr> On your two points: - I am just asking you to bootstrap by correcting the text you pointed to (you said it was outdated) and pass the token over to Gaby - re: "make", the question is really if there are some alternatives which would make so many of us basically happy. Is there a widely spread, platform independant framework, with a good and native connection to svn? Le 7 janv. 11 ? 13:52, Sebastian Rahtz a ?crit : > > On 7 Jan 2011, at 12:30, Laurent Romary wrote: > >> Seb, would you want to bring this as a wiki page, ammend the obvious >> mistakes and let Gabriel put in the feedback from his experience? > > well, the bald answer is no, I would not _want_ to :-} > > but seriously, I wonder if I am the best person to do such a thing - > I am too > close to the setup to be objective enough, and know what needs > explaining. > > which brings me to a more strategic question. > > I am sure we all agree that building the Guidelines is something > that more people should be able to do, and it should be simple > and easier to use. > > so the question for those of you who feel able to comment > on the engineering is what framework/setup/workflow/system > is best for our stuff? currently its all based around use of the Unix > "make" utility. should we move away from this? if so, what to? > > -- > Sebastian Rahtz > Information and Support Group Manager > Oxford University Computing Services > 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 > > S?lo le pido a Dios > que el futuro no me sea indiferente > Laurent Romary INRIA & HUB-IDSL laurent.romary at inria.fr From sebastian.rahtz at oucs.ox.ac.uk Fri Jan 7 09:17:50 2011 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Fri, 7 Jan 2011 14:17:50 +0000 Subject: [tei-council] FR nuncles: new element tei:objectType In-Reply-To: <E260A4C4-AB54-48A0-829B-B1E9664AC0D9@inria.fr> References: <4D1DDB09.40904@kcl.ac.uk> <DCF242AC-E557-45D7-99CA-EE9D678507E2@oucs.ox.ac.uk> <4D2352EF.2020205@retired.ox.ac.uk> <F65328A6-0D5E-4BFC-A50B-B5F327AF1EBD@oucs.ox.ac.uk> <4D2355DE.7080905@retired.ox.ac.uk> <9F02758B-A992-4ADB-89BC-F19923C0F6C1@oucs.ox.ac.uk> <4D2359A5.6000606@retired.ox.ac.uk> <E005D498-F9A5-4C26-A6FA-923267003AB9@oucs.ox.ac.uk> <4D24535B.6090707@kcl.ac.uk> <43A1FAAC-D72B-41DA-ADCD-4C988F36E2B1@oucs.ox.ac.uk> <4D245C47.4060808@oucs.ox.ac.uk> <F2E5398C-FE05-47B0-9564-C956008C929C@inria.fr> <4D245F72.6020604@kcl.ac.uk> <557B16EE-E217-4860-8107-41F258BACA3B@inria.fr> <6168DFA5-E2FE-4CA4-AB09-8A2861EB1453@inria.fr> <4D247F96.3030508@kcl.ac.uk> <F05F14CA-6813-4531-8885-270DC9DA0317@inria.fr> <4D2491C8.4070004@oucs.ox.ac.uk> <4D26E379.6090209@oucs.ox.ac.uk> <D74BB5CE-A247-41EF-88CF-B92BF984ED37@inria.fr> <4D26F94A.8020408@kcl.ac.uk> <D0D692E9-E086-46D0-8C77-2210E3B0AE60@inria.fr> <2DBFCD32-D607-4229-A78C-41C63F6E4374@oucs.ox.ac.uk> <96A218CD-CE3A-4674-A44E-793212680C90@inria.fr> <47DBAE31-571E-4354-98D8-348A611F4477@oucs.ox.ac.uk> <512CC0FE-247E-4642-95FF-704950E915C6@inria.fr> <E43CEE04-3C21-466F-8C04-9294E33EE678@oucs.ox.ac.uk> <E260A4C4-AB54-48A0-829B-B1E9664AC0D9@inria.fr> Message-ID: <51220C2E-F665-4F3E-A3EC-7EBA27C43A14@oucs.ox.ac.uk> On 7 Jan 2011, at 14:02, Laurent Romary wrote: > > - re: "make", the question is really if there are some alternatives > which would make so many of us basically happy. Is there a widely > spread, platform independant framework, with a good and native > connection to svn? > not sure where connection to svn comes in? but see http://en.wikipedia.org/wiki/List_of_build_automation_software for an idea of the scale of the problem -- Sebastian Rahtz Information and Support Group Manager Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From laurent.romary at inria.fr Fri Jan 7 09:22:06 2011 From: laurent.romary at inria.fr (Laurent Romary) Date: Fri, 7 Jan 2011 15:22:06 +0100 Subject: [tei-council] FR nuncles: new element tei:objectType In-Reply-To: <51220C2E-F665-4F3E-A3EC-7EBA27C43A14@oucs.ox.ac.uk> References: <4D1DDB09.40904@kcl.ac.uk> <DCF242AC-E557-45D7-99CA-EE9D678507E2@oucs.ox.ac.uk> <4D2352EF.2020205@retired.ox.ac.uk> <F65328A6-0D5E-4BFC-A50B-B5F327AF1EBD@oucs.ox.ac.uk> <4D2355DE.7080905@retired.ox.ac.uk> <9F02758B-A992-4ADB-89BC-F19923C0F6C1@oucs.ox.ac.uk> <4D2359A5.6000606@retired.ox.ac.uk> <E005D498-F9A5-4C26-A6FA-923267003AB9@oucs.ox.ac.uk> <4D24535B.6090707@kcl.ac.uk> <43A1FAAC-D72B-41DA-ADCD-4C988F36E2B1@oucs.ox.ac.uk> <4D245C47.4060808@oucs.ox.ac.uk> <F2E5398C-FE05-47B0-9564-C956008C929C@inria.fr> <4D245F72.6020604@kcl.ac.uk> <557B16EE-E217-4860-8107-41F258BACA3B@inria.fr> <6168DFA5-E2FE-4CA4-AB09-8A2861EB1453@inria.fr> <4D247F96.3030508@kcl.ac.uk> <F05F14CA-6813-4531-8885-270DC9DA0317@inria.fr> <4D2491C8.4070004@oucs.ox.ac.uk> <4D26E379.6090209@oucs.ox.ac.uk> <D74BB5CE-A247-41EF-88CF-B92BF984ED37@inria.fr> <4D26F94A.8020408@kcl.ac.uk> <D0D692E9-E086-46D0-8C77-2210E3B0AE60@inria.fr> <2DBFCD32-D607-4229-A78C-41C63F6E4374@oucs.ox.ac.uk> <96A218CD-CE3A-4674-A44E-793212680C90@inria.fr> <47DBAE31-571E-4354-98D8-348A611F4477@oucs.ox.ac.uk> <512CC0FE-247E-4642-95FF-704950E915C6@inria.fr> <E43CEE04-3C21-466F-8C04-9294E33EE678@oucs.ox.ac.uk> <E260A4C4-AB54-48A0-829B-B1E9664AC0D9@inria.fr> <51220C2E-F665-4F3E-A3EC-7EBA27C43A14@oucs.ox.ac.uk> Message-ID: <E877343C-3586-490B-B718-DBE3C400697A@inria.fr> Well, I thought some environment could automatically work with a versioning environment. Anuhow, the list you sent is just frightening. Did you have an idea when you asked the question? Le 7 janv. 11 ? 15:17, Sebastian Rahtz a ?crit : > > On 7 Jan 2011, at 14:02, Laurent Romary wrote: > >> >> - re: "make", the question is really if there are some alternatives >> which would make so many of us basically happy. Is there a widely >> spread, platform independant framework, with a good and native >> connection to svn? >> > > > not sure where connection to svn comes in? > > but see http://en.wikipedia.org/wiki/List_of_build_automation_software > for an idea of the scale of the problem > -- > Sebastian Rahtz > Information and Support Group Manager > Oxford University Computing Services > 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 > > S?lo le pido a Dios > que el futuro no me sea indiferente > Laurent Romary INRIA & HUB-IDSL laurent.romary at inria.fr From sebastian.rahtz at oucs.ox.ac.uk Fri Jan 7 09:30:35 2011 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Fri, 7 Jan 2011 14:30:35 +0000 Subject: [tei-council] FR nuncles: new element tei:objectType In-Reply-To: <E877343C-3586-490B-B718-DBE3C400697A@inria.fr> References: <4D1DDB09.40904@kcl.ac.uk> <DCF242AC-E557-45D7-99CA-EE9D678507E2@oucs.ox.ac.uk> <4D2352EF.2020205@retired.ox.ac.uk> <F65328A6-0D5E-4BFC-A50B-B5F327AF1EBD@oucs.ox.ac.uk> <4D2355DE.7080905@retired.ox.ac.uk> <9F02758B-A992-4ADB-89BC-F19923C0F6C1@oucs.ox.ac.uk> <4D2359A5.6000606@retired.ox.ac.uk> <E005D498-F9A5-4C26-A6FA-923267003AB9@oucs.ox.ac.uk> <4D24535B.6090707@kcl.ac.uk> <43A1FAAC-D72B-41DA-ADCD-4C988F36E2B1@oucs.ox.ac.uk> <4D245C47.4060808@oucs.ox.ac.uk> <F2E5398C-FE05-47B0-9564-C956008C929C@inria.fr> <4D245F72.6020604@kcl.ac.uk> <557B16EE-E217-4860-8107-41F258BACA3B@inria.fr> <6168DFA5-E2FE-4CA4-AB09-8A2861EB1453@inria.fr> <4D247F96.3030508@kcl.ac.uk> <F05F14CA-6813-4531-8885-270DC9DA0317@inria.fr> <4D2491C8.4070004@oucs.ox.ac.uk> <4D26E379.6090209@oucs.ox.ac.uk> <D74BB5CE-A247-41EF-88CF-B92BF984ED37@inria.fr> <4D26F94A.8020408@kcl.ac.uk> <D0D692E9-E086-46D0-8C77-2210E3B0AE60@inria.fr> <2DBFCD32-D607-4229-A78C-41C63F6E4374@oucs.ox.ac.uk> <96A218CD-CE3A-4674-A44E-793212680C90@inria.fr> <47DBAE31-571E-4354-98D8-348A611F4477@oucs.ox.ac.uk> <512CC0FE-247E-4642-95FF-704950E915C6@inria.fr> <E43CEE04-3C21-466F-8C04-9294E33EE678@oucs.ox.ac.uk> <E260A4C4-AB54-48A0-829B-B1E9664AC0D9@inria.fr> <51220C2E-F665-4F3E-A3EC-7EBA27C43A14@oucs.ox.ac.uk> <E877343C-3586-490B-B718-DBE3C400697A@inria.fr> Message-ID: <4FC4F7F4-997D-441C-9A00-792456227215@oucs.ox.ac.uk> On 7 Jan 2011, at 14:22, Laurent Romary wrote: > Well, I thought some environment could automatically work with a > versioning environment. Anuhow, the list you sent is just frightening. > Did you have an idea when you asked the question? no, I don't have a preferred answer. as I said before Xmas, one of my desirables is to run a continuous integration tool for P5. this would mean that any change triggered a build and test of everything, and immediate reporting. We'd have to make more and better tests, but that would all be to the good. my current thought was to use Hudson (http://hudson-ci.org/) but I am fairly terrified at the work that may be involved in converting to, and managing, that -- Sebastian Rahtz Information and Support Group Manager Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From lou.burnard at retired.ox.ac.uk Fri Jan 7 09:41:22 2011 From: lou.burnard at retired.ox.ac.uk (Lou Burnard) Date: Fri, 07 Jan 2011 14:41:22 +0000 Subject: [tei-council] FR nuncles: new element tei:objectType In-Reply-To: <51220C2E-F665-4F3E-A3EC-7EBA27C43A14@oucs.ox.ac.uk> References: <4D1DDB09.40904@kcl.ac.uk> <4D24535B.6090707@kcl.ac.uk> <43A1FAAC-D72B-41DA-ADCD-4C988F36E2B1@oucs.ox.ac.uk> <4D245C47.4060808@oucs.ox.ac.uk> <F2E5398C-FE05-47B0-9564-C956008C929C@inria.fr> <4D245F72.6020604@kcl.ac.uk> <557B16EE-E217-4860-8107-41F258BACA3B@inria.fr> <6168DFA5-E2FE-4CA4-AB09-8A2861EB1453@inria.fr> <4D247F96.3030508@kcl.ac.uk> <F05F14CA-6813-4531-8885-270DC9DA0317@inria.fr> <4D2491C8.4070004@oucs.ox.ac.uk> <4D26E379.6090209@oucs.ox.ac.uk> <D74BB5CE-A247-41EF-88CF-B92BF984ED37@inria.fr> <4D26F94A.8020408@kcl.ac.uk> <D0D692E9-E086-46D0-8C77-2210E3B0AE60@inria.fr> <2DBFCD32-D607-4229-A78C-41C63F6E4374@oucs.ox.ac.uk> <96A218CD-CE3A-4674-A44E-793212680C90@inria.fr> <47DBAE31-571E-4354-98D8-348A611F4477@oucs.ox.ac.uk> <512CC0FE-247E-4642-95FF-704950E915C6@inria.fr> <E43CEE04-3C21-466F-8C04-9294E33EE678@oucs.ox.ac.uk> <E260A4C4-AB54-48A0-829B-B1E9664AC0D9@inria.fr> <51220C2E-F665-4F3E-A3EC-7EBA27C43A14@oucs.ox.ac.uk> Message-ID: <4D272612.4080300@retired.ox.ac.uk> On 07/01/11 14:17, Sebastian Rahtz wrote: > > On 7 Jan 2011, at 14:02, Laurent Romary wrote: > >> >> - re: "make", the question is really if there are some alternatives >> which would make so many of us basically happy. Is there a widely >> spread, platform independant framework, with a good and native >> connection to svn? >> > > > not sure where connection to svn comes in? > > but see http://en.wikipedia.org/wiki/List_of_build_automation_software > for an idea of the scale of the problem What is the problem we're trying to solve here? Where is the evidence that the current build process is seriously broken? I hypothesize that one problem with it is seen to be that too few people have direct experience/understanding of it. So while introducing an entirely different system would level the playing field (by ensuring that nobody had knowledge of it) it would hardly advance the status quo very much. I also hypothesize that there is a perceived need to enhance the current environment to do continuous validation better. But, as I said before, this is pointless until we have better test materials. And if we had better test materials then we'd see immediate benefits in our current build process, with no need to go to a completely new environment. From sebastian.rahtz at oucs.ox.ac.uk Fri Jan 7 09:53:09 2011 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Fri, 7 Jan 2011 14:53:09 +0000 Subject: [tei-council] FR nuncles: new element tei:objectType In-Reply-To: <4D272612.4080300@retired.ox.ac.uk> References: <4D1DDB09.40904@kcl.ac.uk> <4D24535B.6090707@kcl.ac.uk> <43A1FAAC-D72B-41DA-ADCD-4C988F36E2B1@oucs.ox.ac.uk> <4D245C47.4060808@oucs.ox.ac.uk> <F2E5398C-FE05-47B0-9564-C956008C929C@inria.fr> <4D245F72.6020604@kcl.ac.uk> <557B16EE-E217-4860-8107-41F258BACA3B@inria.fr> <6168DFA5-E2FE-4CA4-AB09-8A2861EB1453@inria.fr> <4D247F96.3030508@kcl.ac.uk> <F05F14CA-6813-4531-8885-270DC9DA0317@inria.fr> <4D2491C8.4070004@oucs.ox.ac.uk> <4D26E379.6090209@oucs.ox.ac.uk> <D74BB5CE-A247-41EF-88CF-B92BF984ED37@inria.fr> <4D26F94A.8020408@kcl.ac.uk> <D0D692E9-E086-46D0-8C77-2210E3B0AE60@inria.fr> <2DBFCD32-D607-4229-A78C-41C63F6E4374@oucs.ox.ac.uk> <96A218CD-CE3A-4674-A44E-793212680C90@inria.fr> <47DBAE31-571E-4354-98D8-348A611F4477@oucs.ox.ac.uk> <512CC0FE-247E-4642-95FF-704950E915C6@inria.fr> <E43CEE04-3C21-466F-8C04-9294E33EE678@oucs.ox.ac.uk> <E260A4C4-AB54-48A0-829B-B1E9664AC0D9@inria.fr> <51220C2E-F665-4F3E-A3EC-7EBA27C43A14@oucs.ox.ac.uk> <4D272612.4080300@retired.ox.ac.uk> Message-ID: <FACE5996-F865-414D-AADF-6981639828F5@oucs.ox.ac.uk> On 7 Jan 2011, at 14:41, Lou Burnard wrote: > What is the problem we're trying to solve here? two problems a) use of technology which assumes *nix, and which no-one under 50 understands b) lack of a rigorous test procedure > > Where is the evidence that the current build process is seriously broken? do a quick poll, and see how many people can build P5 from scratch on their desktop > > I hypothesize that one problem with it is seen to be that too few people > have direct experience/understanding of it. So while introducing an > entirely different system would level the playing field (by ensuring > that nobody had knowledge of it) it would hardly advance the status quo > very much. but if the new system was already more familiar to more people, this would not apply. and if it was automated, no-one _needs_ to understand it how to run it. > > I also hypothesize that there is a perceived need to enhance the current > environment to do continuous validation better. But, as I said before, > this is pointless until we have better test materials. And if we had > better test materials then we'd see immediate benefits in our current > build process, with no need to go to a completely new environment. I don't buy these arguments. a) our current testing is already pretty effective, (certainly compared to P4!). It regularly catches typos or brainlosses perpetrated by you or me or syd or an other. b) to run the current testing is manual, tedious, local, and poorly documented. Simply automating that so that any commit triggered a change and report on a web site which anyone could see would be hugely beneficial. -- Sebastian Rahtz Information and Support Group Manager Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From James.Cummings at oucs.ox.ac.uk Fri Jan 7 10:29:50 2011 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Fri, 07 Jan 2011 15:29:50 +0000 Subject: [tei-council] how to encode a hyphen at the end of a line, column, or page when you are encoding hyphens In-Reply-To: <4D270046.3050107@retired.ox.ac.uk> References: <4D0E7288.6010006@ultraslavonic.info> <4D0F93EF.3060100@oucs.ox.ac.uk> <4D194285.8010804@ultraslavonic.info> <4D23D7F5.5040009@ultraslavonic.info> <10C726D9-029A-43CF-86D5-DD69BD0778DC@oucs.ox.ac.uk> <4D24A47F.3080107@uvic.ca> <4D24DD6A.8020803@retired.ox.ac.uk> <A37CC5A3-E2A4-4F52-8655-3F45EBC4BF12@oucs.ox.ac.uk> <4D26F04D.2040005@oucs.ox.ac.uk> <4D270046.3050107@retired.ox.ac.uk> Message-ID: <4D27316E.9090103@oucs.ox.ac.uk> On 07/01/11 12:00, Lou Burnard wrote: > On 07/01/11 10:51, James Cummings wrote: >> >> >> I think this is the general TEI form of ontological agnosticism, >> we tell you that if you want to mark up a paragraph use<p> or >> <title> for titles but we don't (and I'd argue shouldn't) tell >> people what paragraphs or titles are. > > > On the contrary, we do very precisely tell people what "paragraphs" and > "titles" are. We leave it to them as to whether or not they choose to > observe the distinction, but it is nonsense to say that all the > categories defined by the TEI are entirely vacuous. Paragraph was probably a bad choice, because we do say more about them than most elements. However, we define a <p> element as "(paragraph) marks paragraphs in prose". My point being we use the word 'title', 'author', 'birth' or other similar words in our element definitions usually without defining them by themselves. <title> is "contains a title for any kind of work". If I go to the section on titles: http://www.tei-c.org/release/doc/tei-p5-doc/en/html/CO.html#COBICOR then I find lots of discussion about how the title element should be used, but nothing which explains what a title is. If I go to the other main place title elements are discussed at: http://www.tei-c.org/release/doc/tei-p5-doc/en/html/HD.html#HD21 where it says things like "The title element contains the chief name of the electronic work, including any alternative title or subtitles it may have" ... but this isn't a definition of what a _title_ is, just what the title element means when inside a titleStmt. The point is what the TEI seems to say is 'Some people seem to say there are things called titles, if you want to encode them here is how to do it, moreover we recommend distinguishing between the title for the electronic resource and its source, etc.' Similarly with the birth element, this is defined as "(birth) contains information about a person's birth, such as its date and place". Here we use the name of the element in defining the element. Ok, granted we indicate this might have something to do with a time and place, but we don't tell people what the act of being born is (and whether, for example, caesarian sections count). We say that some people might want to record birth metadata about a person, and here is how to do so. There are some cases where we provide supplemental examples in the definition (c.f. 'binding' ... should that be e.g. instead of i.e. there?), to explain more the kind of thing we mean, without still saying what the thing itself is (we don't define what a 'binding' is, just some things that might be used to make it up). I should hurry to state that I think this is a strength of the TEI not a weakness. We could forever be embroiled in text-crit religious wars over whether something was a title, merely a reference to a title, or something else. Instead the TEI says that some people like to make the distinction that there are things called 'titles' and here is how to use them. This is a very long tangential way of saying that I still feel we should present the hyphenation options and maybe explain why someone might want to do it one way or another but leave them to make that decision. -James -- Dr James Cummings, Research Technologies Service OUCS, University of Oxford From lou.burnard at oucs.ox.ac.uk Fri Jan 7 16:13:33 2011 From: lou.burnard at oucs.ox.ac.uk (Lou Burnard) Date: Fri, 07 Jan 2011 21:13:33 +0000 Subject: [tei-council] Calling all naming experts In-Reply-To: <3FE7AFA4-24F5-43CB-8F37-B8F1C9C96863@oucs.ox.ac.uk> References: <4D270CFA.2080005@retired.ox.ac.uk> <3FE7AFA4-24F5-43CB-8F37-B8F1C9C96863@oucs.ox.ac.uk> Message-ID: <4D2781FD.8020401@oucs.ox.ac.uk> On 07/01/11 13:17, Sebastian Rahtz wrote: > On 7 Jan 2011, at 12:54, Lou Burnard wrote: > >> musical numbers" . Crucially, such items are at the same hierarchic >> level as the speeches which precede and follow them. The proposal is to >> define a new<spGrp> element which would stand in more or less the same >> relation to<sp> as does<lg> to<l> : it would be a member of >> model.divPart, and have a content model, and have the same content model >> as<sp> > you don't mean that, do you? doesn't it content model of "<sp>+" ? indeed i don't. clearly i pressed the send key before the text was quite ready to be sent. but it isn't just sp+ ... needs to have some other bits and pieces of cruft like what you can have inside and between <sp>s > the alternative is to extend the generic<ab> to make it a grouping > element comparable to HTML's<div>. This, I suggest, would be the kind of extension for which the spanish inquisition was famous: <ab> is defined as being "just like a p but anonymous" so making it a grouping element would be quite a stretch > Or invent a new generic grouper > called<block>. this was suggested earlier, and i see the logic, but i am not sure i see the need for it. this particular use case is the only persuasive case I've come across so far for non-tesselating subdivisions. > It depends on whether this is the thin end of the wedge or not. > Otherwise<spGrp> seems fine. > -- > Sebastian Rahtz > Information and Support Group Manager > Oxford University Computing Services > 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 > > S?lo le pido a Dios > que el futuro no me sea indiferente > From sebastian.rahtz at oucs.ox.ac.uk Sat Jan 8 07:19:18 2011 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Sat, 8 Jan 2011 12:19:18 +0000 Subject: [tei-council] Calling all naming experts In-Reply-To: <4D2781FD.8020401@oucs.ox.ac.uk> References: <4D270CFA.2080005@retired.ox.ac.uk> <3FE7AFA4-24F5-43CB-8F37-B8F1C9C96863@oucs.ox.ac.uk> <4D2781FD.8020401@oucs.ox.ac.uk> Message-ID: <458CA4A1-A3E3-4B31-85AE-2DC058110A06@oucs.ox.ac.uk> On 7 Jan 2011, at 21:13, Lou Burnard wrote: >> Or invent a new generic grouper >> called<block>. > > this was suggested earlier, and i see the logic, but i am not sure i see > the need for it. this particular use case is the only persuasive case > I've come across so far for non-tesselating subdivisions. I would suggest we test this a bit more widely than just the Council. I am not sure everyone out there would agree with you, gasp. my argument is purely theoretical - a <block> would sit alongside <seg> and <ab> to give us an anonymous container at all three levels. we could also, of course, allow <div> to non-tessellate but I think we should make sure paramedics are ready in Southmoor Rd to assist quickly at your attack of apoplexy before I suggest that.... -- Sebastian Rahtz Information and Support Group Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From lou.burnard at retired.ox.ac.uk Sat Jan 8 08:19:56 2011 From: lou.burnard at retired.ox.ac.uk (Lou Burnard) Date: Sat, 8 Jan 2011 13:19:56 +0000 Subject: [tei-council] Calling all naming experts Message-ID: <AF1E1F94-FC50-4F96-8004-DC6BA0A7A710@oucs.ox.ac.uk> Actually I could be pesuaded we need both generic and specific elements. The proposal originated on tei-l so could be revived there certainly. What do other counsllors think? Sent from my HTC ----- Reply message ----- From: "Sebastian Rahtz" <sebastian.rahtz at oucs.ox.ac.uk> Date: Sat, Jan 8, 2011 12:19 Subject: [tei-council] Calling all naming experts To: "Lou Burnard" <lou.burnard at oucs.ox.ac.uk> Cc: "TEI Council" <tei-council at lists.village.Virginia.EDU> On 7 Jan 2011, at 21:13, Lou Burnard wrote: >> Or invent a new generic grouper >> called<block>. > > this was suggested earlier, and i see the logic, but i am not sure i see > the need for it. this particular use case is the only persuasive case > I've come across so far for non-tesselating subdivisions. I would suggest we test this a bit more widely than just the Council. I am not sure everyone out there would agree with you, gasp. my argument is purely theoretical - a <block> would sit alongside <seg> and <ab> to give us an anonymous container at all three levels. we could also, of course, allow <div> to non-tessellate but I think we should make sure paramedics are ready in Southmoor Rd to assist quickly at your attack of apoplexy before I suggest that.... -- Sebastian Rahtz Information and Support Group Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From james.cummings at oucs.ox.ac.uk Sat Jan 8 08:32:00 2011 From: james.cummings at oucs.ox.ac.uk (James Cummings) Date: Sat, 8 Jan 2011 13:32:00 +0000 Subject: [tei-council] Calling all naming experts Message-ID: <xauw1qaotxpxfvl3abplcjqs.1294493511651@email.android.com> I'm currently undecided, but think that this definitely would benefit from more community discussion on TEI-L. James Lou Burnard <lou.burnard at retired.ox.ac.uk> wrote: Actually I could be pesuaded we need both generic and specific elements. The proposal originated on tei-l so could be revived there certainly. What do other counsllors think? Sent from my HTC ----- Reply message ----- From: "Sebastian Rahtz" <sebastian.rahtz at oucs.ox.ac.uk> Date: Sat, Jan 8, 2011 12:19 Subject: [tei-council] Calling all naming experts To: "Lou Burnard" <lou.burnard at oucs.ox.ac.uk> Cc: "TEI Council" <tei-council at lists.village.Virginia.EDU> On 7 Jan 2011, at 21:13, Lou Burnard wrote: >> Or invent a new generic grouper >> called<block>. > > this was suggested earlier, and i see the logic, but i am not sure i see > the need for it. this particular use case is the only persuasive case > I've come across so far for non-tesselating subdivisions. I would suggest we test this a bit more widely than just the Council. I am not sure everyone out there would agree with you, gasp. my argument is purely theoretical - a <block> would sit alongside <seg> and <ab> to give us an anonymous container at all three levels. we could also, of course, allow <div> to non-tessellate but I think we should make sure paramedics are ready in Southmoor Rd to assist quickly at your attack of apoplexy before I suggest that.... -- Sebastian Rahtz Information and Support Group Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente _______________________________________________ tei-council mailing list tei-council at lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council From sebastian.rahtz at oucs.ox.ac.uk Sat Jan 8 09:37:49 2011 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Sat, 8 Jan 2011 14:37:49 +0000 Subject: [tei-council] continuous integration server Message-ID: <7636AC72-D240-4C35-BCE3-A34291A2B3C3@oucs.ox.ac.uk> In case you wondered what I was talking about, I have a trial setup of Hudson at http://rahtz.oucs.ox.ac.uk:8080/ running for a few days. Each time the Subversion repository has a change, it attempts a rebuild of the Guidelines. This avoids the need for each developer to have to run the build and test tools themselves Lots of refinement needed, but something to build on. I'll put it on a proper server if looks useful. -- Sebastian Rahtz Information and Support Group Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From sebastian.rahtz at oucs.ox.ac.uk Sat Jan 8 19:45:40 2011 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Sun, 9 Jan 2011 00:45:40 +0000 Subject: [tei-council] invalid examples allowed in Guidelines? Message-ID: <CDE75081-5D7D-4B10-BE89-B224DAC5B233@oucs.ox.ac.uk> As you or may not know, every <egXML> in the Guidelines source is checked at build time against the P5 schema. This is a good thing, of course. While playing with validation of P5 again, I found (reminded myself) that 26 files have incomplete examples, along the lines of: <msDesc xml:id="DN17"> <!-- ... --> </msDesc> which is not valid because it misses the mandatory child <msIdentifier>. Unfortunately, I cannot see a way to flag some instances <egXML> as being deliberately incomplete. There are four choices: a) fix the examples so they are minimally valid b) fix the build script so that this class of error is thrown away, which has the disadvantage of masking genuine errors; c) leave the error messages in place and remember to ignore them each time (very confusing for the unwary) d) convert all these class of examples to CDATA in <eg> so they are not checked at all. This seems a bad precedent. We were (until today) in a state of b). Option a) is possible, but makes for some over-verbose examples (eg <fileDesc> <titleStmt> <!-- ... --></titleStmt> <editionStmt> <!-- ... --></editionStmt> <extent> <!-- ... --></extent> <publicationStmt> <!-- ... --></publicationStmt> <seriesStmt> <!-- ... --></seriesStmt> <notesStmt> <!-- ... --></notesStmt> <sourceDesc><!-- ... --></sourceDesc> </fileDesc> would need expanding a lot) This was discussed a few years ago but since I have the patient open on the operating table, I'd welcome some current options on the proper way to proceed. -- Sebastian Rahtz Information and Support Group Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From lou.burnard at oucs.ox.ac.uk Sat Jan 8 21:23:53 2011 From: lou.burnard at oucs.ox.ac.uk (Lou Burnard) Date: Sun, 09 Jan 2011 02:23:53 +0000 Subject: [tei-council] invalid examples allowed in Guidelines? In-Reply-To: <CDE75081-5D7D-4B10-BE89-B224DAC5B233@oucs.ox.ac.uk> References: <CDE75081-5D7D-4B10-BE89-B224DAC5B233@oucs.ox.ac.uk> Message-ID: <4D291C39.2080308@oucs.ox.ac.uk> At one time we discussed giving "skeletal" examples like this some special attribute value to indicate that they were not to be parsed. I wonder whether declaring them to be in some other non-TEI namespace would be appropriate. Incidentally, looking at the spec for <egXML> at http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-egXML.html I am mystified to see the claim that it is an empty element. #fail On 09/01/11 00:45, Sebastian Rahtz wrote: > As you or may not know, every<egXML> in the Guidelines source > is checked at build time against the P5 schema. This is a good thing, of course. > > While playing with validation of P5 again, I found (reminded myself) that 26 > files have incomplete examples, along the lines of: > > <msDesc xml:id="DN17"> > <!-- ... --> > </msDesc> > > which is not valid because it misses the mandatory child<msIdentifier>. > > Unfortunately, I cannot see a way to flag some instances<egXML> > as being deliberately incomplete. > > There are four choices: > > a) fix the examples so they are minimally valid > b) fix the build script so that this class of error is thrown away, > which has the disadvantage of masking genuine errors; > c) leave the error messages in place and remember to ignore them each time > (very confusing for the unwary) > d) convert all these class of examples to CDATA in<eg> > so they are not checked at all. This seems a bad precedent. > > We were (until today) in a state of b). > > Option a) is possible, but makes for some over-verbose examples > (eg > <fileDesc> > <titleStmt> <!-- ... --></titleStmt> > <editionStmt> <!-- ... --></editionStmt> > <extent> <!-- ... --></extent> > <publicationStmt> <!-- ... --></publicationStmt> > <seriesStmt> <!-- ... --></seriesStmt> > <notesStmt> <!-- ... --></notesStmt> > <sourceDesc><!-- ... --></sourceDesc> > </fileDesc> > would need expanding a lot) > > This was discussed a few years ago but since I have the patient open > on the operating table, I'd welcome some current options on the > proper way to proceed. > -- > Sebastian Rahtz > Information and Support Group Manager, Oxford University Computing Services > 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 > > S?lo le pido a Dios > que el futuro no me sea indiferente > > > > > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council From sebastian.rahtz at oucs.ox.ac.uk Sun Jan 9 05:34:04 2011 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Sun, 9 Jan 2011 10:34:04 +0000 Subject: [tei-council] invalid examples allowed in Guidelines? In-Reply-To: <4D291C39.2080308@oucs.ox.ac.uk> References: <CDE75081-5D7D-4B10-BE89-B224DAC5B233@oucs.ox.ac.uk> <4D291C39.2080308@oucs.ox.ac.uk> Message-ID: <D70F151F-2817-4913-8B71-2F6BD15A93DA@oucs.ox.ac.uk> On 9 Jan 2011, at 02:23, Lou Burnard wrote: > At one time we discussed giving "skeletal" examples like this some > special attribute value to indicate that they were not to be parsed. I > wonder whether declaring them to be in some other non-TEI namespace > would be appropriate. That would be possible. we'd have to declare a special new element for it. Seems a bit overkill, to be honest. > > Incidentally, looking at the spec for <egXML> at > http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-egXML.html I am > mystified to see the claim that it is an empty element. #fail > oh dang -- Sebastian Rahtz Information and Support Group Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From sebastian.rahtz at oucs.ox.ac.uk Sun Jan 9 05:42:58 2011 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Sun, 9 Jan 2011 10:42:58 +0000 Subject: [tei-council] invalid examples allowed in Guidelines? In-Reply-To: <4D291C39.2080308@oucs.ox.ac.uk> References: <CDE75081-5D7D-4B10-BE89-B224DAC5B233@oucs.ox.ac.uk> <4D291C39.2080308@oucs.ox.ac.uk> Message-ID: <8A70119C-15FD-445E-8E4F-8D192D0B95DE@oucs.ox.ac.uk> On 9 Jan 2011, at 02:23, Lou Burnard wrote: > Incidentally, looking at the spec for <egXML> at > http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-egXML.html I am > mystified to see the claim that it is an empty element. #fail now sorted in Stylesheets, will be reflected in next release (whenever that may be) -- Sebastian Rahtz Information and Support Group Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From kevin.s.hawkins at ultraslavonic.info Sun Jan 9 12:10:42 2011 From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins) Date: Sun, 09 Jan 2011 12:10:42 -0500 Subject: [tei-council] invalid examples allowed in Guidelines? In-Reply-To: <4D291C39.2080308@oucs.ox.ac.uk> References: <CDE75081-5D7D-4B10-BE89-B224DAC5B233@oucs.ox.ac.uk> <4D291C39.2080308@oucs.ox.ac.uk> Message-ID: <4D29EC12.8030102@ultraslavonic.info> Related to this, Syd Bauman is currently working on creating ODDs for the encoding levels described at http://purl.oclc.org/NET/teiinlibraries and has discovered that you can't include @xmlns on any elements within the examples. To clarify Lou's idea while revealing my ignorance, would it be sufficient to put egXML into another namespace, or would every element within an example also need to be? On 1/8/2011 9:23 PM, Lou Burnard wrote: > At one time we discussed giving "skeletal" examples like this some > special attribute value to indicate that they were not to be parsed. I > wonder whether declaring them to be in some other non-TEI namespace > would be appropriate. > On 09/01/11 00:45, Sebastian Rahtz wrote: >> As you or may not know, every<egXML> in the Guidelines source >> is checked at build time against the P5 schema. This is a good thing, of course. >> >> While playing with validation of P5 again, I found (reminded myself) that 26 >> files have incomplete examples, along the lines of: >> >> <msDesc xml:id="DN17"> >> <!-- ... --> >> </msDesc> >> >> which is not valid because it misses the mandatory child<msIdentifier>. >> >> Unfortunately, I cannot see a way to flag some instances<egXML> >> as being deliberately incomplete. >> >> There are four choices: >> >> a) fix the examples so they are minimally valid >> b) fix the build script so that this class of error is thrown away, >> which has the disadvantage of masking genuine errors; >> c) leave the error messages in place and remember to ignore them each time >> (very confusing for the unwary) >> d) convert all these class of examples to CDATA in<eg> >> so they are not checked at all. This seems a bad precedent. >> >> We were (until today) in a state of b). >> >> Option a) is possible, but makes for some over-verbose examples >> (eg >> <fileDesc> >> <titleStmt> <!-- ... --></titleStmt> >> <editionStmt> <!-- ... --></editionStmt> >> <extent> <!-- ... --></extent> >> <publicationStmt> <!-- ... --></publicationStmt> >> <seriesStmt> <!-- ... --></seriesStmt> >> <notesStmt> <!-- ... --></notesStmt> >> <sourceDesc><!-- ... --></sourceDesc> >> </fileDesc> >> would need expanding a lot) >> >> This was discussed a few years ago but since I have the patient open >> on the operating table, I'd welcome some current options on the >> proper way to proceed. >> -- >> Sebastian Rahtz >> Information and Support Group Manager, Oxford University Computing Services >> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 >> >> S?lo le pido a Dios >> que el futuro no me sea indiferente >> >> >> >> >> >> _______________________________________________ >> tei-council mailing list >> tei-council at lists.village.Virginia.EDU >> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council From sebastian.rahtz at oucs.ox.ac.uk Sun Jan 9 12:16:16 2011 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Sun, 9 Jan 2011 17:16:16 +0000 Subject: [tei-council] invalid examples allowed in Guidelines? In-Reply-To: <4D29EC12.8030102@ultraslavonic.info> References: <CDE75081-5D7D-4B10-BE89-B224DAC5B233@oucs.ox.ac.uk> <4D291C39.2080308@oucs.ox.ac.uk> <4D29EC12.8030102@ultraslavonic.info> Message-ID: <52C46B0F-4D1A-4415-B608-D3F23B47D342@oucs.ox.ac.uk> On 9 Jan 2011, at 17:10, Kevin Hawkins wrote: > Related to this, Syd Bauman is currently working on creating ODDs for > the encoding levels described at http://purl.oclc.org/NET/teiinlibraries > and has discovered that you can't include @xmlns on any elements within > the examples. Of course you can. Whether its valid or not depends on the schema you build to validate the ODD. > > To clarify Lou's idea while revealing my ignorance, would it be > sufficient to put egXML into another namespace, or would every element > within an example also need to be? if you said <egXML xmlns="http://www.example.com/foo.bar"> then the <egXML> itself would be invalid, and the stylesheets would have to extended to know what to do with this new beast. the elements inside <egXML> are normally in the same namespace as the <egXML> anyway if you use @xmlns (its value is inherited) -- Sebastian Rahtz Information and Support Group Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From kevin.s.hawkins at ultraslavonic.info Sun Jan 9 13:34:00 2011 From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins) Date: Sun, 09 Jan 2011 13:34:00 -0500 Subject: [tei-council] invalid examples allowed in Guidelines? In-Reply-To: <52C46B0F-4D1A-4415-B608-D3F23B47D342@oucs.ox.ac.uk> References: <CDE75081-5D7D-4B10-BE89-B224DAC5B233@oucs.ox.ac.uk> <4D291C39.2080308@oucs.ox.ac.uk> <4D29EC12.8030102@ultraslavonic.info> <52C46B0F-4D1A-4415-B608-D3F23B47D342@oucs.ox.ac.uk> Message-ID: <4D29FF98.1060602@ultraslavonic.info> On 1/9/2011 12:16 PM, Sebastian Rahtz wrote: > > On 9 Jan 2011, at 17:10, Kevin Hawkins wrote: > >> Related to this, Syd Bauman is currently working on creating ODDs for >> the encoding levels described at http://purl.oclc.org/NET/teiinlibraries >> and has discovered that you can't include @xmlns on any elements within >> the examples. > > Of course you can. Whether its valid or not depends on the schema you build > to validate the ODD. I've asked him to get in touch with you to explain. >> To clarify Lou's idea while revealing my ignorance, would it be >> sufficient to put egXML into another namespace, or would every element >> within an example also need to be? > > > if you said<egXML xmlns="http://www.example.com/foo.bar"> > then the<egXML> itself would be invalid, and the stylesheets > would have to extended to know what to do with this new beast. > > the elements inside<egXML> are normally in the same namespace > as the<egXML> anyway if you use @xmlns (its value is inherited) I stated my question sloppily, leading to confusion. Let me try again. Lou wrote, "I wonder whether declaring them to be in some other non-TEI namespace would be appropriate." I'd like to clarify Lou's suggestion by asking the following: A) To avoid validation errors at build time, would it be sufficient to redefine the element egXML so that it is in another namespace besides tei:? B) Unlike Lou's solution d (convert all these class of examples to CDATA in <eg> so they are not checked at all), redefining the namespace of egXML lets us continue checking for well-formedness of examples. However, am I correct to understand that by doing this, we would lose the ability to validate examples at all? Kevin From sebastian.rahtz at oucs.ox.ac.uk Sun Jan 9 13:43:35 2011 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Sun, 9 Jan 2011 18:43:35 +0000 Subject: [tei-council] invalid examples allowed in Guidelines? In-Reply-To: <4D29FF98.1060602@ultraslavonic.info> References: <CDE75081-5D7D-4B10-BE89-B224DAC5B233@oucs.ox.ac.uk> <4D291C39.2080308@oucs.ox.ac.uk> <4D29EC12.8030102@ultraslavonic.info> <52C46B0F-4D1A-4415-B608-D3F23B47D342@oucs.ox.ac.uk> <4D29FF98.1060602@ultraslavonic.info> Message-ID: <4CB7C8EE-3008-43C4-9B5C-C7CAC262BE14@oucs.ox.ac.uk> On 9 Jan 2011, at 18:34, Kevin Hawkins wrote: > > A) To avoid validation errors at build time, would it be sufficient to > redefine the element egXML so that it is in another namespace besides tei:? > if you make any change to the errant instances of <egXML> in the chapters a) the document would become invalid at a higher level b) the stylesheets would not render those examples properly c) the contents would not be validated at all > B) Unlike Lou's solution d (convert all these class of examples to CDATA > in <eg> so they are not checked at all), redefining the namespace of > egXML lets us continue checking for well-formedness of examples. > However, am I correct to understand that by doing this, we would lose > the ability to validate examples at all? we _could_ make the schema and stylesheet changes above (not too big a deal), and support <specialEgXML> in places, and not validate them. However, there would be _no_ validation, not even that <TEI> was not spelt <TEIX>. its true this would be better than <eg>, as you would get well-formedness checking. For the moment, I have fudged the issue by making this class of error a *warning*. so if you look at the result of a run, you'll see the messages, but it will not have caused the build to fail. -- Sebastian Rahtz Information and Support Group Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From sebastian.rahtz at oucs.ox.ac.uk Sun Jan 9 15:08:13 2011 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Sun, 9 Jan 2011 20:08:13 +0000 Subject: [tei-council] building TEI P5 Message-ID: <5B43971C-3BAF-4530-882D-FBD3C2674475@oucs.ox.ac.uk> I have finally got the TEI Guidelines and Stylesheets building properly under remote control, which makes me happy. If you want to see the sort of things that come up during a build, have a gander at http://rahtz.oucs.ox.ac.uk:8080/job/TEIP5/20/parsed_console/? Nerdy enough for you? -- Sebastian Rahtz Information and Support Group Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From laurent.romary at inria.fr Mon Jan 10 04:23:34 2011 From: laurent.romary at inria.fr (Laurent Romary) Date: Mon, 10 Jan 2011 10:23:34 +0100 Subject: [tei-council] Calling all naming experts In-Reply-To: <xauw1qaotxpxfvl3abplcjqs.1294493511651@email.android.com> References: <xauw1qaotxpxfvl3abplcjqs.1294493511651@email.android.com> Message-ID: <6226984C-E28F-4FA7-89C7-877EFC3193A6@inria.fr> After reading the whole thread, I would be very pragmatic in a) providing right away a specific element (and spGrp is just OK) and b) asking tei-l if there are use cases for a generic beast of which spGrp would be a syntactic suggar. But I would not want b) to prevent implementing a). Laurent (more messages than I can treat...) Le 8 janv. 11 ? 14:32, James Cummings a ?crit : > > I'm currently undecided, but think that this definitely would > benefit from more community discussion on TEI-L. > > James > > Lou Burnard <lou.burnard at retired.ox.ac.uk> wrote: > > > Actually I could be pesuaded we need both generic and specific > elements. The proposal originated on tei-l so could be revived > there certainly. What do other counsllors think? > > Sent from my HTC > > ----- Reply message ----- > From: "Sebastian Rahtz" <sebastian.rahtz at oucs.ox.ac.uk> > Date: Sat, Jan 8, 2011 12:19 > Subject: [tei-council] Calling all naming experts > To: "Lou Burnard" <lou.burnard at oucs.ox.ac.uk> > Cc: "TEI Council" <tei-council at lists.village.Virginia.EDU> > > On 7 Jan 2011, at 21:13, Lou Burnard wrote: > >>> Or invent a new generic grouper >>> called<block>. >> >> this was suggested earlier, and i see the logic, but i am not sure >> i see >> the need for it. this particular use case is the only persuasive case >> I've come across so far for non-tesselating subdivisions. > > I would suggest we test this a bit more widely > than just the Council. I am not sure everyone out there > would agree with you, gasp. > > my argument is purely theoretical - a <block> would > sit alongside <seg> and <ab> to give us an anonymous > container at all three levels. > > we could also, of course, allow <div> to non-tessellate but > I think we should make sure paramedics are ready in > Southmoor Rd to assist quickly at your attack of apoplexy > before I suggest that.... > -- > Sebastian Rahtz > Information and Support Group Manager, Oxford University Computing > Services > 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 > > S?lo le pido a Dios > que el futuro no me sea indiferente > > > > > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Laurent Romary INRIA & HUB-IDSL laurent.romary at inria.fr From laurent.romary at inria.fr Mon Jan 10 06:28:25 2011 From: laurent.romary at inria.fr (Laurent Romary) Date: Mon, 10 Jan 2011 12:28:25 +0100 Subject: [tei-council] invalid examples allowed in Guidelines? In-Reply-To: <CDE75081-5D7D-4B10-BE89-B224DAC5B233@oucs.ox.ac.uk> References: <CDE75081-5D7D-4B10-BE89-B224DAC5B233@oucs.ox.ac.uk> Message-ID: <B999548C-881D-449F-BEFD-E7D78AADDD1D@inria.fr> I think that we sjhould not break up egXML too much, but make it more powerful to cope with various similar use cases. As a preliminary point, we have the same problem in the ISO work, where we would like to state that examples could be validated against the schema that the ODD spec is defining (within the same document), and this shoxs that we should not focus only on the issue of the TEI namespace per se. This leads me to identify two aspects: - indicating that one should or should not try to validate an example. Mimicking the its:translate attribute (cf. http://www.w3.org/TR/its/), we could think of something like validate="yes" (resp. "no") when we want to indicate that an example is to be validated by whatever processor - indicating against what to validate. We could have the simple mechanisms of providing (not changing, thus not using @xmlns) the reference namespace for the example within @ns (we do have this attribute already, why not use it) Laurent Le 9 janv. 11 ? 01:45, Sebastian Rahtz a ?crit : > As you or may not know, every <egXML> in the Guidelines source > is checked at build time against the P5 schema. This is a good > thing, of course. > > While playing with validation of P5 again, I found (reminded myself) > that 26 > files have incomplete examples, along the lines of: > > <msDesc xml:id="DN17"> > <!-- ... --> > </msDesc> > > which is not valid because it misses the mandatory child > <msIdentifier>. > > Unfortunately, I cannot see a way to flag some instances <egXML> > as being deliberately incomplete. > > There are four choices: > > a) fix the examples so they are minimally valid > b) fix the build script so that this class of error is thrown away, > which has the disadvantage of masking genuine errors; > c) leave the error messages in place and remember to ignore them > each time > (very confusing for the unwary) > d) convert all these class of examples to CDATA in <eg> > so they are not checked at all. This seems a bad precedent. > > We were (until today) in a state of b). > > Option a) is possible, but makes for some over-verbose examples > (eg > <fileDesc> > <titleStmt> <!-- ... --></titleStmt> > <editionStmt> <!-- ... --></editionStmt> > <extent> <!-- ... --></extent> > <publicationStmt> <!-- ... --></publicationStmt> > <seriesStmt> <!-- ... --></seriesStmt> > <notesStmt> <!-- ... --></notesStmt> > <sourceDesc><!-- ... --></sourceDesc> > </fileDesc> > would need expanding a lot) > > This was discussed a few years ago but since I have the patient open > on the operating table, I'd welcome some current options on the > proper way to proceed. > -- > Sebastian Rahtz > Information and Support Group Manager, Oxford University Computing > Services > 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 > > S?lo le pido a Dios > que el futuro no me sea indiferente > > > > > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Laurent Romary INRIA & HUB-IDSL laurent.romary at inria.fr From sebastian.rahtz at oucs.ox.ac.uk Mon Jan 10 06:43:44 2011 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 10 Jan 2011 11:43:44 +0000 Subject: [tei-council] invalid examples allowed in Guidelines? In-Reply-To: <B999548C-881D-449F-BEFD-E7D78AADDD1D@inria.fr> References: <CDE75081-5D7D-4B10-BE89-B224DAC5B233@oucs.ox.ac.uk> <B999548C-881D-449F-BEFD-E7D78AADDD1D@inria.fr> Message-ID: <8DB60C1E-81AB-407E-BBD7-D644FCCEF424@oucs.ox.ac.uk> On 10 Jan 2011, at 11:28, Laurent Romary wrote: > This leads me to identify two aspects: > - indicating that one should or should not try to validate an example. > Mimicking the its:translate attribute (cf. http://www.w3.org/TR/its/), > we could think of something like validate="yes" (resp. "no") when we > want to indicate that an example is to be validated by whatever > processor unfortunately, I cannot see any way using NVDL to implement such an idea. P5 implements its example parsing by using an NVLD script which says that islands in the namespace http://www.tei-c.org/ns/Examples should be validated against p5odds-examples.rng - the mapping from namespace to schema is managed externally. We could implement support for a namespace http://www.tei-c.org/ns/ExamplesUnparsed, I suppose. But is it worth the trouble? does anyone want to do it? Personally, I think we should fix as many of these as we can to make sure they _are_ valid. There are not many occasions when the invalidity is justified. eg I showed one to Lou yesterday which had <list> <head>?</head> </list> and is thus invalid 'cos at least one item is needed. In that case it seems obvious to me that we should add one item and a comment saying "and more?" or whatever. Otherwise a reader may genuinely think this is legal. -- Sebastian Rahtz Information and Support Group Manager Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From sebastian.rahtz at oucs.ox.ac.uk Mon Jan 10 06:43:47 2011 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 10 Jan 2011 11:43:47 +0000 Subject: [tei-council] invalid examples allowed in Guidelines? In-Reply-To: <B999548C-881D-449F-BEFD-E7D78AADDD1D@inria.fr> References: <CDE75081-5D7D-4B10-BE89-B224DAC5B233@oucs.ox.ac.uk> <B999548C-881D-449F-BEFD-E7D78AADDD1D@inria.fr> Message-ID: <54EE9BEA-79A0-4973-8011-F825625CFF08@oucs.ox.ac.uk> On 10 Jan 2011, at 11:28, Laurent Romary wrote: > This leads me to identify two aspects: > - indicating that one should or should not try to validate an example. > Mimicking the its:translate attribute (cf. http://www.w3.org/TR/its/), > we could think of something like validate="yes" (resp. "no") when we > want to indicate that an example is to be validated by whatever > processor unfortunately, I cannot see any way using NVDL to implement such an idea. P5 implements its example parsing by using an NVLD script which says that islands in the namespace http://www.tei-c.org/ns/Examples should be validated against p5odds-examples.rng - the mapping from namespace to schema is managed externally. We could implement support for a namespace http://www.tei-c.org/ns/ExamplesUnparsed, I suppose. But is it worth the trouble? does anyone want to do it? Personally, I think we should fix as many of these as we can to make sure they _are_ valid. There are not many occasions when the invalidity is justified. eg I showed one to Lou yesterday which had <list> <head>?</head> </list> and is thus invalid 'cos at least one item is needed. In that case it seems obvious to me that we should add one item and a comment saying "and more?" or whatever. Otherwise a reader may genuinely think this is legal. -- Sebastian Rahtz Information and Support Group Manager Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From sebastian.rahtz at oucs.ox.ac.uk Mon Jan 10 06:43:50 2011 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Mon, 10 Jan 2011 11:43:50 +0000 Subject: [tei-council] invalid examples allowed in Guidelines? In-Reply-To: <B999548C-881D-449F-BEFD-E7D78AADDD1D@inria.fr> References: <CDE75081-5D7D-4B10-BE89-B224DAC5B233@oucs.ox.ac.uk> <B999548C-881D-449F-BEFD-E7D78AADDD1D@inria.fr> Message-ID: <F28709E5-15C7-4143-B49F-51BEB0CD540C@oucs.ox.ac.uk> On 10 Jan 2011, at 11:28, Laurent Romary wrote: > This leads me to identify two aspects: > - indicating that one should or should not try to validate an example. > Mimicking the its:translate attribute (cf. http://www.w3.org/TR/its/), > we could think of something like validate="yes" (resp. "no") when we > want to indicate that an example is to be validated by whatever > processor unfortunately, I cannot see any way using NVDL to implement such an idea. P5 implements its example parsing by using an NVLD script which says that islands in the namespace http://www.tei-c.org/ns/Examples should be validated against p5odds-examples.rng - the mapping from namespace to schema is managed externally. We could implement support for a namespace http://www.tei-c.org/ns/ExamplesUnparsed, I suppose. But is it worth the trouble? does anyone want to do it? Personally, I think we should fix as many of these as we can to make sure they _are_ valid. There are not many occasions when the invalidity is justified. eg I showed one to Lou yesterday which had <list> <head>?</head> </list> and is thus invalid 'cos at least one item is needed. In that case it seems obvious to me that we should add one item and a comment saying "and more?" or whatever. Otherwise a reader may genuinely think this is legal. -- Sebastian Rahtz Information and Support Group Manager Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From lou.burnard at oucs.ox.ac.uk Mon Jan 10 21:31:11 2011 From: lou.burnard at oucs.ox.ac.uk (Lou Burnard) Date: Tue, 11 Jan 2011 02:31:11 +0000 Subject: [tei-council] invalid examples allowed in Guidelines? In-Reply-To: <F28709E5-15C7-4143-B49F-51BEB0CD540C@oucs.ox.ac.uk> References: <CDE75081-5D7D-4B10-BE89-B224DAC5B233@oucs.ox.ac.uk> <B999548C-881D-449F-BEFD-E7D78AADDD1D@inria.fr> <F28709E5-15C7-4143-B49F-51BEB0CD540C@oucs.ox.ac.uk> Message-ID: <4D2BC0EF.8030304@oucs.ox.ac.uk> I agree that we should fix as many as possible and will try to do so as soon as I can reliably identify the ones that need attention. The ones that cannot be fixed -- because they are deliberately schematic -- should in my view be recoded as CDATA marked sections. This would have the advantage that they will be visually distinct from the "real" examples. The text around them should also explicitlky draw attention to the fact that these are not valid examples. On 10/01/11 11:43, Sebastian Rahtz wrote: > On 10 Jan 2011, at 11:28, Laurent Romary wrote: >> This leads me to identify two aspects: >> - indicating that one should or should not try to validate an example. >> Mimicking the its:translate attribute (cf. http://www.w3.org/TR/its/), >> we could think of something like validate="yes" (resp. "no") when we >> want to indicate that an example is to be validated by whatever >> processor > unfortunately, I cannot see any way using NVDL to implement such > an idea. > > P5 implements its example parsing by using an NVLD script which > says that islands in the namespace http://www.tei-c.org/ns/Examples > should be validated against p5odds-examples.rng - the mapping > from namespace to schema is managed externally. > > We could implement support for a namespace > http://www.tei-c.org/ns/ExamplesUnparsed, I suppose. > But is it worth the trouble? does anyone want to do it? > > Personally, I think we should fix as many of these as we > can to make sure they _are_ valid. There are not many > occasions when the invalidity is justified. eg I showed one > to Lou yesterday which had > <list> > <head>?</head> > </list> > and is thus invalid 'cos at least one item is needed. In that > case it seems obvious to me that we should add one > item and a comment saying "and more?" or whatever. > Otherwise a reader may genuinely think this is legal. > -- > Sebastian Rahtz > Information and Support Group Manager > Oxford University Computing Services > 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 > > S?lo le pido a Dios > que el futuro no me sea indiferente > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council From sebastian.rahtz at oucs.ox.ac.uk Tue Jan 11 04:44:01 2011 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 11 Jan 2011 09:44:01 +0000 Subject: [tei-council] invalid examples allowed in Guidelines? In-Reply-To: <4D2BC0EF.8030304@oucs.ox.ac.uk> References: <CDE75081-5D7D-4B10-BE89-B224DAC5B233@oucs.ox.ac.uk> <B999548C-881D-449F-BEFD-E7D78AADDD1D@inria.fr> <F28709E5-15C7-4143-B49F-51BEB0CD540C@oucs.ox.ac.uk> <4D2BC0EF.8030304@oucs.ox.ac.uk> Message-ID: <B3DFDF95-EE62-4E32-8D2B-8DF8C7FACD7C@oucs.ox.ac.uk> On 11 Jan 2011, at 02:31, Lou Burnard wrote: > I agree that we should fix as many as possible and will try to do so as > soon as I can reliably identify the ones that need attention. visible to all at http://rahtz.oucs.ox.ac.uk:8080/job/TEIP5/29/parsed_console/? ?.. > > The ones that cannot be fixed -- because they are deliberately schematic > -- should in my view be recoded as CDATA marked sections. This would > have the advantage that they will be visually distinct from the "real" > examples. The text around them should also explicitlky draw attention to > the fact that these are not valid examples. James has an interesting counter proposal, that we should make all the examples entirely valid, but add a new attribute @noDisplay in the TEIX namespace. so <egXML xmlns="http://www.tei-c.org/ns/Examples" xmlns:teix="http://www.tei-c.org/ns/Examples"> <fileDesc teix:noDisplay='true'> <titleStmt> <title>The title

would generate in the printed page What do others think of this? I find it rather elegant, and has exactly the right effect. -- Sebastian Rahtz Information and Support Group Manager Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From laurent.romary at inria.fr Tue Jan 11 04:53:53 2011 From: laurent.romary at inria.fr (Laurent Romary) Date: Tue, 11 Jan 2011 10:53:53 +0100 Subject: [tei-council] invalid examples allowed in Guidelines? In-Reply-To: References: <4D2BC0EF.8030304@oucs.ox.ac.uk> Message-ID: <549FD3BC-5008-423C-BD06-60D8815AD11F@inria.fr> I would combine this proposal with what I suggested yesterday. We need to put flesh around egXML in any case. James' proposal impacts on the presentation, but we also need to control the validation (again independantly from the short-term issue we have here). I'll file a ticket accordingly. Le 11 janv. 11 ? 10:44, Sebastian Rahtz a ?crit : > > On 11 Jan 2011, at 02:31, Lou Burnard wrote: > >> I agree that we should fix as many as possible and will try to do >> so as >> soon as I can reliably identify the ones that need attention. > > visible to all at http://rahtz.oucs.ox.ac.uk:8080/job/TEIP5/29/parsed_console/? > ?.. >> >> The ones that cannot be fixed -- because they are deliberately >> schematic >> -- should in my view be recoded as CDATA marked sections. This would >> have the advantage that they will be visually distinct from the >> "real" >> examples. The text around them should also explicitlky draw >> attention to >> the fact that these are not valid examples. > > > > James has an interesting counter proposal, that we should make all > the examples entirely valid, but add a new attribute @noDisplay in > the TEIX namespace. > > so > > > > The title > > >

> > >

> > >

> > > > > would generate in the printed page > > > > > > What do others think of this? I find it rather elegant, and has > exactly the > right effect. > -- > Sebastian Rahtz > Information and Support Group Manager > Oxford University Computing Services > 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 > > S?lo le pido a Dios > que el futuro no me sea indiferente > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Laurent Romary INRIA & HUB-IDSL laurent.romary at inria.fr From sebastian.rahtz at oucs.ox.ac.uk Tue Jan 11 04:56:46 2011 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 11 Jan 2011 09:56:46 +0000 Subject: [tei-council] invalid examples allowed in Guidelines? In-Reply-To: <549FD3BC-5008-423C-BD06-60D8815AD11F@inria.fr> References: <4D2BC0EF.8030304@oucs.ox.ac.uk> <549FD3BC-5008-423C-BD06-60D8815AD11F@inria.fr> Message-ID: <995F4798-BBFD-4A74-A4F4-A22FAA43FEA2@oucs.ox.ac.uk> On 11 Jan 2011, at 09:53, Laurent Romary wrote: > I would combine this proposal with what I suggested yesterday. We need > to put flesh around egXML in any case. James' proposal impacts on the > presentation, but we also need to control the validation I am personally not in favour of adding features which we cannot implement. So I'd suggest not putting in an RFC unless/until we have a clearer idea how such a thing could work. In general I would say that what schema elements are validated against, and how that is arranged, is outside our scope. -- Sebastian Rahtz Information and Support Group Manager Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From laurent.romary at inria.fr Tue Jan 11 05:00:48 2011 From: laurent.romary at inria.fr (Laurent Romary) Date: Tue, 11 Jan 2011 11:00:48 +0100 Subject: [tei-council] invalid examples allowed in Guidelines? In-Reply-To: <995F4798-BBFD-4A74-A4F4-A22FAA43FEA2@oucs.ox.ac.uk> References: <4D2BC0EF.8030304@oucs.ox.ac.uk> <549FD3BC-5008-423C-BD06-60D8815AD11F@inria.fr> <995F4798-BBFD-4A74-A4F4-A22FAA43FEA2@oucs.ox.ac.uk> Message-ID: On the contray (and we had this debate before), our duty is also to anticipate and give guidance on mechanisms which are direct consequences of providing something as generic as ODD. I would not mind mentioning in the documzentation that a feature is not yet implemented in Roma, but let users decide what they would do with this. A concrete application would be for someone to extract (by means of his home-made stylesheets) all examples that can be validated and put them as a reference set for further distribution. You don't need to change your tools for this. Think large! Le 11 janv. 11 ? 10:56, Sebastian Rahtz a ?crit : > > On 11 Jan 2011, at 09:53, Laurent Romary wrote: > >> I would combine this proposal with what I suggested yesterday. We >> need >> to put flesh around egXML in any case. James' proposal impacts on the >> presentation, but we also need to control the validation > > I am personally not in favour of adding features which we cannot > implement. > So I'd suggest not putting in an RFC unless/until we have a clearer > idea how > such a thing could work. > > In general I would say that what schema elements are validated > against, > and how that is arranged, is outside our scope. > -- > Sebastian Rahtz > Information and Support Group Manager > Oxford University Computing Services > 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 > > S?lo le pido a Dios > que el futuro no me sea indiferente > Laurent Romary INRIA & HUB-IDSL laurent.romary at inria.fr From sebastian.rahtz at oucs.ox.ac.uk Tue Jan 11 05:21:25 2011 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 11 Jan 2011 10:21:25 +0000 Subject: [tei-council] invalid examples allowed in Guidelines? In-Reply-To: References: <4D2BC0EF.8030304@oucs.ox.ac.uk> <549FD3BC-5008-423C-BD06-60D8815AD11F@inria.fr> <995F4798-BBFD-4A74-A4F4-A22FAA43FEA2@oucs.ox.ac.uk> Message-ID: On 11 Jan 2011, at 10:00, Laurent Romary wrote: > On the contray (and we had this debate before), our duty is also to > anticipate and give guidance on mechanisms which are direct > consequences of providing something as generic as ODD. maybe ? :-} > A concrete application would be for someone to extract (by means of > his home-made stylesheets) all examples that can be validated and put > them as a reference set for further distribution. sure, that would work > You don't need to > change your tools for this. Think large! my instinct tells me, tho, to also worry about the huge backlog of more immediate feature requests and bugs that we are failing to process. -- Sebastian Rahtz Information and Support Group Manager Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From James.Cummings at oucs.ox.ac.uk Tue Jan 11 05:23:31 2011 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Tue, 11 Jan 2011 10:23:31 +0000 Subject: [tei-council] invalid examples allowed in Guidelines? In-Reply-To: References: <4D2BC0EF.8030304@oucs.ox.ac.uk> Message-ID: <4D2C2FA3.80606@oucs.ox.ac.uk> On 11/01/11 09:44, Sebastian Rahtz wrote: > James has an interesting counter proposal, that we should make all > the examples entirely valid, but add a new attribute @noDisplay in the TEIX namespace. Just to elaborate on this. The idea is that when we are missing out elements in TEI examples we are doing so *only* for a reason of presentation. (Changes to ODD to allow other things, I would contend is a separate issue.) It would, however, be better if the user could choose to see the missing bits or not in some cases, and the example was when fully shown a valid chunk of TEI. So my suggesting is *slightly* different from what Sebastian suggests below. Instead of putting the attribute on the I would have put it on the child elements since you may wish to hide some of them and not others. Moreover I would not have this be a binary true/false but instead have something like: 'collapsed', 'expanded', 'hidden', etc. So instead of: > so > > > > The title > > >

> > >

> > >

> > > we might have: The title

Something here

which would be shown in a web view as something like:

Something here

i.e. the 'collapsed' titleStmt is able to be clicked to expand and appear, the publicationStmt is always visible, the editionStmt is not visible or commented upon, the sourceDesc is not visible but commented upon. In printed media collapsed and hidden would be handled identically. Things should only be marked as 'invisible' if the example is entirely valid without them but for some reason we wanted to include it. (e.g. maintaining fidelity with an existing example, or using the same example multiple times with different bits invisible or hidden.) > What do others think of this? I find it rather elegant, and has exactly the > right effect. I hope this expansion on it is equally elegant. While you can talk me out of the need for 'invisible' probably, I would argue that it isn't a binary opposition of displayed and nonDisplayed that we need but notedAsAComment, collapsed and expanded. -James -- Dr James Cummings, Research Technologies Service OUCS, University of Oxford From laurent.romary at inria.fr Tue Jan 11 05:23:53 2011 From: laurent.romary at inria.fr (Laurent Romary) Date: Tue, 11 Jan 2011 11:23:53 +0100 Subject: [tei-council] invalid examples allowed in Guidelines? In-Reply-To: References: <4D2BC0EF.8030304@oucs.ox.ac.uk> <549FD3BC-5008-423C-BD06-60D8815AD11F@inria.fr> <995F4798-BBFD-4A74-A4F4-A22FAA43FEA2@oucs.ox.ac.uk> Message-ID: Le 11 janv. 11 ? 11:21, Sebastian Rahtz a ?crit : > > On 11 Jan 2011, at 10:00, Laurent Romary wrote: > >> On the contray (and we had this debate before), our duty is also to >> anticipate and give guidance on mechanisms which are direct >> consequences of providing something as generic as ODD. > > maybe ? :-} Good... :-) > >> A concrete application would be for someone to extract (by means of >> his home-made stylesheets) all examples that can be validated and put >> them as a reference set for further distribution. > sure, that would work I'll mention this, then. > >> You don't need to >> change your tools for this. Think large! > > > my instinct tells me, tho, to also worry about the huge backlog of > more immediate feature requests and bugs that we are failing to > process. Sure! I have blocked a day tomorrow, now that I am fit again, to take- up TEI issues. BTW, when are you available for the intrduction to Hudson? > -- > Sebastian Rahtz > Information and Support Group Manager > Oxford University Computing Services > 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 > > S?lo le pido a Dios > que el futuro no me sea indiferente > Laurent Romary INRIA & HUB-IDSL laurent.romary at inria.fr From sebastian.rahtz at oucs.ox.ac.uk Tue Jan 11 05:53:04 2011 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 11 Jan 2011 10:53:04 +0000 Subject: [tei-council] invalid examples allowed in Guidelines? In-Reply-To: <4D2C2FA3.80606@oucs.ox.ac.uk> References: <4D2BC0EF.8030304@oucs.ox.ac.uk> <4D2C2FA3.80606@oucs.ox.ac.uk> Message-ID: <8E3982E8-952F-4DBD-BF5C-A09EDF145330@oucs.ox.ac.uk> Sure, I think the exact details of what the @display attribute does, and what values it can take, could be thrashed out during an implementation phase, if the idea is accepted. of course, we don't have to agree on a single answer: - we can make some of the errant examples complete and valid in the normal way - we can turn some into CDATA (as we have to for ones which are _meant_ to be invalid) - we can use James' slippery mechanism for some I think it is at least possible that the number of examples which really need the James Method may be too small to justify the work involved in implementing it now. Alternatively we might find lots of other places where it would be useful. one school of thought would say we should make all elements in all examples expandable/collapseable -- Sebastian Rahtz Information and Support Group Manager Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From James.Cummings at oucs.ox.ac.uk Tue Jan 11 06:56:29 2011 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Tue, 11 Jan 2011 11:56:29 +0000 Subject: [tei-council] invalid examples allowed in Guidelines? In-Reply-To: <8E3982E8-952F-4DBD-BF5C-A09EDF145330@oucs.ox.ac.uk> References: <4D2BC0EF.8030304@oucs.ox.ac.uk> <4D2C2FA3.80606@oucs.ox.ac.uk> <8E3982E8-952F-4DBD-BF5C-A09EDF145330@oucs.ox.ac.uk> Message-ID: <4D2C456D.4050101@oucs.ox.ac.uk> On 11/01/11 10:53, Sebastian Rahtz wrote: > one school of thought would say we should make all elements in all examples expandable/collapseable In the web view, yes I would probably agree with that, but you need to record somewhere what its _default_ state is (which is then what is seen in a printed view, one supposes). That is really what I'm proposing, I think. I don't feel this is too much of a slippery slope because I don't see where it can go. I'm not proposing recording other forms of rendition information about examples... only answering the need for some of them to appear fragmentary but still be valid when copied and pasted. Expanding that, or providing further rendition information we already have technologies to do. We can put an @xml:id on an example and then say "this funny example, colour it all pink" through using something like CSS. But to use mechanisms like that to hide only certain children seems painful in the extreme. Showing only portions of examples appears like a straightforward use-case to me. -James -- Dr James Cummings, Research Technologies Service OUCS, University of Oxford From sebastian.rahtz at oucs.ox.ac.uk Tue Jan 11 07:17:20 2011 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 11 Jan 2011 12:17:20 +0000 Subject: [tei-council] invalid examples allowed in Guidelines? In-Reply-To: <4D2C456D.4050101@oucs.ox.ac.uk> References: <4D2BC0EF.8030304@oucs.ox.ac.uk> <4D2C2FA3.80606@oucs.ox.ac.uk> <8E3982E8-952F-4DBD-BF5C-A09EDF145330@oucs.ox.ac.uk> <4D2C456D.4050101@oucs.ox.ac.uk> Message-ID: <829BEACD-B771-4E72-8116-460841D98496@oucs.ox.ac.uk> On 11 Jan 2011, at 11:56, James Cummings wrote: > I'm not proposing recording other forms of rendition information > about examples... only answering the need for some of them to > appear fragmentary but still be valid when copied and pasted. > Expanding that, or providing further rendition information we > already have technologies to do. Yes, I have no problems with this. There are many ways we could render the bits that are added for forms sake, rather than to make a real example (could colour them grey if they are not supposed to be real, for instance, instead of collapsing, or put them in 6pt writing). I just did a pass over some of the easier errors and fixed them. Worst I found was this: Proceedings of a workshop on corpus resources Programme Organizer Geoffrey Leech DTI Speech and Language Technology Club meeting, 3-4 January 1990, Wadham College, Oxford which looks entirely plausible, but is not - is mandatory for . As it stands, that is genuinely misleading for a reader. -- Sebastian Rahtz Information and Support Group Manager Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From sebastian.rahtz at oucs.ox.ac.uk Tue Jan 11 07:49:05 2011 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 11 Jan 2011 12:49:05 +0000 Subject: [tei-council] invalid examples allowed in Guidelines? In-Reply-To: <4D2C2FA3.80606@oucs.ox.ac.uk> References: <4D2BC0EF.8030304@oucs.ox.ac.uk> <4D2C2FA3.80606@oucs.ox.ac.uk> Message-ID: <7032B5D7-87B0-4231-AA5F-8FBB3A418E8D@oucs.ox.ac.uk> Here's an interesting example:
English-French
Suppose you _do_ want to make this minimally valid, how do you do so? 's content model says ( hom | sense | model.entryPart.top | model.global) + so which does one pick to make a toy example? -- Sebastian Rahtz Information and Support Group Manager Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From James.Cummings at oucs.ox.ac.uk Tue Jan 11 08:00:34 2011 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Tue, 11 Jan 2011 13:00:34 +0000 Subject: [tei-council] invalid examples allowed in Guidelines? In-Reply-To: <7032B5D7-87B0-4231-AA5F-8FBB3A418E8D@oucs.ox.ac.uk> References: <4D2BC0EF.8030304@oucs.ox.ac.uk> <4D2C2FA3.80606@oucs.ox.ac.uk> <7032B5D7-87B0-4231-AA5F-8FBB3A418E8D@oucs.ox.ac.uk> Message-ID: <4D2C5472.5070205@oucs.ox.ac.uk> On 11/01/11 12:49, Sebastian Rahtz wrote: > Here's an interesting example: > >
English-French > > > >
> > > Suppose you _do_ want to make this minimally valid, how > do you do so?'s content model says > > ( hom | sense | model.entryPart.top | model.global) + > > so which does one pick to make a toy example? seems reasonable. ;-) (I was tempted to suggest also valid at this point...) -James -- Dr James Cummings, Research Technologies Service OUCS, University of Oxford From laurent.romary at inria.fr Tue Jan 11 08:04:12 2011 From: laurent.romary at inria.fr (Laurent Romary) Date: Tue, 11 Jan 2011 14:04:12 +0100 Subject: [tei-council] invalid examples allowed in Guidelines? In-Reply-To: <4D2C5472.5070205@oucs.ox.ac.uk> References: <4D2BC0EF.8030304@oucs.ox.ac.uk> <4D2C2FA3.80606@oucs.ox.ac.uk> <7032B5D7-87B0-4231-AA5F-8FBB3A418E8D@oucs.ox.ac.uk> <4D2C5472.5070205@oucs.ox.ac.uk> Message-ID: I would suggest that the minimal content forr should be based on , if we wan t to make any sense of this....
English-French cat
dog
horse
Le 11 janv. 11 ? 14:00, James Cummings a ?crit : > On 11/01/11 12:49, Sebastian Rahtz wrote: >> Here's an interesting example: >> >>
English-French >> >> >> >>
>> >> >> Suppose you _do_ want to make this minimally valid, how >> do you do so?'s content model says >> >> ( hom | sense | model.entryPart.top | model.global) + >> >> so which does one pick to make a toy example? > > seems reasonable. ;-) > > (I was tempted to suggest also valid at this point...) > > -James > -- > Dr James Cummings, Research Technologies Service > OUCS, University of Oxford > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Laurent Romary INRIA & HUB-IDSL laurent.romary at inria.fr From sebastian.rahtz at oucs.ox.ac.uk Tue Jan 11 08:06:38 2011 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 11 Jan 2011 13:06:38 +0000 Subject: [tei-council] invalid examples allowed in Guidelines? In-Reply-To: <4D2C5472.5070205@oucs.ox.ac.uk> References: <4D2BC0EF.8030304@oucs.ox.ac.uk> <4D2C2FA3.80606@oucs.ox.ac.uk> <7032B5D7-87B0-4231-AA5F-8FBB3A418E8D@oucs.ox.ac.uk> <4D2C5472.5070205@oucs.ox.ac.uk> Message-ID: <6B483ABA-CDB0-4B90-B2CC-099155035BF4@oucs.ox.ac.uk> On 11 Jan 2011, at 13:00, James Cummings wrote: > seems reasonable. ;-) > > (I was tempted to suggest also valid at this point?) which makes the point that if is valid, the idea of the + in "hom | sense | model.entryPart.top | model.global) +" is pretty meaningless, and might as well be *, which would solve the problem :-} -- Sebastian Rahtz Information and Support Group Manager Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From laurent.romary at inria.fr Tue Jan 11 08:10:45 2011 From: laurent.romary at inria.fr (Laurent Romary) Date: Tue, 11 Jan 2011 14:10:45 +0100 Subject: [tei-council] invalid examples allowed in Guidelines? In-Reply-To: <6B483ABA-CDB0-4B90-B2CC-099155035BF4@oucs.ox.ac.uk> References: <4D2BC0EF.8030304@oucs.ox.ac.uk> <4D2C2FA3.80606@oucs.ox.ac.uk> <7032B5D7-87B0-4231-AA5F-8FBB3A418E8D@oucs.ox.ac.uk> <4D2C5472.5070205@oucs.ox.ac.uk> <6B483ABA-CDB0-4B90-B2CC-099155035BF4@oucs.ox.ac.uk> Message-ID: Good point by the way. My own view of a dictionary editing workflows makes sense of an empty entry. Le 11 janv. 11 ? 14:06, Sebastian Rahtz a ?crit : > > On 11 Jan 2011, at 13:00, James Cummings wrote: >> seems reasonable. ;-) >> >> (I was tempted to suggest also valid at this point?) > which makes the point that if > > > > is valid, the idea of the + in > "hom | sense | model.entryPart.top | model.global) +" > is pretty meaningless, and might as well be *, > which would solve the problem :-} > > > -- > Sebastian Rahtz > Information and Support Group Manager > Oxford University Computing Services > 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 > > S?lo le pido a Dios > que el futuro no me sea indiferente > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Laurent Romary INRIA & HUB-IDSL laurent.romary at inria.fr From sebastian.rahtz at oucs.ox.ac.uk Tue Jan 11 08:13:03 2011 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 11 Jan 2011 13:13:03 +0000 Subject: [tei-council] invalid examples allowed in Guidelines? In-Reply-To: References: <4D2BC0EF.8030304@oucs.ox.ac.uk> <4D2C2FA3.80606@oucs.ox.ac.uk> <7032B5D7-87B0-4231-AA5F-8FBB3A418E8D@oucs.ox.ac.uk> <4D2C5472.5070205@oucs.ox.ac.uk> <6B483ABA-CDB0-4B90-B2CC-099155035BF4@oucs.ox.ac.uk> Message-ID: <403A29D5-299C-4F17-8386-CAA06434C182@oucs.ox.ac.uk> On 11 Jan 2011, at 13:10, Laurent Romary wrote: > Good point by the way. My own view of a dictionary editing workflows > makes sense of an empty entry. most of the TEI allows empty containers, so this one might as well too... -- Sebastian Rahtz Information and Support Group Manager Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From James.Cummings at oucs.ox.ac.uk Tue Jan 11 08:42:49 2011 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Tue, 11 Jan 2011 13:42:49 +0000 Subject: [tei-council] invalid examples allowed in Guidelines? In-Reply-To: <403A29D5-299C-4F17-8386-CAA06434C182@oucs.ox.ac.uk> References: <4D2BC0EF.8030304@oucs.ox.ac.uk> <4D2C2FA3.80606@oucs.ox.ac.uk> <7032B5D7-87B0-4231-AA5F-8FBB3A418E8D@oucs.ox.ac.uk> <4D2C5472.5070205@oucs.ox.ac.uk> <6B483ABA-CDB0-4B90-B2CC-099155035BF4@oucs.ox.ac.uk> <403A29D5-299C-4F17-8386-CAA06434C182@oucs.ox.ac.uk> Message-ID: <4D2C5E59.8040008@oucs.ox.ac.uk> On 11/01/11 13:13, Sebastian Rahtz wrote: > > On 11 Jan 2011, at 13:10, Laurent Romary wrote: > >> Good point by the way. My own view of a dictionary editing workflows >> makes sense of an empty entry. > > > most of the TEI allows empty containers, so this one might as well too... I think this is a separate bug/FR and shouldn't distract us from our purpose in dealing with fragmentary examples. ;-) -James -- Dr James Cummings, Research Technologies Service OUCS, University of Oxford From sebastian.rahtz at oucs.ox.ac.uk Tue Jan 11 08:47:06 2011 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 11 Jan 2011 13:47:06 +0000 Subject: [tei-council] invalid examples allowed in Guidelines? In-Reply-To: <4D2C5E59.8040008@oucs.ox.ac.uk> References: <4D2BC0EF.8030304@oucs.ox.ac.uk> <4D2C2FA3.80606@oucs.ox.ac.uk> <7032B5D7-87B0-4231-AA5F-8FBB3A418E8D@oucs.ox.ac.uk> <4D2C5472.5070205@oucs.ox.ac.uk> <6B483ABA-CDB0-4B90-B2CC-099155035BF4@oucs.ox.ac.uk> <403A29D5-299C-4F17-8386-CAA06434C182@oucs.ox.ac.uk> <4D2C5E59.8040008@oucs.ox.ac.uk> Message-ID: On 11 Jan 2011, at 13:42, James Cummings wrote: > > I think this is a separate bug/FR and shouldn't distract us from > our purpose in dealing with fragmentary examples. ;-) > most of the easy ones are done. If you have half an hour free, fancy addressing some of the ones listed below? its not very hard usually. if you can do these, whats left are the high-level structural ones. /var/lib/hudson/jobs/TEIP5/workspace/Source/Guidelines/en/FS-FeatureStructures.xml:1116:43: warning: unfinished element "fileDesc": "(titleStmt, publicationStmt, (sourceDesc)+)" required to finish the element /var/lib/hudson/jobs/TEIP5/workspace/Source/Guidelines/en/FS-FeatureStructures.xml:1122:14: warning: unfinished element "fsDecl": "(fDecl)+" required to finish the element /var/lib/hudson/jobs/TEIP5/workspace/Source/Guidelines/en/FS-FeatureStructures.xml:1125:14: warning: unfinished element "fsDecl": "(fDecl)+" required to finish the element /var/lib/hudson/jobs/TEIP5/workspace/Source/Guidelines/en/FS-FeatureStructures.xml:1133:16: warning: unfinished element "body": "((div)+ | (div1)+ | (l | p | ab | lg | sp | graph | tree | eTree | forest | forestGrp | u | schemaSpec | floatingText | eg | egXML | moduleSpec | specGrp | elementSpec | classSpec | macroSpec | listRef | classRef | elementRef | macroRef | moduleRef | specGrpRef | bibl | biblStruct | biblFull | msDesc | desc | label | list | listBibl | listOrg | listEvent | listPerson | listPlace | listNym | listWit | stage | move | view | camera | sound | caption | tech | quote | cit | said | q | castList | table | superEntry | entry | entryFree)+)" required to finish the element /var/lib/hudson/jobs/TEIP5/workspace/Source/Guidelines/en/FS-FeatureStructures.xml:1155:14: warning: unfinished element "fsDecl": "(fDecl)+" required to finish the element /var/lib/hudson/jobs/TEIP5/workspace/Source/Guidelines/en/FS-FeatureStructures.xml:1158:14: warning: unfinished element "fsDecl": "(fDecl)+" required to finish the element /var/lib/hudson/jobs/TEIP5/workspace/Source/Guidelines/en/FS-FeatureStructures.xml:1171:44: warning: unfinished element "fileDesc": "(titleStmt, publicationStmt, (sourceDesc)+)" required to finish the element /var/lib/hudson/jobs/TEIP5/workspace/Source/Guidelines/en/FS-FeatureStructures.xml:1184:16: warning: unfinished element "body": "((div)+ | (div1)+ | (l | p | ab | lg | sp | graph | tree | eTree | forest | forestGrp | u | schemaSpec | floatingText | eg | egXML | moduleSpec | specGrp | elementSpec | classSpec | macroSpec | listRef | classRef | elementRef | macroRef | moduleRef | specGrpRef | bibl | biblStruct | biblFull | msDesc | desc | label | list | listBibl | listOrg | listEvent | listPerson | listPlace | listNym | listWit | stage | move | view | camera | sound | caption | tech | quote | cit | said | q | castList | table | superEntry | entry | entryFree)+)" required to finish the element /var/lib/hudson/jobs/TEIP5/workspace/Source/Guidelines/en/FS-FeatureStructures.xml:1245:17: warning: unfinished element "fDecl": "vRange" required to finish the element /var/lib/hudson/jobs/TEIP5/workspace/Source/Guidelines/en/FS-FeatureStructures.xml:1248:17: warning: unfinished element "fDecl": "vRange" required to finish the element /var/lib/hudson/jobs/TEIP5/workspace/Source/Specs/fsdDecl.xml:48:18: warning: unfinished element "fsDecl": "(fDecl)+" required to finish the element /var/lib/hudson/jobs/TEIP5/workspace/Source/Specs/fsdDecl.xml:51:18: warning: unfinished element "fsDecl": "(fDecl)+" required to finish the element /var/lib/hudson/jobs/TEIP5/workspace/Source/Specs/fsdDecl.xml:60:39: warning: unfinished element "fsDecl": "(fDecl)+" required to finish the element /var/lib/hudson/jobs/TEIP5/workspace/Source/Specs/fsdDecl.xml:61:56: warning: unfinished element "fsDecl": "(fDecl)+" required to finish the element /var/lib/hudson/jobs/TEIP5/workspace/Source/Specs/fsdDecl.xml:72:18: warning: unfinished element "fsDecl": "(fDecl)+" required to finish the element /var/lib/hudson/jobs/TEIP5/workspace/Source/Specs/fsdDecl.xml:75:18: warning: unfinished element "fsDecl": "(fDecl)+" required to finish the element /var/lib/hudson/jobs/TEIP5/workspace/Source/Specs/fsDecl.xml:143:17: warning: unfinished element "fDecl": "vRange" required to finish the element /var/lib/hudson/jobs/TEIP5/workspace/Source/Specs/fsDecl.xml:146:17: warning: unfinished element "fDecl": "vRange" required to finish the element /var/lib/hudson/jobs/TEIP5/workspace/Source/Specs/fsDescr.xml:42:17: warning: unfinished element "fDecl": "vRange" required to finish the element /var/lib/hudson/jobs/TEIP5/workspace/Source/Specs/fsDescr.xml:46:17: warning: unfinished element "fDecl": "vRange" required to finish the element /var/lib/hudson/jobs/TEIP5/workspace/Source/Specs/fsConstraints.xml:53:18: warning: unfinished element "bicond": "((fs | f), iff, (fs | f))" required to finish the element /var/lib/hudson/jobs/TEIP5/workspace/Source/Specs/fsConstraints.xml:56:16: warning: unfinished element "cond": "((fs | f), then, (fs | f))" required to finish the element > -- Sebastian Rahtz Information and Support Group Manager Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From laurent.romary at inria.fr Tue Jan 11 08:49:57 2011 From: laurent.romary at inria.fr (Laurent Romary) Date: Tue, 11 Jan 2011 14:49:57 +0100 Subject: [tei-council] invalid examples allowed in Guidelines? In-Reply-To: <4D2C5E59.8040008@oucs.ox.ac.uk> References: <4D2BC0EF.8030304@oucs.ox.ac.uk> <4D2C2FA3.80606@oucs.ox.ac.uk> <7032B5D7-87B0-4231-AA5F-8FBB3A418E8D@oucs.ox.ac.uk> <4D2C5472.5070205@oucs.ox.ac.uk> <6B483ABA-CDB0-4B90-B2CC-099155035BF4@oucs.ox.ac.uk> <403A29D5-299C-4F17-8386-CAA06434C182@oucs.ox.ac.uk> <4D2C5E59.8040008@oucs.ox.ac.uk> Message-ID: And inded, a minimally filled example is better than just presenting an empty container. Le 11 janv. 11 ? 14:42, James Cummings a ?crit : > On 11/01/11 13:13, Sebastian Rahtz wrote: >> >> On 11 Jan 2011, at 13:10, Laurent Romary wrote: >> >>> Good point by the way. My own view of a dictionary editing workflows >>> makes sense of an empty entry. >> >> >> most of the TEI allows empty containers, so this one might as well >> too... > > > I think this is a separate bug/FR and shouldn't distract us from our > purpose in dealing with fragmentary examples. ;-) > > -James > -- > Dr James Cummings, Research Technologies Service > OUCS, University of Oxford Laurent Romary INRIA & HUB-IDSL laurent.romary at inria.fr From lou.burnard at oucs.ox.ac.uk Tue Jan 11 10:30:09 2011 From: lou.burnard at oucs.ox.ac.uk (Lou Burnard) Date: Tue, 11 Jan 2011 15:30:09 +0000 Subject: [tei-council] invalid examples allowed in Guidelines? In-Reply-To: <4D2C5472.5070205@oucs.ox.ac.uk> References: <4D2BC0EF.8030304@oucs.ox.ac.uk> <4D2C2FA3.80606@oucs.ox.ac.uk> <7032B5D7-87B0-4231-AA5F-8FBB3A418E8D@oucs.ox.ac.uk> <4D2C5472.5070205@oucs.ox.ac.uk> Message-ID: <4D2C7781.3060803@oucs.ox.ac.uk> (sorry to come to this discussion late) I think this discussion is missing a rather important point about what the function of an example is or should be. The examples in the body of the text of the Guidelines are for the most part intended to illustrate a specific point about how a specific element should be used. They are not meant to be complete documents in themselves, nor exemplary in any sense other than that of the point being illustrated. They should be valid, but not if making them valid necessitates introducing confusing irrelevancies. So, in this case, I would ask whether the example is trying to tell us that a
can contain just s, or whether it is trying to tell us something about the contents of the s. I think it's the former rather than the latter. Adding content to the s would in fact confuse the issue (does it mean that a
can contain only empty entries, or only entries which contain just s, or any kind of entry?) Hence, I think this example is in the category of "deliberately invalid schematick" and I would wrap it in a CDATA marked section accordingly. On 11/01/11 13:00, James Cummings wrote: > On 11/01/11 12:49, Sebastian Rahtz wrote: >> Here's an interesting example: >> >>
English-French >> >> >> >>
>> >> >> Suppose you _do_ want to make this minimally valid, how >> do you do so?'s content model says >> >> ( hom | sense | model.entryPart.top | model.global) + >> >> so which does one pick to make a toy example? > seems reasonable. ;-) > > (I was tempted to suggest also valid at this point...) > > -James From sebastian.rahtz at oucs.ox.ac.uk Tue Jan 11 10:39:52 2011 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 11 Jan 2011 15:39:52 +0000 Subject: [tei-council] invalid examples allowed in Guidelines? In-Reply-To: <4D2C7781.3060803@oucs.ox.ac.uk> References: <4D2BC0EF.8030304@oucs.ox.ac.uk> <4D2C2FA3.80606@oucs.ox.ac.uk> <7032B5D7-87B0-4231-AA5F-8FBB3A418E8D@oucs.ox.ac.uk> <4D2C5472.5070205@oucs.ox.ac.uk> <4D2C7781.3060803@oucs.ox.ac.uk> Message-ID: <13109D46-944F-4E0B-8EE0-210781397E6B@oucs.ox.ac.uk> On 11 Jan 2011, at 15:30, Lou Burnard wrote: > . They are not meant to be complete documents in > themselves, nor exemplary in any sense other than that of the point > being illustrated. agreed, they not are virtuous exemplars. > > Hence, I think this example is in the category of "deliberately > invalid schematick" and I would wrap it in a CDATA marked section > accordingly. Yes, this is a good example of a deliberately invalid schema tick, but I worry a lot that the CDATA route is the slippery downhill one which leads us back to the slough we have dragged ourselves from. We really do want a check that is an allowed child of
, and is not spolt and is well-formed. The CDATA method loses more than it gains. I think we need some other notation to express your ticks, to let you say "entries occur inside divs" and have that shown graphically to the reader. -- Sebastian Rahtz Information and Support Group Manager Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From lou.burnard at oucs.ox.ac.uk Tue Jan 11 10:40:16 2011 From: lou.burnard at oucs.ox.ac.uk (Lou Burnard) Date: Tue, 11 Jan 2011 15:40:16 +0000 Subject: [tei-council] invalid examples allowed in Guidelines? In-Reply-To: <4D2C2FA3.80606@oucs.ox.ac.uk> References: <4D2BC0EF.8030304@oucs.ox.ac.uk> <4D2C2FA3.80606@oucs.ox.ac.uk> Message-ID: <4D2C79E0.5000605@oucs.ox.ac.uk> On 11/01/11 10:23, James Cummings wrote: > On 11/01/11 09:44, Sebastian Rahtz wrote: >> James has an interesting counter proposal, that we should make all >> the examples entirely valid, but add a new attribute @noDisplay in the TEIX namespace. > Just to elaborate on this. The idea is that when we are missing > out elements in TEI examples we are doing so *only* for a reason > of presentation. As my previous post suggests, I think I disagree with this. It isn't just a matter of presentation: it's a matter of the intention underlying the specific example -- what it is meant to illustrate. There are situations where we want to illustrate something about an element without being specific about its content because to do so would be confusing. We want to illustrate whereabout in a document a Header can appear without repeating all the information about what a Header must contain. We want to demonstrate that a
can contain just elements and nothing else. Of course there are also times when we want to present the overall gross structure of a document, and allow the reader to unpack at will particular bits of it to reveal the wonders below, but that's a different pedagogic situation and a different approach, not really well suited to a document which has to be usable in static printed form as well as on the web. From lou.burnard at oucs.ox.ac.uk Tue Jan 11 10:47:34 2011 From: lou.burnard at oucs.ox.ac.uk (Lou Burnard) Date: Tue, 11 Jan 2011 15:47:34 +0000 Subject: [tei-council] invalid examples allowed in Guidelines? In-Reply-To: <13109D46-944F-4E0B-8EE0-210781397E6B@oucs.ox.ac.uk> References: <4D2BC0EF.8030304@oucs.ox.ac.uk> <4D2C2FA3.80606@oucs.ox.ac.uk> <7032B5D7-87B0-4231-AA5F-8FBB3A418E8D@oucs.ox.ac.uk> <4D2C5472.5070205@oucs.ox.ac.uk> <4D2C7781.3060803@oucs.ox.ac.uk> <13109D46-944F-4E0B-8EE0-210781397E6B@oucs.ox.ac.uk> Message-ID: <4D2C7B96.5030909@oucs.ox.ac.uk> On 11/01/11 15:39, Sebastian Rahtz wrote: > I worry a lot that the CDATA route is the slippery downhill one > which leads us back to the slough we have dragged ourselves from. > We really do want a check that is an allowed child of
, > and is not spolt and is well-formed. The CDATA method > loses more than it gains. well, maybe. I agree that it is a method that needs to be used very carefully certainly. > I think we need some other notation to express your ticks, to let you say > "entries occur inside divs" and have that shown graphically to the reader. I agree that we need some way of saying I don't agree that providing (but hiding) some specific valid content is the right answer. That seems just to dodge the issue. From sebastian.rahtz at oucs.ox.ac.uk Tue Jan 11 10:53:47 2011 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 11 Jan 2011 15:53:47 +0000 Subject: [tei-council] invalid examples allowed in Guidelines? In-Reply-To: <4D2C7B96.5030909@oucs.ox.ac.uk> References: <4D2BC0EF.8030304@oucs.ox.ac.uk> <4D2C2FA3.80606@oucs.ox.ac.uk> <7032B5D7-87B0-4231-AA5F-8FBB3A418E8D@oucs.ox.ac.uk> <4D2C5472.5070205@oucs.ox.ac.uk> <4D2C7781.3060803@oucs.ox.ac.uk> <13109D46-944F-4E0B-8EE0-210781397E6B@oucs.ox.ac.uk> <4D2C7B96.5030909@oucs.ox.ac.uk> Message-ID: On 11 Jan 2011, at 15:47, Lou Burnard wrote: > > I agree that we need some way of saying > we change all the content models to add | DeepMagic add at all the relevant points, and then render it as Whether you cry Eureka! at that, or scream-like-Nigel-Pargetter (http://audioboo.fm/boos/248750-the-nigel-scream-the-archers), is between you and your conscience. -- Sebastian Rahtz Information and Support Group Manager Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From laurent.romary at inria.fr Tue Jan 11 10:54:25 2011 From: laurent.romary at inria.fr (Laurent Romary) Date: Tue, 11 Jan 2011 16:54:25 +0100 Subject: [tei-council] invalid examples allowed in Guidelines? In-Reply-To: <13109D46-944F-4E0B-8EE0-210781397E6B@oucs.ox.ac.uk> References: <4D2BC0EF.8030304@oucs.ox.ac.uk> <4D2C2FA3.80606@oucs.ox.ac.uk> <7032B5D7-87B0-4231-AA5F-8FBB3A418E8D@oucs.ox.ac.uk> <4D2C5472.5070205@oucs.ox.ac.uk> <4D2C7781.3060803@oucs.ox.ac.uk> <13109D46-944F-4E0B-8EE0-210781397E6B@oucs.ox.ac.uk> Message-ID: <80FFE534-72AE-498D-9EAD-C21DB71D29E8@inria.fr> I'm on the same line as Seb there, I would definitely avoid using CDATA secitons for examples at large. It prevents any kinds of further processing (not even with a stylesheet). Le 11 janv. 11 ? 16:39, Sebastian Rahtz a ?crit : > > On 11 Jan 2011, at 15:30, Lou Burnard wrote: > >> . They are not meant to be complete documents in >> themselves, nor exemplary in any sense other than that of the point >> being illustrated. > > agreed, they not are virtuous exemplars. >> >> Hence, I think this example is in the category of "deliberately >> invalid schematick" and I would wrap it in a CDATA marked section >> accordingly. > > > Yes, this is a good example of a deliberately invalid schema tick, > but I worry a lot that the CDATA route is the slippery downhill one > which leads us back to the slough we have dragged ourselves from. > We really do want a check that is an allowed child of
, > and is not spolt and is well-formed. The CDATA method > loses more than it gains. > > I think we need some other notation to express your ticks, to let > you say > "entries occur inside divs" and have that shown graphically to the > reader. > -- > Sebastian Rahtz > Information and Support Group Manager > Oxford University Computing Services > 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 > > S?lo le pido a Dios > que el futuro no me sea indiferente > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Laurent Romary INRIA & HUB-IDSL laurent.romary at inria.fr From laurent.romary at inria.fr Tue Jan 11 10:56:26 2011 From: laurent.romary at inria.fr (Laurent Romary) Date: Tue, 11 Jan 2011 16:56:26 +0100 Subject: [tei-council] invalid examples allowed in Guidelines? In-Reply-To: <4D2C7B96.5030909@oucs.ox.ac.uk> References: <4D2BC0EF.8030304@oucs.ox.ac.uk> <4D2C2FA3.80606@oucs.ox.ac.uk> <7032B5D7-87B0-4231-AA5F-8FBB3A418E8D@oucs.ox.ac.uk> <4D2C5472.5070205@oucs.ox.ac.uk> <4D2C7781.3060803@oucs.ox.ac.uk> <13109D46-944F-4E0B-8EE0-210781397E6B@oucs.ox.ac.uk> <4D2C7B96.5030909@oucs.ox.ac.uk> Message-ID: This brings us back to my proposal that we need to say explicitly that an example (or a portion thereof) needs to be validated or nor (and whether our tools can implement this feature or not). Le 11 janv. 11 ? 16:47, Lou Burnard a ?crit : > On 11/01/11 15:39, Sebastian Rahtz wrote: >> I worry a lot that the CDATA route is the slippery downhill one >> which leads us back to the slough we have dragged ourselves from. >> We really do want a check that is an allowed child of
, >> and is not spolt and is well-formed. The CDATA method >> loses more than it gains. > > well, maybe. I agree that it is a method that needs to be used very > carefully certainly. > >> I think we need some other notation to express your ticks, to let >> you say >> "entries occur inside divs" and have that shown graphically to the >> reader. > > I agree that we need some way of saying > > I don't agree that providing (but hiding) some specific valid > content is > the right answer. That seems just to dodge the issue. > > > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Laurent Romary INRIA & HUB-IDSL laurent.romary at inria.fr From sebastian.rahtz at oucs.ox.ac.uk Tue Jan 11 10:59:30 2011 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 11 Jan 2011 15:59:30 +0000 Subject: [tei-council] invalid examples allowed in Guidelines? In-Reply-To: <80FFE534-72AE-498D-9EAD-C21DB71D29E8@inria.fr> References: <4D2BC0EF.8030304@oucs.ox.ac.uk> <4D2C2FA3.80606@oucs.ox.ac.uk> <7032B5D7-87B0-4231-AA5F-8FBB3A418E8D@oucs.ox.ac.uk> <4D2C5472.5070205@oucs.ox.ac.uk> <4D2C7781.3060803@oucs.ox.ac.uk> <13109D46-944F-4E0B-8EE0-210781397E6B@oucs.ox.ac.uk> <80FFE534-72AE-498D-9EAD-C21DB71D29E8@inria.fr> Message-ID: On 11 Jan 2011, at 15:54, Laurent Romary wrote: > I'm on the same line as Seb there, I would definitely avoid using > CDATA secitons for examples at large. It prevents any kinds of further > processing (not even with a stylesheet). I suppose Lou would be just as happy with (as opposed to "well-formed" and "valid"), which would simply allow any TEI elements in any combination. Which is half-way between CDATA and James Method. -- Sebastian Rahtz Information and Support Group Manager Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From lou.burnard at oucs.ox.ac.uk Tue Jan 11 10:59:54 2011 From: lou.burnard at oucs.ox.ac.uk (Lou Burnard) Date: Tue, 11 Jan 2011 15:59:54 +0000 Subject: [tei-council] invalid examples allowed in Guidelines? In-Reply-To: References: <4D2BC0EF.8030304@oucs.ox.ac.uk> <4D2C2FA3.80606@oucs.ox.ac.uk> <7032B5D7-87B0-4231-AA5F-8FBB3A418E8D@oucs.ox.ac.uk> <4D2C5472.5070205@oucs.ox.ac.uk> <4D2C7781.3060803@oucs.ox.ac.uk> <13109D46-944F-4E0B-8EE0-210781397E6B@oucs.ox.ac.uk> <4D2C7B96.5030909@oucs.ox.ac.uk> Message-ID: <4D2C7E7A.3020402@oucs.ox.ac.uk> On 11/01/11 15:56, Laurent Romary wrote: > This brings us back to my proposal that we need to say explicitly that > an example (or a portion thereof) needs to be validated or nor (and > whether our tools can implement this feature or not). > The trouble is, as Sebastian has now persuaded me, we actually want to be able to say "this example should be validated, but only down to this level" -- it isn't a matter of all or nothing. Oh well, as suggested earlier maybe we should take stock of the situation, and see how many problematic cases there actually are. From lou.burnard at oucs.ox.ac.uk Tue Jan 11 11:02:09 2011 From: lou.burnard at oucs.ox.ac.uk (Lou Burnard) Date: Tue, 11 Jan 2011 16:02:09 +0000 Subject: [tei-council] invalid examples allowed in Guidelines? In-Reply-To: References: <4D2BC0EF.8030304@oucs.ox.ac.uk> <4D2C2FA3.80606@oucs.ox.ac.uk> <7032B5D7-87B0-4231-AA5F-8FBB3A418E8D@oucs.ox.ac.uk> <4D2C5472.5070205@oucs.ox.ac.uk> <4D2C7781.3060803@oucs.ox.ac.uk> <13109D46-944F-4E0B-8EE0-210781397E6B@oucs.ox.ac.uk> <80FFE534-72AE-498D-9EAD-C21DB71D29E8@inria.fr> Message-ID: <4D2C7F01.6060303@oucs.ox.ac.uk> On 11/01/11 15:59, Sebastian Rahtz wrote: > > I suppose Lou would be just as happy with > > > > (as opposed to "well-formed" and "valid"), which would simply > allow any TEI elements in any combination. > that would indeed be luverly, but didn't you say it couldn't be done? From sebastian.rahtz at oucs.ox.ac.uk Tue Jan 11 11:07:47 2011 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 11 Jan 2011 16:07:47 +0000 Subject: [tei-council] invalid examples allowed in Guidelines? In-Reply-To: <4D2C7E7A.3020402@oucs.ox.ac.uk> References: <4D2BC0EF.8030304@oucs.ox.ac.uk> <4D2C2FA3.80606@oucs.ox.ac.uk> <7032B5D7-87B0-4231-AA5F-8FBB3A418E8D@oucs.ox.ac.uk> <4D2C5472.5070205@oucs.ox.ac.uk> <4D2C7781.3060803@oucs.ox.ac.uk> <13109D46-944F-4E0B-8EE0-210781397E6B@oucs.ox.ac.uk> <4D2C7B96.5030909@oucs.ox.ac.uk> <4D2C7E7A.3020402@oucs.ox.ac.uk> Message-ID: On 11 Jan 2011, at 15:59, Lou Burnard wrote: > > Oh well, as suggested earlier maybe we should take stock of the > situation, and see how many problematic cases there actually are. > yes. important thing to do is look at each case, decide whether its a tick or an example (there is a third case, by the way, which is a template), and _record_ the decision. I'd be more than happy to add an attribute to to indicate whether the intention is validity, plausibility or just well-formedness "plausible" means that the markup is fine so far as it goes but may be incomplete. -- Sebastian Rahtz Information and Support Group Manager Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From sebastian.rahtz at oucs.ox.ac.uk Tue Jan 11 11:09:32 2011 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 11 Jan 2011 16:09:32 +0000 Subject: [tei-council] invalid examples allowed in Guidelines? In-Reply-To: <4D2C7F01.6060303@oucs.ox.ac.uk> References: <4D2BC0EF.8030304@oucs.ox.ac.uk> <4D2C2FA3.80606@oucs.ox.ac.uk> <7032B5D7-87B0-4231-AA5F-8FBB3A418E8D@oucs.ox.ac.uk> <4D2C5472.5070205@oucs.ox.ac.uk> <4D2C7781.3060803@oucs.ox.ac.uk> <13109D46-944F-4E0B-8EE0-210781397E6B@oucs.ox.ac.uk> <80FFE534-72AE-498D-9EAD-C21DB71D29E8@inria.fr> <4D2C7F01.6060303@oucs.ox.ac.uk> Message-ID: <1A79A312-56EB-4B4E-808E-C8BA7D868B67@oucs.ox.ac.uk> On 11 Jan 2011, at 16:02, Lou Burnard wrote: >> (as opposed to "well-formed" and "valid"), which would simply >> allow any TEI elements in any combination. >> > > > that would indeed be luverly, but didn't you say it couldn't be done? I cannot think of a way of implementing it, no, but as a placeholder for the _intention_, it seems like a good idea (reluctant as I am to agree with Laurent ? :-} ) -- Sebastian Rahtz Information and Support Group Manager Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From sebastian.rahtz at oucs.ox.ac.uk Tue Jan 11 11:14:56 2011 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 11 Jan 2011 16:14:56 +0000 Subject: [tei-council] invalid examples allowed in Guidelines? In-Reply-To: <1A79A312-56EB-4B4E-808E-C8BA7D868B67@oucs.ox.ac.uk> References: <4D2BC0EF.8030304@oucs.ox.ac.uk> <4D2C2FA3.80606@oucs.ox.ac.uk> <7032B5D7-87B0-4231-AA5F-8FBB3A418E8D@oucs.ox.ac.uk> <4D2C5472.5070205@oucs.ox.ac.uk> <4D2C7781.3060803@oucs.ox.ac.uk> <13109D46-944F-4E0B-8EE0-210781397E6B@oucs.ox.ac.uk> <80FFE534-72AE-498D-9EAD-C21DB71D29E8@inria.fr> <4D2C7F01.6060303@oucs.ox.ac.uk> <1A79A312-56EB-4B4E-808E-C8BA7D868B67@oucs.ox.ac.uk> Message-ID: <05500C09-0A85-405D-A8A8-BAF76680B848@oucs.ox.ac.uk> I am a dumbo. The word is _feasible_, not plausible. Jing actually implements something similar, and the description there conveys what I meant: -f Checks that the document is feasibly valid. A document is feasibly valid if it could be transformed into a valid document by inserting any number of attributes and child elements anywhere in the tree. This is equivalent to transforming the schema by wrapping every data, list, element and attribute element in an optional element and then validating against the transformed schema. This option may be useful while a document is still under construction. This option also disables checking that for every IDREF there is a corresponding ID. -- Sebastian Rahtz Information and Support Group Manager Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From laurent.romary at inria.fr Tue Jan 11 11:15:27 2011 From: laurent.romary at inria.fr (Laurent Romary) Date: Tue, 11 Jan 2011 17:15:27 +0100 Subject: [tei-council] invalid examples allowed in Guidelines? In-Reply-To: References: <4D2BC0EF.8030304@oucs.ox.ac.uk> <4D2C2FA3.80606@oucs.ox.ac.uk> <7032B5D7-87B0-4231-AA5F-8FBB3A418E8D@oucs.ox.ac.uk> <4D2C5472.5070205@oucs.ox.ac.uk> <4D2C7781.3060803@oucs.ox.ac.uk> <13109D46-944F-4E0B-8EE0-210781397E6B@oucs.ox.ac.uk> <4D2C7B96.5030909@oucs.ox.ac.uk> Message-ID: <59BF57D9-9771-45B3-B87B-6CF6BB326415@inria.fr> Did I mention I would this as well... Le 11 janv. 11 ? 16:53, Sebastian Rahtz a ?crit : > > On 11 Jan 2011, at 15:47, Lou Burnard wrote: > >> >> I agree that we need some way of saying >> > > we change all the content models to add > > | DeepMagic > > add > > > > at all the relevant points, and then render it as > > > > Whether you cry Eureka! at that, or scream-like-Nigel-Pargetter > (http://audioboo.fm/boos/248750-the-nigel-scream-the-archers), > is between you and your conscience. > -- > Sebastian Rahtz > Information and Support Group Manager > Oxford University Computing Services > 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 > > S?lo le pido a Dios > que el futuro no me sea indiferente > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Laurent Romary INRIA & HUB-IDSL laurent.romary at inria.fr From James.Cummings at oucs.ox.ac.uk Tue Jan 11 11:20:05 2011 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Tue, 11 Jan 2011 16:20:05 +0000 Subject: [tei-council] invalid examples allowed in Guidelines? In-Reply-To: <4D2C79E0.5000605@oucs.ox.ac.uk> References: <4D2BC0EF.8030304@oucs.ox.ac.uk> <4D2C2FA3.80606@oucs.ox.ac.uk> <4D2C79E0.5000605@oucs.ox.ac.uk> Message-ID: <4D2C8335.9060202@oucs.ox.ac.uk> On 11/01/11 15:40, Lou Burnard wrote: > On 11/01/11 10:23, James Cummings wrote: >> On 11/01/11 09:44, Sebastian Rahtz wrote: >>> James has an interesting counter proposal, that we should make all >>> the examples entirely valid, but add a new attribute @noDisplay in the TEIX namespace. >> Just to elaborate on this. The idea is that when we are missing >> out elements in TEI examples we are doing so *only* for a reason >> of presentation. > > As my previous post suggests, I think I disagree with this. It isn't > just a matter of presentation: it's a matter of the intention underlying > the specific example -- what it is meant to illustrate. There are > situations where we want to illustrate something about an element > without being specific about its content because to do so would be > confusing. We want to illustrate whereabout in a document a Header can > appear without repeating all the information about what a Header must > contain. We want to demonstrate that a
can contain just > elements and nothing else. Sure... here I was using 'presentation' in a way to include 'pedagogical reasons for why we only want to show some of the example'. As a counterpoint to 'validation' in my head I guess. I in no way suggest that it isn't a good thing to be able to not include otherwise required bits of the TEI in an example for exactly the reasons you suggest. The presentation of fully valid examples would be confusing for the reader, thus we want to present fragmentary examples for completely clear and good pedagogic reasons. The presentation of these is ...a matter of presentation, I would argue, and has very little to do with the validity or not of the example. Separately we think, I believe, having entirely valid examples in general to be $AGoodThing and so need some mechanism to allow us to have fully valid examples but hide some bits of those whose presentation might be confusing to the user and undermine the lesson we are trying to teach. I don't think at the core of things we're disagreeing, except perhaps on implementation. My suggestion is only a straw man really. If it is just that entry can be used inside div then it is pedagogically good to alert the reader (through some presentational means) to that this isn't a fully complete entry element. One way to do that is to have the underlying example be valid, but present them with an XML comment saying that some things have been hidden in this rendering to allow them to just concentrate on the important bit. > Of course there are also times when we want to present the overall gross > structure of a document, and allow the reader to unpack at will > particular bits of it to reveal the wonders below, but that's a > different pedagogic situation and a different approach, not really well > suited to a document which has to be usable in static printed form as > well as on the web. Yes, teiHeader is a good example of this. People would *LOVE* for pedagogical reasons exactly the fully complete and specified header that they could drill down into, but would hate this in a printed version. But replacing the drill-down-into'able sections with a comment saying or whatever, seems sensible to me in print versions. -James -- Dr James Cummings, Research Technologies Service OUCS, University of Oxford From laurent.romary at inria.fr Tue Jan 11 11:20:10 2011 From: laurent.romary at inria.fr (Laurent Romary) Date: Tue, 11 Jan 2011 17:20:10 +0100 Subject: [tei-council] invalid examples allowed in Guidelines? In-Reply-To: <05500C09-0A85-405D-A8A8-BAF76680B848@oucs.ox.ac.uk> References: <4D2BC0EF.8030304@oucs.ox.ac.uk> <4D2C2FA3.80606@oucs.ox.ac.uk> <7032B5D7-87B0-4231-AA5F-8FBB3A418E8D@oucs.ox.ac.uk> <4D2C5472.5070205@oucs.ox.ac.uk> <4D2C7781.3060803@oucs.ox.ac.uk> <13109D46-944F-4E0B-8EE0-210781397E6B@oucs.ox.ac.uk> <80FFE534-72AE-498D-9EAD-C21DB71D29E8@inria.fr> <4D2C7F01.6060303@oucs.ox.ac.uk> <1A79A312-56EB-4B4E-808E-C8BA7D868B67@oucs.ox.ac.uk> <05500C09-0A85-405D-A8A8-BAF76680B848@oucs.ox.ac.uk> Message-ID: <63989D75-A1D8-420C-B11F-B37E8AD56B34@inria.fr> Very good. Wait until I file the ticket, then :-} Le 11 janv. 11 ? 17:14, Sebastian Rahtz a ?crit : > I am a dumbo. The word is _feasible_, not plausible. > > Jing actually implements something similar, and the > description there conveys what I meant: > > -f > Checks that the document is feasibly valid. A document is feasibly > valid if it could be transformed into a valid document by inserting > any number of attributes and child elements anywhere in the tree. > This is equivalent to transforming the schema by wrapping every > data, list, element and attribute element in an optional element and > then validating against the transformed schema. This option may be > useful while a document is still under construction. This option > also disables checking that for every IDREF there is a corresponding > ID. > > > -- > Sebastian Rahtz > Information and Support Group Manager > Oxford University Computing Services > 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 > > S?lo le pido a Dios > que el futuro no me sea indiferente > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council Laurent Romary INRIA & HUB-IDSL laurent.romary at inria.fr From sebastian.rahtz at oucs.ox.ac.uk Tue Jan 11 11:28:43 2011 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 11 Jan 2011 16:28:43 +0000 Subject: [tei-council] invalid examples allowed in Guidelines? In-Reply-To: <63989D75-A1D8-420C-B11F-B37E8AD56B34@inria.fr> References: <4D2BC0EF.8030304@oucs.ox.ac.uk> <4D2C2FA3.80606@oucs.ox.ac.uk> <7032B5D7-87B0-4231-AA5F-8FBB3A418E8D@oucs.ox.ac.uk> <4D2C5472.5070205@oucs.ox.ac.uk> <4D2C7781.3060803@oucs.ox.ac.uk> <13109D46-944F-4E0B-8EE0-210781397E6B@oucs.ox.ac.uk> <80FFE534-72AE-498D-9EAD-C21DB71D29E8@inria.fr> <4D2C7F01.6060303@oucs.ox.ac.uk> <1A79A312-56EB-4B4E-808E-C8BA7D868B67@oucs.ox.ac.uk> <05500C09-0A85-405D-A8A8-BAF76680B848@oucs.ox.ac.uk> <63989D75-A1D8-420C-B11F-B37E8AD56B34@inria.fr> Message-ID: On 11 Jan 2011, at 16:20, Laurent Romary wrote: > Very good. Wait until I file the ticket, then :-} > I am not implying that this gives us an implementation, by the way; it does confirm the concept, however, and shows how we could solve the problem in the future. to see how this works in practice, consider this extracted example: If I do a normal validation, I am told /home/rahtz/TEI/Sourceforge/trunk/P5/foo.xml:2:41: error: element "teiHeader" incomplete; missing required element "fileDesc" /home/rahtz/TEI/Sourceforge/trunk/P5/foo.xml:3:12: error: element "front" not allowed here; expected element "facsimile", "fsdDecl" or "text" /home/rahtz/TEI/Sourceforge/trunk/P5/foo.xml:6:11: error: element "body" not allowed here; expected element "facsimile", "fsdDecl" or "text" /home/rahtz/TEI/Sourceforge/trunk/P5/foo.xml:8:12: error: element "body" incomplete; expected element "ab", "addSpan", "alt", "altGrp", "anchor", "argument", "bibl", "biblFull", "biblStruct", "byline", "camera", "caption", "castList", "cb", "certainty", "cit", "classRef", "classSpec", "damageSpan", "dateline", "delSpan", "desc", "div", "div1", "divGen", "docAuthor", "docDate", "eTree", "eg", "egXML", "elementRef", "elementSpec", "entry", "entryFree", "epigraph", "fLib", "figure", "floatingText", "forest", "forestGrp", "fs", "fvLib", "fw", "gap", "gb", "graph", "head", "incident", "index", "interp", "interpGrp", "join", "joinGrp", "kinesic", "l", "label", "lb", "lg", "link", "linkGrp", "list", "listBibl", "listEvent", "listNym", "listOrg", "listPerson", "listPlace", "listRef", "listWit", "macroRef", "macroSpec", "meeting", "milestone", "moduleRef", "moduleSpec", "move", "msDesc", "note", "opener", "p", "pause", "pb", "precision", "q", "quote", "respons", "said", "salute", "schemaSpec", "shift", "sound", "sp", "space", "span", "spanGrp", "specGrp", "specGrpRef", "stage", "superEntry", "table", "tech", "timeline", "tree", "u", "view", "vocal", "witDetail" or "writing" /home/rahtz/TEI/Sourceforge/trunk/P5/foo.xml:9:11: error: element "back" not allowed here; expected element "facsimile", "fsdDecl" or "text" /home/rahtz/TEI/Sourceforge/trunk/P5/foo.xml:12:8: error: element "TEI" incomplete; expected element "facsimile", "fsdDecl" or "text" but with jing's -f option, I get just rahtz at rahtz:~/TEI/Sourceforge/trunk/P5$ jing -f p5odds-examples.rng foo.xml /home/rahtz/TEI/Sourceforge/trunk/P5/foo.xml:3:12: error: element "front" not allowed here; expected the element end-tag or element "facsimile", "fsdDecl" or "text" /home/rahtz/TEI/Sourceforge/trunk/P5/foo.xml:6:11: error: element "body" not allowed here; expected the element end-tag or element "facsimile", "fsdDecl" or "text" /home/rahtz/TEI/Sourceforge/trunk/P5/foo.xml:9:11: error: element "back" not allowed here; expected the element end-tag or element "facsimile", "fsdDecl" or "text" ie it detects the missing but goes no further. This is exactly the result we want. -- Sebastian Rahtz Information and Support Group Manager Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From lou.burnard at retired.ox.ac.uk Sat Jan 15 12:54:35 2011 From: lou.burnard at retired.ox.ac.uk (Lou Burnard) Date: Sat, 15 Jan 2011 17:54:35 +0000 Subject: [tei-council] Hyphenation discussion Message-ID: <4D31DF5B.2030409@retired.ox.ac.uk>
Hyphenation

Hyphenation as a phenomenon is generally of most concern when producing formatted text for display in print or on screen: different languages and systems have developed quite sophisticated sets of rules about where hyphens may be introduced and for what reason. These generally do not concern the text encoder, since they belong to the domain of formatting and will generally be handled by the rendition software in use. In this section, we discuss issues arising from the appearance of hyphens in pre-existing formatted texts which are being re-encoded for analysis or other processing. Unicode distinguishes three visually similar characters for the hyphen, although it also retains the undifferentiated hyphen-minus (U+002D) for compatibility reasons. The hard hyphen (U+2010) is distinguished from the minus sign (U+2212) which should be used only in mathematical expressions, and also from the soft hyphen (U+00AD) which may appear in born digital documents to indicate places where it is acceptable to insert a hyphen when the document is formatted.

Historically, the hard hyphen has been used in printed or manuscript documents for two distinct purposes. In many languages, it is used between words to show that they function as a single syntactic or lexical unit. For example, in French, est-ce que; in English body-snatcher, tea-party etc. It may also have an important role in disambiguation (for example, by distinguishing say a man-eating fish from a man eating fish). Such usages, although possibly problematic when a linguistic analysis is undertaken, are not generally of concern to text encoders: the hyphen character is usually retained in the text, because it may be regarded as part of the way a compound or other lexical item is spelled. Deciding whether a compound is to be decomposed into its constituent parts, and if so how, is a different question, involving consideration of many other phenomena in addition to the simple presence of a hyphen.

When it appears at the end of a printed or written line however, the hard hyphen generally indicates that ? contrary to what might be expected ? a word is not yet complete, but continues on the next line (or over the next page or column or other boundary). The hyphen character is not, in this case, part of the word, but just a signal that the word continues over the break. Unfortunately, few languages distinguish these two cases visually, which necessarily poses a problem for text encoders. Suppose, for example, that we wish to investigate a diachronic English corpus for occurrences of "tea-pot" and "teapot", to find evidence for the point at which this compound becomes lexicalized. Any case where the word is hyphenated across a linebreak, like this: is entirely ambigous: there is simply no way of deciding which of the two spellings was intended.

As elsewhere, therefore, the encoder has a range of choices: They may decide simply to remove any end-of-line hyphenation from the encoded text, on the grounds that its presence is purely a secondary matter of formatting. This will obviously apply also if line endings are themselves regarded as unimportant. Alternatively, they may decide to record the presence of the hyphen, perhaps on the grounds that it provides useful morphological information; perhaps in order to retain information about the visual appearance of the original source. In either case, they need to decide whether to record it explicitly, by including an appropriate punctuation character in the encoding, or implicitly by supplying an appropriate attribute value on the lb element used to record the fact of the line division. A similar range of possibilities applies equally to the representation of other common punctuation marks, notably quotation marks, as discussed in .

The text data of which XML documents are composed is decomposable into smaller units here called orthographic tokens, even if those units are not explicitly indicated by the XML markup. The ambiguity of the end-of-line hyphen also causes problems in the way a processor identifies such tokens in the absence of explicit markup. If token boundaries are not explicitly marked (for example using the seg or w elements) in most languages a processor will rely on character class information to determine where they are to be found: some punctuation characters are considered to be word-breaking, while others are not. In XML, the newline character in text data is a kind of white space, and is therefore word breaking. XML mixed-content rules are notoriously confusing on this issue. However, it is generally unsafe to assume that whitespace adjacent to markup tags will always be preserved, and it is decidedly unsafe to assume that markup tags themselves are equivalent to whitespace.

The lb, pb, and cb elements are notable exceptions to this general rule, since their function is precisely to represent (or replace) line, page, or column breaks, which, as noted above, are generally considered to be equivalent to white space. These elements provide a more reliable way of preserving the lineation, pagination, etc of a source document, since the encoder should not assume that (untagged) line breaks etc. in an XML source file will necessarily be preserved.

In cases where the lb element does not in fact correspond with a token boundary, the type attribute should be given a special value to indicate that this is a "non-breaking" line break. The values proposed by these Guidelines are noBreak or (for compatibility with existing recommendations) inWord. A value mayBreak is also available, for cases where the encoder does not wish (or is unable) to determine whether the orthographic token concerned is broken by the line ending or not.

As a final complication, it should be noted that in some languages, particularly German and Dutch, the spelling of a word may be altered in the presence of end of line hyphenation. For example, in Dutch, the word opaatje (granddad), occurring at the end of a line may be hyphenated as opa-tje, with a single letter a. An encoder wishing to preserve the original form of this orthographic token in a printed text while at the same time facilitating its recognition as the word opaatje will therefore need to rely on a more sophisticated process than simply removing the hyphen. This is however essentially the same as any other form of normalization accompanying the recognition of variations in spelling or morphology: as such it may be encoded using the choice element discussed in , or the more sophisticated mechanisms for linguistic analysis discussed in chapter .

From kevin.s.hawkins at ultraslavonic.info Sun Jan 16 12:21:34 2011 From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins) Date: Sun, 16 Jan 2011 12:21:34 -0500 Subject: [tei-council] Hyphenation discussion In-Reply-To: <4D31DF5B.2030409@retired.ox.ac.uk> References: <4D31DF5B.2030409@retired.ox.ac.uk> Message-ID: <4D33291E.6010706@ultraslavonic.info> This is excellent. A few notes are madein red below. I like your plan of action but also would very much like to see the note in the definition of lb clarified regarding use of inWord, noBreak, and mayBreak. Could this note also be added to the definitions of and ? I also notice that you wrote "noBreak" below, but the current note in the definition of lb says "nobreak". Do we need to keep "nobreak" for backwards-compatibility? ---Kevin On 1/15/2011 12:54 PM, Lou Burnard wrote: > > >
Hyphenation > >

Hyphenation as a phenomenon is generally of most concern when > producing formatted text for display in print or on screen: different > languages and systems have developed quite sophisticated sets of rules > about where hyphens may be introduced and for what reason. These > generally do not concern the text encoder, since they belong to the > domain of formatting and will generally be handled by the rendition > software in use. In this section, we discuss issues arising from the > appearance of hyphens in pre-existing formatted texts which are being > re-encoded for analysis or other processing. Unicode distinguishes > three visually similar characters for the hyphen, although it also > retains the undifferentiated hyphen-minus (U+002D) for compatibility > reasons. The hard hyphen (U+2010) is distinguished from the minus sign > (U+2212) which should be used only in mathematical expressions, and > also from the soft hyphen (U+00AD) which may appear inborn > digital documents to indicate places where it is acceptable > to insert a hyphen when the document is formatted.

> >

Historically, the hard hyphen has been used in printed or > manuscript documents for two distinct purposes. In many languages, it > is used between words to show that they function as a single syntactic > or lexical unit. For example, in French,est-ce > que; in Englishbody-snatcher, > tea-party etc. It may also have an important > role in disambiguation (for example, by distinguishing say a > man-eating fish from aman eating > fish). Such usages, although possibly problematic when a > linguistic analysis is undertaken, are not generally of concern to > text encoders: the hyphen character is usually retained in the text, > because it may be regarded as part of the way a compound or other > lexical item is spelled. Deciding whether a compound is to be > decomposed into its constituent parts, and if so how, is a different > question, involving consideration of many other phenomena in addition > to the simple presence of a hyphen.

> >

When it appears at the end of a printed or written line however, > the hard hyphen generally indicates that --- contrary to what might be > expected --- a word is not yet complete, but continues on the next line > (or over the next page or column or other boundary). The hyphen > character is not, in this case, part of the word, but just a signal > that the word continues over the break. Unfortunately, few languages > distinguish these two cases visually, which necessarily poses a > problem for text encoders. Suppose, for example, that we wish to > investigate a diachronic English corpus for occurrences of "tea-pot" > and "teapot", to find evidence for the point at which this compound > becomes lexicalized. Any case where the word is hyphenated across a > linebreak, like this: pot]]> is entirely ambigous: there is simply no way of deciding > which of the two spellings was intended. >

> >

As elsewhere, therefore, the encoder has a range of choices: > > They > may decide simply to remove any end-of-line hyphenation from the > encoded text, on the grounds that its presence is purely a secondary > matter of formatting. This will obviously apply also if line endings > are themselves regarded as unimportant. > Alternatively, they may decide to record the presence of the > hyphen, perhaps on the grounds that it provides useful morphological > information; perhaps in order to retain information about the visual > appearance of the original source. In either case, they need to decide > whether to record it explicitly, by including an appropriate punctuation > character in the encoding[Can we be more explicit than "in the encoding"? Perhaps "in the text data"?], or implicitly by supplying an appropriate > attribute value on thelb element used to record the fact of > the line division.Use of thetype attribute to provide morphological information is discussed below, but the rend attribute may be used instead if visual appearance of the hyphen is more important. > > A similar range of possibilities applies equally to the representation of > other common punctuation marks, notably quotation marks, as discussed > in.

> >

Thetext data of which XML documents are > composed is decomposable into smaller units, here called > orthographic tokens, even if those units are not > explicitly indicated by the XML markup. The ambiguity of the > end-of-line hyphen also causes problems in the way a processor > identifies such tokens in the absence of explicit markup. If token > boundaries are not explicitly marked (for example using the > seg orw elements), in formost languages a processor > will rely on character class information to determine where they are > to be found: some punctuation characters are considered to be > word-breaking, while others are not. In XML, the newline character in > text data is a kind of white space, and is therefore word > breaking. XML mixed-content rules are notoriously confusing on this > issue.[The previous sentence feels misplaced, and it's not clear which issue you're discussing (whether the newline character is word-breaking?)] However, it is generally unsafe to assume that whitespace > adjacent to markup tags will always be preserved, and it is decidedly > unsafe to assume that markup tags themselves are equivalent to > whitespace.

> >

Thelb,pb, andcb elements are notable > exceptions to this general rule, since their function is precisely to > represent (or replace) line, page, or column breaks, which, as noted > above, are generally considered to be equivalent to white space. These > elements provide a more reliable way of preserving the lineation, > pagination, etc of a source document, since the encoder should not > assume that (untagged) line breaks etc. in an XML source file will > necessarily be preserved.

> >

In cases where thelb element does not in fact correspond > with a token boundary, thetype attribute should be given a > special value to indicate that this is a "non-breaking" line > break. The values proposed by these Guidelines arenoBreak > or (for compatibility with existing recommendations) > inWord. A valuemayBreak is also available, for > cases where the encoder does not wish (or is unable) to determine > whether the orthographic token concerned is broken by the line ending > or not.

> >

As a final complication, it should be noted that in some languages, > particularly German and Dutch, the spelling of a word may be altered > in the presence of end of line hyphenation. For example, in Dutch, the > wordopaatje (granddad), > occurring at the end of a line may be hyphenated as > opa-tje, with a single letter a. An encoder > wishing to preserve the original form of this orthographic token in a > printed text while at the same time facilitating its recognition as > the wordopaatje will therefore need to rely on > a more sophisticated process than simply removing the hyphen. This is > however essentially the same as any other form of normalization > accompanying the recognition of variations in spelling or morphology: > as such it may be encoded using thechoice element discussed > in, or the more sophisticated mechanisms for > linguistic analysis discussed in chapter. >

>
> > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council From sebastian.rahtz at oucs.ox.ac.uk Sun Jan 16 12:37:18 2011 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Sun, 16 Jan 2011 17:37:18 +0000 Subject: [tei-council] Hyphenation discussion In-Reply-To: <4D31DF5B.2030409@retired.ox.ac.uk> References: <4D31DF5B.2030409@retired.ox.ac.uk> Message-ID: I'm broadly in favour, but some nitpicks below On 15 Jan 2011, at 17:54, Lou Burnard wrote: > re-encoded for analysis or other processing. Unicode distinguishes > three visually similar characters for the hyphen, although it also > retains the undifferentiated hyphen-minus (U+002D) for compatibility > reasons. The hard hyphen (U+2010) is distinguished from the minus sign > (U+2212) which should be used only in mathematical expressions, and > also from the soft hyphen (U+00AD) which may appear in born > digital documents to indicate places where it is acceptable > to insert a hyphen when the document is formatted.

this seems misleading to me. it implies a minus is a sort of hyphen I'd say "Unicode distinguishes four characters visually similar to the hyphen, including the undifferentiated hyphen-minus (U+002D) for compatibility reasons. The hard hyphen (U+2010) is distinguished from the minus sign (U+2212) which is for use in mathematical expressions, and also from the soft hyphen (U+00AD) which may appear in born digital documents to indicate places where it is acceptable to insert a hyphen when the document is formatted.

> >

In cases where the lb element does not in fact correspond > with a token boundary, the type attribute should be given a > special value to indicate that this is a "non-breaking" line ^should^may^ > break. The values proposed by these Guidelines are noBreak > or (forcompatibility with existing recommendations) > inWord. A value mayBreak is also available, I find the idea of "compatibility with existing recommendations" pretty weird. Either it is the recommendation or it is not. I'd say "The value noBreak is recommended (this corresponds to older recommendation of inWord). A value mayBreak is appropriate for cases where the encoder does not wish (or is unable) to determine whether the orthographic token concerned is broken by the line ending or not." -- Sebastian Rahtz Information and Support Group Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From lou.burnard at oucs.ox.ac.uk Sun Jan 16 16:24:58 2011 From: lou.burnard at oucs.ox.ac.uk (Lou Burnard) Date: Sun, 16 Jan 2011 21:24:58 +0000 Subject: [tei-council] Hyphenation discussion In-Reply-To: <4D33291E.6010706@ultraslavonic.info> References: <4D31DF5B.2030409@retired.ox.ac.uk> <4D33291E.6010706@ultraslavonic.info> Message-ID: <4D33622A.4050303@oucs.ox.ac.uk> On 16/01/11 17:21, Kevin Hawkins wrote: > This is excellent. Thanks! > A few notes are madein red below. Sadly, my email reader doesnt do red. > I like your plan of action but also would very much like to see the note > in the definition of lb clarified regarding use of inWord, noBreak, and > mayBreak. Could this note also be added to the definitions of and > ? > yes, as I said below, I will update the definitions for all these elements once we are in agreement with the proposals herein. >> whether to record it explicitly, by including an appropriate punctuation >> character in the encoding[Can we be more explicit than "in the encoding"? Perhaps "in the text data"?] OK >> breaking. XML mixed-content rules are notoriously confusing on this >> issue.[The previous sentence feels misplaced, and it's not clear which issue you're discussing (whether the newline character is word-breaking?)] maybe the term "mixed content" needs glossing. From lou.burnard at oucs.ox.ac.uk Sun Jan 16 16:26:38 2011 From: lou.burnard at oucs.ox.ac.uk (Lou Burnard) Date: Sun, 16 Jan 2011 21:26:38 +0000 Subject: [tei-council] Hyphenation discussion In-Reply-To: References: <4D31DF5B.2030409@retired.ox.ac.uk> Message-ID: <4D33628E.7000102@oucs.ox.ac.uk> Many thanks for helpful improvements. Now standing by for input from other council members. Gabby, what's your take on the proposed values for @type? On 16/01/11 17:37, Sebastian Rahtz wrote: > I'm broadly in favour, but some nitpicks below > From kevin.s.hawkins at ultraslavonic.info Sun Jan 16 16:58:07 2011 From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins) Date: Sun, 16 Jan 2011 16:58:07 -0500 Subject: [tei-council] Hyphenation discussion In-Reply-To: <4D33622A.4050303@oucs.ox.ac.uk> References: <4D31DF5B.2030409@retired.ox.ac.uk> <4D33291E.6010706@ultraslavonic.info> <4D33622A.4050303@oucs.ox.ac.uk> Message-ID: <4D3369EF.1090602@ultraslavonic.info> On 1/16/2011 4:24 PM, Lou Burnard wrote: >> A few notes are madein red below. > > Sadly, my email reader doesnt do red. See attached. I agree with all of Sebastian's revisions as well! -------------- next part -------------- A non-text attachment was scrubbed... Name: hyphenation_for_lou.pdf Type: application/pdf Size: 141427 bytes Desc: not available Url : http://lists.village.Virginia.EDU/pipermail/tei-council/attachments/20110116/c8ba1ab1/attachment.pdf From bansp at o2.pl Sun Jan 16 17:52:02 2011 From: bansp at o2.pl (=?UTF-8?B?UGlvdHIgQmHFhHNraQ==?=) Date: Sun, 16 Jan 2011 23:52:02 +0100 Subject: [tei-council] Hyphenation discussion In-Reply-To: <4D31DF5B.2030409@retired.ox.ac.uk> References: <4D31DF5B.2030409@retired.ox.ac.uk> Message-ID: <4D337692.4030201@o2.pl> Hello All, It's nice to be here, and it's an privilege to be part of the Council :-) I've had a very rough end of the year followed by more-or-less just as rough beginning, and this is why I speak up only now and, let me admit, without having gone through all the previous hyphenation discussions. I'll limit myself to short remarks: * it's good to see this going into the Guidelines, thank you, Lou; * p[3]: s/ambigous/ambiguous * p[3]: > Suppose, for example, that we wish to > investigate a diachronic English corpus for occurrences of "tea-pot" > and "teapot", to find evidence for the point at which this compound > becomes lexicalized. A nitpick: maybe more directly and without explicit reference to lexicalisation: "to find the point at which this compound begins to be written as _tea-pot_ or _teapot_" -- to leave the linguistic interpretation aside. Being spelt with a hyphen is not a necessary condition for being lexicalised (and it's not sufficient either). * my next issue is with "mayBreak" and please ignore this if this has already come up, as I imagine it might have: I feel a bit uneasy about encoding something that looks like a candidate for @cert *as sub-lexical content of an attribute value* (namely "mayBreak" as contrasted with "noBreak" -- of course you can treat them as atomic, but still if you define their 'atomic' meanings, it seems unavoidable to say that "mayBreak" essentially means "noBreak" with low certainty). I realise that possibly, "mayBreak" is a single stone to kill both interpretive ("...encoder ... is unable) to determine") and creative ("encoder does not wish ... to determine") aspects of this issue, but I'm not sure (and neither am I sure if I'd like to have a single stone for such cases). * lastly, the "opaatje" case -- a great example, also because it seems to clearly present the core of the issue: "here's the lemma, and here's the physical, contextual rendering; choose the one you want". If this is correct, then the strategy becomes shorthand for something like lemma rendered_form_with_lb_when_it's_easy_to_recover_the_lemma -- so maybe it's worth presenting as such. Once again -- I will try to go through the earlier hyphenation thread soon but now I had a choice between possibly flogging a dead horse (the "mayBreak" issue) or not posting, so I'm counting on your patience ;-)). Best, Piotr On 2011-01-15 18:54, Lou Burnard wrote: > > >

Hyphenation > >

Hyphenation as a phenomenon is generally of most concern when > producing formatted text for display in print or on screen: different > languages and systems have developed quite sophisticated sets of rules > about where hyphens may be introduced and for what reason. These > generally do not concern the text encoder, since they belong to the > domain of formatting and will generally be handled by the rendition > software in use. In this section, we discuss issues arising from the > appearance of hyphens in pre-existing formatted texts which are being > re-encoded for analysis or other processing. Unicode distinguishes > three visually similar characters for the hyphen, although it also > retains the undifferentiated hyphen-minus (U+002D) for compatibility > reasons. The hard hyphen (U+2010) is distinguished from the minus sign > (U+2212) which should be used only in mathematical expressions, and > also from the soft hyphen (U+00AD) which may appear in born > digital documents to indicate places where it is acceptable > to insert a hyphen when the document is formatted.

> >

Historically, the hard hyphen has been used in printed or > manuscript documents for two distinct purposes. In many languages, it > is used between words to show that they function as a single syntactic > or lexical unit. For example, in French, est-ce > que; in English body-snatcher, > tea-party etc. It may also have an important > role in disambiguation (for example, by distinguishing say a > man-eating fish from a man eating > fish). Such usages, although possibly problematic when a > linguistic analysis is undertaken, are not generally of concern to > text encoders: the hyphen character is usually retained in the text, > because it may be regarded as part of the way a compound or other > lexical item is spelled. Deciding whether a compound is to be > decomposed into its constituent parts, and if so how, is a different > question, involving consideration of many other phenomena in addition > to the simple presence of a hyphen.

> >

When it appears at the end of a printed or written line however, > the hard hyphen generally indicates that ? contrary to what might be > expected ? a word is not yet complete, but continues on the next line > (or over the next page or column or other boundary). The hyphen > character is not, in this case, part of the word, but just a signal > that the word continues over the break. Unfortunately, few languages > distinguish these two cases visually, which necessarily poses a > problem for text encoders. Suppose, for example, that we wish to > investigate a diachronic English corpus for occurrences of "tea-pot" > and "teapot", to find evidence for the point at which this compound > becomes lexicalized. Any case where the word is hyphenated across a > linebreak, like this: pot]]> is entirely ambigous: there is simply no way of deciding > which of the two spellings was intended. >

> >

As elsewhere, therefore, the encoder has a range of choices: > > They > may decide simply to remove any end-of-line hyphenation from the > encoded text, on the grounds that its presence is purely a secondary > matter of formatting. This will obviously apply also if line endings > are themselves regarded as unimportant. > Alternatively, they may decide to record the presence of the > hyphen, perhaps on the grounds that it provides useful morphological > information; perhaps in order to retain information about the visual > appearance of the original source. In either case, they need to decide > whether to record it explicitly, by including an appropriate punctuation > character in the encoding, or implicitly by supplying an appropriate > attribute value on the lb element used to record the fact of > the line division. > > A similar range of possibilities applies equally to the representation of > other common punctuation marks, notably quotation marks, as discussed > in .

> >

The text data of which XML documents are > composed is decomposable into smaller units here called > orthographic tokens, even if those units are not > explicitly indicated by the XML markup. The ambiguity of the > end-of-line hyphen also causes problems in the way a processor > identifies such tokens in the absence of explicit markup. If token > boundaries are not explicitly marked (for example using the > seg or w elements) in most languages a processor > will rely on character class information to determine where they are > to be found: some punctuation characters are considered to be > word-breaking, while others are not. In XML, the newline character in > text data is a kind of white space, and is therefore word > breaking. XML mixed-content rules are notoriously confusing on this > issue. However, it is generally unsafe to assume that whitespace > adjacent to markup tags will always be preserved, and it is decidedly > unsafe to assume that markup tags themselves are equivalent to > whitespace.

> >

The lb, pb, and cb elements are notable > exceptions to this general rule, since their function is precisely to > represent (or replace) line, page, or column breaks, which, as noted > above, are generally considered to be equivalent to white space. These > elements provide a more reliable way of preserving the lineation, > pagination, etc of a source document, since the encoder should not > assume that (untagged) line breaks etc. in an XML source file will > necessarily be preserved.

> >

In cases where the lb element does not in fact correspond > with a token boundary, the type attribute should be given a > special value to indicate that this is a "non-breaking" line > break. The values proposed by these Guidelines are noBreak > or (for compatibility with existing recommendations) > inWord. A value mayBreak is also available, for > cases where the encoder does not wish (or is unable) to determine > whether the orthographic token concerned is broken by the line ending > or not.

> >

As a final complication, it should be noted that in some languages, > particularly German and Dutch, the spelling of a word may be altered > in the presence of end of line hyphenation. For example, in Dutch, the > word opaatje (granddad), > occurring at the end of a line may be hyphenated as > opa-tje, with a single letter a. An encoder > wishing to preserve the original form of this orthographic token in a > printed text while at the same time facilitating its recognition as > the word opaatje will therefore need to rely on > a more sophisticated process than simply removing the hyphen. This is > however essentially the same as any other form of normalization > accompanying the recognition of variations in spelling or morphology: > as such it may be encoded using the choice element discussed > in , or the more sophisticated mechanisms for > linguistic analysis discussed in chapter . >

>
> > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > From gabriel.bodard at kcl.ac.uk Mon Jan 17 06:47:32 2011 From: gabriel.bodard at kcl.ac.uk (Gabriel Bodard) Date: Mon, 17 Jan 2011 11:47:32 +0000 Subject: [tei-council] Hyphenation discussion In-Reply-To: <4D33628E.7000102@oucs.ox.ac.uk> References: <4D31DF5B.2030409@retired.ox.ac.uk> <4D33628E.7000102@oucs.ox.ac.uk> Message-ID: <4D342C54.8000802@kcl.ac.uk> On the whole I'm agnostic about the values used in this case, so long as they're unambiguous (which they seem to be). Wearing my EpiDoc hat, I am concerned that we (EpiDoc) follow as closely as possible the canonical TEI recommendation, which is precisely why we recently changed our recommended usage from "worddiv" to Lou's preferred "inWord". It's a little saddening to see this now being preserved only for backward compatibility with "existing recommendations". :-( But if "noBreak" and "mayBreak" are more clear, and mirror nicely, then so be it (and, with Sebastian, I would sooner have one recommendation than two, even if it means persuading EpiDoc to change again). Certainly I don't think "maybeInWord" would be attractive. But perhaps then, as Piotr points out, the ambiguity of "mayBreak" demands more values; or rather, I would suggests, it suggests we should use to specify how and for what reason we are uncertain about the value of "noBreak" (which then might as well be "inWord"). Another question: preserving the nice mirroring or "noBreak" and "mayBreak", what value would we give for the positive side of this coin? "doesBreak"? (Serious question: while this would normally be the default value, I can certainly imagine cases where I'd want to specify the value of all linebreaks in a text, for example where lineation is completely unrelated to tokenization--as on coins, seals, stoichedon inscriptions, etc.) G On 16/01/2011 21:26, Lou Burnard wrote: > Many thanks for helpful improvements. > > Now standing by for input from other council members. > > Gabby, what's your take on the proposed values for @type? > > On 16/01/11 17:37, Sebastian Rahtz wrote: >> I'm broadly in favour, but some nitpicks below >> > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council -- Dr Gabriel BODARD (Research Associate in Digital Epigraphy) Centre for Computing in the Humanities King's College London 26-29 Drury Lane London WC2B 5RL Email: gabriel.bodard at kcl.ac.uk Tel: +44 (0)20 7848 1388 Fax: +44 (0)20 7848 2980 http://www.digitalclassicist.org/ http://www.currentepigraphy.org/ From gabriel.bodard at kcl.ac.uk Mon Jan 17 09:38:23 2011 From: gabriel.bodard at kcl.ac.uk (Gabriel Bodard) Date: Mon, 17 Jan 2011 14:38:23 +0000 Subject: [tei-council] Hyphenation discussion In-Reply-To: <4D342C54.8000802@kcl.ac.uk> References: <4D31DF5B.2030409@retired.ox.ac.uk> <4D33628E.7000102@oucs.ox.ac.uk> <4D342C54.8000802@kcl.ac.uk> Message-ID: <4D34545F.4040603@kcl.ac.uk> Maybe I should simplify this rambling email to two concrete proposals (neither of which I'm pushing particularly strongly): (1) instead of "noBreak" and (problematic) "mayBreak", we recommend a single value (either "noBreak" or "inWord") and the use of to indicate the possibility that we're either unsure or don't want to commit whether this linebreak is in the middle of a single word or not. 0r: (2) in addition to "noBreak" and "mayBreak", we consider what the value we want for linebreaks that *do* break words. G On 17/01/2011 11:47, Gabriel Bodard wrote: > On the whole I'm agnostic about the values used in this case, so long as > they're unambiguous (which they seem to be). > > Wearing my EpiDoc hat, I am concerned that we (EpiDoc) follow as closely > as possible the canonical TEI recommendation, which is precisely why we > recently changed our recommended usage from "worddiv" to Lou's preferred > "inWord". It's a little saddening to see this now being preserved only > for backward compatibility with "existing recommendations". :-( > > But if "noBreak" and "mayBreak" are more clear, and mirror nicely, then > so be it (and, with Sebastian, I would sooner have one recommendation > than two, even if it means persuading EpiDoc to change again). Certainly > I don't think "maybeInWord" would be attractive. But perhaps then, as > Piotr points out, the ambiguity of "mayBreak" demands more values; or > rather, I would suggests, it suggests we should use to > specify how and for what reason we are uncertain about the value of > "noBreak" (which then might as well be "inWord"). > > Another question: preserving the nice mirroring or "noBreak" and > "mayBreak", what value would we give for the positive side of this coin? > "doesBreak"? (Serious question: while this would normally be the default > value, I can certainly imagine cases where I'd want to specify the value > of all linebreaks in a text, for example where lineation is completely > unrelated to tokenization--as on coins, seals, stoichedon inscriptions, > etc.) > > G > > On 16/01/2011 21:26, Lou Burnard wrote: >> Many thanks for helpful improvements. >> >> Now standing by for input from other council members. >> >> Gabby, what's your take on the proposed values for @type? >> >> On 16/01/11 17:37, Sebastian Rahtz wrote: >>> I'm broadly in favour, but some nitpicks below >>> >> >> _______________________________________________ >> tei-council mailing list >> tei-council at lists.village.Virginia.EDU >> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > -- Dr Gabriel BODARD (Research Associate in Digital Epigraphy) Centre for Computing in the Humanities King's College London 26-29 Drury Lane London WC2B 5RL Email: gabriel.bodard at kcl.ac.uk Tel: +44 (0)20 7848 1388 Fax: +44 (0)20 7848 2980 http://www.digitalclassicist.org/ http://www.currentepigraphy.org/ From bansp at o2.pl Mon Jan 17 11:56:31 2011 From: bansp at o2.pl (=?ISO-8859-2?Q?Piotr_Ba=F1ski?=) Date: Mon, 17 Jan 2011 17:56:31 +0100 Subject: [tei-council] Hyphenation discussion In-Reply-To: <4D337692.4030201@o2.pl> References: <4D31DF5B.2030409@retired.ox.ac.uk> <4D337692.4030201@o2.pl> Message-ID: <4D3474BF.5070709@o2.pl> On 2011-01-16 23:52, I wrote: [...] I chose the wrong term below. I did mean something like "canonical inflected form with no typographic interventions" but that needn't mean the same as "lemma". P. > * lastly, the "opaatje" case -- a great example, also because it seems > to clearly present the core of the issue: "here's the lemma, and here's > the physical, contextual rendering; choose the one you want". If this is > correct, then the strategy becomes shorthand for something like > > lemma > rendered_form_with_lb_when_it's_easy_to_recover_the_lemma > > > -- so maybe it's worth presenting as such. From laurent.romary at inria.fr Tue Jan 18 05:02:04 2011 From: laurent.romary at inria.fr (Laurent Romary) Date: Tue, 18 Jan 2011 11:02:04 +0100 Subject: [tei-council] Council meeting in April - Symposium on 11. April Message-ID: Dear all, As a kind of now long-standing tradition within the council (initiated by Christian Wittern, if I'm not wrong), we will start our meeting in Chicago with a one-day symposium on 11. April on the following topic: "Representation, Preservation, and Interchange : Have We Fulfilled the Poughkeepsie Principles?". Kevin and I have started to brainstorm on this and would like to suggest the following out line for presenting this event: The Text Encoding Initiative (TEI) was formed in 1987 to develop guidelines for the encoding and interchange of machine-readable texts, hoping to overcome the difficulties of moving content across hardware and software platforms. Its development was guided by the Poughkeepsie Principles, which articulated the vision for the TEI, which would give guidelines on how to represent text in digital form and preserve it in a non-proprietary format which would facilitate data interchange. In the nearly 25 years since then, the TEI has seen wide adoption as a recommended format for representing and preserving digital text. While interchange of TEI files has generally become seamless, but interchange of content itself is still difficult due to great variation in local practice and flexibility in application of the Guidelines. And while the TEI community has long evangelized about the power of structured markup, we find that the information retrieval, digital preservation, and publishing communities have to various extents declined to embrace use rich structured markup in favor of simpler solutions. Has the TEI not yet fulfilled the Poughkeepsie Principles? Why are people adopting or developing other solutions besides the TEI? Do we suffer image problems, a lack of visibility, high barriers to entry? Is explicit representation of structure irrelevant today? We would think of inviting there various people which could provide us with food for thought for our future work. Part of the names result from their geographical proximity, hence making their presence more probable: John Wilkin, Thomas Schmidt, Martin Mueller, Jeff Beck, Mark Olsen, plus a report by Kevin on the Best Practices for TEI in libraries. Do not hesitate to come back to me and Kevin with further ideas. Laurent Laurent Romary INRIA & HUB-IDSL laurent.romary at inria.fr From sebastian.rahtz at oucs.ox.ac.uk Tue Jan 18 08:11:09 2011 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 18 Jan 2011 13:11:09 +0000 Subject: [tei-council] Council meeting in April - Symposium on 11. April In-Reply-To: References: Message-ID: <45AA25D0-1508-412C-A4A4-0F52BBAD4AFC@oucs.ox.ac.uk> On 18 Jan 2011, at 10:02, Laurent Romary wrote: > We would think of inviting there various people which could provide us > with food for thought for our future work. Part of the names result > from their geographical proximity, hence making their presence more > probable: John Wilkin, Thomas Schmidt, Martin Mueller, Jeff Beck, Mark > Olsen, plus a report by Kevin on the Best Practices for TEI in > libraries. The point in the past of the pre-Council workshop was to give the local folk a chance to hear from Council members, rather than have local folk advise the Council. One of the points in the past was that the local site sponsored a couple of council members. Is this a conscious change of direction? I'd be impressed to meet such a world-famous guitarist as Jeff Beck, but I only recognize Martin Mueller from the other names :-} -- Sebastian Rahtz Information and Support Group Manager Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From sebastian.rahtz at oucs.ox.ac.uk Tue Jan 18 08:38:28 2011 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 18 Jan 2011 13:38:28 +0000 Subject: [tei-council] Council meeting in April - Symposium on 11. April In-Reply-To: References: Message-ID: <04F2C52B-B4DD-4224-9F5E-9B7379096B11@oucs.ox.ac.uk> PS > Has the TEI not yet fulfilled the Poughkeepsie Principles? Why are > people adopting or developing other solutions besides the TEI? Do we > suffer image problems, a lack of visibility, high barriers to entry? > Is explicit representation of structure irrelevant today? I like the topic, though :-} mind you, its expressed in a rather glass-half-empty way. -- Sebastian Rahtz Information and Support Group Manager Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From laurent.romary at inria.fr Tue Jan 18 09:40:18 2011 From: laurent.romary at inria.fr (Laurent Romary) Date: Tue, 18 Jan 2011 15:40:18 +0100 Subject: [tei-council] Council meeting in April - Symposium on 11. April In-Reply-To: <45AA25D0-1508-412C-A4A4-0F52BBAD4AFC@oucs.ox.ac.uk> References: <45AA25D0-1508-412C-A4A4-0F52BBAD4AFC@oucs.ox.ac.uk> Message-ID: <98659F7D-1667-49B7-A50F-E081BE71CF66@inria.fr> I would say that most of the time, we have tried to inform the concil from local ractices on the contrary (remember Berlin where we had several German based project presenting their expectations towards the TEI). So let's say it's a subliminal unperceived change of direction. And I know more of countertenors than of guitarist, but that's another issue. Le 18 janv. 11 ? 14:11, Sebastian Rahtz a ?crit : > On 18 Jan 2011, at 10:02, Laurent Romary wrote: > >> We would think of inviting there various people which could provide >> us >> with food for thought for our future work. Part of the names result >> from their geographical proximity, hence making their presence more >> probable: John Wilkin, Thomas Schmidt, Martin Mueller, Jeff Beck, >> Mark >> Olsen, plus a report by Kevin on the Best Practices for TEI in >> libraries. > > > > The point in the past of the pre-Council workshop was to > give the local folk a chance to hear from Council members, > rather than have local folk advise the Council. One of the points > in the past was that the local site sponsored a couple > of council members. > > Is this a conscious change of direction? > > I'd be impressed to meet such a world-famous guitarist > as Jeff Beck, but I only recognize Martin Mueller > from the other names :-} > -- > Sebastian Rahtz > Information and Support Group Manager > Oxford University Computing Services > 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 > > S?lo le pido a Dios > que el futuro no me sea indiferente > Laurent Romary INRIA & HUB-IDSL laurent.romary at inria.fr From laurent.romary at inria.fr Tue Jan 18 09:41:19 2011 From: laurent.romary at inria.fr (Laurent Romary) Date: Tue, 18 Jan 2011 15:41:19 +0100 Subject: [tei-council] Council meeting in April - Symposium on 11. April In-Reply-To: <04F2C52B-B4DD-4224-9F5E-9B7379096B11@oucs.ox.ac.uk> References: <04F2C52B-B4DD-4224-9F5E-9B7379096B11@oucs.ox.ac.uk> Message-ID: We have started a google docs with more precise notes. Would you want to contribute there? Kevin, would it make sense to share the drafty thing with the council? Le 18 janv. 11 ? 14:38, Sebastian Rahtz a ?crit : > PS > > >> Has the TEI not yet fulfilled the Poughkeepsie Principles? Why are >> people adopting or developing other solutions besides the TEI? Do we >> suffer image problems, a lack of visibility, high barriers to entry? >> Is explicit representation of structure irrelevant today? > > I like the topic, though :-} mind you, its expressed in a rather > glass-half-empty way. > > -- > Sebastian Rahtz > Information and Support Group Manager > Oxford University Computing Services > 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 > > S?lo le pido a Dios > que el futuro no me sea indiferente > Laurent Romary INRIA & HUB-IDSL laurent.romary at inria.fr From sebastian.rahtz at oucs.ox.ac.uk Tue Jan 18 10:09:18 2011 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 18 Jan 2011 15:09:18 +0000 Subject: [tei-council] Council meeting in April - Symposium on 11. April In-Reply-To: References: <04F2C52B-B4DD-4224-9F5E-9B7379096B11@oucs.ox.ac.uk> Message-ID: Can you elaborate a bit more on what the agenda is here? does the Council actually need a day of lectures on where the TEI Is failing? that sounds like more for the the Board, and the members. let's remember that this day costs the TEI Consortium about $2000 (real money), and costs our institutions about $5000 (staff time) just for the Council members, so let's be sure we want it. -- Sebastian Rahtz Information and Support Group Manager Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From laurent.romary at inria.fr Tue Jan 18 10:13:28 2011 From: laurent.romary at inria.fr (Laurent Romary) Date: Tue, 18 Jan 2011 16:13:28 +0100 Subject: [tei-council] Council meeting in April - Symposium on 11. April In-Reply-To: References: <04F2C52B-B4DD-4224-9F5E-9B7379096B11@oucs.ox.ac.uk> Message-ID: <4DC07E26-2A19-45B4-AAE7-2F8513B8C1FD@inria.fr> I think it is our duty to connect with the local endeavours and projects. We are not so good at showing how close the work of the council can be from everyday practices. Those days, have proven over the years to give the feeling to people that the council does not work within its own bubble but listen to the needs or worries. Le 18 janv. 11 ? 16:09, Sebastian Rahtz a ?crit : > Can you elaborate a bit more on what the agenda is here? does the > Council > actually need a day of lectures on where the TEI Is failing? that > sounds like > more for the the Board, and the members. > > let's remember that this day costs the TEI Consortium about $2000 > (real money), > and costs our institutions about $5000 (staff time) just for the > Council > members, so let's be sure we want it. > -- > Sebastian Rahtz > Information and Support Group Manager > Oxford University Computing Services > 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 > > S?lo le pido a Dios > que el futuro no me sea indiferente > Laurent Romary INRIA & HUB-IDSL laurent.romary at inria.fr From kevin.s.hawkins at ultraslavonic.info Tue Jan 18 10:16:11 2011 From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins) Date: Tue, 18 Jan 2011 10:16:11 -0500 Subject: [tei-council] Council meeting in April - Symposium on 11. April In-Reply-To: References: <04F2C52B-B4DD-4224-9F5E-9B7379096B11@oucs.ox.ac.uk> Message-ID: <4D35AEBB.7010803@ultraslavonic.info> Since the archives of tei-council are publicly available, we must be cautious not just about discussing names of potential invitees. Instead of gathering all Council members' email addresses, I have made the document editable by anyone with the link. However, since this list is crawled, I don't want to include the link publicly So please put the following after "docs.google.com": /Doc?docid=0ARyxZGtPbrQ1ZHYzZHg3aF8yMWQ2dmtwcjZx&hl=en&authkey=CLDv78cK to see what Laurent and I have been working on. On 1/18/2011 9:41 AM, Laurent Romary wrote: > We have started a google docs with more precise notes. Would you want > to contribute there? > Kevin, would it make sense to share the drafty thing with the council? From dsewell at virginia.edu Tue Jan 18 10:29:59 2011 From: dsewell at virginia.edu (David Sewell) Date: Tue, 18 Jan 2011 10:29:59 -0500 (EST) Subject: [tei-council] tei-council list and privacy Message-ID: I just noticed Kevin's reminder about the public nature of the tei-council archives. I just added a list setting that should append a reminder note to that effect at the end of every email to the list. David (as listowner) -- David Sewell, Editorial and Technical Manager ROTUNDA, The University of Virginia Press PO Box 400314, Charlottesville, VA 22904-4314 USA Email: dsewell at virginia.edu Tel: +1 434 924 9973 Web: http://rotunda.upress.virginia.edu/ From sebastian.rahtz at oucs.ox.ac.uk Tue Jan 18 12:18:55 2011 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 18 Jan 2011 17:18:55 +0000 Subject: [tei-council] Council meeting in April - Symposium on 11. April In-Reply-To: <4D35AEBB.7010803@ultraslavonic.info> References: <04F2C52B-B4DD-4224-9F5E-9B7379096B11@oucs.ox.ac.uk> <4D35AEBB.7010803@ultraslavonic.info> Message-ID: On 18 Jan 2011, at 15:16, Kevin Hawkins wrote: > Since the archives of tei-council are publicly available, we must be > cautious not just about discussing names of potential invitees. whoops. my apologies, my posting was _not_ appropriate then. I hope it does not offend anyone. The list of topics on the google docs does look rather negative, sorry. Surely there are folks who can actually be positive about the TEI? -- Sebastian Rahtz Information and Support Group Manager Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From laurent.romary at inria.fr Tue Jan 18 12:48:19 2011 From: laurent.romary at inria.fr (Laurent Romary) Date: Tue, 18 Jan 2011 18:48:19 +0100 Subject: [tei-council] Council meeting in April - Symposium on 11. April In-Reply-To: References: <04F2C52B-B4DD-4224-9F5E-9B7379096B11@oucs.ox.ac.uk> <4D35AEBB.7010803@ultraslavonic.info> Message-ID: <5AAE13C9-7CA9-4F79-92A9-B1CF94658492@inria.fr> To make things appropriate and if I were Seb (using his always positive mood) I would say: "waow, that's exactly the kind of topics the council needs to debate about. I would like to offer to make a visionary presentation of how OxGarage is actually bringing a lot in terms of interoperability". OK, Seb? Le 18 janv. 11 ? 18:18, Sebastian Rahtz a ?crit : > > On 18 Jan 2011, at 15:16, Kevin Hawkins wrote: > >> Since the archives of tei-council are publicly available, we must be >> cautious not just about discussing names of potential invitees. > > whoops. my apologies, my posting was _not_ appropriate then. I hope > it does not offend anyone. > > The list of topics on the google docs does look rather negative, > sorry. Surely > there are folks who can actually be positive about the TEI? > > -- > Sebastian Rahtz > Information and Support Group Manager > Oxford University Computing Services > 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 > > S?lo le pido a Dios > que el futuro no me sea indiferente > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > > PLEASE NOTE: postings to this list are publicly archived Laurent Romary INRIA & HUB-IDSL laurent.romary at inria.fr From James.Cummings at oucs.ox.ac.uk Tue Jan 18 13:48:39 2011 From: James.Cummings at oucs.ox.ac.uk (James Cummings) Date: Tue, 18 Jan 2011 18:48:39 +0000 Subject: [tei-council] Council meeting in April - Symposium on 11. April In-Reply-To: <5AAE13C9-7CA9-4F79-92A9-B1CF94658492@inria.fr> References: <04F2C52B-B4DD-4224-9F5E-9B7379096B11@oucs.ox.ac.uk> <4D35AEBB.7010803@ultraslavonic.info> <5AAE13C9-7CA9-4F79-92A9-B1CF94658492@inria.fr> Message-ID: <4D35E087.1060002@oucs.ox.ac.uk> a) (On who to invite to speak) While I think Sebastian talking about OxGarage and how it now underlies how things like WebRoma works and how loosely coupled web services with clear APIs are a good thing for the TEI, is a good topic... isn't his overall point slightly different. It isn't necessarily "Seb wants to talk as well" but more that usually at the TEI Days before a Council meeting we've had a mixture of people from the council talking and local projects. The local people get the benefit of listening to someone new for a change, the council get the benefit of hearing about some local projects. TEI users don't often get a chance to hear papers which evince how the underlying TEI systems really work or similarly arcane topics. It seems better to me to have the day be a collaboration between local people and the TEI as an organization. b) (On the proposed list) While some of the people there will be quite interesting, Portico/PubMedCentral/OCUL all seem to be the same thing. They use NLM and not TEI and for pretty much all for the same reason if I gather correctly. The NDIIP lists XML rather than TEI specifically as a preferred format, and that is a potentially interesting discussion (especially in light of a TEI mimeType), but the reasons they've done this are probably fairly straightforward as well. I'm feeling uninspired as to what is beneficially going to result for the discussions where people are not using the TEI for straightforward reasons (political, practical, economic, whatever) (Perhaps this is my failing and a lack of imagination.) I'm more interested by those people who *do* engage with the TEI in particular circumstances or who have a long-term view of the TEI and whether it indeed has or has not fulfilled the Poughkeepsie Principles. c) (On the emails to be sent) Doesn't it behove us to provide or at least link to a copy of the Poughkeepsie Principles? Our canonical copy is pretty unreadable some might say.? (unless I'm missing it somewhere?) There is a nicely formatted version in the TEI By Example site.? or I have a list of them in an article that is online? or maybe best is that Michael has a formatted version of EDP1 up (maybe we should put a copy of that in the vault and point there?)? This all reminds me that the Vault on the TEI-C website needs tidying up. d) (On public access to the tei-council mailing list) Just to note that the tei-council archives have been open for quite some time. It was argued for by a very cunning person back in 2006 who recognised that it would allow those running for council to be able to see what council does, allow those who leave council to continue to follow issues that interest them, and also allow us to link back to previous discussions as I'm doing right now.? -James Notes: ? http://www.tei-c.org/Vault/ED/edp01.gml ? http://tbe.kantl.be/TBE/modules/TBED00v00.htm?target=teihistory#poughkeepsie ? http://tinyurl.com/jc-dlstei ?http://cmsmcq.com/1990/edp1.html ?http://lists.village.virginia.edu/pipermail/tei-council/2006/005757.html On 18/01/11 17:48, Laurent Romary wrote: > To make things appropriate and if I were Seb (using his always > positive mood) I would say: "waow, that's exactly the kind of topics > the council needs to debate about. I would like to offer to make a > visionary presentation of how OxGarage is actually bringing a lot in > terms of interoperability". OK, Seb? > > > Le 18 janv. 11 ? 18:18, Sebastian Rahtz a ?crit : > >> >> On 18 Jan 2011, at 15:16, Kevin Hawkins wrote: >> >>> Since the archives of tei-council are publicly available, we must be >>> cautious not just about discussing names of potential invitees. >> >> whoops. my apologies, my posting was _not_ appropriate then. I hope >> it does not offend anyone. >> >> The list of topics on the google docs does look rather negative, >> sorry. Surely >> there are folks who can actually be positive about the TEI? >> >> -- >> Sebastian Rahtz >> Information and Support Group Manager >> Oxford University Computing Services >> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 >> >> S?lo le pido a Dios >> que el futuro no me sea indiferente >> >> _______________________________________________ >> tei-council mailing list >> tei-council at lists.village.Virginia.EDU >> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council >> >> PLEASE NOTE: postings to this list are publicly archived > > Laurent Romary > INRIA& HUB-IDSL > laurent.romary at inria.fr > > > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > > PLEASE NOTE: postings to this list are publicly archived -- Dr James Cummings, Research Technologies Service OUCS, University of Oxford From laurent.romary at inria.fr Tue Jan 18 14:07:33 2011 From: laurent.romary at inria.fr (Laurent Romary) Date: Tue, 18 Jan 2011 20:07:33 +0100 Subject: [tei-council] Council meeting in April - Symposium on 11. April In-Reply-To: <4D35E087.1060002@oucs.ox.ac.uk> References: <04F2C52B-B4DD-4224-9F5E-9B7379096B11@oucs.ox.ac.uk> <4D35AEBB.7010803@ultraslavonic.info> <5AAE13C9-7CA9-4F79-92A9-B1CF94658492@inria.fr> <4D35E087.1060002@oucs.ox.ac.uk> Message-ID: <01881A37-EFB0-4555-9A4B-879856653DFC@inria.fr> I take one point at a time; I have never thought that Seb wanted to speak, but I had the feeling that OxGarage would be a very nice thing to present there; It's potentially a tool which could, among other things, help libraries see format discrepancy with a better eye. And yes, would be great to have other proposals like this. Any thoughts? As a whole I agree with your analysis, but it is always more difficult to get people external to the council to come then find good talks within such a good group as we have (but we can start gathering them) Le 18 janv. 11 ? 19:48, James Cummings a ?crit : > a) (On who to invite to speak) While I think Sebastian talking > about OxGarage and how it now underlies how things like WebRoma > works and how loosely coupled web services with clear APIs are a > good thing for the TEI, is a good topic... isn't his overall > point slightly different. It isn't necessarily "Seb wants to > talk as well" but more that usually at the TEI Days before a > Council meeting we've had a mixture of people from the council > talking and local projects. The local people get the benefit of > listening to someone new for a change, the council get the > benefit of hearing about some local projects. TEI users don't > often get a chance to hear papers which evince how the underlying > TEI systems really work or similarly arcane topics. It seems > better to me to have the day be a collaboration between local > people and the TEI as an organization. Laurent Romary INRIA & HUB-IDSL laurent.romary at inria.fr From sebastian.rahtz at oucs.ox.ac.uk Tue Jan 18 14:33:43 2011 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 18 Jan 2011 19:33:43 +0000 Subject: [tei-council] Council meeting in April - Symposium on 11. April In-Reply-To: <4D35E087.1060002@oucs.ox.ac.uk> References: <04F2C52B-B4DD-4224-9F5E-9B7379096B11@oucs.ox.ac.uk> <4D35AEBB.7010803@ultraslavonic.info> <5AAE13C9-7CA9-4F79-92A9-B1CF94658492@inria.fr> <4D35E087.1060002@oucs.ox.ac.uk> Message-ID: On 18 Jan 2011, at 18:48, James Cummings wrote: > > straightforward as well. I'm feeling uninspired as to what is > beneficially going to result for the discussions where people are > not using the TEI for straightforward reasons (political, > practical, economic, whatever) yes, my feeling exactly. A day of talks by high-level folk about NLM vs TEI or EAD vs TEI will be sterile and predictable; as will a day spent beating our breasts as to why people don't get it about rich markup. the theme of "so did we meet the aims of the P'Keepsie Principles" is a good one, but the talks have to be "open",ie allowing for discussion and possible positive results. The Council on the two days following can then use this to prioritize existing work or commission new work; but I don't want to spend those two days wondering why all the STEM publishers have not adopted the TEI (I spent too many years with TeXxies having that discussion). Why don't we have a day of dark and light? presentations which ask questions and cast doubt alternating with presentations which show what can be achieved and where the TEI has done its job. A digital librarian doubter from the midwest can be followed by Stuart showing how it worked in NZ, for example. While I have no great desire to talk about OxGarage, because it's really rather a trivial bit of software, I do think a talk about the problems of designing a family of XSL stylesheets to process arbitrary TEI docs might be worthwhile - depending on the audience, of course. -- Sebastian Rahtz Information and Support Group Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From bansp at o2.pl Tue Jan 18 14:51:06 2011 From: bansp at o2.pl (=?ISO-8859-2?Q?Piotr_Ba=F1ski?=) Date: Tue, 18 Jan 2011 20:51:06 +0100 Subject: [tei-council] Council meeting in April - Symposium on 11. April In-Reply-To: <4D35E087.1060002@oucs.ox.ac.uk> References: <04F2C52B-B4DD-4224-9F5E-9B7379096B11@oucs.ox.ac.uk> <4D35AEBB.7010803@ultraslavonic.info> <5AAE13C9-7CA9-4F79-92A9-B1CF94658492@inria.fr> <4D35E087.1060002@oucs.ox.ac.uk> Message-ID: <4D35EF2A.2070001@o2.pl> Hi All, I am not sure that mangling the web address of the doc is sufficient to ensure privacy and free exchange of opinions on the particular candidates by name, should anyone feel a need for that. After all, the doc is readable by anyone with the link. Or are crawlers the only concern? Secondly, what is the status of this proposal, please? Is there still time to nominate, or just to voice opinions on the possible invitees (what does e.g. "yes: Laurent" mean? Is that the first vote on the "aye" list, and are we expected to add ours?) The following may betray my lack of imagination and expertise, but the only result I can imagine from listening to the purported advantages of doing text encoding in HTML over semantic vocabulary is annoyance -- I simply can't imagine to what positive goal this might lead.[*] On the other hand, I could imagine the advantages of listening to someone who has abandoned the TEI and proceeded to create two successful language-resource-encoding systems, namely Nancy Ide, and of asking her if the limits of the TEI that made her abandon it once are already gone, and if not, what paths she would suggest that we follow. (We've seen one recent problem gone last summer [in Dublin, I guess], with the adoption of a modification concerning FS-encoding that made it possible not to type features in situ. Are there any others that she sees, I'd like to ask Nancy.) Best, Piotr [*] The only way to use HTML for text encoding that I can imagine is by heavily sub-classing it, and thus turning your HTML into mock-XML without the advantages of real XML. But again, this may just betray my limitations. Or maybe I misunderstand the description in the doc. From kevin.s.hawkins at ultraslavonic.info Tue Jan 18 15:03:30 2011 From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins) Date: Tue, 18 Jan 2011 15:03:30 -0500 Subject: [tei-council] Council meeting in April - Symposium on 11. April In-Reply-To: <4D35EF2A.2070001@o2.pl> References: <04F2C52B-B4DD-4224-9F5E-9B7379096B11@oucs.ox.ac.uk> <4D35AEBB.7010803@ultraslavonic.info> <5AAE13C9-7CA9-4F79-92A9-B1CF94658492@inria.fr> <4D35E087.1060002@oucs.ox.ac.uk> <4D35EF2A.2070001@o2.pl> Message-ID: <4D35F212.4030300@ultraslavonic.info> All, allow me to offer some clarifications: On 1/18/2011 2:51 PM, Piotr Ba?ski wrote: > I am not sure that mangling the web address of the doc is sufficient to > ensure privacy and free exchange of opinions on the particular > candidates by name, should anyone feel a need for that. After all, the > doc is readable by anyone with the link. Or are crawlers the only concern? This was meant to keep spambots from following a link to the document in the tei-council archives and putting nonsense or ads in our document. I opened it to editing by everyone so that you could all contribute to the plans under development without me needing to gather from all of you your preferred email address for use with Google Docs. > Secondly, what is the status of this proposal, please? Is there still > time to nominate, or just to voice opinions on the possible invitees > (what does e.g. "yes: Laurent" mean? Is that the first vote on the "aye" > list, and are we expected to add ours?) Yes, there is time to nominate. Neither Laurent nor I have invited anyone yet, and that third column (entitled "invite now?") was meant to indicate which of us would do the inviting and whether we would do it now or wait till later. I have clarified the wording. We really do want your opinions on all of this so that the program is not entirely compiled by Laurent and me. > The following may betray my lack of imagination and expertise, but the > only result I can imagine from listening to the purported advantages of > doing text encoding in HTML over semantic vocabulary is annoyance -- I > simply can't imagine to what positive goal this might lead.[*] I think you're referring to the proposed topic for John Maxwell. He did semantic markup for years and gave up on it because he felt that it was needlessly complicated for most publishing workflows. See http://thinkubator.ccsp.sfu.ca/wikis/xmlProduction/Home . He presented on this at last year's symposium, actually ( http://dho.ie/node/673 ). --Kevin From bansp at o2.pl Tue Jan 18 15:08:50 2011 From: bansp at o2.pl (=?ISO-8859-2?Q?Piotr_Ba=F1ski?=) Date: Tue, 18 Jan 2011 21:08:50 +0100 Subject: [tei-council] Council meeting in April - Symposium on 11. April In-Reply-To: <4D35F212.4030300@ultraslavonic.info> References: <04F2C52B-B4DD-4224-9F5E-9B7379096B11@oucs.ox.ac.uk> <4D35AEBB.7010803@ultraslavonic.info> <5AAE13C9-7CA9-4F79-92A9-B1CF94658492@inria.fr> <4D35E087.1060002@oucs.ox.ac.uk> <4D35EF2A.2070001@o2.pl> <4D35F212.4030300@ultraslavonic.info> Message-ID: <4D35F352.5080203@o2.pl> On 2011-01-18 21:03, Kevin Hawkins wrote: > All, allow me to offer some clarifications: Thanks Kevin, I'll have a look at these links right away. Piotr From sebastian.rahtz at oucs.ox.ac.uk Tue Jan 18 15:14:57 2011 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 18 Jan 2011 20:14:57 +0000 Subject: [tei-council] Council meeting in April - Symposium on 11. April In-Reply-To: <4D35F212.4030300@ultraslavonic.info> References: <04F2C52B-B4DD-4224-9F5E-9B7379096B11@oucs.ox.ac.uk> <4D35AEBB.7010803@ultraslavonic.info> <5AAE13C9-7CA9-4F79-92A9-B1CF94658492@inria.fr> <4D35E087.1060002@oucs.ox.ac.uk> <4D35EF2A.2070001@o2.pl> <4D35F212.4030300@ultraslavonic.info> Message-ID: On 18 Jan 2011, at 20:03, Kevin Hawkins wrote: > I think you're referring to the proposed topic for John Maxwell. He did > semantic markup for years and gave up on it because he felt that it was > needlessly complicated for most publishing workflows. See > http://thinkubator.ccsp.sfu.ca/wikis/xmlProduction/Home . This, surely, is a good example of beating a dead horse. Would anyone disagree with the points he makes? I wouldn't, in the broad. TEI _is_ needlessly complicated for most publishing workflows. But Poughkeepsie never said it was designed for that ("... a standard format for data interchange..."). -- Sebastian Rahtz Information and Support Group Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From julianne.nyhan at gmail.com Tue Jan 18 15:33:22 2011 From: julianne.nyhan at gmail.com (Julianne Nyhan) Date: Tue, 18 Jan 2011 20:33:22 +0000 Subject: [tei-council] Council meeting in April - Symposium on 11. April In-Reply-To: References: <04F2C52B-B4DD-4224-9F5E-9B7379096B11@oucs.ox.ac.uk> <4D35AEBB.7010803@ultraslavonic.info> <5AAE13C9-7CA9-4F79-92A9-B1CF94658492@inria.fr> <4D35E087.1060002@oucs.ox.ac.uk> <4D35EF2A.2070001@o2.pl> <4D35F212.4030300@ultraslavonic.info> Message-ID: >but interchange of content itself is still difficult due to great >variation in local practice and flexibility in application of the >Guidelines. And while the TEI community has long evangelized about >the power of structured markup, we find that the information >retrieval, digital preservation, and publishing communities have to >various extents declined to embrace use rich structured markup in >favor of simpler solutions. I like Sebastian's idea of having light and dark and it strikes me that it may also be interesting to hear from the middle ground, as it were. For example, TextGrid have not stepped away from TEI but are working on a simplified baseline encoding' format 'a text type-specific encoding which is based on the TEI P5 standard' ( http://www.textgrid.de/fileadmin/TextGrid/reports/TextGrid_R121_v1.0.pdf). Julianne Has the TEI not yet fulfilled the Poughkeepsie Principles? Why are people adopting or developing other solutions besides the TEI? Do we suffer image problems, a lack of visibility, high barriers to entry? Is explicit representation of structure irrelevant today? On Tue, Jan 18, 2011 at 8:14 PM, Sebastian Rahtz < sebastian.rahtz at oucs.ox.ac.uk> wrote: > On 18 Jan 2011, at 20:03, Kevin Hawkins wrote: > > > I think you're referring to the proposed topic for John Maxwell. He did > > semantic markup for years and gave up on it because he felt that it was > > needlessly complicated for most publishing workflows. See > > http://thinkubator.ccsp.sfu.ca/wikis/xmlProduction/Home . > > This, surely, is a good example of beating a dead horse. Would > anyone disagree with the points he makes? I wouldn't, > in the broad. TEI _is_ needlessly complicated for most publishing > workflows. > But Poughkeepsie never said it was designed for that > ("... a standard format for data interchange..."). > > -- > Sebastian Rahtz > Information and Support Group Manager, Oxford University Computing Services > 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 > > S?lo le pido a Dios > que el futuro no me sea indiferente > > > > > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > > PLEASE NOTE: postings to this list are publicly archived > -- Dr Julianne Nyhan, (UCL & Universitaet Trier) *Direct Line:* +44 (0)20 7679 7206) *Fax:* +44 (0)20 7383 0557) *Office:* G15a, Department of Information Studies, Foster Court, University College London, WC1E 6BT, U.K. http://www.ucl.ac.uk/infostudies/julianne-nyhan/ http://germazope.uni-trier.de/Projects/KoZe2/ http://epu.ucc.ie/theses/jnyhan/ http://maney.co.uk/index.php/journals/isr/ From stuart.yeates at vuw.ac.nz Tue Jan 18 15:36:29 2011 From: stuart.yeates at vuw.ac.nz (stuart yeates) Date: Wed, 19 Jan 2011 09:36:29 +1300 Subject: [tei-council] Council meeting in April - Symposium on 11. April In-Reply-To: References: <04F2C52B-B4DD-4224-9F5E-9B7379096B11@oucs.ox.ac.uk> <4D35AEBB.7010803@ultraslavonic.info> <5AAE13C9-7CA9-4F79-92A9-B1CF94658492@inria.fr> <4D35E087.1060002@oucs.ox.ac.uk> Message-ID: <4D35F9CD.4020307@vuw.ac.nz> On 19/01/11 08:33, Sebastian Rahtz wrote: > Why don't we have a day of dark and light? presentations which ask questions > and cast doubt alternating with presentations which show what can be achieved > and where the TEI has done its job. A digital librarian doubter from the > midwest can be followed by Stuart showing how it worked in NZ, for example. I'm happy to participate remotely if it would help. > While I have no great desire to talk about OxGarage, because it's really > rather a trivial bit of software, I do think a talk about the problems of > designing a family of XSL stylesheets to process arbitrary TEI docs > might be worthwhile - depending on the audience, of course. The case could be argued that OxGarage is a trivial piece of software (I've not looked at the internals, so I don't know), but it can only be trivial once one has made a whole chain of other decisions have been made---decisions about encoding, decisions about organisation, decisions about technology, decisions about authority control. To my eye it's the rationale around those chains of decisions that are most interesting and important for doubters and newbies. Discussion of the problems of designing a family of XSL stylesheets to process arbitrary TEI docs does sound interesting. Sounds like an ideal topic for a wikibook, so we can all contribute and help keep it up-to-date. cheers stuart -- Stuart Yeates Library Technology Services http://www.victoria.ac.nz/library/ From sebastian.rahtz at oucs.ox.ac.uk Tue Jan 18 15:54:57 2011 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 18 Jan 2011 20:54:57 +0000 Subject: [tei-council] Council meeting in April - Symposium on 11. April In-Reply-To: <4D35F9CD.4020307@vuw.ac.nz> References: <04F2C52B-B4DD-4224-9F5E-9B7379096B11@oucs.ox.ac.uk> <4D35AEBB.7010803@ultraslavonic.info> <5AAE13C9-7CA9-4F79-92A9-B1CF94658492@inria.fr> <4D35E087.1060002@oucs.ox.ac.uk> <4D35F9CD.4020307@vuw.ac.nz> Message-ID: <0841B0D2-234B-49DB-B537-60C077E5F72B@oucs.ox.ac.uk> On 18 Jan 2011, at 20:36, stuart yeates wrote: >> and where the TEI has done its job. A digital librarian doubter from the >> midwest can be followed by Stuart showing how it worked in NZ, for example. > > I'm happy to participate remotely if it would help. are you not able to come to Chicago? > The case could be argued that OxGarage is a trivial piece of software > (I've not looked at the internals, so I don't know), but it can only be > trivial once one has made a whole chain of other decisions have been > made---decisions about encoding, decisions about organisation, decisions > about technology, decisions about authority control. absolutely. OxGarage per se is the easy bit, once the other things are in place > Discussion of the problems of designing a family of XSL stylesheets to > process arbitrary TEI docs does sound interesting. it would be quite technical, I think. Aspects like how to modularize XSLT, naming of , which bits are shareable across formats, how to document, etc -- Sebastian Rahtz Information and Support Group Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From lou.burnard at oucs.ox.ac.uk Tue Jan 18 16:32:46 2011 From: lou.burnard at oucs.ox.ac.uk (Lou Burnard) Date: Tue, 18 Jan 2011 21:32:46 +0000 Subject: [tei-council] Council meeting in April - Symposium on 11. April In-Reply-To: <4D35E087.1060002@oucs.ox.ac.uk> References: <04F2C52B-B4DD-4224-9F5E-9B7379096B11@oucs.ox.ac.uk> <4D35AEBB.7010803@ultraslavonic.info> <5AAE13C9-7CA9-4F79-92A9-B1CF94658492@inria.fr> <4D35E087.1060002@oucs.ox.ac.uk> Message-ID: <4D3606FE.7070107@oucs.ox.ac.uk> On 18/01/11 18:48, James Cummings wrote: > [much that I entirely agree with snipped out] > c) (On the emails to be sent) Doesn't it behove us to provide or > at least link to a copy of the Poughkeepsie Principles? Our > canonical copy is pretty unreadable some might say.? http://www.tei-c.org/Vault/SC/teipcp1.txt not good enough for you? From lou.burnard at oucs.ox.ac.uk Tue Jan 18 16:37:50 2011 From: lou.burnard at oucs.ox.ac.uk (Lou Burnard) Date: Tue, 18 Jan 2011 21:37:50 +0000 Subject: [tei-council] Council meeting in April - Symposium on 11. April In-Reply-To: <4D35EF2A.2070001@o2.pl> References: <04F2C52B-B4DD-4224-9F5E-9B7379096B11@oucs.ox.ac.uk> <4D35AEBB.7010803@ultraslavonic.info> <5AAE13C9-7CA9-4F79-92A9-B1CF94658492@inria.fr> <4D35E087.1060002@oucs.ox.ac.uk> <4D35EF2A.2070001@o2.pl> Message-ID: <4D36082E.1050405@oucs.ox.ac.uk> On 18/01/11 19:51, Piotr Ba?ski wrote: > doing text encoding in HTML over semantic vocabulary is annoyance -- I > simply can't imagine to what positive goal this might lead.[*] On the > other hand, I could imagine the advantages of listening to someone who > has abandoned the TEI and proceeded to create two successful > language-resource-encoding systems, namely Nancy Ide, and of asking her > if the limits of the TEI that made her abandon it once are already gone, > and if not, what paths she would suggest that we follow. FWIW, Nancy was actually invited to the first TEI Conference and given more or less the same brief then. So she may feel she's "been there done that". > (We've seen one > recent problem gone last summer [in Dublin, I guess], with the adoption > of a modification concerning FS-encoding that made it possible not to > type features in situ. Are there any others that she sees, I'd like to > ask Nancy.) Probably rather too specialised and specific a topic ? From james.cummings at oucs.ox.ac.uk Tue Jan 18 16:45:49 2011 From: james.cummings at oucs.ox.ac.uk (James Cummings) Date: Tue, 18 Jan 2011 21:45:49 +0000 Subject: [tei-council] Council meeting in April - Symposium on 11. April Message-ID: Darn. I didn't find that when searching for it. Careless on my part. James. Lou Burnard wrote: On 18/01/11 18:48, James Cummings wrote: > [much that I entirely agree with snipped out] > c) (On the emails to be sent) Doesn't it behove us to provide or > at least link to a copy of the Poughkeepsie Principles? Our > canonical copy is pretty unreadable some might say.? http://www.tei-c.org/Vault/SC/teipcp1.txt not good enough for you? _______________________________________________ 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 Jan 18 16:49:28 2011 From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins) Date: Tue, 18 Jan 2011 16:49:28 -0500 Subject: [tei-council] Council meeting in April - Symposium on 11. April In-Reply-To: References: Message-ID: <4D360AE8.9060504@ultraslavonic.info> Lou, do you think it would be appropriate for http://www.tei-c.org/About/history.xml at the phrase "intellectual foundation" to link to http://www.tei-c.org/Vault/SC/teipcp1.txt ? I ask you this because there might be more of an intellectual foundation besides this document. (I wasn't at the meeting and can't say.) Adding this link would likely help our version of the principles rise higher in the Google ranking. --Kevin On 1/18/2011 4:45 PM, James Cummings wrote: > Darn. I didn't find that when searching for it. Careless on my part. > > > James. > > > Lou Burnard wrote: > > > On 18/01/11 18:48, James Cummings wrote: >> [much that I entirely agree with snipped out] > >> c) (On the emails to be sent) Doesn't it behove us to provide or >> at least link to a copy of the Poughkeepsie Principles? Our >> canonical copy is pretty unreadable some might say.? > > http://www.tei-c.org/Vault/SC/teipcp1.txt not good enough for you? > > > > _______________________________________________ > 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 sebastian.rahtz at oucs.ox.ac.uk Tue Jan 18 16:54:07 2011 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 18 Jan 2011 21:54:07 +0000 Subject: [tei-council] Council meeting in April - Symposium on 11. April In-Reply-To: <4D360AE8.9060504@ultraslavonic.info> References: <4D360AE8.9060504@ultraslavonic.info> Message-ID: On 18 Jan 2011, at 21:49, Kevin Hawkins wrote: > Lou, do you think it would be appropriate for > > http://www.tei-c.org/About/history.xml if you're editing that, the sentence "The P5 version of the Guidelines is scheduled to be released at the end of 2007." may be worth changing :-} -- Sebastian Rahtz Information and Support Group Manager, Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 S?lo le pido a Dios que el futuro no me sea indiferente From lou.burnard at oucs.ox.ac.uk Tue Jan 18 17:02:00 2011 From: lou.burnard at oucs.ox.ac.uk (Lou Burnard) Date: Tue, 18 Jan 2011 22:02:00 +0000 Subject: [tei-council] Council meeting in April - Symposium on 11. April In-Reply-To: <4D360AE8.9060504@ultraslavonic.info> References: <4D360AE8.9060504@ultraslavonic.info> Message-ID: <4D360DD8.1000705@oucs.ox.ac.uk> On 18/01/11 21:49, Kevin Hawkins wrote: > Lou, do you think it would be appropriate for > > http://www.tei-c.org/About/history.xml > > at the phrase "intellectual foundation" to link to > > http://www.tei-c.org/Vault/SC/teipcp1.txt > > ? I ask you this because there might be more of an intellectual > foundation besides this document. (I wasn't at the meeting and can't > say.) Adding this link would likely help our version of the principles > rise higher in the Google ranking. Probably a rather better candidate for the definitive stateme nt of the TEI's founding "intellectual framework" would be the EDP1 document at http://www.tei-c.org/Vault/ED/edp01.htm (which includes the Poughkeepsie Principles and comments on them) From lou.burnard at oucs.ox.ac.uk Tue Jan 18 17:11:14 2011 From: lou.burnard at oucs.ox.ac.uk (Lou Burnard) Date: Tue, 18 Jan 2011 22:11:14 +0000 Subject: [tei-council] Council meeting in April - Symposium on 11. April In-Reply-To: References: <04F2C52B-B4DD-4224-9F5E-9B7379096B11@oucs.ox.ac.uk> <4D35AEBB.7010803@ultraslavonic.info> <5AAE13C9-7CA9-4F79-92A9-B1CF94658492@inria.fr> <4D35E087.1060002@oucs.ox.ac.uk> <4D35EF2A.2070001@o2.pl> <4D35F212.4030300@ultraslavonic.info> Message-ID: <4D361002.8080606@oucs.ox.ac.uk> On 18/01/11 20:14, Sebastian Rahtz wrote: > On 18 Jan 2011, at 20:03, Kevin Hawkins wrote: > >> I think you're referring to the proposed topic for John Maxwell. He did >> semantic markup for years and gave up on it because he felt that it was >> needlessly complicated for most publishing workflows. See >> http://thinkubator.ccsp.sfu.ca/wikis/xmlProduction/Home . > This, surely, is a good example of beating a dead horse. Would > anyone disagree with the points he makes? I wouldn't, > in the broad. TEI _is_ needlessly complicated for most publishing workflows. > But Poughkeepsie never said it was designed for that > ("... a standard format for data interchange..."). exactly. FWIW, somewhere I used to have a copy of a great presentation from Brian Reid, inventor of Scribe, one of the first descriptive markup languages, in which he too claims a Pauline conversion about the uselessness of descriptive markup in the publishing context. This horse is not just dead, it's pushing up the daisies. on a more positive note, here are some other Big10 people i think might be able to give a more positive note to the proceedings (they're all people we saw recently in Chicago for the Symposium Martin organised in November, so he may well be able to suggest more) -- Allen Renear -- Brian Pitzig (spelling? worked with Martin on Monk) -- Doug Reside (OK, not a big ten person) -- Perry Willett > -- > Sebastian Rahtz > Information and Support Group Manager, Oxford University Computing Services > 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 > > S?lo le pido a Dios > que el futuro no me sea indiferente > > > > > > _______________________________________________ > tei-council mailing list > tei-council at lists.village.Virginia.EDU > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council > > PLEASE NOTE: postings to this list are publicly archived From sebastian.rahtz at oucs.ox.ac.uk Tue Jan 18 17:11:49 2011 From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz) Date: Tue, 18 Jan 2011 22:11:49 +0000 Subject: [tei-council] Council meeting in April - Symposium on 11. April In-Reply-To: <4D360DD8.1000705@oucs.ox.ac.uk> References: <4D360AE8.9060504@ultraslavonic.info> <4D360DD8.1000705@oucs.ox.ac.uk> Message-ID: On 18 Jan 2011, at 22:02, Lou Burnard wrote: > > at http://www.tei-c.org/Vault/ED/edp01.htm (which includes the > Poughkeepsie Principles and comments on them) > epic fail.