From kevin.s.hawkins at ultraslavonic.info  Tue Jan  3 19:30:25 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Tue, 03 Jan 2012 19:30:25 -0500
Subject: [tei-council] namespaces and customization
In-Reply-To: <9CDC2137-B222-4CAD-8AB5-9266A4CE050E@oucs.ox.ac.uk>
References: <4EEE7722.7090407@ultraslavonic.info> <4EEEAF50.6080902@uvic.ca>
	<4EEEFCA9.4070007@oucs.ox.ac.uk>
	<9CDC2137-B222-4CAD-8AB5-9266A4CE050E@oucs.ox.ac.uk>
Message-ID: <4F039DA1.6000503@ultraslavonic.info>

On 12/19/11 4:11 AM, Sebastian Rahtz wrote:
>
> On 19 Dec 2011, at 08:58, James Cummings wrote:
>> TEI, unless these attributes are in a non-TEI namespace. So you could
>> add @my:type and @my:subtype to 'eg' and be perfectly TEI conformant,
>> but adding att.typed to 'eg' is an unclean change and thus should be
>> signalled by a namespace.
>
>
> Amen to that.
>
> Why do want @type on<eg>  anyway?  consider using the excellent<exemplum>  wrapper
> for the job instead.

I was just using the example given in P5 section 23.2.1.4 (#MDMDAL).  I 
didn't want to confuse the matter by introducing a different use case.

However, if @type on <eg> is nonsensical, then I think a revision of 
32.2.1.4 is in order.

From kevin.s.hawkins at ultraslavonic.info  Tue Jan  3 19:41:27 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Tue, 03 Jan 2012 19:41:27 -0500
Subject: [tei-council] namespaces and customization
In-Reply-To: <2F747CFF-96AF-41AC-9EA3-A4A0127F63EB@inria.fr>
References: <4EEE7722.7090407@ultraslavonic.info> <4EEEAF50.6080902@uvic.ca>
	<4EEEFCA9.4070007@oucs.ox.ac.uk>
	<2F747CFF-96AF-41AC-9EA3-A4A0127F63EB@inria.fr>
Message-ID: <4F03A037.7050903@ultraslavonic.info>

Like James, I read the intention of P5 that way: that you're supposed to 
use a namespace for anything that's not a pure subset.  But it's not 
entirely clear to me that this was really the intention -- see my 
original message in this thread.  I questioned this reading because I 
share Martin's questioning that every simple modification -- say, of 
adding a @type to an element -- requires moving it out of the TEI namespace.

At the least I would like to see the intention clarified in P5, and at 
the most I would like us to revisit the intention.  I'm not sure the 
intention is wrong, but I'm not sure it's right either.  If we are 
revisiting the intention, it would be worth talking to Bryan 
Pytlik-Zillig and/or others who have done work on normalizing documents. 
  I wonder whether they would find use of a new namespace useful or a 
hassle.

On 12/19/11 4:05 AM, Laurent Romary wrote:
> Still, I understand Martin's worry and if we think formally of cleanness as subsumption (along a relation is-more constrained-than) than adding eg to att.typed could be seen as clean (any processor with a TEI-all coverage would not have a problem with this, it would just not "see" the corresponding attributes). I let the future council chair to lead this discussion next year :-}
> Laurent
>
> Le 19 d?c. 2011 ? 09:58, James Cummings a ?crit :
>
>> On 19/12/11 03:28, Martin Holmes wrote:
>>> That's a very good question. Personally, I wouldn't have thought that
>>> customizing an existing element would require moving it to a new
>>> namespace -- unless you changed it beyond all recognition, but in that
>>> case I would have thought giving it a new name would make more sense.
>>> Surely just adding tei:eg to att,typed wouldn't require moving it out of
>>> the tei: namespace?
>>
>> I think that is exactly the intention. If you add something to an
>> element making it not a pure subset of the original element (conformant)
>> or automatically able to be cleanly reversed (conformable) then it is no
>> longer the TEI element as the TEI has defined it. Thus should be in a
>> new namespace. You don't want to have something that purports to be a
>> TEI 'eg' element but has lots of attributes which it doesn't have in the
>> TEI, unless these attributes are in a non-TEI namespace. So you could
>> add @my:type and @my:subtype to 'eg' and be perfectly TEI conformant,
>> but adding att.typed to 'eg' is an unclean change and thus should be
>> signalled by a namespace.
>>
>> I believe that was the thinking at least,
>>
>> -James
>>
>>
>>>
>>> Cheers,
>>> Martin
>>>
>>> On 11-12-18 03:28 PM, Kevin Hawkins wrote:
>>>>       From reading chapter 23 of the Guidelines, I'm unclear on whether you
>>>> are supposed to define a new namespace for every element or attribute
>>>> affected by an unclean customization.  I don't see it explicitly stated,
>>>> but it sounds that way.  For example, in section 23.2.1.5,<tei:eg>    is
>>>> modified to add it to att.typed, but as I understand it, the element
>>>> then moves into a new namespace (http://example.com/ns).  So each
>>>> instance of<eg>    should actually be<myNamepsace:eg>    instead of
>>>> <tei:eg>.  Is that right?
>>>>
>>>> Furthermore, I see this sentence in section 23.2.2, after a discussion
>>>> of definining a namespace:
>>>>
>>>> "Similar methods may be used if a modification (clean or unclean) is
>>>> made to the content model or some other aspect of an element, or if it
>>>> declares a new element."
>>>>
>>>> In what cases would you define a new namespace for a clean customization
>>>> of an element?
>>>>
>>>> --Kevin
>>
>>
>> --
>> Dr James Cummings, InfoDev,
>> Computing Services, University of Oxford
>> --
>> tei-council mailing list
>> tei-council at lists.village.Virginia.EDU
>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>>
>> PLEASE NOTE: postings to this list are publicly archived
>
> Laurent Romary
> INRIA&  HUB-IDSL
> laurent.romary at inria.fr
>
>
>

From sebastian.rahtz at oucs.ox.ac.uk  Wed Jan  4 05:44:47 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Wed, 4 Jan 2012 10:44:47 +0000
Subject: [tei-council] namespaces and customization
In-Reply-To: <4F03A037.7050903@ultraslavonic.info>
References: <4EEE7722.7090407@ultraslavonic.info> <4EEEAF50.6080902@uvic.ca>
	<4EEEFCA9.4070007@oucs.ox.ac.uk>
	<2F747CFF-96AF-41AC-9EA3-A4A0127F63EB@inria.fr>
	<4F03A037.7050903@ultraslavonic.info>
Message-ID: <979AA259-8B0D-4559-8189-190EC010F46E@oucs.ox.ac.uk>


On 4 Jan 2012, at 00:41, Kevin Hawkins wrote:

> At the least I would like to see the intention clarified in P5, and at 
> the most I would like us to revisit the intention.  I'm not sure the 
> intention is wrong, but I'm not sure it's right either.  If we are 
> revisiting the intention, it would be worth talking to Bryan 
> Pytlik-Zillig and/or others who have done work on normalizing documents. 
>  I wonder whether they would find use of a new namespace useful or a 
> hassle.

surely large-scale normalization projects such as that which B P-Z
works on should be the last to make casual modifications to TEI, however
simple? they have the time and the resource to do it right, ie work out
with the TEI what the best way to work is, and to get changes in the TEI
if needed. As TCP is doing now (belatedly, sorry, Paul and Rebecca!).
--
Stormageddon Rahtz      
Head of Information and Support Group, Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431

S?lo le pido a Dios
que el futuro no me sea indiferente


From sebastian.rahtz at oucs.ox.ac.uk  Wed Jan  4 05:49:05 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Wed, 4 Jan 2012 10:49:05 +0000
Subject: [tei-council] namespaces and customization
In-Reply-To: <4F039DA1.6000503@ultraslavonic.info>
References: <4EEE7722.7090407@ultraslavonic.info> <4EEEAF50.6080902@uvic.ca>
	<4EEEFCA9.4070007@oucs.ox.ac.uk>
	<9CDC2137-B222-4CAD-8AB5-9266A4CE050E@oucs.ox.ac.uk>
	<4F039DA1.6000503@ultraslavonic.info>
Message-ID: <07238135-C143-48A2-9A26-CA7586D7F090@oucs.ox.ac.uk>


On 4 Jan 2012, at 00:30, Kevin Hawkins wrote:

> I was just using the example given in P5 section 23.2.1.4 (#MDMDAL).  I 
> didn't want to confuse the matter by introducing a different use case.
> 
> However, if @type on <eg> is nonsensical, then I think a revision of 
> 32.2.1.4 is in order.

I looked at 33.2.1 today, and see that the relevant example is

<elementSpec
  ident="eg"
  module="tagdocs"
  mode="change"
  ns="http://example.com/ns">
 <classes mode="change">
  <memberOf key="att.typed"/>
 </classes>
</elementSpec>

which is a bit worrying, as a) it does not work, and b) is probably barking up the wrong tree.
do we really think we can move <eg> to a different namespace like this, in
change mode?

but the ostensible reading there _does_ say that the changed <eg> will not be in
the TEI namespace....

I am looking to see why it does not work.

--
Stormageddon Rahtz      
Head of Information and Support Group, Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431

S?lo le pido a Dios
que el futuro no me sea indiferente


From sebastian.rahtz at oucs.ox.ac.uk  Wed Jan  4 05:53:47 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Wed, 4 Jan 2012 10:53:47 +0000
Subject: [tei-council] namespaces and customization
In-Reply-To: <07238135-C143-48A2-9A26-CA7586D7F090@oucs.ox.ac.uk>
References: <4EEE7722.7090407@ultraslavonic.info> <4EEEAF50.6080902@uvic.ca>
	<4EEEFCA9.4070007@oucs.ox.ac.uk>
	<9CDC2137-B222-4CAD-8AB5-9266A4CE050E@oucs.ox.ac.uk>
	<4F039DA1.6000503@ultraslavonic.info>
	<07238135-C143-48A2-9A26-CA7586D7F090@oucs.ox.ac.uk>
Message-ID: <E5EA2A75-8908-42C6-8422-F32824FBFCB6@oucs.ox.ac.uk>


On 4 Jan 2012, at 10:49, Sebastian Rahtz wrote:

> I looked at 33.2.1 today, and see that the relevant example is
> 
> <elementSpec
>  ident="eg"
>  module="tagdocs"
>  mode="change"
>  ns="http://example.com/ns">
> <classes mode="change">
>  <memberOf key="att.typed"/>
> </classes>
> </elementSpec>



this is not, I now understand, doing what it might appear. I claim
it says that "the element <eg> which is in the namespace http://example.com/ns
is to changed". NOT " the element <eg> is to be changed to appear in the
namespace http://example.com/ns". Big difference.

Do others agree that this is how that @ns should be read? its now
I have implemented it at least.
--
Stormageddon Rahtz      
Head of Information and Support Group, Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431

S?lo le pido a Dios
que el futuro no me sea indiferente


From laurent.romary at inria.fr  Wed Jan  4 06:10:48 2012
From: laurent.romary at inria.fr (Laurent Romary)
Date: Wed, 4 Jan 2012 12:10:48 +0100
Subject: [tei-council] Au revoir!
Message-ID: <D7523FA4-FE71-482F-B7B5-3C7F74FAD1AC@inria.fr>

Hi there,
This is 4 days overdue, but I need to leave now ;-) (David, can you plug me out?)

Many, many thanks to everyone for the excellent work carried out over the last 4 years and in particular for all the things I have learnt in your presence. The most enriching experience ever...

Laurent

From lou.burnard at retired.ox.ac.uk  Wed Jan  4 06:16:06 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Wed, 04 Jan 2012 11:16:06 +0000
Subject: [tei-council] namespaces and customization
In-Reply-To: <E5EA2A75-8908-42C6-8422-F32824FBFCB6@oucs.ox.ac.uk>
References: <4EEE7722.7090407@ultraslavonic.info>
	<4EEEAF50.6080902@uvic.ca>	<4EEEFCA9.4070007@oucs.ox.ac.uk>	<9CDC2137-B222-4CAD-8AB5-9266A4CE050E@oucs.ox.ac.uk>	<4F039DA1.6000503@ultraslavonic.info>	<07238135-C143-48A2-9A26-CA7586D7F090@oucs.ox.ac.uk>
	<E5EA2A75-8908-42C6-8422-F32824FBFCB6@oucs.ox.ac.uk>
Message-ID: <4F0434F6.9080904@retired.ox.ac.uk>

On 04/01/12 10:53, Sebastian Rahtz wrote:
>
> On 4 Jan 2012, at 10:49, Sebastian Rahtz wrote:
>
>> I looked at 33.2.1 today, and see that the relevant example is
>>
>> <elementSpec
>>   ident="eg"
>>   module="tagdocs"
>>   mode="change"
>>   ns="http://example.com/ns">
>> <classes mode="change">
>>   <memberOf key="att.typed"/>
>> </classes>
>> </elementSpec>
>
>
>
> this is not, I now understand, doing what it might appear. I claim
> it says that "the element<eg>  which is in the namespace http://example.com/ns
> is to changed". NOT " the element<eg>  is to be changed to appear in the
> namespace http://example.com/ns". Big difference.
>
> Do others agree that this is how that @ns should be read? its now
> I have implemented it at least.
>

Yes, I can see the logic of this, and I think you are probably right. 
However, it leaves us with an outstanding requirement: how do I say 
"this new element in this name space is cloned from an existing TEI 
element but has these modifications"?  This is not an unreasonable 
requirement. We could say "tough, you have to copy the existing spec and 
tweak it" but that won't win us any friends.

From sebastian.rahtz at oucs.ox.ac.uk  Wed Jan  4 07:08:35 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Wed, 4 Jan 2012 12:08:35 +0000
Subject: [tei-council] namespaces and customization
In-Reply-To: <4F0434F6.9080904@retired.ox.ac.uk>
References: <4EEE7722.7090407@ultraslavonic.info>	<4EEEAF50.6080902@uvic.ca>
	<4EEEFCA9.4070007@oucs.ox.ac.uk>
	<9CDC2137-B222-4CAD-8AB5-9266A4CE050E@oucs.ox.ac.uk>
	<4F039DA1.6000503@ultraslavonic.info>
	<07238135-C143-48A2-9A26-CA7586D7F090@oucs.ox.ac.uk>
	<E5EA2A75-8908-42C6-8422-F32824FBFCB6@oucs.ox.ac.uk>
	<4F0434F6.9080904@retired.ox.ac.uk>
Message-ID: <55D02CD2-121F-467E-9F9E-F3C29FE2FD97@oucs.ox.ac.uk>


On 4 Jan 2012, at 11:16, Lou Burnard wrote:

> However, it leaves us with an outstanding requirement: how do I say 
> "this new element in this name space is cloned from an existing TEI 
> element but has these modifications"?  This is not an unreasonable 
> requirement. We could say "tough, you have to copy the existing spec and 
> tweak it" but that won't win us any friends.

ah, now if we had a requirements document for ODD, 
we'd be in a lot stronger position. But lets make what we've got now
internally consistent. If you agree with my interpretation of elementSpec/@ns,
then the Gidlines example is very very misleading (not _wrong_, exactly...)

which of us wrote that passage which confused Kevin? it talks
about how to add an element to att.typed as an example, but
fails to point out that this makes the doc non-TEI (or so some
of us claim).

--
Stormageddon Rahtz      
Head of Information and Support Group, Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431

S?lo le pido a Dios
que el futuro no me sea indiferente


From dsewell at virginia.edu  Wed Jan  4 10:37:15 2012
From: dsewell at virginia.edu (David Sewell)
Date: Wed, 4 Jan 2012 10:37:15 -0500 (EST)
Subject: [tei-council] TEI Council webpage updated
Message-ID: <alpine.OSX.2.00.1201041034120.51960@lister.ei.virginia.edu>

Dear Council members,

I have updated the TEI Council page at 
http://www.tei-c.org/Activities/Council/index.xml to reflect the changes in 
membership for 2012.

Could everyone please check their listing and send me any corrections (including 
the hyperlinks)? Also, for consistency, it would be preferable to provide a 
title + affiliation for everyone, so let me know how you would like to be listed
(e.g.: "John Doe, Professor of Overlapping Hierarchies, University of Southern 
North Dakota at Hoople").

Thanks,
David

-- 
David Sewell, Editorial and Technical Manager
ROTUNDA, The University of Virginia Press
PO Box 400314, Charlottesville, VA 22904-4314 USA
Email: dsewell at virginia.edu   Tel: +1 434 924 9973
Web: http://rotunda.upress.virginia.edu/

From lou.burnard at retired.ox.ac.uk  Thu Jan  5 14:44:30 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Thu, 05 Jan 2012 19:44:30 +0000
Subject: [tei-council] namespaces and customization
In-Reply-To: <55D02CD2-121F-467E-9F9E-F3C29FE2FD97@oucs.ox.ac.uk>
References: <4EEE7722.7090407@ultraslavonic.info>	<4EEEAF50.6080902@uvic.ca>
	<4EEEFCA9.4070007@oucs.ox.ac.uk>
	<9CDC2137-B222-4CAD-8AB5-9266A4CE050E@oucs.ox.ac.uk>
	<4F039DA1.6000503@ultraslavonic.info>
	<07238135-C143-48A2-9A26-CA7586D7F090@oucs.ox.ac.uk>
	<E5EA2A75-8908-42C6-8422-F32824FBFCB6@oucs.ox.ac.uk>
	<4F0434F6.9080904@retired.ox.ac.uk>
	<55D02CD2-121F-467E-9F9E-F3C29FE2FD97@oucs.ox.ac.uk>
Message-ID: <4F05FD9E.7080102@retired.ox.ac.uk>

On 04/01/12 12:08, Sebastian Rahtz wrote:
>
> On 4 Jan 2012, at 11:16, Lou Burnard wrote:
>
>> However, it leaves us with an outstanding requirement: how do I say
>> "this new element in this name space is cloned from an existing TEI
>> element but has these modifications"?  This is not an unreasonable
>> requirement. We could say "tough, you have to copy the existing spec and
>> tweak it" but that won't win us any friends.
>
> ah, now if we had a requirements document for ODD,
> we'd be in a lot stronger position.

I dont think you need much of a reqts doc to understand that people 
might reasonably want to use the TEI  class system in this way

But lets make what we've got now
> internally consistent. If you agree with my interpretation of elementSpec/@ns,
> then the Gidlines example is very very misleading (not _wrong_, exactly...)
>

Agree on that. But it *is* misleading -- unless you now also claim that 
the flopsy example (in #MDNS) is wrong, we have a situation where @ns 
means one thing when @mode="add" and another, quite different, thing 
when it doesnt.

> which of us wrote that passage which confused Kevin? it talks
> about how to add an element to att.typed as an example, but
> fails to point out that this makes the doc non-TEI (or so some
> of us claim).

Who knows. Probably me, sigh, but I bet you had a hand in it too.

From sebastian.rahtz at oucs.ox.ac.uk  Thu Jan  5 14:59:02 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Thu, 5 Jan 2012 19:59:02 +0000
Subject: [tei-council] namespaces and customization
In-Reply-To: <4F05FD9E.7080102@retired.ox.ac.uk>
References: <4EEE7722.7090407@ultraslavonic.info>	<4EEEAF50.6080902@uvic.ca>
	<4EEEFCA9.4070007@oucs.ox.ac.uk>
	<9CDC2137-B222-4CAD-8AB5-9266A4CE050E@oucs.ox.ac.uk>
	<4F039DA1.6000503@ultraslavonic.info>
	<07238135-C143-48A2-9A26-CA7586D7F090@oucs.ox.ac.uk>
	<E5EA2A75-8908-42C6-8422-F32824FBFCB6@oucs.ox.ac.uk>
	<4F0434F6.9080904@retired.ox.ac.uk>
	<55D02CD2-121F-467E-9F9E-F3C29FE2FD97@oucs.ox.ac.uk>
	<4F05FD9E.7080102@retired.ox.ac.uk>
Message-ID: <9B23E49F-89F9-4579-A76A-4FF43F1E28C2@oucs.ox.ac.uk>

On 5 Jan 2012, at 19:44, Lou Burnard wrote:

> 
> Agree on that. But it *is* misleading -- unless you now also claim that 
> the flopsy example (in #MDNS) is wrong, we have a situation where @ns 
> means one thing when @mode="add" and another, quite different, thing 
> when it doesnt.

tricky. I don't see an easy way to resolve that.

but I take consolation from the fact that no-one has
noticed the problem so far as we know.
--
Stormageddon Rahtz      
Head of Information and Support Group, Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431

S?lo le pido a Dios
que el futuro no me sea indiferente


From kevin.s.hawkins at ultraslavonic.info  Fri Jan  6 21:26:29 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Fri, 06 Jan 2012 21:26:29 -0500
Subject: [tei-council] namespaces and customization
In-Reply-To: <979AA259-8B0D-4559-8189-190EC010F46E@oucs.ox.ac.uk>
References: <4EEE7722.7090407@ultraslavonic.info> <4EEEAF50.6080902@uvic.ca>
	<4EEEFCA9.4070007@oucs.ox.ac.uk>
	<2F747CFF-96AF-41AC-9EA3-A4A0127F63EB@inria.fr>
	<4F03A037.7050903@ultraslavonic.info>
	<979AA259-8B0D-4559-8189-190EC010F46E@oucs.ox.ac.uk>
Message-ID: <4F07AD55.3040009@ultraslavonic.info>

On 1/4/12 5:44 AM, Sebastian Rahtz wrote:
>
> On 4 Jan 2012, at 00:41, Kevin Hawkins wrote:
>
>> At the least I would like to see the intention clarified in P5, and at
>> the most I would like us to revisit the intention.  I'm not sure the
>> intention is wrong, but I'm not sure it's right either.  If we are
>> revisiting the intention, it would be worth talking to Bryan
>> Pytlik-Zillig and/or others who have done work on normalizing documents.
>>   I wonder whether they would find use of a new namespace useful or a
>> hassle.
>
> surely large-scale normalization projects such as that which B P-Z
> works on should be the last to make casual modifications to TEI, however
> simple? they have the time and the resource to do it right, ie work out
> with the TEI what the best way to work is, and to get changes in the TEI
> if needed. As TCP is doing now (belatedly, sorry, Paul and Rebecca!).

What I meant is to suppose that Brian inherited a few sets of documents 
using a customization of the TEI.  Some customized but used the TEI 
namespace for everything, whereas others created a new namespace for 
every non-subsetting customization.  Which would be preferrable to 
someone normalizing these various sets of documents to do data mining 
across the sets?

From kevin.s.hawkins at ultraslavonic.info  Fri Jan  6 21:33:27 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Fri, 06 Jan 2012 21:33:27 -0500
Subject: [tei-council] namespaces and customization
In-Reply-To: <E5EA2A75-8908-42C6-8422-F32824FBFCB6@oucs.ox.ac.uk>
References: <4EEE7722.7090407@ultraslavonic.info> <4EEEAF50.6080902@uvic.ca>
	<4EEEFCA9.4070007@oucs.ox.ac.uk>
	<9CDC2137-B222-4CAD-8AB5-9266A4CE050E@oucs.ox.ac.uk>
	<4F039DA1.6000503@ultraslavonic.info>
	<07238135-C143-48A2-9A26-CA7586D7F090@oucs.ox.ac.uk>
	<E5EA2A75-8908-42C6-8422-F32824FBFCB6@oucs.ox.ac.uk>
Message-ID: <4F07AEF7.3050704@ultraslavonic.info>

There's a few typos here, so I want to check that I'm understanding them 
correctly ...

On 1/4/12 5:53 AM, Sebastian Rahtz wrote:
>
> On 4 Jan 2012, at 10:49, Sebastian Rahtz wrote:
>
>> I looked at 33.2.1 today, and see that the relevant example is
>>
>> <elementSpec
>>   ident="eg"
>>   module="tagdocs"
>>   mode="change"
>>   ns="http://example.com/ns">
>> <classes mode="change">
>>   <memberOf key="att.typed"/>
>> </classes>
>> </elementSpec>
>
>
>
> this is not, I now understand, doing what it might appear. I claim
> it says that "the element<eg>  which is in the namespace http://example.com/ns
> is to changed". NOT " the element<eg>  is to be changed to appear in the
> namespace http://example.com/ns". Big difference.

I think this should read "which is in the namespace 
http://example.com/ns is to BE changed".

> Do others agree that this is how that @ns should be read? its now
> I have implemented it at least.

I also read it the first way, not the second.

I think the second sentence should read "it's how I have implemented it 
at least".

From mholmes at uvic.ca  Mon Jan  9 08:55:01 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Mon, 09 Jan 2012 05:55:01 -0800
Subject: [tei-council] Report on 2011
Message-ID: <4F0AF1B5.7030005@uvic.ca>

Hi all,

I guess we have to provide a Report on Current Work for 2011:

<http://www.tei-c.org/Activities/Council/Reports/>

It looks like this is usually presented to the board by the chair. 
James, are you going to do this, and if so, is there anything we can do 
to help?

Cheers,
Martin

From dsewell at virginia.edu  Mon Jan  9 09:11:47 2012
From: dsewell at virginia.edu (David Sewell)
Date: Mon, 9 Jan 2012 09:11:47 -0500 (EST)
Subject: [tei-council] Report on 2011
In-Reply-To: <4F0AF1B5.7030005@uvic.ca>
References: <4F0AF1B5.7030005@uvic.ca>
Message-ID: <alpine.OSX.2.00.1201090911090.12014@lister.ei.virginia.edu>

Actually, Dan O'Donnell has provided the slides from the report presented at the 
Members Meeting:

http://www.tei-c.org/Membership/Meetings/2011/BusinessMeeting_Hosts.pdf

I neglected to add the link to it from the Reports page. I will do that now.

David

On Mon, 9 Jan 2012, Martin Holmes wrote:

> Hi all,
>
> I guess we have to provide a Report on Current Work for 2011:
>
> <http://www.tei-c.org/Activities/Council/Reports/>
>
> It looks like this is usually presented to the board by the chair.
> James, are you going to do this, and if so, is there anything we can do
> to help?
>
> Cheers,
> Martin
>

-- 
David Sewell, Editorial and Technical Manager
ROTUNDA, The University of Virginia Press
PO Box 400314, Charlottesville, VA 22904-4314 USA
Email: dsewell at virginia.edu   Tel: +1 434 924 9973
Web: http://rotunda.upress.virginia.edu/

From lou.burnard at retired.ox.ac.uk  Mon Jan  9 09:13:16 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Mon, 09 Jan 2012 14:13:16 +0000
Subject: [tei-council] Report on 2011
In-Reply-To: <alpine.OSX.2.00.1201090911090.12014@lister.ei.virginia.edu>
References: <4F0AF1B5.7030005@uvic.ca>
	<alpine.OSX.2.00.1201090911090.12014@lister.ei.virginia.edu>
Message-ID: <4F0AF5FC.1030800@retired.ox.ac.uk>

But that's the Board report, not the Council report, shirley?

On 09/01/12 14:11, David Sewell wrote:
> Actually, Dan O'Donnell has provided the slides from the report presented at the
> Members Meeting:
>
> http://www.tei-c.org/Membership/Meetings/2011/BusinessMeeting_Hosts.pdf
>
> I neglected to add the link to it from the Reports page. I will do that now.
>
> David
>
> On Mon, 9 Jan 2012, Martin Holmes wrote:
>
>> Hi all,
>>
>> I guess we have to provide a Report on Current Work for 2011:
>>
>> <http://www.tei-c.org/Activities/Council/Reports/>
>>
>> It looks like this is usually presented to the board by the chair.
>> James, are you going to do this, and if so, is there anything we can do
>> to help?
>>
>> Cheers,
>> Martin
>>
>


From dsewell at virginia.edu  Mon Jan  9 09:17:02 2012
From: dsewell at virginia.edu (David Sewell)
Date: Mon, 9 Jan 2012 09:17:02 -0500 (EST)
Subject: [tei-council] Report on 2011
In-Reply-To: <4F0AF5FC.1030800@retired.ox.ac.uk>
References: <4F0AF1B5.7030005@uvic.ca>
	<alpine.OSX.2.00.1201090911090.12014@lister.ei.virginia.edu>
	<4F0AF5FC.1030800@retired.ox.ac.uk>
Message-ID: <alpine.OSX.2.00.1201090916320.12014@lister.ei.virginia.edu>

Sorry, coffee has not kicked in yet this morning. The proper link is to

http://www.tei-c.org/Membership/Meetings/2011/TEICouncilReport2011.pdf

and it is now up on the Reports page

http://www.tei-c.org/Activities/Council/Reports/

On Mon, 9 Jan 2012, Lou Burnard wrote:

> But that's the Board report, not the Council report, shirley?
>
> On 09/01/12 14:11, David Sewell wrote:
>> Actually, Dan O'Donnell has provided the slides from the report presented at the
>> Members Meeting:
>>
>> http://www.tei-c.org/Membership/Meetings/2011/BusinessMeeting_Hosts.pdf
>>
>> I neglected to add the link to it from the Reports page. I will do that now.
>>
>> David
>>
>> On Mon, 9 Jan 2012, Martin Holmes wrote:
>>
>>> Hi all,
>>>
>>> I guess we have to provide a Report on Current Work for 2011:
>>>
>>> <http://www.tei-c.org/Activities/Council/Reports/>
>>>
>>> It looks like this is usually presented to the board by the chair.
>>> James, are you going to do this, and if so, is there anything we can do
>>> to help?
>>>
>>> Cheers,
>>> Martin
>>>
>>
>
>

-- 
David Sewell, Editorial and Technical Manager
ROTUNDA, The University of Virginia Press
PO Box 400314, Charlottesville, VA 22904-4314 USA
Email: dsewell at virginia.edu   Tel: +1 434 924 9973
Web: http://rotunda.upress.virginia.edu/

From gabriel.bodard at kcl.ac.uk  Tue Jan 10 11:30:30 2012
From: gabriel.bodard at kcl.ac.uk (Gabriel Bodard)
Date: Tue, 10 Jan 2012 16:30:30 +0000
Subject: [tei-council] Bug: make geo declaring
Message-ID: <4F0C67A6.4010400@kcl.ac.uk>

Dear Councillors,

A reminder of a bug ticket that was submitted last November (just too 
late to make it into the last release, apparently), suggesting that 
<geo> be added to att.declaring:

http://purl.org/TEI/BUGS/3440771

If everyone is agreeable, I'm happy to go ahead and make this change in 
the source. (I know it won't be released for a while now, but if I do it 
now we won't forget in future.)

Best,

Gabby

-- 
Dr Gabriel BODARD
(Research Associate in Digital Epigraphy)

Department of Digital Humanities
King's College London
26-29 Drury Lane
London WC2B 5RL

Email: gabriel.bodard at kcl.ac.uk
Tel: +44 (0)20 7848 1388
Fax: +44 (0)20 7848 2980

http://www.digitalclassicist.org/
http://www.currentepigraphy.org/

From James.Cummings at oucs.ox.ac.uk  Tue Jan 10 18:25:00 2012
From: James.Cummings at oucs.ox.ac.uk (James Cummings)
Date: Tue, 10 Jan 2012 23:25:00 +0000
Subject: [tei-council] TEI Technical Council Budget 2012
Message-ID: <4F0CC8CC.7070700@oucs.ox.ac.uk>

Dear TEI Technical Council,

This afternoon at the TEI Board teleconference our proposed budget for 
two council meetings got (as far as I could tell) unanimous support.

In fact it was decided that (as had been proposed at the w?rzburg 
meeting) that Council would be given a $38K USD budget, with the 
understanding that around ~22K of this would be spent on travel and 
subsistence for the two Council meetings as we had budgeted, and that 
we/I would prepare a more detailed budget for what we wanted to spend 
the rest on. This is good news in that we now know for sure that our two 
planned meetings will go ahead (and we can start making more 
arrangements) and that we should be able to funding some additional 
development work or meetings.

The 'other potential activities' that I very vaguely described were:

a) Paying for some additional people to attend the Ann Arbor meeting 
specifically if we needed more input on ECCO/EEBO-TCP 
conversion/rationalization (I was thinking MartinM or BrianPZ but have 
not approached them), but I wonder if this is still as important as 
we've solved a lot of the problems.

b) Subsidising a couple extra nights of hotel for several people to 
participate in a workshop designing improvements for ODD3 after DH2012. 
(I have put in a Future of ODD panel session that includes Lou Burnard, 
Syd Baumann, Bertrand Gaiffe, Sebastian Rahtz, and Laurent Romary/Piotr 
Ba?ski). If that is accepted then we'd try to get these and some others 
as well and offer to pay a couple nights hotel (if needed) to keep them 
on a couple days and maybe room costs if we can't get one free.

c) Web-Roma redevelopment bounty. This was the idea that we need a new 
community-developed web-roma (not developed/maintained by Oxford) and 
that we might put some money towards encouraging/kickstarting a group in 
creating this.

d) Another idea was to try to fund an entirely new processing 
implementation of ODD2+ that is completely independent of the existing 
XSLT. But this is problematic to budget.

e) General code bounty: We could come up with a list of much smaller 
development or other technical projects that are much more easily 
implemented and sufficiently useful to the TEI-C or Community.

f) Any other ideas?

I'm quite in favour of b) and c) as I believe these respectively lead to 
the future development of the TEI and its ongoing sustainability.

Thoughts?

-James

-- 
Dr James Cummings, InfoDev,
Computing Services, University of Oxford

From sebastian.rahtz at oucs.ox.ac.uk  Wed Jan 11 12:13:45 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Wed, 11 Jan 2012 17:13:45 +0000
Subject: [tei-council] adblock / msad
Message-ID: <D84B17E3-D804-409D-B127-02100250C6D3@oucs.ox.ac.uk>

assuming you all read TEI-L.

maybe we should rewrite all the ID/IDREFS in generated HTML to put "tei_" in front of them?
--
Stormageddon Rahtz      
Head of Information and Support Group
Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431

S?lo le pido a Dios
que el futuro no me sea indiferente


From lou.burnard at retired.ox.ac.uk  Wed Jan 11 13:53:38 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Wed, 11 Jan 2012 18:53:38 +0000
Subject: [tei-council] adblock / msad
In-Reply-To: <D84B17E3-D804-409D-B127-02100250C6D3@oucs.ox.ac.uk>
References: <D84B17E3-D804-409D-B127-02100250C6D3@oucs.ox.ac.uk>
Message-ID: <4F0DDAB2.5010503@retired.ox.ac.uk>

On 11/01/12 17:13, Sebastian Rahtz wrote:
> assuming you all read TEI-L.
>
> maybe we should rewrite all the ID/IDREFS in generated HTML to put "tei_" in front of them?
> --

Sounds like a very simple and effective solution to me. I say go for it, 
Stormy.


(I don't remember who it was said that the ID values in the XML source 
followed a consistent pattern, but I'll have some of what they've been 
drinking.)




From syeates at gmail.com  Wed Jan 11 14:08:22 2012
From: syeates at gmail.com (Stuart A. Yeates)
Date: Thu, 12 Jan 2012 08:08:22 +1300
Subject: [tei-council] adblock / msad
In-Reply-To: <4F0DDAB2.5010503@retired.ox.ac.uk>
References: <D84B17E3-D804-409D-B127-02100250C6D3@oucs.ox.ac.uk>
	<4F0DDAB2.5010503@retired.ox.ac.uk>
Message-ID: <CAC_Lu0ZuyLx_iOzzh_eTz-Czx46ctg5vuU7Fk=enTd0J0GqMNQ@mail.gmail.com>

On Thu, Jan 12, 2012 at 7:53 AM, Lou Burnard
<lou.burnard at retired.ox.ac.uk> wrote:
> On 11/01/12 17:13, Sebastian Rahtz wrote:
>> assuming you all read TEI-L.
>>
>> maybe we should rewrite all the ID/IDREFS in generated HTML to put "tei_" in front of them?
>> --
>
> Sounds like a very simple and effective solution to me. I say go for it,
> Stormy.
>
>
> (I don't remember who it was said that the ID values in the XML source
> followed a consistent pattern, but I'll have some of what they've been
> drinking.)

Sounds good to me.

cheers
stuart

From James.Cummings at oucs.ox.ac.uk  Wed Jan 11 17:09:20 2012
From: James.Cummings at oucs.ox.ac.uk (James Cummings)
Date: Wed, 11 Jan 2012 22:09:20 +0000
Subject: [tei-council] adblock / msad
In-Reply-To: <CAC_Lu0ZuyLx_iOzzh_eTz-Czx46ctg5vuU7Fk=enTd0J0GqMNQ@mail.gmail.com>
References: <D84B17E3-D804-409D-B127-02100250C6D3@oucs.ox.ac.uk>
	<4F0DDAB2.5010503@retired.ox.ac.uk>
	<CAC_Lu0ZuyLx_iOzzh_eTz-Czx46ctg5vuU7Fk=enTd0J0GqMNQ@mail.gmail.com>
Message-ID: <4F0E0890.40706@oucs.ox.ac.uk>


As Martin has posted on TEI-L the AdBlock filter creators seem to be 
responsive in changing the filter.  However, it might be a good idea to 
do this in any case.

However, my devil's advocate caveat still stands as a warning: We would 
be 'breaking' an awful lot of existing URLs that people might have 
bookmarked or referenced in publications.  'Breaking' because they'll 
still get the page, just not the right place on it.

-James


On 11/01/12 19:08, Stuart A. Yeates wrote:
> On Thu, Jan 12, 2012 at 7:53 AM, Lou Burnard
> <lou.burnard at retired.ox.ac.uk>  wrote:
>> On 11/01/12 17:13, Sebastian Rahtz wrote:
>>> assuming you all read TEI-L.
>>>
>>> maybe we should rewrite all the ID/IDREFS in generated HTML to put "tei_" in front of them?
>>> --
>>
>> Sounds like a very simple and effective solution to me. I say go for it,
>> Stormy.
>>
>>
>> (I don't remember who it was said that the ID values in the XML source
>> followed a consistent pattern, but I'll have some of what they've been
>> drinking.)
>
> Sounds good to me.
>
> cheers
> stuart


-- 
Dr James Cummings, InfoDev,
Computing Services, University of Oxford

From kevin.s.hawkins at ultraslavonic.info  Wed Jan 11 19:18:21 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Wed, 11 Jan 2012 19:18:21 -0500
Subject: [tei-council] TEI Technical Council Budget 2012
In-Reply-To: <4F0CC8CC.7070700@oucs.ox.ac.uk>
References: <4F0CC8CC.7070700@oucs.ox.ac.uk>
Message-ID: <4F0E26CD.1000101@ultraslavonic.info>

James,

Thanks for the update.  My thoughts ...

On 1/10/12 6:25 PM, James Cummings wrote:
> a) Paying for some additional people to attend the Ann Arbor meeting
> specifically if we needed more input on ECCO/EEBO-TCP
> conversion/rationalization (I was thinking MartinM or BrianPZ but have
> not approached them), but I wonder if this is still as important as
> we've solved a lot of the problems.

My recollection is that we did indeed solve most of the problems.  Even 
if there are outstanding issues about rationalization that Paul 
Schaffner (who will be attending as a Council member) can't answer for 
us, I imagine we could get Martin Mueller or Brian Pytlik Zillig on the 
phone or Skype to answer those questions.  They're both only one time 
zone away from Ann Arbor, so I can't imagine this will be difficult.

> b) Subsidising a couple extra nights of hotel for several people to
> participate in a workshop designing improvements for ODD3 after DH2012.
> (I have put in a Future of ODD panel session that includes Lou Burnard,
> Syd Baumann, Bertrand Gaiffe, Sebastian Rahtz, and Laurent Romary/Piotr
> Ba?ski). If that is accepted then we'd try to get these and some others
> as well and offer to pay a couple nights hotel (if needed) to keep them
> on a couple days and maybe room costs if we can't get one free.
>
> c) Web-Roma redevelopment bounty. This was the idea that we need a new
> community-developed web-roma (not developed/maintained by Oxford) and
> that we might put some money towards encouraging/kickstarting a group in
> creating this.

Like James, I am most interested in (b) and (c), but I am more 
interested in (c).  I believe that the TEI-C should better support the 
current ODD framework before we jump into developing another framework.

> d) Another idea was to try to fund an entirely new processing
> implementation of ODD2+ that is completely independent of the existing
> XSLT. But this is problematic to budget.

You mean fund a complete rewrite of Roma rather than a better Roma, as 
in (c)?

> e) General code bounty: We could come up with a list of much smaller
> development or other technical projects that are much more easily
> implemented and sufficiently useful to the TEI-C or Community.

We might suggest a few ideas, but opening this to the community for 
suggestions would be good too.  Kind of like the TEI community grants. 
Of course, with the community grants already out there, there might not 
really be a need to do (e) at all.

--Kevin

From bansp at o2.pl  Thu Jan 12 03:21:09 2012
From: bansp at o2.pl (=?ISO-8859-2?Q?Piotr_Ba=F1ski?=)
Date: Thu, 12 Jan 2012 09:21:09 +0100
Subject: [tei-council] TEI Technical Council Budget 2012
In-Reply-To: <4F0E26CD.1000101@ultraslavonic.info>
References: <4F0CC8CC.7070700@oucs.ox.ac.uk>
	<4F0E26CD.1000101@ultraslavonic.info>
Message-ID: <4F0E97F5.20601@o2.pl>

Just to add my 2 cents on top of this:

* +1 for (c),
* ODD2+ funding may present a clearer picture after Hamburg, if we ever
learn about DH's qualification results.

  P.

On 12/01/12 01:18, Kevin Hawkins wrote:
> James,
> 
> Thanks for the update.  My thoughts ...
> 
> On 1/10/12 6:25 PM, James Cummings wrote:
>> a) Paying for some additional people to attend the Ann Arbor meeting
>> specifically if we needed more input on ECCO/EEBO-TCP
>> conversion/rationalization (I was thinking MartinM or BrianPZ but have
>> not approached them), but I wonder if this is still as important as
>> we've solved a lot of the problems.
> 
> My recollection is that we did indeed solve most of the problems.  Even 
> if there are outstanding issues about rationalization that Paul 
> Schaffner (who will be attending as a Council member) can't answer for 
> us, I imagine we could get Martin Mueller or Brian Pytlik Zillig on the 
> phone or Skype to answer those questions.  They're both only one time 
> zone away from Ann Arbor, so I can't imagine this will be difficult.
> 
>> b) Subsidising a couple extra nights of hotel for several people to
>> participate in a workshop designing improvements for ODD3 after DH2012.
>> (I have put in a Future of ODD panel session that includes Lou Burnard,
>> Syd Baumann, Bertrand Gaiffe, Sebastian Rahtz, and Laurent Romary/Piotr
>> Ba?ski). If that is accepted then we'd try to get these and some others
>> as well and offer to pay a couple nights hotel (if needed) to keep them
>> on a couple days and maybe room costs if we can't get one free.
>>
>> c) Web-Roma redevelopment bounty. This was the idea that we need a new
>> community-developed web-roma (not developed/maintained by Oxford) and
>> that we might put some money towards encouraging/kickstarting a group in
>> creating this.
> 
> Like James, I am most interested in (b) and (c), but I am more 
> interested in (c).  I believe that the TEI-C should better support the 
> current ODD framework before we jump into developing another framework.
> 
>> d) Another idea was to try to fund an entirely new processing
>> implementation of ODD2+ that is completely independent of the existing
>> XSLT. But this is problematic to budget.
> 
> You mean fund a complete rewrite of Roma rather than a better Roma, as 
> in (c)?
> 
>> e) General code bounty: We could come up with a list of much smaller
>> development or other technical projects that are much more easily
>> implemented and sufficiently useful to the TEI-C or Community.
> 
> We might suggest a few ideas, but opening this to the community for 
> suggestions would be good too.  Kind of like the TEI community grants. 
> Of course, with the community grants already out there, there might not 
> really be a need to do (e) at all.
> 
> --Kevin


From sebastian.rahtz at oucs.ox.ac.uk  Thu Jan 12 04:12:23 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Thu, 12 Jan 2012 09:12:23 +0000
Subject: [tei-council] TEI Technical Council Budget 2012
In-Reply-To: <4F0E26CD.1000101@ultraslavonic.info>
References: <4F0CC8CC.7070700@oucs.ox.ac.uk>
	<4F0E26CD.1000101@ultraslavonic.info>
Message-ID: <2CADFB7D-C525-40A8-9012-B32A52E4A5E8@oucs.ox.ac.uk>


On 12 Jan 2012, at 00:18, Kevin Hawkins wrote:
> My recollection is that we did indeed solve most of the problems.  Even 
> if there are outstanding issues about rationalization that Paul 
> Schaffner (who will be attending as a Council member) can't answer for 
> us, I imagine we could get Martin Mueller or Brian Pytlik Zillig on the 
> phone or Skype to answer those questions.  They're both only one time 
> zone away from Ann Arbor, so I can't imagine this will be difficult.

I agree, it probably doesnt  need a full-scale session with MM and BPZ;
but we really should revisit the issue. There are certainly unsolved parts of the
equation - <signed> is one of those. Asking MM/BPZ to test 2.0.1 on their
conversions now would be important.

>> d) Another idea was to try to fund an entirely new processing
>> implementation of ODD2+ that is completely independent of the existing
>> XSLT. But this is problematic to budget.
> 
> You mean fund a complete rewrite of Roma rather than a better Roma, as 
> in ??

We need to agree on terminology  here. I think of "roma" as meaning
"user interface to ODD, with facilities to create and edit and odd, and 
call ODD -> XX processing". Note the "call" there. All the Roma-ish tools we
have now (Roma web, command-line, oxgarage, oxygen) all call the same
underlying XSLT library.   James' (d) is a rewrite of that backend library, but his
c) is a new Roma web (probably).

personally, I go for c), on the grounds that Web Roma is _definitely_ incomplete
and has errors, and definitely  has real users, now.

--
Stormageddon Rahtz      
Head of Information and Support Group
Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431

S?lo le pido a Dios
que el futuro no me sea indiferente


From gabriel.bodard at kcl.ac.uk  Thu Jan 12 06:44:50 2012
From: gabriel.bodard at kcl.ac.uk (Gabriel Bodard)
Date: Thu, 12 Jan 2012 11:44:50 +0000
Subject: [tei-council] Bug: make geo declaring
In-Reply-To: <4F0C67A6.4010400@kcl.ac.uk>
References: <4F0C67A6.4010400@kcl.ac.uk>
Message-ID: <4F0EC7B2.4020002@kcl.ac.uk>

There's been a little bit of discussion on the ticket, and it looks like 
we're more or less agreed that we could reasonable make both <geo> and 
<location> members of att.declaring. I'll implement this today if no one 
objects, but I thought I'd ask here if anyone wants to weigh in on the 
minor debate between Martin and myself first...

Cheers,

Gabby

On 2012-01-10 16:30, Gabriel Bodard wrote:
> Dear Councillors,
>
> A reminder of a bug ticket that was submitted last November (just too
> late to make it into the last release, apparently), suggesting that
> <geo>  be added to att.declaring:
>
> http://purl.org/TEI/BUGS/3440771
>
> If everyone is agreeable, I'm happy to go ahead and make this change in
> the source. (I know it won't be released for a while now, but if I do it
> now we won't forget in future.)
>
> Best,
>
> Gabby
>

-- 
Dr Gabriel BODARD
(Research Associate in Digital Epigraphy)

Department of Digital Humanities
King's College London
26-29 Drury Lane
London WC2B 5RL

Email: gabriel.bodard at kcl.ac.uk
Tel: +44 (0)20 7848 1388
Fax: +44 (0)20 7848 2980

http://www.digitalclassicist.org/
http://www.currentepigraphy.org/

From mholmes at uvic.ca  Thu Jan 12 08:17:57 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Thu, 12 Jan 2012 05:17:57 -0800
Subject: [tei-council] TEI Technical Council Budget 2012
In-Reply-To: <4F0E97F5.20601@o2.pl>
References: <4F0CC8CC.7070700@oucs.ox.ac.uk>	<4F0E26CD.1000101@ultraslavonic.info>
	<4F0E97F5.20601@o2.pl>
Message-ID: <4F0EDD85.2000308@uvic.ca>

+1 for (c) too. b) would be nice if I were going to DH2012, but I'm not 
(no funds); still, I should be able to attend virtually.

I think I like the idea of a code bounty too. One possible pilot for 
this is the XPointer implementations that our little XPointer group is 
talking about, although we don't seem to be able to agree on how or 
where such implementations might be done (XInclude processor? Pure XSLT? 
Saxon?).

Cheers,
Martin

On 12-01-12 12:21 AM, Piotr Ba?ski wrote:
> Just to add my 2 cents on top of this:
>
> * +1 for (c),
> * ODD2+ funding may present a clearer picture after Hamburg, if we ever
> learn about DH's qualification results.
>
>    P.
>
> On 12/01/12 01:18, Kevin Hawkins wrote:
>> James,
>>
>> Thanks for the update.  My thoughts ...
>>
>> On 1/10/12 6:25 PM, James Cummings wrote:
>>> a) Paying for some additional people to attend the Ann Arbor meeting
>>> specifically if we needed more input on ECCO/EEBO-TCP
>>> conversion/rationalization (I was thinking MartinM or BrianPZ but have
>>> not approached them), but I wonder if this is still as important as
>>> we've solved a lot of the problems.
>>
>> My recollection is that we did indeed solve most of the problems.  Even
>> if there are outstanding issues about rationalization that Paul
>> Schaffner (who will be attending as a Council member) can't answer for
>> us, I imagine we could get Martin Mueller or Brian Pytlik Zillig on the
>> phone or Skype to answer those questions.  They're both only one time
>> zone away from Ann Arbor, so I can't imagine this will be difficult.
>>
>>> b) Subsidising a couple extra nights of hotel for several people to
>>> participate in a workshop designing improvements for ODD3 after DH2012.
>>> (I have put in a Future of ODD panel session that includes Lou Burnard,
>>> Syd Baumann, Bertrand Gaiffe, Sebastian Rahtz, and Laurent Romary/Piotr
>>> Ba?ski). If that is accepted then we'd try to get these and some others
>>> as well and offer to pay a couple nights hotel (if needed) to keep them
>>> on a couple days and maybe room costs if we can't get one free.
>>>
>>> c) Web-Roma redevelopment bounty. This was the idea that we need a new
>>> community-developed web-roma (not developed/maintained by Oxford) and
>>> that we might put some money towards encouraging/kickstarting a group in
>>> creating this.
>>
>> Like James, I am most interested in (b) and (c), but I am more
>> interested in (c).  I believe that the TEI-C should better support the
>> current ODD framework before we jump into developing another framework.
>>
>>> d) Another idea was to try to fund an entirely new processing
>>> implementation of ODD2+ that is completely independent of the existing
>>> XSLT. But this is problematic to budget.
>>
>> You mean fund a complete rewrite of Roma rather than a better Roma, as
>> in (c)?
>>
>>> e) General code bounty: We could come up with a list of much smaller
>>> development or other technical projects that are much more easily
>>> implemented and sufficiently useful to the TEI-C or Community.
>>
>> We might suggest a few ideas, but opening this to the community for
>> suggestions would be good too.  Kind of like the TEI community grants.
>> Of course, with the community grants already out there, there might not
>> really be a need to do (e) at all.
>>
>> --Kevin
>

From mholmes at uvic.ca  Thu Jan 12 08:21:33 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Thu, 12 Jan 2012 05:21:33 -0800
Subject: [tei-council] TEI Technical Council Budget 2012
In-Reply-To: <2CADFB7D-C525-40A8-9012-B32A52E4A5E8@oucs.ox.ac.uk>
References: <4F0CC8CC.7070700@oucs.ox.ac.uk>	<4F0E26CD.1000101@ultraslavonic.info>
	<2CADFB7D-C525-40A8-9012-B32A52E4A5E8@oucs.ox.ac.uk>
Message-ID: <4F0EDE5D.7030901@uvic.ca>


> We need to agree on terminology  here. I think of "roma" as meaning
> "user interface to ODD, with facilities to create and edit and odd, and
> call ODD -> XX processing". Note the "call" there. All the Roma-ish tools we
> have now (Roma web, command-line, oxgarage, oxygen) all call the same
> underlying XSLT library.   James' (d) is a rewrite of that backend library, but his
> c) is a new Roma web (probably).
>
> personally, I go for c), on the grounds that Web Roma is _definitely_ incomplete
> and has errors, and definitely  has real users, now.

That's exactly how I feel. Web Roma is most people's interface to TEI, 
when they first start to create their own project (as opposed to working 
on someone else's, where the schema is already done). The slicker and 
more reliable it is, the better the initial experience, and the more 
positive people feel towards using TEI.

Cheers,
Martin

On 12-01-12 01:12 AM, Sebastian Rahtz wrote:
>
> On 12 Jan 2012, at 00:18, Kevin Hawkins wrote:
>> My recollection is that we did indeed solve most of the problems.  Even
>> if there are outstanding issues about rationalization that Paul
>> Schaffner (who will be attending as a Council member) can't answer for
>> us, I imagine we could get Martin Mueller or Brian Pytlik Zillig on the
>> phone or Skype to answer those questions.  They're both only one time
>> zone away from Ann Arbor, so I can't imagine this will be difficult.
>
> I agree, it probably doesnt  need a full-scale session with MM and BPZ;
> but we really should revisit the issue. There are certainly unsolved parts of the
> equation -<signed>  is one of those. Asking MM/BPZ to test 2.0.1 on their
> conversions now would be important.
>
>>> d) Another idea was to try to fund an entirely new processing
>>> implementation of ODD2+ that is completely independent of the existing
>>> XSLT. But this is problematic to budget.
>>
>> You mean fund a complete rewrite of Roma rather than a better Roma, as
>> in ??
>
> We need to agree on terminology  here. I think of "roma" as meaning
> "user interface to ODD, with facilities to create and edit and odd, and
> call ODD ->  XX processing". Note the "call" there. All the Roma-ish tools we
> have now (Roma web, command-line, oxgarage, oxygen) all call the same
> underlying XSLT library.   James' (d) is a rewrite of that backend library, but his
> c) is a new Roma web (probably).
>
> personally, I go for c), on the grounds that Web Roma is _definitely_ incomplete
> and has errors, and definitely  has real users, now.
>
> --
> Stormageddon Rahtz
> Head of Information and Support Group
> Oxford University Computing Services
> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>
> S?lo le pido a Dios
> que el futuro no me sea indiferente
>

From mholmes at uvic.ca  Thu Jan 12 12:39:33 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Thu, 12 Jan 2012 09:39:33 -0800
Subject: [tei-council] version 2.0.1 p5subset.xml states "edition 2.0.0"
In-Reply-To: <48F7E21F-4B77-4865-AB90-47F6AA73ADBF@edirom.de>
References: <48F7E21F-4B77-4865-AB90-47F6AA73ADBF@edirom.de>
Message-ID: <4F0F1AD5.4070101@uvic.ca>

Hi all,

I think we need to release a 2.0.2 soon, during which we again run 
through the instructions, after adding the tagging instruction. Should 
we do a quick trawl through the tickets and decide which ones might be 
polished off quickly without controversy?

Can I be the one to go through the release steps this time?

Cheers,
Martin

On 12-01-12 08:27 AM, Peter Stadler wrote:
> Dear geeks again,
>
> again wondering: just downloaded the current release 2.0.1 from sourceforge (tei-2.0.1.zip) and the editionStmt at tei-2.0.1/xml/tei/p5subset.xml reads<edition>2.0.0 Last updated on<date when="2011-12-16">16th December 2011</date>.</edition>
>
> Does that mean it wasn't updated at all or is just the editionStmt wrong?
>
> Many thanks again
> Peter
>

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From sebastian.rahtz at oucs.ox.ac.uk  Thu Jan 12 12:44:52 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Thu, 12 Jan 2012 17:44:52 +0000
Subject: [tei-council] version 2.0.1 p5subset.xml states "edition 2.0.0"
In-Reply-To: <4F0F1AD5.4070101@uvic.ca>
References: <48F7E21F-4B77-4865-AB90-47F6AA73ADBF@edirom.de>
	<4F0F1AD5.4070101@uvic.ca>
Message-ID: <72C9A5F5-636A-4825-8F4D-61FB296317BF@oucs.ox.ac.uk>


On 12 Jan 2012, at 17:39, Martin Holmes wrote:

> Hi all,
> 
> I think we need to release a 2.0.2 soon, during which we again run 
> through the instructions, after adding the tagging instruction.

I have a script maketag which says

svn cp -m "create tag of P5 release $1" -r "{$2}" \
      https://tei.svn.sourceforge.net/svnroot/tei/trunk/P5 \
      https://tei.svn.sourceforge.net/svnroot/tei/tags/P5_release_$1/

as in 

    sh ../maketag 2.0.1 2011-12-22

for retrospective addition of tags. better done on the way without the -r

> Should 
> we do a quick trawl through the tickets and decide which ones might be 
> polished off quickly without controversy?
if they change the content model, we'd go to 2.1.0?.

> 
> Can I be the one to go through the release steps this time?


we have not resolved the Debian issue yet. the sticking point
is updating repo on a Fedora box
--
Stormageddon Rahtz      
Head of Information and Support Group
Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431

S?lo le pido a Dios
que el futuro no me sea indiferente


From gabriel.bodard at kcl.ac.uk  Thu Jan 12 12:45:12 2012
From: gabriel.bodard at kcl.ac.uk (Gabriel Bodard)
Date: Thu, 12 Jan 2012 17:45:12 +0000
Subject: [tei-council] version 2.0.1 p5subset.xml states "edition 2.0.0"
In-Reply-To: <4F0F1AD5.4070101@uvic.ca>
References: <48F7E21F-4B77-4865-AB90-47F6AA73ADBF@edirom.de>
	<4F0F1AD5.4070101@uvic.ca>
Message-ID: <4F0F1C28.9050608@kcl.ac.uk>

In that case, could I slip geo -> att.declaring into this one? Or would 
that be rude for a sub-decimal release?

G

On 2012-01-12 17:39, Martin Holmes wrote:
> Hi all,
>
> I think we need to release a 2.0.2 soon, during which we again run
> through the instructions, after adding the tagging instruction. Should
> we do a quick trawl through the tickets and decide which ones might be
> polished off quickly without controversy?
>
> Can I be the one to go through the release steps this time?
>
> Cheers,
> Martin
>
> On 12-01-12 08:27 AM, Peter Stadler wrote:
>> Dear geeks again,
>>
>> again wondering: just downloaded the current release 2.0.1 from sourceforge (tei-2.0.1.zip) and the editionStmt at tei-2.0.1/xml/tei/p5subset.xml reads<edition>2.0.0 Last updated on<date when="2011-12-16">16th December 2011</date>.</edition>
>>
>> Does that mean it wasn't updated at all or is just the editionStmt wrong?
>>
>> Many thanks again
>> Peter
>>
>

-- 
Dr Gabriel BODARD
(Research Associate in Digital Epigraphy)

Department of Digital Humanities
King's College London
26-29 Drury Lane
London WC2B 5RL

Email: gabriel.bodard at kcl.ac.uk
Tel: +44 (0)20 7848 1388
Fax: +44 (0)20 7848 2980

http://www.digitalclassicist.org/
http://www.currentepigraphy.org/

From lou.burnard at retired.ox.ac.uk  Thu Jan 12 12:50:11 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Thu, 12 Jan 2012 17:50:11 +0000
Subject: [tei-council] version 2.0.1 p5subset.xml states "edition 2.0.0"
In-Reply-To: <4F0F1C28.9050608@kcl.ac.uk>
References: <48F7E21F-4B77-4865-AB90-47F6AA73ADBF@edirom.de>	<4F0F1AD5.4070101@uvic.ca>
	<4F0F1C28.9050608@kcl.ac.uk>
Message-ID: <4F0F1D53.4010306@retired.ox.ac.uk>

As noted on the ticket, I think that's a straightforward error fix. And 
it doesn't change any content models. Just do it. ( now there's a catchy 
phrase, wonder if I can sell it)

On 12/01/12 17:45, Gabriel Bodard wrote:
> In that case, could I slip geo ->  att.declaring into this one? Or would
> that be rude for a sub-decimal release?
>
> G
>
> On 2012-01-12 17:39, Martin Holmes wrote:
>> Hi all,
>>
>> I think we need to release a 2.0.2 soon, during which we again run
>> through the instructions, after adding the tagging instruction. Should
>> we do a quick trawl through the tickets and decide which ones might be
>> polished off quickly without controversy?
>>
>> Can I be the one to go through the release steps this time?
>>
>> Cheers,
>> Martin
>>
>> On 12-01-12 08:27 AM, Peter Stadler wrote:
>>> Dear geeks again,
>>>
>>> again wondering: just downloaded the current release 2.0.1 from sourceforge (tei-2.0.1.zip) and the editionStmt at tei-2.0.1/xml/tei/p5subset.xml reads<edition>2.0.0 Last updated on<date when="2011-12-16">16th December 2011</date>.</edition>
>>>
>>> Does that mean it wasn't updated at all or is just the editionStmt wrong?
>>>
>>> Many thanks again
>>> Peter
>>>
>>
>


From mholmes at uvic.ca  Thu Jan 12 12:51:16 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Thu, 12 Jan 2012 09:51:16 -0800
Subject: [tei-council] version 2.0.1 p5subset.xml states "edition 2.0.0"
In-Reply-To: <4F0F1C28.9050608@kcl.ac.uk>
References: <48F7E21F-4B77-4865-AB90-47F6AA73ADBF@edirom.de>	<4F0F1AD5.4070101@uvic.ca>
	<4F0F1C28.9050608@kcl.ac.uk>
Message-ID: <4F0F1D94.3050705@uvic.ca>

> In that case, could I slip geo -> att.declaring into this one? Or would
> that be rude for a sub-decimal release?

I think that would be uncontroversial. The only arguments are over 
whether <location> deserves it too (Syd, and now I, say yes, Lou says 
no), but the argument for <geo> is convincing.

I would like to aim for a release next week, in which all the trivial 
typos that have been reported have been fixed (I've been trying to do 
those as they come in), and other simple issues like this are done. Then 
we'd be able to review the remaining tickets and raise new issues in 
preparation for the April meeting.

Cheers,
Martin

On 12-01-12 09:45 AM, Gabriel Bodard wrote:

> G
>
> On 2012-01-12 17:39, Martin Holmes wrote:
>> Hi all,
>>
>> I think we need to release a 2.0.2 soon, during which we again run
>> through the instructions, after adding the tagging instruction. Should
>> we do a quick trawl through the tickets and decide which ones might be
>> polished off quickly without controversy?
>>
>> Can I be the one to go through the release steps this time?
>>
>> Cheers,
>> Martin
>>
>> On 12-01-12 08:27 AM, Peter Stadler wrote:
>>> Dear geeks again,
>>>
>>> again wondering: just downloaded the current release 2.0.1 from sourceforge (tei-2.0.1.zip) and the editionStmt at tei-2.0.1/xml/tei/p5subset.xml reads<edition>2.0.0 Last updated on<date when="2011-12-16">16th December 2011</date>.</edition>
>>>
>>> Does that mean it wasn't updated at all or is just the editionStmt wrong?
>>>
>>> Many thanks again
>>> Peter
>>>
>>
>

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From gabriel.bodard at kcl.ac.uk  Thu Jan 12 12:53:22 2012
From: gabriel.bodard at kcl.ac.uk (Gabriel Bodard)
Date: Thu, 12 Jan 2012 17:53:22 +0000
Subject: [tei-council] version 2.0.1 p5subset.xml states "edition 2.0.0"
In-Reply-To: <4F0F1D53.4010306@retired.ox.ac.uk>
References: <48F7E21F-4B77-4865-AB90-47F6AA73ADBF@edirom.de>
	<4F0F1AD5.4070101@uvic.ca>	<4F0F1C28.9050608@kcl.ac.uk>
	<4F0F1D53.4010306@retired.ox.ac.uk>
Message-ID: <4F0F1E12.6010004@kcl.ac.uk>

Well, it adds @decl to one element. Is that not a content model change? 
Or do attributes not count?

On 2012-01-12 17:50, Lou Burnard wrote:
> As noted on the ticket, I think that's a straightforward error fix. And
> it doesn't change any content models. Just do it. ( now there's a catchy
> phrase, wonder if I can sell it)
>
> On 12/01/12 17:45, Gabriel Bodard wrote:
>> In that case, could I slip geo ->   att.declaring into this one? Or would
>> that be rude for a sub-decimal release?
>>
>> G
>>
>> On 2012-01-12 17:39, Martin Holmes wrote:
>>> Hi all,
>>>
>>> I think we need to release a 2.0.2 soon, during which we again run
>>> through the instructions, after adding the tagging instruction. Should
>>> we do a quick trawl through the tickets and decide which ones might be
>>> polished off quickly without controversy?
>>>
>>> Can I be the one to go through the release steps this time?
>>>
>>> Cheers,
>>> Martin
>>>
>>> On 12-01-12 08:27 AM, Peter Stadler wrote:
>>>> Dear geeks again,
>>>>
>>>> again wondering: just downloaded the current release 2.0.1 from sourceforge (tei-2.0.1.zip) and the editionStmt at tei-2.0.1/xml/tei/p5subset.xml reads<edition>2.0.0 Last updated on<date when="2011-12-16">16th December 2011</date>.</edition>
>>>>
>>>> Does that mean it wasn't updated at all or is just the editionStmt wrong?
>>>>
>>>> Many thanks again
>>>> Peter
>>>>
>>>
>>
>

-- 
Dr Gabriel BODARD
(Research Associate in Digital Epigraphy)

Department of Digital Humanities
King's College London
26-29 Drury Lane
London WC2B 5RL

Email: gabriel.bodard at kcl.ac.uk
Tel: +44 (0)20 7848 1388
Fax: +44 (0)20 7848 2980

http://www.digitalclassicist.org/
http://www.currentepigraphy.org/

From James.Cummings at oucs.ox.ac.uk  Thu Jan 12 13:01:42 2012
From: James.Cummings at oucs.ox.ac.uk (James Cummings)
Date: Thu, 12 Jan 2012 18:01:42 +0000
Subject: [tei-council] TEI Technical Council Budget 2012
In-Reply-To: <4F0EDE5D.7030901@uvic.ca>
References: <4F0CC8CC.7070700@oucs.ox.ac.uk>	<4F0E26CD.1000101@ultraslavonic.info>	<2CADFB7D-C525-40A8-9012-B32A52E4A5E8@oucs.ox.ac.uk>
	<4F0EDE5D.7030901@uvic.ca>
Message-ID: <4F0F2006.9040902@oucs.ox.ac.uk>

If I summarise back the consensus I seem to hear is to do b) 
(ODD3 workshop) and c) (New Web Roma).

I think we can do both those things (depending on how much you 
think 'c' will cost). And potentially have some money left over 
for additional things. (Which we can decide on and budget for later.)

We'll invite MartinM and Brian (and anyone else people care to 
suggest) to participate in the Ann Arbor meeting (but remotely).

I'll work up a slightly more detailed budget but wait for the 
result of the DH panel to see if it is accepted before submitting 
it to the board.

-James


On 12/01/12 13:21, Martin Holmes wrote:
>
>> We need to agree on terminology  here. I think of "roma" as meaning
>> "user interface to ODD, with facilities to create and edit and odd, and
>> call ODD ->  XX processing". Note the "call" there. All the Roma-ish tools we
>> have now (Roma web, command-line, oxgarage, oxygen) all call the same
>> underlying XSLT library.   James' (d) is a rewrite of that backend library, but his
>> c) is a new Roma web (probably).
>>
>> personally, I go for c), on the grounds that Web Roma is _definitely_ incomplete
>> and has errors, and definitely  has real users, now.
>
> That's exactly how I feel. Web Roma is most people's interface to TEI,
> when they first start to create their own project (as opposed to working
> on someone else's, where the schema is already done). The slicker and
> more reliable it is, the better the initial experience, and the more
> positive people feel towards using TEI.
>
> Cheers,
> Martin
>
> On 12-01-12 01:12 AM, Sebastian Rahtz wrote:
>>
>> On 12 Jan 2012, at 00:18, Kevin Hawkins wrote:
>>> My recollection is that we did indeed solve most of the problems.  Even
>>> if there are outstanding issues about rationalization that Paul
>>> Schaffner (who will be attending as a Council member) can't answer for
>>> us, I imagine we could get Martin Mueller or Brian Pytlik Zillig on the
>>> phone or Skype to answer those questions.  They're both only one time
>>> zone away from Ann Arbor, so I can't imagine this will be difficult.
>>
>> I agree, it probably doesnt  need a full-scale session with MM and BPZ;
>> but we really should revisit the issue. There are certainly unsolved parts of the
>> equation -<signed>   is one of those. Asking MM/BPZ to test 2.0.1 on their
>> conversions now would be important.
>>
>>>> d) Another idea was to try to fund an entirely new processing
>>>> implementation of ODD2+ that is completely independent of the existing
>>>> XSLT. But this is problematic to budget.
>>>
>>> You mean fund a complete rewrite of Roma rather than a better Roma, as
>>> in ??
>>
>> We need to agree on terminology  here. I think of "roma" as meaning
>> "user interface to ODD, with facilities to create and edit and odd, and
>> call ODD ->   XX processing". Note the "call" there. All the Roma-ish tools we
>> have now (Roma web, command-line, oxgarage, oxygen) all call the same
>> underlying XSLT library.   James' (d) is a rewrite of that backend library, but his
>> c) is a new Roma web (probably).
>>
>> personally, I go for c), on the grounds that Web Roma is _definitely_ incomplete
>> and has errors, and definitely  has real users, now.
>>
>> --
>> Stormageddon Rahtz
>> Head of Information and Support Group
>> Oxford University Computing Services
>> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>>
>> S?lo le pido a Dios
>> que el futuro no me sea indiferente
>>


-- 
Dr James Cummings, InfoDev,
Computing Services, University of Oxford

From kevin.s.hawkins at ultraslavonic.info  Thu Jan 12 15:42:22 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Thu, 12 Jan 2012 15:42:22 -0500
Subject: [tei-council] Bug: make geo declaring
In-Reply-To: <4F0EC7B2.4020002@kcl.ac.uk>
References: <4F0C67A6.4010400@kcl.ac.uk> <4F0EC7B2.4020002@kcl.ac.uk>
Message-ID: <4F0F45AE.9010202@ultraslavonic.info>

Is there really consensus to make <location> a member of att.declaring? 
  I don't see that.  --Kevin

On 1/12/12 6:44 AM, Gabriel Bodard wrote:
> There's been a little bit of discussion on the ticket, and it looks like
> we're more or less agreed that we could reasonable make both<geo>  and
> <location>  members of att.declaring. I'll implement this today if no one
> objects, but I thought I'd ask here if anyone wants to weigh in on the
> minor debate between Martin and myself first...
>
> Cheers,
>
> Gabby
>
> On 2012-01-10 16:30, Gabriel Bodard wrote:
>> Dear Councillors,
>>
>> A reminder of a bug ticket that was submitted last November (just too
>> late to make it into the last release, apparently), suggesting that
>> <geo>   be added to att.declaring:
>>
>> http://purl.org/TEI/BUGS/3440771
>>
>> If everyone is agreeable, I'm happy to go ahead and make this change in
>> the source. (I know it won't be released for a while now, but if I do it
>> now we won't forget in future.)
>>
>> Best,
>>
>> Gabby
>>
>

From mholmes at uvic.ca  Thu Jan 12 16:17:48 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Thu, 12 Jan 2012 13:17:48 -0800
Subject: [tei-council] Bug: make geo declaring
In-Reply-To: <4F0F45AE.9010202@ultraslavonic.info>
References: <4F0C67A6.4010400@kcl.ac.uk> <4F0EC7B2.4020002@kcl.ac.uk>
	<4F0F45AE.9010202@ultraslavonic.info>
Message-ID: <4F0F4DFC.1040304@uvic.ca>

No, the consensus is on <geo> only. We're still arguing about 
<location>. But the ticket requests "multiple <geo> tags in a <location> 
element (which AFAIK has always been permitted), and the removal of the 
restriction for all <geo> tags to use the same coordinate system. This 
change would accomplish that. Of course, before closing the ticket we 
should check that all references and descriptive text are appropriately 
updated, but the addition of <geo> to att.declaring alone answers the 
ticket, I think, and should solve the submitter's problem.

Cheers,
Martin

On 12-01-12 12:42 PM, Kevin Hawkins wrote:
> Is there really consensus to make<location>  a member of att.declaring?
>    I don't see that.  --Kevin
>
> On 1/12/12 6:44 AM, Gabriel Bodard wrote:
>> There's been a little bit of discussion on the ticket, and it looks like
>> we're more or less agreed that we could reasonable make both<geo>   and
>> <location>   members of att.declaring. I'll implement this today if no one
>> objects, but I thought I'd ask here if anyone wants to weigh in on the
>> minor debate between Martin and myself first...
>>
>> Cheers,
>>
>> Gabby
>>
>> On 2012-01-10 16:30, Gabriel Bodard wrote:
>>> Dear Councillors,
>>>
>>> A reminder of a bug ticket that was submitted last November (just too
>>> late to make it into the last release, apparently), suggesting that
>>> <geo>    be added to att.declaring:
>>>
>>> http://purl.org/TEI/BUGS/3440771
>>>
>>> If everyone is agreeable, I'm happy to go ahead and make this change in
>>> the source. (I know it won't be released for a while now, but if I do it
>>> now we won't forget in future.)
>>>
>>> Best,
>>>
>>> Gabby
>>>
>>

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From sebastian.rahtz at oucs.ox.ac.uk  Fri Jan 13 04:32:56 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Fri, 13 Jan 2012 09:32:56 +0000
Subject: [tei-council] Minor error in Guidelines
In-Reply-To: <4F0FBAA5.2090706@uvic.ca>
References: <4F0F9F9F.3050408@gmail.com> <4F0FBAA5.2090706@uvic.ca>
Message-ID: <97AE8F42-0EDB-41CC-8FE1-984EE9E495D4@oucs.ox.ac.uk>


On 13 Jan 2012, at 05:01, Martin Holmes wrote:

> I've put in a bug report for this:
> 
> <http://purl.org/TEI/BUGS/3473329>
> 
> The basic problem is that in the web view of the Guidelines, figures 
> within each chapter are numbered 1, 2, 3, 4 etc., but in the PDF output, 
> they're numbered 11.1, 11.2, 11.3?
> 
there are two issues here.

  a) the use of dangerous markup like "<ref target="#sleeprs">figure 4 above</ref>", which should be changed into a <ptr> to avoid this sort of problem
  b) the different numbering schemes

for the latter, which do we want for the Guidelines? by chapter, or sequential throughout?

for the former, I found 3 occurrences of this, and changed them to <ptr>. am testing before committing.
--
Stormageddon Rahtz      
Head of Information and Support Group
Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431

S?lo le pido a Dios
que el futuro no me sea indiferente


From james.cummings at oucs.ox.ac.uk  Fri Jan 13 04:41:50 2012
From: james.cummings at oucs.ox.ac.uk (James Cummings)
Date: Fri, 13 Jan 2012 09:41:50 +0000
Subject: [tei-council] @source and @version for versioning an ODD
Message-ID: <u1myrvqh628b7cwnlxpusdn1.1320588104551@email.android.com>


I'd agree that if the genetic stuff is all implemented then the release is a major bump. 

JamesC 
--
James Cummings, InfoDev, OUCS, University of Oxford (via phone)

Lou Burnard <lou.burnard at retired.ox.ac.uk> wrote:


From james.cummings at oucs.ox.ac.uk  Fri Jan 13 04:47:59 2012
From: james.cummings at oucs.ox.ac.uk (James Cummings)
Date: Fri, 13 Jan 2012 09:47:59 +0000
Subject: [tei-council] @source and @version for versioning an ODD
Message-ID: <vi3c8xcboyhrqp55mhiajw5n.1326447985544@email.android.com>


Apologies my phone just seemed to send an old draft message. Weird.

JamesC
--
James Cummings, InfoDev, OUCS, University of Oxford (via phone)

James Cummings <james.cummings at oucs.ox.ac.uk> wrote:


I'd agree that if the genetic stuff is all implemented then the release is a major bump.

JamesC
--
James Cummings, InfoDev, OUCS, University of Oxford (via phone)

Lou Burnard <lou.burnard at retired.ox.ac.uk> wrote:

--
tei-council mailing list
tei-council at lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

PLEASE NOTE: postings to this list are publicly archived

From gabriel.bodard at kcl.ac.uk  Fri Jan 13 06:00:18 2012
From: gabriel.bodard at kcl.ac.uk (Gabriel Bodard)
Date: Fri, 13 Jan 2012 11:00:18 +0000
Subject: [tei-council] Bug: make geo declaring
In-Reply-To: <4F0F45AE.9010202@ultraslavonic.info>
References: <4F0C67A6.4010400@kcl.ac.uk> <4F0EC7B2.4020002@kcl.ac.uk>
	<4F0F45AE.9010202@ultraslavonic.info>
Message-ID: <4F100EC2.5020801@kcl.ac.uk>

No, you're right. When I wrote that email it looked much more like a 
consensus (at least that adding @decls to <location> was harmless) than 
it did by the time it hit the list.

I've added decls to geo, but not to location, for now, pending further 
discussion. Will look at the surrounding prose and report here what I 
think needs clarified/changed.

G


On 2012-01-12 20:42, Kevin Hawkins wrote:
> Is there really consensus to make<location>  a member of att.declaring?
>    I don't see that.  --Kevin
>
> On 1/12/12 6:44 AM, Gabriel Bodard wrote:
>> There's been a little bit of discussion on the ticket, and it looks like
>> we're more or less agreed that we could reasonable make both<geo>   and
>> <location>   members of att.declaring. I'll implement this today if no one
>> objects, but I thought I'd ask here if anyone wants to weigh in on the
>> minor debate between Martin and myself first...
>>
>> Cheers,
>>
>> Gabby
>>
>> On 2012-01-10 16:30, Gabriel Bodard wrote:
>>> Dear Councillors,
>>>
>>> A reminder of a bug ticket that was submitted last November (just too
>>> late to make it into the last release, apparently), suggesting that
>>> <geo>    be added to att.declaring:
>>>
>>> http://purl.org/TEI/BUGS/3440771
>>>
>>> If everyone is agreeable, I'm happy to go ahead and make this change in
>>> the source. (I know it won't be released for a while now, but if I do it
>>> now we won't forget in future.)
>>>
>>> Best,
>>>
>>> Gabby
>>>
>>

-- 
Dr Gabriel BODARD
(Research Associate in Digital Epigraphy)

Department of Digital Humanities
King's College London
26-29 Drury Lane
London WC2B 5RL

Email: gabriel.bodard at kcl.ac.uk
Tel: +44 (0)20 7848 1388
Fax: +44 (0)20 7848 2980

http://www.digitalclassicist.org/
http://www.currentepigraphy.org/

From gabriel.bodard at kcl.ac.uk  Fri Jan 13 06:38:44 2012
From: gabriel.bodard at kcl.ac.uk (Gabriel Bodard)
Date: Fri, 13 Jan 2012 11:38:44 +0000
Subject: [tei-council] Bug: make geo declaring
In-Reply-To: <4F0F4DFC.1040304@uvic.ca>
References: <4F0C67A6.4010400@kcl.ac.uk> <4F0EC7B2.4020002@kcl.ac.uk>
	<4F0F45AE.9010202@ultraslavonic.info> <4F0F4DFC.1040304@uvic.ca>
Message-ID: <4F1017C4.4020101@kcl.ac.uk>

Now that I look at it, I'm not clear exactly what we do want to say 
about the content/format of <geo>. As Martin says, we obviously want to 
get rid of the note as written, which says:

1. all <geo> in a document need to use the same coordinate system;

2. in absence of <geoDecl>, this is assumed to be a space-delimited pair 
of coords (lat followed by long) "according to the World Geodetic System."

The first part obviously needs to go; do we need to think some more 
about the format we want to encourage as the default? It's true that a 
coordinate pair will be the most common content, but what do we want to 
recommend for people who want, like Martin, to represent a polygon or 
polyline?

I was thinking that a useful rule might be to follow an existing 
standard like gml:posList, but that expects coordinate pairs to be 
comma-delimited, and lines/polygons to be made up of a space-delimited 
list of such pairs. This is the opposite of what we seem to suggest now, 
and would therefore break a lot of people's usage.

Any other suggestions?

(Final question: do we also want to give some guidance under <geoDecl> 
about how to define more than one datum and refer back to them?)

G

On 2012-01-12 21:17, Martin Holmes wrote:
> No, the consensus is on<geo>  only. We're still arguing about
> <location>. But the ticket requests "multiple<geo>  tags in a<location>
> element (which AFAIK has always been permitted), and the removal of the
> restriction for all<geo>  tags to use the same coordinate system. This
> change would accomplish that. Of course, before closing the ticket we
> should check that all references and descriptive text are appropriately
> updated, but the addition of<geo>  to att.declaring alone answers the
> ticket, I think, and should solve the submitter's problem.
>
> Cheers,
> Martin
>
> On 12-01-12 12:42 PM, Kevin Hawkins wrote:
>> Is there really consensus to make<location>   a member of att.declaring?
>>     I don't see that.  --Kevin
>>
>> On 1/12/12 6:44 AM, Gabriel Bodard wrote:
>>> There's been a little bit of discussion on the ticket, and it looks like
>>> we're more or less agreed that we could reasonable make both<geo>    and
>>> <location>    members of att.declaring. I'll implement this today if no one
>>> objects, but I thought I'd ask here if anyone wants to weigh in on the
>>> minor debate between Martin and myself first...
>>>
>>> Cheers,
>>>
>>> Gabby
>>>
>>> On 2012-01-10 16:30, Gabriel Bodard wrote:
>>>> Dear Councillors,
>>>>
>>>> A reminder of a bug ticket that was submitted last November (just too
>>>> late to make it into the last release, apparently), suggesting that
>>>> <geo>     be added to att.declaring:
>>>>
>>>> http://purl.org/TEI/BUGS/3440771
>>>>
>>>> If everyone is agreeable, I'm happy to go ahead and make this change in
>>>> the source. (I know it won't be released for a while now, but if I do it
>>>> now we won't forget in future.)
>>>>
>>>> Best,
>>>>
>>>> Gabby
>>>>
>>>
>

-- 
Dr Gabriel BODARD
(Research Associate in Digital Epigraphy)

Department of Digital Humanities
King's College London
26-29 Drury Lane
London WC2B 5RL

Email: gabriel.bodard at kcl.ac.uk
Tel: +44 (0)20 7848 1388
Fax: +44 (0)20 7848 2980

http://www.digitalclassicist.org/
http://www.currentepigraphy.org/

From mholmes at uvic.ca  Fri Jan 13 11:17:16 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Fri, 13 Jan 2012 08:17:16 -0800
Subject: [tei-council] Minor error in Guidelines
In-Reply-To: <97AE8F42-0EDB-41CC-8FE1-984EE9E495D4@oucs.ox.ac.uk>
References: <4F0F9F9F.3050408@gmail.com> <4F0FBAA5.2090706@uvic.ca>
	<97AE8F42-0EDB-41CC-8FE1-984EE9E495D4@oucs.ox.ac.uk>
Message-ID: <4F10590C.50904@uvic.ca>

Could you clarify what the difference is between using <ref> and <ptr> 
in the guidelines?

Cheers,
Martin

On 12-01-13 01:32 AM, Sebastian Rahtz wrote:
>
> On 13 Jan 2012, at 05:01, Martin Holmes wrote:
>
>> I've put in a bug report for this:
>>
>> <http://purl.org/TEI/BUGS/3473329>
>>
>> The basic problem is that in the web view of the Guidelines, figures
>> within each chapter are numbered 1, 2, 3, 4 etc., but in the PDF output,
>> they're numbered 11.1, 11.2, 11.3?
>>
> there are two issues here.
>
>    a) the use of dangerous markup like "<ref target="#sleeprs">figure 4 above</ref>", which should be changed into a<ptr>  to avoid this sort of problem
>    b) the different numbering schemes
>
> for the latter, which do we want for the Guidelines? by chapter, or sequential throughout?
>
> for the former, I found 3 occurrences of this, and changed them to<ptr>. am testing before committing.
> --
> Stormageddon Rahtz
> Head of Information and Support Group
> Oxford University Computing Services
> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>
> S?lo le pido a Dios
> que el futuro no me sea indiferente
>

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From James.Cummings at oucs.ox.ac.uk  Fri Jan 13 11:19:45 2012
From: James.Cummings at oucs.ox.ac.uk (James Cummings)
Date: Fri, 13 Jan 2012 16:19:45 +0000
Subject: [tei-council] Minor error in Guidelines
In-Reply-To: <4F10590C.50904@uvic.ca>
References: <4F0F9F9F.3050408@gmail.com>
	<4F0FBAA5.2090706@uvic.ca>	<97AE8F42-0EDB-41CC-8FE1-984EE9E495D4@oucs.ox.ac.uk>
	<4F10590C.50904@uvic.ca>
Message-ID: <4F1059A1.4060206@oucs.ox.ac.uk>


On 13/01/12 16:17, Martin Holmes wrote:
> Could you clarify what the difference is between using<ref>  and<ptr>
> in the guidelines?

I'm assuming that Sebastian's point (ha ha) is that <ref> 
contains text which may become outdated, whereas in processing a 
<ptr> we generate the link text based on the content of the 
@target or whatever it points at.

-James
-- 
Dr James Cummings, InfoDev,
Computing Services, University of Oxford

From lou.burnard at retired.ox.ac.uk  Fri Jan 13 11:19:53 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Fri, 13 Jan 2012 16:19:53 +0000
Subject: [tei-council] Minor error in Guidelines
In-Reply-To: <4F10590C.50904@uvic.ca>
References: <4F0F9F9F.3050408@gmail.com>
	<4F0FBAA5.2090706@uvic.ca>	<97AE8F42-0EDB-41CC-8FE1-984EE9E495D4@oucs.ox.ac.uk>
	<4F10590C.50904@uvic.ca>
Message-ID: <4F1059A9.1000709@retired.ox.ac.uk>

In the Guidelines, as elsewhere,

<ref target="#foo">section foo</ref> means: generate a link to #foo and 
represent it by the text "section foo".

<ptr target="#foo"/> means: generate a link to #foo and represent it by 
whatever text your processor chooses to generate



On 13/01/12 16:17, Martin Holmes wrote:
> Could you clarify what the difference is between using<ref>  and<ptr>
> in the guidelines?
>
> Cheers,
> Martin
>
> On 12-01-13 01:32 AM, Sebastian Rahtz wrote:
>>
>> On 13 Jan 2012, at 05:01, Martin Holmes wrote:
>>
>>> I've put in a bug report for this:
>>>
>>> <http://purl.org/TEI/BUGS/3473329>
>>>
>>> The basic problem is that in the web view of the Guidelines, figures
>>> within each chapter are numbered 1, 2, 3, 4 etc., but in the PDF output,
>>> they're numbered 11.1, 11.2, 11.3?
>>>
>> there are two issues here.
>>
>>     a) the use of dangerous markup like "<ref target="#sleeprs">figure 4 above</ref>", which should be changed into a<ptr>   to avoid this sort of problem
>>     b) the different numbering schemes
>>
>> for the latter, which do we want for the Guidelines? by chapter, or sequential throughout?
>>
>> for the former, I found 3 occurrences of this, and changed them to<ptr>. am testing before committing.
>> --
>> Stormageddon Rahtz
>> Head of Information and Support Group
>> Oxford University Computing Services
>> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>>
>> S?lo le pido a Dios
>> que el futuro no me sea indiferente
>>
>


From sebastian.rahtz at oucs.ox.ac.uk  Fri Jan 13 11:26:38 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Fri, 13 Jan 2012 16:26:38 +0000
Subject: [tei-council] Minor error in Guidelines
In-Reply-To: <4F10590C.50904@uvic.ca>
References: <4F0F9F9F.3050408@gmail.com> <4F0FBAA5.2090706@uvic.ca>
	<97AE8F42-0EDB-41CC-8FE1-984EE9E495D4@oucs.ox.ac.uk>
	<4F10590C.50904@uvic.ca>
Message-ID: <80387C30-DACA-44C1-9EBF-B87E703CE753@oucs.ox.ac.uk>


On 13 Jan 2012, at 16:17, Martin Holmes wrote:

> Could you clarify what the difference is between using <ref> and <ptr> 
> in the guidelines?


if you use <ref>, you (the author) dictate what the cross-reference text is. If you use <ptr>,
it is calculated for you. so <ptr target="#durlach"/> generates "Figure 11.1" or whatever.

I would seldom use <ref> myself in born-digital writing. 

W3C never seemed to cotton on to this sort of thing. They probably still believe in
"follow <a href="#there">this link</a>".
--
Stormageddon Rahtz      
Head of Information and Support Group
Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431

S?lo le pido a Dios
que el futuro no me sea indiferente


From sebastian.rahtz at oucs.ox.ac.uk  Fri Jan 13 12:27:09 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Fri, 13 Jan 2012 17:27:09 +0000
Subject: [tei-council] figure 11.2 etc
Message-ID: <B2AFABD3-87C5-408A-8B8D-BBFC9BBF8487@oucs.ox.ac.uk>

folks may like to examine http://bits.nsms.ox.ac.uk:8080/jenkins/job/TEIP5-Documentation/lastSuccessfulBuild/artifact/Guidelines-web/en/html/PH.html and see if they are happy with rendering of table captions and cross-refs now. I have corrected the stylesheets,
and changed the source to use <ptr>
--
Stormageddon Rahtz      
Head of Information and Support Group
Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431

S?lo le pido a Dios
que el futuro no me sea indiferente


From mholmes at uvic.ca  Fri Jan 13 12:34:28 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Fri, 13 Jan 2012 09:34:28 -0800
Subject: [tei-council] figure 11.2 etc
In-Reply-To: <B2AFABD3-87C5-408A-8B8D-BBFC9BBF8487@oucs.ox.ac.uk>
References: <B2AFABD3-87C5-408A-8B8D-BBFC9BBF8487@oucs.ox.ac.uk>
Message-ID: <4F106B24.9020700@uvic.ca>

That looks great to me. If everyone's happy, I'll close the ticket.

Cheers,
Martin

On 12-01-13 09:27 AM, Sebastian Rahtz wrote:
> folks may like to examine http://bits.nsms.ox.ac.uk:8080/jenkins/job/TEIP5-Documentation/lastSuccessfulBuild/artifact/Guidelines-web/en/html/PH.html and see if they are happy with rendering of table captions and cross-refs now. I have corrected the stylesheets,
> and changed the source to use<ptr>
> --
> Stormageddon Rahtz
> Head of Information and Support Group
> Oxford University Computing Services
> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>
> S?lo le pido a Dios
> que el futuro no me sea indiferente
>

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From gabriel.bodard at kcl.ac.uk  Tue Jan 17 11:11:45 2012
From: gabriel.bodard at kcl.ac.uk (Gabriel Bodard)
Date: Tue, 17 Jan 2012 16:11:45 +0000
Subject: [tei-council] version 2.0.1 p5subset.xml states "edition 2.0.0"
In-Reply-To: <4F0F1AD5.4070101@uvic.ca>
References: <48F7E21F-4B77-4865-AB90-47F6AA73ADBF@edirom.de>
	<4F0F1AD5.4070101@uvic.ca>
Message-ID: <4F159DC1.4010001@kcl.ac.uk>

Has there been any consensus on when 2.0.2 might be put out?

(I ask because, if it's soon I won't both hacking the EpiDoc schema to 
allow geo/@decl; I'll just wait for TEI to introduce it and regenerate 
the schema properly. :-) )

G

On 2012-01-12 17:39, Martin Holmes wrote:
> Hi all,
>
> I think we need to release a 2.0.2 soon, during which we again run
> through the instructions, after adding the tagging instruction. Should
> we do a quick trawl through the tickets and decide which ones might be
> polished off quickly without controversy?
>
> Can I be the one to go through the release steps this time?
>
> Cheers,
> Martin
>
> On 12-01-12 08:27 AM, Peter Stadler wrote:
>> Dear geeks again,
>>
>> again wondering: just downloaded the current release 2.0.1 from sourceforge (tei-2.0.1.zip) and the editionStmt at tei-2.0.1/xml/tei/p5subset.xml reads<edition>2.0.0 Last updated on<date when="2011-12-16">16th December 2011</date>.</edition>
>>
>> Does that mean it wasn't updated at all or is just the editionStmt wrong?
>>
>> Many thanks again
>> Peter
>>
>

-- 
Dr Gabriel BODARD
(Research Associate in Digital Epigraphy)

Department of Digital Humanities
King's College London
26-29 Drury Lane
London WC2B 5RL

Email: gabriel.bodard at kcl.ac.uk
Tel: +44 (0)20 7848 1388
Fax: +44 (0)20 7848 2980

http://www.digitalclassicist.org/
http://www.currentepigraphy.org/

From James.Cummings at oucs.ox.ac.uk  Tue Jan 17 19:13:10 2012
From: James.Cummings at oucs.ox.ac.uk (James Cummings)
Date: Wed, 18 Jan 2012 00:13:10 +0000
Subject: [tei-council] version 2.0.1 p5subset.xml states "edition 2.0.0"
In-Reply-To: <4F159DC1.4010001@kcl.ac.uk>
References: <48F7E21F-4B77-4865-AB90-47F6AA73ADBF@edirom.de>
	<4F0F1AD5.4070101@uvic.ca> <4F159DC1.4010001@kcl.ac.uk>
Message-ID: <4F160E96.2010202@oucs.ox.ac.uk>


Hi all,

Since no one else has piped up, can I suggest a schedule:

31 January midnight GMT: submission deadline of significant changes
1 February: Whole Day for council to proofread and correct typos.
2nd February: Release (Codename: Groundhog Day)

Since Martin asked, I suggest him as release technician.

Any reasons why these dates are wholly unsuitable?

-James

On 17/01/12 16:11, Gabriel Bodard wrote:
> Has there been any consensus on when 2.0.2 might be put out?
>
> (I ask because, if it's soon I won't both hacking the EpiDoc schema to
> allow geo/@decl; I'll just wait for TEI to introduce it and regenerate
> the schema properly. :-) )
>
> G
>
> On 2012-01-12 17:39, Martin Holmes wrote:
>> Hi all,
>>
>> I think we need to release a 2.0.2 soon, during which we again run
>> through the instructions, after adding the tagging instruction. Should
>> we do a quick trawl through the tickets and decide which ones might beS
>> polished off quickly without controversy?
>>
>> Can I be the one to go through the release steps this time?
>>
>> Cheers,
>> Martin
>>
>> On 12-01-12 08:27 AM, Peter Stadler wrote:
>>> Dear geeks again,
>>>
>>> again wondering: just downloaded the current release 2.0.1 from sourceforge (tei-2.0.1.zip) and the editionStmt at tei-2.0.1/xml/tei/p5subset.xml reads<edition>2.0.0 Last updated on<date when="2011-12-16">16th December 2011</date>.</edition>
>>>
>>> Does that mean it wasn't updated at all or is just the editionStmt wrong?
>>>
>>> Many thanks again
>>> Peter
>>>
>>
>


-- 
Dr James Cummings, InfoDev,
Computing Services, University of Oxford

From sebastian.rahtz at oucs.ox.ac.uk  Wed Jan 18 07:24:36 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Wed, 18 Jan 2012 12:24:36 +0000
Subject: [tei-council] version 2.0.1 p5subset.xml states "edition 2.0.0"
In-Reply-To: <4F160E96.2010202@oucs.ox.ac.uk>
References: <48F7E21F-4B77-4865-AB90-47F6AA73ADBF@edirom.de>
	<4F0F1AD5.4070101@uvic.ca> <4F159DC1.4010001@kcl.ac.uk>
	<4F160E96.2010202@oucs.ox.ac.uk>
Message-ID: <c192bcd8-36a8-4468-b742-ecd720d1814e@exht04.ad.oak.ox.ac.uk>

no problem with dates. I'll need to do a new stylesheet release before then, to 
get the Guidelines formatting right.

we have not resolved the issue about  AdBlock and "msad". can we choose
between

   1. ignore it. caveat blockor.
   2. rejig our IDs to use "mss" instead of "ms" (a pain, and breaks published links). would it work?
   3. rejig the stylesheets to rewrite all refs as tei_$whatever (needs dev work, breaks published links)

My personal preference is in the order above.

--
Stormageddon Rahtz      
Head of Information and Support Group
Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431

S?lo le pido a Dios
que el futuro no me sea indiferente


From gabriel.bodard at kcl.ac.uk  Wed Jan 18 07:42:40 2012
From: gabriel.bodard at kcl.ac.uk (Gabriel Bodard)
Date: Wed, 18 Jan 2012 12:42:40 +0000
Subject: [tei-council] version 2.0.1 p5subset.xml states "edition 2.0.0"
In-Reply-To: <c192bcd8-36a8-4468-b742-ecd720d1814e@exht04.ad.oak.ox.ac.uk>
References: <48F7E21F-4B77-4865-AB90-47F6AA73ADBF@edirom.de>
	<4F0F1AD5.4070101@uvic.ca> <4F159DC1.4010001@kcl.ac.uk>
	<4F160E96.2010202@oucs.ox.ac.uk>
	<c192bcd8-36a8-4468-b742-ecd720d1814e@exht04.ad.oak.ox.ac.uk>
Message-ID: <4F16BE40.1030308@kcl.ac.uk>

Given that a subset of 1. "ignore it" is potentially partly resolved by 
all of us (right?) having requested an exception to whatever ABP filter 
we use, it's not the worst option in the world.

2 & 3 both have the problem that is bothering Sebastian, but 3 is of 
course much worse in this case (2 being in practice (a) easy and (b) 
relatively minor inconvenience to anybody). I don't suppose you can 
write a rewrite rule for file fragments, can you?

My preferences, therefore, are (in order): 2 - 1 - 3.

Gabby

On 2012-01-18 12:24, Sebastian Rahtz wrote:
> no problem with dates. I'll need to do a new stylesheet release before then, to
> get the Guidelines formatting right.
>
> we have not resolved the issue about  AdBlock and "msad". can we choose
> between
>
>     1. ignore it. caveat blockor.
>     2. rejig our IDs to use "mss" instead of "ms" (a pain, and breaks published links). would it work?
>     3. rejig the stylesheets to rewrite all refs as tei_$whatever (needs dev work, breaks published links)
>
> My personal preference is in the order above.
>
> --
> Stormageddon Rahtz
> Head of Information and Support Group
> Oxford University Computing Services
> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>
> S?lo le pido a Dios
> que el futuro no me sea indiferente
>

-- 
Dr Gabriel BODARD
(Research Associate in Digital Epigraphy)

Department of Digital Humanities
King's College London
26-29 Drury Lane
London WC2B 5RL

Email: gabriel.bodard at kcl.ac.uk
Tel: +44 (0)20 7848 1388
Fax: +44 (0)20 7848 2980

http://www.digitalclassicist.org/
http://www.currentepigraphy.org/

From sebastian.rahtz at oucs.ox.ac.uk  Wed Jan 18 07:54:46 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Wed, 18 Jan 2012 12:54:46 +0000
Subject: [tei-council] version 2.0.1 p5subset.xml states "edition 2.0.0"
In-Reply-To: <4F16BE40.1030308@kcl.ac.uk>
References: <48F7E21F-4B77-4865-AB90-47F6AA73ADBF@edirom.de>
	<4F0F1AD5.4070101@uvic.ca> <4F159DC1.4010001@kcl.ac.uk>
	<4F160E96.2010202@oucs.ox.ac.uk>
	<c192bcd8-36a8-4468-b742-ecd720d1814e@exht04.ad.oak.ox.ac.uk>
	<4F16BE40.1030308@kcl.ac.uk>
Message-ID: <1B7AE77F-D916-41EC-833C-CC01F8BDCB66@oucs.ox.ac.uk>


On 18 Jan 2012, at 12:42, Gabriel Bodard wrote:

> 
> 2 & 3 both have the problem that is bothering Sebastian, but 3 is of 
> course much worse in this case (2 being in practice (a) easy and (b) 
> relatively minor inconvenience to anybody). I don't suppose you can 
> write a rewrite rule for file fragments, can you?


yes, given careful thought, I think we could trap #msad and rewrite to #mssad.
I'm not volunteering, mind, you can spend whole days understanding
Apache mod_rewrite :-}
--
Stormageddon Rahtz      
Head of Information and Support Group
Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431

S?lo le pido a Dios
que el futuro no me sea indiferente


From mholmes at uvic.ca  Wed Jan 18 08:07:39 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Wed, 18 Jan 2012 05:07:39 -0800
Subject: [tei-council] version 2.0.1 p5subset.xml states "edition 2.0.0"
In-Reply-To: <4F160E96.2010202@oucs.ox.ac.uk>
References: <48F7E21F-4B77-4865-AB90-47F6AA73ADBF@edirom.de>	<4F0F1AD5.4070101@uvic.ca>
	<4F159DC1.4010001@kcl.ac.uk> <4F160E96.2010202@oucs.ox.ac.uk>
Message-ID: <4F16C41B.2050709@uvic.ca>

Works for me. :-)



On 12-01-17 04:13 PM, James Cummings wrote:
>
> Hi all,
>
> Since no one else has piped up, can I suggest a schedule:
>
> 31 January midnight GMT: submission deadline of significant changes
> 1 February: Whole Day for council to proofread and correct typos.
> 2nd February: Release (Codename: Groundhog Day)
>
> Since Martin asked, I suggest him as release technician.
>
> Any reasons why these dates are wholly unsuitable?
>
> -James
>
> On 17/01/12 16:11, Gabriel Bodard wrote:
>> Has there been any consensus on when 2.0.2 might be put out?
>>
>> (I ask because, if it's soon I won't both hacking the EpiDoc schema to
>> allow geo/@decl; I'll just wait for TEI to introduce it and regenerate
>> the schema properly. :-) )
>>
>> G
>>
>> On 2012-01-12 17:39, Martin Holmes wrote:
>>> Hi all,
>>>
>>> I think we need to release a 2.0.2 soon, during which we again run
>>> through the instructions, after adding the tagging instruction. Should
>>> we do a quick trawl through the tickets and decide which ones might beS
>>> polished off quickly without controversy?
>>>
>>> Can I be the one to go through the release steps this time?
>>>
>>> Cheers,
>>> Martin
>>>
>>> On 12-01-12 08:27 AM, Peter Stadler wrote:
>>>> Dear geeks again,
>>>>
>>>> again wondering: just downloaded the current release 2.0.1 from sourceforge (tei-2.0.1.zip) and the editionStmt at tei-2.0.1/xml/tei/p5subset.xml reads<edition>2.0.0 Last updated on<date when="2011-12-16">16th December 2011</date>.</edition>
>>>>
>>>> Does that mean it wasn't updated at all or is just the editionStmt wrong?
>>>>
>>>> Many thanks again
>>>> Peter
>>>>
>>>
>>
>
>

From mholmes at uvic.ca  Wed Jan 18 08:33:21 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Wed, 18 Jan 2012 05:33:21 -0800
Subject: [tei-council] version 2.0.1 p5subset.xml states "edition 2.0.0"
In-Reply-To: <c192bcd8-36a8-4468-b742-ecd720d1814e@exht04.ad.oak.ox.ac.uk>
References: <48F7E21F-4B77-4865-AB90-47F6AA73ADBF@edirom.de>	<4F0F1AD5.4070101@uvic.ca>
	<4F159DC1.4010001@kcl.ac.uk>	<4F160E96.2010202@oucs.ox.ac.uk>
	<c192bcd8-36a8-4468-b742-ecd720d1814e@exht04.ad.oak.ox.ac.uk>
Message-ID: <4F16CA21.5060105@uvic.ca>

My preference is for #1 now, and #3 for a future major release.

Cheers,
Martin

On 12-01-18 04:24 AM, Sebastian Rahtz wrote:
> no problem with dates. I'll need to do a new stylesheet release before then, to
> get the Guidelines formatting right.
>
> we have not resolved the issue about  AdBlock and "msad". can we choose
> between
>
>     1. ignore it. caveat blockor.
>     2. rejig our IDs to use "mss" instead of "ms" (a pain, and breaks published links). would it work?
>     3. rejig the stylesheets to rewrite all refs as tei_$whatever (needs dev work, breaks published links)
>
> My personal preference is in the order above.
>
> --
> Stormageddon Rahtz
> Head of Information and Support Group
> Oxford University Computing Services
> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>
> S?lo le pido a Dios
> que el futuro no me sea indiferente
>

From James.Cummings at oucs.ox.ac.uk  Wed Jan 18 08:50:22 2012
From: James.Cummings at oucs.ox.ac.uk (James Cummings)
Date: Wed, 18 Jan 2012 13:50:22 +0000
Subject: [tei-council] version 2.0.1 p5subset.xml states "edition 2.0.0"
In-Reply-To: <1B7AE77F-D916-41EC-833C-CC01F8BDCB66@oucs.ox.ac.uk>
References: <48F7E21F-4B77-4865-AB90-47F6AA73ADBF@edirom.de>	<4F0F1AD5.4070101@uvic.ca>
	<4F159DC1.4010001@kcl.ac.uk>	<4F160E96.2010202@oucs.ox.ac.uk>	<c192bcd8-36a8-4468-b742-ecd720d1814e@exht04.ad.oak.ox.ac.uk>	<4F16BE40.1030308@kcl.ac.uk>
	<1B7AE77F-D916-41EC-833C-CC01F8BDCB66@oucs.ox.ac.uk>
Message-ID: <4F16CE1E.5080609@oucs.ox.ac.uk>

On 18/01/12 12:54, Sebastian Rahtz wrote:
>> 2&  3 both have the problem that is bothering Sebastian, but 3 is of
>> course much worse in this case (2 being in practice (a) easy and (b)
>> relatively minor inconvenience to anybody). I don't suppose you can
>> write a rewrite rule for file fragments, can you?
> yes, given careful thought, I think we could trap #msad and rewrite to #mssad.
> I'm not volunteering, mind, you can spend whole days understanding
> Apache mod_rewrite :-}

Any disagreements that this is the right course of action?

I'm assuming we are:
a) Changing the source to make @xml:id 'msad' and the child 
@xml:id's for that section into 'mssad' and similar. (So people 
looking at latest version or making new bookmarks have no problem.)
b) Changing any internal references we have to any of these sections
c) trap any url that has #msad* in and replace that matching bit 
with #mssad* in an apache rewrite rule.
d) What about changing historical versions in the vault? Should 
we just leave these?

-James

-- 
Dr James Cummings, InfoDev,
Computing Services, University of Oxford

From sebastian.rahtz at oucs.ox.ac.uk  Wed Jan 18 08:57:41 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Wed, 18 Jan 2012 13:57:41 +0000
Subject: [tei-council] version 2.0.1 p5subset.xml states "edition 2.0.0"
In-Reply-To: <4F16CE1E.5080609@oucs.ox.ac.uk>
References: <48F7E21F-4B77-4865-AB90-47F6AA73ADBF@edirom.de>
	<4F0F1AD5.4070101@uvic.ca>	<4F159DC1.4010001@kcl.ac.uk>
	<4F160E96.2010202@oucs.ox.ac.uk>
	<c192bcd8-36a8-4468-b742-ecd720d1814e@exht04.ad.oak.ox.ac.uk>
	<4F16BE40.1030308@kcl.ac.uk>
	<1B7AE77F-D916-41EC-833C-CC01F8BDCB66@oucs.ox.ac.uk>
	<4F16CE1E.5080609@oucs.ox.ac.uk>
Message-ID: <778FBF03-1354-4F83-A17D-009F88F1AB30@oucs.ox.ac.uk>

well, it does mean the IDs are out of sync with the file name. it is no coincidence
the thing is called MS-ManuscriptDescription.xml, and generates MS.html

should it change to MSS.html?

> c) trap any url that has #msad* in and replace that matching bit 
> with #mssad* in an apache rewrite rule.

is that a volunteer to write the rule? :-}

> d) What about changing historical versions in the vault? Should 
> we just leave these?


gosh yes. tinkering with all the generating HTML would be vile,
and regenerating almost impossible.
--
Stormageddon Rahtz      
Head of Information and Support Group
Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431

S?lo le pido a Dios
que el futuro no me sea indiferente


From PFSchaffner at umich.edu  Wed Jan 18 10:38:04 2012
From: PFSchaffner at umich.edu (Paul F. Schaffner)
Date: Wed, 18 Jan 2012 10:38:04 -0500 (EST)
Subject: [tei-council] version 2.0.1 p5subset.xml states "edition 2.0.0"
In-Reply-To: <4F16CE1E.5080609@oucs.ox.ac.uk>
References: <48F7E21F-4B77-4865-AB90-47F6AA73ADBF@edirom.de>
	<4F0F1AD5.4070101@uvic.ca>
	<4F159DC1.4010001@kcl.ac.uk> <4F160E96.2010202@oucs.ox.ac.uk>
	<c192bcd8-36a8-4468-b742-ecd720d1814e@exht04.ad.oak.ox.ac.uk>
	<4F16BE40.1030308@kcl.ac.uk>
	<1B7AE77F-D916-41EC-833C-CC01F8BDCB66@oucs.ox.ac.uk>
	<4F16CE1E.5080609@oucs.ox.ac.uk>
Message-ID: <Pine.LNX.4.64.1201181034510.4511@punchout.gpcc.itd.umich.edu>

On Wed, 18 Jan 2012, James Cummings wrote:

> On 18/01/12 12:54, Sebastian Rahtz wrote:
> >> 2&  3 both have the problem that is bothering Sebastian, but 3 is of
> >> course much worse in this case (2 being in practice (a) easy and (b)
> >> relatively minor inconvenience to anybody). I don't suppose you can
> >> write a rewrite rule for file fragments, can you?
> > yes, given careful thought, I think we could trap #msad and rewrite to #mssad.
> > I'm not volunteering, mind, you can spend whole days understanding
> > Apache mod_rewrite :-}
> 
> Any disagreements that this is the right course of action?

If I had to vote, I'd go with 'do nothing.' People who filter content
have to know that the filters are imperfect--that they may be trapping 
dolphins with their catch of tuna.

pfs

--------------------------------------------------------------------
Paul Schaffner | PFSchaffner at umich.edu | http://www.umich.edu/~pfs/
316-C Hatcher Library N, Univ. of Michigan, Ann Arbor MI 48109-1190
--------------------------------------------------------------------

From lou.burnard at retired.ox.ac.uk  Wed Jan 18 10:53:54 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Wed, 18 Jan 2012 15:53:54 +0000
Subject: [tei-council] version 2.0.1 p5subset.xml states "edition 2.0.0"
In-Reply-To: <Pine.LNX.4.64.1201181034510.4511@punchout.gpcc.itd.umich.edu>
References: <48F7E21F-4B77-4865-AB90-47F6AA73ADBF@edirom.de>	<4F0F1AD5.4070101@uvic.ca>	<4F159DC1.4010001@kcl.ac.uk>
	<4F160E96.2010202@oucs.ox.ac.uk>	<c192bcd8-36a8-4468-b742-ecd720d1814e@exht04.ad.oak.ox.ac.uk>	<4F16BE40.1030308@kcl.ac.uk>	<1B7AE77F-D916-41EC-833C-CC01F8BDCB66@oucs.ox.ac.uk>	<4F16CE1E.5080609@oucs.ox.ac.uk>
	<Pine.LNX.4.64.1201181034510.4511@punchout.gpcc.itd.umich.edu>
Message-ID: <4F16EB12.5030900@retired.ox.ac.uk>

On 18/01/12 15:38, Paul F. Schaffner wrote:
> On Wed, 18 Jan 2012, James Cummings wrote:
>
>> On 18/01/12 12:54, Sebastian Rahtz wrote:
>>>> 2&   3 both have the problem that is bothering Sebastian, but 3 is of
>>>> course much worse in this case (2 being in practice (a) easy and (b)
>>>> relatively minor inconvenience to anybody). I don't suppose you can
>>>> write a rewrite rule for file fragments, can you?
>>> yes, given careful thought, I think we could trap #msad and rewrite to #mssad.
>>> I'm not volunteering, mind, you can spend whole days understanding
>>> Apache mod_rewrite :-}
>>
>> Any disagreements that this is the right course of action?
>
> If I had to vote, I'd go with 'do nothing.' People who filter content
> have to know that the filters are imperfect--that they may be trapping
> dolphins with their catch of tuna.
>

I would also vote for doing nothing. I really dont see any good reason 
to over-react in this way, especially since (if I understand correctly) 
this problem was rectified by the filtering agency within 48 hours of 
our reporting the problem. We would introduce a whole load of broken 
links to counter a non-existent problem which only ever affected a small 
number of people. If we are serious about wanting to rationalise the 
identifiers, then we should do it properly, once for all, not in a piece 
meal haphazard fashion. That just looks silly.

From gabriel.bodard at kcl.ac.uk  Wed Jan 18 11:17:04 2012
From: gabriel.bodard at kcl.ac.uk (Gabriel Bodard)
Date: Wed, 18 Jan 2012 16:17:04 +0000
Subject: [tei-council] version 2.0.1 p5subset.xml states "edition 2.0.0"
In-Reply-To: <4F16EB12.5030900@retired.ox.ac.uk>
References: <48F7E21F-4B77-4865-AB90-47F6AA73ADBF@edirom.de>
	<4F0F1AD5.4070101@uvic.ca>	<4F159DC1.4010001@kcl.ac.uk>
	<4F160E96.2010202@oucs.ox.ac.uk>
	<c192bcd8-36a8-4468-b742-ecd720d1814e@exht04.ad.oak.ox.ac.uk>
	<4F16BE40.1030308@kcl.ac.uk>
	<1B7AE77F-D916-41EC-833C-CC01F8BDCB66@oucs.ox.ac.uk>
	<4F16CE1E.5080609@oucs.ox.ac.uk>
	<Pine.LNX.4.64.1201181034510.4511@punchout.gpcc.itd.umich.edu>
	<4F16EB12.5030900@retired.ox.ac.uk>
Message-ID: <4F16F080.5080105@kcl.ac.uk>

For the record it's still not fixed for me. When I look at 
<http://www.tei-c.org/release/doc/tei-p5-doc/en/html/MS.html#msad> in 
Firefox, I see no section 10.9.

(There are several filters in use in ABP--the only one that we have 
confirmation have approved an exception for this is the one Martin made 
the request to...)

If we could fix this with a rewrite, then it would be invisible to most 
people, and therefore not look silly at all.

G

On 2012-01-18 15:53, Lou Burnard wrote:
> I would also vote for doing nothing. I really dont see any good reason
> to over-react in this way, especially since (if I understand correctly)
> this problem was rectified by the filtering agency within 48 hours of
> our reporting the problem. We would introduce a whole load of broken
> links to counter a non-existent problem which only ever affected a small
> number of people. If we are serious about wanting to rationalise the
> identifiers, then we should do it properly, once for all, not in a piece
> meal haphazard fashion. That just looks silly.

-- 
Dr Gabriel BODARD
(Research Associate in Digital Epigraphy)

Department of Digital Humanities
King's College London
26-29 Drury Lane
London WC2B 5RL

Email: gabriel.bodard at kcl.ac.uk
Tel: +44 (0)20 7848 1388
Fax: +44 (0)20 7848 2980

http://www.digitalclassicist.org/
http://www.currentepigraphy.org/

From sebastian.rahtz at oucs.ox.ac.uk  Wed Jan 18 12:13:00 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Wed, 18 Jan 2012 17:13:00 +0000
Subject: [tei-council] version 2.0.1 p5subset.xml states "edition 2.0.0"
In-Reply-To: <4F16EB12.5030900@retired.ox.ac.uk>
References: <48F7E21F-4B77-4865-AB90-47F6AA73ADBF@edirom.de>
	<4F0F1AD5.4070101@uvic.ca>	<4F159DC1.4010001@kcl.ac.uk>
	<4F160E96.2010202@oucs.ox.ac.uk>
	<c192bcd8-36a8-4468-b742-ecd720d1814e@exht04.ad.oak.ox.ac.uk>
	<4F16BE40.1030308@kcl.ac.uk>
	<1B7AE77F-D916-41EC-833C-CC01F8BDCB66@oucs.ox.ac.uk>
	<4F16CE1E.5080609@oucs.ox.ac.uk>
	<Pine.LNX.4.64.1201181034510.4511@punchout.gpcc.itd.umich.edu>
	<4F16EB12.5030900@retired.ox.ac.uk>
Message-ID: <1FB0CF37-4883-42F7-B3BA-F4D382DF3F43@oucs.ox.ac.uk>


On 18 Jan 2012, at 15:53, Lou Burnard wrote:

> our reporting the problem. We would introduce a whole load of broken 
> links to counter a non-existent problem which only ever affected a small 
> number of people. If we are serious about wanting to rationalise the 
> identifiers, then we should do it properly, once for all, not in a piece 
> meal haphazard fashion. That just looks silly.

You're right, but I think you are over-egging it.
a) the broken link problem is really minimal (and solvable
if we need to), and b) change the rule for MS that we
use the suffix "mss" instead of "ms" is perfectly rational
and not a change to practice.

I still vote for "do nothing" as well, but shan't cry if
we go for rational ID rename.

--
Stormageddon Rahtz      
Head of Information and Support Group
Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431

S?lo le pido a Dios
que el futuro no me sea indiferente


From mholmes at uvic.ca  Wed Jan 18 12:14:58 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Wed, 18 Jan 2012 09:14:58 -0800
Subject: [tei-council] version 2.0.1 p5subset.xml states "edition 2.0.0"
In-Reply-To: <4F16EB12.5030900@retired.ox.ac.uk>
References: <48F7E21F-4B77-4865-AB90-47F6AA73ADBF@edirom.de>	<4F0F1AD5.4070101@uvic.ca>	<4F159DC1.4010001@kcl.ac.uk>	<4F160E96.2010202@oucs.ox.ac.uk>	<c192bcd8-36a8-4468-b742-ecd720d1814e@exht04.ad.oak.ox.ac.uk>	<4F16BE40.1030308@kcl.ac.uk>	<1B7AE77F-D916-41EC-833C-CC01F8BDCB66@oucs.ox.ac.uk>	<4F16CE1E.5080609@oucs.ox.ac.uk>	<Pine.LNX.4.64.1201181034510.4511@punchout.gpcc.itd.umich.edu>
	<4F16EB12.5030900@retired.ox.ac.uk>
Message-ID: <4F16FE12.3010406@uvic.ca>

On 12-01-18 07:53 AM, Lou Burnard wrote:
> On 18/01/12 15:38, Paul F. Schaffner wrote:
>> On Wed, 18 Jan 2012, James Cummings wrote:
>>
>>> On 18/01/12 12:54, Sebastian Rahtz wrote:
>>>>> 2&    3 both have the problem that is bothering Sebastian, but 3 is of
>>>>> course much worse in this case (2 being in practice (a) easy and (b)
>>>>> relatively minor inconvenience to anybody). I don't suppose you can
>>>>> write a rewrite rule for file fragments, can you?
>>>> yes, given careful thought, I think we could trap #msad and rewrite to #mssad.
>>>> I'm not volunteering, mind, you can spend whole days understanding
>>>> Apache mod_rewrite :-}
>>>
>>> Any disagreements that this is the right course of action?
>>
>> If I had to vote, I'd go with 'do nothing.' People who filter content
>> have to know that the filters are imperfect--that they may be trapping
>> dolphins with their catch of tuna.
>>
>
> I would also vote for doing nothing. I really dont see any good reason
> to over-react in this way, especially since (if I understand correctly)
> this problem was rectified by the filtering agency within 48 hours of
> our reporting the problem. We would introduce a whole load of broken
> links to counter a non-existent problem which only ever affected a small
> number of people. If we are serious about wanting to rationalise the
> identifiers, then we should do it properly, once for all, not in a piece
> meal haphazard fashion. That just looks silly.

The EasyList maintainer fixed the problem immediately, but the Fanboy 
list maintainer has ignored my false-positive report completely (and has 
meanwhile been updating his/her block list regularly). So there probably 
are users out there still suffering from this problem, and other block 
lists we don't know about that include it.

That's why I like #3 as a long-term option. Someday some ad company 
might decide to prefix all of its ids with "tei_". However, in that 
case, we would at least see a consistent and dramatic effect, and we 
could take more concerted steps to get the false-positives fixed, as 
well as recommending publicly that users avoid specific lists we know 
have the problem. When it's just a question of a single div in a single 
chapter, it's not worth worrying about, I don't think.

Cheers,
Martin

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From mholmes at uvic.ca  Wed Jan 18 12:16:05 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Wed, 18 Jan 2012 09:16:05 -0800
Subject: [tei-council] version 2.0.1 p5subset.xml states "edition 2.0.0"
In-Reply-To: <4F16F080.5080105@kcl.ac.uk>
References: <48F7E21F-4B77-4865-AB90-47F6AA73ADBF@edirom.de>	<4F0F1AD5.4070101@uvic.ca>	<4F159DC1.4010001@kcl.ac.uk>	<4F160E96.2010202@oucs.ox.ac.uk>	<c192bcd8-36a8-4468-b742-ecd720d1814e@exht04.ad.oak.ox.ac.uk>	<4F16BE40.1030308@kcl.ac.uk>	<1B7AE77F-D916-41EC-833C-CC01F8BDCB66@oucs.ox.ac.uk>	<4F16CE1E.5080609@oucs.ox.ac.uk>	<Pine.LNX.4.64.1201181034510.4511@punchout.gpcc.itd.umich.edu>	<4F16EB12.5030900@retired.ox.ac.uk>
	<4F16F080.5080105@kcl.ac.uk>
Message-ID: <4F16FE55.2020304@uvic.ca>

Which blocklist are you using? We should go after that one too.

Cheers,
Martin

On 12-01-18 08:17 AM, Gabriel Bodard wrote:
> For the record it's still not fixed for me. When I look at
> <http://www.tei-c.org/release/doc/tei-p5-doc/en/html/MS.html#msad>  in
> Firefox, I see no section 10.9.
>
> (There are several filters in use in ABP--the only one that we have
> confirmation have approved an exception for this is the one Martin made
> the request to...)
>
> If we could fix this with a rewrite, then it would be invisible to most
> people, and therefore not look silly at all.
>
> G
>
> On 2012-01-18 15:53, Lou Burnard wrote:
>> I would also vote for doing nothing. I really dont see any good reason
>> to over-react in this way, especially since (if I understand correctly)
>> this problem was rectified by the filtering agency within 48 hours of
>> our reporting the problem. We would introduce a whole load of broken
>> links to counter a non-existent problem which only ever affected a small
>> number of people. If we are serious about wanting to rationalise the
>> identifiers, then we should do it properly, once for all, not in a piece
>> meal haphazard fashion. That just looks silly.
>

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From sebastian.rahtz at oucs.ox.ac.uk  Wed Jan 18 13:41:56 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Wed, 18 Jan 2012 18:41:56 +0000
Subject: [tei-council] Ann Arbor spring meeting
In-Reply-To: <CAA2irt+8ZcDx6rBYOoZ-f9FrKYP1B+O3pqsxr82JT+hpaA2MXQ@mail.gmail.com>
References: <CAA2irt+8ZcDx6rBYOoZ-f9FrKYP1B+O3pqsxr82JT+hpaA2MXQ@mail.gmail.com>
Message-ID: <8D7B6E12-1923-4DFB-B676-DF361DE81C40@oucs.ox.ac.uk>


On 22 Dec 2011, at 14:12, Rebecca Welzenbach wrote:

> Dear colleagues,
> 
> Most of you have filled out the MeetingWizard poll to determine a time
> to meet this spring, and so far there is one possibility that works
> for all those who have responded (Christmas miracle!): Monday, April
> 16-Wednesday April 18.



is this confirmed now? trying to make family holiday plans.
--
Stormageddon Rahtz      
Head of Information and Support Group, Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431

S?lo le pido a Dios
que el futuro no me sea indiferente


From rwelzenbach at gmail.com  Fri Jan 20 11:32:47 2012
From: rwelzenbach at gmail.com (Rebecca Welzenbach)
Date: Fri, 20 Jan 2012 11:32:47 -0500
Subject: [tei-council] Ann Arbor spring meeting
In-Reply-To: <8D7B6E12-1923-4DFB-B676-DF361DE81C40@oucs.ox.ac.uk>
References: <CAA2irt+8ZcDx6rBYOoZ-f9FrKYP1B+O3pqsxr82JT+hpaA2MXQ@mail.gmail.com>
	<8D7B6E12-1923-4DFB-B676-DF361DE81C40@oucs.ox.ac.uk>
Message-ID: <CAA2irtKZ0k_hv89WotTCZ0VuQ=B6pUwDb4FemkLuyRWjMF9-vw@mail.gmail.com>

Hi all,

I recommend that we confirm April 16-18 as the dates for our meeting.
James and I had some communication about this last week and I proposed
this to him, but I haven't heard back since then, and wasn't sure if
he should give the go-ahead to move forward.

Becky


On Wed, Jan 18, 2012 at 1:41 PM, Sebastian Rahtz
<sebastian.rahtz at oucs.ox.ac.uk> wrote:
>
> On 22 Dec 2011, at 14:12, Rebecca Welzenbach wrote:
>
>> Dear colleagues,
>>
>> Most of you have filled out the MeetingWizard poll to determine a time
>> to meet this spring, and so far there is one possibility that works
>> for all those who have responded (Christmas miracle!): Monday, April
>> 16-Wednesday April 18.
>
>
>
> is this confirmed now? trying to make family holiday plans.
> --
> Stormageddon Rahtz
> Head of Information and Support Group, Oxford University Computing Services
> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>
> S?lo le pido a Dios
> que el futuro no me sea indiferente
>

From mholmes at uvic.ca  Fri Jan 20 11:41:31 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Fri, 20 Jan 2012 08:41:31 -0800
Subject: [tei-council] Ann Arbor spring meeting
In-Reply-To: <CAA2irtKZ0k_hv89WotTCZ0VuQ=B6pUwDb4FemkLuyRWjMF9-vw@mail.gmail.com>
References: <CAA2irt+8ZcDx6rBYOoZ-f9FrKYP1B+O3pqsxr82JT+hpaA2MXQ@mail.gmail.com>	<8D7B6E12-1923-4DFB-B676-DF361DE81C40@oucs.ox.ac.uk>
	<CAA2irtKZ0k_hv89WotTCZ0VuQ=B6pUwDb4FemkLuyRWjMF9-vw@mail.gmail.com>
Message-ID: <4F19993B.5040606@uvic.ca>

The sooner the better, I think -- plane tickets get more expensive as we 
get closer.

Cheers,
Martin

On 12-01-20 08:32 AM, Rebecca Welzenbach wrote:
> Hi all,
>
> I recommend that we confirm April 16-18 as the dates for our meeting.
> James and I had some communication about this last week and I proposed
> this to him, but I haven't heard back since then, and wasn't sure if
> he should give the go-ahead to move forward.
>
> Becky
>
>
> On Wed, Jan 18, 2012 at 1:41 PM, Sebastian Rahtz
> <sebastian.rahtz at oucs.ox.ac.uk>  wrote:
>>
>> On 22 Dec 2011, at 14:12, Rebecca Welzenbach wrote:
>>
>>> Dear colleagues,
>>>
>>> Most of you have filled out the MeetingWizard poll to determine a time
>>> to meet this spring, and so far there is one possibility that works
>>> for all those who have responded (Christmas miracle!): Monday, April
>>> 16-Wednesday April 18.
>>
>>
>>
>> is this confirmed now? trying to make family holiday plans.
>> --
>> Stormageddon Rahtz
>> Head of Information and Support Group, Oxford University Computing Services
>> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>>
>> S?lo le pido a Dios
>> que el futuro no me sea indiferente
>>

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From James.Cummings at oucs.ox.ac.uk  Fri Jan 20 11:51:56 2012
From: James.Cummings at oucs.ox.ac.uk (James Cummings)
Date: Fri, 20 Jan 2012 16:51:56 +0000
Subject: [tei-council] Ann Arbor spring meeting
In-Reply-To: <CAA2irtKZ0k_hv89WotTCZ0VuQ=B6pUwDb4FemkLuyRWjMF9-vw@mail.gmail.com>
References: <CAA2irt+8ZcDx6rBYOoZ-f9FrKYP1B+O3pqsxr82JT+hpaA2MXQ@mail.gmail.com>	<8D7B6E12-1923-4DFB-B676-DF361DE81C40@oucs.ox.ac.uk>
	<CAA2irtKZ0k_hv89WotTCZ0VuQ=B6pUwDb4FemkLuyRWjMF9-vw@mail.gmail.com>
Message-ID: <4F199BAC.6090007@oucs.ox.ac.uk>

On 20/01/12 16:32, Rebecca Welzenbach wrote:
> Hi all,
>
> I recommend that we confirm April 16-18 as the dates for our meeting.
> James and I had some communication about this last week and I proposed
> this to him, but I haven't heard back since then, and wasn't sure if
> he should give the go-ahead to move forward.

Hi,

Sorry about that. Yes, I say we confirm those dates and everyone 
put them in their diary RIGHT NOW!  So that is travel on the 
15th, Meetings on the 16/17/18 with potentially travel home on 
evening of the 18th. At least that is what I'm going to try to 
find in our flight booking system if possible.  (One can of 
course stay longer, but TEI-C won't cover your accommodation.)

-James

-- 
Dr James Cummings, InfoDev,
Computing Services, University of Oxford

From mholmes at uvic.ca  Fri Jan 20 13:36:50 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Fri, 20 Jan 2012 10:36:50 -0800
Subject: [tei-council] Ann Arbor spring meeting
In-Reply-To: <4F199BAC.6090007@oucs.ox.ac.uk>
References: <CAA2irt+8ZcDx6rBYOoZ-f9FrKYP1B+O3pqsxr82JT+hpaA2MXQ@mail.gmail.com>	<8D7B6E12-1923-4DFB-B676-DF361DE81C40@oucs.ox.ac.uk>	<CAA2irtKZ0k_hv89WotTCZ0VuQ=B6pUwDb4FemkLuyRWjMF9-vw@mail.gmail.com>
	<4F199BAC.6090007@oucs.ox.ac.uk>
Message-ID: <4F19B442.8030301@uvic.ca>

Re leaving on the 18th: how do we stand on staying the night of the 18th 
and travelling back the next day? I think I'd have to leave pretty early 
to get back to Victoria without overnighting somewhere, so the 18th 
wouldn't be much of a work day.

Cheers,
Martin

On 12-01-20 08:51 AM, James Cummings wrote:
> On 20/01/12 16:32, Rebecca Welzenbach wrote:
>> Hi all,
>>
>> I recommend that we confirm April 16-18 as the dates for our meeting.
>> James and I had some communication about this last week and I proposed
>> this to him, but I haven't heard back since then, and wasn't sure if
>> he should give the go-ahead to move forward.
>
> Hi,
>
> Sorry about that. Yes, I say we confirm those dates and everyone
> put them in their diary RIGHT NOW!  So that is travel on the
> 15th, Meetings on the 16/17/18 with potentially travel home on
> evening of the 18th. At least that is what I'm going to try to
> find in our flight booking system if possible.  (One can of
> course stay longer, but TEI-C won't cover your accommodation.)
>
> -James
>

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From James.Cummings at oucs.ox.ac.uk  Fri Jan 20 13:55:06 2012
From: James.Cummings at oucs.ox.ac.uk (James Cummings)
Date: Fri, 20 Jan 2012 18:55:06 +0000
Subject: [tei-council] Ann Arbor spring meeting
In-Reply-To: <4F19B442.8030301@uvic.ca>
References: <CAA2irt+8ZcDx6rBYOoZ-f9FrKYP1B+O3pqsxr82JT+hpaA2MXQ@mail.gmail.com>
	<8D7B6E12-1923-4DFB-B676-DF361DE81C40@oucs.ox.ac.uk>
	<CAA2irtKZ0k_hv89WotTCZ0VuQ=B6pUwDb4FemkLuyRWjMF9-vw@mail.gmail.com>
	<4F199BAC.6090007@oucs.ox.ac.uk> <4F19B442.8030301@uvic.ca>
Message-ID: <4F19B88A.8090802@oucs.ox.ac.uk>

On 20/01/12 18:36, Martin Holmes wrote:
> Re leaving on the 18th: how do we stand on staying the night of the 18th
> and travelling back the next day? I think I'd have to leave pretty early
> to get back to Victoria without overnighting somewhere, so the 18th
> wouldn't be much of a work day.

We probably have some degree flexibility on this, especially if everyone 
doesn't need it. The draft budget was done assuming 3 nights hotel at 
each meeting. But we might be able to get discounts which could offset 
some people staying for a fourth night.

(of course, in interest of saving more of the budget for other work, I 
remind council members if they know of any institutional or other 
funding for such things as travel to start applying for them now. ;-) )

-James

>
> Cheers,
> Martin
>
> On 12-01-20 08:51 AM, James Cummings wrote:
>> On 20/01/12 16:32, Rebecca Welzenbach wrote:
>>> Hi all,
>>>
>>> I recommend that we confirm April 16-18 as the dates for our meeting.
>>> James and I had some communication about this last week and I proposed
>>> this to him, but I haven't heard back since then, and wasn't sure if
>>> he should give the go-ahead to move forward.
>>
>> Hi,
>>
>> Sorry about that. Yes, I say we confirm those dates and everyone
>> put them in their diary RIGHT NOW!  So that is travel on the
>> 15th, Meetings on the 16/17/18 with potentially travel home on
>> evening of the 18th. At least that is what I'm going to try to
>> find in our flight booking system if possible.  (One can of
>> course stay longer, but TEI-C won't cover your accommodation.)
>>
>> -James
>>
>


-- 
Dr James Cummings, InfoDev,
Computing Services, University of Oxford

From kevin.s.hawkins at ultraslavonic.info  Sun Jan 22 11:47:26 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Sun, 22 Jan 2012 11:47:26 -0500
Subject: [tei-council] version 2.0.1 p5subset.xml states "edition 2.0.0"
In-Reply-To: <72C9A5F5-636A-4825-8F4D-61FB296317BF@oucs.ox.ac.uk>
References: <48F7E21F-4B77-4865-AB90-47F6AA73ADBF@edirom.de>
	<4F0F1AD5.4070101@uvic.ca>
	<72C9A5F5-636A-4825-8F4D-61FB296317BF@oucs.ox.ac.uk>
Message-ID: <4F1C3D9E.7060205@ultraslavonic.info>

It looks like

http://www.tei-c.org/Activities/Council/Working/tcw20.xml

still needs to be edited to add two steps:

a) update <edition>

b) create tags in subversion

James mentioned he would update this document over the holidays perhaps 
hasn't committed his changes in OpenCMS.

As for making these fixes in time for the next release, Martin created a 
ticket about (a):

http://purl.org/TEI/BUGS/3472984

whereas for (b), I believe the tags Sebastian created ( 
http://listserv.brown.edu/archives/cgi-bin/wa?A2=ind1201&L=TEI-L&P=R5601 
) are for 2.0.1, not the next release.  So that will need to be done as 
well.

--K.

On 1/12/12 12:44 PM, Sebastian Rahtz wrote:
>
> On 12 Jan 2012, at 17:39, Martin Holmes wrote:
>
>> Hi all,
>>
>> I think we need to release a 2.0.2 soon, during which we again run
>> through the instructions, after adding the tagging instruction.
>
> I have a script maketag which says
>
> svn cp -m "create tag of P5 release $1" -r "{$2}" \
>        https://tei.svn.sourceforge.net/svnroot/tei/trunk/P5 \
>        https://tei.svn.sourceforge.net/svnroot/tei/tags/P5_release_$1/
>
> as in
>
>      sh ../maketag 2.0.1 2011-12-22
>
> for retrospective addition of tags. better done on the way without the -r
>
>> Should
>> we do a quick trawl through the tickets and decide which ones might be
>> polished off quickly without controversy?
> if they change the content model, we'd go to 2.1.0?.
>
>>
>> Can I be the one to go through the release steps this time?
>
>
> we have not resolved the Debian issue yet. the sticking point
> is updating repo on a Fedora box
> --
> Stormageddon Rahtz
> Head of Information and Support Group
> Oxford University Computing Services
> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>
> S?lo le pido a Dios
> que el futuro no me sea indiferente
>

From mholmes at uvic.ca  Mon Jan 23 11:20:51 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Mon, 23 Jan 2012 08:20:51 -0800
Subject: [tei-council] version 2.0.1 p5subset.xml states "edition 2.0.0"
In-Reply-To: <4F1C3D9E.7060205@ultraslavonic.info>
References: <48F7E21F-4B77-4865-AB90-47F6AA73ADBF@edirom.de>	<4F0F1AD5.4070101@uvic.ca>	<72C9A5F5-636A-4825-8F4D-61FB296317BF@oucs.ox.ac.uk>
	<4F1C3D9E.7060205@ultraslavonic.info>
Message-ID: <4F1D88E3.7010708@uvic.ca>

With regard to a) below, the issue is that the p5subset.xml file ended 
up with the wrong version number. As far as I can tell from reading the 
Makefile, p5subset.xml is created like this:

${SAXON} ${SAXON_ARGS} -o:p5subset.xml ${DRIVER} Utilities/subset.xsl

where $(DRIVER) DRIVER=${SOURCETREE}/guidelines-${INPUTLANGUAGE}.xml, 
presumably meaning guidelines-en.xml. So the output <edition> info comes 
from the <edition> tag in the guidelines-en.xml file, and that's what 
should be edited right at the beginning of the process. The first 
section in this part of tcw20.xml says:

[quote]
Creating a new file release

First edit the file VERSION, and make it say what you are about to 
release...
[/quote]

Would it be sufficient to add this:

"At the same time, edit P5/Source/guidelines-en.xml to update the 
information in the <editionStmt>/<edition> tag to match the VERSION file."

Cheers,
Martin


On 12-01-22 08:47 AM, Kevin Hawkins wrote:
> It looks like
>
> http://www.tei-c.org/Activities/Council/Working/tcw20.xml
>
> still needs to be edited to add two steps:
>
> a) update<edition>
>
> b) create tags in subversion
>
> James mentioned he would update this document over the holidays perhaps
> hasn't committed his changes in OpenCMS.
>
> As for making these fixes in time for the next release, Martin created a
> ticket about (a):
>
> http://purl.org/TEI/BUGS/3472984
>
> whereas for (b), I believe the tags Sebastian created (
> http://listserv.brown.edu/archives/cgi-bin/wa?A2=ind1201&L=TEI-L&P=R5601
> ) are for 2.0.1, not the next release.  So that will need to be done as
> well.
>
> --K.
>
> On 1/12/12 12:44 PM, Sebastian Rahtz wrote:
>>
>> On 12 Jan 2012, at 17:39, Martin Holmes wrote:
>>
>>> Hi all,
>>>
>>> I think we need to release a 2.0.2 soon, during which we again run
>>> through the instructions, after adding the tagging instruction.
>>
>> I have a script maketag which says
>>
>> svn cp -m "create tag of P5 release $1" -r "{$2}" \
>>         https://tei.svn.sourceforge.net/svnroot/tei/trunk/P5 \
>>         https://tei.svn.sourceforge.net/svnroot/tei/tags/P5_release_$1/
>>
>> as in
>>
>>       sh ../maketag 2.0.1 2011-12-22
>>
>> for retrospective addition of tags. better done on the way without the -r
>>
>>> Should
>>> we do a quick trawl through the tickets and decide which ones might be
>>> polished off quickly without controversy?
>> if they change the content model, we'd go to 2.1.0?.
>>
>>>
>>> Can I be the one to go through the release steps this time?
>>
>>
>> we have not resolved the Debian issue yet. the sticking point
>> is updating repo on a Fedora box
>> --
>> Stormageddon Rahtz
>> Head of Information and Support Group
>> Oxford University Computing Services
>> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>>
>> S?lo le pido a Dios
>> que el futuro no me sea indiferente
>>

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From sebastian.rahtz at oucs.ox.ac.uk  Mon Jan 23 11:50:51 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Mon, 23 Jan 2012 16:50:51 +0000
Subject: [tei-council] version 2.0.1 p5subset.xml states "edition 2.0.0"
In-Reply-To: <4F1D88E3.7010708@uvic.ca>
References: <48F7E21F-4B77-4865-AB90-47F6AA73ADBF@edirom.de>
	<4F0F1AD5.4070101@uvic.ca>
	<72C9A5F5-636A-4825-8F4D-61FB296317BF@oucs.ox.ac.uk>
	<4F1C3D9E.7060205@ultraslavonic.info> <4F1D88E3.7010708@uvic.ca>
Message-ID: <9E3A94AC-64C6-4B4E-8258-C271EC350D78@oucs.ox.ac.uk>


On 23 Jan 2012, at 16:20, Martin Holmes wrote:
> Would it be sufficient to add this:
> 
> "At the same time, edit P5/Source/guidelines-en.xml to update the 
> information in the <editionStmt>/<edition> tag to match the VERSION file."
> 
is it all in editionStmt? i.e. date and version? but yes, that sounds right

--
Stormageddon Rahtz      
Head of Information and Support Group
Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431

S?lo le pido a Dios
que el futuro no me sea indiferente


From mholmes at uvic.ca  Mon Jan 23 11:59:03 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Mon, 23 Jan 2012 08:59:03 -0800
Subject: [tei-council] version 2.0.1 p5subset.xml states "edition 2.0.0"
In-Reply-To: <9E3A94AC-64C6-4B4E-8258-C271EC350D78@oucs.ox.ac.uk>
References: <48F7E21F-4B77-4865-AB90-47F6AA73ADBF@edirom.de>
	<4F0F1AD5.4070101@uvic.ca>
	<72C9A5F5-636A-4825-8F4D-61FB296317BF@oucs.ox.ac.uk>
	<4F1C3D9E.7060205@ultraslavonic.info> <4F1D88E3.7010708@uvic.ca>
	<9E3A94AC-64C6-4B4E-8258-C271EC350D78@oucs.ox.ac.uk>
Message-ID: <4F1D91D7.80102@uvic.ca>

Yes, it looks like this:

<editionStmt>
         <edition>2.0.1 Last updated on <date when="2011-12-22">22nd 
December 2011</date>.</edition>
       </editionStmt>

If no-one objects, I'll add this to the tcw.

Cheers,
Martin

On 12-01-23 08:50 AM, Sebastian Rahtz wrote:
>
> On 23 Jan 2012, at 16:20, Martin Holmes wrote:
>> Would it be sufficient to add this:
>>
>> "At the same time, edit P5/Source/guidelines-en.xml to update the
>> information in the<editionStmt>/<edition>  tag to match the VERSION file."
>>
> is it all in editionStmt? i.e. date and version? but yes, that sounds right
>
> --
> Stormageddon Rahtz
> Head of Information and Support Group
> Oxford University Computing Services
> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>
> S?lo le pido a Dios
> que el futuro no me sea indiferente
>
>

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From James.Cummings at oucs.ox.ac.uk  Mon Jan 23 12:17:02 2012
From: James.Cummings at oucs.ox.ac.uk (James Cummings)
Date: Mon, 23 Jan 2012 17:17:02 +0000
Subject: [tei-council] version 2.0.1 p5subset.xml states "edition 2.0.0"
In-Reply-To: <4F1D91D7.80102@uvic.ca>
References: <48F7E21F-4B77-4865-AB90-47F6AA73ADBF@edirom.de>	<4F0F1AD5.4070101@uvic.ca>	<72C9A5F5-636A-4825-8F4D-61FB296317BF@oucs.ox.ac.uk>	<4F1C3D9E.7060205@ultraslavonic.info>
	<4F1D88E3.7010708@uvic.ca>	<9E3A94AC-64C6-4B4E-8258-C271EC350D78@oucs.ox.ac.uk>
	<4F1D91D7.80102@uvic.ca>
Message-ID: <4F1D960E.8020203@oucs.ox.ac.uk>

Hi all,

See now, I thought I changed that when doing 2.0.1 (and there it 
is changed)... How come the DTD fragments (was that it?) didn't 
get changed? Is there another place I was supposed to change it 
that I didn't?

I didn't update tcw20 because there wasn't much different, in 
fact the process was all very smooth and seemed to be fine. I'll 
write up a step by step list for Martin to check through when he 
does it to double-check.

  -James

On 23/01/12 16:59, Martin Holmes wrote:
> Yes, it looks like this:
>
> <editionStmt>
>           <edition>2.0.1 Last updated on<date when="2011-12-22">22nd
> December 2011</date>.</edition>
>         </editionStmt>
>
> If no-one objects, I'll add this to the tcw.
>
> Cheers,
> Martin
>
> On 12-01-23 08:50 AM, Sebastian Rahtz wrote:
>>
>> On 23 Jan 2012, at 16:20, Martin Holmes wrote:
>>> Would it be sufficient to add this:
>>>
>>> "At the same time, edit P5/Source/guidelines-en.xml to update the
>>> information in the<editionStmt>/<edition>   tag to match the VERSION file."
>>>
>> is it all in editionStmt? i.e. date and version? but yes, that sounds right
>>
>> --
>> Stormageddon Rahtz
>> Head of Information and Support Group
>> Oxford University Computing Services
>> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>>
>> S?lo le pido a Dios
>> que el futuro no me sea indiferente
>>
>>
>


-- 
Dr James Cummings, InfoDev,
Computing Services, University of Oxford

From mholmes at uvic.ca  Mon Jan 23 13:12:07 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Mon, 23 Jan 2012 10:12:07 -0800
Subject: [tei-council] version 2.0.1 p5subset.xml states "edition 2.0.0"
In-Reply-To: <4F1D91D7.80102@uvic.ca>
References: <48F7E21F-4B77-4865-AB90-47F6AA73ADBF@edirom.de>	<4F0F1AD5.4070101@uvic.ca>	<72C9A5F5-636A-4825-8F4D-61FB296317BF@oucs.ox.ac.uk>	<4F1C3D9E.7060205@ultraslavonic.info>
	<4F1D88E3.7010708@uvic.ca>	<9E3A94AC-64C6-4B4E-8258-C271EC350D78@oucs.ox.ac.uk>
	<4F1D91D7.80102@uvic.ca>
Message-ID: <4F1DA2F7.2020802@uvic.ca>

That's done. Next is the bit about creating tags in SVN.

Cheers,
Martin

On 12-01-23 08:59 AM, Martin Holmes wrote:
> Yes, it looks like this:
>
> <editionStmt>
>           <edition>2.0.1 Last updated on<date when="2011-12-22">22nd
> December 2011</date>.</edition>
>         </editionStmt>
>
> If no-one objects, I'll add this to the tcw.
>
> Cheers,
> Martin
>
> On 12-01-23 08:50 AM, Sebastian Rahtz wrote:
>>
>> On 23 Jan 2012, at 16:20, Martin Holmes wrote:
>>> Would it be sufficient to add this:
>>>
>>> "At the same time, edit P5/Source/guidelines-en.xml to update the
>>> information in the<editionStmt>/<edition>   tag to match the VERSION file."
>>>
>> is it all in editionStmt? i.e. date and version? but yes, that sounds right
>>
>> --
>> Stormageddon Rahtz
>> Head of Information and Support Group
>> Oxford University Computing Services
>> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>>
>> S?lo le pido a Dios
>> que el futuro no me sea indiferente
>>
>>
>

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From mholmes at uvic.ca  Mon Jan 23 13:15:03 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Mon, 23 Jan 2012 10:15:03 -0800
Subject: [tei-council] version 2.0.1 p5subset.xml states "edition 2.0.0"
In-Reply-To: <4F1D960E.8020203@oucs.ox.ac.uk>
References: <48F7E21F-4B77-4865-AB90-47F6AA73ADBF@edirom.de>	<4F0F1AD5.4070101@uvic.ca>	<72C9A5F5-636A-4825-8F4D-61FB296317BF@oucs.ox.ac.uk>	<4F1C3D9E.7060205@ultraslavonic.info>	<4F1D88E3.7010708@uvic.ca>	<9E3A94AC-64C6-4B4E-8258-C271EC350D78@oucs.ox.ac.uk>	<4F1D91D7.80102@uvic.ca>
	<4F1D960E.8020203@oucs.ox.ac.uk>
Message-ID: <4F1DA3A7.90905@uvic.ca>

Do you want to add the svn tags bit to tcw20.xml while you're at it? 
Then I can slavishly follow the steps there, and we'll see if everything 
works this time around.

Cheers,
Martin

On 12-01-23 09:17 AM, James Cummings wrote:
> Hi all,
>
> See now, I thought I changed that when doing 2.0.1 (and there it
> is changed)... How come the DTD fragments (was that it?) didn't
> get changed? Is there another place I was supposed to change it
> that I didn't?
>
> I didn't update tcw20 because there wasn't much different, in
> fact the process was all very smooth and seemed to be fine. I'll
> write up a step by step list for Martin to check through when he
> does it to double-check.
>
>    -James
>
> On 23/01/12 16:59, Martin Holmes wrote:
>> Yes, it looks like this:
>>
>> <editionStmt>
>>            <edition>2.0.1 Last updated on<date when="2011-12-22">22nd
>> December 2011</date>.</edition>
>>          </editionStmt>
>>
>> If no-one objects, I'll add this to the tcw.
>>
>> Cheers,
>> Martin
>>
>> On 12-01-23 08:50 AM, Sebastian Rahtz wrote:
>>>
>>> On 23 Jan 2012, at 16:20, Martin Holmes wrote:
>>>> Would it be sufficient to add this:
>>>>
>>>> "At the same time, edit P5/Source/guidelines-en.xml to update the
>>>> information in the<editionStmt>/<edition>    tag to match the VERSION file."
>>>>
>>> is it all in editionStmt? i.e. date and version? but yes, that sounds right
>>>
>>> --
>>> Stormageddon Rahtz
>>> Head of Information and Support Group
>>> Oxford University Computing Services
>>> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>>>
>>> S?lo le pido a Dios
>>> que el futuro no me sea indiferente
>>>
>>>
>>
>
>

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From James.Cummings at oucs.ox.ac.uk  Tue Jan 24 06:15:00 2012
From: James.Cummings at oucs.ox.ac.uk (James Cummings)
Date: Tue, 24 Jan 2012 11:15:00 +0000
Subject: [tei-council] Ann Arbor spring meeting
In-Reply-To: <4F19B88A.8090802@oucs.ox.ac.uk>
References: <CAA2irt+8ZcDx6rBYOoZ-f9FrKYP1B+O3pqsxr82JT+hpaA2MXQ@mail.gmail.com>	<8D7B6E12-1923-4DFB-B676-DF361DE81C40@oucs.ox.ac.uk>	<CAA2irtKZ0k_hv89WotTCZ0VuQ=B6pUwDb4FemkLuyRWjMF9-vw@mail.gmail.com>	<4F199BAC.6090007@oucs.ox.ac.uk>
	<4F19B442.8030301@uvic.ca> <4F19B88A.8090802@oucs.ox.ac.uk>
Message-ID: <4F1E92B4.2060809@oucs.ox.ac.uk>


I've been looking at booking a flight from LHR to DTW for this 
meeting and the cheapest I could find for Sunday - Wednesday was 
1045 pounds.  However, if I included the Saturday, then the 
cheapest was around 538 pounds. I find the bizarre notion that 
one must include a Saturday (or be penalised by doubling the 
price) a strange one. The only 'overnight' flights I could find 
involved 15 hour layovers.

Gaby, Piotr, Sebastian, Lou:  Does it make sense then for those 
of us crossing the Atlantic to fly into DTW on Saturday? 
Charging the TEI for an extra day of hotel seems offset by the 
difference in flight cost.

Let me know what you think,

-James

On 20/01/12 18:55, James Cummings wrote:
> On 20/01/12 18:36, Martin Holmes wrote:
>> Re leaving on the 18th: how do we stand on staying the night of the 18th
>> and travelling back the next day? I think I'd have to leave pretty early
>> to get back to Victoria without overnighting somewhere, so the 18th
>> wouldn't be much of a work day.
>
> We probably have some degree flexibility on this, especially if everyone
> doesn't need it. The draft budget was done assuming 3 nights hotel at
> each meeting. But we might be able to get discounts which could offset
> some people staying for a fourth night.
>
> (of course, in interest of saving more of the budget for other work, I
> remind council members if they know of any institutional or other
> funding for such things as travel to start applying for them now. ;-) )
>
> -James
>
>>
>> Cheers,
>> Martin
>>
>> On 12-01-20 08:51 AM, James Cummings wrote:
>>> On 20/01/12 16:32, Rebecca Welzenbach wrote:
>>>> Hi all,
>>>>
>>>> I recommend that we confirm April 16-18 as the dates for our meeting.
>>>> James and I had some communication about this last week and I proposed
>>>> this to him, but I haven't heard back since then, and wasn't sure if
>>>> he should give the go-ahead to move forward.
>>>
>>> Hi,
>>>
>>> Sorry about that. Yes, I say we confirm those dates and everyone
>>> put them in their diary RIGHT NOW!  So that is travel on the
>>> 15th, Meetings on the 16/17/18 with potentially travel home on
>>> evening of the 18th. At least that is what I'm going to try to
>>> find in our flight booking system if possible.  (One can of
>>> course stay longer, but TEI-C won't cover your accommodation.)
>>>
>>> -James
>>>
>>
>
>


-- 
Dr James Cummings, InfoDev,
Computing Services, University of Oxford

From gabriel.bodard at kcl.ac.uk  Tue Jan 24 07:02:51 2012
From: gabriel.bodard at kcl.ac.uk (Gabriel Bodard)
Date: Tue, 24 Jan 2012 12:02:51 +0000
Subject: [tei-council] Ann Arbor spring meeting
In-Reply-To: <4F1E92B4.2060809@oucs.ox.ac.uk>
References: <CAA2irt+8ZcDx6rBYOoZ-f9FrKYP1B+O3pqsxr82JT+hpaA2MXQ@mail.gmail.com>
	<8D7B6E12-1923-4DFB-B676-DF361DE81C40@oucs.ox.ac.uk>
	<CAA2irtKZ0k_hv89WotTCZ0VuQ=B6pUwDb4FemkLuyRWjMF9-vw@mail.gmail.com>
	<4F199BAC.6090007@oucs.ox.ac.uk>	<4F19B442.8030301@uvic.ca>
	<4F19B88A.8090802@oucs.ox.ac.uk> <4F1E92B4.2060809@oucs.ox.ac.uk>
Message-ID: <4F1E9DEB.2000601@kcl.ac.uk>

That's pretty common, and what I'd expect. Shall we try to come up with 
something "useful" to do on the Sunday to make it worth the TEI's while? 
(I'd like to pin Sebastian down to talk about EpiDoc guidelines 
generation stuff, for starters... :-) )

Or will we just be catching up on sleep / jet-lag and thus making 
ourself more efficient and lively for the three days of the meeting?

G

On 2012-01-24 11:15, James Cummings wrote:
>
> I've been looking at booking a flight from LHR to DTW for this
> meeting and the cheapest I could find for Sunday - Wednesday was
> 1045 pounds.  However, if I included the Saturday, then the
> cheapest was around 538 pounds. I find the bizarre notion that
> one must include a Saturday (or be penalised by doubling the
> price) a strange one. The only 'overnight' flights I could find
> involved 15 hour layovers.
>
> Gaby, Piotr, Sebastian, Lou:  Does it make sense then for those
> of us crossing the Atlantic to fly into DTW on Saturday?
> Charging the TEI for an extra day of hotel seems offset by the
> difference in flight cost.
>
> Let me know what you think,
>
> -James
>
> On 20/01/12 18:55, James Cummings wrote:
>> On 20/01/12 18:36, Martin Holmes wrote:
>>> Re leaving on the 18th: how do we stand on staying the night of the 18th
>>> and travelling back the next day? I think I'd have to leave pretty early
>>> to get back to Victoria without overnighting somewhere, so the 18th
>>> wouldn't be much of a work day.
>>
>> We probably have some degree flexibility on this, especially if everyone
>> doesn't need it. The draft budget was done assuming 3 nights hotel at
>> each meeting. But we might be able to get discounts which could offset
>> some people staying for a fourth night.
>>
>> (of course, in interest of saving more of the budget for other work, I
>> remind council members if they know of any institutional or other
>> funding for such things as travel to start applying for them now. ;-) )
>>
>> -James
>>
>>>
>>> Cheers,
>>> Martin
>>>
>>> On 12-01-20 08:51 AM, James Cummings wrote:
>>>> On 20/01/12 16:32, Rebecca Welzenbach wrote:
>>>>> Hi all,
>>>>>
>>>>> I recommend that we confirm April 16-18 as the dates for our meeting.
>>>>> James and I had some communication about this last week and I proposed
>>>>> this to him, but I haven't heard back since then, and wasn't sure if
>>>>> he should give the go-ahead to move forward.
>>>>
>>>> Hi,
>>>>
>>>> Sorry about that. Yes, I say we confirm those dates and everyone
>>>> put them in their diary RIGHT NOW!  So that is travel on the
>>>> 15th, Meetings on the 16/17/18 with potentially travel home on
>>>> evening of the 18th. At least that is what I'm going to try to
>>>> find in our flight booking system if possible.  (One can of
>>>> course stay longer, but TEI-C won't cover your accommodation.)
>>>>
>>>> -James
>>>>
>>>
>>
>>
>
>

-- 
Dr Gabriel BODARD
(Research Associate in Digital Epigraphy)

Department of Digital Humanities
King's College London
26-29 Drury Lane
London WC2B 5RL

Email: gabriel.bodard at kcl.ac.uk
Tel: +44 (0)20 7848 1388
Fax: +44 (0)20 7848 2980

http://www.digitalclassicist.org/
http://www.currentepigraphy.org/

From sebastian.rahtz at oucs.ox.ac.uk  Tue Jan 24 07:14:44 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Tue, 24 Jan 2012 12:14:44 +0000
Subject: [tei-council] Ann Arbor spring meeting
In-Reply-To: <4F1E9DEB.2000601@kcl.ac.uk>
References: <CAA2irt+8ZcDx6rBYOoZ-f9FrKYP1B+O3pqsxr82JT+hpaA2MXQ@mail.gmail.com>
	<8D7B6E12-1923-4DFB-B676-DF361DE81C40@oucs.ox.ac.uk>
	<CAA2irtKZ0k_hv89WotTCZ0VuQ=B6pUwDb4FemkLuyRWjMF9-vw@mail.gmail.com>
	<4F199BAC.6090007@oucs.ox.ac.uk>	<4F19B442.8030301@uvic.ca>
	<4F19B88A.8090802@oucs.ox.ac.uk> <4F1E92B4.2060809@oucs.ox.ac.uk>
	<4F1E9DEB.2000601@kcl.ac.uk>
Message-ID: <3128560C-412E-48E2-B5F7-10C4423DD364@oucs.ox.ac.uk>

if we could find meeting rooms, I'd be all in favour of starting the meeting after lunch on the Sunday...
--
Stormageddon Rahtz      
Head of Information and Support Group
Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431

S?lo le pido a Dios
que el futuro no me sea indiferente


From bansp at o2.pl  Tue Jan 24 07:47:36 2012
From: bansp at o2.pl (=?ISO-8859-2?Q?Piotr_Ba=F1ski?=)
Date: Tue, 24 Jan 2012 13:47:36 +0100
Subject: [tei-council] Ann Arbor spring meeting
In-Reply-To: <4F1E92B4.2060809@oucs.ox.ac.uk>
References: <CAA2irt+8ZcDx6rBYOoZ-f9FrKYP1B+O3pqsxr82JT+hpaA2MXQ@mail.gmail.com>	<8D7B6E12-1923-4DFB-B676-DF361DE81C40@oucs.ox.ac.uk>	<CAA2irtKZ0k_hv89WotTCZ0VuQ=B6pUwDb4FemkLuyRWjMF9-vw@mail.gmail.com>	<4F199BAC.6090007@oucs.ox.ac.uk>	<4F19B442.8030301@uvic.ca>
	<4F19B88A.8090802@oucs.ox.ac.uk> <4F1E92B4.2060809@oucs.ox.ac.uk>
Message-ID: <4F1EA868.1060101@o2.pl>

Hi James,

Most probably I'll be in Detroit on Sunday afternoon only, transferring
locally -- I planned to arrive some three days earlier to adjust and to
satisfy the Saturday condition. I wasn't planning on getting these extra
nights reimbursed, of course.

And, to be sure, I'm not showing up without my tracker tickets handled,
I'm embarrassed enough with my delay as it is.

Best,

  Piotr

On 24/01/12 12:15, James Cummings wrote:
> 
> I've been looking at booking a flight from LHR to DTW for this 
> meeting and the cheapest I could find for Sunday - Wednesday was 
> 1045 pounds.  However, if I included the Saturday, then the 
> cheapest was around 538 pounds. I find the bizarre notion that 
> one must include a Saturday (or be penalised by doubling the 
> price) a strange one. The only 'overnight' flights I could find 
> involved 15 hour layovers.
> 
> Gaby, Piotr, Sebastian, Lou:  Does it make sense then for those 
> of us crossing the Atlantic to fly into DTW on Saturday? 
> Charging the TEI for an extra day of hotel seems offset by the 
> difference in flight cost.
> 
> Let me know what you think,
> 
> -James
> 
> On 20/01/12 18:55, James Cummings wrote:
>> On 20/01/12 18:36, Martin Holmes wrote:
>>> Re leaving on the 18th: how do we stand on staying the night of the 18th
>>> and travelling back the next day? I think I'd have to leave pretty early
>>> to get back to Victoria without overnighting somewhere, so the 18th
>>> wouldn't be much of a work day.
>>
>> We probably have some degree flexibility on this, especially if everyone
>> doesn't need it. The draft budget was done assuming 3 nights hotel at
>> each meeting. But we might be able to get discounts which could offset
>> some people staying for a fourth night.
>>
>> (of course, in interest of saving more of the budget for other work, I
>> remind council members if they know of any institutional or other
>> funding for such things as travel to start applying for them now. ;-) )
>>
>> -James
>>
>>>
>>> Cheers,
>>> Martin
>>>
>>> On 12-01-20 08:51 AM, James Cummings wrote:
>>>> On 20/01/12 16:32, Rebecca Welzenbach wrote:
>>>>> Hi all,
>>>>>
>>>>> I recommend that we confirm April 16-18 as the dates for our meeting.
>>>>> James and I had some communication about this last week and I proposed
>>>>> this to him, but I haven't heard back since then, and wasn't sure if
>>>>> he should give the go-ahead to move forward.
>>>>
>>>> Hi,
>>>>
>>>> Sorry about that. Yes, I say we confirm those dates and everyone
>>>> put them in their diary RIGHT NOW!  So that is travel on the
>>>> 15th, Meetings on the 16/17/18 with potentially travel home on
>>>> evening of the 18th. At least that is what I'm going to try to
>>>> find in our flight booking system if possible.  (One can of
>>>> course stay longer, but TEI-C won't cover your accommodation.)
>>>>
>>>> -James
>>>>
>>>
>>
>>
> 
> 


From kevin.s.hawkins at ultraslavonic.info  Tue Jan 24 09:42:07 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Tue, 24 Jan 2012 09:42:07 -0500
Subject: [tei-council] Ann Arbor spring meeting
In-Reply-To: <4F1E92B4.2060809@oucs.ox.ac.uk>
References: <CAA2irt+8ZcDx6rBYOoZ-f9FrKYP1B+O3pqsxr82JT+hpaA2MXQ@mail.gmail.com>	<8D7B6E12-1923-4DFB-B676-DF361DE81C40@oucs.ox.ac.uk>	<CAA2irtKZ0k_hv89WotTCZ0VuQ=B6pUwDb4FemkLuyRWjMF9-vw@mail.gmail.com>	<4F199BAC.6090007@oucs.ox.ac.uk>	<4F19B442.8030301@uvic.ca>
	<4F19B88A.8090802@oucs.ox.ac.uk> <4F1E92B4.2060809@oucs.ox.ac.uk>
Message-ID: <4F1EC33F.3070901@ultraslavonic.info>

Flights within the US are commonly priced like this.  It's an old 
arrangement between the airlines and hotels to encourage you to stay 
through the weekend wherever you're going.  I don't think it applies to 
flights to and from the US, but perhaps you have a connection in the US 
causing this.

So the situation might apply to those traveling from within the US as 
well.  I'm sure the TEI's treasurer would agree that it saves the 
Consortium money for James (and anyone else in a similar situation) to 
arrive on Saturday and stay in a hotel the extra night.  That is, you 
end up saving money, even with the hotel and per-diem.

In the future, we might consider planning meetings to begin on a Sunday 
or end on a Saturday because of the likelihood of saving money.  It 
shortens our weekends, of course, but it also is less likely to disrupt 
someone's teaching schedule (as has been the problem for some Council 
members in the past).

--K.

On 1/24/2012 6:15 AM, James Cummings wrote:
>
> I've been looking at booking a flight from LHR to DTW for this
> meeting and the cheapest I could find for Sunday - Wednesday was
> 1045 pounds.  However, if I included the Saturday, then the
> cheapest was around 538 pounds. I find the bizarre notion that
> one must include a Saturday (or be penalised by doubling the
> price) a strange one. The only 'overnight' flights I could find
> involved 15 hour layovers.
>
> Gaby, Piotr, Sebastian, Lou:  Does it make sense then for those
> of us crossing the Atlantic to fly into DTW on Saturday?
> Charging the TEI for an extra day of hotel seems offset by the
> difference in flight cost.
>
> Let me know what you think,
>
> -James
>
> On 20/01/12 18:55, James Cummings wrote:
>> On 20/01/12 18:36, Martin Holmes wrote:
>>> Re leaving on the 18th: how do we stand on staying the night of the 18th
>>> and travelling back the next day? I think I'd have to leave pretty early
>>> to get back to Victoria without overnighting somewhere, so the 18th
>>> wouldn't be much of a work day.
>>
>> We probably have some degree flexibility on this, especially if everyone
>> doesn't need it. The draft budget was done assuming 3 nights hotel at
>> each meeting. But we might be able to get discounts which could offset
>> some people staying for a fourth night.
>>
>> (of course, in interest of saving more of the budget for other work, I
>> remind council members if they know of any institutional or other
>> funding for such things as travel to start applying for them now. ;-) )
>>
>> -James
>>
>>>
>>> Cheers,
>>> Martin
>>>
>>> On 12-01-20 08:51 AM, James Cummings wrote:
>>>> On 20/01/12 16:32, Rebecca Welzenbach wrote:
>>>>> Hi all,
>>>>>
>>>>> I recommend that we confirm April 16-18 as the dates for our meeting.
>>>>> James and I had some communication about this last week and I proposed
>>>>> this to him, but I haven't heard back since then, and wasn't sure if
>>>>> he should give the go-ahead to move forward.
>>>>
>>>> Hi,
>>>>
>>>> Sorry about that. Yes, I say we confirm those dates and everyone
>>>> put them in their diary RIGHT NOW!  So that is travel on the
>>>> 15th, Meetings on the 16/17/18 with potentially travel home on
>>>> evening of the 18th. At least that is what I'm going to try to
>>>> find in our flight booking system if possible.  (One can of
>>>> course stay longer, but TEI-C won't cover your accommodation.)
>>>>
>>>> -James
>>>>
>>>
>>
>>
>
>

From James.Cummings at oucs.ox.ac.uk  Tue Jan 24 10:04:59 2012
From: James.Cummings at oucs.ox.ac.uk (James Cummings)
Date: Tue, 24 Jan 2012 15:04:59 +0000
Subject: [tei-council] Ann Arbor spring meeting
In-Reply-To: <4F1EC33F.3070901@ultraslavonic.info>
References: <CAA2irt+8ZcDx6rBYOoZ-f9FrKYP1B+O3pqsxr82JT+hpaA2MXQ@mail.gmail.com>	<8D7B6E12-1923-4DFB-B676-DF361DE81C40@oucs.ox.ac.uk>	<CAA2irtKZ0k_hv89WotTCZ0VuQ=B6pUwDb4FemkLuyRWjMF9-vw@mail.gmail.com>	<4F199BAC.6090007@oucs.ox.ac.uk>	<4F19B442.8030301@uvic.ca>	<4F19B88A.8090802@oucs.ox.ac.uk>
	<4F1E92B4.2060809@oucs.ox.ac.uk>
	<4F1EC33F.3070901@ultraslavonic.info>
Message-ID: <4F1EC89B.3000006@oucs.ox.ac.uk>

On 24/01/12 14:42, Kevin Hawkins wrote:
> Flights within the US are commonly priced like this.  It's an old
> arrangement between the airlines and hotels to encourage you to stay
> through the weekend wherever you're going.  I don't think it applies to
> flights to and from the US, but perhaps you have a connection in the US
> causing this.

Nope, direct flight from Heathrow. This is always the case when 
travelling to the US if you don't include a Saturday.  It has 
affected me a number of times (and year I always forget it until 
it does). So I think this arrangement is implemented across the 
board.

> So the situation might apply to those traveling from within the US as
> well.  I'm sure the TEI's treasurer would agree that it saves the
> Consortium money for James (and anyone else in a similar situation) to
> arrive on Saturday and stay in a hotel the extra night.  That is, you
> end up saving money, even with the hotel and per-diem.

I agree, and would encourage people to book tickets accordingly.

> In the future, we might consider planning meetings to begin on a Sunday
> or end on a Saturday because of the likelihood of saving money.  It
> shortens our weekends, of course, but it also is less likely to disrupt
> someone's teaching schedule (as has been the problem for some Council
> members in the past).

That is a good idea, but depends on local hosting arrangements. 
I know, for example, that it is quite difficult for us to have 
people in the building on a Sunday here at OUCS. (Though we could 
find other meeting space where that wasn't the case.)  I'll 
consider it when planning the Oxford meeting.

Becky: Do you know if we might be able to get the same meeting 
space on the Sunday as well?

If we can, I propose that we deal with the slight vague other 
useful TEI stuff that Gaby suggests. (I.e. there would be no 
requirement for others to be there, but we'd set aside the time 
to work on decided TEI tickets, TEI infrastructure, EpiDoc etc.)

-James

-- 
Dr James Cummings, InfoDev,
Computing Services, University of Oxford

From sebastian.rahtz at oucs.ox.ac.uk  Tue Jan 24 10:07:31 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Tue, 24 Jan 2012 15:07:31 +0000
Subject: [tei-council] Ann Arbor spring meeting
In-Reply-To: <4F1EC89B.3000006@oucs.ox.ac.uk>
References: <CAA2irt+8ZcDx6rBYOoZ-f9FrKYP1B+O3pqsxr82JT+hpaA2MXQ@mail.gmail.com>
	<8D7B6E12-1923-4DFB-B676-DF361DE81C40@oucs.ox.ac.uk>
	<CAA2irtKZ0k_hv89WotTCZ0VuQ=B6pUwDb4FemkLuyRWjMF9-vw@mail.gmail.com>
	<4F199BAC.6090007@oucs.ox.ac.uk>	<4F19B442.8030301@uvic.ca>
	<4F19B88A.8090802@oucs.ox.ac.uk>	<4F1E92B4.2060809@oucs.ox.ac.uk>
	<4F1EC33F.3070901@ultraslavonic.info> <4F1EC89B.3000006@oucs.ox.ac.uk>
Message-ID: <3f4cd7cd-2539-4dd2-af78-557960b2074a@exht04.ad.oak.ox.ac.uk>


On 24 Jan 2012, at 15:04, James Cummings wrote:
> 
> Becky: Do you know if we might be able to get the same meeting 
> space on the Sunday as well?
> 
> If we can, I propose that we deal with the slight vague other 
> useful TEI stuff that Gaby suggests. (I.e. there would be no 
> requirement for others to be there, but we'd set aside the time 
> to work on decided TEI tickets, TEI infrastructure, EpiDoc etc.)



I strongly suspect many of us will arrive with some "baggage" in terms
of things we meant to get done before the meeting.
an afternoons optional communal hacking would likely
be very productive.

if we get bored we can write Roma2
--
Stormageddon Rahtz      
Head of Information and Support Group
Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431

S?lo le pido a Dios
que el futuro no me sea indiferente


From bansp at o2.pl  Tue Jan 24 11:46:47 2012
From: bansp at o2.pl (=?ISO-8859-2?Q?Piotr_Ba=F1ski?=)
Date: Tue, 24 Jan 2012 17:46:47 +0100
Subject: [tei-council] Ann Arbor spring meeting
In-Reply-To: <4F1EC89B.3000006@oucs.ox.ac.uk>
References: <CAA2irt+8ZcDx6rBYOoZ-f9FrKYP1B+O3pqsxr82JT+hpaA2MXQ@mail.gmail.com>	<8D7B6E12-1923-4DFB-B676-DF361DE81C40@oucs.ox.ac.uk>	<CAA2irtKZ0k_hv89WotTCZ0VuQ=B6pUwDb4FemkLuyRWjMF9-vw@mail.gmail.com>	<4F199BAC.6090007@oucs.ox.ac.uk>	<4F19B442.8030301@uvic.ca>	<4F19B88A.8090802@oucs.ox.ac.uk>	<4F1E92B4.2060809@oucs.ox.ac.uk>	<4F1EC33F.3070901@ultraslavonic.info>
	<4F1EC89B.3000006@oucs.ox.ac.uk>
Message-ID: <4F1EE077.4020202@o2.pl>

I'd happily take part. Haven't bought my ticket yet because tomorrow is
a discount day for the Polish airlines, so if I manage to see a suitable
connection, I'll try to be there around noon instead of later in the
day. The more so if Becky manages to confirm the available space (but I
realise that the notice is rather short).

Best,

  P.

On 24/01/12 16:04, James Cummings wrote:
[...]
> Becky: Do you know if we might be able to get the same meeting 
> space on the Sunday as well?
> 
> If we can, I propose that we deal with the slight vague other 
> useful TEI stuff that Gaby suggests. (I.e. there would be no 
> requirement for others to be there, but we'd set aside the time 
> to work on decided TEI tickets, TEI infrastructure, EpiDoc etc.)
> 
> -James
> 


From kevin.s.hawkins at ultraslavonic.info  Tue Jan 24 11:50:46 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Tue, 24 Jan 2012 11:50:46 -0500
Subject: [tei-council] Ann Arbor spring meeting
In-Reply-To: <4F1EE077.4020202@o2.pl>
References: <CAA2irt+8ZcDx6rBYOoZ-f9FrKYP1B+O3pqsxr82JT+hpaA2MXQ@mail.gmail.com>	<8D7B6E12-1923-4DFB-B676-DF361DE81C40@oucs.ox.ac.uk>	<CAA2irtKZ0k_hv89WotTCZ0VuQ=B6pUwDb4FemkLuyRWjMF9-vw@mail.gmail.com>	<4F199BAC.6090007@oucs.ox.ac.uk>	<4F19B442.8030301@uvic.ca>	<4F19B88A.8090802@oucs.ox.ac.uk>	<4F1E92B4.2060809@oucs.ox.ac.uk>	<4F1EC33F.3070901@ultraslavonic.info>	<4F1EC89B.3000006@oucs.ox.ac.uk>
	<4F1EE077.4020202@o2.pl>
Message-ID: <4F1EE166.1030808@ultraslavonic.info>

I can see the availability of the room Becky reserved for 
Monday-Wednesday and see that it's available on Sunday as well.  Nobody 
ever uses that room on the weekend, and the building opens on Sundays at 
10 a.m., so I'm sure it will be available all day for us to use.

On 1/24/2012 11:46 AM, Piotr Ba?ski wrote:
> I'd happily take part. Haven't bought my ticket yet because tomorrow is
> a discount day for the Polish airlines, so if I manage to see a suitable
> connection, I'll try to be there around noon instead of later in the
> day. The more so if Becky manages to confirm the available space (but I
> realise that the notice is rather short).
>
> Best,
>
>    P.
>
> On 24/01/12 16:04, James Cummings wrote:
> [...]
>> Becky: Do you know if we might be able to get the same meeting
>> space on the Sunday as well?
>>
>> If we can, I propose that we deal with the slight vague other
>> useful TEI stuff that Gaby suggests. (I.e. there would be no
>> requirement for others to be there, but we'd set aside the time
>> to work on decided TEI tickets, TEI infrastructure, EpiDoc etc.)
>>
>> -James
>>
>

From sebastian.rahtz at oucs.ox.ac.uk  Tue Jan 24 11:51:06 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Tue, 24 Jan 2012 16:51:06 +0000
Subject: [tei-council] Ann Arbor spring meeting
In-Reply-To: <4F1EE077.4020202@o2.pl>
References: <CAA2irt+8ZcDx6rBYOoZ-f9FrKYP1B+O3pqsxr82JT+hpaA2MXQ@mail.gmail.com>
	<8D7B6E12-1923-4DFB-B676-DF361DE81C40@oucs.ox.ac.uk>
	<CAA2irtKZ0k_hv89WotTCZ0VuQ=B6pUwDb4FemkLuyRWjMF9-vw@mail.gmail.com>
	<4F199BAC.6090007@oucs.ox.ac.uk>	<4F19B442.8030301@uvic.ca>
	<4F19B88A.8090802@oucs.ox.ac.uk>	<4F1E92B4.2060809@oucs.ox.ac.uk>
	<4F1EC33F.3070901@ultraslavonic.info>	<4F1EC89B.3000006@oucs.ox.ac.uk>
	<4F1EE077.4020202@o2.pl>
Message-ID: <5018475B-D8DD-42E9-B548-84F4E1849BB1@oucs.ox.ac.uk>


On 24 Jan 2012, at 16:46, Piotr Ba?ski wrote:

>  The more so if Becky manages to confirm the available space (but I
> realise that the notice is rather short).



the worst we can do is all occupy someone's bedroom?..
--
Stormageddon Rahtz      
Head of Information and Support Group
Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431

S?lo le pido a Dios
que el futuro no me sea indiferente


From mholmes at uvic.ca  Tue Jan 24 13:32:39 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Tue, 24 Jan 2012 10:32:39 -0800
Subject: [tei-council] Ann Arbor spring meeting
In-Reply-To: <5018475B-D8DD-42E9-B548-84F4E1849BB1@oucs.ox.ac.uk>
References: <CAA2irt+8ZcDx6rBYOoZ-f9FrKYP1B+O3pqsxr82JT+hpaA2MXQ@mail.gmail.com>	<8D7B6E12-1923-4DFB-B676-DF361DE81C40@oucs.ox.ac.uk>	<CAA2irtKZ0k_hv89WotTCZ0VuQ=B6pUwDb4FemkLuyRWjMF9-vw@mail.gmail.com>	<4F199BAC.6090007@oucs.ox.ac.uk>	<4F19B442.8030301@uvic.ca>	<4F19B88A.8090802@oucs.ox.ac.uk>	<4F1E92B4.2060809@oucs.ox.ac.uk>	<4F1EC33F.3070901@ultraslavonic.info>	<4F1EC89B.3000006@oucs.ox.ac.uk>	<4F1EE077.4020202@o2.pl>
	<5018475B-D8DD-42E9-B548-84F4E1849BB1@oucs.ox.ac.uk>
Message-ID: <4F1EF947.1030407@uvic.ca>

I'm checking flight costs for myself to see if coming Saturday would be 
cheaper too.

Is there any recommendation on where to stay?

Cheers,
Martin

On 12-01-24 08:51 AM, Sebastian Rahtz wrote:
>
> On 24 Jan 2012, at 16:46, Piotr Ba?ski wrote:
>
>>   The more so if Becky manages to confirm the available space (but I
>> realise that the notice is rather short).
>
>
>
> the worst we can do is all occupy someone's bedroom?..
> --
> Stormageddon Rahtz
> Head of Information and Support Group
> Oxford University Computing Services
> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>
> S?lo le pido a Dios
> que el futuro no me sea indiferente
>

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From james.cummings at oucs.ox.ac.uk  Tue Jan 24 14:01:25 2012
From: james.cummings at oucs.ox.ac.uk (James Cummings)
Date: Tue, 24 Jan 2012 19:01:25 +0000
Subject: [tei-council] Ann Arbor spring meeting
Message-ID: <o4f8j7egl1qp4ugx9vpvsh8l.1327431683813@email.android.com>


Becky is looking into block booking. Let's leave accommodation until she reports back.
JamesC
--
James Cummings, InfoDev, OUCS, University of Oxford (via phone)

Martin Holmes <mholmes at uvic.ca> wrote:


I'm checking flight costs for myself to see if coming Saturday would be
cheaper too.

Is there any recommendation on where to stay?

Cheers,
Martin

On 12-01-24 08:51 AM, Sebastian Rahtz wrote:
>
> On 24 Jan 2012, at 16:46, Piotr Ba?ski wrote:
>
>>   The more so if Becky manages to confirm the available space (but I
>> realise that the notice is rather short).
>
>
>
> the worst we can do is all occupy someone's bedroom?..
> --
> Stormageddon Rahtz
> Head of Information and Support Group
> Oxford University Computing Services
> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>
> S?lo le pido a Dios
> que el futuro no me sea indiferente
>

--
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)
--
tei-council mailing list
tei-council at lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

PLEASE NOTE: postings to this list are publicly archived

From mholmes at uvic.ca  Tue Jan 24 15:51:47 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Tue, 24 Jan 2012 12:51:47 -0800
Subject: [tei-council] Ann Arbor spring meeting
In-Reply-To: <o4f8j7egl1qp4ugx9vpvsh8l.1327431683813@email.android.com>
References: <o4f8j7egl1qp4ugx9vpvsh8l.1327431683813@email.android.com>
Message-ID: <4F1F19E3.1000401@uvic.ca>

Travelling on Saturday makes virtually no difference to my flight costs. 
But if it turns out that most of us are coming in on Saturday, and work 
will be done on Sunday, should I come on the Saturday too?

Cheers,
Martin

On 12-01-24 11:01 AM, James Cummings wrote:
>
> Becky is looking into block booking. Let's leave accommodation until she reports back.
> JamesC
> --
> James Cummings, InfoDev, OUCS, University of Oxford (via phone)
>
> Martin Holmes<mholmes at uvic.ca>  wrote:
>
>
> I'm checking flight costs for myself to see if coming Saturday would be
> cheaper too.
>
> Is there any recommendation on where to stay?
>
> Cheers,
> Martin
>
> On 12-01-24 08:51 AM, Sebastian Rahtz wrote:
>>
>> On 24 Jan 2012, at 16:46, Piotr Ba?ski wrote:
>>
>>>    The more so if Becky manages to confirm the available space (but I
>>> realise that the notice is rather short).
>>
>>
>>
>> the worst we can do is all occupy someone's bedroom?..
>> --
>> Stormageddon Rahtz
>> Head of Information and Support Group
>> Oxford University Computing Services
>> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>>
>> S?lo le pido a Dios
>> que el futuro no me sea indiferente
>>
>
> --
> Martin Holmes
> University of Victoria Humanities Computing and Media Centre
> (mholmes at uvic.ca)
> --
> tei-council mailing list
> tei-council at lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>
> PLEASE NOTE: postings to this list are publicly archived

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From mholmes at uvic.ca  Tue Jan 24 16:12:36 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Tue, 24 Jan 2012 13:12:36 -0800
Subject: [tei-council] Ann Arbor spring meeting
In-Reply-To: <4F1F19E3.1000401@uvic.ca>
References: <o4f8j7egl1qp4ugx9vpvsh8l.1327431683813@email.android.com>
	<4F1F19E3.1000401@uvic.ca>
Message-ID: <4F1F1EC4.3010301@uvic.ca>

I was just checking out the wifi access at UMich:

"Wireless access
Council members not affiliated with the University of Michigan can use 
MGuest. If the limited access is insufficient, the local organizers can 
ask Desktop Support Services to provide temporary uniqnames."

The MGuest services is quite restrictive:

[quote]
MGuest is limited to web (http), secure web (https) secure mail services 
(IMAPS, POPS, SMTPS) and VPN services:

     HTTP 80
     HTTPS 443 (TLS/SSL)
     POP3s 995 (TLS/SSL)
     IMAPs 993 (TLS/SSL)
     SMTPs 465 (TLS/SSL)
     Secure Shell (SSH) port 22

VPN access via the following ports is allowed:

     Protocol 47, 50 and 51
     port 500
     port 1701
     UDP port 4500
     UDP port 10000

MGuest is rate limited to 1Mbps down and 384kbps upload speeds.

MGuest is treated like a non-UM network; some U-M resource such as 
library journals cannot be accessed.
[/quote]

That would presumably make my Jenkins server inaccessible, because it 
runs on port 8080:

<http://teijenkins.hcmc.uvic.ca:8080/>

And we have other projects running on other ports not on the MGuest 
list. If it's possible to get temporary logins to the main network, 
MWireless, I'd be happier. I'm assuming that UMich doesn't support 
eduroam? Something called "Internet2, Ann Arbor" does, but I don't see 
any mention on the main university site.

Cheers,
Martin

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From lou.burnard at retired.ox.ac.uk  Tue Jan 24 16:47:38 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Tue, 24 Jan 2012 21:47:38 +0000
Subject: [tei-council] Ann Arbor spring meeting
In-Reply-To: <4F1F19E3.1000401@uvic.ca>
References: <o4f8j7egl1qp4ugx9vpvsh8l.1327431683813@email.android.com>
	<4F1F19E3.1000401@uvic.ca>
Message-ID: <4F1F26FA.8030203@retired.ox.ac.uk>

also, if we're changing the sunday into a work day, can we go home early 
on the wednesday?


On 24/01/12 20:51, Martin Holmes wrote:
> Travelling on Saturday makes virtually no difference to my flight costs.
> But if it turns out that most of us are coming in on Saturday, and work
> will be done on Sunday, should I come on the Saturday too?
>
> Cheers,
> Martin
>
> On 12-01-24 11:01 AM, James Cummings wrote:
>>
>> Becky is looking into block booking. Let's leave accommodation until she reports back.
>> JamesC
>> --
>> James Cummings, InfoDev, OUCS, University of Oxford (via phone)
>>
>> Martin Holmes<mholmes at uvic.ca>   wrote:
>>
>>
>> I'm checking flight costs for myself to see if coming Saturday would be
>> cheaper too.
>>
>> Is there any recommendation on where to stay?
>>
>> Cheers,
>> Martin
>>
>> On 12-01-24 08:51 AM, Sebastian Rahtz wrote:
>>>
>>> On 24 Jan 2012, at 16:46, Piotr Ba?ski wrote:
>>>
>>>>     The more so if Becky manages to confirm the available space (but I
>>>> realise that the notice is rather short).
>>>
>>>
>>>
>>> the worst we can do is all occupy someone's bedroom?..
>>> --
>>> Stormageddon Rahtz
>>> Head of Information and Support Group
>>> Oxford University Computing Services
>>> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>>>
>>> S?lo le pido a Dios
>>> que el futuro no me sea indiferente
>>>
>>
>> --
>> Martin Holmes
>> University of Victoria Humanities Computing and Media Centre
>> (mholmes at uvic.ca)
>> --
>> tei-council mailing list
>> tei-council at lists.village.Virginia.EDU
>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>>
>> PLEASE NOTE: postings to this list are publicly archived
>


From mholmes at uvic.ca  Tue Jan 24 17:27:21 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Tue, 24 Jan 2012 14:27:21 -0800
Subject: [tei-council] Ann Arbor spring meeting
In-Reply-To: <4F1F26FA.8030203@retired.ox.ac.uk>
References: <o4f8j7egl1qp4ugx9vpvsh8l.1327431683813@email.android.com>	<4F1F19E3.1000401@uvic.ca>
	<4F1F26FA.8030203@retired.ox.ac.uk>
Message-ID: <4F1F3049.9000804@uvic.ca>

That would work for me. I'm guessing the people who actually live in Ann 
Arbor might get some push-back from family, though, if we turn Sunday 
into a work day.

Cheers,
Martin

On 12-01-24 01:47 PM, Lou Burnard wrote:
> also, if we're changing the sunday into a work day, can we go home early
> on the wednesday?
>
>
> On 24/01/12 20:51, Martin Holmes wrote:
>> Travelling on Saturday makes virtually no difference to my flight costs.
>> But if it turns out that most of us are coming in on Saturday, and work
>> will be done on Sunday, should I come on the Saturday too?
>>
>> Cheers,
>> Martin
>>
>> On 12-01-24 11:01 AM, James Cummings wrote:
>>>
>>> Becky is looking into block booking. Let's leave accommodation until she reports back.
>>> JamesC
>>> --
>>> James Cummings, InfoDev, OUCS, University of Oxford (via phone)
>>>
>>> Martin Holmes<mholmes at uvic.ca>    wrote:
>>>
>>>
>>> I'm checking flight costs for myself to see if coming Saturday would be
>>> cheaper too.
>>>
>>> Is there any recommendation on where to stay?
>>>
>>> Cheers,
>>> Martin
>>>
>>> On 12-01-24 08:51 AM, Sebastian Rahtz wrote:
>>>>
>>>> On 24 Jan 2012, at 16:46, Piotr Ba?ski wrote:
>>>>
>>>>>      The more so if Becky manages to confirm the available space (but I
>>>>> realise that the notice is rather short).
>>>>
>>>>
>>>>
>>>> the worst we can do is all occupy someone's bedroom?..
>>>> --
>>>> Stormageddon Rahtz
>>>> Head of Information and Support Group
>>>> Oxford University Computing Services
>>>> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>>>>
>>>> S?lo le pido a Dios
>>>> que el futuro no me sea indiferente
>>>>
>>>
>>> --
>>> Martin Holmes
>>> University of Victoria Humanities Computing and Media Centre
>>> (mholmes at uvic.ca)
>>> --
>>> tei-council mailing list
>>> tei-council at lists.village.Virginia.EDU
>>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>>>
>>> PLEASE NOTE: postings to this list are publicly archived
>>
>

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From kevin.s.hawkins at ultraslavonic.info  Tue Jan 24 18:51:11 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Tue, 24 Jan 2012 18:51:11 -0500
Subject: [tei-council] Ann Arbor spring meeting
In-Reply-To: <4F1F1EC4.3010301@uvic.ca>
References: <o4f8j7egl1qp4ugx9vpvsh8l.1327431683813@email.android.com>	<4F1F19E3.1000401@uvic.ca>
	<4F1F1EC4.3010301@uvic.ca>
Message-ID: <4F1F43EF.8090904@ultraslavonic.info>

Martin, thanks for investigating what MGuest offers and what we need. 
You're right that it's insufficient for our needs, so we'll need to get 
temporary accounts for everyone.  This is similar to what we did for the 
2009 conference and it shouldn't be a problem.

(U-M is testing eduRoam, but it's not functional yet.)

On 1/24/2012 4:12 PM, Martin Holmes wrote:
> I was just checking out the wifi access at UMich:
>
> "Wireless access
> Council members not affiliated with the University of Michigan can use
> MGuest. If the limited access is insufficient, the local organizers can
> ask Desktop Support Services to provide temporary uniqnames."
>
> The MGuest services is quite restrictive:
>
> [quote]
> MGuest is limited to web (http), secure web (https) secure mail services
> (IMAPS, POPS, SMTPS) and VPN services:
>
>       HTTP 80
>       HTTPS 443 (TLS/SSL)
>       POP3s 995 (TLS/SSL)
>       IMAPs 993 (TLS/SSL)
>       SMTPs 465 (TLS/SSL)
>       Secure Shell (SSH) port 22
>
> VPN access via the following ports is allowed:
>
>       Protocol 47, 50 and 51
>       port 500
>       port 1701
>       UDP port 4500
>       UDP port 10000
>
> MGuest is rate limited to 1Mbps down and 384kbps upload speeds.
>
> MGuest is treated like a non-UM network; some U-M resource such as
> library journals cannot be accessed.
> [/quote]
>
> That would presumably make my Jenkins server inaccessible, because it
> runs on port 8080:
>
> <http://teijenkins.hcmc.uvic.ca:8080/>
>
> And we have other projects running on other ports not on the MGuest
> list. If it's possible to get temporary logins to the main network,
> MWireless, I'd be happier. I'm assuming that UMich doesn't support
> eduroam? Something called "Internet2, Ann Arbor" does, but I don't see
> any mention on the main university site.
>
> Cheers,
> Martin
>

From rwelzenbach at gmail.com  Wed Jan 25 09:01:49 2012
From: rwelzenbach at gmail.com (Rebecca Welzenbach)
Date: Wed, 25 Jan 2012 09:01:49 -0500
Subject: [tei-council] Ann Arbor spring meeting
In-Reply-To: <4F1F43EF.8090904@ultraslavonic.info>
References: <o4f8j7egl1qp4ugx9vpvsh8l.1327431683813@email.android.com>
	<4F1F19E3.1000401@uvic.ca> <4F1F1EC4.3010301@uvic.ca>
	<4F1F43EF.8090904@ultraslavonic.info>
Message-ID: <CAA2irtKqAhk=DOsT1PNxkQf_YhkJzAsJBKdRMqNS4ZCD6y527Q@mail.gmail.com>

Hi all,

As Kevin has suggested, it should be no problem to book our meeting
room for Sunday, in case those who have arrived want to use it.

I'm working now with the Bell Tower Inn
(http://www.belltowerhotel.com/) to reserve a group of rooms. There's
a discount (about 15%) if the rooms are paid for by the University of
Michigan instead of by individuals--I'm working on whether we can get
approval to do this. However, if several people expect to stay for
some extra, un-reimbursed time, or arrive and depart on different
days, this might be too complicated to handle as a single transaction.

Based on the discussion above, it looks to me like there are now a
maximum of five nights eligible for reimbursement: Saturday, April 14
through Wednesday, April 18 (checking out Thursday morning). Is that
right, or are we dropping Wednesday in exchange for Saturday, and not
reimbursing for any stay after Tuesday night? (Or allowing four
nights, *either* Saturday, *or* Wednesday?)

I'm making plans based on our needing seven rooms--please let me know
if I've missed anyone or if plans have suddenly changed and you don't
expect to come:
* James Cummings
* Lou Burnard
* Piotr Banski
* Sebastian Rahtz
* Brett Barney
* Gabriel Bodard
* Martin Holmes

If you could reply, adding your expected arrival and departure dates
after your name, that will help me with securing accommodations.

Becky


On Tue, Jan 24, 2012 at 6:51 PM, Kevin Hawkins
<kevin.s.hawkins at ultraslavonic.info> wrote:
> Martin, thanks for investigating what MGuest offers and what we need.
> You're right that it's insufficient for our needs, so we'll need to get
> temporary accounts for everyone. ?This is similar to what we did for the
> 2009 conference and it shouldn't be a problem.
>
> (U-M is testing eduRoam, but it's not functional yet.)
>
> On 1/24/2012 4:12 PM, Martin Holmes wrote:
>> I was just checking out the wifi access at UMich:
>>
>> "Wireless access
>> Council members not affiliated with the University of Michigan can use
>> MGuest. If the limited access is insufficient, the local organizers can
>> ask Desktop Support Services to provide temporary uniqnames."
>>
>> The MGuest services is quite restrictive:
>>
>> [quote]
>> MGuest is limited to web (http), secure web (https) secure mail services
>> (IMAPS, POPS, SMTPS) and VPN services:
>>
>> ? ? ? HTTP 80
>> ? ? ? HTTPS 443 (TLS/SSL)
>> ? ? ? POP3s 995 (TLS/SSL)
>> ? ? ? IMAPs 993 (TLS/SSL)
>> ? ? ? SMTPs 465 (TLS/SSL)
>> ? ? ? Secure Shell (SSH) port 22
>>
>> VPN access via the following ports is allowed:
>>
>> ? ? ? Protocol 47, 50 and 51
>> ? ? ? port 500
>> ? ? ? port 1701
>> ? ? ? UDP port 4500
>> ? ? ? UDP port 10000
>>
>> MGuest is rate limited to 1Mbps down and 384kbps upload speeds.
>>
>> MGuest is treated like a non-UM network; some U-M resource such as
>> library journals cannot be accessed.
>> [/quote]
>>
>> That would presumably make my Jenkins server inaccessible, because it
>> runs on port 8080:
>>
>> <http://teijenkins.hcmc.uvic.ca:8080/>
>>
>> And we have other projects running on other ports not on the MGuest
>> list. If it's possible to get temporary logins to the main network,
>> MWireless, I'd be happier. I'm assuming that UMich doesn't support
>> eduroam? Something called "Internet2, Ann Arbor" does, but I don't see
>> any mention on the main university site.
>>
>> Cheers,
>> Martin
>>
> --
> tei-council mailing list
> tei-council at lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>
> PLEASE NOTE: postings to this list are publicly archived

From lou.burnard at retired.ox.ac.uk  Wed Jan 25 11:41:24 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Wed, 25 Jan 2012 16:41:24 +0000
Subject: [tei-council] Ann Arbor spring meeting
In-Reply-To: <CAA2irtKqAhk=DOsT1PNxkQf_YhkJzAsJBKdRMqNS4ZCD6y527Q@mail.gmail.com>
References: <o4f8j7egl1qp4ugx9vpvsh8l.1327431683813@email.android.com>	<4F1F19E3.1000401@uvic.ca>
	<4F1F1EC4.3010301@uvic.ca>	<4F1F43EF.8090904@ultraslavonic.info>
	<CAA2irtKqAhk=DOsT1PNxkQf_YhkJzAsJBKdRMqNS4ZCD6y527Q@mail.gmail.com>
Message-ID: <4F2030B4.7070605@retired.ox.ac.uk>

On 25/01/12 14:01, Rebecca Welzenbach wrote:
>
>
> I'm working now with the Bell Tower Inn
> (http://www.belltowerhotel.com/) to reserve a group of rooms.

Hoorah! I liked the Bell Tower when I stayed there back in the 20th 
century some time.

> * Lou Burnard

expects to be arriving on Saturday, leaving on Wednesday


From mholmes at uvic.ca  Wed Jan 25 11:47:34 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Wed, 25 Jan 2012 08:47:34 -0800
Subject: [tei-council] Ann Arbor spring meeting
In-Reply-To: <CAA2irtKqAhk=DOsT1PNxkQf_YhkJzAsJBKdRMqNS4ZCD6y527Q@mail.gmail.com>
References: <o4f8j7egl1qp4ugx9vpvsh8l.1327431683813@email.android.com>	<4F1F19E3.1000401@uvic.ca>
	<4F1F1EC4.3010301@uvic.ca>	<4F1F43EF.8090904@ultraslavonic.info>
	<CAA2irtKqAhk=DOsT1PNxkQf_YhkJzAsJBKdRMqNS4ZCD6y527Q@mail.gmail.com>
Message-ID: <4F203226.10901@uvic.ca>

I think we need to decide if the real meeting dates are Sunday 15th 
through Tuesday 17th. Looking at the list of attendees, there are only 
two of us travelling from elsewhere in North America (Brett and myself); 
I presume that for all the Europeans, a Saturday arrival would be 
better, so I would vote for changing the meeting dates to 15th-17th. If 
we do that, we can all head for home on the 18th (or even at the end of 
the 17th, if flights permit).

How do the local hosts feel about losing their Sunday?

Cheers,
Martin

On 12-01-25 06:01 AM, Rebecca Welzenbach wrote:
> Hi all,
>
> As Kevin has suggested, it should be no problem to book our meeting
> room for Sunday, in case those who have arrived want to use it.
>
> I'm working now with the Bell Tower Inn
> (http://www.belltowerhotel.com/) to reserve a group of rooms. There's
> a discount (about 15%) if the rooms are paid for by the University of
> Michigan instead of by individuals--I'm working on whether we can get
> approval to do this. However, if several people expect to stay for
> some extra, un-reimbursed time, or arrive and depart on different
> days, this might be too complicated to handle as a single transaction.
>
> Based on the discussion above, it looks to me like there are now a
> maximum of five nights eligible for reimbursement: Saturday, April 14
> through Wednesday, April 18 (checking out Thursday morning). Is that
> right, or are we dropping Wednesday in exchange for Saturday, and not
> reimbursing for any stay after Tuesday night? (Or allowing four
> nights, *either* Saturday, *or* Wednesday?)
>
> I'm making plans based on our needing seven rooms--please let me know
> if I've missed anyone or if plans have suddenly changed and you don't
> expect to come:
> * James Cummings
> * Lou Burnard
> * Piotr Banski
> * Sebastian Rahtz
> * Brett Barney
> * Gabriel Bodard
> * Martin Holmes
>
> If you could reply, adding your expected arrival and departure dates
> after your name, that will help me with securing accommodations.
>
> Becky
>
>
> On Tue, Jan 24, 2012 at 6:51 PM, Kevin Hawkins
> <kevin.s.hawkins at ultraslavonic.info>  wrote:
>> Martin, thanks for investigating what MGuest offers and what we need.
>> You're right that it's insufficient for our needs, so we'll need to get
>> temporary accounts for everyone.  This is similar to what we did for the
>> 2009 conference and it shouldn't be a problem.
>>
>> (U-M is testing eduRoam, but it's not functional yet.)
>>
>> On 1/24/2012 4:12 PM, Martin Holmes wrote:
>>> I was just checking out the wifi access at UMich:
>>>
>>> "Wireless access
>>> Council members not affiliated with the University of Michigan can use
>>> MGuest. If the limited access is insufficient, the local organizers can
>>> ask Desktop Support Services to provide temporary uniqnames."
>>>
>>> The MGuest services is quite restrictive:
>>>
>>> [quote]
>>> MGuest is limited to web (http), secure web (https) secure mail services
>>> (IMAPS, POPS, SMTPS) and VPN services:
>>>
>>>        HTTP 80
>>>        HTTPS 443 (TLS/SSL)
>>>        POP3s 995 (TLS/SSL)
>>>        IMAPs 993 (TLS/SSL)
>>>        SMTPs 465 (TLS/SSL)
>>>        Secure Shell (SSH) port 22
>>>
>>> VPN access via the following ports is allowed:
>>>
>>>        Protocol 47, 50 and 51
>>>        port 500
>>>        port 1701
>>>        UDP port 4500
>>>        UDP port 10000
>>>
>>> MGuest is rate limited to 1Mbps down and 384kbps upload speeds.
>>>
>>> MGuest is treated like a non-UM network; some U-M resource such as
>>> library journals cannot be accessed.
>>> [/quote]
>>>
>>> That would presumably make my Jenkins server inaccessible, because it
>>> runs on port 8080:
>>>
>>> <http://teijenkins.hcmc.uvic.ca:8080/>
>>>
>>> And we have other projects running on other ports not on the MGuest
>>> list. If it's possible to get temporary logins to the main network,
>>> MWireless, I'd be happier. I'm assuming that UMich doesn't support
>>> eduroam? Something called "Internet2, Ann Arbor" does, but I don't see
>>> any mention on the main university site.
>>>
>>> Cheers,
>>> Martin
>>>
>> --
>> tei-council mailing list
>> tei-council at lists.village.Virginia.EDU
>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>>
>> PLEASE NOTE: postings to this list are publicly archived

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From James.Cummings at oucs.ox.ac.uk  Wed Jan 25 11:58:25 2012
From: James.Cummings at oucs.ox.ac.uk (James Cummings)
Date: Wed, 25 Jan 2012 16:58:25 +0000
Subject: [tei-council] Ann Arbor spring meeting
In-Reply-To: <4F203226.10901@uvic.ca>
References: <o4f8j7egl1qp4ugx9vpvsh8l.1327431683813@email.android.com>	<4F1F19E3.1000401@uvic.ca>	<4F1F1EC4.3010301@uvic.ca>	<4F1F43EF.8090904@ultraslavonic.info>	<CAA2irtKqAhk=DOsT1PNxkQf_YhkJzAsJBKdRMqNS4ZCD6y527Q@mail.gmail.com>
	<4F203226.10901@uvic.ca>
Message-ID: <4F2034B1.7030608@oucs.ox.ac.uk>


For the record I have just booked a flight:

Departing: Saturday 14 April 09:05 from LHR
Arriving: Saturday 14 April 12:45 at DTW
Delta Airlines 19

then

Departing: Wednesday 18 April 18:45 from DTW
Arriving: Thursday 19 April 07:40 at LHR
Delta Airlines 18

I mention it in case either of my UK colleagues want to be on the 
same flight.

So I'd need hotel Sat/Sun/Mon/Tues nights.

If everyone is going to be there by the Sunday, then I'm not 
adverse to starting early. The Wednesday could be made optional 
for those who really need to fly home on the Tuesday night.

-James

On 25/01/12 16:47, Martin Holmes wrote:
> I think we need to decide if the real meeting dates are Sunday 15th
> through Tuesday 17th. Looking at the list of attendees, there are only
> two of us travelling from elsewhere in North America (Brett and myself);
> I presume that for all the Europeans, a Saturday arrival would be
> better, so I would vote for changing the meeting dates to 15th-17th. If
> we do that, we can all head for home on the 18th (or even at the end of
> the 17th, if flights permit).
>
> How do the local hosts feel about losing their Sunday?
>
> Cheers,
> Martin
>
> On 12-01-25 06:01 AM, Rebecca Welzenbach wrote:
>> Hi all,
>>
>> As Kevin has suggested, it should be no problem to book our meeting
>> room for Sunday, in case those who have arrived want to use it.
>>
>> I'm working now with the Bell Tower Inn
>> (http://www.belltowerhotel.com/) to reserve a group of rooms. There's
>> a discount (about 15%) if the rooms are paid for by the University of
>> Michigan instead of by individuals--I'm working on whether we can get
>> approval to do this. However, if several people expect to stay for
>> some extra, un-reimbursed time, or arrive and depart on different
>> days, this might be too complicated to handle as a single transaction.
>>
>> Based on the discussion above, it looks to me like there are now a
>> maximum of five nights eligible for reimbursement: Saturday, April 14
>> through Wednesday, April 18 (checking out Thursday morning). Is that
>> right, or are we dropping Wednesday in exchange for Saturday, and not
>> reimbursing for any stay after Tuesday night? (Or allowing four
>> nights, *either* Saturday, *or* Wednesday?)
>>
>> I'm making plans based on our needing seven rooms--please let me know
>> if I've missed anyone or if plans have suddenly changed and you don't
>> expect to come:
>> * James Cummings
>> * Lou Burnard
>> * Piotr Banski
>> * Sebastian Rahtz
>> * Brett Barney
>> * Gabriel Bodard
>> * Martin Holmes
>>
>> If you could reply, adding your expected arrival and departure dates
>> after your name, that will help me with securing accommodations.
>>
>> Becky
>>
>>
>> On Tue, Jan 24, 2012 at 6:51 PM, Kevin Hawkins
>> <kevin.s.hawkins at ultraslavonic.info>   wrote:
>>> Martin, thanks for investigating what MGuest offers and what we need.
>>> You're right that it's insufficient for our needs, so we'll need to get
>>> temporary accounts for everyone.  This is similar to what we did for the
>>> 2009 conference and it shouldn't be a problem.
>>>
>>> (U-M is testing eduRoam, but it's not functional yet.)
>>>
>>> On 1/24/2012 4:12 PM, Martin Holmes wrote:
>>>> I was just checking out the wifi access at UMich:
>>>>
>>>> "Wireless access
>>>> Council members not affiliated with the University of Michigan can use
>>>> MGuest. If the limited access is insufficient, the local organizers can
>>>> ask Desktop Support Services to provide temporary uniqnames."
>>>>
>>>> The MGuest services is quite restrictive:
>>>>
>>>> [quote]
>>>> MGuest is limited to web (http), secure web (https) secure mail services
>>>> (IMAPS, POPS, SMTPS) and VPN services:
>>>>
>>>>         HTTP 80
>>>>         HTTPS 443 (TLS/SSL)
>>>>         POP3s 995 (TLS/SSL)
>>>>         IMAPs 993 (TLS/SSL)
>>>>         SMTPs 465 (TLS/SSL)
>>>>         Secure Shell (SSH) port 22
>>>>
>>>> VPN access via the following ports is allowed:
>>>>
>>>>         Protocol 47, 50 and 51
>>>>         port 500
>>>>         port 1701
>>>>         UDP port 4500
>>>>         UDP port 10000
>>>>
>>>> MGuest is rate limited to 1Mbps down and 384kbps upload speeds.
>>>>
>>>> MGuest is treated like a non-UM network; some U-M resource such as
>>>> library journals cannot be accessed.
>>>> [/quote]
>>>>
>>>> That would presumably make my Jenkins server inaccessible, because it
>>>> runs on port 8080:
>>>>
>>>> <http://teijenkins.hcmc.uvic.ca:8080/>
>>>>
>>>> And we have other projects running on other ports not on the MGuest
>>>> list. If it's possible to get temporary logins to the main network,
>>>> MWireless, I'd be happier. I'm assuming that UMich doesn't support
>>>> eduroam? Something called "Internet2, Ann Arbor" does, but I don't see
>>>> any mention on the main university site.
>>>>
>>>> Cheers,
>>>> Martin
>>>>
>>> --
>>> tei-council mailing list
>>> tei-council at lists.village.Virginia.EDU
>>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>>>
>>> PLEASE NOTE: postings to this list are publicly archived
>


-- 
Dr James Cummings, InfoDev,
Computing Services, University of Oxford

From bansp at o2.pl  Wed Jan 25 12:22:49 2012
From: bansp at o2.pl (=?ISO-8859-2?Q?Piotr_Ba=F1ski?=)
Date: Wed, 25 Jan 2012 18:22:49 +0100
Subject: [tei-council] Ann Arbor spring meeting
In-Reply-To: <4F203226.10901@uvic.ca>
References: <o4f8j7egl1qp4ugx9vpvsh8l.1327431683813@email.android.com>	<4F1F19E3.1000401@uvic.ca>	<4F1F1EC4.3010301@uvic.ca>	<4F1F43EF.8090904@ultraslavonic.info>	<CAA2irtKqAhk=DOsT1PNxkQf_YhkJzAsJBKdRMqNS4ZCD6y527Q@mail.gmail.com>
	<4F203226.10901@uvic.ca>
Message-ID: <4F203A69.6000500@o2.pl>

Hi,

I also plan to fly to Detroit from within the States, on Sunday. I will
try to find a morning flight but can't promise I will find one, so I'd
rather treat Sunday afternoon as an extra, rather than as part of the
meeting proper.

Best,

  Piotr

On 25/01/12 17:47, Martin Holmes wrote:
> I think we need to decide if the real meeting dates are Sunday 15th 
> through Tuesday 17th. Looking at the list of attendees, there are only 
> two of us travelling from elsewhere in North America (Brett and myself); 
> I presume that for all the Europeans, a Saturday arrival would be 
> better, so I would vote for changing the meeting dates to 15th-17th. If 
> we do that, we can all head for home on the 18th (or even at the end of 
> the 17th, if flights permit).
> 
> How do the local hosts feel about losing their Sunday?
> 
> Cheers,
> Martin
> 
> On 12-01-25 06:01 AM, Rebecca Welzenbach wrote:
>> Hi all,
>>
>> As Kevin has suggested, it should be no problem to book our meeting
>> room for Sunday, in case those who have arrived want to use it.
>>
>> I'm working now with the Bell Tower Inn
>> (http://www.belltowerhotel.com/) to reserve a group of rooms. There's
>> a discount (about 15%) if the rooms are paid for by the University of
>> Michigan instead of by individuals--I'm working on whether we can get
>> approval to do this. However, if several people expect to stay for
>> some extra, un-reimbursed time, or arrive and depart on different
>> days, this might be too complicated to handle as a single transaction.
>>
>> Based on the discussion above, it looks to me like there are now a
>> maximum of five nights eligible for reimbursement: Saturday, April 14
>> through Wednesday, April 18 (checking out Thursday morning). Is that
>> right, or are we dropping Wednesday in exchange for Saturday, and not
>> reimbursing for any stay after Tuesday night? (Or allowing four
>> nights, *either* Saturday, *or* Wednesday?)
>>
>> I'm making plans based on our needing seven rooms--please let me know
>> if I've missed anyone or if plans have suddenly changed and you don't
>> expect to come:
>> * James Cummings
>> * Lou Burnard
>> * Piotr Banski
>> * Sebastian Rahtz
>> * Brett Barney
>> * Gabriel Bodard
>> * Martin Holmes
>>
>> If you could reply, adding your expected arrival and departure dates
>> after your name, that will help me with securing accommodations.
>>
>> Becky
>>
>>
>> On Tue, Jan 24, 2012 at 6:51 PM, Kevin Hawkins
>> <kevin.s.hawkins at ultraslavonic.info>  wrote:
>>> Martin, thanks for investigating what MGuest offers and what we need.
>>> You're right that it's insufficient for our needs, so we'll need to get
>>> temporary accounts for everyone.  This is similar to what we did for the
>>> 2009 conference and it shouldn't be a problem.
>>>
>>> (U-M is testing eduRoam, but it's not functional yet.)
>>>
>>> On 1/24/2012 4:12 PM, Martin Holmes wrote:
>>>> I was just checking out the wifi access at UMich:
>>>>
>>>> "Wireless access
>>>> Council members not affiliated with the University of Michigan can use
>>>> MGuest. If the limited access is insufficient, the local organizers can
>>>> ask Desktop Support Services to provide temporary uniqnames."
>>>>
>>>> The MGuest services is quite restrictive:
>>>>
>>>> [quote]
>>>> MGuest is limited to web (http), secure web (https) secure mail services
>>>> (IMAPS, POPS, SMTPS) and VPN services:
>>>>
>>>>        HTTP 80
>>>>        HTTPS 443 (TLS/SSL)
>>>>        POP3s 995 (TLS/SSL)
>>>>        IMAPs 993 (TLS/SSL)
>>>>        SMTPs 465 (TLS/SSL)
>>>>        Secure Shell (SSH) port 22
>>>>
>>>> VPN access via the following ports is allowed:
>>>>
>>>>        Protocol 47, 50 and 51
>>>>        port 500
>>>>        port 1701
>>>>        UDP port 4500
>>>>        UDP port 10000
>>>>
>>>> MGuest is rate limited to 1Mbps down and 384kbps upload speeds.
>>>>
>>>> MGuest is treated like a non-UM network; some U-M resource such as
>>>> library journals cannot be accessed.
>>>> [/quote]
>>>>
>>>> That would presumably make my Jenkins server inaccessible, because it
>>>> runs on port 8080:
>>>>
>>>> <http://teijenkins.hcmc.uvic.ca:8080/>
>>>>
>>>> And we have other projects running on other ports not on the MGuest
>>>> list. If it's possible to get temporary logins to the main network,
>>>> MWireless, I'd be happier. I'm assuming that UMich doesn't support
>>>> eduroam? Something called "Internet2, Ann Arbor" does, but I don't see
>>>> any mention on the main university site.
>>>>
>>>> Cheers,
>>>> Martin
>>>>
>>> --
>>> tei-council mailing list
>>> tei-council at lists.village.Virginia.EDU
>>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>>>
>>> PLEASE NOTE: postings to this list are publicly archived
> 


From bansp at o2.pl  Wed Jan 25 17:44:48 2012
From: bansp at o2.pl (=?ISO-8859-2?Q?Piotr_Ba=F1ski?=)
Date: Wed, 25 Jan 2012 23:44:48 +0100
Subject: [tei-council] Ann Arbor spring meeting
In-Reply-To: <4F203A69.6000500@o2.pl>
References: <o4f8j7egl1qp4ugx9vpvsh8l.1327431683813@email.android.com>	<4F1F19E3.1000401@uvic.ca>	<4F1F1EC4.3010301@uvic.ca>	<4F1F43EF.8090904@ultraslavonic.info>	<CAA2irtKqAhk=DOsT1PNxkQf_YhkJzAsJBKdRMqNS4ZCD6y527Q@mail.gmail.com>	<4F203226.10901@uvic.ca>
	<4F203A69.6000500@o2.pl>
Message-ID: <4F2085E0.2070506@o2.pl>

FWIW, I'm scheduled to be in Detroit at 12:43 on Sunday, so I hope to
join the afternoon activities.

Best,

  P.

On 25/01/12 18:22, Piotr Ba?ski wrote:
> Hi,
> 
> I also plan to fly to Detroit from within the States, on Sunday. I will
> try to find a morning flight but can't promise I will find one, so I'd
> rather treat Sunday afternoon as an extra, rather than as part of the
> meeting proper.
> 
> Best,
> 
>   Piotr
> 
> On 25/01/12 17:47, Martin Holmes wrote:
>> I think we need to decide if the real meeting dates are Sunday 15th 
>> through Tuesday 17th. Looking at the list of attendees, there are only 
>> two of us travelling from elsewhere in North America (Brett and myself); 
>> I presume that for all the Europeans, a Saturday arrival would be 
>> better, so I would vote for changing the meeting dates to 15th-17th. If 
>> we do that, we can all head for home on the 18th (or even at the end of 
>> the 17th, if flights permit).
>>
>> How do the local hosts feel about losing their Sunday?
>>
>> Cheers,
>> Martin
>>
>> On 12-01-25 06:01 AM, Rebecca Welzenbach wrote:
>>> Hi all,
>>>
>>> As Kevin has suggested, it should be no problem to book our meeting
>>> room for Sunday, in case those who have arrived want to use it.
>>>
>>> I'm working now with the Bell Tower Inn
>>> (http://www.belltowerhotel.com/) to reserve a group of rooms. There's
>>> a discount (about 15%) if the rooms are paid for by the University of
>>> Michigan instead of by individuals--I'm working on whether we can get
>>> approval to do this. However, if several people expect to stay for
>>> some extra, un-reimbursed time, or arrive and depart on different
>>> days, this might be too complicated to handle as a single transaction.
>>>
>>> Based on the discussion above, it looks to me like there are now a
>>> maximum of five nights eligible for reimbursement: Saturday, April 14
>>> through Wednesday, April 18 (checking out Thursday morning). Is that
>>> right, or are we dropping Wednesday in exchange for Saturday, and not
>>> reimbursing for any stay after Tuesday night? (Or allowing four
>>> nights, *either* Saturday, *or* Wednesday?)
>>>
>>> I'm making plans based on our needing seven rooms--please let me know
>>> if I've missed anyone or if plans have suddenly changed and you don't
>>> expect to come:
>>> * James Cummings
>>> * Lou Burnard
>>> * Piotr Banski
>>> * Sebastian Rahtz
>>> * Brett Barney
>>> * Gabriel Bodard
>>> * Martin Holmes
>>>
>>> If you could reply, adding your expected arrival and departure dates
>>> after your name, that will help me with securing accommodations.
>>>
>>> Becky
>>>
>>>
>>> On Tue, Jan 24, 2012 at 6:51 PM, Kevin Hawkins
>>> <kevin.s.hawkins at ultraslavonic.info>  wrote:
>>>> Martin, thanks for investigating what MGuest offers and what we need.
>>>> You're right that it's insufficient for our needs, so we'll need to get
>>>> temporary accounts for everyone.  This is similar to what we did for the
>>>> 2009 conference and it shouldn't be a problem.
>>>>
>>>> (U-M is testing eduRoam, but it's not functional yet.)
>>>>
>>>> On 1/24/2012 4:12 PM, Martin Holmes wrote:
>>>>> I was just checking out the wifi access at UMich:
>>>>>
>>>>> "Wireless access
>>>>> Council members not affiliated with the University of Michigan can use
>>>>> MGuest. If the limited access is insufficient, the local organizers can
>>>>> ask Desktop Support Services to provide temporary uniqnames."
>>>>>
>>>>> The MGuest services is quite restrictive:
>>>>>
>>>>> [quote]
>>>>> MGuest is limited to web (http), secure web (https) secure mail services
>>>>> (IMAPS, POPS, SMTPS) and VPN services:
>>>>>
>>>>>        HTTP 80
>>>>>        HTTPS 443 (TLS/SSL)
>>>>>        POP3s 995 (TLS/SSL)
>>>>>        IMAPs 993 (TLS/SSL)
>>>>>        SMTPs 465 (TLS/SSL)
>>>>>        Secure Shell (SSH) port 22
>>>>>
>>>>> VPN access via the following ports is allowed:
>>>>>
>>>>>        Protocol 47, 50 and 51
>>>>>        port 500
>>>>>        port 1701
>>>>>        UDP port 4500
>>>>>        UDP port 10000
>>>>>
>>>>> MGuest is rate limited to 1Mbps down and 384kbps upload speeds.
>>>>>
>>>>> MGuest is treated like a non-UM network; some U-M resource such as
>>>>> library journals cannot be accessed.
>>>>> [/quote]
>>>>>
>>>>> That would presumably make my Jenkins server inaccessible, because it
>>>>> runs on port 8080:
>>>>>
>>>>> <http://teijenkins.hcmc.uvic.ca:8080/>
>>>>>
>>>>> And we have other projects running on other ports not on the MGuest
>>>>> list. If it's possible to get temporary logins to the main network,
>>>>> MWireless, I'd be happier. I'm assuming that UMich doesn't support
>>>>> eduroam? Something called "Internet2, Ann Arbor" does, but I don't see
>>>>> any mention on the main university site.
>>>>>
>>>>> Cheers,
>>>>> Martin

From mholmes at uvic.ca  Wed Jan 25 17:54:59 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Wed, 25 Jan 2012 14:54:59 -0800
Subject: [tei-council] Ann Arbor spring meeting
In-Reply-To: <4F203A69.6000500@o2.pl>
References: <o4f8j7egl1qp4ugx9vpvsh8l.1327431683813@email.android.com>	<4F1F19E3.1000401@uvic.ca>	<4F1F1EC4.3010301@uvic.ca>	<4F1F43EF.8090904@ultraslavonic.info>	<CAA2irtKqAhk=DOsT1PNxkQf_YhkJzAsJBKdRMqNS4ZCD6y527Q@mail.gmail.com>	<4F203226.10901@uvic.ca>
	<4F203A69.6000500@o2.pl>
Message-ID: <4F208843.205@uvic.ca>

So, given these choices:

1. Arrive Saturday, leave relatively early Wednesday
      (working days Sunday, Monday, Tuesday, and a bit of Wed)

2. Arrive Sunday, leave Thursday
      (working days Monday, Tuesday, Wednesday)

3. Arrive Saturday, leave Thursday
      (working days Sun, Mon, Tue, Wed, but one extra night in hotel)

which should I choose? #3 gives me maximum working time but costs the 
TEI an extra night. If nobody cares, and James thinks the TEI can afford 
it, I'll choose #3, but if cost matters, would #1 or #2 be better?

Cheers,
Martin

On 12-01-25 09:22 AM, Piotr Ba?ski wrote:
> Hi,
>
> I also plan to fly to Detroit from within the States, on Sunday. I will
> try to find a morning flight but can't promise I will find one, so I'd
> rather treat Sunday afternoon as an extra, rather than as part of the
> meeting proper.
>
> Best,
>
>    Piotr
>
> On 25/01/12 17:47, Martin Holmes wrote:
>> I think we need to decide if the real meeting dates are Sunday 15th
>> through Tuesday 17th. Looking at the list of attendees, there are only
>> two of us travelling from elsewhere in North America (Brett and myself);
>> I presume that for all the Europeans, a Saturday arrival would be
>> better, so I would vote for changing the meeting dates to 15th-17th. If
>> we do that, we can all head for home on the 18th (or even at the end of
>> the 17th, if flights permit).
>>
>> How do the local hosts feel about losing their Sunday?
>>
>> Cheers,
>> Martin
>>
>> On 12-01-25 06:01 AM, Rebecca Welzenbach wrote:
>>> Hi all,
>>>
>>> As Kevin has suggested, it should be no problem to book our meeting
>>> room for Sunday, in case those who have arrived want to use it.
>>>
>>> I'm working now with the Bell Tower Inn
>>> (http://www.belltowerhotel.com/) to reserve a group of rooms. There's
>>> a discount (about 15%) if the rooms are paid for by the University of
>>> Michigan instead of by individuals--I'm working on whether we can get
>>> approval to do this. However, if several people expect to stay for
>>> some extra, un-reimbursed time, or arrive and depart on different
>>> days, this might be too complicated to handle as a single transaction.
>>>
>>> Based on the discussion above, it looks to me like there are now a
>>> maximum of five nights eligible for reimbursement: Saturday, April 14
>>> through Wednesday, April 18 (checking out Thursday morning). Is that
>>> right, or are we dropping Wednesday in exchange for Saturday, and not
>>> reimbursing for any stay after Tuesday night? (Or allowing four
>>> nights, *either* Saturday, *or* Wednesday?)
>>>
>>> I'm making plans based on our needing seven rooms--please let me know
>>> if I've missed anyone or if plans have suddenly changed and you don't
>>> expect to come:
>>> * James Cummings
>>> * Lou Burnard
>>> * Piotr Banski
>>> * Sebastian Rahtz
>>> * Brett Barney
>>> * Gabriel Bodard
>>> * Martin Holmes
>>>
>>> If you could reply, adding your expected arrival and departure dates
>>> after your name, that will help me with securing accommodations.
>>>
>>> Becky
>>>
>>>
>>> On Tue, Jan 24, 2012 at 6:51 PM, Kevin Hawkins
>>> <kevin.s.hawkins at ultraslavonic.info>   wrote:
>>>> Martin, thanks for investigating what MGuest offers and what we need.
>>>> You're right that it's insufficient for our needs, so we'll need to get
>>>> temporary accounts for everyone.  This is similar to what we did for the
>>>> 2009 conference and it shouldn't be a problem.
>>>>
>>>> (U-M is testing eduRoam, but it's not functional yet.)
>>>>
>>>> On 1/24/2012 4:12 PM, Martin Holmes wrote:
>>>>> I was just checking out the wifi access at UMich:
>>>>>
>>>>> "Wireless access
>>>>> Council members not affiliated with the University of Michigan can use
>>>>> MGuest. If the limited access is insufficient, the local organizers can
>>>>> ask Desktop Support Services to provide temporary uniqnames."
>>>>>
>>>>> The MGuest services is quite restrictive:
>>>>>
>>>>> [quote]
>>>>> MGuest is limited to web (http), secure web (https) secure mail services
>>>>> (IMAPS, POPS, SMTPS) and VPN services:
>>>>>
>>>>>         HTTP 80
>>>>>         HTTPS 443 (TLS/SSL)
>>>>>         POP3s 995 (TLS/SSL)
>>>>>         IMAPs 993 (TLS/SSL)
>>>>>         SMTPs 465 (TLS/SSL)
>>>>>         Secure Shell (SSH) port 22
>>>>>
>>>>> VPN access via the following ports is allowed:
>>>>>
>>>>>         Protocol 47, 50 and 51
>>>>>         port 500
>>>>>         port 1701
>>>>>         UDP port 4500
>>>>>         UDP port 10000
>>>>>
>>>>> MGuest is rate limited to 1Mbps down and 384kbps upload speeds.
>>>>>
>>>>> MGuest is treated like a non-UM network; some U-M resource such as
>>>>> library journals cannot be accessed.
>>>>> [/quote]
>>>>>
>>>>> That would presumably make my Jenkins server inaccessible, because it
>>>>> runs on port 8080:
>>>>>
>>>>> <http://teijenkins.hcmc.uvic.ca:8080/>
>>>>>
>>>>> And we have other projects running on other ports not on the MGuest
>>>>> list. If it's possible to get temporary logins to the main network,
>>>>> MWireless, I'd be happier. I'm assuming that UMich doesn't support
>>>>> eduroam? Something called "Internet2, Ann Arbor" does, but I don't see
>>>>> any mention on the main university site.
>>>>>
>>>>> Cheers,
>>>>> Martin
>>>>>
>>>> --
>>>> tei-council mailing list
>>>> tei-council at lists.village.Virginia.EDU
>>>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>>>>
>>>> PLEASE NOTE: postings to this list are publicly archived
>>
>

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From kevin.s.hawkins at ultraslavonic.info  Wed Jan 25 18:01:45 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Wed, 25 Jan 2012 18:01:45 -0500
Subject: [tei-council] Ann Arbor spring meeting
In-Reply-To: <4F208843.205@uvic.ca>
References: <o4f8j7egl1qp4ugx9vpvsh8l.1327431683813@email.android.com>	<4F1F19E3.1000401@uvic.ca>	<4F1F1EC4.3010301@uvic.ca>	<4F1F43EF.8090904@ultraslavonic.info>	<CAA2irtKqAhk=DOsT1PNxkQf_YhkJzAsJBKdRMqNS4ZCD6y527Q@mail.gmail.com>	<4F203226.10901@uvic.ca>
	<4F203A69.6000500@o2.pl> <4F208843.205@uvic.ca>
Message-ID: <4F2089D9.2050405@ultraslavonic.info>

I think we're in a situation where no one is prepared to unilaterally 
declare which days are the official working days of the Council meeting. 
  Since there was interest in having a group hacking session before the 
official sessions start, I suggest we keep Sunday as the optional 
attendance day and keep Monday, Tuesday, and Wednesday as the real work 
days.  I live closer to the university than Paul or Becky, so I don't 
mind opening the meeting room on Sunday and hanging out with whoever 
joins me there.

It is often the case that people need to leave early on the third 
working day, so I suggest leaving that late afternoon or evening if it 
works in your schedule.  If it doesn't for some reason, stay an extra night.

Does this work for everyone?

Kevin

From sebastian.rahtz at oucs.ox.ac.uk  Wed Jan 25 18:11:09 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Wed, 25 Jan 2012 23:11:09 +0000
Subject: [tei-council] Ann Arbor spring meeting
In-Reply-To: <4F2089D9.2050405@ultraslavonic.info>
References: <o4f8j7egl1qp4ugx9vpvsh8l.1327431683813@email.android.com>
	<4F1F19E3.1000401@uvic.ca>	<4F1F1EC4.3010301@uvic.ca>
	<4F1F43EF.8090904@ultraslavonic.info>
	<CAA2irtKqAhk=DOsT1PNxkQf_YhkJzAsJBKdRMqNS4ZCD6y527Q@mail.gmail.com>
	<4F203226.10901@uvic.ca>	<4F203A69.6000500@o2.pl>
	<4F208843.205@uvic.ca> <4F2089D9.2050405@ultraslavonic.info>
Message-ID: <EC1625A5-ACC8-4BFF-AFC2-277B9F984ECE@oucs.ox.ac.uk>


On 25 Jan 2012, at 23:01, Kevin Hawkins wrote:

> I think we're in a situation where no one is prepared to unilaterally 
> declare which days are the official working days of the Council meeting. 
>  Since there was interest in having a group hacking session before the 
> official sessions start, I suggest we keep Sunday as the optional 
> attendance day and keep Monday, Tuesday, and Wednesday as the real work 
> days.  

I agree. Planning to complete by (say) 4pm on Wednesday.

--
Stormageddon Rahtz      
Head of Information and Support Group, Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431

S?lo le pido a Dios
que el futuro no me sea indiferente


From mholmes at uvic.ca  Wed Jan 25 18:19:44 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Wed, 25 Jan 2012 15:19:44 -0800
Subject: [tei-council] Ann Arbor spring meeting
In-Reply-To: <4F2089D9.2050405@ultraslavonic.info>
References: <o4f8j7egl1qp4ugx9vpvsh8l.1327431683813@email.android.com>	<4F1F19E3.1000401@uvic.ca>	<4F1F1EC4.3010301@uvic.ca>	<4F1F43EF.8090904@ultraslavonic.info>	<CAA2irtKqAhk=DOsT1PNxkQf_YhkJzAsJBKdRMqNS4ZCD6y527Q@mail.gmail.com>	<4F203226.10901@uvic.ca>	<4F203A69.6000500@o2.pl>
	<4F208843.205@uvic.ca> <4F2089D9.2050405@ultraslavonic.info>
Message-ID: <4F208E10.8030204@uvic.ca>

Works for me. If there are no strenuous objections overnight, I'll go 
for the five-night option. I promise to do the minutes for at least one 
day as recompense.

Cheers,
Martin

On 12-01-25 03:01 PM, Kevin Hawkins wrote:
> I think we're in a situation where no one is prepared to unilaterally
> declare which days are the official working days of the Council meeting.
>    Since there was interest in having a group hacking session before the
> official sessions start, I suggest we keep Sunday as the optional
> attendance day and keep Monday, Tuesday, and Wednesday as the real work
> days.  I live closer to the university than Paul or Becky, so I don't
> mind opening the meeting room on Sunday and hanging out with whoever
> joins me there.
>
> It is often the case that people need to leave early on the third
> working day, so I suggest leaving that late afternoon or evening if it
> works in your schedule.  If it doesn't for some reason, stay an extra night.
>
> Does this work for everyone?
>
> Kevin

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From James.Cummings at oucs.ox.ac.uk  Thu Jan 26 04:54:28 2012
From: James.Cummings at oucs.ox.ac.uk (James Cummings)
Date: Thu, 26 Jan 2012 09:54:28 +0000
Subject: [tei-council] Ann Arbor spring meeting
In-Reply-To: <4F2089D9.2050405@ultraslavonic.info>
References: <o4f8j7egl1qp4ugx9vpvsh8l.1327431683813@email.android.com>	<4F1F19E3.1000401@uvic.ca>	<4F1F1EC4.3010301@uvic.ca>	<4F1F43EF.8090904@ultraslavonic.info>	<CAA2irtKqAhk=DOsT1PNxkQf_YhkJzAsJBKdRMqNS4ZCD6y527Q@mail.gmail.com>	<4F203226.10901@uvic.ca>	<4F203A69.6000500@o2.pl>
	<4F208843.205@uvic.ca> <4F2089D9.2050405@ultraslavonic.info>
Message-ID: <4F2122D4.7050209@oucs.ox.ac.uk>

On 25/01/12 23:01, Kevin Hawkins wrote:
> I think we're in a situation where no one is prepared to unilaterally
> declare which days are the official working days of the Council meeting.

I think you'll find I am.

As I suggested before, but will now do in my detail I believe the 
schedule should be as follows:

Sunday: TEI Hackfest (optional: those that are there promise to 
dedicate their time to do things that are useful to the TEI)
Monday: Meeting Day 1
Tuesday: Meeting Day 2
Wednesday: Meeting Day 3 with early departure. (Those that need 
to leave, try to stay until at least noon.

I would _only_ suggest those people who achieve a significant 
saving to come earlier (i.e. those getting penalised for not 
including a saturday). The saving must be more than an extra 
night's hotel and per diem of food.

Are there any serious objections to that? Remember that the more 
we spend the less money is left over for funding things like a 
potential web-Roma2 implementation.

> days.  I live closer to the university than Paul or Becky, so I don't
> mind opening the meeting room on Sunday and hanging out with whoever
> joins me there.

Thanks Kevin, I appreciate that. I certainly will be there (and 
from the sounds of it some others).

I've put up a doodle for people to record what nights they will 
need hotel. This will be useful for Becky if doing a block 
booking, and/or all of us to know who is arriving/departing when. 
  Since I'm arriving on the Sat and leaving on the Wednesday, 
I've checked Sat/Sun/Mon/Tues Nights. Could everyone needing 
hotel fill it out?

-James

-- 
Dr James Cummings, InfoDev,
Computing Services, University of Oxford

From James.Cummings at oucs.ox.ac.uk  Thu Jan 26 04:57:51 2012
From: James.Cummings at oucs.ox.ac.uk (James Cummings)
Date: Thu, 26 Jan 2012 09:57:51 +0000
Subject: [tei-council] Ann Arbor spring meeting
In-Reply-To: <4F2122D4.7050209@oucs.ox.ac.uk>
References: <o4f8j7egl1qp4ugx9vpvsh8l.1327431683813@email.android.com>	<4F1F19E3.1000401@uvic.ca>	<4F1F1EC4.3010301@uvic.ca>	<4F1F43EF.8090904@ultraslavonic.info>	<CAA2irtKqAhk=DOsT1PNxkQf_YhkJzAsJBKdRMqNS4ZCD6y527Q@mail.gmail.com>	<4F203226.10901@uvic.ca>	<4F203A69.6000500@o2.pl>	<4F208843.205@uvic.ca>
	<4F2089D9.2050405@ultraslavonic.info>
	<4F2122D4.7050209@oucs.ox.ac.uk>
Message-ID: <4F21239F.5070501@oucs.ox.ac.uk>

On 26/01/12 09:54, James Cummings wrote:
> I've put up a doodle for people to record what nights they will
> need hotel. This will be useful for Becky if doing a block
> booking, and/or all of us to know who is arriving/departing when.
>    Since I'm arriving on the Sat and leaving on the Wednesday,
> I've checked Sat/Sun/Mon/Tues Nights. Could everyone needing
> hotel fill it out?

Of course it would be better if I included the URL. (*doh*)

http://www.doodle.com/9dunbbdcngadff68



>
> -James
>


-- 
Dr James Cummings, InfoDev,
Computing Services, University of Oxford

From rwelzenbach at gmail.com  Thu Jan 26 08:57:43 2012
From: rwelzenbach at gmail.com (Rebecca Welzenbach)
Date: Thu, 26 Jan 2012 08:57:43 -0500
Subject: [tei-council] Ann Arbor spring meeting
In-Reply-To: <4F21239F.5070501@oucs.ox.ac.uk>
References: <o4f8j7egl1qp4ugx9vpvsh8l.1327431683813@email.android.com>
	<4F1F19E3.1000401@uvic.ca> <4F1F1EC4.3010301@uvic.ca>
	<4F1F43EF.8090904@ultraslavonic.info>
	<CAA2irtKqAhk=DOsT1PNxkQf_YhkJzAsJBKdRMqNS4ZCD6y527Q@mail.gmail.com>
	<4F203226.10901@uvic.ca> <4F203A69.6000500@o2.pl>
	<4F208843.205@uvic.ca> <4F2089D9.2050405@ultraslavonic.info>
	<4F2122D4.7050209@oucs.ox.ac.uk> <4F21239F.5070501@oucs.ox.ac.uk>
Message-ID: <CAA2irtJggbRO0XE9H3dsYM4Gxh04pqR=jt_sTZWXj7vVt=XK0w@mail.gmail.com>

Great idea--thanks, James.

On Thu, Jan 26, 2012 at 4:57 AM, James Cummings
<James.Cummings at oucs.ox.ac.uk> wrote:
> On 26/01/12 09:54, James Cummings wrote:
>> I've put up a doodle for people to record what nights they will
>> need hotel. This will be useful for Becky if doing a block
>> booking, and/or all of us to know who is arriving/departing when.
>> ? ?Since I'm arriving on the Sat and leaving on the Wednesday,
>> I've checked Sat/Sun/Mon/Tues Nights. Could everyone needing
>> hotel fill it out?
>
> Of course it would be better if I included the URL. (*doh*)
>
> http://www.doodle.com/9dunbbdcngadff68
>
>
>
>>
>> -James
>>
>
>
> --
> Dr James Cummings, InfoDev,
> Computing Services, University of Oxford
> --
> tei-council mailing list
> tei-council at lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>
> PLEASE NOTE: postings to this list are publicly archived

From kevin.s.hawkins at ultraslavonic.info  Thu Jan 26 20:13:43 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Thu, 26 Jan 2012 20:13:43 -0500
Subject: [tei-council] Minor error in Guidelines
In-Reply-To: <4F1059A9.1000709@retired.ox.ac.uk>
References: <4F0F9F9F.3050408@gmail.com>
	<4F0FBAA5.2090706@uvic.ca>	<97AE8F42-0EDB-41CC-8FE1-984EE9E495D4@oucs.ox.ac.uk>
	<4F10590C.50904@uvic.ca> <4F1059A9.1000709@retired.ox.ac.uk>
Message-ID: <4F21FA47.2050800@ultraslavonic.info>

I'm wondering whether others feel that we should add a bit to

http://www.tei-c.org/Activities/Council/Working/tcw20.xml

or perhaps more properly

P5/Source/Guidelines/en/style-guide.txt

stating this distinction.  There might be other things that those who 
have been editing the Guidelines keep in mind but haven't written down 
for the rest of us.

Such a passage would be similar to this, which I found in tcw20 and is 
similarly prescriptive about encoding practice:

###

In most chapters, the two character code is also used as a prefix for 
the @xml:id values given to each <div> element. Note that every <div> 
element carries an @xml:id value, whether or not it is actually 
referenced explicitly elewhere in the Guidelines.

###

Is this worthwhile, or would none of us ever remember to consult this 
anyway?

--K.

On 1/13/12 11:19 AM, Lou Burnard wrote:
> In the Guidelines, as elsewhere,
>
> <ref target="#foo">section foo</ref>  means: generate a link to #foo and
> represent it by the text "section foo".
>
> <ptr target="#foo"/>  means: generate a link to #foo and represent it by
> whatever text your processor chooses to generate
>
>
>
> On 13/01/12 16:17, Martin Holmes wrote:
>> Could you clarify what the difference is between using<ref>   and<ptr>
>> in the guidelines?
>>
>> Cheers,
>> Martin
>>
>> On 12-01-13 01:32 AM, Sebastian Rahtz wrote:
>>>
>>> On 13 Jan 2012, at 05:01, Martin Holmes wrote:
>>>
>>>> I've put in a bug report for this:
>>>>
>>>> <http://purl.org/TEI/BUGS/3473329>
>>>>
>>>> The basic problem is that in the web view of the Guidelines, figures
>>>> within each chapter are numbered 1, 2, 3, 4 etc., but in the PDF output,
>>>> they're numbered 11.1, 11.2, 11.3?
>>>>
>>> there are two issues here.
>>>
>>>      a) the use of dangerous markup like "<ref target="#sleeprs">figure 4 above</ref>", which should be changed into a<ptr>    to avoid this sort of problem
>>>      b) the different numbering schemes
>>>
>>> for the latter, which do we want for the Guidelines? by chapter, or sequential throughout?
>>>
>>> for the former, I found 3 occurrences of this, and changed them to<ptr>. am testing before committing.
>>> --
>>> Stormageddon Rahtz
>>> Head of Information and Support Group
>>> Oxford University Computing Services
>>> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>>>
>>> S?lo le pido a Dios
>>> que el futuro no me sea indiferente
>>>
>>
>

From gabriel.bodard at kcl.ac.uk  Fri Jan 27 06:22:34 2012
From: gabriel.bodard at kcl.ac.uk (Gabriel Bodard)
Date: Fri, 27 Jan 2012 11:22:34 +0000
Subject: [tei-council] Redundant note in <exemplum>
Message-ID: <4F2288FA.3070405@kcl.ac.uk>

As far as I can see, the note at the bottom of the page 
<http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-exemplum.html> 
must date from when these elements were in SGML, since it warns coders 
to use an explicit end-tag, which has long been required for all 
elements in XML anyway.

Any objection if I just delete this note from the source?

G

-- 
Dr Gabriel BODARD
(Research Associate in Digital Epigraphy)

Department of Digital Humanities
King's College London
26-29 Drury Lane
London WC2B 5RL

Email: gabriel.bodard at kcl.ac.uk
Tel: +44 (0)20 7848 1388
Fax: +44 (0)20 7848 2980

http://www.digitalclassicist.org/
http://www.currentepigraphy.org/

From sebastian.rahtz at oucs.ox.ac.uk  Fri Jan 27 06:27:26 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Fri, 27 Jan 2012 11:27:26 +0000
Subject: [tei-council] Redundant note in <exemplum>
In-Reply-To: <4F2288FA.3070405@kcl.ac.uk>
References: <4F2288FA.3070405@kcl.ac.uk>
Message-ID: <2D5E2DDD-9E07-4EA8-B9FA-BEC64A60E141@oucs.ox.ac.uk>


On 27 Jan 2012, at 11:22, Gabriel Bodard wrote:

> As far as I can see, the note at the bottom of the page 
> <http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-exemplum.html> 
> must date from when these elements were in SGML, since it warns coders 
> to use an explicit end-tag, which has long been required for all 
> elements in XML anyway.
> 
> Any objection if I just delete this note from the source?



+1 (or is it -1?) to agree with you
--
Stormageddon Rahtz      
Head of Information and Support Group
Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431

S?lo le pido a Dios
que el futuro no me sea indiferente


From James.Cummings at oucs.ox.ac.uk  Fri Jan 27 06:27:30 2012
From: James.Cummings at oucs.ox.ac.uk (James Cummings)
Date: Fri, 27 Jan 2012 11:27:30 +0000
Subject: [tei-council] Redundant note in <exemplum>
In-Reply-To: <4F2288FA.3070405@kcl.ac.uk>
References: <4F2288FA.3070405@kcl.ac.uk>
Message-ID: <4F228A22.8090502@oucs.ox.ac.uk>

On 27/01/12 11:22, Gabriel Bodard wrote:
> As far as I can see, the note at the bottom of the page
> <http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-exemplum.html>
> must date from when these elements were in SGML, since it warns coders
> to use an explicit end-tag, which has long been required for all
> elements in XML anyway.
>
> Any objection if I just delete this note from the source?

That seems reasonable to me.

-James


-- 
Dr James Cummings, InfoDev,
Computing Services, University of Oxford

From gabriel.bodard at kcl.ac.uk  Fri Jan 27 06:39:50 2012
From: gabriel.bodard at kcl.ac.uk (Gabriel Bodard)
Date: Fri, 27 Jan 2012 11:39:50 +0000
Subject: [tei-council] Redundant note in <exemplum>
In-Reply-To: <4F228A22.8090502@oucs.ox.ac.uk>
References: <4F2288FA.3070405@kcl.ac.uk> <4F228A22.8090502@oucs.ox.ac.uk>
Message-ID: <4F228D06.3060201@kcl.ac.uk>

There's also a commented out section in here:

<!-- OK wise guy, so how *do* I get this example tagged legal? -->
     <!-- Make the enclosing CDATA marked section RCDATA           -->
     <!-- instead, and use &nil; inside the embedded msc (]]>) to  -->
     <!-- keep the parser from recognizing the msc.  Nothing       -->
     <!-- needs to be done about the embedded CDATA marked         -->
     <!-- section opener, since it will be ignored within an       -->
     <!-- RCDATA marked section. (msm)                             -->

Can anyone make head or tail of that? Delete it? Act on it? Or what?

I guess the question is, is the CDATA section in the <eg> supposed to be 
visible? Otherwise, I'm not sure this example expresses very well how 
<eg> is different from <egXML>...

G

On 2012-01-27 11:27, James Cummings wrote:
> On 27/01/12 11:22, Gabriel Bodard wrote:
>> As far as I can see, the note at the bottom of the page
>> <http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-exemplum.html>
>> must date from when these elements were in SGML, since it warns coders
>> to use an explicit end-tag, which has long been required for all
>> elements in XML anyway.
>>
>> Any objection if I just delete this note from the source?
>
> That seems reasonable to me.
>
> -James
>
>

-- 
Dr Gabriel BODARD
(Research Associate in Digital Epigraphy)

Department of Digital Humanities
King's College London
26-29 Drury Lane
London WC2B 5RL

Email: gabriel.bodard at kcl.ac.uk
Tel: +44 (0)20 7848 1388
Fax: +44 (0)20 7848 2980

http://www.digitalclassicist.org/
http://www.currentepigraphy.org/

From sebastian.rahtz at oucs.ox.ac.uk  Fri Jan 27 07:12:43 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Fri, 27 Jan 2012 12:12:43 +0000
Subject: [tei-council] Redundant note in <exemplum>
In-Reply-To: <4F228D06.3060201@kcl.ac.uk>
References: <4F2288FA.3070405@kcl.ac.uk> <4F228A22.8090502@oucs.ox.ac.uk>
	<4F228D06.3060201@kcl.ac.uk>
Message-ID: <FC4A2E2C-FE6F-428F-9E30-7637A09D1D3C@oucs.ox.ac.uk>

i think you can kill that archaeological artefact,
entertaining as it is. it relates to SGML.
--
Stormageddon Rahtz      
Head of Information and Support Group
Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431

S?lo le pido a Dios
que el futuro no me sea indiferente


From rwelzenbach at gmail.com  Fri Jan 27 12:38:22 2012
From: rwelzenbach at gmail.com (Rebecca Welzenbach)
Date: Fri, 27 Jan 2012 12:38:22 -0500
Subject: [tei-council] Minor error in Guidelines
In-Reply-To: <4F21FA47.2050800@ultraslavonic.info>
References: <4F0F9F9F.3050408@gmail.com> <4F0FBAA5.2090706@uvic.ca>
	<97AE8F42-0EDB-41CC-8FE1-984EE9E495D4@oucs.ox.ac.uk>
	<4F10590C.50904@uvic.ca> <4F1059A9.1000709@retired.ox.ac.uk>
	<4F21FA47.2050800@ultraslavonic.info>
Message-ID: <CAA2irtLG+Rqeh5=buxRqog0-JRnxuwmgfGg5vWUnQKSLBmCJWQ@mail.gmail.com>

I would certainly find it valuable!

On Thu, Jan 26, 2012 at 8:13 PM, Kevin Hawkins
<kevin.s.hawkins at ultraslavonic.info> wrote:
> I'm wondering whether others feel that we should add a bit to
>
> http://www.tei-c.org/Activities/Council/Working/tcw20.xml
>
> or perhaps more properly
>
> P5/Source/Guidelines/en/style-guide.txt
>
> stating this distinction. ?There might be other things that those who
> have been editing the Guidelines keep in mind but haven't written down
> for the rest of us.
>
> Such a passage would be similar to this, which I found in tcw20 and is
> similarly prescriptive about encoding practice:
>
> ###
>
> In most chapters, the two character code is also used as a prefix for
> the @xml:id values given to each <div> element. Note that every <div>
> element carries an @xml:id value, whether or not it is actually
> referenced explicitly elewhere in the Guidelines.
>
> ###
>
> Is this worthwhile, or would none of us ever remember to consult this
> anyway?
>
> --K.
>
> On 1/13/12 11:19 AM, Lou Burnard wrote:
>> In the Guidelines, as elsewhere,
>>
>> <ref target="#foo">section foo</ref> ?means: generate a link to #foo and
>> represent it by the text "section foo".
>>
>> <ptr target="#foo"/> ?means: generate a link to #foo and represent it by
>> whatever text your processor chooses to generate
>>
>>
>>
>> On 13/01/12 16:17, Martin Holmes wrote:
>>> Could you clarify what the difference is between using<ref> ? and<ptr>
>>> in the guidelines?
>>>
>>> Cheers,
>>> Martin
>>>
>>> On 12-01-13 01:32 AM, Sebastian Rahtz wrote:
>>>>
>>>> On 13 Jan 2012, at 05:01, Martin Holmes wrote:
>>>>
>>>>> I've put in a bug report for this:
>>>>>
>>>>> <http://purl.org/TEI/BUGS/3473329>
>>>>>
>>>>> The basic problem is that in the web view of the Guidelines, figures
>>>>> within each chapter are numbered 1, 2, 3, 4 etc., but in the PDF output,
>>>>> they're numbered 11.1, 11.2, 11.3?
>>>>>
>>>> there are two issues here.
>>>>
>>>> ? ? ?a) the use of dangerous markup like "<ref target="#sleeprs">figure 4 above</ref>", which should be changed into a<ptr> ? ?to avoid this sort of problem
>>>> ? ? ?b) the different numbering schemes
>>>>
>>>> for the latter, which do we want for the Guidelines? by chapter, or sequential throughout?
>>>>
>>>> for the former, I found 3 occurrences of this, and changed them to<ptr>. am testing before committing.
>>>> --
>>>> Stormageddon Rahtz
>>>> Head of Information and Support Group
>>>> Oxford University Computing Services
>>>> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>>>>
>>>> S?lo le pido a Dios
>>>> que el futuro no me sea indiferente
>>>>
>>>
>>
> --
> tei-council mailing list
> tei-council at lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>
> PLEASE NOTE: postings to this list are publicly archived

From James.Cummings at oucs.ox.ac.uk  Tue Jan 31 10:01:50 2012
From: James.Cummings at oucs.ox.ac.uk (James Cummings)
Date: Tue, 31 Jan 2012 15:01:50 +0000
Subject: [tei-council] Next Release; Codename: GroundHog Day
In-Reply-To: <4F160E96.2010202@oucs.ox.ac.uk>
References: <48F7E21F-4B77-4865-AB90-47F6AA73ADBF@edirom.de>	<4F0F1AD5.4070101@uvic.ca>
	<4F159DC1.4010001@kcl.ac.uk> <4F160E96.2010202@oucs.ox.ac.uk>
Message-ID: <4F28025E.9050603@oucs.ox.ac.uk>


Just a reminder that any bugs, typos, corrections, and 
schema-affecting changes you've spotted in the Guidelines should 
be fixed by midnight tonight.  This gives us all of Wednesday 1st 
of Feb for proofreading and corrections of any additional typos 
we find, with an intended release by MartinH on Thursday 2 February.

Is the next release going to be 2.1.0 or 2.0.2?  Correct me if 
I'm wrong but If there have been schema-affecting changes then 
the second number is meant to increment. Have there been 
schema-affecting changes since 2.0.1?

-James

On 18/01/12 00:13, James Cummings wrote:
>
> Hi all,
>
> Since no one else has piped up, can I suggest a schedule:
>
> 31 January midnight GMT: submission deadline of significant changes
> 1 February: Whole Day for council to proofread and correct typos.
> 2nd February: Release (Codename: Groundhog Day)
>
> Since Martin asked, I suggest him as release technician.
>
> Any reasons why these dates are wholly unsuitable?
>
> -James
>
> On 17/01/12 16:11, Gabriel Bodard wrote:
>> Has there been any consensus on when 2.0.2 might be put out?
>>
>> (I ask because, if it's soon I won't both hacking the EpiDoc schema to
>> allow geo/@decl; I'll just wait for TEI to introduce it and regenerate
>> the schema properly. :-) )
>>
>> G
>>
>> On 2012-01-12 17:39, Martin Holmes wrote:
>>> Hi all,
>>>
>>> I think we need to release a 2.0.2 soon, during which we again run
>>> through the instructions, after adding the tagging instruction. Should
>>> we do a quick trawl through the tickets and decide which ones might beS
>>> polished off quickly without controversy?
>>>
>>> Can I be the one to go through the release steps this time?
>>>
>>> Cheers,
>>> Martin
>>>
>>> On 12-01-12 08:27 AM, Peter Stadler wrote:
>>>> Dear geeks again,
>>>>
>>>> again wondering: just downloaded the current release 2.0.1 from sourceforge (tei-2.0.1.zip) and the editionStmt at tei-2.0.1/xml/tei/p5subset.xml reads<edition>2.0.0 Last updated on<date when="2011-12-16">16th December 2011</date>.</edition>
>>>>
>>>> Does that mean it wasn't updated at all or is just the editionStmt wrong?
>>>>
>>>> Many thanks again
>>>> Peter
>>>>
>>>
>>
>
>


-- 
Dr James Cummings, InfoDev,
Computing Services, University of Oxford

From mholmes at uvic.ca  Tue Jan 31 11:02:56 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Tue, 31 Jan 2012 08:02:56 -0800
Subject: [tei-council] Next Release; Codename: GroundHog Day
In-Reply-To: <4F28025E.9050603@oucs.ox.ac.uk>
References: <48F7E21F-4B77-4865-AB90-47F6AA73ADBF@edirom.de>	<4F0F1AD5.4070101@uvic.ca>	<4F159DC1.4010001@kcl.ac.uk>
	<4F160E96.2010202@oucs.ox.ac.uk> <4F28025E.9050603@oucs.ox.ac.uk>
Message-ID: <4F2810B0.2020303@uvic.ca>

I think there has been at least one schema-affecting change:

------------------------------------------------------------------------
r10035 | gabrielbodard | 2012-01-12 09:54:18 -0800 (Thu, 12 Jan 2012) | 
1 line

added <geo> to att.declaring

So I guess we should be going for 2.1.0.

Cheers,
Martin


On 12-01-31 07:01 AM, James Cummings wrote:
>
> Just a reminder that any bugs, typos, corrections, and
> schema-affecting changes you've spotted in the Guidelines should
> be fixed by midnight tonight.  This gives us all of Wednesday 1st
> of Feb for proofreading and corrections of any additional typos
> we find, with an intended release by MartinH on Thursday 2 February.
>
> Is the next release going to be 2.1.0 or 2.0.2?  Correct me if
> I'm wrong but If there have been schema-affecting changes then
> the second number is meant to increment. Have there been
> schema-affecting changes since 2.0.1?
>
> -James
>
> On 18/01/12 00:13, James Cummings wrote:
>>
>> Hi all,
>>
>> Since no one else has piped up, can I suggest a schedule:
>>
>> 31 January midnight GMT: submission deadline of significant changes
>> 1 February: Whole Day for council to proofread and correct typos.
>> 2nd February: Release (Codename: Groundhog Day)
>>
>> Since Martin asked, I suggest him as release technician.
>>
>> Any reasons why these dates are wholly unsuitable?
>>
>> -James
>>
>> On 17/01/12 16:11, Gabriel Bodard wrote:
>>> Has there been any consensus on when 2.0.2 might be put out?
>>>
>>> (I ask because, if it's soon I won't both hacking the EpiDoc schema to
>>> allow geo/@decl; I'll just wait for TEI to introduce it and regenerate
>>> the schema properly. :-) )
>>>
>>> G
>>>
>>> On 2012-01-12 17:39, Martin Holmes wrote:
>>>> Hi all,
>>>>
>>>> I think we need to release a 2.0.2 soon, during which we again run
>>>> through the instructions, after adding the tagging instruction. Should
>>>> we do a quick trawl through the tickets and decide which ones might beS
>>>> polished off quickly without controversy?
>>>>
>>>> Can I be the one to go through the release steps this time?
>>>>
>>>> Cheers,
>>>> Martin
>>>>
>>>> On 12-01-12 08:27 AM, Peter Stadler wrote:
>>>>> Dear geeks again,
>>>>>
>>>>> again wondering: just downloaded the current release 2.0.1 from sourceforge (tei-2.0.1.zip) and the editionStmt at tei-2.0.1/xml/tei/p5subset.xml reads<edition>2.0.0 Last updated on<date when="2011-12-16">16th December 2011</date>.</edition>
>>>>>
>>>>> Does that mean it wasn't updated at all or is just the editionStmt wrong?
>>>>>
>>>>> Many thanks again
>>>>> Peter
>>>>>
>>>>
>>>
>>
>>
>
>

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From mholmes at uvic.ca  Tue Jan 31 11:56:17 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Tue, 31 Jan 2012 08:56:17 -0800
Subject: [tei-council] Use of @cRef
Message-ID: <4F281D31.5020206@uvic.ca>

Hi all,

The attribute @cRef (which appears on <ref>, <ptr>, <gloss> and <term>) 
is currently a bit of a mess. I've started a bug for this:

<http://purl.org/TEI/BUGS/3480650>

Changes have to be made to @cRef -- for one thing, the attribute is 
separately defined for each element, with different datatypes. It has 
been suggested that we no longer actually need it, because its original 
function (storing a canonical reference from a scheme defined in a 
<refsDecl> element in the TEI header) can perfectly well be handled 
using @target, using a private URI scheme. However, it's arguable that 
having an attribute whose purpose is explicitly to handle private URI 
schemes (as opposed to official IANA-registered schemes) might be 
useful. If we were to switch to recommending @target and private URI 
schemes, I think we'd have to encourage people to provide resolution 
patterns for such schemes as we currently do with @cRef.

It would be helpful to get a sense of what people are currently doing 
with @cRef, and how changes are likely to affect existing projects. I 
thought about a little survey we could circulate to TEI-L -- something 
like this:

<http://www.surveymonkey.com/s.aspx?PREVIEW_MODE=DO_NOT_USE_THIS_LINK_FOR_COLLECTION&sm=Fpob1swo7qmZTEW4PbIxL9EDe24HTX6Wad91ehsQajc%3d>

What do you think about this? (Assuming you can see the survey -- I'm 
not sure exactly how SurveyMonkey works in this regard, never having 
used it before. If you can't see it, let me know and I'll copy/paste the 
questions into an email.)

I'd like to make some decisions about @cRef at the April meeting if 
that's possible, so a bit of prep now seems like a good idea.

Cheers,
Martin
-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From gabriel.bodard at kcl.ac.uk  Tue Jan 31 12:28:01 2012
From: gabriel.bodard at kcl.ac.uk (Gabriel Bodard)
Date: Tue, 31 Jan 2012 17:28:01 +0000
Subject: [tei-council] Next Release; Codename: GroundHog Day
In-Reply-To: <4F2810B0.2020303@uvic.ca>
References: <48F7E21F-4B77-4865-AB90-47F6AA73ADBF@edirom.de>
	<4F0F1AD5.4070101@uvic.ca>	<4F159DC1.4010001@kcl.ac.uk>
	<4F160E96.2010202@oucs.ox.ac.uk>
	<4F28025E.9050603@oucs.ox.ac.uk> <4F2810B0.2020303@uvic.ca>
Message-ID: <4F2824A1.3060001@kcl.ac.uk>

I have no strong feelings either way, but my understanding was that it 
was argued the addition of geo to att.declaring was an obvious bug-fix, 
and so shouldn't require a 2.1. (If I'm mistaken, or even if I'm correct 
but people disagree with this argument, then go ahead and name it 2.1.0.)

G

On 2012-01-31 16:02, Martin Holmes wrote:
> I think there has been at least one schema-affecting change:
>
> ------------------------------------------------------------------------
> r10035 | gabrielbodard | 2012-01-12 09:54:18 -0800 (Thu, 12 Jan 2012) |
> 1 line
>
> added<geo>  to att.declaring
>
> So I guess we should be going for 2.1.0.
>
> Cheers,
> Martin
>
>
> On 12-01-31 07:01 AM, James Cummings wrote:
>>
>> Just a reminder that any bugs, typos, corrections, and
>> schema-affecting changes you've spotted in the Guidelines should
>> be fixed by midnight tonight.  This gives us all of Wednesday 1st
>> of Feb for proofreading and corrections of any additional typos
>> we find, with an intended release by MartinH on Thursday 2 February.
>>
>> Is the next release going to be 2.1.0 or 2.0.2?  Correct me if
>> I'm wrong but If there have been schema-affecting changes then
>> the second number is meant to increment. Have there been
>> schema-affecting changes since 2.0.1?
>>
>> -James
>>
>> On 18/01/12 00:13, James Cummings wrote:
>>>
>>> Hi all,
>>>
>>> Since no one else has piped up, can I suggest a schedule:
>>>
>>> 31 January midnight GMT: submission deadline of significant changes
>>> 1 February: Whole Day for council to proofread and correct typos.
>>> 2nd February: Release (Codename: Groundhog Day)
>>>
>>> Since Martin asked, I suggest him as release technician.
>>>
>>> Any reasons why these dates are wholly unsuitable?
>>>
>>> -James
>>>
>>> On 17/01/12 16:11, Gabriel Bodard wrote:
>>>> Has there been any consensus on when 2.0.2 might be put out?
>>>>
>>>> (I ask because, if it's soon I won't both hacking the EpiDoc schema to
>>>> allow geo/@decl; I'll just wait for TEI to introduce it and regenerate
>>>> the schema properly. :-) )
>>>>
>>>> G
>>>>
>>>> On 2012-01-12 17:39, Martin Holmes wrote:
>>>>> Hi all,
>>>>>
>>>>> I think we need to release a 2.0.2 soon, during which we again run
>>>>> through the instructions, after adding the tagging instruction. Should
>>>>> we do a quick trawl through the tickets and decide which ones might beS
>>>>> polished off quickly without controversy?
>>>>>
>>>>> Can I be the one to go through the release steps this time?
>>>>>
>>>>> Cheers,
>>>>> Martin
>>>>>
>>>>> On 12-01-12 08:27 AM, Peter Stadler wrote:
>>>>>> Dear geeks again,
>>>>>>
>>>>>> again wondering: just downloaded the current release 2.0.1 from sourceforge (tei-2.0.1.zip) and the editionStmt at tei-2.0.1/xml/tei/p5subset.xml reads<edition>2.0.0 Last updated on<date when="2011-12-16">16th December 2011</date>.</edition>
>>>>>>
>>>>>> Does that mean it wasn't updated at all or is just the editionStmt wrong?
>>>>>>
>>>>>> Many thanks again
>>>>>> Peter
>>>>>>
>>>>>
>>>>
>>>
>>>
>>
>>
>

-- 
Dr Gabriel BODARD
(Research Associate in Digital Epigraphy)

Department of Digital Humanities
King's College London
26-29 Drury Lane
London WC2B 5RL

Email: gabriel.bodard at kcl.ac.uk
Tel: +44 (0)20 7848 1388
Fax: +44 (0)20 7848 2980

http://www.digitalclassicist.org/
http://www.currentepigraphy.org/

From sebastian.rahtz at oucs.ox.ac.uk  Wed Feb  1 05:10:25 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Wed, 1 Feb 2012 10:10:25 +0000
Subject: [tei-council] Use of @cRef
In-Reply-To: <4F281D31.5020206@uvic.ca>
References: <4F281D31.5020206@uvic.ca>
Message-ID: <E5A1331B-9388-4799-9704-24187546EBEA@oucs.ox.ac.uk>

I like the idea of the survey; my working assumption is that we only flush out 3 people using cRef,
and it'll turn out they still use P4 anyway :-}

I have commented on ticket
--
Stormageddon Rahtz      
Head of Information and Support Group
Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431

S?lo le pido a Dios
que el futuro no me sea indiferente


From James.Cummings at oucs.ox.ac.uk  Wed Feb  1 05:21:02 2012
From: James.Cummings at oucs.ox.ac.uk (James Cummings)
Date: Wed, 01 Feb 2012 10:21:02 +0000
Subject: [tei-council] Use of @cRef
In-Reply-To: <4F281D31.5020206@uvic.ca>
References: <4F281D31.5020206@uvic.ca>
Message-ID: <4F29120E.5090603@oucs.ox.ac.uk>


I like the survey, but should it be explained that data.pointer 
can take a URI of the form foo:blort etc?  i.e. that their @cRefs 
probably can be easily represented as pointers?

-James


On 31/01/12 16:56, Martin Holmes wrote:
> Hi all,
>
> The attribute @cRef (which appears on<ref>,<ptr>,<gloss>  and<term>)
> is currently a bit of a mess. I've started a bug for this:
>
> <http://purl.org/TEI/BUGS/3480650>
>
> Changes have to be made to @cRef -- for one thing, the attribute is
> separately defined for each element, with different datatypes. It has
> been suggested that we no longer actually need it, because its original
> function (storing a canonical reference from a scheme defined in a
> <refsDecl>  element in the TEI header) can perfectly well be handled
> using @target, using a private URI scheme. However, it's arguable that
> having an attribute whose purpose is explicitly to handle private URI
> schemes (as opposed to official IANA-registered schemes) might be
> useful. If we were to switch to recommending @target and private URI
> schemes, I think we'd have to encourage people to provide resolution
> patterns for such schemes as we currently do with @cRef.
>
> It would be helpful to get a sense of what people are currently doing
> with @cRef, and how changes are likely to affect existing projects. I
> thought about a little survey we could circulate to TEI-L -- something
> like this:
>
> <http://www.surveymonkey.com/s.aspx?PREVIEW_MODE=DO_NOT_USE_THIS_LINK_FOR_COLLECTION&sm=Fpob1swo7qmZTEW4PbIxL9EDe24HTX6Wad91ehsQajc%3d>
>
> What do you think about this? (Assuming you can see the survey -- I'm
> not sure exactly how SurveyMonkey works in this regard, never having
> used it before. If you can't see it, let me know and I'll copy/paste the
> questions into an email.)
>
> I'd like to make some decisions about @cRef at the April meeting if
> that's possible, so a bit of prep now seems like a good idea.
>
> Cheers,
> Martin


-- 
Dr James Cummings, InfoDev,
Computing Services, University of Oxford

From James.Cummings at oucs.ox.ac.uk  Wed Feb  1 07:48:56 2012
From: James.Cummings at oucs.ox.ac.uk (James Cummings)
Date: Wed, 01 Feb 2012 12:48:56 +0000
Subject: [tei-council] Next Release; Codename: GroundHog Day
In-Reply-To: <4F2824A1.3060001@kcl.ac.uk>
References: <48F7E21F-4B77-4865-AB90-47F6AA73ADBF@edirom.de>	<4F0F1AD5.4070101@uvic.ca>	<4F159DC1.4010001@kcl.ac.uk>	<4F160E96.2010202@oucs.ox.ac.uk>	<4F28025E.9050603@oucs.ox.ac.uk>
	<4F2810B0.2020303@uvic.ca> <4F2824A1.3060001@kcl.ac.uk>
Message-ID: <4F2934B8.9080108@oucs.ox.ac.uk>


A reminder that we are meant to be proofreading the release 
today. So have a look at
http://teijenkins.hcmc.uvic.ca:8080/job/TEIP5-Documentation/ws/
and
http://teijenkins.hcmc.uvic.ca:8080/job/TEIP5-Documentation/ws/Guidelines-web/en/html/index.html

And point out anything (except for version and date) which are 
wrong.  If you are able to and believe it is a corrigible error 
then go and fix it and commit them by midnight tonight. 
Otherwise comment to the list for someone else to do so.

If you can each spend an hour or so today looking at it, 
hopefully will pick up some additional errors.

-James

On 31/01/12 17:28, Gabriel Bodard wrote:
> I have no strong feelings either way, but my understanding was that it
> was argued the addition of geo to att.declaring was an obvious bug-fix,
> and so shouldn't require a 2.1. (If I'm mistaken, or even if I'm correct
> but people disagree with this argument, then go ahead and name it 2.1.0.)
>
> G
>
> On 2012-01-31 16:02, Martin Holmes wrote:
>> I think there has been at least one schema-affecting change:
>>
>> ------------------------------------------------------------------------
>> r10035 | gabrielbodard | 2012-01-12 09:54:18 -0800 (Thu, 12 Jan 2012) |
>> 1 line
>>
>> added<geo>   to att.declaring
>>
>> So I guess we should be going for 2.1.0.
>>
>> Cheers,
>> Martin
>>
>>
>> On 12-01-31 07:01 AM, James Cummings wrote:
>>>
>>> Just a reminder that any bugs, typos, corrections, and
>>> schema-affecting changes you've spotted in the Guidelines should
>>> be fixed by midnight tonight.  This gives us all of Wednesday 1st
>>> of Feb for proofreading and corrections of any additional typos
>>> we find, with an intended release by MartinH on Thursday 2 February.
>>>
>>> Is the next release going to be 2.1.0 or 2.0.2?  Correct me if
>>> I'm wrong but If there have been schema-affecting changes then
>>> the second number is meant to increment. Have there been
>>> schema-affecting changes since 2.0.1?
>>>
>>> -James
>>>
>>> On 18/01/12 00:13, James Cummings wrote:
>>>>
>>>> Hi all,
>>>>
>>>> Since no one else has piped up, can I suggest a schedule:
>>>>
>>>> 31 January midnight GMT: submission deadline of significant changes
>>>> 1 February: Whole Day for council to proofread and correct typos.
>>>> 2nd February: Release (Codename: Groundhog Day)
>>>>
>>>> Since Martin asked, I suggest him as release technician.
>>>>
>>>> Any reasons why these dates are wholly unsuitable?
>>>>
>>>> -James
>>>>
>>>> On 17/01/12 16:11, Gabriel Bodard wrote:
>>>>> Has there been any consensus on when 2.0.2 might be put out?
>>>>>
>>>>> (I ask because, if it's soon I won't both hacking the EpiDoc schema to
>>>>> allow geo/@decl; I'll just wait for TEI to introduce it and regenerate
>>>>> the schema properly. :-) )
>>>>>
>>>>> G
>>>>>
>>>>> On 2012-01-12 17:39, Martin Holmes wrote:
>>>>>> Hi all,
>>>>>>
>>>>>> I think we need to release a 2.0.2 soon, during which we again run
>>>>>> through the instructions, after adding the tagging instruction. Should
>>>>>> we do a quick trawl through the tickets and decide which ones might beS
>>>>>> polished off quickly without controversy?
>>>>>>
>>>>>> Can I be the one to go through the release steps this time?
>>>>>>
>>>>>> Cheers,
>>>>>> Martin
>>>>>>
>>>>>> On 12-01-12 08:27 AM, Peter Stadler wrote:
>>>>>>> Dear geeks again,
>>>>>>>
>>>>>>> again wondering: just downloaded the current release 2.0.1 from sourceforge (tei-2.0.1.zip) and the editionStmt at tei-2.0.1/xml/tei/p5subset.xml reads<edition>2.0.0 Last updated on<date when="2011-12-16">16th December 2011</date>.</edition>
>>>>>>>
>>>>>>> Does that mean it wasn't updated at all or is just the editionStmt wrong?
>>>>>>>
>>>>>>> Many thanks again
>>>>>>> Peter
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>


-- 
Dr James Cummings, InfoDev,
Computing Services, University of Oxford

From mholmes at uvic.ca  Wed Feb  1 08:24:14 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Wed, 01 Feb 2012 05:24:14 -0800
Subject: [tei-council] Use of @cRef
In-Reply-To: <4F29120E.5090603@oucs.ox.ac.uk>
References: <4F281D31.5020206@uvic.ca> <4F29120E.5090603@oucs.ox.ac.uk>
Message-ID: <4F293CFE.8090003@uvic.ca>

I'm not sure whether I want to introduce the explanation of private URI 
schemes into the survey; it's really just trying to discover what people 
are currently doing with @cRef, and presumably nobody is using it that 
way; if they know about private URI schemes, they would naturally tend 
to put them into @target, I think.

But the issue of private URI schemes is definitely something else we 
have to deal with. Whatever we do with @cRef, I think we should be 
encouraging people using private URI schemes to provide the same sort of 
canonical resolution pattern for any private scheme used in e.g. @target 
as they would when using @cRef in the traditional way. 
@target="foo:blort" is no less cryptic than @cRef="blort". This might 
require that we review at least the name of <cRefPattern>, turning it 
into <refPattern>, <uriSchemePattern>, or something like that.

Not that I'm complying with this myself, of course. I'm guilty of using 
both @target="foo:blort" and @cRef="blort" without a <refsDecl>, and I 
should be ashamed of myself.

Cheers,
Martin

On 12-02-01 02:21 AM, James Cummings wrote:
>
> I like the survey, but should it be explained that data.pointer
> can take a URI of the form foo:blort etc?  i.e. that their @cRefs
> probably can be easily represented as pointers?
>
> -James
>
>
> On 31/01/12 16:56, Martin Holmes wrote:
>> Hi all,
>>
>> The attribute @cRef (which appears on<ref>,<ptr>,<gloss>   and<term>)
>> is currently a bit of a mess. I've started a bug for this:
>>
>> <http://purl.org/TEI/BUGS/3480650>
>>
>> Changes have to be made to @cRef -- for one thing, the attribute is
>> separately defined for each element, with different datatypes. It has
>> been suggested that we no longer actually need it, because its original
>> function (storing a canonical reference from a scheme defined in a
>> <refsDecl>   element in the TEI header) can perfectly well be handled
>> using @target, using a private URI scheme. However, it's arguable that
>> having an attribute whose purpose is explicitly to handle private URI
>> schemes (as opposed to official IANA-registered schemes) might be
>> useful. If we were to switch to recommending @target and private URI
>> schemes, I think we'd have to encourage people to provide resolution
>> patterns for such schemes as we currently do with @cRef.
>>
>> It would be helpful to get a sense of what people are currently doing
>> with @cRef, and how changes are likely to affect existing projects. I
>> thought about a little survey we could circulate to TEI-L -- something
>> like this:
>>
>> <http://www.surveymonkey.com/s.aspx?PREVIEW_MODE=DO_NOT_USE_THIS_LINK_FOR_COLLECTION&sm=Fpob1swo7qmZTEW4PbIxL9EDe24HTX6Wad91ehsQajc%3d>
>>
>> What do you think about this? (Assuming you can see the survey -- I'm
>> not sure exactly how SurveyMonkey works in this regard, never having
>> used it before. If you can't see it, let me know and I'll copy/paste the
>> questions into an email.)
>>
>> I'd like to make some decisions about @cRef at the April meeting if
>> that's possible, so a bit of prep now seems like a good idea.
>>
>> Cheers,
>> Martin
>
>

From mholmes at uvic.ca  Wed Feb  1 08:25:11 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Wed, 01 Feb 2012 05:25:11 -0800
Subject: [tei-council] Use of @cRef
In-Reply-To: <E5A1331B-9388-4799-9704-24187546EBEA@oucs.ox.ac.uk>
References: <4F281D31.5020206@uvic.ca>
	<E5A1331B-9388-4799-9704-24187546EBEA@oucs.ox.ac.uk>
Message-ID: <4F293D37.3080801@uvic.ca>

I hope you're right about the numbers, because my free account on Survey 
Monkey only allows for 100 responses to the survey. :-)

On 12-02-01 02:10 AM, Sebastian Rahtz wrote:
> I like the idea of the survey; my working assumption is that we only flush out 3 people using cRef,
> and it'll turn out they still use P4 anyway :-}
>
> I have commented on ticket
> --
> Stormageddon Rahtz
> Head of Information and Support Group
> Oxford University Computing Services
> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>
> S?lo le pido a Dios
> que el futuro no me sea indiferente
>

From kevin.s.hawkins at ultraslavonic.info  Wed Feb  1 11:30:52 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Wed, 01 Feb 2012 11:30:52 -0500
Subject: [tei-council] Use of @cRef
In-Reply-To: <4F293CFE.8090003@uvic.ca>
References: <4F281D31.5020206@uvic.ca> <4F29120E.5090603@oucs.ox.ac.uk>
	<4F293CFE.8090003@uvic.ca>
Message-ID: <4F2968BC.10908@ultraslavonic.info>

It seems to me that private URI schemes relates to the question of 
private URN schemes and the future of @key.  See:

http://sourceforge.net/tracker/index.php?func=detail&group_id=106328&atid=644065&aid=3437509

Do we dare ask about people's use of @key as well?

On 2/1/2012 8:24 AM, Martin Holmes wrote:
> I'm not sure whether I want to introduce the explanation of private URI
> schemes into the survey; it's really just trying to discover what people
> are currently doing with @cRef, and presumably nobody is using it that
> way; if they know about private URI schemes, they would naturally tend
> to put them into @target, I think.
>
> But the issue of private URI schemes is definitely something else we
> have to deal with. Whatever we do with @cRef, I think we should be
> encouraging people using private URI schemes to provide the same sort of
> canonical resolution pattern for any private scheme used in e.g. @target
> as they would when using @cRef in the traditional way.
> @target="foo:blort" is no less cryptic than @cRef="blort". This might
> require that we review at least the name of<cRefPattern>, turning it
> into<refPattern>,<uriSchemePattern>, or something like that.
>
> Not that I'm complying with this myself, of course. I'm guilty of using
> both @target="foo:blort" and @cRef="blort" without a<refsDecl>, and I
> should be ashamed of myself.
>
> Cheers,
> Martin
>
> On 12-02-01 02:21 AM, James Cummings wrote:
>>
>> I like the survey, but should it be explained that data.pointer
>> can take a URI of the form foo:blort etc?  i.e. that their @cRefs
>> probably can be easily represented as pointers?
>>
>> -James
>>
>>
>> On 31/01/12 16:56, Martin Holmes wrote:
>>> Hi all,
>>>
>>> The attribute @cRef (which appears on<ref>,<ptr>,<gloss>    and<term>)
>>> is currently a bit of a mess. I've started a bug for this:
>>>
>>> <http://purl.org/TEI/BUGS/3480650>
>>>
>>> Changes have to be made to @cRef -- for one thing, the attribute is
>>> separately defined for each element, with different datatypes. It has
>>> been suggested that we no longer actually need it, because its original
>>> function (storing a canonical reference from a scheme defined in a
>>> <refsDecl>    element in the TEI header) can perfectly well be handled
>>> using @target, using a private URI scheme. However, it's arguable that
>>> having an attribute whose purpose is explicitly to handle private URI
>>> schemes (as opposed to official IANA-registered schemes) might be
>>> useful. If we were to switch to recommending @target and private URI
>>> schemes, I think we'd have to encourage people to provide resolution
>>> patterns for such schemes as we currently do with @cRef.
>>>
>>> It would be helpful to get a sense of what people are currently doing
>>> with @cRef, and how changes are likely to affect existing projects. I
>>> thought about a little survey we could circulate to TEI-L -- something
>>> like this:
>>>
>>> <http://www.surveymonkey.com/s.aspx?PREVIEW_MODE=DO_NOT_USE_THIS_LINK_FOR_COLLECTION&sm=Fpob1swo7qmZTEW4PbIxL9EDe24HTX6Wad91ehsQajc%3d>
>>>
>>> What do you think about this? (Assuming you can see the survey -- I'm
>>> not sure exactly how SurveyMonkey works in this regard, never having
>>> used it before. If you can't see it, let me know and I'll copy/paste the
>>> questions into an email.)
>>>
>>> I'd like to make some decisions about @cRef at the April meeting if
>>> that's possible, so a bit of prep now seems like a good idea.
>>>
>>> Cheers,
>>> Martin
>>
>>

From mholmes at uvic.ca  Wed Feb  1 12:20:57 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Wed, 1 Feb 2012 09:20:57 -0800
Subject: [tei-council] Use of @cRef
In-Reply-To: <4F2968BC.10908@ultraslavonic.info>
References: <4F281D31.5020206@uvic.ca>
	<4F29120E.5090603@oucs.ox.ac.uk>	<4F293CFE.8090003@uvic.ca>
	<4F2968BC.10908@ultraslavonic.info>
Message-ID: <4F297479.4000109@uvic.ca>

That's a great point. I knew there was something else bearing on this 
issue, but I couldn't recall what it was.

It might be good to handle the two attributes separately, because if as 
Stormy and I suspect hardly anyone is using @cRef, we might be able to 
quietly remove it without much fuss; @key is not like that, though. 
Also, if the process of removing @cRef (or deprecating it) forces us to 
create a proper strategy and documentation for the use of private URI 
schemes, then we'll be in a better position when we come to deal with @key.

Cheers,
Martin

On 12-02-01 08:30 AM, Kevin Hawkins wrote:
> It seems to me that private URI schemes relates to the question of
> private URN schemes and the future of @key.  See:
>
> http://sourceforge.net/tracker/index.php?func=detail&group_id=106328&atid=644065&aid=3437509
>
> Do we dare ask about people's use of @key as well?
>
> On 2/1/2012 8:24 AM, Martin Holmes wrote:
>> I'm not sure whether I want to introduce the explanation of private URI
>> schemes into the survey; it's really just trying to discover what people
>> are currently doing with @cRef, and presumably nobody is using it that
>> way; if they know about private URI schemes, they would naturally tend
>> to put them into @target, I think.
>>
>> But the issue of private URI schemes is definitely something else we
>> have to deal with. Whatever we do with @cRef, I think we should be
>> encouraging people using private URI schemes to provide the same sort of
>> canonical resolution pattern for any private scheme used in e.g. @target
>> as they would when using @cRef in the traditional way.
>> @target="foo:blort" is no less cryptic than @cRef="blort". This might
>> require that we review at least the name of<cRefPattern>, turning it
>> into<refPattern>,<uriSchemePattern>, or something like that.
>>
>> Not that I'm complying with this myself, of course. I'm guilty of using
>> both @target="foo:blort" and @cRef="blort" without a<refsDecl>, and I
>> should be ashamed of myself.
>>
>> Cheers,
>> Martin
>>
>> On 12-02-01 02:21 AM, James Cummings wrote:
>>>
>>> I like the survey, but should it be explained that data.pointer
>>> can take a URI of the form foo:blort etc?  i.e. that their @cRefs
>>> probably can be easily represented as pointers?
>>>
>>> -James
>>>
>>>
>>> On 31/01/12 16:56, Martin Holmes wrote:
>>>> Hi all,
>>>>
>>>> The attribute @cRef (which appears on<ref>,<ptr>,<gloss>     and<term>)
>>>> is currently a bit of a mess. I've started a bug for this:
>>>>
>>>> <http://purl.org/TEI/BUGS/3480650>
>>>>
>>>> Changes have to be made to @cRef -- for one thing, the attribute is
>>>> separately defined for each element, with different datatypes. It has
>>>> been suggested that we no longer actually need it, because its original
>>>> function (storing a canonical reference from a scheme defined in a
>>>> <refsDecl>     element in the TEI header) can perfectly well be handled
>>>> using @target, using a private URI scheme. However, it's arguable that
>>>> having an attribute whose purpose is explicitly to handle private URI
>>>> schemes (as opposed to official IANA-registered schemes) might be
>>>> useful. If we were to switch to recommending @target and private URI
>>>> schemes, I think we'd have to encourage people to provide resolution
>>>> patterns for such schemes as we currently do with @cRef.
>>>>
>>>> It would be helpful to get a sense of what people are currently doing
>>>> with @cRef, and how changes are likely to affect existing projects. I
>>>> thought about a little survey we could circulate to TEI-L -- something
>>>> like this:
>>>>
>>>> <http://www.surveymonkey.com/s.aspx?PREVIEW_MODE=DO_NOT_USE_THIS_LINK_FOR_COLLECTION&sm=Fpob1swo7qmZTEW4PbIxL9EDe24HTX6Wad91ehsQajc%3d>
>>>>
>>>> What do you think about this? (Assuming you can see the survey -- I'm
>>>> not sure exactly how SurveyMonkey works in this regard, never having
>>>> used it before. If you can't see it, let me know and I'll copy/paste the
>>>> questions into an email.)
>>>>
>>>> I'd like to make some decisions about @cRef at the April meeting if
>>>> that's possible, so a bit of prep now seems like a good idea.
>>>>
>>>> Cheers,
>>>> Martin
>>>
>>>

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From mholmes at uvic.ca  Wed Feb  1 12:32:39 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Wed, 1 Feb 2012 09:32:39 -0800
Subject: [tei-council] Release notes for the new release
Message-ID: <4F297737.5030208@uvic.ca>

HI all,

We're winding up for a release tomorrow, and there are a couple of 
things I'd like to confirm:

1. We've decided, haven't we, that this release should be 2.0.2, not 
2.1.0, because there are no schema-busting changes?

2. I've been looking at the readme/release notes. For 2.0.1, James did this:

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

That seems a good policy to me, and I propose to do the same thing, 
although I will trawl through the svn logs after 2.0.1 to identify 
anything I think is worthy of mention (adding <geo> to att.declaring is 
one thing that I think should be there). Is there anything else anyone 
would like to see in the release notes?

Cheers,
Martin
-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From James.Cummings at oucs.ox.ac.uk  Wed Feb  1 17:39:55 2012
From: James.Cummings at oucs.ox.ac.uk (James Cummings)
Date: Wed, 01 Feb 2012 22:39:55 +0000
Subject: [tei-council] nym/@parts
Message-ID: <4F29BF3B.7020109@oucs.ox.ac.uk>


Hiya,

In reading through things (and correcting non-schema things 
relating to an old bug assigned to me) I happened to notice:

http://teijenkins.hcmc.uvic.ca:8080/job/TEIP5-Documentation/ws/Guidelines-web/en/html/ref-nym.html

The @parts attribute on <nym> is limited to 1 - 100 occurrences 
of data.pointer.  Although I can't picture a good use case for 
more than 50 myself... there are plenty of places where we allow 
1 - infinity pointers as an attribute value.  Why are we so 
specific that there can't be more than 100 on nym/@part in specific?

I ask this in full knowledge that I have hazy recollection of 
being part of the working group that introduced <nym>, but no 
recollection of the seemingly arbitrary limit in itself.

Just curious,

-James

-- 
Dr James Cummings, InfoDev,
Computing Services, University of Oxford

From mholmes at uvic.ca  Wed Feb  1 18:06:40 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Wed, 1 Feb 2012 15:06:40 -0800
Subject: [tei-council] nym/@parts
In-Reply-To: <4F29BF3B.7020109@oucs.ox.ac.uk>
References: <4F29BF3B.7020109@oucs.ox.ac.uk>
Message-ID: <4F29C580.5060208@uvic.ca>

At first I thought it must be a typo -- someone copying from 
one-to-infinity on another attribute and misreading it as 1-100 -- but 
SVN says different:

------------------------------------------------------------------------
r2418 | louburnard | 2007-05-07 14:36:57 -0700 (Mon, 07 May 2007) | 2 lines

removing @old on handShift; allowing up to 100 targets for nym at parts


Lou, do you remember why?

Cheers,
Martin

On 12-02-01 02:39 PM, James Cummings wrote:
>
> Hiya,
>
> In reading through things (and correcting non-schema things
> relating to an old bug assigned to me) I happened to notice:
>
> http://teijenkins.hcmc.uvic.ca:8080/job/TEIP5-Documentation/ws/Guidelines-web/en/html/ref-nym.html
>
> The @parts attribute on<nym>  is limited to 1 - 100 occurrences
> of data.pointer.  Although I can't picture a good use case for
> more than 50 myself... there are plenty of places where we allow
> 1 - infinity pointers as an attribute value.  Why are we so
> specific that there can't be more than 100 on nym/@part in specific?
>
> I ask this in full knowledge that I have hazy recollection of
> being part of the working group that introduced<nym>, but no
> recollection of the seemingly arbitrary limit in itself.
>
> Just curious,
>
> -James
>

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From lou.burnard at retired.ox.ac.uk  Wed Feb  1 18:31:32 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Wed, 01 Feb 2012 23:31:32 +0000
Subject: [tei-council] nym/@parts
In-Reply-To: <4F29C580.5060208@uvic.ca>
References: <4F29BF3B.7020109@oucs.ox.ac.uk> <4F29C580.5060208@uvic.ca>
Message-ID: <4F29CB54.1030109@retired.ox.ac.uk>

Nope, don't remember why. Presumably someone thought, not implausibly, 
that allowing more than 100 values was rather silly, as James suggests.


On 01/02/12 23:06, Martin Holmes wrote:
> At first I thought it must be a typo -- someone copying from
> one-to-infinity on another attribute and misreading it as 1-100 -- but
> SVN says different:
>
> ------------------------------------------------------------------------
> r2418 | louburnard | 2007-05-07 14:36:57 -0700 (Mon, 07 May 2007) | 2 lines
>
> removing @old on handShift; allowing up to 100 targets for nym at parts
>
>
> Lou, do you remember why?
>
> Cheers,
> Martin
>
> On 12-02-01 02:39 PM, James Cummings wrote:
>>
>> Hiya,
>>
>> In reading through things (and correcting non-schema things
>> relating to an old bug assigned to me) I happened to notice:
>>
>> http://teijenkins.hcmc.uvic.ca:8080/job/TEIP5-Documentation/ws/Guidelines-web/en/html/ref-nym.html
>>
>> The @parts attribute on<nym>   is limited to 1 - 100 occurrences
>> of data.pointer.  Although I can't picture a good use case for
>> more than 50 myself... there are plenty of places where we allow
>> 1 - infinity pointers as an attribute value.  Why are we so
>> specific that there can't be more than 100 on nym/@part in specific?
>>
>> I ask this in full knowledge that I have hazy recollection of
>> being part of the working group that introduced<nym>, but no
>> recollection of the seemingly arbitrary limit in itself.
>>
>> Just curious,
>>
>> -James
>>
>


From mholmes at uvic.ca  Wed Feb  1 18:43:49 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Wed, 1 Feb 2012 15:43:49 -0800
Subject: [tei-council] nym/@parts
In-Reply-To: <4F29CB54.1030109@retired.ox.ac.uk>
References: <4F29BF3B.7020109@oucs.ox.ac.uk> <4F29C580.5060208@uvic.ca>
	<4F29CB54.1030109@retired.ox.ac.uk>
Message-ID: <4F29CE35.60307@uvic.ca>

As a general rule, whenever you create a fixed array of a size you think 
is more than anyone could need, a need immediately arises for more. 
One-to-infinite is easier than explaining why a limit exists at all. I 
vote for change.

Cheers,
Martin

On 12-02-01 03:31 PM, Lou Burnard wrote:
> Nope, don't remember why. Presumably someone thought, not implausibly,
> that allowing more than 100 values was rather silly, as James suggests.
>
>
> On 01/02/12 23:06, Martin Holmes wrote:
>> At first I thought it must be a typo -- someone copying from
>> one-to-infinity on another attribute and misreading it as 1-100 -- but
>> SVN says different:
>>
>> ------------------------------------------------------------------------
>> r2418 | louburnard | 2007-05-07 14:36:57 -0700 (Mon, 07 May 2007) | 2 lines
>>
>> removing @old on handShift; allowing up to 100 targets for nym at parts
>>
>>
>> Lou, do you remember why?
>>
>> Cheers,
>> Martin
>>
>> On 12-02-01 02:39 PM, James Cummings wrote:
>>>
>>> Hiya,
>>>
>>> In reading through things (and correcting non-schema things
>>> relating to an old bug assigned to me) I happened to notice:
>>>
>>> http://teijenkins.hcmc.uvic.ca:8080/job/TEIP5-Documentation/ws/Guidelines-web/en/html/ref-nym.html
>>>
>>> The @parts attribute on<nym>    is limited to 1 - 100 occurrences
>>> of data.pointer.  Although I can't picture a good use case for
>>> more than 50 myself... there are plenty of places where we allow
>>> 1 - infinity pointers as an attribute value.  Why are we so
>>> specific that there can't be more than 100 on nym/@part in specific?
>>>
>>> I ask this in full knowledge that I have hazy recollection of
>>> being part of the working group that introduced<nym>, but no
>>> recollection of the seemingly arbitrary limit in itself.
>>>
>>> Just curious,
>>>
>>> -James
>>>
>>
>

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From kevin.s.hawkins at ultraslavonic.info  Wed Feb  1 18:44:58 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Wed, 01 Feb 2012 18:44:58 -0500
Subject: [tei-council] nym/@parts
In-Reply-To: <4F29CE35.60307@uvic.ca>
References: <4F29BF3B.7020109@oucs.ox.ac.uk> <4F29C580.5060208@uvic.ca>
	<4F29CB54.1030109@retired.ox.ac.uk> <4F29CE35.60307@uvic.ca>
Message-ID: <4F29CE7A.2090805@ultraslavonic.info>

+1

On 2/1/12 6:43 PM, Martin Holmes wrote:
> As a general rule, whenever you create a fixed array of a size you think
> is more than anyone could need, a need immediately arises for more.
> One-to-infinite is easier than explaining why a limit exists at all. I
> vote for change.
>
> Cheers,
> Martin
>
> On 12-02-01 03:31 PM, Lou Burnard wrote:
>> Nope, don't remember why. Presumably someone thought, not implausibly,
>> that allowing more than 100 values was rather silly, as James suggests.
>>
>>
>> On 01/02/12 23:06, Martin Holmes wrote:
>>> At first I thought it must be a typo -- someone copying from
>>> one-to-infinity on another attribute and misreading it as 1-100 -- but
>>> SVN says different:
>>>
>>> ------------------------------------------------------------------------
>>> r2418 | louburnard | 2007-05-07 14:36:57 -0700 (Mon, 07 May 2007) | 2 lines
>>>
>>> removing @old on handShift; allowing up to 100 targets for nym at parts
>>>
>>>
>>> Lou, do you remember why?
>>>
>>> Cheers,
>>> Martin
>>>
>>> On 12-02-01 02:39 PM, James Cummings wrote:
>>>>
>>>> Hiya,
>>>>
>>>> In reading through things (and correcting non-schema things
>>>> relating to an old bug assigned to me) I happened to notice:
>>>>
>>>> http://teijenkins.hcmc.uvic.ca:8080/job/TEIP5-Documentation/ws/Guidelines-web/en/html/ref-nym.html
>>>>
>>>> The @parts attribute on<nym>     is limited to 1 - 100 occurrences
>>>> of data.pointer.  Although I can't picture a good use case for
>>>> more than 50 myself... there are plenty of places where we allow
>>>> 1 - infinity pointers as an attribute value.  Why are we so
>>>> specific that there can't be more than 100 on nym/@part in specific?
>>>>
>>>> I ask this in full knowledge that I have hazy recollection of
>>>> being part of the working group that introduced<nym>, but no
>>>> recollection of the seemingly arbitrary limit in itself.
>>>>
>>>> Just curious,
>>>>
>>>> -James
>>>>
>>>
>>
>

From rwelzenbach at gmail.com  Wed Feb  1 23:11:59 2012
From: rwelzenbach at gmail.com (Rebecca Welzenbach)
Date: Wed, 1 Feb 2012 23:11:59 -0500
Subject: [tei-council] Next Release; Codename: GroundHog Day
In-Reply-To: <4F2934B8.9080108@oucs.ox.ac.uk>
References: <48F7E21F-4B77-4865-AB90-47F6AA73ADBF@edirom.de>
	<4F0F1AD5.4070101@uvic.ca> <4F159DC1.4010001@kcl.ac.uk>
	<4F160E96.2010202@oucs.ox.ac.uk> <4F28025E.9050603@oucs.ox.ac.uk>
	<4F2810B0.2020303@uvic.ca> <4F2824A1.3060001@kcl.ac.uk>
	<4F2934B8.9080108@oucs.ox.ac.uk>
Message-ID: <CAA2irt+60xXHQ6YfFUzf70JNzRMsnT9Y7mP9B40p04kg29gX-w@mail.gmail.com>

Hi folks,

I know I'm late--it's before midnight here, but not where the rest of
you are--but found one typo:

In 1.3.1 Attribute Classes, the sentence

"This class is however a subclass of the att.pointing class, from
which its members also inherit the attributes type and evaluate."

ought to be, I think,

"This class is however a subclass of the att.pointing class, from
which its members also inherit the attributes *target* and evaluate."

also submitted to sourceforge as a bug report.

On Wed, Feb 1, 2012 at 7:48 AM, James Cummings
<James.Cummings at oucs.ox.ac.uk> wrote:
>
> A reminder that we are meant to be proofreading the release
> today. So have a look at
> http://teijenkins.hcmc.uvic.ca:8080/job/TEIP5-Documentation/ws/
> and
> http://teijenkins.hcmc.uvic.ca:8080/job/TEIP5-Documentation/ws/Guidelines-web/en/html/index.html
>
> And point out anything (except for version and date) which are
> wrong. ?If you are able to and believe it is a corrigible error
> then go and fix it and commit them by midnight tonight.
> Otherwise comment to the list for someone else to do so.
>
> If you can each spend an hour or so today looking at it,
> hopefully will pick up some additional errors.
>
> -James
>
> On 31/01/12 17:28, Gabriel Bodard wrote:
>> I have no strong feelings either way, but my understanding was that it
>> was argued the addition of geo to att.declaring was an obvious bug-fix,
>> and so shouldn't require a 2.1. (If I'm mistaken, or even if I'm correct
>> but people disagree with this argument, then go ahead and name it 2.1.0.)
>>
>> G
>>
>> On 2012-01-31 16:02, Martin Holmes wrote:
>>> I think there has been at least one schema-affecting change:
>>>
>>> ------------------------------------------------------------------------
>>> r10035 | gabrielbodard | 2012-01-12 09:54:18 -0800 (Thu, 12 Jan 2012) |
>>> 1 line
>>>
>>> added<geo> ? to att.declaring
>>>
>>> So I guess we should be going for 2.1.0.
>>>
>>> Cheers,
>>> Martin
>>>
>>>
>>> On 12-01-31 07:01 AM, James Cummings wrote:
>>>>
>>>> Just a reminder that any bugs, typos, corrections, and
>>>> schema-affecting changes you've spotted in the Guidelines should
>>>> be fixed by midnight tonight. ?This gives us all of Wednesday 1st
>>>> of Feb for proofreading and corrections of any additional typos
>>>> we find, with an intended release by MartinH on Thursday 2 February.
>>>>
>>>> Is the next release going to be 2.1.0 or 2.0.2? ?Correct me if
>>>> I'm wrong but If there have been schema-affecting changes then
>>>> the second number is meant to increment. Have there been
>>>> schema-affecting changes since 2.0.1?
>>>>
>>>> -James
>>>>
>>>> On 18/01/12 00:13, James Cummings wrote:
>>>>>
>>>>> Hi all,
>>>>>
>>>>> Since no one else has piped up, can I suggest a schedule:
>>>>>
>>>>> 31 January midnight GMT: submission deadline of significant changes
>>>>> 1 February: Whole Day for council to proofread and correct typos.
>>>>> 2nd February: Release (Codename: Groundhog Day)
>>>>>
>>>>> Since Martin asked, I suggest him as release technician.
>>>>>
>>>>> Any reasons why these dates are wholly unsuitable?
>>>>>
>>>>> -James
>>>>>
>>>>> On 17/01/12 16:11, Gabriel Bodard wrote:
>>>>>> Has there been any consensus on when 2.0.2 might be put out?
>>>>>>
>>>>>> (I ask because, if it's soon I won't both hacking the EpiDoc schema to
>>>>>> allow geo/@decl; I'll just wait for TEI to introduce it and regenerate
>>>>>> the schema properly. :-) )
>>>>>>
>>>>>> G
>>>>>>
>>>>>> On 2012-01-12 17:39, Martin Holmes wrote:
>>>>>>> Hi all,
>>>>>>>
>>>>>>> I think we need to release a 2.0.2 soon, during which we again run
>>>>>>> through the instructions, after adding the tagging instruction. Should
>>>>>>> we do a quick trawl through the tickets and decide which ones might beS
>>>>>>> polished off quickly without controversy?
>>>>>>>
>>>>>>> Can I be the one to go through the release steps this time?
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Martin
>>>>>>>
>>>>>>> On 12-01-12 08:27 AM, Peter Stadler wrote:
>>>>>>>> Dear geeks again,
>>>>>>>>
>>>>>>>> again wondering: just downloaded the current release 2.0.1 from sourceforge (tei-2.0.1.zip) and the editionStmt at tei-2.0.1/xml/tei/p5subset.xml reads<edition>2.0.0 Last updated on<date when="2011-12-16">16th December 2011</date>.</edition>
>>>>>>>>
>>>>>>>> Does that mean it wasn't updated at all or is just the editionStmt wrong?
>>>>>>>>
>>>>>>>> Many thanks again
>>>>>>>> Peter
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>
>
> --
> Dr James Cummings, InfoDev,
> Computing Services, University of Oxford
> --
> tei-council mailing list
> tei-council at lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>
> PLEASE NOTE: postings to this list are publicly archived

From sebastian.rahtz at oucs.ox.ac.uk  Thu Feb  2 04:51:17 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Thu, 2 Feb 2012 09:51:17 +0000
Subject: [tei-council] Next Release; Codename: GroundHog Day
In-Reply-To: <CAA2irt+60xXHQ6YfFUzf70JNzRMsnT9Y7mP9B40p04kg29gX-w@mail.gmail.com>
References: <48F7E21F-4B77-4865-AB90-47F6AA73ADBF@edirom.de>
	<4F0F1AD5.4070101@uvic.ca> <4F159DC1.4010001@kcl.ac.uk>
	<4F160E96.2010202@oucs.ox.ac.uk> <4F28025E.9050603@oucs.ox.ac.uk>
	<4F2810B0.2020303@uvic.ca> <4F2824A1.3060001@kcl.ac.uk>
	<4F2934B8.9080108@oucs.ox.ac.uk>
	<CAA2irt+60xXHQ6YfFUzf70JNzRMsnT9Y7mP9B40p04kg29gX-w@mail.gmail.com>
Message-ID: <40a553c3-dcb5-4279-99a1-be8d40b2cfe9@exht04.ad.oak.ox.ac.uk>


On 2 Feb 2012, at 04:11, Rebecca Welzenbach wrote:

> In 1.3.1 Attribute Classes, the sentence
> 
> "This class is however a subclass of the att.pointing class, from
> which its members also inherit the attributes type and evaluate."
> 
> ought to be, I think,
> 
> "This class is however a subclass of the att.pointing class, from
> which its members also inherit the attributes *target* and evaluate."
> 

what I can see is "also inherit the attributes @type and @evaluate", which is how attribute
names are displayed. That's right, surely?

what rendering are you looking at?

--
Stormageddon Rahtz      
Head of Information and Support Group
Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431

S?lo le pido a Dios
que el futuro no me sea indiferente


From lou.burnard at retired.ox.ac.uk  Thu Feb  2 04:53:53 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Thu, 02 Feb 2012 09:53:53 +0000
Subject: [tei-council] Next Release; Codename: GroundHog Day
In-Reply-To: <40a553c3-dcb5-4279-99a1-be8d40b2cfe9@exht04.ad.oak.ox.ac.uk>
References: <48F7E21F-4B77-4865-AB90-47F6AA73ADBF@edirom.de>	<4F0F1AD5.4070101@uvic.ca>
	<4F159DC1.4010001@kcl.ac.uk>	<4F160E96.2010202@oucs.ox.ac.uk>
	<4F28025E.9050603@oucs.ox.ac.uk>	<4F2810B0.2020303@uvic.ca>
	<4F2824A1.3060001@kcl.ac.uk>	<4F2934B8.9080108@oucs.ox.ac.uk>	<CAA2irt+60xXHQ6YfFUzf70JNzRMsnT9Y7mP9B40p04kg29gX-w@mail.gmail.com>
	<40a553c3-dcb5-4279-99a1-be8d40b2cfe9@exht04.ad.oak.ox.ac.uk>
Message-ID: <4F2A5D31.7090002@retired.ox.ac.uk>

On 02/02/12 09:51, Sebastian Rahtz wrote:
>
> On 2 Feb 2012, at 04:11, Rebecca Welzenbach wrote:
>
>> In 1.3.1 Attribute Classes, the sentence
>>
>> "This class is however a subclass of the att.pointing class, from
>> which its members also inherit the attributes type and evaluate."
>>
>> ought to be, I think,
>>
>> "This class is however a subclass of the att.pointing class, from
>> which its members also inherit the attributes *target* and evaluate."
>>
>
> what I can see is "also inherit the attributes @type and @evaluate", which is how attribute
> names are displayed. That's right, surely?
>
> what rendering are you looking at?
>
>
I think Rebecca's point is (correctly) that @type is not inherited form 
the att.pointing class, whereas @target is. Nothing to do with the 
rendering.

Am fixing.




From sebastian.rahtz at oucs.ox.ac.uk  Thu Feb  2 04:55:03 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Thu, 2 Feb 2012 09:55:03 +0000
Subject: [tei-council] Next Release; Codename: GroundHog Day
In-Reply-To: <4F2A5D31.7090002@retired.ox.ac.uk>
References: <48F7E21F-4B77-4865-AB90-47F6AA73ADBF@edirom.de>
	<4F0F1AD5.4070101@uvic.ca>	<4F159DC1.4010001@kcl.ac.uk>
	<4F160E96.2010202@oucs.ox.ac.uk>	<4F28025E.9050603@oucs.ox.ac.uk>
	<4F2810B0.2020303@uvic.ca>	<4F2824A1.3060001@kcl.ac.uk>
	<4F2934B8.9080108@oucs.ox.ac.uk>
	<CAA2irt+60xXHQ6YfFUzf70JNzRMsnT9Y7mP9B40p04kg29gX-w@mail.gmail.com>
	<40a553c3-dcb5-4279-99a1-be8d40b2cfe9@exht04.ad.oak.ox.ac.uk>
	<4F2A5D31.7090002@retired.ox.ac.uk>
Message-ID: <CE8CCA5B-31DF-4F68-AD28-0E6213ABB475@oucs.ox.ac.uk>

>> 
> I think Rebecca's point is (correctly) that @type is not inherited form 
> the att.pointing class, whereas @target is. Nothing to do with the 
> rendering.


ah, sorry, Rebecca, was reading too fast.
--
Stormageddon Rahtz      
Head of Information and Support Group
Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431

S?lo le pido a Dios
que el futuro no me sea indiferente


From james.cummings at oucs.ox.ac.uk  Thu Feb  2 04:57:32 2012
From: james.cummings at oucs.ox.ac.uk (James Cummings)
Date: Thu, 2 Feb 2012 09:57:32 +0000
Subject: [tei-council] Next Release; Codename: GroundHog Day
Message-ID: <uh65wgv4lgkwkh22bs8spuqc.1328176381278@email.android.com>


I believe Becky is arguing that it should be target not type.

JamesC

--
James Cummings, InfoDev, OUCS, University of Oxford (via phone)

Sebastian Rahtz <sebastian.rahtz at oucs.ox.ac.uk> wrote:


On 2 Feb 2012, at 04:11, Rebecca Welzenbach wrote:

> In 1.3.1 Attribute Classes, the sentence
>
> "This class is however a subclass of the att.pointing class, from
> which its members also inherit the attributes type and evaluate."
>
> ought to be, I think,
>
> "This class is however a subclass of the att.pointing class, from
> which its members also inherit the attributes *target* and evaluate."
>

what I can see is "also inherit the attributes @type and @evaluate", which is how attribute
names are displayed. That's right, surely?

what rendering are you looking at?

--
Stormageddon Rahtz
Head of Information and Support Group
Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431

S?lo le pido a Dios
que el futuro no me sea indiferente

--
tei-council mailing list
tei-council at lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

PLEASE NOTE: postings to this list are publicly archived

From James.Cummings at oucs.ox.ac.uk  Thu Feb  2 05:14:39 2012
From: James.Cummings at oucs.ox.ac.uk (James Cummings)
Date: Thu, 02 Feb 2012 10:14:39 +0000
Subject: [tei-council] Next Release; Codename: GroundHog Day
In-Reply-To: <uh65wgv4lgkwkh22bs8spuqc.1328176381278@email.android.com>
References: <uh65wgv4lgkwkh22bs8spuqc.1328176381278@email.android.com>
Message-ID: <4F2A620F.4080201@oucs.ox.ac.uk>

On 02/02/12 09:57, James Cummings wrote:
>
> I believe Becky is arguing that it should be target not type.

And I was slower than Lou in pointing it out, and indeed fixing 
it in SVN.

On the topic of TEI Guidelines releases over the last couple days 
I've updated tcw20.xml with a list of steps for a 'release 
technician', who is the person in charge of making the release 
(in this case Martin), with a list of steps that the technician 
must ensure are completed.

Martin, Sebastian, and I have talked through some of them which 
are a bit vague at the moment (like "Ensure that the oxygen-tei 
project is updated"), but if I've left out any steps do please 
let me know (or add them to the list if you are able). We may 
break out 'How to release the TEI Guidelines' as a separate 
document from its current place in 'How to edit the TEI 
Guidelines' eventually.

As it is about 10am here that means it is about 2am in Vancouver. 
When Martin wakes up (this afternoon for my timezone) he will 
begin going through those steps.  *If* all goes smoothly then I 
*believe* that this may be the first release of TEI P5 that has 
not been pushed live by someone affiliated in some way with 
Oxford. (Correct me if I'm wrong Lou?)  If that is indeed the 
case I'd like to include it in the announcement to TEI-L as an 
indication of how the TEI is becoming increasingly a distributed 
open source project, etc.  (Not that it wasn't before but it is 
good if it is seen as such.)

-James

-- 
Dr James Cummings, InfoDev,
Computing Services, University of Oxford

From James.Cummings at oucs.ox.ac.uk  Thu Feb  2 05:33:59 2012
From: James.Cummings at oucs.ox.ac.uk (James Cummings)
Date: Thu, 02 Feb 2012 10:33:59 +0000
Subject: [tei-council] TEI Council TeleConference
Message-ID: <4F2A6697.8000409@oucs.ox.ac.uk>

Hi all,

One of the things we mentioned at our last f2f meeting was that 
we should have more regular teleconferences.

To this end I'd like to schedule on one of the 27/28/29th.

The times that are best for outliers like MartinH and StuartY I 
believe are 18:00/19:00/20:00 UTC. (Which it good for people in 
Ann Arbor, but an evening call for us in Europe.)

If everyone can fill in this doodle poll:

http://www.doodle.com/6akx9cqy2zdcbdkn

with your availability.  I've enabled 'time-zone support' so 
hopefully it should show you what those times are in your own 
location, but you may wish to double-check that at:

http://timeanddate.com/worldclock/meetingtime.html?iso=20120228&p1=136&p2=256&p3=264&p4=37&p5=77

Teleconferencing system to be decided. (John Unsworth has one he 
has been trialling and has set me up on it.)

Many thanks,

James

-- 
Dr James Cummings, InfoDev,
Computing Services, University of Oxford

From mholmes at uvic.ca  Thu Feb  2 08:17:03 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Thu, 02 Feb 2012 05:17:03 -0800
Subject: [tei-council] Next Release; Codename: GroundHog Day
In-Reply-To: <4F2A620F.4080201@oucs.ox.ac.uk>
References: <uh65wgv4lgkwkh22bs8spuqc.1328176381278@email.android.com>
	<4F2A620F.4080201@oucs.ox.ac.uk>
Message-ID: <4F2A8CCF.8080304@uvic.ca>

I'm up and beginning work on it now. I'm currently working with 
Sebastian to get my Jenkins server in sync with his, and I'm writing the 
release notes. Hoping to get those done, and VERSION updated, before 
breakfast, then during the time when I'm going to work, the Jenkins 
servers will do their thing and I'll have release packages ready by the 
time I get to the office. Then I'll carry on from there.

Cheers,
Martin

On 12-02-02 02:14 AM, James Cummings wrote:
> On 02/02/12 09:57, James Cummings wrote:
>>
>> I believe Becky is arguing that it should be target not type.
>
> And I was slower than Lou in pointing it out, and indeed fixing
> it in SVN.
>
> On the topic of TEI Guidelines releases over the last couple days
> I've updated tcw20.xml with a list of steps for a 'release
> technician', who is the person in charge of making the release
> (in this case Martin), with a list of steps that the technician
> must ensure are completed.
>
> Martin, Sebastian, and I have talked through some of them which
> are a bit vague at the moment (like "Ensure that the oxygen-tei
> project is updated"), but if I've left out any steps do please
> let me know (or add them to the list if you are able). We may
> break out 'How to release the TEI Guidelines' as a separate
> document from its current place in 'How to edit the TEI
> Guidelines' eventually.
>
> As it is about 10am here that means it is about 2am in Vancouver.
> When Martin wakes up (this afternoon for my timezone) he will
> begin going through those steps.  *If* all goes smoothly then I
> *believe* that this may be the first release of TEI P5 that has
> not been pushed live by someone affiliated in some way with
> Oxford. (Correct me if I'm wrong Lou?)  If that is indeed the
> case I'd like to include it in the announcement to TEI-L as an
> indication of how the TEI is becoming increasingly a distributed
> open source project, etc.  (Not that it wasn't before but it is
> good if it is seen as such.)
>
> -James
>

From mholmes at uvic.ca  Thu Feb  2 08:36:23 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Thu, 02 Feb 2012 05:36:23 -0800
Subject: [tei-council] Next Release; Codename: GroundHog Day
In-Reply-To: <4F2A8CCF.8080304@uvic.ca>
References: <uh65wgv4lgkwkh22bs8spuqc.1328176381278@email.android.com>	<4F2A620F.4080201@oucs.ox.ac.uk>
	<4F2A8CCF.8080304@uvic.ca>
Message-ID: <4F2A9157.1080308@uvic.ca>

OK, Jenkins is updated, and the VERSION file, readme and guidelines-* 
files have been done. Waiting for the Jinkses to do their thing. Could 
we hold off on commits for the rest of the day, just to keep things simple?

Cheers,
Martin

On 12-02-02 05:17 AM, Martin Holmes wrote:
> I'm up and beginning work on it now. I'm currently working with
> Sebastian to get my Jenkins server in sync with his, and I'm writing the
> release notes. Hoping to get those done, and VERSION updated, before
> breakfast, then during the time when I'm going to work, the Jenkins
> servers will do their thing and I'll have release packages ready by the
> time I get to the office. Then I'll carry on from there.
>
> Cheers,
> Martin
>
> On 12-02-02 02:14 AM, James Cummings wrote:
>> On 02/02/12 09:57, James Cummings wrote:
>>>
>>> I believe Becky is arguing that it should be target not type.
>>
>> And I was slower than Lou in pointing it out, and indeed fixing
>> it in SVN.
>>
>> On the topic of TEI Guidelines releases over the last couple days
>> I've updated tcw20.xml with a list of steps for a 'release
>> technician', who is the person in charge of making the release
>> (in this case Martin), with a list of steps that the technician
>> must ensure are completed.
>>
>> Martin, Sebastian, and I have talked through some of them which
>> are a bit vague at the moment (like "Ensure that the oxygen-tei
>> project is updated"), but if I've left out any steps do please
>> let me know (or add them to the list if you are able). We may
>> break out 'How to release the TEI Guidelines' as a separate
>> document from its current place in 'How to edit the TEI
>> Guidelines' eventually.
>>
>> As it is about 10am here that means it is about 2am in Vancouver.
>> When Martin wakes up (this afternoon for my timezone) he will
>> begin going through those steps.  *If* all goes smoothly then I
>> *believe* that this may be the first release of TEI P5 that has
>> not been pushed live by someone affiliated in some way with
>> Oxford. (Correct me if I'm wrong Lou?)  If that is indeed the
>> case I'd like to include it in the announcement to TEI-L as an
>> indication of how the TEI is becoming increasingly a distributed
>> open source project, etc.  (Not that it wasn't before but it is
>> good if it is seen as such.)
>>
>> -James
>>

From James.Cummings at oucs.ox.ac.uk  Thu Feb  2 08:54:00 2012
From: James.Cummings at oucs.ox.ac.uk (James Cummings)
Date: Thu, 02 Feb 2012 13:54:00 +0000
Subject: [tei-council] Next Release; Codename: GroundHog Day
In-Reply-To: <4F2A9157.1080308@uvic.ca>
References: <uh65wgv4lgkwkh22bs8spuqc.1328176381278@email.android.com>	<4F2A620F.4080201@oucs.ox.ac.uk>
	<4F2A8CCF.8080304@uvic.ca> <4F2A9157.1080308@uvic.ca>
Message-ID: <4F2A9578.3060205@oucs.ox.ac.uk>

On 02/02/12 13:36, Martin Holmes wrote:
> OK, Jenkins is updated, and the VERSION file, readme and guidelines-*
> files have been done. Waiting for the Jinkses to do their thing. Could
> we hold off on commits for the rest of the day, just to keep things simple?

For those following along a home, this is Martin doing step 4 of:

http://www.tei-c.org/Activities/Council/Working/tcw20.xml#release-steps

in announcing a temporary freeze on commits to SVN to the council 
mailing list.

(Because, of course, if you commit something, Jenkins fires off 
again and we have to wait through the entire build again.)

-James

>
> Cheers,
> Martin
>
> On 12-02-02 05:17 AM, Martin Holmes wrote:
>> I'm up and beginning work on it now. I'm currently working with
>> Sebastian to get my Jenkins server in sync with his, and I'm writing the
>> release notes. Hoping to get those done, and VERSION updated, before
>> breakfast, then during the time when I'm going to work, the Jenkins
>> servers will do their thing and I'll have release packages ready by the
>> time I get to the office. Then I'll carry on from there.
>>
>> Cheers,
>> Martin
>>
>> On 12-02-02 02:14 AM, James Cummings wrote:
>>> On 02/02/12 09:57, James Cummings wrote:
>>>>
>>>> I believe Becky is arguing that it should be target not type.
>>>
>>> And I was slower than Lou in pointing it out, and indeed fixing
>>> it in SVN.
>>>
>>> On the topic of TEI Guidelines releases over the last couple days
>>> I've updated tcw20.xml with a list of steps for a 'release
>>> technician', who is the person in charge of making the release
>>> (in this case Martin), with a list of steps that the technician
>>> must ensure are completed.
>>>
>>> Martin, Sebastian, and I have talked through some of them which
>>> are a bit vague at the moment (like "Ensure that the oxygen-tei
>>> project is updated"), but if I've left out any steps do please
>>> let me know (or add them to the list if you are able). We may
>>> break out 'How to release the TEI Guidelines' as a separate
>>> document from its current place in 'How to edit the TEI
>>> Guidelines' eventually.
>>>
>>> As it is about 10am here that means it is about 2am in Vancouver.
>>> When Martin wakes up (this afternoon for my timezone) he will
>>> begin going through those steps.  *If* all goes smoothly then I
>>> *believe* that this may be the first release of TEI P5 that has
>>> not been pushed live by someone affiliated in some way with
>>> Oxford. (Correct me if I'm wrong Lou?)  If that is indeed the
>>> case I'd like to include it in the announcement to TEI-L as an
>>> indication of how the TEI is becoming increasingly a distributed
>>> open source project, etc.  (Not that it wasn't before but it is
>>> good if it is seen as such.)
>>>
>>> -James
>>>


-- 
Dr James Cummings, InfoDev,
Computing Services, University of Oxford

From mholmes at uvic.ca  Thu Feb  2 11:00:32 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Thu, 2 Feb 2012 08:00:32 -0800
Subject: [tei-council] Next Release; Codename: GroundHog Day
In-Reply-To: <4F2A9578.3060205@oucs.ox.ac.uk>
References: <uh65wgv4lgkwkh22bs8spuqc.1328176381278@email.android.com>	<4F2A620F.4080201@oucs.ox.ac.uk>
	<4F2A8CCF.8080304@uvic.ca> <4F2A9157.1080308@uvic.ca>
	<4F2A9578.3060205@oucs.ox.ac.uk>
Message-ID: <4F2AB320.3040503@uvic.ca>

The freeze doesn't apply to fixing the error in the readme file that I 
added in step 1, of course. :-)

There will now be a short interlude while the Jinkses rebuild the broken 
documentation....

Cheers,
Martin

On 12-02-02 05:54 AM, James Cummings wrote:
> On 02/02/12 13:36, Martin Holmes wrote:
>> OK, Jenkins is updated, and the VERSION file, readme and guidelines-*
>> files have been done. Waiting for the Jinkses to do their thing. Could
>> we hold off on commits for the rest of the day, just to keep things simple?
>
> For those following along a home, this is Martin doing step 4 of:
>
> http://www.tei-c.org/Activities/Council/Working/tcw20.xml#release-steps
>
> in announcing a temporary freeze on commits to SVN to the council
> mailing list.
>
> (Because, of course, if you commit something, Jenkins fires off
> again and we have to wait through the entire build again.)
>
> -James
>
>>
>> Cheers,
>> Martin
>>
>> On 12-02-02 05:17 AM, Martin Holmes wrote:
>>> I'm up and beginning work on it now. I'm currently working with
>>> Sebastian to get my Jenkins server in sync with his, and I'm writing the
>>> release notes. Hoping to get those done, and VERSION updated, before
>>> breakfast, then during the time when I'm going to work, the Jenkins
>>> servers will do their thing and I'll have release packages ready by the
>>> time I get to the office. Then I'll carry on from there.
>>>
>>> Cheers,
>>> Martin
>>>
>>> On 12-02-02 02:14 AM, James Cummings wrote:
>>>> On 02/02/12 09:57, James Cummings wrote:
>>>>>
>>>>> I believe Becky is arguing that it should be target not type.
>>>>
>>>> And I was slower than Lou in pointing it out, and indeed fixing
>>>> it in SVN.
>>>>
>>>> On the topic of TEI Guidelines releases over the last couple days
>>>> I've updated tcw20.xml with a list of steps for a 'release
>>>> technician', who is the person in charge of making the release
>>>> (in this case Martin), with a list of steps that the technician
>>>> must ensure are completed.
>>>>
>>>> Martin, Sebastian, and I have talked through some of them which
>>>> are a bit vague at the moment (like "Ensure that the oxygen-tei
>>>> project is updated"), but if I've left out any steps do please
>>>> let me know (or add them to the list if you are able). We may
>>>> break out 'How to release the TEI Guidelines' as a separate
>>>> document from its current place in 'How to edit the TEI
>>>> Guidelines' eventually.
>>>>
>>>> As it is about 10am here that means it is about 2am in Vancouver.
>>>> When Martin wakes up (this afternoon for my timezone) he will
>>>> begin going through those steps.  *If* all goes smoothly then I
>>>> *believe* that this may be the first release of TEI P5 that has
>>>> not been pushed live by someone affiliated in some way with
>>>> Oxford. (Correct me if I'm wrong Lou?)  If that is indeed the
>>>> case I'd like to include it in the announcement to TEI-L as an
>>>> indication of how the TEI is becoming increasingly a distributed
>>>> open source project, etc.  (Not that it wasn't before but it is
>>>> good if it is seen as such.)
>>>>
>>>> -James
>>>>
>
>

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From mholmes at uvic.ca  Thu Feb  2 12:59:19 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Thu, 2 Feb 2012 09:59:19 -0800
Subject: [tei-council] Slight glitch with the release
Message-ID: <4F2ACEF7.9070706@uvic.ca>

Hi all,

Just letting everyone know we've hit a minor issue: the install script 
that grabs the newly-built release from the Jenkins server and puts it 
on the TEI site is failing to do the grabbing. I suspect this is a 
permissions issue relating to my account on the TEI server, but I'm not 
sure yet.

This sort of thing isn't entirely unexpected. One of the reasons for my 
doing this release as opposed to James or Sebastian is so we can find 
out about glitches like this, and document everything more thoroughly.

Cheers,
Martin
-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From mholmes at uvic.ca  Thu Feb  2 13:36:02 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Thu, 2 Feb 2012 10:36:02 -0800
Subject: [tei-council] So far so good, but...
Message-ID: <4F2AD792.5060508@uvic.ca>

James gave me write permission to the relevant directory, so I've been 
able to run the scripts on the server, as well as creating the SVN tag 
and setting 2.0.2 as the default download. The main TEI site now has 
2.0.2 (which I determined by checking that <geo> is a member of 
att.declaring -- there seems to be no easy way to see what version of 
the Guidelines you're looking at on the server).

I'm now at this stage:

------
Add an announcement to the SourceForge news feed

Someone with admin privileges on the SourceForge site creates an 
announcement. Make sure the announcement is categorized as "News" on 
SourceForge so that it will appear under "TEI-C News" on the TEI website.
-------

but I don't seem to have any way to post an announcement to the blog 
(which is the WordPress install on SF):

<https://sourceforge.net/apps/wordpress/tei/category/news/>

I'm still digging around, but I see no "post" button when logged in as 
martindholmes (my SF user, which is a project admin). Still working on 
this. James, do I need special permission or am I just missing the 
obvious as usual?

Cheers,
Martin
-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From dsewell at virginia.edu  Thu Feb  2 13:41:12 2012
From: dsewell at virginia.edu (David Sewell)
Date: Thu, 2 Feb 2012 13:41:12 -0500 (EST)
Subject: [tei-council] So far so good, but...
In-Reply-To: <4F2AD792.5060508@uvic.ca>
References: <4F2AD792.5060508@uvic.ca>
Message-ID: <alpine.OSX.2.00.1202021340200.2410@lister.ei.virginia.edu>

Martin, I just changed your Wordpress user role to "Editor", so try logging out 
& logging back in

On Thu, 2 Feb 2012, Martin Holmes wrote:

> James gave me write permission to the relevant directory, so I've been
> able to run the scripts on the server, as well as creating the SVN tag
> and setting 2.0.2 as the default download. The main TEI site now has
> 2.0.2 (which I determined by checking that <geo> is a member of
> att.declaring -- there seems to be no easy way to see what version of
> the Guidelines you're looking at on the server).
>
> I'm now at this stage:
>
> ------
> Add an announcement to the SourceForge news feed
>
> Someone with admin privileges on the SourceForge site creates an
> announcement. Make sure the announcement is categorized as "News" on
> SourceForge so that it will appear under "TEI-C News" on the TEI website.
> -------
>
> but I don't seem to have any way to post an announcement to the blog
> (which is the WordPress install on SF):
>
> <https://sourceforge.net/apps/wordpress/tei/category/news/>
>
> I'm still digging around, but I see no "post" button when logged in as
> martindholmes (my SF user, which is a project admin). Still working on
> this. James, do I need special permission or am I just missing the
> obvious as usual?
>
> Cheers,
> Martin
>

-- 
David Sewell, Editorial and Technical Manager
ROTUNDA, The University of Virginia Press
PO Box 400314, Charlottesville, VA 22904-4314 USA
Email: dsewell at virginia.edu   Tel: +1 434 924 9973
Web: http://rotunda.upress.virginia.edu/

From James.Cummings at oucs.ox.ac.uk  Thu Feb  2 13:49:49 2012
From: James.Cummings at oucs.ox.ac.uk (James Cummings)
Date: Thu, 02 Feb 2012 18:49:49 +0000
Subject: [tei-council] So far so good, but...
In-Reply-To: <4F2AD792.5060508@uvic.ca>
References: <4F2AD792.5060508@uvic.ca>
Message-ID: <4F2ADACD.7060109@oucs.ox.ac.uk>

On 02/02/12 18:36, Martin Holmes wrote:
> James gave me write permission to the relevant directory, so I've been
> able to run the scripts on the server, as well as creating the SVN tag
> and setting 2.0.2 as the default download. The main TEI site now has
> 2.0.2 (which I determined by checking that<geo>  is a member of
> att.declaring -- there seems to be no easy way to see what version of
> the Guidelines you're looking at on the server).

Use the footer, Luke.

-James

> I'm now at this stage:

Which is why I had step 13 be to ask the Council Chair to do this 
for you (so that not every release technician has to get SF blog 
editing permissions just to make a release). ;-)

-James
-- 
Dr James Cummings, InfoDev
Oxford University Computing Services
University of Oxford

From James.Cummings at oucs.ox.ac.uk  Thu Feb  2 14:43:19 2012
From: James.Cummings at oucs.ox.ac.uk (James Cummings)
Date: Thu, 02 Feb 2012 19:43:19 +0000
Subject: [tei-council] So far so good, but...
In-Reply-To: <4F2ADACD.7060109@oucs.ox.ac.uk>
References: <4F2AD792.5060508@uvic.ca> <4F2ADACD.7060109@oucs.ox.ac.uk>
Message-ID: <4F2AE757.3000703@oucs.ox.ac.uk>


Just to say, that aside from the slight permissions error, the 
release of TEI P5 2.0.2 seems to have gone well. Thank you Martin 
for being a Guinea Pig (Or is that Groundhog?).  People can go 
back to committing to the SVN repository! :-)

We discovered that it might be better to move the installation 
scripts on the tei-c.org machine to somewhere central (e.g. 
/home/tei/) and run them from there, and some other small 
corrections to the list of steps that Martin will add in due course.

-James

-- 
Dr James Cummings, InfoDev
Oxford University Computing Services
University of Oxford

From mholmes at uvic.ca  Thu Feb  2 14:52:43 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Thu, 2 Feb 2012 11:52:43 -0800
Subject: [tei-council] So far so good
In-Reply-To: <4F2AE757.3000703@oucs.ox.ac.uk>
References: <4F2AD792.5060508@uvic.ca> <4F2ADACD.7060109@oucs.ox.ac.uk>
	<4F2AE757.3000703@oucs.ox.ac.uk>
Message-ID: <4F2AE98B.3080901@uvic.ca>

We'll spin off the release instructions into their own page, and expand 
them with a lot more detail. As usual, what's obvious to someone who's 
done it once is not necessarily obvious to a first-timer.

Thanks to James, David, and Sebastian for necessary hand-holding. :-)

Cheers,
Martin

On 12-02-02 11:43 AM, James Cummings wrote:
>
> Just to say, that aside from the slight permissions error, the
> release of TEI P5 2.0.2 seems to have gone well. Thank you Martin
> for being a Guinea Pig (Or is that Groundhog?).  People can go
> back to committing to the SVN repository! :-)
>
> We discovered that it might be better to move the installation
> scripts on the tei-c.org machine to somewhere central (e.g.
> /home/tei/) and run them from there, and some other small
> corrections to the list of steps that Martin will add in due course.
>
> -James
>

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From mholmes at uvic.ca  Thu Feb  2 23:42:43 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Thu, 02 Feb 2012 20:42:43 -0800
Subject: [tei-council] New document describing release steps
Message-ID: <4F2B65C3.8070201@uvic.ca>

Following my thrilling day of first-times (first time releasing TEI, 
first time retweeting someone else's tweet, first time using IRC), I've 
put together a more detailed set of instructions for future release 
technicians:

<http://www.tei-c.org/Activities/Council/Working/tcw22.xml>

I've taken the core information in TCW20 relating to building a release, 
and elaborated and extended it to include things we didn't know we 
didn't know until today. I've also tried to explain why you take each 
step and how it works, so you don't find yourself blindly following 
mysterious instructions.

Please take a look through the document. If you've done a release 
before, check to make sure I haven't left anything out or got anything 
wrong. If you haven't done one, read it and see if you think it would be 
clear and detailed enough to help you through the process.

I haven't made any changes to TWC20, but if the new document is 
acceptable, I propose removing all those bits from TCW20 and replacing 
them with a reference to the new doc. I haven't published the new doc 
yet, so it doesn't appear on the TEI site menu.

I shall close with the now-traditional expression of hatred for the CMS 
system, which I must utter every time I have to interact with it. GRRR. ;-)

Cheers,
Martin

From sebastian.rahtz at oucs.ox.ac.uk  Fri Feb  3 04:41:32 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Fri, 3 Feb 2012 09:41:32 +0000
Subject: [tei-council] New document describing release steps
In-Reply-To: <4F2B65C3.8070201@uvic.ca>
References: <4F2B65C3.8070201@uvic.ca>
Message-ID: <81DCE54E-2A35-4C9C-906B-09A1F6058BB6@oucs.ox.ac.uk>


On 3 Feb 2012, at 04:42, Martin Holmes wrote:

> Following my thrilling day of first-times (first time releasing TEI, 
> first time retweeting someone else's tweet, first time using IRC), I've 
> put together a more detailed set of instructions for future release 
> technicians:
> 
> <http://www.tei-c.org/Activities/Council/Working/tcw22.xml>

I'm getting a 500 error I am afraid
--
Stormageddon Rahtz      
Head of Information and Support Group
Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431

S?lo le pido a Dios
que el futuro no me sea indiferente


From lou.burnard at retired.ox.ac.uk  Fri Feb  3 04:42:50 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Fri, 03 Feb 2012 09:42:50 +0000
Subject: [tei-council] New document describing release steps
In-Reply-To: <4F2B65C3.8070201@uvic.ca>
References: <4F2B65C3.8070201@uvic.ca>
Message-ID: <4F2BAC1A.207@retired.ox.ac.uk>

On 03/02/12 04:42, Martin Holmes wrote:

> I shall close with the now-traditional expression of hatred for the CMS
> system, which I must utter every time I have to interact with it. GRRR. ;-)

It seems to be taking its revenge. At any rate the URL you quote

<http://www.tei-c.org/Activities/Council/Working/tcw22.xml>

doesnt work for me!




From James.Cummings at oucs.ox.ac.uk  Fri Feb  3 05:01:42 2012
From: James.Cummings at oucs.ox.ac.uk (James Cummings)
Date: Fri, 03 Feb 2012 10:01:42 +0000
Subject: [tei-council] New document describing release steps
In-Reply-To: <4F2BAC1A.207@retired.ox.ac.uk>
References: <4F2B65C3.8070201@uvic.ca> <4F2BAC1A.207@retired.ox.ac.uk>
Message-ID: <4F2BB086.3090501@oucs.ox.ac.uk>


If Martin hasn't published it, it will not be visible unless you 
have already logged into openCMS.  (Martin: Publishing it isn't 
what makes it appear in the list... that is just by adding it to 
index.xml.  If you did want something to appear in the left-hand 
navigation you had to do so intentionally, by right-clicking on 
it and look at its 'properties' where you can 'add it to 
navigation'.)

I've 'stolen lock' from Martin and published it, but not added it 
to index.xml yet.

So you should be able to see it now at:

http://www.tei-c.org/Activities/Council/Working/tcw22.xml

Don't get me started on OpenCMS...
-James

On 03/02/12 09:42, Lou Burnard wrote:
> On 03/02/12 04:42, Martin Holmes wrote:
>
>> I shall close with the now-traditional expression of hatred for the CMS
>> system, which I must utter every time I have to interact with it. GRRR. ;-)
>
> It seems to be taking its revenge. At any rate the URL you quote
>
> <http://www.tei-c.org/Activities/Council/Working/tcw22.xml>
>
> doesnt work for me!
>
>
>


-- 
Dr James Cummings, InfoDev,
Computing Services, University of Oxford

From gabriel.bodard at kcl.ac.uk  Fri Feb  3 07:57:50 2012
From: gabriel.bodard at kcl.ac.uk (Gabriel Bodard)
Date: Fri, 3 Feb 2012 12:57:50 +0000
Subject: [tei-council] New document describing release steps
In-Reply-To: <4F2B65C3.8070201@uvic.ca>
References: <4F2B65C3.8070201@uvic.ca>
Message-ID: <4F2BD9CE.9090907@kcl.ac.uk>

Thanks and congratulations to Martin for carrying out this release and 
for taking pains to improve the documentation thereof.

I wouldn't mind trying to out myself at some future occasion (I presume 
we're not planning to release every couple weeks from now on!). The 
rationale for this (beyond my desire for self-improvement) would be that 
I am a lot stupider and a *lot* less technically adept than Martin, so 
this would be a sterner test of the foolproofness of the documentation 
and process.

G

On 2012-02-03 04:42, Martin Holmes wrote:
> Following my thrilling day of first-times (first time releasing TEI,
> first time retweeting someone else's tweet, first time using IRC), I've
> put together a more detailed set of instructions for future release
> technicians:
>
> <http://www.tei-c.org/Activities/Council/Working/tcw22.xml>
>
> I've taken the core information in TCW20 relating to building a release,
> and elaborated and extended it to include things we didn't know we
> didn't know until today. I've also tried to explain why you take each
> step and how it works, so you don't find yourself blindly following
> mysterious instructions.
>
> Please take a look through the document. If you've done a release
> before, check to make sure I haven't left anything out or got anything
> wrong. If you haven't done one, read it and see if you think it would be
> clear and detailed enough to help you through the process.
>
> I haven't made any changes to TWC20, but if the new document is
> acceptable, I propose removing all those bits from TCW20 and replacing
> them with a reference to the new doc. I haven't published the new doc
> yet, so it doesn't appear on the TEI site menu.
>
> I shall close with the now-traditional expression of hatred for the CMS
> system, which I must utter every time I have to interact with it. GRRR. ;-)
>
> Cheers,
> Martin

-- 
Dr Gabriel BODARD
(Research Associate in Digital Epigraphy)

Department of Digital Humanities
King's College London
26-29 Drury Lane
London WC2B 5RL

Email: gabriel.bodard at kcl.ac.uk
Tel: +44 (0)20 7848 1388
Fax: +44 (0)20 7848 2980

http://www.digitalclassicist.org/
http://www.currentepigraphy.org/

From mholmes at uvic.ca  Fri Feb  3 08:09:35 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Fri, 03 Feb 2012 05:09:35 -0800
Subject: [tei-council] New document describing release steps
In-Reply-To: <4F2BB086.3090501@oucs.ox.ac.uk>
References: <4F2B65C3.8070201@uvic.ca> <4F2BAC1A.207@retired.ox.ac.uk>
	<4F2BB086.3090501@oucs.ox.ac.uk>
Message-ID: <4F2BDC8F.1010105@uvic.ca>

I had published it, actually, but that was right before the third time 
it crashed my browser. When I restarted the browser I was able to see 
it, so I assumed it was successfully published, but I guess it hadn't 
completed and had just kept my own session alive so it worked for me.

GRRR.

Cheers,
Martin

On 12-02-03 02:01 AM, James Cummings wrote:
>
> If Martin hasn't published it, it will not be visible unless you
> have already logged into openCMS.  (Martin: Publishing it isn't
> what makes it appear in the list... that is just by adding it to
> index.xml.  If you did want something to appear in the left-hand
> navigation you had to do so intentionally, by right-clicking on
> it and look at its 'properties' where you can 'add it to
> navigation'.)
>
> I've 'stolen lock' from Martin and published it, but not added it
> to index.xml yet.
>
> So you should be able to see it now at:
>
> http://www.tei-c.org/Activities/Council/Working/tcw22.xml
>
> Don't get me started on OpenCMS...
> -James
>
> On 03/02/12 09:42, Lou Burnard wrote:
>> On 03/02/12 04:42, Martin Holmes wrote:
>>
>>> I shall close with the now-traditional expression of hatred for the CMS
>>> system, which I must utter every time I have to interact with it. GRRR. ;-)
>>
>> It seems to be taking its revenge. At any rate the URL you quote
>>
>> <http://www.tei-c.org/Activities/Council/Working/tcw22.xml>
>>
>> doesnt work for me!
>>
>>
>>
>
>

From James.Cummings at oucs.ox.ac.uk  Fri Feb  3 08:11:00 2012
From: James.Cummings at oucs.ox.ac.uk (James Cummings)
Date: Fri, 03 Feb 2012 13:11:00 +0000
Subject: [tei-council] New document describing release steps
In-Reply-To: <4F2BDC8F.1010105@uvic.ca>
References: <4F2B65C3.8070201@uvic.ca> <4F2BAC1A.207@retired.ox.ac.uk>
	<4F2BB086.3090501@oucs.ox.ac.uk> <4F2BDC8F.1010105@uvic.ca>
Message-ID: <4F2BDCE4.8030401@oucs.ox.ac.uk>


As I said before:

 >> Don't get me started on OpenCMS...

-James

On 03/02/12 13:09, Martin Holmes wrote:
> I had published it, actually, but that was right before the third time
> it crashed my browser. When I restarted the browser I was able to see
> it, so I assumed it was successfully published, but I guess it hadn't
> completed and had just kept my own session alive so it worked for me.
>
> GRRR.
>
> Cheers,
> Martin
>
> On 12-02-03 02:01 AM, James Cummings wrote:
>>
>> If Martin hasn't published it, it will not be visible unless you
>> have already logged into openCMS.  (Martin: Publishing it isn't
>> what makes it appear in the list... that is just by adding it to
>> index.xml.  If you did want something to appear in the left-hand
>> navigation you had to do so intentionally, by right-clicking on
>> it and look at its 'properties' where you can 'add it to
>> navigation'.)
>>
>> I've 'stolen lock' from Martin and published it, but not added it
>> to index.xml yet.
>>
>> So you should be able to see it now at:
>>
>> http://www.tei-c.org/Activities/Council/Working/tcw22.xml
>>
>> Don't get me started on OpenCMS...
>> -James
>>
>> On 03/02/12 09:42, Lou Burnard wrote:
>>> On 03/02/12 04:42, Martin Holmes wrote:
>>>
>>>> I shall close with the now-traditional expression of hatred for the CMS
>>>> system, which I must utter every time I have to interact with it. GRRR. ;-)
>>>
>>> It seems to be taking its revenge. At any rate the URL you quote
>>>
>>> <http://www.tei-c.org/Activities/Council/Working/tcw22.xml>
>>>
>>> doesnt work for me!
>>>
>>>
>>>
>>
>>


-- 
Dr James Cummings, InfoDev,
Computing Services, University of Oxford

From sebastian.rahtz at oucs.ox.ac.uk  Fri Feb  3 08:11:17 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Fri, 3 Feb 2012 13:11:17 +0000
Subject: [tei-council] New document describing release steps
In-Reply-To: <4F2BD9CE.9090907@kcl.ac.uk>
References: <4F2B65C3.8070201@uvic.ca> <4F2BD9CE.9090907@kcl.ac.uk>
Message-ID: <9C086D37-5F84-4145-9AE1-1036C510A4D6@oucs.ox.ac.uk>

some notes on http://www.tei-c.org/Activities/Council/Working/tcw22.xml

 1) the command "make changelog" in the P5 sources remakes the file ReleaseNotes/ChangeLog which contains a human-readable summary of changes from SVN. I am wondering how to automate this

 9) the reason for running "tei-database-rebuild" is to refresh the eXist database used by Roma. important to note this, I think.

 14) worth suggesting you visit http://www.tei-c.org/Roma/, click on defaults, and check that a) it works, and b) the version number is right in the footer
--
Stormageddon Rahtz      
Head of Information and Support Group
Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431

S?lo le pido a Dios
que el futuro no me sea indiferente


From James.Cummings at oucs.ox.ac.uk  Fri Feb  3 08:16:59 2012
From: James.Cummings at oucs.ox.ac.uk (James Cummings)
Date: Fri, 03 Feb 2012 13:16:59 +0000
Subject: [tei-council] New document describing release steps
In-Reply-To: <4F2BD9CE.9090907@kcl.ac.uk>
References: <4F2B65C3.8070201@uvic.ca> <4F2BD9CE.9090907@kcl.ac.uk>
Message-ID: <4F2BDE4B.7020307@oucs.ox.ac.uk>


That sounds like a volunteer to me!

Barring major or urgent bugs and such, I had mentally timetabled 
that a release should happen awhile after our April meeting. End 
of June start of July?  Does that seem like a good idea? The idea 
being we would decide a lot of problematic tickets at the face 2 
face and then have a deadline about a month and a bit later to 
have completed the work arising.

It might be a bit biased of me to suggest that we aim for 1 July 
and call this release Codename: Canada Day 
http://en.wikipedia.org/wiki/Canada_Day ... It is probably not a 
good idea to tie the codename of the release (so we know which 
one we're talking about) to a specific date.

While this is a bit of fun, any suggestions on a naming strategy 
for such codenames?

-James


On 03/02/12 12:57, Gabriel Bodard wrote:
> Thanks and congratulations to Martin for carrying out this release and
> for taking pains to improve the documentation thereof.
>
> I wouldn't mind trying to out myself at some future occasion (I presume
> we're not planning to release every couple weeks from now on!). The
> rationale for this (beyond my desire for self-improvement) would be that
> I am a lot stupider and a *lot* less technically adept than Martin, so
> this would be a sterner test of the foolproofness of the documentation
> and process.
>
> G
>
> On 2012-02-03 04:42, Martin Holmes wrote:
>> Following my thrilling day of first-times (first time releasing TEI,
>> first time retweeting someone else's tweet, first time using IRC), I've
>> put together a more detailed set of instructions for future release
>> technicians:
>>
>> <http://www.tei-c.org/Activities/Council/Working/tcw22.xml>
>>
>> I've taken the core information in TCW20 relating to building a release,
>> and elaborated and extended it to include things we didn't know we
>> didn't know until today. I've also tried to explain why you take each
>> step and how it works, so you don't find yourself blindly following
>> mysterious instructions.
>>
>> Please take a look through the document. If you've done a release
>> before, check to make sure I haven't left anything out or got anything
>> wrong. If you haven't done one, read it and see if you think it would be
>> clear and detailed enough to help you through the process.
>>
>> I haven't made any changes to TWC20, but if the new document is
>> acceptable, I propose removing all those bits from TCW20 and replacing
>> them with a reference to the new doc. I haven't published the new doc
>> yet, so it doesn't appear on the TEI site menu.
>>
>> I shall close with the now-traditional expression of hatred for the CMS
>> system, which I must utter every time I have to interact with it. GRRR. ;-)
>>
>> Cheers,
>> Martin
>


-- 
Dr James Cummings, InfoDev,
Computing Services, University of Oxford

From lou.burnard at retired.ox.ac.uk  Fri Feb  3 08:20:30 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Fri, 03 Feb 2012 13:20:30 +0000
Subject: [tei-council] New document describing release steps
In-Reply-To: <9C086D37-5F84-4145-9AE1-1036C510A4D6@oucs.ox.ac.uk>
References: <4F2B65C3.8070201@uvic.ca> <4F2BD9CE.9090907@kcl.ac.uk>
	<9C086D37-5F84-4145-9AE1-1036C510A4D6@oucs.ox.ac.uk>
Message-ID: <4F2BDF1E.8020503@retired.ox.ac.uk>

On 03/02/12 13:11, Sebastian Rahtz wrote:
> some notes on http://www.tei-c.org/Activities/Council/Working/tcw22.xml
>
>   1) the command "make changelog" in the P5 sources remakes the file ReleaseNotes/ChangeLog which contains a human-readable summary of changes from SVN. I am wondering how to automate this
>

It's also perhaps worth noting somewhere that the  ChangeLog isnot the 
same as the human-readable readme files included in the release. I have 
always hand-crafted the former from the latter and I don't see any 
obvious way of automating that process.


From lou.burnard at retired.ox.ac.uk  Fri Feb  3 08:21:42 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Fri, 03 Feb 2012 13:21:42 +0000
Subject: [tei-council] New document describing release steps
In-Reply-To: <4F2BDF1E.8020503@retired.ox.ac.uk>
References: <4F2B65C3.8070201@uvic.ca>
	<4F2BD9CE.9090907@kcl.ac.uk>	<9C086D37-5F84-4145-9AE1-1036C510A4D6@oucs.ox.ac.uk>
	<4F2BDF1E.8020503@retired.ox.ac.uk>
Message-ID: <4F2BDF66.5090206@retired.ox.ac.uk>

On 03/02/12 13:20, Lou Burnard wrote:
> On 03/02/12 13:11, Sebastian Rahtz wrote:
>> some notes on http://www.tei-c.org/Activities/Council/Working/tcw22.xml
>>
>>    1) the command "make changelog" in the P5 sources remakes the file ReleaseNotes/ChangeLog which contains a human-readable summary of changes from SVN. I am wondering how to automate this
>>
>
> It's also perhaps worth noting somewhere that the  ChangeLog isnot the
> same as the human-readable readme files included in the release. I have
> always hand-crafted the former from the latter and I don't see any
> obvious way of automating that process.
>
I meant, of course, "handcrafted the latter from the former" :-)






From mholmes at uvic.ca  Fri Feb  3 08:27:35 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Fri, 03 Feb 2012 05:27:35 -0800
Subject: [tei-council] New document describing release steps
In-Reply-To: <9C086D37-5F84-4145-9AE1-1036C510A4D6@oucs.ox.ac.uk>
References: <4F2B65C3.8070201@uvic.ca> <4F2BD9CE.9090907@kcl.ac.uk>
	<9C086D37-5F84-4145-9AE1-1036C510A4D6@oucs.ox.ac.uk>
Message-ID: <4F2BE0C7.5030204@uvic.ca>

Hi there,

On 12-02-03 05:11 AM, Sebastian Rahtz wrote:
> some notes on
> http://www.tei-c.org/Activities/Council/Working/tcw22.xml
>
> 1) the command "make changelog" in the P5 sources remakes the file
> ReleaseNotes/ChangeLog which contains a human-readable summary of
> changes from SVN. I am wondering how to automate this

I never realized that. I just tried it, and it gives me a changelog from 
now back to 2003; I wonder if we could make it detect the last release 
date and give you only the relevant bits?

> 9) the reason for running "tei-database-rebuild" is to refresh the
> eXist database used by Roma. important to note this, I think.

Good point. I've added that.

> 14) worth suggesting you visit http://www.tei-c.org/Roma/, click on
> defaults, and check that a) it works, and b) the version number is
> right in the footer --

Also added. I've uploaded the changes.

Note to self: when the CMS stalls on the "Uploading data..." dialog box, 
wait a bit, then click on the folder in the folder tree again. Then you 
can republish. Any other operation seems to crash Firefox.

Cheers,
Martin

> Stormageddon Rahtz Head of Information and
> Support Group Oxford University Computing Services 13 Banbury Road,
> Oxford OX2 6NN. Phone +44 1865 283431
>
> S?lo le pido a Dios que el futuro no me sea indiferente
>

From mholmes at uvic.ca  Fri Feb  3 08:30:35 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Fri, 03 Feb 2012 05:30:35 -0800
Subject: [tei-council] New document describing release steps
In-Reply-To: <4F2BDF1E.8020503@retired.ox.ac.uk>
References: <4F2B65C3.8070201@uvic.ca>
	<4F2BD9CE.9090907@kcl.ac.uk>	<9C086D37-5F84-4145-9AE1-1036C510A4D6@oucs.ox.ac.uk>
	<4F2BDF1E.8020503@retired.ox.ac.uk>
Message-ID: <4F2BE17B.1090401@uvic.ca>

I agree; I think only a human can determine which SVN changes deserve 
mention in the release notes and which don't. Unless, of course, we 
adopt a rigorous convention for SVN commit messages that would enable 
them to be processed mechanically. But that seems far-fetched.

That "XML 101, Martin..." message is going to haunt me for ever. :-)

Cheers,
Martin

On 12-02-03 05:20 AM, Lou Burnard wrote:
> On 03/02/12 13:11, Sebastian Rahtz wrote:
>> some notes on http://www.tei-c.org/Activities/Council/Working/tcw22.xml
>>
>>    1) the command "make changelog" in the P5 sources remakes the file ReleaseNotes/ChangeLog which contains a human-readable summary of changes from SVN. I am wondering how to automate this
>>
>
> It's also perhaps worth noting somewhere that the  ChangeLog isnot the
> same as the human-readable readme files included in the release. I have
> always hand-crafted the former from the latter and I don't see any
> obvious way of automating that process.
>

From sebastian.rahtz at oucs.ox.ac.uk  Fri Feb  3 08:33:18 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Fri, 3 Feb 2012 13:33:18 +0000
Subject: [tei-council] New document describing release steps
In-Reply-To: <4F2BE17B.1090401@uvic.ca>
References: <4F2B65C3.8070201@uvic.ca>	<4F2BD9CE.9090907@kcl.ac.uk>
	<9C086D37-5F84-4145-9AE1-1036C510A4D6@oucs.ox.ac.uk>
	<4F2BDF1E.8020503@retired.ox.ac.uk> <4F2BE17B.1090401@uvic.ca>
Message-ID: <6590E34F-2A79-4C69-88B3-20CF3F22C8E8@oucs.ox.ac.uk>


On 3 Feb 2012, at 13:30, Martin Holmes wrote:

> 
> That "XML 101, Martin..." message is going to haunt me for ever. :-)


oh, sorry about that, just my bit of fun. feel free to hand edit the changelog!
--
Stormageddon Rahtz      
Head of Information and Support Group
Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431

S?lo le pido a Dios
que el futuro no me sea indiferente


From mholmes at uvic.ca  Fri Feb  3 08:39:03 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Fri, 03 Feb 2012 05:39:03 -0800
Subject: [tei-council] New document describing release steps
In-Reply-To: <4F2BD9CE.9090907@kcl.ac.uk>
References: <4F2B65C3.8070201@uvic.ca> <4F2BD9CE.9090907@kcl.ac.uk>
Message-ID: <4F2BE377.5050306@uvic.ca>



On 12-02-03 04:57 AM, Gabriel Bodard wrote:
> Thanks and congratulations to Martin for carrying out this release and
> for taking pains to improve the documentation thereof.
>
> I wouldn't mind trying to out myself at some future occasion (I presume
> we're not planning to release every couple weeks from now on!). The
> rationale for this (beyond my desire for self-improvement) would be that
> I am a lot stupider and a *lot* less technically adept than Martin, so
> this would be a sterner test of the foolproofness of the documentation
> and process.

That's very kind, but I bet you've never pasted a bunch of content 
before the XML declaration in a file, committed the result without 
validating it, and then gone off to have a leisurely breakfast while the 
Jinks servers choked and spat it out. On release day. :-)

Cheers,
Martin
>
> G
>
> On 2012-02-03 04:42, Martin Holmes wrote:
>> Following my thrilling day of first-times (first time releasing TEI,
>> first time retweeting someone else's tweet, first time using IRC), I've
>> put together a more detailed set of instructions for future release
>> technicians:
>>
>> <http://www.tei-c.org/Activities/Council/Working/tcw22.xml>
>>
>> I've taken the core information in TCW20 relating to building a release,
>> and elaborated and extended it to include things we didn't know we
>> didn't know until today. I've also tried to explain why you take each
>> step and how it works, so you don't find yourself blindly following
>> mysterious instructions.
>>
>> Please take a look through the document. If you've done a release
>> before, check to make sure I haven't left anything out or got anything
>> wrong. If you haven't done one, read it and see if you think it would be
>> clear and detailed enough to help you through the process.
>>
>> I haven't made any changes to TWC20, but if the new document is
>> acceptable, I propose removing all those bits from TCW20 and replacing
>> them with a reference to the new doc. I haven't published the new doc
>> yet, so it doesn't appear on the TEI site menu.
>>
>> I shall close with the now-traditional expression of hatred for the CMS
>> system, which I must utter every time I have to interact with it. GRRR. ;-)
>>
>> Cheers,
>> Martin
>

From sebastian.rahtz at oucs.ox.ac.uk  Fri Feb  3 08:43:58 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Fri, 3 Feb 2012 13:43:58 +0000
Subject: [tei-council] New document describing release steps
In-Reply-To: <4F2BE377.5050306@uvic.ca>
References: <4F2B65C3.8070201@uvic.ca> <4F2BD9CE.9090907@kcl.ac.uk>
	<4F2BE377.5050306@uvic.ca>
Message-ID: <5FD1076D-A6C4-48C0-A665-EF2B9E09CED9@oucs.ox.ac.uk>


On 3 Feb 2012, at 13:39, Martin Holmes wrote:

> That's very kind, but I bet you've never pasted a bunch of content 
> before the XML declaration in a file, committed the result without 
> validating it, and then gone off to have a leisurely breakfast while the 
> Jinks servers choked and spat it out. 

I have to admit, it took me a good ten minutes to understand what
had happened after I saw the error message. It was really quite obscure.
--
Stormageddon Rahtz      
Head of Information and Support Group
Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431

S?lo le pido a Dios
que el futuro no me sea indiferente


From sebastian.rahtz at oucs.ox.ac.uk  Fri Feb  3 10:52:11 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Fri, 3 Feb 2012 15:52:11 +0000
Subject: [tei-council] oxygen-tei release
Message-ID: <4FF1ABFA-4F94-41EF-9E5F-91EE4FDA2E66@oucs.ox.ac.uk>

I have copied all the latest and greatest to http://code.google.com/p/oxygen-tei/

for reference, one has to

  - check out the source using Subversion
  - copy all the xml tree  from the current release
  - copy in an oxygen.jar from current oxygen
  - build the zip with Ant
  - upload the zip to googlecode

scriptable, in due course, but I feel weak today.
--
Stormageddon Rahtz      
Head of Information and Support Group
Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431

S?lo le pido a Dios
que el futuro no me sea indiferente


From James.Cummings at oucs.ox.ac.uk  Fri Feb  3 10:57:23 2012
From: James.Cummings at oucs.ox.ac.uk (James Cummings)
Date: Fri, 03 Feb 2012 15:57:23 +0000
Subject: [tei-council] New document describing release steps
In-Reply-To: <5FD1076D-A6C4-48C0-A665-EF2B9E09CED9@oucs.ox.ac.uk>
References: <4F2B65C3.8070201@uvic.ca>
	<4F2BD9CE.9090907@kcl.ac.uk>	<4F2BE377.5050306@uvic.ca>
	<5FD1076D-A6C4-48C0-A665-EF2B9E09CED9@oucs.ox.ac.uk>
Message-ID: <4F2C03E3.1060505@oucs.ox.ac.uk>

On 03/02/12 13:43, Sebastian Rahtz wrote:
> I have to admit, it took me a good ten minutes to understand what
> had happened after I saw the error message. It was really quite obscure.

Whereas I suspected immediately what it was... having had the 
exact same error message from doing something similar (but not on 
release) at one point. :-)

-James

-- 
Dr James Cummings, InfoDev,
Computing Services, University of Oxford

From mholmes at uvic.ca  Fri Feb  3 11:57:25 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Fri, 3 Feb 2012 08:57:25 -0800
Subject: [tei-council] oxygen-tei release
In-Reply-To: <4FF1ABFA-4F94-41EF-9E5F-91EE4FDA2E66@oucs.ox.ac.uk>
References: <4FF1ABFA-4F94-41EF-9E5F-91EE4FDA2E66@oucs.ox.ac.uk>
Message-ID: <4F2C11F5.9040001@uvic.ca>

I guess the question is whether we want the release technician to take 
care of this (in which case a script would be great, but there would 
also be the issue of permissions to upload to Google Code), or whether 
we view it as peripheral to the main release, and hope Sebastian is 
happy to continue doing it. A middle ground would be for three or four 
of us to have the know-how and rights to do this, so it doesn't always 
have to be Sebastian.

Cheers,
Martin

On 12-02-03 07:52 AM, Sebastian Rahtz wrote:
> I have copied all the latest and greatest to http://code.google.com/p/oxygen-tei/
>
> for reference, one has to
>
>    - check out the source using Subversion
>    - copy all the xml tree  from the current release
>    - copy in an oxygen.jar from current oxygen
>    - build the zip with Ant
>    - upload the zip to googlecode
>
> scriptable, in due course, but I feel weak today.
> --
> Stormageddon Rahtz
> Head of Information and Support Group
> Oxford University Computing Services
> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>
> S?lo le pido a Dios
> que el futuro no me sea indiferente
>

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From rwelzenbach at gmail.com  Fri Feb  3 16:54:07 2012
From: rwelzenbach at gmail.com (Rebecca Welzenbach)
Date: Fri, 3 Feb 2012 16:54:07 -0500
Subject: [tei-council] Ann Arbor spring meeting
In-Reply-To: <CAA2irtJggbRO0XE9H3dsYM4Gxh04pqR=jt_sTZWXj7vVt=XK0w@mail.gmail.com>
References: <o4f8j7egl1qp4ugx9vpvsh8l.1327431683813@email.android.com>
	<4F1F19E3.1000401@uvic.ca> <4F1F1EC4.3010301@uvic.ca>
	<4F1F43EF.8090904@ultraslavonic.info>
	<CAA2irtKqAhk=DOsT1PNxkQf_YhkJzAsJBKdRMqNS4ZCD6y527Q@mail.gmail.com>
	<4F203226.10901@uvic.ca> <4F203A69.6000500@o2.pl>
	<4F208843.205@uvic.ca> <4F2089D9.2050405@ultraslavonic.info>
	<4F2122D4.7050209@oucs.ox.ac.uk> <4F21239F.5070501@oucs.ox.ac.uk>
	<CAA2irtJggbRO0XE9H3dsYM4Gxh04pqR=jt_sTZWXj7vVt=XK0w@mail.gmail.com>
Message-ID: <CAA2irt+-k+Opz1EE3VC+EHq1w-ZL69B53WrOgsuspgmP0W3wRw@mail.gmail.com>

Hi all,

Just an update: a block of rooms has been reserved at the Bell Tower
Inn, and I've just heard this afternoon that the University of
Michigan Library will indeed be able to pay for this transaction, and
then apply for reimbursement from TEI-C, which will save us a bit of
money. (Around $650--Lobsters and champagne for everyone!)

Because the transaction will be between the hotel and UM, you do *not*
need to make your own reservation, but I *do* need a firm list of
exactly who will be here when, to give to both the hotel and our
finance office. Thanks to James' poll, I have this information from
everyone but Gaby, whom I've just bugged separately. So we're set for
accommodations, and you don't need to do anything at this point.

Becky

On Thu, Jan 26, 2012 at 8:57 AM, Rebecca Welzenbach
<rwelzenbach at gmail.com> wrote:
> Great idea--thanks, James.
>
> On Thu, Jan 26, 2012 at 4:57 AM, James Cummings
> <James.Cummings at oucs.ox.ac.uk> wrote:
>> On 26/01/12 09:54, James Cummings wrote:
>>> I've put up a doodle for people to record what nights they will
>>> need hotel. This will be useful for Becky if doing a block
>>> booking, and/or all of us to know who is arriving/departing when.
>>> ? ?Since I'm arriving on the Sat and leaving on the Wednesday,
>>> I've checked Sat/Sun/Mon/Tues Nights. Could everyone needing
>>> hotel fill it out?
>>
>> Of course it would be better if I included the URL. (*doh*)
>>
>> http://www.doodle.com/9dunbbdcngadff68
>>
>>
>>
>>>
>>> -James
>>>
>>
>>
>> --
>> Dr James Cummings, InfoDev,
>> Computing Services, University of Oxford
>> --
>> tei-council mailing list
>> tei-council at lists.village.Virginia.EDU
>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>>
>> PLEASE NOTE: postings to this list are publicly archived

From syeates at gmail.com  Sun Feb  5 21:17:55 2012
From: syeates at gmail.com (stuart yeates)
Date: Mon, 06 Feb 2012 15:17:55 +1300
Subject: [tei-council] New document describing release steps
In-Reply-To: <4F2B65C3.8070201@uvic.ca>
References: <4F2B65C3.8070201@uvic.ca>
Message-ID: <4F2F3853.2090600@gmail.com>

On 03/02/12 17:42, Martin Holmes wrote:
> Following my thrilling day of first-times (first time releasing TEI,
> first time retweeting someone else's tweet, first time using IRC), I've
> put together a more detailed set of instructions for future release
> technicians:
>
> <http://www.tei-c.org/Activities/Council/Working/tcw22.xml>


The line:

svn log -r {2011-12-12}:{2012-02-12}

can be replaced by the slightly simpler:

svn log -r {2011-12-14}:HEAD

which requires only one date to be filled.

---

Could the line:

./tei-install.sh --package=TEIP5 --version=X.X.X --sfuser=username

not be simplified by having the script look in P5/VERSION for the 
version number? Then it'd be one less thing with a chance to go wrong / 
out of sync.

---

It's not 100% clear to me which machine steps 9 and 11 are executed on.

---

Other than that it looks really good.

cheers
stuart



From sebastian.rahtz at oucs.ox.ac.uk  Mon Feb  6 04:14:34 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Mon, 6 Feb 2012 09:14:34 +0000
Subject: [tei-council] New document describing release steps
In-Reply-To: <4F2F3853.2090600@gmail.com>
References: <4F2B65C3.8070201@uvic.ca> <4F2F3853.2090600@gmail.com>
Message-ID: <CD9BFDBE-B97F-4BAD-B9F6-AEB57758C06B@oucs.ox.ac.uk>


On 6 Feb 2012, at 02:17, stuart yeates wrote:

> Could the line:
> 
> ./tei-install.sh --package=TEIP5 --version=X.X.X --sfuser=username
> 
> not be simplified by having the script look in P5/VERSION for the 
> version number? Then it'd be one less thing with a chance to go wrong / 
> out of sync.
No, because the script is not running with a copy of P5 in front of it. It uses the --version
to know which file to grab from the Jenkins server which has prepared the release.
The script itself does no building, it just pulls zip files and unpacks them
in the right place.

--
Stormageddon Rahtz      
Head of Information and Support Group, Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431

S?lo le pido a Dios
que el futuro no me sea indiferente


From mholmes at uvic.ca  Mon Feb  6 08:44:33 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Mon, 06 Feb 2012 05:44:33 -0800
Subject: [tei-council] New document describing release steps
In-Reply-To: <4F2F3853.2090600@gmail.com>
References: <4F2B65C3.8070201@uvic.ca> <4F2F3853.2090600@gmail.com>
Message-ID: <4F2FD941.4030205@uvic.ca>

I've made those changes, except the one to the tei-install.sh script. I 
agree that it's a good idea, but I'm slightly worried about what might 
happen if someone had inadvertently failed to update P5/VERSION 
correctly, and then ran the script. We should think about that a bit.

I've now published the document on the site. (GRRR.)

Does anyone have any objections to my editing TCW20 to remove the old 
release instructions and point to the new file?

Cheers,
Martin

On 12-02-05 06:17 PM, stuart yeates wrote:
> On 03/02/12 17:42, Martin Holmes wrote:
>> Following my thrilling day of first-times (first time releasing TEI,
>> first time retweeting someone else's tweet, first time using IRC), I've
>> put together a more detailed set of instructions for future release
>> technicians:
>>
>> <http://www.tei-c.org/Activities/Council/Working/tcw22.xml>
>
>
> The line:
>
> svn log -r {2011-12-12}:{2012-02-12}
>
> can be replaced by the slightly simpler:
>
> svn log -r {2011-12-14}:HEAD
>
> which requires only one date to be filled.
>
> ---
>
> Could the line:
>
> ./tei-install.sh --package=TEIP5 --version=X.X.X --sfuser=username
>
> not be simplified by having the script look in P5/VERSION for the
> version number? Then it'd be one less thing with a chance to go wrong /
> out of sync.
>
> ---
>
> It's not 100% clear to me which machine steps 9 and 11 are executed on.
>
> ---
>
> Other than that it looks really good.
>
> cheers
> stuart
>
>

From mholmes at uvic.ca  Mon Feb  6 11:41:14 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Mon, 6 Feb 2012 08:41:14 -0800
Subject: [tei-council] New document describing release steps
In-Reply-To: <CD9BFDBE-B97F-4BAD-B9F6-AEB57758C06B@oucs.ox.ac.uk>
References: <4F2B65C3.8070201@uvic.ca> <4F2F3853.2090600@gmail.com>
	<CD9BFDBE-B97F-4BAD-B9F6-AEB57758C06B@oucs.ox.ac.uk>
Message-ID: <4F3002AA.3050803@uvic.ca>

Hi there,

It just occurred to me that the script could curl P5/VERSION from the SF 
repo to get the version info, couldn't it?

Cheers,
Martin

On 12-02-06 01:14 AM, Sebastian Rahtz wrote:
>
> On 6 Feb 2012, at 02:17, stuart yeates wrote:
>
>> Could the line:
>>
>> ./tei-install.sh --package=TEIP5 --version=X.X.X --sfuser=username
>>
>> not be simplified by having the script look in P5/VERSION for the
>> version number? Then it'd be one less thing with a chance to go wrong /
>> out of sync.
> No, because the script is not running with a copy of P5 in front of it. It uses the --version
> to know which file to grab from the Jenkins server which has prepared the release.
> The script itself does no building, it just pulls zip files and unpacks them
> in the right place.
>
> --
> Stormageddon Rahtz
> Head of Information and Support Group, Oxford University Computing Services
> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>
> S?lo le pido a Dios
> que el futuro no me sea indiferente
>

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From sebastian.rahtz at oucs.ox.ac.uk  Mon Feb  6 11:43:55 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Mon, 6 Feb 2012 16:43:55 +0000
Subject: [tei-council] New document describing release steps
In-Reply-To: <4F3002AA.3050803@uvic.ca>
References: <4F2B65C3.8070201@uvic.ca> <4F2F3853.2090600@gmail.com>
	<CD9BFDBE-B97F-4BAD-B9F6-AEB57758C06B@oucs.ox.ac.uk>
	<4F3002AA.3050803@uvic.ca>
Message-ID: <7BAFF5B1-7D6D-4171-8847-DA86CC94EBCD@oucs.ox.ac.uk>


On 6 Feb 2012, at 16:41, Martin Holmes wrote:

> 
> It just occurred to me that the script could curl P5/VERSION from the SF 
> repo to get the version info, couldn't it?


if you think its worth the trouble. I'd still leave the option there of overriding it
if needed.
--
Stormageddon Rahtz      
Head of Information and Support Group
Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431

S?lo le pido a Dios
que el futuro no me sea indiferente


From mholmes at uvic.ca  Tue Feb  7 08:47:47 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Tue, 07 Feb 2012 05:47:47 -0800
Subject: [tei-council] @cRef survey
Message-ID: <4F312B83.8020801@uvic.ca>

Hi all,

I've had only nine responses to my @cRef survey so far, which suggests 
it's not in very wide use. People using it tend to be using it slightly 
incorrectly -- sometimes they're using canonical references with spaces 
in them, or they're using #id-in-different-document or 
#id-which-dunt-exist, and in no case has anyone created a <cRefPattern>.

So if we deprecated it, we'd annoy a small number of people, but there's 
no fix we could make to it that would bring them all into the fold of 
correct usage anyway. Usage is as much of a mess as the definitions are.

To deal with this issue, as well as that of @key, I think we need to 
take three steps:

1. Develop a proper strategy for the use of private URI schemes (with 
something similar to <cRefPattern> where people can properly document 
how their private schemes are to be dereferenced or understood). This 
should divert a large proportion of the current usage of @cRef (and 
@key) over to @ref and @target.

2. Decide whether we want to keep @key and @cRef, or deprecate one or both.

3. If we're keeping them, decide what their datatypes should be. In the 
case of @cRef, create a proper class for it.

4. If we're not keeping them, do we need replacement attribute(s) for 
their use-cases?

Cheers,
Martin

From James.Cummings at oucs.ox.ac.uk  Tue Feb  7 10:19:12 2012
From: James.Cummings at oucs.ox.ac.uk (James Cummings)
Date: Tue, 07 Feb 2012 15:19:12 +0000
Subject: [tei-council] New document describing release steps
In-Reply-To: <7BAFF5B1-7D6D-4171-8847-DA86CC94EBCD@oucs.ox.ac.uk>
References: <4F2B65C3.8070201@uvic.ca>
	<4F2F3853.2090600@gmail.com>	<CD9BFDBE-B97F-4BAD-B9F6-AEB57758C06B@oucs.ox.ac.uk>	<4F3002AA.3050803@uvic.ca>
	<7BAFF5B1-7D6D-4171-8847-DA86CC94EBCD@oucs.ox.ac.uk>
Message-ID: <4F3140F0.1000408@oucs.ox.ac.uk>


The tei user on tei-c.org now has a /home/tei/svn/ directory, 
which updates from sourceforge svn once an hour. So there should 
be a local copy available. Why not just update this (as part of 
the script) and check the VERSION file.  (Ok, leave as an option 
that can be overridden as well...)

I've also moved the relevant release and update scripts into 
/home/tei/bin/

-James

On 06/02/12 16:43, Sebastian Rahtz wrote:
>
> On 6 Feb 2012, at 16:41, Martin Holmes wrote:
>
>>
>> It just occurred to me that the script could curl P5/VERSION from the SF
>> repo to get the version info, couldn't it?
>
>
> if you think its worth the trouble. I'd still leave the option there of overriding it
> if needed.
> --
> Stormageddon Rahtz
> Head of Information and Support Group
> Oxford University Computing Services
> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>
> S?lo le pido a Dios
> que el futuro no me sea indiferente
>


-- 
Dr James Cummings, InfoDev,
Computing Services, University of Oxford

From James.Cummings at oucs.ox.ac.uk  Tue Feb  7 10:21:32 2012
From: James.Cummings at oucs.ox.ac.uk (James Cummings)
Date: Tue, 07 Feb 2012 15:21:32 +0000
Subject: [tei-council] @cRef survey
In-Reply-To: <4F312B83.8020801@uvic.ca>
References: <4F312B83.8020801@uvic.ca>
Message-ID: <4F31417C.4070702@oucs.ox.ac.uk>


Could you make sure that the Library SIG people circulate it? Not 
sure if they use it at all, but one of the comments on my P4 
Survey results were that many Library people probably don't see 
it because they don't read TEI-L.  (I don't think this will 
change your results in the slightest however...)

-James


On 07/02/12 13:47, Martin Holmes wrote:
> Hi all,
>
> I've had only nine responses to my @cRef survey so far, which suggests
> it's not in very wide use. People using it tend to be using it slightly
> incorrectly -- sometimes they're using canonical references with spaces
> in them, or they're using #id-in-different-document or
> #id-which-dunt-exist, and in no case has anyone created a<cRefPattern>.
>
> So if we deprecated it, we'd annoy a small number of people, but there's
> no fix we could make to it that would bring them all into the fold of
> correct usage anyway. Usage is as much of a mess as the definitions are.
>
> To deal with this issue, as well as that of @key, I think we need to
> take three steps:
>
> 1. Develop a proper strategy for the use of private URI schemes (with
> something similar to<cRefPattern>  where people can properly document
> how their private schemes are to be dereferenced or understood). This
> should divert a large proportion of the current usage of @cRef (and
> @key) over to @ref and @target.
>
> 2. Decide whether we want to keep @key and @cRef, or deprecate one or both.
>
> 3. If we're keeping them, decide what their datatypes should be. In the
> case of @cRef, create a proper class for it.
>
> 4. If we're not keeping them, do we need replacement attribute(s) for
> their use-cases?
>
> Cheers,
> Martin


-- 
Dr James Cummings, InfoDev,
Computing Services, University of Oxford

From kevin.s.hawkins at ultraslavonic.info  Tue Feb  7 11:14:24 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Tue, 07 Feb 2012 11:14:24 -0500
Subject: [tei-council] @cRef survey
In-Reply-To: <4F31417C.4070702@oucs.ox.ac.uk>
References: <4F312B83.8020801@uvic.ca> <4F31417C.4070702@oucs.ox.ac.uk>
Message-ID: <4F314DE0.7070508@ultraslavonic.info>

Okay, I will post to the Library SIG list.

On 2/7/2012 10:21 AM, James Cummings wrote:
>
> Could you make sure that the Library SIG people circulate it? Not
> sure if they use it at all, but one of the comments on my P4
> Survey results were that many Library people probably don't see
> it because they don't read TEI-L.  (I don't think this will
> change your results in the slightest however...)
>
> -James
>
>
> On 07/02/12 13:47, Martin Holmes wrote:
>> Hi all,
>>
>> I've had only nine responses to my @cRef survey so far, which suggests
>> it's not in very wide use. People using it tend to be using it slightly
>> incorrectly -- sometimes they're using canonical references with spaces
>> in them, or they're using #id-in-different-document or
>> #id-which-dunt-exist, and in no case has anyone created a<cRefPattern>.
>>
>> So if we deprecated it, we'd annoy a small number of people, but there's
>> no fix we could make to it that would bring them all into the fold of
>> correct usage anyway. Usage is as much of a mess as the definitions are.
>>
>> To deal with this issue, as well as that of @key, I think we need to
>> take three steps:
>>
>> 1. Develop a proper strategy for the use of private URI schemes (with
>> something similar to<cRefPattern>   where people can properly document
>> how their private schemes are to be dereferenced or understood). This
>> should divert a large proportion of the current usage of @cRef (and
>> @key) over to @ref and @target.
>>
>> 2. Decide whether we want to keep @key and @cRef, or deprecate one or both.
>>
>> 3. If we're keeping them, decide what their datatypes should be. In the
>> case of @cRef, create a proper class for it.
>>
>> 4. If we're not keeping them, do we need replacement attribute(s) for
>> their use-cases?
>>
>> Cheers,
>> Martin
>
>

From mholmes at uvic.ca  Tue Feb  7 11:46:27 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Tue, 7 Feb 2012 08:46:27 -0800
Subject: [tei-council] @cRef survey
In-Reply-To: <4F31417C.4070702@oucs.ox.ac.uk>
References: <4F312B83.8020801@uvic.ca> <4F31417C.4070702@oucs.ox.ac.uk>
Message-ID: <4F315563.2080205@uvic.ca>

Kevin, I think you're a convener of that SIG, aren't you? Could you 
point people at:

<http://www.surveymonkey.com/s/PW5YYH6>

Cheers,
Martin

On 12-02-07 07:21 AM, James Cummings wrote:
>
> Could you make sure that the Library SIG people circulate it? Not
> sure if they use it at all, but one of the comments on my P4
> Survey results were that many Library people probably don't see
> it because they don't read TEI-L.  (I don't think this will
> change your results in the slightest however...)
>
> -James
>
>
> On 07/02/12 13:47, Martin Holmes wrote:
>> Hi all,
>>
>> I've had only nine responses to my @cRef survey so far, which suggests
>> it's not in very wide use. People using it tend to be using it slightly
>> incorrectly -- sometimes they're using canonical references with spaces
>> in them, or they're using #id-in-different-document or
>> #id-which-dunt-exist, and in no case has anyone created a<cRefPattern>.
>>
>> So if we deprecated it, we'd annoy a small number of people, but there's
>> no fix we could make to it that would bring them all into the fold of
>> correct usage anyway. Usage is as much of a mess as the definitions are.
>>
>> To deal with this issue, as well as that of @key, I think we need to
>> take three steps:
>>
>> 1. Develop a proper strategy for the use of private URI schemes (with
>> something similar to<cRefPattern>   where people can properly document
>> how their private schemes are to be dereferenced or understood). This
>> should divert a large proportion of the current usage of @cRef (and
>> @key) over to @ref and @target.
>>
>> 2. Decide whether we want to keep @key and @cRef, or deprecate one or both.
>>
>> 3. If we're keeping them, decide what their datatypes should be. In the
>> case of @cRef, create a proper class for it.
>>
>> 4. If we're not keeping them, do we need replacement attribute(s) for
>> their use-cases?
>>
>> Cheers,
>> Martin
>
>

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From mholmes at uvic.ca  Tue Feb  7 23:33:54 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Tue, 07 Feb 2012 20:33:54 -0800
Subject: [tei-council] Question about attribute definitions and descriptions
Message-ID: <4F31FB32.6040808@uvic.ca>

HI all,

As part of working on <http://purl.org/tei/BUGS/3455686>, I built myself 
this little table of TEI attributes, and how they're defined and described:

<http://web.uvic.ca/lancenrd/martin/tei/valdescs.htm>

Could you take a look at rows 286 to 289 (it's OK, they're numbered), 
which all have @scheme attributes?

I'm a bit puzzled by the slight variation in descriptions (att/@scheme 
has "identifier" while the others have "name"), but more by the 
differences in the valLists. The first two are open and the last two 
closed. I can see why constraintSpec/@scheme should have a closed list, 
but I don't see why tag/@scheme should be. It seems to me that it should 
be open, like gi/@scheme.

Am I missing something?

Cheers,
Martin
-- 
Martin Holmes
mholmes at uvic.ca
UVic Humanities Computing and Media Centre

From lou.burnard at retired.ox.ac.uk  Wed Feb  8 05:10:58 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Wed, 08 Feb 2012 10:10:58 +0000
Subject: [tei-council] Question about attribute definitions and
	descriptions
In-Reply-To: <4F31FB32.6040808@uvic.ca>
References: <4F31FB32.6040808@uvic.ca>
Message-ID: <4F324A32.2050600@retired.ox.ac.uk>

On 08/02/12 04:33, Martin Holmes wrote:

> closed. I can see why constraintSpec/@scheme should have a closed list,
> but I don't see why tag/@scheme should be. It seems to me that it should
> be open, like gi/@scheme.
>

I would say that's a corrigible bug. <att> and <tag> should behave in 
the same way -- it should be an open valList in both cases.

Probably <tag> and <gi> should have the same suggested vallist too.

Thanks for this splendid list, perusal of which will probably throw up 
many more such inconsistencies.



From mholmes at uvic.ca  Wed Feb  8 08:38:56 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Wed, 08 Feb 2012 05:38:56 -0800
Subject: [tei-council] Question about attribute definitions
	and	descriptions
In-Reply-To: <4F324A32.2050600@retired.ox.ac.uk>
References: <4F31FB32.6040808@uvic.ca> <4F324A32.2050600@retired.ox.ac.uk>
Message-ID: <4F327AF0.4090900@uvic.ca>

I've made the change to an open valList and made the suggested values 
for <tag> the same as for <gi>.

But now I'm wondering why <gi> has a <datatype> and <tag> doesn't. In 
fact, I'm wondering why so many attributes in the list lack a datatype. 
They all seem to be attributes which should be data.enumerated.

Is this just a historical accident, or is there some reason or pattern 
to it?

Cheers,
Martin

On 12-02-08 02:10 AM, Lou Burnard wrote:
> On 08/02/12 04:33, Martin Holmes wrote:
>
>> closed. I can see why constraintSpec/@scheme should have a closed list,
>> but I don't see why tag/@scheme should be. It seems to me that it should
>> be open, like gi/@scheme.
>>
>
> I would say that's a corrigible bug.<att>  and<tag>  should behave in
> the same way -- it should be an open valList in both cases.
>
> Probably<tag>  and<gi>  should have the same suggested vallist too.
>
> Thanks for this splendid list, perusal of which will probably throw up
> many more such inconsistencies.
>
>

From James.Cummings at oucs.ox.ac.uk  Wed Feb  8 12:24:50 2012
From: James.Cummings at oucs.ox.ac.uk (James Cummings)
Date: Wed, 08 Feb 2012 17:24:50 +0000
Subject: [tei-council] Question about attribute
	definitions	and	descriptions
In-Reply-To: <4F327AF0.4090900@uvic.ca>
References: <4F31FB32.6040808@uvic.ca> <4F324A32.2050600@retired.ox.ac.uk>
	<4F327AF0.4090900@uvic.ca>
Message-ID: <4F32AFE2.60606@oucs.ox.ac.uk>

On 08/02/12 13:38, Martin Holmes wrote:
> But now I'm wondering why<gi>  has a<datatype>  and<tag>  doesn't. In
> fact, I'm wondering why so many attributes in the list lack a datatype.
> They all seem to be attributes which should be data.enumerated.

It does seem to happen with attributes which I would suspect 
should be data.enumerated.

> Is this just a historical accident, or is there some reason or pattern
> to it?

In all the cases I looked at the attribute values were a closed 
value list with very specific values.  Perhaps these should be 
made data.enumerated with a closed value list?

-James

-- 
Dr James Cummings, InfoDev,
Computing Services, University of Oxford

From mholmes at uvic.ca  Wed Feb  8 14:26:28 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Wed, 8 Feb 2012 11:26:28 -0800
Subject: [tei-council] Question about
	attribute	definitions	and	descriptions
In-Reply-To: <4F32AFE2.60606@oucs.ox.ac.uk>
References: <4F31FB32.6040808@uvic.ca>
	<4F324A32.2050600@retired.ox.ac.uk>	<4F327AF0.4090900@uvic.ca>
	<4F32AFE2.60606@oucs.ox.ac.uk>
Message-ID: <4F32CC64.5040005@uvic.ca>

 > In all the cases I looked at the attribute values were a closed
 > value list with very specific values.  Perhaps these should be
 > made data.enumerated with a closed value list?

You're mostly right, but see the list below for one or two exceptions 
(marked with arrows). Numbers refer to 
<http://web.uvic.ca/lancenrd/martin/tei/valdescs.htm>. This raises some 
questions:

1. Should all attributes with a closed valList be specified as 
data.enumerated? "data.enumerated defines the range of attribute values 
expressed as a single XML name taken from a list of documented 
possibilities." This (to my reading) doesn't specify whether the list of 
possibilities is closed or open, so I think it can/should apply to 
closed valLists as well. If it doesn't, we need another datatype that 
does, because I think an attribute without a datatype is not a good thing.

2. rendition/@scope has no @type on its valList. It should have one, I 
think, and it looks like it ought to be closed, because the values are 
taken from CSS pseudo-classes.

3. moduleSpec/@type has only been partially defined. the valDesc 
suggests it should be a closed valList, but there is no valList. It 
looks as though work on this was interrupted half-way through.

===========ATTRIBUTES WITH NO DATATYPE======================

63   @dim       <space>              valList (closed)

74   @eol       <hyphenation>        valList (closed)

75   @evaluate  att.pointing         valList (closed)

86   @feature   <shift>              valList (closed)

92   @form      <quotation> [no valDesc or valList; deprecated]

102   @full     att.personal         valList (closed)

143   @level    <title>              valList (closed)

148   @location <variantEncoding>    valList (closed)

165-  @method   <correction>,        valList (closed)
  167            <normalization>,
                 <variantEncoding>

172-  @mode     <channel>,           valList (closed)
  177            <alt>,
                 <altGrp>,
                 <classes>,
                 <memberOf>,
                 att.combinable

207   @ord      <tree> 	             valList (closed)

213-  @org      att.divLike,         valList (closed)
  216            <vColl>,
                 <vMerge>,
                 <attList>

225-  @part     att.divLike,         valList (closed)
  228            att.segLike,
                 <l>,
                 <ab>

275   @sample   att.divLike          valList (closed)

278   @scheme   <rendition>          valList (closed)

288   @scheme   <tag>                valList (open) <----------
	
289   @scheme   <constraintSpec>     valList (closed)

291   @scope    att.handFeatures     valList (closed)

292   @scope    <rendition>          valList ()     <----------
	
293   @scope    <join>               valList (closed)

320-  @status   <availability>,      valList (closed)
  322            <correction>,
                 att.identified

353   @trans    <u>                  valList (closed)

376,  @type     <tech>,              valList (closed)
  377,           <recording>,
  394,           <constitution>,
  397,           <factuality>,
  398,           <interaction>
  408,           <tag>
  410,           <classSpec>
  411,           <macroSpec>
  412            <valList>

409   @type     <moduleSpec>         valDesc: A closed <----------
                                      set of keywords
                                      yet to be defined

426   @usage    <attDef>             valList (closed)

427   @valid    <egXML>              valList (closed)

467 @xml:space  att.global           valList (closed)

=====================================================

Cheers,
Martin

On 12-02-08 09:24 AM, James Cummings wrote:
> On 08/02/12 13:38, Martin Holmes wrote:
>> But now I'm wondering why<gi>   has a<datatype>   and<tag>   doesn't. In
>> fact, I'm wondering why so many attributes in the list lack a datatype.
>> They all seem to be attributes which should be data.enumerated.
>
> It does seem to happen with attributes which I would suspect
> should be data.enumerated.
>
>> Is this just a historical accident, or is there some reason or pattern
>> to it?
>
> In all the cases I looked at the attribute values were a closed
> value list with very specific values.  Perhaps these should be
> made data.enumerated with a closed value list?
>
> -James
>

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From James.Cummings at oucs.ox.ac.uk  Thu Feb  9 05:58:29 2012
From: James.Cummings at oucs.ox.ac.uk (James Cummings)
Date: Thu, 09 Feb 2012 10:58:29 +0000
Subject: [tei-council] Question
	about	attribute	definitions	and	descriptions
In-Reply-To: <4F32CC64.5040005@uvic.ca>
References: <4F31FB32.6040808@uvic.ca>	<4F324A32.2050600@retired.ox.ac.uk>	<4F327AF0.4090900@uvic.ca>	<4F32AFE2.60606@oucs.ox.ac.uk>
	<4F32CC64.5040005@uvic.ca>
Message-ID: <4F33A6D5.2000604@oucs.ox.ac.uk>

On 08/02/12 19:26, Martin Holmes wrote:
> 1. Should all attributes with a closed valList be specified as
> data.enumerated? "data.enumerated defines the range of attribute values
> expressed as a single XML name taken from a list of documented
> possibilities." This (to my reading) doesn't specify whether the list of
> possibilities is closed or open, so I think it can/should apply to
> closed valLists as well. If it doesn't, we need another datatype that
> does, because I think an attribute without a datatype is not a good thing.

IMHO, all attributes, where they aren't some other datatype for 
some reason, but consist of a documented list of XML names should 
be data.enumerated.  I.e. if they are something else, fine.  If 
they aren't a documented list, then they are data.word or 
something, for the datatype it doesn't matter if the list is open 
or closed.  Having a datatype is definitely better than not 
having one.

> 2. rendition/@scope has no @type on its valList. It should have one, I
> think, and it looks like it ought to be closed, because the values are
> taken from CSS pseudo-classes.

Currently the reference page says 'Sample values include' because 
it isn't closed.  If we do make this closed, it would have to 
contain all the CSS pseudo-elements from any version of the CSS 
spec.  I *think* this is limited to:active, after, before, 
first-child, first-letter, first-line, focus, hover, lang(en), 
link, and visited. However, I think we'd need a volunteer to go 
back to the CSS specs and make sure I'm not missing any.  The 
thing to decide, I guess, is whether it is an error to supply a 
value here which is not one of those?

> 3. moduleSpec/@type has only been partially defined. the valDesc
> suggests it should be a closed valList, but there is no valList. It
> looks as though work on this was interrupted half-way through.

I'm not sure. Although the TEI may have need for a closed set of 
values here, remember that ODD can be used entirely separate from 
the TEI.  Is there a consistent set of moduleSpec type 
categorisations which don't limit other uses of it?  As far as I 
can tell the TEI itself, in the production of the Guidelines or 
our exemplar ODDs, do not use @type on moduleSpec.  (Can someone 
correct me on this?)

<gap reason="snipped"><desc>list of attributes without dataypes 
snipped</desc></gap>

-James


-- 
Dr James Cummings, InfoDev,
Computing Services, University of Oxford

From mholmes at uvic.ca  Thu Feb  9 08:30:56 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Thu, 09 Feb 2012 05:30:56 -0800
Subject: [tei-council] Question about attribute definitions and
	descriptions
In-Reply-To: <4F33A6D5.2000604@oucs.ox.ac.uk>
References: <4F31FB32.6040808@uvic.ca>	<4F324A32.2050600@retired.ox.ac.uk>	<4F327AF0.4090900@uvic.ca>	<4F32AFE2.60606@oucs.ox.ac.uk>	<4F32CC64.5040005@uvic.ca>
	<4F33A6D5.2000604@oucs.ox.ac.uk>
Message-ID: <4F33CA90.1040102@uvic.ca>

On 12-02-09 02:58 AM, James Cummings wrote:
> On 08/02/12 19:26, Martin Holmes wrote:
>> 1. Should all attributes with a closed valList be specified as
>> data.enumerated? "data.enumerated defines the range of attribute values
>> expressed as a single XML name taken from a list of documented
>> possibilities." This (to my reading) doesn't specify whether the list of
>> possibilities is closed or open, so I think it can/should apply to
>> closed valLists as well. If it doesn't, we need another datatype that
>> does, because I think an attribute without a datatype is not a good thing.
>
> IMHO, all attributes, where they aren't some other datatype for
> some reason, but consist of a documented list of XML names should
> be data.enumerated.  I.e. if they are something else, fine.  If
> they aren't a documented list, then they are data.word or
> something, for the datatype it doesn't matter if the list is open
> or closed.  Having a datatype is definitely better than not
> having one.

In that case, I'll go through them all and make them data.enumerated, 
unless anyone raises an objection in the next few hours.

>> 2. rendition/@scope has no @type on its valList. It should have one, I
>> think, and it looks like it ought to be closed, because the values are
>> taken from CSS pseudo-classes.
>
> Currently the reference page says 'Sample values include' because
> it isn't closed.  If we do make this closed, it would have to
> contain all the CSS pseudo-elements from any version of the CSS
> spec.  I *think* this is limited to:active, after, before,
> first-child, first-letter, first-line, focus, hover, lang(en),
> link, and visited. However, I think we'd need a volunteer to go
> back to the CSS specs and make sure I'm not missing any.  The
> thing to decide, I guess, is whether it is an error to supply a
> value here which is not one of those?

Given the ref page text, I guess I was wrong; it should be open. CSS 
pseudo elements are likely to proliferate, so it would be potentially 
obstructive to close the list.

>> 3. moduleSpec/@type has only been partially defined. the valDesc
>> suggests it should be a closed valList, but there is no valList. It
>> looks as though work on this was interrupted half-way through.
>
> I'm not sure. Although the TEI may have need for a closed set of
> values here, remember that ODD can be used entirely separate from
> the TEI.  Is there a consistent set of moduleSpec type
> categorisations which don't limit other uses of it?  As far as I
> can tell the TEI itself, in the production of the Guidelines or
> our exemplar ODDs, do not use @type on moduleSpec.  (Can someone
> correct me on this?)

I take the point, but it seems unintuitive to specify that the list is 
closed, and yet not be able or willing to provide the values. Surely if 
someone else can take the ODD spec and do something different with it, 
and they need to use their own values, then the list is actually open?

Cheers,
Martin

> <gap reason="snipped"><desc>list of attributes without dataypes
> snipped</desc></gap>
>
> -James
>
>

From sebastian.rahtz at oucs.ox.ac.uk  Thu Feb  9 08:53:16 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Thu, 9 Feb 2012 13:53:16 +0000
Subject: [tei-council] Question about attribute definitions
	and	descriptions
In-Reply-To: <4F33CA90.1040102@uvic.ca>
References: <4F31FB32.6040808@uvic.ca>	<4F324A32.2050600@retired.ox.ac.uk>
	<4F327AF0.4090900@uvic.ca>	<4F32AFE2.60606@oucs.ox.ac.uk>
	<4F32CC64.5040005@uvic.ca>	<4F33A6D5.2000604@oucs.ox.ac.uk>
	<4F33CA90.1040102@uvic.ca>
Message-ID: <4567BE20-DE9D-4407-BFA0-D0FB36E3BF53@oucs.ox.ac.uk>

we have one instance of moduleSpec/@type, viz 

<moduleSpec xml:id="DSTTEI2" ident="tei" type="core">

I suggest removing the valDesc and simply make moduleSpec a member of att. typed.
I agree that it looks like unfinished work, and in its present state is confusing
--
Stormageddon Rahtz      
Head of Information and Support Group
Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431

S?lo le pido a Dios
que el futuro no me sea indiferente


From mholmes at uvic.ca  Thu Feb  9 13:04:10 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Thu, 9 Feb 2012 10:04:10 -0800
Subject: [tei-council] Question about attribute definitions
	and	descriptions
In-Reply-To: <4F33CA90.1040102@uvic.ca>
References: <4F31FB32.6040808@uvic.ca>	<4F324A32.2050600@retired.ox.ac.uk>	<4F327AF0.4090900@uvic.ca>	<4F32AFE2.60606@oucs.ox.ac.uk>	<4F32CC64.5040005@uvic.ca>	<4F33A6D5.2000604@oucs.ox.ac.uk>
	<4F33CA90.1040102@uvic.ca>
Message-ID: <4F340A9A.4050806@uvic.ca>

I've added datatypes to all the non-controversial ones. The one 
outstanding issue is moduleSpec, as Sebastian says:

> we have one instance of moduleSpec/@type, viz
>
> <moduleSpec xml:id="DSTTEI2" ident="tei" type="core">
>
> I suggest removing the valDesc and simply make moduleSpec a member of att. typed.
> I agree that it looks like unfinished work, and in its present state is confusing

I'm going to raise a ticket for that, because it's potentially a bit thorny.

Can't tell at the moment whether my changes have broken anything, 
because builds are currently broken anyway -- Sebastian, shall we revert 
your changes to Makefile to allow builds to go ahead, while we figure 
out a different solution to the p5subset.xml problem?

Cheers,
Martin

On 12-02-09 05:30 AM, Martin Holmes wrote:
> On 12-02-09 02:58 AM, James Cummings wrote:
>> On 08/02/12 19:26, Martin Holmes wrote:
>>> 1. Should all attributes with a closed valList be specified as
>>> data.enumerated? "data.enumerated defines the range of attribute values
>>> expressed as a single XML name taken from a list of documented
>>> possibilities." This (to my reading) doesn't specify whether the list of
>>> possibilities is closed or open, so I think it can/should apply to
>>> closed valLists as well. If it doesn't, we need another datatype that
>>> does, because I think an attribute without a datatype is not a good thing.
>>
>> IMHO, all attributes, where they aren't some other datatype for
>> some reason, but consist of a documented list of XML names should
>> be data.enumerated.  I.e. if they are something else, fine.  If
>> they aren't a documented list, then they are data.word or
>> something, for the datatype it doesn't matter if the list is open
>> or closed.  Having a datatype is definitely better than not
>> having one.
>
> In that case, I'll go through them all and make them data.enumerated,
> unless anyone raises an objection in the next few hours.
>
>>> 2. rendition/@scope has no @type on its valList. It should have one, I
>>> think, and it looks like it ought to be closed, because the values are
>>> taken from CSS pseudo-classes.
>>
>> Currently the reference page says 'Sample values include' because
>> it isn't closed.  If we do make this closed, it would have to
>> contain all the CSS pseudo-elements from any version of the CSS
>> spec.  I *think* this is limited to:active, after, before,
>> first-child, first-letter, first-line, focus, hover, lang(en),
>> link, and visited. However, I think we'd need a volunteer to go
>> back to the CSS specs and make sure I'm not missing any.  The
>> thing to decide, I guess, is whether it is an error to supply a
>> value here which is not one of those?
>
> Given the ref page text, I guess I was wrong; it should be open. CSS
> pseudo elements are likely to proliferate, so it would be potentially
> obstructive to close the list.
>
>>> 3. moduleSpec/@type has only been partially defined. the valDesc
>>> suggests it should be a closed valList, but there is no valList. It
>>> looks as though work on this was interrupted half-way through.
>>
>> I'm not sure. Although the TEI may have need for a closed set of
>> values here, remember that ODD can be used entirely separate from
>> the TEI.  Is there a consistent set of moduleSpec type
>> categorisations which don't limit other uses of it?  As far as I
>> can tell the TEI itself, in the production of the Guidelines or
>> our exemplar ODDs, do not use @type on moduleSpec.  (Can someone
>> correct me on this?)
>
> I take the point, but it seems unintuitive to specify that the list is
> closed, and yet not be able or willing to provide the values. Surely if
> someone else can take the ODD spec and do something different with it,
> and they need to use their own values, then the list is actually open?
>
> Cheers,
> Martin
>
>> <gap reason="snipped"><desc>list of attributes without dataypes
>> snipped</desc></gap>
>>
>> -James
>>
>>

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From sebastian.rahtz at oucs.ox.ac.uk  Thu Feb  9 18:04:20 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Thu, 9 Feb 2012 23:04:20 +0000
Subject: [tei-council] Question about attribute
	definitions	and	descriptions
In-Reply-To: <4F340A9A.4050806@uvic.ca>
References: <4F31FB32.6040808@uvic.ca>	<4F324A32.2050600@retired.ox.ac.uk>
	<4F327AF0.4090900@uvic.ca>	<4F32AFE2.60606@oucs.ox.ac.uk>
	<4F32CC64.5040005@uvic.ca>	<4F33A6D5.2000604@oucs.ox.ac.uk>
	<4F33CA90.1040102@uvic.ca> <4F340A9A.4050806@uvic.ca>
Message-ID: <BC036331-45E7-4AC1-B808-12B97FB6A107@oucs.ox.ac.uk>


On 9 Feb 2012, at 18:04, Martin Holmes wrote:

> 
> Can't tell at the moment whether my changes have broken anything, 
> because builds are currently broken anyway -- Sebastian, shall we revert 
> your changes to Makefile to allow builds to go ahead, while we figure 
> out a different solution to the p5subset.xml problem?
> 
just trying to fix that now

--
Stormageddon Rahtz      
Head of Information and Support Group, Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431

S?lo le pido a Dios
que el futuro no me sea indiferente


From gabriel.bodard at kcl.ac.uk  Fri Feb 10 12:37:33 2012
From: gabriel.bodard at kcl.ac.uk (Gabriel Bodard)
Date: Fri, 10 Feb 2012 17:37:33 +0000
Subject: [tei-council] TEI-C irc channel
Message-ID: <4F3555DD.8080308@kcl.ac.uk>

Hey, for the first time I've noticed in the ten months I've been 
regularly signed into the TEI-C irc channel (irc://freenode/TEI-C), two 
non-council users have logged in today to ask technical questions. At 
least one was someone who is not on TEI-L and claimed not to like 
mailing lists.

If this is starting to become a habit, it might be useful if other 
Council members hung around from time to time, because many of you will 
be better able to answer some questions than I am. (Although James is 
usually in there too, today he was apparently busy elsewhere.)

Seem reasonable? Or a one-off?

G

-- 
Dr Gabriel BODARD
(Research Associate in Digital Epigraphy)

Department of Digital Humanities
King's College London
26-29 Drury Lane
London WC2B 5RL

Email: gabriel.bodard at kcl.ac.uk
Tel: +44 (0)20 7848 1388
Fax: +44 (0)20 7848 2980

http://www.digitalclassicist.org/
http://www.currentepigraphy.org/

From James.Cummings at oucs.ox.ac.uk  Sat Feb 11 05:06:27 2012
From: James.Cummings at oucs.ox.ac.uk (James Cummings)
Date: Sat, 11 Feb 2012 10:06:27 +0000
Subject: [tei-council] TEI-C irc channel
In-Reply-To: <4F3555DD.8080308@kcl.ac.uk>
References: <4F3555DD.8080308@kcl.ac.uk>
Message-ID: <4F363DA3.80409@oucs.ox.ac.uk>


Hi Gaby (et al.),


Yes, I'm auto-logged into that IRC channel _most_ of the time. 
Even when I'm asleep.  So quite often I'm not physically present. 
;-)

Those logging in who are not related to board/council does happen 
sometimes and I think should be encouraged. I know I've answered 
questions there occasionally from people on freenode.net wanting 
to know something about the TEI. (One of the users that Gaby so 
deftly answered has definitely popped in before to ask questions.)

Information on the TEI-C IRC channel and how to use it is 
available on the wiki at:

http://wiki.tei-c.org/index.php/IRC

(feel free to update... I wrote most of it in 2005....)

Although IRC is a fairly erm... mature... technology, lots of 
software packages and other markup languages (e.g. docbook) have 
channels on freenode.net for public discussion and support.

-James


On 10/02/12 17:37, Gabriel Bodard wrote:
> Hey, for the first time I've noticed in the ten months I've been
> regularly signed into the TEI-C irc channel (irc://freenode/TEI-C), two
> non-council users have logged in today to ask technical questions. At
> least one was someone who is not on TEI-L and claimed not to like
> mailing lists.
>
> If this is starting to become a habit, it might be useful if other
> Council members hung around from time to time, because many of you will
> be better able to answer some questions than I am. (Although James is
> usually in there too, today he was apparently busy elsewhere.)
>
> Seem reasonable? Or a one-off?
>
> G
>


-- 
Dr James Cummings, InfoDev,
Computing Services, University of Oxford

From James.Cummings at oucs.ox.ac.uk  Sat Feb 11 07:55:16 2012
From: James.Cummings at oucs.ox.ac.uk (James Cummings)
Date: Sat, 11 Feb 2012 12:55:16 +0000
Subject: [tei-council] TEI Council Teleconference: 28 Feb 18:00 GMT
Message-ID: <4F366534.7050501@oucs.ox.ac.uk>

Dear all,

According to the doodle poll 
http://www.doodle.com/6akx9cqy2zdcbdkn the best dateTime for a 
teleconference is Tuesday 28 February at 18:00 GMT. Please triple 
check what time and date this is for you at
http://www.timeanddate.com/worldclock/fixedtime.html?msg=TEI+Council+Teleconference&iso=20120228T18&p1=1233 


I'll circulate details of the conferencing system closer to the date.

If anyone has suggestions for items for the agenda, feel free to 
either email me or the mailing list.

-James

-- 
Dr James Cummings, InfoDev,
Computing Services, University of Oxford

From kevin.s.hawkins at ultraslavonic.info  Sun Feb 12 10:44:17 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Sun, 12 Feb 2012 10:44:17 -0500
Subject: [tei-council] updated list of Council members etc. for P5
Message-ID: <4F37DE51.4020509@ultraslavonic.info>

Colleagues,

I am finally getting around to implementing FR 3041605:

http://purl.org/TEI/fr/3041605

I've just posted two comments on the ticket with my proposed changes. 
There are a few outstanding questions there that someone with good 
institutional memory (I'm looking at you, Lou) might be able to help with:

* Which members were on the Board by virtue of being Board Chair and 
which there there as appointed members?

* Was Alejandro Bia replaced when he resigned?

* When were the positions of Editors created?

This whole thing has led me to wonder how exactly we ended up electing 6 
and 4 Council members in alternating years.  This practice dates to 
2002, but I can't figure out how it got started.

--Kevin

From sebastian.rahtz at oucs.ox.ac.uk  Sun Feb 12 11:08:42 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Sun, 12 Feb 2012 16:08:42 +0000
Subject: [tei-council] updated list of Council members etc. for P5
In-Reply-To: <4F37DE51.4020509@ultraslavonic.info>
References: <4F37DE51.4020509@ultraslavonic.info>
Message-ID: <252F6DCE-AECF-453D-9B75-F118D5A8E138@oucs.ox.ac.uk>


On 12 Feb 2012, at 15:44, Kevin Hawkins wrote:

> 
> * Which members were on the Board by virtue of being Board Chair and 
> which there there as appointed members?

I was the sole appointed member from 2001 to 2009. John, Julia, Matt, Dan and Martin were
as council chairs

> 
> * Was Alejandro Bia replaced when he resigned?
> 
that I cant remember

> * When were the positions of Editors created?
> 
in the formation of TEI-C in 2000.

> This whole thing has led me to wonder how exactly we ended up electing 6 
> and 4 Council members in alternating years.  This practice dates to 
> 2002, but I can't figure out how it got started.
> 					
I fear I cant remember offhand

--
Stormageddon Rahtz      
Head of Information and Support Group, Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431

S?lo le pido a Dios
que el futuro no me sea indiferente


From lou.burnard at retired.ox.ac.uk  Sun Feb 12 12:59:20 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Sun, 12 Feb 2012 17:59:20 +0000
Subject: [tei-council] updated list of Council members etc. for P5
In-Reply-To: <252F6DCE-AECF-453D-9B75-F118D5A8E138@oucs.ox.ac.uk>
References: <4F37DE51.4020509@ultraslavonic.info>
	<252F6DCE-AECF-453D-9B75-F118D5A8E138@oucs.ox.ac.uk>
Message-ID: <4F37FDF8.5090800@retired.ox.ac.uk>

On 12/02/12 16:08, Sebastian Rahtz wrote:
>
> On 12 Feb 2012, at 15:44, Kevin Hawkins wrote:
>
>>
>> * Which members were on the Board by virtue of being Board Chair and
>> which there there as appointed members?
>
> I was the sole appointed member from 2001 to 2009. John, Julia, Matt, Dan and Martin were
> as council chairs


I think my esteemed colleague means to say

"Sebastian was appointed to the Council by the Board; John Julia Matt 
Dan and Martin as Board chairs were ex officio members of the Council"

>
>>
>> * Was Alejandro Bia replaced when he resigned?
>>
> that I cant remember

I think he was, but I cannot remember by whom. This would require some 
research... is it important?

>
>> * When were the positions of Editors created?
>>
> in the formation of TEI-C in 2000.

Nonsense. The position of TEI Editor predates the existence of the 
Consortium by many many years.

>
>> This whole thing has led me to wonder how exactly we ended up electing 6
>> and 4 Council members in alternating years.  This practice dates to
>> 2002, but I can't figure out how it got started.
>> 					
> I fear I cant remember offhand


Which "whole thing" would that be? I think it's probably a consequence 
of the number of vacancies in year x being different from that in year 
y, coupled with the term of office?




>
> --
> Stormageddon Rahtz
> Head of Information and Support Group, Oxford University Computing Services
> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>
> S?lo le pido a Dios
> que el futuro no me sea indiferente
>


From mholmes at uvic.ca  Sun Feb 12 13:28:24 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Sun, 12 Feb 2012 10:28:24 -0800
Subject: [tei-council] updated list of Council members etc. for P5
In-Reply-To: <4F37DE51.4020509@ultraslavonic.info>
References: <4F37DE51.4020509@ultraslavonic.info>
Message-ID: <4F3804C8.6070200@uvic.ca>

I see I also had a task on this ticket, which I've shamefully neglected. 
As far as figuring out how to encode a person-base, I don't think 
there's anything complicated involved, but I think everyone (past and 
present members) will have to agree on what information about them may 
be included, and we'll need a mechanism for updating the info 
periodically. I'll try to have something ready for the teleconference.

Cheers,
Martin

On 12-02-12 07:44 AM, Kevin Hawkins wrote:
> Colleagues,
>
> I am finally getting around to implementing FR 3041605:
>
> http://purl.org/TEI/fr/3041605
>
> I've just posted two comments on the ticket with my proposed changes.
> There are a few outstanding questions there that someone with good
> institutional memory (I'm looking at you, Lou) might be able to help with:
>
> * Which members were on the Board by virtue of being Board Chair and
> which there there as appointed members?
>
> * Was Alejandro Bia replaced when he resigned?
>
> * When were the positions of Editors created?
>
> This whole thing has led me to wonder how exactly we ended up electing 6
> and 4 Council members in alternating years.  This practice dates to
> 2002, but I can't figure out how it got started.
>
> --Kevin

From sebastian.rahtz at oucs.ox.ac.uk  Sun Feb 12 14:21:26 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Sun, 12 Feb 2012 19:21:26 +0000
Subject: [tei-council] updated list of Council members etc. for P5
In-Reply-To: <4F37FDF8.5090800@retired.ox.ac.uk>
References: <4F37DE51.4020509@ultraslavonic.info>
	<252F6DCE-AECF-453D-9B75-F118D5A8E138@oucs.ox.ac.uk>
	<4F37FDF8.5090800@retired.ox.ac.uk>
Message-ID: <3C89BE68-D1D3-4241-BC28-6013BBD16632@oucs.ox.ac.uk>


On 12 Feb 2012, at 17:59, Lou Burnard wrote:

> I think my esteemed colleague means to say
> 
> "Sebastian was appointed to the Council by the Board; John Julia Matt 
> Dan and Martin as Board chairs were ex officio members of the Council"
> 
krekt


>> in the formation of TEI-C in 2000.
> 
> Nonsense. The position of TEI Editor predates the existence of the 
> Consortium by many many years.
> 
yes. but the pre-TEIC editors were in a different world. what I meant was that the editors
were built into TEIC from its start


--
Stormageddon Rahtz      
Head of Information and Support Group, Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431

S?lo le pido a Dios
que el futuro no me sea indiferente


From kevin.s.hawkins at ultraslavonic.info  Sun Feb 12 15:43:18 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Sun, 12 Feb 2012 15:43:18 -0500
Subject: [tei-council] updated list of Council members etc. for P5
In-Reply-To: <3C89BE68-D1D3-4241-BC28-6013BBD16632@oucs.ox.ac.uk>
References: <4F37DE51.4020509@ultraslavonic.info>
	<252F6DCE-AECF-453D-9B75-F118D5A8E138@oucs.ox.ac.uk>
	<4F37FDF8.5090800@retired.ox.ac.uk>
	<3C89BE68-D1D3-4241-BC28-6013BBD16632@oucs.ox.ac.uk>
Message-ID: <4F382466.6070506@ultraslavonic.info>

Thanks for the quick responses ...

On 2/12/12 12:59 PM, Lou Burnard wrote:
 >>> * Was Alejandro Bia replaced when he resigned?
 >>>
 >> that I cant remember
 >
 > I think he was, but I cannot remember by whom. This would require some
 > research... is it important?

Only because I want to make sure that if someone filled out his term, 
this is acknowledged in the list.

 >>> This whole thing has led me to wonder how exactly we ended up 
electing 6
 >>> and 4 Council members in alternating years.  This practice dates to
 >>> 2002, but I can't figure out how it got started.
 >>> 					
 >> I fear I cant remember offhand
 >
 >
 > Which "whole thing" would that be? I think it's probably a consequence
 > of the number of vacancies in year x being different from that in year
 > y, coupled with the term of office?

The "whole thing" is revising FM1.  In going through the TEI-L archives 
and especially minutes of past business meetings, I see that we've 
alternated between 6 and 4 people from as far back as I can find record 
of elections to Council.  It implies that when the Council was first 
constituted, we didn't evenly divide its membership into one- and 
two-year terms.  I find this suspicious and wonder if the solution could 
reveal an error of some sort in the list of Council members in FM1.  But 
I'm not going to worry about it.

On 2/12/12 2:21 PM, Sebastian Rahtz wrote:
>>> in the formation of TEI-C in 2000.
>>
>> Nonsense. The position of TEI Editor predates the existence of the
>> Consortium by many many years.
>>
> yes. but the pre-TEIC editors were in a different world. what I meant was that the editors
> were built into TEIC from its start

Right, the sentence in need of revision deals with editors serving ex 
officio on the Council.  Were the editors (2000-08) appointed by the 
Board?  Elected by the TEI-C membership?  Something else?  This affects 
how I would revise the sentence for clarity.


From mholmes at uvic.ca  Mon Feb 13 10:47:59 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Mon, 13 Feb 2012 07:47:59 -0800
Subject: [tei-council] Release process documentation
Message-ID: <4F3930AF.5040701@uvic.ca>

Hi all,

I've made one more change to the release process documentation document, 
TCW22, to add a 17th step relating to the Stylesheets, and arising out 
of our experience cleaning up after the last release. I've also edited 
TCW20 to remove the content of the section on Building a Release, and 
replace it with a link to the new document. The two working papers are here:

<http://www.tei-c.org/Activities/Council/Working/tcw20.xml>
<http://www.tei-c.org/Activities/Council/Working/tcw22.xml>

I think that concludes the work arising out of the 2.0.2 release, and I 
think we're now in good shape for Gaby to work through TWC22 when he 
does the next one. Because it's so tricky (well, it's impossible, 
really) to fully test the process without actually doing it for real, we 
won't be really sure that the changes we made to avoid the problems we 
had last time are really effective until the next release, but it should 
be much smoother next time around.

Cheers,
Martin

From bansp at o2.pl  Mon Feb 13 11:00:37 2012
From: bansp at o2.pl (=?ISO-8859-2?Q?Piotr_Ba=F1ski?=)
Date: Mon, 13 Feb 2012 17:00:37 +0100
Subject: [tei-council] Release process documentation
In-Reply-To: <4F3930AF.5040701@uvic.ca>
References: <4F3930AF.5040701@uvic.ca>
Message-ID: <4F3933A5.4030301@o2.pl>

Hi Martin,

Thanks for putting the doc together, it's going to be very useful. I
wonder, maybe it makes sense to encourage local validation before
waiting for Jenkins to finish, as in the e-mail by Sebastian:

http://lists.village.virginia.edu/pipermail/tei-council/2011/013232.html

Best,

  P.

On 13/02/12 16:47, Martin Holmes wrote:
> Hi all,
> 
> I've made one more change to the release process documentation document, 
> TCW22, to add a 17th step relating to the Stylesheets, and arising out 
> of our experience cleaning up after the last release. I've also edited 
> TCW20 to remove the content of the section on Building a Release, and 
> replace it with a link to the new document. The two working papers are here:
> 
> <http://www.tei-c.org/Activities/Council/Working/tcw20.xml>
> <http://www.tei-c.org/Activities/Council/Working/tcw22.xml>
> 
> I think that concludes the work arising out of the 2.0.2 release, and I 
> think we're now in good shape for Gaby to work through TWC22 when he 
> does the next one. Because it's so tricky (well, it's impossible, 
> really) to fully test the process without actually doing it for real, we 
> won't be really sure that the changes we made to avoid the problems we 
> had last time are really effective until the next release, but it should 
> be much smoother next time around.
> 
> Cheers,
> Martin


From bansp at o2.pl  Mon Feb 13 11:18:50 2012
From: bansp at o2.pl (=?ISO-8859-2?Q?Piotr_Ba=F1ski?=)
Date: Mon, 13 Feb 2012 17:18:50 +0100
Subject: [tei-council] Release process documentation
In-Reply-To: <4F3933A5.4030301@o2.pl>
References: <4F3930AF.5040701@uvic.ca> <4F3933A5.4030301@o2.pl>
Message-ID: <4F3937EA.4080600@o2.pl>

Or maybe this info belongs rather at

http://www.tei-c.org/Activities/Council/Working/tcw20.xml#body.1_div.4

where p5odds.rnc is mentioned, but it doesn't say how to derive it
("make oddschema").

  P.

On 13/02/12 17:00, Piotr Ba?ski wrote:
> Hi Martin,
> 
> Thanks for putting the doc together, it's going to be very useful. I
> wonder, maybe it makes sense to encourage local validation before
> waiting for Jenkins to finish, as in the e-mail by Sebastian:
> 
> http://lists.village.virginia.edu/pipermail/tei-council/2011/013232.html
> 
> Best,
> 
>   P.
> 
> On 13/02/12 16:47, Martin Holmes wrote:
>> Hi all,
>>
>> I've made one more change to the release process documentation document, 
>> TCW22, to add a 17th step relating to the Stylesheets, and arising out 
>> of our experience cleaning up after the last release. I've also edited 
>> TCW20 to remove the content of the section on Building a Release, and 
>> replace it with a link to the new document. The two working papers are here:
>>
>> <http://www.tei-c.org/Activities/Council/Working/tcw20.xml>
>> <http://www.tei-c.org/Activities/Council/Working/tcw22.xml>
>>
>> I think that concludes the work arising out of the 2.0.2 release, and I 
>> think we're now in good shape for Gaby to work through TWC22 when he 
>> does the next one. Because it's so tricky (well, it's impossible, 
>> really) to fully test the process without actually doing it for real, we 
>> won't be really sure that the changes we made to avoid the problems we 
>> had last time are really effective until the next release, but it should 
>> be much smoother next time around.
>>
>> Cheers,
>> Martin
> 


From sebastian.rahtz at oucs.ox.ac.uk  Mon Feb 13 11:26:33 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Mon, 13 Feb 2012 16:26:33 +0000
Subject: [tei-council] Release process documentation
In-Reply-To: <4F3937EA.4080600@o2.pl>
References: <4F3930AF.5040701@uvic.ca> <4F3933A5.4030301@o2.pl>
	<4F3937EA.4080600@o2.pl>
Message-ID: <CE44EE83-DB13-4D76-877B-613B4AD45BE3@oucs.ox.ac.uk>


On 13 Feb 2012, at 16:18, Piotr Ba?ski wrote:

> Or maybe this info belongs rather at
> 
> http://www.tei-c.org/Activities/Council/Working/tcw20.xml#body.1_div.4
> 
> where p5odds.rnc is mentioned, but it doesn't say how to derive it
> ("make oddschema").


I now think we should tweak P5 to deliver p5odds.rnc, so that its referenceable from
www.tei-c.org. I'll look at that for the next release.

but it does say how to derive it - "make oddschema" mean
type the command "make oddschema" in the P5 source directory,
on a *Nix command line
--
Stormageddon Rahtz      
Head of Information and Support Group
Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431

S?lo le pido a Dios
que el futuro no me sea indiferente


From mholmes at uvic.ca  Mon Feb 13 11:29:22 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Mon, 13 Feb 2012 08:29:22 -0800
Subject: [tei-council] Release process documentation
In-Reply-To: <4F3933A5.4030301@o2.pl>
References: <4F3930AF.5040701@uvic.ca> <4F3933A5.4030301@o2.pl>
Message-ID: <4F393A62.8080609@uvic.ca>

Hi Piotr,

I thought about this, but there is some risk that a local installation 
of the TEI infrastructure might not be fully updated. Sebastian releases 
regular updates to the Debian and Oxygen packages, and obviously keeps 
his Jenkins server updated; he also informs me about any changes such as 
new packages which need to be added, and I try to keep mine in sync too, 
so the two act as a check on each other.

If someone did a local build, and encountered errors, they wouldn't 
necessarily know whether the errors were caused by their local install 
of TEI being slightly out of sync, or whether the errors were real. So 
on balance, relying on the Jinks servers (especially now there are two 
of them) seems the more solid option.

Cheers,
Martin

On 12-02-13 08:00 AM, Piotr Ba?ski wrote:
> Hi Martin,
>
> Thanks for putting the doc together, it's going to be very useful. I
> wonder, maybe it makes sense to encourage local validation before
> waiting for Jenkins to finish, as in the e-mail by Sebastian:
>
> http://lists.village.virginia.edu/pipermail/tei-council/2011/013232.html
>
> Best,
>
>    P.
>
> On 13/02/12 16:47, Martin Holmes wrote:
>> Hi all,
>>
>> I've made one more change to the release process documentation document,
>> TCW22, to add a 17th step relating to the Stylesheets, and arising out
>> of our experience cleaning up after the last release. I've also edited
>> TCW20 to remove the content of the section on Building a Release, and
>> replace it with a link to the new document. The two working papers are here:
>>
>> <http://www.tei-c.org/Activities/Council/Working/tcw20.xml>
>> <http://www.tei-c.org/Activities/Council/Working/tcw22.xml>
>>
>> I think that concludes the work arising out of the 2.0.2 release, and I
>> think we're now in good shape for Gaby to work through TWC22 when he
>> does the next one. Because it's so tricky (well, it's impossible,
>> really) to fully test the process without actually doing it for real, we
>> won't be really sure that the changes we made to avoid the problems we
>> had last time are really effective until the next release, but it should
>> be much smoother next time around.
>>
>> Cheers,
>> Martin
>

From bansp at o2.pl  Mon Feb 13 12:56:12 2012
From: bansp at o2.pl (=?ISO-8859-2?Q?Piotr_Ba=F1ski?=)
Date: Mon, 13 Feb 2012 18:56:12 +0100
Subject: [tei-council] Release process documentation
In-Reply-To: <4F393A62.8080609@uvic.ca>
References: <4F3930AF.5040701@uvic.ca> <4F3933A5.4030301@o2.pl>
	<4F393A62.8080609@uvic.ca>
Message-ID: <4F394EBC.3000402@o2.pl>

Frankly, being mostly an end user of SVN, with its sacred policy of
"sync before you start your work", I'm a bit lost when it comes to the
interaction of SVN and continuous integration. I'm just wondering
whether, if we neglect telling the user (Council member, etc.) to sync
before work, we risk that other people's additions may get lost, given
that they go via SVN. I really don't see the whole picture here -- maybe
it's worth a note by a specialist, for paranoid half-trained types like
myself.

:-)

  Piotr

On 13/02/12 17:29, Martin Holmes wrote:
> Hi Piotr,
> 
> I thought about this, but there is some risk that a local installation 
> of the TEI infrastructure might not be fully updated. Sebastian releases 
> regular updates to the Debian and Oxygen packages, and obviously keeps 
> his Jenkins server updated; he also informs me about any changes such as 
> new packages which need to be added, and I try to keep mine in sync too, 
> so the two act as a check on each other.
> 
> If someone did a local build, and encountered errors, they wouldn't 
> necessarily know whether the errors were caused by their local install 
> of TEI being slightly out of sync, or whether the errors were real. So 
> on balance, relying on the Jinks servers (especially now there are two 
> of them) seems the more solid option.
> 
> Cheers,
> Martin
> 
> On 12-02-13 08:00 AM, Piotr Ba?ski wrote:
>> Hi Martin,
>>
>> Thanks for putting the doc together, it's going to be very useful. I
>> wonder, maybe it makes sense to encourage local validation before
>> waiting for Jenkins to finish, as in the e-mail by Sebastian:
>>
>> http://lists.village.virginia.edu/pipermail/tei-council/2011/013232.html
>>
>> Best,
>>
>>    P.
>>
>> On 13/02/12 16:47, Martin Holmes wrote:
>>> Hi all,
>>>
>>> I've made one more change to the release process documentation document,
>>> TCW22, to add a 17th step relating to the Stylesheets, and arising out
>>> of our experience cleaning up after the last release. I've also edited
>>> TCW20 to remove the content of the section on Building a Release, and
>>> replace it with a link to the new document. The two working papers are here:
>>>
>>> <http://www.tei-c.org/Activities/Council/Working/tcw20.xml>
>>> <http://www.tei-c.org/Activities/Council/Working/tcw22.xml>
>>>
>>> I think that concludes the work arising out of the 2.0.2 release, and I
>>> think we're now in good shape for Gaby to work through TWC22 when he
>>> does the next one. Because it's so tricky (well, it's impossible,
>>> really) to fully test the process without actually doing it for real, we
>>> won't be really sure that the changes we made to avoid the problems we
>>> had last time are really effective until the next release, but it should
>>> be much smoother next time around.
>>>
>>> Cheers,
>>> Martin
>>


From bansp at o2.pl  Mon Feb 13 12:58:15 2012
From: bansp at o2.pl (=?ISO-8859-2?Q?Piotr_Ba=F1ski?=)
Date: Mon, 13 Feb 2012 18:58:15 +0100
Subject: [tei-council] Release process documentation
In-Reply-To: <CE44EE83-DB13-4D76-877B-613B4AD45BE3@oucs.ox.ac.uk>
References: <4F3930AF.5040701@uvic.ca>
	<4F3933A5.4030301@o2.pl>	<4F3937EA.4080600@o2.pl>
	<CE44EE83-DB13-4D76-877B-613B4AD45BE3@oucs.ox.ac.uk>
Message-ID: <4F394F37.8070909@o2.pl>

On 13/02/12 17:26, Sebastian Rahtz wrote:
> but it does say how to derive it - "make oddschema" mean
> type the command "make oddschema" in the P5 source directory,
> on a *Nix command line

But "it says" so in your e-mail, not in those docs :-)
(I should have phrased it clearer -- the "make oddschema" was my
suggested addition)

  P.

From mholmes at uvic.ca  Mon Feb 13 13:25:44 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Mon, 13 Feb 2012 10:25:44 -0800
Subject: [tei-council] Release process documentation
In-Reply-To: <4F394EBC.3000402@o2.pl>
References: <4F3930AF.5040701@uvic.ca>
	<4F3933A5.4030301@o2.pl>	<4F393A62.8080609@uvic.ca>
	<4F394EBC.3000402@o2.pl>
Message-ID: <4F3955A8.9010708@uvic.ca>

Hi Piotr,

We would expect anyone managing a release to be fully comfortable with 
editing the source and syncing with SVN. They have to commit changes to 
the VERSION file anyway, to start the process, so if their source tree 
was out of sync, there would be an error there.

If they want to build locally before committing changes, then that's 
fine, but there's no need for it when we have the Jinks servers. I'd 
also rather not get into giving instructions for setting up a build 
environment on your local machine (which might be Windows, Mac or 
Linux), when all that's actually needed is SVN.

Cheers,
Martin

On 12-02-13 09:56 AM, Piotr Ba?ski wrote:
> Frankly, being mostly an end user of SVN, with its sacred policy of
> "sync before you start your work", I'm a bit lost when it comes to the
> interaction of SVN and continuous integration. I'm just wondering
> whether, if we neglect telling the user (Council member, etc.) to sync
> before work, we risk that other people's additions may get lost, given
> that they go via SVN. I really don't see the whole picture here -- maybe
> it's worth a note by a specialist, for paranoid half-trained types like
> myself.
>
> :-)
>
>    Piotr
>
> On 13/02/12 17:29, Martin Holmes wrote:
>> Hi Piotr,
>>
>> I thought about this, but there is some risk that a local installation
>> of the TEI infrastructure might not be fully updated. Sebastian releases
>> regular updates to the Debian and Oxygen packages, and obviously keeps
>> his Jenkins server updated; he also informs me about any changes such as
>> new packages which need to be added, and I try to keep mine in sync too,
>> so the two act as a check on each other.
>>
>> If someone did a local build, and encountered errors, they wouldn't
>> necessarily know whether the errors were caused by their local install
>> of TEI being slightly out of sync, or whether the errors were real. So
>> on balance, relying on the Jinks servers (especially now there are two
>> of them) seems the more solid option.
>>
>> Cheers,
>> Martin
>>
>> On 12-02-13 08:00 AM, Piotr Ba?ski wrote:
>>> Hi Martin,
>>>
>>> Thanks for putting the doc together, it's going to be very useful. I
>>> wonder, maybe it makes sense to encourage local validation before
>>> waiting for Jenkins to finish, as in the e-mail by Sebastian:
>>>
>>> http://lists.village.virginia.edu/pipermail/tei-council/2011/013232.html
>>>
>>> Best,
>>>
>>>     P.
>>>
>>> On 13/02/12 16:47, Martin Holmes wrote:
>>>> Hi all,
>>>>
>>>> I've made one more change to the release process documentation document,
>>>> TCW22, to add a 17th step relating to the Stylesheets, and arising out
>>>> of our experience cleaning up after the last release. I've also edited
>>>> TCW20 to remove the content of the section on Building a Release, and
>>>> replace it with a link to the new document. The two working papers are here:
>>>>
>>>> <http://www.tei-c.org/Activities/Council/Working/tcw20.xml>
>>>> <http://www.tei-c.org/Activities/Council/Working/tcw22.xml>
>>>>
>>>> I think that concludes the work arising out of the 2.0.2 release, and I
>>>> think we're now in good shape for Gaby to work through TWC22 when he
>>>> does the next one. Because it's so tricky (well, it's impossible,
>>>> really) to fully test the process without actually doing it for real, we
>>>> won't be really sure that the changes we made to avoid the problems we
>>>> had last time are really effective until the next release, but it should
>>>> be much smoother next time around.
>>>>
>>>> Cheers,
>>>> Martin
>>>
>

From sebastian.rahtz at oucs.ox.ac.uk  Mon Feb 13 13:32:58 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Mon, 13 Feb 2012 18:32:58 +0000
Subject: [tei-council] Release process documentation
In-Reply-To: <4F394EBC.3000402@o2.pl>
References: <4F3930AF.5040701@uvic.ca> <4F3933A5.4030301@o2.pl>
	<4F393A62.8080609@uvic.ca> <4F394EBC.3000402@o2.pl>
Message-ID: <66126A59-A2CE-4550-93E9-8AB4489E3A55@oucs.ox.ac.uk>


On 13 Feb 2012, at 17:56, Piotr Ba?ski wrote:

> Frankly, being mostly an end user of SVN, with its sacred policy of
> "sync before you start your work", I'm a bit lost when it comes to the
> interaction of SVN and continuous integration. I'm just wondering
> whether, if we neglect telling the user (Council member, etc.) to sync
> before work, we risk that other people's additions may get lost, given
> that they go via SVN. I

Using  SVN to edit the sources is separately from building.
All the normal disciplines apply, like syncing before you start.
SVN won't ever lose your work if you commit it - if it fails to commit,
it will tell you why, and you'll need to recover. 

if you check out P5, and edit it over a period of a week Monday to Friday
without committing changes, then you run a risk that I will have
done work on Tuesday, and committed it the same day, so when you
come to commit on Friday you may have a conflict. But this is normal
version control stuff.
--
Stormageddon Rahtz      
Head of Information and Support Group, Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431

S?lo le pido a Dios
que el futuro no me sea indiferente


From lou.burnard at retired.ox.ac.uk  Mon Feb 13 13:40:14 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Mon, 13 Feb 2012 18:40:14 +0000
Subject: [tei-council] Release process documentation
In-Reply-To: <66126A59-A2CE-4550-93E9-8AB4489E3A55@oucs.ox.ac.uk>
References: <4F3930AF.5040701@uvic.ca>
	<4F3933A5.4030301@o2.pl>	<4F393A62.8080609@uvic.ca>
	<4F394EBC.3000402@o2.pl>
	<66126A59-A2CE-4550-93E9-8AB4489E3A55@oucs.ox.ac.uk>
Message-ID: <4F39590E.3030807@retired.ox.ac.uk>

Personally, I find it very useful to be able to do a test build on my 
local machine before committing changes. The chances that some other 
change will have taken place that might affect the parts I am messing 
with, although not neglible, is still less than the probability that I 
will have messed up those parts in some embarrassingly obvious way which 
I'd rather not expose to the rest of the developer community :-)

But, to coin a phrase, your mileage may very well vary. And now that we 
have a pair of Jinxes I am finding the number of embarrassingly obvious 
errors I do have to expose is considerably reduced.


On 13/02/12 18:32, Sebastian Rahtz wrote:
>
> On 13 Feb 2012, at 17:56, Piotr Ba?ski wrote:
>
>> Frankly, being mostly an end user of SVN, with its sacred policy of
>> "sync before you start your work", I'm a bit lost when it comes to the
>> interaction of SVN and continuous integration. I'm just wondering
>> whether, if we neglect telling the user (Council member, etc.) to sync
>> before work, we risk that other people's additions may get lost, given
>> that they go via SVN. I
>
> Using  SVN to edit the sources is separately from building.
> All the normal disciplines apply, like syncing before you start.
> SVN won't ever lose your work if you commit it - if it fails to commit,
> it will tell you why, and you'll need to recover.
>
> if you check out P5, and edit it over a period of a week Monday to Friday
> without committing changes, then you run a risk that I will have
> done work on Tuesday, and committed it the same day, so when you
> come to commit on Friday you may have a conflict. But this is normal
> version control stuff.
> --
> Stormageddon Rahtz
> Head of Information and Support Group, Oxford University Computing Services
> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>
> S?lo le pido a Dios
> que el futuro no me sea indiferente
>


From sebastian.rahtz at oucs.ox.ac.uk  Mon Feb 13 13:52:26 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Mon, 13 Feb 2012 18:52:26 +0000
Subject: [tei-council] Release process documentation
In-Reply-To: <4F39590E.3030807@retired.ox.ac.uk>
References: <4F3930AF.5040701@uvic.ca>	<4F3933A5.4030301@o2.pl>
	<4F393A62.8080609@uvic.ca>	<4F394EBC.3000402@o2.pl>
	<66126A59-A2CE-4550-93E9-8AB4489E3A55@oucs.ox.ac.uk>
	<4F39590E.3030807@retired.ox.ac.uk>
Message-ID: <2290631C-9755-446D-B396-0920F8BC08BE@oucs.ox.ac.uk>


On 13 Feb 2012, at 18:40, Lou Burnard wrote:

> Personally, I find it very useful to be able to do a test build on my 
> local machine before committing changes. The chances that some other 
> change will have taken place that might affect the parts I am messing 
> with, although not neglible, is still less than the probability that I 
> will have messed up those parts in some embarrassingly obvious way which 
> I'd rather not expose to the rest of the developer community :-)

Yes indeed, me too. And its vitally important that the build process
be entirely open and reproducible by relatively ordinary people.

Worth remembering that the Jinxes do more than validating. They also
assemble and package deliverables, doing things that most
people can't be bothered with, and running over the tedious tests
like validating all the separate HTML files generated.

--
Stormageddon Rahtz      
Head of Information and Support Group, Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431

S?lo le pido a Dios
que el futuro no me sea indiferente


From bansp at o2.pl  Mon Feb 13 14:06:10 2012
From: bansp at o2.pl (=?ISO-8859-2?Q?Piotr_Ba=F1ski?=)
Date: Mon, 13 Feb 2012 20:06:10 +0100
Subject: [tei-council] Release process documentation
In-Reply-To: <4F3955A8.9010708@uvic.ca>
References: <4F3930AF.5040701@uvic.ca>	<4F3933A5.4030301@o2.pl>	<4F393A62.8080609@uvic.ca>	<4F394EBC.3000402@o2.pl>
	<4F3955A8.9010708@uvic.ca>
Message-ID: <4F395F22.9050109@o2.pl>

Hi again,

Ah, I think I see where the misunderstanding was: I meant only "a bit of
building" ;-), namely making sure to have the p5odds schema alone, which
is obviously useful for editing with validation on the fly, which in
turn eliminates the need to wait for Jenkins to discover that I forgot
something half-obvious, like element ordering, obligatory attribute,
etc. And which helps in content completion.

But if Sebastian goes with what he suggested earlier in this thread,
namely making the current p5odds referenceable from outside, as it were,
all my problems will be forgotten, and the world will be green and dreamy...

Best,

  P.


On 13/02/12 19:25, Martin Holmes wrote:
> Hi Piotr,
> 
> We would expect anyone managing a release to be fully comfortable with 
> editing the source and syncing with SVN. They have to commit changes to 
> the VERSION file anyway, to start the process, so if their source tree 
> was out of sync, there would be an error there.
> 
> If they want to build locally before committing changes, then that's 
> fine, but there's no need for it when we have the Jinks servers. I'd 
> also rather not get into giving instructions for setting up a build 
> environment on your local machine (which might be Windows, Mac or 
> Linux), when all that's actually needed is SVN.
> 
> Cheers,
> Martin
> 
> On 12-02-13 09:56 AM, Piotr Ba?ski wrote:
>> Frankly, being mostly an end user of SVN, with its sacred policy of
>> "sync before you start your work", I'm a bit lost when it comes to the
>> interaction of SVN and continuous integration. I'm just wondering
>> whether, if we neglect telling the user (Council member, etc.) to sync
>> before work, we risk that other people's additions may get lost, given
>> that they go via SVN. I really don't see the whole picture here -- maybe
>> it's worth a note by a specialist, for paranoid half-trained types like
>> myself.
>>
>> :-)
>>
>>    Piotr
>>
>> On 13/02/12 17:29, Martin Holmes wrote:
>>> Hi Piotr,
>>>
>>> I thought about this, but there is some risk that a local installation
>>> of the TEI infrastructure might not be fully updated. Sebastian releases
>>> regular updates to the Debian and Oxygen packages, and obviously keeps
>>> his Jenkins server updated; he also informs me about any changes such as
>>> new packages which need to be added, and I try to keep mine in sync too,
>>> so the two act as a check on each other.
>>>
>>> If someone did a local build, and encountered errors, they wouldn't
>>> necessarily know whether the errors were caused by their local install
>>> of TEI being slightly out of sync, or whether the errors were real. So
>>> on balance, relying on the Jinks servers (especially now there are two
>>> of them) seems the more solid option.
>>>
>>> Cheers,
>>> Martin
>>>
>>> On 12-02-13 08:00 AM, Piotr Ba?ski wrote:
>>>> Hi Martin,
>>>>
>>>> Thanks for putting the doc together, it's going to be very useful. I
>>>> wonder, maybe it makes sense to encourage local validation before
>>>> waiting for Jenkins to finish, as in the e-mail by Sebastian:
>>>>
>>>> http://lists.village.virginia.edu/pipermail/tei-council/2011/013232.html
>>>>
>>>> Best,
>>>>
>>>>     P.
>>>>
>>>> On 13/02/12 16:47, Martin Holmes wrote:
>>>>> Hi all,
>>>>>
>>>>> I've made one more change to the release process documentation document,
>>>>> TCW22, to add a 17th step relating to the Stylesheets, and arising out
>>>>> of our experience cleaning up after the last release. I've also edited
>>>>> TCW20 to remove the content of the section on Building a Release, and
>>>>> replace it with a link to the new document. The two working papers are here:
>>>>>
>>>>> <http://www.tei-c.org/Activities/Council/Working/tcw20.xml>
>>>>> <http://www.tei-c.org/Activities/Council/Working/tcw22.xml>
>>>>>
>>>>> I think that concludes the work arising out of the 2.0.2 release, and I
>>>>> think we're now in good shape for Gaby to work through TWC22 when he
>>>>> does the next one. Because it's so tricky (well, it's impossible,
>>>>> really) to fully test the process without actually doing it for real, we
>>>>> won't be really sure that the changes we made to avoid the problems we
>>>>> had last time are really effective until the next release, but it should
>>>>> be much smoother next time around.
>>>>>
>>>>> Cheers,
>>>>> Martin
>>>>
>>


From sebastian.rahtz at oucs.ox.ac.uk  Mon Feb 13 14:34:52 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Mon, 13 Feb 2012 19:34:52 +0000
Subject: [tei-council] Release process documentation
In-Reply-To: <4F395F22.9050109@o2.pl>
References: <4F3930AF.5040701@uvic.ca>	<4F3933A5.4030301@o2.pl>
	<4F393A62.8080609@uvic.ca>	<4F394EBC.3000402@o2.pl>
	<4F3955A8.9010708@uvic.ca> <4F395F22.9050109@o2.pl>
Message-ID: <714EF1F4-8452-42EB-AB4B-B493FF736919@oucs.ox.ac.uk>


On 13 Feb 2012, at 19:06, Piotr Ba?ski wrote:

> 
> But if Sebastian goes with what he suggested earlier in this thread,
> namely making the current p5odds referenceable from outside, as it were,
> all my problems will be forgotten, and the world will be green and dreamy...


I've just made that changes, seems uncontroversial.
--
Stormageddon Rahtz      
Head of Information and Support Group, Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431

S?lo le pido a Dios
que el futuro no me sea indiferente


From kevin.s.hawkins at ultraslavonic.info  Sat Feb 18 18:13:02 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Sat, 18 Feb 2012 18:13:02 -0500
Subject: [tei-council] for 28 Feb. conf call: background on Best Practice
	for TEI in Libraries
Message-ID: <4F40307E.6080807@ultraslavonic.info>

All,

James has asked me to provide some background on the conf call agenda 
items that I put forward so that we can focus on discussion rather than 
providing background information during the call.  To that end, I'll 
send two emails: one giving background on the brief reports (forthcoming 
once I find out a bit more about what my collaborators are up to) and 
this one, which gives background on the *Best Practices for TEI in 
Libraries* (BP).

The BP was created by members of the SIG on Libraries and consists of a 
set of ODD files in a GitHub project, plus a few shell scripts and such 
for compilation into unified documentation. It was released as version 
3.0 (having superseded earlier documents with similar names), and a 
snapshot of the full documentation is stored in the SIG's webspace on 
tei-c.org ( http://www.tei-c.org/SIG/Libraries/teiinlibraries/ ).  There 
are a few pages in the TEI wiki containing notes on recommended 
revisions to the document.

While it would make sense for the SIG on Libraries to review the BP 
occasionally in light of new releases of the TEI and in response to 
community needs, only been a handful of SIG members have found time to 
contribute to the BP.  I hosted two SIG meetings this fall (in Wuerzburg 
and at the Digital Library Federation Forum in Baltimore) and informally 
fished for successors to Michelle Dalmau and me, who led development of 
the BP, but wasn't finding any.  So we would like to institutionalize 
support for the BP's development for fear that will fall into neglect.

If the Council takes a role in the maintenance of this and other 
community-driven customizations, the Council can ensure coherence across 
them and attempt to recruit assistance from specialists for complex 
matters. Maintenance by the Council would help ensure (though somewhat 
indirectly) that the BP customizations are available through Roma and in 
oxygen-tei.

However, I need to offer a few disclaimers about the BP:

a) The encoding prescribed in the BP for Levels 1 and 2 is definitely 
not TEI-conformant; I'm unsure about Levels 3 and 4.  Not sure whether 
this would disqualify it.

b) If Council feels that materials under its stewardship must be in 
Sourceforge, the content would need to be moved there from GitHub and 
the appropriate wiki pages. This isn't a problem, but note that the idea 
of moving all TEI content out of Sourceforge into GitHub has 
occasionally been suggested.

Regardless of whether the Council takes over or contributes to 
maintenance of the BP, I would like to see the BP added to the 
appropriate section of http://www.tei-c.org/Guidelines/Customization/ . 
  Currently that webpage says to email editors at tei-c.org to request that 
a customization be added, but I'm not sure that's correct since there 
are no longer editors of the TEI.

Perhaps if you have any clarifying questions, I can try to answer them 
now; otherwise, we can simply discuss on 28 February.

Kevin

From kevin.s.hawkins at ultraslavonic.info  Sat Feb 18 18:33:21 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Sat, 18 Feb 2012 18:33:21 -0500
Subject: [tei-council] Minor error in Guidelines
In-Reply-To: <CAA2irtLG+Rqeh5=buxRqog0-JRnxuwmgfGg5vWUnQKSLBmCJWQ@mail.gmail.com>
References: <4F0F9F9F.3050408@gmail.com> <4F0FBAA5.2090706@uvic.ca>
	<97AE8F42-0EDB-41CC-8FE1-984EE9E495D4@oucs.ox.ac.uk>
	<4F10590C.50904@uvic.ca> <4F1059A9.1000709@retired.ox.ac.uk>
	<4F21FA47.2050800@ultraslavonic.info>
	<CAA2irtLG+Rqeh5=buxRqog0-JRnxuwmgfGg5vWUnQKSLBmCJWQ@mail.gmail.com>
Message-ID: <4F403541.5050107@ultraslavonic.info>

Good, I've updated 
http://www.tei-c.org/Activities/Council/Working/tcw20.xml .

On 1/27/12 12:38 PM, Rebecca Welzenbach wrote:
> I would certainly find it valuable!
>
> On Thu, Jan 26, 2012 at 8:13 PM, Kevin Hawkins
> <kevin.s.hawkins at ultraslavonic.info>  wrote:
>> I'm wondering whether others feel that we should add a bit to
>>
>> http://www.tei-c.org/Activities/Council/Working/tcw20.xml
>>
>> or perhaps more properly
>>
>> P5/Source/Guidelines/en/style-guide.txt
>>
>> stating this distinction.  There might be other things that those who
>> have been editing the Guidelines keep in mind but haven't written down
>> for the rest of us.
>>
>> Such a passage would be similar to this, which I found in tcw20 and is
>> similarly prescriptive about encoding practice:
>>
>> ###
>>
>> In most chapters, the two character code is also used as a prefix for
>> the @xml:id values given to each<div>  element. Note that every<div>
>> element carries an @xml:id value, whether or not it is actually
>> referenced explicitly elewhere in the Guidelines.
>>
>> ###
>>
>> Is this worthwhile, or would none of us ever remember to consult this
>> anyway?
>>
>> --K.
>>
>> On 1/13/12 11:19 AM, Lou Burnard wrote:
>>> In the Guidelines, as elsewhere,
>>>
>>> <ref target="#foo">section foo</ref>    means: generate a link to #foo and
>>> represent it by the text "section foo".
>>>
>>> <ptr target="#foo"/>    means: generate a link to #foo and represent it by
>>> whatever text your processor chooses to generate
>>>
>>>
>>>
>>> On 13/01/12 16:17, Martin Holmes wrote:
>>>> Could you clarify what the difference is between using<ref>     and<ptr>
>>>> in the guidelines?
>>>>
>>>> Cheers,
>>>> Martin
>>>>
>>>> On 12-01-13 01:32 AM, Sebastian Rahtz wrote:
>>>>>
>>>>> On 13 Jan 2012, at 05:01, Martin Holmes wrote:
>>>>>
>>>>>> I've put in a bug report for this:
>>>>>>
>>>>>> <http://purl.org/TEI/BUGS/3473329>
>>>>>>
>>>>>> The basic problem is that in the web view of the Guidelines, figures
>>>>>> within each chapter are numbered 1, 2, 3, 4 etc., but in the PDF output,
>>>>>> they're numbered 11.1, 11.2, 11.3?
>>>>>>
>>>>> there are two issues here.
>>>>>
>>>>>       a) the use of dangerous markup like "<ref target="#sleeprs">figure 4 above</ref>", which should be changed into a<ptr>      to avoid this sort of problem
>>>>>       b) the different numbering schemes
>>>>>
>>>>> for the latter, which do we want for the Guidelines? by chapter, or sequential throughout?
>>>>>
>>>>> for the former, I found 3 occurrences of this, and changed them to<ptr>. am testing before committing.
>>>>> --
>>>>> Stormageddon Rahtz
>>>>> Head of Information and Support Group
>>>>> Oxford University Computing Services
>>>>> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>>>>>
>>>>> S?lo le pido a Dios
>>>>> que el futuro no me sea indiferente
>>>>>
>>>>
>>>
>> --
>> tei-council mailing list
>> tei-council at lists.village.Virginia.EDU
>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>>
>> PLEASE NOTE: postings to this list are publicly archived

From kevin.s.hawkins at ultraslavonic.info  Sat Feb 18 19:03:42 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Sat, 18 Feb 2012 19:03:42 -0500
Subject: [tei-council] updated list of Council members etc. for P5
In-Reply-To: <3C89BE68-D1D3-4241-BC28-6013BBD16632@oucs.ox.ac.uk>
References: <4F37DE51.4020509@ultraslavonic.info>
	<252F6DCE-AECF-453D-9B75-F118D5A8E138@oucs.ox.ac.uk>
	<4F37FDF8.5090800@retired.ox.ac.uk>
	<3C89BE68-D1D3-4241-BC28-6013BBD16632@oucs.ox.ac.uk>
Message-ID: <4F403C5E.1030301@ultraslavonic.info>

Okay, I've implemented most of this.  Notes on remaining questions are 
in the ticket:

http://purl.org/TEI/fr/3041605

From mholmes at uvic.ca  Sat Feb 18 19:21:39 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Sat, 18 Feb 2012 16:21:39 -0800
Subject: [tei-council] updated list of Council members etc. for P5
In-Reply-To: <4F403C5E.1030301@ultraslavonic.info>
References: <4F37DE51.4020509@ultraslavonic.info>	<252F6DCE-AECF-453D-9B75-F118D5A8E138@oucs.ox.ac.uk>	<4F37FDF8.5090800@retired.ox.ac.uk>	<3C89BE68-D1D3-4241-BC28-6013BBD16632@oucs.ox.ac.uk>
	<4F403C5E.1030301@ultraslavonic.info>
Message-ID: <4F404093.5040708@uvic.ca>

Does anyone think we really need a formal "personbase"? I've been trying 
to think of what sort of information might be worth collecting from 
people, and I can't think of much that would be useful without already 
being public and obvious (where people currently work and their terms on 
the Board or the Council), or raising privacy issues (DOB, 
qualifications, employment history etc.).

Cheers,
Martin

On 12-02-18 04:03 PM, Kevin Hawkins wrote:
> Okay, I've implemented most of this.  Notes on remaining questions are
> in the ticket:
>
> http://purl.org/TEI/fr/3041605

From syeates at gmail.com  Sat Feb 18 22:07:30 2012
From: syeates at gmail.com (stuart yeates)
Date: Sun, 19 Feb 2012 16:07:30 +1300
Subject: [tei-council] updated list of Council members etc. for P5
In-Reply-To: <4F404093.5040708@uvic.ca>
References: <4F37DE51.4020509@ultraslavonic.info>	<252F6DCE-AECF-453D-9B75-F118D5A8E138@oucs.ox.ac.uk>	<4F37FDF8.5090800@retired.ox.ac.uk>	<3C89BE68-D1D3-4241-BC28-6013BBD16632@oucs.ox.ac.uk>
	<4F403C5E.1030301@ultraslavonic.info> <4F404093.5040708@uvic.ca>
Message-ID: <4F406772.2070608@gmail.com>

On 19/02/12 13:21, Martin Holmes wrote:
> Does anyone think we really need a formal "personbase"? I've been trying
> to think of what sort of information might be worth collecting from
> people, and I can't think of much that would be useful without already
> being public and obvious (where people currently work and their terms on
> the Board or the Council), or raising privacy issues (DOB,
> qualifications, employment history etc.).

As I understand it, an attribution-based copyright license requires 
tracking people who have made contributions.

cheers
stuart


From mholmes at uvic.ca  Sat Feb 18 23:30:35 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Sat, 18 Feb 2012 20:30:35 -0800
Subject: [tei-council] updated list of Council members etc. for P5
In-Reply-To: <4F406772.2070608@gmail.com>
References: <4F37DE51.4020509@ultraslavonic.info>	<252F6DCE-AECF-453D-9B75-F118D5A8E138@oucs.ox.ac.uk>	<4F37FDF8.5090800@retired.ox.ac.uk>	<3C89BE68-D1D3-4241-BC28-6013BBD16632@oucs.ox.ac.uk>	<4F403C5E.1030301@ultraslavonic.info>
	<4F404093.5040708@uvic.ca> <4F406772.2070608@gmail.com>
Message-ID: <4F407AEB.6090200@uvic.ca>

On 12-02-18 07:07 PM, stuart yeates wrote:
> On 19/02/12 13:21, Martin Holmes wrote:
>> Does anyone think we really need a formal "personbase"? I've been trying
>> to think of what sort of information might be worth collecting from
>> people, and I can't think of much that would be useful without already
>> being public and obvious (where people currently work and their terms on
>> the Board or the Council), or raising privacy issues (DOB,
>> qualifications, employment history etc.).
>
> As I understand it, an attribution-based copyright license requires
> tracking people who have made contributions.

This caused me to go back to the original minutes and check the context 
in which we decided this was a good idea:

<quote>
3041605: Update list of Council members. The Council agrees that the 
current list of members should be updated, and that a complete list of 
current and former Council members should be maintained and included in 
the Guidelines. KH will collect info from LB and elsewhere to create the 
list, and MH will then take over to create a more robust and formal 
collection of info based on a <listPerson> ; a template <person> can be 
sent out to TEI-L. LB reminds us about privacy concerns.
</quote>

I think the reason we decided to go with <listPerson> was simply so that 
we could include the list in the Guidelines in such a way that we could 
easily link to individuals through @xml:ids. So the question then 
becomes: what do we need to know about people? I had originally imagined 
something simple like this:

<person role="teiCouncil">
  <persName>
   <forename>Martin</forename>
   <surname>Holmes</surname>
  </persName>
  <affiliation>University of Victoria Humanities Computing and Media 
Centre</affiliation>
</person>

However, someone could have had multiple affiliations with different 
dates, and been on the Council for a couple of years and the Board for a 
year. So:

<person>
  <persName>
   <forename>Martin</forename>
   <surname>Holmes</surname>
  </persName>
  <affiliation notBefore="1998">University of Victoria HCMC</affiliation>
  <affiliation role="council_elected" notBefore="2010">TEI</affiliation>
</person>

We should be able to devise a system in which it's possible to encode 
all the various configurations of service to the TEI (Council, Board, 
elected, appointed, committees, workgroups, etc.) in the 
affiliation/@role attribute (possibly with multiple TEI-related 
<affiliations>, if necessary); and then we should be able to generate at 
least some of the FM1 page automatically from the list; all we then have 
to do is make sure we keep the list up to date, and Council members at 
least can keep their own <person> entry updated in SF.

Does this make sense? Is it worth the trouble?

Cheers,
Martin

From sebastian.rahtz at oucs.ox.ac.uk  Sun Feb 19 07:24:09 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Sun, 19 Feb 2012 12:24:09 +0000
Subject: [tei-council] updated list of Council members etc. for P5
In-Reply-To: <4F406772.2070608@gmail.com>
References: <4F37DE51.4020509@ultraslavonic.info>
	<252F6DCE-AECF-453D-9B75-F118D5A8E138@oucs.ox.ac.uk>
	<4F37FDF8.5090800@retired.ox.ac.uk>
	<3C89BE68-D1D3-4241-BC28-6013BBD16632@oucs.ox.ac.uk>
	<4F403C5E.1030301@ultraslavonic.info> <4F404093.5040708@uvic.ca>
	<4F406772.2070608@gmail.com>
Message-ID: <E70FC133-D9A8-4710-A8D9-DFC1C9E10F27@oucs.ox.ac.uk>


On 19 Feb 2012, at 03:07, stuart yeates wrote:
> 
> As I understand it, an attribution-based copyright license requires 
> tracking people who have made contributions.
> 
that is raising an interesting issue, over whether contributors
to the TEI are retaining their own copyright, or giving it
to the Consortium. My view has always been that we are
all giving up our copyright, but not surprisingly that has
never been enforced or documented. Back when we had
editors who were (as it were) paid employees of the Consortium,
it was probably clearer that the copyright belonged to the Consortium.

of course, the membership of the Council is not the same
as the role of committers to the TEI :-}

If you wonder, by the way, who the committers are, this list might
help:

Brett Barney
David Sewell
Eve Radermacher
Gabriel Bodard
J-L Benoit
James Cummings
Kevin Hawkins
Laurent Romary
Lou Burnard 
Martin Holmes
Perry Trolard
Piotr Banski
Sebastian Rahtz 
Stuart Yeates
Syd Bauman 



--
Stormageddon Rahtz      
Head of Information and Support Group, Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431

S?lo le pido a Dios
que el futuro no me sea indiferente


From sebastian.rahtz at oucs.ox.ac.uk  Sun Feb 19 07:32:32 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Sun, 19 Feb 2012 12:32:32 +0000
Subject: [tei-council] updated list of Council members etc. for P5
In-Reply-To: <4F407AEB.6090200@uvic.ca>
References: <4F37DE51.4020509@ultraslavonic.info>
	<252F6DCE-AECF-453D-9B75-F118D5A8E138@oucs.ox.ac.uk>
	<4F37FDF8.5090800@retired.ox.ac.uk>
	<3C89BE68-D1D3-4241-BC28-6013BBD16632@oucs.ox.ac.uk>
	<4F403C5E.1030301@ultraslavonic.info>	<4F404093.5040708@uvic.ca>
	<4F406772.2070608@gmail.com> <4F407AEB.6090200@uvic.ca>
Message-ID: <E65B40B9-6802-46BF-8632-54A09A03967D@oucs.ox.ac.uk>


On 19 Feb 2012, at 04:30, Martin Holmes wrote:

> <person>
>  <persName>
>   <forename>Martin</forename>
>   <surname>Holmes</surname>
>  </persName>
>  <affiliation notBefore="1998">University of Victoria HCMC</affiliation>
>  <affiliation role="council_elected" notBefore="2010">TEI</affiliation>
> </person>
> 
I don't think this is too over the top, it should be possible to keep something as minimal
as this up to date.

--
Stormageddon Rahtz      
Head of Information and Support Group, Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431

S?lo le pido a Dios
que el futuro no me sea indiferente


From sebastian.rahtz at oucs.ox.ac.uk  Sun Feb 19 07:47:54 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Sun, 19 Feb 2012 12:47:54 +0000
Subject: [tei-council] for 28 Feb. conf call: background on Best
 Practice	for TEI in Libraries
In-Reply-To: <4F40307E.6080807@ultraslavonic.info>
References: <4F40307E.6080807@ultraslavonic.info>
Message-ID: <EBB790FD-70DA-40F9-BFF0-7C84F3E173B9@oucs.ox.ac.uk>

> 
> a) The encoding prescribed in the BP for Levels 1 and 2 is definitely 
> not TEI-conformant; I'm unsure about Levels 3 and 4.  Not sure whether 
> this would disqualify it.
> 
maybe you can give some background here. are levels 1 and 2

  a) non-TEI deliberately,
  b) only non-TEI pending resolution of feature requests, or
  c) non-TEI by accident, pending some editorial work
?

it would seem fairly weird for us to deliberately maintain customizations which are
not TEI-conformant.
--
Stormageddon Rahtz      
Head of Information and Support Group, Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431

S?lo le pido a Dios
que el futuro no me sea indiferente


From kevin.s.hawkins at ultraslavonic.info  Sun Feb 19 09:53:42 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Sun, 19 Feb 2012 09:53:42 -0500
Subject: [tei-council] for 28 Feb. conf call: background on Best
 Practice for TEI in Libraries
In-Reply-To: <EBB790FD-70DA-40F9-BFF0-7C84F3E173B9@oucs.ox.ac.uk>
References: <4F40307E.6080807@ultraslavonic.info>
	<EBB790FD-70DA-40F9-BFF0-7C84F3E173B9@oucs.ox.ac.uk>
Message-ID: <4F410CF6.4040804@ultraslavonic.info>

The answer is mostly (a).  But I misremembered the specifics from Syd 
and didn't think till now to consult the ODDs where Syd explains these 
things, so it turns out Level 2 might actually be conformant.  But in 
both cases we're talking about conformance to the TEI's abtract model, 
not syntactic conformance.

Level 1 is not conformant because <ab> is abused to include the OCR text 
of the entire document, not something at the level of a paragraph.

Level 2 is possibly not conformant depending on whether you think the 
Guidelines say that encoding of <p>s is mandatory.

On 2/19/12 7:47 AM, Sebastian Rahtz wrote:
>>
>> a) The encoding prescribed in the BP for Levels 1 and 2 is definitely
>> not TEI-conformant; I'm unsure about Levels 3 and 4.  Not sure whether
>> this would disqualify it.
>>
> maybe you can give some background here. are levels 1 and 2
>
>    a) non-TEI deliberately,
>    b) only non-TEI pending resolution of feature requests, or
>    c) non-TEI by accident, pending some editorial work
> ?
>
> it would seem fairly weird for us to deliberately maintain customizations which are
> not TEI-conformant.
> --
> Stormageddon Rahtz
> Head of Information and Support Group, Oxford University Computing Services
> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>
> S?lo le pido a Dios
> que el futuro no me sea indiferente
>

From sebastian.rahtz at oucs.ox.ac.uk  Sun Feb 19 11:57:55 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Sun, 19 Feb 2012 16:57:55 +0000
Subject: [tei-council] for 28 Feb. conf call: background on Best
 Practice for TEI in Libraries
In-Reply-To: <4F410CF6.4040804@ultraslavonic.info>
References: <4F40307E.6080807@ultraslavonic.info>
	<EBB790FD-70DA-40F9-BFF0-7C84F3E173B9@oucs.ox.ac.uk>
	<4F410CF6.4040804@ultraslavonic.info>
Message-ID: <EBF08744-1474-4712-A41A-10D2DFF1042D@oucs.ox.ac.uk>


On 19 Feb 2012, at 14:53, Kevin Hawkins wrote:

> The answer is mostly (a) [ a) non-TEI deliberately ]

So we'd end up with the TEI  Consortium owning some customizations
labelled "Best Practice" which contradicted its own Guidelines. That would
be pretty weird!

But seriously, isn't the question of whether the TEIC should take over
maintenance of these BPs something the TEI Board
should be debating, not the Council? obviously if the Board
accepted the task then the Council could work out the technicalities.

--
Stormageddon Rahtz      
Head of Information and Support Group, Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431

S?lo le pido a Dios
que el futuro no me sea indiferente


From James.Cummings at oucs.ox.ac.uk  Sun Feb 19 15:15:19 2012
From: James.Cummings at oucs.ox.ac.uk (James Cummings)
Date: Sun, 19 Feb 2012 20:15:19 +0000
Subject: [tei-council] for 28 Feb. conf call: background on Best
 Practice for TEI in Libraries
In-Reply-To: <4F40307E.6080807@ultraslavonic.info>
References: <4F40307E.6080807@ultraslavonic.info>
Message-ID: <4F415857.6050601@oucs.ox.ac.uk>

On 18/02/12 23:13, Kevin Hawkins wrote:
> James has asked me to provide some background on the conf call agenda
> items that I put forward so that we can focus on discussion rather than
> providing background information during the call.

For others on the list, the draft agenda is available at:
http://wiki.tei-c.org/index.php/Council

Specifically:
http://wiki.tei-c.org/index.php/Council#Teleconference_-_Tuesday_28_February_2012_at_18:00_GMT 


-James

-- 
Dr James Cummings, InfoDev
Oxford University Computing Services
University of Oxford

From James.Cummings at oucs.ox.ac.uk  Sun Feb 19 15:26:21 2012
From: James.Cummings at oucs.ox.ac.uk (James Cummings)
Date: Sun, 19 Feb 2012 20:26:21 +0000
Subject: [tei-council] for 28 Feb. conf call: background on Best
 Practice for TEI in Libraries
In-Reply-To: <EBF08744-1474-4712-A41A-10D2DFF1042D@oucs.ox.ac.uk>
References: <4F40307E.6080807@ultraslavonic.info>	<EBB790FD-70DA-40F9-BFF0-7C84F3E173B9@oucs.ox.ac.uk>	<4F410CF6.4040804@ultraslavonic.info>
	<EBF08744-1474-4712-A41A-10D2DFF1042D@oucs.ox.ac.uk>
Message-ID: <4F415AED.6000100@oucs.ox.ac.uk>

On 19/02/12 16:57, Sebastian Rahtz wrote:
> So we'd end up with the TEI  Consortium owning some customizations
> labelled "Best Practice" which contradicted its own Guidelines. That would
> be pretty weird!

It does strike me as weird as well, and I can understand why 
people might be confused as to how something can be 
'non-Conformant' and 'Best Practice' at the same time.

> But seriously, isn't the question of whether the TEIC should take over
> maintenance of these BPs something the TEI Board
> should be debating, not the Council? obviously if the Board
> accepted the task then the Council could work out the technicalities.

This is, if memory serves, what happened with TEI Tite (which 
would serve as an example of another non-conformant TEI extension 
which we at least provide as an exemplar if not have shared 
custody of).

If the idea of the council maintaining this BP was presented to 
the Board, I would not feel I was doing my duty if I did not 
present the Council's position on this to the Board. (Nor would 
the Board correspondingly be doing their duty if they didn't ask 
for the technical perspective of the Council if substantial 
technical queries were raised.) In that case I would only have to 
return to the Council list in an attempt to get a consensus in 
any case. I think it is best if this goes to the Board that the 
Council position (if indeed we are able to agree on one) is 
already understood. If we aren't able to agree that this would be 
a good or bad thing, then equally the lack of consensus should be 
mentioned to the Board to inform their own discussions.

-James

-- 
Dr James Cummings, InfoDev
Oxford University Computing Services
University of Oxford

From sebastian.rahtz at oucs.ox.ac.uk  Sun Feb 19 18:02:29 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Sun, 19 Feb 2012 23:02:29 +0000
Subject: [tei-council] for 28 Feb. conf call: background on Best
 Practice for TEI in Libraries
In-Reply-To: <4F415AED.6000100@oucs.ox.ac.uk>
References: <4F40307E.6080807@ultraslavonic.info>
	<EBB790FD-70DA-40F9-BFF0-7C84F3E173B9@oucs.ox.ac.uk>
	<4F410CF6.4040804@ultraslavonic.info>
	<EBF08744-1474-4712-A41A-10D2DFF1042D@oucs.ox.ac.uk>
	<4F415AED.6000100@oucs.ox.ac.uk>
Message-ID: <1f2b0fcc-944d-46d7-ad1f-53ff54d886d8@HUB01.ad.oak.ox.ac.uk>


On 19 Feb 2012, at 20:26, James Cummings wrote:
> 
> If the idea of the council maintaining this BP was presented to 
> the Board, I would not feel I was doing my duty if I did not 
> present the Council's position on this to the Board. 

fair do's.

Speaking for the implementation side of it, I think we need to 
bear in mind that the BPs are not Exemplars
like most of what we have, so I suggest it would not make sense for them
to show up in Roma, for example. Maybe we need to maintain
a separate family of Canned Schemas, containing Lite and Tite
at present, distinct from the Exemplars.

It could be a useful exercise for that Sunday afternoon in Michigan
for one of us to sit down and understand how the oXygen TEI framework
is put together, so we can get the templates there better under our control.
--
Stormageddon Rahtz      
Head of Information and Support Group, Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431

S?lo le pido a Dios
que el futuro no me sea indiferente


From mholmes at uvic.ca  Mon Feb 20 12:16:38 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Mon, 20 Feb 2012 09:16:38 -0800
Subject: [tei-council] updated list of Council members etc. for P5
In-Reply-To: <E65B40B9-6802-46BF-8632-54A09A03967D@oucs.ox.ac.uk>
References: <4F37DE51.4020509@ultraslavonic.info>
	<252F6DCE-AECF-453D-9B75-F118D5A8E138@oucs.ox.ac.uk>
	<4F37FDF8.5090800@retired.ox.ac.uk>
	<3C89BE68-D1D3-4241-BC28-6013BBD16632@oucs.ox.ac.uk>
	<4F403C5E.1030301@ultraslavonic.info>	<4F404093.5040708@uvic.ca>
	<4F406772.2070608@gmail.com> <4F407AEB.6090200@uvic.ca>
	<E65B40B9-6802-46BF-8632-54A09A03967D@oucs.ox.ac.uk>
Message-ID: <4F427FF6.40309@uvic.ca>

So the next stage is to figure out what all the roles are.

We need to distinguish TEI <affiliations>s from other <affiliation>s, 
which could be done, as in my previous example, simply by having "TEI" 
as the text content of any <affiliation> tag. But that leaves only the 
@role attribute to distinguish all the different roles (since 
<affiliation> isn't a member of att.typed, for instance). However, 
<roleName> is also available as a child of <affiliation>, and it's a 
member of att.typed, so we could have:

<affiliation role="tei">
  <roleName type="council_member" subtype="elected">
</affiliation>

This would enable us to find all TEI affiliations 
(affiliation/@role="tei"), all council members (roleName/@type) and the 
nature of the appointment (roleName/@subtype). The text content of 
<affiliation> could be used to provide a more detailed explanation of 
the person's role in human-readable form.

We would presumably have the following types:

council_member
council_chair
board_member
board_chair
board_representative (non-voting partner reps)
board_treasurer
board_secretary
committer
editor
webmaster
workgroup_chair
workgroup_member
sig_convener

and the following subtypes:

elected
appointed

Is there anything else to add?

Cheers,
Martin

On 12-02-19 04:32 AM, Sebastian Rahtz wrote:
>
> On 19 Feb 2012, at 04:30, Martin Holmes wrote:
>
>> <person>
>>   <persName>
>>    <forename>Martin</forename>
>>    <surname>Holmes</surname>
>>   </persName>
>>   <affiliation notBefore="1998">University of Victoria HCMC</affiliation>
>>   <affiliation role="council_elected" notBefore="2010">TEI</affiliation>
>> </person>
>>
> I don't think this is too over the top, it should be possible to keep something as minimal
> as this up to date.
>
> --
> Stormageddon Rahtz
> Head of Information and Support Group, Oxford University Computing Services
> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>
> S?lo le pido a Dios
> que el futuro no me sea indiferente
>
>

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From James.Cummings at oucs.ox.ac.uk  Thu Feb 23 11:38:02 2012
From: James.Cummings at oucs.ox.ac.uk (James Cummings)
Date: Thu, 23 Feb 2012 16:38:02 +0000
Subject: [tei-council] TEI Telco February 2012
Message-ID: <4F466B6A.5060107@oucs.ox.ac.uk>

Hi all,

For the teleconference on Tuesday 28 February at 18:00 GMT, we'll 
be dialling into a conferencing service run by 
economyconferencecall.com.  This should allow you to dial in 
toll-free and is using an account set-up by John Unsworth that is 
being used for the Board as well and the TEI-C will pay for the 
toll-free calls.  (Though the cost is per call so I'll try to 
convince Sebastian to share a conference phone with me.)

I'm not entirely sure where all of you will be on Tuesday, so 
I've retrieved the toll free numbers for:

US and Canada: 866-906-0040
France (excl. Monaco): 0-800-916-758
Germany: 0-800-182-0270
New Zealand: 0-800-446-259
Poland: 00-800-112-4271 (0.35 zloty charge)
UK: 0-800-635-0541

Dial the appropriate number, and then enter the access code: 
4614041 followed by the # button. You'll be asked to give your 
name. I'm told you can mute/unmute your line using *6 but have 
never tried it myself.

I have a draft agenda at http://wiki.tei-c.org/index.php/Council

Can I have a volunteer to take minutes?

-James

-- 
Dr James Cummings, InfoDev
Oxford University Computing Services
University of Oxford

From mholmes at uvic.ca  Thu Feb 23 12:47:05 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Thu, 23 Feb 2012 09:47:05 -0800
Subject: [tei-council] TEI Telco February 2012
In-Reply-To: <4F466B6A.5060107@oucs.ox.ac.uk>
References: <4F466B6A.5060107@oucs.ox.ac.uk>
Message-ID: <4F467B99.2060400@uvic.ca>

Is it OK to Skype into these numbers? It's easier to do things with 
headphones on than prop a phone against your shoulder.

Cheers,
Martin

On 12-02-23 08:38 AM, James Cummings wrote:
> Hi all,
>
> For the teleconference on Tuesday 28 February at 18:00 GMT, we'll
> be dialling into a conferencing service run by
> economyconferencecall.com.  This should allow you to dial in
> toll-free and is using an account set-up by John Unsworth that is
> being used for the Board as well and the TEI-C will pay for the
> toll-free calls.  (Though the cost is per call so I'll try to
> convince Sebastian to share a conference phone with me.)
>
> I'm not entirely sure where all of you will be on Tuesday, so
> I've retrieved the toll free numbers for:
>
> US and Canada: 866-906-0040
> France (excl. Monaco): 0-800-916-758
> Germany: 0-800-182-0270
> New Zealand: 0-800-446-259
> Poland: 00-800-112-4271 (0.35 zloty charge)
> UK: 0-800-635-0541
>
> Dial the appropriate number, and then enter the access code:
> 4614041 followed by the # button. You'll be asked to give your
> name. I'm told you can mute/unmute your line using *6 but have
> never tried it myself.
>
> I have a draft agenda at http://wiki.tei-c.org/index.php/Council
>
> Can I have a volunteer to take minutes?
>
> -James
>

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From bansp at o2.pl  Thu Feb 23 19:07:23 2012
From: bansp at o2.pl (=?ISO-8859-2?Q?Piotr_Ba=F1ski?=)
Date: Fri, 24 Feb 2012 01:07:23 +0100
Subject: [tei-council] TEI Telco February 2012
In-Reply-To: <4F466B6A.5060107@oucs.ox.ac.uk>
References: <4F466B6A.5060107@oucs.ox.ac.uk>
Message-ID: <4F46D4BB.4010604@o2.pl>

Hi James,

So toll-free is not free but funded by TEI-C? I was wondering: why not
just skype -- it's worked for conference organisation and lots of other
meetings. Or are skype conferences non-free as well?

There is a web service that some projects have used, and that is free
for sure, but I think one has to reserve the time for more intensive
telcos; it has video (yay) and it saves the conferences so that they can
be replayed later.

Would that be in any way interesting as an alternative, or not really?
Not sure if I should research that.

So long,

  P.

On 23/02/12 17:38, James Cummings wrote:
> Hi all,
> 
> For the teleconference on Tuesday 28 February at 18:00 GMT, we'll 
> be dialling into a conferencing service run by 
> economyconferencecall.com.  This should allow you to dial in 
> toll-free and is using an account set-up by John Unsworth that is 
> being used for the Board as well and the TEI-C will pay for the 
> toll-free calls.  (Though the cost is per call so I'll try to 
> convince Sebastian to share a conference phone with me.)
> 
> I'm not entirely sure where all of you will be on Tuesday, so 
> I've retrieved the toll free numbers for:
> 
> US and Canada: 866-906-0040
> France (excl. Monaco): 0-800-916-758
> Germany: 0-800-182-0270
> New Zealand: 0-800-446-259
> Poland: 00-800-112-4271 (0.35 zloty charge)
> UK: 0-800-635-0541
> 
> Dial the appropriate number, and then enter the access code: 
> 4614041 followed by the # button. You'll be asked to give your 
> name. I'm told you can mute/unmute your line using *6 but have 
> never tried it myself.
> 
> I have a draft agenda at http://wiki.tei-c.org/index.php/Council
> 
> Can I have a volunteer to take minutes?
> 
> -James
> 


From kevin.s.hawkins at ultraslavonic.info  Thu Feb 23 20:04:58 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Thu, 23 Feb 2012 20:04:58 -0500
Subject: [tei-council] P5 releases: changes to boilerplate HTML code
Message-ID: <4F46E23A.2030509@ultraslavonic.info>

I recall that when a new release of the TEI is made, all of the stuff at 
the top of each HTML page -- the TEI logo, the navbar, the search box, 
and the phrase "P5: Guidelines for Electronic Text Encoding and 
Interchange" -- is inserted at time of compilation.  Somewhere there is 
a file that stores the bits of HTML code needed for this.

Related to that, a few things:

a) This code is in need of updating: the menu options have not kept up 
with things being used on the TEI website.

b) We should note the location of the code in tcw22 and make a note to 
compare against what's currently in use on the TEI website and adjust as 
necessary.

c) Currently the P5 version number is in fine print at the bottom of the 
page, along with the last updated information.  To a casual visitor, 
this looks like a version number for the particular HTML file, not the 
full guidelines.  Furthermore, a casual visitor is unlikely to ever see 
this.  Therefore, I'd like to request that we modify the code to insert 
the current version number somewhere near "P5: Guidelines for Electronic 
Text Encoding and Interchange".  Right now there's no straightforward 
way for someone to know that there are versions of P5 and to know which 
they are looking at, and I think this would make it obvious that the 
Guidelines are in fact under constant evolution.

--Kevin

From bansp at o2.pl  Fri Feb 24 04:13:06 2012
From: bansp at o2.pl (=?ISO-8859-2?Q?Piotr_Ba=F1ski?=)
Date: Fri, 24 Feb 2012 10:13:06 +0100
Subject: [tei-council] TEI Telco February 2012
In-Reply-To: <4F46D4BB.4010604@o2.pl>
References: <4F466B6A.5060107@oucs.ox.ac.uk> <4F46D4BB.4010604@o2.pl>
Message-ID: <4F4754A2.3020909@o2.pl>

Here's the URL, for the record. I know that various projects have had
regular meetings via this system.

http://fm.ea-tel.eu/help.html

From James.Cummings at oucs.ox.ac.uk  Fri Feb 24 05:48:27 2012
From: James.Cummings at oucs.ox.ac.uk (James Cummings)
Date: Fri, 24 Feb 2012 10:48:27 +0000
Subject: [tei-council] TEI ODD meeting after DH2012
Message-ID: <4F476AFB.5040700@oucs.ox.ac.uk>

Dear Council,

Good news that our panel on TEI ODD was accepted at DH2012. As 
you know it is my suggestion that we organise a working meeting 
immediately after the conference (the Saturday/Sunday) and that 
the TEI-C would provide money towards a couple extra nights of 
hotel for those speakers who need it.  Depending on whether there 
are costs for rental of the room, and how many of them need a 
couple nights extra hotel, we might also be able to invite 
specific other people to stay on after the conference (e.g. from 
the council) and contribute to a couple night's hotel for them. 
(Food will not be covered.)  Since I know people book flights and 
accommodation quickly, I want move as swiftly as possible on this.

If you are attending DH anyway, could you let me know:
a) whether you are want to and are able to attend the  sat/sun 
meeting? (if so, make your travel plans accordingly)
b) whether you need whatever flat rate I can get out of the TEI-C 
for one or two nights?
c) suggestions of other people to invite (potentially paying 
their hotel a well)

When I have an idea of the figures I'll be approaching the Board 
with the more detailed budget for this event.

Many thanks,

-James
-- 
Dr James Cummings, InfoDev,
Computing Services, University of Oxford

From James.Cummings at oucs.ox.ac.uk  Fri Feb 24 06:38:46 2012
From: James.Cummings at oucs.ox.ac.uk (James Cummings)
Date: Fri, 24 Feb 2012 11:38:46 +0000
Subject: [tei-council] TEI Telco February 2012
In-Reply-To: <4F467B99.2060400@uvic.ca>
References: <4F466B6A.5060107@oucs.ox.ac.uk> <4F467B99.2060400@uvic.ca>
Message-ID: <4F4776C6.4000705@oucs.ox.ac.uk>


On 23/02/12 17:47, Martin Holmes wrote:
> Is it OK to Skype into these numbers? It's easier to do things with
> headphones on than prop a phone against your shoulder.

I believe this may work.  Go ahead and phone the number to test 
(just don't put in the conference ID when prompted...)

-James

>
> Cheers,
> Martin
>
> On 12-02-23 08:38 AM, James Cummings wrote:
>> Hi all,
>>
>> For the teleconference on Tuesday 28 February at 18:00 GMT, we'll
>> be dialling into a conferencing service run by
>> economyconferencecall.com.  This should allow you to dial in
>> toll-free and is using an account set-up by John Unsworth that is
>> being used for the Board as well and the TEI-C will pay for the
>> toll-free calls.  (Though the cost is per call so I'll try to
>> convince Sebastian to share a conference phone with me.)
>>
>> I'm not entirely sure where all of you will be on Tuesday, so
>> I've retrieved the toll free numbers for:
>>
>> US and Canada: 866-906-0040
>> France (excl. Monaco): 0-800-916-758
>> Germany: 0-800-182-0270
>> New Zealand: 0-800-446-259
>> Poland: 00-800-112-4271 (0.35 zloty charge)
>> UK: 0-800-635-0541
>>
>> Dial the appropriate number, and then enter the access code:
>> 4614041 followed by the # button. You'll be asked to give your
>> name. I'm told you can mute/unmute your line using *6 but have
>> never tried it myself.
>>
>> I have a draft agenda at http://wiki.tei-c.org/index.php/Council
>>
>> Can I have a volunteer to take minutes?
>>
>> -James
>>
>


-- 
Dr James Cummings, InfoDev,
Computing Services, University of Oxford

From James.Cummings at oucs.ox.ac.uk  Fri Feb 24 06:51:38 2012
From: James.Cummings at oucs.ox.ac.uk (James Cummings)
Date: Fri, 24 Feb 2012 11:51:38 +0000
Subject: [tei-council] TEI Telco February 2012
In-Reply-To: <4F46D4BB.4010604@o2.pl>
References: <4F466B6A.5060107@oucs.ox.ac.uk> <4F46D4BB.4010604@o2.pl>
Message-ID: <4F4779CA.1090700@oucs.ox.ac.uk>

On 24/02/12 00:07, Piotr Ba?ski wrote:
> Hi James,
>
> So toll-free is not free but funded by TEI-C? I was wondering: why not
> just skype -- it's worked for conference organisation and lots of other
> meetings. Or are skype conferences non-free as well?

If skype conversations are all held by people are a computer they 
are free. However, in the past it has often been found that the 
quality of the call seems to degrade depending on very 
unpredictable conditions. (e.g. the local bandwidth, individuals 
computers, whether they mute themselves etc.) While all of this 
is also true with non-skype teleconferences, it seems less 
frequent.  The board used this service for a teleconference 
recently (minutes here http://www.tei-c.org/Board/bm44.xml) and 
it seemed to go smoothly. The costs are not great, the Board 
meeting of about an hour cost "$113.49 (about $21 of which is 
taxes)" according to JohnU.  So for simplicity I suggest we try 
this for parallel with the Board. If it turns out to not work, or 
be much more expensive, then we can look at other options.

With this system it is _possible_ to record the conversation, I'm 
told, but I don't know if this incurs additional charges.  The 
idea of being able to record them to then write up minutes 
afterwards is attractive though.

Speaking of which, I have yet to have any volunteers to take 
minutes during the conference call.  I don't want to pick someone 
at random (but will)...how about I say that if you do the minutes 
this time, I won't make you do them next time?

-James

> There is a web service that some projects have used, and that is free
> for sure, but I think one has to reserve the time for more intensive
> telcos; it has video (yay) and it saves the conferences so that they can
> be replayed later.
>
> Would that be in any way interesting as an alternative, or not really?
> Not sure if I should research that.
>
> So long,
>
>    P.
>
> On 23/02/12 17:38, James Cummings wrote:
>> Hi all,
>>
>> For the teleconference on Tuesday 28 February at 18:00 GMT, we'll
>> be dialling into a conferencing service run by
>> economyconferencecall.com.  This should allow you to dial in
>> toll-free and is using an account set-up by John Unsworth that is
>> being used for the Board as well and the TEI-C will pay for the
>> toll-free calls.  (Though the cost is per call so I'll try to
>> convince Sebastian to share a conference phone with me.)
>>
>> I'm not entirely sure where all of you will be on Tuesday, so
>> I've retrieved the toll free numbers for:
>>
>> US and Canada: 866-906-0040
>> France (excl. Monaco): 0-800-916-758
>> Germany: 0-800-182-0270
>> New Zealand: 0-800-446-259
>> Poland: 00-800-112-4271 (0.35 zloty charge)
>> UK: 0-800-635-0541
>>
>> Dial the appropriate number, and then enter the access code:
>> 4614041 followed by the # button. You'll be asked to give your
>> name. I'm told you can mute/unmute your line using *6 but have
>> never tried it myself.
>>
>> I have a draft agenda at http://wiki.tei-c.org/index.php/Council
>>
>> Can I have a volunteer to take minutes?
>>
>> -James
>>
>


-- 
Dr James Cummings, InfoDev,
Computing Services, University of Oxford

From James.Cummings at oucs.ox.ac.uk  Fri Feb 24 06:53:02 2012
From: James.Cummings at oucs.ox.ac.uk (James Cummings)
Date: Fri, 24 Feb 2012 11:53:02 +0000
Subject: [tei-council] TEI Telco February 2012
In-Reply-To: <4F4779CA.1090700@oucs.ox.ac.uk>
References: <4F466B6A.5060107@oucs.ox.ac.uk> <4F46D4BB.4010604@o2.pl>
	<4F4779CA.1090700@oucs.ox.ac.uk>
Message-ID: <4F477A1E.6010006@oucs.ox.ac.uk>

On 24/02/12 11:51, James Cummings wrote:
> If skype conversations are all held by people are a computer they
> are free. However, in the past it has often been found that the

s/are a computer/who are on a computer/

*sigh*

-James

-- 
Dr James Cummings, InfoDev,
Computing Services, University of Oxford

From mholmes at uvic.ca  Fri Feb 24 08:29:32 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Fri, 24 Feb 2012 05:29:32 -0800
Subject: [tei-council] Glines problem with model.persStateLike
Message-ID: <4F4790BC.5090809@uvic.ca>

Hi all,

Jens has submitted another detailed list of Guidelines problems which 
I'm working through:

http://purl.org/TEI/BUGS/3492947

One refers to this section:

<http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ND.html#NDPERSEpc>

The list of elements which are supposed to be members of 
model.persStateLike appears to be incorrect:

<state> and <trait> are missing, although they are both discussed later. 
I think they should be added to the list.

<langKnown> appears not to be a member of model.persStateLike, and as 
far as I can tell from SVN, never has been. It's a child of 
<langKnowledge>, which is a member. Its inclusion in the list is 
therefore a bit misleading. It is discussed as part of the discussion of 
<langKnowledge>, its parent.

Therefore I propose removing <langKnown> and adding <state> and <trait> 
to the list. Any objections?

Cheers,
Martin

From James.Cummings at oucs.ox.ac.uk  Fri Feb 24 10:27:47 2012
From: James.Cummings at oucs.ox.ac.uk (James Cummings)
Date: Fri, 24 Feb 2012 15:27:47 +0000
Subject: [tei-council] Glines problem with model.persStateLike
In-Reply-To: <4F4790BC.5090809@uvic.ca>
References: <4F4790BC.5090809@uvic.ca>
Message-ID: <4F47AC73.7030707@oucs.ox.ac.uk>

On 24/02/12 13:29, Martin Holmes wrote:
> <http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ND.html#NDPERSEpc>
>
> The list of elements which are supposed to be members of
> model.persStateLike appears to be incorrect:
>
> <state>  and<trait>  are missing, although they are both discussed later.
> I think they should be added to the list.

Yes, this is probably an omission on my part from the 
rationalisation of state and trait to make state the default from 
a previous ticket.


> Therefore I propose removing<langKnown>  and adding<state>  and<trait>
> to the list. Any objections?

<langKnown> needs to be mentioned at some point near there 
because it is a child element of <langKnowledge>, as seen in the 
examples just a bit down.

-James


-- 
Dr James Cummings, InfoDev,
Computing Services, University of Oxford

From mholmes at uvic.ca  Fri Feb 24 11:02:44 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Fri, 24 Feb 2012 08:02:44 -0800
Subject: [tei-council] Glines problem with model.persStateLike
In-Reply-To: <4F47AC73.7030707@oucs.ox.ac.uk>
References: <4F4790BC.5090809@uvic.ca> <4F47AC73.7030707@oucs.ox.ac.uk>
Message-ID: <4F47B4A4.1060407@uvic.ca>

OK, that's done: <langKnown> commented out, and <state> and <trait> 
added. <langKnown> is discussed in the context of <langKnowledge>, so 
it's in the text, but it's not true to say it's a member of 
model.persStateLike.

Cheers,
Martin

On 12-02-24 07:27 AM, James Cummings wrote:
> On 24/02/12 13:29, Martin Holmes wrote:
>> <http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ND.html#NDPERSEpc>
>>
>> The list of elements which are supposed to be members of
>> model.persStateLike appears to be incorrect:
>>
>> <state>   and<trait>   are missing, although they are both discussed later.
>> I think they should be added to the list.
>
> Yes, this is probably an omission on my part from the
> rationalisation of state and trait to make state the default from
> a previous ticket.
>
>
>> Therefore I propose removing<langKnown>   and adding<state>   and<trait>
>> to the list. Any objections?
>
> <langKnown>  needs to be mentioned at some point near there
> because it is a child element of<langKnowledge>, as seen in the
> examples just a bit down.
>
> -James
>
>

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From lou.burnard at retired.ox.ac.uk  Fri Feb 24 13:34:37 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Fri, 24 Feb 2012 18:34:37 +0000
Subject: [tei-council] unmarked for gender
Message-ID: <4F47D83D.7050404@retired.ox.ac.uk>

Martin writes in response to a recent sf ticket (3492947)

 > "and the encoder" => "and encoders" (cf. "their" below).
 > This is a use of "their" for a 3rd-person singular unmarked for gender
 > (instead of "his/her", which is felt to be ungainly). I think this is 
 > now probably acceptable in formal written English.

Maybe someone would like to record in our stylistic guidelines that this 
usage is not just "probably acceptable" but actually our preferred 
practice? Certainly it's mine!





From mholmes at uvic.ca  Fri Feb 24 13:44:08 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Fri, 24 Feb 2012 10:44:08 -0800
Subject: [tei-council] unmarked for gender
In-Reply-To: <4F47D83D.7050404@retired.ox.ac.uk>
References: <4F47D83D.7050404@retired.ox.ac.uk>
Message-ID: <4F47DA78.1080601@uvic.ca>

Done. I've added a new section to the "Editing the Guidelines" document:

<http://www.tei-c.org/Activities/Council/Working/tcw20.xml#house-style-usage>

called "House style: notes on usage". We can use this to collect 
together snippets and preferences like this, until we reach a point 
where we create a formal style guide.

Cheers,
Martin

On 12-02-24 10:34 AM, Lou Burnard wrote:
> Martin writes in response to a recent sf ticket (3492947)
>
>   >  "and the encoder" =>  "and encoders" (cf. "their" below).
>   >  This is a use of "their" for a 3rd-person singular unmarked for gender
>   >  (instead of "his/her", which is felt to be ungainly). I think this is
>   >  now probably acceptable in formal written English.
>
> Maybe someone would like to record in our stylistic guidelines that this
> usage is not just "probably acceptable" but actually our preferred
> practice? Certainly it's mine!
>
>
>
>

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From mholmes at uvic.ca  Sat Feb 25 13:18:17 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Sat, 25 Feb 2012 10:18:17 -0800
Subject: [tei-council] Standardi[s|z]ation
Message-ID: <4F4925E9.8020105@uvic.ca>

Hi all,

One of Jens's excellent proofing reports suggests that we standardize 
spellings ending in -ise/-ize. I'm inclined to agree, and with -ise 
looking a bit beleaguered these days, I think it should be -ize. Lou 
agrees, on the ticket.

So I ran this regex to see what we have:

is((e[d|s]*)|(ing))\b

It found 1529 instances, most of which aren't relevant ("otherwise", 
"raise" etc.). But amongst those which are, they don't all seem clear 
cut to me, though. I think these are uncontroversial:

standardise
normalise
capitalise
specialise
summarise
computerise
italicise
recognise
regularise
categorise

But what about these? I feel instinctively less happy with changing 
these to z, for some reason:

harmonise
compromise
analyse
exercise
utilise

and I think these cannot be changed to z, even though, in many cases, 
variants with z are attested:

comprise
revise
devise
advise
excise

So what do your instincts tell you about these? Should we basically make 
a list of words which should use z, and put it in our style guide?

Making the changes will be a significant job, because there are 
instances of similar words in French that mustn't be changed ("utilise", 
for instance). I think it'll best be done with XSLT (which can be 
language-aware, and ignore the French) and some very precise regexes.

Cheers,
Martin

From lou.burnard at retired.ox.ac.uk  Sat Feb 25 13:42:52 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Sat, 25 Feb 2012 18:42:52 +0000
Subject: [tei-council] Standardi[s|z]ation
In-Reply-To: <4F4925E9.8020105@uvic.ca>
References: <4F4925E9.8020105@uvic.ca>
Message-ID: <4F492BAC.2080904@retired.ox.ac.uk>

Michael Quinnion is good on this, (as on many other things)

  http://www.worldwidewords.org/qa/qa-ise1.htm

The -IZE suffix only applize to words which (etymologically speaking) 
come to use from a Latinized version of a Greek suffix. That's the 
rationale given by the OED anyway.

I don't think we should be guided by "instinct" here. Look em up.


On 25/02/12 18:18, Martin Holmes wrote:
> Hi all,
>
> One of Jens's excellent proofing reports suggests that we standardize
> spellings ending in -ise/-ize. I'm inclined to agree, and with -ise
> looking a bit beleaguered these days, I think it should be -ize. Lou
> agrees, on the ticket.
>
> So I ran this regex to see what we have:
>
> is((e[d|s]*)|(ing))\b
>
> It found 1529 instances, most of which aren't relevant ("otherwise",
> "raise" etc.). But amongst those which are, they don't all seem clear
> cut to me, though. I think these are uncontroversial:
>
> standardise
> normalise
> capitalise
> specialise
> summarise
> computerise
> italicise
> recognise
> regularise
> categorise
>
> But what about these? I feel instinctively less happy with changing
> these to z, for some reason:
>
> harmonise
> compromise
> analyse
> exercise
> utilise
>
> and I think these cannot be changed to z, even though, in many cases,
> variants with z are attested:
>
> comprise
> revise
> devise
> advise
> excise
>
> So what do your instincts tell you about these? Should we basically make
> a list of words which should use z, and put it in our style guide?
>
> Making the changes will be a significant job, because there are
> instances of similar words in French that mustn't be changed ("utilise",
> for instance). I think it'll best be done with XSLT (which can be
> language-aware, and ignore the French) and some very precise regexes.
>
> Cheers,
> Martin


From kevin.s.hawkins at ultraslavonic.info  Sat Feb 25 19:12:40 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Sat, 25 Feb 2012 19:12:40 -0500
Subject: [tei-council] some brief reports to save time during our upcoming
	conf call
Message-ID: <4F4978F8.205@ultraslavonic.info>

Gang,

This is the second of two promised emails.  This one gives summaries of 
a couple of activities I've been involved in -- all on the agenda under 
"brief reports".  I'm sending these in advance so that we can use the 
time during our call for discussion of these.

= Bibliographic Citations =

Martin Holmes, Laurent Romary, and I (a.k.a. "the biblio gang") have 
been trying to clarify the Guidelines in matters relating to 
bibliographic citations.  Some clarifying copyedits were made after the 
Dublin meeting, and tickets were created on the substantial changes. 
Those tickets have all been discussed and resolved by Council except 
one: bug 2714682, in which we are wrestling with four related issues:

a) whether biblScope should have different semantics depending on its 
parent element

b) whether the Guidelines should be more explicit on whether to use 
biblScope as a child of <imprint> and what it means if it is a child of 
<imprint>

c) whether to add <biblScope> as an allowed child of <analytic>

d) whether we should distinguish between two types of page ranges: those 
pages cited, and the whole range of the item

The three of us are currently discussing these questions by email and 
are converging on a proposed solution, which we will post to the ticket 
and bring back to the Council for consideration.

= TEI Tite =

In September 2010, Laurent appointed me, Greg Suprock (of Apex 
CoVantage), and Perry Trolard (author of Tite) to a workgroup to realign 
the version of Tite used by Apex CoVantage with the canonical version 
maintained in SourceForge and to oversee ongoing evolution of Tite.

Since Apex only maintains a DTD, changes that they made had to be 
recreated in the master ODD in SourceForge.  I believe I've reconciled 
everything, but I have not yet made the time to generate a DTD from the 
latest ODD and check for discrepancies with Apex's version.  This will 
be complicated by the fact that any changes to P5 since Apex first 
created their DTD may filter through when I create a DTD using Roma.

Next up will be taking up various bugs and feature requests related to 
Tite in SourceForge.  These changes would need to be made not only in 
the Tite ODD but also communicated to Apex so that they begin using them 
in their encoding.

= Google Books =

In September 2011, Laurent charged James Cummings, Martin Holmes, me, 
and himself with providing guidance to an engineer from Google who is 
working on adding TEI as an export format for Google Books.

We've been in occasional contact with the engineer, who produced some 
sample documents and asked for feedback.  In addition to our feedback, 
he used a schema for Level 3 of the Best Practices for TEI in Libraries 
in order to check his output (though mixing in Level-4 elements when has 
the data to do so) and was in contact with the Google Books Library 
Partners about how useful the TEI output would be.  He reported earlier 
this month that "The code has been reviewed and checked in but we're 
still working on some questions related to integrating the code in our 
production pipeline."  He said he might come back for help as they get 
closer to deploying and encouraged us to check back in.

The importance of this for the TEI's PR can't really be understated. 
We, or the Board, might want to give some thought about whether to do 
anything more once Google deloys this code than simply announce it on 
TEI-L with shouts of hurrah/hooray/huzzah.

= Physical Bibliography =

While in Paris, we dealt with a feature request to handle encoding of a 
printer, distributor, etc.  This led someone to suggest we revive the 
Physical Bibliography Work Group, which never completed its work.  Some 
of its recommendations were included in the manuscript description 
module, but other parts were never fully resolved.  We decided that I 
would ask Paul Schaffner and Markus Flatscher if they would be willing 
to revive this group.  I never heard back from either of them.

However, at the 2011 HASTAC conference, one panel included some papers 
from grad students on physical bibliography, which included discussion 
of the inadequacies of TEI markup in that area.  In short: if you want 
to physical/descriptive bibliography of printed books, the elements you 
need are children of msDesc, but the description of this element and its 
children refer to handwritten manuscripts only.

I spoke to the presenters afterwards and asked take over the group with 
guidance from me.  They were quite enthusiastic but have since decided 
that they don't have the time to lead the effort but would still like to 
participate.  They shared their papers with me.

Coincidentally, Sebastiaan Verweij posted to TEI-L in late January with 
very similar concerns to those of the HASTAC presenters.  I've never met 
Sebastiaan at all, but if Council thinks it's appropriate, I'd like to 
approach him to ask him to lead the revival of the Physical Bibliography 
Work Group (with input from the HASTAC presenters and guidance from me 
and anyone else interested in participating).

--Kevin

From lou.burnard at retired.ox.ac.uk  Sun Feb 26 09:34:12 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Sun, 26 Feb 2012 14:34:12 +0000
Subject: [tei-council] Standardi[s|z]ation
In-Reply-To: <4F492BAC.2080904@retired.ox.ac.uk>
References: <4F4925E9.8020105@uvic.ca> <4F492BAC.2080904@retired.ox.ac.uk>
Message-ID: <4F4A42E4.9050203@retired.ox.ac.uk>

Further to my rather cryptic comment below: my recommendation is

a) look up the word in the OED
b) if it says that both -IZE and -ISE forms are usable, use the -IZE form.
c) otherwise use the -ISE form.


n 25/02/12 18:42, Lou Burnard wrote:
> Michael Quinnion is good on this, (as on many other things)
>
>    http://www.worldwidewords.org/qa/qa-ise1.htm
>
> The -IZE suffix only applize to words which (etymologically speaking)
> come to use from a Latinized version of a Greek suffix. That's the
> rationale given by the OED anyway.
>
> I don't think we should be guided by "instinct" here. Look em up.
>
>
> On 25/02/12 18:18, Martin Holmes wrote:
>> Hi all,
>>
>> One of Jens's excellent proofing reports suggests that we standardize
>> spellings ending in -ise/-ize. I'm inclined to agree, and with -ise
>> looking a bit beleaguered these days, I think it should be -ize. Lou
>> agrees, on the ticket.
>>
>> So I ran this regex to see what we have:
>>
>> is((e[d|s]*)|(ing))\b
>>
>> It found 1529 instances, most of which aren't relevant ("otherwise",
>> "raise" etc.). But amongst those which are, they don't all seem clear
>> cut to me, though. I think these are uncontroversial:
>>
>> standardise
>> normalise
>> capitalise
>> specialise
>> summarise
>> computerise
>> italicise
>> recognise
>> regularise
>> categorise
>>
>> But what about these? I feel instinctively less happy with changing
>> these to z, for some reason:
>>
>> harmonise
>> compromise
>> analyse
>> exercise
>> utilise
>>
>> and I think these cannot be changed to z, even though, in many cases,
>> variants with z are attested:
>>
>> comprise
>> revise
>> devise
>> advise
>> excise
>>
>> So what do your instincts tell you about these? Should we basically make
>> a list of words which should use z, and put it in our style guide?
>>
>> Making the changes will be a significant job, because there are
>> instances of similar words in French that mustn't be changed ("utilise",
>> for instance). I think it'll best be done with XSLT (which can be
>> language-aware, and ignore the French) and some very precise regexes.
>>
>> Cheers,
>> Martin
>


From kevin.s.hawkins at ultraslavonic.info  Sun Feb 26 09:50:27 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Sun, 26 Feb 2012 09:50:27 -0500
Subject: [tei-council] Standardi[s|z]ation
In-Reply-To: <4F4A42E4.9050203@retired.ox.ac.uk>
References: <4F4925E9.8020105@uvic.ca> <4F492BAC.2080904@retired.ox.ac.uk>
	<4F4A42E4.9050203@retired.ox.ac.uk>
Message-ID: <4F4A46B3.9010508@ultraslavonic.info>

This seems like good policy to add to 
http://www.tei-c.org/Activities/Council/Working/tcw20.xml#house-style-orthography 
and I think also to P5/Source/Guidelines/en/style-guide.txt .

It continues to bother me that we repeat information in these two 
documents, which could easily fall out of sync.  I would suggest having 
one point to the other, but I'm not sure which should be primary.  Thoughts?

On 2/26/12 9:34 AM, Lou Burnard wrote:
> Further to my rather cryptic comment below: my recommendation is
>
> a) look up the word in the OED
> b) if it says that both -IZE and -ISE forms are usable, use the -IZE form.
> c) otherwise use the -ISE form.
>
>
> n 25/02/12 18:42, Lou Burnard wrote:
>> Michael Quinnion is good on this, (as on many other things)
>>
>>     http://www.worldwidewords.org/qa/qa-ise1.htm
>>
>> The -IZE suffix only applize to words which (etymologically speaking)
>> come to use from a Latinized version of a Greek suffix. That's the
>> rationale given by the OED anyway.
>>
>> I don't think we should be guided by "instinct" here. Look em up.
>>
>>
>> On 25/02/12 18:18, Martin Holmes wrote:
>>> Hi all,
>>>
>>> One of Jens's excellent proofing reports suggests that we standardize
>>> spellings ending in -ise/-ize. I'm inclined to agree, and with -ise
>>> looking a bit beleaguered these days, I think it should be -ize. Lou
>>> agrees, on the ticket.
>>>
>>> So I ran this regex to see what we have:
>>>
>>> is((e[d|s]*)|(ing))\b
>>>
>>> It found 1529 instances, most of which aren't relevant ("otherwise",
>>> "raise" etc.). But amongst those which are, they don't all seem clear
>>> cut to me, though. I think these are uncontroversial:
>>>
>>> standardise
>>> normalise
>>> capitalise
>>> specialise
>>> summarise
>>> computerise
>>> italicise
>>> recognise
>>> regularise
>>> categorise
>>>
>>> But what about these? I feel instinctively less happy with changing
>>> these to z, for some reason:
>>>
>>> harmonise
>>> compromise
>>> analyse
>>> exercise
>>> utilise
>>>
>>> and I think these cannot be changed to z, even though, in many cases,
>>> variants with z are attested:
>>>
>>> comprise
>>> revise
>>> devise
>>> advise
>>> excise
>>>
>>> So what do your instincts tell you about these? Should we basically make
>>> a list of words which should use z, and put it in our style guide?
>>>
>>> Making the changes will be a significant job, because there are
>>> instances of similar words in French that mustn't be changed ("utilise",
>>> for instance). I think it'll best be done with XSLT (which can be
>>> language-aware, and ignore the French) and some very precise regexes.
>>>
>>> Cheers,
>>> Martin
>>
>

From kevin.s.hawkins at ultraslavonic.info  Sun Feb 26 11:41:11 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Sun, 26 Feb 2012 11:41:11 -0500
Subject: [tei-council] P5 releases: changes to boilerplate HTML code
In-Reply-To: <4F46E23A.2030509@ultraslavonic.info>
References: <4F46E23A.2030509@ultraslavonic.info>
Message-ID: <4F4A60A7.1050809@ultraslavonic.info>

One more suggestion:

d) In the "Declaration" section of each element definition, there's an 
HTML button that says "Compact to XML format".  If you click on it, the 
button label changes to say "XML format to compact".  These labels are 
confusing, so I'd like to suggest changing as follows:

"Compact to XML format" --> "Switch to XML format"

XML format to compact" --> "Switch to compact format"

On 2/23/12 8:04 PM, Kevin Hawkins wrote:
> I recall that when a new release of the TEI is made, all of the stuff at
> the top of each HTML page -- the TEI logo, the navbar, the search box,
> and the phrase "P5: Guidelines for Electronic Text Encoding and
> Interchange" -- is inserted at time of compilation. Somewhere there is a
> file that stores the bits of HTML code needed for this.
>
> Related to that, a few things:
>
> a) This code is in need of updating: the menu options have not kept up
> with things being used on the TEI website.
>
> b) We should note the location of the code in tcw22 and make a note to
> compare against what's currently in use on the TEI website and adjust as
> necessary.
>
> c) Currently the P5 version number is in fine print at the bottom of the
> page, along with the last updated information. To a casual visitor, this
> looks like a version number for the particular HTML file, not the full
> guidelines. Furthermore, a casual visitor is unlikely to ever see this.
> Therefore, I'd like to request that we modify the code to insert the
> current version number somewhere near "P5: Guidelines for Electronic
> Text Encoding and Interchange". Right now there's no straightforward way
> for someone to know that there are versions of P5 and to know which they
> are looking at, and I think this would make it obvious that the
> Guidelines are in fact under constant evolution.
>
> --Kevin

From sebastian.rahtz at oucs.ox.ac.uk  Sun Feb 26 12:21:41 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Sun, 26 Feb 2012 17:21:41 +0000
Subject: [tei-council] P5 releases: changes to boilerplate HTML code
In-Reply-To: <4F4A60A7.1050809@ultraslavonic.info>
References: <4F46E23A.2030509@ultraslavonic.info>
	<4F4A60A7.1050809@ultraslavonic.info>
Message-ID: <4201B678-EDB6-46F3-9E4D-2E746FFEBB58@oucs.ox.ac.uk>


On 26 Feb 2012, at 16:41, Kevin Hawkins wrote:

> One more suggestion:
> 
> d) In the "Declaration" section of each element definition, there's an 
> HTML button that says "Compact to XML format".  If you click on it, the 
> button label changes to say "XML format to compact".  These labels are 
> confusing, so I'd like to suggest changing as follows:
> 
> "Compact to XML format" --> "Switch to XML format"
> 
> XML format to compact" --> "Switch to compact format"

This is easier than it sounds. We'd have to get re-translations of the
phrase for each language.   I don't mind, but whats the evidence
that the existing words are confusing? its not been questioned
in the ?6-7 years we've had the facility.

--
Stormageddon Rahtz      
Head of Information and Support Group, Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431

S?lo le pido a Dios
que el futuro no me sea indiferente


From mholmes at uvic.ca  Sun Feb 26 12:30:58 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Sun, 26 Feb 2012 09:30:58 -0800
Subject: [tei-council] Standardi[s|z]ation
In-Reply-To: <4F4A46B3.9010508@ultraslavonic.info>
References: <4F4925E9.8020105@uvic.ca> <4F492BAC.2080904@retired.ox.ac.uk>
	<4F4A42E4.9050203@retired.ox.ac.uk>
	<4F4A46B3.9010508@ultraslavonic.info>
Message-ID: <4F4A6C52.6060906@uvic.ca>

I think we should spin off the styleguide into a separate Working Paper 
(since it's definitely a work in progress), and point to it from both 
locations. There's a lot of work to do here, assuming that we're going 
to maintain our own styleguide rather than adopt an existing one. It 
deserves its own document.

Cheers,
Martin

On 12-02-26 06:50 AM, Kevin Hawkins wrote:
> This seems like good policy to add to
> http://www.tei-c.org/Activities/Council/Working/tcw20.xml#house-style-orthography
> and I think also to P5/Source/Guidelines/en/style-guide.txt .
>
> It continues to bother me that we repeat information in these two
> documents, which could easily fall out of sync.  I would suggest having
> one point to the other, but I'm not sure which should be primary.  Thoughts?
>
> On 2/26/12 9:34 AM, Lou Burnard wrote:
>> Further to my rather cryptic comment below: my recommendation is
>>
>> a) look up the word in the OED
>> b) if it says that both -IZE and -ISE forms are usable, use the -IZE form.
>> c) otherwise use the -ISE form.
>>
>>
>> n 25/02/12 18:42, Lou Burnard wrote:
>>> Michael Quinnion is good on this, (as on many other things)
>>>
>>>      http://www.worldwidewords.org/qa/qa-ise1.htm
>>>
>>> The -IZE suffix only applize to words which (etymologically speaking)
>>> come to use from a Latinized version of a Greek suffix. That's the
>>> rationale given by the OED anyway.
>>>
>>> I don't think we should be guided by "instinct" here. Look em up.
>>>
>>>
>>> On 25/02/12 18:18, Martin Holmes wrote:
>>>> Hi all,
>>>>
>>>> One of Jens's excellent proofing reports suggests that we standardize
>>>> spellings ending in -ise/-ize. I'm inclined to agree, and with -ise
>>>> looking a bit beleaguered these days, I think it should be -ize. Lou
>>>> agrees, on the ticket.
>>>>
>>>> So I ran this regex to see what we have:
>>>>
>>>> is((e[d|s]*)|(ing))\b
>>>>
>>>> It found 1529 instances, most of which aren't relevant ("otherwise",
>>>> "raise" etc.). But amongst those which are, they don't all seem clear
>>>> cut to me, though. I think these are uncontroversial:
>>>>
>>>> standardise
>>>> normalise
>>>> capitalise
>>>> specialise
>>>> summarise
>>>> computerise
>>>> italicise
>>>> recognise
>>>> regularise
>>>> categorise
>>>>
>>>> But what about these? I feel instinctively less happy with changing
>>>> these to z, for some reason:
>>>>
>>>> harmonise
>>>> compromise
>>>> analyse
>>>> exercise
>>>> utilise
>>>>
>>>> and I think these cannot be changed to z, even though, in many cases,
>>>> variants with z are attested:
>>>>
>>>> comprise
>>>> revise
>>>> devise
>>>> advise
>>>> excise
>>>>
>>>> So what do your instincts tell you about these? Should we basically make
>>>> a list of words which should use z, and put it in our style guide?
>>>>
>>>> Making the changes will be a significant job, because there are
>>>> instances of similar words in French that mustn't be changed ("utilise",
>>>> for instance). I think it'll best be done with XSLT (which can be
>>>> language-aware, and ignore the French) and some very precise regexes.
>>>>
>>>> Cheers,
>>>> Martin
>>>
>>

-- 
Martin Holmes
mholmes at uvic.ca
UVic Humanities Computing and Media Centre

From kevin.s.hawkins at ultraslavonic.info  Sun Feb 26 12:43:05 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Sun, 26 Feb 2012 12:43:05 -0500
Subject: [tei-council] P5 releases: changes to boilerplate HTML code
In-Reply-To: <4201B678-EDB6-46F3-9E4D-2E746FFEBB58@oucs.ox.ac.uk>
References: <4F46E23A.2030509@ultraslavonic.info>
	<4F4A60A7.1050809@ultraslavonic.info>
	<4201B678-EDB6-46F3-9E4D-2E746FFEBB58@oucs.ox.ac.uk>
Message-ID: <4F4A6F29.8030500@ultraslavonic.info>

On 2/26/12 12:21 PM, Sebastian Rahtz wrote:
>
> On 26 Feb 2012, at 16:41, Kevin Hawkins wrote:
>
>> One more suggestion:
>>
>> d) In the "Declaration" section of each element definition, there's an
>> HTML button that says "Compact to XML format".  If you click on it, the
>> button label changes to say "XML format to compact".  These labels are
>> confusing, so I'd like to suggest changing as follows:
>>
>> "Compact to XML format" -->  "Switch to XML format"
>>
>> XML format to compact" -->  "Switch to compact format"
>
> This is easier than it sounds. We'd have to get re-translations of the
> phrase for each language.   I don't mind, but whats the evidence
> that the existing words are confusing? its not been questioned
> in the ?6-7 years we've had the facility.

I confess that until this morning, I read "Compact to XML format" as "if 
you click this, it will compact what you see into an XML format".  But 
clicking on it gives you something more verbose, which is counter-intuitive.

Likewise, I read "XML format to compact" as "if you click this, it will 
give you an XML format, which you can compact", but it in fact gives you 
RelaxNG compact format.

It's true that those who need to figure things out without questioning, 
but I'd like us to continue to strive for ease of use in everything we 
provide.  This includes clear labeling.

From sebastian.rahtz at oucs.ox.ac.uk  Sun Feb 26 15:38:20 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Sun, 26 Feb 2012 20:38:20 +0000
Subject: [tei-council] P5 releases: changes to boilerplate HTML code
In-Reply-To: <4F46E23A.2030509@ultraslavonic.info>
References: <4F46E23A.2030509@ultraslavonic.info>
Message-ID: <05D6A411-463E-4350-9A79-BEF71FA51479@oucs.ox.ac.uk>


On 24 Feb 2012, at 01:04, Kevin Hawkins wrote:

> I recall that when a new release of the TEI is made, all of the stuff at 
> the top of each HTML page -- the TEI logo, the navbar, the search box, 
> and the phrase "P5: Guidelines for Electronic Text Encoding and 
> Interchange" -- is inserted at time of compilation.  Somewhere there is 
> a file that stores the bits of HTML code needed for this.

indeed. its in P5/Utilities/staticnav.xml in Sourceforge for Guldelines. Any of us can edit
this in the usual way and it'll get picked up at the next build.


> c) Currently the P5 version number is in fine print at the bottom of the 
> page, along with the last updated information.  To a casual visitor, 
> this looks like a version number for the particular HTML file, not the 
> full guidelines.
I have inserted "TEI Guidelines " before the word "Version" (P5/Utilities/guidelines.xsl.model),
does that help?

>  Therefore, I'd like to request that we modify the code to insert 
> the current version number somewhere near "P5: Guidelines for Electronic 
> Text Encoding and Interchange". 

I have added it inside a <p> after the <h1> of the "P5: ...", is that OK?
--
Stormageddon Rahtz      
Head of Information and Support Group, Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431

S?lo le pido a Dios
que el futuro no me sea indiferente


From lou.burnard at retired.ox.ac.uk  Sun Feb 26 18:08:24 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Sun, 26 Feb 2012 23:08:24 +0000
Subject: [tei-council] Standardi[s|z]ation
In-Reply-To: <4F4A6C52.6060906@uvic.ca>
References: <4F4925E9.8020105@uvic.ca>
	<4F492BAC.2080904@retired.ox.ac.uk>	<4F4A42E4.9050203@retired.ox.ac.uk>	<4F4A46B3.9010508@ultraslavonic.info>
	<4F4A6C52.6060906@uvic.ca>
Message-ID: <4F4ABB68.6060909@retired.ox.ac.uk>

Well, P5/Source/Guidelines/en/style-guide.txt is really only the 
beginnings of a style guide. I copied the whole of it into tcw20.xml 
because it seemed convenient to have everything in one place. By all 
means let's work on elaborating it (and perhaps, when it gets bigger, 
replacing it by a link in tcw20), but there's no need to maintain this 
information in  THREE places surely?



the On 26/02/12 17:30, Martin Holmes wrote:
> I think we should spin off the styleguide into a separate Working Paper
> (since it's definitely a work in progress), and point to it from both
> locations. There's a lot of work to do here, assuming that we're going
> to maintain our own styleguide rather than adopt an existing one. It
> deserves its own document.
>
> Cheers,
> Martin
>
> On 12-02-26 06:50 AM, Kevin Hawkins wrote:
>> This seems like good policy to add to
>> http://www.tei-c.org/Activities/Council/Working/tcw20.xml#house-style-orthography
>> and I think also to P5/Source/Guidelines/en/style-guide.txt .
>>
>> It continues to bother me that we repeat information in these two
>> documents, which could easily fall out of sync.  I would suggest having
>> one point to the other, but I'm not sure which should be primary.  Thoughts?
>>
>> On 2/26/12 9:34 AM, Lou Burnard wrote:
>>> Further to my rather cryptic comment below: my recommendation is
>>>
>>> a) look up the word in the OED
>>> b) if it says that both -IZE and -ISE forms are usable, use the -IZE form.
>>> c) otherwise use the -ISE form.
>>>
>>>
>>> n 25/02/12 18:42, Lou Burnard wrote:
>>>> Michael Quinnion is good on this, (as on many other things)
>>>>
>>>>       http://www.worldwidewords.org/qa/qa-ise1.htm
>>>>
>>>> The -IZE suffix only applize to words which (etymologically speaking)
>>>> come to use from a Latinized version of a Greek suffix. That's the
>>>> rationale given by the OED anyway.
>>>>
>>>> I don't think we should be guided by "instinct" here. Look em up.
>>>>
>>>>
>>>> On 25/02/12 18:18, Martin Holmes wrote:
>>>>> Hi all,
>>>>>
>>>>> One of Jens's excellent proofing reports suggests that we standardize
>>>>> spellings ending in -ise/-ize. I'm inclined to agree, and with -ise
>>>>> looking a bit beleaguered these days, I think it should be -ize. Lou
>>>>> agrees, on the ticket.
>>>>>
>>>>> So I ran this regex to see what we have:
>>>>>
>>>>> is((e[d|s]*)|(ing))\b
>>>>>
>>>>> It found 1529 instances, most of which aren't relevant ("otherwise",
>>>>> "raise" etc.). But amongst those which are, they don't all seem clear
>>>>> cut to me, though. I think these are uncontroversial:
>>>>>
>>>>> standardise
>>>>> normalise
>>>>> capitalise
>>>>> specialise
>>>>> summarise
>>>>> computerise
>>>>> italicise
>>>>> recognise
>>>>> regularise
>>>>> categorise
>>>>>
>>>>> But what about these? I feel instinctively less happy with changing
>>>>> these to z, for some reason:
>>>>>
>>>>> harmonise
>>>>> compromise
>>>>> analyse
>>>>> exercise
>>>>> utilise
>>>>>
>>>>> and I think these cannot be changed to z, even though, in many cases,
>>>>> variants with z are attested:
>>>>>
>>>>> comprise
>>>>> revise
>>>>> devise
>>>>> advise
>>>>> excise
>>>>>
>>>>> So what do your instincts tell you about these? Should we basically make
>>>>> a list of words which should use z, and put it in our style guide?
>>>>>
>>>>> Making the changes will be a significant job, because there are
>>>>> instances of similar words in French that mustn't be changed ("utilise",
>>>>> for instance). I think it'll best be done with XSLT (which can be
>>>>> language-aware, and ignore the French) and some very precise regexes.
>>>>>
>>>>> Cheers,
>>>>> Martin
>>>>
>>>
>


From kevin.s.hawkins at ultraslavonic.info  Sun Feb 26 21:34:45 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Sun, 26 Feb 2012 21:34:45 -0500
Subject: [tei-council] P5 releases: changes to boilerplate HTML code
In-Reply-To: <05D6A411-463E-4350-9A79-BEF71FA51479@oucs.ox.ac.uk>
References: <4F46E23A.2030509@ultraslavonic.info>
	<05D6A411-463E-4350-9A79-BEF71FA51479@oucs.ox.ac.uk>
Message-ID: <4F4AEBC5.4060708@ultraslavonic.info>

On 2/26/12 3:38 PM, Sebastian Rahtz wrote:
>> c) Currently the P5 version number is in fine print at the bottom of the
>> page, along with the last updated information.  To a casual visitor,
>> this looks like a version number for the particular HTML file, not the
>> full guidelines.
> I have inserted "TEI Guidelines " before the word "Version" (P5/Utilities/guidelines.xsl.model),
> does that help?

Yes.

>>   Therefore, I'd like to request that we modify the code to insert
>> the current version number somewhere near "P5: Guidelines for Electronic
>> Text Encoding and Interchange".
>
> I have added it inside a<p>  after the<h1>  of the "P5: ...", is that OK?

Yes, except that the <p> is aligned left whereas the <h1> is aligned 
right.  Is it safe to just edit guidelines.css in the same directory to 
pretty things up?

--K.

From sebastian.rahtz at oucs.ox.ac.uk  Mon Feb 27 04:05:55 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Mon, 27 Feb 2012 09:05:55 +0000
Subject: [tei-council] P5 releases: changes to boilerplate HTML code
In-Reply-To: <4F4AEBC5.4060708@ultraslavonic.info>
References: <4F46E23A.2030509@ultraslavonic.info>
	<05D6A411-463E-4350-9A79-BEF71FA51479@oucs.ox.ac.uk>
	<4F4AEBC5.4060708@ultraslavonic.info>
Message-ID: <925769A7-2F5B-4EFF-8B29-42CCE3C70C7A@oucs.ox.ac.uk>

> Yes, except that the <p> is aligned left whereas the <h1> is aligned 
> right.  Is it safe to just edit guidelines.css in the same directory to 
> pretty things up?


yes, definitely. that <p> should be addressable OK?
--
Stormageddon Rahtz      
Head of Information and Support Group
Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431

S?lo le pido a Dios
que el futuro no me sea indiferente


From mholmes at uvic.ca  Mon Feb 27 08:50:47 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Mon, 27 Feb 2012 05:50:47 -0800
Subject: [tei-council] TEI telco Agenda
In-Reply-To: <4F3C533D.9060403@uvic.ca>
References: <4F3C3442.9010801@oucs.ox.ac.uk> <4F3C533D.9060403@uvic.ca>
Message-ID: <4F4B8A37.7010801@uvic.ca>

Hi all,

Following Kevin's example, I'm presenting quick outlines of the things 
I'm supposed to be reporting on at the telco:

On 16/02/12 00:52, Martin Holmes wrote:

1.3. TEI and AdBlock (MH) (Would be good to get a recap of where
things stand and what we decided)

This is bug <http://purl.org/TEI/BUGS/3472477>. The original problem 
arose when we discovered that one section of the Guidelines was 
invisible to some readers. It turned out that its @id attribute, "msad", 
was on a list of ids being blocked by AdBlock Plus. AdBlock Plus 
behaviour is controlled by any of many different blocking lists, to 
which people subscribe. The two most common lists are EasyList and 
Fanboy's List. I filed a bug with EasyList, and their maintainer fixed 
the problem within 24 hours. I also filed a bug with Fanboy's List, but 
that has been ignored.

In preparation for the Telco, I've taken a look through a
sampling of about ten of the filters listed here:

http://adblockplus.org/en/subscriptions

None of them have the specific element id "msad", although the server
"msads.net" crops up frequently. It may be the case at this point that 
only Fanboy's list has the problem, but the maintainer is completely
unresponsive. It would be impractical to check all the lists on the page
manually, although it could be automated.

There is nothing to prevent a similar problem appearing in future, with 
any of the @xml:ids which give rise to @xhtml:ids in the web version of 
the Guidelines. In view of this, Sebastian suggested changing the output 
XSLT to prefix all ids with "tei_". Lou thought this was a good idea, 
but you warned that it would break some existing links to anchors on the 
web. It would not break links to pages, only to anchors within pages. 
Personally I think it's worth breaking the links, so we should ask 
Sebastian to make the change the stylesheets, but perhaps this is a 
change that should only be made when we move to 2.1, since it may 
partially break some existing links on the web. During the Telco, 
perhaps we can make a decision on this.

1.6. Attribute Datatypes (MH)

This relates to the following bug reports:

<http://purl.org/TEI/BUGS/3441933>
<http://purl.org/TEI/BUGS/3455686>

The basic issue was that some textual descriptions of attributes did not 
match their actual formal datatypes; in investigating this, we 
discovered that many attributes didn't actually have formal datatypes. 
All of the initial problems have been fixed. A table showing the current 
state of attributes is here:

<http://web.uvic.ca/lancenrd/martin/tei/valdescs.htm>

The remaining attributes without datatypes (92 and 409 in that table) 
were intrinsically problematic (the first deprecated, the second not 
fully defined). The latter was given its own ticket:

<http://purl.org/TEI/BUGS/3486352>

which is now closed, because that issue is fixed.

So the only remaining issue is the deprecated attribute quotation/@form, 
which has no datatype. For the sake of completeness, we could assign it 
one, or we could just ignore it.

1.8. TEI Release Process Document (MH)

During the last release, several of us worked to revise a detailed 
version of the Process Release Document "Building a TEI Release", which 
is a working paper here:

<http://www.tei-c.org/Activities/Council/Working/tcw22.xml>

We now believe this is pretty much as comprehensive as it can be, and 
should be able to guide anyone through the process of making a release, 
but please read through it and bring any comments to the Telco. There 
were also a couple of post-release problems with the db that handles 
Roma, which we hope are now fixed, but we won't know for sure until 
another release has been done. Gabriel has volunteered to be the next 
release engineer.


There is one more issue I'm scheduled to speak on:

2. @ref/key/cRef & Private URI Schemes (MH)

and I'm still working on an outline of that.

Cheers,
Martin

From kevin.s.hawkins at ultraslavonic.info  Mon Feb 27 09:57:57 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Mon, 27 Feb 2012 09:57:57 -0500
Subject: [tei-council] P5 releases: changes to boilerplate HTML code
In-Reply-To: <925769A7-2F5B-4EFF-8B29-42CCE3C70C7A@oucs.ox.ac.uk>
References: <4F46E23A.2030509@ultraslavonic.info>	<05D6A411-463E-4350-9A79-BEF71FA51479@oucs.ox.ac.uk>	<4F4AEBC5.4060708@ultraslavonic.info>
	<925769A7-2F5B-4EFF-8B29-42CCE3C70C7A@oucs.ox.ac.uk>
Message-ID: <4F4B99F5.10501@ultraslavonic.info>

On 2/27/2012 4:05 AM, Sebastian Rahtz wrote:
>> Yes, except that the<p>  is aligned left whereas the<h1>  is aligned
>> right.  Is it safe to just edit guidelines.css in the same directory to
>> pretty things up?
>
>
> yes, definitely. that<p>  should be addressable OK?

I think you are asking whether the <p> for the version number is 
addressable by CSS -- that is, can I create a rule that will affect the 
display of only this <p>.  I've made this change (revision 10121) and am 
waiting for Jenkins to finish to make sure it actually displays as intended.

From mholmes at uvic.ca  Mon Feb 27 11:31:12 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Mon, 27 Feb 2012 08:31:12 -0800
Subject: [tei-council] Standardi[s|z]ation
In-Reply-To: <4F4ABB68.6060909@retired.ox.ac.uk>
References: <4F4925E9.8020105@uvic.ca>	<4F492BAC.2080904@retired.ox.ac.uk>	<4F4A42E4.9050203@retired.ox.ac.uk>	<4F4A46B3.9010508@ultraslavonic.info>	<4F4A6C52.6060906@uvic.ca>
	<4F4ABB68.6060909@retired.ox.ac.uk>
Message-ID: <4F4BAFD0.7060703@uvic.ca>

The question really is whether it's best to maintain this information in 
a text file in the Guidelines source code, or as a more public document 
on the TEI website. In the latter case, it would be in P5 and benefit 
from transformation into richer XHTML, with links etc. working.

I like the P5 option. It's currently part of TCW20 because it doesn't 
consist of much, but it's going to get bigger as we go along, so I think 
it deserves a document to itself.

Cheers,
Martin

On 12-02-26 03:08 PM, Lou Burnard wrote:
> Well, P5/Source/Guidelines/en/style-guide.txt is really only the
> beginnings of a style guide. I copied the whole of it into tcw20.xml
> because it seemed convenient to have everything in one place. By all
> means let's work on elaborating it (and perhaps, when it gets bigger,
> replacing it by a link in tcw20), but there's no need to maintain this
> information in  THREE places surely?
>
>
>
> the On 26/02/12 17:30, Martin Holmes wrote:
>> I think we should spin off the styleguide into a separate Working Paper
>> (since it's definitely a work in progress), and point to it from both
>> locations. There's a lot of work to do here, assuming that we're going
>> to maintain our own styleguide rather than adopt an existing one. It
>> deserves its own document.
>>
>> Cheers,
>> Martin
>>
>> On 12-02-26 06:50 AM, Kevin Hawkins wrote:
>>> This seems like good policy to add to
>>> http://www.tei-c.org/Activities/Council/Working/tcw20.xml#house-style-orthography
>>> and I think also to P5/Source/Guidelines/en/style-guide.txt .
>>>
>>> It continues to bother me that we repeat information in these two
>>> documents, which could easily fall out of sync.  I would suggest having
>>> one point to the other, but I'm not sure which should be primary.  Thoughts?
>>>
>>> On 2/26/12 9:34 AM, Lou Burnard wrote:
>>>> Further to my rather cryptic comment below: my recommendation is
>>>>
>>>> a) look up the word in the OED
>>>> b) if it says that both -IZE and -ISE forms are usable, use the -IZE form.
>>>> c) otherwise use the -ISE form.
>>>>
>>>>
>>>> n 25/02/12 18:42, Lou Burnard wrote:
>>>>> Michael Quinnion is good on this, (as on many other things)
>>>>>
>>>>>        http://www.worldwidewords.org/qa/qa-ise1.htm
>>>>>
>>>>> The -IZE suffix only applize to words which (etymologically speaking)
>>>>> come to use from a Latinized version of a Greek suffix. That's the
>>>>> rationale given by the OED anyway.
>>>>>
>>>>> I don't think we should be guided by "instinct" here. Look em up.
>>>>>
>>>>>
>>>>> On 25/02/12 18:18, Martin Holmes wrote:
>>>>>> Hi all,
>>>>>>
>>>>>> One of Jens's excellent proofing reports suggests that we standardize
>>>>>> spellings ending in -ise/-ize. I'm inclined to agree, and with -ise
>>>>>> looking a bit beleaguered these days, I think it should be -ize. Lou
>>>>>> agrees, on the ticket.
>>>>>>
>>>>>> So I ran this regex to see what we have:
>>>>>>
>>>>>> is((e[d|s]*)|(ing))\b
>>>>>>
>>>>>> It found 1529 instances, most of which aren't relevant ("otherwise",
>>>>>> "raise" etc.). But amongst those which are, they don't all seem clear
>>>>>> cut to me, though. I think these are uncontroversial:
>>>>>>
>>>>>> standardise
>>>>>> normalise
>>>>>> capitalise
>>>>>> specialise
>>>>>> summarise
>>>>>> computerise
>>>>>> italicise
>>>>>> recognise
>>>>>> regularise
>>>>>> categorise
>>>>>>
>>>>>> But what about these? I feel instinctively less happy with changing
>>>>>> these to z, for some reason:
>>>>>>
>>>>>> harmonise
>>>>>> compromise
>>>>>> analyse
>>>>>> exercise
>>>>>> utilise
>>>>>>
>>>>>> and I think these cannot be changed to z, even though, in many cases,
>>>>>> variants with z are attested:
>>>>>>
>>>>>> comprise
>>>>>> revise
>>>>>> devise
>>>>>> advise
>>>>>> excise
>>>>>>
>>>>>> So what do your instincts tell you about these? Should we basically make
>>>>>> a list of words which should use z, and put it in our style guide?
>>>>>>
>>>>>> Making the changes will be a significant job, because there are
>>>>>> instances of similar words in French that mustn't be changed ("utilise",
>>>>>> for instance). I think it'll best be done with XSLT (which can be
>>>>>> language-aware, and ignore the French) and some very precise regexes.
>>>>>>
>>>>>> Cheers,
>>>>>> Martin
>>>>>
>>>>
>>
>

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From gabriel.bodard at kcl.ac.uk  Mon Feb 27 11:32:48 2012
From: gabriel.bodard at kcl.ac.uk (Gabriel Bodard)
Date: Mon, 27 Feb 2012 16:32:48 +0000
Subject: [tei-council] P5 releases: changes to boilerplate HTML code
In-Reply-To: <4201B678-EDB6-46F3-9E4D-2E746FFEBB58@oucs.ox.ac.uk>
References: <4F46E23A.2030509@ultraslavonic.info>
	<4F4A60A7.1050809@ultraslavonic.info>
	<4201B678-EDB6-46F3-9E4D-2E746FFEBB58@oucs.ox.ac.uk>
Message-ID: <4F4BB030.7000801@kcl.ac.uk>

On 2012-02-26 17:21, Sebastian Rahtz wrote:
>> "Compact to XML format" -->  "Switch to XML format"
>>
>> XML format to compact" -->  "Switch to compact format"
>
> This is easier than it sounds. We'd have to get re-translations of the
> phrase for each language.   I don't mind, but whats the evidence
> that the existing words are confusing? its not been questioned
> in the ?6-7 years we've had the facility.

It's sure as hell confusing to me. I always have to squint at it to 
figure out which way round it should be. I'd be inclined to suggest two 
tabs, one ("compact") obviously "selected", and the other a button 
reading "XML" (and vice versa). But failing that I like Kevin's 
suggestion. (That no one has complained before is no indication that 
it's not a problem. You know how much people prefer to keep quiet, 
especially if doing otherwise might make them look ignorant.)

I would also suggest that we change this in English asap, regardless of 
whether or not the other language versions are changed. The text 
supplied by some of the other i18n groups might not be confusing, after 
all, if the phrasing is quite different.

G

-- 
Dr Gabriel BODARD
(Research Associate in Digital Epigraphy)

Department of Digital Humanities
King's College London
26-29 Drury Lane
London WC2B 5RL

Email: gabriel.bodard at kcl.ac.uk
Tel: +44 (0)20 7848 1388
Fax: +44 (0)20 7848 2980

http://www.digitalclassicist.org/
http://www.currentepigraphy.org/

From bansp at o2.pl  Mon Feb 27 14:36:34 2012
From: bansp at o2.pl (=?ISO-8859-2?Q?Piotr_Ba=F1ski?=)
Date: Mon, 27 Feb 2012 20:36:34 +0100
Subject: [tei-council] telco - probable absence
Message-ID: <4F4BDB42.4040201@o2.pl>

Dear All,

It looks like the yellow in my '(yes)' option in the doodle was leaning
more towards red than I expected, at the time when James was making sure
that the date+hour was OK with me. I'll try to be there tomorrow, but
don't be surprised if I don't turn up.

(Conditional) apologies in advance,

  Piotr

From mholmes at uvic.ca  Mon Feb 27 14:42:00 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Mon, 27 Feb 2012 11:42:00 -0800
Subject: [tei-council] Magic tokens, private URIs, and canonical references
Message-ID: <4F4BDC88.8040506@uvic.ca>

The final topic I'm supposed to cover during the Telco relates to the 
big mess surrounding several attributes:

@cRef
@key
@lemma
@loc
metSym/@value

The current tickets are these:

<http://purl.org/TEI/BUGS/3480650> ("@cRef is a mess")

<http://purl.org/TEI/BUGS/3413346> ("Deprecation of data.key and 
data.word attributes")

The basic issue is this:

Historically, we have encouraged the use of what might be termed "magic 
tokens" in attributes such as @key:

<name key="bloggs_f">Fred Bloggs</name>

where the @key value is used to look up or point to a more detailed 
record for the thing being referred to. The syntax or format of @key has 
not been prescribed:

"@key provides an externally-defined means of identifying the entity (or 
entities) being named, using a coded value of some kind."

and it has been left up to encoders to devise their own schemes for 
dereferencing their @key values (usually turning them into 
fully-qualified URLs, XPaths, database queries etc.), and to document 
them in their own way.

In some cases, such as @cRef, a more formal methodology for 
dereferencing has been prescribed. Here is how @cRef is defined on <term>:

<quote>
@cRef	identifies the associated gloss element using a canonical 
reference from a scheme defined in a refsDecl element in the TEI header
Status:	Optional
Datatype: data.pointer

Values 	the result of applying the algorithm for the resolution of 
canonical references (described in section 16.2.5 Canonical References) 
should be a valid URI reference that resolves to a gloss element
Note	
The refsDecl to use may be indicated with the decls attribute.
</quote>

The element <cRefPattern> is available for documenting the resolution 
algorithm.

Recently we have become rightly uncomfortable with "magic key" values, 
and have been looking for more formal ways for people to specify this 
kind of pointer. The most commonly-advanced approach is to use what's 
called a "private URI scheme", which essentially means an idiosyncratic, 
unregistered prefix, followed by a unique identifier. For instance, in 
our project "Map of London", we use private URIs like this:

<name type="person" ref="mol:HOLM3">Martin Holmes</name>

The advantage of private URI schemes is that they can be used in 
attributes such as @ref and @target, which expect one or more URIs.

However, it's pretty obvious that these are still actually magic tokens. 
There's no way for anyone to know what "mol:HOLM3" points at without 
proper documentation and/or an algorithm for dereferencing it.

It's my belief that we should:

1. Provide a formal mechanism by which private URIs can be documented, 
and where an algorithm for dereferencing them (converting them to some 
sort of universal pointer such as an absolute web URI) can be specified.

2. Once we have done this, rewrite relevant parts of the guidelines to 
encourage the use of attributes such as @ref and @target in place of the 
old "magic token" attributes such as @key.

3. Deprecate some or all of these attributes.

4. Address the mess which is @cRef (see the relevant ticket). It will be 
easier to do this after 1-3 are completed.


During the Telco, I'd like to get a sense of whether people agree with 
me on #1. If they don't -- if everyone is happy that private URIs should 
be used as magic tokens have historically been used, without any formal 
recommendation for documentation -- then the second ticket can be 
closed; the issue of @cRef is still problematic, but we could even 
choose to ignore that if we wish. If there is some agreement with #1, 
then I think we should put together a small working group to create a 
recommendation.

Cheers,
Martin


-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From sebastian.rahtz at oucs.ox.ac.uk  Mon Feb 27 16:06:18 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Mon, 27 Feb 2012 21:06:18 +0000
Subject: [tei-council] P5 releases: changes to boilerplate HTML code
In-Reply-To: <4F4BB030.7000801@kcl.ac.uk>
References: <4F46E23A.2030509@ultraslavonic.info>
	<4F4A60A7.1050809@ultraslavonic.info>
	<4201B678-EDB6-46F3-9E4D-2E746FFEBB58@oucs.ox.ac.uk>
	<4F4BB030.7000801@kcl.ac.uk>
Message-ID: <BC5D5ACD-7C4B-4954-8BC6-AAF3A0A11196@oucs.ox.ac.uk>


On 27 Feb 2012, at 16:32, Gabriel Bodard wrote:


> I'd be inclined to suggest two 
> tabs, one ("compact") obviously "selected", and the other a button 
> reading "XML" (and vice versa).

that would be nice, I agree.  Do any of you have a webby person
who could knock up the appropriate bit of HTML and jQuery which I could drop 
directly[1] in?  it will be a while before I have the time to concentrate on this for an hour
(it probably needs less...)


> (That no one has complained before is no indication that 
> it's not a problem. You know how much people prefer to keep quiet, 
> especially if doing otherwise might make them look ignorant.)

but its also true that we shouldn't make changes just because
two people ask for it.....

[1] strangely, it doesn't solve the problem to be told "package XX does all this,
we use it all the time".....
--
Stormageddon Rahtz      
Head of Information and Support Group, Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431

S?lo le pido a Dios
que el futuro no me sea indiferente


From rwelzenbach at gmail.com  Mon Feb 27 22:51:29 2012
From: rwelzenbach at gmail.com (Rebecca Welzenbach)
Date: Mon, 27 Feb 2012 22:51:29 -0500
Subject: [tei-council] TEI Telco February 2012
In-Reply-To: <4F4779CA.1090700@oucs.ox.ac.uk>
References: <4F466B6A.5060107@oucs.ox.ac.uk> <4F46D4BB.4010604@o2.pl>
	<4F4779CA.1090700@oucs.ox.ac.uk>
Message-ID: <CAA2irtLfXcAGv2h4DSXZznHW7kTei7PM9iq874-P16oMLP4Pyg@mail.gmail.com>

I can do the minutes, unless James has already picked someone else and
feels committed to his choice.

Speak to you tomorrow...

Becky

> Speaking of which, I have yet to have any volunteers to take
> minutes during the conference call. ?I don't want to pick someone
> at random (but will)...how about I say that if you do the minutes
> this time, I won't make you do them next time?

From rwelzenbach at gmail.com  Tue Feb 28 00:06:12 2012
From: rwelzenbach at gmail.com (Rebecca Welzenbach)
Date: Tue, 28 Feb 2012 00:06:12 -0500
Subject: [tei-council] P5 releases: changes to boilerplate HTML code
In-Reply-To: <BC5D5ACD-7C4B-4954-8BC6-AAF3A0A11196@oucs.ox.ac.uk>
References: <4F46E23A.2030509@ultraslavonic.info>
	<4F4A60A7.1050809@ultraslavonic.info>
	<4201B678-EDB6-46F3-9E4D-2E746FFEBB58@oucs.ox.ac.uk>
	<4F4BB030.7000801@kcl.ac.uk>
	<BC5D5ACD-7C4B-4954-8BC6-AAF3A0A11196@oucs.ox.ac.uk>
Message-ID: <CAA2irtJjWjetvObrBzZBpwogReReyagDo-606KoKL3OBUq8Tbg@mail.gmail.com>

I agree with Kevin and Gabby. For me, the problem is that the current
phrasing is missing a clear verb. "Switch", "go," "toggle," or
whatever action will take place when you click the button, is implied
rather than stated explicitly.

This makes it easy to incorrectly read other words in the phrase as
the verbs: "click here to compact" and "click here to format." I think
this is how one arrives at something like Kevin's interpretation
above.

Gabby's button solution seems the least ambiguous, and perhaps also
easiest to export to other languages, since you just need the two
labels, "XML view" and "Compact view." All syntactic messiness is
neatly avoided. But Kevin's suggestion seems perfectly clear to me as
well.

Becky

On Mon, Feb 27, 2012 at 4:06 PM, Sebastian Rahtz
<sebastian.rahtz at oucs.ox.ac.uk> wrote:
>
> On 27 Feb 2012, at 16:32, Gabriel Bodard wrote:
>
>
>> I'd be inclined to suggest two
>> tabs, one ("compact") obviously "selected", and the other a button
>> reading "XML" (and vice versa).
>
> that would be nice, I agree. ?Do any of you have a webby person
> who could knock up the appropriate bit of HTML and jQuery which I could drop
> directly[1] in? ?it will be a while before I have the time to concentrate on this for an hour
> (it probably needs less...)
>
>
>> (That no one has complained before is no indication that
>> it's not a problem. You know how much people prefer to keep quiet,
>> especially if doing otherwise might make them look ignorant.)
>
> but its also true that we shouldn't make changes just because
> two people ask for it.....
>
> [1] strangely, it doesn't solve the problem to be told "package XX does all this,
> we use it all the time".....
> --
> Stormageddon Rahtz
> Head of Information and Support Group, Oxford University Computing Services
> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>
> S?lo le pido a Dios
> que el futuro no me sea indiferente
>
> --
> tei-council mailing list
> tei-council at lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>
> PLEASE NOTE: postings to this list are publicly archived

From James.Cummings at oucs.ox.ac.uk  Tue Feb 28 06:31:27 2012
From: James.Cummings at oucs.ox.ac.uk (James Cummings)
Date: Tue, 28 Feb 2012 11:31:27 +0000
Subject: [tei-council] TEI Telco February 2012
In-Reply-To: <CAA2irtLfXcAGv2h4DSXZznHW7kTei7PM9iq874-P16oMLP4Pyg@mail.gmail.com>
References: <4F466B6A.5060107@oucs.ox.ac.uk>	<4F46D4BB.4010604@o2.pl>	<4F4779CA.1090700@oucs.ox.ac.uk>
	<CAA2irtLfXcAGv2h4DSXZznHW7kTei7PM9iq874-P16oMLP4Pyg@mail.gmail.com>
Message-ID: <4F4CBB0F.6030206@oucs.ox.ac.uk>


Hi Becky,

In this case Lou has volunteered to take the minutes (thank you 
Lou!), but I'll put your name as a reserve on the list (with 
Martin) ... we will always need minute takers at the Ann Arbor 
meeting as well. :-) I'll try to make sure the burden gets spread 
around.

-James

On 28/02/12 03:51, Rebecca Welzenbach wrote:
> I can do the minutes, unless James has already picked someone else and
> feels committed to his choice.
>
> Speak to you tomorrow...


-- 
Dr James Cummings, InfoDev,
Computing Services, University of Oxford

From gabriel.bodard at kcl.ac.uk  Tue Feb 28 12:38:47 2012
From: gabriel.bodard at kcl.ac.uk (Gabriel Bodard)
Date: Tue, 28 Feb 2012 17:38:47 +0000
Subject: [tei-council] TEI Telco February 2012
In-Reply-To: <4F477A1E.6010006@oucs.ox.ac.uk>
References: <4F466B6A.5060107@oucs.ox.ac.uk> <4F46D4BB.4010604@o2.pl>
	<4F4779CA.1090700@oucs.ox.ac.uk> <4F477A1E.6010006@oucs.ox.ac.uk>
Message-ID: <4F4D1127.5000101@kcl.ac.uk>

Even though we're not using Skype for the conference call, would it be 
worthwhile having a skype window open with all of us chatting, so we can 
do things like pass around URLs and other text quickly and easily during 
the call?

I'll try to set up a chat, but there may be a few people whose contacts 
I don't have yet. If you're one of those, could you try to share your 
details with me (I'm "gabrielbodard", predictably enough...)?

G

On 2012-02-24 11:53, James Cummings wrote:
> On 24/02/12 11:51, James Cummings wrote:
>> If skype conversations are all held by people are a computer they
>> are free. However, in the past it has often been found that the
>
> s/are a computer/who are on a computer/
>
> *sigh*
>
> -James
>

-- 
Dr Gabriel BODARD
(Research Associate in Digital Epigraphy)

Department of Digital Humanities
King's College London
26-29 Drury Lane
London WC2B 5RL

Email: gabriel.bodard at kcl.ac.uk
Tel: +44 (0)20 7848 1388
Fax: +44 (0)20 7848 2980

http://www.digitalclassicist.org/
http://www.currentepigraphy.org/

From James.Cummings at oucs.ox.ac.uk  Tue Feb 28 12:44:31 2012
From: James.Cummings at oucs.ox.ac.uk (James Cummings)
Date: Tue, 28 Feb 2012 17:44:31 +0000
Subject: [tei-council] TEI Telco February 2012
In-Reply-To: <4F4D1127.5000101@kcl.ac.uk>
References: <4F466B6A.5060107@oucs.ox.ac.uk>
	<4F46D4BB.4010604@o2.pl>	<4F4779CA.1090700@oucs.ox.ac.uk>
	<4F477A1E.6010006@oucs.ox.ac.uk> <4F4D1127.5000101@kcl.ac.uk>
Message-ID: <4F4D127F.6080600@oucs.ox.ac.uk>


Sounds like a good idea to me.  (Other alternative being IRC, but 
of course more people have skype already set up, so let's use that!)

-James


On 28/02/12 17:38, Gabriel Bodard wrote:
> Even though we're not using Skype for the conference call, would it be
> worthwhile having a skype window open with all of us chatting, so we can
> do things like pass around URLs and other text quickly and easily during
> the call?
>
> I'll try to set up a chat, but there may be a few people whose contacts
> I don't have yet. If you're one of those, could you try to share your
> details with me (I'm "gabrielbodard", predictably enough...)?
>
> G
>
> On 2012-02-24 11:53, James Cummings wrote:
>> On 24/02/12 11:51, James Cummings wrote:
>>> If skype conversations are all held by people are a computer they
>>> are free. However, in the past it has often been found that the
>>
>> s/are a computer/who are on a computer/
>>
>> *sigh*
>>
>> -James
>>
>


-- 
Dr James Cummings, InfoDev,
Computing Services, University of Oxford

From gabriel.bodard at kcl.ac.uk  Tue Feb 28 12:49:07 2012
From: gabriel.bodard at kcl.ac.uk (Gabriel Bodard)
Date: Tue, 28 Feb 2012 17:49:07 +0000
Subject: [tei-council] TEI Telco February 2012
In-Reply-To: <4F4D127F.6080600@oucs.ox.ac.uk>
References: <4F466B6A.5060107@oucs.ox.ac.uk>	<4F46D4BB.4010604@o2.pl>
	<4F4779CA.1090700@oucs.ox.ac.uk>	<4F477A1E.6010006@oucs.ox.ac.uk>
	<4F4D1127.5000101@kcl.ac.uk> <4F4D127F.6080600@oucs.ox.ac.uk>
Message-ID: <4F4D1393.7060006@kcl.ac.uk>

IRC's not a bad idea, especially as there is a web interface to that. 
(http://webchat.freenode.net/) But if everyone has Skype, then we're 
probably okay.

On 2012-02-28 17:44, James Cummings wrote:
>
> Sounds like a good idea to me.  (Other alternative being IRC, but
> of course more people have skype already set up, so let's use that!)
>
> -James
>
>
> On 28/02/12 17:38, Gabriel Bodard wrote:
>> Even though we're not using Skype for the conference call, would it be
>> worthwhile having a skype window open with all of us chatting, so we can
>> do things like pass around URLs and other text quickly and easily during
>> the call?
>>
>> I'll try to set up a chat, but there may be a few people whose contacts
>> I don't have yet. If you're one of those, could you try to share your
>> details with me (I'm "gabrielbodard", predictably enough...)?
>>
>> G
>>
>> On 2012-02-24 11:53, James Cummings wrote:
>>> On 24/02/12 11:51, James Cummings wrote:
>>>> If skype conversations are all held by people are a computer they
>>>> are free. However, in the past it has often been found that the
>>>
>>> s/are a computer/who are on a computer/
>>>
>>> *sigh*
>>>
>>> -James
>>>
>>
>
>

-- 
Dr Gabriel BODARD
(Research Associate in Digital Epigraphy)

Department of Digital Humanities
King's College London
26-29 Drury Lane
London WC2B 5RL

Email: gabriel.bodard at kcl.ac.uk
Tel: +44 (0)20 7848 1388
Fax: +44 (0)20 7848 2980

http://www.digitalclassicist.org/
http://www.currentepigraphy.org/

From rwelzenbach at gmail.com  Tue Feb 28 12:51:29 2012
From: rwelzenbach at gmail.com (Rebecca Welzenbach)
Date: Tue, 28 Feb 2012 12:51:29 -0500
Subject: [tei-council] TEI Telco February 2012
In-Reply-To: <4F4D1393.7060006@kcl.ac.uk>
References: <4F466B6A.5060107@oucs.ox.ac.uk> <4F46D4BB.4010604@o2.pl>
	<4F4779CA.1090700@oucs.ox.ac.uk> <4F477A1E.6010006@oucs.ox.ac.uk>
	<4F4D1127.5000101@kcl.ac.uk> <4F4D127F.6080600@oucs.ox.ac.uk>
	<4F4D1393.7060006@kcl.ac.uk>
Message-ID: <CAA2irtJtcA1h=Haaju1u4LXQtnfQDri6CfO1HMz=6TEw5N-tFA@mail.gmail.com>

I will be on Skype: rwelzenb


On Tue, Feb 28, 2012 at 12:49 PM, Gabriel Bodard
<gabriel.bodard at kcl.ac.uk> wrote:
> IRC's not a bad idea, especially as there is a web interface to that.
> (http://webchat.freenode.net/) But if everyone has Skype, then we're
> probably okay.
>
> On 2012-02-28 17:44, James Cummings wrote:
>>
>> Sounds like a good idea to me. ?(Other alternative being IRC, but
>> of course more people have skype already set up, so let's use that!)
>>
>> -James
>>
>>
>> On 28/02/12 17:38, Gabriel Bodard wrote:
>>> Even though we're not using Skype for the conference call, would it be
>>> worthwhile having a skype window open with all of us chatting, so we can
>>> do things like pass around URLs and other text quickly and easily during
>>> the call?
>>>
>>> I'll try to set up a chat, but there may be a few people whose contacts
>>> I don't have yet. If you're one of those, could you try to share your
>>> details with me (I'm "gabrielbodard", predictably enough...)?
>>>
>>> G
>>>
>>> On 2012-02-24 11:53, James Cummings wrote:
>>>> On 24/02/12 11:51, James Cummings wrote:
>>>>> If skype conversations are all held by people are a computer they
>>>>> are free. However, in the past it has often been found that the
>>>>
>>>> s/are a computer/who are on a computer/
>>>>
>>>> *sigh*
>>>>
>>>> -James
>>>>
>>>
>>
>>
>
> --
> Dr Gabriel BODARD
> (Research Associate in Digital Epigraphy)
>
> Department of Digital Humanities
> King's College London
> 26-29 Drury Lane
> London WC2B 5RL
>
> Email: gabriel.bodard at kcl.ac.uk
> Tel: +44 (0)20 7848 1388
> Fax: +44 (0)20 7848 2980
>
> http://www.digitalclassicist.org/
> http://www.currentepigraphy.org/
> --
> tei-council mailing list
> tei-council at lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>
> PLEASE NOTE: postings to this list are publicly archived

From gabriel.bodard at kcl.ac.uk  Tue Feb 28 14:00:34 2012
From: gabriel.bodard at kcl.ac.uk (Gabriel Bodard)
Date: Tue, 28 Feb 2012 19:00:34 +0000
Subject: [tei-council] XPointer working group
Message-ID: <4F4D2452.4020902@kcl.ac.uk>

The XPointer ad hoc working group (myself, Martin, Piotr, Laurent, Syd 
Baumann and Hugh Cayless) is using the old "Stand-off markup" mailing 
list (archives at 
<http://listserv.brown.edu/archives/cgi-bin/wa?A0=TEI-SOM>) to discuss 
possible approaches to making TEI XPointer schemes more useful. Possible 
recommendations at the end of the day might include:

  * completely abandon XPointer and recommend (or develop) some other 
scheme;
  * drop most of the obscurer functions and keep only xpath() and/or 
xpath2()
  * leave everything alone, but possibly do something about improving 
the implementation

I have asked the workgroup to come up with a self-imposed deadline to 
report back to Council.

G

-- 
Dr Gabriel BODARD
(Research Associate in Digital Epigraphy)

Department of Digital Humanities
King's College London
26-29 Drury Lane
London WC2B 5RL

Email: gabriel.bodard at kcl.ac.uk
Tel: +44 (0)20 7848 1388
Fax: +44 (0)20 7848 2980

http://www.digitalclassicist.org/
http://www.currentepigraphy.org/

From syeates at gmail.com  Tue Feb 28 14:11:29 2012
From: syeates at gmail.com (Stuart A. Yeates)
Date: Wed, 29 Feb 2012 08:11:29 +1300
Subject: [tei-council] some brief reports to save time during our
 upcoming conf call
In-Reply-To: <4F4978F8.205@ultraslavonic.info>
References: <4F4978F8.205@ultraslavonic.info>
Message-ID: <CAC_Lu0a4ddMsKdqTfofgJA9XmLvFpJ_FC8LQAy9X0rBBiDTAQw@mail.gmail.com>

On Sun, Feb 26, 2012 at 1:12 PM, Kevin Hawkins
<kevin.s.hawkins at ultraslavonic.info> wrote:
> = Google Books =
> The importance of this for the TEI's PR can't really be understated.
> We, or the Board, might want to give some thought about whether to do
> anything more once Google deloys this code than simply announce it on
> TEI-L with shouts of hurrah/hooray/huzzah.

I think it might be productive to have a few paragraphs contrasting
TEI texts and underlying openness to the closed and propriety nature
of formats currently in use by Amazon and OverDrive.

I'm happy to write these, maybe with Kevin giving me some feedback?

cheers
stuart

From kevin.s.hawkins at ultraslavonic.info  Tue Feb 28 22:31:55 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Tue, 28 Feb 2012 22:31:55 -0500
Subject: [tei-council] Standardi[s|z]ation
In-Reply-To: <4F4BAFD0.7060703@uvic.ca>
References: <4F4925E9.8020105@uvic.ca>	<4F492BAC.2080904@retired.ox.ac.uk>	<4F4A42E4.9050203@retired.ox.ac.uk>	<4F4A46B3.9010508@ultraslavonic.info>	<4F4A6C52.6060906@uvic.ca>
	<4F4ABB68.6060909@retired.ox.ac.uk> <4F4BAFD0.7060703@uvic.ca>
Message-ID: <4F4D9C2B.1060904@ultraslavonic.info>

Lou, I don't think Martin was suggesting that we duplicate the 
information in three places.  Instead, he suggested replacing 
P5/Source/Guidelines/en/style-guide.txt and the relevant section of 
tcw20 with a link to the new document, which would be a TEI document 
named tcw23 or the next available "tcw" number at the time of creation. 
  I agree with this strategy.

Perhaps one of our newer members would like to take on the task of 
composing tcw23?  Martin or I can handle updating tcw20 and 
style-guide.txt once the new document is in place.

On 2/27/12 11:31 AM, Martin Holmes wrote:
> The question really is whether it's best to maintain this information in
> a text file in the Guidelines source code, or as a more public document
> on the TEI website. In the latter case, it would be in P5 and benefit
> from transformation into richer XHTML, with links etc. working.
>
> I like the P5 option. It's currently part of TCW20 because it doesn't
> consist of much, but it's going to get bigger as we go along, so I think
> it deserves a document to itself.
>
> Cheers,
> Martin
>
> On 12-02-26 03:08 PM, Lou Burnard wrote:
>> Well, P5/Source/Guidelines/en/style-guide.txt is really only the
>> beginnings of a style guide. I copied the whole of it into tcw20.xml
>> because it seemed convenient to have everything in one place. By all
>> means let's work on elaborating it (and perhaps, when it gets bigger,
>> replacing it by a link in tcw20), but there's no need to maintain this
>> information in  THREE places surely?
>>
>>
>>
>> the On 26/02/12 17:30, Martin Holmes wrote:
>>> I think we should spin off the styleguide into a separate Working Paper
>>> (since it's definitely a work in progress), and point to it from both
>>> locations. There's a lot of work to do here, assuming that we're going
>>> to maintain our own styleguide rather than adopt an existing one. It
>>> deserves its own document.
>>>
>>> Cheers,
>>> Martin
>>>
>>> On 12-02-26 06:50 AM, Kevin Hawkins wrote:
>>>> This seems like good policy to add to
>>>> http://www.tei-c.org/Activities/Council/Working/tcw20.xml#house-style-orthography
>>>> and I think also to P5/Source/Guidelines/en/style-guide.txt .
>>>>
>>>> It continues to bother me that we repeat information in these two
>>>> documents, which could easily fall out of sync.  I would suggest having
>>>> one point to the other, but I'm not sure which should be primary.  Thoughts?
>>>>
>>>> On 2/26/12 9:34 AM, Lou Burnard wrote:
>>>>> Further to my rather cryptic comment below: my recommendation is
>>>>>
>>>>> a) look up the word in the OED
>>>>> b) if it says that both -IZE and -ISE forms are usable, use the -IZE form.
>>>>> c) otherwise use the -ISE form.
>>>>>
>>>>>
>>>>> n 25/02/12 18:42, Lou Burnard wrote:
>>>>>> Michael Quinnion is good on this, (as on many other things)
>>>>>>
>>>>>>         http://www.worldwidewords.org/qa/qa-ise1.htm
>>>>>>
>>>>>> The -IZE suffix only applize to words which (etymologically speaking)
>>>>>> come to use from a Latinized version of a Greek suffix. That's the
>>>>>> rationale given by the OED anyway.
>>>>>>
>>>>>> I don't think we should be guided by "instinct" here. Look em up.
>>>>>>
>>>>>>
>>>>>> On 25/02/12 18:18, Martin Holmes wrote:
>>>>>>> Hi all,
>>>>>>>
>>>>>>> One of Jens's excellent proofing reports suggests that we standardize
>>>>>>> spellings ending in -ise/-ize. I'm inclined to agree, and with -ise
>>>>>>> looking a bit beleaguered these days, I think it should be -ize. Lou
>>>>>>> agrees, on the ticket.
>>>>>>>
>>>>>>> So I ran this regex to see what we have:
>>>>>>>
>>>>>>> is((e[d|s]*)|(ing))\b
>>>>>>>
>>>>>>> It found 1529 instances, most of which aren't relevant ("otherwise",
>>>>>>> "raise" etc.). But amongst those which are, they don't all seem clear
>>>>>>> cut to me, though. I think these are uncontroversial:
>>>>>>>
>>>>>>> standardise
>>>>>>> normalise
>>>>>>> capitalise
>>>>>>> specialise
>>>>>>> summarise
>>>>>>> computerise
>>>>>>> italicise
>>>>>>> recognise
>>>>>>> regularise
>>>>>>> categorise
>>>>>>>
>>>>>>> But what about these? I feel instinctively less happy with changing
>>>>>>> these to z, for some reason:
>>>>>>>
>>>>>>> harmonise
>>>>>>> compromise
>>>>>>> analyse
>>>>>>> exercise
>>>>>>> utilise
>>>>>>>
>>>>>>> and I think these cannot be changed to z, even though, in many cases,
>>>>>>> variants with z are attested:
>>>>>>>
>>>>>>> comprise
>>>>>>> revise
>>>>>>> devise
>>>>>>> advise
>>>>>>> excise
>>>>>>>
>>>>>>> So what do your instincts tell you about these? Should we basically make
>>>>>>> a list of words which should use z, and put it in our style guide?
>>>>>>>
>>>>>>> Making the changes will be a significant job, because there are
>>>>>>> instances of similar words in French that mustn't be changed ("utilise",
>>>>>>> for instance). I think it'll best be done with XSLT (which can be
>>>>>>> language-aware, and ignore the French) and some very precise regexes.
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Martin
>>>>>>
>>>>>
>>>
>>
>

From rwelzenbach at gmail.com  Thu Mar  1 14:50:19 2012
From: rwelzenbach at gmail.com (Rebecca Welzenbach)
Date: Thu, 1 Mar 2012 14:50:19 -0500
Subject: [tei-council] Standardi[s|z]ation
In-Reply-To: <4F4D9C2B.1060904@ultraslavonic.info>
References: <4F4925E9.8020105@uvic.ca> <4F492BAC.2080904@retired.ox.ac.uk>
	<4F4A42E4.9050203@retired.ox.ac.uk>
	<4F4A46B3.9010508@ultraslavonic.info> <4F4A6C52.6060906@uvic.ca>
	<4F4ABB68.6060909@retired.ox.ac.uk> <4F4BAFD0.7060703@uvic.ca>
	<4F4D9C2B.1060904@ultraslavonic.info>
Message-ID: <CAA2irt+2RsPLXnAf2K=atjtAnwnFXt6f-h5tV22UwNuR2AHEgA@mail.gmail.com>

I would be happy to do this.

On Tue, Feb 28, 2012 at 10:31 PM, Kevin Hawkins
<kevin.s.hawkins at ultraslavonic.info> wrote:
> Lou, I don't think Martin was suggesting that we duplicate the
> information in three places. ?Instead, he suggested replacing
> P5/Source/Guidelines/en/style-guide.txt and the relevant section of
> tcw20 with a link to the new document, which would be a TEI document
> named tcw23 or the next available "tcw" number at the time of creation.
> ?I agree with this strategy.
>
> Perhaps one of our newer members would like to take on the task of
> composing tcw23? ?Martin or I can handle updating tcw20 and
> style-guide.txt once the new document is in place.
>
> On 2/27/12 11:31 AM, Martin Holmes wrote:
>> The question really is whether it's best to maintain this information in
>> a text file in the Guidelines source code, or as a more public document
>> on the TEI website. In the latter case, it would be in P5 and benefit
>> from transformation into richer XHTML, with links etc. working.
>>
>> I like the P5 option. It's currently part of TCW20 because it doesn't
>> consist of much, but it's going to get bigger as we go along, so I think
>> it deserves a document to itself.
>>
>> Cheers,
>> Martin
>>
>> On 12-02-26 03:08 PM, Lou Burnard wrote:
>>> Well, P5/Source/Guidelines/en/style-guide.txt is really only the
>>> beginnings of a style guide. I copied the whole of it into tcw20.xml
>>> because it seemed convenient to have everything in one place. By all
>>> means let's work on elaborating it (and perhaps, when it gets bigger,
>>> replacing it by a link in tcw20), but there's no need to maintain this
>>> information in ?THREE places surely?
>>>
>>>
>>>
>>> the On 26/02/12 17:30, Martin Holmes wrote:
>>>> I think we should spin off the styleguide into a separate Working Paper
>>>> (since it's definitely a work in progress), and point to it from both
>>>> locations. There's a lot of work to do here, assuming that we're going
>>>> to maintain our own styleguide rather than adopt an existing one. It
>>>> deserves its own document.
>>>>
>>>> Cheers,
>>>> Martin
>>>>
>>>> On 12-02-26 06:50 AM, Kevin Hawkins wrote:
>>>>> This seems like good policy to add to
>>>>> http://www.tei-c.org/Activities/Council/Working/tcw20.xml#house-style-orthography
>>>>> and I think also to P5/Source/Guidelines/en/style-guide.txt .
>>>>>
>>>>> It continues to bother me that we repeat information in these two
>>>>> documents, which could easily fall out of sync. ?I would suggest having
>>>>> one point to the other, but I'm not sure which should be primary. ?Thoughts?
>>>>>
>>>>> On 2/26/12 9:34 AM, Lou Burnard wrote:
>>>>>> Further to my rather cryptic comment below: my recommendation is
>>>>>>
>>>>>> a) look up the word in the OED
>>>>>> b) if it says that both -IZE and -ISE forms are usable, use the -IZE form.
>>>>>> c) otherwise use the -ISE form.
>>>>>>
>>>>>>
>>>>>> n 25/02/12 18:42, Lou Burnard wrote:
>>>>>>> Michael Quinnion is good on this, (as on many other things)
>>>>>>>
>>>>>>> ? ? ? ? http://www.worldwidewords.org/qa/qa-ise1.htm
>>>>>>>
>>>>>>> The -IZE suffix only applize to words which (etymologically speaking)
>>>>>>> come to use from a Latinized version of a Greek suffix. That's the
>>>>>>> rationale given by the OED anyway.
>>>>>>>
>>>>>>> I don't think we should be guided by "instinct" here. Look em up.
>>>>>>>
>>>>>>>
>>>>>>> On 25/02/12 18:18, Martin Holmes wrote:
>>>>>>>> Hi all,
>>>>>>>>
>>>>>>>> One of Jens's excellent proofing reports suggests that we standardize
>>>>>>>> spellings ending in -ise/-ize. I'm inclined to agree, and with -ise
>>>>>>>> looking a bit beleaguered these days, I think it should be -ize. Lou
>>>>>>>> agrees, on the ticket.
>>>>>>>>
>>>>>>>> So I ran this regex to see what we have:
>>>>>>>>
>>>>>>>> is((e[d|s]*)|(ing))\b
>>>>>>>>
>>>>>>>> It found 1529 instances, most of which aren't relevant ("otherwise",
>>>>>>>> "raise" etc.). But amongst those which are, they don't all seem clear
>>>>>>>> cut to me, though. I think these are uncontroversial:
>>>>>>>>
>>>>>>>> standardise
>>>>>>>> normalise
>>>>>>>> capitalise
>>>>>>>> specialise
>>>>>>>> summarise
>>>>>>>> computerise
>>>>>>>> italicise
>>>>>>>> recognise
>>>>>>>> regularise
>>>>>>>> categorise
>>>>>>>>
>>>>>>>> But what about these? I feel instinctively less happy with changing
>>>>>>>> these to z, for some reason:
>>>>>>>>
>>>>>>>> harmonise
>>>>>>>> compromise
>>>>>>>> analyse
>>>>>>>> exercise
>>>>>>>> utilise
>>>>>>>>
>>>>>>>> and I think these cannot be changed to z, even though, in many cases,
>>>>>>>> variants with z are attested:
>>>>>>>>
>>>>>>>> comprise
>>>>>>>> revise
>>>>>>>> devise
>>>>>>>> advise
>>>>>>>> excise
>>>>>>>>
>>>>>>>> So what do your instincts tell you about these? Should we basically make
>>>>>>>> a list of words which should use z, and put it in our style guide?
>>>>>>>>
>>>>>>>> Making the changes will be a significant job, because there are
>>>>>>>> instances of similar words in French that mustn't be changed ("utilise",
>>>>>>>> for instance). I think it'll best be done with XSLT (which can be
>>>>>>>> language-aware, and ignore the French) and some very precise regexes.
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>> Martin
>>>>>>>
>>>>>>
>>>>
>>>
>>
> --
> tei-council mailing list
> tei-council at lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>
> PLEASE NOTE: postings to this list are publicly archived

From kevin.s.hawkins at ultraslavonic.info  Sun Mar  4 22:45:24 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Sun, 04 Mar 2012 22:45:24 -0500
Subject: [tei-council] PR for TEI in Google Books (was Re: some brief
 reports to save time during our upcoming conf call)
In-Reply-To: <CAC_Lu0a4ddMsKdqTfofgJA9XmLvFpJ_FC8LQAy9X0rBBiDTAQw@mail.gmail.com>
References: <4F4978F8.205@ultraslavonic.info>
	<CAC_Lu0a4ddMsKdqTfofgJA9XmLvFpJ_FC8LQAy9X0rBBiDTAQw@mail.gmail.com>
Message-ID: <4F5436D4.8040605@ultraslavonic.info>

On 2/28/12 2:11 PM, Stuart A. Yeates wrote:
> On Sun, Feb 26, 2012 at 1:12 PM, Kevin Hawkins
> <kevin.s.hawkins at ultraslavonic.info>  wrote:
>> = Google Books =
>> The importance of this for the TEI's PR can't really be understated.
>> We, or the Board, might want to give some thought about whether to do
>> anything more once Google deloys this code than simply announce it on
>> TEI-L with shouts of hurrah/hooray/huzzah.
>
> I think it might be productive to have a few paragraphs contrasting
> TEI texts and underlying openness to the closed and propriety nature
> of formats currently in use by Amazon and OverDrive.
>
> I'm happy to write these, maybe with Kevin giving me some feedback?
>
> cheers
> stuart

I believe the teleconference discussion did not reach a conclusion on 
whether, once Google deploys their code, the TEI-C should (a) ride a way 
of publicity that might be generated in the community, (b) seek to 
create a wave, or (c) do nothing.  In any case, I plan to act as a 
private citizen (not in my role as a Council member) in publicizing this 
since I personally believe it's significant, even if Google turns out 
TEI files that many of us think aren't all that usable.

But in the case of (a) or (b), it would be good to have a text drafted 
by Stuart and me, with input from the rest of you, ready for when the 
appointed hour arrives.  However, I don't know who should make an 
official statement on behalf of the TEI-C.  Perhaps we don't need an 
official statement: instead, someone posts their own private 
announcement to TEI-L and then it gets added to the news feed on 
www.tei-c.org.  Pretty soon it gets tweeted and then picked up by 
Digital Humanities Now, ProfHacker, the Times (London and New York), 
CNN, Fox News, Sky News, and of course the Sunday Sun, in which Mr. 
Murdoch is no doubt anxious to promote an open, non-proprietary format 
for interchange of digital text!

--Kevin

From gabriel.bodard at kcl.ac.uk  Mon Mar  5 05:43:59 2012
From: gabriel.bodard at kcl.ac.uk (Gabriel Bodard)
Date: Mon, 5 Mar 2012 10:43:59 +0000
Subject: [tei-council] PR for TEI in Google Books (was Re: some brief
 reports to save time during our upcoming conf call)
In-Reply-To: <4F5436D4.8040605@ultraslavonic.info>
References: <4F4978F8.205@ultraslavonic.info>
	<CAC_Lu0a4ddMsKdqTfofgJA9XmLvFpJ_FC8LQAy9X0rBBiDTAQw@mail.gmail.com>
	<4F5436D4.8040605@ultraslavonic.info>
Message-ID: <4F5498EF.90001@kcl.ac.uk>

For what it's worth, although Council may not have reached a conclusion, 
I am very much in favour of preparing to publicize this event.

Even in the worst-case scenario where the TEI produced by Google is 
really really bad (or contains bad OCR), the fact that TEI is a format 
chosen to encode many many thousands of public domain texts is something 
that we can and should make a loud noise about. (And even if it's so 
bad, (a) that isn't our fault, and (b) hopefully someone will work to 
improve it.)

In short: +1

G

On 2012-03-05 03:45, Kevin Hawkins wrote:
> On 2/28/12 2:11 PM, Stuart A. Yeates wrote:
>> On Sun, Feb 26, 2012 at 1:12 PM, Kevin Hawkins
>> <kevin.s.hawkins at ultraslavonic.info>   wrote:
>>> = Google Books =
>>> The importance of this for the TEI's PR can't really be understated.
>>> We, or the Board, might want to give some thought about whether to do
>>> anything more once Google deloys this code than simply announce it on
>>> TEI-L with shouts of hurrah/hooray/huzzah.
>>
>> I think it might be productive to have a few paragraphs contrasting
>> TEI texts and underlying openness to the closed and propriety nature
>> of formats currently in use by Amazon and OverDrive.
>>
>> I'm happy to write these, maybe with Kevin giving me some feedback?
>>
>> cheers
>> stuart
>
> I believe the teleconference discussion did not reach a conclusion on
> whether, once Google deploys their code, the TEI-C should (a) ride a way
> of publicity that might be generated in the community, (b) seek to
> create a wave, or (c) do nothing.  In any case, I plan to act as a
> private citizen (not in my role as a Council member) in publicizing this
> since I personally believe it's significant, even if Google turns out
> TEI files that many of us think aren't all that usable.
>
> But in the case of (a) or (b), it would be good to have a text drafted
> by Stuart and me, with input from the rest of you, ready for when the
> appointed hour arrives.  However, I don't know who should make an
> official statement on behalf of the TEI-C.  Perhaps we don't need an
> official statement: instead, someone posts their own private
> announcement to TEI-L and then it gets added to the news feed on
> www.tei-c.org.  Pretty soon it gets tweeted and then picked up by
> Digital Humanities Now, ProfHacker, the Times (London and New York),
> CNN, Fox News, Sky News, and of course the Sunday Sun, in which Mr.
> Murdoch is no doubt anxious to promote an open, non-proprietary format
> for interchange of digital text!
>
> --Kevin

-- 
Dr Gabriel BODARD
(Research Associate in Digital Epigraphy)

Department of Digital Humanities
King's College London
26-29 Drury Lane
London WC2B 5RL

Email: gabriel.bodard at kcl.ac.uk
Tel: +44 (0)20 7848 1388
Fax: +44 (0)20 7848 2980

http://www.digitalclassicist.org/
http://www.currentepigraphy.org/

From sebastian.rahtz at oucs.ox.ac.uk  Mon Mar  5 05:50:31 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Mon, 5 Mar 2012 10:50:31 +0000
Subject: [tei-council] PR for TEI in Google Books (was Re: some brief
 reports to save time during our upcoming conf call)
In-Reply-To: <4F5498EF.90001@kcl.ac.uk>
References: <4F4978F8.205@ultraslavonic.info>
	<CAC_Lu0a4ddMsKdqTfofgJA9XmLvFpJ_FC8LQAy9X0rBBiDTAQw@mail.gmail.com>
	<4F5436D4.8040605@ultraslavonic.info> <4F5498EF.90001@kcl.ac.uk>
Message-ID: <10B41F85-FE85-4EC0-9301-A732FF929434@oucs.ox.ac.uk>


On 5 Mar 2012, at 10:43, Gabriel Bodard wrote:

> really really bad (or contains bad OCR), the fact that TEI is a format 
> chosen to encode many many thousands of public domain texts 

it would really be a big deal if Google released these texts
as public domain?. but I don't think thats what you mean :-}

--
Stormageddon Rahtz      
Head of Information and Support Group
Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431

S?lo le pido a Dios
que el futuro no me sea indiferente


From gabriel.bodard at kcl.ac.uk  Mon Mar  5 05:54:12 2012
From: gabriel.bodard at kcl.ac.uk (Gabriel Bodard)
Date: Mon, 5 Mar 2012 10:54:12 +0000
Subject: [tei-council] PR for TEI in Google Books (was Re: some brief
 reports to save time during our upcoming conf call)
In-Reply-To: <10B41F85-FE85-4EC0-9301-A732FF929434@oucs.ox.ac.uk>
References: <4F4978F8.205@ultraslavonic.info>
	<CAC_Lu0a4ddMsKdqTfofgJA9XmLvFpJ_FC8LQAy9X0rBBiDTAQw@mail.gmail.com>
	<4F5436D4.8040605@ultraslavonic.info> <4F5498EF.90001@kcl.ac.uk>
	<10B41F85-FE85-4EC0-9301-A732FF929434@oucs.ox.ac.uk>
Message-ID: <4F549B54.2040108@kcl.ac.uk>

Well, the texts themselves are public domain. Do we know what license 
Google normally attach to otherwise PD texts that they release? (E.g. 
page scans.) I wonder what would be the point of releasing TEI versions 
of texts without licensing them for some kind of re-use...?

Kevin, any insight on this? Any value in pushing in this direction?

G

On 2012-03-05 10:50, Sebastian Rahtz wrote:
>
> On 5 Mar 2012, at 10:43, Gabriel Bodard wrote:
>
>> really really bad (or contains bad OCR), the fact that TEI is a format
>> chosen to encode many many thousands of public domain texts
>
> it would really be a big deal if Google released these texts
> as public domain?. but I don't think thats what you mean :-}
>
> --
> Stormageddon Rahtz
> Head of Information and Support Group
> Oxford University Computing Services
> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>
> S?lo le pido a Dios
> que el futuro no me sea indiferente
>

-- 
Dr Gabriel BODARD
(Research Associate in Digital Epigraphy)

Department of Digital Humanities
King's College London
26-29 Drury Lane
London WC2B 5RL

Email: gabriel.bodard at kcl.ac.uk
Tel: +44 (0)20 7848 1388
Fax: +44 (0)20 7848 2980

http://www.digitalclassicist.org/
http://www.currentepigraphy.org/

From lou.burnard at retired.ox.ac.uk  Mon Mar  5 05:57:46 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Mon, 05 Mar 2012 10:57:46 +0000
Subject: [tei-council] PR for TEI in Google Books (was Re: some brief
 reports to save time during our upcoming conf call)
In-Reply-To: <4F549B54.2040108@kcl.ac.uk>
References: <4F4978F8.205@ultraslavonic.info>	<CAC_Lu0a4ddMsKdqTfofgJA9XmLvFpJ_FC8LQAy9X0rBBiDTAQw@mail.gmail.com>	<4F5436D4.8040605@ultraslavonic.info>
	<4F5498EF.90001@kcl.ac.uk>	<10B41F85-FE85-4EC0-9301-A732FF929434@oucs.ox.ac.uk>
	<4F549B54.2040108@kcl.ac.uk>
Message-ID: <4F549C2A.1010406@retired.ox.ac.uk>

I think Kevin did give us this impression during the teleconf. Certainly 
that's what the minutes (which I sent to James last night) say!

I suspect my esteemed colleague  Rahtz is trolling on the use of the 
phrase "public domain"

On 05/03/12 10:54, Gabriel Bodard wrote:
> Well, the texts themselves are public domain. Do we know what license
> Google normally attach to otherwise PD texts that they release? (E.g.
> page scans.) I wonder what would be the point of releasing TEI versions
> of texts without licensing them for some kind of re-use...?
>
> Kevin, any insight on this? Any value in pushing in this direction?
>
> G
>
> On 2012-03-05 10:50, Sebastian Rahtz wrote:
>>
>> On 5 Mar 2012, at 10:43, Gabriel Bodard wrote:
>>
>>> really really bad (or contains bad OCR), the fact that TEI is a format
>>> chosen to encode many many thousands of public domain texts
>>
>> it would really be a big deal if Google released these texts
>> as public domain?. but I don't think thats what you mean :-}
>>
>> --
>> Stormageddon Rahtz
>> Head of Information and Support Group
>> Oxford University Computing Services
>> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>>
>> S?lo le pido a Dios
>> que el futuro no me sea indiferente
>>
>


From sebastian.rahtz at oucs.ox.ac.uk  Mon Mar  5 06:02:18 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Mon, 5 Mar 2012 11:02:18 +0000
Subject: [tei-council] PR for TEI in Google Books (was Re: some brief
 reports to save time during our upcoming conf call)
In-Reply-To: <4F549C2A.1010406@retired.ox.ac.uk>
References: <4F4978F8.205@ultraslavonic.info>
	<CAC_Lu0a4ddMsKdqTfofgJA9XmLvFpJ_FC8LQAy9X0rBBiDTAQw@mail.gmail.com>
	<4F5436D4.8040605@ultraslavonic.info> <4F5498EF.90001@kcl.ac.uk>
	<10B41F85-FE85-4EC0-9301-A732FF929434@oucs.ox.ac.uk>
	<4F549B54.2040108@kcl.ac.uk> <4F549C2A.1010406@retired.ox.ac.uk>
Message-ID: <2596d7e0-fbcf-491c-b823-d39cff890d35@HUB01.ad.oak.ox.ac.uk>

"You may not sell, rent, lease, distribute, broadcast, transfer or assign your rights to the Google Digital Content or any part of it to any third party except as expressly permitted by Google "

so I suspect there are no rights to re-use.
--
Stormageddon Rahtz      
Head of Information and Support Group
Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431

S?lo le pido a Dios
que el futuro no me sea indiferente


From kevin.s.hawkins at ultraslavonic.info  Mon Mar  5 09:04:26 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Mon, 05 Mar 2012 09:04:26 -0500
Subject: [tei-council] PR for TEI in Google Books (was Re: some brief
 reports to save time during our upcoming conf call)
In-Reply-To: <4F549C2A.1010406@retired.ox.ac.uk>
References: <4F4978F8.205@ultraslavonic.info>	<CAC_Lu0a4ddMsKdqTfofgJA9XmLvFpJ_FC8LQAy9X0rBBiDTAQw@mail.gmail.com>	<4F5436D4.8040605@ultraslavonic.info>
	<4F5498EF.90001@kcl.ac.uk>	<10B41F85-FE85-4EC0-9301-A732FF929434@oucs.ox.ac.uk>
	<4F549B54.2040108@kcl.ac.uk> <4F549C2A.1010406@retired.ox.ac.uk>
Message-ID: <4F54C7EA.6090006@ultraslavonic.info>

While Google might plan to prepare TEI documents of in-copyright books 
scanned by their partners (to give back to the partners along with page 
images and OCR), I am concerned with the deployment of code to 
books.google.com for public-domain titles.  This is what the general 
public would see.

Here is a title that I believe everyone (even those outside of the US) 
can see in full:

http://books.google.com/books?id=7nsCAAAAQAAJ

If you click "Preview this book" and then click the gear icon in the 
upper right, you can choose to "Download PDF".  They PDF that is 
generated has a page at the front which explains a bit about it and asks 
(though does not require) that you use it for non-commercial purposes. 
I expect that Google would do the same for a TEI document.

As Gabby said, the work itself is in the public domain, and in the US 
you can't receive copyright protection for a reproduction of a 
public-domain work that doesn't involve new creative work.  While 
reprints of public domain titles can sometimes receive copyright 
protection in some other countries, I doubt Google would assert such 
rights in specific countries.

In short, we're talking about Google releasing these TEI documents into 
the public domain.

On 3/5/12 5:57 AM, Lou Burnard wrote:
> I think Kevin did give us this impression during the teleconf. Certainly
> that's what the minutes (which I sent to James last night) say!
>
> I suspect my esteemed colleague  Rahtz is trolling on the use of the
> phrase "public domain"
>
> On 05/03/12 10:54, Gabriel Bodard wrote:
>> Well, the texts themselves are public domain. Do we know what license
>> Google normally attach to otherwise PD texts that they release? (E.g.
>> page scans.) I wonder what would be the point of releasing TEI versions
>> of texts without licensing them for some kind of re-use...?
>>
>> Kevin, any insight on this? Any value in pushing in this direction?
>>
>> G
>>
>> On 2012-03-05 10:50, Sebastian Rahtz wrote:
>>>
>>> On 5 Mar 2012, at 10:43, Gabriel Bodard wrote:
>>>
>>>> really really bad (or contains bad OCR), the fact that TEI is a format
>>>> chosen to encode many many thousands of public domain texts
>>>
>>> it would really be a big deal if Google released these texts
>>> as public domain?. but I don't think thats what you mean :-}
>>>
>>> --
>>> Stormageddon Rahtz
>>> Head of Information and Support Group
>>> Oxford University Computing Services
>>> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>>>
>>> S?lo le pido a Dios
>>> que el futuro no me sea indiferente
>>>
>>
>

From sebastian.rahtz at oucs.ox.ac.uk  Mon Mar  5 09:18:12 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Mon, 5 Mar 2012 14:18:12 +0000
Subject: [tei-council] PR for TEI in Google Books (was Re: some brief
 reports to save time during our upcoming conf call)
In-Reply-To: <4F54C7EA.6090006@ultraslavonic.info>
References: <4F4978F8.205@ultraslavonic.info>
	<CAC_Lu0a4ddMsKdqTfofgJA9XmLvFpJ_FC8LQAy9X0rBBiDTAQw@mail.gmail.com>
	<4F5436D4.8040605@ultraslavonic.info> <4F5498EF.90001@kcl.ac.uk>
	<10B41F85-FE85-4EC0-9301-A732FF929434@oucs.ox.ac.uk>
	<4F549B54.2040108@kcl.ac.uk> <4F549C2A.1010406@retired.ox.ac.uk>
	<4F54C7EA.6090006@ultraslavonic.info>
Message-ID: <67EECFD4-BF42-4348-9937-170B965A0BB0@oucs.ox.ac.uk>

I am not convinced. That PDF is just a set of images, isn't it? The TEI-ed XML version _would_ attract copyright, as there
is substantial intellectual effort being put into the work. If you can show me a google book with the actual OCRed text being
given to me with a free license, then I may believe?..
--
Stormageddon Rahtz      
Head of Information and Support Group
Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431

S?lo le pido a Dios
que el futuro no me sea indiferente


From kevin.s.hawkins at ultraslavonic.info  Mon Mar  5 09:29:26 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Mon, 05 Mar 2012 09:29:26 -0500
Subject: [tei-council] PR for TEI in Google Books (was Re: some brief
 reports to save time during our upcoming conf call)
In-Reply-To: <67EECFD4-BF42-4348-9937-170B965A0BB0@oucs.ox.ac.uk>
References: <4F4978F8.205@ultraslavonic.info>
	<CAC_Lu0a4ddMsKdqTfofgJA9XmLvFpJ_FC8LQAy9X0rBBiDTAQw@mail.gmail.com>
	<4F5436D4.8040605@ultraslavonic.info> <4F5498EF.90001@kcl.ac.uk>
	<10B41F85-FE85-4EC0-9301-A732FF929434@oucs.ox.ac.uk>
	<4F549B54.2040108@kcl.ac.uk> <4F549C2A.1010406@retired.ox.ac.uk>
	<4F54C7EA.6090006@ultraslavonic.info>
	<67EECFD4-BF42-4348-9937-170B965A0BB0@oucs.ox.ac.uk>
Message-ID: <4F54CDC6.8000806@ultraslavonic.info>

Creative work is not the same as "sweat of the brow" in US copyright 
case law.  It takes a lot of effort to compile a telephone book, but 
there's no creativity in its arrangement.  So it is not copyrightable.

Google has developed algorithms for inserting markup, but no TEI 
document created using this algorithm requires creativity.  So the 
algorithm is copyrightable but not the documents it produces.

In any case, no need to trust me.  Let's just be ready with the PR 
announcement in case Google does not attach a copyright notice to the 
TEI document.  If they do attach a copyright notice, I'll be ready to 
argue with the Google engineer that it's a spurious claim.

On 3/5/12 9:18 AM, Sebastian Rahtz wrote:
> I am not convinced. That PDF is just a set of images, isn't it? The TEI-ed XML version _would_ attract copyright, as there
> is substantial intellectual effort being put into the work. If you can show me a google book with the actual OCRed text being
> given to me with a free license, then I may believe?..
> --
> Stormageddon Rahtz
> Head of Information and Support Group
> Oxford University Computing Services
> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>
> S?lo le pido a Dios
> que el futuro no me sea indiferente
>

From lou.burnard at retired.ox.ac.uk  Mon Mar  5 09:44:04 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Mon, 05 Mar 2012 14:44:04 +0000
Subject: [tei-council] PR for TEI in Google Books (was Re: some brief
 reports to save time during our upcoming conf call)
In-Reply-To: <4F54CDC6.8000806@ultraslavonic.info>
References: <4F4978F8.205@ultraslavonic.info>	<CAC_Lu0a4ddMsKdqTfofgJA9XmLvFpJ_FC8LQAy9X0rBBiDTAQw@mail.gmail.com>	<4F5436D4.8040605@ultraslavonic.info>
	<4F5498EF.90001@kcl.ac.uk>	<10B41F85-FE85-4EC0-9301-A732FF929434@oucs.ox.ac.uk>	<4F549B54.2040108@kcl.ac.uk>
	<4F549C2A.1010406@retired.ox.ac.uk>	<4F54C7EA.6090006@ultraslavonic.info>	<67EECFD4-BF42-4348-9937-170B965A0BB0@oucs.ox.ac.uk>
	<4F54CDC6.8000806@ultraslavonic.info>
Message-ID: <4F54D134.1010303@retired.ox.ac.uk>

I was talking about this with another TEI Board member at lunch today, 
and she said "Of course what we really want is for it to be possible to 
export/import TEI format in Google Docs."

That does seems like an interesting prospect worth raising with Mr 
Google, if we have the opportunity. Though I suppose that the part 
concerned with  Google Docs and the part concerned with Google Books 
rarely meet.



On 05/03/12 14:29, Kevin Hawkins wrote:
> Creative work is not the same as "sweat of the brow" in US copyright
> case law.  It takes a lot of effort to compile a telephone book, but
> there's no creativity in its arrangement.  So it is not copyrightable.
>
> Google has developed algorithms for inserting markup, but no TEI
> document created using this algorithm requires creativity.  So the
> algorithm is copyrightable but not the documents it produces.
>
> In any case, no need to trust me.  Let's just be ready with the PR
> announcement in case Google does not attach a copyright notice to the
> TEI document.  If they do attach a copyright notice, I'll be ready to
> argue with the Google engineer that it's a spurious claim.
>
> On 3/5/12 9:18 AM, Sebastian Rahtz wrote:
>> I am not convinced. That PDF is just a set of images, isn't it? The TEI-ed XML version _would_ attract copyright, as there
>> is substantial intellectual effort being put into the work. If you can show me a google book with the actual OCRed text being
>> given to me with a free license, then I may believe?..
>> --
>> Stormageddon Rahtz
>> Head of Information and Support Group
>> Oxford University Computing Services
>> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>>
>> S?lo le pido a Dios
>> que el futuro no me sea indiferente
>>


From sebastian.rahtz at oucs.ox.ac.uk  Mon Mar  5 10:14:34 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Mon, 5 Mar 2012 15:14:34 +0000
Subject: [tei-council] PR for TEI in Google Books (was Re: some brief
 reports to save time during our upcoming conf call)
In-Reply-To: <4F54D134.1010303@retired.ox.ac.uk>
References: <4F4978F8.205@ultraslavonic.info>
	<CAC_Lu0a4ddMsKdqTfofgJA9XmLvFpJ_FC8LQAy9X0rBBiDTAQw@mail.gmail.com>
	<4F5436D4.8040605@ultraslavonic.info> <4F5498EF.90001@kcl.ac.uk>
	<10B41F85-FE85-4EC0-9301-A732FF929434@oucs.ox.ac.uk>
	<4F549B54.2040108@kcl.ac.uk> <4F549C2A.1010406@retired.ox.ac.uk>
	<4F54C7EA.6090006@ultraslavonic.info>
	<67EECFD4-BF42-4348-9937-170B965A0BB0@oucs.ox.ac.uk>
	<4F54CDC6.8000806@ultraslavonic.info>
	<4F54D134.1010303@retired.ox.ac.uk>
Message-ID: <d8286125-0e61-403d-937b-ecb163af81c0@HUB01.ad.oak.ox.ac.uk>


On 5 Mar 2012, at 14:44, Lou Burnard wrote:

> I was talking about this with another TEI Board member at lunch today, 
> and she said "Of course what we really want is for it to be possible to 
> export/import TEI format in Google Docs."

She wants a mare's nest?

Google Docs is a weak imitation of Microsoft Word, with all
the concomitant issues of lack of nesting. 

you can of course convert TEI to/from word-processor formats using OxGarage,
and use the results in GiggleDocs, if thats your wish.

But I agree with your surmise, that the different parts of Google are
quite unlikely to talk to each other.
--
Stormageddon Rahtz      
Head of Information and Support Group
Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431

S?lo le pido a Dios
que el futuro no me sea indiferente


From kevin.s.hawkins at ultraslavonic.info  Mon Mar  5 12:23:00 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Mon, 05 Mar 2012 12:23:00 -0500
Subject: [tei-council] Proposal to clarify and rationalize encoding of
 pagination in bibliographic citations
Message-ID: <4F54F674.6030404@ultraslavonic.info>

Folks,

As I mentioned during our conf call, the Ad-Hoc Commmittee on Encoding 
of Bibliographic Citations has been working on a proposal to handle the 
remaining thorny issue for citations: clarifying and rationalizing 
encoding of pagination in bibliographic citations.  Since the comment 
thread on the open ticket in SourceForge had grown quite long, we have 
formulated a full, clean, unified proposal:

http://www.tei-c.org/Activities/Council/Working/tcw23.xml

I've started a new SourceForge feature request to allow for a public 
discussion:

http://purl.org/TEI/fr/3497079

I hope we'll be able to consider this at the meeting in Ann Arbor, if 
not before.

Kevin



From James.Cummings at oucs.ox.ac.uk  Mon Mar  5 16:40:16 2012
From: James.Cummings at oucs.ox.ac.uk (James Cummings)
Date: Mon, 05 Mar 2012 21:40:16 +0000
Subject: [tei-council] PR for TEI in Google Books (was Re: some brief
 reports to save time during our upcoming conf call)
In-Reply-To: <4F5436D4.8040605@ultraslavonic.info>
References: <4F4978F8.205@ultraslavonic.info>	<CAC_Lu0a4ddMsKdqTfofgJA9XmLvFpJ_FC8LQAy9X0rBBiDTAQw@mail.gmail.com>
	<4F5436D4.8040605@ultraslavonic.info>
Message-ID: <4F5532C0.60909@oucs.ox.ac.uk>

On 05/03/12 03:45, Kevin Hawkins wrote:
> I believe the teleconference discussion did not reach a conclusion on
> whether, once Google deploys their code, the TEI-C should (a) ride a way
> of publicity that might be generated in the community, (b) seek to
> create a wave, or (c) do nothing.  In any case, I plan to act as a
> private citizen (not in my role as a Council member) in publicizing this
> since I personally believe it's significant, even if Google turns out
> TEI files that many of us think aren't all that usable.

Although some had reservations about the quality of the TEI that 
Google would be producing, I don' think anyone doubts that Google 
making any large number of texts available in some form of TEI is 
potentially beneficial to the TEI.  I would support the TEI-C 
using this publicity to attract people to the TEI who might not 
have heard of it.

> appointed hour arrives.  However, I don't know who should make an
> official statement on behalf of the TEI-C.

I'm of the opinion that official press releases on behalf of the 
consortium or such should come from the Board via the Chair. I 
hope that we'll have some warning before this comes about and 
they'll have time to draft something. I'll mention it to JohnU as 
an item to discuss at the next board meeting. But yes, this does 
not stop anyone talking about it in a private capacity. I'm of 
the opinion that when any of us are posting (e.g. to TEI-L) that 
we're doing so in such a capacity unless we say something like 
"The TEI Technical Council asks that....".

> Perhaps we don't need an
> official statement: instead, someone posts their own private
> announcement to TEI-L and then it gets added to the news feed on
> www.tei-c.org.

Only thanks to David Sewell and the helpful band of news posters, 
I only mention it to take any opportunity to thank them.

-James

-- 
Dr James Cummings, InfoDev
Oxford University Computing Services
University of Oxford

From James.Cummings at oucs.ox.ac.uk  Mon Mar  5 16:48:42 2012
From: James.Cummings at oucs.ox.ac.uk (James Cummings)
Date: Mon, 05 Mar 2012 21:48:42 +0000
Subject: [tei-council] Minutes of 2012-02-28 telco
Message-ID: <4F5534BA.5030803@oucs.ox.ac.uk>


The minutes for the 2012-02-28 teleconference are up at:

http://www.tei-c.org/Activities/Council/Meetings/tcm49.xml

Let me (or Lou) know of any changes or corrections.

Best,
-James


-- 
Dr James Cummings, InfoDev
Oxford University Computing Services
University of Oxford

From James.Cummings at oucs.ox.ac.uk  Tue Mar  6 16:34:48 2012
From: James.Cummings at oucs.ox.ac.uk (James Cummings)
Date: Tue, 06 Mar 2012 21:34:48 +0000
Subject: [tei-council] Programme Committee for TEI Members' Meeting and
	Conference
Message-ID: <4F5682F8.60902@oucs.ox.ac.uk>


Hi all,

Can I ask for a volunteer to join me on the Board's ad hoc 
Programme/Organizational Committee for this year's TEI 
Conference? This will be hosted at Texas A&M University, and it 
might make sense if it was someone who was planning to attend.

Best,

-James

-- 
Dr James Cummings, InfoDev
Oxford University Computing Services
University of Oxford

From kevin.s.hawkins at ultraslavonic.info  Tue Mar  6 19:35:40 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Tue, 06 Mar 2012 19:35:40 -0500
Subject: [tei-council] PR for TEI in Google Books (was Re: some brief
 reports to save time during our upcoming conf call)
In-Reply-To: <4F54D134.1010303@retired.ox.ac.uk>
References: <4F4978F8.205@ultraslavonic.info>	<CAC_Lu0a4ddMsKdqTfofgJA9XmLvFpJ_FC8LQAy9X0rBBiDTAQw@mail.gmail.com>	<4F5436D4.8040605@ultraslavonic.info>	<4F5498EF.90001@kcl.ac.uk>	<10B41F85-FE85-4EC0-9301-A732FF929434@oucs.ox.ac.uk>	<4F549B54.2040108@kcl.ac.uk>	<4F549C2A.1010406@retired.ox.ac.uk>	<4F54C7EA.6090006@ultraslavonic.info>	<67EECFD4-BF42-4348-9937-170B965A0BB0@oucs.ox.ac.uk>	<4F54CDC6.8000806@ultraslavonic.info>
	<4F54D134.1010303@retired.ox.ac.uk>
Message-ID: <4F56AD5C.2040008@ultraslavonic.info>

I've asked our Google contact and suggested a couple of ways we might 
move forward on this.  The worst he can do is say no!

On 3/5/2012 9:44 AM, Lou Burnard wrote:
> I was talking about this with another TEI Board member at lunch today,
> and she said "Of course what we really want is for it to be possible to
> export/import TEI format in Google Docs."
>
> That does seems like an interesting prospect worth raising with Mr
> Google, if we have the opportunity. Though I suppose that the part
> concerned with  Google Docs and the part concerned with Google Books
> rarely meet.

From kevin.s.hawkins at ultraslavonic.info  Tue Mar  6 21:40:03 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Tue, 06 Mar 2012 21:40:03 -0500
Subject: [tei-council] Fwd: Re: Google Books > TEI
In-Reply-To: <CAHScxsXxO188J7bFBH929-r2btB1ajB8Fv=ESNPerXjVgEb24g@mail.gmail.com>
References: <CAHScxsXxO188J7bFBH929-r2btB1ajB8Fv=ESNPerXjVgEb24g@mail.gmail.com>
Message-ID: <4F56CA83.8050704@ultraslavonic.info>

All,

I'm forwarding two messages from our contact at Google (cc'd here), 
where he answers the questions that came up during our last conference 
call with some requests for further information from us.  He 
accidentally sent the second message sent only to me rather than to our 
whole committee, so I'm copying Laurent as well since he's no longer on 
the TEI Council.

(Ranjith, to prevent spam, only members can post to tei-council, but I 
can forward messages from you to the group.)

---Kevin

-------- Original Message --------
Subject: 	Re: Google Books > TEI
Date: 	Mon, 5 Mar 2012 15:43:13 -0800
From: 	Ranjith Unnikrishnan <ranjith at google.com>
To: 	Kevin Hawkins <kevin.s.hawkins at ultraslavonic.info>
CC: 	James.Cummings at oucs.ox.ac.uk, mholmes at uvic.ca, laurent.romary at inria.fr



Hi Kevin,

Responses are inline.

    1. Would Google be willing to release the code used for the
    transformation from Google's internal data format to TEI?  We
    realize the code might wouldn't be useful to anyone without the
    underlying data, but it might help users who are trying to
    understand what you produce and what errors are likely.


I personally don't think this is likely because (i) in addition to the 
source material we'd have to open-source our internal data format for 
the code to make any sense, and (ii) during the course of processing, 
the code interacts with many internal storage systems that cannot be 
made publicly accessible.

That said, the significant errors originate not from the process of 
converting our internal data format to TEI, but from poor OCR and/or 
structure analysis. So I'm not convinced that looking at the conversion 
code would serve the purpose of better understanding the errors. The 
bulk of the OCR work is done using the Tesseract OCR engine, which is 
open-source and is updated periodically, and so may be a better place 
for interested parties to look.


    2. Will there be a mechanism for users to report errors in the TEI
    files or submit revised TEI files?  This might relate to the work
    you're doing with James Cummings and others on matching TEI
    documents with scanned editions of the same source document.


This was my hope and intention from the start, but we don't have a 
feedback mechanism for this at the moment and I'm not sure what the best 
scalable solution is. In fact I'm eager to get your ideas on this since, 
as both stewards and users of the format, you are in a better position 
than us to guide and drive this correction process in the community of 
TEI users.

I'm not sure of the document matching work that you're referring to, but 
I am working with James to import some public-domain material that he 
can provide. My end of the work requires setting up the infrastructure 
to ingest ePub files directly into our corpus so that it is freely 
available to a broader audience via the Google Books website. In that 
respect, the work could relate to your comment as it should result in a 
way to import whole corrected TEI files (via an intermediate conversion 
to ePub).

On a related note, you may be aware of an early stage project out of 
Texas A&M University that is aimed at digitizing 18th century books via 
crowd-sourcing in combination with OCR. I've been trying to motivate 
them to use TEI as an input/output format so that when we eventually 
provide TEI files for public domain books, they will have a free source 
of input material to correct, and secondly if they wish to return the 
corrected TEI files to us to make freely available on Google Books then 
it will benefit everyone and every community involved. I don't know if 
they're completely on board with this vision, but I do know that some of 
the tools they plan to use do accept TEI.

~Ranjith



-------- Original Message --------
Subject: 	Re: scope of Google Books > TEI
Date: 	Tue, 6 Mar 2012 17:36:31 -0800
From: 	Ranjith Unnikrishnan <ranjith at google.com>
To: 	Kevin Hawkins <kevin.s.hawkins at ultraslavonic.info>



Actually, I'd like to turn that question around if you don't mind. Can 
you give some convincing arguments as to why such a release, if it were 
to happen, would be useful to the community?
The reason I'm asking is that we're still in early days and at this 
point I'm one of the few voices advocating making TEI files available in 
the manner you describe. If you can provide me some arguments, 
preferably with some backing numbers, around the impact you anticipate 
this having, it would help bolster my position and help move this forward.


On Tue, Mar 6, 2012 at 4:26 PM, Kevin Hawkins 
<kevin.s.hawkins at ultraslavonic.info 
<mailto:kevin.s.hawkins at ultraslavonic.info>> wrote:

    One more question, Ranjith: will this code, once deployed, make TEI
    available as a download format for all material in the public domain
    in the user's location?  Do you have a sense of how many titles this
    will affect in Google Books?  The TEI Consortium would like to be
    ready to generate publicity around this, so having some stats will help.


From kevin.s.hawkins at ultraslavonic.info  Tue Mar  6 22:00:14 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Tue, 06 Mar 2012 22:00:14 -0500
Subject: [tei-council] Programme Committee for TEI Members' Meeting and
 Conference
In-Reply-To: <4F5682F8.60902@oucs.ox.ac.uk>
References: <4F5682F8.60902@oucs.ox.ac.uk>
Message-ID: <4F56CF3E.6030301@ultraslavonic.info>

James, has it been decided -- or are you at liberty to say yet -- what 
dates the conference will be held?  I imagine that will affect who is 
planning to attend.  --Kevin

On 3/6/12 4:34 PM, James Cummings wrote:
>
> Hi all,
>
> Can I ask for a volunteer to join me on the Board's ad hoc
> Programme/Organizational Committee for this year's TEI
> Conference? This will be hosted at Texas A&M University, and it
> might make sense if it was someone who was planning to attend.
>
> Best,
>
> -James
>

From kevin.s.hawkins at ultraslavonic.info  Tue Mar  6 22:49:22 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Tue, 06 Mar 2012 22:49:22 -0500
Subject: [tei-council] Fwd: Re: TEI for Google Docs?
In-Reply-To: <4F56BDF3.5020909@uvic.ca>
References: <4F56BDF3.5020909@uvic.ca>
Message-ID: <4F56DAC2.5070308@ultraslavonic.info>

Another message where we could use broader input than what our small 
group, formed to offer technical advice on samples, can come up with on 
our own.

-------- Original Message --------
Subject: 	Re: TEI for Google Docs?
Date: 	Tue, 6 Mar 2012 17:46:27 -0800
From: 	Martin Holmes <mholmes at uvic.ca>
Reply-To: 	mholmes at uvic.ca
Organization: 	UVic HCMC
To: 	Ranjith Unnikrishnan <ranjith at google.com>
CC: 	Kevin Hawkins <kevin.s.hawkins at ultraslavonic.info>, 
"James.Cummings at oucs.ox.ac.uk" <James.Cummings at oucs.ox.ac.uk>, 
"laurent.romary at inria.fr" <laurent.romary at inria.fr>



On 12-03-06 05:38 PM, Ranjith Unnikrishnan wrote:
>  Interesting suggestion. I'm not sure if the Docs team would be
>  interested in supporting export to TEI but can ask. What would the use
>  of such functionality be?

One example: Various journals and conferences in our field use TEI as
the format for abstracts and papers. People would be able to author
these documents in Google Docs and save them in TEI.

Cheers,
Martin

>  On Tue, Mar 6, 2012 at 4:34 PM, Kevin Hawkins
>  <kevin.s.hawkins at ultraslavonic.info
>  <mailto:kevin.s.hawkins at ultraslavonic.info>>  wrote:
>
>      Hi again Ranjith,
>
>      I've been hearing of interest in our community of having Google Docs
>      export in TEI.  I think this would actually be fairly easy.  There
>      are two ways we could proceed:
>
>      a) Produce a Google Docs file that includes at least one instance of
>      every paragraph style, list style, and formatting (bold, italic,
>      etc.). Then one of us produces this same document encoded in TEI for
>      you.
>
>      b) Produce a mapping of every paragraph style, list style, and
>      formatting (bold, italic, etc.) in Google Docs to TEI elements,
>      explaining how to build the hierarchy.
>
>      Please let us know if either of these would work for you!
>
>      Kevin
>
>

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)


From rwelzenbach at gmail.com  Wed Mar  7 09:48:33 2012
From: rwelzenbach at gmail.com (Rebecca Welzenbach)
Date: Wed, 7 Mar 2012 09:48:33 -0500
Subject: [tei-council] Fwd: Re: Google Books > TEI
In-Reply-To: <4F56CA83.8050704@ultraslavonic.info>
References: <CAHScxsXxO188J7bFBH929-r2btB1ajB8Fv=ESNPerXjVgEb24g@mail.gmail.com>
	<4F56CA83.8050704@ultraslavonic.info>
Message-ID: <CAA2irtJs0PfM8=FgJdRC3FxK7Oqu_U9_=8R3PRLbFOam6qka0w@mail.gmail.com>

Thanks for all of this Kevin....very interesting. More thoughts and
questions below....

Becky

> ? ?2. Will there be a mechanism for users to report errors in the TEI
> ? ?files or submit revised TEI files? ?This might relate to the work
> ? ?you're doing with James Cummings and others on matching TEI
> ? ?documents with scanned editions of the same source document.
>
>
> This was my hope and intention from the start, but we don't have a
> feedback mechanism for this at the moment and I'm not sure what the best
> scalable solution is. In fact I'm eager to get your ideas on this since,
> as both stewards and users of the format, you are in a better position
> than us to guide and drive this correction process in the community of
> TEI users.

Ranjith's commet is in line with my (admittedly vague) sense of what
Google currently allows: that you can report errors, but this simply
puts the reported book back on a queue to be re-scanned and re-OCRed.
One challenge here may be that Google doesn't want corrections
inserted in the middle or at the end of their workflow, because if the
book is ever re-processed, by accident or on purpose, those changes
would be lost.
>
> I'm not sure of the document matching work that you're referring to, but
> I am working with James to import some public-domain material that he
> can provide. My end of the work requires setting up the infrastructure
> to ingest ePub files directly into our corpus so that it is freely
> available to a broader audience via the Google Books website. In that
> respect, the work could relate to your comment as it should result in a
> way to import whole corrected TEI files (via an intermediate conversion
> to ePub).

James, these are the ECCO-TCP texts (and perhaps other Oxford Text
Archive texts), right? If matching the texts up to scanned books is
*not* part of this work, does that mean that from Google's perspective
these works would only consist of electronic text, and no page images?
 That's the part that seemed to me like it might tie in with the
development of a text feedback mechanism, because it implies a
workflow where the electronic text is the original object, rather than
the output of another process (in contrast with the current scan + OCR
model). If text is 1) going to be accepted from the outside in the
first place and 2) Not going to be generated or overwritten by a
Google engine, building a way to make or recommend corrections to the
text starts to look more reasonable.
>
> On a related note, you may be aware of an early stage project out of
> Texas A&M University that is aimed at digitizing 18th century books via
> crowd-sourcing in combination with OCR. I've been trying to motivate
> them to use TEI as an input/output format so that when we eventually
> provide TEI files for public domain books, they will have a free source
> of input material to correct, and secondly if they wish to return the
> corrected TEI files to us to make freely available on Google Books then
> it will benefit everyone and every community involved. I don't know if
> they're completely on board with this vision, but I do know that some of
> the tools they plan to use do accept TEI.

Very interesting! I'm aware of the work at Texas A&M (the TCP has
provided lots of 18th-century texts to them for testing this OCR) and
glad to hear that they're in touch with Google about it. I agree it
would be nice if they could generate TEI as an output, but I'm not
sure I understand what is meant by TEI as an input. Since this work
involves OCR, isn't the desired input format just the page images? My
understanding of the project at Texas A&M is that the goal is to train
OCR to successfully capture characters in books/fonts where this is
currently still too hard to do. If this project is successful, it
would be great if the tool they build could be used to generate more
accurate OCR for older books in Google's corpus. But I'm not sure that
crowdsourced correction of existing electronic text fits into the
mission of their project.

> Actually, I'd like to turn that question around if you don't mind. Can
> you give some convincing arguments as to why such a release, if it were
> to happen, would be useful to the community?
> The reason I'm asking is that we're still in early days and at this
> point I'm one of the few voices advocating making TEI files available in
> the manner you describe. If you can provide me some arguments,
> preferably with some backing numbers, around the impact you anticipate
> this having, it would help bolster my position and help move this forward.
>
>
> On Tue, Mar 6, 2012 at 4:26 PM, Kevin Hawkins
> <kevin.s.hawkins at ultraslavonic.info
> <mailto:kevin.s.hawkins at ultraslavonic.info>> wrote:
>
> ? ?One more question, Ranjith: will this code, once deployed, make TEI
> ? ?available as a download format for all material in the public domain
> ? ?in the user's location? ?Do you have a sense of how many titles this
> ? ?will affect in Google Books? ?The TEI Consortium would like to be
> ? ?ready to generate publicity around this, so having some stats will help.
>
I'm not sure I understand what Ranjith wants here. Is this a request
for justification of making the TEI available for download, or
justification for doing TEI at all? If the TEI files would not be
available for download, what's the point of producing it?

From James.Cummings at oucs.ox.ac.uk  Wed Mar  7 10:32:04 2012
From: James.Cummings at oucs.ox.ac.uk (James Cummings)
Date: Wed, 07 Mar 2012 15:32:04 +0000
Subject: [tei-council] Programme Committee for TEI Members' Meeting and
 Conference
In-Reply-To: <4F56CF3E.6030301@ultraslavonic.info>
References: <4F5682F8.60902@oucs.ox.ac.uk>
	<4F56CF3E.6030301@ultraslavonic.info>
Message-ID: <4F577F74.6040507@oucs.ox.ac.uk>

On 07/03/12 03:00, Kevin Hawkins wrote:
> James, has it been decided -- or are you at liberty to say yet -- what
> dates the conference will be held?  I imagine that will affect who is
> planning to attend.  --Kevin

It certainly isn't my place to announce the details. 
Hypothetically, an educated guess would probably expect it to be 
on (and the days surrounding) say 10 November or so.

Are you volunteering Kevin?

-James

-- 
Dr James Cummings, InfoDev,
Computing Services, University of Oxford

From kevin.s.hawkins at ultraslavonic.info  Wed Mar  7 10:43:46 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Wed, 07 Mar 2012 10:43:46 -0500
Subject: [tei-council] Programme Committee for TEI Members' Meeting and
 Conference
In-Reply-To: <4F577F74.6040507@oucs.ox.ac.uk>
References: <4F5682F8.60902@oucs.ox.ac.uk>	<4F56CF3E.6030301@ultraslavonic.info>
	<4F577F74.6040507@oucs.ox.ac.uk>
Message-ID: <4F578232.8090303@ultraslavonic.info>

On 3/7/2012 10:32 AM, James Cummings wrote:
> On 07/03/12 03:00, Kevin Hawkins wrote:
>> James, has it been decided -- or are you at liberty to say yet -- what
>> dates the conference will be held?  I imagine that will affect who is
>> planning to attend.  --Kevin
>
> It certainly isn't my place to announce the details.
> Hypothetically, an educated guess would probably expect it to be
> on (and the days surrounding) say 10 November or so.
>
> Are you volunteering Kevin?

No.  :(  Just asking in order to move the discussion forward.

From rwelzenbach at gmail.com  Wed Mar  7 11:00:00 2012
From: rwelzenbach at gmail.com (Rebecca Welzenbach)
Date: Wed, 7 Mar 2012 11:00:00 -0500
Subject: [tei-council] Programme Committee for TEI Members' Meeting and
	Conference
In-Reply-To: <4F578232.8090303@ultraslavonic.info>
References: <4F5682F8.60902@oucs.ox.ac.uk>
	<4F56CF3E.6030301@ultraslavonic.info>
	<4F577F74.6040507@oucs.ox.ac.uk>
	<4F578232.8090303@ultraslavonic.info>
Message-ID: <CAA2irt+mbgVCfgnx+yxaJkL7ELsKRDGiA=DKJb7XNkxiwkopyg@mail.gmail.com>

I would be happy to be on the program committee. I intend to make
attending the TEI Meeting a priority this year, but (as Kevin
suggests), I guess I won't know for sure until we know the dates.

Becky

On Wed, Mar 7, 2012 at 10:43 AM, Kevin Hawkins
<kevin.s.hawkins at ultraslavonic.info> wrote:
> On 3/7/2012 10:32 AM, James Cummings wrote:
>> On 07/03/12 03:00, Kevin Hawkins wrote:
>>> James, has it been decided -- or are you at liberty to say yet -- what
>>> dates the conference will be held? ?I imagine that will affect who is
>>> planning to attend. ?--Kevin
>>
>> It certainly isn't my place to announce the details.
>> Hypothetically, an educated guess would probably expect it to be
>> on (and the days surrounding) say 10 November or so.
>>
>> Are you volunteering Kevin?
>
> No. ?:( ?Just asking in order to move the discussion forward.
> --
> tei-council mailing list
> tei-council at lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>
> PLEASE NOTE: postings to this list are publicly archived

From James.Cummings at oucs.ox.ac.uk  Wed Mar  7 12:13:07 2012
From: James.Cummings at oucs.ox.ac.uk (James Cummings)
Date: Wed, 07 Mar 2012 17:13:07 +0000
Subject: [tei-council] Fwd: Re: Google Books > TEI
In-Reply-To: <CAA2irtJs0PfM8=FgJdRC3FxK7Oqu_U9_=8R3PRLbFOam6qka0w@mail.gmail.com>
References: <CAHScxsXxO188J7bFBH929-r2btB1ajB8Fv=ESNPerXjVgEb24g@mail.gmail.com>	<4F56CA83.8050704@ultraslavonic.info>
	<CAA2irtJs0PfM8=FgJdRC3FxK7Oqu_U9_=8R3PRLbFOam6qka0w@mail.gmail.com>
Message-ID: <4F579723.8080706@oucs.ox.ac.uk>

On 07/03/12 14:48, Rebecca Welzenbach wrote:
> James, these are the ECCO-TCP texts (and perhaps other Oxford Text
> Archive texts), right?

Yes, I believe these would be ECCO-TCP and eventually potentially 
EEBO-TCP conversions along with other texts from the OTA 
converted to TEI P5 and then to EPub.

> If matching the texts up to scanned books is
> *not* part of this work, does that mean that from Google's perspective
> these works would only consist of electronic text, and no page images?

The idea, from my point of view, might be that you could download 
the EPub on your android phone using the google Books 
application. Presumably, the matching up would mean that where 
there was a Google Books scanned book of this, they could offer 
the EPub as an alternative to download or something.

> That's the part that seemed to me like it might tie in with the
> development of a text feedback mechanism, because it implies a
> workflow where the electronic text is the original object, rather than
> the output of another process (in contrast with the current scan + OCR
> model). If text is 1) going to be accepted from the outside in the
> first place and 2) Not going to be generated or overwritten by a
> Google engine, building a way to make or recommend corrections to the
> text starts to look more reasonable.

I think this would be treated as a separate but related object.

-James


-- 
Dr James Cummings, InfoDev,
Computing Services, University of Oxford

From James.Cummings at oucs.ox.ac.uk  Fri Mar  9 12:30:56 2012
From: James.Cummings at oucs.ox.ac.uk (James Cummings)
Date: Fri, 09 Mar 2012 17:30:56 +0000
Subject: [tei-council] Fwd: Re: Google Books > TEI
In-Reply-To: <CAHScxsWcSq5Yp=xcmJbTGW3cKrKBrVdpJuhj1cG_=+AS-NvJcA@mail.gmail.com>
References: <CAHScxsXxO188J7bFBH929-r2btB1ajB8Fv=ESNPerXjVgEb24g@mail.gmail.com>
	<4F56CA83.8050704@ultraslavonic.info>
	<CAA2irtJs0PfM8=FgJdRC3FxK7Oqu_U9_=8R3PRLbFOam6qka0w@mail.gmail.com>
	<CAHScxsWcSq5Yp=xcmJbTGW3cKrKBrVdpJuhj1cG_=+AS-NvJcA@mail.gmail.com>
Message-ID: <4F5A3E50.7020508@oucs.ox.ac.uk>

On 07/03/12 18:48, Ranjith Unnikrishnan wrote:
> I'm looking for formal justification from you for our producing
> and making TEI files available for download on Google Books. Both
> require our commitment of several resources for the long term eg.
> for updating and maintaining code, making necessary changes in
> our processing pipeline, maintaining the download functionality
> for the lifetime of Google Books, committing to the extra storage
> space and computation etc. I have some anecdotal knowledge of why
> TEI is important, and have already spent a substantial amount of
> personal time writing the code and vetting the converted TEI
> output along with various interested parties; so we know it is
> possible and obviously I have an interest in seeing this all the
> way through. But since this will be "product"-level decision,
> there are others who will need to be convinced and will ask the
> big questions such as:

Hi Ranjith,

I'm more than happy to work with you in coming up with some 
executive summary kind of answers to these questions if that will 
help. How about I share a google doc with you and some of the 
others of the ad hoc working group.

> Hope that makes sense. I'm just trying to move this effort
> forward with your input.

We really appreciate that and all your hard work. We're more than 
happy to work with you in any way to benefit TEI users.

I'll share a google doc link from my gapps account soon.

-James

-- 
Dr James Cummings, InfoDev,
Computing Services, University of Oxford

From mholmes at uvic.ca  Tue Mar 13 14:21:15 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Tue, 13 Mar 2012 11:21:15 -0700
Subject: [tei-council] Question about an attribute definition
Message-ID: <4F5F901B.2090608@uvic.ca>

This is relevant to <http://purl.org/TEI/BUGS/3455686>.

I was looking at att.global.analytic, and noticed this:

[quote]
ana	(analysis)
Datatype 	1?? occurrences of

data.pointer

separated by whitespace

Values 	one or more valid identifiers of one or more interpretive 
elements (usually fs or interp), separated by white space.
[/quote]

I'm not really sure whether the valDesc reflects the datatype properly 
in this case. Is "valid identifiers" really the same thing as data.pointers?

Cheers,
Martin
-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From PFSchaffner at umich.edu  Wed Mar 14 12:00:39 2012
From: PFSchaffner at umich.edu (Paul F. Schaffner)
Date: Wed, 14 Mar 2012 12:00:39 -0400 (EDT)
Subject: [tei-council] Ann Arbor <-> DTW transportation
In-Reply-To: <4F5F901B.2090608@uvic.ca>
References: <4F5F901B.2090608@uvic.ca>
Message-ID: <Pine.LNX.4.64.1203141154150.16107@goldenaxe.gpcc.itd.umich.edu>

In case it went unnoticed and might prove useful to some, I should
point out that a cheaper and more frequent bus service between Detroit 
Metro Airport (DTW) and central Ann Arbor is scheduled to begin on 2 
April:

http://michiganflyer.com/ann-arbor-airride-schedules.asp

http://www.theride.org/PRAirRide.asp

I will also be glad to provide pickup service. (Even at the
Windsor railway station, Lou.)

pfs
--------------------------------------------------------------------
Paul Schaffner | PFSchaffner at umich.edu | http://www.umich.edu/~pfs/
316-C Hatcher Library N, Univ. of Michigan, Ann Arbor MI 48109-1190
--------------------------------------------------------------------

From mholmes at uvic.ca  Wed Mar 14 12:36:42 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Wed, 14 Mar 2012 09:36:42 -0700
Subject: [tei-council] Ann Arbor <-> DTW transportation
In-Reply-To: <Pine.LNX.4.64.1203141154150.16107@goldenaxe.gpcc.itd.umich.edu>
References: <4F5F901B.2090608@uvic.ca>
	<Pine.LNX.4.64.1203141154150.16107@goldenaxe.gpcc.itd.umich.edu>
Message-ID: <4F60C91A.7080501@uvic.ca>

This looks handy. I'm arriving about 5.30pm on the Sunday -- I'm 
assuming these buses run on Sundays -- so I could be on the 6.30. Of the 
three final stops:

Kensington Hotel	
AA/BTC Blake Transit Ctr
AA/CCTC Central Campus

which is best for where we're staying?

Cheers,
Martin

On 12-03-14 09:00 AM, Paul F. Schaffner wrote:
> In case it went unnoticed and might prove useful to some, I should
> point out that a cheaper and more frequent bus service between Detroit
> Metro Airport (DTW) and central Ann Arbor is scheduled to begin on 2
> April:
>
> http://michiganflyer.com/ann-arbor-airride-schedules.asp
>
> http://www.theride.org/PRAirRide.asp
>
> I will also be glad to provide pickup service. (Even at the
> Windsor railway station, Lou.)
>
> pfs
> --------------------------------------------------------------------
> Paul Schaffner | PFSchaffner at umich.edu | http://www.umich.edu/~pfs/
> 316-C Hatcher Library N, Univ. of Michigan, Ann Arbor MI 48109-1190
> --------------------------------------------------------------------

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From lou.burnard at retired.ox.ac.uk  Wed Mar 14 15:48:51 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Wed, 14 Mar 2012 19:48:51 +0000
Subject: [tei-council] Ann Arbor <-> DTW transportation
In-Reply-To: <Pine.LNX.4.64.1203141154150.16107@goldenaxe.gpcc.itd.umich.edu>
References: <4F5F901B.2090608@uvic.ca>
	<Pine.LNX.4.64.1203141154150.16107@goldenaxe.gpcc.itd.umich.edu>
Message-ID: <4F60F623.3070105@retired.ox.ac.uk>

On 14/03/12 16:00, Paul F. Schaffner wrote:

> I will also be glad to provide pickup service. (Even at the
> Windsor railway station, Lou.)
>

Thanks for this generous offer, but I've revised my travel plans -- I'm 
now spending the Friday night in Chicago and catching the Wolverine all 
the way down to Ann Arbor on Saturday!

Though I might need some help getting to DTW in time for a 1922 
departure on Wednesday (only way I could get a reasonable open jaw fare)



From mholmes at uvic.ca  Wed Mar 14 16:25:00 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Wed, 14 Mar 2012 13:25:00 -0700
Subject: [tei-council] Ann Arbor <-> DTW transportation
In-Reply-To: <4F60F623.3070105@retired.ox.ac.uk>
References: <4F5F901B.2090608@uvic.ca>	<Pine.LNX.4.64.1203141154150.16107@goldenaxe.gpcc.itd.umich.edu>
	<4F60F623.3070105@retired.ox.ac.uk>
Message-ID: <4F60FE9C.4090708@uvic.ca>

I'm leaving on a 6pm plane on Wednesday, so I'll have to take off before 
you do. We could share transport if you're willing to leave early.

Cheers,
Martin

On 12-03-14 12:48 PM, Lou Burnard wrote:
> On 14/03/12 16:00, Paul F. Schaffner wrote:
>
>> I will also be glad to provide pickup service. (Even at the
>> Windsor railway station, Lou.)
>>
>
> Thanks for this generous offer, but I've revised my travel plans -- I'm
> now spending the Friday night in Chicago and catching the Wolverine all
> the way down to Ann Arbor on Saturday!
>
> Though I might need some help getting to DTW in time for a 1922
> departure on Wednesday (only way I could get a reasonable open jaw fare)
>
>

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From PFSchaffner at umich.edu  Wed Mar 14 16:35:40 2012
From: PFSchaffner at umich.edu (Paul F. Schaffner)
Date: Wed, 14 Mar 2012 16:35:40 -0400 (EDT)
Subject: [tei-council] Ann Arbor <-> DTW transportation
In-Reply-To: <4F60C91A.7080501@uvic.ca>
References: <4F5F901B.2090608@uvic.ca>
	<Pine.LNX.4.64.1203141154150.16107@goldenaxe.gpcc.itd.umich.edu>
	<4F60C91A.7080501@uvic.ca>
Message-ID: <Pine.LNX.4.64.1203141545160.952@rygar.gpcc.itd.umich.edu>

On Wed, 14 Mar 2012, Martin Holmes wrote:

> This looks handy. I'm arriving about 5.30pm on the Sunday -- I'm
> assuming these buses run on Sundays

Since the service is new, I'd assume nothing. But we'll keep watch
to find out!

> Kensington Hotel
> AA/BTC Blake Transit Ctr
> AA/CCTC Central Campus
> which is best for where we're staying?

The last of these three. The first is 2.5 miles to the south
(out by the interstate); the second is a ten-minute walk to the
west; and the third is a five-minute walk to the east from
the Bell Tower Hotel.

Hmm, I haven't tried this mapmaking site before, but maybe
it will work:

http://www.communitywalk.com/map/index/1488824#101 at 0010742.13if8-83.2dSP0

pfs



--------------------------------------------------------------------
Paul Schaffner | PFSchaffner at umich.edu | http://www.umich.edu/~pfs/
316-C Hatcher Library N, Univ. of Michigan, Ann Arbor MI 48109-1190
--------------------------------------------------------------------

From lou.burnard at retired.ox.ac.uk  Sun Mar 18 15:47:12 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Sun, 18 Mar 2012 19:47:12 +0000
Subject: [tei-council] ticket triage
Message-ID: <4F663BC0.5080902@retired.ox.ac.uk>

A quick look at 
http://www.tei-c.org/Activities/Council/Working/tcw17.html shows the 
following state of play...

GREEN tickets (11 bugs; 5 Feature Requests)

May I suggest that Council members should take a quick look initially at 
the GREEN tickets?  As far as I can tell, what needs to be done is 
fairly self evident in each case (that's the definition of GREEN, after 
all). Furthermore, each GREEN ticket (with one exception, see below) has 
been assigned to someone for action. All you need do therefore is post a 
message to the list if you disagree with the action being proposed for 
the ticket.

The exception is bug 3437782. This is a ticket I created and on which 
no-one has commented so far; I am reluctant to assign it to myself and 
just do it, even though I think it should just be done. So please 
express your views on that one!

AMBER tickets (18 bugs; 13 Feature requests)

Several of them are on overlapping topics (e.g. we have three or four 
talking about <wit>, and more than one worrying about the use of <idno>) 
so I think we should be able to group them together and dispose of quite 
a few in Chicago. I'll have a shot at doing that (the grouping) next, in 
consultation with James when he comes back from his hols.

RED tickets (4 red; 11 feature requests)

Some of these are quite old (the oldest goes back to 2007) so maybe we 
should find some way of indicating topics that we are giving up on for 
the moment.

Feel free, of course, to add comments on any ticket if you think the 
discussion is in need of it.

From sebastian.rahtz at oucs.ox.ac.uk  Sun Mar 18 19:24:58 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Sun, 18 Mar 2012 23:24:58 +0000
Subject: [tei-council] ticket triage
In-Reply-To: <4F663BC0.5080902@retired.ox.ac.uk>
References: <4F663BC0.5080902@retired.ox.ac.uk>
Message-ID: <7668ea3a-de70-490b-964b-f134bb6ea3fa@HUB02.ad.oak.ox.ac.uk>


On 18 Mar 2012, at 19:47, Lou Burnard wrote:
> May I suggest that Council members should take a quick look initially at 
> the GREEN tickets?

added some comments where i can

> 
> The exception is bug 3437782. This is a ticket I created and on which 
> no-one has commented so far; I am reluctant to assign it to myself and 
> just do it, even though I think it should just be done. So please 
> express your views on that one!
have done so, with a heavy heart


--
Stormageddon Rahtz      
Head of Information and Support Group, Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431

S?lo le pido a Dios
que el futuro no me sea indiferente


From sebastian.rahtz at oucs.ox.ac.uk  Tue Mar 20 05:55:55 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Tue, 20 Mar 2012 09:55:55 +0000
Subject: [tei-council] ticket triage
In-Reply-To: <4F663BC0.5080902@retired.ox.ac.uk>
References: <4F663BC0.5080902@retired.ox.ac.uk>
Message-ID: <a76cce4d-9319-42a3-9ac9-552591e2e69a@HUB04.ad.oak.ox.ac.uk>


On 18 Mar 2012, at 19:47, Lou Burnard wrote:
> May I suggest that Council members should take a quick look initially at 
> the GREEN tickets?

added some comments where i can

> 
> The exception is bug 3437782. This is a ticket I created and on which 
> no-one has commented so far; I am reluctant to assign it to myself and 
> just do it, even though I think it should just be done. So please 
> express your views on that one!
have done so, with a heavy heart


--
Stormageddon Rahtz      
Head of Information and Support Group, Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431

S?lo le pido a Dios
que el futuro no me sea indiferente


From mholmes at uvic.ca  Fri Mar 23 14:16:42 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Fri, 23 Mar 2012 11:16:42 -0700
Subject: [tei-council] <egXML> example
Message-ID: <4F6CBE0A.6050307@uvic.ca>

Hi there,

Why is the first example on this page flagged as incorrect?

<http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-egXML.html>

I don't actually see what's wrong with it, but even if it is wrong, it's 
mightily confusing to have as the first example of an element 
proclaiming itself as incorrect, surely? What am I missing?

Cheers,
Martin

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From PFSchaffner at umich.edu  Fri Mar 23 15:20:48 2012
From: PFSchaffner at umich.edu (Paul F. Schaffner)
Date: Fri, 23 Mar 2012 15:20:48 -0400 (EDT)
Subject: [tei-council] <egXML> example
In-Reply-To: <4F6CBE0A.6050307@uvic.ca>
References: <4F6CBE0A.6050307@uvic.ca>
Message-ID: <Pine.LNX.4.64.1203231519030.15262@zaxxon.gpcc.itd.umich.edu>


Umm, because "fr" does not stand for "English" ?

pfs


On Fri, 23 Mar 2012, Martin Holmes wrote:

> Hi there,
>
> Why is the first example on this page flagged as incorrect?
>
> <http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-egXML.html>
>
> I don't actually see what's wrong with it, but even if it is wrong, it's
> mightily confusing to have as the first example of an element
> proclaiming itself as incorrect, surely? What am I missing?
>
> Cheers,
> Martin
>
> -- 
> Martin Holmes
> University of Victoria Humanities Computing and Media Centre
> (mholmes at uvic.ca)
> -- 
> tei-council mailing list
> tei-council at lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>
> PLEASE NOTE: postings to this list are publicly archived
>
>
>

--------------------------------------------------------------------
Paul Schaffner | PFSchaffner at umich.edu | http://www.umich.edu/~pfs/
316-C Hatcher Library N, Univ. of Michigan, Ann Arbor MI 48109-1190
--------------------------------------------------------------------

From lou.burnard at retired.ox.ac.uk  Fri Mar 23 15:39:35 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Fri, 23 Mar 2012 19:39:35 +0000
Subject: [tei-council] <egXML> example
In-Reply-To: <Pine.LNX.4.64.1203231519030.15262@zaxxon.gpcc.itd.umich.edu>
References: <4F6CBE0A.6050307@uvic.ca>,
	<Pine.LNX.4.64.1203231519030.15262@zaxxon.gpcc.itd.umich.edu>
Message-ID: <5C0990DE-01B4-4C56-859B-7CD0066EF2C0@retired.ox.ac.uk>

I think Martins question wasnt so much what's wrong as why is a wrong example here.   The answer is because we wanted to test the mechanism which renders wrong examples colourfully I believe.
Sent from my HTC

----- Reply message -----
From: "Paul F. Schaffner" <PFSchaffner at umich.edu>
To: "Martin Holmes" <mholmes at uvic.ca>
Cc: "TEI Council" <tei-council at lists.village.virginia.edu>
Subject: [tei-council] <egXML> example
Date: Fri, Mar 23, 2012 19:20




Umm, because "fr" does not stand for "English" ?

pfs


On Fri, 23 Mar 2012, Martin Holmes wrote:

> Hi there,
>
> Why is the first example on this page flagged as incorrect?
>
> <http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-egXML.html>
>
> I don't actually see what's wrong with it, but even if it is wrong, it's
> mightily confusing to have as the first example of an element
> proclaiming itself as incorrect, surely? What am I missing?
>
> Cheers,
> Martin
>
> --
> Martin Holmes
> University of Victoria Humanities Computing and Media Centre
> (mholmes at uvic.ca)
> --
> tei-council mailing list
> tei-council at lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>
> PLEASE NOTE: postings to this list are publicly archived
>
>
>

--------------------------------------------------------------------
Paul Schaffner | PFSchaffner at umich.edu | http://www.umich.edu/~pfs/
316-C Hatcher Library N, Univ. of Michigan, Ann Arbor MI 48109-1190
--------------------------------------------------------------------
--
tei-council mailing list
tei-council at lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

PLEASE NOTE: postings to this list are publicly archived

From rwelzenbach at gmail.com  Fri Mar 23 15:56:10 2012
From: rwelzenbach at gmail.com (Rebecca Welzenbach)
Date: Fri, 23 Mar 2012 15:56:10 -0400
Subject: [tei-council] <egXML> example
In-Reply-To: <5C0990DE-01B4-4C56-859B-7CD0066EF2C0@retired.ox.ac.uk>
References: <4F6CBE0A.6050307@uvic.ca>
	<Pine.LNX.4.64.1203231519030.15262@zaxxon.gpcc.itd.umich.edu>
	<5C0990DE-01B4-4C56-859B-7CD0066EF2C0@retired.ox.ac.uk>
Message-ID: <CAA2irtJaayR2ejZd9O8KrvVEsvLYM_11XfwBm7uo2sewxNgM3A@mail.gmail.com>

Part of Martin's question seems easy: in cases like this can we just
flip the examples around so a correct one appears first and an
incorrect one second (so we don't say what not to do without first
saying what to do).

But I am also confused about why this example is flagged as incorrect.
Although <language ident="fr">English</language> is clearly wrong, I
would expect an example identified as "incorrect" to be wrong in the
way it uses the element it is demonstrating--not to have some other
error inside of it. Is there something wrong with how <egXML> is being
used in this example?

Becky

On Fri, Mar 23, 2012 at 3:39 PM, Lou Burnard
<lou.burnard at retired.ox.ac.uk> wrote:
> I think Martins question wasnt so much what's wrong as why is a wrong example here. ? The answer is because we wanted to test the mechanism which renders wrong examples colourfully I believe.
> Sent from my HTC
>
> ----- Reply message -----
> From: "Paul F. Schaffner" <PFSchaffner at umich.edu>
> To: "Martin Holmes" <mholmes at uvic.ca>
> Cc: "TEI Council" <tei-council at lists.village.virginia.edu>
> Subject: [tei-council] <egXML> example
> Date: Fri, Mar 23, 2012 19:20
>
>
>
>
> Umm, because "fr" does not stand for "English" ?
>
> pfs
>
>
> On Fri, 23 Mar 2012, Martin Holmes wrote:
>
>> Hi there,
>>
>> Why is the first example on this page flagged as incorrect?
>>
>> <http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-egXML.html>
>>
>> I don't actually see what's wrong with it, but even if it is wrong, it's
>> mightily confusing to have as the first example of an element
>> proclaiming itself as incorrect, surely? What am I missing?
>>
>> Cheers,
>> Martin
>>
>> --
>> Martin Holmes
>> University of Victoria Humanities Computing and Media Centre
>> (mholmes at uvic.ca)
>> --
>> tei-council mailing list
>> tei-council at lists.village.Virginia.EDU
>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>>
>> PLEASE NOTE: postings to this list are publicly archived
>>
>>
>>
>
> --------------------------------------------------------------------
> Paul Schaffner | PFSchaffner at umich.edu | http://www.umich.edu/~pfs/
> 316-C Hatcher Library N, Univ. of Michigan, Ann Arbor MI 48109-1190
> --------------------------------------------------------------------
> --
> tei-council mailing list
> tei-council at lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>
> PLEASE NOTE: postings to this list are publicly archived
> --
> tei-council mailing list
> tei-council at lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>
> PLEASE NOTE: postings to this list are publicly archived

From mholmes at uvic.ca  Fri Mar 23 16:38:11 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Fri, 23 Mar 2012 13:38:11 -0700
Subject: [tei-council] <egXML> example
In-Reply-To: <CAA2irtJaayR2ejZd9O8KrvVEsvLYM_11XfwBm7uo2sewxNgM3A@mail.gmail.com>
References: <4F6CBE0A.6050307@uvic.ca>
	<Pine.LNX.4.64.1203231519030.15262@zaxxon.gpcc.itd.umich.edu>
	<5C0990DE-01B4-4C56-859B-7CD0066EF2C0@retired.ox.ac.uk>
	<CAA2irtJaayR2ejZd9O8KrvVEsvLYM_11XfwBm7uo2sewxNgM3A@mail.gmail.com>
Message-ID: <4F6CDF33.5010706@uvic.ca>

This is actually more complex than we thought:

I'd actually missed the language mismatch error, because I was looking 
for something that was wrong with the use of <egXML>. But now I've 
looked at the source, I see this:

   <exemplum xml:lang="en">
     <egXML xmlns="http://www.tei-c.org/ns/Examples" xml:lang="und"
	   valid="false">
<![CDATA[
       <egXML xmlns="http://www.tei-c.org/ns/Examples">
         <langUsage>
           <language ident="fr">English</language>
         </langUsage>
       </egXML>
<!-- Though syntactically valid, this example is incorrect -->
]]>
     </egXML>
   </exemplum>

The purpose of the "incorrect" example seems to be to demonstrate the 
usage of the @valid attribute, here set to false. However, there's a 
use-mention problem in the rendering of the page, and the result is that 
instead of seeing how to flag an incorrect example as invalid, the 
example itself is flagged as invalid.

At this point, my heart goes out to Sebastian, whose stylesheets are 
expected to be able to tell the difference between using an attribute 
designed to show that examples are invalid, on an example of an example, 
and exemplifying the use of that attribute. Ye gods and little fishes, 
as me old dad used to say.

Cheers,
Martin


On 12-03-23 12:56 PM, Rebecca Welzenbach wrote:
> Part of Martin's question seems easy: in cases like this can we just
> flip the examples around so a correct one appears first and an
> incorrect one second (so we don't say what not to do without first
> saying what to do).

> But I am also confused about why this example is flagged as incorrect.
> Although<language ident="fr">English</language>  is clearly wrong, I
> would expect an example identified as "incorrect" to be wrong in the
> way it uses the element it is demonstrating--not to have some other
> error inside of it. Is there something wrong with how<egXML>  is being
> used in this example?
>
> Becky
>
> On Fri, Mar 23, 2012 at 3:39 PM, Lou Burnard
> <lou.burnard at retired.ox.ac.uk>  wrote:
>> I think Martins question wasnt so much what's wrong as why is a wrong example here.   The answer is because we wanted to test the mechanism which renders wrong examples colourfully I believe.
>> Sent from my HTC
>>
>> ----- Reply message -----
>> From: "Paul F. Schaffner"<PFSchaffner at umich.edu>
>> To: "Martin Holmes"<mholmes at uvic.ca>
>> Cc: "TEI Council"<tei-council at lists.village.virginia.edu>
>> Subject: [tei-council]<egXML>  example
>> Date: Fri, Mar 23, 2012 19:20
>>
>>
>>
>>
>> Umm, because "fr" does not stand for "English" ?
>>
>> pfs
>>
>>
>> On Fri, 23 Mar 2012, Martin Holmes wrote:
>>
>>> Hi there,
>>>
>>> Why is the first example on this page flagged as incorrect?
>>>
>>> <http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-egXML.html>
>>>
>>> I don't actually see what's wrong with it, but even if it is wrong, it's
>>> mightily confusing to have as the first example of an element
>>> proclaiming itself as incorrect, surely? What am I missing?
>>>
>>> Cheers,
>>> Martin
>>>
>>> --
>>> Martin Holmes
>>> University of Victoria Humanities Computing and Media Centre
>>> (mholmes at uvic.ca)
>>> --
>>> tei-council mailing list
>>> tei-council at lists.village.Virginia.EDU
>>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>>>
>>> PLEASE NOTE: postings to this list are publicly archived
>>>
>>>
>>>
>>
>> --------------------------------------------------------------------
>> Paul Schaffner | PFSchaffner at umich.edu | http://www.umich.edu/~pfs/
>> 316-C Hatcher Library N, Univ. of Michigan, Ann Arbor MI 48109-1190
>> --------------------------------------------------------------------
>> --
>> tei-council mailing list
>> tei-council at lists.village.Virginia.EDU
>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>>
>> PLEASE NOTE: postings to this list are publicly archived
>> --
>> tei-council mailing list
>> tei-council at lists.village.Virginia.EDU
>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>>
>> PLEASE NOTE: postings to this list are publicly archived
> .
>

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From mholmes at uvic.ca  Fri Mar 23 16:56:17 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Fri, 23 Mar 2012 13:56:17 -0700
Subject: [tei-council] <egXML> example
In-Reply-To: <4F6CDF33.5010706@uvic.ca>
References: <4F6CBE0A.6050307@uvic.ca>
	<Pine.LNX.4.64.1203231519030.15262@zaxxon.gpcc.itd.umich.edu>
	<5C0990DE-01B4-4C56-859B-7CD0066EF2C0@retired.ox.ac.uk>
	<CAA2irtJaayR2ejZd9O8KrvVEsvLYM_11XfwBm7uo2sewxNgM3A@mail.gmail.com>
	<4F6CDF33.5010706@uvic.ca>
Message-ID: <4F6CE371.9000003@uvic.ca>

I just tried to submit a bug for this, and the Tracker appeared to 
accept it, but now it doesn't appear anywhere. I wonder if it's because 
I quoted the egXML code which has a CDATA section in it?

I'll try again later.

Cheers,
Martin

On 12-03-23 01:38 PM, Martin Holmes wrote:
> This is actually more complex than we thought:
>
> I'd actually missed the language mismatch error, because I was looking
> for something that was wrong with the use of<egXML>. But now I've
> looked at the source, I see this:
>
>     <exemplum xml:lang="en">
>       <egXML xmlns="http://www.tei-c.org/ns/Examples" xml:lang="und"
> 	   valid="false">
> <![CDATA[
>         <egXML xmlns="http://www.tei-c.org/ns/Examples">
>           <langUsage>
>             <language ident="fr">English</language>
>           </langUsage>
>         </egXML>
> <!-- Though syntactically valid, this example is incorrect -->
> ]]>
>       </egXML>
>     </exemplum>
>
> The purpose of the "incorrect" example seems to be to demonstrate the
> usage of the @valid attribute, here set to false. However, there's a
> use-mention problem in the rendering of the page, and the result is that
> instead of seeing how to flag an incorrect example as invalid, the
> example itself is flagged as invalid.
>
> At this point, my heart goes out to Sebastian, whose stylesheets are
> expected to be able to tell the difference between using an attribute
> designed to show that examples are invalid, on an example of an example,
> and exemplifying the use of that attribute. Ye gods and little fishes,
> as me old dad used to say.
>
> Cheers,
> Martin
>
>
> On 12-03-23 12:56 PM, Rebecca Welzenbach wrote:
>> Part of Martin's question seems easy: in cases like this can we just
>> flip the examples around so a correct one appears first and an
>> incorrect one second (so we don't say what not to do without first
>> saying what to do).
>
>> But I am also confused about why this example is flagged as incorrect.
>> Although<language ident="fr">English</language>   is clearly wrong, I
>> would expect an example identified as "incorrect" to be wrong in the
>> way it uses the element it is demonstrating--not to have some other
>> error inside of it. Is there something wrong with how<egXML>   is being
>> used in this example?
>>
>> Becky
>>
>> On Fri, Mar 23, 2012 at 3:39 PM, Lou Burnard
>> <lou.burnard at retired.ox.ac.uk>   wrote:
>>> I think Martins question wasnt so much what's wrong as why is a wrong example here.   The answer is because we wanted to test the mechanism which renders wrong examples colourfully I believe.
>>> Sent from my HTC
>>>
>>> ----- Reply message -----
>>> From: "Paul F. Schaffner"<PFSchaffner at umich.edu>
>>> To: "Martin Holmes"<mholmes at uvic.ca>
>>> Cc: "TEI Council"<tei-council at lists.village.virginia.edu>
>>> Subject: [tei-council]<egXML>   example
>>> Date: Fri, Mar 23, 2012 19:20
>>>
>>>
>>>
>>>
>>> Umm, because "fr" does not stand for "English" ?
>>>
>>> pfs
>>>
>>>
>>> On Fri, 23 Mar 2012, Martin Holmes wrote:
>>>
>>>> Hi there,
>>>>
>>>> Why is the first example on this page flagged as incorrect?
>>>>
>>>> <http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-egXML.html>
>>>>
>>>> I don't actually see what's wrong with it, but even if it is wrong, it's
>>>> mightily confusing to have as the first example of an element
>>>> proclaiming itself as incorrect, surely? What am I missing?
>>>>
>>>> Cheers,
>>>> Martin
>>>>
>>>> --
>>>> Martin Holmes
>>>> University of Victoria Humanities Computing and Media Centre
>>>> (mholmes at uvic.ca)
>>>> --
>>>> tei-council mailing list
>>>> tei-council at lists.village.Virginia.EDU
>>>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>>>>
>>>> PLEASE NOTE: postings to this list are publicly archived
>>>>
>>>>
>>>>
>>>
>>> --------------------------------------------------------------------
>>> Paul Schaffner | PFSchaffner at umich.edu | http://www.umich.edu/~pfs/
>>> 316-C Hatcher Library N, Univ. of Michigan, Ann Arbor MI 48109-1190
>>> --------------------------------------------------------------------
>>> --
>>> tei-council mailing list
>>> tei-council at lists.village.Virginia.EDU
>>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>>>
>>> PLEASE NOTE: postings to this list are publicly archived
>>> --
>>> tei-council mailing list
>>> tei-council at lists.village.Virginia.EDU
>>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>>>
>>> PLEASE NOTE: postings to this list are publicly archived
>> .
>>
>

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From mholmes at uvic.ca  Fri Mar 23 16:57:35 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Fri, 23 Mar 2012 13:57:35 -0700
Subject: [tei-council] <egXML> example
In-Reply-To: <4F6CE371.9000003@uvic.ca>
References: <4F6CBE0A.6050307@uvic.ca>
	<Pine.LNX.4.64.1203231519030.15262@zaxxon.gpcc.itd.umich.edu>
	<5C0990DE-01B4-4C56-859B-7CD0066EF2C0@retired.ox.ac.uk>
	<CAA2irtJaayR2ejZd9O8KrvVEsvLYM_11XfwBm7uo2sewxNgM3A@mail.gmail.com>
	<4F6CDF33.5010706@uvic.ca> <4F6CE371.9000003@uvic.ca>
Message-ID: <4F6CE3BF.7030407@uvic.ca>

The missing bug mysteriously appeared:

<http://purl.org/TEI/BUGS/3510653>

Cheers,
Martin

On 12-03-23 01:56 PM, Martin Holmes wrote:
> I just tried to submit a bug for this, and the Tracker appeared to
> accept it, but now it doesn't appear anywhere. I wonder if it's because
> I quoted the egXML code which has a CDATA section in it?
>
> I'll try again later.
>
> Cheers,
> Martin
>
> On 12-03-23 01:38 PM, Martin Holmes wrote:
>> This is actually more complex than we thought:
>>
>> I'd actually missed the language mismatch error, because I was looking
>> for something that was wrong with the use of<egXML>. But now I've
>> looked at the source, I see this:
>>
>>      <exemplum xml:lang="en">
>>        <egXML xmlns="http://www.tei-c.org/ns/Examples" xml:lang="und"
>> 	   valid="false">
>> <![CDATA[
>>          <egXML xmlns="http://www.tei-c.org/ns/Examples">
>>            <langUsage>
>>              <language ident="fr">English</language>
>>            </langUsage>
>>          </egXML>
>> <!-- Though syntactically valid, this example is incorrect -->
>> ]]>
>>        </egXML>
>>      </exemplum>
>>
>> The purpose of the "incorrect" example seems to be to demonstrate the
>> usage of the @valid attribute, here set to false. However, there's a
>> use-mention problem in the rendering of the page, and the result is that
>> instead of seeing how to flag an incorrect example as invalid, the
>> example itself is flagged as invalid.
>>
>> At this point, my heart goes out to Sebastian, whose stylesheets are
>> expected to be able to tell the difference between using an attribute
>> designed to show that examples are invalid, on an example of an example,
>> and exemplifying the use of that attribute. Ye gods and little fishes,
>> as me old dad used to say.
>>
>> Cheers,
>> Martin
>>
>>
>> On 12-03-23 12:56 PM, Rebecca Welzenbach wrote:
>>> Part of Martin's question seems easy: in cases like this can we just
>>> flip the examples around so a correct one appears first and an
>>> incorrect one second (so we don't say what not to do without first
>>> saying what to do).
>>
>>> But I am also confused about why this example is flagged as incorrect.
>>> Although<language ident="fr">English</language>    is clearly wrong, I
>>> would expect an example identified as "incorrect" to be wrong in the
>>> way it uses the element it is demonstrating--not to have some other
>>> error inside of it. Is there something wrong with how<egXML>    is being
>>> used in this example?
>>>
>>> Becky
>>>
>>> On Fri, Mar 23, 2012 at 3:39 PM, Lou Burnard
>>> <lou.burnard at retired.ox.ac.uk>    wrote:
>>>> I think Martins question wasnt so much what's wrong as why is a wrong example here.   The answer is because we wanted to test the mechanism which renders wrong examples colourfully I believe.
>>>> Sent from my HTC
>>>>
>>>> ----- Reply message -----
>>>> From: "Paul F. Schaffner"<PFSchaffner at umich.edu>
>>>> To: "Martin Holmes"<mholmes at uvic.ca>
>>>> Cc: "TEI Council"<tei-council at lists.village.virginia.edu>
>>>> Subject: [tei-council]<egXML>    example
>>>> Date: Fri, Mar 23, 2012 19:20
>>>>
>>>>
>>>>
>>>>
>>>> Umm, because "fr" does not stand for "English" ?
>>>>
>>>> pfs
>>>>
>>>>
>>>> On Fri, 23 Mar 2012, Martin Holmes wrote:
>>>>
>>>>> Hi there,
>>>>>
>>>>> Why is the first example on this page flagged as incorrect?
>>>>>
>>>>> <http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-egXML.html>
>>>>>
>>>>> I don't actually see what's wrong with it, but even if it is wrong, it's
>>>>> mightily confusing to have as the first example of an element
>>>>> proclaiming itself as incorrect, surely? What am I missing?
>>>>>
>>>>> Cheers,
>>>>> Martin
>>>>>
>>>>> --
>>>>> Martin Holmes
>>>>> University of Victoria Humanities Computing and Media Centre
>>>>> (mholmes at uvic.ca)
>>>>> --
>>>>> tei-council mailing list
>>>>> tei-council at lists.village.Virginia.EDU
>>>>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>>>>>
>>>>> PLEASE NOTE: postings to this list are publicly archived
>>>>>
>>>>>
>>>>>
>>>>
>>>> --------------------------------------------------------------------
>>>> Paul Schaffner | PFSchaffner at umich.edu | http://www.umich.edu/~pfs/
>>>> 316-C Hatcher Library N, Univ. of Michigan, Ann Arbor MI 48109-1190
>>>> --------------------------------------------------------------------
>>>> --
>>>> tei-council mailing list
>>>> tei-council at lists.village.Virginia.EDU
>>>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>>>>
>>>> PLEASE NOTE: postings to this list are publicly archived
>>>> --
>>>> tei-council mailing list
>>>> tei-council at lists.village.Virginia.EDU
>>>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>>>>
>>>> PLEASE NOTE: postings to this list are publicly archived
>>> .
>>>
>>
>

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From sebastian.rahtz at oucs.ox.ac.uk  Sat Mar 24 09:45:39 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Sat, 24 Mar 2012 13:45:39 +0000
Subject: [tei-council] <egXML> example
In-Reply-To: <4F6CDF33.5010706@uvic.ca>
References: <4F6CBE0A.6050307@uvic.ca>
	<Pine.LNX.4.64.1203231519030.15262@zaxxon.gpcc.itd.umich.edu>
	<5C0990DE-01B4-4C56-859B-7CD0066EF2C0@retired.ox.ac.uk>
	<CAA2irtJaayR2ejZd9O8KrvVEsvLYM_11XfwBm7uo2sewxNgM3A@mail.gmail.com>
	<4F6CDF33.5010706@uvic.ca>
Message-ID: <0C8224DC-3A7D-4D6A-BC0A-4444CDF4DE0B@oucs.ox.ac.uk>

this thing does seem extraordinary.  if we revert to 

<exemplum xml:lang="en">
    <egXML xmlns="http://www.tei-c.org/ns/Examples" xml:lang="und">
      <![CDATA[<egXML xmlns="http://www.tei-c.org/ns/Examples">
        <langUsage>
          <language ident="fr">French</language>
        </langUsage>
      </egXML>]]>
    </egXML>
  </exemplum>

it is entirely valid, but misleading, cos the XML is not XML just
looks like it. so I feel inclined to keep "valid=false", lose the comment,
and correct the semantics.

if you wonder its in CDATA to avoid the whole thing being processed.
--
Sebastian Rahtz    
Head of Information and Support Group, Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431

S?lo le pido a Dios
que el futuro no me sea indiferente




From mholmes at uvic.ca  Sat Mar 24 10:50:59 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Sat, 24 Mar 2012 07:50:59 -0700
Subject: [tei-council] <egXML> example
In-Reply-To: <0C8224DC-3A7D-4D6A-BC0A-4444CDF4DE0B@oucs.ox.ac.uk>
References: <4F6CBE0A.6050307@uvic.ca>
	<Pine.LNX.4.64.1203231519030.15262@zaxxon.gpcc.itd.umich.edu>
	<5C0990DE-01B4-4C56-859B-7CD0066EF2C0@retired.ox.ac.uk>
	<CAA2irtJaayR2ejZd9O8KrvVEsvLYM_11XfwBm7uo2sewxNgM3A@mail.gmail.com>
	<4F6CDF33.5010706@uvic.ca>
	<0C8224DC-3A7D-4D6A-BC0A-4444CDF4DE0B@oucs.ox.ac.uk>
Message-ID: <4F6DDF53.5000601@uvic.ca>

I think I just had an aha moment:

If the purpose of the example is to illustrate the use of @valid, then 
@valid needs also to be on the embedded CDATA <egXML> as well as the 
outer one:

    <exemplum xml:lang="en">
      <egXML xmlns="http://www.tei-c.org/ns/Examples" xml:lang="und"
	   valid="false">
<![CDATA[
        <egXML xmlns="http://www.tei-c.org/ns/Examples" valid="false">
          <langUsage>
            <language ident="fr">English</language>
          </langUsage>
        </egXML>
<!-- Though syntactically valid, this example is incorrect -->
]]>
      </egXML>
    </exemplum>

The comment also needs to point out what is being illustrated:

<!-- Though syntactically valid, this example is incorrect because
      the text of the <language> element does not match its @ident
      value. Therefore the attribute @valid is set to false.  -->

Now, if I'm right, the purpose of the example will be apparent. I've 
implemented that change and we'll see what the result looks like when 
Jinks has finished with it in an hour or so:

<http://teijenkins.hcmc.uvic.ca:8080/job/TEIP5-Documentation/lastSuccessfulBuild/artifact/Guidelines-web/en/html/ref-egXML.html>

I'm still not sure if we should have that as the first example of 
<egXML>, but that's a different question.

Cheers,
Martin

On 12-03-24 06:45 AM, Sebastian Rahtz wrote:
> this thing does seem extraordinary.  if we revert to
>
> <exemplum xml:lang="en">
>      <egXML xmlns="http://www.tei-c.org/ns/Examples" xml:lang="und">
>        <![CDATA[<egXML xmlns="http://www.tei-c.org/ns/Examples">
>          <langUsage>
>            <language ident="fr">French</language>
>          </langUsage>
>        </egXML>]]>
>      </egXML>
>    </exemplum>
>
> it is entirely valid, but misleading, cos the XML is not XML just
> looks like it. so I feel inclined to keep "valid=false", lose the comment,
> and correct the semantics.
>
> if you wonder its in CDATA to avoid the whole thing being processed.
> --
> Sebastian Rahtz
> Head of Information and Support Group, Oxford University Computing Services
> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>
> S?lo le pido a Dios
> que el futuro no me sea indiferente
>
>
>

From lou.burnard at retired.ox.ac.uk  Sat Mar 24 11:25:39 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Sat, 24 Mar 2012 15:25:39 +0000
Subject: [tei-council] <egXML> example
In-Reply-To: <4F6DDF53.5000601@uvic.ca>
References: <4F6CBE0A.6050307@uvic.ca>	<Pine.LNX.4.64.1203231519030.15262@zaxxon.gpcc.itd.umich.edu>	<5C0990DE-01B4-4C56-859B-7CD0066EF2C0@retired.ox.ac.uk>	<CAA2irtJaayR2ejZd9O8KrvVEsvLYM_11XfwBm7uo2sewxNgM3A@mail.gmail.com>	<4F6CDF33.5010706@uvic.ca>	<0C8224DC-3A7D-4D6A-BC0A-4444CDF4DE0B@oucs.ox.ac.uk>
	<4F6DDF53.5000601@uvic.ca>
Message-ID: <4F6DE773.3040904@retired.ox.ac.uk>

Dear Alan Partridge [joke for brits only]

Your aha moment is plausible, though I think in fact the purpose of the 
@valid was just to check whether the colour change introduced by its 
presence at the outer level worked: i.e. to test the stylesheets, not 
exemplify the use of this attribute.

But your changes seem like an improvement.



On 24/03/12 14:50, Martin Holmes wrote:
> I think I just had an aha moment:
>
> If the purpose of the example is to illustrate the use of @valid, then
> @valid needs also to be on the embedded CDATA<egXML>  as well as the
> outer one:
>
>      <exemplum xml:lang="en">
>        <egXML xmlns="http://www.tei-c.org/ns/Examples" xml:lang="und"
> 	   valid="false">
> <![CDATA[
>          <egXML xmlns="http://www.tei-c.org/ns/Examples" valid="false">
>            <langUsage>
>              <language ident="fr">English</language>
>            </langUsage>
>          </egXML>
> <!-- Though syntactically valid, this example is incorrect -->
> ]]>
>        </egXML>
>      </exemplum>
>
> The comment also needs to point out what is being illustrated:
>
> <!-- Though syntactically valid, this example is incorrect because
>        the text of the<language>  element does not match its @ident
>        value. Therefore the attribute @valid is set to false.  -->
>
> Now, if I'm right, the purpose of the example will be apparent. I've
> implemented that change and we'll see what the result looks like when
> Jinks has finished with it in an hour or so:
>
> <http://teijenkins.hcmc.uvic.ca:8080/job/TEIP5-Documentation/lastSuccessfulBuild/artifact/Guidelines-web/en/html/ref-egXML.html>
>
> I'm still not sure if we should have that as the first example of
> <egXML>, but that's a different question.
>
> Cheers,
> Martin
>
> On 12-03-24 06:45 AM, Sebastian Rahtz wrote:
>> this thing does seem extraordinary.  if we revert to
>>
>> <exemplum xml:lang="en">
>>       <egXML xmlns="http://www.tei-c.org/ns/Examples" xml:lang="und">
>>         <![CDATA[<egXML xmlns="http://www.tei-c.org/ns/Examples">
>>           <langUsage>
>>             <language ident="fr">French</language>
>>           </langUsage>
>>         </egXML>]]>
>>       </egXML>
>>     </exemplum>
>>
>> it is entirely valid, but misleading, cos the XML is not XML just
>> looks like it. so I feel inclined to keep "valid=false", lose the comment,
>> and correct the semantics.
>>
>> if you wonder its in CDATA to avoid the whole thing being processed.
>> --
>> Sebastian Rahtz
>> Head of Information and Support Group, Oxford University Computing Services
>> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>>
>> S?lo le pido a Dios
>> que el futuro no me sea indiferente
>>
>>
>>


From sebastian.rahtz at oucs.ox.ac.uk  Sat Mar 24 12:53:40 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Sat, 24 Mar 2012 16:53:40 +0000
Subject: [tei-council] <egXML> example
In-Reply-To: <4F6DE773.3040904@retired.ox.ac.uk>
References: <4F6CBE0A.6050307@uvic.ca>
	<Pine.LNX.4.64.1203231519030.15262@zaxxon.gpcc.itd.umich.edu>
	<5C0990DE-01B4-4C56-859B-7CD0066EF2C0@retired.ox.ac.uk>
	<CAA2irtJaayR2ejZd9O8KrvVEsvLYM_11XfwBm7uo2sewxNgM3A@mail.gmail.com>
	<4F6CDF33.5010706@uvic.ca>
	<0C8224DC-3A7D-4D6A-BC0A-4444CDF4DE0B@oucs.ox.ac.uk>
	<4F6DDF53.5000601@uvic.ca> <4F6DE773.3040904@retired.ox.ac.uk>
Message-ID: <DC755EEB-B5A0-4443-BA02-B17E35B2531A@oucs.ox.ac.uk>

I am a little worried, as the point of valid=true|false|feasible was about XML validity, not semantic
validity. It would be better to make the example syntactically invalid.

I have submitted another change in which I have

 - added an example of valid=feasible
 - make the invalid one invalid
 - reordered the examples

which I hope makes sense
--
Sebastian Rahtz    
Head of Information and Support Group, Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431

S?lo le pido a Dios
que el futuro no me sea indiferente





From mholmes at uvic.ca  Sat Mar 24 20:02:52 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Sat, 24 Mar 2012 17:02:52 -0700
Subject: [tei-council] <egXML> example
In-Reply-To: <DC755EEB-B5A0-4443-BA02-B17E35B2531A@oucs.ox.ac.uk>
References: <4F6CBE0A.6050307@uvic.ca>
	<Pine.LNX.4.64.1203231519030.15262@zaxxon.gpcc.itd.umich.edu>
	<5C0990DE-01B4-4C56-859B-7CD0066EF2C0@retired.ox.ac.uk>
	<CAA2irtJaayR2ejZd9O8KrvVEsvLYM_11XfwBm7uo2sewxNgM3A@mail.gmail.com>
	<4F6CDF33.5010706@uvic.ca>
	<0C8224DC-3A7D-4D6A-BC0A-4444CDF4DE0B@oucs.ox.ac.uk>
	<4F6DDF53.5000601@uvic.ca> <4F6DE773.3040904@retired.ox.ac.uk>
	<DC755EEB-B5A0-4443-BA02-B17E35B2531A@oucs.ox.ac.uk>
Message-ID: <4F6E60AC.1020202@uvic.ca>

I think this works well.

It does bring up another issue that I've been thinking about for a 
while, though: a single specification file contains not only its element 
but also any attributes which are defined on the element, and which may 
be unique to it. There's no way (to my knowledge) to specify that any 
given example is focused on the use of the element or one of its 
attributes. It would be helpful if there were a way to specify what an 
example is supposed to be exemplifying.

We could always do this with comments inside the example, of course.

Cheers,
Martin

On 12-03-24 09:53 AM, Sebastian Rahtz wrote:
> I am a little worried, as the point of valid=true|false|feasible was about XML validity, not semantic
> validity. It would be better to make the example syntactically invalid.
>
> I have submitted another change in which I have
>
>   - added an example of valid=feasible
>   - make the invalid one invalid
>   - reordered the examples
>
> which I hope makes sense
> --
> Sebastian Rahtz
> Head of Information and Support Group, Oxford University Computing Services
> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>
> S?lo le pido a Dios
> que el futuro no me sea indiferente
>
>
>
>

From kevin.s.hawkins at ultraslavonic.info  Sat Mar 24 23:28:32 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Sat, 24 Mar 2012 23:28:32 -0400
Subject: [tei-council] summary of Council taking on a role in maintenance of
 Best Practices for TEI in Libraries
In-Reply-To: <1f2b0fcc-944d-46d7-ad1f-53ff54d886d8@HUB01.ad.oak.ox.ac.uk>
References: <4F40307E.6080807@ultraslavonic.info>
	<EBB790FD-70DA-40F9-BFF0-7C84F3E173B9@oucs.ox.ac.uk>
	<4F410CF6.4040804@ultraslavonic.info>
	<EBF08744-1474-4712-A41A-10D2DFF1042D@oucs.ox.ac.uk>
	<4F415AED.6000100@oucs.ox.ac.uk>
	<1f2b0fcc-944d-46d7-ad1f-53ff54d886d8@HUB01.ad.oak.ox.ac.uk>
Message-ID: <4F6E90E0.9060005@ultraslavonic.info>

All,

We didn't have time during our 28 February conf call to discuss the role 
of the TEI-C in maintaining the Best Practices for TEI in Libraries. 
Lou's minutes of our call say that we decided to defer this to the next 
meeting, but my notes were that we would resume discussion on the email 
list.  Let me try to summarize our recent discussion (see the 
tei-council thread "for 28 Feb. conf call: background on Best Practice 
for TEI in Libraries") since this could be useful whether we continue to 
discuss by email or as the basis for a discussion during our next meeting.

The BP was created by members of the SIG on Libraries and consists of a 
set of ODD files in a GitHub project, plus a few shell scripts and such 
for compilation into unified documentation. It was released as version 
3.0 (having superseded earlier documents with similar names), and a 
snapshot of the full documentation is stored in the SIG's webspace on 
tei-c.org ( http://www.tei-c.org/SIG/Libraries/teiinlibraries/ ).  There 
are a few pages in the TEI wiki containing notes on recommended 
revisions to the document.

While it would make sense for the SIG on Libraries to review the BP 
occasionally in light of new releases of the TEI and in response to 
community needs, only been a handful of SIG members have found time to 
contribute to the BP.  I hosted two SIG meetings this fall (in Wuerzburg 
and at the Digital Library Federation Forum in Baltimore) and informally 
fished for successors to Michelle Dalmau and me, who led development of 
the BP, but wasn't finding any.  So Michelle and I would like to 
institutionalize support for the BP's development for fear that will 
fall into neglect.

If the Council takes a role in the maintenance of this and other 
community-driven customizations, the Council can ensure coherence across 
them and attempt to recruit assistance from specialists for complex 
matters. Maintenance by the Council would help ensure (though somewhat 
indirectly) that the BP customizations are available in oxygen-tei.

However, I need to offer a few disclaimers about the BP:

a) The encoding prescribed in the BP for Level 1 does not conform to the 
TEI's abstract model because it requires a single <ab> to be the only 
child element of <div> or <div1>, which in turn is the required single 
child of <body>.  Level 2 is possibly not conferment to the abstract 
model depending on whether you think the Guidelines say that encoding of 
<p>s is mandatory.  I'm unsure about Levels 3 and 4.  So there is a 
paradox of the Council maintaining something that is a "best practice" 
yet non-conformant according to the TEI Guidelines.

b) If Council feels that materials under its stewardship must be in 
Sourceforge, the content would need to be moved there from GitHub and 
the appropriate wiki pages. This isn't a problem, but note that the idea 
of moving all TEI content out of Sourceforge into GitHub has 
occasionally been suggested.

Regardless of whether the Council takes over or contributes to 
maintenance of the BP, I would like to see the BP added to the 
appropriate section of http://www.tei-c.org/Guidelines/Customization/ . 
  Currently that webpage says to email editors at tei-c.org to request that 
a customization be added, but I'm not sure that's correct since there 
are no longer editors of the TEI.

It has been suggested that the question is actually not whether the 
Council should maintain but whether the TEI-C should maintain, and that 
this is really a decision for the Board, not Council.  However, James 
said that if the question came before the Board, he would like to 
present Council's position on this.

Sebastian has suggested that Lite, Tite, and the BP be made into a 
family of "canned schemas" that are distinct from the Exemplars and 
therefore not included in Roma (but still in oxygen-tei).  This seems 
reasonable to me.

--Kevin

From sebastian.rahtz at oucs.ox.ac.uk  Sun Mar 25 09:52:59 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Sun, 25 Mar 2012 13:52:59 +0000
Subject: [tei-council] <egXML> example
In-Reply-To: <4F6E60AC.1020202@uvic.ca>
References: <4F6CBE0A.6050307@uvic.ca>
	<Pine.LNX.4.64.1203231519030.15262@zaxxon.gpcc.itd.umich.edu>
	<5C0990DE-01B4-4C56-859B-7CD0066EF2C0@retired.ox.ac.uk>
	<CAA2irtJaayR2ejZd9O8KrvVEsvLYM_11XfwBm7uo2sewxNgM3A@mail.gmail.com>
	<4F6CDF33.5010706@uvic.ca>
	<0C8224DC-3A7D-4D6A-BC0A-4444CDF4DE0B@oucs.ox.ac.uk>
	<4F6DDF53.5000601@uvic.ca> <4F6DE773.3040904@retired.ox.ac.uk>
	<DC755EEB-B5A0-4443-BA02-B17E35B2531A@oucs.ox.ac.uk>
	<4F6E60AC.1020202@uvic.ca>
Message-ID: <21715821-AC0C-4C60-B415-B6A761B7A37A@oucs.ox.ac.uk>


On 25 Mar 2012, at 00:02, Martin Holmes wrote:

> 
> It does bring up another issue that I've been thinking about for a while, though: a single specification file contains not only its element but also any attributes which are defined on the element, and which may be unique to it. There's no way (to my knowledge) to specify that any given example is focused on the use of the element or one of its attributes. It would be helpful if there were a way to specify what an example is supposed to be exemplifying.

it's a fair point.  Back in the olden days when I was working on http://www.amazon.com/LaTeX-Graphics-Companion-The-Edition/dp/0321508920,
we tagged each example with a list of macro names (in that case) for which we wanted an entry in the index at this point. The same
technique would apply here - yes, it shows a <p>, but its not an especially interesting use of <p> worth showing people.

One could literally use index terms for the job, inside <exemplum>

But the amount of retrofitting work needed is fearsome.
--
Sebastian Rahtz    
Head of Information and Support Group, Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431

S?lo le pido a Dios
que el futuro no me sea indiferente





From kevin.s.hawkins at ultraslavonic.info  Sun Mar 25 09:53:39 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Sun, 25 Mar 2012 09:53:39 -0400
Subject: [tei-council] ticket triage
In-Reply-To: <4F663BC0.5080902@retired.ox.ac.uk>
References: <4F663BC0.5080902@retired.ox.ac.uk>
Message-ID: <4F6F2363.1080803@ultraslavonic.info>

Gang,

I have just revised tcw17 to explain the use of color coding for tickets 
(since this has been a point of confusion in the past).  I have also changed

http://purl.org/TEI/fr/3305016

from "pending" to "open" (and from green to amber) so that it now 
appears linked from tcw17.  This ticket was nearly resolved in the past, 
but a new discussion has arisen.

--Kevin

On 3/18/12 3:47 PM, Lou Burnard wrote:
> A quick look at
> http://www.tei-c.org/Activities/Council/Working/tcw17.html shows the
> following state of play...
>
> GREEN tickets (11 bugs; 5 Feature Requests)
>
> May I suggest that Council members should take a quick look initially at
> the GREEN tickets?  As far as I can tell, what needs to be done is
> fairly self evident in each case (that's the definition of GREEN, after
> all). Furthermore, each GREEN ticket (with one exception, see below) has
> been assigned to someone for action. All you need do therefore is post a
> message to the list if you disagree with the action being proposed for
> the ticket.
>
> The exception is bug 3437782. This is a ticket I created and on which
> no-one has commented so far; I am reluctant to assign it to myself and
> just do it, even though I think it should just be done. So please
> express your views on that one!
>
> AMBER tickets (18 bugs; 13 Feature requests)
>
> Several of them are on overlapping topics (e.g. we have three or four
> talking about<wit>, and more than one worrying about the use of<idno>)
> so I think we should be able to group them together and dispose of quite
> a few in Chicago. I'll have a shot at doing that (the grouping) next, in
> consultation with James when he comes back from his hols.
>
> RED tickets (4 red; 11 feature requests)
>
> Some of these are quite old (the oldest goes back to 2007) so maybe we
> should find some way of indicating topics that we are giving up on for
> the moment.
>
> Feel free, of course, to add comments on any ticket if you think the
> discussion is in need of it.

From sebastian.rahtz at oucs.ox.ac.uk  Sun Mar 25 10:19:41 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Sun, 25 Mar 2012 14:19:41 +0000
Subject: [tei-council] summary of Council taking on a role in
 maintenance of Best Practices for TEI in Libraries
In-Reply-To: <4F6E90E0.9060005@ultraslavonic.info>
References: <4F40307E.6080807@ultraslavonic.info>
	<EBB790FD-70DA-40F9-BFF0-7C84F3E173B9@oucs.ox.ac.uk>
	<4F410CF6.4040804@ultraslavonic.info>
	<EBF08744-1474-4712-A41A-10D2DFF1042D@oucs.ox.ac.uk>
	<4F415AED.6000100@oucs.ox.ac.uk>
	<1f2b0fcc-944d-46d7-ad1f-53ff54d886d8@HUB01.ad.oak.ox.ac.uk>
	<4F6E90E0.9060005@ultraslavonic.info>
Message-ID: <2B77E136-DAEF-4CFE-A013-827678785CA9@oucs.ox.ac.uk>

My fundamental problem with this is:

>  I hosted two SIG meetings this fall (in Wuerzburg 
> and at the Digital Library Federation Forum in Baltimore) and informally 
> fished for successors to Michelle Dalmau and me, who led development of 
> the BP, but wasn't finding any.  So Michelle and I would like to 
> institutionalize support for the BP's development for fear that will 
> fall into neglect.


because if the community of users does not interested in maintaining the BP,
doesn't that suggest that it is not needed? If we have a BP which
the library community has lost interested in, then just let it die; if
the library community is all behind it, then why would they not look after it?

This seems like the very essence of a SIG, that it develops
and maintains the specialist knowledge and experience that
the general purpose Council, changing every few years, cannot
reliably have.  if the Council maintained the BP, it would presumably
expect to make the decisions about it, but on what basis?

One of the strengths of the BP is that it is NOT dictated by the TEI-C
from above, but reflects real practice (well, I assume thats what it does...).

I think the mess with Tite, whereby we have the tension between
TEI-C and Apex about ownership and changes, shows we should
_not_ take on BP. 

But others may have the opposite opinions :-}

--
Sebastian Rahtz    
Head of Information and Support Group, Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431

S?lo le pido a Dios
que el futuro no me sea indiferente





From lou.burnard at retired.ox.ac.uk  Sun Mar 25 15:12:29 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Sun, 25 Mar 2012 20:12:29 +0100
Subject: [tei-council] open tickets : proposed  groupings
Message-ID: <4F6F6E1D.6060407@retired.ox.ac.uk>

In an attempt to help structure the agenda for the Chicago meeting,
I've now grouped together currently open AMBER and RED tickets under
approx 9 headings as follows. Some of these are quite specialised
(e.g. the crit app tickets); some are quite varied (e.g. New
proposals). In the past we've divided into small groups meeting in
parallel to thrash out proposals aimed at dealing with several tickets
at once, and I think that would probably work equally well this time,
unless our chair has a better proposal.

-----A: Obscurities in crit app------
http://purl.org/tei/bugs/3497369  TEI Guidelines, p. 396 - XPath
http://purl.org/tei/bugs/3497356  TEI Guidelines, p. 394 - external
apparatus
http://purl.org/tei/bugs/3496998  TEI Guidelines, p. 393 - <lacunaEnd>
http://purl.org/tei/bugs/3496958  Guidelines, p. 384 - number of <rdg>
in <app>
http://purl.org/tei/bugs/3496954  Guidelines, p. 390-3 - "where no
witness exists"
http://purl.org/tei/bugs/3496951  Guidelines, p. 389-2 - @wit on <rdgGrp>
http://purl.org/tei/bugs/3496949  Guidelines, p. 388 -
"<wit>[unattested]</wit>"

-------B: Policy/style issues-------
http://purl.org/tei/bugs/3454814  Prune comments from TEI source
http://purl.org/tei/bugs/3454803  Review of language, script and region
code recommendations
http://purl.org/tei/bugs/3432216  i18n revision due
http://purl.org/tei/bugs/3223636  @xml:space vs. CDATA for blocks of code
http://purl.org/tei/bugs/3393781 @version in examples

-----C: Misc content model queries----
http://purl.org/tei/bugs/3475748  Inaccurate example in dictionary chapter
http://purl.org/tei/bugs/3440771  Multiple <geo> tags in <location>
http://purl.org/tei/bugs/3439980  content model of <signed>
http://purl.org/tei/bugs/3458222  <choice> as child of <pc>
http://purl.org/tei/bugs/3500088  French example of <metDecl> seems wrong

-----D: Usage of magic tokens--------
http://purl.org/tei/bugs/3480650 @cRef is a mess
http://purl.org/tei/bugs/3413346  Deprecation of data.key and data.word
attributes

----E: New proposals-------
http://purl.org/tei/fr/3504690  floatingDiv proposal
http://purl.org/tei/fr/3490054  Split off 'Dates and Times' to new TEI
chapter
http://purl.org/tei/fr/3423686  an <object> element
http://purl.org/tei/fr/3475007 New section on encoding text directionality
http://purl.org/tei/fr/3288293 creat @refLang, add it to att.pointing
http://purl.org/tei/fr/2724997 Cater for audio/video facsimile
http://purl.org/tei/fr/2507305 Alignment and documentation of sound files

----F: Usage of idno-------
http://purl.org/tei/fr/3439587  Problems introduced by content models of
bibl and imprint.
http://purl.org/tei/fr/3500566  revise handling of ISBNs in <idno>
http://purl.org/tei/fr/3497079  clarify and rationalize encoding of
pagination in bibliograp
http://purl.org/tei/fr/3440977  Add idno to person (maybe also place)
http://purl.org/tei/fr/2493417  <idno> coverage
http://purl.org/tei/fr/3480057 Allow <idno> inside <monogr> without
restrictions
----G: Class tweaks--------
http://purl.org/tei/fr/3496494  make attributes from and to (as
pointers) part of a class
http://purl.org/tei/fr/3495987  members of model.respLike should be
members of att.declarabl
http://purl.org/tei/fr/2834511  Add more elements to att.spanning with
schematron constraint
http://purl.org/tei/fr/3291540 att.editLike should not bring
att.dimensions and att.ranging
http://purl.org/tei/fr/3284816  att.canonical for model.persTraitLike

----H: Minor content model tweaks--------
http://purl.org/tei/fr/3434990  require minimum of two lines or lg inside lg
http://purl.org/tei/fr/3305016  make <graphic> available within <table>
and ...
http://purl.org/tei/fr/3416130 Allow certainty etc. inside milestoneLike
elements
http://purl.org/tei/bugs/337683 macro.paraContent out of place in <gram>
etc [cf <u>
discussion]

---J: ODD related-----
http://purl.org/tei/fr/3415801  Allow modification of attributes
belonging to a class
http://purl.org/tei/fr/3118435  classes in interleave mode and
cardinality membership.
http://purl.org/tei/fr/3426828 more coherence on mode attribute on
classes and attList
http://purl.org/tei/fr/1650195 Need Header element to reference or embed
schema/odd

From James.Cummings at oucs.ox.ac.uk  Tue Mar 27 08:40:01 2012
From: James.Cummings at oucs.ox.ac.uk (James Cummings)
Date: Tue, 27 Mar 2012 13:40:01 +0100
Subject: [tei-council] <egXML> example
In-Reply-To: <21715821-AC0C-4C60-B415-B6A761B7A37A@oucs.ox.ac.uk>
References: <4F6CBE0A.6050307@uvic.ca>	<Pine.LNX.4.64.1203231519030.15262@zaxxon.gpcc.itd.umich.edu>	<5C0990DE-01B4-4C56-859B-7CD0066EF2C0@retired.ox.ac.uk>	<CAA2irtJaayR2ejZd9O8KrvVEsvLYM_11XfwBm7uo2sewxNgM3A@mail.gmail.com>	<4F6CDF33.5010706@uvic.ca>	<0C8224DC-3A7D-4D6A-BC0A-4444CDF4DE0B@oucs.ox.ac.uk>	<4F6DDF53.5000601@uvic.ca>
	<4F6DE773.3040904@retired.ox.ac.uk>	<DC755EEB-B5A0-4443-BA02-B17E35B2531A@oucs.ox.ac.uk>	<4F6E60AC.1020202@uvic.ca>
	<21715821-AC0C-4C60-B415-B6A761B7A37A@oucs.ox.ac.uk>
Message-ID: <4F71B521.8040904@oucs.ox.ac.uk>

On 25/03/12 14:52, Sebastian Rahtz wrote:
> On 25 Mar 2012, at 00:02, Martin Holmes wrote:
> it's a fair point.  Back in the olden days when I was working on http://www.amazon.com/LaTeX-Graphics-Companion-The-Edition/dp/0321508920,
> we tagged each example with a list of macro names (in that case) for which we wanted an entry in the index at this point. The same
> technique would apply here - yes, it shows a<p>, but its not an especially interesting use of<p>  worth showing people.
> One could literally use index terms for the job, inside<exemplum>
> But the amount of retrofitting work needed is fearsome.

There are all sorts of ways we could be making better use of our 
examples.  I had already added TEI Examples to the agenda for the 
face2face, so we should at least have a quick discussion about it 
then.  I do think it is something we need to investigate a bit 
first and come to a decision about the best way to organise, 
re-use and process our examples rather than just bolting on more 
workarounds.  (But use of index terms might indeed be a good way 
to do this.)

-James

-- 
Dr James Cummings, InfoDev,
Computing Services, University of Oxford

From bansp at o2.pl  Tue Mar 27 10:00:49 2012
From: bansp at o2.pl (=?ISO-8859-2?Q?Piotr_Ba=F1ski?=)
Date: Tue, 27 Mar 2012 16:00:49 +0200
Subject: [tei-council] summary of Council taking on a role in
 maintenance of Best Practices for TEI in Libraries
In-Reply-To: <2B77E136-DAEF-4CFE-A013-827678785CA9@oucs.ox.ac.uk>
References: <4F40307E.6080807@ultraslavonic.info>	<EBB790FD-70DA-40F9-BFF0-7C84F3E173B9@oucs.ox.ac.uk>	<4F410CF6.4040804@ultraslavonic.info>	<EBF08744-1474-4712-A41A-10D2DFF1042D@oucs.ox.ac.uk>	<4F415AED.6000100@oucs.ox.ac.uk>	<1f2b0fcc-944d-46d7-ad1f-53ff54d886d8@HUB01.ad.oak.ox.ac.uk>	<4F6E90E0.9060005@ultraslavonic.info>
	<2B77E136-DAEF-4CFE-A013-827678785CA9@oucs.ox.ac.uk>
Message-ID: <4F71C811.8080908@o2.pl>

I think Sebastian's points are very strong.

An admittedly extreme reading of Kevin's post is: "no one in the SIG
cares, so let's push this onto the Council". I know you didn't mean it
that way, but that would be the net effect.

SIGs are the creatures of the Council and/or the Board, depending on
their nature (I'm not talking about the formal relationship but rather
the factual relationship). In this case, I would think, as an outsider
to the Libraries SIG, that part of its raison d'etre was/is the
maintenance of the BP doc, in sync with the Council (to be sure: the
syncing is the SIG's responsibility, I'd hope). If the SIG doesn't want
to do that, then what is the SIG for?

Another question is: maybe the SIG doesn't *need* to modify the BP for
now because it's acceptable as it is? So maybe it's not a general lack
of interest, but just a lack of interest in fixing what ain't broke? (I
realise that these may be naive questions, I stress that I'm asking them
as an outsider.)

Again, to follow Kevin's suggestion ad absurdum (again begging
forgiveness for the rhetorical device):

> If the Council takes a role in the maintenance of this and other 
> community-driven customizations, the Council can ensure coherence across 
> them and attempt to recruit assistance from specialists for complex 
> matters.

if the Council accepts this role, the Council may eventually choke on
that. Unless we're lucky to make this part of our jobs, we're all taking
time away from our jobs when we can (I'm an embarrassed example that
sometimes we just can't), to push the cart forward. Getting busy with
syncing all specialist customizations would saturate the time available
to the Council members for Council work, I'm afraid. I think
de-centralization (as Sebastian notes), i.e. making the SIG responsible
for syncing with the Council, is not just the right way, but possibly
the only way to handle this coherently across-the-board.

Once again, forgive the possible naivety in my direct questions about
the Libraries SIG, they are not meant as an attack of any sort, rather
as a way to shed some light at the possible end of the proposed path, so
to say.

Best,

  Piotr


On 25/03/12 16:19, Sebastian Rahtz wrote:
> My fundamental problem with this is:
> 
>>  I hosted two SIG meetings this fall (in Wuerzburg 
>> and at the Digital Library Federation Forum in Baltimore) and informally 
>> fished for successors to Michelle Dalmau and me, who led development of 
>> the BP, but wasn't finding any.  So Michelle and I would like to 
>> institutionalize support for the BP's development for fear that will 
>> fall into neglect.
> 
> 
> because if the community of users does not interested in maintaining the BP,
> doesn't that suggest that it is not needed? If we have a BP which
> the library community has lost interested in, then just let it die; if
> the library community is all behind it, then why would they not look after it?
> 
> This seems like the very essence of a SIG, that it develops
> and maintains the specialist knowledge and experience that
> the general purpose Council, changing every few years, cannot
> reliably have.  if the Council maintained the BP, it would presumably
> expect to make the decisions about it, but on what basis?
> 
> One of the strengths of the BP is that it is NOT dictated by the TEI-C
> from above, but reflects real practice (well, I assume thats what it does...).
> 
> I think the mess with Tite, whereby we have the tension between
> TEI-C and Apex about ownership and changes, shows we should
> _not_ take on BP. 
> 
> But others may have the opposite opinions :-}
> 
> --
> Sebastian Rahtz    
> Head of Information and Support Group, Oxford University Computing Services
> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
> 
> S?lo le pido a Dios
> que el futuro no me sea indiferente
> 
> 
> 
> 


From syeates at gmail.com  Tue Mar 27 16:14:36 2012
From: syeates at gmail.com (Stuart A. Yeates)
Date: Wed, 28 Mar 2012 09:14:36 +1300
Subject: [tei-council] summary of Council taking on a role in
 maintenance of Best Practices for TEI in Libraries
In-Reply-To: <4F71C811.8080908@o2.pl>
References: <4F40307E.6080807@ultraslavonic.info>
	<EBB790FD-70DA-40F9-BFF0-7C84F3E173B9@oucs.ox.ac.uk>
	<4F410CF6.4040804@ultraslavonic.info>
	<EBF08744-1474-4712-A41A-10D2DFF1042D@oucs.ox.ac.uk>
	<4F415AED.6000100@oucs.ox.ac.uk>
	<1f2b0fcc-944d-46d7-ad1f-53ff54d886d8@HUB01.ad.oak.ox.ac.uk>
	<4F6E90E0.9060005@ultraslavonic.info>
	<2B77E136-DAEF-4CFE-A013-827678785CA9@oucs.ox.ac.uk>
	<4F71C811.8080908@o2.pl>
Message-ID: <CAC_Lu0Zvw70pXVUC7=3hZKXFvbdT8g2qLVceuRqcaBc-JEA9VQ@mail.gmail.com>

I think the key point here is what is meant by the term 'maintenance'

If 'maintenance' means hosting the documentation, schemas, etc;
providing technical methods for community members to make minor
corrections (typos, links to discussions for clarifications, etc);
migrating schemas, etc across different versions of tools (roma, etc);
then that seems like something the council might take on.

If 'maintenance' means any more than this, it seems like the kind of
thing that we should not.

cheers
stuart

From kevin.s.hawkins at ultraslavonic.info  Tue Mar 27 20:04:23 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Tue, 27 Mar 2012 20:04:23 -0400
Subject: [tei-council] summary of Council taking on a role in
 maintenance of Best Practices for TEI in Libraries
In-Reply-To: <4F71C811.8080908@o2.pl>
References: <4F40307E.6080807@ultraslavonic.info>	<EBB790FD-70DA-40F9-BFF0-7C84F3E173B9@oucs.ox.ac.uk>	<4F410CF6.4040804@ultraslavonic.info>	<EBF08744-1474-4712-A41A-10D2DFF1042D@oucs.ox.ac.uk>	<4F415AED.6000100@oucs.ox.ac.uk>	<1f2b0fcc-944d-46d7-ad1f-53ff54d886d8@HUB01.ad.oak.ox.ac.uk>	<4F6E90E0.9060005@ultraslavonic.info>
	<2B77E136-DAEF-4CFE-A013-827678785CA9@oucs.ox.ac.uk>
	<4F71C811.8080908@o2.pl>
Message-ID: <4F725587.7040303@ultraslavonic.info>

Thank you all for your thoughtful responses so far.

On this point ...

On 3/27/12 10:00 AM, Piotr Ba?ski wrote:
> Another question is: maybe the SIG doesn't *need* to modify the BP for
> now because it's acceptable as it is? So maybe it's not a general lack
> of interest, but just a lack of interest in fixing what ain't broke? (I
> realise that these may be naive questions, I stress that I'm asking them
> as an outsider.)

... I can say that we've already accumulated quite a list of things to 
change:

http://wiki.tei-c.org/index.php/Future_changes_to_Best_Practices_for_TEI_in_Libraries

Some were noted between April 2008 (when we started work on the BP) and 
October 2011 (when we released it) but set aside because the problems 
were too complicated or because the solution depended on work that was 
underway in the TEI community as a whole.  Others have arisen because of 
changes that Council has made to P5 since this fall.

--Kevin

From sebastian.rahtz at oucs.ox.ac.uk  Wed Mar 28 08:32:22 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Wed, 28 Mar 2012 12:32:22 +0000
Subject: [tei-council] summary of Council taking on a role in
 maintenance of Best Practices for TEI in Libraries
In-Reply-To: <4F725587.7040303@ultraslavonic.info>
References: <4F40307E.6080807@ultraslavonic.info>
	<EBB790FD-70DA-40F9-BFF0-7C84F3E173B9@oucs.ox.ac.uk>
	<4F410CF6.4040804@ultraslavonic.info>
	<EBF08744-1474-4712-A41A-10D2DFF1042D@oucs.ox.ac.uk>
	<4F415AED.6000100@oucs.ox.ac.uk>
	<1f2b0fcc-944d-46d7-ad1f-53ff54d886d8@HUB01.ad.oak.ox.ac.uk>
	<4F6E90E0.9060005@ultraslavonic.info>
	<2B77E136-DAEF-4CFE-A013-827678785CA9@oucs.ox.ac.uk>
	<4F71C811.8080908@o2.pl> <4F725587.7040303@ultraslavonic.info>
Message-ID: <AA9987A3-CDE7-46B9-BF46-7C8906E83F66@oucs.ox.ac.uk>


On 28 Mar 2012, at 01:04, Kevin Hawkins wrote:
> ... I can say that we've already accumulated quite a list of things to 
> change:
> 
> http://wiki.tei-c.org/index.php/Future_changes_to_Best_Practices_for_TEI_in_Libraries
> 

This intensifies my concern. It is an interesting and fairly complex list,
to resolve which needs real work. The obvious solution would be to
form a subcommittee to examine the issues in details, and work out
what to do; and that subcommittee would pull in external experts,
and then waddya know, we'd have a SIG :-}

Comes back to the same problem. If there was someone here
on Council who was the natural lead to revise the BP,
they'd already have volunteered. Handing the job to the committee-as-a-whole
is just not going to work.

One way forward could be to stop treating TEI in libraries
as some sort of special case, and merge the whole BP thing
into the Guidelines for everyone. i.e. make the Guidelines
more prescriptive across the board than they already are.
So effectively the current BP is the draft of new sections
of the Guidelines.

It would arguably be a good use of money (had we any) to
pay someone to work on this for 3-6 months.
--
Stormageddon Rahtz      
Head of Information and Support Group
Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431

S?lo le pido a Dios
que el futuro no me sea indiferente


From kevin.s.hawkins at ultraslavonic.info  Mon Apr  2 21:09:17 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Mon, 02 Apr 2012 21:09:17 -0400
Subject: [tei-council] summary of Council taking on a role in
 maintenance of Best Practices for TEI in Libraries
In-Reply-To: <AA9987A3-CDE7-46B9-BF46-7C8906E83F66@oucs.ox.ac.uk>
References: <4F40307E.6080807@ultraslavonic.info>
	<EBB790FD-70DA-40F9-BFF0-7C84F3E173B9@oucs.ox.ac.uk>
	<4F410CF6.4040804@ultraslavonic.info>
	<EBF08744-1474-4712-A41A-10D2DFF1042D@oucs.ox.ac.uk>
	<4F415AED.6000100@oucs.ox.ac.uk>
	<1f2b0fcc-944d-46d7-ad1f-53ff54d886d8@HUB01.ad.oak.ox.ac.uk>
	<4F6E90E0.9060005@ultraslavonic.info>
	<2B77E136-DAEF-4CFE-A013-827678785CA9@oucs.ox.ac.uk>
	<4F71C811.8080908@o2.pl> <4F725587.7040303@ultraslavonic.info>
	<AA9987A3-CDE7-46B9-BF46-7C8906E83F66@oucs.ox.ac.uk>
Message-ID: <4F7A4DBD.6040006@ultraslavonic.info>

On 3/28/12 8:32 AM, Sebastian Rahtz wrote:
> One way forward could be to stop treating TEI in libraries
> as some sort of special case, and merge the whole BP thing
> into the Guidelines for everyone. i.e. make the Guidelines
> more prescriptive across the board than they already are.
> So effectively the current BP is the draft of new sections
> of the Guidelines.
>
> It would arguably be a good use of money (had we any) to
> pay someone to work on this for 3-6 months.

This is an intriguing idea and one that jives with longstanding 
complaints by some that the Guidelines don't foster as much interchange 
as claimed.  But it's also controversial since others feel that the 
Guidelines should allow for certain types of variation.  Even with the 
BP, which had as a principle that we should choose a single solution 
when possible, stalemates left us with alternative ways of doing certain 
things.

Perhaps in Ann Arbor we can get a sense of which parts of the BP, if 
any, Council is likely to support assimilating into the Guidelines.  I 
wouldn't want to waste a grant applicaiton and months of work if the 
whole thing is dead on arrival.

From kevin.s.hawkins at ultraslavonic.info  Sat Apr  7 22:42:35 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Sat, 07 Apr 2012 22:42:35 -0400
Subject: [tei-council] namespaces and customization
In-Reply-To: <9B23E49F-89F9-4579-A76A-4FF43F1E28C2@oucs.ox.ac.uk>
References: <4EEE7722.7090407@ultraslavonic.info>	<4EEEAF50.6080902@uvic.ca>
	<4EEEFCA9.4070007@oucs.ox.ac.uk>
	<9CDC2137-B222-4CAD-8AB5-9266A4CE050E@oucs.ox.ac.uk>
	<4F039DA1.6000503@ultraslavonic.info>
	<07238135-C143-48A2-9A26-CA7586D7F090@oucs.ox.ac.uk>
	<E5EA2A75-8908-42C6-8422-F32824FBFCB6@oucs.ox.ac.uk>
	<4F0434F6.9080904@retired.ox.ac.uk>
	<55D02CD2-121F-467E-9F9E-F3C29FE2FD97@oucs.ox.ac.uk>
	<4F05FD9E.7080102@retired.ox.ac.uk>
	<9B23E49F-89F9-4579-A76A-4FF43F1E28C2@oucs.ox.ac.uk>
Message-ID: <4F80FB1B.5070806@ultraslavonic.info>

On 1/5/12 2:59 PM, Sebastian Rahtz wrote:
> On 5 Jan 2012, at 19:44, Lou Burnard wrote:
>
>>
>> Agree on that. But it *is* misleading -- unless you now also claim that
>> the flopsy example (in #MDNS) is wrong, we have a situation where @ns
>> means one thing when @mode="add" and another, quite different, thing
>> when it doesnt.
>
> tricky. I don't see an easy way to resolve that.
>
> but I take consolation from the fact that no-one has
> noticed the problem so far as we know.

I take no consolation and have therefore filed a bug report:

http://purl.org/TEI/bug/3515805

From kevin.s.hawkins at ultraslavonic.info  Sat Apr  7 22:56:50 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Sat, 07 Apr 2012 22:56:50 -0400
Subject: [tei-council] namespaces and customization
In-Reply-To: <55D02CD2-121F-467E-9F9E-F3C29FE2FD97@oucs.ox.ac.uk>
References: <4EEE7722.7090407@ultraslavonic.info>	<4EEEAF50.6080902@uvic.ca>
	<4EEEFCA9.4070007@oucs.ox.ac.uk>
	<9CDC2137-B222-4CAD-8AB5-9266A4CE050E@oucs.ox.ac.uk>
	<4F039DA1.6000503@ultraslavonic.info>
	<07238135-C143-48A2-9A26-CA7586D7F090@oucs.ox.ac.uk>
	<E5EA2A75-8908-42C6-8422-F32824FBFCB6@oucs.ox.ac.uk>
	<4F0434F6.9080904@retired.ox.ac.uk>
	<55D02CD2-121F-467E-9F9E-F3C29FE2FD97@oucs.ox.ac.uk>
Message-ID: <4F80FE72.40007@ultraslavonic.info>

My problem wasn't that the Guidelines didn't point out that the example 
in section 23.2.1.5 would make this an unclean customization but rather 
that the role of namespaces as a whole is a bit unclear.  I have just 
posted a bug report:

http://purl.org/TEI/bug/3515806

and also mentioned on TEI-L, where I began this discussion.

(Just tying up loose ends here for anyone digging through the archives 
some day.)

On 1/4/12 7:08 AM, Sebastian Rahtz wrote:
> which of us wrote that passage which confused Kevin? it talks
> about how to add an element to att.typed as an example, but
> fails to point out that this makes the doc non-TEI (or so some
> of us claim).

From kevin.s.hawkins at ultraslavonic.info  Tue Apr 10 12:08:06 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Tue, 10 Apr 2012 12:08:06 -0400
Subject: [tei-council] sunday hack session
Message-ID: <4F845AE6.7010509@ultraslavonic.info>

All,

I'd like to have a sense of how early I should show up on Sunday for the 
hack session, and and how late those of us there should stay to meet any 
late arrivals.  If you're planning to come, please let me know.  Well, 
let us all know so no one thinks they're going to have to spend an 
awkward afternoon alone with me.  :)

An update on logistics will probably be coming from Becky this week, but 
let me say now that the Sunday hack session, just like the working 
meetings on Monday through Wednesday, will be in the Shapiro Library on 
U-M's central campus.  This is next door to the Hatcher Library, where 
the 2009 conference was held.  The folks at the hotel reception desk can 
tell you how to find it.

We'll be in the Turkish-American Friendship Room, which is on the fourth 
floor.  Follow the signs once you're in the building.  Some of you will 
recall this room as one that was used for various meetings held before, 
during, and after the 2009 conference.

See you soon!

From gabriel.bodard at kcl.ac.uk  Tue Apr 10 13:28:14 2012
From: gabriel.bodard at kcl.ac.uk (Gabriel BODARD)
Date: Tue, 10 Apr 2012 18:28:14 +0100
Subject: [tei-council] No show [was Re: sunday hack session]
In-Reply-To: <4F845AE6.7010509@ultraslavonic.info>
References: <4F845AE6.7010509@ultraslavonic.info>
Message-ID: <4F846DAE.5080304@kcl.ac.uk>

Dear all,

As James and Becky already know, I'm not going to make it to Ann Arbor 
in the flesh next week, but I will be attending all day Monday-Wednesday 
as a disembodied presence via Skype and IRC, and I've set aside those 
three days to work on odd/schema/guidelines related things.

Very sorry that I won't be seeing you all in person there (especially 
those of you I've not met yet), but looking forward to the working 
sessions nevertheless.

Cheers,

Gabby

On 10/04/2012 17:08, Kevin Hawkins wrote:
> All,
>
> I'd like to have a sense of how early I should show up on Sunday for the
> hack session, and and how late those of us there should stay to meet any
> late arrivals.  If you're planning to come, please let me know.  Well,
> let us all know so no one thinks they're going to have to spend an
> awkward afternoon alone with me.  :)
>
> An update on logistics will probably be coming from Becky this week, but
> let me say now that the Sunday hack session, just like the working
> meetings on Monday through Wednesday, will be in the Shapiro Library on
> U-M's central campus.  This is next door to the Hatcher Library, where
> the 2009 conference was held.  The folks at the hotel reception desk can
> tell you how to find it.
>
> We'll be in the Turkish-American Friendship Room, which is on the fourth
> floor.  Follow the signs once you're in the building.  Some of you will
> recall this room as one that was used for various meetings held before,
> during, and after the 2009 conference.
>
> See you soon!

-- 
Dr Gabriel BODARD
(Research Associate in Digital Epigraphy)

Department of Digital Humanities
King's College London
26-29 Drury Lane
London WC2B 5RL

Email: gabriel.bodard at kcl.ac.uk
Tel: +44 (0)20 7848 1388
Fax: +44 (0)20 7848 2980

http://www.digitalclassicist.org/
http://www.currentepigraphy.org/

From mholmes at uvic.ca  Tue Apr 10 13:29:09 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Tue, 10 Apr 2012 10:29:09 -0700
Subject: [tei-council] sunday hack session
In-Reply-To: <4F845AE6.7010509@ultraslavonic.info>
References: <4F845AE6.7010509@ultraslavonic.info>
Message-ID: <4F846DE5.30606@uvic.ca>

I won't get there till the evening, unfortunately. But I'll be hungry 
when I do get there -- any plan for food on Sunday night?

Cheers,
Martin

On 12-04-10 09:08 AM, Kevin Hawkins wrote:
> All,
>
> I'd like to have a sense of how early I should show up on Sunday for the
> hack session, and and how late those of us there should stay to meet any
> late arrivals.  If you're planning to come, please let me know.  Well,
> let us all know so no one thinks they're going to have to spend an
> awkward afternoon alone with me.  :)
>
> An update on logistics will probably be coming from Becky this week, but
> let me say now that the Sunday hack session, just like the working
> meetings on Monday through Wednesday, will be in the Shapiro Library on
> U-M's central campus.  This is next door to the Hatcher Library, where
> the 2009 conference was held.  The folks at the hotel reception desk can
> tell you how to find it.
>
> We'll be in the Turkish-American Friendship Room, which is on the fourth
> floor.  Follow the signs once you're in the building.  Some of you will
> recall this room as one that was used for various meetings held before,
> during, and after the 2009 conference.
>
> See you soon!

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From sebastian.rahtz at oucs.ox.ac.uk  Tue Apr 10 13:37:35 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Tue, 10 Apr 2012 17:37:35 +0000
Subject: [tei-council] sunday hack session
In-Reply-To: <4F845AE6.7010509@ultraslavonic.info>
References: <4F845AE6.7010509@ultraslavonic.info>
Message-ID: <D957117C-E9E0-43A0-A1C1-BC2A37DDB3C5@oucs.ox.ac.uk>

I am up for Sunday working. Can anyone remind me of something I said I'd make work on that day?
I think there is some problem of ODD processing in a pending ticket which I said was doable
with some concentration - was it the idea of redeclaration of attributes (i.e. datatypes) in the P5 source itself?


Sebastian

From sebastian.rahtz at oucs.ox.ac.uk  Tue Apr 10 13:38:46 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Tue, 10 Apr 2012 17:38:46 +0000
Subject: [tei-council] sunday hack session
In-Reply-To: <4F845AE6.7010509@ultraslavonic.info>
References: <4F845AE6.7010509@ultraslavonic.info>
Message-ID: <32DC54C3-C98F-4A3F-A926-DB53171EFC4E@oucs.ox.ac.uk>

PS

> 
> I'd like to have a sense of how early I should show up on Sunday for the 
> hack session, and and how late those of us there should stay to meet any 
> late arrivals. 

I'm thinking 9.30 am?

Sebastian

From kevin.s.hawkins at ultraslavonic.info  Tue Apr 10 13:58:51 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Tue, 10 Apr 2012 13:58:51 -0400
Subject: [tei-council] sunday hack session
In-Reply-To: <32DC54C3-C98F-4A3F-A926-DB53171EFC4E@oucs.ox.ac.uk>
References: <4F845AE6.7010509@ultraslavonic.info>
	<32DC54C3-C98F-4A3F-A926-DB53171EFC4E@oucs.ox.ac.uk>
Message-ID: <4F8474DB.5070204@ultraslavonic.info>

Oh, wow!  The building only opens at 10 a.m. on Sundays, so we can't 
begin earlier than then.  I could meet at 10 a.m. to open the room for 
Sebastian at that time but might then leave for brunch with friends 
before returning in the afternoon.  (Planning my social calendar got me 
thinking about this.)

In any case, you all should have my mobile phone number in case you're 
trying to meet me: +1 734 255 7458.  Note that I can only receive text 
messages from non-US carriers listed at:

http://businessportals.verizonwireless.com/international/Text_Messaging/index.html

--Kevin

On 4/10/2012 1:38 PM, Sebastian Rahtz wrote:
> PS
>
>>
>> I'd like to have a sense of how early I should show up on Sunday for the
>> hack session, and and how late those of us there should stay to meet any
>> late arrivals.
>
> I'm thinking 9.30 am?
>
> Sebastian

From sebastian.rahtz at oucs.ox.ac.uk  Tue Apr 10 14:08:14 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Tue, 10 Apr 2012 18:08:14 +0000
Subject: [tei-council] sunday hack session
In-Reply-To: <4F8474DB.5070204@ultraslavonic.info>
References: <4F845AE6.7010509@ultraslavonic.info>
	<32DC54C3-C98F-4A3F-A926-DB53171EFC4E@oucs.ox.ac.uk>
	<4F8474DB.5070204@ultraslavonic.info>
Message-ID: <166F1EC3-CFAE-44A1-936C-D679AB9486AA@oucs.ox.ac.uk>


On 10 Apr 2012, at 18:58, Kevin Hawkins wrote:

> Oh, wow!  The building only opens at 10 a.m. on Sundays, so we can't 
> begin earlier than then.  I could meet at 10 a.m. to open the room for 
> Sebastian at that time but might then leave for brunch with friends 
> before returning in the afternoon.  

10am is fine :-} 

can you comment on food and drink around that place during the day? is this a god-fearing, everything-closed, sort of place?

Sebastian

From lou.burnard at retired.ox.ac.uk  Tue Apr 10 15:45:34 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Tue, 10 Apr 2012 19:45:34 +0000
Subject: [tei-council] sunday hack session
In-Reply-To: <166F1EC3-CFAE-44A1-936C-D679AB9486AA@oucs.ox.ac.uk>
References: <4F845AE6.7010509@ultraslavonic.info>
	<32DC54C3-C98F-4A3F-A926-DB53171EFC4E@oucs.ox.ac.uk>
	<4F8474DB.5070204@ultraslavonic.info>,
	<166F1EC3-CFAE-44A1-936C-D679AB9486AA@oucs.ox.ac.uk>
Message-ID: <5149f753-4ce9-44fb-9dbf-1298e4344f28@HUB04.ad.oak.ox.ac.uk>

>From memory its a short walk to a typical street of campus restaurants. I will be arriving sat pm so happy to research the options.

Sent from my HTC

----- Reply message -----
From: "Sebastian Rahtz" <sebastian.rahtz at oucs.ox.ac.uk>
To: "Kevin Hawkins" <kevin.s.hawkins at ultraslavonic.info>
Cc: "TEI Council" <tei-council at lists.village.Virginia.EDU>
Subject: [tei-council] sunday hack session
Date: Tue, Apr 10, 2012 19:08




On 10 Apr 2012, at 18:58, Kevin Hawkins wrote:

> Oh, wow!  The building only opens at 10 a.m. on Sundays, so we can't
> begin earlier than then.  I could meet at 10 a.m. to open the room for
> Sebastian at that time but might then leave for brunch with friends
> before returning in the afternoon.

10am is fine :-}

can you comment on food and drink around that place during the day? is this a god-fearing, everything-closed, sort of place?

Sebastian
--
tei-council mailing list
tei-council at lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

PLEASE NOTE: postings to this list are publicly archived

From kevin.s.hawkins at ultraslavonic.info  Tue Apr 10 15:50:43 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Tue, 10 Apr 2012 15:50:43 -0400
Subject: [tei-council] sunday hack session
In-Reply-To: <166F1EC3-CFAE-44A1-936C-D679AB9486AA@oucs.ox.ac.uk>
References: <4F845AE6.7010509@ultraslavonic.info>
	<32DC54C3-C98F-4A3F-A926-DB53171EFC4E@oucs.ox.ac.uk>
	<4F8474DB.5070204@ultraslavonic.info>
	<166F1EC3-CFAE-44A1-936C-D679AB9486AA@oucs.ox.ac.uk>
Message-ID: <4F848F13.4090204@ultraslavonic.info>

On 4/10/2012 2:08 PM, Sebastian Rahtz wrote:
> 10am is fine :-}

Good, see you there.

> can you comment on food and drink around that place during the day? is this a god-fearing, everything-closed, sort of place?

Plenty of options within a short walk.

From kevin.s.hawkins at ultraslavonic.info  Tue Apr 10 15:53:42 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Tue, 10 Apr 2012 15:53:42 -0400
Subject: [tei-council] sunday hack session
In-Reply-To: <D957117C-E9E0-43A0-A1C1-BC2A37DDB3C5@oucs.ox.ac.uk>
References: <4F845AE6.7010509@ultraslavonic.info>
	<D957117C-E9E0-43A0-A1C1-BC2A37DDB3C5@oucs.ox.ac.uk>
Message-ID: <4F848FC6.2050704@ultraslavonic.info>

The only thing I find in my email archive that Sebastian has suggested 
is to write roma2 if we get bored.  I've started a list of possibilities:

http://wiki.tei-c.org/index.php/Council#Sunday_15_April_10:00-.3F

On 4/10/2012 1:37 PM, Sebastian Rahtz wrote:
> I am up for Sunday working. Can anyone remind me of something I said I'd make work on that day?
> I think there is some problem of ODD processing in a pending ticket which I said was doable
> with some concentration - was it the idea of redeclaration of attributes (i.e. datatypes) in the P5 source itself?
>
>
> Sebastian

From kevin.s.hawkins at ultraslavonic.info  Tue Apr 10 15:59:19 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Tue, 10 Apr 2012 15:59:19 -0400
Subject: [tei-council] sunday hack session
In-Reply-To: <4F846DE5.30606@uvic.ca>
References: <4F845AE6.7010509@ultraslavonic.info> <4F846DE5.30606@uvic.ca>
Message-ID: <4F849117.2090700@ultraslavonic.info>

I suggest that those who are in town on Sunday self-organize at the 
hackathon.  So you could come to the meeting room to find us or give me 
a call to figure out where we are at that point.

On 4/10/2012 1:29 PM, Martin Holmes wrote:
> I won't get there till the evening, unfortunately. But I'll be hungry
> when I do get there -- any plan for food on Sunday night?
>
> Cheers,
> Martin
>
> On 12-04-10 09:08 AM, Kevin Hawkins wrote:
>> All,
>>
>> I'd like to have a sense of how early I should show up on Sunday for the
>> hack session, and and how late those of us there should stay to meet any
>> late arrivals. If you're planning to come, please let me know. Well,
>> let us all know so no one thinks they're going to have to spend an
>> awkward afternoon alone with me. :)
>>
>> An update on logistics will probably be coming from Becky this week, but
>> let me say now that the Sunday hack session, just like the working
>> meetings on Monday through Wednesday, will be in the Shapiro Library on
>> U-M's central campus. This is next door to the Hatcher Library, where
>> the 2009 conference was held. The folks at the hotel reception desk can
>> tell you how to find it.
>>
>> We'll be in the Turkish-American Friendship Room, which is on the fourth
>> floor. Follow the signs once you're in the building. Some of you will
>> recall this room as one that was used for various meetings held before,
>> during, and after the 2009 conference.
>>
>> See you soon!
>

From sebastian.rahtz at oucs.ox.ac.uk  Tue Apr 10 16:06:20 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Tue, 10 Apr 2012 20:06:20 +0000
Subject: [tei-council] sunday hack session
In-Reply-To: <4F848FC6.2050704@ultraslavonic.info>
References: <4F845AE6.7010509@ultraslavonic.info>
	<D957117C-E9E0-43A0-A1C1-BC2A37DDB3C5@oucs.ox.ac.uk>
	<4F848FC6.2050704@ultraslavonic.info>
Message-ID: <05C940C0-4D03-4FCE-A996-3DC6A625D028@oucs.ox.ac.uk>


On 10 Apr 2012, at 20:53, Kevin Hawkins wrote:

> The only thing I find in my email archive that Sebastian has suggested 
> is to write roma2 if we get bored. 

phew, no chance of that, luckily :-}

though, as some of you know, James and I have submitted a small funding
bid to JISC in the UK for a project which would make a good start
on a new Roma

Sebastian

From James.Cummings at oucs.ox.ac.uk  Wed Apr 11 05:01:17 2012
From: James.Cummings at oucs.ox.ac.uk (James Cummings)
Date: Wed, 11 Apr 2012 10:01:17 +0100
Subject: [tei-council] TEI ODD meeting after DH2012
Message-ID: <4F85485D.5060907@oucs.ox.ac.uk>

Dear TEI Council,

In interests of transparency I just sent this update on my 
planning of the TEI ODD meeting after DH2012 to the Board list. I 
don't believe there is anything confidential in it so circulate 
it here as well. I wasn't able to invite/subsidise everyone 
suggested, but hopefully some of them will still be able to make it.

-James

====
Dear TEI-C Board,

As an update on the planning for this TEI ODD meeting after 
DH2012: a total of 15 people who were invited can make it, 8 of 
which need up to 15 nights of hotel. 3 invitations are still 
outstanding (but I don't expect to hear back from 2 of them). 
About 10 suggested people were unable to be invited/subsidised 
without increasing the budget, however, I will make sure those 
people are invited in a non-subsidised manner.

The conference is charging 200 EUR for renting the room including 
"for cleaning, use of fixed equipment (projector), and admin: EUR 
200 / day".  I've said that they should go ahead and we can have 
them invoice the TEI-C for that charge.

I'll give Dot a list of names of those that have said that they 
need hotel to be subsidised and can claim up to two nights hotel. 
  I'll also provide those people with instructions on how to do so.

Within the next week I'll start announcing it publicly on TEI-L 
(etc.) as an open meeting for others with their own means able to 
attend should they wish.

Best,

James Cummings

-- 
Dr James Cummings, InfoDev,
Computing Services, University of Oxford

From James.Cummings at oucs.ox.ac.uk  Wed Apr 11 06:46:47 2012
From: James.Cummings at oucs.ox.ac.uk (James Cummings)
Date: Wed, 11 Apr 2012 11:46:47 +0100
Subject: [tei-council] Draft Agenda for AnnArbor2012 face2face meeting
Message-ID: <4F856117.6090104@oucs.ox.ac.uk>

Hi All,

I've put a draft agenda up on the wiki at:

http://wiki.tei-c.org/index.php/Council

Now is the time to shout, re-order stuff, add stuff, etc. Feel 
free to change it (and/or add more detail) as you feel appropriate.

My suggestion is that we organise each day to structurally 
alternate between other business and bugs/FR. e.g. warming up by 
talking about some of the issues/actions that have been raised, 
then work through bugs/FR, have lunch, talk about other issues, 
then work on bugs/FR.

You'll notice the 'open lunch' on Tuesday. Kevin and Becky can 
tell us more about that. (psst, that is a cue.)

I'm hoping because of Lou's triaging work (see 
http://www.tei-c.org/Activities/Council/Working/tcw17.html) we 
can progress through the Green bugs/FR very quickly and move on 
to the Amber ones.

HOMEWORK: I would like *every* council member to spend some time 
(if you have not already) looking through *every* Green and then 
Amber Bug/FR. If you have any objections or comments, add it to 
the SF ticket for the item.  If you think the right conclusion 
has been reached (e.g. on an Amber one), add it to the ticket. In 
the meeting *no* Bug/FR should come as a surprise to you! (Well, 
except perhaps ones submitted between now and then!)

Minutes: Martin and Becky have volunteered to take minutes, and 
Kevin has arranged for a UM student to gain some experience by 
converting them to TEI.

Flights: Can I confirm who amongst us needs to depart early on 
the Wednesday and by what time?  Sebastian and my flight doesn't 
leave until about 10pm now, I believe.

Remote Participants: I believe it is StuartY and GabyB that are 
participating remotely.  Can you make sure that some of us have 
your skype usernames (and I know both of you know how to use the 
IRC channel).

-James
--
Dr James Cummings, InfoDev,
Computing Services, University of Oxford

From James.Cummings at oucs.ox.ac.uk  Wed Apr 11 07:07:15 2012
From: James.Cummings at oucs.ox.ac.uk (James Cummings)
Date: Wed, 11 Apr 2012 12:07:15 +0100
Subject: [tei-council] Draft Agenda for AnnArbor2012 face2face meeting
In-Reply-To: <4F856117.6090104@oucs.ox.ac.uk>
References: <4F856117.6090104@oucs.ox.ac.uk>
Message-ID: <4F8565E3.9080600@oucs.ox.ac.uk>

On 11/04/12 11:46, James Cummings wrote:
> I've put a draft agenda up on the wiki at:
>
> http://wiki.tei-c.org/index.php/Council
>
> Now is the time to shout, re-order stuff, add stuff, etc. Feel
> free to change it (and/or add more detail) as you feel appropriate.

If you've forgotten your username and/or password and/or email or 
have other problems logging into the wiki do feel free to email 
me, Kevin, or Piotr all of whom have power to changes these things.

> I'm hoping because of Lou's triaging work (see
> http://www.tei-c.org/Activities/Council/Working/tcw17.html) we
> can progress through the Green bugs/FR very quickly and move on
> to the Amber ones.

Fair warning here however, I intend to plough through the Green 
bugs/FR quickly... making the homework below more crucial if you 
think you might disagree with any of them.

> HOMEWORK: I would like *every* council member to spend some time
> (if you have not already) looking through *every* Green and then
> Amber Bug/FR. If you have any objections or comments, add it to
> the SF ticket for the item.  If you think the right conclusion
> has been reached (e.g. on an Amber one), add it to the ticket. In
> the meeting *no* Bug/FR should come as a surprise to you! (Well,
> except perhaps ones submitted between now and then!)

-James

-- 
Dr James Cummings, InfoDev,
Computing Services, University of Oxford

From rwelzenbach at gmail.com  Wed Apr 11 09:18:10 2012
From: rwelzenbach at gmail.com (Rebecca Welzenbach)
Date: Wed, 11 Apr 2012 09:18:10 -0400
Subject: [tei-council] sunday hack session
In-Reply-To: <05C940C0-4D03-4FCE-A996-3DC6A625D028@oucs.ox.ac.uk>
References: <4F845AE6.7010509@ultraslavonic.info>
	<D957117C-E9E0-43A0-A1C1-BC2A37DDB3C5@oucs.ox.ac.uk>
	<4F848FC6.2050704@ultraslavonic.info>
	<05C940C0-4D03-4FCE-A996-3DC6A625D028@oucs.ox.ac.uk>
Message-ID: <CAA2irtLhNN4obsW=Z41rCrRGU90OfVeLLXEcehPegahr7VsrZw@mail.gmail.com>

Hi all,

Looking forward to seeing you soon. Some details that may be of
interest as you arrive and get settled (will add them to the Google
doc as well):

*Transport*
Last week I used the new AirRide shuttle that Paul mentioned, and
recommend it, if you still need to make arrangements to get from the
airport to campus. It was on time, comfortable, clean, runs
frequently, etc., and is certainly the cheapest option. You can make
reservations in advance here: http://www.myairride.com/. If you do
this, be sure to print out everything and bring it with you.
I think they also take walk-ons, for a slightly higher fee. You'll
want to take the shuttle to the Central Campus Transit Center, which
is a short walk from the hotel.

*Maps*
* From the shuttle station to the hotel: http://g.co/maps/8du2f
* Hotel location and surrounding area:
http://www.belltowerhotel.com/location.html
* Map of central campus: http://www.umich.edu/~info/pdf/central.pdf
* Map of the 4th floor of the Shapiro Library, where we'll be meeting:
http://www.lib.umich.edu/navigator/shapiro4.html

Note that, confusingly, the library map is oriented with north in the
lower right hand corner. The big white square to the right of the map
is our meeting room. The oddly shaped taupe area just above is where
Kevin's and my office is.

*food*
You won't have any trouble finding places to eat and drink within
walking distance of the hotel or the library, and most or all will be
open on Sunday.

* I believe your hotel reservation includes free continental breakfast
(as well as in-room wireless), but I'll confirm this.
* There's also a restaurant in the hotel, but I have no idea what it
is like: http://www.mercysrestaurant.com/menu
* There's a coffee shop on the first floor of the library, which has
light (pre-made) fare like sandwiches, salads, and sushi as well as
coffee and pastries: http://uunions.umich.edu/berts/
* Espresso Royale has locations close to the hotel and the library:
http://www.espressoroyale.com/location.php?id=20
* Or if you prefer gourmet coffee and really excellent pastries, there
is Comet Coffee: http://www.yelp.com/biz/comet-coffee-ann-arbor

*Wireless*
Non-UM-ers who will be on site will be assigned a temporary log-in so
you can access the "MWireless" network used by faculty, staff, and
students (the open "MGuest" network won't be sufficient for our work).
Library Desktop Support is working now on setting up your
accounts--hopefully they or I will be able to get the info to you
before the end of the week. I'll also bring the details with me on
Sunday, just in case. They know we need to be up and running over the
weekend.

I'm about to look over James' agenda, but want to note that on Tuesday
we plan to have lunch catered in the library, and invite interested
staff and other local people who might be interested to join us.
Planning to order a variety of foods from
http://www.jerusalemgarden.net/.

Hopefully this will at least get you here, fed and rested--let me know
if you have questions, and see you soon.

Becky


On Tue, Apr 10, 2012 at 4:06 PM, Sebastian Rahtz
<sebastian.rahtz at oucs.ox.ac.uk> wrote:
>
> On 10 Apr 2012, at 20:53, Kevin Hawkins wrote:
>
>> The only thing I find in my email archive that Sebastian has suggested
>> is to write roma2 if we get bored.
>
> phew, no chance of that, luckily :-}
>
> though, as some of you know, James and I have submitted a small funding
> bid to JISC in the UK for a project which would make a good start
> on a new Roma
>
> Sebastian
> --
> tei-council mailing list
> tei-council at lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>
> PLEASE NOTE: postings to this list are publicly archived

From mholmes at uvic.ca  Wed Apr 11 11:15:14 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Wed, 11 Apr 2012 08:15:14 -0700
Subject: [tei-council] Draft Agenda for AnnArbor2012 face2face meeting
In-Reply-To: <4F856117.6090104@oucs.ox.ac.uk>
References: <4F856117.6090104@oucs.ox.ac.uk>
Message-ID: <4F85A002.6050602@uvic.ca>

HI James,

I thought we were going to discuss the issue of @ref/key/cRef & Private 
URI Schemes. It was on the agenda for the February telco, but would have 
taken too long to address fully then, and I thought we agreed to move it 
forward to the ftf. I think it's important, and it's not something that 
can be captured in a single bug (although it's intrinsic to bugs 3480650 
and 3413346).

Cheers,
Martin

On 12-04-11 03:46 AM, James Cummings wrote:
> Hi All,
>
> I've put a draft agenda up on the wiki at:
>
> http://wiki.tei-c.org/index.php/Council
>
> Now is the time to shout, re-order stuff, add stuff, etc. Feel
> free to change it (and/or add more detail) as you feel appropriate.
>
> My suggestion is that we organise each day to structurally
> alternate between other business and bugs/FR. e.g. warming up by
> talking about some of the issues/actions that have been raised,
> then work through bugs/FR, have lunch, talk about other issues,
> then work on bugs/FR.
>
> You'll notice the 'open lunch' on Tuesday. Kevin and Becky can
> tell us more about that. (psst, that is a cue.)
>
> I'm hoping because of Lou's triaging work (see
> http://www.tei-c.org/Activities/Council/Working/tcw17.html) we
> can progress through the Green bugs/FR very quickly and move on
> to the Amber ones.
>
> HOMEWORK: I would like *every* council member to spend some time
> (if you have not already) looking through *every* Green and then
> Amber Bug/FR. If you have any objections or comments, add it to
> the SF ticket for the item.  If you think the right conclusion
> has been reached (e.g. on an Amber one), add it to the ticket. In
> the meeting *no* Bug/FR should come as a surprise to you! (Well,
> except perhaps ones submitted between now and then!)
>
> Minutes: Martin and Becky have volunteered to take minutes, and
> Kevin has arranged for a UM student to gain some experience by
> converting them to TEI.
>
> Flights: Can I confirm who amongst us needs to depart early on
> the Wednesday and by what time?  Sebastian and my flight doesn't
> leave until about 10pm now, I believe.
>
> Remote Participants: I believe it is StuartY and GabyB that are
> participating remotely.  Can you make sure that some of us have
> your skype usernames (and I know both of you know how to use the
> IRC channel).
>
> -James
> --
> Dr James Cummings, InfoDev,
> Computing Services, University of Oxford

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From mholmes at uvic.ca  Wed Apr 11 12:37:06 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Wed, 11 Apr 2012 09:37:06 -0700
Subject: [tei-council] sunday hack session
In-Reply-To: <CAA2irtLhNN4obsW=Z41rCrRGU90OfVeLLXEcehPegahr7VsrZw@mail.gmail.com>
References: <4F845AE6.7010509@ultraslavonic.info>
	<D957117C-E9E0-43A0-A1C1-BC2A37DDB3C5@oucs.ox.ac.uk>
	<4F848FC6.2050704@ultraslavonic.info>
	<05C940C0-4D03-4FCE-A996-3DC6A625D028@oucs.ox.ac.uk>
	<CAA2irtLhNN4obsW=Z41rCrRGU90OfVeLLXEcehPegahr7VsrZw@mail.gmail.com>
Message-ID: <4F85B332.3000303@uvic.ca>

I just tried to book the AirRide shuttle, but it declined my credit 
card. Has anyone successfully completed a booking with a non-US credit card?

Cheers,
Martin

On 12-04-11 06:18 AM, Rebecca Welzenbach wrote:
> Hi all,
>
> Looking forward to seeing you soon. Some details that may be of
> interest as you arrive and get settled (will add them to the Google
> doc as well):
>
> *Transport*
> Last week I used the new AirRide shuttle that Paul mentioned, and
> recommend it, if you still need to make arrangements to get from the
> airport to campus. It was on time, comfortable, clean, runs
> frequently, etc., and is certainly the cheapest option. You can make
> reservations in advance here: http://www.myairride.com/. If you do
> this, be sure to print out everything and bring it with you.
> I think they also take walk-ons, for a slightly higher fee. You'll
> want to take the shuttle to the Central Campus Transit Center, which
> is a short walk from the hotel.
>
> *Maps*
> * From the shuttle station to the hotel: http://g.co/maps/8du2f
> * Hotel location and surrounding area:
> http://www.belltowerhotel.com/location.html
> * Map of central campus: http://www.umich.edu/~info/pdf/central.pdf
> * Map of the 4th floor of the Shapiro Library, where we'll be meeting:
> http://www.lib.umich.edu/navigator/shapiro4.html
>
> Note that, confusingly, the library map is oriented with north in the
> lower right hand corner. The big white square to the right of the map
> is our meeting room. The oddly shaped taupe area just above is where
> Kevin's and my office is.
>
> *food*
> You won't have any trouble finding places to eat and drink within
> walking distance of the hotel or the library, and most or all will be
> open on Sunday.
>
> * I believe your hotel reservation includes free continental breakfast
> (as well as in-room wireless), but I'll confirm this.
> * There's also a restaurant in the hotel, but I have no idea what it
> is like: http://www.mercysrestaurant.com/menu
> * There's a coffee shop on the first floor of the library, which has
> light (pre-made) fare like sandwiches, salads, and sushi as well as
> coffee and pastries: http://uunions.umich.edu/berts/
> * Espresso Royale has locations close to the hotel and the library:
> http://www.espressoroyale.com/location.php?id=20
> * Or if you prefer gourmet coffee and really excellent pastries, there
> is Comet Coffee: http://www.yelp.com/biz/comet-coffee-ann-arbor
>
> *Wireless*
> Non-UM-ers who will be on site will be assigned a temporary log-in so
> you can access the "MWireless" network used by faculty, staff, and
> students (the open "MGuest" network won't be sufficient for our work).
> Library Desktop Support is working now on setting up your
> accounts--hopefully they or I will be able to get the info to you
> before the end of the week. I'll also bring the details with me on
> Sunday, just in case. They know we need to be up and running over the
> weekend.
>
> I'm about to look over James' agenda, but want to note that on Tuesday
> we plan to have lunch catered in the library, and invite interested
> staff and other local people who might be interested to join us.
> Planning to order a variety of foods from
> http://www.jerusalemgarden.net/.
>
> Hopefully this will at least get you here, fed and rested--let me know
> if you have questions, and see you soon.
>
> Becky
>
>
> On Tue, Apr 10, 2012 at 4:06 PM, Sebastian Rahtz
> <sebastian.rahtz at oucs.ox.ac.uk>  wrote:
>>
>> On 10 Apr 2012, at 20:53, Kevin Hawkins wrote:
>>
>>> The only thing I find in my email archive that Sebastian has suggested
>>> is to write roma2 if we get bored.
>>
>> phew, no chance of that, luckily :-}
>>
>> though, as some of you know, James and I have submitted a small funding
>> bid to JISC in the UK for a project which would make a good start
>> on a new Roma
>>
>> Sebastian
>> --
>> tei-council mailing list
>> tei-council at lists.village.Virginia.EDU
>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>>
>> PLEASE NOTE: postings to this list are publicly archived

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From James.Cummings at oucs.ox.ac.uk  Thu Apr 12 05:59:03 2012
From: James.Cummings at oucs.ox.ac.uk (James Cummings)
Date: Thu, 12 Apr 2012 10:59:03 +0100
Subject: [tei-council] Draft Agenda for AnnArbor2012 face2face meeting
In-Reply-To: <4F85A002.6050602@uvic.ca>
References: <4F856117.6090104@oucs.ox.ac.uk> <4F85A002.6050602@uvic.ca>
Message-ID: <4F86A767.9010601@oucs.ox.ac.uk>


Hi Martin, (et al.)

You are right. I had entirely forgotten that. I've added on the 
first day as 'TEI and URIs' since it will affect how we deal with 
those tickets. Moving release process discussion to Weds since I 
don't think there is much to say about, Gaby (our next proposed 
release technician) won't be there, etc.

If there are other things I've forgotten, do make sure to add 
them to the agenda.

-James


On 11/04/12 16:15, Martin Holmes wrote:
> HI James,
>
> I thought we were going to discuss the issue of @ref/key/cRef &
> Private URI Schemes. It was on the agenda for the February telco,
> but would have taken too long to address fully then, and I
> thought we agreed to move it forward to the ftf. I think it's
> important, and it's not something that can be captured in a
> single bug (although it's intrinsic to bugs 3480650 and 3413346).
>
> Cheers,
> Martin
>
> On 12-04-11 03:46 AM, James Cummings wrote:
>> Hi All,
>>
>> I've put a draft agenda up on the wiki at:
>>
>> http://wiki.tei-c.org/index.php/Council
>>
>> Now is the time to shout, re-order stuff, add stuff, etc. Feel
>> free to change it (and/or add more detail) as you feel
>> appropriate.
>>
>> My suggestion is that we organise each day to structurally
>> alternate between other business and bugs/FR. e.g. warming up by
>> talking about some of the issues/actions that have been raised,
>> then work through bugs/FR, have lunch, talk about other issues,
>> then work on bugs/FR.
>>
>> You'll notice the 'open lunch' on Tuesday. Kevin and Becky can
>> tell us more about that. (psst, that is a cue.)
>>
>> I'm hoping because of Lou's triaging work (see
>> http://www.tei-c.org/Activities/Council/Working/tcw17.html) we
>> can progress through the Green bugs/FR very quickly and move on
>> to the Amber ones.
>>
>> HOMEWORK: I would like *every* council member to spend some time
>> (if you have not already) looking through *every* Green and then
>> Amber Bug/FR. If you have any objections or comments, add it to
>> the SF ticket for the item. If you think the right conclusion
>> has been reached (e.g. on an Amber one), add it to the ticket. In
>> the meeting *no* Bug/FR should come as a surprise to you! (Well,
>> except perhaps ones submitted between now and then!)
>>
>> Minutes: Martin and Becky have volunteered to take minutes, and
>> Kevin has arranged for a UM student to gain some experience by
>> converting them to TEI.
>>
>> Flights: Can I confirm who amongst us needs to depart early on
>> the Wednesday and by what time? Sebastian and my flight doesn't
>> leave until about 10pm now, I believe.
>>
>> Remote Participants: I believe it is StuartY and GabyB that are
>> participating remotely. Can you make sure that some of us have
>> your skype usernames (and I know both of you know how to use the
>> IRC channel).
>>
>> -James
>> --
>> Dr James Cummings, InfoDev,
>> Computing Services, University of Oxford
>


-- 
Dr James Cummings, InfoDev,
Computing Services, University of Oxford

From James.Cummings at oucs.ox.ac.uk  Thu Apr 12 08:00:55 2012
From: James.Cummings at oucs.ox.ac.uk (James Cummings)
Date: Thu, 12 Apr 2012 13:00:55 +0100
Subject: [tei-council] sunday hack session
In-Reply-To: <4F85B332.3000303@uvic.ca>
References: <4F845AE6.7010509@ultraslavonic.info>	<D957117C-E9E0-43A0-A1C1-BC2A37DDB3C5@oucs.ox.ac.uk>	<4F848FC6.2050704@ultraslavonic.info>	<05C940C0-4D03-4FCE-A996-3DC6A625D028@oucs.ox.ac.uk>	<CAA2irtLhNN4obsW=Z41rCrRGU90OfVeLLXEcehPegahr7VsrZw@mail.gmail.com>
	<4F85B332.3000303@uvic.ca>
Message-ID: <4F86C3F7.1050300@oucs.ox.ac.uk>

On 11/04/12 17:37, Martin Holmes wrote:
> I just tried to book the AirRide shuttle, but it declined my credit
> card. Has anyone successfully completed a booking with a non-US credit card?

I didn't try because I'm never confident of airline schedules, or 
other opportunities, etc. I figured the difference in price was 
minimal ($12 vs $15 for a single) and that I'd be billing it to 
Oxford rather than the TEI-C.

However, I've just watched The Millionaire Tour:
http://www.imdb.com/title/tt1937388/ so I'm unlikely to be 
jumping in any strange taxis touting for business. ;-)

-James

>
> Cheers,
> Martin
>
> On 12-04-11 06:18 AM, Rebecca Welzenbach wrote:
>> Hi all,
>>
>> Looking forward to seeing you soon. Some details that may be of
>> interest as you arrive and get settled (will add them to the Google
>> doc as well):
>>
>> *Transport*
>> Last week I used the new AirRide shuttle that Paul mentioned, and
>> recommend it, if you still need to make arrangements to get from the
>> airport to campus. It was on time, comfortable, clean, runs
>> frequently, etc., and is certainly the cheapest option. You can make
>> reservations in advance here: http://www.myairride.com/. If you do
>> this, be sure to print out everything and bring it with you.
>> I think they also take walk-ons, for a slightly higher fee. You'll
>> want to take the shuttle to the Central Campus Transit Center, which
>> is a short walk from the hotel.
>>
>> *Maps*
>> * From the shuttle station to the hotel: http://g.co/maps/8du2f
>> * Hotel location and surrounding area:
>> http://www.belltowerhotel.com/location.html
>> * Map of central campus: http://www.umich.edu/~info/pdf/central.pdf
>> * Map of the 4th floor of the Shapiro Library, where we'll be meeting:
>> http://www.lib.umich.edu/navigator/shapiro4.html
>>
>> Note that, confusingly, the library map is oriented with north in the
>> lower right hand corner. The big white square to the right of the map
>> is our meeting room. The oddly shaped taupe area just above is where
>> Kevin's and my office is.
>>
>> *food*
>> You won't have any trouble finding places to eat and drink within
>> walking distance of the hotel or the library, and most or all will be
>> open on Sunday.
>>
>> * I believe your hotel reservation includes free continental breakfast
>> (as well as in-room wireless), but I'll confirm this.
>> * There's also a restaurant in the hotel, but I have no idea what it
>> is like: http://www.mercysrestaurant.com/menu
>> * There's a coffee shop on the first floor of the library, which has
>> light (pre-made) fare like sandwiches, salads, and sushi as well as
>> coffee and pastries: http://uunions.umich.edu/berts/
>> * Espresso Royale has locations close to the hotel and the library:
>> http://www.espressoroyale.com/location.php?id=20
>> * Or if you prefer gourmet coffee and really excellent pastries, there
>> is Comet Coffee: http://www.yelp.com/biz/comet-coffee-ann-arbor
>>
>> *Wireless*
>> Non-UM-ers who will be on site will be assigned a temporary log-in so
>> you can access the "MWireless" network used by faculty, staff, and
>> students (the open "MGuest" network won't be sufficient for our work).
>> Library Desktop Support is working now on setting up your
>> accounts--hopefully they or I will be able to get the info to you
>> before the end of the week. I'll also bring the details with me on
>> Sunday, just in case. They know we need to be up and running over the
>> weekend.
>>
>> I'm about to look over James' agenda, but want to note that on Tuesday
>> we plan to have lunch catered in the library, and invite interested
>> staff and other local people who might be interested to join us.
>> Planning to order a variety of foods from
>> http://www.jerusalemgarden.net/.
>>
>> Hopefully this will at least get you here, fed and rested--let me know
>> if you have questions, and see you soon.
>>
>> Becky
>>
>>
>> On Tue, Apr 10, 2012 at 4:06 PM, Sebastian Rahtz
>> <sebastian.rahtz at oucs.ox.ac.uk>   wrote:
>>>
>>> On 10 Apr 2012, at 20:53, Kevin Hawkins wrote:
>>>
>>>> The only thing I find in my email archive that Sebastian has suggested
>>>> is to write roma2 if we get bored.
>>>
>>> phew, no chance of that, luckily :-}
>>>
>>> though, as some of you know, James and I have submitted a small funding
>>> bid to JISC in the UK for a project which would make a good start
>>> on a new Roma
>>>
>>> Sebastian
>>> --
>>> tei-council mailing list
>>> tei-council at lists.village.Virginia.EDU
>>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>>>
>>> PLEASE NOTE: postings to this list are publicly archived
>


-- 
Dr James Cummings, InfoDev,
Computing Services, University of Oxford

From PFSchaffner at umich.edu  Thu Apr 12 21:35:37 2012
From: PFSchaffner at umich.edu (Paul F. Schaffner)
Date: Thu, 12 Apr 2012 21:35:37 -0400 (EDT)
Subject: [tei-council] sunday hack session
In-Reply-To: <4F85B332.3000303@uvic.ca>
References: <4F845AE6.7010509@ultraslavonic.info>
	<D957117C-E9E0-43A0-A1C1-BC2A37DDB3C5@oucs.ox.ac.uk>
	<4F848FC6.2050704@ultraslavonic.info>
	<05C940C0-4D03-4FCE-A996-3DC6A625D028@oucs.ox.ac.uk>
	<CAA2irtLhNN4obsW=Z41rCrRGU90OfVeLLXEcehPegahr7VsrZw@mail.gmail.com>
	<4F85B332.3000303@uvic.ca>
Message-ID: <Pine.LNX.4.64.1204122126070.16325@zaxxon.gpcc.itd.umich.edu>

If anyone needs a local contact for any reason, transport or
otherwise, please feel free to phone me. Mobile = 1 734 709 9144.

I see that Mr. B. will be at The Ark on both Saturday and
Sunday night (The Ark = the last of the folkie clubs,
and a good visit; Mr. B. = Ann Arbor blues piano virtuoso.)
http://theark.org/3066.html
with the rest of the schedule here
http://theark.org/search/results133428055489282.html

pfs



On Wed, 11 Apr 2012, Martin Holmes wrote:

> I just tried to book the AirRide shuttle, but it declined my credit
> card. Has anyone successfully completed a booking with a non-US credit card?
>
> Cheers,
> Martin
>
> On 12-04-11 06:18 AM, Rebecca Welzenbach wrote:
>> Hi all,
>>
>> Looking forward to seeing you soon. Some details that may be of
>> interest as you arrive and get settled (will add them to the Google
>> doc as well):
>>
>> *Transport*
>> Last week I used the new AirRide shuttle that Paul mentioned, and
>> recommend it, if you still need to make arrangements to get from the
>> airport to campus. It was on time, comfortable, clean, runs
>> frequently, etc., and is certainly the cheapest option. You can make
>> reservations in advance here: http://www.myairride.com/. If you do
>> this, be sure to print out everything and bring it with you.
>> I think they also take walk-ons, for a slightly higher fee. You'll
>> want to take the shuttle to the Central Campus Transit Center, which
>> is a short walk from the hotel.
>>
>> *Maps*
>> * From the shuttle station to the hotel: http://g.co/maps/8du2f
>> * Hotel location and surrounding area:
>> http://www.belltowerhotel.com/location.html
>> * Map of central campus: http://www.umich.edu/~info/pdf/central.pdf
>> * Map of the 4th floor of the Shapiro Library, where we'll be meeting:
>> http://www.lib.umich.edu/navigator/shapiro4.html
>>
>> Note that, confusingly, the library map is oriented with north in the
>> lower right hand corner. The big white square to the right of the map
>> is our meeting room. The oddly shaped taupe area just above is where
>> Kevin's and my office is.
>>
>> *food*
>> You won't have any trouble finding places to eat and drink within
>> walking distance of the hotel or the library, and most or all will be
>> open on Sunday.
>>
>> * I believe your hotel reservation includes free continental breakfast
>> (as well as in-room wireless), but I'll confirm this.
>> * There's also a restaurant in the hotel, but I have no idea what it
>> is like: http://www.mercysrestaurant.com/menu
>> * There's a coffee shop on the first floor of the library, which has
>> light (pre-made) fare like sandwiches, salads, and sushi as well as
>> coffee and pastries: http://uunions.umich.edu/berts/
>> * Espresso Royale has locations close to the hotel and the library:
>> http://www.espressoroyale.com/location.php?id=20
>> * Or if you prefer gourmet coffee and really excellent pastries, there
>> is Comet Coffee: http://www.yelp.com/biz/comet-coffee-ann-arbor
>>
>> *Wireless*
>> Non-UM-ers who will be on site will be assigned a temporary log-in so
>> you can access the "MWireless" network used by faculty, staff, and
>> students (the open "MGuest" network won't be sufficient for our work).
>> Library Desktop Support is working now on setting up your
>> accounts--hopefully they or I will be able to get the info to you
>> before the end of the week. I'll also bring the details with me on
>> Sunday, just in case. They know we need to be up and running over the
>> weekend.
>>
>> I'm about to look over James' agenda, but want to note that on Tuesday
>> we plan to have lunch catered in the library, and invite interested
>> staff and other local people who might be interested to join us.
>> Planning to order a variety of foods from
>> http://www.jerusalemgarden.net/.
>>
>> Hopefully this will at least get you here, fed and rested--let me know
>> if you have questions, and see you soon.
>>
>> Becky
>>
>>
>> On Tue, Apr 10, 2012 at 4:06 PM, Sebastian Rahtz
>> <sebastian.rahtz at oucs.ox.ac.uk>  wrote:
>>>
>>> On 10 Apr 2012, at 20:53, Kevin Hawkins wrote:
>>>
>>>> The only thing I find in my email archive that Sebastian has suggested
>>>> is to write roma2 if we get bored.
>>>
>>> phew, no chance of that, luckily :-}
>>>
>>> though, as some of you know, James and I have submitted a small funding
>>> bid to JISC in the UK for a project which would make a good start
>>> on a new Roma
>>>
>>> Sebastian
>>> --
>>> tei-council mailing list
>>> tei-council at lists.village.Virginia.EDU
>>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>>>
>>> PLEASE NOTE: postings to this list are publicly archived
>
> -- 
> Martin Holmes
> University of Victoria Humanities Computing and Media Centre
> (mholmes at uvic.ca)
> -- 
> tei-council mailing list
> tei-council at lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>
> PLEASE NOTE: postings to this list are publicly archived
>
>
>

--------------------------------------------------------------------
Paul Schaffner | PFSchaffner at umich.edu | http://www.umich.edu/~pfs/
316-C Hatcher Library N, Univ. of Michigan, Ann Arbor MI 48109-1190
--------------------------------------------------------------------

From kevin.s.hawkins at ultraslavonic.info  Sat Apr 14 14:04:27 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Sat, 14 Apr 2012 14:04:27 -0400
Subject: [tei-council] medical advice for our upcoming meeting
Message-ID: <4F89BC2B.7090609@ultraslavonic.info>

Since the next few days will involve a lot of problem-solving, I 
encourage you all to take this medical advice into account:

http://www.medicaldaily.com/news/20120411/9496/alcohol-solving-skills-analytical-thinking-creativity-study.htm

;-)

From mholmes at uvic.ca  Sat Apr 14 14:34:32 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Sat, 14 Apr 2012 11:34:32 -0700
Subject: [tei-council] medical advice for our upcoming meeting
In-Reply-To: <4F89BC2B.7090609@ultraslavonic.info>
References: <4F89BC2B.7090609@ultraslavonic.info>
Message-ID: <4F89C338.9060600@uvic.ca>

Oh good. I just started drinking again after teetotalling the first 
three months of the year. :-)

I remember a very nice bar in Ann Arbor that served dozens of great 
beers and allowed you to try test sets of six or so in little glasses. 
Is it still there?

Cheers,
Martin

On 12-04-14 11:04 AM, Kevin Hawkins wrote:
> Since the next few days will involve a lot of problem-solving, I
> encourage you all to take this medical advice into account:
>
> http://www.medicaldaily.com/news/20120411/9496/alcohol-solving-skills-analytical-thinking-creativity-study.htm
>
> ;-)

From kevin.s.hawkins at ultraslavonic.info  Sat Apr 14 14:42:47 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Sat, 14 Apr 2012 14:42:47 -0400
Subject: [tei-council] medical advice for our upcoming meeting
In-Reply-To: <4F89C338.9060600@uvic.ca>
References: <4F89BC2B.7090609@ultraslavonic.info> <4F89C338.9060600@uvic.ca>
Message-ID: <4F89C527.3060807@ultraslavonic.info>

You might have been at Ashley's, which is right near Central Campus. 
Huge selection and probably offer samplers/flights.  There are plenty of 
other options in town, some of which brew their own beer.  I'm a big fan 
of the Jolly Pumpkin, which specializes in sour Belgian ales.  The food 
is better there too.

On 4/14/12 2:34 PM, Martin Holmes wrote:
> Oh good. I just started drinking again after teetotalling the first
> three months of the year. :-)
>
> I remember a very nice bar in Ann Arbor that served dozens of great
> beers and allowed you to try test sets of six or so in little glasses.
> Is it still there?
>
> Cheers,
> Martin
>
> On 12-04-14 11:04 AM, Kevin Hawkins wrote:
>> Since the next few days will involve a lot of problem-solving, I
>> encourage you all to take this medical advice into account:
>>
>> http://www.medicaldaily.com/news/20120411/9496/alcohol-solving-skills-analytical-thinking-creativity-study.htm
>>
>>
>> ;-)

From James.Cummings at oucs.ox.ac.uk  Sat Apr 14 17:34:51 2012
From: James.Cummings at oucs.ox.ac.uk (James Cummings)
Date: Sat, 14 Apr 2012 17:34:51 -0400
Subject: [tei-council] Per Diem Rates; Supper Saturday
Message-ID: <4F89ED7B.3000403@oucs.ox.ac.uk>


Just a reminder that the Per Diem Rates for meals that the TEI-C 
uses for meals, in Ann Arbor are:

70% of $56 = $39	
Specifically:
Breakfast | 25% = $10	
Lunch | 35% = $14	
Dinner | 40% = $15

The original budget was for 3 days-worth of food. However, this 
budget included Gaby attending, which he now isn't.  So I propose 
that those of us who are attending the optional TEI hackfest on 
Sunday also have food covered at the same per diem rate as above 
for that day as well.

On a related note, Sebastian and I will be in the Belltower 
Hotel's lobby at 6pm'ish this evening before going somewhere for 
supper.   Email us if you are around and want us to wait.

-James


-- 
Dr James Cummings, InfoDev,
Computing Services, University of Oxford

From sebastian.rahtz at oucs.ox.ac.uk  Sat Apr 14 17:58:22 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Sat, 14 Apr 2012 21:58:22 +0000
Subject: [tei-council] Per Diem Rates; Supper Saturday
In-Reply-To: <4F89ED7B.3000403@oucs.ox.ac.uk>
References: <4F89ED7B.3000403@oucs.ox.ac.uk>
Message-ID: <543e7c7d-87ee-4e55-8f78-a7e0d5b4d3cd@HUB03.ad.oak.ox.ac.uk>

breakfast at the hotel is included, and I hear Mr  Crazy Joe's Blimbyburger is jolly fine, so thats a nice big lunch?

sebastian

From rwelzenbach at gmail.com  Sat Apr 14 18:25:10 2012
From: rwelzenbach at gmail.com (Rebecca Welzenbach)
Date: Sat, 14 Apr 2012 18:25:10 -0400
Subject: [tei-council] Per Diem Rates; Supper Saturday
In-Reply-To: <543e7c7d-87ee-4e55-8f78-a7e0d5b4d3cd@HUB03.ad.oak.ox.ac.uk>
References: <4F89ED7B.3000403@oucs.ox.ac.uk>
	<543e7c7d-87ee-4e55-8f78-a7e0d5b4d3cd@HUB03.ad.oak.ox.ac.uk>
Message-ID: <CAA2irtLp8T5ayHA=iMaPJ86QM27=mKm9C4NikN2CiKDN9p0xDw@mail.gmail.com>

Glad to hear you're beginning to arrive--I trust everything went
smoothly at the hotel?

I've got your temporary usernames and passwords for the MWireless
network, and will bring them with me to the library tomorrow at 10
a.m.

Becky

On Sat, Apr 14, 2012 at 5:58 PM, Sebastian Rahtz
<sebastian.rahtz at oucs.ox.ac.uk> wrote:
> breakfast at the hotel is included, and I hear Mr ?Crazy Joe's Blimbyburger is jolly fine, so thats a nice big lunch?
>
> sebastian
> --
> tei-council mailing list
> tei-council at lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>
> PLEASE NOTE: postings to this list are publicly archived

From sebastian.rahtz at oucs.ox.ac.uk  Sun Apr 15 07:57:28 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Sun, 15 Apr 2012 11:57:28 +0000
Subject: [tei-council] Per Diem Rates; Supper Saturday
In-Reply-To: <CAA2irtLp8T5ayHA=iMaPJ86QM27=mKm9C4NikN2CiKDN9p0xDw@mail.gmail.com>
References: <4F89ED7B.3000403@oucs.ox.ac.uk>
	<543e7c7d-87ee-4e55-8f78-a7e0d5b4d3cd@HUB03.ad.oak.ox.ac.uk>,
	<CAA2irtLp8T5ayHA=iMaPJ86QM27=mKm9C4NikN2CiKDN9p0xDw@mail.gmail.com>
Message-ID: <5585cf8f-9abd-4fc1-b025-618044daf329@HUB06.ad.oak.ox.ac.uk>

Yes, hotel is nice. I hear rain outside..

Carved in stone on my iPad


From lou.burnard at retired.ox.ac.uk  Sun Apr 15 08:30:36 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Sun, 15 Apr 2012 13:30:36 +0100
Subject: [tei-council] Per Diem Rates; Supper Saturday
In-Reply-To: <5585cf8f-9abd-4fc1-b025-618044daf329@HUB06.ad.oak.ox.ac.uk>
References: <4F89ED7B.3000403@oucs.ox.ac.uk>	<543e7c7d-87ee-4e55-8f78-a7e0d5b4d3cd@HUB03.ad.oak.ox.ac.uk>,
	<CAA2irtLp8T5ayHA=iMaPJ86QM27=mKm9C4NikN2CiKDN9p0xDw@mail.gmail.com>
	<5585cf8f-9abd-4fc1-b025-618044daf329@HUB06.ad.oak.ox.ac.uk>
Message-ID: <4F8ABF6C.50205@retired.ox.ac.uk>

On 15/04/12 12:57, Sebastian Rahtz (wrote:
> Yes, hotel is nice. I hear rain outside..
>
> Carved in stone on my iPad
>

A masterly non-sequitur if ever I saw one.

I assume that what woke me this morning was what CNN was bleating on 
about yesterday "severe weather conditions predicted for the great 
plains area"



From kevin.s.hawkins at ultraslavonic.info  Sun Apr 15 08:34:33 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Sun, 15 Apr 2012 08:34:33 -0400
Subject: [tei-council] Per Diem Rates; Supper Saturday
In-Reply-To: <4F8ABF6C.50205@retired.ox.ac.uk>
References: <4F89ED7B.3000403@oucs.ox.ac.uk>	<543e7c7d-87ee-4e55-8f78-a7e0d5b4d3cd@HUB03.ad.oak.ox.ac.uk>,
	<CAA2irtLp8T5ayHA=iMaPJ86QM27=mKm9C4NikN2CiKDN9p0xDw@mail.gmail.com>
	<5585cf8f-9abd-4fc1-b025-618044daf329@HUB06.ad.oak.ox.ac.uk>
	<4F8ABF6C.50205@retired.ox.ac.uk>
Message-ID: <4F8AC059.20204@ultraslavonic.info>

On 4/15/12 8:30 AM, Lou Burnard wrote:
> I assume that what woke me this morning was what CNN was bleating on
> about yesterday "severe weather conditions predicted for the great
> plains area"

That was a thunderclap.  Actual severe weather was found last night in 
the actual Great Plains.  I'm sure CNN's got the crews on the ground to 
show the wreckage.

From PFSchaffner at umich.edu  Sun Apr 15 19:56:28 2012
From: PFSchaffner at umich.edu (Paul F. Schaffner)
Date: Sun, 15 Apr 2012 19:56:28 -0400 (EDT)
Subject: [tei-council] Examples of <head>s containing <l>
In-Reply-To: <4F8ABF6C.50205@retired.ox.ac.uk>
References: <4F89ED7B.3000403@oucs.ox.ac.uk>
	<543e7c7d-87ee-4e55-8f78-a7e0d5b4d3cd@HUB03.ad.oak.ox.ac.uk>,
	<CAA2irtLp8T5ayHA=iMaPJ86QM27=mKm9C4NikN2CiKDN9p0xDw@mail.gmail.com>
	<5585cf8f-9abd-4fc1-b025-618044daf329@HUB06.ad.oak.ox.ac.uk>
	<4F8ABF6C.50205@retired.ox.ac.uk>
Message-ID: <Pine.LNX.4.64.1204151954320.14120@punchout.gpcc.itd.umich.edu>

At Lou's request (in conversation).

http://www.lib.umich.edu/tcp/docs/dox/verse_in_head.html

Some (though not all) can be squeezed into <argument> rather
than <head>, but I think that the most natural tagging for
most, if not all, of these examples, is

<head>
<l>...</l>
<l>...</l>

See if you agree.

pfs
--------------------------------------------------------------------
Paul Schaffner | PFSchaffner at umich.edu | http://www.umich.edu/~pfs/
316-C Hatcher Library N, Univ. of Michigan, Ann Arbor MI 48109-1190
--------------------------------------------------------------------

From rwelzenbach at gmail.com  Mon Apr 16 09:11:35 2012
From: rwelzenbach at gmail.com (Rebecca Welzenbach)
Date: Mon, 16 Apr 2012 09:11:35 -0400
Subject: [tei-council] Fwd: TEI Council Face 2 Face Ann Arbor 2012 - Minutes
	(mholmes@uvic.ca)
In-Reply-To: <4F86C73C.5090503@uvic.ca>
References: <20cf305495f3df5d8e04bd79f030@google.com>
	<4F86C73C.5090503@uvic.ca>
Message-ID: <CAA2irt+xnEPkPzymb_kfSxjhy55Nx_SQ0FP6a=-teG5F97kRjg@mail.gmail.com>

Here's the link to the "minutes" google doc


---------- Forwarded message ----------
From: Martin Holmes <mholmes at uvic.ca>
Date: Thu, Apr 12, 2012 at 8:14 AM
Subject: Re: TEI Council Face 2 Face Ann Arbor 2012 - Minutes (mholmes at uvic.ca)
To: "James Cummings (Google Docs)" <james at blushingbunny.net>
Cc: "rwelzenb at umich.edu" <rwelzenb at umich.edu>


Tested and working.

On 12-04-12 04:48 AM, James Cummings (Google Docs) wrote:
>
> ? ? ? ?I've shared TEI Council Face 2 Face Ann Arbor 2012 - Minutes
> <https://docs.google.com/document/d/15kJ22QBO6B5M_YuMHUD3_cLE3rOFU_wkCkugwvWl6-4/edit>
>
> Click to open:
>
> ?* TEI Council Face 2 Face Ann Arbor 2012 - Minutes
> ? ?<https://docs.google.com/document/d/15kJ22QBO6B5M_YuMHUD3_cLE3rOFU_wkCkugwvWl6-4/edit>
>
>
> Google Docs makes it easy to create, store and share online documents,
> spreadsheets and presentations.
> Logo for Google Docs <https://docs.google.com>

From PFSchaffner at umich.edu  Mon Apr 16 19:08:03 2012
From: PFSchaffner at umich.edu (Paul F. Schaffner)
Date: Mon, 16 Apr 2012 19:08:03 -0400 (EDT)
Subject: [tei-council] SIGNED
Message-ID: <Pine.LNX.4.64.1204161906130.15944@punchout.gpcc.itd.umich.edu>

I've unearthed the three messages I sent to Council back in
November, not because they change the discussion much, but
because one of them at least contains numerous examples that
may serve as test cases for whatever scheme (if any) that
we end up adopting.

I'll reforward them to the list, and you may delete at your
pleasure

pfs

--------------------------------------------------------------------
Paul Schaffner | PFSchaffner at umich.edu | http://www.umich.edu/~pfs/
316-C Hatcher Library N, Univ. of Michigan, Ann Arbor MI 48109-1190
--------------------------------------------------------------------

From PFSchaffner at umich.edu  Mon Apr 16 19:08:18 2012
From: PFSchaffner at umich.edu (Paul F. Schaffner)
Date: Mon, 16 Apr 2012 19:08:18 -0400 (EDT)
Subject: [tei-council] signed/list (fwd)
Message-ID: <Pine.LNX.4.64.1204161908120.15944@punchout.gpcc.itd.umich.edu>



--------------------------------------------------------------------
Paul Schaffner | PFSchaffner at umich.edu | http://www.umich.edu/~pfs/
316-C Hatcher Library N, Univ. of Michigan, Ann Arbor MI 48109-1190
--------------------------------------------------------------------

---------- Forwarded message ----------
Date: Mon, 21 Nov 2011 18:33:43 -0500 (EST)
From: Paul F. Schaffner <PFSchaffner at umich.edu>
To: Lou Burnard <lou.burnard at retired.ox.ac.uk>
Cc: "tei-council at lists.village.virginia.edu"
     <tei-council at lists.village.virginia.edu>
Subject: Re: [tei-council] signed/list

On Sat, 19 Nov 2011, Lou Burnard wrote:

> Hi Paul
> 
> On 19/11/11 00:02, Paul F. Schaffner wrote:
>
>>    -- to be honest, the 'narrow' definition just doesn't make
>>       any sense to me, for reasons I have explained before,
>>       and virtually impossible to apply.
> 
> I'm curious as to what makes you say that, and apologetic for having 
> forgotten your previous explanation.

Lou,

   My difficulty was that I could find no ready way
to distinguish -- or rationale for distinguishing --
those phrases descriptive of the signer which belonged
in signed from those that did not.

   Here is a reprint of part of my message on the subject
from September of 2010, which I think explains the problem
as I saw it.

---snip---

I think there were a few factors ...
that led to our interpretation of <signed> as a container
for all the 'yours truly' sort of phrases (to my mind, 'signing
phrases,' not 'greeting phrases'). The most important
was perhaps that in writing instructions for data-conversion
firms,  I could find no tenable rule by which to tell them to
distinguish between many grammatically and semantically similar
constructions, as splitting them between <signed> and <salute>
seemed to require. E.g.:

(1) Everyone agrees (I think) that the first three examples below
belong entirely in <signed>. But I could see no essential difference
between those and the fourth and fifth examples, which some would
divide between <signed> and <salute>:

#1 <CLOSER>
<SIGNED>John</SIGNED>
</CLOSER>

#2 <CLOSER>
<SIGNED>John, lieutenant of the Tower</SIGNED>
</CLOSER>

#3 <CLOSER>
<SIGNED>John, lieutenant of the Tower and servant of God</SIGNED>
</CLOSER>

#4 <CLOSER>
<SIGNED>John, lieutenant, etc., and your obedient servant</SIGNED>
</CLOSER>

#5 <CLOSER>
<SIGNED>Your obedient servant, John, lieutenant of the Tower.</SIGNED>
</CLOSER>


(2) Likewise, I could see no essential difference between phrases,
all descriptive of the signatory, that happened to refer to the
addressee and those that did not. I gather that some would put
the former (#2 below) in <salute> but not the latter (#1 below).
Nor could I see what to do--or how to tell my keyers what to do--when both
kinds of phrases were combined (#3 below).

#1 <CLOSER>
<SIGNED>A Public Servant</SIGNED>
</CLOSER>

#2 <CLOSER>
<SIGNED>Your obedient Servant</SIGNED>
</CLOSER>

#3 <CLOSER>
<SIGNED>A Friend to Humanity and to your Welfare</SIGNED>
</CLOSER>


-- Someone in this thread suggested that every <signed> must contain
     a name (or at least a nom de plume). We tag many abbreviated ones
     that do not, usu.of the form <signed>Yours truly, &c.</signed>
     Surely this falls under the definition of <signed> as 'a closing
     salutation'!


-- Below is a random and generous selection of <signed> tags
     (and a few <salute>s) from the 5,546 found in my current
     review batch. Tag them as you will! See how much variety,
     or unanimity, arises (n.b., you will see that we allow <list> within
     <signed>,  a local customization.)


pfs


Samples
=======

<SIGNED>Jeremiah Rich.</SIGNED>

<SIGNED>Yours (desirous particularly to be engaged yours
to serve you,) <HI>JOHN LILBURN.</HI></SIGNED>

<SIGNED>Your assured loving friend and servant,
EDWARD WOLBY.</SIGNED>

<SIGNED>A Faithfull Servant to all Lovers of
<HI>Musick,</HI> JOHN PLAYFORD.</SIGNED>

<SIGNED><HI>Your Lordship</HI>'s <HI>most Faithful and
most Obedient Servant,</HI> Stephen Willoughby.</SIGNED>

<SIGNED>Your servant till Death. <HI>Captaine</HI>
John  Williams.</SIGNED>

<SIGNED>From a Sufferer for the Truth and Righteousness sake,
known to many of you by the Name of <HI>Isabel Wails.</HI>
</SIGNED>

<SIGNED><HI>Jo. Radford</HI> Foreman of the Mineral
Grand Jury there, with his fellows.
<LIST>
<ITEM><HI>Walter Webb.</HI></ITEM>
<ITEM><HI>Richard Franke.</HI></ITEM>
<ITEM><HI>Richard Adams.</HI></ITEM>
<ITEM><HI>Jahn Phelps.</HI></ITEM>
<ITEM><HI>Thomas Younge.</HI></ITEM>
<ITEM><HI>William Dowling.</HI></ITEM>
<ITEM><HI>Alexandor Cuer.</HI></ITEM>
<ITEM><HI>William Hopkins.</HI></ITEM>
<ITEM><HI>Jonas Lexstond.</HI></ITEM>
<ITEM><HI>John House.</HI></ITEM>
<ITEM><HI>Richard Ayrer.</HI></ITEM>
</LIST></SIGNED>


<SIGNED>A True Lover of his Countries Honour, <HI>W. W.</HI>
</SIGNED>

<SIGNED><HI>Your most affectionately devoted Brethren in Christ,</HI>
<LIST>
<ITEM>Commissioners of the Church of <HI>Scotland.</HI>
     <LIST>
     <ITEM><HI>Jo. Maitland,</HI></ITEM>
     <ITEM><HI>A. Jhonston,</HI></ITEM>
     <ITEM><HI>Alex. Henderson,</HI></ITEM>
     <ITEM><HI>Sam. Rutherfurd,</HI></ITEM>
     <ITEM><HI>Rob. Bailyie.</HI></ITEM>
     <ITEM><HI>Geo. Gillespie.</HI></ITEM>
     </LIST>
</ITEM>
<ITEM><HI>William Twisse,</HI> Prolocutor,</ITEM>
<ITEM><HI>Cornel. Burges,</HI> Assessor,</ITEM>
<ITEM><HI>Jo. White,</HI> Assessor,</ITEM>
<ITEM><HI>Henry Robrough,</HI> Scribe,</ITEM>
<ITEM><HI>Adoniram Byfield,</HI> Scribe.</ITEM>
</LIST></SIGNED>

<SIGNED>H. Elsynge, Cler. Parl. D. Com.</SIGNED>

<SIGNED>Wholly and intirely your most affectionate
Kinsman and humble servant. <HI>F. W.</HI></SIGNED>

<SIGNED>Thy most Affectionate and Faithful Husband,
and their most loving Father, <HI>J. H.</HI></SIGNED>

<SIGNED>Thy souls well-wisher, <HI>Richard Kentish.</HI></SIGNED>

<SIGNED><LIST>
<ITEM><HI>Adam Samuel Hartman,</HI> Pastor of the Church of <HI>Lesna</HI>
in <HI>Poland,</HI> and Rector of the famous University there.</ITEM>
<ITEM><HI>Paul Cyril</HI> a late Member of the Univer&s;ity of
<HI>Ly&s;na.</HI></ITEM></LIST></SIGNED>

<SALUTE>SIR,</SALUTE>
<SIGNED>An Admirer of your indefatigable industry and rare
abilities, JOHN TRAPP.</SIGNED>

<DATELINE>Written in the true fear of the Lord,</DATELINE>
<SIGNED>by me his Servant, Anthony Tompkins.</SIGNED>
<DATELINE><DATE>The 2d day of the 11th Moneth, 68.</DATE></DATELINE>


<SIGNED>Yours, The Inhabitants of the County of Rutland.</SIGNED>

<DATELINE>Written in <HI>York</HI> Castle,</DATELINE>
<SIGNED>by your dear Brother, and lover of your souls, known unto
you by the name of <HI>Samuel Thornton.</HI></SIGNED>

<SIGNED>Your Maiesties faithfull Subiects and Servants.
<LIST>
<ITEM>Earle <HI>Lothian.</HI></ITEM>
<ITEM>Earle <HI>Lindesay.</HI></ITEM>
<ITEM>Lord <HI>Balmerino.</HI></ITEM>
<ITEM>Sir <HI>Thomas Morton.</HI></ITEM>
<ITEM>Sir <HI>Thomas Hope.</HI></ITEM>
<ITEM>Sir <HI>Archibauld Johnston</HI></ITEM>
<ITEM>Burgesses.</ITEM>
<ITEM>Sir <HI>Iohn Smith.</HI></ITEM>
<ITEM>Master <HI>Robert Barklay.</HI></ITEM>
<ITEM>Master <HI>Patrick Bell.</HI></ITEM>
</LIST></SIGNED>

<SALUTE>VALE LECTOR, &amp; fruere.</SALUTE>

<SALUTE>Adieu Madam.</SALUTE>

<SIGNED>Your Servant, <HI>&amp;c.</HI></SIGNED>

<SIGNED>So help me God. <HI>DANIEL SCARGILL.</HI></SIGNED>

<SIGNED>Your sorrowfull friend, and brother in Christ,
<HI>Thomas Sweet.</HI></SIGNED>

<SIGNED>Your Worships affectionate Kinsman and Servant.</SIGNED>

<SIGNED>Your Lordship's Most Passionate Admirer And Most Devoted
Humble Servant.</SIGNED>

<SIGNED>Your true friend and Cosen, <HI>Nathanael
Warters.</HI></SIGNED>

<SIGNED>We subscribe our selves,
Your Brethren in the Faith and Fellowship of the Gospel,
<LIST>
<ITEM><HI>William Kiffin,</HI></ITEM>
<ITEM><HI>George Barrett,</HI></ITEM>
<ITEM><HI>Robert Steed,</HI></ITEM>
<ITEM><HI>Edward Man.</HI></ITEM>
</LIST></SIGNED>

<SIGNED>Thine to serve thee for the Publike good, G.  A.</SIGNED>

<SALUTE>>MY LORD!</SALUTE>
<SIGNED>Your <HI>Highness,</HI> though unknown, yet most
humble servant.</SIGNED>

<SIGNED><HI>From thy Friend, and all Peoples, In Sincerity
and Truth,</HI> Thomas Rudd.</SIGNED>

<SIGNED><HI>one</HI> of the meanest of Your Servants for
Christ, and this Commonwealth. <HI>JO. ROGERS.</HI></SIGNED>


<SIGNED>Your affectionate fellow Apprentices of Bridge
Ward within.</SIGNED>
<DATELINE><HI>Dated</HI> <DATE>the 17 <HI>of</HI> May, 1649. <HI>the
first year of Englands hopeful Restauration, through the blessing of
God, to its primitive Liberty.</HI></DATE></DATELINE>


<SALUTE>My Lord, </SALUTE>
<SIGNED><HI>Your Most Humble and Most Obedient Servants,
the Agents General of the Clergy of</HI> France. <HI>The Abbot</HI>
de VILLARS. <HI>The Abbot</HI> PHILYPEA&V;X.</SIGNED>
<DATELINE><HI>Paris</HI> <DATE>this <HI>2d. of</HI> October,
<HI>1688.</HI></DATE></DATELINE>

<SIGNED>By the Contriver of the Citizens Protestation,
here following.</SIGNED>

<SIGNED><HI>Yours unfeignedly, in the right way of the Gospel
to serve you faithfully, according to my measure in the things
of Jesus Christ,</HI> THO: LAMBE.</SIGNED>


<SALUTE>(SIR,)</SALUTE>
<SIGNED>Your most affectionate Friend, heartily to serve you
[being yet as much an English man as ever I was] <HI>JOHN LILBURN,
Semper idem</HI></SIGNED>
<DATELINE>From my delightfull dwelling in Bruges,
<DATE>Saturday, Novemb. the 9. 1652. New stile.</DATE></DATELINE>
<TRAILER>The End.</TRAILER>


<SIGNED><HI>I subscribe myself Your Fellow-Citizen,</HI>
A FRIEND TO HUMANITY.</SIGNED>

<SIGNED>Your servant, S--l C--h, forever.</SIGNED>

<SIGNED>THOMAS GORDON, Attorney in fact for WILLIAM
CUNNINGHAM &amp; Co.</SIGNED>

<SIGNED>WM. GIBBONS, <HI>President and Delegate from Chatham.</HI>
</SIGNED>

<SIGNED>Thomas Gozaeus a Bellomonte, sacrae Theologiae
Professor, &amp; authoritate Pontificis librorum approbator.</SIGNED>

<SIGNED>Your Honours obliged servant though unworthiest
among the Ministers of Christ. <HI>THO. MARRIOT.</HI></SIGNED>



From PFSchaffner at umich.edu  Mon Apr 16 19:08:28 2012
From: PFSchaffner at umich.edu (Paul F. Schaffner)
Date: Mon, 16 Apr 2012 19:08:28 -0400 (EDT)
Subject: [tei-council] signed/list (fwd)
Message-ID: <Pine.LNX.4.64.1204161908220.15944@punchout.gpcc.itd.umich.edu>



--------------------------------------------------------------------
Paul Schaffner | PFSchaffner at umich.edu | http://www.umich.edu/~pfs/
316-C Hatcher Library N, Univ. of Michigan, Ann Arbor MI 48109-1190
--------------------------------------------------------------------

---------- Forwarded message ----------
Date: Mon, 21 Nov 2011 19:21:49 -0500 (EST)
From: Paul F. Schaffner <PFSchaffner at umich.edu>
To: Lou Burnard <lou.burnard at retired.ox.ac.uk>
Cc: "tei-council at lists.village.virginia.edu"
     <tei-council at lists.village.virginia.edu>
Subject: Re: [tei-council] signed/list

Of course the *other* inconsistency with <signed> is between the
prose definition ('closing salutation') and the scheme, which
allows it in both div.top and div.bottom. We followed the scheme
rather than the prose which (given the variety of epistolary
form, among other things) seemed the reasonable course. And it
allows us to break formulaic openers like these into <signed> and
<salute> blocks:

<OPENER>
<SIGNED>JAMES the Second, By the Grace of God, King of England, Scotland,
France and Ireland, Defender of the Faith, &amp;c.</SIGNED>
<SALUTE>TO ALL and Singular Archbishops, Bishops, Archdeacons, Deans, and
their Officials, Parsons, Vicars, Curates, and all other Spiritual
Persons: And also to all Iustices of the Peace, Mayors, Sheriffs,
Bayliffs, Constables, Churchwardens, Chappelwardens, Headboroughs,
Collectors for the Poor, and their Overseers: And also to all Officers of
Cities, Boroughs, and Towns Corporate, and to all other Our Officers,
Ministers and Subjects whatsoever they be, as well within Liberties as
without, to whom these Presents shall come, Greeting.</SALUTE>
</OPENER>

pfs

From PFSchaffner at umich.edu  Mon Apr 16 19:08:46 2012
From: PFSchaffner at umich.edu (Paul F. Schaffner)
Date: Mon, 16 Apr 2012 19:08:46 -0400 (EDT)
Subject: [tei-council] signed/list (fwd)
Message-ID: <Pine.LNX.4.64.1204161908380.15944@punchout.gpcc.itd.umich.edu>



--------------------------------------------------------------------
Paul Schaffner | PFSchaffner at umich.edu | http://www.umich.edu/~pfs/
316-C Hatcher Library N, Univ. of Michigan, Ann Arbor MI 48109-1190
--------------------------------------------------------------------

---------- Forwarded message ----------
Date: Tue, 22 Nov 2011 16:47:08 -0500 (EST)
From: Paul F. Schaffner <PFSchaffner at umich.edu>
To: Lou Burnard <lou.burnard at retired.ox.ac.uk>
Cc: "tei-council at lists.village.virginia.edu"
     <tei-council at lists.village.virginia.edu>
Subject: Re: [tei-council] signed/list

Yes, that is a good summary. And I know that there are still
ambiguous and intermingled cases -- but I find that this
approach reduces them to a manageable number.

I suspect that (multiple signatories aside), we are not that
far apart: it is just that I have come to regard 'your servant'
'your darling John' etc. as, in effect, part of the signer's
name -- name in the sense of 'self-designation' -- not different
in kind from 'dei gratia rex angliae'.

pfs



On Tue, 22 Nov 2011, Lou Burnard wrote:

> Many thanks for this florilegium ... which entirely persuades me (if there 
> were any doubt) that the current statements in the Guidelines about the 
> intended usage of these elements are in serious need of revision.
> 
> Leaving aside syntactic questions, would it be fair to say that for you at 
> least the distinction between "signature" and "salute" is that the latter is 
> always in the vocative -- it is ostensibly addressed to someone -- while the 
> former is always (is there such a word?) "presentative" -- it always 
> ostensibly presents the identity of the writer or signatory ?
> 
> This seems a plausible distinction, but even there it's easy to imagine (or 
> to find) cases where the two are almost inextricably mixed.
> 
> I am (dear sir) your very humble servant
> 
> Lou
> 
> p.s. and I apologise again for not having paid more attention to your note 
> back in september 2010 -- it was obviously too interesting to deal with at 
> the time
> 
>
>     On 21/11/11 23:33, Paul F. Schaffner wrote:
> 
> 
>

--------------------------------------------------------------------
Paul Schaffner | PFSchaffner at umich.edu | http://www.umich.edu/~pfs/
316-C Hatcher Library N, Univ. of Michigan, Ann Arbor MI 48109-1190
--------------------------------------------------------------------

From James.Cummings at oucs.ox.ac.uk  Mon Apr 16 22:33:25 2012
From: James.Cummings at oucs.ox.ac.uk (James Cummings)
Date: Mon, 16 Apr 2012 22:33:25 -0400
Subject: [tei-council] per diem rate for Council meetings
In-Reply-To: <35D067FC-AF14-4708-90EE-4A7FBE6C1BBC@virginia.edu>
References: <35D067FC-AF14-4708-90EE-4A7FBE6C1BBC@virginia.edu>
Message-ID: <4F8CD675.9080505@oucs.ox.ac.uk>


Dear Council,

Several of you asked me to check that the rates I had mentioned 
were correct.  I've not emailed Sarah again, but here is her 
original message below.  I might note that Breakfast is included 
with the hotel, so perhaps that amount of money might be used 
towards dinner.

I've included the same system's rates for Oxford demonstrating 
that the state department eats well when abroad and barely when 
in Ann Arbor.

-James

-------- Original Message --------
Subject: 	Re: [tei-council] per diem rate for Council meetings
Date: 	Fri, 11 Nov 2011 17:12:22 +0000
From: 	Sarah Wells <spw4s at virginia.edu>
To: 	James Cummings <james.cummings at oucs.ox.ac.uk>


Dear James,

For Ann Arbor, 70% of $56 = $39
Breakfast | 25% = $10
Lunch | 35% = $14
Dinner | 40% = $15

For Oxford, 70% of $177 = $124
Breakfast | 25% = $30
Lunch | 35% = $44
Dinner | 40% = $50

Yrs,
Sarah




From PFSchaffner at umich.edu  Tue Apr 17 08:43:41 2012
From: PFSchaffner at umich.edu (Paul F. Schaffner)
Date: Tue, 17 Apr 2012 08:43:41 -0400 (EDT)
Subject: [tei-council] floating divs
In-Reply-To: <Pine.LNX.4.64.1204161908380.15944@punchout.gpcc.itd.umich.edu>
References: <Pine.LNX.4.64.1204161908380.15944@punchout.gpcc.itd.umich.edu>
Message-ID: <Pine.LNX.4.64.1204170843150.8707@punchout.gpcc.itd.umich.edu>

Hastily assembled examples, not the best and mostly (Martin's
favorite) songs in drama.

<STAGE>Arrived at the Scene againe and meaning to reascend, 
<HI>MERCVRY</HI> finding some impedi|ment
<PB N="7" REF="5">
by the way of question adresses himselfe to the Company.</STAGE>
<P><TEXT>
<BODY>
<DIV1 TYPE="song">
<HEAD>The third Song.</HEAD>
<SP>
<SPEAKER>MERCVRY.</SPEAKER>
<L>What mak's me so vnnimbly ryse,</L>
<L>That did descend so fleete?</L>
<L>There is no vp-hill in the skyes;</L>
<L>Clouds stay not feathered feete.</L>
</SP>
<SP>
<SPEAKER>CHORVS.</SPEAKER>
<L>Thy wings are sing'd: and thou canst fly</L>
<L>But slowly now, swift <HI>MERCVRY.</HI></L>
</SP>
<SP>
<SPEAKER>MERCVRY.</SPEAKER>
<L>Some Lady heere, is sure too blame</L>
<L>That from Loves starry skyes,</L>
<L>Hath shot some Beame, or sent some flame,</L>
<L>Like Lghtning, from her Eyes.</L>
</SP>
<SP>
<SPEAKER>CHORVS.</SPEAKER>
<L>Taxe not the Starrs, with what the Sunne,</L>
<L>Too neere aproch't (insens't) hath done.</L>
</SP>
<SP>
<SPEAKER>MERCVRY.</SPEAKER>
<L>I'le rowle me in Auroras Dew,</L>
<L>Or lye in Tethis bed;</L>
<L>Or from coole Iris begge a few,</L>
<L>Pure Opale shewrs new shed.</L>
</SP>
<SP>
<PB N="8" REF="6">
<SPEAKER>CHORVS.</SPEAKER>
<L>Nor Dew, nor shewers, nor sea can slake</L>
<L>Thy quenchlesse heate, but Lethes lake.</L>
</SP>
</DIV1>
</BODY>
</TEXT></P>
</DIV2>
</DIV1>
<DIV1 TYPE="scene">


------------------


I will propound an Obiection, which seemeth
to make for the Papists, at least in Popish sence and mea|ning.</P>
<P><TEXT LANG="eng">
<BODY>
<DIV1 TYPE="objection">
<HEAD>The Obiection.</HEAD>
<P>Two <HI>adequate</HI> bodies may be in one place at once, and yet
neither the place be deuided into two places, nor yet the


<PB N="53" REF="33" MS="y">
bodies transformed or confounded into one body: Ergo,
&agrave; <HI>simili,</HI> one body may be in two places at once (as 
Christs
body in many thousand Altars at popish Masse,) and yet
neyther the body deuided into two places, neyther the
two places contracted into one.</P>
</DIV1>
</BODY>
</TEXT></P>
</SP>
<SP>
<SPEAKER>T. B.</SPEAKER>
<P>When you (O Iesuite) shall be able to proue the Ante|cedent,
which will be <HI>ad Calendas Graecas,</HI> when men vse to
clip Pigges and Rats) I will yeeld vnto you.</P>
</SP>


------------------


<SP>
<SPEAKER>Ai.</SPEAKER>
<P>Why the Devil don't you then? Gad, I fancy you are as fond of being 
ask'd as I. Why, you &s;ing almo&s;t as well as I do. Come, let's &s;ing 
the la&s;t Dialogue our Ma&s;ter &s;et.</P>
</SP>
<P><TEXT>
<BODY>
<DIV1 TYPE="song">
<HEAD>DIALOGUE.</HEAD>
<SP>
<SPEAKER>Man.</SPEAKER>
<L>Hark you, Madam, can't I move you? </L>
<L>why the Devil do you run?</L>
<L><PB N="42" REF="28">Ha'n't I told you twice I love you? </L>
<L>come then, ki&s;s me, or I'm gone.</L>
</SP>
<SP>
<SPEAKER>Wom.</SPEAKER>
<L>Foh! I hate a Raki&s;h Lover, </L>
<L>Do not di&s;compo&s;e my Dre&s;s:</L>
<L>Good familiar Spark, give over! </L>
<L>how on Quality you pre&s;s!</L>
</SP>
<SP>
<SPEAKER>Man.</SPEAKER>
<L>From the Counte&s;s to the Cit, </L>
<L>ev'ry Beauty for me dies:</L>
<L>Demme, why &s;hould I &s;ubmit</L>
<L> to do at on <HI>this</HI> Woman's Eyes!</L>
</SP>
<SP>
<SPEAKER>Wom.</SPEAKER>
<L>Fifty Beaux expire for me, </L>
<L>ogling, &s;ighing all the Day;</L>
<L>Yet not one dares be &s;o free, </L>
<L>tho they let me win at Play.</L>
</SP>
<SP>
<SPEAKER>Man.</SPEAKER>
<L>Sure we Rakes can better move you; </L>
<L>&s;ee this Shape and Leg, my Dear!</L>
<L>In one Minute more I'll love you </L>
<L>than tho&s;e Fops can in a Year.</L>
</SP>
<SP>
<SPEAKER>Wom.</SPEAKER>
<L>But your Love will &s;oon be over.</L>
</SP>
<SP>
<SPEAKER>Man.</SPEAKER>
<L>Then you'll get a fre&s;her Lover.</L>
<L>Come, to Bed! I long t'embrace.</L>
</SP>
<SP>
<SPEAKER>Wom.</SPEAKER>
<L>Leave my Hand!</L>
</SP>
<SP>
<SPEAKER>Man.</SPEAKER>
<L>&mdash;Then lend your Face!</L>
<L>Fir&s;t the Hand, and then the Face,</L>
<L>Then the Brea&s;t,</L>
<L>And then the re&s;t,</L>
<L>Then the Breast, and then&mdash;</L>
</SP>
<SP>
<SPEAKER>Wom.</SPEAKER>
<L>&mdash;The Face.</L>
</SP>
<STAGE>Gives him a &s;lap 'othe Face.</STAGE>
<SP>
<SPEAKER>Man.</SPEAKER>
<L>'s Death, I've a good mind to beat you;</L>
<L>No; to vex you more, I'llgo.</L>
<L>Thus I puff you&mdash;I'll go &s;ay,</L>
<L>I refus'd your Love to Day.</L>
</SP>
<SP>
<SPEAKER>Wom.</SPEAKER>
<L>Then I'll &s;ay how I did treat you.</L>
</SP>
<STAGE>Both together</STAGE>
<SP>
<SPEAKER> Man.</SPEAKER>
<L>None will believe you cou'd do &s;o.</L>
</SP>
<SP>
<SPEAKER>Wom.</SPEAKER>
<L>All will believe I us'd you &s;o.</L>
</SP>
</DIV1>
</BODY>
</TEXT></P>
<SP>
<PB N="43" REF="28">
<SPEAKER>Ai.</SPEAKER>
<P>Pretty well, pretty well, all but that damn'd Slap on the 
Face&mdash;Well, I &s;hall run mad for you in Two Days, that's 
certain.</P>
</SP>


--------------


<STAGE>Enter Mr. <HI>Redding</HI> in a Smith's Habit, a Bottle in his 
hand. He &s;ings; &s;eemingly drunk.</STAGE>
<P><TEXT>
<BODY>
<DIV1 TYPE="song">
<HEAD>SONG.</HEAD>
<SP>
<SPEAKER>Man.</SPEAKER>
<L>SHou'd I not lead a happy Life&punc; </L>
<L>Were but my Bottle like my Wife! </L>
<L>My Bottle empties when I &s;will, </L>
<L>But my Wife &s;wells up when we bill.</L>
<L><PB N="19" REF="16">Wou'd (when I drink) my Bottle fill, </L>
<L>And (when I ki&s;s) my Wife not &s;well, </L>
<L>All wou'd be well: </L>
<L>I wou'd &s;o bill, </L>
<L>So fill, &s;o &s;will,</L>
<L> That daily gaily I wou'd &s;pend my Life, </L>
<L>Sucking, filling, </L>
<L>Hugging, billing, </L>
<L>My merry Bottle and my Wife.</L>
</SP>
<STAGE> Drinks; then throws away his Bottle, and takes up a Quart 
Pot.</STAGE>
<STAGE> <HI>Enter Mr.</HI> Lee <HI>dre&s;t as the Smith's Wife and 
big-bellied.</HI></STAGE>
</DIV1>
<DIV1 TYPE="song">
<HEAD>DIALOGUE.</HEAD>
<SP>
<SPEAKER>Wom.</SPEAKER>
<L>STill at your Pot, </L>
<L>You drunken Sot? </L>
<L>You till I come </L>
<L>Will ne're go home; </L>
<L>And when you're there, </L>
<L>You cur&s;e and &s;wear; </L>
<L>Then prove a Bed </L>
<L>A lump of Lead.</L>
</SP>
<SP>
<SPEAKER>Man.</SPEAKER>
<L>D' you think, you Scold, </L>
<L>I'll be controul'd? </L>
<L>No more be &s;aid: </L>
<L>Or at your Head, </L>
<L>As I'm a Sot, </L>
<L>Sou&s;e flys the Pot! </L>
<L>But fir&s;t, I think, </L>
<L>I'll &s;ave the Drink.</L>
</SP>
<STAGE>Drinks.</STAGE>
<SP>
<SPEAKER>Wom.</SPEAKER>
<L>Hold, leave a &s;up, </L>
<L>Don't drink all up.</L>
</SP>
<SP>
<SPEAKER>Man.</SPEAKER>
<L>Here, ta&s;te and know </L>
<L>Why I'll not go.</L>
</SP>
<STAGE>He gives her the Drink, &s;he drinks.</STAGE>
<SP>
<PB N="20" REF="17">
<SPEAKER>Wom.</SPEAKER>
<L>How &s;weet! oh how it chears my heart!</L>
<L>O dear! methinks I &s;uck my Mother.</L>
<L>Here's t'you, my Love! have t' other Quart, </L>
<L>And then&mdash;</L>
</SP>
<SP>
<SPEAKER>Man.</SPEAKER>
<P>&mdash;What then?</P>
</SP>
<SP>
<SPEAKER>Wom.</SPEAKER>
<L>&mdash;And then another.</L>
</SP>
<SP>
<SPEAKER>Both.</SPEAKER>
<L>Come, now we're Friends, and all is right.</L>
</SP>
<SP>
<SPEAKER>Man.</SPEAKER>
<L>Drink, drink all day:</L>
</SP>
<SP>
<SPEAKER>Wom.</SPEAKER>
<L>&mdash;&mdash;&mdash;But love at night.</L>
</SP>
<SP>
<SPEAKER>Both.</SPEAKER>
<L>Drink, drink all day, but love at night.</L>
</SP>
<STAGE>Both going off lovingly.</STAGE>
</DIV1>
</BODY>
</TEXT></P>
<SP>
<SPEAKER>Sir Top.</SPEAKER>
<P>Now this is &s;omething like a Tanzy: here Friends, there's a couple of 
Shillings for you to drink.</P>
</SP>


---------------


<P>So I de&s;ire all you that be Schollars, that either reads it, or hears 
it read, let it be a good in&s;truction for you all, in the fir&s;t place 
to
<PB N="19" REF="11">
learn to &s;erve God: &s;econdly, to give honour and obedience to thy 
Parents: thirdly, let not thy heart over-&s;lip th&eacute;e with <GAP 
DESC="illegible" RESP="apex" EXTENT="1 letter">nvy and ha|tred towards thy 
Neighbour; but be always ready with diligence to do any thing for them 
which lyeth in thy power to do; not wrong|ing thy Parents nor thy &s;elf. 
The duty of a Scholar is, if thou m&eacute;et any man or woman in the 
&s;tr&eacute;et, thou art to carry thy &s;elf very ci|villy, to put off 
thy hat, and to give them the time of the day, for in &s;o doing thou 
&s;hewe&s;t thy br&eacute;eding: more-over there will be &s;ome &s;ign of 
grace in thy old age, for as y^e Scripture &s;aith, <HI>Train up a child 
in the way he &s;hould go and when he is old he will not depart from 
it.</HI> And I pray God give every child grace to lead his life in his 
youth, that he may have joy and comfort both in this world, and in the 
world to come without end, <HI>Amen.</HI></P>
<P>A &s;hort Prayer for every Schollar to learn every morning before he 
goes to School, o<GAP DESC="illegible" RESP="apex" EXTENT="1 letter"> 
beginneth any labour, then after this y^e Lord<GAP DESC="illegible" 
RESP="apex" EXTENT="1 letter"> Prayer.</P>
<FLOATEXT LANG="eng" TYPE="prayer">
<HEAD>A Prayer for the morning.</HEAD>
<P>O Mo&s;t gracious Lord God; thou that &s;itte<GAP DESC="illegible" 
RESP="apex" EXTENT="1 letter"> upon thy throne, and &s;ee&s;t into all the 
co<GAP DESC="illegible" RESP="apex" EXTENT="1 letter">+ners
<PB N="20" REF="12">
of the World; thou mad'&s;t the heaven and the earth, and all things 
belonging thereto: thou art a God of mercy, thou art a God of favour and 
love; and even &s;o thou art a God of ju&s;t<GAP DESC="illegible" 
RESP="apex" EXTENT="1 letter">ce and wrath, yet &s;low to anger, or el&s;e 
what would become of poor &s;inners; O Lord, I do give thee humble and 
hearty thanks for this good ble&s;&s;ing which thou ha&s;t be&s;towed upon 
me this night pa&s;t, in giving me &s;uch quiet re&s;t and &s;leep; O Lord 
I confe&s;s thou mighte&s;t have made my bed of ea&s;e a bed of death: But 
O Lord, &s;eeing it hath plea&s;ed thee to pre&s;erve my life a little 
lon|ger: &s;o O Lord I do de&s;ire thee out of thy ten|der mercy to give 
me this day, a heart of true Repent<GAP DESC="illegible" RESP="apex" 
EXTENT="1 letter">nce, that I may truely repent me of my &s;ins, and 
lament for all my tran&s;gre&s;&s;ions. O God thou knowe&s;t the fle&s;h 
of man is weak and frail, yet we know thou art able to put &s;trength into 
the weake&s;t &s;oul: therefore I be&s;eech thee out of thy tender mercy 
for to &s;trengthen my faith; put grace and wi&s;dome into my heart, that 
I may do nothing but what is plea&s;ing to thy &s;ight. And gr<GAP 
DESC="illegible" RESP="apex" EXTENT="1 letter">nt O mo&s;t merciful 
Father, that what&s;oever. I &s;hall think, or &s;peak, or take in hand, 
it may tend to thy glory the good of my friends and neigh|bours&punc; and 
for the joy and comfort of my poor &s;oul, and that for thy Son, our Lord 
and Saviours &s;ake, I will farther call upon thee, in that mo&s;t
<PB N="21" REF="12">
holy and perfect prayer which thou taught thy Di&s;ciples, in that holy 
place of Scripture, <HI>Mat.</HI> 6. 9. where he &s;aid to his Di&s;ciple, 
<HI><GAP DESC="illegible" RESP="apex" EXTENT="2 letters"> you pray, pray 
thus, &s;aying,</HI> Our Father, &amp;c.</P>
</FLOATEXT>
<P><HI>La&s;tly, when thou ha&s;t &s;pent the day, call into thy mind how 
thou ha&s;t &s;pent it; and if thou ha&s;t done any thing which thy 
con&s;ci|ence telleth th&eacute;e is not right, then fall on thy 
kn&eacute;es, and de&s;ire the Lord to forgive th&eacute;e, and that with 
a true heart, and then no doubt but the Lord will hear thy 
prayers.</HI></P>
<FLOATEXT LANG="eng" TYPE="prayer">
<HEAD>A &s;hort Prayer for the Evening.</HEAD>
<P>O Lord God, Heavenly Father, I be&s;eech thee hear my prayer, and let 
my cry come unto thee, con&s;ider my prayer, O Lord my God, lighten thou 
mine eyes, le&s;t I &s;leep the &s;leep of death, and &s;o be utterly 
lo&s;t: I cannot but confe&s;s I have &s;inned again&s;t thee: but O Lord 
I know thou art merciful, and will &s;hew mercy to all &s;uch as will 
con&s;e&s;s their faults, and truely repent them of their &s;ins, and 
&s;trive to for&s;ake their wicked ways, and turn to the Lord and live: 
therefore turn me O Lord, and I &s;hall be turned: make me to know the way 
to righteou&s;ne&s;s, and give me thy &s;piritual grace, that I may flye 
from the way of
<PB N="22" REF="13">
the wicked, and turn unto thee for &s;alvation: O Lord my God, and my 
redeemer; and as it hath plea&s;ed thee to give me this day liberty to 
follow my calling which thou ha&s;t called me unto, &s;o O Lord I 
be&s;eech thee to give me thy favour and countenance this night, &s;et 
thou a guard of An|gels about me, that no evil &s;pirit have power to 
entice my poor weak and &s;inful &s;oul, that by thy power and protection 
I may take quiet &s;leep, and re&s;t under the &s;hadow of thy wings, that 
when I &s;leep, I may not &s;leep unto death, but &s;leep unto life 
everla&s;ting, and all for thy Son our Lord and Saviour, in his words I 
pray farther, &s;aying:</P>
<P><HI>Our Father which art in heaven, hallowed be thy Name, thy Kingdom 
come, thy will be done on earth as it is in heaven, give us this day, our 
daily bread, and forgive us our tre&s;|pa&s;&s;es, as we forgive them that 
tre&s;pa&s;s a|gain&s;t us, and lead us not into temptation, but deliver 
us from evil,</HI> Amen.</P>
</FLOATEXT>



--------------------------------------------------------------------
Paul Schaffner | PFSchaffner at umich.edu | http://www.umich.edu/~pfs/
316-C Hatcher Library N, Univ. of Michigan, Ann Arbor MI 48109-1190
--------------------------------------------------------------------

From James.Cummings at oucs.ox.ac.uk  Tue Apr 17 14:03:38 2012
From: James.Cummings at oucs.ox.ac.uk (James Cummings)
Date: Tue, 17 Apr 2012 14:03:38 -0400
Subject: [tei-council] Fwd: Re: Council meals at Ann Arbor Meeting
In-Reply-To: <4F8D7025.5010203@virginia.edu>
References: <4F8D7025.5010203@virginia.edu>
Message-ID: <4F8DB07A.2070906@oucs.ox.ac.uk>

Just to forward on Sarah's latest message:

====
Hey there!  Group meals are no problem.  Kevin and/or Paul should 
submit
a receipt & a list of who attended the meal.  There are 
instructions for
that in the reimbursement form
(http://www.tei-c.org/Admin/TEI_travel_form.pdf).  And, of 
course, that
meal shouldn't be counted towards anyone else's expenses!

For the rate, we've used the 70% formula for other locations, but 
the
sticking point is probably that the other locations were non-U.S. 
  But,
if the reality is that daily meal costs are in fact closer to 
$56, then
I think we should use that.  The formula isn't really written in 
stone,
and while there is a time & a place for a $5 Subway sandwich for 
dinner,
this is perhaps not that time & place.  It would work out to:

For Ann Arbor,  $56
Breakfast | 25% = $14
Lunch | 35% = $20
Dinner | 40% = $22

If this still doesn't reflect reality in the mean streets of Ann 
Arbor,
we should revisit it.  Of course, we're assuming that you aren't 
having
hummingbird tongues for lunch and flamingo chops for dinner.  I 
mean, we
all know that the Council is where it's happening, so I kinda 
envision
you guys as hanging out in a biker bar, slurping down cheap beer &
burgers and comparing your tatoos. Right?

Yrs,
Sarah

From lou.burnard at retired.ox.ac.uk  Wed Apr 18 09:28:31 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Wed, 18 Apr 2012 14:28:31 +0100
Subject: [tei-council] Fwd: Important encoded information for the council...
Message-ID: <4F8EC17F.7080505@retired.ox.ac.uk>



-------- Original Message --------
Subject: 	Important encoded information for the council...
Date: 	Wed, 18 Apr 2012 15:23:26 +0200
From: 	Laurent Romary <laurent.romary at inria.fr>
To: 	Lou Burnard <lou.burnard at tge-adonis.fr>



<person>
<persName>
<forenametype="first">Nathan</forename>
<forenametype="middle">Zacharie</forename>
<surname>Alt</surname>
</persName>
<birthwhen="2012-04-18"/>
<sex>Male</sex>
</person>


Laurent Romary
INRIA & HUB-IDSL
laurent.romary at inria.fr <mailto:laurent.romary at inria.fr>




From gabriel.bodard at kcl.ac.uk  Wed Apr 18 09:32:32 2012
From: gabriel.bodard at kcl.ac.uk (Gabriel BODARD)
Date: Wed, 18 Apr 2012 14:32:32 +0100
Subject: [tei-council] Fwd: Important encoded information for the
	council...
In-Reply-To: <4F8EC17F.7080505@retired.ox.ac.uk>
References: <4F8EC17F.7080505@retired.ox.ac.uk>
Message-ID: <4F8EC270.1040701@kcl.ac.uk>

Brilliant. Congratulations, Laurent! (And welcome to the TEI Council, 
Nathan...)

On 18/04/2012 14:28, Lou Burnard wrote:
>
>
> -------- Original Message --------
> Subject: 	Important encoded information for the council...
> Date: 	Wed, 18 Apr 2012 15:23:26 +0200
> From: 	Laurent Romary<laurent.romary at inria.fr>
> To: 	Lou Burnard<lou.burnard at tge-adonis.fr>
>
>
>
> <person>
> <persName>
> <forename type="first">Nathan</forename>
> <forename type="middle">Zacharie</forename>
> <surname>Alt</surname>
> </persName>
> <birth when="2012-04-18"/>
> <sex>Male</sex>
> </person>
>
>
> Laurent Romary
> INRIA&  HUB-IDSL
> laurent.romary at inria.fr<mailto:laurent.romary at inria.fr>
>
>
>

-- 
Dr Gabriel BODARD
(Research Associate in Digital Epigraphy)

Department of Digital Humanities
King's College London
26-29 Drury Lane
London WC2B 5RL

Email: gabriel.bodard at kcl.ac.uk
Tel: +44 (0)20 7848 1388
Fax: +44 (0)20 7848 2980

http://www.digitalclassicist.org/
http://www.currentepigraphy.org/

From sebastian.rahtz at oucs.ox.ac.uk  Wed Apr 18 15:13:16 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Wed, 18 Apr 2012 19:13:16 +0000
Subject: [tei-council] 'ware massive change
Message-ID: <112EA18B-9AC2-43F5-BBCF-EADD2B7A9845@oucs.ox.ac.uk>

I have just changed everyone and his sister to switch from use of @version to @versionDate, as
per Council decision. this effects more or less every element/class/macro specification.

Sebastian

From sebastian.rahtz at oucs.ox.ac.uk  Wed Apr 18 15:15:07 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Wed, 18 Apr 2012 19:15:07 +0000
Subject: [tei-council] 'ware massive change
In-Reply-To: <112EA18B-9AC2-43F5-BBCF-EADD2B7A9845@oucs.ox.ac.uk>
References: <112EA18B-9AC2-43F5-BBCF-EADD2B7A9845@oucs.ox.ac.uk>
Message-ID: <7D85202C-7293-444F-9C1C-9F4FC32CE962@oucs.ox.ac.uk>


On 18 Apr 2012, at 15:13, Sebastian Rahtz wrote:

>  this effects more or less every element/class/macro specification.
> 

more obviously, it affects them as well

sebastian


From sebastian.rahtz at oucs.ox.ac.uk  Thu Apr 19 11:16:35 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Thu, 19 Apr 2012 15:16:35 +0000
Subject: [tei-council] f2f @ Ann Arbor
Message-ID: <6FB346F8-7E6A-439B-9CB7-795EA2904CE9@oucs.ox.ac.uk>

Just to record my thanks to Kevin, Becky and Paul for their exemplary hosting
this last week. The purchase of cushions sets a standard of care it will be hard
to surpass...
--
Stormageddon Rahtz      
Head of Information and Support Group
Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431

S?lo le pido a Dios
que el futuro no me sea indiferente


From mholmes at uvic.ca  Thu Apr 19 14:00:02 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Thu, 19 Apr 2012 11:00:02 -0700
Subject: [tei-council] f2f @ Ann Arbor
In-Reply-To: <6FB346F8-7E6A-439B-9CB7-795EA2904CE9@oucs.ox.ac.uk>
References: <6FB346F8-7E6A-439B-9CB7-795EA2904CE9@oucs.ox.ac.uk>
Message-ID: <4F9052A2.8070802@uvic.ca>

+1 from me. That was a great meeting. And special thanks for giving up 
your evenings to find us good food and eat with us.

Cheers,
Martin

On 12-04-19 08:16 AM, Sebastian Rahtz wrote:
> Just to record my thanks to Kevin, Becky and Paul for their exemplary hosting
> this last week. The purchase of cushions sets a standard of care it will be hard
> to surpass...
> --
> Stormageddon Rahtz
> Head of Information and Support Group
> Oxford University Computing Services
> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>
> S?lo le pido a Dios
> que el futuro no me sea indiferente
>

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From bansp at o2.pl  Thu Apr 19 17:09:51 2012
From: bansp at o2.pl (=?ISO-8859-2?Q?Piotr_Ba=F1ski?=)
Date: Thu, 19 Apr 2012 23:09:51 +0200
Subject: [tei-council] f2f @ Ann Arbor
In-Reply-To: <4F9052A2.8070802@uvic.ca>
References: <6FB346F8-7E6A-439B-9CB7-795EA2904CE9@oucs.ox.ac.uk>
	<4F9052A2.8070802@uvic.ca>
Message-ID: <4F907F1F.50803@o2.pl>

Come on, Martin: being so ultracool, we are all surely a reciprocal
superpleasure to eat with...

Many thanks from me as well to the UM team -- you've been terrific from
before it started (I appreciate the info on transportation and the hotel
arrangement, which is usually such a pain and this time it was just a
pleasure, and thank you, thank you for being so generous about using
your cards for us at the meals -- another headache not materializing).

But I would also like to acknowledge the extra work by Becky and Martin
on the minutes -- being mono-threaded attention-wise myself, and prone
to any distraction, I really admire people able to do this sort of work,
and so well at that.

Last but not least, thanks to James for managing the agenda to squeeze
out the last bit of efficiency from this meeting -- nice d?but there!

I've learned quite a bit during these three days, that feels really good.

Best,

  Piotr

On 19/04/12 20:00, Martin Holmes wrote:
> +1 from me. That was a great meeting. And special thanks for giving up 
> your evenings to find us good food and eat with us.
> 
> Cheers,
> Martin
> 
> On 12-04-19 08:16 AM, Sebastian Rahtz wrote:
>> Just to record my thanks to Kevin, Becky and Paul for their exemplary hosting
>> this last week. The purchase of cushions sets a standard of care it will be hard
>> to surpass...
>> --
>> Stormageddon Rahtz
>> Head of Information and Support Group
>> Oxford University Computing Services
>> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>>
>> S?lo le pido a Dios
>> que el futuro no me sea indiferente
>>
> 


From mholmes at uvic.ca  Thu Apr 19 17:27:22 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Thu, 19 Apr 2012 14:27:22 -0700
Subject: [tei-council] style-guide.txt deleted
Message-ID: <4F90833A.4030504@uvic.ca>

Hi all,

I've removed style-guide.txt from SVN in accordance with our decision on 
Monday. Just for the record, here are (were) its contents:

STYLESHEET FOR TEI GUIDELINES USAGES
====================================

    This file contains a working list of usages for spelling of various 
terms
    used in the TEI Guidelines.

    Version History:

         2008-01-31  Created, David Sewell

Reference Abbreviations:

         CMS:    Chicago Manual of Style, 15th ed.
         MW:     Merriam-Webster's Collegiate Dictionary, 11th ed.
         OED:    Oxford English Dictionary, 2d ed. online 
(dictionary.oed.com)
         ODE:    Oxford Dictionary of English (aka NODE), 2d ed.
         ORDS:   O'Reilly Default Stylesheet,
                 http://www.oreilly.com/oreilly/author/stylesheet.html
         UCG:    Unicode Consortium Glossary, http://unicode.org/glossary/
         W3CXML: W3C XML Recommendation, http://www.w3.org/TR/xml/


Word or Term             Authority/explanation
============             =====================

code point (n.)         UCG [discussed on TEI Council list]
code-point (adj.)
cross-reference         MW, OED
data set                OED
datatype                [OED, ORDS have 'data type', but Guidelines
                          consistently use single word dozens of places]
end-tag                 ORDS
high-level (adj.)       MW, OED
line break
lowercase/uppercase     MW, ORDS
proofread               MW, OED
start-tag               ORDS
stylesheet              ORDS
typeface                MW
the Web                 ORDS
web page                ORDS
web site                ORDS, OED
well-formed             W3CXML (even in a predicate usage:
                           "the XML is well-formed")
whitespace              ORDS



    /* vim: set ai ts=8 sw=8 expandtab tw=78: */

Cheers,
Martin
-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From mholmes at uvic.ca  Thu Apr 19 18:18:10 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Thu, 19 Apr 2012 15:18:10 -0700
Subject: [tei-council] Attributes without examples
Message-ID: <4F908F22.4070908@uvic.ca>

Following on from our discussion of examples for attributes, a 
quick-and-dirty XSLT seems to show that there are only 19 attributes 
with their own examples, and 450 without. This is not to say that those 
without are unexemplified, because the example code for their parent 
elements in the elementSpec may show examples of them; I'll refine the 
XSLT and make that apparent.

Here's the list:

ATTRIBUTE DEFINITIONS LACKING EXAMPLES AS OF 2012-04-19T15:12:34.968-07:00

1. status (att.identified)
2. type (interaction)
3. value (sex)
4. scale (graphic)
5. scale (binaryObject)
6. weights (alt)
7. hand (att.damaged)
8. agent (gap)
9. predeclare (att.identified)
10. degree (att.damaged)
11. module (att.identified)
12. ident (att.identified)
13. height (graphic)
14. height (binaryObject)
15. width (graphic)
16. width (binaryObject)
17. encoding (binaryObject)
18. version (teiCorpus)
19. hand (unclear)
20. agent (unclear)
21. feature (shift)
22. type (preparedness)
23. type (abbr)
24. commodity (att.measurement)
25. agent (att.damaged)
26. type (derivation)
27. type (domain)
28. type (factuality)
29. type (idno)
30. type (relation)
31. type (sound)
32. type (tech)
33. type (castItem)
34. type (att.typed)
35. type (move)
36. script (att.handFeatures)
37. class (msItemStruct)
38. class (msItem)
39. class (msContents)
40. type (form)
41. cause (att.textCritical)
42. type (gram)
43. type (lbl)
44. type (att.textCritical)
45. type (title)
46. type (titlePage)
47. type (usg)
48. type (app)
49. columns (layout)
50. valueDatcat (att.datcat)
51. datcat (att.datcat)
52. contemporary (seal)
53. contemporary (binding)
54. from (locus)
55. type (list)
56. result (joinGrp)
57. medium (att.handFeatures)
58. type (graph)
59. type (witDetail)
60. origin (timeline)
61. function (att.segLike)
62. form (objectDesc)
63. mergedIn (att.lexicographic)
64. type (fsDecl)
65. scribe (att.handFeatures)
66. degree (node)
67. extent (orth)
68. from (arc)
69. to (arc)
70. inDegree (node)
71. arity (tree)
72. baseTypes (fsDecl)
73. level (sense)
74. order (tree)
75. outDegree (iNode)
76. outDegree (node)
77. outDegree (root)
78. reason (gap)
79. type (orth)
80. when (docDate)
81. split (att.lexicographic)
82. code (socecStatus)
83. code (occupation)
84. decls (att.declaring)
85. cRef (term)
86. from (app)
87. scheme (catRef)
88. scheme (occupation)
89. scheme (classCode)
90. scheme (socecStatus)
91. scheme (keywords)
92. to (app)
93. baseForm (m)
94. new (handShift)
95. passive (relation)
96. since (when)
97. type (fsdLink)
98. type (biblScope)
99. type (listForest)
100. type (forest)
101. hand (gap)
102. given (certainty)
103. locus (certainty)
104. type (rs)
105. source (normalization)
106. level (title)
107. degree (certainty)
108. status (correction)
109. degree (precision)
110. spanTo (att.spanning)
111. to (att.datable.w3c)
112. to-iso (att.datable.iso)
113. force (pc)
114. reason (surplus)
115. type (stage)
116. type (oRef)
117. type (oVar)
118. method (correction)
119. method (normalization)
120. name (fDecl)
121. evidence (att.editLike)
122. rows (table)
123. org (vMerge)
124. who (att.ascribed)
125. locus (respons)
126. from-custom (att.datable.custom)
127. from (att.datable.w3c)
128. from-iso (att.datable.iso)
129. type (xr)
130. type (iType)
131. type (num)
132. type (att.entryLike)
133. type (att.interpLike)
134. unit (refState)
135. notation (pron)
136. break (att.breaking)
137. iterated (kinesic)
138. iterated (vocal)
139. optional (fDecl)
140. default (att.declarable)
141. location (variantEncoding)
142. anchored (note)
143. full (att.personal)
144. type (metDecl)
145. extent (pron)
146. discrete (sound)
147. scope (join)
148. gradual (writing)
149. sample (att.divLike)
150. type (classSpec)
151. pre (pc)
152. type (dimensions)
153. method (variantEncoding)
154. type (macroSpec)
155. reason (supplied)
156. to (locus)
157. rows (att.tableDecoration)
158. writtenLines (layout)
159. ruledLines (layout)
160. location (att.lexicographic)
161. hands (handDesc)
162. material (supportDesc)
163. notation (formula)
164. unit (att.dimensions)
165. ns (attDef)
166. ns (elementSpec)
167. domains (att.pointing.group)
168. part (att.segLike)
169. source (writing)
170. ref (g)
171. scribeRef (att.handFeatures)
172. scriptRef (att.handFeatures)
173. copyOf (att.global.linking)
174. sameAs (att.global.linking)
175. exclude (att.global.linking)
176. targetEnd (note)
177. next (att.global.linking)
178. target (relatedItem)
179. unit (milestone)
180. label (rhyme)
181. lemma (w)
182. children (iNode)
183. children (root)
184. name (f)
185. unit (pc)
186. value (leaf)
187. type (node)
188. key (att.canonical)
189. follow (iNode)
190. follow (leaf)
191. parent (leaf)
192. parent (iNode)
193. value (node)
194. value (triangle)
195. value (eLeaf)
196. value (eTree)
197. value (iNode)
198. value (root)
199. quantity (att.measurement)
200. role (att.tableDecoration)
201. scheme (att)
202. select (att.global.linking)
203. xml:space (att.global)
204. hand (att.textCritical)
205. subtype (att.typed)
206. prefix (schemaSpec)
207. prefix (elementSpec)
208. type (purpose)
209. role (org)
210. role (person)
211. matchPattern (cRefPattern)
212. replacementPattern (cRefPattern)
213. age (person)
214. start (schemaSpec)
215. form (quotation)
216. time (distinct)
217. social (distinct)
218. space (distinct)
219. type (constitution)
220. scope (att.handFeatures)
221. age (personGrp)
222. usage (language)
223. ident (valItem)
224. from (span)
225. value (metSym)
226. versionDate (att.translatable)
227. target (att.pointing)
228. where (move)
229. notBefore (att.datable.w3c)
230. notBefore-custom (att.datable.custom)
231. notBefore-iso (att.datable.iso)
232. mode (classes)
233. mode (att.combinable)
234. mode (memberOf)
235. to (span)
236. to (biblScope)
237. type (valList)
238. degree (purpose)
239. length (refState)
240. render (tagUsage)
241. targets (alt)
242. targets (join)
243. targets (link)
244. type (teiHeader)
245. notAfter (att.datable.w3c)
246. notAfter-custom (att.datable.custom)
247. notAfter-iso (att.datable.iso)
248. version (TEI)
249. mode (channel)
250. result (join)
251. new (shift)
252. active (interaction)
253. occurs (tagUsage)
254. passive (interaction)
255. interval (when)
256. interval (timeline)
257. usage (attDef)
258. role (personGrp)
259. type (titlePart)
260. sex (personGrp)
261. sex (person)
262. size (personGrp)
263. from (biblScope)
264. type (distinct)
265. type (measure)
266. type (fs)
267. unit (timeline)
268. unit (when)
269. version (unicodeName)
270. type (divGen)
271. part (ab)
272. part (att.divLike)
273. part (l)
274. terminal (metSym)
275. trunc (numeric)
276. order (graph)
277. size (graph)
278. mode (alt)
279. mode (altGrp)
280. value (binary)
281. status (availability)
282. datum (geoDecl)
283. value (numeric)
284. name (relation)
285. name (vLabel)
286. indexName (index)
287. stdDeviation (precision)
288. absolute (when)
289. max (numeric)
290. scheme (constraintSpec)
291. scheme (tag)
292. scheme (gi)
293. value (symbol)
294. value (num)
295. scheme (locusGrp)
296. scheme (locus)
297. name (namespace)
298. type (recording)
299. unit (att.measurement)
300. value (att.lexicographic)
301. scope (att.dimensions)
302. evaluate (att.pointing)
303. active (relation)
304. to-custom (att.datable.custom)
305. mutual (relation)
306. dur-iso (att.duration.iso)
307. instant (att.editLike)
308. function (metamark)
309. attachment (surface)
310. cause (att.transcriptional)
311. target (metamark)
312. rotate (zone)
313. target (redo)
314. target (undo)
315. except (moduleRef)
316. include (moduleRef)
317. datingMethod (att.datable.custom)
318. datingPoint (att.datable.custom)
319. key (moduleRef)
320. url (moduleRef)
321. mimeType (att.internetMedia)
322. version (application)
323. ident (application)
324. confidence (att.ranging)
325. level (langKnown)
326. adj (node)
327. adjFrom (node)
328. adjTo (node)
329. ana (att.global.analytic)
330. group (att.damaged)
331. cRef (gloss)
332. cRef (ptr)
333. cRef (ref)
334. cert (att.responsibility)
335. cert (certainty)
336. precision (precision)
337. precision (att.dimensions)
338. type (fw)
339. cols (table)
340. cols (att.tableDecoration)
341. source (att.editLike)
342. autoPrefix (content)
343. corresp (att.global.linking)
344. delim (refState)
345. dim (space)
346. docLang (schemaSpec)
347. dur (att.duration.w3c)
348. ed (att.sourced)
349. gi (tagUsage)
350. eol (hyphenation)
351. enjamb (att.enjamb)
352. facs (att.global.facs)
353. fVal (f)
354. feats (fs)
355. lang (code)
356. atMost (att.ranging)
357. atLeast (att.ranging)
358. lrx (att.coordinated)
359. ulx (att.coordinated)
360. lry (att.coordinated)
361. uly (att.coordinated)
362. xml:id (att.global)
363. ident (language)
364. scheme (rendition)
365. status (att.transcriptional)
366. where (event)
367. start (att.timed)
368. end (att.timed)
369. type (tag)
370. defective (att.msExcerpt)
371. generate (classSpec)
372. inst (att.interpLike)
373. xml:lang (att.global)
374. loc (app)
375. mainLang (textLang)
376. maxOccurs (datatype)
377. type (q)
378. direct (said)
379. aloud (said)
380. met (att.metrical)
381. real (att.metrical)
382. minOccurs (datatype)
383. name (equiv)
384. ns (schemaSpec)
385. n (att.global)
386. opt (att.lexicographic)
387. ord (iNode)
388. ord (root)
389. ord (tree)
390. sort (att.personal)
391. org (attList)
392. org (vColl)
393. org (att.divLike)
394. orig (att.lexicographic)
395. otherLangs (textLang)
396. perf (move)
397. perf (tech)
398. target (specGrpRef)
399. parts (nym)
400. change (att.global.change)
401. target (change)
402. prev (att.global.linking)
403. lemmaRef (w)
404. marks (quotation)
405. ref (att.canonical)
406. nymRef (att.naming)
407. filter (equiv)
408. pattern (metDecl)
409. resp (respons)
410. resp (att.responsibility)
411. resp (space)
412. rhyme (att.metrical)
413. seq (att.transcriptional)
414. hand (att.transcriptional)
415. prefix (moduleRef)
416. key (memberOf)
417. quantity (att.dimensions)
418. value (age)
419. target (fsdLink)
420. period (att.datable)
421. tag (langKnown)
422. tags (langKnowledge)
423. max (memberOf)
424. min (memberOf)
425. synch (att.global.linking)
426. targFunc (att.pointing.group)
427. targetLang (schemaSpec)
428. key (classRef)
429. key (elementRef)
430. key (macroRef)
431. name (attRef)
432. trans (u)
433. uri (equiv)
434. url (graphic)
435. varSeq (att.textCritical)
436. scope (rendition)
437. max (att.ranging)
438. min (att.ranging)
439. withId (tagUsage)
440. wit (att.witnessed)
441. wit (att.rdgPart)
442. wit (witDetail)
443. status (att.docStatus)
444. points (zone)
445. start (att.coordinated)
446. valid (egXML)
447. ordered (listChange)
448. role (att.naming)
449. source (att.readFrom)
450. flipping (surface)


ATTRIBUTE DEFINITIONS WHICH HAVE EXAMPLES AS OF 
2012-04-19T15:12:34.968-07:00

1. place (att.placement)
2. expand (att.lexicographic)
3. extent (att.dimensions)
4. calendar (att.datable)
5. reason (unclear)
6. target (att.scoping)
7. xml:base (att.global)
8. assertedValue (certainty)
9. refLang (att.pointing)
10. match (att.scoping)
11. sortKey (att.sortable)
12. atts (specDesc)
13. key (specDesc)
14. norm (att.lexicographic)
15. rendition (att.global)
16. rend (att.global)
17. when-iso (att.datable.iso)
18. when-custom (att.datable.custom)
19. when (att.datable.w3c)

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From mholmes at uvic.ca  Thu Apr 19 20:27:30 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Thu, 19 Apr 2012 17:27:30 -0700
Subject: [tei-council] Attributes without examples
In-Reply-To: <4F908F22.4070908@uvic.ca>
References: <4F908F22.4070908@uvic.ca>
Message-ID: <4F90AD72.10605@uvic.ca>

Below is another slightly shorter list. These are attributes which do 
not appear on any examples in the <elementSpec> or <classSpec> in which 
they're defined. Not that this doesn't mean there are no examples at all 
for them; there may be an example somewhere in the Guidelines text, or 
the attribute may be defined in a <classSpec> for an attribute class, 
and then show up in an example in an <elementSpec> for an element which 
belongs to that class. An example of the latter is @agent (att.damaged), 
which has no example in the att.damaged <classSpec>, but happens to show 
up in an example for the <damage> element.

Nevertheless, I think it would be a good idea to try to provide examples 
for all these attributes, in the files which define them.

ATTRIBUTES WHICH DO NOT SHOW UP ON ANY EXAMPLE IN THEIR elementSpec OR 
classSpec AS OF 2012-04-19T17:19:17.315-07:00

1. absolute (when)
2. adj (node)
3. adjFrom (node)
4. adjTo (node)
5. age (personGrp)
6. agent (att.damaged)
7. agent (gap)
8. agent (unclear)
9. ana (att.global.analytic)
10. atLeast (att.ranging)
11. atMost (att.ranging)
12. attachment (surface)
13. autoPrefix (content)
14. baseTypes (fsDecl)
15. break (att.breaking)
16. cRef (gloss)
17. cRef (ptr)
18. cRef (ref)
19. cRef (term)
20. cause (att.textCritical)
21. cause (att.transcriptional)
22. cert (att.responsibility)
23. change (att.global.change)
24. class (msContents)
25. cols (att.tableDecoration)
26. confidence (att.ranging)
27. contemporary (seal)
28. copyOf (att.global.linking)
29. corresp (att.global.linking)
30. datingMethod (att.datable.custom)
31. datingPoint (att.datable.custom)
32. decls (att.declaring)
33. default (att.declarable)
34. defective (att.msExcerpt)
35. degree (att.damaged)
36. degree (node)
37. dim (space)
38. direct (said)
39. docLang (schemaSpec)
40. domains (att.pointing.group)
41. dur (att.duration.w3c)
42. dur-iso (att.duration.iso)
43. encoding (binaryObject)
44. end (att.timed)
45. enjamb (att.enjamb)
46. evaluate (att.pointing)
47. evidence (att.editLike)
48. except (moduleRef)
49. exclude (att.global.linking)
50. expand (att.lexicographic)
51. extent (orth)
52. fVal (f)
53. facs (att.global.facs)
54. feats (fs)
55. filter (equiv)
56. flipping (surface)
57. follow (leaf)
58. force (pc)
59. from (app)
60. from (att.datable.w3c)
61. from-custom (att.datable.custom)
62. from-iso (att.datable.iso)
63. full (att.personal)
64. function (att.segLike)
65. generate (classSpec)
66. gradual (writing)
67. group (att.damaged)
68. hand (att.damaged)
69. hand (att.textCritical)
70. hand (att.transcriptional)
71. hand (gap)
72. hand (unclear)
73. height (binaryObject)
74. height (graphic)
75. ident (att.identified)
76. inst (att.interpLike)
77. instant (att.editLike)
78. key (att.canonical)
79. key (classRef)
80. key (macroRef)
81. level (sense)
82. level (title)
83. loc (app)
84. location (att.lexicographic)
85. lrx (att.coordinated)
86. lry (att.coordinated)
87. match (att.scoping)
88. material (supportDesc)
89. max (att.ranging)
90. max (memberOf)
91. medium (att.handFeatures)
92. mergedIn (att.lexicographic)
93. met (att.metrical)
94. method (correction)
95. mimeType (att.internetMedia)
96. min (att.ranging)
97. min (memberOf)
98. mode (att.combinable)
99. mode (classes)
100. mode (memberOf)
101. module (att.identified)
102. new (handShift)
103. next (att.global.linking)
104. notAfter-custom (att.datable.custom)
105. notAfter-iso (att.datable.iso)
106. notBefore-custom (att.datable.custom)
107. notBefore-iso (att.datable.iso)
108. notation (pron)
109. ns (attDef)
110. ns (elementSpec)
111. ns (schemaSpec)
112. nymRef (att.naming)
113. opt (att.lexicographic)
114. optional (fDecl)
115. ord (iNode)
116. ord (root)
117. org (att.divLike)
118. org (attList)
119. orig (att.lexicographic)
120. part (ab)
121. part (att.divLike)
122. part (att.segLike)
123. parts (nym)
124. perf (tech)
125. period (att.datable)
126. pre (pc)
127. precision (att.dimensions)
128. predeclare (att.identified)
129. prefix (elementSpec)
130. prefix (moduleRef)
131. prev (att.global.linking)
132. quantity (att.dimensions)
133. real (att.metrical)
134. ref (att.canonical)
135. refLang (att.pointing)
136. resp (att.responsibility)
137. resp (space)
138. rhyme (att.metrical)
139. role (att.naming)
140. role (att.tableDecoration)
141. role (org)
142. rotate (zone)
143. rows (att.tableDecoration)
144. sameAs (att.global.linking)
145. sample (att.divLike)
146. scale (binaryObject)
147. scale (graphic)
148. scheme (catRef)
149. scheme (locus)
150. scheme (locusGrp)
151. scheme (tag)
152. scope (att.dimensions)
153. scope (att.handFeatures)
154. scribe (att.handFeatures)
155. scribeRef (att.handFeatures)
156. script (att.handFeatures)
157. scriptRef (att.handFeatures)
158. select (att.global.linking)
159. seq (att.transcriptional)
160. social (distinct)
161. sort (att.personal)
162. source (att.editLike)
163. source (att.readFrom)
164. source (writing)
165. space (distinct)
166. spanTo (att.spanning)
167. split (att.lexicographic)
168. start (att.coordinated)
169. start (att.timed)
170. status (att.identified)
171. status (att.transcriptional)
172. status (correction)
173. stdDeviation (precision)
174. subtype (att.typed)
175. synch (att.global.linking)
176. targFunc (att.pointing.group)
177. target (change)
178. target (relatedItem)
179. targetEnd (note)
180. targetLang (schemaSpec)
181. targets (alt)
182. targets (join)
183. targets (link)
184. time (distinct)
185. to (app)
186. to (att.datable.w3c)
187. to-custom (att.datable.custom)
188. to-iso (att.datable.iso)
189. type (abbr)
190. type (att.entryLike)
191. type (att.interpLike)
192. type (att.textCritical)
193. type (att.typed)
194. type (form)
195. type (q)
196. type (sound)
197. ulx (att.coordinated)
198. uly (att.coordinated)
199. unit (att.dimensions)
200. unit (pc)
201. unit (when)
202. url (moduleRef)
203. value (att.lexicographic)
204. value (eTree)
205. value (iNode)
206. value (leaf)
207. value (node)
208. value (root)
209. value (triangle)
210. varSeq (att.textCritical)
211. version (unicodeName)
212. versionDate (att.translatable)
213. when (docDate)
214. where (event)
215. who (att.ascribed)
216. width (binaryObject)
217. width (graphic)
218. wit (att.rdgPart)
219. wit (att.witnessed)
220. xml:base (att.global)
221. xml:id (att.global)
222. xml:lang (att.global)
223. xml:space (att.global)

Cheers,
Martin

On 12-04-19 03:18 PM, Martin Holmes wrote:
> Following on from our discussion of examples for attributes, a
> quick-and-dirty XSLT seems to show that there are only 19 attributes
> with their own examples, and 450 without. This is not to say that those
> without are unexemplified, because the example code for their parent
> elements in the elementSpec may show examples of them; I'll refine the
> XSLT and make that apparent.
>
> Here's the list:
>
> ATTRIBUTE DEFINITIONS LACKING EXAMPLES AS OF 2012-04-19T15:12:34.968-07:00
>
> 1. status (att.identified)
> 2. type (interaction)
> 3. value (sex)
> 4. scale (graphic)
> 5. scale (binaryObject)
> 6. weights (alt)
> 7. hand (att.damaged)
> 8. agent (gap)
> 9. predeclare (att.identified)
> 10. degree (att.damaged)
> 11. module (att.identified)
> 12. ident (att.identified)
> 13. height (graphic)
> 14. height (binaryObject)
> 15. width (graphic)
> 16. width (binaryObject)
> 17. encoding (binaryObject)
> 18. version (teiCorpus)
> 19. hand (unclear)
> 20. agent (unclear)
> 21. feature (shift)
> 22. type (preparedness)
> 23. type (abbr)
> 24. commodity (att.measurement)
> 25. agent (att.damaged)
> 26. type (derivation)
> 27. type (domain)
> 28. type (factuality)
> 29. type (idno)
> 30. type (relation)
> 31. type (sound)
> 32. type (tech)
> 33. type (castItem)
> 34. type (att.typed)
> 35. type (move)
> 36. script (att.handFeatures)
> 37. class (msItemStruct)
> 38. class (msItem)
> 39. class (msContents)
> 40. type (form)
> 41. cause (att.textCritical)
> 42. type (gram)
> 43. type (lbl)
> 44. type (att.textCritical)
> 45. type (title)
> 46. type (titlePage)
> 47. type (usg)
> 48. type (app)
> 49. columns (layout)
> 50. valueDatcat (att.datcat)
> 51. datcat (att.datcat)
> 52. contemporary (seal)
> 53. contemporary (binding)
> 54. from (locus)
> 55. type (list)
> 56. result (joinGrp)
> 57. medium (att.handFeatures)
> 58. type (graph)
> 59. type (witDetail)
> 60. origin (timeline)
> 61. function (att.segLike)
> 62. form (objectDesc)
> 63. mergedIn (att.lexicographic)
> 64. type (fsDecl)
> 65. scribe (att.handFeatures)
> 66. degree (node)
> 67. extent (orth)
> 68. from (arc)
> 69. to (arc)
> 70. inDegree (node)
> 71. arity (tree)
> 72. baseTypes (fsDecl)
> 73. level (sense)
> 74. order (tree)
> 75. outDegree (iNode)
> 76. outDegree (node)
> 77. outDegree (root)
> 78. reason (gap)
> 79. type (orth)
> 80. when (docDate)
> 81. split (att.lexicographic)
> 82. code (socecStatus)
> 83. code (occupation)
> 84. decls (att.declaring)
> 85. cRef (term)
> 86. from (app)
> 87. scheme (catRef)
> 88. scheme (occupation)
> 89. scheme (classCode)
> 90. scheme (socecStatus)
> 91. scheme (keywords)
> 92. to (app)
> 93. baseForm (m)
> 94. new (handShift)
> 95. passive (relation)
> 96. since (when)
> 97. type (fsdLink)
> 98. type (biblScope)
> 99. type (listForest)
> 100. type (forest)
> 101. hand (gap)
> 102. given (certainty)
> 103. locus (certainty)
> 104. type (rs)
> 105. source (normalization)
> 106. level (title)
> 107. degree (certainty)
> 108. status (correction)
> 109. degree (precision)
> 110. spanTo (att.spanning)
> 111. to (att.datable.w3c)
> 112. to-iso (att.datable.iso)
> 113. force (pc)
> 114. reason (surplus)
> 115. type (stage)
> 116. type (oRef)
> 117. type (oVar)
> 118. method (correction)
> 119. method (normalization)
> 120. name (fDecl)
> 121. evidence (att.editLike)
> 122. rows (table)
> 123. org (vMerge)
> 124. who (att.ascribed)
> 125. locus (respons)
> 126. from-custom (att.datable.custom)
> 127. from (att.datable.w3c)
> 128. from-iso (att.datable.iso)
> 129. type (xr)
> 130. type (iType)
> 131. type (num)
> 132. type (att.entryLike)
> 133. type (att.interpLike)
> 134. unit (refState)
> 135. notation (pron)
> 136. break (att.breaking)
> 137. iterated (kinesic)
> 138. iterated (vocal)
> 139. optional (fDecl)
> 140. default (att.declarable)
> 141. location (variantEncoding)
> 142. anchored (note)
> 143. full (att.personal)
> 144. type (metDecl)
> 145. extent (pron)
> 146. discrete (sound)
> 147. scope (join)
> 148. gradual (writing)
> 149. sample (att.divLike)
> 150. type (classSpec)
> 151. pre (pc)
> 152. type (dimensions)
> 153. method (variantEncoding)
> 154. type (macroSpec)
> 155. reason (supplied)
> 156. to (locus)
> 157. rows (att.tableDecoration)
> 158. writtenLines (layout)
> 159. ruledLines (layout)
> 160. location (att.lexicographic)
> 161. hands (handDesc)
> 162. material (supportDesc)
> 163. notation (formula)
> 164. unit (att.dimensions)
> 165. ns (attDef)
> 166. ns (elementSpec)
> 167. domains (att.pointing.group)
> 168. part (att.segLike)
> 169. source (writing)
> 170. ref (g)
> 171. scribeRef (att.handFeatures)
> 172. scriptRef (att.handFeatures)
> 173. copyOf (att.global.linking)
> 174. sameAs (att.global.linking)
> 175. exclude (att.global.linking)
> 176. targetEnd (note)
> 177. next (att.global.linking)
> 178. target (relatedItem)
> 179. unit (milestone)
> 180. label (rhyme)
> 181. lemma (w)
> 182. children (iNode)
> 183. children (root)
> 184. name (f)
> 185. unit (pc)
> 186. value (leaf)
> 187. type (node)
> 188. key (att.canonical)
> 189. follow (iNode)
> 190. follow (leaf)
> 191. parent (leaf)
> 192. parent (iNode)
> 193. value (node)
> 194. value (triangle)
> 195. value (eLeaf)
> 196. value (eTree)
> 197. value (iNode)
> 198. value (root)
> 199. quantity (att.measurement)
> 200. role (att.tableDecoration)
> 201. scheme (att)
> 202. select (att.global.linking)
> 203. xml:space (att.global)
> 204. hand (att.textCritical)
> 205. subtype (att.typed)
> 206. prefix (schemaSpec)
> 207. prefix (elementSpec)
> 208. type (purpose)
> 209. role (org)
> 210. role (person)
> 211. matchPattern (cRefPattern)
> 212. replacementPattern (cRefPattern)
> 213. age (person)
> 214. start (schemaSpec)
> 215. form (quotation)
> 216. time (distinct)
> 217. social (distinct)
> 218. space (distinct)
> 219. type (constitution)
> 220. scope (att.handFeatures)
> 221. age (personGrp)
> 222. usage (language)
> 223. ident (valItem)
> 224. from (span)
> 225. value (metSym)
> 226. versionDate (att.translatable)
> 227. target (att.pointing)
> 228. where (move)
> 229. notBefore (att.datable.w3c)
> 230. notBefore-custom (att.datable.custom)
> 231. notBefore-iso (att.datable.iso)
> 232. mode (classes)
> 233. mode (att.combinable)
> 234. mode (memberOf)
> 235. to (span)
> 236. to (biblScope)
> 237. type (valList)
> 238. degree (purpose)
> 239. length (refState)
> 240. render (tagUsage)
> 241. targets (alt)
> 242. targets (join)
> 243. targets (link)
> 244. type (teiHeader)
> 245. notAfter (att.datable.w3c)
> 246. notAfter-custom (att.datable.custom)
> 247. notAfter-iso (att.datable.iso)
> 248. version (TEI)
> 249. mode (channel)
> 250. result (join)
> 251. new (shift)
> 252. active (interaction)
> 253. occurs (tagUsage)
> 254. passive (interaction)
> 255. interval (when)
> 256. interval (timeline)
> 257. usage (attDef)
> 258. role (personGrp)
> 259. type (titlePart)
> 260. sex (personGrp)
> 261. sex (person)
> 262. size (personGrp)
> 263. from (biblScope)
> 264. type (distinct)
> 265. type (measure)
> 266. type (fs)
> 267. unit (timeline)
> 268. unit (when)
> 269. version (unicodeName)
> 270. type (divGen)
> 271. part (ab)
> 272. part (att.divLike)
> 273. part (l)
> 274. terminal (metSym)
> 275. trunc (numeric)
> 276. order (graph)
> 277. size (graph)
> 278. mode (alt)
> 279. mode (altGrp)
> 280. value (binary)
> 281. status (availability)
> 282. datum (geoDecl)
> 283. value (numeric)
> 284. name (relation)
> 285. name (vLabel)
> 286. indexName (index)
> 287. stdDeviation (precision)
> 288. absolute (when)
> 289. max (numeric)
> 290. scheme (constraintSpec)
> 291. scheme (tag)
> 292. scheme (gi)
> 293. value (symbol)
> 294. value (num)
> 295. scheme (locusGrp)
> 296. scheme (locus)
> 297. name (namespace)
> 298. type (recording)
> 299. unit (att.measurement)
> 300. value (att.lexicographic)
> 301. scope (att.dimensions)
> 302. evaluate (att.pointing)
> 303. active (relation)
> 304. to-custom (att.datable.custom)
> 305. mutual (relation)
> 306. dur-iso (att.duration.iso)
> 307. instant (att.editLike)
> 308. function (metamark)
> 309. attachment (surface)
> 310. cause (att.transcriptional)
> 311. target (metamark)
> 312. rotate (zone)
> 313. target (redo)
> 314. target (undo)
> 315. except (moduleRef)
> 316. include (moduleRef)
> 317. datingMethod (att.datable.custom)
> 318. datingPoint (att.datable.custom)
> 319. key (moduleRef)
> 320. url (moduleRef)
> 321. mimeType (att.internetMedia)
> 322. version (application)
> 323. ident (application)
> 324. confidence (att.ranging)
> 325. level (langKnown)
> 326. adj (node)
> 327. adjFrom (node)
> 328. adjTo (node)
> 329. ana (att.global.analytic)
> 330. group (att.damaged)
> 331. cRef (gloss)
> 332. cRef (ptr)
> 333. cRef (ref)
> 334. cert (att.responsibility)
> 335. cert (certainty)
> 336. precision (precision)
> 337. precision (att.dimensions)
> 338. type (fw)
> 339. cols (table)
> 340. cols (att.tableDecoration)
> 341. source (att.editLike)
> 342. autoPrefix (content)
> 343. corresp (att.global.linking)
> 344. delim (refState)
> 345. dim (space)
> 346. docLang (schemaSpec)
> 347. dur (att.duration.w3c)
> 348. ed (att.sourced)
> 349. gi (tagUsage)
> 350. eol (hyphenation)
> 351. enjamb (att.enjamb)
> 352. facs (att.global.facs)
> 353. fVal (f)
> 354. feats (fs)
> 355. lang (code)
> 356. atMost (att.ranging)
> 357. atLeast (att.ranging)
> 358. lrx (att.coordinated)
> 359. ulx (att.coordinated)
> 360. lry (att.coordinated)
> 361. uly (att.coordinated)
> 362. xml:id (att.global)
> 363. ident (language)
> 364. scheme (rendition)
> 365. status (att.transcriptional)
> 366. where (event)
> 367. start (att.timed)
> 368. end (att.timed)
> 369. type (tag)
> 370. defective (att.msExcerpt)
> 371. generate (classSpec)
> 372. inst (att.interpLike)
> 373. xml:lang (att.global)
> 374. loc (app)
> 375. mainLang (textLang)
> 376. maxOccurs (datatype)
> 377. type (q)
> 378. direct (said)
> 379. aloud (said)
> 380. met (att.metrical)
> 381. real (att.metrical)
> 382. minOccurs (datatype)
> 383. name (equiv)
> 384. ns (schemaSpec)
> 385. n (att.global)
> 386. opt (att.lexicographic)
> 387. ord (iNode)
> 388. ord (root)
> 389. ord (tree)
> 390. sort (att.personal)
> 391. org (attList)
> 392. org (vColl)
> 393. org (att.divLike)
> 394. orig (att.lexicographic)
> 395. otherLangs (textLang)
> 396. perf (move)
> 397. perf (tech)
> 398. target (specGrpRef)
> 399. parts (nym)
> 400. change (att.global.change)
> 401. target (change)
> 402. prev (att.global.linking)
> 403. lemmaRef (w)
> 404. marks (quotation)
> 405. ref (att.canonical)
> 406. nymRef (att.naming)
> 407. filter (equiv)
> 408. pattern (metDecl)
> 409. resp (respons)
> 410. resp (att.responsibility)
> 411. resp (space)
> 412. rhyme (att.metrical)
> 413. seq (att.transcriptional)
> 414. hand (att.transcriptional)
> 415. prefix (moduleRef)
> 416. key (memberOf)
> 417. quantity (att.dimensions)
> 418. value (age)
> 419. target (fsdLink)
> 420. period (att.datable)
> 421. tag (langKnown)
> 422. tags (langKnowledge)
> 423. max (memberOf)
> 424. min (memberOf)
> 425. synch (att.global.linking)
> 426. targFunc (att.pointing.group)
> 427. targetLang (schemaSpec)
> 428. key (classRef)
> 429. key (elementRef)
> 430. key (macroRef)
> 431. name (attRef)
> 432. trans (u)
> 433. uri (equiv)
> 434. url (graphic)
> 435. varSeq (att.textCritical)
> 436. scope (rendition)
> 437. max (att.ranging)
> 438. min (att.ranging)
> 439. withId (tagUsage)
> 440. wit (att.witnessed)
> 441. wit (att.rdgPart)
> 442. wit (witDetail)
> 443. status (att.docStatus)
> 444. points (zone)
> 445. start (att.coordinated)
> 446. valid (egXML)
> 447. ordered (listChange)
> 448. role (att.naming)
> 449. source (att.readFrom)
> 450. flipping (surface)
>
>
> ATTRIBUTE DEFINITIONS WHICH HAVE EXAMPLES AS OF
> 2012-04-19T15:12:34.968-07:00
>
> 1. place (att.placement)
> 2. expand (att.lexicographic)
> 3. extent (att.dimensions)
> 4. calendar (att.datable)
> 5. reason (unclear)
> 6. target (att.scoping)
> 7. xml:base (att.global)
> 8. assertedValue (certainty)
> 9. refLang (att.pointing)
> 10. match (att.scoping)
> 11. sortKey (att.sortable)
> 12. atts (specDesc)
> 13. key (specDesc)
> 14. norm (att.lexicographic)
> 15. rendition (att.global)
> 16. rend (att.global)
> 17. when-iso (att.datable.iso)
> 18. when-custom (att.datable.custom)
> 19. when (att.datable.w3c)
>
> --
> Martin Holmes
> University of Victoria Humanities Computing and Media Centre
> (mholmes at uvic.ca)
> --
> tei-council mailing list
> tei-council at lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>
> PLEASE NOTE: postings to this list are publicly archived
> .
>

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From mholmes at uvic.ca  Thu Apr 19 21:01:58 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Thu, 19 Apr 2012 18:01:58 -0700
Subject: [tei-council] New council members and SourceForge
Message-ID: <4F90B586.3010308@uvic.ca>

One thing we should have done at the ftf is to get the new Council 
members set up with SourceForge accounts and add them to the project, so 
that we can assign tickets to them. Neither Becky nor Paul are members 
of the TEI project on SF yet. Do either of you have a SourceForge 
account? If not, could you set one up:

<https://sourceforge.net/user/registration>

Once you have an id, let me know and I'll add you to the list, and then 
you can start getting tickets dumped on you by the likes of us. :-)

Cheers,
Martin
-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From PFSchaffner at umich.edu  Thu Apr 19 21:07:41 2012
From: PFSchaffner at umich.edu (Paul F. Schaffner)
Date: Thu, 19 Apr 2012 21:07:41 -0400 (EDT)
Subject: [tei-council] New council members and SourceForge
In-Reply-To: <4F90B586.3010308@uvic.ca>
References: <4F90B586.3010308@uvic.ca>
Message-ID: <Pine.LNX.4.64.1204192106340.9625@zaxxon.gpcc.itd.umich.edu>


Martin, my sourceforge ID is 'pfschaffner'. It's old but still
works -- like me :)

pfs

On Thu, 19 Apr 2012, Martin Holmes wrote:

> One thing we should have done at the ftf is to get the new Council
> members set up with SourceForge accounts and add them to the project, so
> that we can assign tickets to them. Neither Becky nor Paul are members
> of the TEI project on SF yet. Do either of you have a SourceForge
> account? If not, could you set one up:
>
> <https://sourceforge.net/user/registration>
>
> Once you have an id, let me know and I'll add you to the list, and then
> you can start getting tickets dumped on you by the likes of us. :-)
>
> Cheers,
> Martin
> -- 
> Martin Holmes
> University of Victoria Humanities Computing and Media Centre
> (mholmes at uvic.ca)
> -- 
> tei-council mailing list
> tei-council at lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>
> PLEASE NOTE: postings to this list are publicly archived
>
>
>

--------------------------------------------------------------------
Paul Schaffner | PFSchaffner at umich.edu | http://www.umich.edu/~pfs/
316-C Hatcher Library N, Univ. of Michigan, Ann Arbor MI 48109-1190
--------------------------------------------------------------------

From syeates at gmail.com  Fri Apr 20 02:33:22 2012
From: syeates at gmail.com (stuart yeates)
Date: Fri, 20 Apr 2012 18:33:22 +1200
Subject: [tei-council] Links in examples
Message-ID: <4F910332.4000701@gmail.com>


http://www.tei-c.org/release/doc/tei-p5-doc/fr/html/examples-lg.html 
contains an example with the line "Les amoureux fervents et les savants 
aust?res" the example links to 
http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-lg.html but is 
should link to 
http://www.tei-c.org/release/doc/tei-p5-doc/fr/html/ref-lg.html (i.e. it 
should link to the fr version not the en version).

I tripped over this doing new examples for 
https://secure.wikimedia.org/wikipedia/en/wiki/Text_Encoding_Initiative

Is that a trivial fix, or should I open a ticket about it?

cheers
stuart

From syeates at gmail.com  Fri Apr 20 02:33:37 2012
From: syeates at gmail.com (stuart yeates)
Date: Fri, 20 Apr 2012 18:33:37 +1200
Subject: [tei-council] removing and renaming XML files
Message-ID: <4F910341.8070906@gmail.com>

The following XML files appear to no longer in use, I would like to 
remove them (preserving them in the subversion history, naturally):

P5/Source/Guidelines/en/SH-OtherMetadataStandards.xml
P5/Source/Guidelines/en/TE-TerminologicalDatabases.xml
P5/Source/Guidelines/en/PARTIND.xml
P5/Source/Guidelines/en/DT-ObtainingSchemas.xml
P5/Source/Guidelines/en/IN-RulesForInterchange.xml


I would also like to rename:

P5/Source/Guidelines/*/DI-PrintDictionaries.xml

to

P5/Source/Guidelines/*/DI-Dictionaries.xml

because this chapter covers born-digital dictionaries too. I don't 
believe that this will change the resulting output, but may change the 
way that we think about it. The name would also need to be updated in:

Documents/Editing/tcw-editing.xml
P5/Source/guidelines-*.xml

cheers
stuart


From sebastian.rahtz at oucs.ox.ac.uk  Fri Apr 20 05:11:40 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Fri, 20 Apr 2012 09:11:40 +0000
Subject: [tei-council] Links in examples
In-Reply-To: <4F910332.4000701@gmail.com>
References: <4F910332.4000701@gmail.com>
Message-ID: <9EA071A6-7C11-42C5-A021-8EB7092349B9@oucs.ox.ac.uk>


On 20 Apr 2012, at 07:33, stuart yeates wrote:

> 
> http://www.tei-c.org/release/doc/tei-p5-doc/fr/html/examples-lg.html 
> contains an example with the line "Les amoureux fervents et les savants 
> aust?res" the example links to 
> http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-lg.html but is 
> should link to 
> http://www.tei-c.org/release/doc/tei-p5-doc/fr/html/ref-lg.html (i.e. it 
> should link to the fr version not the en version).
> ...
> Is that a trivial fix, or should I open a ticket about it?


potentially trivial. do you want to have a look and see if you can
fix it?
--
Stormageddon Rahtz      
Head of Information and Support Group
Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431

S?lo le pido a Dios
que el futuro no me sea indiferente


From syeates at gmail.com  Fri Apr 20 06:11:27 2012
From: syeates at gmail.com (stuart yeates)
Date: Fri, 20 Apr 2012 22:11:27 +1200
Subject: [tei-council] Links in examples
In-Reply-To: <9EA071A6-7C11-42C5-A021-8EB7092349B9@oucs.ox.ac.uk>
References: <4F910332.4000701@gmail.com>
	<9EA071A6-7C11-42C5-A021-8EB7092349B9@oucs.ox.ac.uk>
Message-ID: <4F91364F.60907@gmail.com>

On 20/04/12 21:11, Sebastian Rahtz wrote:
>
> On 20 Apr 2012, at 07:33, stuart yeates wrote:
>
>>
>> http://www.tei-c.org/release/doc/tei-p5-doc/fr/html/examples-lg.html
>> contains an example with the line "Les amoureux fervents et les savants
>> aust?res" the example links to
>> http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-lg.html but is
>> should link to
>> http://www.tei-c.org/release/doc/tei-p5-doc/fr/html/ref-lg.html (i.e. it
>> should link to the fr version not the en version).
>> ...
>> Is that a trivial fix, or should I open a ticket about it?
>
>
> potentially trivial. do you want to have a look and see if you can
> fix it?

I've just had a crack at it, which ought to work, and jenkins didn't 
choke on it.

cheers
stuart

From sebastian.rahtz at oucs.ox.ac.uk  Fri Apr 20 06:30:08 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Fri, 20 Apr 2012 10:30:08 +0000
Subject: [tei-council] Links in examples
In-Reply-To: <4F91364F.60907@gmail.com>
References: <4F910332.4000701@gmail.com>
	<9EA071A6-7C11-42C5-A021-8EB7092349B9@oucs.ox.ac.uk>
	<4F91364F.60907@gmail.com>
Message-ID: <22D632AD-9695-4657-AA50-106FA7D0AA8E@oucs.ox.ac.uk>


On 20 Apr 2012, at 11:11, stuart yeates wrote:
> 
> I've just had a crack at it, which ought to work, and jenkins didn't choke on it.
> 
and that prompted me to wonder why Jenkins had not built new documentation
after your change (which should be fine, from what I could see). 

the answer is that after all the changes this week, Jenkins thinks P5 is unstable
(because of too many failed builds, even though current is OK), so it did not pass on to later stages. 
I have told it to do so.

--
Stormageddon Rahtz      
Head of Information and Support Group
Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431

S?lo le pido a Dios
que el futuro no me sea indiferente


From sebastian.rahtz at oucs.ox.ac.uk  Fri Apr 20 06:35:09 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Fri, 20 Apr 2012 10:35:09 +0000
Subject: [tei-council] removing and renaming XML files
In-Reply-To: <4F910341.8070906@gmail.com>
References: <4F910341.8070906@gmail.com>
Message-ID: <00B92B20-1069-4A53-A8BE-F18703C4003A@oucs.ox.ac.uk>


On 20 Apr 2012, at 07:33, stuart yeates wrote:

> The following XML files appear to no longer in use, I would like to 
> remove them (preserving them in the subversion history, naturally):
> 
> P5/Source/Guidelines/en/SH-OtherMetadataStandards.xml
> P5/Source/Guidelines/en/TE-TerminologicalDatabases.xml
> P5/Source/Guidelines/en/PARTIND.xml
> P5/Source/Guidelines/en/DT-ObtainingSchemas.xml
> P5/Source/Guidelines/en/IN-RulesForInterchange.xml
> 
you could move them into Source/Specs-unused perhaps
for now. thats where other similar things are.

> 
> I would also like to rename:
> 
> P5/Source/Guidelines/*/DI-PrintDictionaries.xml
> 
> to
> 
> P5/Source/Guidelines/*/DI-Dictionaries.xml


seems good to me
--
Stormageddon Rahtz      
Head of Information and Support Group
Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431

S?lo le pido a Dios
que el futuro no me sea indiferente


From sebastian.rahtz at oucs.ox.ac.uk  Fri Apr 20 07:49:44 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Fri, 20 Apr 2012 11:49:44 +0000
Subject: [tei-council] Links in examples
In-Reply-To: <4F910332.4000701@gmail.com>
References: <4F910332.4000701@gmail.com>
Message-ID: <C69C38D5-CD5C-4B47-B993-348054B504A2@oucs.ox.ac.uk>

see http://bits.nsms.ox.ac.uk:8080/jenkins/job/TEIP5-Documentation/lastSuccessfulBuild/artifact/Guidelines-web/fr/html/examples-lg.html
now after Stuart's changes. Seems right


--
Stormageddon Rahtz      
Head of Information and Support Group
Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431

S?lo le pido a Dios
que el futuro no me sea indiferente


From bansp at o2.pl  Fri Apr 20 09:14:09 2012
From: bansp at o2.pl (=?ISO-8859-2?Q?Piotr_Ba=F1ski?=)
Date: Fri, 20 Apr 2012 15:14:09 +0200
Subject: [tei-council] removing and renaming XML files
In-Reply-To: <4F910341.8070906@gmail.com>
References: <4F910341.8070906@gmail.com>
Message-ID: <4F916121.3040808@o2.pl>

On 20/04/12 08:33, stuart yeates wrote:
[..]
> I would also like to rename:
> 
> P5/Source/Guidelines/*/DI-PrintDictionaries.xml
> 
> to
> 
> P5/Source/Guidelines/*/DI-Dictionaries.xml
> 
> because this chapter covers born-digital dictionaries too. I don't 
> believe that this will change the resulting output, but may change the 
> way that we think about it. The name would also need to be updated in:
> 
> Documents/Editing/tcw-editing.xml
> P5/Source/guidelines-*.xml
> 

I thought that this change was not happening because the individual
chapters are often linked from many places. Is there a chance to leave
DI-PrintDictionaries.xml as an alias to the new filename, not to break
too many links out there?

  P.

From mholmes at uvic.ca  Fri Apr 20 10:18:33 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Fri, 20 Apr 2012 07:18:33 -0700
Subject: [tei-council] removing and renaming XML files
In-Reply-To: <4F916121.3040808@o2.pl>
References: <4F910341.8070906@gmail.com> <4F916121.3040808@o2.pl>
Message-ID: <4F917039.9060903@uvic.ca>

Better to break the links and fix them, I think, since we're winding up 
to a "major" release, and if the tei_ prefix in anchors is included in 
it, lots of existing links will break anyway.

But this really ought to be a policy issue. Under what circumstances is 
it acceptable to break existing links to a) pages in the Guidelines, and 
b) anchors on pages? And when we do break them with a new release, what 
are our obligations in terms of supporting the old links?

Cheers,
Martin

On 12-04-20 06:14 AM, Piotr Ba?ski wrote:
> On 20/04/12 08:33, stuart yeates wrote:
> [..]
>> I would also like to rename:
>>
>> P5/Source/Guidelines/*/DI-PrintDictionaries.xml
>>
>> to
>>
>> P5/Source/Guidelines/*/DI-Dictionaries.xml
>>
>> because this chapter covers born-digital dictionaries too. I don't
>> believe that this will change the resulting output, but may change the
>> way that we think about it. The name would also need to be updated in:
>>
>> Documents/Editing/tcw-editing.xml
>> P5/Source/guidelines-*.xml
>>
>
> I thought that this change was not happening because the individual
> chapters are often linked from many places. Is there a chance to leave
> DI-PrintDictionaries.xml as an alias to the new filename, not to break
> too many links out there?
>
>    P.

From sebastian.rahtz at oucs.ox.ac.uk  Fri Apr 20 11:34:06 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Fri, 20 Apr 2012 15:34:06 +0000
Subject: [tei-council] removing and renaming XML files
In-Reply-To: <4F917039.9060903@uvic.ca>
References: <4F910341.8070906@gmail.com> <4F916121.3040808@o2.pl>
	<4F917039.9060903@uvic.ca>
Message-ID: <EAEC2C8D-5BE0-41DE-A35A-F59244891DF1@oucs.ox.ac.uk>


On 20 Apr 2012, at 15:18, Martin Holmes wrote:

> Better to break the links and fix them, I think, since we're winding up 
> to a "major" release, and if the tei_ prefix in anchors is included in 
> it, lots of existing links will break anyway.
> 
but the link to the _files_ mustn't change. i.e. it will still be
  DI-PrintDictionaries.html
not
  tei_DI-PrintDictionaries.html

> But this really ought to be a policy issue. Under what circumstances is 
> it acceptable to break existing links to a) pages in the Guidelines, and 
> b) anchors on pages?

a) not many, but if the alternatives are worse, so be it
b) when it seems sensible

> And when we do break them with a new release, what 
> are our obligations in terms of supporting the old links?


as much as is reasonably possible.

if all the tei_ exercise changes is anchors on pages, I'd not worry about it
--
Stormageddon Rahtz      
Head of Information and Support Group
Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431

S?lo le pido a Dios
que el futuro no me sea indiferente


From lou.burnard at retired.ox.ac.uk  Fri Apr 20 13:41:21 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Fri, 20 Apr 2012 18:41:21 +0100
Subject: [tei-council] removing and renaming XML files
In-Reply-To: <4F916121.3040808@o2.pl>
References: <4F910341.8070906@gmail.com> <4F916121.3040808@o2.pl>
Message-ID: <4F919FC1.2030400@retired.ox.ac.uk>

On 20/04/12 14:14, Piotr Ba?ski wrote:
> On 20/04/12 08:33, stuart yeates wrote:
> [..]
>> I would also like to rename:
>>
>> P5/Source/Guidelines/*/DI-PrintDictionaries.xml
>>
>> to
>>
>> P5/Source/Guidelines/*/DI-Dictionaries.xml
>>
>> because this chapter covers born-digital dictionaries too.


I don't think changing the filename of this chapter is warranted as yet. 
There was some discussion about extending its coverage so as to deliver 
more specifically on the promise made in its first chapter that its 
content could also be applied to non-print dictionaries, but so far that 
extension  hasn't happened yet. Unless and until it does, I think this 
change would be a needless additional complication, needlessly messing 
up links to the chapter (of which there are probably many more than 
there are links to its component sections).

People use the content  of the msDescription chapter to describe things 
that aren't manuscripts too.


From rwelzenbach at gmail.com  Fri Apr 20 15:00:18 2012
From: rwelzenbach at gmail.com (Rebecca Welzenbach)
Date: Fri, 20 Apr 2012 15:00:18 -0400
Subject: [tei-council] New council members and SourceForge
In-Reply-To: <Pine.LNX.4.64.1204192106340.9625@zaxxon.gpcc.itd.umich.edu>
References: <4F90B586.3010308@uvic.ca>
	<Pine.LNX.4.64.1204192106340.9625@zaxxon.gpcc.itd.umich.edu>
Message-ID: <CAA2irt+dK_g6GXe=P+QUEN3DAu0DWJXBBTyrYmJssN2Q_uzbPA@mail.gmail.com>

Thanks for doing this, Martin. My sourceforge ID is 'rwelzenb'. It is
as-yet untested, but ready to be assigned something--like me.

Becky

P.S. I see Paul and I are still not in agreement on the issue of
spaces around parenthetical em dashes.



On Thu, Apr 19, 2012 at 9:07 PM, Paul F. Schaffner
<PFSchaffner at umich.edu> wrote:
>
> Martin, my sourceforge ID is 'pfschaffner'. It's old but still
> works -- like me :)
>
> pfs
>
> On Thu, 19 Apr 2012, Martin Holmes wrote:
>
>> One thing we should have done at the ftf is to get the new Council
>> members set up with SourceForge accounts and add them to the project, so
>> that we can assign tickets to them. Neither Becky nor Paul are members
>> of the TEI project on SF yet. Do either of you have a SourceForge
>> account? If not, could you set one up:
>>
>> <https://sourceforge.net/user/registration>
>>
>> Once you have an id, let me know and I'll add you to the list, and then
>> you can start getting tickets dumped on you by the likes of us. :-)
>>
>> Cheers,
>> Martin
>> --
>> Martin Holmes
>> University of Victoria Humanities Computing and Media Centre
>> (mholmes at uvic.ca)
>> --
>> tei-council mailing list
>> tei-council at lists.village.Virginia.EDU
>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>>
>> PLEASE NOTE: postings to this list are publicly archived
>>
>>
>>
>
> --------------------------------------------------------------------
> Paul Schaffner | PFSchaffner at umich.edu | http://www.umich.edu/~pfs/
> 316-C Hatcher Library N, Univ. of Michigan, Ann Arbor MI 48109-1190
> --------------------------------------------------------------------
> --
> tei-council mailing list
> tei-council at lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>
> PLEASE NOTE: postings to this list are publicly archived

From kevin.s.hawkins at ultraslavonic.info  Fri Apr 20 15:24:15 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Fri, 20 Apr 2012 15:24:15 -0400
Subject: [tei-council] removing and renaming XML files
In-Reply-To: <4F919FC1.2030400@retired.ox.ac.uk>
References: <4F910341.8070906@gmail.com> <4F916121.3040808@o2.pl>
	<4F919FC1.2030400@retired.ox.ac.uk>
Message-ID: <4F91B7DF.2080209@ultraslavonic.info>

On 4/20/2012 1:41 PM, Lou Burnard wrote:
> On 20/04/12 14:14, Piotr Ba?ski wrote:
>> On 20/04/12 08:33, stuart yeates wrote:
>> [..]
>>> I would also like to rename:
>>>
>>> P5/Source/Guidelines/*/DI-PrintDictionaries.xml
>>>
>>> to
>>>
>>> P5/Source/Guidelines/*/DI-Dictionaries.xml
>>>
>>> because this chapter covers born-digital dictionaries too.
>
>
> I don't think changing the filename of this chapter is warranted as yet.
> There was some discussion about extending its coverage so as to deliver
> more specifically on the promise made in its first chapter that its
> content could also be applied to non-print dictionaries, but so far that
> extension  hasn't happened yet.

Lou, do you mean "the promise made in the first section of this chapter"?

The title of the chapter given in the HTML and PDF versions of the 
Guidelines is already "Dictionaries", not "Print Dictionaries", so I 
think Piotr is suggesting renaming the file to match the human-readable 
form actually in use.

 > Unless and until it does, I think this
> change would be a needless additional complication, needlessly messing
> up links to the chapter (of which there are probably many more than
> there are links to its component sections).
>
> People use the content  of the msDescription chapter to describe things
> that aren't manuscripts too.

Yes, and this causes confusion because people who are working with 
printed works aren't sure whether to use this chapter.  On this note, I 
think I've found a chair for a rechartered physical bibliography group 
who can lead the many people who have expressed interest in the group 
but been unwilling to lead the effort.  I asked her to draft a new 
charter that I could share with Council before the group gets started 
(in case we feel they are headed in entirely the wrong direction).

From syeates at gmail.com  Fri Apr 20 15:49:22 2012
From: syeates at gmail.com (stuart yeates)
Date: Sat, 21 Apr 2012 07:49:22 +1200
Subject: [tei-council] removing and renaming XML files
In-Reply-To: <4F917039.9060903@uvic.ca>
References: <4F910341.8070906@gmail.com> <4F916121.3040808@o2.pl>
	<4F917039.9060903@uvic.ca>
Message-ID: <4F91BDC2.9020802@gmail.com>

On 21/04/12 02:18, Martin Holmes wrote:
> Better to break the links and fix them, I think, since we're winding up
> to a "major" release, and if the tei_ prefix in anchors is included in
> it, lots of existing links will break anyway.

Only the "DI" part is included in the anchors (or the ones I checked, 
anyway).

I don't believe that this will break any links and should not be 
supported / should be actively rolled back if it is later found to be 
breaking them.

> But this really ought to be a policy issue. Under what circumstances is
> it acceptable to break existing links to a) pages in the Guidelines, and
> b) anchors on pages? And when we do break them with a new release, what
> are our obligations in terms of supporting the old links?

I'd support not deliberately breaking links until P6.

cheers
stuart

From mholmes at uvic.ca  Fri Apr 20 15:55:35 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Fri, 20 Apr 2012 12:55:35 -0700
Subject: [tei-council] New council members and SourceForge
In-Reply-To: <CAA2irt+dK_g6GXe=P+QUEN3DAu0DWJXBBTyrYmJssN2Q_uzbPA@mail.gmail.com>
References: <4F90B586.3010308@uvic.ca>
	<Pine.LNX.4.64.1204192106340.9625@zaxxon.gpcc.itd.umich.edu>
	<CAA2irt+dK_g6GXe=P+QUEN3DAu0DWJXBBTyrYmJssN2Q_uzbPA@mail.gmail.com>
Message-ID: <4F91BF37.5010100@uvic.ca>

Hi Rebecca,

I've added you as a Technician on Bugs and Feature Requests, and 
assigned you this ticket:

<http://purl.org/TEI/BUGS/3471119>

You can close it when you've set up the style guide document and copied 
the relevant bits into it from the ticket.

Cheers,
Martin

On 12-04-20 12:00 PM, Rebecca Welzenbach wrote:
> Thanks for doing this, Martin. My sourceforge ID is 'rwelzenb'. It is
> as-yet untested, but ready to be assigned something--like me.
>
> Becky
>
> P.S. I see Paul and I are still not in agreement on the issue of
> spaces around parenthetical em dashes.
>
>
>
> On Thu, Apr 19, 2012 at 9:07 PM, Paul F. Schaffner
> <PFSchaffner at umich.edu>  wrote:
>>
>> Martin, my sourceforge ID is 'pfschaffner'. It's old but still
>> works -- like me :)
>>
>> pfs
>>
>> On Thu, 19 Apr 2012, Martin Holmes wrote:
>>
>>> One thing we should have done at the ftf is to get the new Council
>>> members set up with SourceForge accounts and add them to the project, so
>>> that we can assign tickets to them. Neither Becky nor Paul are members
>>> of the TEI project on SF yet. Do either of you have a SourceForge
>>> account? If not, could you set one up:
>>>
>>> <https://sourceforge.net/user/registration>
>>>
>>> Once you have an id, let me know and I'll add you to the list, and then
>>> you can start getting tickets dumped on you by the likes of us. :-)
>>>
>>> Cheers,
>>> Martin
>>> --
>>> Martin Holmes
>>> University of Victoria Humanities Computing and Media Centre
>>> (mholmes at uvic.ca)
>>> --
>>> tei-council mailing list
>>> tei-council at lists.village.Virginia.EDU
>>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>>>
>>> PLEASE NOTE: postings to this list are publicly archived
>>>
>>>
>>>
>>
>> --------------------------------------------------------------------
>> Paul Schaffner | PFSchaffner at umich.edu | http://www.umich.edu/~pfs/
>> 316-C Hatcher Library N, Univ. of Michigan, Ann Arbor MI 48109-1190
>> --------------------------------------------------------------------
>> --
>> tei-council mailing list
>> tei-council at lists.village.Virginia.EDU
>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>>
>> PLEASE NOTE: postings to this list are publicly archived

From PFSchaffner at umich.edu  Fri Apr 20 16:06:15 2012
From: PFSchaffner at umich.edu (Paul F. Schaffner)
Date: Fri, 20 Apr 2012 16:06:15 -0400 (EDT)
Subject: [tei-council] New council members and SourceForge
In-Reply-To: <4F91BF37.5010100@uvic.ca>
References: <4F90B586.3010308@uvic.ca>
	<Pine.LNX.4.64.1204192106340.9625@zaxxon.gpcc.itd.umich.edu>
	<CAA2irt+dK_g6GXe=P+QUEN3DAu0DWJXBBTyrYmJssN2Q_uzbPA@mail.gmail.com>
	<4F91BF37.5010100@uvic.ca>
Message-ID: <Pine.LNX.4.64.1204201600080.6689@rygar.gpcc.itd.umich.edu>

Paul wrote:
>> It's old but still works -- like me.
Becky wrote:
>> ... ready to be assigned something--like me.
>> P.S. I see Paul and I are still not in agreement on the issue of
>> spaces around parenthetical em dashes.

Examining my own usage--always a perilous thing--I find that I
close up the spaces in more formal prose, and where the dashes
are truly parenthetical; but in more liberated settings, or when
leaping from a sentence into a concluding exclamation, or on
Fridays -- well then, the em-dashes require a little room around
them to breathe!

This should not be construed as a feature request.

pfs
--------------------------------------------------------------------
Paul Schaffner | PFSchaffner at umich.edu | http://www.umich.edu/~pfs/
316-C Hatcher Library N, Univ. of Michigan, Ann Arbor MI 48109-1190
--------------------------------------------------------------------

From mholmes at uvic.ca  Fri Apr 20 17:40:41 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Fri, 20 Apr 2012 14:40:41 -0700
Subject: [tei-council] New council members and SourceForge
In-Reply-To: <Pine.LNX.4.64.1204201600080.6689@rygar.gpcc.itd.umich.edu>
References: <4F90B586.3010308@uvic.ca>
	<Pine.LNX.4.64.1204192106340.9625@zaxxon.gpcc.itd.umich.edu>
	<CAA2irt+dK_g6GXe=P+QUEN3DAu0DWJXBBTyrYmJssN2Q_uzbPA@mail.gmail.com>
	<4F91BF37.5010100@uvic.ca>
	<Pine.LNX.4.64.1204201600080.6689@rygar.gpcc.itd.umich.edu>
Message-ID: <4F91D7D9.4040906@uvic.ca>

I think we decided re spaces around em dashes. We go with Chicago, and 
don't permit them.

However, I've left them in non-English language text, as well as in 
quotations, egXMLs, and bibliographic items such as ISO document titles, 
on the grounds that when you're quoting something else, you'll quote its 
spacing as well.

Cheers,
Martin

On 12-04-20 01:06 PM, Paul F. Schaffner wrote:
> Paul wrote:
>>> It's old but still works -- like me.
> Becky wrote:
>>> ... ready to be assigned something--like me.
>>> P.S. I see Paul and I are still not in agreement on the issue of
>>> spaces around parenthetical em dashes.
>
> Examining my own usage--always a perilous thing--I find that I
> close up the spaces in more formal prose, and where the dashes
> are truly parenthetical; but in more liberated settings, or when
> leaping from a sentence into a concluding exclamation, or on
> Fridays -- well then, the em-dashes require a little room around
> them to breathe!
>
> This should not be construed as a feature request.
>
> pfs
> --------------------------------------------------------------------
> Paul Schaffner | PFSchaffner at umich.edu | http://www.umich.edu/~pfs/
> 316-C Hatcher Library N, Univ. of Michigan, Ann Arbor MI 48109-1190
> --------------------------------------------------------------------

From lou.burnard at retired.ox.ac.uk  Fri Apr 20 18:19:37 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Fri, 20 Apr 2012 23:19:37 +0100
Subject: [tei-council] removing and renaming XML files
In-Reply-To: <4F91B7DF.2080209@ultraslavonic.info>
References: <4F910341.8070906@gmail.com>
	<4F916121.3040808@o2.pl>	<4F919FC1.2030400@retired.ox.ac.uk>
	<4F91B7DF.2080209@ultraslavonic.info>
Message-ID: <4F91E0F9.4050205@retired.ox.ac.uk>

On 20/04/12 20:24, Kevin Hawkins wrote:
> On 4/20/2012 1:41 PM, Lou Burnard wrote:
>> On 20/04/12 14:14, Piotr Ba?ski wrote:
>>> On 20/04/12 08:33, stuart yeates wrote:
>>> [..]
>>>> I would also like to rename:
>>>>
>>>> P5/Source/Guidelines/*/DI-PrintDictionaries.xml
>>>>
>>>> to
>>>>
>>>> P5/Source/Guidelines/*/DI-Dictionaries.xml
>>>>
>>>> because this chapter covers born-digital dictionaries too.
>>
>>
>> I don't think changing the filename of this chapter is warranted as yet.
>> There was some discussion about extending its coverage so as to deliver
>> more specifically on the promise made in its first chapter that its
>> content could also be applied to non-print dictionaries, but so far that
>> extension  hasn't happened yet.
>
> Lou, do you mean "the promise made in the first section of this chapter"?

Indeed I do. Sorry about the tyupo.

>
> The title of the chapter given in the HTML and PDF versions of the
> Guidelines is already "Dictionaries", not "Print Dictionaries", so I
> think Piotr is suggesting renaming the file to match the human-readable
> form actually in use.
>

Good point. I had forgotten that.


>   >  Unless and until it does, I think this
>> change would be a needless additional complication, needlessly messing
>> up links to the chapter (of which there are probably many more than
>> there are links to its component sections).
>>

I still think that on balance it's not worth the effort of renaming the 
chapter file. But then I was also the one who wanted to leave it with 
the name "DI,xml" on the grounds that introducing more information into 
file names would only lead to tears before bedtime. And lo...


From syeates at gmail.com  Fri Apr 20 19:03:21 2012
From: syeates at gmail.com (stuart yeates)
Date: Sat, 21 Apr 2012 11:03:21 +1200
Subject: [tei-council] Links in examples
In-Reply-To: <C69C38D5-CD5C-4B47-B993-348054B504A2@oucs.ox.ac.uk>
References: <4F910332.4000701@gmail.com>
	<C69C38D5-CD5C-4B47-B993-348054B504A2@oucs.ox.ac.uk>
Message-ID: <4F91EB39.70902@gmail.com>

On 20/04/12 23:49, Sebastian Rahtz wrote:
> see http://bits.nsms.ox.ac.uk:8080/jenkins/job/TEIP5-Documentation/lastSuccessfulBuild/artifact/Guidelines-web/fr/html/examples-lg.html
> now after Stuart's changes. Seems right

On the third attempt I appear to have fixed this properly.

Jenkins proved very useful in getting this right.

cheers
stuart


From mholmes at uvic.ca  Sat Apr 21 02:42:07 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Sat, 21 Apr 2012 02:42:07 -0400
Subject: [tei-council] Attributes without examples
In-Reply-To: <4F90AEBC.6000608@ultraslavonic.info>
References: <4F908F22.4070908@uvic.ca> <4F90AD72.10605@uvic.ca>
	<4F90AEBC.6000608@ultraslavonic.info>
Message-ID: <4F9256BF.5050406@uvic.ca>

I'll do this on Monday, but before I do: does everyone have an account 
on the wiki?

Cheers,
Martin

On 12-04-19 08:33 PM, Kevin Hawkins wrote:
> Would you be able to output as a table with a third column for people to
> sign up, either in MediaWiki or HTML syntax, for a page in the wiki?
>
> On 4/19/12 8:27 PM, Martin Holmes wrote:
>> Below is another slightly shorter list. These are attributes which do
>> not appear on any examples in the<elementSpec>   or<classSpec>   in which
>> they're defined. Not that this doesn't mean there are no examples at all
>> for them; there may be an example somewhere in the Guidelines text, or
>> the attribute may be defined in a<classSpec>   for an attribute class,
>> and then show up in an example in an<elementSpec>   for an element which
>> belongs to that class. An example of the latter is @agent (att.damaged),
>> which has no example in the att.damaged<classSpec>, but happens to show
>> up in an example for the<damage>   element.
>>
>> Nevertheless, I think it would be a good idea to try to provide examples
>> for all these attributes, in the files which define them.
>>
>> ATTRIBUTES WHICH DO NOT SHOW UP ON ANY EXAMPLE IN THEIR elementSpec OR
>> classSpec AS OF 2012-04-19T17:19:17.315-07:00
>>
>> 1. absolute (when)
>> 2. adj (node)
>> 3. adjFrom (node)
>> 4. adjTo (node)
>> 5. age (personGrp)
>> 6. agent (att.damaged)
>> 7. agent (gap)
>> 8. agent (unclear)
>> 9. ana (att.global.analytic)
>> 10. atLeast (att.ranging)
>> 11. atMost (att.ranging)
>> 12. attachment (surface)
>> 13. autoPrefix (content)
>> 14. baseTypes (fsDecl)
>> 15. break (att.breaking)
>> 16. cRef (gloss)
>> 17. cRef (ptr)
>> 18. cRef (ref)
>> 19. cRef (term)
>> 20. cause (att.textCritical)
>> 21. cause (att.transcriptional)
>> 22. cert (att.responsibility)
>> 23. change (att.global.change)
>> 24. class (msContents)
>> 25. cols (att.tableDecoration)
>> 26. confidence (att.ranging)
>> 27. contemporary (seal)
>> 28. copyOf (att.global.linking)
>> 29. corresp (att.global.linking)
>> 30. datingMethod (att.datable.custom)
>> 31. datingPoint (att.datable.custom)
>> 32. decls (att.declaring)
>> 33. default (att.declarable)
>> 34. defective (att.msExcerpt)
>> 35. degree (att.damaged)
>> 36. degree (node)
>> 37. dim (space)
>> 38. direct (said)
>> 39. docLang (schemaSpec)
>> 40. domains (att.pointing.group)
>> 41. dur (att.duration.w3c)
>> 42. dur-iso (att.duration.iso)
>> 43. encoding (binaryObject)
>> 44. end (att.timed)
>> 45. enjamb (att.enjamb)
>> 46. evaluate (att.pointing)
>> 47. evidence (att.editLike)
>> 48. except (moduleRef)
>> 49. exclude (att.global.linking)
>> 50. expand (att.lexicographic)
>> 51. extent (orth)
>> 52. fVal (f)
>> 53. facs (att.global.facs)
>> 54. feats (fs)
>> 55. filter (equiv)
>> 56. flipping (surface)
>> 57. follow (leaf)
>> 58. force (pc)
>> 59. from (app)
>> 60. from (att.datable.w3c)
>> 61. from-custom (att.datable.custom)
>> 62. from-iso (att.datable.iso)
>> 63. full (att.personal)
>> 64. function (att.segLike)
>> 65. generate (classSpec)
>> 66. gradual (writing)
>> 67. group (att.damaged)
>> 68. hand (att.damaged)
>> 69. hand (att.textCritical)
>> 70. hand (att.transcriptional)
>> 71. hand (gap)
>> 72. hand (unclear)
>> 73. height (binaryObject)
>> 74. height (graphic)
>> 75. ident (att.identified)
>> 76. inst (att.interpLike)
>> 77. instant (att.editLike)
>> 78. key (att.canonical)
>> 79. key (classRef)
>> 80. key (macroRef)
>> 81. level (sense)
>> 82. level (title)
>> 83. loc (app)
>> 84. location (att.lexicographic)
>> 85. lrx (att.coordinated)
>> 86. lry (att.coordinated)
>> 87. match (att.scoping)
>> 88. material (supportDesc)
>> 89. max (att.ranging)
>> 90. max (memberOf)
>> 91. medium (att.handFeatures)
>> 92. mergedIn (att.lexicographic)
>> 93. met (att.metrical)
>> 94. method (correction)
>> 95. mimeType (att.internetMedia)
>> 96. min (att.ranging)
>> 97. min (memberOf)
>> 98. mode (att.combinable)
>> 99. mode (classes)
>> 100. mode (memberOf)
>> 101. module (att.identified)
>> 102. new (handShift)
>> 103. next (att.global.linking)
>> 104. notAfter-custom (att.datable.custom)
>> 105. notAfter-iso (att.datable.iso)
>> 106. notBefore-custom (att.datable.custom)
>> 107. notBefore-iso (att.datable.iso)
>> 108. notation (pron)
>> 109. ns (attDef)
>> 110. ns (elementSpec)
>> 111. ns (schemaSpec)
>> 112. nymRef (att.naming)
>> 113. opt (att.lexicographic)
>> 114. optional (fDecl)
>> 115. ord (iNode)
>> 116. ord (root)
>> 117. org (att.divLike)
>> 118. org (attList)
>> 119. orig (att.lexicographic)
>> 120. part (ab)
>> 121. part (att.divLike)
>> 122. part (att.segLike)
>> 123. parts (nym)
>> 124. perf (tech)
>> 125. period (att.datable)
>> 126. pre (pc)
>> 127. precision (att.dimensions)
>> 128. predeclare (att.identified)
>> 129. prefix (elementSpec)
>> 130. prefix (moduleRef)
>> 131. prev (att.global.linking)
>> 132. quantity (att.dimensions)
>> 133. real (att.metrical)
>> 134. ref (att.canonical)
>> 135. refLang (att.pointing)
>> 136. resp (att.responsibility)
>> 137. resp (space)
>> 138. rhyme (att.metrical)
>> 139. role (att.naming)
>> 140. role (att.tableDecoration)
>> 141. role (org)
>> 142. rotate (zone)
>> 143. rows (att.tableDecoration)
>> 144. sameAs (att.global.linking)
>> 145. sample (att.divLike)
>> 146. scale (binaryObject)
>> 147. scale (graphic)
>> 148. scheme (catRef)
>> 149. scheme (locus)
>> 150. scheme (locusGrp)
>> 151. scheme (tag)
>> 152. scope (att.dimensions)
>> 153. scope (att.handFeatures)
>> 154. scribe (att.handFeatures)
>> 155. scribeRef (att.handFeatures)
>> 156. script (att.handFeatures)
>> 157. scriptRef (att.handFeatures)
>> 158. select (att.global.linking)
>> 159. seq (att.transcriptional)
>> 160. social (distinct)
>> 161. sort (att.personal)
>> 162. source (att.editLike)
>> 163. source (att.readFrom)
>> 164. source (writing)
>> 165. space (distinct)
>> 166. spanTo (att.spanning)
>> 167. split (att.lexicographic)
>> 168. start (att.coordinated)
>> 169. start (att.timed)
>> 170. status (att.identified)
>> 171. status (att.transcriptional)
>> 172. status (correction)
>> 173. stdDeviation (precision)
>> 174. subtype (att.typed)
>> 175. synch (att.global.linking)
>> 176. targFunc (att.pointing.group)
>> 177. target (change)
>> 178. target (relatedItem)
>> 179. targetEnd (note)
>> 180. targetLang (schemaSpec)
>> 181. targets (alt)
>> 182. targets (join)
>> 183. targets (link)
>> 184. time (distinct)
>> 185. to (app)
>> 186. to (att.datable.w3c)
>> 187. to-custom (att.datable.custom)
>> 188. to-iso (att.datable.iso)
>> 189. type (abbr)
>> 190. type (att.entryLike)
>> 191. type (att.interpLike)
>> 192. type (att.textCritical)
>> 193. type (att.typed)
>> 194. type (form)
>> 195. type (q)
>> 196. type (sound)
>> 197. ulx (att.coordinated)
>> 198. uly (att.coordinated)
>> 199. unit (att.dimensions)
>> 200. unit (pc)
>> 201. unit (when)
>> 202. url (moduleRef)
>> 203. value (att.lexicographic)
>> 204. value (eTree)
>> 205. value (iNode)
>> 206. value (leaf)
>> 207. value (node)
>> 208. value (root)
>> 209. value (triangle)
>> 210. varSeq (att.textCritical)
>> 211. version (unicodeName)
>> 212. versionDate (att.translatable)
>> 213. when (docDate)
>> 214. where (event)
>> 215. who (att.ascribed)
>> 216. width (binaryObject)
>> 217. width (graphic)
>> 218. wit (att.rdgPart)
>> 219. wit (att.witnessed)
>> 220. xml:base (att.global)
>> 221. xml:id (att.global)
>> 222. xml:lang (att.global)
>> 223. xml:space (att.global)
>>
>> Cheers,
>> Martin
>>
>> On 12-04-19 03:18 PM, Martin Holmes wrote:
>>> Following on from our discussion of examples for attributes, a
>>> quick-and-dirty XSLT seems to show that there are only 19 attributes
>>> with their own examples, and 450 without. This is not to say that those
>>> without are unexemplified, because the example code for their parent
>>> elements in the elementSpec may show examples of them; I'll refine the
>>> XSLT and make that apparent.
>>>
>>> Here's the list:
>>>
>>> ATTRIBUTE DEFINITIONS LACKING EXAMPLES AS OF 2012-04-19T15:12:34.968-07:00
>>>
>>> 1. status (att.identified)
>>> 2. type (interaction)
>>> 3. value (sex)
>>> 4. scale (graphic)
>>> 5. scale (binaryObject)
>>> 6. weights (alt)
>>> 7. hand (att.damaged)
>>> 8. agent (gap)
>>> 9. predeclare (att.identified)
>>> 10. degree (att.damaged)
>>> 11. module (att.identified)
>>> 12. ident (att.identified)
>>> 13. height (graphic)
>>> 14. height (binaryObject)
>>> 15. width (graphic)
>>> 16. width (binaryObject)
>>> 17. encoding (binaryObject)
>>> 18. version (teiCorpus)
>>> 19. hand (unclear)
>>> 20. agent (unclear)
>>> 21. feature (shift)
>>> 22. type (preparedness)
>>> 23. type (abbr)
>>> 24. commodity (att.measurement)
>>> 25. agent (att.damaged)
>>> 26. type (derivation)
>>> 27. type (domain)
>>> 28. type (factuality)
>>> 29. type (idno)
>>> 30. type (relation)
>>> 31. type (sound)
>>> 32. type (tech)
>>> 33. type (castItem)
>>> 34. type (att.typed)
>>> 35. type (move)
>>> 36. script (att.handFeatures)
>>> 37. class (msItemStruct)
>>> 38. class (msItem)
>>> 39. class (msContents)
>>> 40. type (form)
>>> 41. cause (att.textCritical)
>>> 42. type (gram)
>>> 43. type (lbl)
>>> 44. type (att.textCritical)
>>> 45. type (title)
>>> 46. type (titlePage)
>>> 47. type (usg)
>>> 48. type (app)
>>> 49. columns (layout)
>>> 50. valueDatcat (att.datcat)
>>> 51. datcat (att.datcat)
>>> 52. contemporary (seal)
>>> 53. contemporary (binding)
>>> 54. from (locus)
>>> 55. type (list)
>>> 56. result (joinGrp)
>>> 57. medium (att.handFeatures)
>>> 58. type (graph)
>>> 59. type (witDetail)
>>> 60. origin (timeline)
>>> 61. function (att.segLike)
>>> 62. form (objectDesc)
>>> 63. mergedIn (att.lexicographic)
>>> 64. type (fsDecl)
>>> 65. scribe (att.handFeatures)
>>> 66. degree (node)
>>> 67. extent (orth)
>>> 68. from (arc)
>>> 69. to (arc)
>>> 70. inDegree (node)
>>> 71. arity (tree)
>>> 72. baseTypes (fsDecl)
>>> 73. level (sense)
>>> 74. order (tree)
>>> 75. outDegree (iNode)
>>> 76. outDegree (node)
>>> 77. outDegree (root)
>>> 78. reason (gap)
>>> 79. type (orth)
>>> 80. when (docDate)
>>> 81. split (att.lexicographic)
>>> 82. code (socecStatus)
>>> 83. code (occupation)
>>> 84. decls (att.declaring)
>>> 85. cRef (term)
>>> 86. from (app)
>>> 87. scheme (catRef)
>>> 88. scheme (occupation)
>>> 89. scheme (classCode)
>>> 90. scheme (socecStatus)
>>> 91. scheme (keywords)
>>> 92. to (app)
>>> 93. baseForm (m)
>>> 94. new (handShift)
>>> 95. passive (relation)
>>> 96. since (when)
>>> 97. type (fsdLink)
>>> 98. type (biblScope)
>>> 99. type (listForest)
>>> 100. type (forest)
>>> 101. hand (gap)
>>> 102. given (certainty)
>>> 103. locus (certainty)
>>> 104. type (rs)
>>> 105. source (normalization)
>>> 106. level (title)
>>> 107. degree (certainty)
>>> 108. status (correction)
>>> 109. degree (precision)
>>> 110. spanTo (att.spanning)
>>> 111. to (att.datable.w3c)
>>> 112. to-iso (att.datable.iso)
>>> 113. force (pc)
>>> 114. reason (surplus)
>>> 115. type (stage)
>>> 116. type (oRef)
>>> 117. type (oVar)
>>> 118. method (correction)
>>> 119. method (normalization)
>>> 120. name (fDecl)
>>> 121. evidence (att.editLike)
>>> 122. rows (table)
>>> 123. org (vMerge)
>>> 124. who (att.ascribed)
>>> 125. locus (respons)
>>> 126. from-custom (att.datable.custom)
>>> 127. from (att.datable.w3c)
>>> 128. from-iso (att.datable.iso)
>>> 129. type (xr)
>>> 130. type (iType)
>>> 131. type (num)
>>> 132. type (att.entryLike)
>>> 133. type (att.interpLike)
>>> 134. unit (refState)
>>> 135. notation (pron)
>>> 136. break (att.breaking)
>>> 137. iterated (kinesic)
>>> 138. iterated (vocal)
>>> 139. optional (fDecl)
>>> 140. default (att.declarable)
>>> 141. location (variantEncoding)
>>> 142. anchored (note)
>>> 143. full (att.personal)
>>> 144. type (metDecl)
>>> 145. extent (pron)
>>> 146. discrete (sound)
>>> 147. scope (join)
>>> 148. gradual (writing)
>>> 149. sample (att.divLike)
>>> 150. type (classSpec)
>>> 151. pre (pc)
>>> 152. type (dimensions)
>>> 153. method (variantEncoding)
>>> 154. type (macroSpec)
>>> 155. reason (supplied)
>>> 156. to (locus)
>>> 157. rows (att.tableDecoration)
>>> 158. writtenLines (layout)
>>> 159. ruledLines (layout)
>>> 160. location (att.lexicographic)
>>> 161. hands (handDesc)
>>> 162. material (supportDesc)
>>> 163. notation (formula)
>>> 164. unit (att.dimensions)
>>> 165. ns (attDef)
>>> 166. ns (elementSpec)
>>> 167. domains (att.pointing.group)
>>> 168. part (att.segLike)
>>> 169. source (writing)
>>> 170. ref (g)
>>> 171. scribeRef (att.handFeatures)
>>> 172. scriptRef (att.handFeatures)
>>> 173. copyOf (att.global.linking)
>>> 174. sameAs (att.global.linking)
>>> 175. exclude (att.global.linking)
>>> 176. targetEnd (note)
>>> 177. next (att.global.linking)
>>> 178. target (relatedItem)
>>> 179. unit (milestone)
>>> 180. label (rhyme)
>>> 181. lemma (w)
>>> 182. children (iNode)
>>> 183. children (root)
>>> 184. name (f)
>>> 185. unit (pc)
>>> 186. value (leaf)
>>> 187. type (node)
>>> 188. key (att.canonical)
>>> 189. follow (iNode)
>>> 190. follow (leaf)
>>> 191. parent (leaf)
>>> 192. parent (iNode)
>>> 193. value (node)
>>> 194. value (triangle)
>>> 195. value (eLeaf)
>>> 196. value (eTree)
>>> 197. value (iNode)
>>> 198. value (root)
>>> 199. quantity (att.measurement)
>>> 200. role (att.tableDecoration)
>>> 201. scheme (att)
>>> 202. select (att.global.linking)
>>> 203. xml:space (att.global)
>>> 204. hand (att.textCritical)
>>> 205. subtype (att.typed)
>>> 206. prefix (schemaSpec)
>>> 207. prefix (elementSpec)
>>> 208. type (purpose)
>>> 209. role (org)
>>> 210. role (person)
>>> 211. matchPattern (cRefPattern)
>>> 212. replacementPattern (cRefPattern)
>>> 213. age (person)
>>> 214. start (schemaSpec)
>>> 215. form (quotation)
>>> 216. time (distinct)
>>> 217. social (distinct)
>>> 218. space (distinct)
>>> 219. type (constitution)
>>> 220. scope (att.handFeatures)
>>> 221. age (personGrp)
>>> 222. usage (language)
>>> 223. ident (valItem)
>>> 224. from (span)
>>> 225. value (metSym)
>>> 226. versionDate (att.translatable)
>>> 227. target (att.pointing)
>>> 228. where (move)
>>> 229. notBefore (att.datable.w3c)
>>> 230. notBefore-custom (att.datable.custom)
>>> 231. notBefore-iso (att.datable.iso)
>>> 232. mode (classes)
>>> 233. mode (att.combinable)
>>> 234. mode (memberOf)
>>> 235. to (span)
>>> 236. to (biblScope)
>>> 237. type (valList)
>>> 238. degree (purpose)
>>> 239. length (refState)
>>> 240. render (tagUsage)
>>> 241. targets (alt)
>>> 242. targets (join)
>>> 243. targets (link)
>>> 244. type (teiHeader)
>>> 245. notAfter (att.datable.w3c)
>>> 246. notAfter-custom (att.datable.custom)
>>> 247. notAfter-iso (att.datable.iso)
>>> 248. version (TEI)
>>> 249. mode (channel)
>>> 250. result (join)
>>> 251. new (shift)
>>> 252. active (interaction)
>>> 253. occurs (tagUsage)
>>> 254. passive (interaction)
>>> 255. interval (when)
>>> 256. interval (timeline)
>>> 257. usage (attDef)
>>> 258. role (personGrp)
>>> 259. type (titlePart)
>>> 260. sex (personGrp)
>>> 261. sex (person)
>>> 262. size (personGrp)
>>> 263. from (biblScope)
>>> 264. type (distinct)
>>> 265. type (measure)
>>> 266. type (fs)
>>> 267. unit (timeline)
>>> 268. unit (when)
>>> 269. version (unicodeName)
>>> 270. type (divGen)
>>> 271. part (ab)
>>> 272. part (att.divLike)
>>> 273. part (l)
>>> 274. terminal (metSym)
>>> 275. trunc (numeric)
>>> 276. order (graph)
>>> 277. size (graph)
>>> 278. mode (alt)
>>> 279. mode (altGrp)
>>> 280. value (binary)
>>> 281. status (availability)
>>> 282. datum (geoDecl)
>>> 283. value (numeric)
>>> 284. name (relation)
>>> 285. name (vLabel)
>>> 286. indexName (index)
>>> 287. stdDeviation (precision)
>>> 288. absolute (when)
>>> 289. max (numeric)
>>> 290. scheme (constraintSpec)
>>> 291. scheme (tag)
>>> 292. scheme (gi)
>>> 293. value (symbol)
>>> 294. value (num)
>>> 295. scheme (locusGrp)
>>> 296. scheme (locus)
>>> 297. name (namespace)
>>> 298. type (recording)
>>> 299. unit (att.measurement)
>>> 300. value (att.lexicographic)
>>> 301. scope (att.dimensions)
>>> 302. evaluate (att.pointing)
>>> 303. active (relation)
>>> 304. to-custom (att.datable.custom)
>>> 305. mutual (relation)
>>> 306. dur-iso (att.duration.iso)
>>> 307. instant (att.editLike)
>>> 308. function (metamark)
>>> 309. attachment (surface)
>>> 310. cause (att.transcriptional)
>>> 311. target (metamark)
>>> 312. rotate (zone)
>>> 313. target (redo)
>>> 314. target (undo)
>>> 315. except (moduleRef)
>>> 316. include (moduleRef)
>>> 317. datingMethod (att.datable.custom)
>>> 318. datingPoint (att.datable.custom)
>>> 319. key (moduleRef)
>>> 320. url (moduleRef)
>>> 321. mimeType (att.internetMedia)
>>> 322. version (application)
>>> 323. ident (application)
>>> 324. confidence (att.ranging)
>>> 325. level (langKnown)
>>> 326. adj (node)
>>> 327. adjFrom (node)
>>> 328. adjTo (node)
>>> 329. ana (att.global.analytic)
>>> 330. group (att.damaged)
>>> 331. cRef (gloss)
>>> 332. cRef (ptr)
>>> 333. cRef (ref)
>>> 334. cert (att.responsibility)
>>> 335. cert (certainty)
>>> 336. precision (precision)
>>> 337. precision (att.dimensions)
>>> 338. type (fw)
>>> 339. cols (table)
>>> 340. cols (att.tableDecoration)
>>> 341. source (att.editLike)
>>> 342. autoPrefix (content)
>>> 343. corresp (att.global.linking)
>>> 344. delim (refState)
>>> 345. dim (space)
>>> 346. docLang (schemaSpec)
>>> 347. dur (att.duration.w3c)
>>> 348. ed (att.sourced)
>>> 349. gi (tagUsage)
>>> 350. eol (hyphenation)
>>> 351. enjamb (att.enjamb)
>>> 352. facs (att.global.facs)
>>> 353. fVal (f)
>>> 354. feats (fs)
>>> 355. lang (code)
>>> 356. atMost (att.ranging)
>>> 357. atLeast (att.ranging)
>>> 358. lrx (att.coordinated)
>>> 359. ulx (att.coordinated)
>>> 360. lry (att.coordinated)
>>> 361. uly (att.coordinated)
>>> 362. xml:id (att.global)
>>> 363. ident (language)
>>> 364. scheme (rendition)
>>> 365. status (att.transcriptional)
>>> 366. where (event)
>>> 367. start (att.timed)
>>> 368. end (att.timed)
>>> 369. type (tag)
>>> 370. defective (att.msExcerpt)
>>> 371. generate (classSpec)
>>> 372. inst (att.interpLike)
>>> 373. xml:lang (att.global)
>>> 374. loc (app)
>>> 375. mainLang (textLang)
>>> 376. maxOccurs (datatype)
>>> 377. type (q)
>>> 378. direct (said)
>>> 379. aloud (said)
>>> 380. met (att.metrical)
>>> 381. real (att.metrical)
>>> 382. minOccurs (datatype)
>>> 383. name (equiv)
>>> 384. ns (schemaSpec)
>>> 385. n (att.global)
>>> 386. opt (att.lexicographic)
>>> 387. ord (iNode)
>>> 388. ord (root)
>>> 389. ord (tree)
>>> 390. sort (att.personal)
>>> 391. org (attList)
>>> 392. org (vColl)
>>> 393. org (att.divLike)
>>> 394. orig (att.lexicographic)
>>> 395. otherLangs (textLang)
>>> 396. perf (move)
>>> 397. perf (tech)
>>> 398. target (specGrpRef)
>>> 399. parts (nym)
>>> 400. change (att.global.change)
>>> 401. target (change)
>>> 402. prev (att.global.linking)
>>> 403. lemmaRef (w)
>>> 404. marks (quotation)
>>> 405. ref (att.canonical)
>>> 406. nymRef (att.naming)
>>> 407. filter (equiv)
>>> 408. pattern (metDecl)
>>> 409. resp (respons)
>>> 410. resp (att.responsibility)
>>> 411. resp (space)
>>> 412. rhyme (att.metrical)
>>> 413. seq (att.transcriptional)
>>> 414. hand (att.transcriptional)
>>> 415. prefix (moduleRef)
>>> 416. key (memberOf)
>>> 417. quantity (att.dimensions)
>>> 418. value (age)
>>> 419. target (fsdLink)
>>> 420. period (att.datable)
>>> 421. tag (langKnown)
>>> 422. tags (langKnowledge)
>>> 423. max (memberOf)
>>> 424. min (memberOf)
>>> 425. synch (att.global.linking)
>>> 426. targFunc (att.pointing.group)
>>> 427. targetLang (schemaSpec)
>>> 428. key (classRef)
>>> 429. key (elementRef)
>>> 430. key (macroRef)
>>> 431. name (attRef)
>>> 432. trans (u)
>>> 433. uri (equiv)
>>> 434. url (graphic)
>>> 435. varSeq (att.textCritical)
>>> 436. scope (rendition)
>>> 437. max (att.ranging)
>>> 438. min (att.ranging)
>>> 439. withId (tagUsage)
>>> 440. wit (att.witnessed)
>>> 441. wit (att.rdgPart)
>>> 442. wit (witDetail)
>>> 443. status (att.docStatus)
>>> 444. points (zone)
>>> 445. start (att.coordinated)
>>> 446. valid (egXML)
>>> 447. ordered (listChange)
>>> 448. role (att.naming)
>>> 449. source (att.readFrom)
>>> 450. flipping (surface)
>>>
>>>
>>> ATTRIBUTE DEFINITIONS WHICH HAVE EXAMPLES AS OF
>>> 2012-04-19T15:12:34.968-07:00
>>>
>>> 1. place (att.placement)
>>> 2. expand (att.lexicographic)
>>> 3. extent (att.dimensions)
>>> 4. calendar (att.datable)
>>> 5. reason (unclear)
>>> 6. target (att.scoping)
>>> 7. xml:base (att.global)
>>> 8. assertedValue (certainty)
>>> 9. refLang (att.pointing)
>>> 10. match (att.scoping)
>>> 11. sortKey (att.sortable)
>>> 12. atts (specDesc)
>>> 13. key (specDesc)
>>> 14. norm (att.lexicographic)
>>> 15. rendition (att.global)
>>> 16. rend (att.global)
>>> 17. when-iso (att.datable.iso)
>>> 18. when-custom (att.datable.custom)
>>> 19. when (att.datable.w3c)
>>>
>>> --
>>> Martin Holmes
>>> University of Victoria Humanities Computing and Media Centre
>>> (mholmes at uvic.ca)
>>> --
>>> tei-council mailing list
>>> tei-council at lists.village.Virginia.EDU
>>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>>>
>>> PLEASE NOTE: postings to this list are publicly archived
>>> .
>>>
>>

-- 
Martin Holmes
mholmes at uvic.ca
UVic Humanities Computing and Media Centre

From sebastian.rahtz at oucs.ox.ac.uk  Sat Apr 21 07:03:53 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Sat, 21 Apr 2012 11:03:53 +0000
Subject: [tei-council] next release?
Message-ID: <0F18A249-5480-42D9-BFF2-538AC7B9E1EB@oucs.ox.ac.uk>

something we forgot to debate in Ann Arbor was a timetable
for the next release, I think? i.e. what is the due date for
everyone to complete their ticket work so that Sir Gabriel
of B'odard can undertake his Quest.

speaking for myself, if I don't do my assignments
more or less immediately I will not get to them for ages,
so I favour a short window (say, 3 weeks).

Sebastian 

From bansp at o2.pl  Sat Apr 21 12:17:51 2012
From: bansp at o2.pl (=?ISO-8859-2?Q?Piotr_Ba=F1ski?=)
Date: Sat, 21 Apr 2012 18:17:51 +0200
Subject: [tei-council] Grouping traitlike, statelike,
	and eventlike elements - ID: 3060867
Message-ID: <4F92DDAF.4050900@o2.pl>

May I ask the Council to have a look at a ticket that was set to pending
and this is probably why it didn't make it onto Lou's list (and I wasn't
nagged by SF even once about it):

http://sourceforge.net/tracker/index.php?func=detail&aid=3060867&group_id=106328&atid=644065

I thought the implementation would be as quick as Lou's summary of what
we decided in Paris, but things do not seem that easy (the schema
becomes non-deterministic), unless we decide to split the
not-so-easy-to-implement listState into listOrgState,
listPersState, and listPlaceState (listPlaceStateLike? OhMyGoodness...).

I summarised the way I see this in my recent comment on the ticket. If
this reasoning is found correct, the practical question for the Council
is: do I have green light to implement the three above-mentioned list
elements?

Or do we take a different route, for example the route proposed
tentatively by Sebastian (let me stress that he wrote in a hurry from
the airport and kept to the logic of the decision made in Paris):

> I think I'd 
> 
>  * make a class model.stateLike
>  * make trait a direct member of that
>  * make the other stateLike classes members of it too
>  * refer to stateLike in listState
> 
> does that work?
> 

which I think has the semantic problem of mixing three kinds of
stateLike elements (and thus making it possible to talk about the
climate of a person and the sex of a place).

Thanks,

  P.

From mholmes at uvic.ca  Sat Apr 21 13:50:05 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Sat, 21 Apr 2012 10:50:05 -0700
Subject: [tei-council] next release?
In-Reply-To: <0F18A249-5480-42D9-BFF2-538AC7B9E1EB@oucs.ox.ac.uk>
References: <0F18A249-5480-42D9-BFF2-538AC7B9E1EB@oucs.ox.ac.uk>
Message-ID: <4F92F34D.2040103@uvic.ca>

Three weeks will be a bit tough for me, and a couple of the tickets I 
have might turn out to have unpredicted side-effects (like the tei_ 
prefix). As long as we have the option to launch without the change if 
it proves difficult, we could go with three weeks.

The attributes-without-examples problem is so large that we'll just have 
to hack away at it steadily.

Cheers,
Martin

On 12-04-21 04:03 AM, Sebastian Rahtz wrote:
> something we forgot to debate in Ann Arbor was a timetable
> for the next release, I think? i.e. what is the due date for
> everyone to complete their ticket work so that Sir Gabriel
> of B'odard can undertake his Quest.
>
> speaking for myself, if I don't do my assignments
> more or less immediately I will not get to them for ages,
> so I favour a short window (say, 3 weeks).
>
> Sebastian

From syeates at gmail.com  Sat Apr 21 17:46:04 2012
From: syeates at gmail.com (stuart yeates)
Date: Sun, 22 Apr 2012 09:46:04 +1200
Subject: [tei-council] Grouping traitlike, statelike,
 and eventlike elements - ID: 3060867
In-Reply-To: <4F92DDAF.4050900@o2.pl>
References: <4F92DDAF.4050900@o2.pl>
Message-ID: <4F932A9C.7070904@gmail.com>

On 22/04/12 04:17, Piotr Ba?ski wrote:
> May I ask the Council to have a look at a ticket that was set to pending
> and this is probably why it didn't make it onto Lou's list (and I wasn't
> nagged by SF even once about it):
>
> http://sourceforge.net/tracker/index.php?func=detail&aid=3060867&group_id=106328&atid=644065
>
> I thought the implementation would be as quick as Lou's summary of what
> we decided in Paris, but things do not seem that easy (the schema
> becomes non-deterministic), unless we decide to split the
> not-so-easy-to-implement listState into listOrgState,
> listPersState, and listPlaceState (listPlaceStateLike? OhMyGoodness...).
>
> I summarised the way I see this in my recent comment on the ticket. If
> this reasoning is found correct, the practical question for the Council
> is: do I have green light to implement the three above-mentioned list
> elements?
>
> Or do we take a different route, for example the route proposed
> tentatively by Sebastian (let me stress that he wrote in a hurry from
> the airport and kept to the logic of the decision made in Paris):
>
>> I think I'd
>>
>>   * make a class model.stateLike
>>   * make trait a direct member of that
>>   * make the other stateLike classes members of it too
>>   * refer to stateLike in listState
>>
>> does that work?
>>
>
> which I think has the semantic problem of mixing three kinds of
> stateLike elements (and thus making it possible to talk about the
> climate of a person and the sex of a place).

Splitting these is the sane approach, I think.

cheers
stuart


From mholmes at uvic.ca  Sat Apr 21 19:58:48 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Sat, 21 Apr 2012 16:58:48 -0700
Subject: [tei-council] Ignore my Jenkins for a while...
Message-ID: <4F9349B8.7030709@uvic.ca>

Hi all,

Just writing to warn everybody that I'm working on the configuration of 
jobs on my Jenkins box, with limited success, so builds are failing for 
reasons which probably have nothing to do with you. Sebastian says his 
Jinks is stable, and it looks to be so, so please refer to his when 
you've committed changes:

<http://bits.nsms.ox.ac.uk:8080/jenkins/>

rather than mine, which is two butties short of a picnic at the moment:

<http://teijenkins.hcmc.uvic.ca:8080/>

I'm hoping that normal service will be resumed as soon as possible. Once 
it's working again, I'll be leaving it well alone, and working on 
another VM built from Ubuntu Precise. That should ultimately replace 
this one, and be the model from which you can build your own Jenkins 
machine should you wish to.

Cheers,
Martin

From James.Cummings at oucs.ox.ac.uk  Mon Apr 23 09:11:02 2012
From: James.Cummings at oucs.ox.ac.uk (James Cummings)
Date: Mon, 23 Apr 2012 14:11:02 +0100
Subject: [tei-council] TEI-C Expenses for April Face to Face and Meals.
Message-ID: <4F9554E6.4080308@oucs.ox.ac.uk>


A reminder that TEI-C expense forms should be submitted within 10 
days of the end of the meeting (which I count as by this coming 
weekend).

I believe that the following meals were paid for by Kevin, Becky, 
or Paul and so cannot be claimed for by those present (thanks 
Kevin for the list):

= Sunday evening =
Lou Burnard, Piotr Banski, James Cummings, Kevin Hawkins

= Monday lunch =
everybody

= Monday dinner =
everybody

= Tuesday lunch =
everybody

= Tuesday dinner =
Lou Burnard, Martin Holmes, James Cummings, Sebastian Rahtz, 
Kevin Hawkins

= Wednesday lunch =
everybody except Martin Holmes


Let me know if there are any mistakes there as I'll be submitting 
that to the treasurer.

-James

-- 
Dr James Cummings, InfoDev,
Computing Services, University of Oxford

From James.Cummings at oucs.ox.ac.uk  Mon Apr 23 09:12:03 2012
From: James.Cummings at oucs.ox.ac.uk (James Cummings)
Date: Mon, 23 Apr 2012 14:12:03 +0100
Subject: [tei-council] TEI-C Expenses for April Face to Face and Meals.
In-Reply-To: <4F9554E6.4080308@oucs.ox.ac.uk>
References: <4F9554E6.4080308@oucs.ox.ac.uk>
Message-ID: <4F955523.6060405@oucs.ox.ac.uk>


Oh, and the PDF form is available at:
http://www.tei-c.org/Admin/TEI_travel_form.pdf

Best,
James

On 23/04/12 14:11, James Cummings wrote:
>
> A reminder that TEI-C expense forms should be submitted within 10
> days of the end of the meeting (which I count as by this coming
> weekend).
>
> I believe that the following meals were paid for by Kevin, Becky,
> or Paul and so cannot be claimed for by those present (thanks
> Kevin for the list):
>
> = Sunday evening =
> Lou Burnard, Piotr Banski, James Cummings, Kevin Hawkins
>
> = Monday lunch =
> everybody
>
> = Monday dinner =
> everybody
>
> = Tuesday lunch =
> everybody
>
> = Tuesday dinner =
> Lou Burnard, Martin Holmes, James Cummings, Sebastian Rahtz,
> Kevin Hawkins
>
> = Wednesday lunch =
> everybody except Martin Holmes
>
>
> Let me know if there are any mistakes there as I'll be submitting
> that to the treasurer.
>
> -James
>


-- 
Dr James Cummings, InfoDev,
Computing Services, University of Oxford

From mholmes at uvic.ca  Mon Apr 23 11:22:39 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Mon, 23 Apr 2012 08:22:39 -0700
Subject: [tei-council] Attributes without examples
In-Reply-To: <4F90AEBC.6000608@ultraslavonic.info>
References: <4F908F22.4070908@uvic.ca> <4F90AD72.10605@uvic.ca>
	<4F90AEBC.6000608@ultraslavonic.info>
Message-ID: <4F9573BF.1080302@uvic.ca>

I've just tried to create a wiki page which has a table listing all 
these attributes, but I've been prevented from doing so by the sad 
little spam filter, which won't allow this:

att.msExcerpt

because it contains "sEx".

I seem to remember having spent a frustrating time fighting with this 
stupidity some time ago. Does anyone remember how to get around this, or 
is it pointless to try?

Cheers,
Martin

On 12-04-19 05:33 PM, Kevin Hawkins wrote:
> Would you be able to output as a table with a third column for people to
> sign up, either in MediaWiki or HTML syntax, for a page in the wiki?
>
> On 4/19/12 8:27 PM, Martin Holmes wrote:
>> Below is another slightly shorter list. These are attributes which do
>> not appear on any examples in the<elementSpec>   or<classSpec>   in which
>> they're defined. Not that this doesn't mean there are no examples at all
>> for them; there may be an example somewhere in the Guidelines text, or
>> the attribute may be defined in a<classSpec>   for an attribute class,
>> and then show up in an example in an<elementSpec>   for an element which
>> belongs to that class. An example of the latter is @agent (att.damaged),
>> which has no example in the att.damaged<classSpec>, but happens to show
>> up in an example for the<damage>   element.
>>
>> Nevertheless, I think it would be a good idea to try to provide examples
>> for all these attributes, in the files which define them.
>>
>> ATTRIBUTES WHICH DO NOT SHOW UP ON ANY EXAMPLE IN THEIR elementSpec OR
>> classSpec AS OF 2012-04-19T17:19:17.315-07:00
>>
>> 1. absolute (when)
>> 2. adj (node)
>> 3. adjFrom (node)
>> 4. adjTo (node)
>> 5. age (personGrp)
>> 6. agent (att.damaged)
>> 7. agent (gap)
>> 8. agent (unclear)
>> 9. ana (att.global.analytic)
>> 10. atLeast (att.ranging)
>> 11. atMost (att.ranging)
>> 12. attachment (surface)
>> 13. autoPrefix (content)
>> 14. baseTypes (fsDecl)
>> 15. break (att.breaking)
>> 16. cRef (gloss)
>> 17. cRef (ptr)
>> 18. cRef (ref)
>> 19. cRef (term)
>> 20. cause (att.textCritical)
>> 21. cause (att.transcriptional)
>> 22. cert (att.responsibility)
>> 23. change (att.global.change)
>> 24. class (msContents)
>> 25. cols (att.tableDecoration)
>> 26. confidence (att.ranging)
>> 27. contemporary (seal)
>> 28. copyOf (att.global.linking)
>> 29. corresp (att.global.linking)
>> 30. datingMethod (att.datable.custom)
>> 31. datingPoint (att.datable.custom)
>> 32. decls (att.declaring)
>> 33. default (att.declarable)
>> 34. defective (att.msExcerpt)
>> 35. degree (att.damaged)
>> 36. degree (node)
>> 37. dim (space)
>> 38. direct (said)
>> 39. docLang (schemaSpec)
>> 40. domains (att.pointing.group)
>> 41. dur (att.duration.w3c)
>> 42. dur-iso (att.duration.iso)
>> 43. encoding (binaryObject)
>> 44. end (att.timed)
>> 45. enjamb (att.enjamb)
>> 46. evaluate (att.pointing)
>> 47. evidence (att.editLike)
>> 48. except (moduleRef)
>> 49. exclude (att.global.linking)
>> 50. expand (att.lexicographic)
>> 51. extent (orth)
>> 52. fVal (f)
>> 53. facs (att.global.facs)
>> 54. feats (fs)
>> 55. filter (equiv)
>> 56. flipping (surface)
>> 57. follow (leaf)
>> 58. force (pc)
>> 59. from (app)
>> 60. from (att.datable.w3c)
>> 61. from-custom (att.datable.custom)
>> 62. from-iso (att.datable.iso)
>> 63. full (att.personal)
>> 64. function (att.segLike)
>> 65. generate (classSpec)
>> 66. gradual (writing)
>> 67. group (att.damaged)
>> 68. hand (att.damaged)
>> 69. hand (att.textCritical)
>> 70. hand (att.transcriptional)
>> 71. hand (gap)
>> 72. hand (unclear)
>> 73. height (binaryObject)
>> 74. height (graphic)
>> 75. ident (att.identified)
>> 76. inst (att.interpLike)
>> 77. instant (att.editLike)
>> 78. key (att.canonical)
>> 79. key (classRef)
>> 80. key (macroRef)
>> 81. level (sense)
>> 82. level (title)
>> 83. loc (app)
>> 84. location (att.lexicographic)
>> 85. lrx (att.coordinated)
>> 86. lry (att.coordinated)
>> 87. match (att.scoping)
>> 88. material (supportDesc)
>> 89. max (att.ranging)
>> 90. max (memberOf)
>> 91. medium (att.handFeatures)
>> 92. mergedIn (att.lexicographic)
>> 93. met (att.metrical)
>> 94. method (correction)
>> 95. mimeType (att.internetMedia)
>> 96. min (att.ranging)
>> 97. min (memberOf)
>> 98. mode (att.combinable)
>> 99. mode (classes)
>> 100. mode (memberOf)
>> 101. module (att.identified)
>> 102. new (handShift)
>> 103. next (att.global.linking)
>> 104. notAfter-custom (att.datable.custom)
>> 105. notAfter-iso (att.datable.iso)
>> 106. notBefore-custom (att.datable.custom)
>> 107. notBefore-iso (att.datable.iso)
>> 108. notation (pron)
>> 109. ns (attDef)
>> 110. ns (elementSpec)
>> 111. ns (schemaSpec)
>> 112. nymRef (att.naming)
>> 113. opt (att.lexicographic)
>> 114. optional (fDecl)
>> 115. ord (iNode)
>> 116. ord (root)
>> 117. org (att.divLike)
>> 118. org (attList)
>> 119. orig (att.lexicographic)
>> 120. part (ab)
>> 121. part (att.divLike)
>> 122. part (att.segLike)
>> 123. parts (nym)
>> 124. perf (tech)
>> 125. period (att.datable)
>> 126. pre (pc)
>> 127. precision (att.dimensions)
>> 128. predeclare (att.identified)
>> 129. prefix (elementSpec)
>> 130. prefix (moduleRef)
>> 131. prev (att.global.linking)
>> 132. quantity (att.dimensions)
>> 133. real (att.metrical)
>> 134. ref (att.canonical)
>> 135. refLang (att.pointing)
>> 136. resp (att.responsibility)
>> 137. resp (space)
>> 138. rhyme (att.metrical)
>> 139. role (att.naming)
>> 140. role (att.tableDecoration)
>> 141. role (org)
>> 142. rotate (zone)
>> 143. rows (att.tableDecoration)
>> 144. sameAs (att.global.linking)
>> 145. sample (att.divLike)
>> 146. scale (binaryObject)
>> 147. scale (graphic)
>> 148. scheme (catRef)
>> 149. scheme (locus)
>> 150. scheme (locusGrp)
>> 151. scheme (tag)
>> 152. scope (att.dimensions)
>> 153. scope (att.handFeatures)
>> 154. scribe (att.handFeatures)
>> 155. scribeRef (att.handFeatures)
>> 156. script (att.handFeatures)
>> 157. scriptRef (att.handFeatures)
>> 158. select (att.global.linking)
>> 159. seq (att.transcriptional)
>> 160. social (distinct)
>> 161. sort (att.personal)
>> 162. source (att.editLike)
>> 163. source (att.readFrom)
>> 164. source (writing)
>> 165. space (distinct)
>> 166. spanTo (att.spanning)
>> 167. split (att.lexicographic)
>> 168. start (att.coordinated)
>> 169. start (att.timed)
>> 170. status (att.identified)
>> 171. status (att.transcriptional)
>> 172. status (correction)
>> 173. stdDeviation (precision)
>> 174. subtype (att.typed)
>> 175. synch (att.global.linking)
>> 176. targFunc (att.pointing.group)
>> 177. target (change)
>> 178. target (relatedItem)
>> 179. targetEnd (note)
>> 180. targetLang (schemaSpec)
>> 181. targets (alt)
>> 182. targets (join)
>> 183. targets (link)
>> 184. time (distinct)
>> 185. to (app)
>> 186. to (att.datable.w3c)
>> 187. to-custom (att.datable.custom)
>> 188. to-iso (att.datable.iso)
>> 189. type (abbr)
>> 190. type (att.entryLike)
>> 191. type (att.interpLike)
>> 192. type (att.textCritical)
>> 193. type (att.typed)
>> 194. type (form)
>> 195. type (q)
>> 196. type (sound)
>> 197. ulx (att.coordinated)
>> 198. uly (att.coordinated)
>> 199. unit (att.dimensions)
>> 200. unit (pc)
>> 201. unit (when)
>> 202. url (moduleRef)
>> 203. value (att.lexicographic)
>> 204. value (eTree)
>> 205. value (iNode)
>> 206. value (leaf)
>> 207. value (node)
>> 208. value (root)
>> 209. value (triangle)
>> 210. varSeq (att.textCritical)
>> 211. version (unicodeName)
>> 212. versionDate (att.translatable)
>> 213. when (docDate)
>> 214. where (event)
>> 215. who (att.ascribed)
>> 216. width (binaryObject)
>> 217. width (graphic)
>> 218. wit (att.rdgPart)
>> 219. wit (att.witnessed)
>> 220. xml:base (att.global)
>> 221. xml:id (att.global)
>> 222. xml:lang (att.global)
>> 223. xml:space (att.global)
>>
>> Cheers,
>> Martin
>>
>> On 12-04-19 03:18 PM, Martin Holmes wrote:
>>> Following on from our discussion of examples for attributes, a
>>> quick-and-dirty XSLT seems to show that there are only 19 attributes
>>> with their own examples, and 450 without. This is not to say that those
>>> without are unexemplified, because the example code for their parent
>>> elements in the elementSpec may show examples of them; I'll refine the
>>> XSLT and make that apparent.
>>>
>>> Here's the list:
>>>
>>> ATTRIBUTE DEFINITIONS LACKING EXAMPLES AS OF 2012-04-19T15:12:34.968-07:00
>>>
>>> 1. status (att.identified)
>>> 2. type (interaction)
>>> 3. value (sex)
>>> 4. scale (graphic)
>>> 5. scale (binaryObject)
>>> 6. weights (alt)
>>> 7. hand (att.damaged)
>>> 8. agent (gap)
>>> 9. predeclare (att.identified)
>>> 10. degree (att.damaged)
>>> 11. module (att.identified)
>>> 12. ident (att.identified)
>>> 13. height (graphic)
>>> 14. height (binaryObject)
>>> 15. width (graphic)
>>> 16. width (binaryObject)
>>> 17. encoding (binaryObject)
>>> 18. version (teiCorpus)
>>> 19. hand (unclear)
>>> 20. agent (unclear)
>>> 21. feature (shift)
>>> 22. type (preparedness)
>>> 23. type (abbr)
>>> 24. commodity (att.measurement)
>>> 25. agent (att.damaged)
>>> 26. type (derivation)
>>> 27. type (domain)
>>> 28. type (factuality)
>>> 29. type (idno)
>>> 30. type (relation)
>>> 31. type (sound)
>>> 32. type (tech)
>>> 33. type (castItem)
>>> 34. type (att.typed)
>>> 35. type (move)
>>> 36. script (att.handFeatures)
>>> 37. class (msItemStruct)
>>> 38. class (msItem)
>>> 39. class (msContents)
>>> 40. type (form)
>>> 41. cause (att.textCritical)
>>> 42. type (gram)
>>> 43. type (lbl)
>>> 44. type (att.textCritical)
>>> 45. type (title)
>>> 46. type (titlePage)
>>> 47. type (usg)
>>> 48. type (app)
>>> 49. columns (layout)
>>> 50. valueDatcat (att.datcat)
>>> 51. datcat (att.datcat)
>>> 52. contemporary (seal)
>>> 53. contemporary (binding)
>>> 54. from (locus)
>>> 55. type (list)
>>> 56. result (joinGrp)
>>> 57. medium (att.handFeatures)
>>> 58. type (graph)
>>> 59. type (witDetail)
>>> 60. origin (timeline)
>>> 61. function (att.segLike)
>>> 62. form (objectDesc)
>>> 63. mergedIn (att.lexicographic)
>>> 64. type (fsDecl)
>>> 65. scribe (att.handFeatures)
>>> 66. degree (node)
>>> 67. extent (orth)
>>> 68. from (arc)
>>> 69. to (arc)
>>> 70. inDegree (node)
>>> 71. arity (tree)
>>> 72. baseTypes (fsDecl)
>>> 73. level (sense)
>>> 74. order (tree)
>>> 75. outDegree (iNode)
>>> 76. outDegree (node)
>>> 77. outDegree (root)
>>> 78. reason (gap)
>>> 79. type (orth)
>>> 80. when (docDate)
>>> 81. split (att.lexicographic)
>>> 82. code (socecStatus)
>>> 83. code (occupation)
>>> 84. decls (att.declaring)
>>> 85. cRef (term)
>>> 86. from (app)
>>> 87. scheme (catRef)
>>> 88. scheme (occupation)
>>> 89. scheme (classCode)
>>> 90. scheme (socecStatus)
>>> 91. scheme (keywords)
>>> 92. to (app)
>>> 93. baseForm (m)
>>> 94. new (handShift)
>>> 95. passive (relation)
>>> 96. since (when)
>>> 97. type (fsdLink)
>>> 98. type (biblScope)
>>> 99. type (listForest)
>>> 100. type (forest)
>>> 101. hand (gap)
>>> 102. given (certainty)
>>> 103. locus (certainty)
>>> 104. type (rs)
>>> 105. source (normalization)
>>> 106. level (title)
>>> 107. degree (certainty)
>>> 108. status (correction)
>>> 109. degree (precision)
>>> 110. spanTo (att.spanning)
>>> 111. to (att.datable.w3c)
>>> 112. to-iso (att.datable.iso)
>>> 113. force (pc)
>>> 114. reason (surplus)
>>> 115. type (stage)
>>> 116. type (oRef)
>>> 117. type (oVar)
>>> 118. method (correction)
>>> 119. method (normalization)
>>> 120. name (fDecl)
>>> 121. evidence (att.editLike)
>>> 122. rows (table)
>>> 123. org (vMerge)
>>> 124. who (att.ascribed)
>>> 125. locus (respons)
>>> 126. from-custom (att.datable.custom)
>>> 127. from (att.datable.w3c)
>>> 128. from-iso (att.datable.iso)
>>> 129. type (xr)
>>> 130. type (iType)
>>> 131. type (num)
>>> 132. type (att.entryLike)
>>> 133. type (att.interpLike)
>>> 134. unit (refState)
>>> 135. notation (pron)
>>> 136. break (att.breaking)
>>> 137. iterated (kinesic)
>>> 138. iterated (vocal)
>>> 139. optional (fDecl)
>>> 140. default (att.declarable)
>>> 141. location (variantEncoding)
>>> 142. anchored (note)
>>> 143. full (att.personal)
>>> 144. type (metDecl)
>>> 145. extent (pron)
>>> 146. discrete (sound)
>>> 147. scope (join)
>>> 148. gradual (writing)
>>> 149. sample (att.divLike)
>>> 150. type (classSpec)
>>> 151. pre (pc)
>>> 152. type (dimensions)
>>> 153. method (variantEncoding)
>>> 154. type (macroSpec)
>>> 155. reason (supplied)
>>> 156. to (locus)
>>> 157. rows (att.tableDecoration)
>>> 158. writtenLines (layout)
>>> 159. ruledLines (layout)
>>> 160. location (att.lexicographic)
>>> 161. hands (handDesc)
>>> 162. material (supportDesc)
>>> 163. notation (formula)
>>> 164. unit (att.dimensions)
>>> 165. ns (attDef)
>>> 166. ns (elementSpec)
>>> 167. domains (att.pointing.group)
>>> 168. part (att.segLike)
>>> 169. source (writing)
>>> 170. ref (g)
>>> 171. scribeRef (att.handFeatures)
>>> 172. scriptRef (att.handFeatures)
>>> 173. copyOf (att.global.linking)
>>> 174. sameAs (att.global.linking)
>>> 175. exclude (att.global.linking)
>>> 176. targetEnd (note)
>>> 177. next (att.global.linking)
>>> 178. target (relatedItem)
>>> 179. unit (milestone)
>>> 180. label (rhyme)
>>> 181. lemma (w)
>>> 182. children (iNode)
>>> 183. children (root)
>>> 184. name (f)
>>> 185. unit (pc)
>>> 186. value (leaf)
>>> 187. type (node)
>>> 188. key (att.canonical)
>>> 189. follow (iNode)
>>> 190. follow (leaf)
>>> 191. parent (leaf)
>>> 192. parent (iNode)
>>> 193. value (node)
>>> 194. value (triangle)
>>> 195. value (eLeaf)
>>> 196. value (eTree)
>>> 197. value (iNode)
>>> 198. value (root)
>>> 199. quantity (att.measurement)
>>> 200. role (att.tableDecoration)
>>> 201. scheme (att)
>>> 202. select (att.global.linking)
>>> 203. xml:space (att.global)
>>> 204. hand (att.textCritical)
>>> 205. subtype (att.typed)
>>> 206. prefix (schemaSpec)
>>> 207. prefix (elementSpec)
>>> 208. type (purpose)
>>> 209. role (org)
>>> 210. role (person)
>>> 211. matchPattern (cRefPattern)
>>> 212. replacementPattern (cRefPattern)
>>> 213. age (person)
>>> 214. start (schemaSpec)
>>> 215. form (quotation)
>>> 216. time (distinct)
>>> 217. social (distinct)
>>> 218. space (distinct)
>>> 219. type (constitution)
>>> 220. scope (att.handFeatures)
>>> 221. age (personGrp)
>>> 222. usage (language)
>>> 223. ident (valItem)
>>> 224. from (span)
>>> 225. value (metSym)
>>> 226. versionDate (att.translatable)
>>> 227. target (att.pointing)
>>> 228. where (move)
>>> 229. notBefore (att.datable.w3c)
>>> 230. notBefore-custom (att.datable.custom)
>>> 231. notBefore-iso (att.datable.iso)
>>> 232. mode (classes)
>>> 233. mode (att.combinable)
>>> 234. mode (memberOf)
>>> 235. to (span)
>>> 236. to (biblScope)
>>> 237. type (valList)
>>> 238. degree (purpose)
>>> 239. length (refState)
>>> 240. render (tagUsage)
>>> 241. targets (alt)
>>> 242. targets (join)
>>> 243. targets (link)
>>> 244. type (teiHeader)
>>> 245. notAfter (att.datable.w3c)
>>> 246. notAfter-custom (att.datable.custom)
>>> 247. notAfter-iso (att.datable.iso)
>>> 248. version (TEI)
>>> 249. mode (channel)
>>> 250. result (join)
>>> 251. new (shift)
>>> 252. active (interaction)
>>> 253. occurs (tagUsage)
>>> 254. passive (interaction)
>>> 255. interval (when)
>>> 256. interval (timeline)
>>> 257. usage (attDef)
>>> 258. role (personGrp)
>>> 259. type (titlePart)
>>> 260. sex (personGrp)
>>> 261. sex (person)
>>> 262. size (personGrp)
>>> 263. from (biblScope)
>>> 264. type (distinct)
>>> 265. type (measure)
>>> 266. type (fs)
>>> 267. unit (timeline)
>>> 268. unit (when)
>>> 269. version (unicodeName)
>>> 270. type (divGen)
>>> 271. part (ab)
>>> 272. part (att.divLike)
>>> 273. part (l)
>>> 274. terminal (metSym)
>>> 275. trunc (numeric)
>>> 276. order (graph)
>>> 277. size (graph)
>>> 278. mode (alt)
>>> 279. mode (altGrp)
>>> 280. value (binary)
>>> 281. status (availability)
>>> 282. datum (geoDecl)
>>> 283. value (numeric)
>>> 284. name (relation)
>>> 285. name (vLabel)
>>> 286. indexName (index)
>>> 287. stdDeviation (precision)
>>> 288. absolute (when)
>>> 289. max (numeric)
>>> 290. scheme (constraintSpec)
>>> 291. scheme (tag)
>>> 292. scheme (gi)
>>> 293. value (symbol)
>>> 294. value (num)
>>> 295. scheme (locusGrp)
>>> 296. scheme (locus)
>>> 297. name (namespace)
>>> 298. type (recording)
>>> 299. unit (att.measurement)
>>> 300. value (att.lexicographic)
>>> 301. scope (att.dimensions)
>>> 302. evaluate (att.pointing)
>>> 303. active (relation)
>>> 304. to-custom (att.datable.custom)
>>> 305. mutual (relation)
>>> 306. dur-iso (att.duration.iso)
>>> 307. instant (att.editLike)
>>> 308. function (metamark)
>>> 309. attachment (surface)
>>> 310. cause (att.transcriptional)
>>> 311. target (metamark)
>>> 312. rotate (zone)
>>> 313. target (redo)
>>> 314. target (undo)
>>> 315. except (moduleRef)
>>> 316. include (moduleRef)
>>> 317. datingMethod (att.datable.custom)
>>> 318. datingPoint (att.datable.custom)
>>> 319. key (moduleRef)
>>> 320. url (moduleRef)
>>> 321. mimeType (att.internetMedia)
>>> 322. version (application)
>>> 323. ident (application)
>>> 324. confidence (att.ranging)
>>> 325. level (langKnown)
>>> 326. adj (node)
>>> 327. adjFrom (node)
>>> 328. adjTo (node)
>>> 329. ana (att.global.analytic)
>>> 330. group (att.damaged)
>>> 331. cRef (gloss)
>>> 332. cRef (ptr)
>>> 333. cRef (ref)
>>> 334. cert (att.responsibility)
>>> 335. cert (certainty)
>>> 336. precision (precision)
>>> 337. precision (att.dimensions)
>>> 338. type (fw)
>>> 339. cols (table)
>>> 340. cols (att.tableDecoration)
>>> 341. source (att.editLike)
>>> 342. autoPrefix (content)
>>> 343. corresp (att.global.linking)
>>> 344. delim (refState)
>>> 345. dim (space)
>>> 346. docLang (schemaSpec)
>>> 347. dur (att.duration.w3c)
>>> 348. ed (att.sourced)
>>> 349. gi (tagUsage)
>>> 350. eol (hyphenation)
>>> 351. enjamb (att.enjamb)
>>> 352. facs (att.global.facs)
>>> 353. fVal (f)
>>> 354. feats (fs)
>>> 355. lang (code)
>>> 356. atMost (att.ranging)
>>> 357. atLeast (att.ranging)
>>> 358. lrx (att.coordinated)
>>> 359. ulx (att.coordinated)
>>> 360. lry (att.coordinated)
>>> 361. uly (att.coordinated)
>>> 362. xml:id (att.global)
>>> 363. ident (language)
>>> 364. scheme (rendition)
>>> 365. status (att.transcriptional)
>>> 366. where (event)
>>> 367. start (att.timed)
>>> 368. end (att.timed)
>>> 369. type (tag)
>>> 370. defective (att.msExcerpt)
>>> 371. generate (classSpec)
>>> 372. inst (att.interpLike)
>>> 373. xml:lang (att.global)
>>> 374. loc (app)
>>> 375. mainLang (textLang)
>>> 376. maxOccurs (datatype)
>>> 377. type (q)
>>> 378. direct (said)
>>> 379. aloud (said)
>>> 380. met (att.metrical)
>>> 381. real (att.metrical)
>>> 382. minOccurs (datatype)
>>> 383. name (equiv)
>>> 384. ns (schemaSpec)
>>> 385. n (att.global)
>>> 386. opt (att.lexicographic)
>>> 387. ord (iNode)
>>> 388. ord (root)
>>> 389. ord (tree)
>>> 390. sort (att.personal)
>>> 391. org (attList)
>>> 392. org (vColl)
>>> 393. org (att.divLike)
>>> 394. orig (att.lexicographic)
>>> 395. otherLangs (textLang)
>>> 396. perf (move)
>>> 397. perf (tech)
>>> 398. target (specGrpRef)
>>> 399. parts (nym)
>>> 400. change (att.global.change)
>>> 401. target (change)
>>> 402. prev (att.global.linking)
>>> 403. lemmaRef (w)
>>> 404. marks (quotation)
>>> 405. ref (att.canonical)
>>> 406. nymRef (att.naming)
>>> 407. filter (equiv)
>>> 408. pattern (metDecl)
>>> 409. resp (respons)
>>> 410. resp (att.responsibility)
>>> 411. resp (space)
>>> 412. rhyme (att.metrical)
>>> 413. seq (att.transcriptional)
>>> 414. hand (att.transcriptional)
>>> 415. prefix (moduleRef)
>>> 416. key (memberOf)
>>> 417. quantity (att.dimensions)
>>> 418. value (age)
>>> 419. target (fsdLink)
>>> 420. period (att.datable)
>>> 421. tag (langKnown)
>>> 422. tags (langKnowledge)
>>> 423. max (memberOf)
>>> 424. min (memberOf)
>>> 425. synch (att.global.linking)
>>> 426. targFunc (att.pointing.group)
>>> 427. targetLang (schemaSpec)
>>> 428. key (classRef)
>>> 429. key (elementRef)
>>> 430. key (macroRef)
>>> 431. name (attRef)
>>> 432. trans (u)
>>> 433. uri (equiv)
>>> 434. url (graphic)
>>> 435. varSeq (att.textCritical)
>>> 436. scope (rendition)
>>> 437. max (att.ranging)
>>> 438. min (att.ranging)
>>> 439. withId (tagUsage)
>>> 440. wit (att.witnessed)
>>> 441. wit (att.rdgPart)
>>> 442. wit (witDetail)
>>> 443. status (att.docStatus)
>>> 444. points (zone)
>>> 445. start (att.coordinated)
>>> 446. valid (egXML)
>>> 447. ordered (listChange)
>>> 448. role (att.naming)
>>> 449. source (att.readFrom)
>>> 450. flipping (surface)
>>>
>>>
>>> ATTRIBUTE DEFINITIONS WHICH HAVE EXAMPLES AS OF
>>> 2012-04-19T15:12:34.968-07:00
>>>
>>> 1. place (att.placement)
>>> 2. expand (att.lexicographic)
>>> 3. extent (att.dimensions)
>>> 4. calendar (att.datable)
>>> 5. reason (unclear)
>>> 6. target (att.scoping)
>>> 7. xml:base (att.global)
>>> 8. assertedValue (certainty)
>>> 9. refLang (att.pointing)
>>> 10. match (att.scoping)
>>> 11. sortKey (att.sortable)
>>> 12. atts (specDesc)
>>> 13. key (specDesc)
>>> 14. norm (att.lexicographic)
>>> 15. rendition (att.global)
>>> 16. rend (att.global)
>>> 17. when-iso (att.datable.iso)
>>> 18. when-custom (att.datable.custom)
>>> 19. when (att.datable.w3c)
>>>
>>> --
>>> Martin Holmes
>>> University of Victoria Humanities Computing and Media Centre
>>> (mholmes at uvic.ca)
>>> --
>>> tei-council mailing list
>>> tei-council at lists.village.Virginia.EDU
>>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>>>
>>> PLEASE NOTE: postings to this list are publicly archived
>>> .
>>>
>>
> .
>

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From James.Cummings at oucs.ox.ac.uk  Mon Apr 23 11:47:44 2012
From: James.Cummings at oucs.ox.ac.uk (James Cummings)
Date: Mon, 23 Apr 2012 16:47:44 +0100
Subject: [tei-council] next release?
In-Reply-To: <4F92F34D.2040103@uvic.ca>
References: <0F18A249-5480-42D9-BFF2-538AC7B9E1EB@oucs.ox.ac.uk>
	<4F92F34D.2040103@uvic.ca>
Message-ID: <4F9579A0.8010002@oucs.ox.ac.uk>


How about we set a notional target release date of 25 May?  (This 
is about 5 weeks from now.) If we assume that we want most things 
completed by the end of Sunday 20th, to allow time for 
proofreading and error spotting.

Does that sounds reasonable to most people?

Gaby: Most importantly, does the proposed Release Technician like 
these dates?

-James


On 21/04/12 18:50, Martin Holmes wrote:
> Three weeks will be a bit tough for me, and a couple of the tickets I
> have might turn out to have unpredicted side-effects (like the tei_
> prefix). As long as we have the option to launch without the change if
> it proves difficult, we could go with three weeks.
>
> The attributes-without-examples problem is so large that we'll just have
> to hack away at it steadily.
>
> Cheers,
> Martin
>
> On 12-04-21 04:03 AM, Sebastian Rahtz wrote:
>> something we forgot to debate in Ann Arbor was a timetable
>> for the next release, I think? i.e. what is the due date for
>> everyone to complete their ticket work so that Sir Gabriel
>> of B'odard can undertake his Quest.
>>
>> speaking for myself, if I don't do my assignments
>> more or less immediately I will not get to them for ages,
>> so I favour a short window (say, 3 weeks).
>>
>> Sebastian


-- 
Dr James Cummings, InfoDev,
Computing Services, University of Oxford

From James.Cummings at oucs.ox.ac.uk  Mon Apr 23 11:57:55 2012
From: James.Cummings at oucs.ox.ac.uk (James Cummings)
Date: Mon, 23 Apr 2012 16:57:55 +0100
Subject: [tei-council] Attributes without examples
In-Reply-To: <4F9573BF.1080302@uvic.ca>
References: <4F908F22.4070908@uvic.ca>
	<4F90AD72.10605@uvic.ca>	<4F90AEBC.6000608@ultraslavonic.info>
	<4F9573BF.1080302@uvic.ca>
Message-ID: <4F957C03.8090008@oucs.ox.ac.uk>


Martin,

It is simple but intentionally not documented. Interrupt the spam 
word with an element. Specifically use <nowiki/> so 
att.ms<nowiki/>Excerpt will allow you to get around the spam filter.

Just don't advertise via<nowiki/>gra too much.

-James

On 23/04/12 16:22, Martin Holmes wrote:
> I've just tried to create a wiki page which has a table listing all
> these attributes, but I've been prevented from doing so by the sad
> little spam filter, which won't allow this:
>
> att.msExcerpt
>
> because it contains "sEx".
>
> I seem to remember having spent a frustrating time fighting with this
> stupidity some time ago. Does anyone remember how to get around this, or
> is it pointless to try?
>
> Cheers,
> Martin
>
> On 12-04-19 05:33 PM, Kevin Hawkins wrote:
>> Would you be able to output as a table with a third column for people to
>> sign up, either in MediaWiki or HTML syntax, for a page in the wiki?
>>
>> On 4/19/12 8:27 PM, Martin Holmes wrote:
>>> Below is another slightly shorter list. These are attributes which do
>>> not appear on any examples in the<elementSpec>    or<classSpec>    in which
>>> they're defined. Not that this doesn't mean there are no examples at all
>>> for them; there may be an example somewhere in the Guidelines text, or
>>> the attribute may be defined in a<classSpec>    for an attribute class,
>>> and then show up in an example in an<elementSpec>    for an element which
>>> belongs to that class. An example of the latter is @agent (att.damaged),
>>> which has no example in the att.damaged<classSpec>, but happens to show
>>> up in an example for the<damage>    element.
>>>
>>> Nevertheless, I think it would be a good idea to try to provide examples
>>> for all these attributes, in the files which define them.
>>>
>>> ATTRIBUTES WHICH DO NOT SHOW UP ON ANY EXAMPLE IN THEIR elementSpec OR
>>> classSpec AS OF 2012-04-19T17:19:17.315-07:00
>>>
>>> 1. absolute (when)
>>> 2. adj (node)
>>> 3. adjFrom (node)
>>> 4. adjTo (node)
>>> 5. age (personGrp)
>>> 6. agent (att.damaged)
>>> 7. agent (gap)
>>> 8. agent (unclear)
>>> 9. ana (att.global.analytic)
>>> 10. atLeast (att.ranging)
>>> 11. atMost (att.ranging)
>>> 12. attachment (surface)
>>> 13. autoPrefix (content)
>>> 14. baseTypes (fsDecl)
>>> 15. break (att.breaking)
>>> 16. cRef (gloss)
>>> 17. cRef (ptr)
>>> 18. cRef (ref)
>>> 19. cRef (term)
>>> 20. cause (att.textCritical)
>>> 21. cause (att.transcriptional)
>>> 22. cert (att.responsibility)
>>> 23. change (att.global.change)
>>> 24. class (msContents)
>>> 25. cols (att.tableDecoration)
>>> 26. confidence (att.ranging)
>>> 27. contemporary (seal)
>>> 28. copyOf (att.global.linking)
>>> 29. corresp (att.global.linking)
>>> 30. datingMethod (att.datable.custom)
>>> 31. datingPoint (att.datable.custom)
>>> 32. decls (att.declaring)
>>> 33. default (att.declarable)
>>> 34. defective (att.msExcerpt)
>>> 35. degree (att.damaged)
>>> 36. degree (node)
>>> 37. dim (space)
>>> 38. direct (said)
>>> 39. docLang (schemaSpec)
>>> 40. domains (att.pointing.group)
>>> 41. dur (att.duration.w3c)
>>> 42. dur-iso (att.duration.iso)
>>> 43. encoding (binaryObject)
>>> 44. end (att.timed)
>>> 45. enjamb (att.enjamb)
>>> 46. evaluate (att.pointing)
>>> 47. evidence (att.editLike)
>>> 48. except (moduleRef)
>>> 49. exclude (att.global.linking)
>>> 50. expand (att.lexicographic)
>>> 51. extent (orth)
>>> 52. fVal (f)
>>> 53. facs (att.global.facs)
>>> 54. feats (fs)
>>> 55. filter (equiv)
>>> 56. flipping (surface)
>>> 57. follow (leaf)
>>> 58. force (pc)
>>> 59. from (app)
>>> 60. from (att.datable.w3c)
>>> 61. from-custom (att.datable.custom)
>>> 62. from-iso (att.datable.iso)
>>> 63. full (att.personal)
>>> 64. function (att.segLike)
>>> 65. generate (classSpec)
>>> 66. gradual (writing)
>>> 67. group (att.damaged)
>>> 68. hand (att.damaged)
>>> 69. hand (att.textCritical)
>>> 70. hand (att.transcriptional)
>>> 71. hand (gap)
>>> 72. hand (unclear)
>>> 73. height (binaryObject)
>>> 74. height (graphic)
>>> 75. ident (att.identified)
>>> 76. inst (att.interpLike)
>>> 77. instant (att.editLike)
>>> 78. key (att.canonical)
>>> 79. key (classRef)
>>> 80. key (macroRef)
>>> 81. level (sense)
>>> 82. level (title)
>>> 83. loc (app)
>>> 84. location (att.lexicographic)
>>> 85. lrx (att.coordinated)
>>> 86. lry (att.coordinated)
>>> 87. match (att.scoping)
>>> 88. material (supportDesc)
>>> 89. max (att.ranging)
>>> 90. max (memberOf)
>>> 91. medium (att.handFeatures)
>>> 92. mergedIn (att.lexicographic)
>>> 93. met (att.metrical)
>>> 94. method (correction)
>>> 95. mimeType (att.internetMedia)
>>> 96. min (att.ranging)
>>> 97. min (memberOf)
>>> 98. mode (att.combinable)
>>> 99. mode (classes)
>>> 100. mode (memberOf)
>>> 101. module (att.identified)
>>> 102. new (handShift)
>>> 103. next (att.global.linking)
>>> 104. notAfter-custom (att.datable.custom)
>>> 105. notAfter-iso (att.datable.iso)
>>> 106. notBefore-custom (att.datable.custom)
>>> 107. notBefore-iso (att.datable.iso)
>>> 108. notation (pron)
>>> 109. ns (attDef)
>>> 110. ns (elementSpec)
>>> 111. ns (schemaSpec)
>>> 112. nymRef (att.naming)
>>> 113. opt (att.lexicographic)
>>> 114. optional (fDecl)
>>> 115. ord (iNode)
>>> 116. ord (root)
>>> 117. org (att.divLike)
>>> 118. org (attList)
>>> 119. orig (att.lexicographic)
>>> 120. part (ab)
>>> 121. part (att.divLike)
>>> 122. part (att.segLike)
>>> 123. parts (nym)
>>> 124. perf (tech)
>>> 125. period (att.datable)
>>> 126. pre (pc)
>>> 127. precision (att.dimensions)
>>> 128. predeclare (att.identified)
>>> 129. prefix (elementSpec)
>>> 130. prefix (moduleRef)
>>> 131. prev (att.global.linking)
>>> 132. quantity (att.dimensions)
>>> 133. real (att.metrical)
>>> 134. ref (att.canonical)
>>> 135. refLang (att.pointing)
>>> 136. resp (att.responsibility)
>>> 137. resp (space)
>>> 138. rhyme (att.metrical)
>>> 139. role (att.naming)
>>> 140. role (att.tableDecoration)
>>> 141. role (org)
>>> 142. rotate (zone)
>>> 143. rows (att.tableDecoration)
>>> 144. sameAs (att.global.linking)
>>> 145. sample (att.divLike)
>>> 146. scale (binaryObject)
>>> 147. scale (graphic)
>>> 148. scheme (catRef)
>>> 149. scheme (locus)
>>> 150. scheme (locusGrp)
>>> 151. scheme (tag)
>>> 152. scope (att.dimensions)
>>> 153. scope (att.handFeatures)
>>> 154. scribe (att.handFeatures)
>>> 155. scribeRef (att.handFeatures)
>>> 156. script (att.handFeatures)
>>> 157. scriptRef (att.handFeatures)
>>> 158. select (att.global.linking)
>>> 159. seq (att.transcriptional)
>>> 160. social (distinct)
>>> 161. sort (att.personal)
>>> 162. source (att.editLike)
>>> 163. source (att.readFrom)
>>> 164. source (writing)
>>> 165. space (distinct)
>>> 166. spanTo (att.spanning)
>>> 167. split (att.lexicographic)
>>> 168. start (att.coordinated)
>>> 169. start (att.timed)
>>> 170. status (att.identified)
>>> 171. status (att.transcriptional)
>>> 172. status (correction)
>>> 173. stdDeviation (precision)
>>> 174. subtype (att.typed)
>>> 175. synch (att.global.linking)
>>> 176. targFunc (att.pointing.group)
>>> 177. target (change)
>>> 178. target (relatedItem)
>>> 179. targetEnd (note)
>>> 180. targetLang (schemaSpec)
>>> 181. targets (alt)
>>> 182. targets (join)
>>> 183. targets (link)
>>> 184. time (distinct)
>>> 185. to (app)
>>> 186. to (att.datable.w3c)
>>> 187. to-custom (att.datable.custom)
>>> 188. to-iso (att.datable.iso)
>>> 189. type (abbr)
>>> 190. type (att.entryLike)
>>> 191. type (att.interpLike)
>>> 192. type (att.textCritical)
>>> 193. type (att.typed)
>>> 194. type (form)
>>> 195. type (q)
>>> 196. type (sound)
>>> 197. ulx (att.coordinated)
>>> 198. uly (att.coordinated)
>>> 199. unit (att.dimensions)
>>> 200. unit (pc)
>>> 201. unit (when)
>>> 202. url (moduleRef)
>>> 203. value (att.lexicographic)
>>> 204. value (eTree)
>>> 205. value (iNode)
>>> 206. value (leaf)
>>> 207. value (node)
>>> 208. value (root)
>>> 209. value (triangle)
>>> 210. varSeq (att.textCritical)
>>> 211. version (unicodeName)
>>> 212. versionDate (att.translatable)
>>> 213. when (docDate)
>>> 214. where (event)
>>> 215. who (att.ascribed)
>>> 216. width (binaryObject)
>>> 217. width (graphic)
>>> 218. wit (att.rdgPart)
>>> 219. wit (att.witnessed)
>>> 220. xml:base (att.global)
>>> 221. xml:id (att.global)
>>> 222. xml:lang (att.global)
>>> 223. xml:space (att.global)
>>>
>>> Cheers,
>>> Martin
>>>
>>> On 12-04-19 03:18 PM, Martin Holmes wrote:
>>>> Following on from our discussion of examples for attributes, a
>>>> quick-and-dirty XSLT seems to show that there are only 19 attributes
>>>> with their own examples, and 450 without. This is not to say that those
>>>> without are unexemplified, because the example code for their parent
>>>> elements in the elementSpec may show examples of them; I'll refine the
>>>> XSLT and make that apparent.
>>>>
>>>> Here's the list:
>>>>
>>>> ATTRIBUTE DEFINITIONS LACKING EXAMPLES AS OF 2012-04-19T15:12:34.968-07:00
>>>>
>>>> 1. status (att.identified)
>>>> 2. type (interaction)
>>>> 3. value (sex)
>>>> 4. scale (graphic)
>>>> 5. scale (binaryObject)
>>>> 6. weights (alt)
>>>> 7. hand (att.damaged)
>>>> 8. agent (gap)
>>>> 9. predeclare (att.identified)
>>>> 10. degree (att.damaged)
>>>> 11. module (att.identified)
>>>> 12. ident (att.identified)
>>>> 13. height (graphic)
>>>> 14. height (binaryObject)
>>>> 15. width (graphic)
>>>> 16. width (binaryObject)
>>>> 17. encoding (binaryObject)
>>>> 18. version (teiCorpus)
>>>> 19. hand (unclear)
>>>> 20. agent (unclear)
>>>> 21. feature (shift)
>>>> 22. type (preparedness)
>>>> 23. type (abbr)
>>>> 24. commodity (att.measurement)
>>>> 25. agent (att.damaged)
>>>> 26. type (derivation)
>>>> 27. type (domain)
>>>> 28. type (factuality)
>>>> 29. type (idno)
>>>> 30. type (relation)
>>>> 31. type (sound)
>>>> 32. type (tech)
>>>> 33. type (castItem)
>>>> 34. type (att.typed)
>>>> 35. type (move)
>>>> 36. script (att.handFeatures)
>>>> 37. class (msItemStruct)
>>>> 38. class (msItem)
>>>> 39. class (msContents)
>>>> 40. type (form)
>>>> 41. cause (att.textCritical)
>>>> 42. type (gram)
>>>> 43. type (lbl)
>>>> 44. type (att.textCritical)
>>>> 45. type (title)
>>>> 46. type (titlePage)
>>>> 47. type (usg)
>>>> 48. type (app)
>>>> 49. columns (layout)
>>>> 50. valueDatcat (att.datcat)
>>>> 51. datcat (att.datcat)
>>>> 52. contemporary (seal)
>>>> 53. contemporary (binding)
>>>> 54. from (locus)
>>>> 55. type (list)
>>>> 56. result (joinGrp)
>>>> 57. medium (att.handFeatures)
>>>> 58. type (graph)
>>>> 59. type (witDetail)
>>>> 60. origin (timeline)
>>>> 61. function (att.segLike)
>>>> 62. form (objectDesc)
>>>> 63. mergedIn (att.lexicographic)
>>>> 64. type (fsDecl)
>>>> 65. scribe (att.handFeatures)
>>>> 66. degree (node)
>>>> 67. extent (orth)
>>>> 68. from (arc)
>>>> 69. to (arc)
>>>> 70. inDegree (node)
>>>> 71. arity (tree)
>>>> 72. baseTypes (fsDecl)
>>>> 73. level (sense)
>>>> 74. order (tree)
>>>> 75. outDegree (iNode)
>>>> 76. outDegree (node)
>>>> 77. outDegree (root)
>>>> 78. reason (gap)
>>>> 79. type (orth)
>>>> 80. when (docDate)
>>>> 81. split (att.lexicographic)
>>>> 82. code (socecStatus)
>>>> 83. code (occupation)
>>>> 84. decls (att.declaring)
>>>> 85. cRef (term)
>>>> 86. from (app)
>>>> 87. scheme (catRef)
>>>> 88. scheme (occupation)
>>>> 89. scheme (classCode)
>>>> 90. scheme (socecStatus)
>>>> 91. scheme (keywords)
>>>> 92. to (app)
>>>> 93. baseForm (m)
>>>> 94. new (handShift)
>>>> 95. passive (relation)
>>>> 96. since (when)
>>>> 97. type (fsdLink)
>>>> 98. type (biblScope)
>>>> 99. type (listForest)
>>>> 100. type (forest)
>>>> 101. hand (gap)
>>>> 102. given (certainty)
>>>> 103. locus (certainty)
>>>> 104. type (rs)
>>>> 105. source (normalization)
>>>> 106. level (title)
>>>> 107. degree (certainty)
>>>> 108. status (correction)
>>>> 109. degree (precision)
>>>> 110. spanTo (att.spanning)
>>>> 111. to (att.datable.w3c)
>>>> 112. to-iso (att.datable.iso)
>>>> 113. force (pc)
>>>> 114. reason (surplus)
>>>> 115. type (stage)
>>>> 116. type (oRef)
>>>> 117. type (oVar)
>>>> 118. method (correction)
>>>> 119. method (normalization)
>>>> 120. name (fDecl)
>>>> 121. evidence (att.editLike)
>>>> 122. rows (table)
>>>> 123. org (vMerge)
>>>> 124. who (att.ascribed)
>>>> 125. locus (respons)
>>>> 126. from-custom (att.datable.custom)
>>>> 127. from (att.datable.w3c)
>>>> 128. from-iso (att.datable.iso)
>>>> 129. type (xr)
>>>> 130. type (iType)
>>>> 131. type (num)
>>>> 132. type (att.entryLike)
>>>> 133. type (att.interpLike)
>>>> 134. unit (refState)
>>>> 135. notation (pron)
>>>> 136. break (att.breaking)
>>>> 137. iterated (kinesic)
>>>> 138. iterated (vocal)
>>>> 139. optional (fDecl)
>>>> 140. default (att.declarable)
>>>> 141. location (variantEncoding)
>>>> 142. anchored (note)
>>>> 143. full (att.personal)
>>>> 144. type (metDecl)
>>>> 145. extent (pron)
>>>> 146. discrete (sound)
>>>> 147. scope (join)
>>>> 148. gradual (writing)
>>>> 149. sample (att.divLike)
>>>> 150. type (classSpec)
>>>> 151. pre (pc)
>>>> 152. type (dimensions)
>>>> 153. method (variantEncoding)
>>>> 154. type (macroSpec)
>>>> 155. reason (supplied)
>>>> 156. to (locus)
>>>> 157. rows (att.tableDecoration)
>>>> 158. writtenLines (layout)
>>>> 159. ruledLines (layout)
>>>> 160. location (att.lexicographic)
>>>> 161. hands (handDesc)
>>>> 162. material (supportDesc)
>>>> 163. notation (formula)
>>>> 164. unit (att.dimensions)
>>>> 165. ns (attDef)
>>>> 166. ns (elementSpec)
>>>> 167. domains (att.pointing.group)
>>>> 168. part (att.segLike)
>>>> 169. source (writing)
>>>> 170. ref (g)
>>>> 171. scribeRef (att.handFeatures)
>>>> 172. scriptRef (att.handFeatures)
>>>> 173. copyOf (att.global.linking)
>>>> 174. sameAs (att.global.linking)
>>>> 175. exclude (att.global.linking)
>>>> 176. targetEnd (note)
>>>> 177. next (att.global.linking)
>>>> 178. target (relatedItem)
>>>> 179. unit (milestone)
>>>> 180. label (rhyme)
>>>> 181. lemma (w)
>>>> 182. children (iNode)
>>>> 183. children (root)
>>>> 184. name (f)
>>>> 185. unit (pc)
>>>> 186. value (leaf)
>>>> 187. type (node)
>>>> 188. key (att.canonical)
>>>> 189. follow (iNode)
>>>> 190. follow (leaf)
>>>> 191. parent (leaf)
>>>> 192. parent (iNode)
>>>> 193. value (node)
>>>> 194. value (triangle)
>>>> 195. value (eLeaf)
>>>> 196. value (eTree)
>>>> 197. value (iNode)
>>>> 198. value (root)
>>>> 199. quantity (att.measurement)
>>>> 200. role (att.tableDecoration)
>>>> 201. scheme (att)
>>>> 202. select (att.global.linking)
>>>> 203. xml:space (att.global)
>>>> 204. hand (att.textCritical)
>>>> 205. subtype (att.typed)
>>>> 206. prefix (schemaSpec)
>>>> 207. prefix (elementSpec)
>>>> 208. type (purpose)
>>>> 209. role (org)
>>>> 210. role (person)
>>>> 211. matchPattern (cRefPattern)
>>>> 212. replacementPattern (cRefPattern)
>>>> 213. age (person)
>>>> 214. start (schemaSpec)
>>>> 215. form (quotation)
>>>> 216. time (distinct)
>>>> 217. social (distinct)
>>>> 218. space (distinct)
>>>> 219. type (constitution)
>>>> 220. scope (att.handFeatures)
>>>> 221. age (personGrp)
>>>> 222. usage (language)
>>>> 223. ident (valItem)
>>>> 224. from (span)
>>>> 225. value (metSym)
>>>> 226. versionDate (att.translatable)
>>>> 227. target (att.pointing)
>>>> 228. where (move)
>>>> 229. notBefore (att.datable.w3c)
>>>> 230. notBefore-custom (att.datable.custom)
>>>> 231. notBefore-iso (att.datable.iso)
>>>> 232. mode (classes)
>>>> 233. mode (att.combinable)
>>>> 234. mode (memberOf)
>>>> 235. to (span)
>>>> 236. to (biblScope)
>>>> 237. type (valList)
>>>> 238. degree (purpose)
>>>> 239. length (refState)
>>>> 240. render (tagUsage)
>>>> 241. targets (alt)
>>>> 242. targets (join)
>>>> 243. targets (link)
>>>> 244. type (teiHeader)
>>>> 245. notAfter (att.datable.w3c)
>>>> 246. notAfter-custom (att.datable.custom)
>>>> 247. notAfter-iso (att.datable.iso)
>>>> 248. version (TEI)
>>>> 249. mode (channel)
>>>> 250. result (join)
>>>> 251. new (shift)
>>>> 252. active (interaction)
>>>> 253. occurs (tagUsage)
>>>> 254. passive (interaction)
>>>> 255. interval (when)
>>>> 256. interval (timeline)
>>>> 257. usage (attDef)
>>>> 258. role (personGrp)
>>>> 259. type (titlePart)
>>>> 260. sex (personGrp)
>>>> 261. sex (person)
>>>> 262. size (personGrp)
>>>> 263. from (biblScope)
>>>> 264. type (distinct)
>>>> 265. type (measure)
>>>> 266. type (fs)
>>>> 267. unit (timeline)
>>>> 268. unit (when)
>>>> 269. version (unicodeName)
>>>> 270. type (divGen)
>>>> 271. part (ab)
>>>> 272. part (att.divLike)
>>>> 273. part (l)
>>>> 274. terminal (metSym)
>>>> 275. trunc (numeric)
>>>> 276. order (graph)
>>>> 277. size (graph)
>>>> 278. mode (alt)
>>>> 279. mode (altGrp)
>>>> 280. value (binary)
>>>> 281. status (availability)
>>>> 282. datum (geoDecl)
>>>> 283. value (numeric)
>>>> 284. name (relation)
>>>> 285. name (vLabel)
>>>> 286. indexName (index)
>>>> 287. stdDeviation (precision)
>>>> 288. absolute (when)
>>>> 289. max (numeric)
>>>> 290. scheme (constraintSpec)
>>>> 291. scheme (tag)
>>>> 292. scheme (gi)
>>>> 293. value (symbol)
>>>> 294. value (num)
>>>> 295. scheme (locusGrp)
>>>> 296. scheme (locus)
>>>> 297. name (namespace)
>>>> 298. type (recording)
>>>> 299. unit (att.measurement)
>>>> 300. value (att.lexicographic)
>>>> 301. scope (att.dimensions)
>>>> 302. evaluate (att.pointing)
>>>> 303. active (relation)
>>>> 304. to-custom (att.datable.custom)
>>>> 305. mutual (relation)
>>>> 306. dur-iso (att.duration.iso)
>>>> 307. instant (att.editLike)
>>>> 308. function (metamark)
>>>> 309. attachment (surface)
>>>> 310. cause (att.transcriptional)
>>>> 311. target (metamark)
>>>> 312. rotate (zone)
>>>> 313. target (redo)
>>>> 314. target (undo)
>>>> 315. except (moduleRef)
>>>> 316. include (moduleRef)
>>>> 317. datingMethod (att.datable.custom)
>>>> 318. datingPoint (att.datable.custom)
>>>> 319. key (moduleRef)
>>>> 320. url (moduleRef)
>>>> 321. mimeType (att.internetMedia)
>>>> 322. version (application)
>>>> 323. ident (application)
>>>> 324. confidence (att.ranging)
>>>> 325. level (langKnown)
>>>> 326. adj (node)
>>>> 327. adjFrom (node)
>>>> 328. adjTo (node)
>>>> 329. ana (att.global.analytic)
>>>> 330. group (att.damaged)
>>>> 331. cRef (gloss)
>>>> 332. cRef (ptr)
>>>> 333. cRef (ref)
>>>> 334. cert (att.responsibility)
>>>> 335. cert (certainty)
>>>> 336. precision (precision)
>>>> 337. precision (att.dimensions)
>>>> 338. type (fw)
>>>> 339. cols (table)
>>>> 340. cols (att.tableDecoration)
>>>> 341. source (att.editLike)
>>>> 342. autoPrefix (content)
>>>> 343. corresp (att.global.linking)
>>>> 344. delim (refState)
>>>> 345. dim (space)
>>>> 346. docLang (schemaSpec)
>>>> 347. dur (att.duration.w3c)
>>>> 348. ed (att.sourced)
>>>> 349. gi (tagUsage)
>>>> 350. eol (hyphenation)
>>>> 351. enjamb (att.enjamb)
>>>> 352. facs (att.global.facs)
>>>> 353. fVal (f)
>>>> 354. feats (fs)
>>>> 355. lang (code)
>>>> 356. atMost (att.ranging)
>>>> 357. atLeast (att.ranging)
>>>> 358. lrx (att.coordinated)
>>>> 359. ulx (att.coordinated)
>>>> 360. lry (att.coordinated)
>>>> 361. uly (att.coordinated)
>>>> 362. xml:id (att.global)
>>>> 363. ident (language)
>>>> 364. scheme (rendition)
>>>> 365. status (att.transcriptional)
>>>> 366. where (event)
>>>> 367. start (att.timed)
>>>> 368. end (att.timed)
>>>> 369. type (tag)
>>>> 370. defective (att.msExcerpt)
>>>> 371. generate (classSpec)
>>>> 372. inst (att.interpLike)
>>>> 373. xml:lang (att.global)
>>>> 374. loc (app)
>>>> 375. mainLang (textLang)
>>>> 376. maxOccurs (datatype)
>>>> 377. type (q)
>>>> 378. direct (said)
>>>> 379. aloud (said)
>>>> 380. met (att.metrical)
>>>> 381. real (att.metrical)
>>>> 382. minOccurs (datatype)
>>>> 383. name (equiv)
>>>> 384. ns (schemaSpec)
>>>> 385. n (att.global)
>>>> 386. opt (att.lexicographic)
>>>> 387. ord (iNode)
>>>> 388. ord (root)
>>>> 389. ord (tree)
>>>> 390. sort (att.personal)
>>>> 391. org (attList)
>>>> 392. org (vColl)
>>>> 393. org (att.divLike)
>>>> 394. orig (att.lexicographic)
>>>> 395. otherLangs (textLang)
>>>> 396. perf (move)
>>>> 397. perf (tech)
>>>> 398. target (specGrpRef)
>>>> 399. parts (nym)
>>>> 400. change (att.global.change)
>>>> 401. target (change)
>>>> 402. prev (att.global.linking)
>>>> 403. lemmaRef (w)
>>>> 404. marks (quotation)
>>>> 405. ref (att.canonical)
>>>> 406. nymRef (att.naming)
>>>> 407. filter (equiv)
>>>> 408. pattern (metDecl)
>>>> 409. resp (respons)
>>>> 410. resp (att.responsibility)
>>>> 411. resp (space)
>>>> 412. rhyme (att.metrical)
>>>> 413. seq (att.transcriptional)
>>>> 414. hand (att.transcriptional)
>>>> 415. prefix (moduleRef)
>>>> 416. key (memberOf)
>>>> 417. quantity (att.dimensions)
>>>> 418. value (age)
>>>> 419. target (fsdLink)
>>>> 420. period (att.datable)
>>>> 421. tag (langKnown)
>>>> 422. tags (langKnowledge)
>>>> 423. max (memberOf)
>>>> 424. min (memberOf)
>>>> 425. synch (att.global.linking)
>>>> 426. targFunc (att.pointing.group)
>>>> 427. targetLang (schemaSpec)
>>>> 428. key (classRef)
>>>> 429. key (elementRef)
>>>> 430. key (macroRef)
>>>> 431. name (attRef)
>>>> 432. trans (u)
>>>> 433. uri (equiv)
>>>> 434. url (graphic)
>>>> 435. varSeq (att.textCritical)
>>>> 436. scope (rendition)
>>>> 437. max (att.ranging)
>>>> 438. min (att.ranging)
>>>> 439. withId (tagUsage)
>>>> 440. wit (att.witnessed)
>>>> 441. wit (att.rdgPart)
>>>> 442. wit (witDetail)
>>>> 443. status (att.docStatus)
>>>> 444. points (zone)
>>>> 445. start (att.coordinated)
>>>> 446. valid (egXML)
>>>> 447. ordered (listChange)
>>>> 448. role (att.naming)
>>>> 449. source (att.readFrom)
>>>> 450. flipping (surface)
>>>>
>>>>
>>>> ATTRIBUTE DEFINITIONS WHICH HAVE EXAMPLES AS OF
>>>> 2012-04-19T15:12:34.968-07:00
>>>>
>>>> 1. place (att.placement)
>>>> 2. expand (att.lexicographic)
>>>> 3. extent (att.dimensions)
>>>> 4. calendar (att.datable)
>>>> 5. reason (unclear)
>>>> 6. target (att.scoping)
>>>> 7. xml:base (att.global)
>>>> 8. assertedValue (certainty)
>>>> 9. refLang (att.pointing)
>>>> 10. match (att.scoping)
>>>> 11. sortKey (att.sortable)
>>>> 12. atts (specDesc)
>>>> 13. key (specDesc)
>>>> 14. norm (att.lexicographic)
>>>> 15. rendition (att.global)
>>>> 16. rend (att.global)
>>>> 17. when-iso (att.datable.iso)
>>>> 18. when-custom (att.datable.custom)
>>>> 19. when (att.datable.w3c)
>>>>
>>>> --
>>>> Martin Holmes
>>>> University of Victoria Humanities Computing and Media Centre
>>>> (mholmes at uvic.ca)
>>>> --
>>>> tei-council mailing list
>>>> tei-council at lists.village.Virginia.EDU
>>>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>>>>
>>>> PLEASE NOTE: postings to this list are publicly archived
>>>> .
>>>>
>>>
>> .
>>
>


-- 
Dr James Cummings, InfoDev,
Computing Services, University of Oxford

From mholmes at uvic.ca  Mon Apr 23 12:03:36 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Mon, 23 Apr 2012 09:03:36 -0700
Subject: [tei-council] Ignore my Jenkins for a while...
In-Reply-To: <4F9349B8.7030709@uvic.ca>
References: <4F9349B8.7030709@uvic.ca>
Message-ID: <4F957D58.70600@uvic.ca>

I think we're stable again on the UVic Jenkins.

Cheers,
Martin

On 12-04-21 04:58 PM, Martin Holmes wrote:
> Hi all,
>
> Just writing to warn everybody that I'm working on the configuration of
> jobs on my Jenkins box, with limited success, so builds are failing for
> reasons which probably have nothing to do with you. Sebastian says his
> Jinks is stable, and it looks to be so, so please refer to his when
> you've committed changes:
>
> <http://bits.nsms.ox.ac.uk:8080/jenkins/>
>
> rather than mine, which is two butties short of a picnic at the moment:
>
> <http://teijenkins.hcmc.uvic.ca:8080/>
>
> I'm hoping that normal service will be resumed as soon as possible. Once
> it's working again, I'll be leaving it well alone, and working on
> another VM built from Ubuntu Precise. That should ultimately replace
> this one, and be the model from which you can build your own Jenkins
> machine should you wish to.
>
> Cheers,
> Martin

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From sebastian.rahtz at oucs.ox.ac.uk  Mon Apr 23 12:06:28 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Mon, 23 Apr 2012 16:06:28 +0000
Subject: [tei-council] Ignore my Jenkins for a while...
In-Reply-To: <4F957D58.70600@uvic.ca>
References: <4F9349B8.7030709@uvic.ca> <4F957D58.70600@uvic.ca>
Message-ID: <73DE755F-BA7C-401D-A0FE-56DD1B22D86A@oucs.ox.ac.uk>


On 23 Apr 2012, at 17:03, Martin Holmes wrote:

> I think we're stable again on the UVic Jenkins.


and we're back to pure green in Oxford.

people should be aware that the Guidelines now build
against the current state of Stylesheets, so any changes
to the core stylesheets show up in Guidelines 
immediately. this is a Good Thing (according to MH
and SR)
--
Stormageddon Rahtz      
Head of Information and Support Group
Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431

S?lo le pido a Dios
que el futuro no me sea indiferente


From mholmes at uvic.ca  Mon Apr 23 12:19:02 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Mon, 23 Apr 2012 09:19:02 -0700
Subject: [tei-council] Attributes without examples
In-Reply-To: <4F957C03.8090008@oucs.ox.ac.uk>
References: <4F908F22.4070908@uvic.ca>	<4F90AD72.10605@uvic.ca>
	<4F90AEBC.6000608@ultraslavonic.info>	<4F9573BF.1080302@uvic.ca>
	<4F957C03.8090008@oucs.ox.ac.uk>
Message-ID: <4F9580F6.4080505@uvic.ca>

Thanks James -- that works. I have to write that down somewhere. I 
wonder why spambots wouldn't use <nowiki/> themselves.

Here's the page -- feel free to sign up for one or more attributes by 
editing it:

<http://wiki.tei-c.org/index.php/AttsWithoutEgs>

Cheers,
Martin

On 12-04-23 08:57 AM, James Cummings wrote:
>
> Martin,
>
> It is simple but intentionally not documented. Interrupt the spam
> word with an element. Specifically use<nowiki/>  so
> att.ms<nowiki/>Excerpt will allow you to get around the spam filter.
>
> Just don't advertise via<nowiki/>gra too much.
>
> -James
>
> On 23/04/12 16:22, Martin Holmes wrote:
>> I've just tried to create a wiki page which has a table listing all
>> these attributes, but I've been prevented from doing so by the sad
>> little spam filter, which won't allow this:
>>
>> att.msExcerpt
>>
>> because it contains "sEx".
>>
>> I seem to remember having spent a frustrating time fighting with this
>> stupidity some time ago. Does anyone remember how to get around this, or
>> is it pointless to try?
>>
>> Cheers,
>> Martin
>>
>> On 12-04-19 05:33 PM, Kevin Hawkins wrote:
>>> Would you be able to output as a table with a third column for people to
>>> sign up, either in MediaWiki or HTML syntax, for a page in the wiki?
>>>
>>> On 4/19/12 8:27 PM, Martin Holmes wrote:
>>>> Below is another slightly shorter list. These are attributes which do
>>>> not appear on any examples in the<elementSpec>     or<classSpec>     in which
>>>> they're defined. Not that this doesn't mean there are no examples at all
>>>> for them; there may be an example somewhere in the Guidelines text, or
>>>> the attribute may be defined in a<classSpec>     for an attribute class,
>>>> and then show up in an example in an<elementSpec>     for an element which
>>>> belongs to that class. An example of the latter is @agent (att.damaged),
>>>> which has no example in the att.damaged<classSpec>, but happens to show
>>>> up in an example for the<damage>     element.
>>>>
>>>> Nevertheless, I think it would be a good idea to try to provide examples
>>>> for all these attributes, in the files which define them.
>>>>
>>>> ATTRIBUTES WHICH DO NOT SHOW UP ON ANY EXAMPLE IN THEIR elementSpec OR
>>>> classSpec AS OF 2012-04-19T17:19:17.315-07:00
>>>>
>>>> 1. absolute (when)
>>>> 2. adj (node)
>>>> 3. adjFrom (node)
>>>> 4. adjTo (node)
>>>> 5. age (personGrp)
>>>> 6. agent (att.damaged)
>>>> 7. agent (gap)
>>>> 8. agent (unclear)
>>>> 9. ana (att.global.analytic)
>>>> 10. atLeast (att.ranging)
>>>> 11. atMost (att.ranging)
>>>> 12. attachment (surface)
>>>> 13. autoPrefix (content)
>>>> 14. baseTypes (fsDecl)
>>>> 15. break (att.breaking)
>>>> 16. cRef (gloss)
>>>> 17. cRef (ptr)
>>>> 18. cRef (ref)
>>>> 19. cRef (term)
>>>> 20. cause (att.textCritical)
>>>> 21. cause (att.transcriptional)
>>>> 22. cert (att.responsibility)
>>>> 23. change (att.global.change)
>>>> 24. class (msContents)
>>>> 25. cols (att.tableDecoration)
>>>> 26. confidence (att.ranging)
>>>> 27. contemporary (seal)
>>>> 28. copyOf (att.global.linking)
>>>> 29. corresp (att.global.linking)
>>>> 30. datingMethod (att.datable.custom)
>>>> 31. datingPoint (att.datable.custom)
>>>> 32. decls (att.declaring)
>>>> 33. default (att.declarable)
>>>> 34. defective (att.msExcerpt)
>>>> 35. degree (att.damaged)
>>>> 36. degree (node)
>>>> 37. dim (space)
>>>> 38. direct (said)
>>>> 39. docLang (schemaSpec)
>>>> 40. domains (att.pointing.group)
>>>> 41. dur (att.duration.w3c)
>>>> 42. dur-iso (att.duration.iso)
>>>> 43. encoding (binaryObject)
>>>> 44. end (att.timed)
>>>> 45. enjamb (att.enjamb)
>>>> 46. evaluate (att.pointing)
>>>> 47. evidence (att.editLike)
>>>> 48. except (moduleRef)
>>>> 49. exclude (att.global.linking)
>>>> 50. expand (att.lexicographic)
>>>> 51. extent (orth)
>>>> 52. fVal (f)
>>>> 53. facs (att.global.facs)
>>>> 54. feats (fs)
>>>> 55. filter (equiv)
>>>> 56. flipping (surface)
>>>> 57. follow (leaf)
>>>> 58. force (pc)
>>>> 59. from (app)
>>>> 60. from (att.datable.w3c)
>>>> 61. from-custom (att.datable.custom)
>>>> 62. from-iso (att.datable.iso)
>>>> 63. full (att.personal)
>>>> 64. function (att.segLike)
>>>> 65. generate (classSpec)
>>>> 66. gradual (writing)
>>>> 67. group (att.damaged)
>>>> 68. hand (att.damaged)
>>>> 69. hand (att.textCritical)
>>>> 70. hand (att.transcriptional)
>>>> 71. hand (gap)
>>>> 72. hand (unclear)
>>>> 73. height (binaryObject)
>>>> 74. height (graphic)
>>>> 75. ident (att.identified)
>>>> 76. inst (att.interpLike)
>>>> 77. instant (att.editLike)
>>>> 78. key (att.canonical)
>>>> 79. key (classRef)
>>>> 80. key (macroRef)
>>>> 81. level (sense)
>>>> 82. level (title)
>>>> 83. loc (app)
>>>> 84. location (att.lexicographic)
>>>> 85. lrx (att.coordinated)
>>>> 86. lry (att.coordinated)
>>>> 87. match (att.scoping)
>>>> 88. material (supportDesc)
>>>> 89. max (att.ranging)
>>>> 90. max (memberOf)
>>>> 91. medium (att.handFeatures)
>>>> 92. mergedIn (att.lexicographic)
>>>> 93. met (att.metrical)
>>>> 94. method (correction)
>>>> 95. mimeType (att.internetMedia)
>>>> 96. min (att.ranging)
>>>> 97. min (memberOf)
>>>> 98. mode (att.combinable)
>>>> 99. mode (classes)
>>>> 100. mode (memberOf)
>>>> 101. module (att.identified)
>>>> 102. new (handShift)
>>>> 103. next (att.global.linking)
>>>> 104. notAfter-custom (att.datable.custom)
>>>> 105. notAfter-iso (att.datable.iso)
>>>> 106. notBefore-custom (att.datable.custom)
>>>> 107. notBefore-iso (att.datable.iso)
>>>> 108. notation (pron)
>>>> 109. ns (attDef)
>>>> 110. ns (elementSpec)
>>>> 111. ns (schemaSpec)
>>>> 112. nymRef (att.naming)
>>>> 113. opt (att.lexicographic)
>>>> 114. optional (fDecl)
>>>> 115. ord (iNode)
>>>> 116. ord (root)
>>>> 117. org (att.divLike)
>>>> 118. org (attList)
>>>> 119. orig (att.lexicographic)
>>>> 120. part (ab)
>>>> 121. part (att.divLike)
>>>> 122. part (att.segLike)
>>>> 123. parts (nym)
>>>> 124. perf (tech)
>>>> 125. period (att.datable)
>>>> 126. pre (pc)
>>>> 127. precision (att.dimensions)
>>>> 128. predeclare (att.identified)
>>>> 129. prefix (elementSpec)
>>>> 130. prefix (moduleRef)
>>>> 131. prev (att.global.linking)
>>>> 132. quantity (att.dimensions)
>>>> 133. real (att.metrical)
>>>> 134. ref (att.canonical)
>>>> 135. refLang (att.pointing)
>>>> 136. resp (att.responsibility)
>>>> 137. resp (space)
>>>> 138. rhyme (att.metrical)
>>>> 139. role (att.naming)
>>>> 140. role (att.tableDecoration)
>>>> 141. role (org)
>>>> 142. rotate (zone)
>>>> 143. rows (att.tableDecoration)
>>>> 144. sameAs (att.global.linking)
>>>> 145. sample (att.divLike)
>>>> 146. scale (binaryObject)
>>>> 147. scale (graphic)
>>>> 148. scheme (catRef)
>>>> 149. scheme (locus)
>>>> 150. scheme (locusGrp)
>>>> 151. scheme (tag)
>>>> 152. scope (att.dimensions)
>>>> 153. scope (att.handFeatures)
>>>> 154. scribe (att.handFeatures)
>>>> 155. scribeRef (att.handFeatures)
>>>> 156. script (att.handFeatures)
>>>> 157. scriptRef (att.handFeatures)
>>>> 158. select (att.global.linking)
>>>> 159. seq (att.transcriptional)
>>>> 160. social (distinct)
>>>> 161. sort (att.personal)
>>>> 162. source (att.editLike)
>>>> 163. source (att.readFrom)
>>>> 164. source (writing)
>>>> 165. space (distinct)
>>>> 166. spanTo (att.spanning)
>>>> 167. split (att.lexicographic)
>>>> 168. start (att.coordinated)
>>>> 169. start (att.timed)
>>>> 170. status (att.identified)
>>>> 171. status (att.transcriptional)
>>>> 172. status (correction)
>>>> 173. stdDeviation (precision)
>>>> 174. subtype (att.typed)
>>>> 175. synch (att.global.linking)
>>>> 176. targFunc (att.pointing.group)
>>>> 177. target (change)
>>>> 178. target (relatedItem)
>>>> 179. targetEnd (note)
>>>> 180. targetLang (schemaSpec)
>>>> 181. targets (alt)
>>>> 182. targets (join)
>>>> 183. targets (link)
>>>> 184. time (distinct)
>>>> 185. to (app)
>>>> 186. to (att.datable.w3c)
>>>> 187. to-custom (att.datable.custom)
>>>> 188. to-iso (att.datable.iso)
>>>> 189. type (abbr)
>>>> 190. type (att.entryLike)
>>>> 191. type (att.interpLike)
>>>> 192. type (att.textCritical)
>>>> 193. type (att.typed)
>>>> 194. type (form)
>>>> 195. type (q)
>>>> 196. type (sound)
>>>> 197. ulx (att.coordinated)
>>>> 198. uly (att.coordinated)
>>>> 199. unit (att.dimensions)
>>>> 200. unit (pc)
>>>> 201. unit (when)
>>>> 202. url (moduleRef)
>>>> 203. value (att.lexicographic)
>>>> 204. value (eTree)
>>>> 205. value (iNode)
>>>> 206. value (leaf)
>>>> 207. value (node)
>>>> 208. value (root)
>>>> 209. value (triangle)
>>>> 210. varSeq (att.textCritical)
>>>> 211. version (unicodeName)
>>>> 212. versionDate (att.translatable)
>>>> 213. when (docDate)
>>>> 214. where (event)
>>>> 215. who (att.ascribed)
>>>> 216. width (binaryObject)
>>>> 217. width (graphic)
>>>> 218. wit (att.rdgPart)
>>>> 219. wit (att.witnessed)
>>>> 220. xml:base (att.global)
>>>> 221. xml:id (att.global)
>>>> 222. xml:lang (att.global)
>>>> 223. xml:space (att.global)
>>>>
>>>> Cheers,
>>>> Martin
>>>>
>>>> On 12-04-19 03:18 PM, Martin Holmes wrote:
>>>>> Following on from our discussion of examples for attributes, a
>>>>> quick-and-dirty XSLT seems to show that there are only 19 attributes
>>>>> with their own examples, and 450 without. This is not to say that those
>>>>> without are unexemplified, because the example code for their parent
>>>>> elements in the elementSpec may show examples of them; I'll refine the
>>>>> XSLT and make that apparent.
>>>>>
>>>>> Here's the list:
>>>>>
>>>>> ATTRIBUTE DEFINITIONS LACKING EXAMPLES AS OF 2012-04-19T15:12:34.968-07:00
>>>>>
>>>>> 1. status (att.identified)
>>>>> 2. type (interaction)
>>>>> 3. value (sex)
>>>>> 4. scale (graphic)
>>>>> 5. scale (binaryObject)
>>>>> 6. weights (alt)
>>>>> 7. hand (att.damaged)
>>>>> 8. agent (gap)
>>>>> 9. predeclare (att.identified)
>>>>> 10. degree (att.damaged)
>>>>> 11. module (att.identified)
>>>>> 12. ident (att.identified)
>>>>> 13. height (graphic)
>>>>> 14. height (binaryObject)
>>>>> 15. width (graphic)
>>>>> 16. width (binaryObject)
>>>>> 17. encoding (binaryObject)
>>>>> 18. version (teiCorpus)
>>>>> 19. hand (unclear)
>>>>> 20. agent (unclear)
>>>>> 21. feature (shift)
>>>>> 22. type (preparedness)
>>>>> 23. type (abbr)
>>>>> 24. commodity (att.measurement)
>>>>> 25. agent (att.damaged)
>>>>> 26. type (derivation)
>>>>> 27. type (domain)
>>>>> 28. type (factuality)
>>>>> 29. type (idno)
>>>>> 30. type (relation)
>>>>> 31. type (sound)
>>>>> 32. type (tech)
>>>>> 33. type (castItem)
>>>>> 34. type (att.typed)
>>>>> 35. type (move)
>>>>> 36. script (att.handFeatures)
>>>>> 37. class (msItemStruct)
>>>>> 38. class (msItem)
>>>>> 39. class (msContents)
>>>>> 40. type (form)
>>>>> 41. cause (att.textCritical)
>>>>> 42. type (gram)
>>>>> 43. type (lbl)
>>>>> 44. type (att.textCritical)
>>>>> 45. type (title)
>>>>> 46. type (titlePage)
>>>>> 47. type (usg)
>>>>> 48. type (app)
>>>>> 49. columns (layout)
>>>>> 50. valueDatcat (att.datcat)
>>>>> 51. datcat (att.datcat)
>>>>> 52. contemporary (seal)
>>>>> 53. contemporary (binding)
>>>>> 54. from (locus)
>>>>> 55. type (list)
>>>>> 56. result (joinGrp)
>>>>> 57. medium (att.handFeatures)
>>>>> 58. type (graph)
>>>>> 59. type (witDetail)
>>>>> 60. origin (timeline)
>>>>> 61. function (att.segLike)
>>>>> 62. form (objectDesc)
>>>>> 63. mergedIn (att.lexicographic)
>>>>> 64. type (fsDecl)
>>>>> 65. scribe (att.handFeatures)
>>>>> 66. degree (node)
>>>>> 67. extent (orth)
>>>>> 68. from (arc)
>>>>> 69. to (arc)
>>>>> 70. inDegree (node)
>>>>> 71. arity (tree)
>>>>> 72. baseTypes (fsDecl)
>>>>> 73. level (sense)
>>>>> 74. order (tree)
>>>>> 75. outDegree (iNode)
>>>>> 76. outDegree (node)
>>>>> 77. outDegree (root)
>>>>> 78. reason (gap)
>>>>> 79. type (orth)
>>>>> 80. when (docDate)
>>>>> 81. split (att.lexicographic)
>>>>> 82. code (socecStatus)
>>>>> 83. code (occupation)
>>>>> 84. decls (att.declaring)
>>>>> 85. cRef (term)
>>>>> 86. from (app)
>>>>> 87. scheme (catRef)
>>>>> 88. scheme (occupation)
>>>>> 89. scheme (classCode)
>>>>> 90. scheme (socecStatus)
>>>>> 91. scheme (keywords)
>>>>> 92. to (app)
>>>>> 93. baseForm (m)
>>>>> 94. new (handShift)
>>>>> 95. passive (relation)
>>>>> 96. since (when)
>>>>> 97. type (fsdLink)
>>>>> 98. type (biblScope)
>>>>> 99. type (listForest)
>>>>> 100. type (forest)
>>>>> 101. hand (gap)
>>>>> 102. given (certainty)
>>>>> 103. locus (certainty)
>>>>> 104. type (rs)
>>>>> 105. source (normalization)
>>>>> 106. level (title)
>>>>> 107. degree (certainty)
>>>>> 108. status (correction)
>>>>> 109. degree (precision)
>>>>> 110. spanTo (att.spanning)
>>>>> 111. to (att.datable.w3c)
>>>>> 112. to-iso (att.datable.iso)
>>>>> 113. force (pc)
>>>>> 114. reason (surplus)
>>>>> 115. type (stage)
>>>>> 116. type (oRef)
>>>>> 117. type (oVar)
>>>>> 118. method (correction)
>>>>> 119. method (normalization)
>>>>> 120. name (fDecl)
>>>>> 121. evidence (att.editLike)
>>>>> 122. rows (table)
>>>>> 123. org (vMerge)
>>>>> 124. who (att.ascribed)
>>>>> 125. locus (respons)
>>>>> 126. from-custom (att.datable.custom)
>>>>> 127. from (att.datable.w3c)
>>>>> 128. from-iso (att.datable.iso)
>>>>> 129. type (xr)
>>>>> 130. type (iType)
>>>>> 131. type (num)
>>>>> 132. type (att.entryLike)
>>>>> 133. type (att.interpLike)
>>>>> 134. unit (refState)
>>>>> 135. notation (pron)
>>>>> 136. break (att.breaking)
>>>>> 137. iterated (kinesic)
>>>>> 138. iterated (vocal)
>>>>> 139. optional (fDecl)
>>>>> 140. default (att.declarable)
>>>>> 141. location (variantEncoding)
>>>>> 142. anchored (note)
>>>>> 143. full (att.personal)
>>>>> 144. type (metDecl)
>>>>> 145. extent (pron)
>>>>> 146. discrete (sound)
>>>>> 147. scope (join)
>>>>> 148. gradual (writing)
>>>>> 149. sample (att.divLike)
>>>>> 150. type (classSpec)
>>>>> 151. pre (pc)
>>>>> 152. type (dimensions)
>>>>> 153. method (variantEncoding)
>>>>> 154. type (macroSpec)
>>>>> 155. reason (supplied)
>>>>> 156. to (locus)
>>>>> 157. rows (att.tableDecoration)
>>>>> 158. writtenLines (layout)
>>>>> 159. ruledLines (layout)
>>>>> 160. location (att.lexicographic)
>>>>> 161. hands (handDesc)
>>>>> 162. material (supportDesc)
>>>>> 163. notation (formula)
>>>>> 164. unit (att.dimensions)
>>>>> 165. ns (attDef)
>>>>> 166. ns (elementSpec)
>>>>> 167. domains (att.pointing.group)
>>>>> 168. part (att.segLike)
>>>>> 169. source (writing)
>>>>> 170. ref (g)
>>>>> 171. scribeRef (att.handFeatures)
>>>>> 172. scriptRef (att.handFeatures)
>>>>> 173. copyOf (att.global.linking)
>>>>> 174. sameAs (att.global.linking)
>>>>> 175. exclude (att.global.linking)
>>>>> 176. targetEnd (note)
>>>>> 177. next (att.global.linking)
>>>>> 178. target (relatedItem)
>>>>> 179. unit (milestone)
>>>>> 180. label (rhyme)
>>>>> 181. lemma (w)
>>>>> 182. children (iNode)
>>>>> 183. children (root)
>>>>> 184. name (f)
>>>>> 185. unit (pc)
>>>>> 186. value (leaf)
>>>>> 187. type (node)
>>>>> 188. key (att.canonical)
>>>>> 189. follow (iNode)
>>>>> 190. follow (leaf)
>>>>> 191. parent (leaf)
>>>>> 192. parent (iNode)
>>>>> 193. value (node)
>>>>> 194. value (triangle)
>>>>> 195. value (eLeaf)
>>>>> 196. value (eTree)
>>>>> 197. value (iNode)
>>>>> 198. value (root)
>>>>> 199. quantity (att.measurement)
>>>>> 200. role (att.tableDecoration)
>>>>> 201. scheme (att)
>>>>> 202. select (att.global.linking)
>>>>> 203. xml:space (att.global)
>>>>> 204. hand (att.textCritical)
>>>>> 205. subtype (att.typed)
>>>>> 206. prefix (schemaSpec)
>>>>> 207. prefix (elementSpec)
>>>>> 208. type (purpose)
>>>>> 209. role (org)
>>>>> 210. role (person)
>>>>> 211. matchPattern (cRefPattern)
>>>>> 212. replacementPattern (cRefPattern)
>>>>> 213. age (person)
>>>>> 214. start (schemaSpec)
>>>>> 215. form (quotation)
>>>>> 216. time (distinct)
>>>>> 217. social (distinct)
>>>>> 218. space (distinct)
>>>>> 219. type (constitution)
>>>>> 220. scope (att.handFeatures)
>>>>> 221. age (personGrp)
>>>>> 222. usage (language)
>>>>> 223. ident (valItem)
>>>>> 224. from (span)
>>>>> 225. value (metSym)
>>>>> 226. versionDate (att.translatable)
>>>>> 227. target (att.pointing)
>>>>> 228. where (move)
>>>>> 229. notBefore (att.datable.w3c)
>>>>> 230. notBefore-custom (att.datable.custom)
>>>>> 231. notBefore-iso (att.datable.iso)
>>>>> 232. mode (classes)
>>>>> 233. mode (att.combinable)
>>>>> 234. mode (memberOf)
>>>>> 235. to (span)
>>>>> 236. to (biblScope)
>>>>> 237. type (valList)
>>>>> 238. degree (purpose)
>>>>> 239. length (refState)
>>>>> 240. render (tagUsage)
>>>>> 241. targets (alt)
>>>>> 242. targets (join)
>>>>> 243. targets (link)
>>>>> 244. type (teiHeader)
>>>>> 245. notAfter (att.datable.w3c)
>>>>> 246. notAfter-custom (att.datable.custom)
>>>>> 247. notAfter-iso (att.datable.iso)
>>>>> 248. version (TEI)
>>>>> 249. mode (channel)
>>>>> 250. result (join)
>>>>> 251. new (shift)
>>>>> 252. active (interaction)
>>>>> 253. occurs (tagUsage)
>>>>> 254. passive (interaction)
>>>>> 255. interval (when)
>>>>> 256. interval (timeline)
>>>>> 257. usage (attDef)
>>>>> 258. role (personGrp)
>>>>> 259. type (titlePart)
>>>>> 260. sex (personGrp)
>>>>> 261. sex (person)
>>>>> 262. size (personGrp)
>>>>> 263. from (biblScope)
>>>>> 264. type (distinct)
>>>>> 265. type (measure)
>>>>> 266. type (fs)
>>>>> 267. unit (timeline)
>>>>> 268. unit (when)
>>>>> 269. version (unicodeName)
>>>>> 270. type (divGen)
>>>>> 271. part (ab)
>>>>> 272. part (att.divLike)
>>>>> 273. part (l)
>>>>> 274. terminal (metSym)
>>>>> 275. trunc (numeric)
>>>>> 276. order (graph)
>>>>> 277. size (graph)
>>>>> 278. mode (alt)
>>>>> 279. mode (altGrp)
>>>>> 280. value (binary)
>>>>> 281. status (availability)
>>>>> 282. datum (geoDecl)
>>>>> 283. value (numeric)
>>>>> 284. name (relation)
>>>>> 285. name (vLabel)
>>>>> 286. indexName (index)
>>>>> 287. stdDeviation (precision)
>>>>> 288. absolute (when)
>>>>> 289. max (numeric)
>>>>> 290. scheme (constraintSpec)
>>>>> 291. scheme (tag)
>>>>> 292. scheme (gi)
>>>>> 293. value (symbol)
>>>>> 294. value (num)
>>>>> 295. scheme (locusGrp)
>>>>> 296. scheme (locus)
>>>>> 297. name (namespace)
>>>>> 298. type (recording)
>>>>> 299. unit (att.measurement)
>>>>> 300. value (att.lexicographic)
>>>>> 301. scope (att.dimensions)
>>>>> 302. evaluate (att.pointing)
>>>>> 303. active (relation)
>>>>> 304. to-custom (att.datable.custom)
>>>>> 305. mutual (relation)
>>>>> 306. dur-iso (att.duration.iso)
>>>>> 307. instant (att.editLike)
>>>>> 308. function (metamark)
>>>>> 309. attachment (surface)
>>>>> 310. cause (att.transcriptional)
>>>>> 311. target (metamark)
>>>>> 312. rotate (zone)
>>>>> 313. target (redo)
>>>>> 314. target (undo)
>>>>> 315. except (moduleRef)
>>>>> 316. include (moduleRef)
>>>>> 317. datingMethod (att.datable.custom)
>>>>> 318. datingPoint (att.datable.custom)
>>>>> 319. key (moduleRef)
>>>>> 320. url (moduleRef)
>>>>> 321. mimeType (att.internetMedia)
>>>>> 322. version (application)
>>>>> 323. ident (application)
>>>>> 324. confidence (att.ranging)
>>>>> 325. level (langKnown)
>>>>> 326. adj (node)
>>>>> 327. adjFrom (node)
>>>>> 328. adjTo (node)
>>>>> 329. ana (att.global.analytic)
>>>>> 330. group (att.damaged)
>>>>> 331. cRef (gloss)
>>>>> 332. cRef (ptr)
>>>>> 333. cRef (ref)
>>>>> 334. cert (att.responsibility)
>>>>> 335. cert (certainty)
>>>>> 336. precision (precision)
>>>>> 337. precision (att.dimensions)
>>>>> 338. type (fw)
>>>>> 339. cols (table)
>>>>> 340. cols (att.tableDecoration)
>>>>> 341. source (att.editLike)
>>>>> 342. autoPrefix (content)
>>>>> 343. corresp (att.global.linking)
>>>>> 344. delim (refState)
>>>>> 345. dim (space)
>>>>> 346. docLang (schemaSpec)
>>>>> 347. dur (att.duration.w3c)
>>>>> 348. ed (att.sourced)
>>>>> 349. gi (tagUsage)
>>>>> 350. eol (hyphenation)
>>>>> 351. enjamb (att.enjamb)
>>>>> 352. facs (att.global.facs)
>>>>> 353. fVal (f)
>>>>> 354. feats (fs)
>>>>> 355. lang (code)
>>>>> 356. atMost (att.ranging)
>>>>> 357. atLeast (att.ranging)
>>>>> 358. lrx (att.coordinated)
>>>>> 359. ulx (att.coordinated)
>>>>> 360. lry (att.coordinated)
>>>>> 361. uly (att.coordinated)
>>>>> 362. xml:id (att.global)
>>>>> 363. ident (language)
>>>>> 364. scheme (rendition)
>>>>> 365. status (att.transcriptional)
>>>>> 366. where (event)
>>>>> 367. start (att.timed)
>>>>> 368. end (att.timed)
>>>>> 369. type (tag)
>>>>> 370. defective (att.msExcerpt)
>>>>> 371. generate (classSpec)
>>>>> 372. inst (att.interpLike)
>>>>> 373. xml:lang (att.global)
>>>>> 374. loc (app)
>>>>> 375. mainLang (textLang)
>>>>> 376. maxOccurs (datatype)
>>>>> 377. type (q)
>>>>> 378. direct (said)
>>>>> 379. aloud (said)
>>>>> 380. met (att.metrical)
>>>>> 381. real (att.metrical)
>>>>> 382. minOccurs (datatype)
>>>>> 383. name (equiv)
>>>>> 384. ns (schemaSpec)
>>>>> 385. n (att.global)
>>>>> 386. opt (att.lexicographic)
>>>>> 387. ord (iNode)
>>>>> 388. ord (root)
>>>>> 389. ord (tree)
>>>>> 390. sort (att.personal)
>>>>> 391. org (attList)
>>>>> 392. org (vColl)
>>>>> 393. org (att.divLike)
>>>>> 394. orig (att.lexicographic)
>>>>> 395. otherLangs (textLang)
>>>>> 396. perf (move)
>>>>> 397. perf (tech)
>>>>> 398. target (specGrpRef)
>>>>> 399. parts (nym)
>>>>> 400. change (att.global.change)
>>>>> 401. target (change)
>>>>> 402. prev (att.global.linking)
>>>>> 403. lemmaRef (w)
>>>>> 404. marks (quotation)
>>>>> 405. ref (att.canonical)
>>>>> 406. nymRef (att.naming)
>>>>> 407. filter (equiv)
>>>>> 408. pattern (metDecl)
>>>>> 409. resp (respons)
>>>>> 410. resp (att.responsibility)
>>>>> 411. resp (space)
>>>>> 412. rhyme (att.metrical)
>>>>> 413. seq (att.transcriptional)
>>>>> 414. hand (att.transcriptional)
>>>>> 415. prefix (moduleRef)
>>>>> 416. key (memberOf)
>>>>> 417. quantity (att.dimensions)
>>>>> 418. value (age)
>>>>> 419. target (fsdLink)
>>>>> 420. period (att.datable)
>>>>> 421. tag (langKnown)
>>>>> 422. tags (langKnowledge)
>>>>> 423. max (memberOf)
>>>>> 424. min (memberOf)
>>>>> 425. synch (att.global.linking)
>>>>> 426. targFunc (att.pointing.group)
>>>>> 427. targetLang (schemaSpec)
>>>>> 428. key (classRef)
>>>>> 429. key (elementRef)
>>>>> 430. key (macroRef)
>>>>> 431. name (attRef)
>>>>> 432. trans (u)
>>>>> 433. uri (equiv)
>>>>> 434. url (graphic)
>>>>> 435. varSeq (att.textCritical)
>>>>> 436. scope (rendition)
>>>>> 437. max (att.ranging)
>>>>> 438. min (att.ranging)
>>>>> 439. withId (tagUsage)
>>>>> 440. wit (att.witnessed)
>>>>> 441. wit (att.rdgPart)
>>>>> 442. wit (witDetail)
>>>>> 443. status (att.docStatus)
>>>>> 444. points (zone)
>>>>> 445. start (att.coordinated)
>>>>> 446. valid (egXML)
>>>>> 447. ordered (listChange)
>>>>> 448. role (att.naming)
>>>>> 449. source (att.readFrom)
>>>>> 450. flipping (surface)
>>>>>
>>>>>
>>>>> ATTRIBUTE DEFINITIONS WHICH HAVE EXAMPLES AS OF
>>>>> 2012-04-19T15:12:34.968-07:00
>>>>>
>>>>> 1. place (att.placement)
>>>>> 2. expand (att.lexicographic)
>>>>> 3. extent (att.dimensions)
>>>>> 4. calendar (att.datable)
>>>>> 5. reason (unclear)
>>>>> 6. target (att.scoping)
>>>>> 7. xml:base (att.global)
>>>>> 8. assertedValue (certainty)
>>>>> 9. refLang (att.pointing)
>>>>> 10. match (att.scoping)
>>>>> 11. sortKey (att.sortable)
>>>>> 12. atts (specDesc)
>>>>> 13. key (specDesc)
>>>>> 14. norm (att.lexicographic)
>>>>> 15. rendition (att.global)
>>>>> 16. rend (att.global)
>>>>> 17. when-iso (att.datable.iso)
>>>>> 18. when-custom (att.datable.custom)
>>>>> 19. when (att.datable.w3c)
>>>>>
>>>>> --
>>>>> Martin Holmes
>>>>> University of Victoria Humanities Computing and Media Centre
>>>>> (mholmes at uvic.ca)
>>>>> --
>>>>> tei-council mailing list
>>>>> tei-council at lists.village.Virginia.EDU
>>>>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>>>>>
>>>>> PLEASE NOTE: postings to this list are publicly archived
>>>>> .
>>>>>
>>>>
>>> .
>>>
>>
>
>
> --
> Dr James Cummings, InfoDev,
> Computing Services, University of Oxford
> --
> tei-council mailing list
> tei-council at lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>
> PLEASE NOTE: postings to this list are publicly archived
> .
>

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From James.Cummings at oucs.ox.ac.uk  Mon Apr 23 12:30:14 2012
From: James.Cummings at oucs.ox.ac.uk (James Cummings)
Date: Mon, 23 Apr 2012 17:30:14 +0100
Subject: [tei-council] Attributes without examples
In-Reply-To: <4F9580F6.4080505@uvic.ca>
References: <4F908F22.4070908@uvic.ca>	<4F90AD72.10605@uvic.ca>
	<4F90AEBC.6000608@ultraslavonic.info>	<4F9573BF.1080302@uvic.ca>
	<4F957C03.8090008@oucs.ox.ac.uk> <4F9580F6.4080505@uvic.ca>
Message-ID: <4F958396.9010304@oucs.ox.ac.uk>

On 23/04/12 17:19, Martin Holmes wrote:
> Thanks James -- that works. I have to write that down somewhere.
> I wonder why spambots wouldn't use <nowiki/> themselves.

Sadly, they do. Increasingly, they can also read captchas.

> Here's the page -- feel free to sign up for one or more
> attributes by editing it:
> <http://wiki.tei-c.org/index.php/AttsWithoutEgs>

Would it make sense to also look at the attribute's datatype and 
if it is something like data.pointer consider putting in multiple 
examples (e.g. one that points locally and one that points to a 
remote object).

-James

-- 
Dr James Cummings, InfoDev,
Computing Services, University of Oxford

From mholmes at uvic.ca  Mon Apr 23 12:35:03 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Mon, 23 Apr 2012 09:35:03 -0700
Subject: [tei-council] Attributes without examples
In-Reply-To: <4F9580F6.4080505@uvic.ca>
References: <4F908F22.4070908@uvic.ca>	<4F90AD72.10605@uvic.ca>
	<4F90AEBC.6000608@ultraslavonic.info>	<4F9573BF.1080302@uvic.ca>
	<4F957C03.8090008@oucs.ox.ac.uk> <4F9580F6.4080505@uvic.ca>
Message-ID: <4F9584B7.3080302@uvic.ca>

I've created a ticket for this too, so we don't lose track of it:

<http://purl.org/TEI/BUGS/3520704>

Cheers,
Martin

On 12-04-23 09:19 AM, Martin Holmes wrote:
> Thanks James -- that works. I have to write that down somewhere. I
> wonder why spambots wouldn't use<nowiki/>  themselves.
>
> Here's the page -- feel free to sign up for one or more attributes by
> editing it:
>
> <http://wiki.tei-c.org/index.php/AttsWithoutEgs>
>
> Cheers,
> Martin
>
> On 12-04-23 08:57 AM, James Cummings wrote:
>>
>> Martin,
>>
>> It is simple but intentionally not documented. Interrupt the spam
>> word with an element. Specifically use<nowiki/>   so
>> att.ms<nowiki/>Excerpt will allow you to get around the spam filter.
>>
>> Just don't advertise via<nowiki/>gra too much.
>>
>> -James
>>
>> On 23/04/12 16:22, Martin Holmes wrote:
>>> I've just tried to create a wiki page which has a table listing all
>>> these attributes, but I've been prevented from doing so by the sad
>>> little spam filter, which won't allow this:
>>>
>>> att.msExcerpt
>>>
>>> because it contains "sEx".
>>>
>>> I seem to remember having spent a frustrating time fighting with this
>>> stupidity some time ago. Does anyone remember how to get around this, or
>>> is it pointless to try?
>>>
>>> Cheers,
>>> Martin
>>>
>>> On 12-04-19 05:33 PM, Kevin Hawkins wrote:
>>>> Would you be able to output as a table with a third column for people to
>>>> sign up, either in MediaWiki or HTML syntax, for a page in the wiki?
>>>>
>>>> On 4/19/12 8:27 PM, Martin Holmes wrote:
>>>>> Below is another slightly shorter list. These are attributes which do
>>>>> not appear on any examples in the<elementSpec>      or<classSpec>      in which
>>>>> they're defined. Not that this doesn't mean there are no examples at all
>>>>> for them; there may be an example somewhere in the Guidelines text, or
>>>>> the attribute may be defined in a<classSpec>      for an attribute class,
>>>>> and then show up in an example in an<elementSpec>      for an element which
>>>>> belongs to that class. An example of the latter is @agent (att.damaged),
>>>>> which has no example in the att.damaged<classSpec>, but happens to show
>>>>> up in an example for the<damage>      element.
>>>>>
>>>>> Nevertheless, I think it would be a good idea to try to provide examples
>>>>> for all these attributes, in the files which define them.
>>>>>
>>>>> ATTRIBUTES WHICH DO NOT SHOW UP ON ANY EXAMPLE IN THEIR elementSpec OR
>>>>> classSpec AS OF 2012-04-19T17:19:17.315-07:00
>>>>>
>>>>> 1. absolute (when)
>>>>> 2. adj (node)
>>>>> 3. adjFrom (node)
>>>>> 4. adjTo (node)
>>>>> 5. age (personGrp)
>>>>> 6. agent (att.damaged)
>>>>> 7. agent (gap)
>>>>> 8. agent (unclear)
>>>>> 9. ana (att.global.analytic)
>>>>> 10. atLeast (att.ranging)
>>>>> 11. atMost (att.ranging)
>>>>> 12. attachment (surface)
>>>>> 13. autoPrefix (content)
>>>>> 14. baseTypes (fsDecl)
>>>>> 15. break (att.breaking)
>>>>> 16. cRef (gloss)
>>>>> 17. cRef (ptr)
>>>>> 18. cRef (ref)
>>>>> 19. cRef (term)
>>>>> 20. cause (att.textCritical)
>>>>> 21. cause (att.transcriptional)
>>>>> 22. cert (att.responsibility)
>>>>> 23. change (att.global.change)
>>>>> 24. class (msContents)
>>>>> 25. cols (att.tableDecoration)
>>>>> 26. confidence (att.ranging)
>>>>> 27. contemporary (seal)
>>>>> 28. copyOf (att.global.linking)
>>>>> 29. corresp (att.global.linking)
>>>>> 30. datingMethod (att.datable.custom)
>>>>> 31. datingPoint (att.datable.custom)
>>>>> 32. decls (att.declaring)
>>>>> 33. default (att.declarable)
>>>>> 34. defective (att.msExcerpt)
>>>>> 35. degree (att.damaged)
>>>>> 36. degree (node)
>>>>> 37. dim (space)
>>>>> 38. direct (said)
>>>>> 39. docLang (schemaSpec)
>>>>> 40. domains (att.pointing.group)
>>>>> 41. dur (att.duration.w3c)
>>>>> 42. dur-iso (att.duration.iso)
>>>>> 43. encoding (binaryObject)
>>>>> 44. end (att.timed)
>>>>> 45. enjamb (att.enjamb)
>>>>> 46. evaluate (att.pointing)
>>>>> 47. evidence (att.editLike)
>>>>> 48. except (moduleRef)
>>>>> 49. exclude (att.global.linking)
>>>>> 50. expand (att.lexicographic)
>>>>> 51. extent (orth)
>>>>> 52. fVal (f)
>>>>> 53. facs (att.global.facs)
>>>>> 54. feats (fs)
>>>>> 55. filter (equiv)
>>>>> 56. flipping (surface)
>>>>> 57. follow (leaf)
>>>>> 58. force (pc)
>>>>> 59. from (app)
>>>>> 60. from (att.datable.w3c)
>>>>> 61. from-custom (att.datable.custom)
>>>>> 62. from-iso (att.datable.iso)
>>>>> 63. full (att.personal)
>>>>> 64. function (att.segLike)
>>>>> 65. generate (classSpec)
>>>>> 66. gradual (writing)
>>>>> 67. group (att.damaged)
>>>>> 68. hand (att.damaged)
>>>>> 69. hand (att.textCritical)
>>>>> 70. hand (att.transcriptional)
>>>>> 71. hand (gap)
>>>>> 72. hand (unclear)
>>>>> 73. height (binaryObject)
>>>>> 74. height (graphic)
>>>>> 75. ident (att.identified)
>>>>> 76. inst (att.interpLike)
>>>>> 77. instant (att.editLike)
>>>>> 78. key (att.canonical)
>>>>> 79. key (classRef)
>>>>> 80. key (macroRef)
>>>>> 81. level (sense)
>>>>> 82. level (title)
>>>>> 83. loc (app)
>>>>> 84. location (att.lexicographic)
>>>>> 85. lrx (att.coordinated)
>>>>> 86. lry (att.coordinated)
>>>>> 87. match (att.scoping)
>>>>> 88. material (supportDesc)
>>>>> 89. max (att.ranging)
>>>>> 90. max (memberOf)
>>>>> 91. medium (att.handFeatures)
>>>>> 92. mergedIn (att.lexicographic)
>>>>> 93. met (att.metrical)
>>>>> 94. method (correction)
>>>>> 95. mimeType (att.internetMedia)
>>>>> 96. min (att.ranging)
>>>>> 97. min (memberOf)
>>>>> 98. mode (att.combinable)
>>>>> 99. mode (classes)
>>>>> 100. mode (memberOf)
>>>>> 101. module (att.identified)
>>>>> 102. new (handShift)
>>>>> 103. next (att.global.linking)
>>>>> 104. notAfter-custom (att.datable.custom)
>>>>> 105. notAfter-iso (att.datable.iso)
>>>>> 106. notBefore-custom (att.datable.custom)
>>>>> 107. notBefore-iso (att.datable.iso)
>>>>> 108. notation (pron)
>>>>> 109. ns (attDef)
>>>>> 110. ns (elementSpec)
>>>>> 111. ns (schemaSpec)
>>>>> 112. nymRef (att.naming)
>>>>> 113. opt (att.lexicographic)
>>>>> 114. optional (fDecl)
>>>>> 115. ord (iNode)
>>>>> 116. ord (root)
>>>>> 117. org (att.divLike)
>>>>> 118. org (attList)
>>>>> 119. orig (att.lexicographic)
>>>>> 120. part (ab)
>>>>> 121. part (att.divLike)
>>>>> 122. part (att.segLike)
>>>>> 123. parts (nym)
>>>>> 124. perf (tech)
>>>>> 125. period (att.datable)
>>>>> 126. pre (pc)
>>>>> 127. precision (att.dimensions)
>>>>> 128. predeclare (att.identified)
>>>>> 129. prefix (elementSpec)
>>>>> 130. prefix (moduleRef)
>>>>> 131. prev (att.global.linking)
>>>>> 132. quantity (att.dimensions)
>>>>> 133. real (att.metrical)
>>>>> 134. ref (att.canonical)
>>>>> 135. refLang (att.pointing)
>>>>> 136. resp (att.responsibility)
>>>>> 137. resp (space)
>>>>> 138. rhyme (att.metrical)
>>>>> 139. role (att.naming)
>>>>> 140. role (att.tableDecoration)
>>>>> 141. role (org)
>>>>> 142. rotate (zone)
>>>>> 143. rows (att.tableDecoration)
>>>>> 144. sameAs (att.global.linking)
>>>>> 145. sample (att.divLike)
>>>>> 146. scale (binaryObject)
>>>>> 147. scale (graphic)
>>>>> 148. scheme (catRef)
>>>>> 149. scheme (locus)
>>>>> 150. scheme (locusGrp)
>>>>> 151. scheme (tag)
>>>>> 152. scope (att.dimensions)
>>>>> 153. scope (att.handFeatures)
>>>>> 154. scribe (att.handFeatures)
>>>>> 155. scribeRef (att.handFeatures)
>>>>> 156. script (att.handFeatures)
>>>>> 157. scriptRef (att.handFeatures)
>>>>> 158. select (att.global.linking)
>>>>> 159. seq (att.transcriptional)
>>>>> 160. social (distinct)
>>>>> 161. sort (att.personal)
>>>>> 162. source (att.editLike)
>>>>> 163. source (att.readFrom)
>>>>> 164. source (writing)
>>>>> 165. space (distinct)
>>>>> 166. spanTo (att.spanning)
>>>>> 167. split (att.lexicographic)
>>>>> 168. start (att.coordinated)
>>>>> 169. start (att.timed)
>>>>> 170. status (att.identified)
>>>>> 171. status (att.transcriptional)
>>>>> 172. status (correction)
>>>>> 173. stdDeviation (precision)
>>>>> 174. subtype (att.typed)
>>>>> 175. synch (att.global.linking)
>>>>> 176. targFunc (att.pointing.group)
>>>>> 177. target (change)
>>>>> 178. target (relatedItem)
>>>>> 179. targetEnd (note)
>>>>> 180. targetLang (schemaSpec)
>>>>> 181. targets (alt)
>>>>> 182. targets (join)
>>>>> 183. targets (link)
>>>>> 184. time (distinct)
>>>>> 185. to (app)
>>>>> 186. to (att.datable.w3c)
>>>>> 187. to-custom (att.datable.custom)
>>>>> 188. to-iso (att.datable.iso)
>>>>> 189. type (abbr)
>>>>> 190. type (att.entryLike)
>>>>> 191. type (att.interpLike)
>>>>> 192. type (att.textCritical)
>>>>> 193. type (att.typed)
>>>>> 194. type (form)
>>>>> 195. type (q)
>>>>> 196. type (sound)
>>>>> 197. ulx (att.coordinated)
>>>>> 198. uly (att.coordinated)
>>>>> 199. unit (att.dimensions)
>>>>> 200. unit (pc)
>>>>> 201. unit (when)
>>>>> 202. url (moduleRef)
>>>>> 203. value (att.lexicographic)
>>>>> 204. value (eTree)
>>>>> 205. value (iNode)
>>>>> 206. value (leaf)
>>>>> 207. value (node)
>>>>> 208. value (root)
>>>>> 209. value (triangle)
>>>>> 210. varSeq (att.textCritical)
>>>>> 211. version (unicodeName)
>>>>> 212. versionDate (att.translatable)
>>>>> 213. when (docDate)
>>>>> 214. where (event)
>>>>> 215. who (att.ascribed)
>>>>> 216. width (binaryObject)
>>>>> 217. width (graphic)
>>>>> 218. wit (att.rdgPart)
>>>>> 219. wit (att.witnessed)
>>>>> 220. xml:base (att.global)
>>>>> 221. xml:id (att.global)
>>>>> 222. xml:lang (att.global)
>>>>> 223. xml:space (att.global)
>>>>>
>>>>> Cheers,
>>>>> Martin
>>>>>
>>>>> On 12-04-19 03:18 PM, Martin Holmes wrote:
>>>>>> Following on from our discussion of examples for attributes, a
>>>>>> quick-and-dirty XSLT seems to show that there are only 19 attributes
>>>>>> with their own examples, and 450 without. This is not to say that those
>>>>>> without are unexemplified, because the example code for their parent
>>>>>> elements in the elementSpec may show examples of them; I'll refine the
>>>>>> XSLT and make that apparent.
>>>>>>
>>>>>> Here's the list:
>>>>>>
>>>>>> ATTRIBUTE DEFINITIONS LACKING EXAMPLES AS OF 2012-04-19T15:12:34.968-07:00
>>>>>>
>>>>>> 1. status (att.identified)
>>>>>> 2. type (interaction)
>>>>>> 3. value (sex)
>>>>>> 4. scale (graphic)
>>>>>> 5. scale (binaryObject)
>>>>>> 6. weights (alt)
>>>>>> 7. hand (att.damaged)
>>>>>> 8. agent (gap)
>>>>>> 9. predeclare (att.identified)
>>>>>> 10. degree (att.damaged)
>>>>>> 11. module (att.identified)
>>>>>> 12. ident (att.identified)
>>>>>> 13. height (graphic)
>>>>>> 14. height (binaryObject)
>>>>>> 15. width (graphic)
>>>>>> 16. width (binaryObject)
>>>>>> 17. encoding (binaryObject)
>>>>>> 18. version (teiCorpus)
>>>>>> 19. hand (unclear)
>>>>>> 20. agent (unclear)
>>>>>> 21. feature (shift)
>>>>>> 22. type (preparedness)
>>>>>> 23. type (abbr)
>>>>>> 24. commodity (att.measurement)
>>>>>> 25. agent (att.damaged)
>>>>>> 26. type (derivation)
>>>>>> 27. type (domain)
>>>>>> 28. type (factuality)
>>>>>> 29. type (idno)
>>>>>> 30. type (relation)
>>>>>> 31. type (sound)
>>>>>> 32. type (tech)
>>>>>> 33. type (castItem)
>>>>>> 34. type (att.typed)
>>>>>> 35. type (move)
>>>>>> 36. script (att.handFeatures)
>>>>>> 37. class (msItemStruct)
>>>>>> 38. class (msItem)
>>>>>> 39. class (msContents)
>>>>>> 40. type (form)
>>>>>> 41. cause (att.textCritical)
>>>>>> 42. type (gram)
>>>>>> 43. type (lbl)
>>>>>> 44. type (att.textCritical)
>>>>>> 45. type (title)
>>>>>> 46. type (titlePage)
>>>>>> 47. type (usg)
>>>>>> 48. type (app)
>>>>>> 49. columns (layout)
>>>>>> 50. valueDatcat (att.datcat)
>>>>>> 51. datcat (att.datcat)
>>>>>> 52. contemporary (seal)
>>>>>> 53. contemporary (binding)
>>>>>> 54. from (locus)
>>>>>> 55. type (list)
>>>>>> 56. result (joinGrp)
>>>>>> 57. medium (att.handFeatures)
>>>>>> 58. type (graph)
>>>>>> 59. type (witDetail)
>>>>>> 60. origin (timeline)
>>>>>> 61. function (att.segLike)
>>>>>> 62. form (objectDesc)
>>>>>> 63. mergedIn (att.lexicographic)
>>>>>> 64. type (fsDecl)
>>>>>> 65. scribe (att.handFeatures)
>>>>>> 66. degree (node)
>>>>>> 67. extent (orth)
>>>>>> 68. from (arc)
>>>>>> 69. to (arc)
>>>>>> 70. inDegree (node)
>>>>>> 71. arity (tree)
>>>>>> 72. baseTypes (fsDecl)
>>>>>> 73. level (sense)
>>>>>> 74. order (tree)
>>>>>> 75. outDegree (iNode)
>>>>>> 76. outDegree (node)
>>>>>> 77. outDegree (root)
>>>>>> 78. reason (gap)
>>>>>> 79. type (orth)
>>>>>> 80. when (docDate)
>>>>>> 81. split (att.lexicographic)
>>>>>> 82. code (socecStatus)
>>>>>> 83. code (occupation)
>>>>>> 84. decls (att.declaring)
>>>>>> 85. cRef (term)
>>>>>> 86. from (app)
>>>>>> 87. scheme (catRef)
>>>>>> 88. scheme (occupation)
>>>>>> 89. scheme (classCode)
>>>>>> 90. scheme (socecStatus)
>>>>>> 91. scheme (keywords)
>>>>>> 92. to (app)
>>>>>> 93. baseForm (m)
>>>>>> 94. new (handShift)
>>>>>> 95. passive (relation)
>>>>>> 96. since (when)
>>>>>> 97. type (fsdLink)
>>>>>> 98. type (biblScope)
>>>>>> 99. type (listForest)
>>>>>> 100. type (forest)
>>>>>> 101. hand (gap)
>>>>>> 102. given (certainty)
>>>>>> 103. locus (certainty)
>>>>>> 104. type (rs)
>>>>>> 105. source (normalization)
>>>>>> 106. level (title)
>>>>>> 107. degree (certainty)
>>>>>> 108. status (correction)
>>>>>> 109. degree (precision)
>>>>>> 110. spanTo (att.spanning)
>>>>>> 111. to (att.datable.w3c)
>>>>>> 112. to-iso (att.datable.iso)
>>>>>> 113. force (pc)
>>>>>> 114. reason (surplus)
>>>>>> 115. type (stage)
>>>>>> 116. type (oRef)
>>>>>> 117. type (oVar)
>>>>>> 118. method (correction)
>>>>>> 119. method (normalization)
>>>>>> 120. name (fDecl)
>>>>>> 121. evidence (att.editLike)
>>>>>> 122. rows (table)
>>>>>> 123. org (vMerge)
>>>>>> 124. who (att.ascribed)
>>>>>> 125. locus (respons)
>>>>>> 126. from-custom (att.datable.custom)
>>>>>> 127. from (att.datable.w3c)
>>>>>> 128. from-iso (att.datable.iso)
>>>>>> 129. type (xr)
>>>>>> 130. type (iType)
>>>>>> 131. type (num)
>>>>>> 132. type (att.entryLike)
>>>>>> 133. type (att.interpLike)
>>>>>> 134. unit (refState)
>>>>>> 135. notation (pron)
>>>>>> 136. break (att.breaking)
>>>>>> 137. iterated (kinesic)
>>>>>> 138. iterated (vocal)
>>>>>> 139. optional (fDecl)
>>>>>> 140. default (att.declarable)
>>>>>> 141. location (variantEncoding)
>>>>>> 142. anchored (note)
>>>>>> 143. full (att.personal)
>>>>>> 144. type (metDecl)
>>>>>> 145. extent (pron)
>>>>>> 146. discrete (sound)
>>>>>> 147. scope (join)
>>>>>> 148. gradual (writing)
>>>>>> 149. sample (att.divLike)
>>>>>> 150. type (classSpec)
>>>>>> 151. pre (pc)
>>>>>> 152. type (dimensions)
>>>>>> 153. method (variantEncoding)
>>>>>> 154. type (macroSpec)
>>>>>> 155. reason (supplied)
>>>>>> 156. to (locus)
>>>>>> 157. rows (att.tableDecoration)
>>>>>> 158. writtenLines (layout)
>>>>>> 159. ruledLines (layout)
>>>>>> 160. location (att.lexicographic)
>>>>>> 161. hands (handDesc)
>>>>>> 162. material (supportDesc)
>>>>>> 163. notation (formula)
>>>>>> 164. unit (att.dimensions)
>>>>>> 165. ns (attDef)
>>>>>> 166. ns (elementSpec)
>>>>>> 167. domains (att.pointing.group)
>>>>>> 168. part (att.segLike)
>>>>>> 169. source (writing)
>>>>>> 170. ref (g)
>>>>>> 171. scribeRef (att.handFeatures)
>>>>>> 172. scriptRef (att.handFeatures)
>>>>>> 173. copyOf (att.global.linking)
>>>>>> 174. sameAs (att.global.linking)
>>>>>> 175. exclude (att.global.linking)
>>>>>> 176. targetEnd (note)
>>>>>> 177. next (att.global.linking)
>>>>>> 178. target (relatedItem)
>>>>>> 179. unit (milestone)
>>>>>> 180. label (rhyme)
>>>>>> 181. lemma (w)
>>>>>> 182. children (iNode)
>>>>>> 183. children (root)
>>>>>> 184. name (f)
>>>>>> 185. unit (pc)
>>>>>> 186. value (leaf)
>>>>>> 187. type (node)
>>>>>> 188. key (att.canonical)
>>>>>> 189. follow (iNode)
>>>>>> 190. follow (leaf)
>>>>>> 191. parent (leaf)
>>>>>> 192. parent (iNode)
>>>>>> 193. value (node)
>>>>>> 194. value (triangle)
>>>>>> 195. value (eLeaf)
>>>>>> 196. value (eTree)
>>>>>> 197. value (iNode)
>>>>>> 198. value (root)
>>>>>> 199. quantity (att.measurement)
>>>>>> 200. role (att.tableDecoration)
>>>>>> 201. scheme (att)
>>>>>> 202. select (att.global.linking)
>>>>>> 203. xml:space (att.global)
>>>>>> 204. hand (att.textCritical)
>>>>>> 205. subtype (att.typed)
>>>>>> 206. prefix (schemaSpec)
>>>>>> 207. prefix (elementSpec)
>>>>>> 208. type (purpose)
>>>>>> 209. role (org)
>>>>>> 210. role (person)
>>>>>> 211. matchPattern (cRefPattern)
>>>>>> 212. replacementPattern (cRefPattern)
>>>>>> 213. age (person)
>>>>>> 214. start (schemaSpec)
>>>>>> 215. form (quotation)
>>>>>> 216. time (distinct)
>>>>>> 217. social (distinct)
>>>>>> 218. space (distinct)
>>>>>> 219. type (constitution)
>>>>>> 220. scope (att.handFeatures)
>>>>>> 221. age (personGrp)
>>>>>> 222. usage (language)
>>>>>> 223. ident (valItem)
>>>>>> 224. from (span)
>>>>>> 225. value (metSym)
>>>>>> 226. versionDate (att.translatable)
>>>>>> 227. target (att.pointing)
>>>>>> 228. where (move)
>>>>>> 229. notBefore (att.datable.w3c)
>>>>>> 230. notBefore-custom (att.datable.custom)
>>>>>> 231. notBefore-iso (att.datable.iso)
>>>>>> 232. mode (classes)
>>>>>> 233. mode (att.combinable)
>>>>>> 234. mode (memberOf)
>>>>>> 235. to (span)
>>>>>> 236. to (biblScope)
>>>>>> 237. type (valList)
>>>>>> 238. degree (purpose)
>>>>>> 239. length (refState)
>>>>>> 240. render (tagUsage)
>>>>>> 241. targets (alt)
>>>>>> 242. targets (join)
>>>>>> 243. targets (link)
>>>>>> 244. type (teiHeader)
>>>>>> 245. notAfter (att.datable.w3c)
>>>>>> 246. notAfter-custom (att.datable.custom)
>>>>>> 247. notAfter-iso (att.datable.iso)
>>>>>> 248. version (TEI)
>>>>>> 249. mode (channel)
>>>>>> 250. result (join)
>>>>>> 251. new (shift)
>>>>>> 252. active (interaction)
>>>>>> 253. occurs (tagUsage)
>>>>>> 254. passive (interaction)
>>>>>> 255. interval (when)
>>>>>> 256. interval (timeline)
>>>>>> 257. usage (attDef)
>>>>>> 258. role (personGrp)
>>>>>> 259. type (titlePart)
>>>>>> 260. sex (personGrp)
>>>>>> 261. sex (person)
>>>>>> 262. size (personGrp)
>>>>>> 263. from (biblScope)
>>>>>> 264. type (distinct)
>>>>>> 265. type (measure)
>>>>>> 266. type (fs)
>>>>>> 267. unit (timeline)
>>>>>> 268. unit (when)
>>>>>> 269. version (unicodeName)
>>>>>> 270. type (divGen)
>>>>>> 271. part (ab)
>>>>>> 272. part (att.divLike)
>>>>>> 273. part (l)
>>>>>> 274. terminal (metSym)
>>>>>> 275. trunc (numeric)
>>>>>> 276. order (graph)
>>>>>> 277. size (graph)
>>>>>> 278. mode (alt)
>>>>>> 279. mode (altGrp)
>>>>>> 280. value (binary)
>>>>>> 281. status (availability)
>>>>>> 282. datum (geoDecl)
>>>>>> 283. value (numeric)
>>>>>> 284. name (relation)
>>>>>> 285. name (vLabel)
>>>>>> 286. indexName (index)
>>>>>> 287. stdDeviation (precision)
>>>>>> 288. absolute (when)
>>>>>> 289. max (numeric)
>>>>>> 290. scheme (constraintSpec)
>>>>>> 291. scheme (tag)
>>>>>> 292. scheme (gi)
>>>>>> 293. value (symbol)
>>>>>> 294. value (num)
>>>>>> 295. scheme (locusGrp)
>>>>>> 296. scheme (locus)
>>>>>> 297. name (namespace)
>>>>>> 298. type (recording)
>>>>>> 299. unit (att.measurement)
>>>>>> 300. value (att.lexicographic)
>>>>>> 301. scope (att.dimensions)
>>>>>> 302. evaluate (att.pointing)
>>>>>> 303. active (relation)
>>>>>> 304. to-custom (att.datable.custom)
>>>>>> 305. mutual (relation)
>>>>>> 306. dur-iso (att.duration.iso)
>>>>>> 307. instant (att.editLike)
>>>>>> 308. function (metamark)
>>>>>> 309. attachment (surface)
>>>>>> 310. cause (att.transcriptional)
>>>>>> 311. target (metamark)
>>>>>> 312. rotate (zone)
>>>>>> 313. target (redo)
>>>>>> 314. target (undo)
>>>>>> 315. except (moduleRef)
>>>>>> 316. include (moduleRef)
>>>>>> 317. datingMethod (att.datable.custom)
>>>>>> 318. datingPoint (att.datable.custom)
>>>>>> 319. key (moduleRef)
>>>>>> 320. url (moduleRef)
>>>>>> 321. mimeType (att.internetMedia)
>>>>>> 322. version (application)
>>>>>> 323. ident (application)
>>>>>> 324. confidence (att.ranging)
>>>>>> 325. level (langKnown)
>>>>>> 326. adj (node)
>>>>>> 327. adjFrom (node)
>>>>>> 328. adjTo (node)
>>>>>> 329. ana (att.global.analytic)
>>>>>> 330. group (att.damaged)
>>>>>> 331. cRef (gloss)
>>>>>> 332. cRef (ptr)
>>>>>> 333. cRef (ref)
>>>>>> 334. cert (att.responsibility)
>>>>>> 335. cert (certainty)
>>>>>> 336. precision (precision)
>>>>>> 337. precision (att.dimensions)
>>>>>> 338. type (fw)
>>>>>> 339. cols (table)
>>>>>> 340. cols (att.tableDecoration)
>>>>>> 341. source (att.editLike)
>>>>>> 342. autoPrefix (content)
>>>>>> 343. corresp (att.global.linking)
>>>>>> 344. delim (refState)
>>>>>> 345. dim (space)
>>>>>> 346. docLang (schemaSpec)
>>>>>> 347. dur (att.duration.w3c)
>>>>>> 348. ed (att.sourced)
>>>>>> 349. gi (tagUsage)
>>>>>> 350. eol (hyphenation)
>>>>>> 351. enjamb (att.enjamb)
>>>>>> 352. facs (att.global.facs)
>>>>>> 353. fVal (f)
>>>>>> 354. feats (fs)
>>>>>> 355. lang (code)
>>>>>> 356. atMost (att.ranging)
>>>>>> 357. atLeast (att.ranging)
>>>>>> 358. lrx (att.coordinated)
>>>>>> 359. ulx (att.coordinated)
>>>>>> 360. lry (att.coordinated)
>>>>>> 361. uly (att.coordinated)
>>>>>> 362. xml:id (att.global)
>>>>>> 363. ident (language)
>>>>>> 364. scheme (rendition)
>>>>>> 365. status (att.transcriptional)
>>>>>> 366. where (event)
>>>>>> 367. start (att.timed)
>>>>>> 368. end (att.timed)
>>>>>> 369. type (tag)
>>>>>> 370. defective (att.msExcerpt)
>>>>>> 371. generate (classSpec)
>>>>>> 372. inst (att.interpLike)
>>>>>> 373. xml:lang (att.global)
>>>>>> 374. loc (app)
>>>>>> 375. mainLang (textLang)
>>>>>> 376. maxOccurs (datatype)
>>>>>> 377. type (q)
>>>>>> 378. direct (said)
>>>>>> 379. aloud (said)
>>>>>> 380. met (att.metrical)
>>>>>> 381. real (att.metrical)
>>>>>> 382. minOccurs (datatype)
>>>>>> 383. name (equiv)
>>>>>> 384. ns (schemaSpec)
>>>>>> 385. n (att.global)
>>>>>> 386. opt (att.lexicographic)
>>>>>> 387. ord (iNode)
>>>>>> 388. ord (root)
>>>>>> 389. ord (tree)
>>>>>> 390. sort (att.personal)
>>>>>> 391. org (attList)
>>>>>> 392. org (vColl)
>>>>>> 393. org (att.divLike)
>>>>>> 394. orig (att.lexicographic)
>>>>>> 395. otherLangs (textLang)
>>>>>> 396. perf (move)
>>>>>> 397. perf (tech)
>>>>>> 398. target (specGrpRef)
>>>>>> 399. parts (nym)
>>>>>> 400. change (att.global.change)
>>>>>> 401. target (change)
>>>>>> 402. prev (att.global.linking)
>>>>>> 403. lemmaRef (w)
>>>>>> 404. marks (quotation)
>>>>>> 405. ref (att.canonical)
>>>>>> 406. nymRef (att.naming)
>>>>>> 407. filter (equiv)
>>>>>> 408. pattern (metDecl)
>>>>>> 409. resp (respons)
>>>>>> 410. resp (att.responsibility)
>>>>>> 411. resp (space)
>>>>>> 412. rhyme (att.metrical)
>>>>>> 413. seq (att.transcriptional)
>>>>>> 414. hand (att.transcriptional)
>>>>>> 415. prefix (moduleRef)
>>>>>> 416. key (memberOf)
>>>>>> 417. quantity (att.dimensions)
>>>>>> 418. value (age)
>>>>>> 419. target (fsdLink)
>>>>>> 420. period (att.datable)
>>>>>> 421. tag (langKnown)
>>>>>> 422. tags (langKnowledge)
>>>>>> 423. max (memberOf)
>>>>>> 424. min (memberOf)
>>>>>> 425. synch (att.global.linking)
>>>>>> 426. targFunc (att.pointing.group)
>>>>>> 427. targetLang (schemaSpec)
>>>>>> 428. key (classRef)
>>>>>> 429. key (elementRef)
>>>>>> 430. key (macroRef)
>>>>>> 431. name (attRef)
>>>>>> 432. trans (u)
>>>>>> 433. uri (equiv)
>>>>>> 434. url (graphic)
>>>>>> 435. varSeq (att.textCritical)
>>>>>> 436. scope (rendition)
>>>>>> 437. max (att.ranging)
>>>>>> 438. min (att.ranging)
>>>>>> 439. withId (tagUsage)
>>>>>> 440. wit (att.witnessed)
>>>>>> 441. wit (att.rdgPart)
>>>>>> 442. wit (witDetail)
>>>>>> 443. status (att.docStatus)
>>>>>> 444. points (zone)
>>>>>> 445. start (att.coordinated)
>>>>>> 446. valid (egXML)
>>>>>> 447. ordered (listChange)
>>>>>> 448. role (att.naming)
>>>>>> 449. source (att.readFrom)
>>>>>> 450. flipping (surface)
>>>>>>
>>>>>>
>>>>>> ATTRIBUTE DEFINITIONS WHICH HAVE EXAMPLES AS OF
>>>>>> 2012-04-19T15:12:34.968-07:00
>>>>>>
>>>>>> 1. place (att.placement)
>>>>>> 2. expand (att.lexicographic)
>>>>>> 3. extent (att.dimensions)
>>>>>> 4. calendar (att.datable)
>>>>>> 5. reason (unclear)
>>>>>> 6. target (att.scoping)
>>>>>> 7. xml:base (att.global)
>>>>>> 8. assertedValue (certainty)
>>>>>> 9. refLang (att.pointing)
>>>>>> 10. match (att.scoping)
>>>>>> 11. sortKey (att.sortable)
>>>>>> 12. atts (specDesc)
>>>>>> 13. key (specDesc)
>>>>>> 14. norm (att.lexicographic)
>>>>>> 15. rendition (att.global)
>>>>>> 16. rend (att.global)
>>>>>> 17. when-iso (att.datable.iso)
>>>>>> 18. when-custom (att.datable.custom)
>>>>>> 19. when (att.datable.w3c)
>>>>>>
>>>>>> --
>>>>>> Martin Holmes
>>>>>> University of Victoria Humanities Computing and Media Centre
>>>>>> (mholmes at uvic.ca)
>>>>>> --
>>>>>> tei-council mailing list
>>>>>> tei-council at lists.village.Virginia.EDU
>>>>>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>>>>>>
>>>>>> PLEASE NOTE: postings to this list are publicly archived
>>>>>> .
>>>>>>
>>>>>
>>>> .
>>>>
>>>
>>
>>
>> --
>> Dr James Cummings, InfoDev,
>> Computing Services, University of Oxford
>> --
>> tei-council mailing list
>> tei-council at lists.village.Virginia.EDU
>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>>
>> PLEASE NOTE: postings to this list are publicly archived
>> .
>>
>
> --
> Martin Holmes
> University of Victoria Humanities Computing and Media Centre
> (mholmes at uvic.ca)
> --
> tei-council mailing list
> tei-council at lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>
> PLEASE NOTE: postings to this list are publicly archived
> .
>

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From gabriel.bodard at kcl.ac.uk  Mon Apr 23 13:35:13 2012
From: gabriel.bodard at kcl.ac.uk (Gabriel BODARD)
Date: Mon, 23 Apr 2012 18:35:13 +0100
Subject: [tei-council] next release?
In-Reply-To: <4F9579A0.8010002@oucs.ox.ac.uk>
References: <0F18A249-5480-42D9-BFF2-538AC7B9E1EB@oucs.ox.ac.uk>
	<4F92F34D.2040103@uvic.ca> <4F9579A0.8010002@oucs.ox.ac.uk>
Message-ID: <4F9592D1.30207@kcl.ac.uk>

In terms of doing the release tech, I guess I need to put aside at least 
a day to work through this, and it doesn't matter much to me when that 
day is, so that's fine.

I'm now just trying to remember if there were any tickets assigned to me 
in the meantime, and if I'll have time to complete them by May 20. I was 
going to look into the guidelines-wide impact of something, but I don't 
recall exactly what. Did someone add a note to the ticket in question? 
(And in what may be the answer to the same or may be a completely 
unrelated question, could someone update http://purl.com/tei/fr/3416130 
with the current state of Council thinking after Ann Arbor, please?)

(Incidentally, I think http://purl.com/TEI/BUGS/3496949 has been 
erroneously assigned to me--I don't think I know what we're meant to do 
with this.)

Gabby

On 23/04/2012 16:47, James Cummings wrote:
>
> How about we set a notional target release date of 25 May?  (This
> is about 5 weeks from now.) If we assume that we want most things
> completed by the end of Sunday 20th, to allow time for
> proofreading and error spotting.
>
> Does that sounds reasonable to most people?
>
> Gaby: Most importantly, does the proposed Release Technician like
> these dates?
>
> -James
>
>
> On 21/04/12 18:50, Martin Holmes wrote:
>> Three weeks will be a bit tough for me, and a couple of the tickets I
>> have might turn out to have unpredicted side-effects (like the tei_
>> prefix). As long as we have the option to launch without the change if
>> it proves difficult, we could go with three weeks.
>>
>> The attributes-without-examples problem is so large that we'll just have
>> to hack away at it steadily.
>>
>> Cheers,
>> Martin
>>
>> On 12-04-21 04:03 AM, Sebastian Rahtz wrote:
>>> something we forgot to debate in Ann Arbor was a timetable
>>> for the next release, I think? i.e. what is the due date for
>>> everyone to complete their ticket work so that Sir Gabriel
>>> of B'odard can undertake his Quest.
>>>
>>> speaking for myself, if I don't do my assignments
>>> more or less immediately I will not get to them for ages,
>>> so I favour a short window (say, 3 weeks).
>>>
>>> Sebastian
>
>

-- 
Dr Gabriel BODARD
(Research Associate in Digital Epigraphy)

Department of Digital Humanities
King's College London
26-29 Drury Lane
London WC2B 5RL

Email: gabriel.bodard at kcl.ac.uk
Tel: +44 (0)20 7848 1388
Fax: +44 (0)20 7848 2980

http://www.digitalclassicist.org/
http://www.currentepigraphy.org/

From kevin.s.hawkins at ultraslavonic.info  Mon Apr 23 13:38:53 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Mon, 23 Apr 2012 13:38:53 -0400
Subject: [tei-council] next release?
In-Reply-To: <4F9592D1.30207@kcl.ac.uk>
References: <0F18A249-5480-42D9-BFF2-538AC7B9E1EB@oucs.ox.ac.uk>	<4F92F34D.2040103@uvic.ca>
	<4F9579A0.8010002@oucs.ox.ac.uk> <4F9592D1.30207@kcl.ac.uk>
Message-ID: <4F9593AD.2000403@ultraslavonic.info>

Whereas in past meetings Lou and/or others would add comments to tickets 
directly as we discussed them, at this meeting we generally recorded 
decisions only in the minutes (which are in a Google Docs file that 
Becky shared a week ago).  So you have to look for your initials to find 
any tasks assigned to you and then see what the decision reached was.

On 4/23/2012 1:35 PM, Gabriel BODARD wrote:
> In terms of doing the release tech, I guess I need to put aside at least
> a day to work through this, and it doesn't matter much to me when that
> day is, so that's fine.
>
> I'm now just trying to remember if there were any tickets assigned to me
> in the meantime, and if I'll have time to complete them by May 20. I was
> going to look into the guidelines-wide impact of something, but I don't
> recall exactly what. Did someone add a note to the ticket in question?
> (And in what may be the answer to the same or may be a completely
> unrelated question, could someone update http://purl.com/tei/fr/3416130
> with the current state of Council thinking after Ann Arbor, please?)
>
> (Incidentally, I think http://purl.com/TEI/BUGS/3496949 has been
> erroneously assigned to me--I don't think I know what we're meant to do
> with this.)
>
> Gabby
>
> On 23/04/2012 16:47, James Cummings wrote:
>>
>> How about we set a notional target release date of 25 May?  (This
>> is about 5 weeks from now.) If we assume that we want most things
>> completed by the end of Sunday 20th, to allow time for
>> proofreading and error spotting.
>>
>> Does that sounds reasonable to most people?
>>
>> Gaby: Most importantly, does the proposed Release Technician like
>> these dates?
>>
>> -James
>>
>>
>> On 21/04/12 18:50, Martin Holmes wrote:
>>> Three weeks will be a bit tough for me, and a couple of the tickets I
>>> have might turn out to have unpredicted side-effects (like the tei_
>>> prefix). As long as we have the option to launch without the change if
>>> it proves difficult, we could go with three weeks.
>>>
>>> The attributes-without-examples problem is so large that we'll just have
>>> to hack away at it steadily.
>>>
>>> Cheers,
>>> Martin
>>>
>>> On 12-04-21 04:03 AM, Sebastian Rahtz wrote:
>>>> something we forgot to debate in Ann Arbor was a timetable
>>>> for the next release, I think? i.e. what is the due date for
>>>> everyone to complete their ticket work so that Sir Gabriel
>>>> of B'odard can undertake his Quest.
>>>>
>>>> speaking for myself, if I don't do my assignments
>>>> more or less immediately I will not get to them for ages,
>>>> so I favour a short window (say, 3 weeks).
>>>>
>>>> Sebastian
>>
>>
>

From mholmes at uvic.ca  Mon Apr 23 14:18:01 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Mon, 23 Apr 2012 11:18:01 -0700
Subject: [tei-council] next release?
In-Reply-To: <4F9593AD.2000403@ultraslavonic.info>
References: <0F18A249-5480-42D9-BFF2-538AC7B9E1EB@oucs.ox.ac.uk>
	<4F92F34D.2040103@uvic.ca>	<4F9579A0.8010002@oucs.ox.ac.uk>
	<4F9592D1.30207@kcl.ac.uk> <4F9593AD.2000403@ultraslavonic.info>
Message-ID: <4F959CD9.8020201@uvic.ca>

 >> (Incidentally, I think http://purl.com/TEI/BUGS/3496949 has been
 >> erroneously assigned to me--I don't think I know what we're meant to do
 >> with this.)

IIRC, we (James, Lou and I) assigned it to you because we thought you 
would have a good knowledge of the topic and clear views on it. Also 
because you weren't there to object, of course.

Lou's comment, I think, records what we felt should be done:

"Agreed to revise and expand example: firstly, use a straightforward
witness; secondly add an example for the "unattested" case."

Cheers,
Martin

On 12-04-23 10:38 AM, Kevin Hawkins wrote:
> Whereas in past meetings Lou and/or others would add comments to tickets
> directly as we discussed them, at this meeting we generally recorded
> decisions only in the minutes (which are in a Google Docs file that
> Becky shared a week ago).  So you have to look for your initials to find
> any tasks assigned to you and then see what the decision reached was.
>
> On 4/23/2012 1:35 PM, Gabriel BODARD wrote:
>> In terms of doing the release tech, I guess I need to put aside at least
>> a day to work through this, and it doesn't matter much to me when that
>> day is, so that's fine.
>>
>> I'm now just trying to remember if there were any tickets assigned to me
>> in the meantime, and if I'll have time to complete them by May 20. I was
>> going to look into the guidelines-wide impact of something, but I don't
>> recall exactly what. Did someone add a note to the ticket in question?
>> (And in what may be the answer to the same or may be a completely
>> unrelated question, could someone update http://purl.com/tei/fr/3416130
>> with the current state of Council thinking after Ann Arbor, please?)
>>
>> (Incidentally, I think http://purl.com/TEI/BUGS/3496949 has been
>> erroneously assigned to me--I don't think I know what we're meant to do
>> with this.)
>>
>> Gabby
>>
>> On 23/04/2012 16:47, James Cummings wrote:
>>>
>>> How about we set a notional target release date of 25 May?  (This
>>> is about 5 weeks from now.) If we assume that we want most things
>>> completed by the end of Sunday 20th, to allow time for
>>> proofreading and error spotting.
>>>
>>> Does that sounds reasonable to most people?
>>>
>>> Gaby: Most importantly, does the proposed Release Technician like
>>> these dates?
>>>
>>> -James
>>>
>>>
>>> On 21/04/12 18:50, Martin Holmes wrote:
>>>> Three weeks will be a bit tough for me, and a couple of the tickets I
>>>> have might turn out to have unpredicted side-effects (like the tei_
>>>> prefix). As long as we have the option to launch without the change if
>>>> it proves difficult, we could go with three weeks.
>>>>
>>>> The attributes-without-examples problem is so large that we'll just have
>>>> to hack away at it steadily.
>>>>
>>>> Cheers,
>>>> Martin
>>>>
>>>> On 12-04-21 04:03 AM, Sebastian Rahtz wrote:
>>>>> something we forgot to debate in Ann Arbor was a timetable
>>>>> for the next release, I think? i.e. what is the due date for
>>>>> everyone to complete their ticket work so that Sir Gabriel
>>>>> of B'odard can undertake his Quest.
>>>>>
>>>>> speaking for myself, if I don't do my assignments
>>>>> more or less immediately I will not get to them for ages,
>>>>> so I favour a short window (say, 3 weeks).
>>>>>
>>>>> Sebastian
>>>
>>>
>>

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From mholmes at uvic.ca  Mon Apr 23 14:48:15 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Mon, 23 Apr 2012 11:48:15 -0700
Subject: [tei-council] Prefacing ids with "tei_"
Message-ID: <4F95A3EF.7030509@uvic.ca>

I'm planning to make a significant number of changes to Sebastian's 
stylesheets to implement our decision to preface all ids in the web 
output with "tei_", in an effort to avoid the problems caused by AdBlock 
Plus. Before I do, having looked at the code, there are a couple of 
things I wanted to get some feedback on:

1. Generated ids. There are some places in which ids in the output are 
generated using the XPath generate-id() function:

	<xsl:call-template name="makeAnchor">
             <xsl:with-param name="name">
               <xsl:value-of select="generate-id()"/>
             </xsl:with-param>
           </xsl:call-template>

These result in ids that look like random sequences of characters. Do we 
need to preface these with "tei_"? My instinct says yes -- after all, 
such a random sequence is perfectly likely to end up with content which 
might trigger an AdBlock filter, so we might as well protect it in the 
normal way.

2. @n attributes. There's one place where the @n attribute can be used 
to create an id attribute in the output (in textstructure.xsl, code 
below). Should this also be prefaced by "tei_"? I'm not sure about this, 
because depending on the contents of the @n, the result might be 
puzzling. On the other hand, I don't think that @n can be relied upon to 
work as an id attribute anyway, can it?

<xsl:variable name="identifier">
          <xsl:text>App</xsl:text>
          <xsl:choose>
	   <xsl:when test="@xml:id">
	     <xsl:value-of select="@xml:id"/>
	   </xsl:when>
	   <xsl:when test="@n">
	     <xsl:value-of select="@n"/>
	   </xsl:when>
	   <xsl:otherwise>
	     <xsl:number count="tei:app" level="any"/>
	   </xsl:otherwise>
          </xsl:choose>
       </xsl:variable>

       <xsl:choose>
        <xsl:when test="$footnoteFile='true'">
	 <a class="notelink" href="{$masterFile}-notes.html#{$identifier}">
	   <sup>
	     <xsl:call-template name="appN"/>
	   </sup>
	 </a>
        </xsl:when>
        <xsl:otherwise>
	 <a class="notelink" href="#{$identifier}">
	   <sup>
	     <xsl:call-template name="appN"/>
	   </sup>
	 </a>
        </xsl:otherwise>
       </xsl:choose>

Cheers,
Martin
-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From bansp at o2.pl  Mon Apr 23 17:15:21 2012
From: bansp at o2.pl (=?ISO-8859-2?Q?Piotr_Ba=F1ski?=)
Date: Mon, 23 Apr 2012 23:15:21 +0200
Subject: [tei-council] Prefacing ids with "tei_"
In-Reply-To: <4F95A3EF.7030509@uvic.ca>
References: <4F95A3EF.7030509@uvic.ca>
Message-ID: <4F95C669.7040709@o2.pl>

Hi Martin,

This may be a classic case of my missing the point, but something
doesn't click in my mind, so I'd better comment on that, just in case:

On 23/04/12 20:48, Martin Holmes wrote:
> I'm planning to make a significant number of changes to Sebastian's 
> stylesheets to implement our decision to preface all ids in the web 
> output with "tei_", in an effort to avoid the problems caused by AdBlock 
> Plus. Before I do, having looked at the code, there are a couple of 
> things I wanted to get some feedback on:
> 
> 1. Generated ids. There are some places in which ids in the output are 
> generated using the XPath generate-id() function:
[..]
> These result in ids that look like random sequences of characters. Do we 
> need to preface these with "tei_"? My instinct says yes -- after all, 
> such a random sequence is perfectly likely to end up with content which 
> might trigger an AdBlock filter, so we might as well protect it in the 
> normal way.

I understood that "msad" triggered the false positive, and the (arguable
and, IIRC, argued) decision was for the TEI to adjust to AdBlock.

But if the problem was the matching of the entire string "msad" only (as
opposed to "tei_msad"), then i am led to conclude that a substring match
does not trigger the false positive. If that is true, then
generated-ids() can't within reasonable probability generate an
offensive string, and only that string (without extra characters).

As to your second question, I'd say the prefix introduces a layer of
safety indeed. But I'm not sure to what extent we as the Council need to
bother of someone using silly @n atts as the basis for a silly algorithm
of @n->@id. We might end up being overprotective here.

Best,

  P.



> 
> 2. @n attributes. There's one place where the @n attribute can be used 
> to create an id attribute in the output (in textstructure.xsl, code 
> below). Should this also be prefaced by "tei_"? I'm not sure about this, 
> because depending on the contents of the @n, the result might be 
> puzzling. On the other hand, I don't think that @n can be relied upon to 
> work as an id attribute anyway, can it?
> 
> <xsl:variable name="identifier">
>           <xsl:text>App</xsl:text>
>           <xsl:choose>
> 	   <xsl:when test="@xml:id">
> 	     <xsl:value-of select="@xml:id"/>
> 	   </xsl:when>
> 	   <xsl:when test="@n">
> 	     <xsl:value-of select="@n"/>
> 	   </xsl:when>
> 	   <xsl:otherwise>
> 	     <xsl:number count="tei:app" level="any"/>
> 	   </xsl:otherwise>
>           </xsl:choose>
>        </xsl:variable>
> 
>        <xsl:choose>
>         <xsl:when test="$footnoteFile='true'">
> 	 <a class="notelink" href="{$masterFile}-notes.html#{$identifier}">
> 	   <sup>
> 	     <xsl:call-template name="appN"/>
> 	   </sup>
> 	 </a>
>         </xsl:when>
>         <xsl:otherwise>
> 	 <a class="notelink" href="#{$identifier}">
> 	   <sup>
> 	     <xsl:call-template name="appN"/>
> 	   </sup>
> 	 </a>
>         </xsl:otherwise>
>        </xsl:choose>
> 
> Cheers,
> Martin


From bansp at o2.pl  Mon Apr 23 17:20:33 2012
From: bansp at o2.pl (=?ISO-8859-2?Q?Piotr_Ba=F1ski?=)
Date: Mon, 23 Apr 2012 23:20:33 +0200
Subject: [tei-council] next release?
In-Reply-To: <4F9579A0.8010002@oucs.ox.ac.uk>
References: <0F18A249-5480-42D9-BFF2-538AC7B9E1EB@oucs.ox.ac.uk>	<4F92F34D.2040103@uvic.ca>
	<4F9579A0.8010002@oucs.ox.ac.uk>
Message-ID: <4F95C7A1.1080707@o2.pl>

Hi James,

Isn't May 25 roughly in the middle of LREC? Could we shift by a week
from then, please?

(I actually intend to be ready with my stuff [and possibly more] in
advance this time, but I've made some such totally honest promises to
myself and to the world recently, several times, and with meager results...)

Ah. Will we telco before releasing?

Best,

  P.



On 23/04/12 17:47, James Cummings wrote:
> 
> How about we set a notional target release date of 25 May?  (This 
> is about 5 weeks from now.) If we assume that we want most things 
> completed by the end of Sunday 20th, to allow time for 
> proofreading and error spotting.
> 
> Does that sounds reasonable to most people?
> 
> Gaby: Most importantly, does the proposed Release Technician like 
> these dates?
> 
> -James
> 
> 
> On 21/04/12 18:50, Martin Holmes wrote:
>> Three weeks will be a bit tough for me, and a couple of the tickets I
>> have might turn out to have unpredicted side-effects (like the tei_
>> prefix). As long as we have the option to launch without the change if
>> it proves difficult, we could go with three weeks.
>>
>> The attributes-without-examples problem is so large that we'll just have
>> to hack away at it steadily.
>>
>> Cheers,
>> Martin
>>
>> On 12-04-21 04:03 AM, Sebastian Rahtz wrote:
>>> something we forgot to debate in Ann Arbor was a timetable
>>> for the next release, I think? i.e. what is the due date for
>>> everyone to complete their ticket work so that Sir Gabriel
>>> of B'odard can undertake his Quest.
>>>
>>> speaking for myself, if I don't do my assignments
>>> more or less immediately I will not get to them for ages,
>>> so I favour a short window (say, 3 weeks).
>>>
>>> Sebastian
> 
> 


From mholmes at uvic.ca  Mon Apr 23 17:43:46 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Mon, 23 Apr 2012 14:43:46 -0700
Subject: [tei-council] Prefacing ids with "tei_"
In-Reply-To: <4F95C669.7040709@o2.pl>
References: <4F95A3EF.7030509@uvic.ca> <4F95C669.7040709@o2.pl>
Message-ID: <4F95CD12.9070904@uvic.ca>

On 12-04-23 02:15 PM, Piotr Ba?ski wrote:
> Hi Martin,
>
> This may be a classic case of my missing the point, but something
> doesn't click in my mind, so I'd better comment on that, just in case:
>
> On 23/04/12 20:48, Martin Holmes wrote:
>> I'm planning to make a significant number of changes to Sebastian's
>> stylesheets to implement our decision to preface all ids in the web
>> output with "tei_", in an effort to avoid the problems caused by AdBlock
>> Plus. Before I do, having looked at the code, there are a couple of
>> things I wanted to get some feedback on:
>>
>> 1. Generated ids. There are some places in which ids in the output are
>> generated using the XPath generate-id() function:
> [..]
>> These result in ids that look like random sequences of characters. Do we
>> need to preface these with "tei_"? My instinct says yes -- after all,
>> such a random sequence is perfectly likely to end up with content which
>> might trigger an AdBlock filter, so we might as well protect it in the
>> normal way.
>
> I understood that "msad" triggered the false positive, and the (arguable
> and, IIRC, argued) decision was for the TEI to adjust to AdBlock.

Yes, the false positive was triggered by "msad".

> But if the problem was the matching of the entire string "msad" only (as
> opposed to "tei_msad"), then i am led to conclude that a substring match
> does not trigger the false positive. If that is true, then
> generated-ids() can't within reasonable probability generate an
> offensive string, and only that string (without extra characters).

It is possible to use regular expressions in Adblock Plus lists, so 
partial matches may trigger a block. If this happens, one advantage of 
our tei_ prefix will be that we can ask filter list writers to refine 
their regexp to exclude our ids, using the prefix, while still remaining 
able to block their original target. I think given that option, they'll 
be more likely to respond to bug reports from us.

> As to your second question, I'd say the prefix introduces a layer of
> safety indeed. But I'm not sure to what extent we as the Council need to
> bother of someone using silly @n atts as the basis for a silly algorithm
> of @n->@id. We might end up being overprotective here.

True. On consideration, I think we should add the prefix in all cases, 
for the sake of consistency.

Cheers,
Martin

> Best,
>
>    P.
>
>
>
>>
>> 2. @n attributes. There's one place where the @n attribute can be used
>> to create an id attribute in the output (in textstructure.xsl, code
>> below). Should this also be prefaced by "tei_"? I'm not sure about this,
>> because depending on the contents of the @n, the result might be
>> puzzling. On the other hand, I don't think that @n can be relied upon to
>> work as an id attribute anyway, can it?
>>
>> <xsl:variable name="identifier">
>>            <xsl:text>App</xsl:text>
>>            <xsl:choose>
>> 	<xsl:when test="@xml:id">
>> 	<xsl:value-of select="@xml:id"/>
>> 	</xsl:when>
>> 	<xsl:when test="@n">
>> 	<xsl:value-of select="@n"/>
>> 	</xsl:when>
>> 	<xsl:otherwise>
>> 	<xsl:number count="tei:app" level="any"/>
>> 	</xsl:otherwise>
>>            </xsl:choose>
>>         </xsl:variable>
>>
>>         <xsl:choose>
>>          <xsl:when test="$footnoteFile='true'">
>> 	<a class="notelink" href="{$masterFile}-notes.html#{$identifier}">
>> 	<sup>
>> 	<xsl:call-template name="appN"/>
>> 	</sup>
>> 	</a>
>>          </xsl:when>
>>          <xsl:otherwise>
>> 	<a class="notelink" href="#{$identifier}">
>> 	<sup>
>> 	<xsl:call-template name="appN"/>
>> 	</sup>
>> 	</a>
>>          </xsl:otherwise>
>>         </xsl:choose>
>>
>> Cheers,
>> Martin
>

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From sebastian.rahtz at oucs.ox.ac.uk  Mon Apr 23 18:18:04 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Mon, 23 Apr 2012 22:18:04 +0000
Subject: [tei-council] Prefacing ids with "tei_"
In-Reply-To: <4F95A3EF.7030509@uvic.ca>
References: <4F95A3EF.7030509@uvic.ca>
Message-ID: <2C467D4E-E07E-4BDA-B76A-8EEA113BB12C@oucs.ox.ac.uk>


On 23 Apr 2012, at 19:48, Martin Holmes wrote:

> 
> 1. Generated ids. There are some places in which ids in the output are 
> generated using the XPath generate-id() function:
> 
> 	<xsl:call-template name="makeAnchor">
>             <xsl:with-param name="name">
>               <xsl:value-of select="generate-id()"/>
>             </xsl:with-param>
>           </xsl:call-template>

in practice generate-id() creates a single letter followed by a number,
so I think you could leave them alone. If Adblock looks
for "MSAD" in the _middle_ of a string, then it will be triggered by
"tei_MSAD", after all!


> 2. @n attributes. There's one place where the @n attribute can be used 
> to create an id attribute in the output (in textstructure.xsl, code 
> below)
this looks like a step too far. I have removed that <when> clause.

the HTML @id is already prefixed by "App", so no need to change it.


Sebastian


From syeates at gmail.com  Mon Apr 23 19:38:23 2012
From: syeates at gmail.com (Stuart A. Yeates)
Date: Tue, 24 Apr 2012 11:38:23 +1200
Subject: [tei-council] Attributes without examples
In-Reply-To: <4F9584B7.3080302@uvic.ca>
References: <4F908F22.4070908@uvic.ca> <4F90AD72.10605@uvic.ca>
	<4F90AEBC.6000608@ultraslavonic.info> <4F9573BF.1080302@uvic.ca>
	<4F957C03.8090008@oucs.ox.ac.uk> <4F9580F6.4080505@uvic.ca>
	<4F9584B7.3080302@uvic.ca>
Message-ID: <CAC_Lu0aeSZBOpxEK6zndQ99jhiV-aMZfcbupkqe8jxmnwOibsw@mail.gmail.com>

I've just tarted the wiki page up a little, making the table sortable
by arbitrary columns, linking to the ticket, etc.

cheers
stuart

On Tue, Apr 24, 2012 at 4:35 AM, Martin Holmes <mholmes at uvic.ca> wrote:
> I've created a ticket for this too, so we don't lose track of it:
>
> <http://purl.org/TEI/BUGS/3520704>
>
> Cheers,
> Martin
>
> On 12-04-23 09:19 AM, Martin Holmes wrote:
>> Thanks James -- that works. I have to write that down somewhere. I
>> wonder why spambots wouldn't use<nowiki/> ?themselves.
>>
>> Here's the page -- feel free to sign up for one or more attributes by
>> editing it:
>>
>> <http://wiki.tei-c.org/index.php/AttsWithoutEgs>
>>
>> Cheers,
>> Martin
>>
>> On 12-04-23 08:57 AM, James Cummings wrote:
>>>
>>> Martin,
>>>
>>> It is simple but intentionally not documented. Interrupt the spam
>>> word with an element. Specifically use<nowiki/> ? so
>>> att.ms<nowiki/>Excerpt will allow you to get around the spam filter.
>>>
>>> Just don't advertise via<nowiki/>gra too much.
>>>
>>> -James
>>>
>>> On 23/04/12 16:22, Martin Holmes wrote:
>>>> I've just tried to create a wiki page which has a table listing all
>>>> these attributes, but I've been prevented from doing so by the sad
>>>> little spam filter, which won't allow this:
>>>>
>>>> att.msExcerpt
>>>>
>>>> because it contains "sEx".
>>>>
>>>> I seem to remember having spent a frustrating time fighting with this
>>>> stupidity some time ago. Does anyone remember how to get around this, or
>>>> is it pointless to try?
>>>>
>>>> Cheers,
>>>> Martin
>>>>
>>>> On 12-04-19 05:33 PM, Kevin Hawkins wrote:
>>>>> Would you be able to output as a table with a third column for people to
>>>>> sign up, either in MediaWiki or HTML syntax, for a page in the wiki?
>>>>>
>>>>> On 4/19/12 8:27 PM, Martin Holmes wrote:
>>>>>> Below is another slightly shorter list. These are attributes which do
>>>>>> not appear on any examples in the<elementSpec> ? ? ?or<classSpec> ? ? ?in which
>>>>>> they're defined. Not that this doesn't mean there are no examples at all
>>>>>> for them; there may be an example somewhere in the Guidelines text, or
>>>>>> the attribute may be defined in a<classSpec> ? ? ?for an attribute class,
>>>>>> and then show up in an example in an<elementSpec> ? ? ?for an element which
>>>>>> belongs to that class. An example of the latter is @agent (att.damaged),
>>>>>> which has no example in the att.damaged<classSpec>, but happens to show
>>>>>> up in an example for the<damage> ? ? ?element.
>>>>>>
>>>>>> Nevertheless, I think it would be a good idea to try to provide examples
>>>>>> for all these attributes, in the files which define them.
>>>>>>
>>>>>> ATTRIBUTES WHICH DO NOT SHOW UP ON ANY EXAMPLE IN THEIR elementSpec OR
>>>>>> classSpec AS OF 2012-04-19T17:19:17.315-07:00
>>>>>>
>>>>>> 1. absolute (when)
>>>>>> 2. adj (node)
>>>>>> 3. adjFrom (node)
>>>>>> 4. adjTo (node)
>>>>>> 5. age (personGrp)
>>>>>> 6. agent (att.damaged)
>>>>>> 7. agent (gap)
>>>>>> 8. agent (unclear)
>>>>>> 9. ana (att.global.analytic)
>>>>>> 10. atLeast (att.ranging)
>>>>>> 11. atMost (att.ranging)
>>>>>> 12. attachment (surface)
>>>>>> 13. autoPrefix (content)
>>>>>> 14. baseTypes (fsDecl)
>>>>>> 15. break (att.breaking)
>>>>>> 16. cRef (gloss)
>>>>>> 17. cRef (ptr)
>>>>>> 18. cRef (ref)
>>>>>> 19. cRef (term)
>>>>>> 20. cause (att.textCritical)
>>>>>> 21. cause (att.transcriptional)
>>>>>> 22. cert (att.responsibility)
>>>>>> 23. change (att.global.change)
>>>>>> 24. class (msContents)
>>>>>> 25. cols (att.tableDecoration)
>>>>>> 26. confidence (att.ranging)
>>>>>> 27. contemporary (seal)
>>>>>> 28. copyOf (att.global.linking)
>>>>>> 29. corresp (att.global.linking)
>>>>>> 30. datingMethod (att.datable.custom)
>>>>>> 31. datingPoint (att.datable.custom)
>>>>>> 32. decls (att.declaring)
>>>>>> 33. default (att.declarable)
>>>>>> 34. defective (att.msExcerpt)
>>>>>> 35. degree (att.damaged)
>>>>>> 36. degree (node)
>>>>>> 37. dim (space)
>>>>>> 38. direct (said)
>>>>>> 39. docLang (schemaSpec)
>>>>>> 40. domains (att.pointing.group)
>>>>>> 41. dur (att.duration.w3c)
>>>>>> 42. dur-iso (att.duration.iso)
>>>>>> 43. encoding (binaryObject)
>>>>>> 44. end (att.timed)
>>>>>> 45. enjamb (att.enjamb)
>>>>>> 46. evaluate (att.pointing)
>>>>>> 47. evidence (att.editLike)
>>>>>> 48. except (moduleRef)
>>>>>> 49. exclude (att.global.linking)
>>>>>> 50. expand (att.lexicographic)
>>>>>> 51. extent (orth)
>>>>>> 52. fVal (f)
>>>>>> 53. facs (att.global.facs)
>>>>>> 54. feats (fs)
>>>>>> 55. filter (equiv)
>>>>>> 56. flipping (surface)
>>>>>> 57. follow (leaf)
>>>>>> 58. force (pc)
>>>>>> 59. from (app)
>>>>>> 60. from (att.datable.w3c)
>>>>>> 61. from-custom (att.datable.custom)
>>>>>> 62. from-iso (att.datable.iso)
>>>>>> 63. full (att.personal)
>>>>>> 64. function (att.segLike)
>>>>>> 65. generate (classSpec)
>>>>>> 66. gradual (writing)
>>>>>> 67. group (att.damaged)
>>>>>> 68. hand (att.damaged)
>>>>>> 69. hand (att.textCritical)
>>>>>> 70. hand (att.transcriptional)
>>>>>> 71. hand (gap)
>>>>>> 72. hand (unclear)
>>>>>> 73. height (binaryObject)
>>>>>> 74. height (graphic)
>>>>>> 75. ident (att.identified)
>>>>>> 76. inst (att.interpLike)
>>>>>> 77. instant (att.editLike)
>>>>>> 78. key (att.canonical)
>>>>>> 79. key (classRef)
>>>>>> 80. key (macroRef)
>>>>>> 81. level (sense)
>>>>>> 82. level (title)
>>>>>> 83. loc (app)
>>>>>> 84. location (att.lexicographic)
>>>>>> 85. lrx (att.coordinated)
>>>>>> 86. lry (att.coordinated)
>>>>>> 87. match (att.scoping)
>>>>>> 88. material (supportDesc)
>>>>>> 89. max (att.ranging)
>>>>>> 90. max (memberOf)
>>>>>> 91. medium (att.handFeatures)
>>>>>> 92. mergedIn (att.lexicographic)
>>>>>> 93. met (att.metrical)
>>>>>> 94. method (correction)
>>>>>> 95. mimeType (att.internetMedia)
>>>>>> 96. min (att.ranging)
>>>>>> 97. min (memberOf)
>>>>>> 98. mode (att.combinable)
>>>>>> 99. mode (classes)
>>>>>> 100. mode (memberOf)
>>>>>> 101. module (att.identified)
>>>>>> 102. new (handShift)
>>>>>> 103. next (att.global.linking)
>>>>>> 104. notAfter-custom (att.datable.custom)
>>>>>> 105. notAfter-iso (att.datable.iso)
>>>>>> 106. notBefore-custom (att.datable.custom)
>>>>>> 107. notBefore-iso (att.datable.iso)
>>>>>> 108. notation (pron)
>>>>>> 109. ns (attDef)
>>>>>> 110. ns (elementSpec)
>>>>>> 111. ns (schemaSpec)
>>>>>> 112. nymRef (att.naming)
>>>>>> 113. opt (att.lexicographic)
>>>>>> 114. optional (fDecl)
>>>>>> 115. ord (iNode)
>>>>>> 116. ord (root)
>>>>>> 117. org (att.divLike)
>>>>>> 118. org (attList)
>>>>>> 119. orig (att.lexicographic)
>>>>>> 120. part (ab)
>>>>>> 121. part (att.divLike)
>>>>>> 122. part (att.segLike)
>>>>>> 123. parts (nym)
>>>>>> 124. perf (tech)
>>>>>> 125. period (att.datable)
>>>>>> 126. pre (pc)
>>>>>> 127. precision (att.dimensions)
>>>>>> 128. predeclare (att.identified)
>>>>>> 129. prefix (elementSpec)
>>>>>> 130. prefix (moduleRef)
>>>>>> 131. prev (att.global.linking)
>>>>>> 132. quantity (att.dimensions)
>>>>>> 133. real (att.metrical)
>>>>>> 134. ref (att.canonical)
>>>>>> 135. refLang (att.pointing)
>>>>>> 136. resp (att.responsibility)
>>>>>> 137. resp (space)
>>>>>> 138. rhyme (att.metrical)
>>>>>> 139. role (att.naming)
>>>>>> 140. role (att.tableDecoration)
>>>>>> 141. role (org)
>>>>>> 142. rotate (zone)
>>>>>> 143. rows (att.tableDecoration)
>>>>>> 144. sameAs (att.global.linking)
>>>>>> 145. sample (att.divLike)
>>>>>> 146. scale (binaryObject)
>>>>>> 147. scale (graphic)
>>>>>> 148. scheme (catRef)
>>>>>> 149. scheme (locus)
>>>>>> 150. scheme (locusGrp)
>>>>>> 151. scheme (tag)
>>>>>> 152. scope (att.dimensions)
>>>>>> 153. scope (att.handFeatures)
>>>>>> 154. scribe (att.handFeatures)
>>>>>> 155. scribeRef (att.handFeatures)
>>>>>> 156. script (att.handFeatures)
>>>>>> 157. scriptRef (att.handFeatures)
>>>>>> 158. select (att.global.linking)
>>>>>> 159. seq (att.transcriptional)
>>>>>> 160. social (distinct)
>>>>>> 161. sort (att.personal)
>>>>>> 162. source (att.editLike)
>>>>>> 163. source (att.readFrom)
>>>>>> 164. source (writing)
>>>>>> 165. space (distinct)
>>>>>> 166. spanTo (att.spanning)
>>>>>> 167. split (att.lexicographic)
>>>>>> 168. start (att.coordinated)
>>>>>> 169. start (att.timed)
>>>>>> 170. status (att.identified)
>>>>>> 171. status (att.transcriptional)
>>>>>> 172. status (correction)
>>>>>> 173. stdDeviation (precision)
>>>>>> 174. subtype (att.typed)
>>>>>> 175. synch (att.global.linking)
>>>>>> 176. targFunc (att.pointing.group)
>>>>>> 177. target (change)
>>>>>> 178. target (relatedItem)
>>>>>> 179. targetEnd (note)
>>>>>> 180. targetLang (schemaSpec)
>>>>>> 181. targets (alt)
>>>>>> 182. targets (join)
>>>>>> 183. targets (link)
>>>>>> 184. time (distinct)
>>>>>> 185. to (app)
>>>>>> 186. to (att.datable.w3c)
>>>>>> 187. to-custom (att.datable.custom)
>>>>>> 188. to-iso (att.datable.iso)
>>>>>> 189. type (abbr)
>>>>>> 190. type (att.entryLike)
>>>>>> 191. type (att.interpLike)
>>>>>> 192. type (att.textCritical)
>>>>>> 193. type (att.typed)
>>>>>> 194. type (form)
>>>>>> 195. type (q)
>>>>>> 196. type (sound)
>>>>>> 197. ulx (att.coordinated)
>>>>>> 198. uly (att.coordinated)
>>>>>> 199. unit (att.dimensions)
>>>>>> 200. unit (pc)
>>>>>> 201. unit (when)
>>>>>> 202. url (moduleRef)
>>>>>> 203. value (att.lexicographic)
>>>>>> 204. value (eTree)
>>>>>> 205. value (iNode)
>>>>>> 206. value (leaf)
>>>>>> 207. value (node)
>>>>>> 208. value (root)
>>>>>> 209. value (triangle)
>>>>>> 210. varSeq (att.textCritical)
>>>>>> 211. version (unicodeName)
>>>>>> 212. versionDate (att.translatable)
>>>>>> 213. when (docDate)
>>>>>> 214. where (event)
>>>>>> 215. who (att.ascribed)
>>>>>> 216. width (binaryObject)
>>>>>> 217. width (graphic)
>>>>>> 218. wit (att.rdgPart)
>>>>>> 219. wit (att.witnessed)
>>>>>> 220. xml:base (att.global)
>>>>>> 221. xml:id (att.global)
>>>>>> 222. xml:lang (att.global)
>>>>>> 223. xml:space (att.global)
>>>>>>
>>>>>> Cheers,
>>>>>> Martin
>>>>>>
>>>>>> On 12-04-19 03:18 PM, Martin Holmes wrote:
>>>>>>> Following on from our discussion of examples for attributes, a
>>>>>>> quick-and-dirty XSLT seems to show that there are only 19 attributes
>>>>>>> with their own examples, and 450 without. This is not to say that those
>>>>>>> without are unexemplified, because the example code for their parent
>>>>>>> elements in the elementSpec may show examples of them; I'll refine the
>>>>>>> XSLT and make that apparent.
>>>>>>>
>>>>>>> Here's the list:
>>>>>>>
>>>>>>> ATTRIBUTE DEFINITIONS LACKING EXAMPLES AS OF 2012-04-19T15:12:34.968-07:00
>>>>>>>
>>>>>>> 1. status (att.identified)
>>>>>>> 2. type (interaction)
>>>>>>> 3. value (sex)
>>>>>>> 4. scale (graphic)
>>>>>>> 5. scale (binaryObject)
>>>>>>> 6. weights (alt)
>>>>>>> 7. hand (att.damaged)
>>>>>>> 8. agent (gap)
>>>>>>> 9. predeclare (att.identified)
>>>>>>> 10. degree (att.damaged)
>>>>>>> 11. module (att.identified)
>>>>>>> 12. ident (att.identified)
>>>>>>> 13. height (graphic)
>>>>>>> 14. height (binaryObject)
>>>>>>> 15. width (graphic)
>>>>>>> 16. width (binaryObject)
>>>>>>> 17. encoding (binaryObject)
>>>>>>> 18. version (teiCorpus)
>>>>>>> 19. hand (unclear)
>>>>>>> 20. agent (unclear)
>>>>>>> 21. feature (shift)
>>>>>>> 22. type (preparedness)
>>>>>>> 23. type (abbr)
>>>>>>> 24. commodity (att.measurement)
>>>>>>> 25. agent (att.damaged)
>>>>>>> 26. type (derivation)
>>>>>>> 27. type (domain)
>>>>>>> 28. type (factuality)
>>>>>>> 29. type (idno)
>>>>>>> 30. type (relation)
>>>>>>> 31. type (sound)
>>>>>>> 32. type (tech)
>>>>>>> 33. type (castItem)
>>>>>>> 34. type (att.typed)
>>>>>>> 35. type (move)
>>>>>>> 36. script (att.handFeatures)
>>>>>>> 37. class (msItemStruct)
>>>>>>> 38. class (msItem)
>>>>>>> 39. class (msContents)
>>>>>>> 40. type (form)
>>>>>>> 41. cause (att.textCritical)
>>>>>>> 42. type (gram)
>>>>>>> 43. type (lbl)
>>>>>>> 44. type (att.textCritical)
>>>>>>> 45. type (title)
>>>>>>> 46. type (titlePage)
>>>>>>> 47. type (usg)
>>>>>>> 48. type (app)
>>>>>>> 49. columns (layout)
>>>>>>> 50. valueDatcat (att.datcat)
>>>>>>> 51. datcat (att.datcat)
>>>>>>> 52. contemporary (seal)
>>>>>>> 53. contemporary (binding)
>>>>>>> 54. from (locus)
>>>>>>> 55. type (list)
>>>>>>> 56. result (joinGrp)
>>>>>>> 57. medium (att.handFeatures)
>>>>>>> 58. type (graph)
>>>>>>> 59. type (witDetail)
>>>>>>> 60. origin (timeline)
>>>>>>> 61. function (att.segLike)
>>>>>>> 62. form (objectDesc)
>>>>>>> 63. mergedIn (att.lexicographic)
>>>>>>> 64. type (fsDecl)
>>>>>>> 65. scribe (att.handFeatures)
>>>>>>> 66. degree (node)
>>>>>>> 67. extent (orth)
>>>>>>> 68. from (arc)
>>>>>>> 69. to (arc)
>>>>>>> 70. inDegree (node)
>>>>>>> 71. arity (tree)
>>>>>>> 72. baseTypes (fsDecl)
>>>>>>> 73. level (sense)
>>>>>>> 74. order (tree)
>>>>>>> 75. outDegree (iNode)
>>>>>>> 76. outDegree (node)
>>>>>>> 77. outDegree (root)
>>>>>>> 78. reason (gap)
>>>>>>> 79. type (orth)
>>>>>>> 80. when (docDate)
>>>>>>> 81. split (att.lexicographic)
>>>>>>> 82. code (socecStatus)
>>>>>>> 83. code (occupation)
>>>>>>> 84. decls (att.declaring)
>>>>>>> 85. cRef (term)
>>>>>>> 86. from (app)
>>>>>>> 87. scheme (catRef)
>>>>>>> 88. scheme (occupation)
>>>>>>> 89. scheme (classCode)
>>>>>>> 90. scheme (socecStatus)
>>>>>>> 91. scheme (keywords)
>>>>>>> 92. to (app)
>>>>>>> 93. baseForm (m)
>>>>>>> 94. new (handShift)
>>>>>>> 95. passive (relation)
>>>>>>> 96. since (when)
>>>>>>> 97. type (fsdLink)
>>>>>>> 98. type (biblScope)
>>>>>>> 99. type (listForest)
>>>>>>> 100. type (forest)
>>>>>>> 101. hand (gap)
>>>>>>> 102. given (certainty)
>>>>>>> 103. locus (certainty)
>>>>>>> 104. type (rs)
>>>>>>> 105. source (normalization)
>>>>>>> 106. level (title)
>>>>>>> 107. degree (certainty)
>>>>>>> 108. status (correction)
>>>>>>> 109. degree (precision)
>>>>>>> 110. spanTo (att.spanning)
>>>>>>> 111. to (att.datable.w3c)
>>>>>>> 112. to-iso (att.datable.iso)
>>>>>>> 113. force (pc)
>>>>>>> 114. reason (surplus)
>>>>>>> 115. type (stage)
>>>>>>> 116. type (oRef)
>>>>>>> 117. type (oVar)
>>>>>>> 118. method (correction)
>>>>>>> 119. method (normalization)
>>>>>>> 120. name (fDecl)
>>>>>>> 121. evidence (att.editLike)
>>>>>>> 122. rows (table)
>>>>>>> 123. org (vMerge)
>>>>>>> 124. who (att.ascribed)
>>>>>>> 125. locus (respons)
>>>>>>> 126. from-custom (att.datable.custom)
>>>>>>> 127. from (att.datable.w3c)
>>>>>>> 128. from-iso (att.datable.iso)
>>>>>>> 129. type (xr)
>>>>>>> 130. type (iType)
>>>>>>> 131. type (num)
>>>>>>> 132. type (att.entryLike)
>>>>>>> 133. type (att.interpLike)
>>>>>>> 134. unit (refState)
>>>>>>> 135. notation (pron)
>>>>>>> 136. break (att.breaking)
>>>>>>> 137. iterated (kinesic)
>>>>>>> 138. iterated (vocal)
>>>>>>> 139. optional (fDecl)
>>>>>>> 140. default (att.declarable)
>>>>>>> 141. location (variantEncoding)
>>>>>>> 142. anchored (note)
>>>>>>> 143. full (att.personal)
>>>>>>> 144. type (metDecl)
>>>>>>> 145. extent (pron)
>>>>>>> 146. discrete (sound)
>>>>>>> 147. scope (join)
>>>>>>> 148. gradual (writing)
>>>>>>> 149. sample (att.divLike)
>>>>>>> 150. type (classSpec)
>>>>>>> 151. pre (pc)
>>>>>>> 152. type (dimensions)
>>>>>>> 153. method (variantEncoding)
>>>>>>> 154. type (macroSpec)
>>>>>>> 155. reason (supplied)
>>>>>>> 156. to (locus)
>>>>>>> 157. rows (att.tableDecoration)
>>>>>>> 158. writtenLines (layout)
>>>>>>> 159. ruledLines (layout)
>>>>>>> 160. location (att.lexicographic)
>>>>>>> 161. hands (handDesc)
>>>>>>> 162. material (supportDesc)
>>>>>>> 163. notation (formula)
>>>>>>> 164. unit (att.dimensions)
>>>>>>> 165. ns (attDef)
>>>>>>> 166. ns (elementSpec)
>>>>>>> 167. domains (att.pointing.group)
>>>>>>> 168. part (att.segLike)
>>>>>>> 169. source (writing)
>>>>>>> 170. ref (g)
>>>>>>> 171. scribeRef (att.handFeatures)
>>>>>>> 172. scriptRef (att.handFeatures)
>>>>>>> 173. copyOf (att.global.linking)
>>>>>>> 174. sameAs (att.global.linking)
>>>>>>> 175. exclude (att.global.linking)
>>>>>>> 176. targetEnd (note)
>>>>>>> 177. next (att.global.linking)
>>>>>>> 178. target (relatedItem)
>>>>>>> 179. unit (milestone)
>>>>>>> 180. label (rhyme)
>>>>>>> 181. lemma (w)
>>>>>>> 182. children (iNode)
>>>>>>> 183. children (root)
>>>>>>> 184. name (f)
>>>>>>> 185. unit (pc)
>>>>>>> 186. value (leaf)
>>>>>>> 187. type (node)
>>>>>>> 188. key (att.canonical)
>>>>>>> 189. follow (iNode)
>>>>>>> 190. follow (leaf)
>>>>>>> 191. parent (leaf)
>>>>>>> 192. parent (iNode)
>>>>>>> 193. value (node)
>>>>>>> 194. value (triangle)
>>>>>>> 195. value (eLeaf)
>>>>>>> 196. value (eTree)
>>>>>>> 197. value (iNode)
>>>>>>> 198. value (root)
>>>>>>> 199. quantity (att.measurement)
>>>>>>> 200. role (att.tableDecoration)
>>>>>>> 201. scheme (att)
>>>>>>> 202. select (att.global.linking)
>>>>>>> 203. xml:space (att.global)
>>>>>>> 204. hand (att.textCritical)
>>>>>>> 205. subtype (att.typed)
>>>>>>> 206. prefix (schemaSpec)
>>>>>>> 207. prefix (elementSpec)
>>>>>>> 208. type (purpose)
>>>>>>> 209. role (org)
>>>>>>> 210. role (person)
>>>>>>> 211. matchPattern (cRefPattern)
>>>>>>> 212. replacementPattern (cRefPattern)
>>>>>>> 213. age (person)
>>>>>>> 214. start (schemaSpec)
>>>>>>> 215. form (quotation)
>>>>>>> 216. time (distinct)
>>>>>>> 217. social (distinct)
>>>>>>> 218. space (distinct)
>>>>>>> 219. type (constitution)
>>>>>>> 220. scope (att.handFeatures)
>>>>>>> 221. age (personGrp)
>>>>>>> 222. usage (language)
>>>>>>> 223. ident (valItem)
>>>>>>> 224. from (span)
>>>>>>> 225. value (metSym)
>>>>>>> 226. versionDate (att.translatable)
>>>>>>> 227. target (att.pointing)
>>>>>>> 228. where (move)
>>>>>>> 229. notBefore (att.datable.w3c)
>>>>>>> 230. notBefore-custom (att.datable.custom)
>>>>>>> 231. notBefore-iso (att.datable.iso)
>>>>>>> 232. mode (classes)
>>>>>>> 233. mode (att.combinable)
>>>>>>> 234. mode (memberOf)
>>>>>>> 235. to (span)
>>>>>>> 236. to (biblScope)
>>>>>>> 237. type (valList)
>>>>>>> 238. degree (purpose)
>>>>>>> 239. length (refState)
>>>>>>> 240. render (tagUsage)
>>>>>>> 241. targets (alt)
>>>>>>> 242. targets (join)
>>>>>>> 243. targets (link)
>>>>>>> 244. type (teiHeader)
>>>>>>> 245. notAfter (att.datable.w3c)
>>>>>>> 246. notAfter-custom (att.datable.custom)
>>>>>>> 247. notAfter-iso (att.datable.iso)
>>>>>>> 248. version (TEI)
>>>>>>> 249. mode (channel)
>>>>>>> 250. result (join)
>>>>>>> 251. new (shift)
>>>>>>> 252. active (interaction)
>>>>>>> 253. occurs (tagUsage)
>>>>>>> 254. passive (interaction)
>>>>>>> 255. interval (when)
>>>>>>> 256. interval (timeline)
>>>>>>> 257. usage (attDef)
>>>>>>> 258. role (personGrp)
>>>>>>> 259. type (titlePart)
>>>>>>> 260. sex (personGrp)
>>>>>>> 261. sex (person)
>>>>>>> 262. size (personGrp)
>>>>>>> 263. from (biblScope)
>>>>>>> 264. type (distinct)
>>>>>>> 265. type (measure)
>>>>>>> 266. type (fs)
>>>>>>> 267. unit (timeline)
>>>>>>> 268. unit (when)
>>>>>>> 269. version (unicodeName)
>>>>>>> 270. type (divGen)
>>>>>>> 271. part (ab)
>>>>>>> 272. part (att.divLike)
>>>>>>> 273. part (l)
>>>>>>> 274. terminal (metSym)
>>>>>>> 275. trunc (numeric)
>>>>>>> 276. order (graph)
>>>>>>> 277. size (graph)
>>>>>>> 278. mode (alt)
>>>>>>> 279. mode (altGrp)
>>>>>>> 280. value (binary)
>>>>>>> 281. status (availability)
>>>>>>> 282. datum (geoDecl)
>>>>>>> 283. value (numeric)
>>>>>>> 284. name (relation)
>>>>>>> 285. name (vLabel)
>>>>>>> 286. indexName (index)
>>>>>>> 287. stdDeviation (precision)
>>>>>>> 288. absolute (when)
>>>>>>> 289. max (numeric)
>>>>>>> 290. scheme (constraintSpec)
>>>>>>> 291. scheme (tag)
>>>>>>> 292. scheme (gi)
>>>>>>> 293. value (symbol)
>>>>>>> 294. value (num)
>>>>>>> 295. scheme (locusGrp)
>>>>>>> 296. scheme (locus)
>>>>>>> 297. name (namespace)
>>>>>>> 298. type (recording)
>>>>>>> 299. unit (att.measurement)
>>>>>>> 300. value (att.lexicographic)
>>>>>>> 301. scope (att.dimensions)
>>>>>>> 302. evaluate (att.pointing)
>>>>>>> 303. active (relation)
>>>>>>> 304. to-custom (att.datable.custom)
>>>>>>> 305. mutual (relation)
>>>>>>> 306. dur-iso (att.duration.iso)
>>>>>>> 307. instant (att.editLike)
>>>>>>> 308. function (metamark)
>>>>>>> 309. attachment (surface)
>>>>>>> 310. cause (att.transcriptional)
>>>>>>> 311. target (metamark)
>>>>>>> 312. rotate (zone)
>>>>>>> 313. target (redo)
>>>>>>> 314. target (undo)
>>>>>>> 315. except (moduleRef)
>>>>>>> 316. include (moduleRef)
>>>>>>> 317. datingMethod (att.datable.custom)
>>>>>>> 318. datingPoint (att.datable.custom)
>>>>>>> 319. key (moduleRef)
>>>>>>> 320. url (moduleRef)
>>>>>>> 321. mimeType (att.internetMedia)
>>>>>>> 322. version (application)
>>>>>>> 323. ident (application)
>>>>>>> 324. confidence (att.ranging)
>>>>>>> 325. level (langKnown)
>>>>>>> 326. adj (node)
>>>>>>> 327. adjFrom (node)
>>>>>>> 328. adjTo (node)
>>>>>>> 329. ana (att.global.analytic)
>>>>>>> 330. group (att.damaged)
>>>>>>> 331. cRef (gloss)
>>>>>>> 332. cRef (ptr)
>>>>>>> 333. cRef (ref)
>>>>>>> 334. cert (att.responsibility)
>>>>>>> 335. cert (certainty)
>>>>>>> 336. precision (precision)
>>>>>>> 337. precision (att.dimensions)
>>>>>>> 338. type (fw)
>>>>>>> 339. cols (table)
>>>>>>> 340. cols (att.tableDecoration)
>>>>>>> 341. source (att.editLike)
>>>>>>> 342. autoPrefix (content)
>>>>>>> 343. corresp (att.global.linking)
>>>>>>> 344. delim (refState)
>>>>>>> 345. dim (space)
>>>>>>> 346. docLang (schemaSpec)
>>>>>>> 347. dur (att.duration.w3c)
>>>>>>> 348. ed (att.sourced)
>>>>>>> 349. gi (tagUsage)
>>>>>>> 350. eol (hyphenation)
>>>>>>> 351. enjamb (att.enjamb)
>>>>>>> 352. facs (att.global.facs)
>>>>>>> 353. fVal (f)
>>>>>>> 354. feats (fs)
>>>>>>> 355. lang (code)
>>>>>>> 356. atMost (att.ranging)
>>>>>>> 357. atLeast (att.ranging)
>>>>>>> 358. lrx (att.coordinated)
>>>>>>> 359. ulx (att.coordinated)
>>>>>>> 360. lry (att.coordinated)
>>>>>>> 361. uly (att.coordinated)
>>>>>>> 362. xml:id (att.global)
>>>>>>> 363. ident (language)
>>>>>>> 364. scheme (rendition)
>>>>>>> 365. status (att.transcriptional)
>>>>>>> 366. where (event)
>>>>>>> 367. start (att.timed)
>>>>>>> 368. end (att.timed)
>>>>>>> 369. type (tag)
>>>>>>> 370. defective (att.msExcerpt)
>>>>>>> 371. generate (classSpec)
>>>>>>> 372. inst (att.interpLike)
>>>>>>> 373. xml:lang (att.global)
>>>>>>> 374. loc (app)
>>>>>>> 375. mainLang (textLang)
>>>>>>> 376. maxOccurs (datatype)
>>>>>>> 377. type (q)
>>>>>>> 378. direct (said)
>>>>>>> 379. aloud (said)
>>>>>>> 380. met (att.metrical)
>>>>>>> 381. real (att.metrical)
>>>>>>> 382. minOccurs (datatype)
>>>>>>> 383. name (equiv)
>>>>>>> 384. ns (schemaSpec)
>>>>>>> 385. n (att.global)
>>>>>>> 386. opt (att.lexicographic)
>>>>>>> 387. ord (iNode)
>>>>>>> 388. ord (root)
>>>>>>> 389. ord (tree)
>>>>>>> 390. sort (att.personal)
>>>>>>> 391. org (attList)
>>>>>>> 392. org (vColl)
>>>>>>> 393. org (att.divLike)
>>>>>>> 394. orig (att.lexicographic)
>>>>>>> 395. otherLangs (textLang)
>>>>>>> 396. perf (move)
>>>>>>> 397. perf (tech)
>>>>>>> 398. target (specGrpRef)
>>>>>>> 399. parts (nym)
>>>>>>> 400. change (att.global.change)
>>>>>>> 401. target (change)
>>>>>>> 402. prev (att.global.linking)
>>>>>>> 403. lemmaRef (w)
>>>>>>> 404. marks (quotation)
>>>>>>> 405. ref (att.canonical)
>>>>>>> 406. nymRef (att.naming)
>>>>>>> 407. filter (equiv)
>>>>>>> 408. pattern (metDecl)
>>>>>>> 409. resp (respons)
>>>>>>> 410. resp (att.responsibility)
>>>>>>> 411. resp (space)
>>>>>>> 412. rhyme (att.metrical)
>>>>>>> 413. seq (att.transcriptional)
>>>>>>> 414. hand (att.transcriptional)
>>>>>>> 415. prefix (moduleRef)
>>>>>>> 416. key (memberOf)
>>>>>>> 417. quantity (att.dimensions)
>>>>>>> 418. value (age)
>>>>>>> 419. target (fsdLink)
>>>>>>> 420. period (att.datable)
>>>>>>> 421. tag (langKnown)
>>>>>>> 422. tags (langKnowledge)
>>>>>>> 423. max (memberOf)
>>>>>>> 424. min (memberOf)
>>>>>>> 425. synch (att.global.linking)
>>>>>>> 426. targFunc (att.pointing.group)
>>>>>>> 427. targetLang (schemaSpec)
>>>>>>> 428. key (classRef)
>>>>>>> 429. key (elementRef)
>>>>>>> 430. key (macroRef)
>>>>>>> 431. name (attRef)
>>>>>>> 432. trans (u)
>>>>>>> 433. uri (equiv)
>>>>>>> 434. url (graphic)
>>>>>>> 435. varSeq (att.textCritical)
>>>>>>> 436. scope (rendition)
>>>>>>> 437. max (att.ranging)
>>>>>>> 438. min (att.ranging)
>>>>>>> 439. withId (tagUsage)
>>>>>>> 440. wit (att.witnessed)
>>>>>>> 441. wit (att.rdgPart)
>>>>>>> 442. wit (witDetail)
>>>>>>> 443. status (att.docStatus)
>>>>>>> 444. points (zone)
>>>>>>> 445. start (att.coordinated)
>>>>>>> 446. valid (egXML)
>>>>>>> 447. ordered (listChange)
>>>>>>> 448. role (att.naming)
>>>>>>> 449. source (att.readFrom)
>>>>>>> 450. flipping (surface)
>>>>>>>
>>>>>>>
>>>>>>> ATTRIBUTE DEFINITIONS WHICH HAVE EXAMPLES AS OF
>>>>>>> 2012-04-19T15:12:34.968-07:00
>>>>>>>
>>>>>>> 1. place (att.placement)
>>>>>>> 2. expand (att.lexicographic)
>>>>>>> 3. extent (att.dimensions)
>>>>>>> 4. calendar (att.datable)
>>>>>>> 5. reason (unclear)
>>>>>>> 6. target (att.scoping)
>>>>>>> 7. xml:base (att.global)
>>>>>>> 8. assertedValue (certainty)
>>>>>>> 9. refLang (att.pointing)
>>>>>>> 10. match (att.scoping)
>>>>>>> 11. sortKey (att.sortable)
>>>>>>> 12. atts (specDesc)
>>>>>>> 13. key (specDesc)
>>>>>>> 14. norm (att.lexicographic)
>>>>>>> 15. rendition (att.global)
>>>>>>> 16. rend (att.global)
>>>>>>> 17. when-iso (att.datable.iso)
>>>>>>> 18. when-custom (att.datable.custom)
>>>>>>> 19. when (att.datable.w3c)
>>>>>>>
>>>>>>> --
>>>>>>> Martin Holmes
>>>>>>> University of Victoria Humanities Computing and Media Centre
>>>>>>> (mholmes at uvic.ca)
>>>>>>> --
>>>>>>> tei-council mailing list
>>>>>>> tei-council at lists.village.Virginia.EDU
>>>>>>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>>>>>>>
>>>>>>> PLEASE NOTE: postings to this list are publicly archived
>>>>>>> .
>>>>>>>
>>>>>>
>>>>> .
>>>>>
>>>>
>>>
>>>
>>> --
>>> Dr James Cummings, InfoDev,
>>> Computing Services, University of Oxford
>>> --
>>> tei-council mailing list
>>> tei-council at lists.village.Virginia.EDU
>>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>>>
>>> PLEASE NOTE: postings to this list are publicly archived
>>> .
>>>
>>
>> --
>> Martin Holmes
>> University of Victoria Humanities Computing and Media Centre
>> (mholmes at uvic.ca)
>> --
>> tei-council mailing list
>> tei-council at lists.village.Virginia.EDU
>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>>
>> PLEASE NOTE: postings to this list are publicly archived
>> .
>>
>
> --
> Martin Holmes
> University of Victoria Humanities Computing and Media Centre
> (mholmes at uvic.ca)
> --
> tei-council mailing list
> tei-council at lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>
> PLEASE NOTE: postings to this list are publicly archived

From mholmes at uvic.ca  Mon Apr 23 20:00:22 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Mon, 23 Apr 2012 17:00:22 -0700
Subject: [tei-council] Attributes without examples
In-Reply-To: <CAC_Lu0aeSZBOpxEK6zndQ99jhiV-aMZfcbupkqe8jxmnwOibsw@mail.gmail.com>
References: <4F908F22.4070908@uvic.ca>	<4F90AD72.10605@uvic.ca>
	<4F90AEBC.6000608@ultraslavonic.info>	<4F9573BF.1080302@uvic.ca>
	<4F957C03.8090008@oucs.ox.ac.uk>	<4F9580F6.4080505@uvic.ca>
	<4F9584B7.3080302@uvic.ca>
	<CAC_Lu0aeSZBOpxEK6zndQ99jhiV-aMZfcbupkqe8jxmnwOibsw@mail.gmail.com>
Message-ID: <4F95ED16.1010000@uvic.ca>

On 12-04-23 04:38 PM, Stuart A. Yeates wrote:
> I've just tarted the wiki page up a little, making the table sortable
> by arbitrary columns, linking to the ticket, etc.

Neat! If I'd known about class="sortable" I'd have used it. Now I do.

Cheers,
Martin

>
> cheers
> stuart
>
> On Tue, Apr 24, 2012 at 4:35 AM, Martin Holmes<mholmes at uvic.ca>  wrote:
>> I've created a ticket for this too, so we don't lose track of it:
>>
>> <http://purl.org/TEI/BUGS/3520704>
>>
>> Cheers,
>> Martin
>>
>> On 12-04-23 09:19 AM, Martin Holmes wrote:
>>> Thanks James -- that works. I have to write that down somewhere. I
>>> wonder why spambots wouldn't use<nowiki/>   themselves.
>>>
>>> Here's the page -- feel free to sign up for one or more attributes by
>>> editing it:
>>>
>>> <http://wiki.tei-c.org/index.php/AttsWithoutEgs>
>>>
>>> Cheers,
>>> Martin
>>>
>>> On 12-04-23 08:57 AM, James Cummings wrote:
>>>>
>>>> Martin,
>>>>
>>>> It is simple but intentionally not documented. Interrupt the spam
>>>> word with an element. Specifically use<nowiki/>    so
>>>> att.ms<nowiki/>Excerpt will allow you to get around the spam filter.
>>>>
>>>> Just don't advertise via<nowiki/>gra too much.
>>>>
>>>> -James
>>>>
>>>> On 23/04/12 16:22, Martin Holmes wrote:
>>>>> I've just tried to create a wiki page which has a table listing all
>>>>> these attributes, but I've been prevented from doing so by the sad
>>>>> little spam filter, which won't allow this:
>>>>>
>>>>> att.msExcerpt
>>>>>
>>>>> because it contains "sEx".
>>>>>
>>>>> I seem to remember having spent a frustrating time fighting with this
>>>>> stupidity some time ago. Does anyone remember how to get around this, or
>>>>> is it pointless to try?
>>>>>
>>>>> Cheers,
>>>>> Martin
>>>>>
>>>>> On 12-04-19 05:33 PM, Kevin Hawkins wrote:
>>>>>> Would you be able to output as a table with a third column for people to
>>>>>> sign up, either in MediaWiki or HTML syntax, for a page in the wiki?
>>>>>>
>>>>>> On 4/19/12 8:27 PM, Martin Holmes wrote:
>>>>>>> Below is another slightly shorter list. These are attributes which do
>>>>>>> not appear on any examples in the<elementSpec>       or<classSpec>       in which
>>>>>>> they're defined. Not that this doesn't mean there are no examples at all
>>>>>>> for them; there may be an example somewhere in the Guidelines text, or
>>>>>>> the attribute may be defined in a<classSpec>       for an attribute class,
>>>>>>> and then show up in an example in an<elementSpec>       for an element which
>>>>>>> belongs to that class. An example of the latter is @agent (att.damaged),
>>>>>>> which has no example in the att.damaged<classSpec>, but happens to show
>>>>>>> up in an example for the<damage>       element.
>>>>>>>
>>>>>>> Nevertheless, I think it would be a good idea to try to provide examples
>>>>>>> for all these attributes, in the files which define them.
>>>>>>>
>>>>>>> ATTRIBUTES WHICH DO NOT SHOW UP ON ANY EXAMPLE IN THEIR elementSpec OR
>>>>>>> classSpec AS OF 2012-04-19T17:19:17.315-07:00
>>>>>>>
>>>>>>> 1. absolute (when)
>>>>>>> 2. adj (node)
>>>>>>> 3. adjFrom (node)
>>>>>>> 4. adjTo (node)
>>>>>>> 5. age (personGrp)
>>>>>>> 6. agent (att.damaged)
>>>>>>> 7. agent (gap)
>>>>>>> 8. agent (unclear)
>>>>>>> 9. ana (att.global.analytic)
>>>>>>> 10. atLeast (att.ranging)
>>>>>>> 11. atMost (att.ranging)
>>>>>>> 12. attachment (surface)
>>>>>>> 13. autoPrefix (content)
>>>>>>> 14. baseTypes (fsDecl)
>>>>>>> 15. break (att.breaking)
>>>>>>> 16. cRef (gloss)
>>>>>>> 17. cRef (ptr)
>>>>>>> 18. cRef (ref)
>>>>>>> 19. cRef (term)
>>>>>>> 20. cause (att.textCritical)
>>>>>>> 21. cause (att.transcriptional)
>>>>>>> 22. cert (att.responsibility)
>>>>>>> 23. change (att.global.change)
>>>>>>> 24. class (msContents)
>>>>>>> 25. cols (att.tableDecoration)
>>>>>>> 26. confidence (att.ranging)
>>>>>>> 27. contemporary (seal)
>>>>>>> 28. copyOf (att.global.linking)
>>>>>>> 29. corresp (att.global.linking)
>>>>>>> 30. datingMethod (att.datable.custom)
>>>>>>> 31. datingPoint (att.datable.custom)
>>>>>>> 32. decls (att.declaring)
>>>>>>> 33. default (att.declarable)
>>>>>>> 34. defective (att.msExcerpt)
>>>>>>> 35. degree (att.damaged)
>>>>>>> 36. degree (node)
>>>>>>> 37. dim (space)
>>>>>>> 38. direct (said)
>>>>>>> 39. docLang (schemaSpec)
>>>>>>> 40. domains (att.pointing.group)
>>>>>>> 41. dur (att.duration.w3c)
>>>>>>> 42. dur-iso (att.duration.iso)
>>>>>>> 43. encoding (binaryObject)
>>>>>>> 44. end (att.timed)
>>>>>>> 45. enjamb (att.enjamb)
>>>>>>> 46. evaluate (att.pointing)
>>>>>>> 47. evidence (att.editLike)
>>>>>>> 48. except (moduleRef)
>>>>>>> 49. exclude (att.global.linking)
>>>>>>> 50. expand (att.lexicographic)
>>>>>>> 51. extent (orth)
>>>>>>> 52. fVal (f)
>>>>>>> 53. facs (att.global.facs)
>>>>>>> 54. feats (fs)
>>>>>>> 55. filter (equiv)
>>>>>>> 56. flipping (surface)
>>>>>>> 57. follow (leaf)
>>>>>>> 58. force (pc)
>>>>>>> 59. from (app)
>>>>>>> 60. from (att.datable.w3c)
>>>>>>> 61. from-custom (att.datable.custom)
>>>>>>> 62. from-iso (att.datable.iso)
>>>>>>> 63. full (att.personal)
>>>>>>> 64. function (att.segLike)
>>>>>>> 65. generate (classSpec)
>>>>>>> 66. gradual (writing)
>>>>>>> 67. group (att.damaged)
>>>>>>> 68. hand (att.damaged)
>>>>>>> 69. hand (att.textCritical)
>>>>>>> 70. hand (att.transcriptional)
>>>>>>> 71. hand (gap)
>>>>>>> 72. hand (unclear)
>>>>>>> 73. height (binaryObject)
>>>>>>> 74. height (graphic)
>>>>>>> 75. ident (att.identified)
>>>>>>> 76. inst (att.interpLike)
>>>>>>> 77. instant (att.editLike)
>>>>>>> 78. key (att.canonical)
>>>>>>> 79. key (classRef)
>>>>>>> 80. key (macroRef)
>>>>>>> 81. level (sense)
>>>>>>> 82. level (title)
>>>>>>> 83. loc (app)
>>>>>>> 84. location (att.lexicographic)
>>>>>>> 85. lrx (att.coordinated)
>>>>>>> 86. lry (att.coordinated)
>>>>>>> 87. match (att.scoping)
>>>>>>> 88. material (supportDesc)
>>>>>>> 89. max (att.ranging)
>>>>>>> 90. max (memberOf)
>>>>>>> 91. medium (att.handFeatures)
>>>>>>> 92. mergedIn (att.lexicographic)
>>>>>>> 93. met (att.metrical)
>>>>>>> 94. method (correction)
>>>>>>> 95. mimeType (att.internetMedia)
>>>>>>> 96. min (att.ranging)
>>>>>>> 97. min (memberOf)
>>>>>>> 98. mode (att.combinable)
>>>>>>> 99. mode (classes)
>>>>>>> 100. mode (memberOf)
>>>>>>> 101. module (att.identified)
>>>>>>> 102. new (handShift)
>>>>>>> 103. next (att.global.linking)
>>>>>>> 104. notAfter-custom (att.datable.custom)
>>>>>>> 105. notAfter-iso (att.datable.iso)
>>>>>>> 106. notBefore-custom (att.datable.custom)
>>>>>>> 107. notBefore-iso (att.datable.iso)
>>>>>>> 108. notation (pron)
>>>>>>> 109. ns (attDef)
>>>>>>> 110. ns (elementSpec)
>>>>>>> 111. ns (schemaSpec)
>>>>>>> 112. nymRef (att.naming)
>>>>>>> 113. opt (att.lexicographic)
>>>>>>> 114. optional (fDecl)
>>>>>>> 115. ord (iNode)
>>>>>>> 116. ord (root)
>>>>>>> 117. org (att.divLike)
>>>>>>> 118. org (attList)
>>>>>>> 119. orig (att.lexicographic)
>>>>>>> 120. part (ab)
>>>>>>> 121. part (att.divLike)
>>>>>>> 122. part (att.segLike)
>>>>>>> 123. parts (nym)
>>>>>>> 124. perf (tech)
>>>>>>> 125. period (att.datable)
>>>>>>> 126. pre (pc)
>>>>>>> 127. precision (att.dimensions)
>>>>>>> 128. predeclare (att.identified)
>>>>>>> 129. prefix (elementSpec)
>>>>>>> 130. prefix (moduleRef)
>>>>>>> 131. prev (att.global.linking)
>>>>>>> 132. quantity (att.dimensions)
>>>>>>> 133. real (att.metrical)
>>>>>>> 134. ref (att.canonical)
>>>>>>> 135. refLang (att.pointing)
>>>>>>> 136. resp (att.responsibility)
>>>>>>> 137. resp (space)
>>>>>>> 138. rhyme (att.metrical)
>>>>>>> 139. role (att.naming)
>>>>>>> 140. role (att.tableDecoration)
>>>>>>> 141. role (org)
>>>>>>> 142. rotate (zone)
>>>>>>> 143. rows (att.tableDecoration)
>>>>>>> 144. sameAs (att.global.linking)
>>>>>>> 145. sample (att.divLike)
>>>>>>> 146. scale (binaryObject)
>>>>>>> 147. scale (graphic)
>>>>>>> 148. scheme (catRef)
>>>>>>> 149. scheme (locus)
>>>>>>> 150. scheme (locusGrp)
>>>>>>> 151. scheme (tag)
>>>>>>> 152. scope (att.dimensions)
>>>>>>> 153. scope (att.handFeatures)
>>>>>>> 154. scribe (att.handFeatures)
>>>>>>> 155. scribeRef (att.handFeatures)
>>>>>>> 156. script (att.handFeatures)
>>>>>>> 157. scriptRef (att.handFeatures)
>>>>>>> 158. select (att.global.linking)
>>>>>>> 159. seq (att.transcriptional)
>>>>>>> 160. social (distinct)
>>>>>>> 161. sort (att.personal)
>>>>>>> 162. source (att.editLike)
>>>>>>> 163. source (att.readFrom)
>>>>>>> 164. source (writing)
>>>>>>> 165. space (distinct)
>>>>>>> 166. spanTo (att.spanning)
>>>>>>> 167. split (att.lexicographic)
>>>>>>> 168. start (att.coordinated)
>>>>>>> 169. start (att.timed)
>>>>>>> 170. status (att.identified)
>>>>>>> 171. status (att.transcriptional)
>>>>>>> 172. status (correction)
>>>>>>> 173. stdDeviation (precision)
>>>>>>> 174. subtype (att.typed)
>>>>>>> 175. synch (att.global.linking)
>>>>>>> 176. targFunc (att.pointing.group)
>>>>>>> 177. target (change)
>>>>>>> 178. target (relatedItem)
>>>>>>> 179. targetEnd (note)
>>>>>>> 180. targetLang (schemaSpec)
>>>>>>> 181. targets (alt)
>>>>>>> 182. targets (join)
>>>>>>> 183. targets (link)
>>>>>>> 184. time (distinct)
>>>>>>> 185. to (app)
>>>>>>> 186. to (att.datable.w3c)
>>>>>>> 187. to-custom (att.datable.custom)
>>>>>>> 188. to-iso (att.datable.iso)
>>>>>>> 189. type (abbr)
>>>>>>> 190. type (att.entryLike)
>>>>>>> 191. type (att.interpLike)
>>>>>>> 192. type (att.textCritical)
>>>>>>> 193. type (att.typed)
>>>>>>> 194. type (form)
>>>>>>> 195. type (q)
>>>>>>> 196. type (sound)
>>>>>>> 197. ulx (att.coordinated)
>>>>>>> 198. uly (att.coordinated)
>>>>>>> 199. unit (att.dimensions)
>>>>>>> 200. unit (pc)
>>>>>>> 201. unit (when)
>>>>>>> 202. url (moduleRef)
>>>>>>> 203. value (att.lexicographic)
>>>>>>> 204. value (eTree)
>>>>>>> 205. value (iNode)
>>>>>>> 206. value (leaf)
>>>>>>> 207. value (node)
>>>>>>> 208. value (root)
>>>>>>> 209. value (triangle)
>>>>>>> 210. varSeq (att.textCritical)
>>>>>>> 211. version (unicodeName)
>>>>>>> 212. versionDate (att.translatable)
>>>>>>> 213. when (docDate)
>>>>>>> 214. where (event)
>>>>>>> 215. who (att.ascribed)
>>>>>>> 216. width (binaryObject)
>>>>>>> 217. width (graphic)
>>>>>>> 218. wit (att.rdgPart)
>>>>>>> 219. wit (att.witnessed)
>>>>>>> 220. xml:base (att.global)
>>>>>>> 221. xml:id (att.global)
>>>>>>> 222. xml:lang (att.global)
>>>>>>> 223. xml:space (att.global)
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Martin
>>>>>>>
>>>>>>> On 12-04-19 03:18 PM, Martin Holmes wrote:
>>>>>>>> Following on from our discussion of examples for attributes, a
>>>>>>>> quick-and-dirty XSLT seems to show that there are only 19 attributes
>>>>>>>> with their own examples, and 450 without. This is not to say that those
>>>>>>>> without are unexemplified, because the example code for their parent
>>>>>>>> elements in the elementSpec may show examples of them; I'll refine the
>>>>>>>> XSLT and make that apparent.
>>>>>>>>
>>>>>>>> Here's the list:
>>>>>>>>
>>>>>>>> ATTRIBUTE DEFINITIONS LACKING EXAMPLES AS OF 2012-04-19T15:12:34.968-07:00
>>>>>>>>
>>>>>>>> 1. status (att.identified)
>>>>>>>> 2. type (interaction)
>>>>>>>> 3. value (sex)
>>>>>>>> 4. scale (graphic)
>>>>>>>> 5. scale (binaryObject)
>>>>>>>> 6. weights (alt)
>>>>>>>> 7. hand (att.damaged)
>>>>>>>> 8. agent (gap)
>>>>>>>> 9. predeclare (att.identified)
>>>>>>>> 10. degree (att.damaged)
>>>>>>>> 11. module (att.identified)
>>>>>>>> 12. ident (att.identified)
>>>>>>>> 13. height (graphic)
>>>>>>>> 14. height (binaryObject)
>>>>>>>> 15. width (graphic)
>>>>>>>> 16. width (binaryObject)
>>>>>>>> 17. encoding (binaryObject)
>>>>>>>> 18. version (teiCorpus)
>>>>>>>> 19. hand (unclear)
>>>>>>>> 20. agent (unclear)
>>>>>>>> 21. feature (shift)
>>>>>>>> 22. type (preparedness)
>>>>>>>> 23. type (abbr)
>>>>>>>> 24. commodity (att.measurement)
>>>>>>>> 25. agent (att.damaged)
>>>>>>>> 26. type (derivation)
>>>>>>>> 27. type (domain)
>>>>>>>> 28. type (factuality)
>>>>>>>> 29. type (idno)
>>>>>>>> 30. type (relation)
>>>>>>>> 31. type (sound)
>>>>>>>> 32. type (tech)
>>>>>>>> 33. type (castItem)
>>>>>>>> 34. type (att.typed)
>>>>>>>> 35. type (move)
>>>>>>>> 36. script (att.handFeatures)
>>>>>>>> 37. class (msItemStruct)
>>>>>>>> 38. class (msItem)
>>>>>>>> 39. class (msContents)
>>>>>>>> 40. type (form)
>>>>>>>> 41. cause (att.textCritical)
>>>>>>>> 42. type (gram)
>>>>>>>> 43. type (lbl)
>>>>>>>> 44. type (att.textCritical)
>>>>>>>> 45. type (title)
>>>>>>>> 46. type (titlePage)
>>>>>>>> 47. type (usg)
>>>>>>>> 48. type (app)
>>>>>>>> 49. columns (layout)
>>>>>>>> 50. valueDatcat (att.datcat)
>>>>>>>> 51. datcat (att.datcat)
>>>>>>>> 52. contemporary (seal)
>>>>>>>> 53. contemporary (binding)
>>>>>>>> 54. from (locus)
>>>>>>>> 55. type (list)
>>>>>>>> 56. result (joinGrp)
>>>>>>>> 57. medium (att.handFeatures)
>>>>>>>> 58. type (graph)
>>>>>>>> 59. type (witDetail)
>>>>>>>> 60. origin (timeline)
>>>>>>>> 61. function (att.segLike)
>>>>>>>> 62. form (objectDesc)
>>>>>>>> 63. mergedIn (att.lexicographic)
>>>>>>>> 64. type (fsDecl)
>>>>>>>> 65. scribe (att.handFeatures)
>>>>>>>> 66. degree (node)
>>>>>>>> 67. extent (orth)
>>>>>>>> 68. from (arc)
>>>>>>>> 69. to (arc)
>>>>>>>> 70. inDegree (node)
>>>>>>>> 71. arity (tree)
>>>>>>>> 72. baseTypes (fsDecl)
>>>>>>>> 73. level (sense)
>>>>>>>> 74. order (tree)
>>>>>>>> 75. outDegree (iNode)
>>>>>>>> 76. outDegree (node)
>>>>>>>> 77. outDegree (root)
>>>>>>>> 78. reason (gap)
>>>>>>>> 79. type (orth)
>>>>>>>> 80. when (docDate)
>>>>>>>> 81. split (att.lexicographic)
>>>>>>>> 82. code (socecStatus)
>>>>>>>> 83. code (occupation)
>>>>>>>> 84. decls (att.declaring)
>>>>>>>> 85. cRef (term)
>>>>>>>> 86. from (app)
>>>>>>>> 87. scheme (catRef)
>>>>>>>> 88. scheme (occupation)
>>>>>>>> 89. scheme (classCode)
>>>>>>>> 90. scheme (socecStatus)
>>>>>>>> 91. scheme (keywords)
>>>>>>>> 92. to (app)
>>>>>>>> 93. baseForm (m)
>>>>>>>> 94. new (handShift)
>>>>>>>> 95. passive (relation)
>>>>>>>> 96. since (when)
>>>>>>>> 97. type (fsdLink)
>>>>>>>> 98. type (biblScope)
>>>>>>>> 99. type (listForest)
>>>>>>>> 100. type (forest)
>>>>>>>> 101. hand (gap)
>>>>>>>> 102. given (certainty)
>>>>>>>> 103. locus (certainty)
>>>>>>>> 104. type (rs)
>>>>>>>> 105. source (normalization)
>>>>>>>> 106. level (title)
>>>>>>>> 107. degree (certainty)
>>>>>>>> 108. status (correction)
>>>>>>>> 109. degree (precision)
>>>>>>>> 110. spanTo (att.spanning)
>>>>>>>> 111. to (att.datable.w3c)
>>>>>>>> 112. to-iso (att.datable.iso)
>>>>>>>> 113. force (pc)
>>>>>>>> 114. reason (surplus)
>>>>>>>> 115. type (stage)
>>>>>>>> 116. type (oRef)
>>>>>>>> 117. type (oVar)
>>>>>>>> 118. method (correction)
>>>>>>>> 119. method (normalization)
>>>>>>>> 120. name (fDecl)
>>>>>>>> 121. evidence (att.editLike)
>>>>>>>> 122. rows (table)
>>>>>>>> 123. org (vMerge)
>>>>>>>> 124. who (att.ascribed)
>>>>>>>> 125. locus (respons)
>>>>>>>> 126. from-custom (att.datable.custom)
>>>>>>>> 127. from (att.datable.w3c)
>>>>>>>> 128. from-iso (att.datable.iso)
>>>>>>>> 129. type (xr)
>>>>>>>> 130. type (iType)
>>>>>>>> 131. type (num)
>>>>>>>> 132. type (att.entryLike)
>>>>>>>> 133. type (att.interpLike)
>>>>>>>> 134. unit (refState)
>>>>>>>> 135. notation (pron)
>>>>>>>> 136. break (att.breaking)
>>>>>>>> 137. iterated (kinesic)
>>>>>>>> 138. iterated (vocal)
>>>>>>>> 139. optional (fDecl)
>>>>>>>> 140. default (att.declarable)
>>>>>>>> 141. location (variantEncoding)
>>>>>>>> 142. anchored (note)
>>>>>>>> 143. full (att.personal)
>>>>>>>> 144. type (metDecl)
>>>>>>>> 145. extent (pron)
>>>>>>>> 146. discrete (sound)
>>>>>>>> 147. scope (join)
>>>>>>>> 148. gradual (writing)
>>>>>>>> 149. sample (att.divLike)
>>>>>>>> 150. type (classSpec)
>>>>>>>> 151. pre (pc)
>>>>>>>> 152. type (dimensions)
>>>>>>>> 153. method (variantEncoding)
>>>>>>>> 154. type (macroSpec)
>>>>>>>> 155. reason (supplied)
>>>>>>>> 156. to (locus)
>>>>>>>> 157. rows (att.tableDecoration)
>>>>>>>> 158. writtenLines (layout)
>>>>>>>> 159. ruledLines (layout)
>>>>>>>> 160. location (att.lexicographic)
>>>>>>>> 161. hands (handDesc)
>>>>>>>> 162. material (supportDesc)
>>>>>>>> 163. notation (formula)
>>>>>>>> 164. unit (att.dimensions)
>>>>>>>> 165. ns (attDef)
>>>>>>>> 166. ns (elementSpec)
>>>>>>>> 167. domains (att.pointing.group)
>>>>>>>> 168. part (att.segLike)
>>>>>>>> 169. source (writing)
>>>>>>>> 170. ref (g)
>>>>>>>> 171. scribeRef (att.handFeatures)
>>>>>>>> 172. scriptRef (att.handFeatures)
>>>>>>>> 173. copyOf (att.global.linking)
>>>>>>>> 174. sameAs (att.global.linking)
>>>>>>>> 175. exclude (att.global.linking)
>>>>>>>> 176. targetEnd (note)
>>>>>>>> 177. next (att.global.linking)
>>>>>>>> 178. target (relatedItem)
>>>>>>>> 179. unit (milestone)
>>>>>>>> 180. label (rhyme)
>>>>>>>> 181. lemma (w)
>>>>>>>> 182. children (iNode)
>>>>>>>> 183. children (root)
>>>>>>>> 184. name (f)
>>>>>>>> 185. unit (pc)
>>>>>>>> 186. value (leaf)
>>>>>>>> 187. type (node)
>>>>>>>> 188. key (att.canonical)
>>>>>>>> 189. follow (iNode)
>>>>>>>> 190. follow (leaf)
>>>>>>>> 191. parent (leaf)
>>>>>>>> 192. parent (iNode)
>>>>>>>> 193. value (node)
>>>>>>>> 194. value (triangle)
>>>>>>>> 195. value (eLeaf)
>>>>>>>> 196. value (eTree)
>>>>>>>> 197. value (iNode)
>>>>>>>> 198. value (root)
>>>>>>>> 199. quantity (att.measurement)
>>>>>>>> 200. role (att.tableDecoration)
>>>>>>>> 201. scheme (att)
>>>>>>>> 202. select (att.global.linking)
>>>>>>>> 203. xml:space (att.global)
>>>>>>>> 204. hand (att.textCritical)
>>>>>>>> 205. subtype (att.typed)
>>>>>>>> 206. prefix (schemaSpec)
>>>>>>>> 207. prefix (elementSpec)
>>>>>>>> 208. type (purpose)
>>>>>>>> 209. role (org)
>>>>>>>> 210. role (person)
>>>>>>>> 211. matchPattern (cRefPattern)
>>>>>>>> 212. replacementPattern (cRefPattern)
>>>>>>>> 213. age (person)
>>>>>>>> 214. start (schemaSpec)
>>>>>>>> 215. form (quotation)
>>>>>>>> 216. time (distinct)
>>>>>>>> 217. social (distinct)
>>>>>>>> 218. space (distinct)
>>>>>>>> 219. type (constitution)
>>>>>>>> 220. scope (att.handFeatures)
>>>>>>>> 221. age (personGrp)
>>>>>>>> 222. usage (language)
>>>>>>>> 223. ident (valItem)
>>>>>>>> 224. from (span)
>>>>>>>> 225. value (metSym)
>>>>>>>> 226. versionDate (att.translatable)
>>>>>>>> 227. target (att.pointing)
>>>>>>>> 228. where (move)
>>>>>>>> 229. notBefore (att.datable.w3c)
>>>>>>>> 230. notBefore-custom (att.datable.custom)
>>>>>>>> 231. notBefore-iso (att.datable.iso)
>>>>>>>> 232. mode (classes)
>>>>>>>> 233. mode (att.combinable)
>>>>>>>> 234. mode (memberOf)
>>>>>>>> 235. to (span)
>>>>>>>> 236. to (biblScope)
>>>>>>>> 237. type (valList)
>>>>>>>> 238. degree (purpose)
>>>>>>>> 239. length (refState)
>>>>>>>> 240. render (tagUsage)
>>>>>>>> 241. targets (alt)
>>>>>>>> 242. targets (join)
>>>>>>>> 243. targets (link)
>>>>>>>> 244. type (teiHeader)
>>>>>>>> 245. notAfter (att.datable.w3c)
>>>>>>>> 246. notAfter-custom (att.datable.custom)
>>>>>>>> 247. notAfter-iso (att.datable.iso)
>>>>>>>> 248. version (TEI)
>>>>>>>> 249. mode (channel)
>>>>>>>> 250. result (join)
>>>>>>>> 251. new (shift)
>>>>>>>> 252. active (interaction)
>>>>>>>> 253. occurs (tagUsage)
>>>>>>>> 254. passive (interaction)
>>>>>>>> 255. interval (when)
>>>>>>>> 256. interval (timeline)
>>>>>>>> 257. usage (attDef)
>>>>>>>> 258. role (personGrp)
>>>>>>>> 259. type (titlePart)
>>>>>>>> 260. sex (personGrp)
>>>>>>>> 261. sex (person)
>>>>>>>> 262. size (personGrp)
>>>>>>>> 263. from (biblScope)
>>>>>>>> 264. type (distinct)
>>>>>>>> 265. type (measure)
>>>>>>>> 266. type (fs)
>>>>>>>> 267. unit (timeline)
>>>>>>>> 268. unit (when)
>>>>>>>> 269. version (unicodeName)
>>>>>>>> 270. type (divGen)
>>>>>>>> 271. part (ab)
>>>>>>>> 272. part (att.divLike)
>>>>>>>> 273. part (l)
>>>>>>>> 274. terminal (metSym)
>>>>>>>> 275. trunc (numeric)
>>>>>>>> 276. order (graph)
>>>>>>>> 277. size (graph)
>>>>>>>> 278. mode (alt)
>>>>>>>> 279. mode (altGrp)
>>>>>>>> 280. value (binary)
>>>>>>>> 281. status (availability)
>>>>>>>> 282. datum (geoDecl)
>>>>>>>> 283. value (numeric)
>>>>>>>> 284. name (relation)
>>>>>>>> 285. name (vLabel)
>>>>>>>> 286. indexName (index)
>>>>>>>> 287. stdDeviation (precision)
>>>>>>>> 288. absolute (when)
>>>>>>>> 289. max (numeric)
>>>>>>>> 290. scheme (constraintSpec)
>>>>>>>> 291. scheme (tag)
>>>>>>>> 292. scheme (gi)
>>>>>>>> 293. value (symbol)
>>>>>>>> 294. value (num)
>>>>>>>> 295. scheme (locusGrp)
>>>>>>>> 296. scheme (locus)
>>>>>>>> 297. name (namespace)
>>>>>>>> 298. type (recording)
>>>>>>>> 299. unit (att.measurement)
>>>>>>>> 300. value (att.lexicographic)
>>>>>>>> 301. scope (att.dimensions)
>>>>>>>> 302. evaluate (att.pointing)
>>>>>>>> 303. active (relation)
>>>>>>>> 304. to-custom (att.datable.custom)
>>>>>>>> 305. mutual (relation)
>>>>>>>> 306. dur-iso (att.duration.iso)
>>>>>>>> 307. instant (att.editLike)
>>>>>>>> 308. function (metamark)
>>>>>>>> 309. attachment (surface)
>>>>>>>> 310. cause (att.transcriptional)
>>>>>>>> 311. target (metamark)
>>>>>>>> 312. rotate (zone)
>>>>>>>> 313. target (redo)
>>>>>>>> 314. target (undo)
>>>>>>>> 315. except (moduleRef)
>>>>>>>> 316. include (moduleRef)
>>>>>>>> 317. datingMethod (att.datable.custom)
>>>>>>>> 318. datingPoint (att.datable.custom)
>>>>>>>> 319. key (moduleRef)
>>>>>>>> 320. url (moduleRef)
>>>>>>>> 321. mimeType (att.internetMedia)
>>>>>>>> 322. version (application)
>>>>>>>> 323. ident (application)
>>>>>>>> 324. confidence (att.ranging)
>>>>>>>> 325. level (langKnown)
>>>>>>>> 326. adj (node)
>>>>>>>> 327. adjFrom (node)
>>>>>>>> 328. adjTo (node)
>>>>>>>> 329. ana (att.global.analytic)
>>>>>>>> 330. group (att.damaged)
>>>>>>>> 331. cRef (gloss)
>>>>>>>> 332. cRef (ptr)
>>>>>>>> 333. cRef (ref)
>>>>>>>> 334. cert (att.responsibility)
>>>>>>>> 335. cert (certainty)
>>>>>>>> 336. precision (precision)
>>>>>>>> 337. precision (att.dimensions)
>>>>>>>> 338. type (fw)
>>>>>>>> 339. cols (table)
>>>>>>>> 340. cols (att.tableDecoration)
>>>>>>>> 341. source (att.editLike)
>>>>>>>> 342. autoPrefix (content)
>>>>>>>> 343. corresp (att.global.linking)
>>>>>>>> 344. delim (refState)
>>>>>>>> 345. dim (space)
>>>>>>>> 346. docLang (schemaSpec)
>>>>>>>> 347. dur (att.duration.w3c)
>>>>>>>> 348. ed (att.sourced)
>>>>>>>> 349. gi (tagUsage)
>>>>>>>> 350. eol (hyphenation)
>>>>>>>> 351. enjamb (att.enjamb)
>>>>>>>> 352. facs (att.global.facs)
>>>>>>>> 353. fVal (f)
>>>>>>>> 354. feats (fs)
>>>>>>>> 355. lang (code)
>>>>>>>> 356. atMost (att.ranging)
>>>>>>>> 357. atLeast (att.ranging)
>>>>>>>> 358. lrx (att.coordinated)
>>>>>>>> 359. ulx (att.coordinated)
>>>>>>>> 360. lry (att.coordinated)
>>>>>>>> 361. uly (att.coordinated)
>>>>>>>> 362. xml:id (att.global)
>>>>>>>> 363. ident (language)
>>>>>>>> 364. scheme (rendition)
>>>>>>>> 365. status (att.transcriptional)
>>>>>>>> 366. where (event)
>>>>>>>> 367. start (att.timed)
>>>>>>>> 368. end (att.timed)
>>>>>>>> 369. type (tag)
>>>>>>>> 370. defective (att.msExcerpt)
>>>>>>>> 371. generate (classSpec)
>>>>>>>> 372. inst (att.interpLike)
>>>>>>>> 373. xml:lang (att.global)
>>>>>>>> 374. loc (app)
>>>>>>>> 375. mainLang (textLang)
>>>>>>>> 376. maxOccurs (datatype)
>>>>>>>> 377. type (q)
>>>>>>>> 378. direct (said)
>>>>>>>> 379. aloud (said)
>>>>>>>> 380. met (att.metrical)
>>>>>>>> 381. real (att.metrical)
>>>>>>>> 382. minOccurs (datatype)
>>>>>>>> 383. name (equiv)
>>>>>>>> 384. ns (schemaSpec)
>>>>>>>> 385. n (att.global)
>>>>>>>> 386. opt (att.lexicographic)
>>>>>>>> 387. ord (iNode)
>>>>>>>> 388. ord (root)
>>>>>>>> 389. ord (tree)
>>>>>>>> 390. sort (att.personal)
>>>>>>>> 391. org (attList)
>>>>>>>> 392. org (vColl)
>>>>>>>> 393. org (att.divLike)
>>>>>>>> 394. orig (att.lexicographic)
>>>>>>>> 395. otherLangs (textLang)
>>>>>>>> 396. perf (move)
>>>>>>>> 397. perf (tech)
>>>>>>>> 398. target (specGrpRef)
>>>>>>>> 399. parts (nym)
>>>>>>>> 400. change (att.global.change)
>>>>>>>> 401. target (change)
>>>>>>>> 402. prev (att.global.linking)
>>>>>>>> 403. lemmaRef (w)
>>>>>>>> 404. marks (quotation)
>>>>>>>> 405. ref (att.canonical)
>>>>>>>> 406. nymRef (att.naming)
>>>>>>>> 407. filter (equiv)
>>>>>>>> 408. pattern (metDecl)
>>>>>>>> 409. resp (respons)
>>>>>>>> 410. resp (att.responsibility)
>>>>>>>> 411. resp (space)
>>>>>>>> 412. rhyme (att.metrical)
>>>>>>>> 413. seq (att.transcriptional)
>>>>>>>> 414. hand (att.transcriptional)
>>>>>>>> 415. prefix (moduleRef)
>>>>>>>> 416. key (memberOf)
>>>>>>>> 417. quantity (att.dimensions)
>>>>>>>> 418. value (age)
>>>>>>>> 419. target (fsdLink)
>>>>>>>> 420. period (att.datable)
>>>>>>>> 421. tag (langKnown)
>>>>>>>> 422. tags (langKnowledge)
>>>>>>>> 423. max (memberOf)
>>>>>>>> 424. min (memberOf)
>>>>>>>> 425. synch (att.global.linking)
>>>>>>>> 426. targFunc (att.pointing.group)
>>>>>>>> 427. targetLang (schemaSpec)
>>>>>>>> 428. key (classRef)
>>>>>>>> 429. key (elementRef)
>>>>>>>> 430. key (macroRef)
>>>>>>>> 431. name (attRef)
>>>>>>>> 432. trans (u)
>>>>>>>> 433. uri (equiv)
>>>>>>>> 434. url (graphic)
>>>>>>>> 435. varSeq (att.textCritical)
>>>>>>>> 436. scope (rendition)
>>>>>>>> 437. max (att.ranging)
>>>>>>>> 438. min (att.ranging)
>>>>>>>> 439. withId (tagUsage)
>>>>>>>> 440. wit (att.witnessed)
>>>>>>>> 441. wit (att.rdgPart)
>>>>>>>> 442. wit (witDetail)
>>>>>>>> 443. status (att.docStatus)
>>>>>>>> 444. points (zone)
>>>>>>>> 445. start (att.coordinated)
>>>>>>>> 446. valid (egXML)
>>>>>>>> 447. ordered (listChange)
>>>>>>>> 448. role (att.naming)
>>>>>>>> 449. source (att.readFrom)
>>>>>>>> 450. flipping (surface)
>>>>>>>>
>>>>>>>>
>>>>>>>> ATTRIBUTE DEFINITIONS WHICH HAVE EXAMPLES AS OF
>>>>>>>> 2012-04-19T15:12:34.968-07:00
>>>>>>>>
>>>>>>>> 1. place (att.placement)
>>>>>>>> 2. expand (att.lexicographic)
>>>>>>>> 3. extent (att.dimensions)
>>>>>>>> 4. calendar (att.datable)
>>>>>>>> 5. reason (unclear)
>>>>>>>> 6. target (att.scoping)
>>>>>>>> 7. xml:base (att.global)
>>>>>>>> 8. assertedValue (certainty)
>>>>>>>> 9. refLang (att.pointing)
>>>>>>>> 10. match (att.scoping)
>>>>>>>> 11. sortKey (att.sortable)
>>>>>>>> 12. atts (specDesc)
>>>>>>>> 13. key (specDesc)
>>>>>>>> 14. norm (att.lexicographic)
>>>>>>>> 15. rendition (att.global)
>>>>>>>> 16. rend (att.global)
>>>>>>>> 17. when-iso (att.datable.iso)
>>>>>>>> 18. when-custom (att.datable.custom)
>>>>>>>> 19. when (att.datable.w3c)
>>>>>>>>
>>>>>>>> --
>>>>>>>> Martin Holmes
>>>>>>>> University of Victoria Humanities Computing and Media Centre
>>>>>>>> (mholmes at uvic.ca)
>>>>>>>> --
>>>>>>>> tei-council mailing list
>>>>>>>> tei-council at lists.village.Virginia.EDU
>>>>>>>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>>>>>>>>
>>>>>>>> PLEASE NOTE: postings to this list are publicly archived
>>>>>>>> .
>>>>>>>>
>>>>>>>
>>>>>> .
>>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Dr James Cummings, InfoDev,
>>>> Computing Services, University of Oxford
>>>> --
>>>> tei-council mailing list
>>>> tei-council at lists.village.Virginia.EDU
>>>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>>>>
>>>> PLEASE NOTE: postings to this list are publicly archived
>>>> .
>>>>
>>>
>>> --
>>> Martin Holmes
>>> University of Victoria Humanities Computing and Media Centre
>>> (mholmes at uvic.ca)
>>> --
>>> tei-council mailing list
>>> tei-council at lists.village.Virginia.EDU
>>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>>>
>>> PLEASE NOTE: postings to this list are publicly archived
>>> .
>>>
>>
>> --
>> Martin Holmes
>> University of Victoria Humanities Computing and Media Centre
>> (mholmes at uvic.ca)
>> --
>> tei-council mailing list
>> tei-council at lists.village.Virginia.EDU
>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>>
>> PLEASE NOTE: postings to this list are publicly archived

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From James.Cummings at oucs.ox.ac.uk  Tue Apr 24 05:36:06 2012
From: James.Cummings at oucs.ox.ac.uk (James Cummings)
Date: Tue, 24 Apr 2012 10:36:06 +0100
Subject: [tei-council] next release?
In-Reply-To: <4F9592D1.30207@kcl.ac.uk>
References: <0F18A249-5480-42D9-BFF2-538AC7B9E1EB@oucs.ox.ac.uk>	<4F92F34D.2040103@uvic.ca>
	<4F9579A0.8010002@oucs.ox.ac.uk> <4F9592D1.30207@kcl.ac.uk>
Message-ID: <4F967406.8010304@oucs.ox.ac.uk>


Just to say that I'm planning to go through all the tickets 
discussed in Ann Arbor and note what the minutes say about them 
and confirm they are assigned to the right person. Maybe this 
evening....

-James

On 23/04/12 18:35, Gabriel BODARD wrote:
> In terms of doing the release tech, I guess I need to put aside at least
> a day to work through this, and it doesn't matter much to me when that
> day is, so that's fine.
>
> I'm now just trying to remember if there were any tickets assigned to me
> in the meantime, and if I'll have time to complete them by May 20. I was
> going to look into the guidelines-wide impact of something, but I don't
> recall exactly what. Did someone add a note to the ticket in question?
> (And in what may be the answer to the same or may be a completely
> unrelated question, could someone update http://purl.com/tei/fr/3416130
> with the current state of Council thinking after Ann Arbor, please?)
>
> (Incidentally, I think http://purl.com/TEI/BUGS/3496949 has been
> erroneously assigned to me--I don't think I know what we're meant to do
> with this.)
>
> Gabby
>
> On 23/04/2012 16:47, James Cummings wrote:
>>
>> How about we set a notional target release date of 25 May?  (This
>> is about 5 weeks from now.) If we assume that we want most things
>> completed by the end of Sunday 20th, to allow time for
>> proofreading and error spotting.
>>
>> Does that sounds reasonable to most people?
>>
>> Gaby: Most importantly, does the proposed Release Technician like
>> these dates?
>>
>> -James
>>
>>
>> On 21/04/12 18:50, Martin Holmes wrote:
>>> Three weeks will be a bit tough for me, and a couple of the tickets I
>>> have might turn out to have unpredicted side-effects (like the tei_
>>> prefix). As long as we have the option to launch without the change if
>>> it proves difficult, we could go with three weeks.
>>>
>>> The attributes-without-examples problem is so large that we'll just have
>>> to hack away at it steadily.
>>>
>>> Cheers,
>>> Martin
>>>
>>> On 12-04-21 04:03 AM, Sebastian Rahtz wrote:
>>>> something we forgot to debate in Ann Arbor was a timetable
>>>> for the next release, I think? i.e. what is the due date for
>>>> everyone to complete their ticket work so that Sir Gabriel
>>>> of B'odard can undertake his Quest.
>>>>
>>>> speaking for myself, if I don't do my assignments
>>>> more or less immediately I will not get to them for ages,
>>>> so I favour a short window (say, 3 weeks).
>>>>
>>>> Sebastian
>>
>>
>


-- 
Dr James Cummings, InfoDev,
Computing Services, University of Oxford

From James.Cummings at oucs.ox.ac.uk  Tue Apr 24 05:42:03 2012
From: James.Cummings at oucs.ox.ac.uk (James Cummings)
Date: Tue, 24 Apr 2012 10:42:03 +0100
Subject: [tei-council] next release?
In-Reply-To: <4F95C7A1.1080707@o2.pl>
References: <0F18A249-5480-42D9-BFF2-538AC7B9E1EB@oucs.ox.ac.uk>	<4F92F34D.2040103@uvic.ca>	<4F9579A0.8010002@oucs.ox.ac.uk>
	<4F95C7A1.1080707@o2.pl>
Message-ID: <4F96756B.1060202@oucs.ox.ac.uk>


What do others think? We can of course move releasing back to 
whenever we've finished a majority of tickets, but I'd prefer 
sooner rather than later and a deadline that forces us to get 
stuff done.

I'm of the opinion that we probably don't need to telco before 
this release (we can, after all, conduct business on the mailing 
list), but would do so shortly after the release to get updates 
on the longer-term issues and reports from the council working 
groups.

thoughts?

-James


On 23/04/12 22:20, Piotr Ba?ski wrote:
> Hi James,
>
> Isn't May 25 roughly in the middle of LREC? Could we shift by a week
> from then, please?
>
> (I actually intend to be ready with my stuff [and possibly more] in
> advance this time, but I've made some such totally honest promises to
> myself and to the world recently, several times, and with meager results...)
>
> Ah. Will we telco before releasing?
>
> Best,
>
>    P.
>
>
>
> On 23/04/12 17:47, James Cummings wrote:
>>
>> How about we set a notional target release date of 25 May?  (This
>> is about 5 weeks from now.) If we assume that we want most things
>> completed by the end of Sunday 20th, to allow time for
>> proofreading and error spotting.
>>
>> Does that sounds reasonable to most people?
>>
>> Gaby: Most importantly, does the proposed Release Technician like
>> these dates?
>>
>> -James
>>
>>
>> On 21/04/12 18:50, Martin Holmes wrote:
>>> Three weeks will be a bit tough for me, and a couple of the tickets I
>>> have might turn out to have unpredicted side-effects (like the tei_
>>> prefix). As long as we have the option to launch without the change if
>>> it proves difficult, we could go with three weeks.
>>>
>>> The attributes-without-examples problem is so large that we'll just have
>>> to hack away at it steadily.
>>>
>>> Cheers,
>>> Martin
>>>
>>> On 12-04-21 04:03 AM, Sebastian Rahtz wrote:
>>>> something we forgot to debate in Ann Arbor was a timetable
>>>> for the next release, I think? i.e. what is the due date for
>>>> everyone to complete their ticket work so that Sir Gabriel
>>>> of B'odard can undertake his Quest.
>>>>
>>>> speaking for myself, if I don't do my assignments
>>>> more or less immediately I will not get to them for ages,
>>>> so I favour a short window (say, 3 weeks).
>>>>
>>>> Sebastian
>>
>>
>


-- 
Dr James Cummings, InfoDev,
Computing Services, University of Oxford

From bansp at o2.pl  Tue Apr 24 07:03:04 2012
From: bansp at o2.pl (=?ISO-8859-2?Q?Piotr_Ba=F1ski?=)
Date: Tue, 24 Apr 2012 13:03:04 +0200
Subject: [tei-council] Prefacing ids with "tei_"
In-Reply-To: <4F95CD12.9070904@uvic.ca>
References: <4F95A3EF.7030509@uvic.ca> <4F95C669.7040709@o2.pl>
	<4F95CD12.9070904@uvic.ca>
Message-ID: <4F968868.5040708@o2.pl>

1. I agree that a positive message "please add to your filters a
positive exception for 'tei_.+'" is sociologically better than the
negative message "don't reject 'msad' because we happen to use it". It
has a better chance of being successful, even if only as courtesy of one
open-content developer to another.

2. prefacing all ids with "tei_" indeed seems more consistent, at least
it doesn't raise user questions of "why do you prefix here and not
there", which may, psychologically, contribute to the impression that
the TEI is more complex than it really is (which is quite complex anyway).

3. since (as I understand this) we're talking about an internal change
targetting the web Guidelines and related resources (also the kind of
output that should not be worked on directly), the results may be tested
and quickly fixed if necessary; and "being overprotective", which I
didn't like before, is restricted to giving an example of good practice
that is not imposed on the individual encoder.


So, despite my earlier nitpicks and Sebastian's remarks on why it is not
necessary from the point of view of the system to prefix all IDs, I tend
to agree that 2 and 3 above may swing the balance towards Martin's
uniform solution.

  P.


On 23/04/12 23:43, Martin Holmes wrote:
> On 12-04-23 02:15 PM, Piotr Ba?ski wrote:
>> Hi Martin,
>>
>> This may be a classic case of my missing the point, but something
>> doesn't click in my mind, so I'd better comment on that, just in case:
>>
>> On 23/04/12 20:48, Martin Holmes wrote:
>>> I'm planning to make a significant number of changes to Sebastian's
>>> stylesheets to implement our decision to preface all ids in the web
>>> output with "tei_", in an effort to avoid the problems caused by AdBlock
>>> Plus. Before I do, having looked at the code, there are a couple of
>>> things I wanted to get some feedback on:
>>>
>>> 1. Generated ids. There are some places in which ids in the output are
>>> generated using the XPath generate-id() function:
>> [..]
>>> These result in ids that look like random sequences of characters. Do we
>>> need to preface these with "tei_"? My instinct says yes -- after all,
>>> such a random sequence is perfectly likely to end up with content which
>>> might trigger an AdBlock filter, so we might as well protect it in the
>>> normal way.
>>
>> I understood that "msad" triggered the false positive, and the (arguable
>> and, IIRC, argued) decision was for the TEI to adjust to AdBlock.
> 
> Yes, the false positive was triggered by "msad".
> 
>> But if the problem was the matching of the entire string "msad" only (as
>> opposed to "tei_msad"), then i am led to conclude that a substring match
>> does not trigger the false positive. If that is true, then
>> generated-ids() can't within reasonable probability generate an
>> offensive string, and only that string (without extra characters).
> 
> It is possible to use regular expressions in Adblock Plus lists, so 
> partial matches may trigger a block. If this happens, one advantage of 
> our tei_ prefix will be that we can ask filter list writers to refine 
> their regexp to exclude our ids, using the prefix, while still remaining 
> able to block their original target. I think given that option, they'll 
> be more likely to respond to bug reports from us.
> 
>> As to your second question, I'd say the prefix introduces a layer of
>> safety indeed. But I'm not sure to what extent we as the Council need to
>> bother of someone using silly @n atts as the basis for a silly algorithm
>> of @n->@id. We might end up being overprotective here.
> 
> True. On consideration, I think we should add the prefix in all cases, 
> for the sake of consistency.
> 
> Cheers,
> Martin
> 
>> Best,
>>
>>    P.
>>
>>
>>
>>>
>>> 2. @n attributes. There's one place where the @n attribute can be used
>>> to create an id attribute in the output (in textstructure.xsl, code
>>> below). Should this also be prefaced by "tei_"? I'm not sure about this,
>>> because depending on the contents of the @n, the result might be
>>> puzzling. On the other hand, I don't think that @n can be relied upon to
>>> work as an id attribute anyway, can it?
>>>
>>> <xsl:variable name="identifier">
>>>            <xsl:text>App</xsl:text>
>>>            <xsl:choose>
>>> 	<xsl:when test="@xml:id">
>>> 	<xsl:value-of select="@xml:id"/>
>>> 	</xsl:when>
>>> 	<xsl:when test="@n">
>>> 	<xsl:value-of select="@n"/>
>>> 	</xsl:when>
>>> 	<xsl:otherwise>
>>> 	<xsl:number count="tei:app" level="any"/>
>>> 	</xsl:otherwise>
>>>            </xsl:choose>
>>>         </xsl:variable>
>>>
>>>         <xsl:choose>
>>>          <xsl:when test="$footnoteFile='true'">
>>> 	<a class="notelink" href="{$masterFile}-notes.html#{$identifier}">
>>> 	<sup>
>>> 	<xsl:call-template name="appN"/>
>>> 	</sup>
>>> 	</a>
>>>          </xsl:when>
>>>          <xsl:otherwise>
>>> 	<a class="notelink" href="#{$identifier}">
>>> 	<sup>
>>> 	<xsl:call-template name="appN"/>
>>> 	</sup>
>>> 	</a>
>>>          </xsl:otherwise>
>>>         </xsl:choose>
>>>
>>> Cheers,
>>> Martin
>>
> 


From bansp at o2.pl  Tue Apr 24 08:19:20 2012
From: bansp at o2.pl (=?ISO-8859-2?Q?Piotr_Ba=F1ski?=)
Date: Tue, 24 Apr 2012 14:19:20 +0200
Subject: [tei-council] next release?
In-Reply-To: <4F96756B.1060202@oucs.ox.ac.uk>
References: <0F18A249-5480-42D9-BFF2-538AC7B9E1EB@oucs.ox.ac.uk>	<4F92F34D.2040103@uvic.ca>	<4F9579A0.8010002@oucs.ox.ac.uk>	<4F95C7A1.1080707@o2.pl>
	<4F96756B.1060202@oucs.ox.ac.uk>
Message-ID: <4F969A48.30507@o2.pl>

I do agree that sooner is better... It's just that I tend to panic when
thinking of all the deadlines coming together :-)

As for the telco, it just seemed to me that the rapid interaction mode
may be useful for quick exchanges on some outstanding pre-release
issues, where we may lack energy for long e-mail discussions about
sometimes tiny details. Updates and reports, OTOH, seem a bit
monologueish in nature, and thus not requiring a telco (maybe).

(Let me note, however, that for 10 days before the 23rd, I am rather
sure that I will not be able to participate. Just mentioning that in
case you decide to have a pre-release telco after all, with the release
on the 25th -- so that it doesn't look like I was arguing for that and
then decided to abstain.)

Best,

  P.


On 24/04/12 11:42, James Cummings wrote:
> 
> What do others think? We can of course move releasing back to 
> whenever we've finished a majority of tickets, but I'd prefer 
> sooner rather than later and a deadline that forces us to get 
> stuff done.
> 
> I'm of the opinion that we probably don't need to telco before 
> this release (we can, after all, conduct business on the mailing 
> list), but would do so shortly after the release to get updates 
> on the longer-term issues and reports from the council working 
> groups.
> 
> thoughts?
> 
> -James
> 
> 
> On 23/04/12 22:20, Piotr Ba?ski wrote:
>> Hi James,
>>
>> Isn't May 25 roughly in the middle of LREC? Could we shift by a week
>> from then, please?
>>
>> (I actually intend to be ready with my stuff [and possibly more] in
>> advance this time, but I've made some such totally honest promises to
>> myself and to the world recently, several times, and with meager results...)
>>
>> Ah. Will we telco before releasing?
>>
>> Best,
>>
>>    P.
>>
>>
>>
>> On 23/04/12 17:47, James Cummings wrote:
>>>
>>> How about we set a notional target release date of 25 May?  (This
>>> is about 5 weeks from now.) If we assume that we want most things
>>> completed by the end of Sunday 20th, to allow time for
>>> proofreading and error spotting.
>>>
>>> Does that sounds reasonable to most people?
>>>
>>> Gaby: Most importantly, does the proposed Release Technician like
>>> these dates?
>>>
>>> -James
>>>
>>>
>>> On 21/04/12 18:50, Martin Holmes wrote:
>>>> Three weeks will be a bit tough for me, and a couple of the tickets I
>>>> have might turn out to have unpredicted side-effects (like the tei_
>>>> prefix). As long as we have the option to launch without the change if
>>>> it proves difficult, we could go with three weeks.
>>>>
>>>> The attributes-without-examples problem is so large that we'll just have
>>>> to hack away at it steadily.
>>>>
>>>> Cheers,
>>>> Martin
>>>>
>>>> On 12-04-21 04:03 AM, Sebastian Rahtz wrote:
>>>>> something we forgot to debate in Ann Arbor was a timetable
>>>>> for the next release, I think? i.e. what is the due date for
>>>>> everyone to complete their ticket work so that Sir Gabriel
>>>>> of B'odard can undertake his Quest.
>>>>>
>>>>> speaking for myself, if I don't do my assignments
>>>>> more or less immediately I will not get to them for ages,
>>>>> so I favour a short window (say, 3 weeks).
>>>>>
>>>>> Sebastian
>>>
>>>
>>
> 
> 


From bansp at o2.pl  Wed Apr 25 07:26:22 2012
From: bansp at o2.pl (=?ISO-8859-2?Q?Piotr_Ba=F1ski?=)
Date: Wed, 25 Apr 2012 13:26:22 +0200
Subject: [tei-council] targetLang in att.pointing and schemaSpec
In-Reply-To: <CAC_Lu0aeSZBOpxEK6zndQ99jhiV-aMZfcbupkqe8jxmnwOibsw@mail.gmail.com>
References: <4F908F22.4070908@uvic.ca>
	<4F90AD72.10605@uvic.ca>	<4F90AEBC.6000608@ultraslavonic.info>
	<4F9573BF.1080302@uvic.ca>	<4F957C03.8090008@oucs.ox.ac.uk>
	<4F9580F6.4080505@uvic.ca>	<4F9584B7.3080302@uvic.ca>
	<CAC_Lu0aeSZBOpxEK6zndQ99jhiV-aMZfcbupkqe8jxmnwOibsw@mail.gmail.com>
Message-ID: <4F97DF5E.6050308@o2.pl>

Thanks to Stuart's wiki list, I noticed that targetLang is now defined
in two places: (a) att.pointing (new) and (b) schemaSpec (old).

They don't differ in the datatype, but in the semantics ((a) identifies,
(b) apparently prescribes) and the context ((a) accompanies @target and
points at a remote resource, (b) acts locally; the Schematron rule for
(a) is not applicable to (b)).

(b) is listed in 23.4.1 (description pulled from the spec, there is no
independent discussion of it), and actually, I don't fully understand
what it is meant to do: "specifies which language to use when creating
the objects in a schema if names for elements or attributes are
available in more than one language".

What should I do?

1. leave them as they are, effectively (b) becoming now a local override
of (a), just like in the case of e.g. @type (but note that the situation
is not fully analogous!)

2. rename (a), but it makes so much sense to leave this name, cf. [1],
because it really nicely goes together with @target, and renaming it to
the originally suggested "refLang" would create the somewhat misleading
network of @target, @refLang (supposed to always accompany @target) and
@targetLang (supposed NOT to accompany @target).

[1]:
https://sourceforge.net/tracker/index.php?func=detail&aid=3288293&group_id=106328&atid=644065

3. create a ticket for renaming (b) to e.g. objectLang (as its
description suggests)?

Thanks,

  P.

From mholmes at uvic.ca  Wed Apr 25 08:45:48 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Wed, 25 Apr 2012 05:45:48 -0700
Subject: [tei-council] targetLang in att.pointing and schemaSpec
In-Reply-To: <4F97DF5E.6050308@o2.pl>
References: <4F908F22.4070908@uvic.ca>	<4F90AD72.10605@uvic.ca>
	<4F90AEBC.6000608@ultraslavonic.info>	<4F9573BF.1080302@uvic.ca>
	<4F957C03.8090008@oucs.ox.ac.uk>	<4F9580F6.4080505@uvic.ca>
	<4F9584B7.3080302@uvic.ca>
	<CAC_Lu0aeSZBOpxEK6zndQ99jhiV-aMZfcbupkqe8jxmnwOibsw@mail.gmail.com>
	<4F97DF5E.6050308@o2.pl>
Message-ID: <4F97F1FC.4060003@uvic.ca>

I think the original @targetLang on <schemaSpec> is doing a completely 
different job from the new one, isn't it? I think its purpose and 
semantics are clear from the description:

<http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-schemaSpec.html>

although I don't know if anyone has ever used it. Given that ODD is 
meant to be broader than TEI, someone may well use it at some point, if 
they're working with a specification that allows element or attribute 
names in different languages, so I'd recommend leaving it. I think it's 
OK to have two attributes with the same name doing different jobs in 
different contexts (although it's obviously not ideal). If we were to 
make a change, I'd recommend changing schemaSpec/@targetLang to 
@namingLang, or something like that.

Cheers,
Martin

On 12-04-25 04:26 AM, Piotr Ba?ski wrote:
> Thanks to Stuart's wiki list, I noticed that targetLang is now defined
> in two places: (a) att.pointing (new) and (b) schemaSpec (old).
>
> They don't differ in the datatype, but in the semantics ((a) identifies,
> (b) apparently prescribes) and the context ((a) accompanies @target and
> points at a remote resource, (b) acts locally; the Schematron rule for
> (a) is not applicable to (b)).
>
> (b) is listed in 23.4.1 (description pulled from the spec, there is no
> independent discussion of it), and actually, I don't fully understand
> what it is meant to do: "specifies which language to use when creating
> the objects in a schema if names for elements or attributes are
> available in more than one language".
>
> What should I do?
>
> 1. leave them as they are, effectively (b) becoming now a local override
> of (a), just like in the case of e.g. @type (but note that the situation
> is not fully analogous!)
>
> 2. rename (a), but it makes so much sense to leave this name, cf. [1],
> because it really nicely goes together with @target, and renaming it to
> the originally suggested "refLang" would create the somewhat misleading
> network of @target, @refLang (supposed to always accompany @target) and
> @targetLang (supposed NOT to accompany @target).
>
> [1]:
> https://sourceforge.net/tracker/index.php?func=detail&aid=3288293&group_id=106328&atid=644065
>
> 3. create a ticket for renaming (b) to e.g. objectLang (as its
> description suggests)?
>
> Thanks,
>
>    P.

From bansp at o2.pl  Wed Apr 25 10:17:13 2012
From: bansp at o2.pl (=?ISO-8859-2?Q?Piotr_Ba=F1ski?=)
Date: Wed, 25 Apr 2012 16:17:13 +0200
Subject: [tei-council] targetLang in att.pointing and schemaSpec
In-Reply-To: <4F97F1FC.4060003@uvic.ca>
References: <4F908F22.4070908@uvic.ca>	<4F90AD72.10605@uvic.ca>	<4F90AEBC.6000608@ultraslavonic.info>	<4F9573BF.1080302@uvic.ca>	<4F957C03.8090008@oucs.ox.ac.uk>	<4F9580F6.4080505@uvic.ca>	<4F9584B7.3080302@uvic.ca>	<CAC_Lu0aeSZBOpxEK6zndQ99jhiV-aMZfcbupkqe8jxmnwOibsw@mail.gmail.com>	<4F97DF5E.6050308@o2.pl>
	<4F97F1FC.4060003@uvic.ca>
Message-ID: <4F980769.2070103@o2.pl>

On 25/04/12 14:45, Martin Holmes wrote:
> I think the original @targetLang on <schemaSpec> is doing a completely 
> different job from the new one, isn't it? I think its purpose and 
> semantics are clear from the description:
> 
> <http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-schemaSpec.html>

Indeed, on the second reading I understand what these "objects" are
supposed to be. And you're right, namingLang would be a reasonable
choice, targetLang seems actually a bit unfortunate in this context.

  P.

> although I don't know if anyone has ever used it. Given that ODD is 
> meant to be broader than TEI, someone may well use it at some point, if 
> they're working with a specification that allows element or attribute 
> names in different languages, so I'd recommend leaving it. I think it's 
> OK to have two attributes with the same name doing different jobs in 
> different contexts (although it's obviously not ideal). If we were to 
> make a change, I'd recommend changing schemaSpec/@targetLang to 
> @namingLang, or something like that.
> 
> Cheers,
> Martin
> 
> On 12-04-25 04:26 AM, Piotr Ba?ski wrote:
>> Thanks to Stuart's wiki list, I noticed that targetLang is now defined
>> in two places: (a) att.pointing (new) and (b) schemaSpec (old).
>>
>> They don't differ in the datatype, but in the semantics ((a) identifies,
>> (b) apparently prescribes) and the context ((a) accompanies @target and
>> points at a remote resource, (b) acts locally; the Schematron rule for
>> (a) is not applicable to (b)).
>>
>> (b) is listed in 23.4.1 (description pulled from the spec, there is no
>> independent discussion of it), and actually, I don't fully understand
>> what it is meant to do: "specifies which language to use when creating
>> the objects in a schema if names for elements or attributes are
>> available in more than one language".
>>
>> What should I do?
>>
>> 1. leave them as they are, effectively (b) becoming now a local override
>> of (a), just like in the case of e.g. @type (but note that the situation
>> is not fully analogous!)
>>
>> 2. rename (a), but it makes so much sense to leave this name, cf. [1],
>> because it really nicely goes together with @target, and renaming it to
>> the originally suggested "refLang" would create the somewhat misleading
>> network of @target, @refLang (supposed to always accompany @target) and
>> @targetLang (supposed NOT to accompany @target).
>>
>> [1]:
>> https://sourceforge.net/tracker/index.php?func=detail&aid=3288293&group_id=106328&atid=644065
>>
>> 3. create a ticket for renaming (b) to e.g. objectLang (as its
>> description suggests)?
>>
>> Thanks,
>>
>>    P.


From lou.burnard at retired.ox.ac.uk  Wed Apr 25 10:17:39 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Wed, 25 Apr 2012 15:17:39 +0100
Subject: [tei-council] targetLang in att.pointing and schemaSpec
In-Reply-To: <4F97F1FC.4060003@uvic.ca>
References: <4F908F22.4070908@uvic.ca>	<4F90AD72.10605@uvic.ca>
	<4F90AEBC.6000608@ultraslavonic.info>	<4F9573BF.1080302@uvic.ca>
	<4F957C03.8090008@oucs.ox.ac.uk>	<4F9580F6.4080505@uvic.ca>
	<4F9584B7.3080302@uvic.ca>
	<CAC_Lu0aeSZBOpxEK6zndQ99jhiV-aMZfcbupkqe8jxmnwOibsw@mail.gmail.com>
	<4F97DF5E.6050308@o2.pl> <4F97F1FC.4060003@uvic.ca>
Message-ID: <4F980783.7060900@retired.ox.ac.uk>

The @targetLang in <schemaSpec> is used by Roma, or should be, if you 
say you want to generate a schema in which the element identifiers use 
some language other than English. It then selects the <altIdentifier>
for that language rather than the default. Or so I believe.

Seems to me this is not entirely dissimilar to what the new @targetLang 
is meant to imply. But since we do currently use it, I think it might be 
better to try to find a different name for this new attribute.

  On 25/04/12 13:45, Martin Holmes wrote:
> I think the original @targetLang on<schemaSpec>  is doing a completely
> different job from the new one, isn't it? I think its purpose and
> semantics are clear from the description:
>
> <http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-schemaSpec.html>
>
> although I don't know if anyone has ever used it. Given that ODD is
> meant to be broader than TEI, someone may well use it at some point, if
> they're working with a specification that allows element or attribute
> names in different languages, so I'd recommend leaving it. I think it's
> OK to have two attributes with the same name doing different jobs in
> different contexts (although it's obviously not ideal). If we were to
> make a change, I'd recommend changing schemaSpec/@targetLang to
> @namingLang, or something like that.
>
> Cheers,
> Martin
>
> On 12-04-25 04:26 AM, Piotr Ba?ski wrote:
>> Thanks to Stuart's wiki list, I noticed that targetLang is now defined
>> in two places: (a) att.pointing (new) and (b) schemaSpec (old).
>>
>> They don't differ in the datatype, but in the semantics ((a) identifies,
>> (b) apparently prescribes) and the context ((a) accompanies @target and
>> points at a remote resource, (b) acts locally; the Schematron rule for
>> (a) is not applicable to (b)).
>>
>> (b) is listed in 23.4.1 (description pulled from the spec, there is no
>> independent discussion of it), and actually, I don't fully understand
>> what it is meant to do: "specifies which language to use when creating
>> the objects in a schema if names for elements or attributes are
>> available in more than one language".
>>
>> What should I do?
>>
>> 1. leave them as they are, effectively (b) becoming now a local override
>> of (a), just like in the case of e.g. @type (but note that the situation
>> is not fully analogous!)
>>
>> 2. rename (a), but it makes so much sense to leave this name, cf. [1],
>> because it really nicely goes together with @target, and renaming it to
>> the originally suggested "refLang" would create the somewhat misleading
>> network of @target, @refLang (supposed to always accompany @target) and
>> @targetLang (supposed NOT to accompany @target).
>>
>> [1]:
>> https://sourceforge.net/tracker/index.php?func=detail&aid=3288293&group_id=106328&atid=644065
>>
>> 3. create a ticket for renaming (b) to e.g. objectLang (as its
>> description suggests)?
>>
>> Thanks,
>>
>>     P.


From lou.burnard at retired.ox.ac.uk  Wed Apr 25 10:33:52 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Wed, 25 Apr 2012 15:33:52 +0100
Subject: [tei-council] targetLang in att.pointing and schemaSpec
In-Reply-To: <4F980769.2070103@o2.pl>
References: <4F908F22.4070908@uvic.ca>	<4F90AD72.10605@uvic.ca>	<4F90AEBC.6000608@ultraslavonic.info>	<4F9573BF.1080302@uvic.ca>	<4F957C03.8090008@oucs.ox.ac.uk>	<4F9580F6.4080505@uvic.ca>	<4F9584B7.3080302@uvic.ca>	<CAC_Lu0aeSZBOpxEK6zndQ99jhiV-aMZfcbupkqe8jxmnwOibsw@mail.gmail.com>	<4F97DF5E.6050308@o2.pl>
	<4F97F1FC.4060003@uvic.ca> <4F980769.2070103@o2.pl>
Message-ID: <4F980B50.7010607@retired.ox.ac.uk>

Sorry, I disagree.

We currently use @targetLang on <schemaSpec> with quite a plausible 
meaning. If that meaning isn't appropriate for the new attribute, it's 
the new guy who has to be renamed not the existing one.


On 25/04/12 15:17, Piotr Ba?ski wrote:
> On 25/04/12 14:45, Martin Holmes wrote:
>> I think the original @targetLang on<schemaSpec>  is doing a completely
>> different job from the new one, isn't it? I think its purpose and
>> semantics are clear from the description:
>>
>> <http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-schemaSpec.html>
>
> Indeed, on the second reading I understand what these "objects" are
> supposed to be. And you're right, namingLang would be a reasonable
> choice, targetLang seems actually a bit unfortunate in this context.
>
>    P.
>
>> although I don't know if anyone has ever used it. Given that ODD is
>> meant to be broader than TEI, someone may well use it at some point, if
>> they're working with a specification that allows element or attribute
>> names in different languages, so I'd recommend leaving it. I think it's
>> OK to have two attributes with the same name doing different jobs in
>> different contexts (although it's obviously not ideal). If we were to
>> make a change, I'd recommend changing schemaSpec/@targetLang to
>> @namingLang, or something like that.
>>
>> Cheers,
>> Martin
>>
>> On 12-04-25 04:26 AM, Piotr Ba?ski wrote:
>>> Thanks to Stuart's wiki list, I noticed that targetLang is now defined
>>> in two places: (a) att.pointing (new) and (b) schemaSpec (old).
>>>
>>> They don't differ in the datatype, but in the semantics ((a) identifies,
>>> (b) apparently prescribes) and the context ((a) accompanies @target and
>>> points at a remote resource, (b) acts locally; the Schematron rule for
>>> (a) is not applicable to (b)).
>>>
>>> (b) is listed in 23.4.1 (description pulled from the spec, there is no
>>> independent discussion of it), and actually, I don't fully understand
>>> what it is meant to do: "specifies which language to use when creating
>>> the objects in a schema if names for elements or attributes are
>>> available in more than one language".
>>>
>>> What should I do?
>>>
>>> 1. leave them as they are, effectively (b) becoming now a local override
>>> of (a), just like in the case of e.g. @type (but note that the situation
>>> is not fully analogous!)
>>>
>>> 2. rename (a), but it makes so much sense to leave this name, cf. [1],
>>> because it really nicely goes together with @target, and renaming it to
>>> the originally suggested "refLang" would create the somewhat misleading
>>> network of @target, @refLang (supposed to always accompany @target) and
>>> @targetLang (supposed NOT to accompany @target).
>>>
>>> [1]:
>>> https://sourceforge.net/tracker/index.php?func=detail&aid=3288293&group_id=106328&atid=644065
>>>
>>> 3. create a ticket for renaming (b) to e.g. objectLang (as its
>>> description suggests)?
>>>
>>> Thanks,
>>>
>>>     P.
>


From bansp at o2.pl  Wed Apr 25 10:48:50 2012
From: bansp at o2.pl (=?ISO-8859-2?Q?Piotr_Ba=F1ski?=)
Date: Wed, 25 Apr 2012 16:48:50 +0200
Subject: [tei-council] targetLang in att.pointing and schemaSpec
In-Reply-To: <4F980B50.7010607@retired.ox.ac.uk>
References: <4F908F22.4070908@uvic.ca>	<4F90AD72.10605@uvic.ca>	<4F90AEBC.6000608@ultraslavonic.info>	<4F9573BF.1080302@uvic.ca>	<4F957C03.8090008@oucs.ox.ac.uk>	<4F9580F6.4080505@uvic.ca>	<4F9584B7.3080302@uvic.ca>	<CAC_Lu0aeSZBOpxEK6zndQ99jhiV-aMZfcbupkqe8jxmnwOibsw@mail.gmail.com>	<4F97DF5E.6050308@o2.pl>	<4F97F1FC.4060003@uvic.ca>
	<4F980769.2070103@o2.pl> <4F980B50.7010607@retired.ox.ac.uk>
Message-ID: <4F980ED2.4070400@o2.pl>

I wasn't saying "let's change the old one" -- the option of leaving
both, by analogy to overriding @type, seems acceptable.

As for whether "targetLang" is great for referring to tags and attribute
names, well, my point is that the name doesn't suggest anything like
that to someone who isn't simply used to it. It could just as well be
used to refer to the language of documentation or whatever else, since
"target" in this case means nearly "anything I tell you this should
mean, with some pointing/directionality implied". This meaning is
appropriate for half the attributes, including many new guys.

I'm not pressing in any direction, though if I were forced to take a
stand, I'd probably vote on "keep both", because I understand the value
of not modifying stuff that doesn't badly need to be modified, and I see
certain advantages of maintaining the "target" part of "targetLang" in
connection with the one used for identifying the language that @target
points to (your own suggestion, Lou, BTW).

best,

  P.

On 25/04/12 16:33, Lou Burnard wrote:
> Sorry, I disagree.
> 
> We currently use @targetLang on <schemaSpec> with quite a plausible 
> meaning. If that meaning isn't appropriate for the new attribute, it's 
> the new guy who has to be renamed not the existing one.
> 
> 
> On 25/04/12 15:17, Piotr Ba?ski wrote:
>> On 25/04/12 14:45, Martin Holmes wrote:
>>> I think the original @targetLang on<schemaSpec>  is doing a completely
>>> different job from the new one, isn't it? I think its purpose and
>>> semantics are clear from the description:
>>>
>>> <http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-schemaSpec.html>
>>
>> Indeed, on the second reading I understand what these "objects" are
>> supposed to be. And you're right, namingLang would be a reasonable
>> choice, targetLang seems actually a bit unfortunate in this context.
>>
>>    P.
>>
>>> although I don't know if anyone has ever used it. Given that ODD is
>>> meant to be broader than TEI, someone may well use it at some point, if
>>> they're working with a specification that allows element or attribute
>>> names in different languages, so I'd recommend leaving it. I think it's
>>> OK to have two attributes with the same name doing different jobs in
>>> different contexts (although it's obviously not ideal). If we were to
>>> make a change, I'd recommend changing schemaSpec/@targetLang to
>>> @namingLang, or something like that.
>>>
>>> Cheers,
>>> Martin
>>>
>>> On 12-04-25 04:26 AM, Piotr Ba?ski wrote:
>>>> Thanks to Stuart's wiki list, I noticed that targetLang is now defined
>>>> in two places: (a) att.pointing (new) and (b) schemaSpec (old).
>>>>
>>>> They don't differ in the datatype, but in the semantics ((a) identifies,
>>>> (b) apparently prescribes) and the context ((a) accompanies @target and
>>>> points at a remote resource, (b) acts locally; the Schematron rule for
>>>> (a) is not applicable to (b)).
>>>>
>>>> (b) is listed in 23.4.1 (description pulled from the spec, there is no
>>>> independent discussion of it), and actually, I don't fully understand
>>>> what it is meant to do: "specifies which language to use when creating
>>>> the objects in a schema if names for elements or attributes are
>>>> available in more than one language".
>>>>
>>>> What should I do?
>>>>
>>>> 1. leave them as they are, effectively (b) becoming now a local override
>>>> of (a), just like in the case of e.g. @type (but note that the situation
>>>> is not fully analogous!)
>>>>
>>>> 2. rename (a), but it makes so much sense to leave this name, cf. [1],
>>>> because it really nicely goes together with @target, and renaming it to
>>>> the originally suggested "refLang" would create the somewhat misleading
>>>> network of @target, @refLang (supposed to always accompany @target) and
>>>> @targetLang (supposed NOT to accompany @target).
>>>>
>>>> [1]:
>>>> https://sourceforge.net/tracker/index.php?func=detail&aid=3288293&group_id=106328&atid=644065
>>>>
>>>> 3. create a ticket for renaming (b) to e.g. objectLang (as its
>>>> description suggests)?
>>>>
>>>> Thanks,
>>>>
>>>>     P.
>>
> 


From lou.burnard at retired.ox.ac.uk  Wed Apr 25 10:58:18 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Wed, 25 Apr 2012 15:58:18 +0100
Subject: [tei-council] targetLang in att.pointing and schemaSpec
In-Reply-To: <4F980ED2.4070400@o2.pl>
References: <4F908F22.4070908@uvic.ca>	<4F90AD72.10605@uvic.ca>	<4F90AEBC.6000608@ultraslavonic.info>	<4F9573BF.1080302@uvic.ca>	<4F957C03.8090008@oucs.ox.ac.uk>	<4F9580F6.4080505@uvic.ca>	<4F9584B7.3080302@uvic.ca>	<CAC_Lu0aeSZBOpxEK6zndQ99jhiV-aMZfcbupkqe8jxmnwOibsw@mail.gmail.com>	<4F97DF5E.6050308@o2.pl>	<4F97F1FC.4060003@uvic.ca>
	<4F980769.2070103@o2.pl> <4F980B50.7010607@retired.ox.ac.uk>
	<4F980ED2.4070400@o2.pl>
Message-ID: <4F98110A.5060805@retired.ox.ac.uk>

On 25/04/12 15:48, Piotr Ba?ski wrote:
> I wasn't saying "let's change the old one" -- the option of leaving
> both, by analogy to overriding @type, seems acceptable.

No, but Martin was.

>
> As for whether "targetLang" is great for referring to tags and attribute
> names, well, my point is that the name doesn't suggest anything like
> that to someone who isn't simply used to it. It could just as well be
> used to refer to the language of documentation

That's what @docLang is for

>
> I'm not pressing in any direction, though if I were forced to take a
> stand, I'd probably vote on "keep both", because I understand the value
> of not modifying stuff that doesn't badly need to be modified, and I see
> certain advantages of maintaining the "target" part of "targetLang" in
> connection with the one used for identifying the language that @target
> points to (your own suggestion, Lou, BTW).
>

which is why I am also happy with keeping the same name for both attributes!


From kevin.s.hawkins at ultraslavonic.info  Wed Apr 25 11:05:45 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Wed, 25 Apr 2012 11:05:45 -0400
Subject: [tei-council] removing and renaming XML files
In-Reply-To: <4F91E0F9.4050205@retired.ox.ac.uk>
References: <4F910341.8070906@gmail.com>	<4F916121.3040808@o2.pl>	<4F919FC1.2030400@retired.ox.ac.uk>	<4F91B7DF.2080209@ultraslavonic.info>
	<4F91E0F9.4050205@retired.ox.ac.uk>
Message-ID: <4F9812C9.5060805@ultraslavonic.info>

On 4/20/2012 6:19 PM, Lou Burnard wrote:
> I still think that on balance it's not worth the effort of renaming the
> chapter file. But then I was also the one who wanted to leave it with
> the name "DI,xml" on the grounds that introducing more information into
> file names would only lead to tears before bedtime. And lo...

I still don't understand what complications renaming will introduce.

Cross-references to chapters are already of the form

<ptr target="#DI"/>

and all files online are still named according to the form "DI.html".

So if we rename

DI-PrintDictionaries.xml

to

DI-Dictionaries.xml

to match what's actually used in the div[@type='div1']/head of that 
chapter, what would be the problem?

The advantage is that it makes it easier for us to find the right file 
(based on the name of the chapter).  The only problem I can imagine is 
that it disrupts the version control history, but maybe there's a way to 
mend that in Subversion that I'm not aware of.

--Kevin

From bansp at o2.pl  Wed Apr 25 11:24:40 2012
From: bansp at o2.pl (=?ISO-8859-2?Q?Piotr_Ba=F1ski?=)
Date: Wed, 25 Apr 2012 17:24:40 +0200
Subject: [tei-council] removing and renaming XML files
In-Reply-To: <4F91B7DF.2080209@ultraslavonic.info>
References: <4F910341.8070906@gmail.com>
	<4F916121.3040808@o2.pl>	<4F919FC1.2030400@retired.ox.ac.uk>
	<4F91B7DF.2080209@ultraslavonic.info>
Message-ID: <4F981738.1000203@o2.pl>

[re-reading this thread; I somehow managed to completely overlook it.
But as for...]

On 20/04/12 21:24, Kevin Hawkins wrote:
[...]

> I 
> think I've found a chair for a rechartered physical bibliography group 
> who can lead the many people who have expressed interest in the group 
> but been unwilling to lead the effort.  I asked her to draft a new 
> charter that I could share with Council before the group gets started 
> (in case we feel they are headed in entirely the wrong direction).

Congrats! :-)

  P.

From bansp at o2.pl  Wed Apr 25 11:45:02 2012
From: bansp at o2.pl (=?ISO-8859-2?Q?Piotr_Ba=F1ski?=)
Date: Wed, 25 Apr 2012 17:45:02 +0200
Subject: [tei-council] removing and renaming XML files
In-Reply-To: <4F91B7DF.2080209@ultraslavonic.info>
References: <4F910341.8070906@gmail.com>
	<4F916121.3040808@o2.pl>	<4F919FC1.2030400@retired.ox.ac.uk>
	<4F91B7DF.2080209@ultraslavonic.info>
Message-ID: <4F981BFE.7070805@o2.pl>

On 20/04/12 21:24, Kevin Hawkins wrote:
> On 4/20/2012 1:41 PM, Lou Burnard wrote:
>> On 20/04/12 14:14, Piotr Ba?ski wrote:
>>> On 20/04/12 08:33, stuart yeates wrote:
>>> [..]
>>>> I would also like to rename:
>>>>
>>>> P5/Source/Guidelines/*/DI-PrintDictionaries.xml
>>>>
>>>> to
>>>>
>>>> P5/Source/Guidelines/*/DI-Dictionaries.xml
>>>>
>>>> because this chapter covers born-digital dictionaries too.
>>
>>
>> I don't think changing the filename of this chapter is warranted as yet.
>> There was some discussion about extending its coverage so as to deliver
>> more specifically on the promise made in its first chapter that its
>> content could also be applied to non-print dictionaries, but so far that
>> extension  hasn't happened yet.
> 
> Lou, do you mean "the promise made in the first section of this chapter"?
> 
> The title of the chapter given in the HTML and PDF versions of the 
> Guidelines is already "Dictionaries", not "Print Dictionaries", so I 
> think Piotr is suggesting renaming the file to match the human-readable 
> form actually in use.

Got it: quoting accident. Lou quoted my reply to Stuart, but without my
response, and Kevin ascribed Stuart's idea to me.

Here's the summary, as I see it:
* Stuart suggests changing the filename
* I understand the reason for the change, but I'm afraid that the links
from outside to the published chapter of the P5 will break. I'm wrong
(see below)
* Sebastian says, roughly "well, if it's really necessary..."
* Lou says "not yet"

I forgot that the URL
http://www.tei-c.org/release/doc/tei-p5-doc/en/html/DI.html

doesn't use the long name anyway, so there would be no problem with
outside links even if the chapter name were to changes already in P5.

I think that the DI chapter *is* used as guidelines for encoding
electronic dictionaries (in the "lexical" view), exactly because nothing
better exists. So the "Print" in the filename is indeed misleading, but
the question is, who does it potentially mislead? If it only misleads
us, the cost is relatively low, because we're just several people who
will now remember the naming issue well, if we don't already use "DI" as
the identifier.

I'm rather lukewarm on this issue -- I'm glad that the title of this
chapter got changed (in 2007?), and the underlying filename doesn't
bother me too much (unless I've missed something important in the
summary above).

Best,

  P.

From syeates at gmail.com  Wed Apr 25 13:41:39 2012
From: syeates at gmail.com (stuart yeates)
Date: Thu, 26 Apr 2012 05:41:39 +1200
Subject: [tei-council] removing and renaming XML files
In-Reply-To: <4F981BFE.7070805@o2.pl>
References: <4F910341.8070906@gmail.com>
	<4F916121.3040808@o2.pl>	<4F919FC1.2030400@retired.ox.ac.uk>
	<4F91B7DF.2080209@ultraslavonic.info> <4F981BFE.7070805@o2.pl>
Message-ID: <4F983753.2070308@gmail.com>

On 26/04/12 03:45, Piotr Ba?ski wrote:

 > ... but
> the question is, who does it potentially mislead?

It also misleads every person we try and recruit to do technical work on 
the TEI, increasing the barrier to entry.

cheers
stuart



From bansp at o2.pl  Wed Apr 25 13:53:55 2012
From: bansp at o2.pl (=?ISO-8859-2?Q?Piotr_Ba=F1ski?=)
Date: Wed, 25 Apr 2012 19:53:55 +0200
Subject: [tei-council] removing and renaming XML files
In-Reply-To: <4F983753.2070308@gmail.com>
References: <4F910341.8070906@gmail.com>	<4F916121.3040808@o2.pl>	<4F919FC1.2030400@retired.ox.ac.uk>	<4F91B7DF.2080209@ultraslavonic.info>
	<4F981BFE.7070805@o2.pl> <4F983753.2070308@gmail.com>
Message-ID: <4F983A33.2010600@o2.pl>

Hi Stuart,

On 25/04/12 19:41, stuart yeates wrote:
> On 26/04/12 03:45, Piotr Ba?ski wrote:
> 
>  > ... but
>> the question is, who does it potentially mislead?
> 
> It also misleads every person we try and recruit to do technical work on 
> the TEI, increasing the barrier to entry.

I agree with the principle, but disagree with the detail. I think that
if someone is able to stumble on the difference between
"DI-PrintDictionaries" and "DI-Dictionaries" and run away as a result,
then, well, maybe we should be glad the difference is there. ;-)

Let me stress: I'm lukewarm wrt this issue overall, the above is just my
reaction to the "increasing the barrier" argument, which is true for
some cases, but not so obvious to me in this one.

Best,

  P.

From bansp at o2.pl  Wed Apr 25 16:40:04 2012
From: bansp at o2.pl (=?ISO-8859-2?Q?Piotr_Ba=F1ski?=)
Date: Wed, 25 Apr 2012 22:40:04 +0200
Subject: [tei-council] DCR alignment inside ODD
Message-ID: <4F986124.30406@o2.pl>

I'm working on the ISO DCR / ISOcat issues.[1] Got stuck at the point of
adding the relevant pieces of text to the Guidelines.

The enlightened way to align grammatical categories with the values of
the DCR is to put the appropriate references into the ODD, and I guess
<equiv> is the ideal place for that.

I imagine, and please correct me if I am wrong, that for elements such
as <pos>, this action may be trivial:

<elementSpec ident="pos" mode="change">
   <equiv dcr:datcat="http://www.isocat.org/datcat/DC-1345"/>
</elementSpec>

(I'm skipping several issues to try to focus on the main one [2])

The above makes it possible for us to happily realize that whenever we
do e.g.

<gramGrp><pos>...</pos></gramGrp>

all the machines in the world may know that by <pos>, we mean
http://www.isocat.org/datcat/DC-1345 .

However, there is also the content of <pos> to be handled, and it is not
so obvious to me how to represent this in the ODD. Intuitively, I'm
thinking of

<elementSpec>
...
<content>
 {list of values with their DCR references}
</content>
...

except I can't pull this off in the TEI -- I need to use RNG (and it's
not so obvious to me right now, how exactly). But this is not the idea
of the exercise, is it: the idea was to make the creation of DCR
references available to an average hum... well, say, electronic
lexicographer or corpus linguist. Actually, to encourage the creation of
such references.

Do I misunderstand something?
(at this point, I'm adding a CC to Laurent, and will relay his reply if
he finds the time to provide any)

In Zadar, I presented a solution whereby I encoded this sort of
information inside the header. I was told no no no, it belongs in the
ODD. Now I'm wondering if we're not back to the header, after all.[3]

I'll be grateful for any hints you can offer.

Thanks and good night,

  Piotr


[1]:
https://sourceforge.net/tracker/index.php?func=detail&aid=3432520&group_id=106328&atid=644065

[2]: One such issue is: but do we modify the TEI Spec for <pos> thus or
do we let each encoder do it on their own? My answer would be the
latter, because there is no single reference for POS.

[3]: And in some cases, I actually still firmly believe that the header
is the only place to do that efficiently; I may actually have a topic
for the next TEI-MM...




From sebastian.rahtz at oucs.ox.ac.uk  Wed Apr 25 16:59:00 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Wed, 25 Apr 2012 20:59:00 +0000
Subject: [tei-council] DCR alignment inside ODD
In-Reply-To: <4F986124.30406@o2.pl>
References: <4F986124.30406@o2.pl>
Message-ID: <4F26B857-B17C-4819-A224-2678E5ADD75A@oucs.ox.ac.uk>


On 25 Apr 2012, at 21:40, Piotr Ba?ski wrote:

> I'm working on the ISO DCR / ISOcat issues.[1] Got stuck at the point of
> adding the relevant pieces of text to the Guidelines.
> 
> The enlightened way to align grammatical categories with the values of
> the DCR is to put the appropriate references into the ODD, and I guess
> <equiv> is the ideal place for that.
> 
> I imagine, and please correct me if I am wrong, that for elements such
> as <pos>, this action may be trivial:
> 
> <elementSpec ident="pos" mode="change">
>   <equiv dcr:datcat="http://www.isocat.org/datcat/DC-1345"/>
> </elementSpec>

<equiv url="http://www.isocat.org/datcat/DC-1345"/> is the syntax, I think.

> The above makes it possible for us to happily realize that whenever we
> do e.g.
> 
> <gramGrp><pos>...</pos></gramGrp>
> 
> all the machines in the world may know that by <pos>, we mean
> http://www.isocat.org/datcat/DC-1345 .
well, if they read the ODD yes. I think there is a certain amount
of "simple matter of programming" involved here.

> 
> However, there is also the content of <pos> to be handled, and it is not
> so obvious to me how to represent this in the ODD. Intuitively, I'm
> thinking of
> 
> <elementSpec>
> ...
> <content>
> {list of values with their DCR references}
> </content>

a <elementSpec> can contain a <valList>, whose <valItem> children
can have <equiv> children

Does that help?

I suspect what you'd really like is to use a DTD which supplied default dcr:cat attributes to
instances of <pos>.

Sebastian


From gabriel.bodard at kcl.ac.uk  Wed Apr 25 17:02:43 2012
From: gabriel.bodard at kcl.ac.uk (Gabriel BODARD)
Date: Wed, 25 Apr 2012 22:02:43 +0100
Subject: [tei-council] next release?
In-Reply-To: <4F96756B.1060202@oucs.ox.ac.uk>
References: <0F18A249-5480-42D9-BFF2-538AC7B9E1EB@oucs.ox.ac.uk>
	<4F92F34D.2040103@uvic.ca>	<4F9579A0.8010002@oucs.ox.ac.uk>
	<4F95C7A1.1080707@o2.pl> <4F96756B.1060202@oucs.ox.ac.uk>
Message-ID: <4F986673.7020201@kcl.ac.uk>

The first week of June is likely to be bad for me; I'm back from 
international travel around the 4th, I think, and will be groggy the 
first couple days after that. So if not May 25th, then best to put it 
off by two weeks. (Or someone else be launch technician...)

G

On 24/04/2012 10:42, James Cummings wrote:
>
> What do others think? We can of course move releasing back to
> whenever we've finished a majority of tickets, but I'd prefer
> sooner rather than later and a deadline that forces us to get
> stuff done.
>
> I'm of the opinion that we probably don't need to telco before
> this release (we can, after all, conduct business on the mailing
> list), but would do so shortly after the release to get updates
> on the longer-term issues and reports from the council working
> groups.
>
> thoughts?
>
> -James
>
>
> On 23/04/12 22:20, Piotr Ba?ski wrote:
>> Hi James,
>>
>> Isn't May 25 roughly in the middle of LREC? Could we shift by a week
>> from then, please?
>>
>> (I actually intend to be ready with my stuff [and possibly more] in
>> advance this time, but I've made some such totally honest promises to
>> myself and to the world recently, several times, and with meager results...)
>>
>> Ah. Will we telco before releasing?
>>
>> Best,
>>
>>     P.
>>
>>
>>
>> On 23/04/12 17:47, James Cummings wrote:
>>>
>>> How about we set a notional target release date of 25 May?  (This
>>> is about 5 weeks from now.) If we assume that we want most things
>>> completed by the end of Sunday 20th, to allow time for
>>> proofreading and error spotting.
>>>
>>> Does that sounds reasonable to most people?
>>>
>>> Gaby: Most importantly, does the proposed Release Technician like
>>> these dates?
>>>
>>> -James
>>>
>>>
>>> On 21/04/12 18:50, Martin Holmes wrote:
>>>> Three weeks will be a bit tough for me, and a couple of the tickets I
>>>> have might turn out to have unpredicted side-effects (like the tei_
>>>> prefix). As long as we have the option to launch without the change if
>>>> it proves difficult, we could go with three weeks.
>>>>
>>>> The attributes-without-examples problem is so large that we'll just have
>>>> to hack away at it steadily.
>>>>
>>>> Cheers,
>>>> Martin
>>>>
>>>> On 12-04-21 04:03 AM, Sebastian Rahtz wrote:
>>>>> something we forgot to debate in Ann Arbor was a timetable
>>>>> for the next release, I think? i.e. what is the due date for
>>>>> everyone to complete their ticket work so that Sir Gabriel
>>>>> of B'odard can undertake his Quest.
>>>>>
>>>>> speaking for myself, if I don't do my assignments
>>>>> more or less immediately I will not get to them for ages,
>>>>> so I favour a short window (say, 3 weeks).
>>>>>
>>>>> Sebastian
>>>
>>>
>>
>
>

-- 
Dr Gabriel BODARD
(Research Associate in Digital Epigraphy)

Department of Digital Humanities
King's College London
26-29 Drury Lane
London WC2B 5RL

Email: gabriel.bodard at kcl.ac.uk
Tel: +44 (0)20 7848 1388
Fax: +44 (0)20 7848 2980

http://www.digitalclassicist.org/
http://www.currentepigraphy.org/

From bansp at o2.pl  Thu Apr 26 11:51:55 2012
From: bansp at o2.pl (=?UTF-8?B?UGlvdHIgQmHFhHNraQ==?=)
Date: Thu, 26 Apr 2012 17:51:55 +0200
Subject: [tei-council] DCR alignment inside ODD
In-Reply-To: <C9A60E97-2162-495B-A3E6-C0FBAEF00CA4@inria.fr>
References: <4F986124.30406@o2.pl>
	<4F26B857-B17C-4819-A224-2678E5ADD75A@oucs.ox.ac.uk>
	<C9A60E97-2162-495B-A3E6-C0FBAEF00CA4@inria.fr>
Message-ID: <4F996F1B.9030407@o2.pl>

Thank you, Sebastian and Laurent,

There's several issues here. (I concentrate on Laurent's post and will
reply to Sebastian's separately)

Firstly, you (Laurent) want the most radical move, i.e., making the
datcat attributes available to *all* elements. Two comments:

* I had an impression that this was not accepted by the Council, and
that the recommendation was to go from the bottom up, i.e. to select the
items that need the datcat stuff, and possibly increase the scope as
needed. I agree that the radical solution would simplify the issue,
given that ISOcat is able to provide alignment for practically any kind
of data category, not just those purely linguistic. Perhaps we could
reopen the discussion on that, I'd be happy to see att.datcat where you
suggest.

The title of the ticket is general, but the description may indeed
suggest that this is a proposal restricted to linguistic stuff:

https://sourceforge.net/tracker/index.php?func=detail&aid=3432520&group_id=106328&atid=644065


* if you assume that att.datcat are global, why on earth NOT use them on
<equiv>, where's the consistency? Sure thing, equiv has the @uri
attribute which was, or could be, used for DCR alignment, since there
was no other tool to do it. But if you postulate global datcat
attributes, I see it as inconsistent and counterintuitive to demand that
on <equiv> alone, DCR alignment is to be handled by @uri rather than the
available datcat attributes.

Secondly, yes, I know the example, it's nice until you imagine lots of
<fs> at the POS layer (take any serious corpus out there), at which
point it stops being nice and becomes seriously overredundant, and makes
you think of shifting the DCR stuff at least to the level of FSD.
Granted, FSD is not quite there still (sigh), so keeping all the stuff
within <f> is an unhappy temporary solution, good for presenting as one
of the examples in the spec, but maybe not necessarily in the
Dictionaries chapter.

Sure thing, I can do the <equiv>alence for POS in the ODD, and then do:
<pos dcr:valueDatcat="http://www.isocat.org/datcat/DC-1256">CN</pos>
(for "common noun"), except that it's a variant of the problem with <f>,
namely redundancy, very clear in the context of a dictionary. It is also
a problem of a split mechanism (<equiv> for containers vs. local
dcr:valueDatcat for values) instead of a unified mechanism.

Let me make sure it's clear what I consider redundancy in this very
case: <pos> or @name="part of speech" have to be repeated many times,
that's OK. But if we add the dcr: stuff, then, together with the "local"
identifiers, we repeat the "global" identifiers, in every place
affected, instead of saying once, either in the ODD, schema, or header:
<pos> = "http://www.isocat.org/datcat/DC-1345", and then using <pos>,
with its meaning now clarified.

Still, I'm grateful for the replies and discussion because it took away
my doubts concerning the here-and-now: it's better to have the DCR stuff
officially in the TEI than create roundabout solutions of the type I
talked about in Zadar and implemented in FreeDict. For the reasons that
I gave above, it feels to me like a half-way solution, but still, as we
all know, it's better to have it than not to have it, and I will now put
some example into the DI chapter (maybe even without mentioning <equiv>
for the time being), and will be happy to make a step forward. I think I
wanted too much too soon (and feared about how overwhelming it might
become, and that it goes beyond just a brief Council discussion that
we've had).

Best,

  P.


On 26/04/12 09:44, Laurent Romary wrote:
> I guess you are currently working on 3432520
> 
> There are two distinct mechanisms here:
> - the normal use of <equiv> within an ODD spec
> - the on-the-fly declaration of equivalence on an element instance ("I
> used <pos> here, meaning exactly the POS in ISOCat")
> For the latter purpose, ISO 12620 introduces two attributes in the dcr:
> namespace, for instance (example provided by Menzo in CC), you can
> decorate an FS as follows
> <tei:TEI xmlns:tei="http://www.tei-c.org/ns/1.0" xmlns:dcr="http://www.isocat.org/ns/dcr">
>     ...
>     <tei:fs>
>         ...
>         <tei:f 
>             name="part of speech"
>            dcr:datcat="http://www.isocat.org/datcat/DC-1345"
>             fVal="common noun"
>             dcr:valueDatcat="http://www.isocat.org/datcat/DC-1256"
>         /> 
>         ...
>     </tei:fs>
>     ...
> </tei:TEI>
> 
> 
>  So, looking again at the ticket the situation is clear, you
> make att.global a member of att.datcat, but make clear in the guidelines
> that this does not replace <equiv>
> 
> 
> Le 25 avr. 2012 ? 22:59, Sebastian Rahtz a ?crit :
> 
>>
>> On 25 Apr 2012, at 21:40, Piotr Ba?ski wrote:
>>
>>> I'm working on the ISO DCR / ISOcat issues.[1] Got stuck at the point of
>>> adding the relevant pieces of text to the Guidelines.
>>>
>>> The enlightened way to align grammatical categories with the values of
>>> the DCR is to put the appropriate references into the ODD, and I guess
>>> <equiv> is the ideal place for that.
>>>
>>> I imagine, and please correct me if I am wrong, that for elements such
>>> as <pos>, this action may be trivial:
>>>
>>> <elementSpec ident="pos" mode="change">
>>>  <equiv dcr:datcat="http://www.isocat.org/datcat/DC-1345"/>
>>> </elementSpec>
>>
>> <equiv url="http://www.isocat.org/datcat/DC-1345"/> is the syntax, I
>> think.
>>
>>> The above makes it possible for us to happily realize that whenever we
>>> do e.g.
>>>
>>> <gramGrp><pos>...</pos></gramGrp>
>>>
>>> all the machines in the world may know that by <pos>, we mean
>>> http://www.isocat.org/datcat/DC-1345 .
>> well, if they read the ODD yes. I think there is a certain amount
>> of "simple matter of programming" involved here.
>>
>>>
>>> However, there is also the content of <pos> to be handled, and it is not
>>> so obvious to me how to represent this in the ODD. Intuitively, I'm
>>> thinking of
>>>
>>> <elementSpec>
>>> ...
>>> <content>
>>> {list of values with their DCR references}
>>> </content>
>>
>> a <elementSpec> can contain a <valList>, whose <valItem> children
>> can have <equiv> children
>>
>> Does that help?
>>
>> I suspect what you'd really like is to use a DTD which supplied
>> default dcr:cat attributes to
>> instances of <pos>.
>>
>> Sebastian
>>
> 
> Laurent Romary
> INRIA & HUB-IDSL
> laurent.romary at inria.fr <mailto:laurent.romary at inria.fr>
> 
> 
> 


From bansp at o2.pl  Thu Apr 26 12:12:07 2012
From: bansp at o2.pl (=?ISO-8859-2?Q?Piotr_Ba=F1ski?=)
Date: Thu, 26 Apr 2012 18:12:07 +0200
Subject: [tei-council] DCR alignment inside ODD
In-Reply-To: <4F26B857-B17C-4819-A224-2678E5ADD75A@oucs.ox.ac.uk>
References: <4F986124.30406@o2.pl>
	<4F26B857-B17C-4819-A224-2678E5ADD75A@oucs.ox.ac.uk>
Message-ID: <4F9973D7.2020608@o2.pl>

On 25/04/12 22:59, Sebastian Rahtz wrote:
> 
> On 25 Apr 2012, at 21:40, Piotr Ba?ski wrote:
> 
>> I'm working on the ISO DCR / ISOcat issues.[1] Got stuck at the point of
>> adding the relevant pieces of text to the Guidelines.
>>
>> The enlightened way to align grammatical categories with the values of
>> the DCR is to put the appropriate references into the ODD, and I guess
>> <equiv> is the ideal place for that.
>>
>> I imagine, and please correct me if I am wrong, that for elements such
>> as <pos>, this action may be trivial:
>>
>> <elementSpec ident="pos" mode="change">
>>   <equiv dcr:datcat="http://www.isocat.org/datcat/DC-1345"/>
>> </elementSpec>
> 
> <equiv url="http://www.isocat.org/datcat/DC-1345"/> is the syntax, I think.

@uri, but yes, except that maintaining the use of @uri (rather than
softly deprecating it) creates two devices for DCR alignment in the same
element; I think the introduction of att.datcat makes @uri spurious here
-- @uri seems to have the status of a historical placeholder for
att.datcat. (Right?)

> 
>> The above makes it possible for us to happily realize that whenever we
>> do e.g.
>>
>> <gramGrp><pos>...</pos></gramGrp>
>>
>> all the machines in the world may know that by <pos>, we mean
>> http://www.isocat.org/datcat/DC-1345 .
> well, if they read the ODD yes. I think there is a certain amount
> of "simple matter of programming" involved here.

"simple", true... Well, for now I think I will concentrate on non-equiv
ways of implementing datcat, so that I can proceed in stages rather than
nab at everything at once.

>> However, there is also the content of <pos> to be handled, and it is not
>> so obvious to me how to represent this in the ODD. Intuitively, I'm
>> thinking of
>>
>> <elementSpec>
>> ...
>> <content>
>> {list of values with their DCR references}
>> </content>
> 
> a <elementSpec> can contain a <valList>, whose <valItem> children
> can have <equiv> children
> 
> Does that help?

Some. Thanks. I looked at valItem but the description made me shy away
from it ("contains one or more valItem elements defining possible values
for an *attribute*") -- it made me think that using it for element
content is Bad.

> I suspect what you'd really like is to use a DTD which supplied default dcr:cat attributes to
> instances of <pos>.

I'm not sure how to handle this in DTDs. default dcr:datcat pointing at
a definition of the POS, sure. But I can't see how to use this approach
for the values (noun, verb, etc.), maybe I'm missing something again.

Best,

  P.

From bansp at o2.pl  Thu Apr 26 12:14:36 2012
From: bansp at o2.pl (=?UTF-8?B?UGlvdHIgQmHFhHNraQ==?=)
Date: Thu, 26 Apr 2012 18:14:36 +0200
Subject: [tei-council] DCR alignment inside ODD
In-Reply-To: <BCDAE098-D838-4CF1-8C34-9CF16ED3B081@inria.fr>
References: <4F986124.30406@o2.pl>
	<4F26B857-B17C-4819-A224-2678E5ADD75A@oucs.ox.ac.uk>
	<C9A60E97-2162-495B-A3E6-C0FBAEF00CA4@inria.fr>
	<4F996F1B.9030407@o2.pl>
	<BCDAE098-D838-4CF1-8C34-9CF16ED3B081@inria.fr>
Message-ID: <4F99746C.3030108@o2.pl>

Ouch, I get the difference wrt <equiv> now, thanks! :-)

  P.

On 26/04/12 18:01, Laurent Romary wrote:
> I answer your two points quickly (baby bottle soon):
> 
> * I could live with a decision of just making http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-model.gramPart.html member of att.datcat and consider step by step the integration of other objects (but maybe metadata elements in the header should be considered quickly). Still, I do see this as a kind of general purpose mechanism at the service of convergence across standardization bodies and as such a stro,ng move to make
> * the semantic of dcr:datcat is "the element I qualify  corresponds to the concept expressed in my value", and you don't want to express this for <equiv>: there is a level of indirection here, because equiv qualifies the semantic of an element defined by the element spec, the element itself does not contain the attribute. It would thus be conceptually wrong (attribute-abuse,of the worst kind ;-)) to adopt the construct you suggest...
> :-)
> Laurent
> 
> Le 26 avr. 2012 ? 17:51, Piotr Ba?ski a ?crit :
> 
>> Thank you, Sebastian and Laurent,
>>
>> There's several issues here. (I concentrate on Laurent's post and will
>> reply to Sebastian's separately)
>>
>> Firstly, you (Laurent) want the most radical move, i.e., making the
>> datcat attributes available to *all* elements. Two comments:
>>
>> * I had an impression that this was not accepted by the Council, and
>> that the recommendation was to go from the bottom up, i.e. to select the
>> items that need the datcat stuff, and possibly increase the scope as
>> needed. I agree that the radical solution would simplify the issue,
>> given that ISOcat is able to provide alignment for practically any kind
>> of data category, not just those purely linguistic. Perhaps we could
>> reopen the discussion on that, I'd be happy to see att.datcat where you
>> suggest.
>>
>> The title of the ticket is general, but the description may indeed
>> suggest that this is a proposal restricted to linguistic stuff:
>>
>> https://sourceforge.net/tracker/index.php?func=detail&aid=3432520&group_id=106328&atid=644065
>>
>>
>> * if you assume that att.datcat are global, why on earth NOT use them on
>> <equiv>, where's the consistency? Sure thing, equiv has the @uri
>> attribute which was, or could be, used for DCR alignment, since there
>> was no other tool to do it. But if you postulate global datcat
>> attributes, I see it as inconsistent and counterintuitive to demand that
>> on <equiv> alone, DCR alignment is to be handled by @uri rather than the
>> available datcat attributes.
>>
>> Secondly, yes, I know the example, it's nice until you imagine lots of
>> <fs> at the POS layer (take any serious corpus out there), at which
>> point it stops being nice and becomes seriously overredundant, and makes
>> you think of shifting the DCR stuff at least to the level of FSD.
>> Granted, FSD is not quite there still (sigh), so keeping all the stuff
>> within <f> is an unhappy temporary solution, good for presenting as one
>> of the examples in the spec, but maybe not necessarily in the
>> Dictionaries chapter.
>>
>> Sure thing, I can do the <equiv>alence for POS in the ODD, and then do:
>> <pos dcr:valueDatcat="http://www.isocat.org/datcat/DC-1256">CN</pos>
>> (for "common noun"), except that it's a variant of the problem with <f>,
>> namely redundancy, very clear in the context of a dictionary. It is also
>> a problem of a split mechanism (<equiv> for containers vs. local
>> dcr:valueDatcat for values) instead of a unified mechanism.
>>
>> Let me make sure it's clear what I consider redundancy in this very
>> case: <pos> or @name="part of speech" have to be repeated many times,
>> that's OK. But if we add the dcr: stuff, then, together with the "local"
>> identifiers, we repeat the "global" identifiers, in every place
>> affected, instead of saying once, either in the ODD, schema, or header:
>> <pos> = "http://www.isocat.org/datcat/DC-1345", and then using <pos>,
>> with its meaning now clarified.
>>
>> Still, I'm grateful for the replies and discussion because it took away
>> my doubts concerning the here-and-now: it's better to have the DCR stuff
>> officially in the TEI than create roundabout solutions of the type I
>> talked about in Zadar and implemented in FreeDict. For the reasons that
>> I gave above, it feels to me like a half-way solution, but still, as we
>> all know, it's better to have it than not to have it, and I will now put
>> some example into the DI chapter (maybe even without mentioning <equiv>
>> for the time being), and will be happy to make a step forward. I think I
>> wanted too much too soon (and feared about how overwhelming it might
>> become, and that it goes beyond just a brief Council discussion that
>> we've had).
>>
>> Best,
>>
>>  P.
>>
>>
>> On 26/04/12 09:44, Laurent Romary wrote:
>>> I guess you are currently working on 3432520
>>>
>>> There are two distinct mechanisms here:
>>> - the normal use of <equiv> within an ODD spec
>>> - the on-the-fly declaration of equivalence on an element instance ("I
>>> used <pos> here, meaning exactly the POS in ISOCat")
>>> For the latter purpose, ISO 12620 introduces two attributes in the dcr:
>>> namespace, for instance (example provided by Menzo in CC), you can
>>> decorate an FS as follows
>>> <tei:TEI xmlns:tei="http://www.tei-c.org/ns/1.0" xmlns:dcr="http://www.isocat.org/ns/dcr">
>>>    ...
>>>    <tei:fs>
>>>        ...
>>>        <tei:f 
>>>            name="part of speech"
>>>           dcr:datcat="http://www.isocat.org/datcat/DC-1345"
>>>            fVal="common noun"
>>>            dcr:valueDatcat="http://www.isocat.org/datcat/DC-1256"
>>>        /> 
>>>        ...
>>>    </tei:fs>
>>>    ...
>>> </tei:TEI>
>>>
>>>
>>> So, looking again at the ticket the situation is clear, you
>>> make att.global a member of att.datcat, but make clear in the guidelines
>>> that this does not replace <equiv>
>>>
>>>
>>> Le 25 avr. 2012 ? 22:59, Sebastian Rahtz a ?crit :
>>>
>>>>
>>>> On 25 Apr 2012, at 21:40, Piotr Ba?ski wrote:
>>>>
>>>>> I'm working on the ISO DCR / ISOcat issues.[1] Got stuck at the point of
>>>>> adding the relevant pieces of text to the Guidelines.
>>>>>
>>>>> The enlightened way to align grammatical categories with the values of
>>>>> the DCR is to put the appropriate references into the ODD, and I guess
>>>>> <equiv> is the ideal place for that.
>>>>>
>>>>> I imagine, and please correct me if I am wrong, that for elements such
>>>>> as <pos>, this action may be trivial:
>>>>>
>>>>> <elementSpec ident="pos" mode="change">
>>>>> <equiv dcr:datcat="http://www.isocat.org/datcat/DC-1345"/>
>>>>> </elementSpec>
>>>>
>>>> <equiv url="http://www.isocat.org/datcat/DC-1345"/> is the syntax, I
>>>> think.
>>>>
>>>>> The above makes it possible for us to happily realize that whenever we
>>>>> do e.g.
>>>>>
>>>>> <gramGrp><pos>...</pos></gramGrp>
>>>>>
>>>>> all the machines in the world may know that by <pos>, we mean
>>>>> http://www.isocat.org/datcat/DC-1345 .
>>>> well, if they read the ODD yes. I think there is a certain amount
>>>> of "simple matter of programming" involved here.
>>>>
>>>>>
>>>>> However, there is also the content of <pos> to be handled, and it is not
>>>>> so obvious to me how to represent this in the ODD. Intuitively, I'm
>>>>> thinking of
>>>>>
>>>>> <elementSpec>
>>>>> ...
>>>>> <content>
>>>>> {list of values with their DCR references}
>>>>> </content>
>>>>
>>>> a <elementSpec> can contain a <valList>, whose <valItem> children
>>>> can have <equiv> children
>>>>
>>>> Does that help?
>>>>
>>>> I suspect what you'd really like is to use a DTD which supplied
>>>> default dcr:cat attributes to
>>>> instances of <pos>.
>>>>
>>>> Sebastian
>>>>
>>>
>>> Laurent Romary
>>> INRIA & HUB-IDSL
>>> laurent.romary at inria.fr <mailto:laurent.romary at inria.fr>
>>>
>>>
>>>
>>
> 
> Laurent Romary
> INRIA & HUB-IDSL
> laurent.romary at inria.fr
> 
> 
> 
> 


From lou.burnard at retired.ox.ac.uk  Thu Apr 26 12:48:59 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Thu, 26 Apr 2012 17:48:59 +0100
Subject: [tei-council] DCR alignment inside ODD
In-Reply-To: <4F9973D7.2020608@o2.pl>
References: <4F986124.30406@o2.pl>
	<4F26B857-B17C-4819-A224-2678E5ADD75A@oucs.ox.ac.uk>
	<4F9973D7.2020608@o2.pl>
Message-ID: <4F997C7B.3010805@retired.ox.ac.uk>

On 26/04/12 17:12, Piotr Ba?ski wrote:

[... snip ... ]

>> a<elementSpec>  can contain a<valList>, whose<valItem>  children
>> can have<equiv>  children
>>
>> Does that help?
>
> Some. Thanks. I looked at valItem but the description made me shy away
> from it ("contains one or more valItem elements defining possible values
> for an *attribute*") -- it made me think that using it for element
> content is Bad.


I'd say that description is erroneous and should be revised. Please put 
in a ticket.

>
>> I suspect what you'd really like is to use a DTD which supplied default dcr:cat attributes to
>> instances of<pos>.
>
> I'm not sure how to handle this in DTDs. default dcr:datcat pointing at
> a definition of the POS, sure. But I can't see how to use this approach
> for the values (noun, verb, etc.), maybe I'm missing something again.
>

I am coming to this discussion under-prepared, but for what it's worth, 
it seems to me that if what you want is to say "my <pos> elements all 
have content/values defined by the ISO DCR", you certainly don't need to 
say it on every <pos> occurrence. You could either say it in your ODD 
using <equiv> (as previously noted), or you could also say it in the 
<encodingDesc> somewhere. Similarly if you wanted to say that for your 
@type attributes or anything else. But this seems different from saying 
that your @type attribute or <pos> element itself is defined by the ISO 
DCR.



From bansp at o2.pl  Thu Apr 26 14:10:29 2012
From: bansp at o2.pl (=?ISO-8859-2?Q?Piotr_Ba=F1ski?=)
Date: Thu, 26 Apr 2012 20:10:29 +0200
Subject: [tei-council] DCR alignment inside ODD
In-Reply-To: <4F997C7B.3010805@retired.ox.ac.uk>
References: <4F986124.30406@o2.pl>	<4F26B857-B17C-4819-A224-2678E5ADD75A@oucs.ox.ac.uk>	<4F9973D7.2020608@o2.pl>
	<4F997C7B.3010805@retired.ox.ac.uk>
Message-ID: <4F998F95.7050503@o2.pl>

[keeping Laurent in the loop, as he requested]

On 26/04/12 18:48, Lou Burnard wrote:
> On 26/04/12 17:12, Piotr Ba?ski wrote:
> 
> [... snip ... ]
> 
>>> a<elementSpec>  can contain a<valList>, whose<valItem>  children
>>> can have<equiv>  children
>>>
>>> Does that help?
>>
>> Some. Thanks. I looked at valItem but the description made me shy away
>> from it ("contains one or more valItem elements defining possible values
>> for an *attribute*") -- it made me think that using it for element
>> content is Bad.
> 
> 
> I'd say that description is erroneous and should be revised. Please put 
> in a ticket.

Done.

https://sourceforge.net/tracker/?func=detail&aid=3521714&group_id=106328&atid=644062

>>> I suspect what you'd really like is to use a DTD which supplied default dcr:cat attributes to
>>> instances of<pos>.
>>
>> I'm not sure how to handle this in DTDs. default dcr:datcat pointing at
>> a definition of the POS, sure. But I can't see how to use this approach
>> for the values (noun, verb, etc.), maybe I'm missing something again.
>>
> 
> I am coming to this discussion under-prepared, but for what it's worth, 
> it seems to me that if what you want is to say "my <pos> elements all 
> have content/values defined by the ISO DCR", you certainly don't need to 
> say it on every <pos> occurrence. You could either say it in your ODD 
> using <equiv> (as previously noted), or you could also say it in the 
> <encodingDesc> somewhere. Similarly if you wanted to say that for your 
> @type attributes or anything else. But this seems different from saying 
> that your @type attribute or <pos> element itself is defined by the ISO 
> DCR.

I want to say about <pos>noun</pos> that:

1) the concept expressed by <pos> is this-and-that Data Category kept at
PID X (that's the dcr:datcat pointing at the definition of
"part-of-speech"), and

2) the value of that POS is this-and-that Simple Data Category kept at
PID Y (that's the dcr:valueDatcat pointing at the definition of the
concept "noun").

(note that I am restricting this to linguistic examples, but you can
have just as well Data Categories for the concept of "author" or "sex",
or "trochee", etc., with the same reference machinery -- this is why
Laurent wants them global)

In particular, I would like to know that when dictionary A says that
something is "fem", dictionary B that it is "f", and C that it is
"feminine" (or "?", "?e?.", or "weibl.", etc.), they all talk about the
same value of the category "Gender" (so I use dcr:datcat for the concept
"Gender", and valueDatcat for the concept "Feminine").

Conversely, when one dictionary tells me that something is "n", and
another that something else is "n", I want to make sure to indicate that
the first one talks about the concept "noun", but the other about the
concept "neuter", so I don't want to combine them in my search, or in my
combined mega-dictionary.

So it's not just about saying that "my pos elements have content defined
by the ISO DCR", but I need to be more granular, and actually identify
the concepts by their PIDs. I could indicate that to humans by e.g.
"neut" and to machines by the appropriate valueDatcat, at the same time
-- this is roughly the extension of the <f> example mentioned by
Laurent. And I guess this is the stage which can be encoded in the
Guidelines right now.

<gen dcr:datcat="{PID of 'Gender'}"
     dcr:valueDatcat="{PID of 'Neuter'}">neut</gen>

-------------------------------------------
What I talked about in Zadar was a way to state, just *once* per
dictionary, that "wherever I use "neut" below as the value of <gen>, I
mean this-and-that DC under this PID". So in the body of the dictionary,
one would only use "neut" (incidentally human-readable and short), but
the header would tie this string appropriately to the relevant PID. I
guess that this is a matter for at least one Council session, and I hope
that LingSIG will come up with a coherent proposal, hopefully around
College Station or Oxford, whichever comes first.

best,

  P.

From sebastian.rahtz at oucs.ox.ac.uk  Thu Apr 26 16:57:10 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Thu, 26 Apr 2012 20:57:10 +0000
Subject: [tei-council] DCR alignment inside ODD
In-Reply-To: <4F9973D7.2020608@o2.pl>
References: <4F986124.30406@o2.pl>
	<4F26B857-B17C-4819-A224-2678E5ADD75A@oucs.ox.ac.uk>
	<4F9973D7.2020608@o2.pl>
Message-ID: <859A95EE-D224-45F0-96A4-9514F7C12F48@oucs.ox.ac.uk>


On 26 Apr 2012, at 17:12, Piotr Ba?ski wrote:

> @uri, but yes, except that maintaining the use of @uri (rather than
> softly deprecating it) creates two devices for DCR alignment in the same
> element; I think the introduction of att.datcat makes @uri spurious here
> -- @uri seems to have the status of a historical placeholder for
> att.datcat.

you might say that, but I believe there are some few renegades who have spotted life
outside ISO 12620:2009  :-}


> I'm not sure how to handle this in DTDs. default dcr:datcat pointing at
> a definition of the POS, sure. But I can't see how to use this approach
> for the values (noun, verb, etc.), maybe I'm missing something again.


no, you can't do that in DTDs.

if you want to say 

  * when  the TEI uses <foo>, thats the same data category as ISO <bar>
  * when the content of <foo> is "noun", thats also a concept defined in ISO, as "noun"
  * <foo> can _only_ contain "noun" or "verb", and they are ISO xxxxx

then it seems to me that you have <equiv> and dcr:datcat filling all your needs right now.

saying
  <elementSpec dcr:datcat="iso:xxx" ident="foo">
seems to be to be saying that the idea of an "element" is  ISO category "xxx",
which is not the same thing at all, of course.

saying
 
  <equiv dcr:datcat="iso:yyy"> 

similarly says that our notion of "equiv" is ISO's yyy, which is also not what you mean

IMHO.

Sebastian

From bansp at o2.pl  Thu Apr 26 17:07:47 2012
From: bansp at o2.pl (=?ISO-8859-2?Q?Piotr_Ba=F1ski?=)
Date: Thu, 26 Apr 2012 23:07:47 +0200
Subject: [tei-council] DCR alignment inside ODD
In-Reply-To: <859A95EE-D224-45F0-96A4-9514F7C12F48@oucs.ox.ac.uk>
References: <4F986124.30406@o2.pl>	<4F26B857-B17C-4819-A224-2678E5ADD75A@oucs.ox.ac.uk>	<4F9973D7.2020608@o2.pl>
	<859A95EE-D224-45F0-96A4-9514F7C12F48@oucs.ox.ac.uk>
Message-ID: <4F99B923.2000300@o2.pl>

On 26/04/12 22:57, Sebastian Rahtz wrote:
> 
> On 26 Apr 2012, at 17:12, Piotr Ba?ski wrote:
> 
>> @uri, but yes, except that maintaining the use of @uri (rather than
>> softly deprecating it) creates two devices for DCR alignment in the same
>> element; I think the introduction of att.datcat makes @uri spurious here
>> -- @uri seems to have the status of a historical placeholder for
>> att.datcat.
> 
> you might say that, but I believe there are some few renegades who have spotted life
> outside ISO 12620:2009  :-}

I just hope this isn't yet another false positive!

Thanks for the corrections and hints :-)

  P.

From mholmes at uvic.ca  Thu Apr 26 19:42:06 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Thu, 26 Apr 2012 16:42:06 -0700
Subject: [tei-council] Addition to HD re schemaSpec in encodingDesc
Message-ID: <4F99DD4E.5050502@uvic.ca>

Hi all,

Working on this ticket:

<http://purl.org/TEI/FR/1650195>

I've added <schemaSpec> to model.encodingDescPart, which makes it 
available in <encodingDesc>, and I've added a little section to the 
Header chapter to cover its usage:

<http://teijenkins.hcmc.uvic.ca:8080/job/TEIP5-Documentation/lastSuccessfulBuild/artifact/Guidelines-web/en/html/HD.html#HDSCHSPEC>

Take a look if you have a chance, and let me know if there's anything 
that should be changed or added.

Cheers,
Martin

From bansp at o2.pl  Fri Apr 27 07:07:24 2012
From: bansp at o2.pl (=?UTF-8?B?UGlvdHIgQmHFhHNraQ==?=)
Date: Fri, 27 Apr 2012 13:07:24 +0200
Subject: [tei-council] DCR alignment inside ODD
In-Reply-To: <24B98204-C664-49E6-BECF-D3301E294D9A@inria.fr>
References: <4F986124.30406@o2.pl>	<4F26B857-B17C-4819-A224-2678E5ADD75A@oucs.ox.ac.uk>	<4F9973D7.2020608@o2.pl>
	<4F997C7B.3010805@retired.ox.ac.uk> <4F998F95.7050503@o2.pl>
	<24B98204-C664-49E6-BECF-D3301E294D9A@inria.fr>
Message-ID: <4F9A7DEC.6050101@o2.pl>

Hi Laurent,

Right, tagUsage is exactly what I used there. Will formulate a more
precise proposal when I've dealt with the most pressing things before
the end of the month.

Isn't this a bit like the <equiv> case, where you talk about the DCR
alignment indirectly? Need to give it a thought when the reality calms down.

Thanks,

  P.

On 27/04/12 09:03, Laurent Romary wrote:
> Hi Piotr,
> I also like your Zadar use case. We need to think of a way of having a global declaration ("all my <gen> mean X in the DCR") in encodingDesc, which would be indepedent of the <equiv> mechanism. I would suggest that the dcr: attributes go on tagUsage for this purpose.
> Cheers,
> Laurent
> 
> Le 26 avr. 2012 ? 20:10, Piotr Ba?ski a ?crit :
> 
>> [keeping Laurent in the loop, as he requested]
>>
>> On 26/04/12 18:48, Lou Burnard wrote:
>>> On 26/04/12 17:12, Piotr Ba?ski wrote:
>>>
>>> [... snip ... ]
>>>
>>>>> a<elementSpec>  can contain a<valList>, whose<valItem>  children
>>>>> can have<equiv>  children
>>>>>
>>>>> Does that help?
>>>>
>>>> Some. Thanks. I looked at valItem but the description made me shy away
>>>> from it ("contains one or more valItem elements defining possible values
>>>> for an *attribute*") -- it made me think that using it for element
>>>> content is Bad.
>>>
>>>
>>> I'd say that description is erroneous and should be revised. Please put 
>>> in a ticket.
>>
>> Done.
>>
>> https://sourceforge.net/tracker/?func=detail&aid=3521714&group_id=106328&atid=644062
>>
>>>>> I suspect what you'd really like is to use a DTD which supplied default dcr:cat attributes to
>>>>> instances of<pos>.
>>>>
>>>> I'm not sure how to handle this in DTDs. default dcr:datcat pointing at
>>>> a definition of the POS, sure. But I can't see how to use this approach
>>>> for the values (noun, verb, etc.), maybe I'm missing something again.
>>>>
>>>
>>> I am coming to this discussion under-prepared, but for what it's worth, 
>>> it seems to me that if what you want is to say "my <pos> elements all 
>>> have content/values defined by the ISO DCR", you certainly don't need to 
>>> say it on every <pos> occurrence. You could either say it in your ODD 
>>> using <equiv> (as previously noted), or you could also say it in the 
>>> <encodingDesc> somewhere. Similarly if you wanted to say that for your 
>>> @type attributes or anything else. But this seems different from saying 
>>> that your @type attribute or <pos> element itself is defined by the ISO 
>>> DCR.
>>
>> I want to say about <pos>noun</pos> that:
>>
>> 1) the concept expressed by <pos> is this-and-that Data Category kept at
>> PID X (that's the dcr:datcat pointing at the definition of
>> "part-of-speech"), and
>>
>> 2) the value of that POS is this-and-that Simple Data Category kept at
>> PID Y (that's the dcr:valueDatcat pointing at the definition of the
>> concept "noun").
>>
>> (note that I am restricting this to linguistic examples, but you can
>> have just as well Data Categories for the concept of "author" or "sex",
>> or "trochee", etc., with the same reference machinery -- this is why
>> Laurent wants them global)
>>
>> In particular, I would like to know that when dictionary A says that
>> something is "fem", dictionary B that it is "f", and C that it is
>> "feminine" (or "?", "?e?.", or "weibl.", etc.), they all talk about the
>> same value of the category "Gender" (so I use dcr:datcat for the concept
>> "Gender", and valueDatcat for the concept "Feminine").
>>
>> Conversely, when one dictionary tells me that something is "n", and
>> another that something else is "n", I want to make sure to indicate that
>> the first one talks about the concept "noun", but the other about the
>> concept "neuter", so I don't want to combine them in my search, or in my
>> combined mega-dictionary.
>>
>> So it's not just about saying that "my pos elements have content defined
>> by the ISO DCR", but I need to be more granular, and actually identify
>> the concepts by their PIDs. I could indicate that to humans by e.g.
>> "neut" and to machines by the appropriate valueDatcat, at the same time
>> -- this is roughly the extension of the <f> example mentioned by
>> Laurent. And I guess this is the stage which can be encoded in the
>> Guidelines right now.
>>
>> <gen dcr:datcat="{PID of 'Gender'}"
>>     dcr:valueDatcat="{PID of 'Neuter'}">neut</gen>
>>
>> -------------------------------------------
>> What I talked about in Zadar was a way to state, just *once* per
>> dictionary, that "wherever I use "neut" below as the value of <gen>, I
>> mean this-and-that DC under this PID". So in the body of the dictionary,
>> one would only use "neut" (incidentally human-readable and short), but
>> the header would tie this string appropriately to the relevant PID. I
>> guess that this is a matter for at least one Council session, and I hope
>> that LingSIG will come up with a coherent proposal, hopefully around
>> College Station or Oxford, whichever comes first.
>>
>> best,
>>
>>  P.
> 
> Laurent Romary
> INRIA & HUB-IDSL
> laurent.romary at inria.fr
> 
> 
> 
> 


From mholmes at uvic.ca  Fri Apr 27 08:30:38 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Fri, 27 Apr 2012 05:30:38 -0700
Subject: [tei-council] xml-model processing instruction
Message-ID: <4F9A916E.3070806@uvic.ca>

Hi there,

In Michigan we agreed (on ticket <http://purl.org/TEI/FR/1650195>) that 
we'd add a recommendation that people use the W3C standard xml-model 
processing instruction to link both regular schemas and ODD files into 
their XML documents, but we didn't say exactly where we'd put that 
recommendation.

The obvious place is this section of the Gentle Introduction:

<http://teijenkins.hcmc.uvic.ca:8080/job/TEIP5-Documentation/lastSuccessfulBuild/artifact/Guidelines-web/en/html/SG.html#SG-assoc>

which is currently slightly misleading: "In RELAX NG therefore no 
facility for associating a particular schema with a particular instance 
exists...". Although this is technically true, xml-model is now a 
standard method (although defined outside of RELAX NG).

I think it might also be addressed in Chapter 22 Documentation Elements 
too -- what do you think about adding a new section like this:

     22.1 Phrase Level Documentary Elements
     22.2 Modules and Schemas
     22.3 Specification Elements
     22.4 Common Elements
     22.5 Building a Schema
     22.6 Combining TEI and Non-TEI Modules
 >>  22.7 Linking Schemas to XML Documents
     22.8 Module for Documention Elements

The difference between the two explanations, I think, would be that the 
Gentle Introduction one should focus mainly on linking schemas into your 
documents, whereas the Ch 22 section should also give some detail on 
linking ODD files by the same mechanism, and should also point at the 
new section in the Header chapter on including a <schemaSpec> in your 
<encodingDesc>, to give a comprehensive overview of all the ways your 
document can be linked to its XML model.

Any disagreement on this, before I proceed?

Cheers,
Martin

From bansp at o2.pl  Fri Apr 27 08:32:59 2012
From: bansp at o2.pl (=?ISO-8859-2?Q?Piotr_Ba=F1ski?=)
Date: Fri, 27 Apr 2012 14:32:59 +0200
Subject: [tei-council] xml-model processing instruction
In-Reply-To: <4F9A916E.3070806@uvic.ca>
References: <4F9A916E.3070806@uvic.ca>
Message-ID: <4F9A91FB.6040209@o2.pl>

Thumbs up from me.

  P.

On 27/04/12 14:30, Martin Holmes wrote:
> Hi there,
> 
> In Michigan we agreed (on ticket <http://purl.org/TEI/FR/1650195>) that 
> we'd add a recommendation that people use the W3C standard xml-model 
> processing instruction to link both regular schemas and ODD files into 
> their XML documents, but we didn't say exactly where we'd put that 
> recommendation.
> 
> The obvious place is this section of the Gentle Introduction:
> 
> <http://teijenkins.hcmc.uvic.ca:8080/job/TEIP5-Documentation/lastSuccessfulBuild/artifact/Guidelines-web/en/html/SG.html#SG-assoc>
> 
> which is currently slightly misleading: "In RELAX NG therefore no 
> facility for associating a particular schema with a particular instance 
> exists...". Although this is technically true, xml-model is now a 
> standard method (although defined outside of RELAX NG).
> 
> I think it might also be addressed in Chapter 22 Documentation Elements 
> too -- what do you think about adding a new section like this:
> 
>      22.1 Phrase Level Documentary Elements
>      22.2 Modules and Schemas
>      22.3 Specification Elements
>      22.4 Common Elements
>      22.5 Building a Schema
>      22.6 Combining TEI and Non-TEI Modules
>  >>  22.7 Linking Schemas to XML Documents
>      22.8 Module for Documention Elements
> 
> The difference between the two explanations, I think, would be that the 
> Gentle Introduction one should focus mainly on linking schemas into your 
> documents, whereas the Ch 22 section should also give some detail on 
> linking ODD files by the same mechanism, and should also point at the 
> new section in the Header chapter on including a <schemaSpec> in your 
> <encodingDesc>, to give a comprehensive overview of all the ways your 
> document can be linked to its XML model.
> 
> Any disagreement on this, before I proceed?
> 
> Cheers,
> Martin


From James.Cummings at oucs.ox.ac.uk  Fri Apr 27 10:43:39 2012
From: James.Cummings at oucs.ox.ac.uk (James Cummings)
Date: Fri, 27 Apr 2012 15:43:39 +0100
Subject: [tei-council] xml-model processing instruction
In-Reply-To: <4F9A91FB.6040209@o2.pl>
References: <4F9A916E.3070806@uvic.ca> <4F9A91FB.6040209@o2.pl>
Message-ID: <4F9AB09B.1020201@oucs.ox.ac.uk>


Likewise (as the original requestor), this seems good to me.

-James

On 27/04/12 13:32, Piotr Ba?ski wrote:
> Thumbs up from me.
>
>    P.
>
> On 27/04/12 14:30, Martin Holmes wrote:
>> Hi there,
>>
>> In Michigan we agreed (on ticket<http://purl.org/TEI/FR/1650195>) that
>> we'd add a recommendation that people use the W3C standard xml-model
>> processing instruction to link both regular schemas and ODD files into
>> their XML documents, but we didn't say exactly where we'd put that
>> recommendation.
>>
>> The obvious place is this section of the Gentle Introduction:
>>
>> <http://teijenkins.hcmc.uvic.ca:8080/job/TEIP5-Documentation/lastSuccessfulBuild/artifact/Guidelines-web/en/html/SG.html#SG-assoc>
>>
>> which is currently slightly misleading: "In RELAX NG therefore no
>> facility for associating a particular schema with a particular instance
>> exists...". Although this is technically true, xml-model is now a
>> standard method (although defined outside of RELAX NG).
>>
>> I think it might also be addressed in Chapter 22 Documentation Elements
>> too -- what do you think about adding a new section like this:
>>
>>       22.1 Phrase Level Documentary Elements
>>       22.2 Modules and Schemas
>>       22.3 Specification Elements
>>       22.4 Common Elements
>>       22.5 Building a Schema
>>       22.6 Combining TEI and Non-TEI Modules
>>   >>   22.7 Linking Schemas to XML Documents
>>       22.8 Module for Documention Elements
>>
>> The difference between the two explanations, I think, would be that the
>> Gentle Introduction one should focus mainly on linking schemas into your
>> documents, whereas the Ch 22 section should also give some detail on
>> linking ODD files by the same mechanism, and should also point at the
>> new section in the Header chapter on including a<schemaSpec>  in your
>> <encodingDesc>, to give a comprehensive overview of all the ways your
>> document can be linked to its XML model.
>>
>> Any disagreement on this, before I proceed?
>>
>> Cheers,
>> Martin
>


-- 
Dr James Cummings, InfoDev,
Computing Services, University of Oxford

From James.Cummings at oucs.ox.ac.uk  Fri Apr 27 11:05:04 2012
From: James.Cummings at oucs.ox.ac.uk (James Cummings)
Date: Fri, 27 Apr 2012 16:05:04 +0100
Subject: [tei-council] next release?
In-Reply-To: <4F986673.7020201@kcl.ac.uk>
References: <0F18A249-5480-42D9-BFF2-538AC7B9E1EB@oucs.ox.ac.uk>	<4F92F34D.2040103@uvic.ca>	<4F9579A0.8010002@oucs.ox.ac.uk>	<4F95C7A1.1080707@o2.pl>
	<4F96756B.1060202@oucs.ox.ac.uk> <4F986673.7020201@kcl.ac.uk>
Message-ID: <4F9AB5A0.1090006@oucs.ox.ac.uk>


That to me looks like a good reason to go with the 25th as our 
proposed date again. Unless anyone screams violently against 
that, I'm putting it in my calendar and hope Gaby does the same. :-)

Remember, although it would be good to get everything implemented 
that we decided, the benefit of sorting out the release process 
is that it means we can, if necessary, have later releases as 
well.  The TEI has traditionally (well certainly since launch of 
P5 in 2007) had releases twice a year, and I don't think we 
should be frightened of upping that number significantly.  (On 
the other hand, we don't want to be making monthly releases, I 
don't think!?)

-James


On 25/04/12 22:02, Gabriel BODARD wrote:
> The first week of June is likely to be bad for me; I'm back from
> international travel around the 4th, I think, and will be groggy the
> first couple days after that. So if not May 25th, then best to put it
> off by two weeks. (Or someone else be launch technician...)
>
> G
>
> On 24/04/2012 10:42, James Cummings wrote:
>>
>> What do others think? We can of course move releasing back to
>> whenever we've finished a majority of tickets, but I'd prefer
>> sooner rather than later and a deadline that forces us to get
>> stuff done.
>>
>> I'm of the opinion that we probably don't need to telco before
>> this release (we can, after all, conduct business on the mailing
>> list), but would do so shortly after the release to get updates
>> on the longer-term issues and reports from the council working
>> groups.
>>
>> thoughts?
>>
>> -James
>>
>>
>> On 23/04/12 22:20, Piotr Ba?ski wrote:
>>> Hi James,
>>>
>>> Isn't May 25 roughly in the middle of LREC? Could we shift by a week
>>> from then, please?
>>>
>>> (I actually intend to be ready with my stuff [and possibly more] in
>>> advance this time, but I've made some such totally honest promises to
>>> myself and to the world recently, several times, and with meager results...)
>>>
>>> Ah. Will we telco before releasing?
>>>
>>> Best,
>>>
>>>      P.
>>>
>>>
>>>
>>> On 23/04/12 17:47, James Cummings wrote:
>>>>
>>>> How about we set a notional target release date of 25 May?  (This
>>>> is about 5 weeks from now.) If we assume that we want most things
>>>> completed by the end of Sunday 20th, to allow time for
>>>> proofreading and error spotting.
>>>>
>>>> Does that sounds reasonable to most people?
>>>>
>>>> Gaby: Most importantly, does the proposed Release Technician like
>>>> these dates?
>>>>
>>>> -James
>>>>
>>>>
>>>> On 21/04/12 18:50, Martin Holmes wrote:
>>>>> Three weeks will be a bit tough for me, and a couple of the tickets I
>>>>> have might turn out to have unpredicted side-effects (like the tei_
>>>>> prefix). As long as we have the option to launch without the change if
>>>>> it proves difficult, we could go with three weeks.
>>>>>
>>>>> The attributes-without-examples problem is so large that we'll just have
>>>>> to hack away at it steadily.
>>>>>
>>>>> Cheers,
>>>>> Martin
>>>>>
>>>>> On 12-04-21 04:03 AM, Sebastian Rahtz wrote:
>>>>>> something we forgot to debate in Ann Arbor was a timetable
>>>>>> for the next release, I think? i.e. what is the due date for
>>>>>> everyone to complete their ticket work so that Sir Gabriel
>>>>>> of B'odard can undertake his Quest.
>>>>>>
>>>>>> speaking for myself, if I don't do my assignments
>>>>>> more or less immediately I will not get to them for ages,
>>>>>> so I favour a short window (say, 3 weeks).
>>>>>>
>>>>>> Sebastian
>>>>
>>>>
>>>
>>
>>
>


-- 
Dr James Cummings, InfoDev,
Computing Services, University of Oxford

From James.Cummings at oucs.ox.ac.uk  Fri Apr 27 11:31:42 2012
From: James.Cummings at oucs.ox.ac.uk (James Cummings)
Date: Fri, 27 Apr 2012 16:31:42 +0100
Subject: [tei-council] Addition to HD re schemaSpec in encodingDesc
In-Reply-To: <4F99DD4E.5050502@uvic.ca>
References: <4F99DD4E.5050502@uvic.ca>
Message-ID: <4F9ABBDE.2090501@oucs.ox.ac.uk>


Hi Martin,

This looks good to me.  Potentially it is possible to embed 
multiple schemaSpec, which I assume would just mean that you are 
storing multiple ones there.  (i.e. one document may have 
different schemas at different points in its workflow.)

-James


On 27/04/12 00:42, Martin Holmes wrote:
> Hi all,
>
> Working on this ticket:
>
> <http://purl.org/TEI/FR/1650195>
>
> I've added<schemaSpec>  to model.encodingDescPart, which makes
> it available in<encodingDesc>, and I've added a little section
> to the Header chapter to cover its usage:
>
> <http://teijenkins.hcmc.uvic.ca:8080/job/TEIP5-Documentation/lastSuccessfulBuild/artifact/Guidelines-web/en/html/HD.html#HDSCHSPEC>
>
>  Take a look if you have a chance, and let me know if there's
> anything that should be changed or added.
>
> Cheers, Martin


-- 
Dr James Cummings, InfoDev,
Computing Services, University of Oxford

From mholmes at uvic.ca  Fri Apr 27 11:35:28 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Fri, 27 Apr 2012 08:35:28 -0700
Subject: [tei-council] Addition to HD re schemaSpec in encodingDesc
In-Reply-To: <4F9ABBDE.2090501@oucs.ox.ac.uk>
References: <4F99DD4E.5050502@uvic.ca> <4F9ABBDE.2090501@oucs.ox.ac.uk>
Message-ID: <4F9ABCC0.8020803@uvic.ca>

On 12-04-27 08:31 AM, James Cummings wrote:
>
> Hi Martin,
>
> This looks good to me.  Potentially it is possible to embed
> multiple schemaSpec, which I assume would just mean that you are
> storing multiple ones there.  (i.e. one document may have
> different schemas at different points in its workflow.)

Do you think we should actually mention that, or does it just commit us 
to explaining something hideously complex? For instance, if you were 
intending to generate a schema from one of several <schemaSpec>s stored 
in <encodingDesc>, you'd need to know what stage the document was at in 
order to know which schema it should validate against; that info would 
have to be stored somewhere, etc. etc. Do we want to get into that?

Cheers,
Martin

>
> -James
>
>
> On 27/04/12 00:42, Martin Holmes wrote:
>> Hi all,
>>
>> Working on this ticket:
>>
>> <http://purl.org/TEI/FR/1650195>
>>
>> I've added<schemaSpec>   to model.encodingDescPart, which makes
>> it available in<encodingDesc>, and I've added a little section
>> to the Header chapter to cover its usage:
>>
>> <http://teijenkins.hcmc.uvic.ca:8080/job/TEIP5-Documentation/lastSuccessfulBuild/artifact/Guidelines-web/en/html/HD.html#HDSCHSPEC>
>>
>>   Take a look if you have a chance, and let me know if there's
>> anything that should be changed or added.
>>
>> Cheers, Martin
>
>

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From gabriel.bodard at kcl.ac.uk  Fri Apr 27 11:39:11 2012
From: gabriel.bodard at kcl.ac.uk (Gabriel BODARD)
Date: Fri, 27 Apr 2012 16:39:11 +0100
Subject: [tei-council] next release?
In-Reply-To: <4F9AB5A0.1090006@oucs.ox.ac.uk>
References: <0F18A249-5480-42D9-BFF2-538AC7B9E1EB@oucs.ox.ac.uk>
	<4F92F34D.2040103@uvic.ca>	<4F9579A0.8010002@oucs.ox.ac.uk>
	<4F95C7A1.1080707@o2.pl>	<4F96756B.1060202@oucs.ox.ac.uk>
	<4F986673.7020201@kcl.ac.uk> <4F9AB5A0.1090006@oucs.ox.ac.uk>
Message-ID: <4F9ABD9F.2040404@kcl.ac.uk>

If we end up making monthly releases at some point, I don't suppose 
there's any harm in that, but we certainly want to avoid raising the 
expectation that we're going to continue making monthly releases!

I'll put May 25 in my calendar (in fact it's been there for a while). 
Will this be release 2.1.0?

G

On 27/04/2012 16:05, James Cummings wrote:
>
> That to me looks like a good reason to go with the 25th as our
> proposed date again. Unless anyone screams violently against
> that, I'm putting it in my calendar and hope Gaby does the same. :-)
>
> Remember, although it would be good to get everything implemented
> that we decided, the benefit of sorting out the release process
> is that it means we can, if necessary, have later releases as
> well.  The TEI has traditionally (well certainly since launch of
> P5 in 2007) had releases twice a year, and I don't think we
> should be frightened of upping that number significantly.  (On
> the other hand, we don't want to be making monthly releases, I
> don't think!?)
>
> -James
>
>
> On 25/04/12 22:02, Gabriel BODARD wrote:
>> The first week of June is likely to be bad for me; I'm back from
>> international travel around the 4th, I think, and will be groggy the
>> first couple days after that. So if not May 25th, then best to put it
>> off by two weeks. (Or someone else be launch technician...)
>>
>> G
>>
>> On 24/04/2012 10:42, James Cummings wrote:
>>>
>>> What do others think? We can of course move releasing back to
>>> whenever we've finished a majority of tickets, but I'd prefer
>>> sooner rather than later and a deadline that forces us to get
>>> stuff done.
>>>
>>> I'm of the opinion that we probably don't need to telco before
>>> this release (we can, after all, conduct business on the mailing
>>> list), but would do so shortly after the release to get updates
>>> on the longer-term issues and reports from the council working
>>> groups.
>>>
>>> thoughts?
>>>
>>> -James
>>>
>>>
>>> On 23/04/12 22:20, Piotr Ba?ski wrote:
>>>> Hi James,
>>>>
>>>> Isn't May 25 roughly in the middle of LREC? Could we shift by a week
>>>> from then, please?
>>>>
>>>> (I actually intend to be ready with my stuff [and possibly more] in
>>>> advance this time, but I've made some such totally honest promises to
>>>> myself and to the world recently, several times, and with meager results...)
>>>>
>>>> Ah. Will we telco before releasing?
>>>>
>>>> Best,
>>>>
>>>>       P.
>>>>
>>>>
>>>>
>>>> On 23/04/12 17:47, James Cummings wrote:
>>>>>
>>>>> How about we set a notional target release date of 25 May?  (This
>>>>> is about 5 weeks from now.) If we assume that we want most things
>>>>> completed by the end of Sunday 20th, to allow time for
>>>>> proofreading and error spotting.
>>>>>
>>>>> Does that sounds reasonable to most people?
>>>>>
>>>>> Gaby: Most importantly, does the proposed Release Technician like
>>>>> these dates?
>>>>>
>>>>> -James
>>>>>
>>>>>
>>>>> On 21/04/12 18:50, Martin Holmes wrote:
>>>>>> Three weeks will be a bit tough for me, and a couple of the tickets I
>>>>>> have might turn out to have unpredicted side-effects (like the tei_
>>>>>> prefix). As long as we have the option to launch without the change if
>>>>>> it proves difficult, we could go with three weeks.
>>>>>>
>>>>>> The attributes-without-examples problem is so large that we'll just have
>>>>>> to hack away at it steadily.
>>>>>>
>>>>>> Cheers,
>>>>>> Martin
>>>>>>
>>>>>> On 12-04-21 04:03 AM, Sebastian Rahtz wrote:
>>>>>>> something we forgot to debate in Ann Arbor was a timetable
>>>>>>> for the next release, I think? i.e. what is the due date for
>>>>>>> everyone to complete their ticket work so that Sir Gabriel
>>>>>>> of B'odard can undertake his Quest.
>>>>>>>
>>>>>>> speaking for myself, if I don't do my assignments
>>>>>>> more or less immediately I will not get to them for ages,
>>>>>>> so I favour a short window (say, 3 weeks).
>>>>>>>
>>>>>>> Sebastian
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>
>

-- 
Dr Gabriel BODARD
(Research Associate in Digital Epigraphy)

Department of Digital Humanities
King's College London
26-29 Drury Lane
London WC2B 5RL

Email: gabriel.bodard at kcl.ac.uk
Tel: +44 (0)20 7848 1388
Fax: +44 (0)20 7848 2980

http://www.digitalclassicist.org/
http://www.currentepigraphy.org/

From James.Cummings at oucs.ox.ac.uk  Fri Apr 27 12:13:24 2012
From: James.Cummings at oucs.ox.ac.uk (James Cummings)
Date: Fri, 27 Apr 2012 17:13:24 +0100
Subject: [tei-council] next release?
In-Reply-To: <4F9ABD9F.2040404@kcl.ac.uk>
References: <0F18A249-5480-42D9-BFF2-538AC7B9E1EB@oucs.ox.ac.uk>	<4F92F34D.2040103@uvic.ca>	<4F9579A0.8010002@oucs.ox.ac.uk>	<4F95C7A1.1080707@o2.pl>	<4F96756B.1060202@oucs.ox.ac.uk>	<4F986673.7020201@kcl.ac.uk>
	<4F9AB5A0.1090006@oucs.ox.ac.uk> <4F9ABD9F.2040404@kcl.ac.uk>
Message-ID: <4F9AC5A4.3080106@oucs.ox.ac.uk>

On 27/04/12 16:39, Gabriel BODARD wrote:
> If we end up making monthly releases at some point, I don't suppose
> there's any harm in that, but we certainly want to avoid raising the
> expectation that we're going to continue making monthly releases!

I certainly don't want to create that expectation! Just the 
expectation that we develop openly and release when significant 
changes have been made.

> I'll put May 25 in my calendar (in fact it's been there for a while).
> Will this be release 2.1.0?

Yes. Although we'll have plenty of schema-related changes (hence 
the bump to the middle number), I don't think they justify moving 
to 3.0.0 just yet.

-James

-- 
Dr James Cummings, InfoDev,
Computing Services, University of Oxford

From James.Cummings at oucs.ox.ac.uk  Fri Apr 27 12:19:57 2012
From: James.Cummings at oucs.ox.ac.uk (James Cummings)
Date: Fri, 27 Apr 2012 17:19:57 +0100
Subject: [tei-council] Addition to HD re schemaSpec in encodingDesc
In-Reply-To: <4F9ABCC0.8020803@uvic.ca>
References: <4F99DD4E.5050502@uvic.ca> <4F9ABBDE.2090501@oucs.ox.ac.uk>
	<4F9ABCC0.8020803@uvic.ca>
Message-ID: <4F9AC72D.108@oucs.ox.ac.uk>

On 27/04/12 16:35, Martin Holmes wrote:
> Do you think we should actually mention that, or does it just
> commit us to explaining something hideously complex? For
> instance, if you were intending to generate a schema from one of
> several <schemaSpec>s stored in <encodingDesc>, you'd need to
> know what stage the document was at in order to know which schema
> it should validate against; that info would have to be stored
> somewhere, etc. etc. Do we want to get into that?

You are probably right, maybe we shouldn't mention it even though 
it is a possibility.

-James

-- 
Dr James Cummings, InfoDev,
Computing Services, University of Oxford

From sebastian.rahtz at oucs.ox.ac.uk  Sat Apr 28 14:30:00 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Sat, 28 Apr 2012 18:30:00 +0000
Subject: [tei-council] brooding about override of class attributes
Message-ID: <3A34A1B3-54FE-4C5C-ADAE-05194A19E2F5@oucs.ox.ac.uk>

I am tasked with making this work:

  <elementSpec ident="p">
     <classSpec>
       <memberOf key="att.typed"/>
     </classSpec>
    <attList>
      <attDef ident="type" mode="change">
         ?.
      </attDef>
   </attList>
 </elementSpec>

in the Guidelines. which is OK. but what if
we are processing an ODD which does things with
att.typed? if it deletes @type, do we follow
suite for <div>?

can anyone philosophise on what the exact algorithm is
which I have to implement?

Sebastian

From sebastian.rahtz at oucs.ox.ac.uk  Sat Apr 28 14:41:29 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Sat, 28 Apr 2012 18:41:29 +0000
Subject: [tei-council] content model for <attDef>
Message-ID: <6C6B3B88-7118-4DF9-B58B-DD31FD3A421E@oucs.ox.ac.uk>

we currently say that an attribute looks like this:

<content>
    <group xmlns="http://relaxng.org/ns/structure/1.0">
      <zeroOrMore>
        <ref name="model.glossLike"/>
      </zeroOrMore>
      <optional>
        <ref name="datatype"/>
      </optional>
      <zeroOrMore>
        <ref name="constraintSpec"/>
      </zeroOrMore>
      <optional>
        <ref name="defaultVal"/>
      </optional>
      <optional>
        <choice>
          <ref name="valList"/>
          <oneOrMore>
            <ref name="valDesc"/>
          </oneOrMore>
        </choice>
      </optional>
      <zeroOrMore>
        <ref name="exemplum"/>
      </zeroOrMore>
      <zeroOrMore>
        <ref name="remarks"/>
      </zeroOrMore>
    </group>
  </content>

which means that it can end up with no datatype of valList at all.

What do folks think of adding a constraint that, unless its in @mode='change', you must
either supply a closed valList or a datatype?

Sebastian



From bansp at o2.pl  Sun Apr 29 04:47:21 2012
From: bansp at o2.pl (=?ISO-8859-2?Q?Piotr_Ba=F1ski?=)
Date: Sun, 29 Apr 2012 10:47:21 +0200
Subject: [tei-council] content model for <attDef>
In-Reply-To: <6C6B3B88-7118-4DF9-B58B-DD31FD3A421E@oucs.ox.ac.uk>
References: <6C6B3B88-7118-4DF9-B58B-DD31FD3A421E@oucs.ox.ac.uk>
Message-ID: <4F9D0019.4010609@o2.pl>

On 28/04/12 20:41, Sebastian Rahtz wrote:
[...]
> What do folks think of adding a constraint that, unless its in @mode='change', you must
> either supply a closed valList or a datatype?

Makes some sense to me.

Do I see correctly that, for a closed valList, there is no way to
*enforce* the specification of a datatype (of the list or of the
particular items)? (Not a huge problem, I guess, but I'm just wondering.)

Hmm, I guess part of my question is: is there a chance that by "either
... or ... " above, you mean "... or ..."?

I guess further that I'd be most happy with an obligatory datatype, but
that would probably break quite a few ODDs, wouldn't it?

  Piotr

From bansp at o2.pl  Sun Apr 29 05:05:57 2012
From: bansp at o2.pl (=?UTF-8?B?UGlvdHIgQmHFhHNraQ==?=)
Date: Sun, 29 Apr 2012 11:05:57 +0200
Subject: [tei-council] brooding about override of class attributes
In-Reply-To: <3A34A1B3-54FE-4C5C-ADAE-05194A19E2F5@oucs.ox.ac.uk>
References: <3A34A1B3-54FE-4C5C-ADAE-05194A19E2F5@oucs.ox.ac.uk>
Message-ID: <4F9D0475.4080800@o2.pl>

Do I understand correctly that the sore spot is mode="change" for a
derivedly (can one say that?) non-existent object?

And if so, I wonder how ugly it would be to have an optional attribute
(call it e.g. "@sourceSpec") that identifies the class whose member gets
overridden, so that the processor could reach there before signalling an
error of trying to change/replace/delete a non-existent object?

And in general, (do forgive my ignorance) is it possible to have an
imported part of a combined ODD change/replace an object that is then
elsewhere invoked with mode="change"? If it were so, perhaps that would
make such a "@sourceSpec" worthwhile?

  P.

On 28/04/12 20:30, Sebastian Rahtz wrote:
> I am tasked with making this work:
> 
>   <elementSpec ident="p">
>      <classSpec>
>        <memberOf key="att.typed"/>
>      </classSpec>
>     <attList>
>       <attDef ident="type" mode="change">
>          ?.
>       </attDef>
>    </attList>
>  </elementSpec>
> 
> in the Guidelines. which is OK. but what if
> we are processing an ODD which does things with
> att.typed? if it deletes @type, do we follow
> suite for <div>?
> 
> can anyone philosophise on what the exact algorithm is
> which I have to implement?
> 
> Sebastian


From lou.burnard at retired.ox.ac.uk  Sun Apr 29 07:16:23 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Sun, 29 Apr 2012 12:16:23 +0100
Subject: [tei-council] content model for <attDef>
In-Reply-To: <6C6B3B88-7118-4DF9-B58B-DD31FD3A421E@oucs.ox.ac.uk>
References: <6C6B3B88-7118-4DF9-B58B-DD31FD3A421E@oucs.ox.ac.uk>
Message-ID: <4F9D2307.90305@retired.ox.ac.uk>

On 28/04/12 19:41, Sebastian Rahtz wrote:

>
> What do folks think of adding a constraint that, unless its in @mode='change', you must
> either supply a closed valList or a datatype?
>

That is our current de facto practice, so a rule to enforce it cannot be 
a bad idea.

L

From sebastian.rahtz at oucs.ox.ac.uk  Sun Apr 29 07:16:28 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Sun, 29 Apr 2012 11:16:28 +0000
Subject: [tei-council] content model for <attDef>
In-Reply-To: <4F9D0019.4010609@o2.pl>
References: <6C6B3B88-7118-4DF9-B58B-DD31FD3A421E@oucs.ox.ac.uk>
	<4F9D0019.4010609@o2.pl>
Message-ID: <E7FA0990-CA8F-459D-81DB-9DA81A6F9520@oucs.ox.ac.uk>


On 29 Apr 2012, at 09:47, Piotr Ba?ski wrote:

> Do I see correctly that, for a closed valList, there is no way to
> *enforce* the specification of a datatype (of the list or of the
> particular items)? (Not a huge problem, I guess, but I'm just wondering.)

um, a closed valList is a fixed list of values. how does data typing fit in? if you say the 
list of allowed values is  "1.2", "freddy" and "false", is that bad in some way?

Sebastian

From lou.burnard at retired.ox.ac.uk  Sun Apr 29 07:23:06 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Sun, 29 Apr 2012 12:23:06 +0100
Subject: [tei-council] brooding about override of class attributes
In-Reply-To: <3A34A1B3-54FE-4C5C-ADAE-05194A19E2F5@oucs.ox.ac.uk>
References: <3A34A1B3-54FE-4C5C-ADAE-05194A19E2F5@oucs.ox.ac.uk>
Message-ID: <4F9D249A.2040306@retired.ox.ac.uk>

On 28/04/12 19:30, Sebastian Rahtz wrote:
> I am tasked with making this work:
>
>    <elementSpec ident="p">
>       <classSpec>
>         <memberOf key="att.typed"/>
>       </classSpec>
>      <attList>
>        <attDef ident="type" mode="change">
>           ?.
>        </attDef>
>     </attList>
>   </elementSpec>
>
> in the Guidelines. which is OK. but what if
> we are processing an ODD which does things with
> att.typed? if it deletes @type, do we follow
> suite for<div>?
>
> can anyone philosophise on what the exact algorithm is
> which I have to implement?

Tricky. Clearly if someone deletes @type from att.typed they expect it 
to disappear from all elements which inherit their @type from it. If 
those elements inherit and subsequently modify it (which is your case) I 
think on balance the same should apply, since you cannot modify 
something without first inheriting it. If someone wants to remove the 
inherited @type globally and then reinstate a locally defined @type on 
some element or elements, then that must be done with mode='add', of 
course.

I can also anticipate people being puzzled by the fact that deleting 
@type from att.typed does not remove from elements in which @type is 
locally defined, but that's another question.



From sebastian.rahtz at oucs.ox.ac.uk  Sun Apr 29 07:29:09 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Sun, 29 Apr 2012 11:29:09 +0000
Subject: [tei-council] brooding about override of class attributes
In-Reply-To: <4F9D249A.2040306@retired.ox.ac.uk>
References: <3A34A1B3-54FE-4C5C-ADAE-05194A19E2F5@oucs.ox.ac.uk>
	<4F9D249A.2040306@retired.ox.ac.uk>
Message-ID: <18638790-744b-43b5-88f4-64d5e770876a@HUB04.ad.oak.ox.ac.uk>


On 29 Apr 2012, at 12:23, Lou Burnard wrote:

> Tricky. Clearly if someone deletes @type from att.typed they expect it 
> to disappear from all elements which inherit their @type from it. If 
> those elements inherit and subsequently modify it (which is your case) I 
> think on balance the same should apply

ok. the @mode='change'  kicks in after assessing the effect of the ODDs
class changes

> I can also anticipate people being puzzled by the fact that deleting 
> @type from att.typed does not remove from elements in which @type is 
> locally defined, but that's another question.


when we have this facility in place, we can remove those occurrences
neatly, so the puzzlement level will decline over time.

Sebastian

From bansp at o2.pl  Sun Apr 29 08:03:13 2012
From: bansp at o2.pl (=?ISO-8859-2?Q?Piotr_Ba=F1ski?=)
Date: Sun, 29 Apr 2012 14:03:13 +0200
Subject: [tei-council] content model for <attDef>
In-Reply-To: <E7FA0990-CA8F-459D-81DB-9DA81A6F9520@oucs.ox.ac.uk>
References: <6C6B3B88-7118-4DF9-B58B-DD31FD3A421E@oucs.ox.ac.uk>
	<4F9D0019.4010609@o2.pl>
	<E7FA0990-CA8F-459D-81DB-9DA81A6F9520@oucs.ox.ac.uk>
Message-ID: <4F9D2E01.10400@o2.pl>

On 29/04/12 13:16, Sebastian Rahtz wrote:
> 
> On 29 Apr 2012, at 09:47, Piotr Ba?ski wrote:
> 
>> Do I see correctly that, for a closed valList, there is no way to
>> *enforce* the specification of a datatype (of the list or of the
>> particular items)? (Not a huge problem, I guess, but I'm just wondering.)
> 
> um, a closed valList is a fixed list of values. how does data typing fit in? if you say the 
> list of allowed values is  "1.2", "freddy" and "false", is that bad in some way?

I may be misunderstanding, but what is wrong with defining the datatype
for an attribute and then pre-selecting a proper subset of possible
values with that datatype?

I think I was confused when I mentioned "datatype of the list", because
that would imply validation at the level of the ODD, whereas what I have
in mind is datatyping of a value that appears in a document instance.
Whether I can choose from the infinity of integers or a set of three
integers, it may be worthwhile to state explicitly that what I mean by
"3" is an integer, as opposed to a string, for the purpose of further
processing.

I understand that it didn't work that way in DTDs, where one could
either state the datatype or enumerate the values without a datatype,
but with more elaborate schema languages, it surely is possible to
enumerate within a datatype, is it not?

Best,

 P.

From lou.burnard at retired.ox.ac.uk  Sun Apr 29 08:24:16 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Sun, 29 Apr 2012 13:24:16 +0100
Subject: [tei-council] content model for <attDef>
In-Reply-To: <4F9D2E01.10400@o2.pl>
References: <6C6B3B88-7118-4DF9-B58B-DD31FD3A421E@oucs.ox.ac.uk>
	<4F9D0019.4010609@o2.pl>
	<E7FA0990-CA8F-459D-81DB-9DA81A6F9520@oucs.ox.ac.uk>
	<4F9D2E01.10400@o2.pl>
Message-ID: <4F9D32F0.30508@retired.ox.ac.uk>

On 29/04/12 13:03, Piotr Ba?ski wrote:


> I may be misunderstanding, but what is wrong with defining the datatype
> for an attribute and then pre-selecting a proper subset of possible
> values with that datatype?
>

Nothing at all. And you can certainly do that in ODD. But I don't know 
whether Sebastian's current code will check that when both datatype and 
valList are present, they are mutually compatible. Not hard to find out 
though!


>
> I understand that it didn't work that way in DTDs, where one could
> either state the datatype or enumerate the values without a datatype,
> but with more elaborate schema languages, it surely is possible to
> enumerate within a datatype, is it not?

I think this rather depends on the schema language.


From sebastian.rahtz at oucs.ox.ac.uk  Sun Apr 29 10:07:53 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Sun, 29 Apr 2012 14:07:53 +0000
Subject: [tei-council] content model for <attDef>
In-Reply-To: <4F9D2E01.10400@o2.pl>
References: <6C6B3B88-7118-4DF9-B58B-DD31FD3A421E@oucs.ox.ac.uk>
	<4F9D0019.4010609@o2.pl>
	<E7FA0990-CA8F-459D-81DB-9DA81A6F9520@oucs.ox.ac.uk>
	<4F9D2E01.10400@o2.pl>
Message-ID: <A7DA8C45-19B0-40A5-9A2E-1AFD2A42F88E@oucs.ox.ac.uk>


On 29 Apr 2012, at 13:03, Piotr Ba?ski wrote:

> I may be misunderstanding, but what is wrong with defining the datatype
> for an attribute and then pre-selecting a proper subset of possible
> values with that datatype?

nothing wrong, but what is the point?

> 
> Whether I can choose from the infinity of integers or a set of three
> integers, it may be worthwhile to state explicitly that what I mean by
> "3" is an integer, as opposed to a string, for the purpose of further
> processing.
ah, thats the point.  I think you'd want to  through the details of this
and see how the different schema languages work 

> 
> I understand that it didn't work that way in DTDs, where one could
> either state the datatype or enumerate the values without a datatype,
> but with more elaborate schema languages, it surely is possible to
> enumerate within a datatype, is it not?


really not sure

sebastian

From bansp at o2.pl  Sun Apr 29 11:55:41 2012
From: bansp at o2.pl (=?ISO-8859-2?Q?Piotr_Ba=F1ski?=)
Date: Sun, 29 Apr 2012 17:55:41 +0200
Subject: [tei-council] searchable archive?, @corresp
Message-ID: <4F9D647D.6040302@o2.pl>

Do we have a searchable version of the Council list archive, or is
pipermail our only crippled friend when it comes to recalling the past
exchanges?

Laurent in an e-mail conversation mentioned to me that he recalls some
Council discussion on @corresp vs. @target, but I can't locate it in my
mailbox. Which is naturally very incomplete.

So if the answer to my first question is unfortunately positive, I have
another: does anyone recall such a discussion, and roughly its time
frame? So far, I only did a quick search of all the subjects in the
archive, to no avail.

Thanks in advance!

  Piotr

From dsewell at virginia.edu  Sun Apr 29 13:10:46 2012
From: dsewell at virginia.edu (David Sewell)
Date: Sun, 29 Apr 2012 13:10:46 -0400 (EDT)
Subject: [tei-council] searchable archive?, @corresp
In-Reply-To: <4F9D647D.6040302@o2.pl>
References: <4F9D647D.6040302@o2.pl>
Message-ID: <alpine.OSX.2.00.1204291308030.7723@koson.local>

The pipermail text archives are the only option currently.

The Board is considering whether to migrate their email list to one with 
public archives. If that decision is "yes" it might be a good time to 
explore moving the Council list at the same time to a more robust 
platform. Virginia is now using Sympa (http://www.sympa.org/) for new 
lists and I believe I could get assistance migrating an old 
pipermail/Mailman archive to Sympa format.

David

On Sun, 29 Apr 2012, Piotr Ba?ski wrote:

> Do we have a searchable version of the Council list archive, or is
> pipermail our only crippled friend when it comes to recalling the past
> exchanges?
>
> Laurent in an e-mail conversation mentioned to me that he recalls some
> Council discussion on @corresp vs. @target, but I can't locate it in my
> mailbox. Which is naturally very incomplete.
>
> So if the answer to my first question is unfortunately positive, I have
> another: does anyone recall such a discussion, and roughly its time
> frame? So far, I only did a quick search of all the subjects in the
> archive, to no avail.
>
> Thanks in advance!
>
>  Piotr
>

-- 
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 syeates at gmail.com  Mon Apr 30 06:18:10 2012
From: syeates at gmail.com (stuart yeates)
Date: Mon, 30 Apr 2012 22:18:10 +1200
Subject: [tei-council] DCR alignment inside ODD
In-Reply-To: <4F26B857-B17C-4819-A224-2678E5ADD75A@oucs.ox.ac.uk>
References: <4F986124.30406@o2.pl>
	<4F26B857-B17C-4819-A224-2678E5ADD75A@oucs.ox.ac.uk>
Message-ID: <4F9E66E2.4090704@gmail.com>

On 26/04/12 08:59, Sebastian Rahtz wrote:
>
> On 25 Apr 2012, at 21:40, Piotr Ba?ski wrote:
>
>> I'm working on the ISO DCR / ISOcat issues.[1] Got stuck at the point of
>> adding the relevant pieces of text to the Guidelines.
>>
>> The enlightened way to align grammatical categories with the values of
>> the DCR is to put the appropriate references into the ODD, and I guess
>> <equiv>  is the ideal place for that.
>>
>> I imagine, and please correct me if I am wrong, that for elements such
>> as<pos>, this action may be trivial:
>>
>> <elementSpec ident="pos" mode="change">
>>    <equiv dcr:datcat="http://www.isocat.org/datcat/DC-1345"/>
>> </elementSpec>
>
> <equiv url="http://www.isocat.org/datcat/DC-1345"/>  is the syntax, I think.

I've been looking at http://www.isocat.org/datcat/DC-1345 in more detail.

I've written up a quick XSLT to transform the webpage into a DTD (see 
both transform and output below). Feedback welcome. Is it worth 
including this in the TEI distribution?

I've also submitted a replace URL for the reference at 
https://sourceforge.net/tracker/index.php?func=detail&aid=3522517&group_id=244572&atid=1126007 
(Note that's the ISOCat tracker not the TEI tracker).

cheers
stuart

?xml version="1.0"?>
<xsl:stylesheet  version="1.0"
		 xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
		 >
      <xsl:output method="text"/>

   <xsl:template match="/">
     <xsl:text>#Attributes from http://www.isocat.org/rest/dc/1345
</xsl:text>

     <xsl:text><![CDATA[<!ATTLIST dcr:cat type (
]]></xsl:text>
     <xsl:apply-templates select="//tr[.//a/@datcat]"/>
     <xsl:text><![CDATA[) "">]]></xsl:text>
   </xsl:template>

   <xsl:template match="tr" >
     <xsl:value-of select="td[2]//a"/>
     <xsl:text><![CDATA[|
]]></xsl:text>
   </xsl:template>

</xsl:stylesheet>


#Attributes from http://www.isocat.org/rest/dc/1345
<!ATTLIST dcr:cat type (
adjective|
adposition|
adverb|
adverbialPronoun|
affirmativeParticle|
affixedPersonalPronoun|
allusivePronoun|
article|
bullet|
cardinalNumeral|
circumposition|
closeParenthesis|
collectivePronoun|
colon|
comma|
commonNoun|
comparativeParticle|
compoundPreposition|
conditionalParticle|
conditionalPronoun|
conjunction|
coordinatingConjunction|
coordinationParticle|
copula|
deficientVerb|
definiteArticle|
demonstrativeDeterminer|
demonstrativePronoun|
determiner|
diminutiveNoun|
distinctiveParticle|
echo|
emphaticPronoun|
exclamativeDeterminer|
exclamativePoint|
exclamativePronoun|
existentialPronoun|
fusedPreposition|
fusedPrepositionDeterminer|
fusedPrepositionPronoun|
fusedPronounAuxiliary|
futureParticle|
generalAdverb|
generalizationWord|
genericNumeral|
impersonalPronoun|
indefiniteArticle|
indefiniteCardinalNumeral|
indefiniteDeterminer|
indefiniteMultiplicativeNumeral|
indefiniteOrdinalNumeral|
indefinitePronoun|
infinitiveParticle|
interjection|
interrogativeCardinalNumeral|
interrogativeDeterminer|
interrogativeMultiplicativeNumeral|
interrogativeOrdinalNumeral|
interrogativeParticle|
interrogativePronoun|
interrogativeRelativePronoun|
invertedComma|
irreflexivePersonalPronoun|
lightVerb|
mainVerb|
modal|
multiplicativeNumeral|
negativeParticle|
negativePronoun|
noun|
numeral|
numeralFraction|
openParenthesis|
ordinalAdjective|
participleAdjective|
particle|
particleAdverb|
partitiveArticle|
pastParticipleAdjective|
personalPronoun|
plainVerb|
point|
possessiveAdjective|
possessiveDeterminer|
possessiveParticle|
possessivePronoun|
possessiveRelativePronoun|
postposition|
preposition|
prepositionalAdverb|
presentParticipleAdjective|
presentativePronoun|
pronominalAdverb|
pronoun|
properNoun|
punctuation|
qualifierAdjective|
questionMark|
reciprocalPronoun|
reduplicative|
reflexiveDeterminer|
reflexivePersonalPronoun|
reflexivePossessivePronoun|
relationNoun|
relativeDeterminer|
relativeParticle|
relativePronoun|
semiColon|
simplePreposition|
slash|
strongPersonalPronoun|
subordinatingConjunction|
superlativeParticle|
suspensionPoints|
unclassifiedParticle|
verb|
voiceNoun|
weakPersonalPronoun|
adjective|
adverb|
noun|
verb|
) "">





From bansp at o2.pl  Mon Apr 30 06:44:24 2012
From: bansp at o2.pl (=?ISO-8859-2?Q?Piotr_Ba=F1ski?=)
Date: Mon, 30 Apr 2012 12:44:24 +0200
Subject: [tei-council] DCR alignment inside ODD
In-Reply-To: <4F9E66E2.4090704@gmail.com>
References: <4F986124.30406@o2.pl>
	<4F26B857-B17C-4819-A224-2678E5ADD75A@oucs.ox.ac.uk>
	<4F9E66E2.4090704@gmail.com>
Message-ID: <4F9E6D08.2020908@o2.pl>

Hi Stuart,

On 30/04/12 12:18, stuart yeates wrote:
[...]
> I've been looking at http://www.isocat.org/datcat/DC-1345 in more detail.
> 
> I've written up a quick XSLT to transform the webpage into a DTD (see 
> both transform and output below). Feedback welcome. Is it worth 
> including this in the TEI distribution?

I believe that part of the intended charm of ISOcat is that it is both
static and dynamic: it provides a potential variety of systems (e.g. for
POS and more refined grammatical information) which are frozen for
external reference. The reason that there are a variety of systems is
that no common agreement in this area can be reached, but the
user/scholarly communities may at least communicate their ontological
concepts, and various networks of relationships can be postulated among
them, externally to ISOcat.

Adopting a single view as a snapshot of one section of ISOcat may
actually be contrary to the entire principle, and would place the TEI in
one concrete position on the map of competing reference networks, with
the immediate question of "why this one and not any of the others?". We
would be moving from a standards view that tries to enable
interoperability by aligning the concepts to the view of "one golden
standard to rule them all", which has been shown to be untenable.

Furthermore, ISOcat is not the only framework of reference possible. I
think what we want is to provide a way to uniformly relate to *some*
external repository of concepts, rather than taking a *single* snapshot
from *one* repository.

Best,

  P.

From syeates at gmail.com  Mon Apr 30 06:48:08 2012
From: syeates at gmail.com (stuart yeates)
Date: Mon, 30 Apr 2012 22:48:08 +1200
Subject: [tei-council] DCR alignment inside ODD
In-Reply-To: <4F9E6D08.2020908@o2.pl>
References: <4F986124.30406@o2.pl>
	<4F26B857-B17C-4819-A224-2678E5ADD75A@oucs.ox.ac.uk>
	<4F9E66E2.4090704@gmail.com> <4F9E6D08.2020908@o2.pl>
Message-ID: <4F9E6DE8.6020900@gmail.com>

On 30/04/12 22:44, Piotr Ba?ski wrote:
> Furthermore, ISOcat is not the only framework of reference possible. I
> think what we want is to provide a way to uniformly relate to *some*
> external repository of concepts, rather than taking a *single* snapshot
> from *one* repository.

I can live with that, but I feel that we need to provide concrete tools 
to help users validate their documents.

Maybe you could nominate a couple of other snapshots / repositories and 
I'll generate DTDs for them too?

cheers
stuart


From sebastian.rahtz at oucs.ox.ac.uk  Mon Apr 30 08:06:12 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Mon, 30 Apr 2012 12:06:12 +0000
Subject: [tei-council] DCR alignment inside ODD
In-Reply-To: <4F9E66E2.4090704@gmail.com>
References: <4F986124.30406@o2.pl>
	<4F26B857-B17C-4819-A224-2678E5ADD75A@oucs.ox.ac.uk>
	<4F9E66E2.4090704@gmail.com>
Message-ID: <5AE50F7D-77AF-4D2D-9B70-B7C02422E595@oucs.ox.ac.uk>


On 30 Apr 2012, at 11:18, stuart yeates wrote:

> 
> I've written up a quick XSLT to transform the webpage into a DTD (see 
> both transform and output below). Feedback welcome. Is it worth 
> including this in the TEI distribution?
> 
if there is a fixed list of possible values for dcr:datcat, 
we should surely enforce this directly in our schema,
as a <valList type="closed">?


--
Stormageddon Rahtz      
Head of Information and Support Group
Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431

S?lo le pido a Dios
que el futuro no me sea indiferente


From bansp at o2.pl  Mon Apr 30 09:09:38 2012
From: bansp at o2.pl (=?ISO-8859-2?Q?Piotr_Ba=F1ski?=)
Date: Mon, 30 Apr 2012 15:09:38 +0200
Subject: [tei-council] DCR alignment inside ODD
In-Reply-To: <5AE50F7D-77AF-4D2D-9B70-B7C02422E595@oucs.ox.ac.uk>
References: <4F986124.30406@o2.pl>
	<4F26B857-B17C-4819-A224-2678E5ADD75A@oucs.ox.ac.uk>
	<4F9E66E2.4090704@gmail.com>
	<5AE50F7D-77AF-4D2D-9B70-B7C02422E595@oucs.ox.ac.uk>
Message-ID: <4F9E8F12.30709@o2.pl>

On 30/04/12 14:06, Sebastian Rahtz wrote:
> 
> On 30 Apr 2012, at 11:18, stuart yeates wrote:
> 
>>
>> I've written up a quick XSLT to transform the webpage into a DTD (see 
>> both transform and output below). Feedback welcome. Is it worth 
>> including this in the TEI distribution?
>>
> if there is a fixed list of possible values for dcr:datcat, 
> we should surely enforce this directly in our schema,
> as a <valList type="closed">?

My point was that there are many such lists. And the one chosen by
Stuart is no better than the others. It's just the first to be input.
Hopefully not the last.

And in general, why copy something that is maintained separately? I'd
rather not see the TEI tied to one random set of solutions, contested by
more parties than back it up.

Flexibility lies in providing the option to refer to external
collections, rather than tying the TEI to one of them, selected at
random. Next thing, we're going to recommend values for "gender", with
e.g. "feminine" defined as "referring to women" or something equally
sorry that you can find in ISOcat descriptions.

  P.

From mholmes at uvic.ca  Mon Apr 30 11:57:20 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Mon, 30 Apr 2012 08:57:20 -0700
Subject: [tei-council] zones inside zones?
In-Reply-To: <4F9E5C0A.6080200@oucs.ox.ac.uk>
References: <CAPXT2Vuw5thvaOY6B4-P6DvVhTC5ZLD9TzxN6BMEdwVmZzgNGg@mail.gmail.com>
	<4F9AB22A.6090206@faustedition.de>
	<4F9AC9AB.2000302@retired.ox.ac.uk> <4F9D4604.3080504@versi.edu.au>
	<4F9E5C0A.6080200@oucs.ox.ac.uk>
Message-ID: <4F9EB660.20208@uvic.ca>

I'm bringing this discussion over to the Council list, because I'm a bit 
puzzled about what we did with @points here:

On 12-04-30 02:31 AM, James Cummings wrote:
> On 29/04/12 14:45, Conal Tuohy wrote:
>> It appears that the<zone>  element has expanded in scope since
>> the time we added it to TEI P5 1.0. At that time, if I remember
>> correctly, it could not nest, and in fact had a very limited
>> content model (just<gloss>,<desc>, etc.). At that time, the
>> Council's view was that allowing nesting of<zone>  elements would
>> add complexity without any additional functionality, and I
>> honestly don't know the rationale for the subsequent change.
>
> Digging around in the http://www.tei-c.org/Vault/P5/ confirms
> that the big change for<zone>  came in release 2.0.0 when we
> added the genetic editing abilities and<sourceDoc>.  It is at
> this point that it gets @points as a separate attribute
> (previously in att.coordinated), @rotate, and its element content
> model changes from:
> ( model.glossLike*, model.graphicLike* )
> to:
> (text | model.graphicLike | model.global | surface |
> model.linePart )*

I don't remember deciding to remove @points from att.coordinated and 
define it directly on <zone>. Looking at the SVN log, I didn't find any 
mention of this, even though between 1.9.1 (May last year) and 2.0.0 
(December) the change was clearly made. I found nothing on any of the 
tickets that would prompt this change, nor did I see anything in Council 
minutes that suggests we decided to do it.

Looking closer, it appears the changes was made by Lou in rev 9790, for 
which this was the message:

"introduce model.linePart class; add line to it; move @coords out of 
att.coordinated"

However, there is no attribute @coords; a diff shows that it was 
actually @points that was moved:

svn diff -r 9789:9790 att.coordinated.xml
Index: att.coordinated.xml
===================================================================
--- att.coordinated.xml	(revision 9789)
+++ att.coordinated.xml	(revision 9790)
@@ -83,15 +83,6 @@
          <rng:ref name="data.numeric"/>
        </datatype>
      </attDef>
-<attDef ident="points">
-<desc>identifies a non-rectangular area within the bounding box
-specified by the other attributes  by specifying
-a series of pairs of numbers, each of which gives the x,y coordinates
-of a point on a line defining the non-rectangular area.</desc>
-<datatype minOccurs="3" maxOccurs="unbounded">
-<rng:ref name="data.point"/>
-</datatype>
-</attDef>

Lou, do you remember why you made this change? Doesn't @points belong in 
att.coordinated? Or have I missed a discussion or a ticket somewhere?

Cheers,
Martin

> This is because in its new existence in<sourceDoc>  it is allowed
> to have transcribed (but un-interpreted) text in it. Nesting
> <zone>  elements inside<sourceDoc>  make more sense to me, but
> make much less sense inside<facsimile>.
>
> It might be a reasonable feature request to have a TEI schematron
> rule that reduced<zone>  as a descendent of<facsimile>  to not
> allow nesting, and only allow the equivalent of its original
> content model of (model.glossLike*, model.graphicLike*). That is,
> at least, how I'll use it in documents I encode.
>
> -James
>

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From lou.burnard at retired.ox.ac.uk  Mon Apr 30 13:07:00 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Mon, 30 Apr 2012 18:07:00 +0100
Subject: [tei-council] zones inside zones?
In-Reply-To: <4F9EB660.20208@uvic.ca>
References: <CAPXT2Vuw5thvaOY6B4-P6DvVhTC5ZLD9TzxN6BMEdwVmZzgNGg@mail.gmail.com>
	<4F9AB22A.6090206@faustedition.de>
	<4F9AC9AB.2000302@retired.ox.ac.uk> <4F9D4604.3080504@versi.edu.au>
	<4F9E5C0A.6080200@oucs.ox.ac.uk> <4F9EB660.20208@uvic.ca>
Message-ID: <4F9EC6B4.7060608@retired.ox.ac.uk>

As one Martin Holmes noted on the Council list back on 10 Nov 2011,
the co-ordinate space (defined by a <surface>) must be rectangular.
Further, on 19 Nov 2011, one Sebastian Rahtz (remember him?) remarks 
categorically

"it [the case where a <surface> contains both coordinates and @point]
is a plain ole error, I'd say"

Holmes also says, on 20 Nov 2011m

"I think we agreed that since <surface> is always establishing a
coordinate system, and a coordinate system must always be rectangular,
we don't need @points on <surface>, only on <zone>.
That gives us the rather odd possibility of a non-rectangular <zone>
which contains a <surface> that must have a rectangular coordinate
system, though."


THEREFORE since <surface> inherits the coordination attributes from 
att.coordinated, @points should not be a member of att.coordinated. 
Faced with a choice of defining four attributes locally on several 
elements, or one attribute (@points) locally on <zone>, your humble 
editor obviously took the path of least effort.



On 30/04/12 16:57, Martin Holmes wrote:
> I'm bringing this discussion over to the Council list, because I'm a bit
> puzzled about what we did with @points here:
>
> On 12-04-30 02:31 AM, James Cummings wrote:
>> On 29/04/12 14:45, Conal Tuohy wrote:
>>> It appears that the<zone>   element has expanded in scope since
>>> the time we added it to TEI P5 1.0. At that time, if I remember
>>> correctly, it could not nest, and in fact had a very limited
>>> content model (just<gloss>,<desc>, etc.). At that time, the
>>> Council's view was that allowing nesting of<zone>   elements would
>>> add complexity without any additional functionality, and I
>>> honestly don't know the rationale for the subsequent change.
>>
>> Digging around in the http://www.tei-c.org/Vault/P5/ confirms
>> that the big change for<zone>   came in release 2.0.0 when we
>> added the genetic editing abilities and<sourceDoc>.  It is at
>> this point that it gets @points as a separate attribute
>> (previously in att.coordinated), @rotate, and its element content
>> model changes from:
>> ( model.glossLike*, model.graphicLike* )
>> to:
>> (text | model.graphicLike | model.global | surface |
>> model.linePart )*
>
> I don't remember deciding to remove @points from att.coordinated and
> define it directly on<zone>. Looking at the SVN log, I didn't find any
> mention of this, even though between 1.9.1 (May last year) and 2.0.0
> (December) the change was clearly made. I found nothing on any of the
> tickets that would prompt this change, nor did I see anything in Council
> minutes that suggests we decided to do it.
>
> Looking closer, it appears the changes was made by Lou in rev 9790, for
> which this was the message:
>
> "introduce model.linePart class; add line to it; move @coords out of
> att.coordinated"
>
> However, there is no attribute @coords; a diff shows that it was
> actually @points that was moved:
>
> svn diff -r 9789:9790 att.coordinated.xml
> Index: att.coordinated.xml
> ===================================================================
> --- att.coordinated.xml	(revision 9789)
> +++ att.coordinated.xml	(revision 9790)
> @@ -83,15 +83,6 @@
>            <rng:ref name="data.numeric"/>
>          </datatype>
>        </attDef>
> -<attDef ident="points">
> -<desc>identifies a non-rectangular area within the bounding box
> -specified by the other attributes  by specifying
> -a series of pairs of numbers, each of which gives the x,y coordinates
> -of a point on a line defining the non-rectangular area.</desc>
> -<datatype minOccurs="3" maxOccurs="unbounded">
> -<rng:ref name="data.point"/>
> -</datatype>
> -</attDef>
>
> Lou, do you remember why you made this change? Doesn't @points belong in
> att.coordinated? Or have I missed a discussion or a ticket somewhere?
>
> Cheers,
> Martin
>
>> This is because in its new existence in<sourceDoc>   it is allowed
>> to have transcribed (but un-interpreted) text in it. Nesting
>> <zone>   elements inside<sourceDoc>   make more sense to me, but
>> make much less sense inside<facsimile>.
>>
>> It might be a reasonable feature request to have a TEI schematron
>> rule that reduced<zone>   as a descendent of<facsimile>   to not
>> allow nesting, and only allow the equivalent of its original
>> content model of (model.glossLike*, model.graphicLike*). That is,
>> at least, how I'll use it in documents I encode.
>>
>> -James
>>
>


From mholmes at uvic.ca  Mon Apr 30 13:13:34 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Mon, 30 Apr 2012 10:13:34 -0700
Subject: [tei-council] zones inside zones?
In-Reply-To: <4F9EC6B4.7060608@retired.ox.ac.uk>
References: <CAPXT2Vuw5thvaOY6B4-P6DvVhTC5ZLD9TzxN6BMEdwVmZzgNGg@mail.gmail.com>
	<4F9AB22A.6090206@faustedition.de>	<4F9AC9AB.2000302@retired.ox.ac.uk>
	<4F9D4604.3080504@versi.edu.au>	<4F9E5C0A.6080200@oucs.ox.ac.uk>
	<4F9EB660.20208@uvic.ca> <4F9EC6B4.7060608@retired.ox.ac.uk>
Message-ID: <4F9EC83E.9080108@uvic.ca>

Thanks Lou. Makes perfect sense. Sorry my memory is so faulty these days.

Cheers,
Martin

On 12-04-30 10:07 AM, Lou Burnard wrote:
> As one Martin Holmes noted on the Council list back on 10 Nov 2011,
> the co-ordinate space (defined by a<surface>) must be rectangular.
> Further, on 19 Nov 2011, one Sebastian Rahtz (remember him?) remarks
> categorically
>
> "it [the case where a<surface>  contains both coordinates and @point]
> is a plain ole error, I'd say"
>
> Holmes also says, on 20 Nov 2011m
>
> "I think we agreed that since<surface>  is always establishing a
> coordinate system, and a coordinate system must always be rectangular,
> we don't need @points on<surface>, only on<zone>.
> That gives us the rather odd possibility of a non-rectangular<zone>
> which contains a<surface>  that must have a rectangular coordinate
> system, though."
>
>
> THEREFORE since<surface>  inherits the coordination attributes from
> att.coordinated, @points should not be a member of att.coordinated.
> Faced with a choice of defining four attributes locally on several
> elements, or one attribute (@points) locally on<zone>, your humble
> editor obviously took the path of least effort.
>
>
>
> On 30/04/12 16:57, Martin Holmes wrote:
>> I'm bringing this discussion over to the Council list, because I'm a bit
>> puzzled about what we did with @points here:
>>
>> On 12-04-30 02:31 AM, James Cummings wrote:
>>> On 29/04/12 14:45, Conal Tuohy wrote:
>>>> It appears that the<zone>    element has expanded in scope since
>>>> the time we added it to TEI P5 1.0. At that time, if I remember
>>>> correctly, it could not nest, and in fact had a very limited
>>>> content model (just<gloss>,<desc>, etc.). At that time, the
>>>> Council's view was that allowing nesting of<zone>    elements would
>>>> add complexity without any additional functionality, and I
>>>> honestly don't know the rationale for the subsequent change.
>>>
>>> Digging around in the http://www.tei-c.org/Vault/P5/ confirms
>>> that the big change for<zone>    came in release 2.0.0 when we
>>> added the genetic editing abilities and<sourceDoc>.  It is at
>>> this point that it gets @points as a separate attribute
>>> (previously in att.coordinated), @rotate, and its element content
>>> model changes from:
>>> ( model.glossLike*, model.graphicLike* )
>>> to:
>>> (text | model.graphicLike | model.global | surface |
>>> model.linePart )*
>>
>> I don't remember deciding to remove @points from att.coordinated and
>> define it directly on<zone>. Looking at the SVN log, I didn't find any
>> mention of this, even though between 1.9.1 (May last year) and 2.0.0
>> (December) the change was clearly made. I found nothing on any of the
>> tickets that would prompt this change, nor did I see anything in Council
>> minutes that suggests we decided to do it.
>>
>> Looking closer, it appears the changes was made by Lou in rev 9790, for
>> which this was the message:
>>
>> "introduce model.linePart class; add line to it; move @coords out of
>> att.coordinated"
>>
>> However, there is no attribute @coords; a diff shows that it was
>> actually @points that was moved:
>>
>> svn diff -r 9789:9790 att.coordinated.xml
>> Index: att.coordinated.xml
>> ===================================================================
>> --- att.coordinated.xml	(revision 9789)
>> +++ att.coordinated.xml	(revision 9790)
>> @@ -83,15 +83,6 @@
>>             <rng:ref name="data.numeric"/>
>>           </datatype>
>>         </attDef>
>> -<attDef ident="points">
>> -<desc>identifies a non-rectangular area within the bounding box
>> -specified by the other attributes  by specifying
>> -a series of pairs of numbers, each of which gives the x,y coordinates
>> -of a point on a line defining the non-rectangular area.</desc>
>> -<datatype minOccurs="3" maxOccurs="unbounded">
>> -<rng:ref name="data.point"/>
>> -</datatype>
>> -</attDef>
>>
>> Lou, do you remember why you made this change? Doesn't @points belong in
>> att.coordinated? Or have I missed a discussion or a ticket somewhere?
>>
>> Cheers,
>> Martin
>>
>>> This is because in its new existence in<sourceDoc>    it is allowed
>>> to have transcribed (but un-interpreted) text in it. Nesting
>>> <zone>    elements inside<sourceDoc>    make more sense to me, but
>>> make much less sense inside<facsimile>.
>>>
>>> It might be a reasonable feature request to have a TEI schematron
>>> rule that reduced<zone>    as a descendent of<facsimile>    to not
>>> allow nesting, and only allow the equivalent of its original
>>> content model of (model.glossLike*, model.graphicLike*). That is,
>>> at least, how I'll use it in documents I encode.
>>>
>>> -James
>>>
>>
>

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From syeates at gmail.com  Mon Apr 30 17:16:05 2012
From: syeates at gmail.com (Stuart A. Yeates)
Date: Tue, 1 May 2012 09:16:05 +1200
Subject: [tei-council] DCR alignment inside ODD
In-Reply-To: <4F9E8F12.30709@o2.pl>
References: <4F986124.30406@o2.pl>
	<4F26B857-B17C-4819-A224-2678E5ADD75A@oucs.ox.ac.uk>
	<4F9E66E2.4090704@gmail.com>
	<5AE50F7D-77AF-4D2D-9B70-B7C02422E595@oucs.ox.ac.uk>
	<4F9E8F12.30709@o2.pl>
Message-ID: <CAC_Lu0Zp35Gn7J=K4jLZ4FW0Jf5wBMOK66oMm5Gvzm5qpB6Omg@mail.gmail.com>

On Tue, May 1, 2012 at 1:09 AM, Piotr Ba?ski <bansp at o2.pl> wrote:
> On 30/04/12 14:06, Sebastian Rahtz wrote:
>>
>> On 30 Apr 2012, at 11:18, stuart yeates wrote:
>>
>>>
>>> I've written up a quick XSLT to transform the webpage into a DTD (see
>>> both transform and output below). Feedback welcome. Is it worth
>>> including this in the TEI distribution?
>>>
>> if there is a fixed list of possible values for dcr:datcat,
>> we should surely enforce this directly in our schema,
>> as a <valList type="closed">?
>
> My point was that there are many such lists. And the one chosen by
> Stuart is no better than the others. It's just the first to be input.
> Hopefully not the last.
>
> And in general, why copy something that is maintained separately? I'd
> rather not see the TEI tied to one random set of solutions, contested by
> more parties than back it up.

I agree that maintaining something separate is a bad idea. My plan was
the have the XSLT and two lines in a make file in the TEI svn to build
a new list from the web page every time we did a build / release.

> Flexibility lies in providing the option to refer to external
> collections, rather than tying the TEI to one of them, selected at
> random. Next thing, we're going to recommend values for "gender", with
> e.g. "feminine" defined as "referring to women" or something equally
> sorry that you can find in ISOcat descriptions.

I completely agree. Indeed the list I supplied doesn't satisfactorily
cover the Eastern Polynesian languages I care about.

Maybe we should put this on hold?

cheers
stuart

From James.Cummings at oucs.ox.ac.uk  Mon Apr 30 18:17:37 2012
From: James.Cummings at oucs.ox.ac.uk (James Cummings)
Date: Mon, 30 Apr 2012 23:17:37 +0100
Subject: [tei-council] zones inside zones?
In-Reply-To: <4F9EC83E.9080108@uvic.ca>
References: <CAPXT2Vuw5thvaOY6B4-P6DvVhTC5ZLD9TzxN6BMEdwVmZzgNGg@mail.gmail.com>
	<4F9AB22A.6090206@faustedition.de>	<4F9AC9AB.2000302@retired.ox.ac.uk>
	<4F9D4604.3080504@versi.edu.au>	<4F9E5C0A.6080200@oucs.ox.ac.uk>
	<4F9EB660.20208@uvic.ca> <4F9EC6B4.7060608@retired.ox.ac.uk>
	<4F9EC83E.9080108@uvic.ca>
Message-ID: <4F9F0F81.80101@oucs.ox.ac.uk>


Would one of you relate this back to TEI-L for those who were 
following that discussion? The others in the discussion might 
appreciate it.

Best,
-James


On 30/04/12 18:13, Martin Holmes wrote:
> Thanks Lou. Makes perfect sense. Sorry my memory is so faulty these days.
>
> Cheers,
> Martin
>
> On 12-04-30 10:07 AM, Lou Burnard wrote:
>> As one Martin Holmes noted on the Council list back on 10 Nov 2011,
>> the co-ordinate space (defined by a<surface>) must be rectangular.
>> Further, on 19 Nov 2011, one Sebastian Rahtz (remember him?) remarks
>> categorically
>>
>> "it [the case where a<surface>   contains both coordinates and @point]
>> is a plain ole error, I'd say"
>>
>> Holmes also says, on 20 Nov 2011m
>>
>> "I think we agreed that since<surface>   is always establishing a
>> coordinate system, and a coordinate system must always be rectangular,
>> we don't need @points on<surface>, only on<zone>.
>> That gives us the rather odd possibility of a non-rectangular<zone>
>> which contains a<surface>   that must have a rectangular coordinate
>> system, though."
>>
>>
>> THEREFORE since<surface>   inherits the coordination attributes from
>> att.coordinated, @points should not be a member of att.coordinated.
>> Faced with a choice of defining four attributes locally on several
>> elements, or one attribute (@points) locally on<zone>, your humble
>> editor obviously took the path of least effort.
>>
>>
>>
>> On 30/04/12 16:57, Martin Holmes wrote:
>>> I'm bringing this discussion over to the Council list, because I'm a bit
>>> puzzled about what we did with @points here:
>>>
>>> On 12-04-30 02:31 AM, James Cummings wrote:
>>>> On 29/04/12 14:45, Conal Tuohy wrote:
>>>>> It appears that the<zone>     element has expanded in scope since
>>>>> the time we added it to TEI P5 1.0. At that time, if I remember
>>>>> correctly, it could not nest, and in fact had a very limited
>>>>> content model (just<gloss>,<desc>, etc.). At that time, the
>>>>> Council's view was that allowing nesting of<zone>     elements would
>>>>> add complexity without any additional functionality, and I
>>>>> honestly don't know the rationale for the subsequent change.
>>>>
>>>> Digging around in the http://www.tei-c.org/Vault/P5/ confirms
>>>> that the big change for<zone>     came in release 2.0.0 when we
>>>> added the genetic editing abilities and<sourceDoc>.  It is at
>>>> this point that it gets @points as a separate attribute
>>>> (previously in att.coordinated), @rotate, and its element content
>>>> model changes from:
>>>> ( model.glossLike*, model.graphicLike* )
>>>> to:
>>>> (text | model.graphicLike | model.global | surface |
>>>> model.linePart )*
>>>
>>> I don't remember deciding to remove @points from att.coordinated and
>>> define it directly on<zone>. Looking at the SVN log, I didn't find any
>>> mention of this, even though between 1.9.1 (May last year) and 2.0.0
>>> (December) the change was clearly made. I found nothing on any of the
>>> tickets that would prompt this change, nor did I see anything in Council
>>> minutes that suggests we decided to do it.
>>>
>>> Looking closer, it appears the changes was made by Lou in rev 9790, for
>>> which this was the message:
>>>
>>> "introduce model.linePart class; add line to it; move @coords out of
>>> att.coordinated"
>>>
>>> However, there is no attribute @coords; a diff shows that it was
>>> actually @points that was moved:
>>>
>>> svn diff -r 9789:9790 att.coordinated.xml
>>> Index: att.coordinated.xml
>>> ===================================================================
>>> --- att.coordinated.xml	(revision 9789)
>>> +++ att.coordinated.xml	(revision 9790)
>>> @@ -83,15 +83,6 @@
>>>              <rng:ref name="data.numeric"/>
>>>            </datatype>
>>>          </attDef>
>>> -<attDef ident="points">
>>> -<desc>identifies a non-rectangular area within the bounding box
>>> -specified by the other attributes  by specifying
>>> -a series of pairs of numbers, each of which gives the x,y coordinates
>>> -of a point on a line defining the non-rectangular area.</desc>
>>> -<datatype minOccurs="3" maxOccurs="unbounded">
>>> -<rng:ref name="data.point"/>
>>> -</datatype>
>>> -</attDef>
>>>
>>> Lou, do you remember why you made this change? Doesn't @points belong in
>>> att.coordinated? Or have I missed a discussion or a ticket somewhere?
>>>
>>> Cheers,
>>> Martin
>>>
>>>> This is because in its new existence in<sourceDoc>     it is allowed
>>>> to have transcribed (but un-interpreted) text in it. Nesting
>>>> <zone>     elements inside<sourceDoc>     make more sense to me, but
>>>> make much less sense inside<facsimile>.
>>>>
>>>> It might be a reasonable feature request to have a TEI schematron
>>>> rule that reduced<zone>     as a descendent of<facsimile>     to not
>>>> allow nesting, and only allow the equivalent of its original
>>>> content model of (model.glossLike*, model.graphicLike*). That is,
>>>> at least, how I'll use it in documents I encode.
>>>>
>>>> -James
>>>>
>>>
>>
>


-- 
Dr James Cummings, InfoDev,
Computing Services, University of Oxford

From syeates at gmail.com  Tue May  1 19:24:02 2012
From: syeates at gmail.com (Stuart A. Yeates)
Date: Wed, 2 May 2012 11:24:02 +1200
Subject: [tei-council] Usefulness of http://www.tei-c.org/ns/1.0/
Message-ID: <CAC_Lu0YBE-JRW7XsZvFdx03ZYa9tuM1rCBbjtP2EO3W=GFLg_Q@mail.gmail.com>

It has been pointed out to me (on IRC) that the HTML served up for
http://www.tei-c.org/ns/1.0/ may not be ideal. I would like to propose
an additional paragraph of content specifically to assist XML-using
but TEI-unaware users who are likely to have arrived at the page
having found the URL in some random TEI:

"The full text of the current TEI standard is online
[http://www.tei-c.org/release/doc/tei-p5-doc/en/html/index-toc.html],
the current DTD
[http://www.tei-c.org/Vault/P5/current/xml/tei/schema/dtd/tei.dtd] and
RelaxNG schema [http://www.tei-c.org/Vault/P5/current/xml/tei/schema/relaxng/tei.rng]
are also available. Historical versions are accessible in the Vault
[http://www.tei-c.org/Vault/P5/]."

cheers
stuart

From bansp at o2.pl  Wed May  2 10:04:18 2012
From: bansp at o2.pl (=?UTF-8?B?UGlvdHIgQmHFhHNraQ==?=)
Date: Wed, 02 May 2012 16:04:18 +0200
Subject: [tei-council] DCR alignment inside ODD
In-Reply-To: <BE421D816877B244A7C5D480BA305406EBBF07C648@MAILER.mpi.nl>
References: <4F986124.30406@o2.pl>
	<4F26B857-B17C-4819-A224-2678E5ADD75A@oucs.ox.ac.uk>
	<C9A60E97-2162-495B-A3E6-C0FBAEF00CA4@inria.fr>
	<4F996F1B.9030407@o2.pl>
	<BCDAE098-D838-4CF1-8C34-9CF16ED3B081@inria.fr>
	<BE421D816877B244A7C5D480BA305406EBBF07C648@MAILER.mpi.nl>
Message-ID: <4FA13EE2.3000604@o2.pl>

This is a quick reply to relay Menzo's reply to the Council and to thank
him for it :-)

And let me also add that by sighing over FSD not being quite there I
indeed meant the practical side, i.e. the lack of a way to validate FSRs
against an FSD with a single, publicly available tool.

Possibly this may be another thing for the Council to bear in mind wrt
project packages that might be announced to the community. I also
wonder, on a somewhat related note, if the relatively recent
introduction of the option to use <rng:text/> inside <f> impacts on the
FSD section in any way.

Best,

  Piotr

On 02/05/12 15:11, Menzo Windhouwer wrote:
> Dear all,
> 
> Sorry for my late response, we had some national holidays in the Netherlands so I was a few days off :-)
> 
> Indeed the @dcr:datcat and the ODD <equiv/> can function on different levels, e.g., in ODD one could say what <tei:f/> in a feature structure means, i.e., link to a data category /feature/, while using the @dcr:datcat/@dcr:valueDatcat one could link an specific feature instance to a specific data category, i.e., /partOfSpeech/ and /commonNoun/.
> 
> For the TEI header I've created in the past already a set of scripts to create data categories and link them using <equiv/>. However, this is suboptimal as it would create new data categories for all elements/attributes while ISOcat might already contain useful ones. The results never made it to isocat.org, but it might still be an interesting starting point and I would glady run/update these scripts and show case the result on the ISOcat test server ...
> 
> In a lexicon related project (the RELISH project also presented at the TEI lexicon workshop last year) I'm working on a LMF serialization that allows the use of the TEI feature structures. There I encountered the same problem as you Piotr, i.e., one needs to repeat all @dcr:datcat/dcr:valueDatcat annotation for each instance. I was planning to minimize that burden by allowing annotating a feature structure declaration. So I wonder what you mean by "FSD is not quite there still (sigh)". The XML vocabulary is defined and can be used isn't it? Or do you mean that there is no actual impact, e.g., validation, of the declaration on the instances?
> 
> Best,
> 
> Menzo
> 
> --
> Menzo Windhouwer
> e-mail:Menzo.Windhouwer at mpi.nl
> Max-Planck-Institute for Psycholinguistics
> 
> 
>> -----Original Message-----
>> From: Laurent Romary [mailto:laurent.romary at inria.fr]
>> Sent: Thursday, April 26, 2012 18:01
>> To: Piotr Ba?ski
>> Cc: Sebastian Rahtz; TEI Council; Menzo Windhouwer
>> Subject: Re: [tei-council] DCR alignment inside ODD
>>
>> I answer your two points quickly (baby bottle soon):
>>
>> * I could live with a decision of just making http://www.tei-
>> c.org/release/doc/tei-p5-doc/en/html/ref-model.gramPart.html member of
>> att.datcat and consider step by step the integration of other objects (but
>> maybe metadata elements in the header should be considered quickly). Still,
>> I do see this as a kind of general purpose mechanism at the service of
>> convergence across standardization bodies and as such a stro,ng move to
>> make
>> * the semantic of dcr:datcat is "the element I qualify  corresponds to the
>> concept expressed in my value", and you don't want to express this for
>> <equiv>: there is a level of indirection here, because equiv qualifies the
>> semantic of an element defined by the element spec, the element itself
>> does not contain the attribute. It would thus be conceptually wrong
>> (attribute-abuse,of the worst kind ;-)) to adopt the construct you suggest...
>> :-)
>> Laurent
>>
>> Le 26 avr. 2012 ? 17:51, Piotr Ba?ski a ?crit :
>>
>>> Thank you, Sebastian and Laurent,
>>>
>>> There's several issues here. (I concentrate on Laurent's post and will
>>> reply to Sebastian's separately)
>>>
>>> Firstly, you (Laurent) want the most radical move, i.e., making the
>>> datcat attributes available to *all* elements. Two comments:
>>>
>>> * I had an impression that this was not accepted by the Council, and
>>> that the recommendation was to go from the bottom up, i.e. to select
>>> the items that need the datcat stuff, and possibly increase the scope
>>> as needed. I agree that the radical solution would simplify the issue,
>>> given that ISOcat is able to provide alignment for practically any
>>> kind of data category, not just those purely linguistic. Perhaps we
>>> could reopen the discussion on that, I'd be happy to see att.datcat
>>> where you suggest.
>>>
>>> The title of the ticket is general, but the description may indeed
>>> suggest that this is a proposal restricted to linguistic stuff:
>>>
>>>
>> https://sourceforge.net/tracker/index.php?func=detail&aid=3432520&grou
>>> p_id=106328&atid=644065
>>>
>>>
>>> * if you assume that att.datcat are global, why on earth NOT use them
>>> on <equiv>, where's the consistency? Sure thing, equiv has the @uri
>>> attribute which was, or could be, used for DCR alignment, since there
>>> was no other tool to do it. But if you postulate global datcat
>>> attributes, I see it as inconsistent and counterintuitive to demand
>>> that on <equiv> alone, DCR alignment is to be handled by @uri rather
>>> than the available datcat attributes.
>>>
>>> Secondly, yes, I know the example, it's nice until you imagine lots of
>>> <fs> at the POS layer (take any serious corpus out there), at which
>>> point it stops being nice and becomes seriously overredundant, and
>>> makes you think of shifting the DCR stuff at least to the level of FSD.
>>> Granted, FSD is not quite there still (sigh), so keeping all the stuff
>>> within <f> is an unhappy temporary solution, good for presenting as
>>> one of the examples in the spec, but maybe not necessarily in the
>>> Dictionaries chapter.
>>>
>>> Sure thing, I can do the <equiv>alence for POS in the ODD, and then do:
>>> <pos dcr:valueDatcat="http://www.isocat.org/datcat/DC-1256">CN</pos>
>>> (for "common noun"), except that it's a variant of the problem with
>>> <f>, namely redundancy, very clear in the context of a dictionary. It
>>> is also a problem of a split mechanism (<equiv> for containers vs.
>>> local dcr:valueDatcat for values) instead of a unified mechanism.
>>>
>>> Let me make sure it's clear what I consider redundancy in this very
>>> case: <pos> or @name="part of speech" have to be repeated many times,
>>> that's OK. But if we add the dcr: stuff, then, together with the "local"
>>> identifiers, we repeat the "global" identifiers, in every place
>>> affected, instead of saying once, either in the ODD, schema, or header:
>>> <pos> = "http://www.isocat.org/datcat/DC-1345", and then using <pos>,
>>> with its meaning now clarified.
>>>
>>> Still, I'm grateful for the replies and discussion because it took
>>> away my doubts concerning the here-and-now: it's better to have the
>>> DCR stuff officially in the TEI than create roundabout solutions of
>>> the type I talked about in Zadar and implemented in FreeDict. For the
>>> reasons that I gave above, it feels to me like a half-way solution,
>>> but still, as we all know, it's better to have it than not to have it,
>>> and I will now put some example into the DI chapter (maybe even
>>> without mentioning <equiv> for the time being), and will be happy to
>>> make a step forward. I think I wanted too much too soon (and feared
>>> about how overwhelming it might become, and that it goes beyond just a
>>> brief Council discussion that we've had).
>>>
>>> Best,
>>>
>>>  P.
>>>
>>>
>>> On 26/04/12 09:44, Laurent Romary wrote:
>>>> I guess you are currently working on 3432520
>>>>
>>>> There are two distinct mechanisms here:
>>>> - the normal use of <equiv> within an ODD spec
>>>> - the on-the-fly declaration of equivalence on an element instance
>>>> ("I used <pos> here, meaning exactly the POS in ISOCat") For the
>>>> latter purpose, ISO 12620 introduces two attributes in the dcr:
>>>> namespace, for instance (example provided by Menzo in CC), you can
>>>> decorate an FS as follows <tei:TEI
>>>> xmlns:tei="http://www.tei-c.org/ns/1.0"
>> xmlns:dcr="http://www.isocat.org/ns/dcr">
>>>>    ...
>>>>    <tei:fs>
>>>>        ...
>>>>        <tei:f
>>>>            name="part of speech"
>>>>           dcr:datcat="http://www.isocat.org/datcat/DC-1345"
>>>>            fVal="common noun"
>>>>            dcr:valueDatcat="http://www.isocat.org/datcat/DC-1256"
>>>>        />
>>>>        ...
>>>>    </tei:fs>
>>>>    ...
>>>> </tei:TEI>
>>>>
>>>>
>>>> So, looking again at the ticket the situation is clear, you make
>>>> att.global a member of att.datcat, but make clear in the guidelines
>>>> that this does not replace <equiv>
>>>>
>>>>
>>>> Le 25 avr. 2012 ? 22:59, Sebastian Rahtz a ?crit :
>>>>
>>>>>
>>>>> On 25 Apr 2012, at 21:40, Piotr Ba?ski wrote:
>>>>>
>>>>>> I'm working on the ISO DCR / ISOcat issues.[1] Got stuck at the
>>>>>> point of adding the relevant pieces of text to the Guidelines.
>>>>>>
>>>>>> The enlightened way to align grammatical categories with the values
>>>>>> of the DCR is to put the appropriate references into the ODD, and I
>>>>>> guess <equiv> is the ideal place for that.
>>>>>>
>>>>>> I imagine, and please correct me if I am wrong, that for elements
>>>>>> such as <pos>, this action may be trivial:
>>>>>>
>>>>>> <elementSpec ident="pos" mode="change"> <equiv
>>>>>> dcr:datcat="http://www.isocat.org/datcat/DC-1345"/>
>>>>>> </elementSpec>
>>>>>
>>>>> <equiv url="http://www.isocat.org/datcat/DC-1345"/> is the syntax, I
>>>>> think.
>>>>>
>>>>>> The above makes it possible for us to happily realize that whenever
>>>>>> we do e.g.
>>>>>>
>>>>>> <gramGrp><pos>...</pos></gramGrp>
>>>>>>
>>>>>> all the machines in the world may know that by <pos>, we mean
>>>>>> http://www.isocat.org/datcat/DC-1345 .
>>>>> well, if they read the ODD yes. I think there is a certain amount of
>>>>> "simple matter of programming" involved here.
>>>>>
>>>>>>
>>>>>> However, there is also the content of <pos> to be handled, and it
>>>>>> is not so obvious to me how to represent this in the ODD.
>>>>>> Intuitively, I'm thinking of
>>>>>>
>>>>>> <elementSpec>
>>>>>> ...
>>>>>> <content>
>>>>>> {list of values with their DCR references} </content>
>>>>>
>>>>> a <elementSpec> can contain a <valList>, whose <valItem> children
>>>>> can have <equiv> children
>>>>>
>>>>> Does that help?
>>>>>
>>>>> I suspect what you'd really like is to use a DTD which supplied
>>>>> default dcr:cat attributes to instances of <pos>.
>>>>>
>>>>> Sebastian
>>>>>

From James.Cummings at oucs.ox.ac.uk  Wed May  2 12:35:11 2012
From: James.Cummings at oucs.ox.ac.uk (James Cummings)
Date: Wed, 02 May 2012 17:35:11 +0100
Subject: [tei-council] Usefulness of http://www.tei-c.org/ns/1.0/
In-Reply-To: <CAC_Lu0YBE-JRW7XsZvFdx03ZYa9tuM1rCBbjtP2EO3W=GFLg_Q@mail.gmail.com>
References: <CAC_Lu0YBE-JRW7XsZvFdx03ZYa9tuM1rCBbjtP2EO3W=GFLg_Q@mail.gmail.com>
Message-ID: <4FA1623F.3090606@oucs.ox.ac.uk>

Hiya,

I'd agree with Stuart's suggestion but personally would not 
mention DTDs at all.

Also I'd point to http://www.tei-c.org/Guidelines/P5/ as where 
the P5 Guidelines are (rather than assume they want the English 
version).

So I might suggest the following modification:

"The full text of the current TEI P5 Guidelines is freely 
available online at:
[http://www.tei-c.org/Guidelines/P5/].
and a full RelaxNG schema for the TEI is available at:
[http://www.tei-c.org/release/xml/tei/custom/schema/relaxng/tei_all.rng].
Historical versions of the TEI's recommendations and other 
materials are accessible in the Vault at:
[http://www.tei-c.org/Vault/P5/]"

Does that sound better?  Of course there is no requirement for 
anything dereferenceable to be at that URL because namespaces are 
not URIs, just take the form of them... but that pendantry aside 
since we *do* have a page there making a change like this seems 
reasonable to me.

-James


On 02/05/12 00:24, Stuart A. Yeates wrote:
> It has been pointed out to me (on IRC) that the HTML served up for
> http://www.tei-c.org/ns/1.0/ may not be ideal. I would like to propose
> an additional paragraph of content specifically to assist XML-using
> but TEI-unaware users who are likely to have arrived at the page
> having found the URL in some random TEI:
>
> "The full text of the current TEI standard is online
> [http://www.tei-c.org/release/doc/tei-p5-doc/en/html/index-toc.html],
> the current DTD
> [http://www.tei-c.org/Vault/P5/current/xml/tei/schema/dtd/tei.dtd] and
> RelaxNG schema [http://www.tei-c.org/Vault/P5/current/xml/tei/schema/relaxng/tei.rng]
> are also available. Historical versions are accessible in the Vault
> [http://www.tei-c.org/Vault/P5/]."
>
> cheers
> stuart


-- 
Dr James Cummings, InfoDev,
Computing Services, University of Oxford

From lou.burnard at retired.ox.ac.uk  Wed May  2 13:06:25 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Wed, 02 May 2012 18:06:25 +0100
Subject: [tei-council] Usefulness of http://www.tei-c.org/ns/1.0/
In-Reply-To: <4FA1623F.3090606@oucs.ox.ac.uk>
References: <CAC_Lu0YBE-JRW7XsZvFdx03ZYa9tuM1rCBbjtP2EO3W=GFLg_Q@mail.gmail.com>
	<4FA1623F.3090606@oucs.ox.ac.uk>
Message-ID: <4FA16991.4030402@retired.ox.ac.uk>

Would it be "pendantic" to point out that DTD and XSD versions of the 
schema are also available?


On 02/05/12 17:35, James Cummings wrote:
> Hiya,
>
> I'd agree with Stuart's suggestion but personally would not
> mention DTDs at all.
>
> Also I'd point to http://www.tei-c.org/Guidelines/P5/ as where
> the P5 Guidelines are (rather than assume they want the English
> version).
>
> So I might suggest the following modification:
>
> "The full text of the current TEI P5 Guidelines is freely
> available online at:
> [http://www.tei-c.org/Guidelines/P5/].
> and a full RelaxNG schema for the TEI is available at:
> [http://www.tei-c.org/release/xml/tei/custom/schema/relaxng/tei_all.rng].
> Historical versions of the TEI's recommendations and other
> materials are accessible in the Vault at:
> [http://www.tei-c.org/Vault/P5/]"
>
> Does that sound better?  Of course there is no requirement for
> anything dereferenceable to be at that URL because namespaces are
> not URIs, just take the form of them... but that pendantry aside
> since we *do* have a page there making a change like this seems
> reasonable to me.
>
> -James
>
>
> On 02/05/12 00:24, Stuart A. Yeates wrote:
>> It has been pointed out to me (on IRC) that the HTML served up for
>> http://www.tei-c.org/ns/1.0/ may not be ideal. I would like to propose
>> an additional paragraph of content specifically to assist XML-using
>> but TEI-unaware users who are likely to have arrived at the page
>> having found the URL in some random TEI:
>>
>> "The full text of the current TEI standard is online
>> [http://www.tei-c.org/release/doc/tei-p5-doc/en/html/index-toc.html],
>> the current DTD
>> [http://www.tei-c.org/Vault/P5/current/xml/tei/schema/dtd/tei.dtd] and
>> RelaxNG schema [http://www.tei-c.org/Vault/P5/current/xml/tei/schema/relaxng/tei.rng]
>> are also available. Historical versions are accessible in the Vault
>> [http://www.tei-c.org/Vault/P5/]."
>>
>> cheers
>> stuart
>
>


From kevin.s.hawkins at ultraslavonic.info  Wed May  2 13:10:04 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Wed, 02 May 2012 13:10:04 -0400
Subject: [tei-council] Usefulness of http://www.tei-c.org/ns/1.0/
In-Reply-To: <4FA1623F.3090606@oucs.ox.ac.uk>
References: <CAC_Lu0YBE-JRW7XsZvFdx03ZYa9tuM1rCBbjtP2EO3W=GFLg_Q@mail.gmail.com>
	<4FA1623F.3090606@oucs.ox.ac.uk>
Message-ID: <4FA16A6C.4050201@ultraslavonic.info>

Will the namespace URL change in P6?  If not, I suggest linking to 
http://www.tei-c.org/Guidelines/ instead of 
http://www.tei-c.org/Guidelines/P5/ .

On 5/2/2012 12:35 PM, James Cummings wrote:
> Hiya,
>
> I'd agree with Stuart's suggestion but personally would not
> mention DTDs at all.
>
> Also I'd point to http://www.tei-c.org/Guidelines/P5/ as where
> the P5 Guidelines are (rather than assume they want the English
> version).
>
> So I might suggest the following modification:
>
> "The full text of the current TEI P5 Guidelines is freely
> available online at:
> [http://www.tei-c.org/Guidelines/P5/].
> and a full RelaxNG schema for the TEI is available at:
> [http://www.tei-c.org/release/xml/tei/custom/schema/relaxng/tei_all.rng].
> Historical versions of the TEI's recommendations and other
> materials are accessible in the Vault at:
> [http://www.tei-c.org/Vault/P5/]"
>
> Does that sound better?  Of course there is no requirement for
> anything dereferenceable to be at that URL because namespaces are
> not URIs, just take the form of them... but that pendantry aside
> since we *do* have a page there making a change like this seems
> reasonable to me.
>
> -James
>
>
> On 02/05/12 00:24, Stuart A. Yeates wrote:
>> It has been pointed out to me (on IRC) that the HTML served up for
>> http://www.tei-c.org/ns/1.0/ may not be ideal. I would like to propose
>> an additional paragraph of content specifically to assist XML-using
>> but TEI-unaware users who are likely to have arrived at the page
>> having found the URL in some random TEI:
>>
>> "The full text of the current TEI standard is online
>> [http://www.tei-c.org/release/doc/tei-p5-doc/en/html/index-toc.html],
>> the current DTD
>> [http://www.tei-c.org/Vault/P5/current/xml/tei/schema/dtd/tei.dtd] and
>> RelaxNG schema [http://www.tei-c.org/Vault/P5/current/xml/tei/schema/relaxng/tei.rng]
>> are also available. Historical versions are accessible in the Vault
>> [http://www.tei-c.org/Vault/P5/]."
>>
>> cheers
>> stuart
>
>

From sebastian.rahtz at oucs.ox.ac.uk  Wed May  2 13:30:35 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Wed, 2 May 2012 17:30:35 +0000
Subject: [tei-council] Usefulness of http://www.tei-c.org/ns/1.0/
In-Reply-To: <4FA1623F.3090606@oucs.ox.ac.uk>
References: <CAC_Lu0YBE-JRW7XsZvFdx03ZYa9tuM1rCBbjtP2EO3W=GFLg_Q@mail.gmail.com>
	<4FA1623F.3090606@oucs.ox.ac.uk>
Message-ID: <a25337bf-d858-45b9-a6b1-a4e77966f31f@HUB03.ad.oak.ox.ac.uk>

+1 from me to James' version, and I agree with Stuart about the principle

sebastian

From sebastian.rahtz at oucs.ox.ac.uk  Wed May  2 13:40:41 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Wed, 2 May 2012 17:40:41 +0000
Subject: [tei-council] Usefulness of http://www.tei-c.org/ns/1.0/
In-Reply-To: <4FA16991.4030402@retired.ox.ac.uk>
References: <CAC_Lu0YBE-JRW7XsZvFdx03ZYa9tuM1rCBbjtP2EO3W=GFLg_Q@mail.gmail.com>
	<4FA1623F.3090606@oucs.ox.ac.uk> <4FA16991.4030402@retired.ox.ac.uk>
Message-ID: <c696d2c6-13da-4716-8aa4-887f5b61cfe2@HUB06.ad.oak.ox.ac.uk>


On 2 May 2012, at 18:06, Lou Burnard wrote:

Would it be "pendantic" to point out that DTD and XSD versions of the
schema are also available?

well, that depends. Stuart pointed at http://www.tei-c.org/release/xml/tei/schema/relaxng/tei.rng
whereas James pointed at http://www.tei-c.org/release/xml/tei/custom/schema/relaxng/tei_all.rng
which are not at all the same thing, oh no. One has an XSD equiv, the other doesn't.

enquiring minds will investigate http://www.tei-c.org/release/xml/tei/schema/relaxng/tei.rng
and work out what it is (clue: its not what you think)

Sebastian

From James.Cummings at oucs.ox.ac.uk  Wed May  2 13:59:06 2012
From: James.Cummings at oucs.ox.ac.uk (James Cummings)
Date: Wed, 02 May 2012 18:59:06 +0100
Subject: [tei-council] Usefulness of http://www.tei-c.org/ns/1.0/
In-Reply-To: <c696d2c6-13da-4716-8aa4-887f5b61cfe2@HUB06.ad.oak.ox.ac.uk>
References: <CAC_Lu0YBE-JRW7XsZvFdx03ZYa9tuM1rCBbjtP2EO3W=GFLg_Q@mail.gmail.com>	<4FA1623F.3090606@oucs.ox.ac.uk>
	<4FA16991.4030402@retired.ox.ac.uk>
	<c696d2c6-13da-4716-8aa4-887f5b61cfe2@HUB06.ad.oak.ox.ac.uk>
Message-ID: <4FA175EA.6030804@oucs.ox.ac.uk>

On 02/05/12 18:40, Sebastian Rahtz wrote:
>
> On 2 May 2012, at 18:06, Lou Burnard wrote:
>
> Would it be "pendantic" to point out that DTD and XSD versions of the
> schema are also available?

Darn silly typooohs.

> well, that depends. Stuart pointed at http://www.tei-c.org/release/xml/tei/schema/relaxng/tei.rng
> whereas James pointed at http://www.tei-c.org/release/xml/tei/custom/schema/relaxng/tei_all.rng
> which are not at all the same thing, oh no. One has an XSD equiv, the other doesn't.

Yes, that is a change that I glossed over.  I think pointing to 
tei_all.rng is more useful for Stuart's proposed use case of 
someone finding a TEI document in the wild and following the 
xmlns to find a schema for it.

> enquiring minds will investigate http://www.tei-c.org/release/xml/tei/schema/relaxng/tei.rng
> and work out what it is (clue: its not what you think)


-James
-- 
Dr James Cummings, InfoDev,
Computing Services, University of Oxford

From dsewell at virginia.edu  Fri May  4 11:50:13 2012
From: dsewell at virginia.edu (David Sewell)
Date: Fri, 4 May 2012 11:50:13 -0400 (EDT)
Subject: [tei-council] Usefulness of http://www.tei-c.org/ns/1.0/
In-Reply-To: <4FA175EA.6030804@oucs.ox.ac.uk>
References: <CAC_Lu0YBE-JRW7XsZvFdx03ZYa9tuM1rCBbjtP2EO3W=GFLg_Q@mail.gmail.com>
	<4FA1623F.3090606@oucs.ox.ac.uk>
	<4FA16991.4030402@retired.ox.ac.uk>
	<c696d2c6-13da-4716-8aa4-887f5b61cfe2@HUB06.ad.oak.ox.ac.uk>
	<4FA175EA.6030804@oucs.ox.ac.uk>
Message-ID: <alpine.OSX.2.00.1205041149250.1352@lister.ei.virginia.edu>

If someone wants to formulate the agreed-upon modifications, I'll make the 
change (or any other OpenCMS-literate Council member is welcome to).

On Wed, 2 May 2012, James Cummings wrote:

> On 02/05/12 18:40, Sebastian Rahtz wrote:
>>
>> On 2 May 2012, at 18:06, Lou Burnard wrote:
>>
>> Would it be "pendantic" to point out that DTD and XSD versions of the
>> schema are also available?
>
> Darn silly typooohs.
>
>> well, that depends. Stuart pointed at http://www.tei-c.org/release/xml/tei/schema/relaxng/tei.rng
>> whereas James pointed at http://www.tei-c.org/release/xml/tei/custom/schema/relaxng/tei_all.rng
>> which are not at all the same thing, oh no. One has an XSD equiv, the other doesn't.
>
> Yes, that is a change that I glossed over.  I think pointing to
> tei_all.rng is more useful for Stuart's proposed use case of
> someone finding a TEI document in the wild and following the
> xmlns to find a schema for it.
>
>> enquiring minds will investigate http://www.tei-c.org/release/xml/tei/schema/relaxng/tei.rng
>> and work out what it is (clue: its not what you think)
>
>
> -James
>

-- 
David Sewell, Editorial and Technical Manager
ROTUNDA, The University of Virginia Press
PO Box 400314, Charlottesville, VA 22904-4314 USA
Email: dsewell at virginia.edu   Tel: +1 434 924 9973
Web: http://rotunda.upress.virginia.edu/

From James.Cummings at oucs.ox.ac.uk  Sun May  6 07:29:50 2012
From: James.Cummings at oucs.ox.ac.uk (James Cummings)
Date: Sun, 06 May 2012 12:29:50 +0100
Subject: [tei-council] Fwd: TEI TITE question
Message-ID: <4FA660AE.3080907@oucs.ox.ac.uk>

Hi MartinM,

I'm forwarding this to the council list for open discussion since 
that is publicly archived (and so you'll be able to follow the 
discussion in the archive).

I'd argue that lb/pb/cb are somehow of a higher structural 
category in the effect they have on teh text and our 
interpretation of it. Whereas sup/sub/bold/i are merely 
phrase-level highlighting.  My worry, I guess, is that if people 
have <i>text</i> they are less likely to encode the reason for 
the italics and concentrate more on presentational aspects of the 
source text rather than their intellectual interpretation. 
(Though inside sourceDoc, of course, this admittedly rather 
flimsy argument falls down entirely.)  My unexamined reservation, 
I suppose, is probably based on the idiom that it is much better 
to say what things are than what they look like, and these 
convenience syntactic sugar encodings are more about what stuff 
looks like than what function they are playing. As I said, a 
flimsy argument, but just my initial gut feeling.

What do others think?

-James


-------- Original Message --------
Subject: 	TEI TITE question
Date: 	Sat, 5 May 2012 23:16:00 +0000
From: 	Martin Mueller <martinmueller at northwestern.edu>
To: 	James Cummings <James.Cummings at OUCS.OX.AC.UK>



James,

has there ever been a discussion about the convenience features
of TITE (sup, sub, bold, i) becoming parts of the main TEI set,
along the lines of lb or pb being shortcuts for <milestone
unit="line"/>. I can see quite a few arguments in favour of this,
and not really many against it. It might encourage people to be
sloppy in some ways. But M<sup>rs</sup> has something going for
it over M<hi rend="sup">rs</hi>. And there are a lot of those.

MM

From sebastian.rahtz at oucs.ox.ac.uk  Sun May  6 08:22:42 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Sun, 6 May 2012 12:22:42 +0000
Subject: [tei-council] Fwd: TEI TITE question
In-Reply-To: <4FA660AE.3080907@oucs.ox.ac.uk>
References: <4FA660AE.3080907@oucs.ox.ac.uk>
Message-ID: <012a76a2-c45a-4a92-8207-89917aa95067@HUB02.ad.oak.ox.ac.uk>

This has been raised, but drifted off the agenda in the past.  I am in favour, particularly for sup and sub, because @rend is so hard to use meaningfully, and sup/sub are so seldom semantic. I and b are a bit harder, but dramatically I would vote for them. We could put them in a module call sugar, and add olist and ulist at the same time.

.sebastian

Sent from my HTC

----- Reply message -----
From: "James Cummings" <James.Cummings at oucs.ox.ac.uk>
Date: Sun, May 6, 2012 12:29
Subject: [tei-council] Fwd: TEI TITE question
To: "TEI Council" <tei-council at lists.village.virginia.edu>
Cc: "Martin Mueller" <martinmueller at NORTHWESTERN.EDU>

Hi MartinM,

I'm forwarding this to the council list for open discussion since
that is publicly archived (and so you'll be able to follow the
discussion in the archive).

I'd argue that lb/pb/cb are somehow of a higher structural
category in the effect they have on teh text and our
interpretation of it. Whereas sup/sub/bold/i are merely
phrase-level highlighting.  My worry, I guess, is that if people
have <i>text</i> they are less likely to encode the reason for
the italics and concentrate more on presentational aspects of the
source text rather than their intellectual interpretation.
(Though inside sourceDoc, of course, this admittedly rather
flimsy argument falls down entirely.)  My unexamined reservation,
I suppose, is probably based on the idiom that it is much better
to say what things are than what they look like, and these
convenience syntactic sugar encodings are more about what stuff
looks like than what function they are playing. As I said, a
flimsy argument, but just my initial gut feeling.

What do others think?

-James


-------- Original Message --------
Subject:         TEI TITE question
Date:    Sat, 5 May 2012 23:16:00 +0000
From:    Martin Mueller <martinmueller at northwestern.edu>
To:      James Cummings <James.Cummings at OUCS.OX.AC.UK>



James,

has there ever been a discussion about the convenience features
of TITE (sup, sub, bold, i) becoming parts of the main TEI set,
along the lines of lb or pb being shortcuts for <milestone
unit="line"/>. I can see quite a few arguments in favour of this,
and not really many against it. It might encourage people to be
sloppy in some ways. But M<sup>rs</sup> has something going for
it over M<hi rend="sup">rs</hi>. And there are a lot of those.

MM
--
tei-council mailing list
tei-council at lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

PLEASE NOTE: postings to this list are publicly archived

From lou.burnard at retired.ox.ac.uk  Sun May  6 08:24:25 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Sun, 06 May 2012 13:24:25 +0100
Subject: [tei-council] Fwd: TEI TITE question
In-Reply-To: <4FA660AE.3080907@oucs.ox.ac.uk>
References: <4FA660AE.3080907@oucs.ox.ac.uk>
Message-ID: <4FA66D79.9020205@retired.ox.ac.uk>

Certainly no good reason to stop people defining convenience tags like 
<it> <bo> <sup> etc and we could even add a section in the place where 
<hi> is defined to explain how, if there isn't one already. We *could* 
also add them as first class TEI elements, perhaps in the transcr module 
rather than the core though.  But why do we choose these rather minimal 
indications of rendering? Shouldn't there be some tags for other kinds 
of visual salience, notably for size of letters, letter spacing etc. ? 
Oh wait, isn't that what <rendition> is for?

I also worry about the way that visual salience is not a simple matter. 
If you mark up font change alone you will often completely miss the 
point -- for example, the word/s in Roman within a paragraph in italic 
are the ones that should be tagged, not the words around them which 
happen to be in italic.



   On 06/05/12 12:29, James Cummings wrote:
> Hi MartinM,
>
> I'm forwarding this to the council list for open discussion since
> that is publicly archived (and so you'll be able to follow the
> discussion in the archive).
>
> I'd argue that lb/pb/cb are somehow of a higher structural
> category in the effect they have on teh text and our
> interpretation of it. Whereas sup/sub/bold/i are merely
> phrase-level highlighting.  My worry, I guess, is that if people
> have<i>text</i>  they are less likely to encode the reason for
> the italics and concentrate more on presentational aspects of the
> source text rather than their intellectual interpretation.
> (Though inside sourceDoc, of course, this admittedly rather
> flimsy argument falls down entirely.)  My unexamined reservation,
> I suppose, is probably based on the idiom that it is much better
> to say what things are than what they look like, and these
> convenience syntactic sugar encodings are more about what stuff
> looks like than what function they are playing. As I said, a
> flimsy argument, but just my initial gut feeling.
>
> What do others think?
>
> -James
>
>
> -------- Original Message --------
> Subject: 	TEI TITE question
> Date: 	Sat, 5 May 2012 23:16:00 +0000
> From: 	Martin Mueller<martinmueller at northwestern.edu>
> To: 	James Cummings<James.Cummings at OUCS.OX.AC.UK>
>
>
>
> James,
>
> has there ever been a discussion about the convenience features
> of TITE (sup, sub, bold, i) becoming parts of the main TEI set,
> along the lines of lb or pb being shortcuts for<milestone
> unit="line"/>. I can see quite a few arguments in favour of this,
> and not really many against it. It might encourage people to be
> sloppy in some ways. But M<sup>rs</sup>  has something going for
> it over M<hi rend="sup">rs</hi>. And there are a lot of those.
>
> MM


From lou.burnard at retired.ox.ac.uk  Sun May  6 09:06:58 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Sun, 06 May 2012 14:06:58 +0100
Subject: [tei-council] Fwd: TEI TITE question
In-Reply-To: <012a76a2-c45a-4a92-8207-89917aa95067@HUB02.ad.oak.ox.ac.uk>
References: <4FA660AE.3080907@oucs.ox.ac.uk>
	<012a76a2-c45a-4a92-8207-89917aa95067@HUB02.ad.oak.ox.ac.uk>
Message-ID: <4FA67772.8010104@retired.ox.ac.uk>

If @rend is hard to use "meaningfully" surely it's the right choice for 
sub/sup which are "seldom semantic".

I can't understand why people think sup and sub matter in things like 
page signatures or ordinal numbers. I can see why they matter in 
mathematical expressions, but there's other ways of doing that and there 
they have clear semantics. Whether we spell "first" 1<sup>st</sup> or 
1st really doesn't seem to matter a great deal, and if it does, I'd 
rather use the Unicode glyph variant anyway (I know I know, there are 
some missing)(

But I suppose a module called sugar is the way to go. Needs a more 
sensible name though.


On 06/05/12 13:22, Sebastian Rahtz wrote:
> This has been raised, but drifted off the agenda in the past.  I am
> in favour, particularly for sup and sub, because @rend is so hard to
> use meaningfully, and sup/sub are so seldom semantic. I and b are a
> bit harder, but dramatically I would vote for them. We could put them
> in a module call sugar, and add olist and ulist at the same time.
>
> .sebastian
>
> Sent from my HTC
>
> ----- Reply message ----- From: "James
> Cummings"<James.Cummings at oucs.ox.ac.uk> Date: Sun, May 6, 2012 12:29
> Subject: [tei-council] Fwd: TEI TITE question To: "TEI
> Council"<tei-council at lists.village.virginia.edu> Cc: "Martin
> Mueller"<martinmueller at NORTHWESTERN.EDU>
>
> Hi MartinM,
>
> I'm forwarding this to the council list for open discussion since
> that is publicly archived (and so you'll be able to follow the
> discussion in the archive).
>
> I'd argue that lb/pb/cb are somehow of a higher structural category
> in the effect they have on teh text and our interpretation of it.
> Whereas sup/sub/bold/i are merely phrase-level highlighting.  My
> worry, I guess, is that if people have<i>text</i>  they are less
> likely to encode the reason for the italics and concentrate more on
> presentational aspects of the source text rather than their
> intellectual interpretation. (Though inside sourceDoc, of course,
> this admittedly rather flimsy argument falls down entirely.)  My
> unexamined reservation, I suppose, is probably based on the idiom
> that it is much better to say what things are than what they look
> like, and these convenience syntactic sugar encodings are more about
> what stuff looks like than what function they are playing. As I said,
> a flimsy argument, but just my initial gut feeling.
>
> What do others think?
>
> -James
>
>
> -------- Original Message -------- Subject:         TEI TITE
> question Date:    Sat, 5 May 2012 23:16:00 +0000 From:    Martin
> Mueller<martinmueller at northwestern.edu> To:      James
> Cummings<James.Cummings at OUCS.OX.AC.UK>
>
>
>
> James,
>
> has there ever been a discussion about the convenience features of
> TITE (sup, sub, bold, i) becoming parts of the main TEI set, along
> the lines of lb or pb being shortcuts for<milestone unit="line"/>. I
> can see quite a few arguments in favour of this, and not really many
> against it. It might encourage people to be sloppy in some ways. But
> M<sup>rs</sup>  has something going for it over M<hi
> rend="sup">rs</hi>. And there are a lot of those.
>
> MM -- tei-council mailing list
> tei-council at lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>
> PLEASE NOTE: postings to this list are publicly archived


From kevin.s.hawkins at ultraslavonic.info  Sun May  6 09:35:37 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Sun, 06 May 2012 09:35:37 -0400
Subject: [tei-council] Fwd: TEI TITE question
In-Reply-To: <4FA67772.8010104@retired.ox.ac.uk>
References: <4FA660AE.3080907@oucs.ox.ac.uk>
	<012a76a2-c45a-4a92-8207-89917aa95067@HUB02.ad.oak.ox.ac.uk>
	<4FA67772.8010104@retired.ox.ac.uk>
Message-ID: <4FA67E29.60604@ultraslavonic.info>

Note that at http://purl.org/TEI/fr/3075996 , in which we discuss 
incorporating parts of Tite into P5, we've considering having a fixed 
list of values for @rend in Tite.  This solution could potentially be 
used in P5 as well.

On 5/6/12 9:06 AM, Lou Burnard wrote:
> If @rend is hard to use "meaningfully" surely it's the right choice for
> sub/sup which are "seldom semantic".
>
> I can't understand why people think sup and sub matter in things like
> page signatures or ordinal numbers. I can see why they matter in
> mathematical expressions, but there's other ways of doing that and there
> they have clear semantics. Whether we spell "first" 1<sup>st</sup>  or
> 1st really doesn't seem to matter a great deal, and if it does, I'd
> rather use the Unicode glyph variant anyway (I know I know, there are
> some missing)(
>
> But I suppose a module called sugar is the way to go. Needs a more
> sensible name though.
>
>
> On 06/05/12 13:22, Sebastian Rahtz wrote:
>> This has been raised, but drifted off the agenda in the past.  I am
>> in favour, particularly for sup and sub, because @rend is so hard to
>> use meaningfully, and sup/sub are so seldom semantic. I and b are a
>> bit harder, but dramatically I would vote for them. We could put them
>> in a module call sugar, and add olist and ulist at the same time.
>>
>> .sebastian
>>
>> Sent from my HTC
>>
>> ----- Reply message ----- From: "James
>> Cummings"<James.Cummings at oucs.ox.ac.uk>  Date: Sun, May 6, 2012 12:29
>> Subject: [tei-council] Fwd: TEI TITE question To: "TEI
>> Council"<tei-council at lists.village.virginia.edu>  Cc: "Martin
>> Mueller"<martinmueller at NORTHWESTERN.EDU>
>>
>> Hi MartinM,
>>
>> I'm forwarding this to the council list for open discussion since
>> that is publicly archived (and so you'll be able to follow the
>> discussion in the archive).
>>
>> I'd argue that lb/pb/cb are somehow of a higher structural category
>> in the effect they have on teh text and our interpretation of it.
>> Whereas sup/sub/bold/i are merely phrase-level highlighting.  My
>> worry, I guess, is that if people have<i>text</i>   they are less
>> likely to encode the reason for the italics and concentrate more on
>> presentational aspects of the source text rather than their
>> intellectual interpretation. (Though inside sourceDoc, of course,
>> this admittedly rather flimsy argument falls down entirely.)  My
>> unexamined reservation, I suppose, is probably based on the idiom
>> that it is much better to say what things are than what they look
>> like, and these convenience syntactic sugar encodings are more about
>> what stuff looks like than what function they are playing. As I said,
>> a flimsy argument, but just my initial gut feeling.
>>
>> What do others think?
>>
>> -James
>>
>>
>> -------- Original Message -------- Subject:         TEI TITE
>> question Date:    Sat, 5 May 2012 23:16:00 +0000 From:    Martin
>> Mueller<martinmueller at northwestern.edu>  To:      James
>> Cummings<James.Cummings at OUCS.OX.AC.UK>
>>
>>
>>
>> James,
>>
>> has there ever been a discussion about the convenience features of
>> TITE (sup, sub, bold, i) becoming parts of the main TEI set, along
>> the lines of lb or pb being shortcuts for<milestone unit="line"/>. I
>> can see quite a few arguments in favour of this, and not really many
>> against it. It might encourage people to be sloppy in some ways. But
>> M<sup>rs</sup>   has something going for it over M<hi
>> rend="sup">rs</hi>. And there are a lot of those.
>>
>> MM -- tei-council mailing list
>> tei-council at lists.village.Virginia.EDU
>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>>
>> PLEASE NOTE: postings to this list are publicly archived
>

From bansp at o2.pl  Sun May  6 09:55:49 2012
From: bansp at o2.pl (=?ISO-8859-2?Q?Piotr_Ba=F1ski?=)
Date: Sun, 06 May 2012 15:55:49 +0200
Subject: [tei-council] Fwd: TEI TITE question
In-Reply-To: <4FA67772.8010104@retired.ox.ac.uk>
References: <4FA660AE.3080907@oucs.ox.ac.uk>
	<012a76a2-c45a-4a92-8207-89917aa95067@HUB02.ad.oak.ox.ac.uk>
	<4FA67772.8010104@retired.ox.ac.uk>
Message-ID: <4FA682E5.6050201@o2.pl>

If they sit in a separate module... maybe the module (call it...
"TEI-HTML 3.2"?) could serve as illustration of how to create
customisations. OTOH, being a module of the TEI, it won't be a
customisation any longer, and we may then want to rewrite some of the
justification for the TEI's existence.

I guess I'm being somewhat bipolar about it, the poles being "roughly
neutral" and "strongly against". I mean, when does <hi rend="sup"> hurt,
other than when you're actually keying stuff in, in an editor without
markup/content completion?

I would agree with James that <lb>, <cb>, and <pb> (I feel some strong
affinity with that one, somehow) feel different than <sup> and, well,
"<scaps>" for that matter, possibly because they have the double role of
indicating, usually, some structural-physical necessities and possibly,
in rarer cases, the author's intentions, whereas I can't see any
structural necessity in <i>.

I'm just afraid that the "sugar" module would soon become one of the
most important modules of the Guidelines, with lots of feature requests,
for completely no good reason that I can see. (From Martin M.'s,
Sebastian's and Lou's messages, I infer that I might be short-sighted in
this respect, and I'm ready to be enlightened, but, going by my gut,
this sounds a bit like "let's go back to HTML 3.2, and is <marquee>
inline or block-level?")

Best,

  P.

On 06/05/12 15:06, Lou Burnard wrote:
> If @rend is hard to use "meaningfully" surely it's the right choice for 
> sub/sup which are "seldom semantic".
> 
> I can't understand why people think sup and sub matter in things like 
> page signatures or ordinal numbers. I can see why they matter in 
> mathematical expressions, but there's other ways of doing that and there 
> they have clear semantics. Whether we spell "first" 1<sup>st</sup> or 
> 1st really doesn't seem to matter a great deal, and if it does, I'd 
> rather use the Unicode glyph variant anyway (I know I know, there are 
> some missing)(
> 
> But I suppose a module called sugar is the way to go. Needs a more 
> sensible name though.
> 
> 
> On 06/05/12 13:22, Sebastian Rahtz wrote:
>> This has been raised, but drifted off the agenda in the past.  I am
>> in favour, particularly for sup and sub, because @rend is so hard to
>> use meaningfully, and sup/sub are so seldom semantic. I and b are a
>> bit harder, but dramatically I would vote for them. We could put them
>> in a module call sugar, and add olist and ulist at the same time.
>>
>> .sebastian
>>
>> Sent from my HTC
>>
>> ----- Reply message ----- From: "James
>> Cummings"<James.Cummings at oucs.ox.ac.uk> Date: Sun, May 6, 2012 12:29
>> Subject: [tei-council] Fwd: TEI TITE question To: "TEI
>> Council"<tei-council at lists.village.virginia.edu> Cc: "Martin
>> Mueller"<martinmueller at NORTHWESTERN.EDU>
>>
>> Hi MartinM,
>>
>> I'm forwarding this to the council list for open discussion since
>> that is publicly archived (and so you'll be able to follow the
>> discussion in the archive).
>>
>> I'd argue that lb/pb/cb are somehow of a higher structural category
>> in the effect they have on teh text and our interpretation of it.
>> Whereas sup/sub/bold/i are merely phrase-level highlighting.  My
>> worry, I guess, is that if people have<i>text</i>  they are less
>> likely to encode the reason for the italics and concentrate more on
>> presentational aspects of the source text rather than their
>> intellectual interpretation. (Though inside sourceDoc, of course,
>> this admittedly rather flimsy argument falls down entirely.)  My
>> unexamined reservation, I suppose, is probably based on the idiom
>> that it is much better to say what things are than what they look
>> like, and these convenience syntactic sugar encodings are more about
>> what stuff looks like than what function they are playing. As I said,
>> a flimsy argument, but just my initial gut feeling.
>>
>> What do others think?
>>
>> -James
>>
>>
>> -------- Original Message -------- Subject:         TEI TITE
>> question Date:    Sat, 5 May 2012 23:16:00 +0000 From:    Martin
>> Mueller<martinmueller at northwestern.edu> To:      James
>> Cummings<James.Cummings at OUCS.OX.AC.UK>
>>
>>
>>
>> James,
>>
>> has there ever been a discussion about the convenience features of
>> TITE (sup, sub, bold, i) becoming parts of the main TEI set, along
>> the lines of lb or pb being shortcuts for<milestone unit="line"/>. I
>> can see quite a few arguments in favour of this, and not really many
>> against it. It might encourage people to be sloppy in some ways. But
>> M<sup>rs</sup>  has something going for it over M<hi
>> rend="sup">rs</hi>. And there are a lot of those.
>>
>> MM -- tei-council mailing list
>> tei-council at lists.village.Virginia.EDU
>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>>
>> PLEASE NOTE: postings to this list are publicly archived
> 


From sebastian.rahtz at oucs.ox.ac.uk  Sun May  6 11:49:36 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Sun, 6 May 2012 15:49:36 +0000
Subject: [tei-council] Fwd: TEI TITE question
In-Reply-To: <4FA66D79.9020205@retired.ox.ac.uk>
References: <4FA660AE.3080907@oucs.ox.ac.uk>
	<4FA66D79.9020205@retired.ox.ac.uk>
Message-ID: <ec9f2524-db7f-4fee-b5ea-bcbb9d18a01b@HUB05.ad.oak.ox.ac.uk>


On 6 May 2012, at 13:24, Lou Burnard wrote:

> rather than the core though.  But why do we choose these rather minimal 
> indications of rendering? Shouldn't there be some tags for other kinds 
> of visual salience, notably for size of letters, letter spacing etc. ? 

some answers to this come from analysis of large amounts
of texts, surely. ie if there are 999 examples of people doing
<hi rend="bold"> and only 1 of <hi rend="doubleunderline">,
then it suggest we need <b> but not <dub>. 

letterspacing and size are tricky, as they more commonly involve
measurement of the amount of the effect (ok, so bold has the same
problem, but much less so).  But one could certainly _consider_
<larger>, <smaller> and <letterspaced> I suppose. and
<underline>.

> 
> I also worry about the way that visual salience is not a simple matter. 
> If you mark up font change alone you will often completely miss the 
> point -- for example, the word/s in Roman within a paragraph in italic 
> are the ones that should be tagged, not the words around them which 
> happen to be in italic.

Sure. But many people will surely want to use the TEI crudely for recording
font changes, and then release that text for someone else to do
semantic markup? I assume this is where the digilib levels of encoding
come in.

Sebastian

From sebastian.rahtz at oucs.ox.ac.uk  Sun May  6 12:00:08 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Sun, 6 May 2012 16:00:08 +0000
Subject: [tei-council] Fwd: TEI TITE question
In-Reply-To: <4FA67772.8010104@retired.ox.ac.uk>
References: <4FA660AE.3080907@oucs.ox.ac.uk>
	<012a76a2-c45a-4a92-8207-89917aa95067@HUB02.ad.oak.ox.ac.uk>
	<4FA67772.8010104@retired.ox.ac.uk>
Message-ID: <8ec8c195-1428-4283-a7ba-a2ec89e2131f@HUB06.ad.oak.ox.ac.uk>


On 6 May 2012, at 14:06, Lou Burnard wrote:

> If @rend is hard to use "meaningfully" surely it's the right choice for 
> sub/sup which are "seldom semantic".
different sort of meaningfully. I meant that using @rend is fairly
useless for interchange, but we could buy simple interchange
immediately with <sup> and <sub>

> I can't understand why people think sup and sub matter in things like 
> page signatures or ordinal numbers.
good lord, surely its used for many more things than that?

of course it doesnt _mean_ much, but won't most encoders do
"The only grand child of the Right Rev<hi rend="sup">d</hi>"
and not "The only grand child of the Right Revd"? is that just
sentimental twaddle?

> But I suppose a module called sugar is the way to go. Needs a more 
> sensible name though.

I suppose there are four choices

 1. say these are about transcription, and put them there (with <underline>)
 2. bung 'em in the swollen core, what the heck
 3. make a module for "born digital", and add in these elements cos they correspond to overwhelming modern practice
 4. create a specific module for syntactic sugar, with strict instructions that processors
    should expand these before processing, and guve unambiguous <equiv>s  for each thing

my preference varies between 3 and 4

sebastian

From sebastian.rahtz at oucs.ox.ac.uk  Sun May  6 12:02:16 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Sun, 6 May 2012 16:02:16 +0000
Subject: [tei-council] Fwd: TEI TITE question
In-Reply-To: <4FA67E29.60604@ultraslavonic.info>
References: <4FA660AE.3080907@oucs.ox.ac.uk>
	<012a76a2-c45a-4a92-8207-89917aa95067@HUB02.ad.oak.ox.ac.uk>
	<4FA67772.8010104@retired.ox.ac.uk> <4FA67E29.60604@ultraslavonic.info>
Message-ID: <1FB6031F-83BC-4808-9D08-4AD466EB41CE@oucs.ox.ac.uk>


On 6 May 2012, at 14:35, Kevin Hawkins wrote:

> Note that at http://purl.org/TEI/fr/3075996 , in which we discuss 
> incorporating parts of Tite into P5, we've considering having a fixed 
> list of values for @rend in Tite.  This solution could potentially be 
> used in P5 as well.

with the (so far non-existent) facility for TEI to modify itself, I could
imagine a TEI module called "strict" which had provided fixed
lists for @rend, to avoid everyone having to do it in their own ODD

Sebastian

From sebastian.rahtz at oucs.ox.ac.uk  Sun May  6 19:16:39 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Sun, 6 May 2012 23:16:39 +0000
Subject: [tei-council] <postscript>
Message-ID: <21E81436-F8A4-4219-B392-667250C9A21F@oucs.ox.ac.uk>

A gentleman of my acquaintance notes that this is illegal:

<postscript>
<p>some stuff</p>
<lb/>
<closer><signed>MM</signed></closer>
</postscript>

which seems harsh.

Would anyone care to know why we defined the content model of postscript
as

<zeroOrMore>
     <choice>
       <group>
<zeroOrMore xmlns="http://relaxng.org/ns/structure/1.0">
  <ref name="model.divTopPart"/>
</zeroOrMore>
<oneOrMore xmlns="http://relaxng.org/ns/structure/1.0">
  <ref name="model.common"/>
</oneOrMore>
<zeroOrMore xmlns="http://relaxng.org/ns/structure/1.0">
  <ref name="model.divBottomPart"/>
</zeroOrMore>
       </group>
       <group>
<ref name="model.global"/>
       </group>
     </choice>
 </zeroOrMore>

? i mean, why did we make model.global a choice all its own? the effect is that once you've met the <lb/>,
you go back to the start of the rule, and so <closer> fails cos there is nothing from model.common.

I know this is head-bending stuff, just vaguely hoping someone can see a rhyme or reason.

Sebastian



From mholmes at uvic.ca  Sun May  6 21:01:03 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Sun, 6 May 2012 18:01:03 -0700
Subject: [tei-council] <postscript>
In-Reply-To: <21E81436-F8A4-4219-B392-667250C9A21F@oucs.ox.ac.uk>
References: <21E81436-F8A4-4219-B392-667250C9A21F@oucs.ox.ac.uk>
Message-ID: <4FA71ECF.7000905@uvic.ca>

Odd indeed. You could get round it by including the <lb/> inside one of 
the other components, presumably:

<postscript>
<p>some stuff<lb/></p>
<closer><lb/><signed>MM</signed></closer>
</postscript>

but it's a hack.

What would you be wanting as a solution? Should model.global interleave 
with the others in the main group? Is this actually a case that would be 
a good illustration of the need for interleave?

Cheers,
Martin

On 12-05-06 04:16 PM, Sebastian Rahtz wrote:
> A gentleman of my acquaintance notes that this is illegal:
>
> <postscript>
> <p>some stuff</p>
> <lb/>
> <closer><signed>MM</signed></closer>
> </postscript>
>
> which seems harsh.
>
> Would anyone care to know why we defined the content model of postscript
> as
>
> <zeroOrMore>
>       <choice>
>         <group>
> <zeroOrMore xmlns="http://relaxng.org/ns/structure/1.0">
>    <ref name="model.divTopPart"/>
> </zeroOrMore>
> <oneOrMore xmlns="http://relaxng.org/ns/structure/1.0">
>    <ref name="model.common"/>
> </oneOrMore>
> <zeroOrMore xmlns="http://relaxng.org/ns/structure/1.0">
>    <ref name="model.divBottomPart"/>
> </zeroOrMore>
>         </group>
>         <group>
> <ref name="model.global"/>
>         </group>
>       </choice>
>   </zeroOrMore>
>
> ? i mean, why did we make model.global a choice all its own? the effect is that once you've met the<lb/>,
> you go back to the start of the rule, and so<closer>  fails cos there is nothing from model.common.
>
> I know this is head-bending stuff, just vaguely hoping someone can see a rhyme or reason.
>
> Sebastian
>
>

From sebastian.rahtz at oucs.ox.ac.uk  Mon May  7 05:08:31 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Mon, 7 May 2012 09:08:31 +0000
Subject: [tei-council] <postscript>
In-Reply-To: <4FA71ECF.7000905@uvic.ca>
References: <21E81436-F8A4-4219-B392-667250C9A21F@oucs.ox.ac.uk>
	<4FA71ECF.7000905@uvic.ca>
Message-ID: <3FC4D2E4-6400-408D-A0D5-8B9DF8D7F5E4@oucs.ox.ac.uk>


On 7 May 2012, at 02:01, Martin Holmes wrote:

> What would you be wanting as a solution? Should model.global interleave with the others in the main group? Is this actually a case that would be a good illustration of the need for interleave?
> 


yes, I think model.global  always causes problems because we don't have interleave-like features. This <postscript> situation is 
typical - we have to write very contorted models to avoid ambiguous content models

my answer is to rewrite postscript until it allows <lb/> anywhere, but yet retains the top*, common+, bottom* rule which is what
seems to be the intention. Does anyone disagree? its really like a little <div> (cf discussions in Ann Arbor....)

Sebastian


From lou.burnard at retired.ox.ac.uk  Mon May  7 10:08:55 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Mon, 07 May 2012 15:08:55 +0100
Subject: [tei-council] <postscript>
In-Reply-To: <21E81436-F8A4-4219-B392-667250C9A21F@oucs.ox.ac.uk>
References: <21E81436-F8A4-4219-B392-667250C9A21F@oucs.ox.ac.uk>
Message-ID: <4FA7D777.4050403@retired.ox.ac.uk>

On 07/05/12 00:16, Sebastian Rahtz wrote:
> A gentleman of my acquaintance notes that this is illegal:
>
> <postscript>
> <p>some stuff</p>
> <lb/>
> <closer><signed>MM</signed></closer>
> </postscript>
>
> which seems harsh.

Why? What is the <lb/> doing there? If it's meant to show that the 
<signed> starts on a new line, shouldn't it be inside the <signed>? (And 
in any case, surely the new line is implied by the </p> preceding it)

If it's meant to show that there is lots of white space before the 
<closer> then that is just Wrong.

From PFSchaffner at umich.edu  Mon May  7 10:57:54 2012
From: PFSchaffner at umich.edu (Paul F. Schaffner)
Date: Mon, 7 May 2012 10:57:54 -0400 (EDT)
Subject: [tei-council] Fwd: TEI TITE question
In-Reply-To: <1FB6031F-83BC-4808-9D08-4AD466EB41CE@oucs.ox.ac.uk>
References: <4FA660AE.3080907@oucs.ox.ac.uk>
	<012a76a2-c45a-4a92-8207-89917aa95067@HUB02.ad.oak.ox.ac.uk>
	<4FA67772.8010104@retired.ox.ac.uk> <4FA67E29.60604@ultraslavonic.info>
	<1FB6031F-83BC-4808-9D08-4AD466EB41CE@oucs.ox.ac.uk>
Message-ID: <Pine.LNX.4.64.1205071049580.14094@zaxxon.gpcc.itd.umich.edu>


On the 'pro' side, I've written schemas using i/b/u/sup/sub and
found them handy, especially for vendor use (and for string-based
processing). And they do have a reassuringly rootedness in actual
page phenomena: TCP tried instead to get keyers to recognize
'salience' or markedness, which required them to identify first
the unmarked default font of every structural unit. The result has
been almost unmitigated disaster. We should have simply asked them
to identify fonts and leave it at that.

On the 'con' side, I already find myself protesting the inadequacy of
the list. 'Bold' in particular is meaningless before, I think, the
19th century. Our chief contrasts are roman-italic-blackletter, with
occasional subtype contrasts (rotunda/textura/bastarda) and of course
font-size contrasts. On the Continent, it would be a little different.
And with non-Latin alphabets more different still.

pfs



On Sun, 6 May 2012, Sebastian Rahtz wrote:

>
> On 6 May 2012, at 14:35, Kevin Hawkins wrote:
>
>> Note that at http://purl.org/TEI/fr/3075996 , in which we discuss
>> incorporating parts of Tite into P5, we've considering having a fixed
>> list of values for @rend in Tite.  This solution could potentially be
>> used in P5 as well.
>
> with the (so far non-existent) facility for TEI to modify itself, I could
> imagine a TEI module called "strict" which had provided fixed
> lists for @rend, to avoid everyone having to do it in their own ODD
>
> Sebastian
> -- 
> tei-council mailing list
> tei-council at lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>
> PLEASE NOTE: postings to this list are publicly archived
>
>
>

--------------------------------------------------------------------
Paul Schaffner | PFSchaffner at umich.edu | http://www.umich.edu/~pfs/
316-C Hatcher Library N, Univ. of Michigan, Ann Arbor MI 48109-1190
--------------------------------------------------------------------

From sebastian.rahtz at oucs.ox.ac.uk  Mon May  7 11:06:24 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Mon, 7 May 2012 15:06:24 +0000
Subject: [tei-council] <postscript>
In-Reply-To: <4FA7D777.4050403@retired.ox.ac.uk>
References: <21E81436-F8A4-4219-B392-667250C9A21F@oucs.ox.ac.uk>
	<4FA7D777.4050403@retired.ox.ac.uk>
Message-ID: <285825e7-3e29-45e4-9f70-39121972217c@HUB03.ad.oak.ox.ac.uk>


On 7 May 2012, at 15:08, Lou Burnard wrote:

> On 07/05/12 00:16, Sebastian Rahtz wrote:
>> A gentleman of my acquaintance notes that this is illegal:
>> 
>> <postscript>
>> <p>some stuff</p>
>> <lb/>
>> <closer><signed>MM</signed></closer>
>> </postscript>
>> 
>> which seems harsh.
> 
> Why? What is the <lb/> doing there? If it's meant to show that the 
> <signed> starts on a new line, shouldn't it be inside the <signed>? (And 
> in any case, surely the new line is implied by the </p> preceding it)
> 
cf discussion about whether <signed> is block-level or inline.....

anyway, whether its mad or not, I am sure we _intended_ to allow lb (sic)
to interleave any old which way. mentally replace with <pb/>
if it makes you happier.

Sebastian


From PFSchaffner at umich.edu  Mon May  7 11:15:10 2012
From: PFSchaffner at umich.edu (Paul F. Schaffner)
Date: Mon, 7 May 2012 11:15:10 -0400 (EDT)
Subject: [tei-council] Fwd: TEI TITE question
In-Reply-To: <Pine.LNX.4.64.1205071049580.14094@zaxxon.gpcc.itd.umich.edu>
References: <4FA660AE.3080907@oucs.ox.ac.uk>
	<012a76a2-c45a-4a92-8207-89917aa95067@HUB02.ad.oak.ox.ac.uk>
	<4FA67772.8010104@retired.ox.ac.uk> <4FA67E29.60604@ultraslavonic.info>
	<1FB6031F-83BC-4808-9D08-4AD466EB41CE@oucs.ox.ac.uk>
	<Pine.LNX.4.64.1205071049580.14094@zaxxon.gpcc.itd.umich.edu>
Message-ID: <Pine.LNX.4.64.1205071113420.14094@zaxxon.gpcc.itd.umich.edu>

And oh yes, I imagine that the existence of <i> alongside
@rend="italic" would only tend to add to the confusion about
inherited renderings. pfs

On Mon, 7 May 2012, Paul F. Schaffner wrote:

>
> On the 'pro' side, I've written schemas using i/b/u/sup/sub and
> found them handy, especially for vendor use (and for string-based
> processing). And they do have a reassuringly rootedness in actual
> page phenomena: TCP tried instead to get keyers to recognize
> 'salience' or markedness, which required them to identify first
> the unmarked default font of every structural unit. The result has
> been almost unmitigated disaster. We should have simply asked them
> to identify fonts and leave it at that.
>
> On the 'con' side, I already find myself protesting the inadequacy of
> the list. 'Bold' in particular is meaningless before, I think, the
> 19th century. Our chief contrasts are roman-italic-blackletter, with
> occasional subtype contrasts (rotunda/textura/bastarda) and of course
> font-size contrasts. On the Continent, it would be a little different.
> And with non-Latin alphabets more different still.
>
> pfs
>
>
>
> On Sun, 6 May 2012, Sebastian Rahtz wrote:
>
>> 
>> On 6 May 2012, at 14:35, Kevin Hawkins wrote:
>> 
>>> Note that at http://purl.org/TEI/fr/3075996 , in which we discuss
>>> incorporating parts of Tite into P5, we've considering having a fixed
>>> list of values for @rend in Tite.  This solution could potentially be
>>> used in P5 as well.
>> 
>> with the (so far non-existent) facility for TEI to modify itself, I could
>> imagine a TEI module called "strict" which had provided fixed
>> lists for @rend, to avoid everyone having to do it in their own ODD
>> 
>> Sebastian
>> -- 
>> tei-council mailing list
>> tei-council at lists.village.Virginia.EDU
>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>> 
>> PLEASE NOTE: postings to this list are publicly archived
>> 
>> 
>> 
>
> --------------------------------------------------------------------
> Paul Schaffner | PFSchaffner at umich.edu | http://www.umich.edu/~pfs/
> 316-C Hatcher Library N, Univ. of Michigan, Ann Arbor MI 48109-1190
> --------------------------------------------------------------------
>

--------------------------------------------------------------------
Paul Schaffner | PFSchaffner at umich.edu | http://www.umich.edu/~pfs/
316-C Hatcher Library N, Univ. of Michigan, Ann Arbor MI 48109-1190
--------------------------------------------------------------------

From sebastian.rahtz at oucs.ox.ac.uk  Mon May  7 11:25:43 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Mon, 7 May 2012 15:25:43 +0000
Subject: [tei-council] Fwd: TEI TITE question
In-Reply-To: <Pine.LNX.4.64.1205071113420.14094@zaxxon.gpcc.itd.umich.edu>
References: <4FA660AE.3080907@oucs.ox.ac.uk>
	<012a76a2-c45a-4a92-8207-89917aa95067@HUB02.ad.oak.ox.ac.uk>
	<4FA67772.8010104@retired.ox.ac.uk> <4FA67E29.60604@ultraslavonic.info>
	<1FB6031F-83BC-4808-9D08-4AD466EB41CE@oucs.ox.ac.uk>
	<Pine.LNX.4.64.1205071049580.14094@zaxxon.gpcc.itd.umich.edu>
	<Pine.LNX.4.64.1205071113420.14094@zaxxon.gpcc.itd.umich.edu>
Message-ID: <05BBCEA5-9697-44B3-A3FE-322EBCAB1ADA@oucs.ox.ac.uk>


On 7 May 2012, at 16:15, Paul F. Schaffner wrote:

> And oh yes, I imagine that the existence of <i> alongside
> @rend="italic" would only tend to add to the confusion about
> inherited renderings. pfs

one could imagine the "kiss" module adding
i/b/u/bl/larger/smaller/sup/sub, and removing
the @rend attribute across the board. harsh but fair...

sebastian

From PFSchaffner at umich.edu  Mon May  7 11:35:31 2012
From: PFSchaffner at umich.edu (Paul F. Schaffner)
Date: Mon, 7 May 2012 11:35:31 -0400 (EDT)
Subject: [tei-council] <postscript>
In-Reply-To: <285825e7-3e29-45e4-9f70-39121972217c@HUB03.ad.oak.ox.ac.uk>
References: <21E81436-F8A4-4219-B392-667250C9A21F@oucs.ox.ac.uk>
	<4FA7D777.4050403@retired.ox.ac.uk>
	<285825e7-3e29-45e4-9f70-39121972217c@HUB03.ad.oak.ox.ac.uk>
Message-ID: <Pine.LNX.4.64.1205071132300.14094@zaxxon.gpcc.itd.umich.edu>

> anyway, whether its mad or not, I am sure we _intended_ to allow lb (sic)
> to interleave any old which way. mentally replace with <pb/>
> if it makes you happier.

Or <milestone/> or <note> ? Those are globals, right?

> a little <div> ...

Indeed, I think TCP's <postscript> was defined simply by stealing the
model of <div7> and trimming it down a bit.

pfs
--------------------------------------------------------------------
Paul Schaffner | PFSchaffner at umich.edu | http://www.umich.edu/~pfs/
316-C Hatcher Library N, Univ. of Michigan, Ann Arbor MI 48109-1190
--------------------------------------------------------------------

From mholmes at uvic.ca  Mon May  7 12:14:10 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Mon, 7 May 2012 09:14:10 -0700
Subject: [tei-council] Fwd: TEI TITE question
In-Reply-To: <05BBCEA5-9697-44B3-A3FE-322EBCAB1ADA@oucs.ox.ac.uk>
References: <4FA660AE.3080907@oucs.ox.ac.uk>
	<012a76a2-c45a-4a92-8207-89917aa95067@HUB02.ad.oak.ox.ac.uk>
	<4FA67772.8010104@retired.ox.ac.uk>
	<4FA67E29.60604@ultraslavonic.info>
	<1FB6031F-83BC-4808-9D08-4AD466EB41CE@oucs.ox.ac.uk>
	<Pine.LNX.4.64.1205071049580.14094@zaxxon.gpcc.itd.umich.edu>
	<Pine.LNX.4.64.1205071113420.14094@zaxxon.gpcc.itd.umich.edu>
	<05BBCEA5-9697-44B3-A3FE-322EBCAB1ADA@oucs.ox.ac.uk>
Message-ID: <4FA7F4D2.1070006@uvic.ca>

On 12-05-07 08:25 AM, Sebastian Rahtz wrote:
>
> On 7 May 2012, at 16:15, Paul F. Schaffner wrote:
>
>> And oh yes, I imagine that the existence of<i>  alongside
>> @rend="italic" would only tend to add to the confusion about
>> inherited renderings. pfs
>
> one could imagine the "kiss" module adding
> i/b/u/bl/larger/smaller/sup/sub, and removing
> the @rend attribute across the board. harsh but fair...

That would presuppose that your new elements cover all possible needs 
currently handled by @rend, which seems impossible to me. You'd always 
need @rend to cover the unpredicted, surely.

Cheers,
Martin

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From sebastian.rahtz at oucs.ox.ac.uk  Mon May  7 12:38:59 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Mon, 7 May 2012 16:38:59 +0000
Subject: [tei-council] Fwd: TEI TITE question
In-Reply-To: <4FA7F4D2.1070006@uvic.ca>
References: <4FA660AE.3080907@oucs.ox.ac.uk>
	<012a76a2-c45a-4a92-8207-89917aa95067@HUB02.ad.oak.ox.ac.uk>
	<4FA67772.8010104@retired.ox.ac.uk> <4FA67E29.60604@ultraslavonic.info>
	<1FB6031F-83BC-4808-9D08-4AD466EB41CE@oucs.ox.ac.uk>
	<Pine.LNX.4.64.1205071049580.14094@zaxxon.gpcc.itd.umich.edu>
	<Pine.LNX.4.64.1205071113420.14094@zaxxon.gpcc.itd.umich.edu>
	<05BBCEA5-9697-44B3-A3FE-322EBCAB1ADA@oucs.ox.ac.uk>
	<4FA7F4D2.1070006@uvic.ca>
Message-ID: <2F930E77-F582-4338-BA04-EAF40FFDB489@oucs.ox.ac.uk>


On 7 May 2012, at 17:14, Martin Holmes wrote:

> 
> That would presuppose that your new elements cover all possible needs 
> currently handled by @rend, which seems impossible to me. You'd always 
> need @rend to cover the unpredicted, surely.
> 
no, the point of the kiss module would be to
make things as predictable as possible.

you choose to have the power of hi/@rend, or
pick from our canned list of possibilities.

Sebastian


From mholmes at uvic.ca  Mon May  7 13:19:52 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Mon, 7 May 2012 10:19:52 -0700
Subject: [tei-council] Fwd: TEI TITE question
In-Reply-To: <2F930E77-F582-4338-BA04-EAF40FFDB489@oucs.ox.ac.uk>
References: <4FA660AE.3080907@oucs.ox.ac.uk>
	<012a76a2-c45a-4a92-8207-89917aa95067@HUB02.ad.oak.ox.ac.uk>
	<4FA67772.8010104@retired.ox.ac.uk>
	<4FA67E29.60604@ultraslavonic.info>
	<1FB6031F-83BC-4808-9D08-4AD466EB41CE@oucs.ox.ac.uk>
	<Pine.LNX.4.64.1205071049580.14094@zaxxon.gpcc.itd.umich.edu>
	<Pine.LNX.4.64.1205071113420.14094@zaxxon.gpcc.itd.umich.edu>
	<05BBCEA5-9697-44B3-A3FE-322EBCAB1ADA@oucs.ox.ac.uk>
	<4FA7F4D2.1070006@uvic.ca>
	<2F930E77-F582-4338-BA04-EAF40FFDB489@oucs.ox.ac.uk>
Message-ID: <4FA80438.4020308@uvic.ca>

On 12-05-07 09:38 AM, Sebastian Rahtz wrote:
>
> On 7 May 2012, at 17:14, Martin Holmes wrote:
>
>>
>> That would presuppose that your new elements cover all possible needs
>> currently handled by @rend, which seems impossible to me. You'd always
>> need @rend to cover the unpredicted, surely.
>>
> no, the point of the kiss module would be to
> make things as predictable as possible.
>
> you choose to have the power of hi/@rend, or
> pick from our canned list of possibilities.

Won't you find yourself continually dealing with feature requests for 
more canned possibilities to be added to the list?

Cheers,
Martin

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From PFSchaffner at umich.edu  Mon May  7 13:46:37 2012
From: PFSchaffner at umich.edu (Paul F. Schaffner)
Date: Mon, 7 May 2012 13:46:37 -0400 (EDT)
Subject: [tei-council] Fwd: TEI TITE question
In-Reply-To: <4FA80438.4020308@uvic.ca>
References: <4FA660AE.3080907@oucs.ox.ac.uk>
	<012a76a2-c45a-4a92-8207-89917aa95067@HUB02.ad.oak.ox.ac.uk>
	<4FA67772.8010104@retired.ox.ac.uk> <4FA67E29.60604@ultraslavonic.info>
	<1FB6031F-83BC-4808-9D08-4AD466EB41CE@oucs.ox.ac.uk>
	<Pine.LNX.4.64.1205071049580.14094@zaxxon.gpcc.itd.umich.edu>
	<Pine.LNX.4.64.1205071113420.14094@zaxxon.gpcc.itd.umich.edu>
	<05BBCEA5-9697-44B3-A3FE-322EBCAB1ADA@oucs.ox.ac.uk>
	<4FA7F4D2.1070006@uvic.ca>
	<2F930E77-F582-4338-BA04-EAF40FFDB489@oucs.ox.ac.uk>
	<4FA80438.4020308@uvic.ca>
Message-ID: <Pine.LNX.4.64.1205071341210.19656@zaxxon.gpcc.itd.umich.edu>

  In '<b>Martin <i>Holmes</i></b>' is  'Holmes' italic
or bold italic? If merely italic, then we clearly need <bi>.
Etc. etc.

  And of course a user interested in using <b> and <i> is not
for that reason any less likely to be interested in capturing
(say) <l rend="indent">. The most you could say, I think, is
that a user interested in marking font changes with <b> and <i>
would be less interested in using @rend="italic" and @rend="bold"
-- not that they would be less interested in using @rend for other
things like justification and indenting.

pfs

On Mon, 7 May 2012, Martin Holmes wrote:

> On 12-05-07 09:38 AM, Sebastian Rahtz wrote:
>>
>> On 7 May 2012, at 17:14, Martin Holmes wrote:
>>
>>>
>>> That would presuppose that your new elements cover all possible needs
>>> currently handled by @rend, which seems impossible to me. You'd always
>>> need @rend to cover the unpredicted, surely.
>>>
>> no, the point of the kiss module would be to
>> make things as predictable as possible.
>>
>> you choose to have the power of hi/@rend, or
>> pick from our canned list of possibilities.
>
> Won't you find yourself continually dealing with feature requests for
> more canned possibilities to be added to the list?
>
> Cheers,
> Martin
>
> -- 
> Martin Holmes
> University of Victoria Humanities Computing and Media Centre
> (mholmes at uvic.ca)
> -- 
> tei-council mailing list
> tei-council at lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>
> PLEASE NOTE: postings to this list are publicly archived
>
>
>

--------------------------------------------------------------------
Paul Schaffner | PFSchaffner at umich.edu | http://www.umich.edu/~pfs/
316-C Hatcher Library N, Univ. of Michigan, Ann Arbor MI 48109-1190
--------------------------------------------------------------------

From sebastian.rahtz at oucs.ox.ac.uk  Tue May  8 04:38:43 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Tue, 8 May 2012 08:38:43 +0000
Subject: [tei-council] TEI TITE question
In-Reply-To: <Pine.LNX.4.64.1205071341210.19656@zaxxon.gpcc.itd.umich.edu>
References: <4FA660AE.3080907@oucs.ox.ac.uk>
	<012a76a2-c45a-4a92-8207-89917aa95067@HUB02.ad.oak.ox.ac.uk>
	<4FA67772.8010104@retired.ox.ac.uk> <4FA67E29.60604@ultraslavonic.info>
	<1FB6031F-83BC-4808-9D08-4AD466EB41CE@oucs.ox.ac.uk>
	<Pine.LNX.4.64.1205071049580.14094@zaxxon.gpcc.itd.umich.edu>
	<Pine.LNX.4.64.1205071113420.14094@zaxxon.gpcc.itd.umich.edu>
	<05BBCEA5-9697-44B3-A3FE-322EBCAB1ADA@oucs.ox.ac.uk>
	<4FA7F4D2.1070006@uvic.ca>
	<2F930E77-F582-4338-BA04-EAF40FFDB489@oucs.ox.ac.uk>
	<4FA80438.4020308@uvic.ca>
	<Pine.LNX.4.64.1205071341210.19656@zaxxon.gpcc.itd.umich.edu>
Message-ID: <FCED4827-D114-427A-881C-91042BB47766@oucs.ox.ac.uk>


On 7 May 2012, at 18:46, Paul F. Schaffner wrote:

>  In '<b>Martin <i>Holmes</i></b>' is  'Holmes' italic
> or bold italic? If merely italic, then we clearly need <bi>.
> Etc. etc.

thats a matter of defining the rules clearly; and the
problem of requests for additions is not trivial either.
but neither are these things insurmountable
> 
>  And of course a user interested in using <b> and <i> is not
> for that reason any less likely to be interested in capturing
> (say) <l rend="indent">.

actually, I think I'd propose that "kiss" deleted <hi> rather than
@rend passim

please understand, I am doing a devil's advocate job here,
I am not a strong proponent. But I think its a _possible_
way forward.

--
Sebastian Rahtz      
Head of Information and Support Group
Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431

S?lo le pido a Dios
que el futuro no me sea indiferente


From lou.burnard at retired.ox.ac.uk  Tue May  8 04:58:20 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Tue, 08 May 2012 09:58:20 +0100
Subject: [tei-council] TEI TITE question
In-Reply-To: <FCED4827-D114-427A-881C-91042BB47766@oucs.ox.ac.uk>
References: <4FA660AE.3080907@oucs.ox.ac.uk>
	<012a76a2-c45a-4a92-8207-89917aa95067@HUB02.ad.oak.ox.ac.uk>
	<4FA67772.8010104@retired.ox.ac.uk>
	<4FA67E29.60604@ultraslavonic.info>
	<1FB6031F-83BC-4808-9D08-4AD466EB41CE@oucs.ox.ac.uk>
	<Pine.LNX.4.64.1205071049580.14094@zaxxon.gpcc.itd.umich.edu>
	<Pine.LNX.4.64.1205071113420.14094@zaxxon.gpcc.itd.umich.edu>
	<05BBCEA5-9697-44B3-A3FE-322EBCAB1ADA@oucs.ox.ac.uk>
	<4FA7F4D2.1070006@uvic.ca>
	<2F930E77-F582-4338-BA04-EAF40FFDB489@oucs.ox.ac.uk>
	<4FA80438.4020308@uvic.ca>
	<Pine.LNX.4.64.1205071341210.19656@zaxxon.gpcc.itd.umich.edu>
	<FCED4827-D114-427A-881C-91042BB47766@oucs.ox.ac.uk>
Message-ID: <4FA8E02C.4050703@retired.ox.ac.uk>

On 08/05/12 09:38, Sebastian Rahtz wrote:
>
> On 7 May 2012, at 18:46, Paul F. Schaffner wrote:
>
>>   In '<b>Martin<i>Holmes</i></b>' is  'Holmes' italic
>> or bold italic? If merely italic, then we clearly need<bi>.
>> Etc. etc.
>
> thats a matter of defining the rules clearly; and the
> problem of requests for additions is not trivial either.
> but neither are these things insurmountable


I think the point is that "defining the rules clearly" is not at all 
obvious. Some values of @rend are commutative, and others are clearly 
not. I would include in Paul's "etc etc" things like the following:

<italic>Martin <roman>Holmes</roman> esquire</italic>

or (if you think "roman" is just the unmarked case) suppose it were "tt"


>>
>>   And of course a user interested in using<b>  and<i>  is not
>> for that reason any less likely to be interested in capturing
>> (say)<l rend="indent">.
>
> actually, I think I'd propose that "kiss" deleted<hi>  rather than
> @rend passim

Thus leaving the inheritance issue entirely unchangeded? So I can do

<p rend="it">blah blah <bo>foo </bo> ...

and expect (or not) to see my foo in bold italic?

>
> please understand, I am doing a devil's advocate job here,
> I am not a strong proponent. But I think its a _possible_
> way forward.
>

I am sure we all agree that it's possible. Whether it's desirable is 
another question however.


From gabriel.bodard at kcl.ac.uk  Tue May  8 07:54:22 2012
From: gabriel.bodard at kcl.ac.uk (Gabriel BODARD)
Date: Tue, 8 May 2012 12:54:22 +0100
Subject: [tei-council] Fwd: TEI TITE question
In-Reply-To: <8ec8c195-1428-4283-a7ba-a2ec89e2131f@HUB06.ad.oak.ox.ac.uk>
References: <4FA660AE.3080907@oucs.ox.ac.uk>
	<012a76a2-c45a-4a92-8207-89917aa95067@HUB02.ad.oak.ox.ac.uk>
	<4FA67772.8010104@retired.ox.ac.uk>
	<8ec8c195-1428-4283-a7ba-a2ec89e2131f@HUB06.ad.oak.ox.ac.uk>
Message-ID: <4FA9096E.4050103@kcl.ac.uk>

On 06/05/2012 17:00, Sebastian Rahtz wrote:
> of course it doesnt _mean_ much, but won't most encoders do
> "The only grand child of the Right Rev<hi rend="sup">d</hi>"
> and not "The only grand child of the Right Revd"? is that just
> sentimental twaddle?

I'm against inserting the sort of semantic sugar (actually not semantic 
is it, just presentational sugar) proposed in this discussion. For me 
the awkwardness of entering <hi rend="super"> is a feature, not a bug, 
as it encourages the coder to consider a more semantic tag. The example 
above, for example, shouldn't be <hi> at all, it should be <am> or 
<abbr> or similar.

On the other hand, I'm strongly in favour of encouraging more 
consistency in the values of @rend (the first thing I do when I 
customize an odd is restrict @rend either globally or on <hi> to a 
constrained set of values).

I suppose at the end of the day my objection to the sugar module is no 
stonger than my saying, I'm sure I'd never use it. But I like the fact 
that the Tite elements map consistently to proper TEI. Watering down TEI 
so that (a) there are even more ways to do the same thing, and (b) it 
becomes more Tite-like and HTML-like, seems to me an abomination.

That said, an easy way to push a single button in Roma(aut sim.) and 
create a schema that has all your chosen rich modules and 
customizations, plus Tite-like sugar for coders would be a very useful 
thing. But it shouldn't be part of TEI All--it should be transformed to 
good TEI after data entry.

::grumble grumble::

::kids these days::

G

-- 
Dr Gabriel BODARD
(Research Associate in Digital Epigraphy)

Department of Digital Humanities
King's College London
26-29 Drury Lane
London WC2B 5RL

Email: gabriel.bodard at kcl.ac.uk
Tel: +44 (0)20 7848 1388
Fax: +44 (0)20 7848 2980

http://www.digitalclassicist.org/
http://www.currentepigraphy.org/

From sebastian.rahtz at oucs.ox.ac.uk  Tue May  8 08:52:29 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Tue, 8 May 2012 12:52:29 +0000
Subject: [tei-council] TEI TITE question
In-Reply-To: <4FA9096E.4050103@kcl.ac.uk>
References: <4FA660AE.3080907@oucs.ox.ac.uk>
	<012a76a2-c45a-4a92-8207-89917aa95067@HUB02.ad.oak.ox.ac.uk>
	<4FA67772.8010104@retired.ox.ac.uk>
	<8ec8c195-1428-4283-a7ba-a2ec89e2131f@HUB06.ad.oak.ox.ac.uk>
	<4FA9096E.4050103@kcl.ac.uk>
Message-ID: <BACBD862-E8D4-4D18-967F-ACA528C093B4@oucs.ox.ac.uk>

We shouldn't forget that the Tite extra tags must come from _somewhere_,
not just plucked at random from a fevered brain.  Why did that group feel these
were needed?
--
Sebastian Rahtz      
Head of Information and Support Group
Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431

S?lo le pido a Dios
que el futuro no me sea indiferente


From gabriel.bodard at kcl.ac.uk  Tue May  8 09:43:18 2012
From: gabriel.bodard at kcl.ac.uk (Gabriel BODARD)
Date: Tue, 8 May 2012 14:43:18 +0100
Subject: [tei-council] TEI TITE question
In-Reply-To: <BACBD862-E8D4-4D18-967F-ACA528C093B4@oucs.ox.ac.uk>
References: <4FA660AE.3080907@oucs.ox.ac.uk>
	<012a76a2-c45a-4a92-8207-89917aa95067@HUB02.ad.oak.ox.ac.uk>
	<4FA67772.8010104@retired.ox.ac.uk>
	<8ec8c195-1428-4283-a7ba-a2ec89e2131f@HUB06.ad.oak.ox.ac.uk>
	<4FA9096E.4050103@kcl.ac.uk>
	<BACBD862-E8D4-4D18-967F-ACA528C093B4@oucs.ox.ac.uk>
Message-ID: <4FA922F6.906@kcl.ac.uk>

To save money on keystrokes, no?

On 08/05/2012 13:52, Sebastian Rahtz wrote:
> We shouldn't forget that the Tite extra tags must come from _somewhere_,
> not just plucked at random from a fevered brain.  Why did that group feel these
> were needed?
> --
> Sebastian Rahtz
> Head of Information and Support Group
> Oxford University Computing Services
> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>
> S?lo le pido a Dios
> que el futuro no me sea indiferente
>

-- 
Dr Gabriel BODARD
(Research Associate in Digital Epigraphy)

Department of Digital Humanities
King's College London
26-29 Drury Lane
London WC2B 5RL

Email: gabriel.bodard at kcl.ac.uk
Tel: +44 (0)20 7848 1388
Fax: +44 (0)20 7848 2980

http://www.digitalclassicist.org/
http://www.currentepigraphy.org/

From lou.burnard at retired.ox.ac.uk  Tue May  8 09:58:14 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Tue, 08 May 2012 14:58:14 +0100
Subject: [tei-council] TEI TITE question
In-Reply-To: <4FA922F6.906@kcl.ac.uk>
References: <4FA660AE.3080907@oucs.ox.ac.uk>
	<012a76a2-c45a-4a92-8207-89917aa95067@HUB02.ad.oak.ox.ac.uk>
	<4FA67772.8010104@retired.ox.ac.uk>
	<8ec8c195-1428-4283-a7ba-a2ec89e2131f@HUB06.ad.oak.ox.ac.uk>
	<4FA9096E.4050103@kcl.ac.uk>
	<BACBD862-E8D4-4D18-967F-ACA528C093B4@oucs.ox.ac.uk>
	<4FA922F6.906@kcl.ac.uk>
Message-ID: <4FA92676.5070901@retired.ox.ac.uk>

Exactly! and also to avoid thinking too much. Thought takes time and 
costs money.

On 08/05/12 14:43, Gabriel BODARD wrote:
> To save money on keystrokes, no?
>
> On 08/05/2012 13:52, Sebastian Rahtz wrote:
>> We shouldn't forget that the Tite extra tags must come from _somewhere_,
>> not just plucked at random from a fevered brain.  Why did that group feel these
>> were needed?
>> --
>> Sebastian Rahtz
>> Head of Information and Support Group
>> Oxford University Computing Services
>> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>>
>> S?lo le pido a Dios
>> que el futuro no me sea indiferente
>>
>


From kevin.s.hawkins at ultraslavonic.info  Tue May  8 09:58:52 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Tue, 08 May 2012 09:58:52 -0400
Subject: [tei-council] Fwd: TEI TITE question
In-Reply-To: <4FA9096E.4050103@kcl.ac.uk>
References: <4FA660AE.3080907@oucs.ox.ac.uk>	<012a76a2-c45a-4a92-8207-89917aa95067@HUB02.ad.oak.ox.ac.uk>	<4FA67772.8010104@retired.ox.ac.uk>	<8ec8c195-1428-4283-a7ba-a2ec89e2131f@HUB06.ad.oak.ox.ac.uk>
	<4FA9096E.4050103@kcl.ac.uk>
Message-ID: <4FA9269C.2060406@ultraslavonic.info>

To respond to these two points ...

On 5/8/2012 7:54 AM, Gabriel BODARD wrote:
> I'm against inserting the sort of semantic sugar (actually not semantic
> is it, just presentational sugar) proposed in this discussion. For me
> the awkwardness of entering<hi rend="super">  is a feature, not a bug,
> as it encourages the coder to consider a more semantic tag. The example
> above, for example, shouldn't be<hi>  at all, it should be<am>  or
> <abbr>  or similar.

On 5/8/2012 8:52 AM, Sebastian Rahtz wrote:
 > We shouldn't forget that the Tite extra tags must come from _somewhere_,
 > not just plucked at random from a fevered brain.  Why did that group 
feel these
 > were needed?

... I think the question is what uses of digital text the TEI aims to 
support.  The Guidelines "are addressed to anyone who works with any 
kind of textual resource in digital form", and yet:

a) We know that lots of workflows for large-scale digitization and 
conversion from born-digital documents recognize italics and bold 
without attempting to do the labor-intensive and difficult work of 
distinguishing them (cf. Gabby's comment).

b) We know that people have identified bold, italics, superscript, 
subscript, etc. as being such common features that they deserve their 
own elements (as in Sebastian's comment).

It seems to me that there is a compelling case for supporting a certain 
depth of encoding that doesn't try to disambiguate phrase-level 
features.  (This is Level 3 in the Best Practices for TEI in Libraries.) 
  This could be done using those particular features chosen for Tite.

From kevin.s.hawkins at ultraslavonic.info  Tue May  8 10:06:20 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Tue, 08 May 2012 10:06:20 -0400
Subject: [tei-council] TEI TITE question
In-Reply-To: <4FA92676.5070901@retired.ox.ac.uk>
References: <4FA660AE.3080907@oucs.ox.ac.uk>	<012a76a2-c45a-4a92-8207-89917aa95067@HUB02.ad.oak.ox.ac.uk>	<4FA67772.8010104@retired.ox.ac.uk>	<8ec8c195-1428-4283-a7ba-a2ec89e2131f@HUB06.ad.oak.ox.ac.uk>	<4FA9096E.4050103@kcl.ac.uk>	<BACBD862-E8D4-4D18-967F-ACA528C093B4@oucs.ox.ac.uk>	<4FA922F6.906@kcl.ac.uk>
	<4FA92676.5070901@retired.ox.ac.uk>
Message-ID: <4FA9285C.1020505@ultraslavonic.info>

No!

We give people shortcut options like <name> and <bibl> instead of 
forcing them to think too much by using <forename>, <surname>, and 
<biblStruct> because we know that for certain envisioned uses of the 
encoded document, these are perfectly sufficient.  How do we know that 
it's for someone's own good to distinguish various uses of italics?

The situation we are in right now is as if the TEI had only:

<forename>
<surname>
<rs type="name">

but no:

<name>

(I understand the distinction Gabby made between semantic and 
presentational sugar, but now I'm talking about straightforwardness of 
encoding.)

--K.

On 5/8/2012 9:58 AM, Lou Burnard wrote:
> Exactly! and also to avoid thinking too much. Thought takes time and
> costs money.
>
> On 08/05/12 14:43, Gabriel BODARD wrote:
>> To save money on keystrokes, no?
>>
>> On 08/05/2012 13:52, Sebastian Rahtz wrote:
>>> We shouldn't forget that the Tite extra tags must come from _somewhere_,
>>> not just plucked at random from a fevered brain.  Why did that group feel these
>>> were needed?
>>> --
>>> Sebastian Rahtz
>>> Head of Information and Support Group
>>> Oxford University Computing Services
>>> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>>>
>>> S?lo le pido a Dios
>>> que el futuro no me sea indiferente
>>>
>>
>

From PFSchaffner at umich.edu  Tue May  8 10:18:50 2012
From: PFSchaffner at umich.edu (Paul F. Schaffner)
Date: Tue, 8 May 2012 10:18:50 -0400 (EDT)
Subject: [tei-council] TEI TITE question
In-Reply-To: <4FA922F6.906@kcl.ac.uk>
References: <4FA660AE.3080907@oucs.ox.ac.uk>
	<012a76a2-c45a-4a92-8207-89917aa95067@HUB02.ad.oak.ox.ac.uk>
	<4FA67772.8010104@retired.ox.ac.uk>
	<8ec8c195-1428-4283-a7ba-a2ec89e2131f@HUB06.ad.oak.ox.ac.uk>
	<4FA9096E.4050103@kcl.ac.uk>
	<BACBD862-E8D4-4D18-967F-ACA528C093B4@oucs.ox.ac.uk>
	<4FA922F6.906@kcl.ac.uk>
Message-ID: <Pine.LNX.4.64.1205081011570.14534@joust.gpcc.itd.umich.edu>

On Tue, 8 May 2012, Gabriel BODARD wrote:

> To save money on keystrokes, no?

Some may indeed think that way, but to my mind this has always been
something of a red herring. Vendors are clever enough to know the
difference between succinct and verbose markup (to assess the
density of the product, as it were), and to set their prices
accordingly. If you insist on short tags, they will charge more
per byte; if long tags, they will charge less. The only issue
arises when they are offered a choice, in which case they may
well price on the basis of short tags and deliver long ones.

pfs
--------------------------------------------------------------------
Paul Schaffner | PFSchaffner at umich.edu | http://www.umich.edu/~pfs/
316-C Hatcher Library N, Univ. of Michigan, Ann Arbor MI 48109-1190
--------------------------------------------------------------------

From gabriel.bodard at kcl.ac.uk  Tue May  8 10:25:19 2012
From: gabriel.bodard at kcl.ac.uk (Gabriel BODARD)
Date: Tue, 8 May 2012 15:25:19 +0100
Subject: [tei-council] TEI TITE question
In-Reply-To: <4FA9285C.1020505@ultraslavonic.info>
References: <4FA660AE.3080907@oucs.ox.ac.uk>
	<012a76a2-c45a-4a92-8207-89917aa95067@HUB02.ad.oak.ox.ac.uk>
	<4FA67772.8010104@retired.ox.ac.uk>
	<8ec8c195-1428-4283-a7ba-a2ec89e2131f@HUB06.ad.oak.ox.ac.uk>
	<4FA9096E.4050103@kcl.ac.uk>
	<BACBD862-E8D4-4D18-967F-ACA528C093B4@oucs.ox.ac.uk>
	<4FA922F6.906@kcl.ac.uk>	<4FA92676.5070901@retired.ox.ac.uk>
	<4FA9285C.1020505@ultraslavonic.info>
Message-ID: <4FA92CCF.10104@kcl.ac.uk>

I'm not entirely clear that the situation is quite the same as

 > <forename>
 > <surname>
 > <rs type="name">

(Or even <placeName>, <persName>, <rs type="name">.) What we have at the 
moment is no shortcuts for <hi rend="x"> at all, because the list of 
possible values for "x" is near infinite. (Even a short list is pretty 
long.)

We already have a long-established way to encode the undistinguished use 
of italics, the only argument against which is that it's more keystrokes 
than <it>. We could easily encourage more consistency in attribute 
values if we really wanted to--though I predict there will be resistance 
to doing so.

There is also a certain semantic value in the <hi> element, by which I 
mean in its very name, not it's attribute values: this text is 
highlighted in some way to set it apart from the surrounding text. I can 
imagine a transcription scenario when all you want to encode is that the 
text is set apart, not how it is rendered.

My opinion remains that there is a place for elements such as <i>, <b>, 
<sup>, etc., but that that place is in a custom schema for 
encoders/vendors, not in the published, interchangeable TEI.



On 08/05/2012 15:06, Kevin Hawkins wrote:
> No!
>
> We give people shortcut options like<name>  and<bibl>  instead of
> forcing them to think too much by using<forename>,<surname>, and
> <biblStruct>  because we know that for certain envisioned uses of the
> encoded document, these are perfectly sufficient.  How do we know that
> it's for someone's own good to distinguish various uses of italics?
>
> The situation we are in right now is as if the TEI had only:
>
> <forename>
> <surname>
> <rs type="name">
>
> but no:
>
> <name>
>
> (I understand the distinction Gabby made between semantic and
> presentational sugar, but now I'm talking about straightforwardness of
> encoding.)
>
> --K.
>
> On 5/8/2012 9:58 AM, Lou Burnard wrote:
>> Exactly! and also to avoid thinking too much. Thought takes time and
>> costs money.
>>
>> On 08/05/12 14:43, Gabriel BODARD wrote:
>>> To save money on keystrokes, no?
>>>
>>> On 08/05/2012 13:52, Sebastian Rahtz wrote:
>>>> We shouldn't forget that the Tite extra tags must come from _somewhere_,
>>>> not just plucked at random from a fevered brain.  Why did that group feel these
>>>> were needed?
>>>> --
>>>> Sebastian Rahtz
>>>> Head of Information and Support Group
>>>> Oxford University Computing Services
>>>> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>>>>
>>>> S?lo le pido a Dios
>>>> que el futuro no me sea indiferente
>>>>
>>>
>>

-- 
Dr Gabriel BODARD
(Research Associate in Digital Epigraphy)

Department of Digital Humanities
King's College London
26-29 Drury Lane
London WC2B 5RL

Email: gabriel.bodard at kcl.ac.uk
Tel: +44 (0)20 7848 1388
Fax: +44 (0)20 7848 2980

http://www.digitalclassicist.org/
http://www.currentepigraphy.org/

From kevin.s.hawkins at ultraslavonic.info  Tue May  8 10:34:28 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Tue, 08 May 2012 10:34:28 -0400
Subject: [tei-council] TEI TITE question
In-Reply-To: <4FA92CCF.10104@kcl.ac.uk>
References: <4FA660AE.3080907@oucs.ox.ac.uk>	<012a76a2-c45a-4a92-8207-89917aa95067@HUB02.ad.oak.ox.ac.uk>	<4FA67772.8010104@retired.ox.ac.uk>	<8ec8c195-1428-4283-a7ba-a2ec89e2131f@HUB06.ad.oak.ox.ac.uk>	<4FA9096E.4050103@kcl.ac.uk>	<BACBD862-E8D4-4D18-967F-ACA528C093B4@oucs.ox.ac.uk>	<4FA922F6.906@kcl.ac.uk>	<4FA92676.5070901@retired.ox.ac.uk>	<4FA9285C.1020505@ultraslavonic.info>
	<4FA92CCF.10104@kcl.ac.uk>
Message-ID: <4FA92EF4.10708@ultraslavonic.info>

On 5/8/2012 10:25 AM, Gabriel BODARD wrote:
> We already have a long-established way to encode the undistinguished use
> of italics, the only argument against which is that it's more keystrokes
> than<it>. We could easily encourage more consistency in attribute
> values if we really wanted to--though I predict there will be resistance
> to doing so.

But what is this long-established way?  I can think of many (with 
non-canonical practices marked with an asterisk):

<hi rend="i">

<hi rend="ii">

<hi rend="ital">

<hi rend="italic">

<hi rend="italics">

<hi rend="Kursiv">

<hi rendition="#foo"> with <rendition xml:id="foo" 
scheme="css">font-style: italic</rendition>

<hi rendition="#foo"> with <rendition xml:id="foo" scheme="free">This 
text is italicized.</rendition>

*<hi rend="font-style: italic">

> There is also a certain semantic value in the<hi>  element, by which I
> mean in its very name, not it's attribute values: this text is
> highlighted in some way to set it apart from the surrounding text. I can
> imagine a transcription scenario when all you want to encode is that the
> text is set apart, not how it is rendered.

I agree with the value of <hi> and do not think we should eliminate this 
element.

> My opinion remains that there is a place for elements such as<i>,<b>,
> <sup>, etc., but that that place is in a custom schema for
> encoders/vendors, not in the published, interchangeable TEI.

But it would be enormously helpful if the TEI could promote interchange 
of encoding of italics, bold, and other of the most common features in 
printed source documents!

From bansp at o2.pl  Tue May  8 10:40:09 2012
From: bansp at o2.pl (=?ISO-8859-2?Q?Piotr_Ba=F1ski?=)
Date: Tue, 08 May 2012 16:40:09 +0200
Subject: [tei-council] TEI TITE question
In-Reply-To: <4FA92CCF.10104@kcl.ac.uk>
References: <4FA660AE.3080907@oucs.ox.ac.uk>
	<012a76a2-c45a-4a92-8207-89917aa95067@HUB02.ad.oak.ox.ac.uk>
	<4FA67772.8010104@retired.ox.ac.uk>
	<8ec8c195-1428-4283-a7ba-a2ec89e2131f@HUB06.ad.oak.ox.ac.uk>
	<4FA9096E.4050103@kcl.ac.uk>
	<BACBD862-E8D4-4D18-967F-ACA528C093B4@oucs.ox.ac.uk>
	<4FA922F6.906@kcl.ac.uk>	<4FA92676.5070901@retired.ox.ac.uk>
	<4FA9285C.1020505@ultraslavonic.info> <4FA92CCF.10104@kcl.ac.uk>
Message-ID: <4FA93049.9030703@o2.pl>

It seems to me that <i>, <it>, <ital> and friends are on the leaves of
interoperability -- they are what often has to be aligned between
formats. In the trunk, or pivot, sits the <hi> element, with a multitude
of ways of describing it further, if necessary (even including a pointer
to an external reference system that defines "italic"). This is the rich
core through which the flow of interoperability should be directed. Add
<i> to <hi> and the result is an increase, instead of decrease, of
messiness. It opens the way for all the other HTML 3.2 stuff.

  P.

On 08/05/12 16:25, Gabriel BODARD wrote:
> I'm not entirely clear that the situation is quite the same as
> 
>  > <forename>
>  > <surname>
>  > <rs type="name">
> 
> (Or even <placeName>, <persName>, <rs type="name">.) What we have at the 
> moment is no shortcuts for <hi rend="x"> at all, because the list of 
> possible values for "x" is near infinite. (Even a short list is pretty 
> long.)
> 
> We already have a long-established way to encode the undistinguished use 
> of italics, the only argument against which is that it's more keystrokes 
> than <it>. We could easily encourage more consistency in attribute 
> values if we really wanted to--though I predict there will be resistance 
> to doing so.
> 
> There is also a certain semantic value in the <hi> element, by which I 
> mean in its very name, not it's attribute values: this text is 
> highlighted in some way to set it apart from the surrounding text. I can 
> imagine a transcription scenario when all you want to encode is that the 
> text is set apart, not how it is rendered.
> 
> My opinion remains that there is a place for elements such as <i>, <b>, 
> <sup>, etc., but that that place is in a custom schema for 
> encoders/vendors, not in the published, interchangeable TEI.
> 
> 
> 
> On 08/05/2012 15:06, Kevin Hawkins wrote:
>> No!
>>
>> We give people shortcut options like<name>  and<bibl>  instead of
>> forcing them to think too much by using<forename>,<surname>, and
>> <biblStruct>  because we know that for certain envisioned uses of the
>> encoded document, these are perfectly sufficient.  How do we know that
>> it's for someone's own good to distinguish various uses of italics?
>>
>> The situation we are in right now is as if the TEI had only:
>>
>> <forename>
>> <surname>
>> <rs type="name">
>>
>> but no:
>>
>> <name>
>>
>> (I understand the distinction Gabby made between semantic and
>> presentational sugar, but now I'm talking about straightforwardness of
>> encoding.)
>>
>> --K.
>>
>> On 5/8/2012 9:58 AM, Lou Burnard wrote:
>>> Exactly! and also to avoid thinking too much. Thought takes time and
>>> costs money.
>>>
>>> On 08/05/12 14:43, Gabriel BODARD wrote:
>>>> To save money on keystrokes, no?
>>>>
>>>> On 08/05/2012 13:52, Sebastian Rahtz wrote:
>>>>> We shouldn't forget that the Tite extra tags must come from _somewhere_,
>>>>> not just plucked at random from a fevered brain.  Why did that group feel these
>>>>> were needed?
>>>>> --
>>>>> Sebastian Rahtz
>>>>> Head of Information and Support Group
>>>>> Oxford University Computing Services
>>>>> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>>>>>
>>>>> S?lo le pido a Dios
>>>>> que el futuro no me sea indiferente
>>>>>
>>>>
>>>
> 


From gabriel.bodard at kcl.ac.uk  Tue May  8 10:43:26 2012
From: gabriel.bodard at kcl.ac.uk (Gabriel BODARD)
Date: Tue, 8 May 2012 15:43:26 +0100
Subject: [tei-council] TEI TITE question
In-Reply-To: <4FA92EF4.10708@ultraslavonic.info>
References: <4FA660AE.3080907@oucs.ox.ac.uk>
	<012a76a2-c45a-4a92-8207-89917aa95067@HUB02.ad.oak.ox.ac.uk>
	<4FA67772.8010104@retired.ox.ac.uk>
	<8ec8c195-1428-4283-a7ba-a2ec89e2131f@HUB06.ad.oak.ox.ac.uk>
	<4FA9096E.4050103@kcl.ac.uk>
	<BACBD862-E8D4-4D18-967F-ACA528C093B4@oucs.ox.ac.uk>
	<4FA922F6.906@kcl.ac.uk>	<4FA92676.5070901@retired.ox.ac.uk>
	<4FA9285C.1020505@ultraslavonic.info>	<4FA92CCF.10104@kcl.ac.uk>
	<4FA92EF4.10708@ultraslavonic.info>
Message-ID: <4FA9310E.60102@kcl.ac.uk>

All of the below. If you want better interchangeability, then let's 
argue for a list of recommended values for @rend, rather than for adding 
yet one more way of doing this.

I would support this argument.

@rend (rendition) indicates how the element in question was rendered or 
presented in the source text.
Status 	Optional
Datatype 	1?? occurrences of data.word separated by whitespace
Values 	may contain any number of tokens, each of which may contain 
letters, punctuation marks, or symbols, but not word-separating 
characters. Suggested values include:
	italic
	bold
	superscript
	subscript
	underline
	larger
	smaller

This won't force anyone to do this, and it won't break backward 
compatibility or fix the mess that exists in old texts, but it will 
reduce the likelihood in future of values such as "italics", "i", "ii", 
"it", "ital", etc.

G

On 08/05/2012 15:34, Kevin Hawkins wrote:
> On 5/8/2012 10:25 AM, Gabriel BODARD wrote:
>> We already have a long-established way to encode the undistinguished use
>> of italics, the only argument against which is that it's more keystrokes
>> than<it>. We could easily encourage more consistency in attribute
>> values if we really wanted to--though I predict there will be resistance
>> to doing so.
>
> But what is this long-established way?  I can think of many (with
> non-canonical practices marked with an asterisk):
>
> <hi rend="i">
>
> <hi rend="ii">
>
> <hi rend="ital">
>
> <hi rend="italic">
>
> <hi rend="italics">
>
> <hi rend="Kursiv">
>
> <hi rendition="#foo">  with<rendition xml:id="foo"
> scheme="css">font-style: italic</rendition>
>
> <hi rendition="#foo">  with<rendition xml:id="foo" scheme="free">This
> text is italicized.</rendition>
>
> *<hi rend="font-style: italic">
>
>> There is also a certain semantic value in the<hi>   element, by which I
>> mean in its very name, not it's attribute values: this text is
>> highlighted in some way to set it apart from the surrounding text. I can
>> imagine a transcription scenario when all you want to encode is that the
>> text is set apart, not how it is rendered.
>
> I agree with the value of<hi>  and do not think we should eliminate this
> element.
>
>> My opinion remains that there is a place for elements such as<i>,<b>,
>> <sup>, etc., but that that place is in a custom schema for
>> encoders/vendors, not in the published, interchangeable TEI.
>
> But it would be enormously helpful if the TEI could promote interchange
> of encoding of italics, bold, and other of the most common features in
> printed source documents!

-- 
Dr Gabriel BODARD
(Research Associate in Digital Epigraphy)

Department of Digital Humanities
King's College London
26-29 Drury Lane
London WC2B 5RL

Email: gabriel.bodard at kcl.ac.uk
Tel: +44 (0)20 7848 1388
Fax: +44 (0)20 7848 2980

http://www.digitalclassicist.org/
http://www.currentepigraphy.org/

From kevin.s.hawkins at ultraslavonic.info  Tue May  8 10:47:02 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Tue, 08 May 2012 10:47:02 -0400
Subject: [tei-council] TEI TITE question
In-Reply-To: <4FA93049.9030703@o2.pl>
References: <4FA660AE.3080907@oucs.ox.ac.uk>	<012a76a2-c45a-4a92-8207-89917aa95067@HUB02.ad.oak.ox.ac.uk>	<4FA67772.8010104@retired.ox.ac.uk>	<8ec8c195-1428-4283-a7ba-a2ec89e2131f@HUB06.ad.oak.ox.ac.uk>	<4FA9096E.4050103@kcl.ac.uk>	<BACBD862-E8D4-4D18-967F-ACA528C093B4@oucs.ox.ac.uk>	<4FA922F6.906@kcl.ac.uk>	<4FA92676.5070901@retired.ox.ac.uk>	<4FA9285C.1020505@ultraslavonic.info>
	<4FA92CCF.10104@kcl.ac.uk> <4FA93049.9030703@o2.pl>
Message-ID: <4FA931E6.2010304@ultraslavonic.info>

Wait, now we're talking about mapping between various XML schemes, each 
of which represent italics.  This is a different matter.

My point is that we should offer a clear way to represent 
undifferentiated italicized text in TEI.  Right now, "<hi>" is not a 
clear way to do this.

On 5/8/2012 10:40 AM, Piotr Ba?ski wrote:
> It seems to me that<i>,<it>,<ital>  and friends are on the leaves of
> interoperability -- they are what often has to be aligned between
> formats. In the trunk, or pivot, sits the<hi>  element, with a multitude
> of ways of describing it further, if necessary (even including a pointer
> to an external reference system that defines "italic"). This is the rich
> core through which the flow of interoperability should be directed. Add
> <i>  to<hi>  and the result is an increase, instead of decrease, of
> messiness. It opens the way for all the other HTML 3.2 stuff.
>
>    P.

From kevin.s.hawkins at ultraslavonic.info  Tue May  8 10:49:05 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Tue, 08 May 2012 10:49:05 -0400
Subject: [tei-council] TEI TITE question
In-Reply-To: <4FA9310E.60102@kcl.ac.uk>
References: <4FA660AE.3080907@oucs.ox.ac.uk>	<012a76a2-c45a-4a92-8207-89917aa95067@HUB02.ad.oak.ox.ac.uk>	<4FA67772.8010104@retired.ox.ac.uk>	<8ec8c195-1428-4283-a7ba-a2ec89e2131f@HUB06.ad.oak.ox.ac.uk>	<4FA9096E.4050103@kcl.ac.uk>	<BACBD862-E8D4-4D18-967F-ACA528C093B4@oucs.ox.ac.uk>	<4FA922F6.906@kcl.ac.uk>	<4FA92676.5070901@retired.ox.ac.uk>	<4FA9285C.1020505@ultraslavonic.info>	<4FA92CCF.10104@kcl.ac.uk>	<4FA92EF4.10708@ultraslavonic.info>
	<4FA9310E.60102@kcl.ac.uk>
Message-ID: <4FA93261.5000803@ultraslavonic.info>

I would support this.  But I would go further by offering the Tite 
elements as presentational sugar for these suggested values.  There's 
enough sugar elsewhere in the TEI that no one is going to be confused by 
a few more such elements.

On 5/8/2012 10:43 AM, Gabriel BODARD wrote:
> [. . .] If you want better interchangeability, then let's
> argue for a list of recommended values for @rend, rather than for adding
> yet one more way of doing this.
>
> I would support this argument.
>
> @rend (rendition) indicates how the element in question was rendered or
> presented in the source text.
> Status 	Optional
> Datatype 	1?? occurrences of data.word separated by whitespace
> Values 	may contain any number of tokens, each of which may contain
> letters, punctuation marks, or symbols, but not word-separating
> characters. Suggested values include:
> 	italic
> 	bold
> 	superscript
> 	subscript
> 	underline
> 	larger
> 	smaller
>
> This won't force anyone to do this, and it won't break backward
> compatibility or fix the mess that exists in old texts, but it will
> reduce the likelihood in future of values such as "italics", "i", "ii",
> "it", "ital", etc.
>
> G

From mholmes at uvic.ca  Tue May  8 10:59:22 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Tue, 8 May 2012 07:59:22 -0700
Subject: [tei-council] TEI TITE question
In-Reply-To: <4FA9285C.1020505@ultraslavonic.info>
References: <4FA660AE.3080907@oucs.ox.ac.uk>
	<012a76a2-c45a-4a92-8207-89917aa95067@HUB02.ad.oak.ox.ac.uk>
	<4FA67772.8010104@retired.ox.ac.uk>
	<8ec8c195-1428-4283-a7ba-a2ec89e2131f@HUB06.ad.oak.ox.ac.uk>
	<4FA9096E.4050103@kcl.ac.uk>
	<BACBD862-E8D4-4D18-967F-ACA528C093B4@oucs.ox.ac.uk>
	<4FA922F6.906@kcl.ac.uk>	<4FA92676.5070901@retired.ox.ac.uk>
	<4FA9285C.1020505@ultraslavonic.info>
Message-ID: <4FA934CA.3090503@uvic.ca>

I don't think I agree with this. As the Gentle Introduction to XML says, 
"XML is more interested in the meaning of data than in its 
presentation." We have lots of ways of encoding names because the 
variety of name types and the subtle distinctions between them are 
things that we're primarily interested in. In the same way, I think most 
encoders are (or perhaps should be?) more interested in why something is 
italic than in the fact that it is italic.

I agree with the point someone made earlier: the slight inconvenience of 
<hi rend="whatever"> is actually useful, because it makes us wonder why 
we're seeing this presentational feature, and perhaps pushes us in the 
direction of encoding it in some more meaningful way (<emph> or whatever).

Cheers,
Martin

On 12-05-08 07:06 AM, Kevin Hawkins wrote:
> No!
>
> We give people shortcut options like<name>  and<bibl>  instead of
> forcing them to think too much by using<forename>,<surname>, and
> <biblStruct>  because we know that for certain envisioned uses of the
> encoded document, these are perfectly sufficient.  How do we know that
> it's for someone's own good to distinguish various uses of italics?
>
> The situation we are in right now is as if the TEI had only:
>
> <forename>
> <surname>
> <rs type="name">
>
> but no:
>
> <name>
>
> (I understand the distinction Gabby made between semantic and
> presentational sugar, but now I'm talking about straightforwardness of
> encoding.)
>
> --K.
>
> On 5/8/2012 9:58 AM, Lou Burnard wrote:
>> Exactly! and also to avoid thinking too much. Thought takes time and
>> costs money.
>>
>> On 08/05/12 14:43, Gabriel BODARD wrote:
>>> To save money on keystrokes, no?
>>>
>>> On 08/05/2012 13:52, Sebastian Rahtz wrote:
>>>> We shouldn't forget that the Tite extra tags must come from _somewhere_,
>>>> not just plucked at random from a fevered brain.  Why did that group feel these
>>>> were needed?
>>>> --
>>>> Sebastian Rahtz
>>>> Head of Information and Support Group
>>>> Oxford University Computing Services
>>>> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>>>>
>>>> S?lo le pido a Dios
>>>> que el futuro no me sea indiferente
>>>>
>>>
>>

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From kevin.s.hawkins at ultraslavonic.info  Tue May  8 11:30:24 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Tue, 08 May 2012 11:30:24 -0400
Subject: [tei-council] TEI TITE question
In-Reply-To: <4FA934CA.3090503@uvic.ca>
References: <4FA660AE.3080907@oucs.ox.ac.uk>
	<012a76a2-c45a-4a92-8207-89917aa95067@HUB02.ad.oak.ox.ac.uk>
	<4FA67772.8010104@retired.ox.ac.uk>
	<8ec8c195-1428-4283-a7ba-a2ec89e2131f@HUB06.ad.oak.ox.ac.uk>
	<4FA9096E.4050103@kcl.ac.uk>
	<BACBD862-E8D4-4D18-967F-ACA528C093B4@oucs.ox.ac.uk>
	<4FA922F6.906@kcl.ac.uk>	<4FA92676.5070901@retired.ox.ac.uk>
	<4FA9285C.1020505@ultraslavonic.info> <4FA934CA.3090503@uvic.ca>
Message-ID: <4FA93C10.7060807@ultraslavonic.info>

I know it sounds crazy, but I don't see how we can say that an encoder 
should be more interested in why something is in italics than in whether 
a name is a surname, patronymic, forename, etc.  It all depends on what 
you want to do with your digital text.  That statement from the gentle 
introduction is even prejudiced, frankly: it assumes certain uses of XML.

On 5/8/2012 10:59 AM, Martin Holmes wrote:
> I don't think I agree with this. As the Gentle Introduction to XML says,
> "XML is more interested in the meaning of data than in its
> presentation." We have lots of ways of encoding names because the
> variety of name types and the subtle distinctions between them are
> things that we're primarily interested in. In the same way, I think most
> encoders are (or perhaps should be?) more interested in why something is
> italic than in the fact that it is italic.
>
> I agree with the point someone made earlier: the slight inconvenience of
> <hi rend="whatever"> is actually useful, because it makes us wonder why
> we're seeing this presentational feature, and perhaps pushes us in the
> direction of encoding it in some more meaningful way (<emph> or whatever).
>
> Cheers,
> Martin
>
> On 12-05-08 07:06 AM, Kevin Hawkins wrote:
>> No!
>>
>> We give people shortcut options like<name> and<bibl> instead of
>> forcing them to think too much by using<forename>,<surname>, and
>> <biblStruct> because we know that for certain envisioned uses of the
>> encoded document, these are perfectly sufficient. How do we know that
>> it's for someone's own good to distinguish various uses of italics?
>>
>> The situation we are in right now is as if the TEI had only:
>>
>> <forename>
>> <surname>
>> <rs type="name">
>>
>> but no:
>>
>> <name>
>>
>> (I understand the distinction Gabby made between semantic and
>> presentational sugar, but now I'm talking about straightforwardness of
>> encoding.)
>>
>> --K.
>>
>> On 5/8/2012 9:58 AM, Lou Burnard wrote:
>>> Exactly! and also to avoid thinking too much. Thought takes time and
>>> costs money.
>>>
>>> On 08/05/12 14:43, Gabriel BODARD wrote:
>>>> To save money on keystrokes, no?
>>>>
>>>> On 08/05/2012 13:52, Sebastian Rahtz wrote:
>>>>> We shouldn't forget that the Tite extra tags must come from
>>>>> _somewhere_,
>>>>> not just plucked at random from a fevered brain. Why did that group
>>>>> feel these
>>>>> were needed?
>>>>> --
>>>>> Sebastian Rahtz
>>>>> Head of Information and Support Group
>>>>> Oxford University Computing Services
>>>>> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>>>>>
>>>>> S?lo le pido a Dios
>>>>> que el futuro no me sea indiferente
>>>>>
>>>>
>>>
>

From mholmes at uvic.ca  Tue May  8 11:31:48 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Tue, 8 May 2012 08:31:48 -0700
Subject: [tei-council] TEI TITE question
In-Reply-To: <4FA9310E.60102@kcl.ac.uk>
References: <4FA660AE.3080907@oucs.ox.ac.uk>
	<012a76a2-c45a-4a92-8207-89917aa95067@HUB02.ad.oak.ox.ac.uk>
	<4FA67772.8010104@retired.ox.ac.uk>
	<8ec8c195-1428-4283-a7ba-a2ec89e2131f@HUB06.ad.oak.ox.ac.uk>
	<4FA9096E.4050103@kcl.ac.uk>
	<BACBD862-E8D4-4D18-967F-ACA528C093B4@oucs.ox.ac.uk>
	<4FA922F6.906@kcl.ac.uk>	<4FA92676.5070901@retired.ox.ac.uk>
	<4FA9285C.1020505@ultraslavonic.info>	<4FA92CCF.10104@kcl.ac.uk>
	<4FA92EF4.10708@ultraslavonic.info> <4FA9310E.60102@kcl.ac.uk>
Message-ID: <4FA93C64.8050102@uvic.ca>

Just a reminder that this suggestion is in conflict with an existing 
feature request:

<http://purl.org/TEI/FR/3519866>

As Sebastian says on that ticket, we're unlikely ever to reach a 
consensus on this; there's a large group of people already using @rend 
with CSS in it, and an equally large group of people who think that's 
abusive.

I think we need to recognize that:

  - Those who want to use @rend for CSS at the tag level (not through 
@rendition) need to be accommodated, either by loosening its data type 
or by the provision of another attribute for that purpose.

  - Those who still follow the traditional use of @rend by supplying 
data.word values for it also have a strong desire for a set of 
recommended values, to enhance interoperability.

  - The current situation is a bit of a mess, because nobody is 
particularly happy.

Cheers,
Martin

On 12-05-08 07:43 AM, Gabriel BODARD wrote:
> All of the below. If you want better interchangeability, then let's
> argue for a list of recommended values for @rend, rather than for adding
> yet one more way of doing this.
>
> I would support this argument.
>
> @rend (rendition) indicates how the element in question was rendered or
> presented in the source text.
> Status 	Optional
> Datatype 	1?? occurrences of data.word separated by whitespace
> Values 	may contain any number of tokens, each of which may contain
> letters, punctuation marks, or symbols, but not word-separating
> characters. Suggested values include:
> 	italic
> 	bold
> 	superscript
> 	subscript
> 	underline
> 	larger
> 	smaller
>
> This won't force anyone to do this, and it won't break backward
> compatibility or fix the mess that exists in old texts, but it will
> reduce the likelihood in future of values such as "italics", "i", "ii",
> "it", "ital", etc.
>
> G
>
> On 08/05/2012 15:34, Kevin Hawkins wrote:
>> On 5/8/2012 10:25 AM, Gabriel BODARD wrote:
>>> We already have a long-established way to encode the undistinguished use
>>> of italics, the only argument against which is that it's more keystrokes
>>> than<it>. We could easily encourage more consistency in attribute
>>> values if we really wanted to--though I predict there will be resistance
>>> to doing so.
>>
>> But what is this long-established way?  I can think of many (with
>> non-canonical practices marked with an asterisk):
>>
>> <hi rend="i">
>>
>> <hi rend="ii">
>>
>> <hi rend="ital">
>>
>> <hi rend="italic">
>>
>> <hi rend="italics">
>>
>> <hi rend="Kursiv">
>>
>> <hi rendition="#foo">   with<rendition xml:id="foo"
>> scheme="css">font-style: italic</rendition>
>>
>> <hi rendition="#foo">   with<rendition xml:id="foo" scheme="free">This
>> text is italicized.</rendition>
>>
>> *<hi rend="font-style: italic">
>>
>>> There is also a certain semantic value in the<hi>    element, by which I
>>> mean in its very name, not it's attribute values: this text is
>>> highlighted in some way to set it apart from the surrounding text. I can
>>> imagine a transcription scenario when all you want to encode is that the
>>> text is set apart, not how it is rendered.
>>
>> I agree with the value of<hi>   and do not think we should eliminate this
>> element.
>>
>>> My opinion remains that there is a place for elements such as<i>,<b>,
>>> <sup>, etc., but that that place is in a custom schema for
>>> encoders/vendors, not in the published, interchangeable TEI.
>>
>> But it would be enormously helpful if the TEI could promote interchange
>> of encoding of italics, bold, and other of the most common features in
>> printed source documents!
>

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From mholmes at uvic.ca  Tue May  8 12:03:45 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Tue, 8 May 2012 09:03:45 -0700
Subject: [tei-council] TEI TITE question
In-Reply-To: <4FA93C10.7060807@ultraslavonic.info>
References: <4FA660AE.3080907@oucs.ox.ac.uk>
	<012a76a2-c45a-4a92-8207-89917aa95067@HUB02.ad.oak.ox.ac.uk>
	<4FA67772.8010104@retired.ox.ac.uk>
	<8ec8c195-1428-4283-a7ba-a2ec89e2131f@HUB06.ad.oak.ox.ac.uk>
	<4FA9096E.4050103@kcl.ac.uk>
	<BACBD862-E8D4-4D18-967F-ACA528C093B4@oucs.ox.ac.uk>
	<4FA922F6.906@kcl.ac.uk>	<4FA92676.5070901@retired.ox.ac.uk>
	<4FA9285C.1020505@ultraslavonic.info> <4FA934CA.3090503@uvic.ca>
	<4FA93C10.7060807@ultraslavonic.info>
Message-ID: <4FA943E1.6050200@uvic.ca>

On 12-05-08 08:30 AM, Kevin Hawkins wrote:
> I know it sounds crazy, but I don't see how we can say that an encoder
> should be more interested in why something is in italics than in whether
> a name is a surname, patronymic, forename, etc.  It all depends on what
> you want to do with your digital text.  That statement from the gentle
> introduction is even prejudiced, frankly: it assumes certain uses of XML.

That wasn't what I was saying: my point was that we're typically more 
interested in what something _is_ (forename, surname, emphasis, book 
title) than in what it looks like (italics, bold, etc.). One of the 
reasons TEI XML is more useful than (say) RTF is that it can distinguish 
between a book title and emphasis, even though both are presented in 
italics.

That really does assume certain uses of XML, but I think they're the 
prototypical TEI uses, aren't they? Otherwise we might as well be using 
XHTML.

Cheers,
Martin

>
> On 5/8/2012 10:59 AM, Martin Holmes wrote:
>> I don't think I agree with this. As the Gentle Introduction to XML says,
>> "XML is more interested in the meaning of data than in its
>> presentation." We have lots of ways of encoding names because the
>> variety of name types and the subtle distinctions between them are
>> things that we're primarily interested in. In the same way, I think most
>> encoders are (or perhaps should be?) more interested in why something is
>> italic than in the fact that it is italic.
>>
>> I agree with the point someone made earlier: the slight inconvenience of
>> <hi rend="whatever">  is actually useful, because it makes us wonder why
>> we're seeing this presentational feature, and perhaps pushes us in the
>> direction of encoding it in some more meaningful way (<emph>  or whatever).
>>
>> Cheers,
>> Martin
>>
>> On 12-05-08 07:06 AM, Kevin Hawkins wrote:
>>> No!
>>>
>>> We give people shortcut options like<name>  and<bibl>  instead of
>>> forcing them to think too much by using<forename>,<surname>, and
>>> <biblStruct>  because we know that for certain envisioned uses of the
>>> encoded document, these are perfectly sufficient. How do we know that
>>> it's for someone's own good to distinguish various uses of italics?
>>>
>>> The situation we are in right now is as if the TEI had only:
>>>
>>> <forename>
>>> <surname>
>>> <rs type="name">
>>>
>>> but no:
>>>
>>> <name>
>>>
>>> (I understand the distinction Gabby made between semantic and
>>> presentational sugar, but now I'm talking about straightforwardness of
>>> encoding.)
>>>
>>> --K.
>>>
>>> On 5/8/2012 9:58 AM, Lou Burnard wrote:
>>>> Exactly! and also to avoid thinking too much. Thought takes time and
>>>> costs money.
>>>>
>>>> On 08/05/12 14:43, Gabriel BODARD wrote:
>>>>> To save money on keystrokes, no?
>>>>>
>>>>> On 08/05/2012 13:52, Sebastian Rahtz wrote:
>>>>>> We shouldn't forget that the Tite extra tags must come from
>>>>>> _somewhere_,
>>>>>> not just plucked at random from a fevered brain. Why did that group
>>>>>> feel these
>>>>>> were needed?
>>>>>> --
>>>>>> Sebastian Rahtz
>>>>>> Head of Information and Support Group
>>>>>> Oxford University Computing Services
>>>>>> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>>>>>>
>>>>>> S?lo le pido a Dios
>>>>>> que el futuro no me sea indiferente
>>>>>>
>>>>>
>>>>
>>

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From bansp at o2.pl  Tue May  8 12:27:14 2012
From: bansp at o2.pl (=?ISO-8859-2?Q?Piotr_Ba=F1ski?=)
Date: Tue, 08 May 2012 18:27:14 +0200
Subject: [tei-council] TEI TITE question
In-Reply-To: <4FA931E6.2010304@ultraslavonic.info>
References: <4FA660AE.3080907@oucs.ox.ac.uk>	<012a76a2-c45a-4a92-8207-89917aa95067@HUB02.ad.oak.ox.ac.uk>	<4FA67772.8010104@retired.ox.ac.uk>	<8ec8c195-1428-4283-a7ba-a2ec89e2131f@HUB06.ad.oak.ox.ac.uk>	<4FA9096E.4050103@kcl.ac.uk>	<BACBD862-E8D4-4D18-967F-ACA528C093B4@oucs.ox.ac.uk>	<4FA922F6.906@kcl.ac.uk>	<4FA92676.5070901@retired.ox.ac.uk>	<4FA9285C.1020505@ultraslavonic.info>
	<4FA92CCF.10104@kcl.ac.uk> <4FA93049.9030703@o2.pl>
	<4FA931E6.2010304@ultraslavonic.info>
Message-ID: <4FA94962.8000109@o2.pl>

On 08/05/12 16:47, Kevin Hawkins wrote:
> Wait, now we're talking about mapping between various XML schemes, each 
> of which represent italics.  This is a different matter.

I guess I want to say that it's part of the same picture, actually.

> My point is that we should offer a clear way to represent 
> undifferentiated italicized text in TEI.  Right now, "<hi>" is not a 
> clear way to do this.

Just italicized or also bold, small caps, etc.?

The TEI has a great customization mechanism. We're talking about one
customization. Why should we want to create a rule out of this specific
customization is what escapes me. Titefication of the TEI... but why?
One argument I saw it that it's handier. Well, it depends, that's what
customizations are supposed to be for, among others: if you want to make
things handier for one particular project, customize rather than adjust
the entire system for that one project. We call this, in Polish,
"turning the cat tail-first". It just seems to go the wrong way.

Another argument that I saw, from Sebastian, mentioned that <sub> is
non-semantic. I am not sure what "being semantic" means in this context,
I feel that some assumed common ground escapes me (and I'm slightly
embarrassed about that).

But your argument, Kevin, I just don't grok, especially that you invoke
interchange by suggesting making interchange harder, i.e. by adding to
the potential mess of the content of @rend and the @rend vs. @rendition
mechanism, one more mechanism, of using an element for that, an element
which belongs on the "leaf", i.e., I would think, in a customization,
rather than in the core of the system.

best,

  P.


> On 5/8/2012 10:40 AM, Piotr Ba?ski wrote:
>> It seems to me that<i>,<it>,<ital>  and friends are on the leaves of
>> interoperability -- they are what often has to be aligned between
>> formats. In the trunk, or pivot, sits the<hi>  element, with a multitude
>> of ways of describing it further, if necessary (even including a pointer
>> to an external reference system that defines "italic"). This is the rich
>> core through which the flow of interoperability should be directed. Add
>> <i>  to<hi>  and the result is an increase, instead of decrease, of
>> messiness. It opens the way for all the other HTML 3.2 stuff.
>>
>>    P.


From bansp at o2.pl  Tue May  8 12:41:13 2012
From: bansp at o2.pl (=?ISO-8859-2?Q?Piotr_Ba=F1ski?=)
Date: Tue, 08 May 2012 18:41:13 +0200
Subject: [tei-council] TEI TITE question
In-Reply-To: <4FA943E1.6050200@uvic.ca>
References: <4FA660AE.3080907@oucs.ox.ac.uk>
	<012a76a2-c45a-4a92-8207-89917aa95067@HUB02.ad.oak.ox.ac.uk>
	<4FA67772.8010104@retired.ox.ac.uk>
	<8ec8c195-1428-4283-a7ba-a2ec89e2131f@HUB06.ad.oak.ox.ac.uk>
	<4FA9096E.4050103@kcl.ac.uk>
	<BACBD862-E8D4-4D18-967F-ACA528C093B4@oucs.ox.ac.uk>
	<4FA922F6.906@kcl.ac.uk>	<4FA92676.5070901@retired.ox.ac.uk>
	<4FA9285C.1020505@ultraslavonic.info> <4FA934CA.3090503@uvic.ca>
	<4FA93C10.7060807@ultraslavonic.info> <4FA943E1.6050200@uvic.ca>
Message-ID: <4FA94CA9.7050105@o2.pl>

On 08/05/12 18:03, Martin Holmes wrote:
> On 12-05-08 08:30 AM, Kevin Hawkins wrote:
>> I know it sounds crazy, but I don't see how we can say that an encoder
>> should be more interested in why something is in italics than in whether
>> a name is a surname, patronymic, forename, etc.  It all depends on what
>> you want to do with your digital text.  That statement from the gentle
>> introduction is even prejudiced, frankly: it assumes certain uses of XML.
> 
> That wasn't what I was saying: my point was that we're typically more 
> interested in what something _is_ (forename, surname, emphasis, book 
> title) than in what it looks like (italics, bold, etc.). One of the 
> reasons TEI XML is more useful than (say) RTF is that it can distinguish 
> between a book title and emphasis, even though both are presented in 
> italics.
> 
> That really does assume certain uses of XML, but I think they're the 
> prototypical TEI uses, aren't they? Otherwise we might as well be using 
> XHTML.

That's my sentiment as well, that's why I said earlier that going in
this direction may make us want to rewrite some of the justification for
the TEI's existence, because I'm not sure if it will still be valid.

  P.

From sebastian.rahtz at oucs.ox.ac.uk  Tue May  8 12:43:25 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Tue, 8 May 2012 16:43:25 +0000
Subject: [tei-council] TEI TITE question
In-Reply-To: <4FA93C64.8050102@uvic.ca>
References: <4FA660AE.3080907@oucs.ox.ac.uk>
	<012a76a2-c45a-4a92-8207-89917aa95067@HUB02.ad.oak.ox.ac.uk>
	<4FA67772.8010104@retired.ox.ac.uk>
	<8ec8c195-1428-4283-a7ba-a2ec89e2131f@HUB06.ad.oak.ox.ac.uk>
	<4FA9096E.4050103@kcl.ac.uk>
	<BACBD862-E8D4-4D18-967F-ACA528C093B4@oucs.ox.ac.uk>
	<4FA922F6.906@kcl.ac.uk>	<4FA92676.5070901@retired.ox.ac.uk>
	<4FA9285C.1020505@ultraslavonic.info>	<4FA92CCF.10104@kcl.ac.uk>
	<4FA92EF4.10708@ultraslavonic.info> <4FA9310E.60102@kcl.ac.uk>
	<4FA93C64.8050102@uvic.ca>
Message-ID: <94E37A2E-F70E-4AAF-8ABA-9E036E425638@oucs.ox.ac.uk>


On 8 May 2012, at 16:31, Martin Holmes wrote:

> Just a reminder that this suggestion is in conflict with an existing 
> feature request:
> 
> <http://purl.org/TEI/FR/3519866>
> 
yes, please can some more people comment on that?

> I think we need to recognize that:
> 
>  - Those who want to use @rend for CSS at the tag level (not through 
> @rendition) need to be accommodated, either by loosening its data type 
> or by the provision of another attribute for that purpose.
> 
>  - Those who still follow the traditional use of @rend by supplying 
> data.word values for it also have a strong desire for a set of 
> recommended values, to enhance interoperability.
> 
>  - The current situation is a bit of a mess, because nobody is 
> particularly happy.

"amen" to all of those points. Its not at all clear how to proceed,
because we just each reiterate the same arguments over and over again.
Lou may tell us that "it was always so", or alternatively that back in
the Golden Age they had no patience with any sort of descriptive markup ?..


--
Sebastian Rahtz      
Head of Information and Support Group
Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431

S?lo le pido a Dios
que el futuro no me sea indiferente


From gabriel.bodard at kcl.ac.uk  Tue May  8 13:29:46 2012
From: gabriel.bodard at kcl.ac.uk (Gabriel BODARD)
Date: Tue, 8 May 2012 18:29:46 +0100
Subject: [tei-council] TEI TITE question
In-Reply-To: <94E37A2E-F70E-4AAF-8ABA-9E036E425638@oucs.ox.ac.uk>
References: <4FA660AE.3080907@oucs.ox.ac.uk>
	<012a76a2-c45a-4a92-8207-89917aa95067@HUB02.ad.oak.ox.ac.uk>
	<4FA67772.8010104@retired.ox.ac.uk>
	<8ec8c195-1428-4283-a7ba-a2ec89e2131f@HUB06.ad.oak.ox.ac.uk>
	<4FA9096E.4050103@kcl.ac.uk>
	<BACBD862-E8D4-4D18-967F-ACA528C093B4@oucs.ox.ac.uk>
	<4FA922F6.906@kcl.ac.uk>	<4FA92676.5070901@retired.ox.ac.uk>
	<4FA9285C.1020505@ultraslavonic.info>	<4FA92CCF.10104@kcl.ac.uk>
	<4FA92EF4.10708@ultraslavonic.info> <4FA9310E.60102@kcl.ac.uk>
	<4FA93C64.8050102@uvic.ca>
	<94E37A2E-F70E-4AAF-8ABA-9E036E425638@oucs.ox.ac.uk>
Message-ID: <4FA9580A.5080100@kcl.ac.uk>

I've just commented. (Disclaimer--I'm not on TEI-L these days, so I 
missed whatever discussion there was there.)

I think the answer to that ticket must be very much tied up with what 
we're discussing here (obviously).

(May I also put in a plea for James not to be so coy, and to summarise 
his arguments against on the ticket, because almost no one is going to 
click through to two blog posts from Sourceforge! I didn't. ;-) )

G

On 08/05/2012 17:43, Sebastian Rahtz wrote:
>
> On 8 May 2012, at 16:31, Martin Holmes wrote:
>
>> Just a reminder that this suggestion is in conflict with an existing
>> feature request:
>>
>> <http://purl.org/TEI/FR/3519866>
>>
> yes, please can some more people comment on that?
>
>> I think we need to recognize that:
>>
>>   - Those who want to use @rend for CSS at the tag level (not through
>> @rendition) need to be accommodated, either by loosening its data type
>> or by the provision of another attribute for that purpose.
>>
>>   - Those who still follow the traditional use of @rend by supplying
>> data.word values for it also have a strong desire for a set of
>> recommended values, to enhance interoperability.
>>
>>   - The current situation is a bit of a mess, because nobody is
>> particularly happy.
>
> "amen" to all of those points. Its not at all clear how to proceed,
> because we just each reiterate the same arguments over and over again.
> Lou may tell us that "it was always so", or alternatively that back in
> the Golden Age they had no patience with any sort of descriptive markup ?..
>
>
> --
> Sebastian Rahtz
> Head of Information and Support Group
> Oxford University Computing Services
> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>
> S?lo le pido a Dios
> que el futuro no me sea indiferente
>

-- 
Dr Gabriel BODARD
(Research Associate in Digital Epigraphy)

Department of Digital Humanities
King's College London
26-29 Drury Lane
London WC2B 5RL

Email: gabriel.bodard at kcl.ac.uk
Tel: +44 (0)20 7848 1388
Fax: +44 (0)20 7848 2980

http://www.digitalclassicist.org/
http://www.currentepigraphy.org/

From kevin.s.hawkins at ultraslavonic.info  Tue May  8 13:38:24 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Tue, 08 May 2012 13:38:24 -0400
Subject: [tei-council] TEI TITE question
In-Reply-To: <4FA94962.8000109@o2.pl>
References: <4FA660AE.3080907@oucs.ox.ac.uk>	<012a76a2-c45a-4a92-8207-89917aa95067@HUB02.ad.oak.ox.ac.uk>	<4FA67772.8010104@retired.ox.ac.uk>	<8ec8c195-1428-4283-a7ba-a2ec89e2131f@HUB06.ad.oak.ox.ac.uk>	<4FA9096E.4050103@kcl.ac.uk>	<BACBD862-E8D4-4D18-967F-ACA528C093B4@oucs.ox.ac.uk>	<4FA922F6.906@kcl.ac.uk>	<4FA92676.5070901@retired.ox.ac.uk>	<4FA9285C.1020505@ultraslavonic.info>	<4FA92CCF.10104@kcl.ac.uk>
	<4FA93049.9030703@o2.pl>	<4FA931E6.2010304@ultraslavonic.info>
	<4FA94962.8000109@o2.pl>
Message-ID: <4FA95A10.1090105@ultraslavonic.info>

On various points ...

On 5/8/2012 12:27 PM, Piotr Ba?ski wrote:
> But your argument, Kevin, I just don't grok, especially that you invoke
> interchange by suggesting making interchange harder, i.e. by adding to
> the potential mess of the content of @rend and the @rend vs. @rendition
> mechanism, one more mechanism, of using an element for that, an element
> which belongs on the "leaf", i.e., I would think, in a customization,
> rather than in the core of the system.

If we added <i> and then added a note to the definition of <hi> saying 
that it's equivalent to <hi rend="i"> (or <hi type="i">!), I would be 
happy because people who want to do undifferentiated italics would 
almost certainly choose <i> in this case, and our interchange problems 
(and stylesheet-writing problems!) would be mitigated.  I think this 
would be clearer than our current situation, in which there's no clear 
interchangeable solution for undifferentiated italics.

More below ...

On 5/8/2012 12:41 PM, Piotr Ba?ski wrote:
 > On 08/05/12 18:03, Martin Holmes wrote:

[. . .]

 >> That really does assume certain uses of XML, but I think they're the
 >> prototypical TEI uses, aren't they? Otherwise we might as well be using
 >> XHTML.
 >
 > That's my sentiment as well, that's why I said earlier that going in
 > this direction may make us want to rewrite some of the justification for
 > the TEI's existence, because I'm not sure if it will still be valid.

We all share a common understanding for why use TEI and not HTML, but 
when you look at the Guidelines, it never explains in what cases you 
should just use HTML.  So while I agree that you might as well use HTML 
if you're just going to use <hi rend="___"> everywhere, I think we 
should either articulate this in "About the Guidelines", or we should 
provide clearer ways to encode italics, bold, etc. in TEI.

--K.

From PFSchaffner at umich.edu  Tue May  8 14:07:37 2012
From: PFSchaffner at umich.edu (Paul F. Schaffner)
Date: Tue, 8 May 2012 14:07:37 -0400 (EDT)
Subject: [tei-council] TEI TITE question
In-Reply-To: <4FA95A10.1090105@ultraslavonic.info>
References: <4FA660AE.3080907@oucs.ox.ac.uk>
	<012a76a2-c45a-4a92-8207-89917aa95067@HUB02.ad.oak.ox.ac.uk>
	<4FA67772.8010104@retired.ox.ac.uk>
	<8ec8c195-1428-4283-a7ba-a2ec89e2131f@HUB06.ad.oak.ox.ac.uk>
	<4FA9096E.4050103@kcl.ac.uk>
	<BACBD862-E8D4-4D18-967F-ACA528C093B4@oucs.ox.ac.uk>
	<4FA922F6.906@kcl.ac.uk> <4FA92676.5070901@retired.ox.ac.uk>
	<4FA9285C.1020505@ultraslavonic.info> <4FA92CCF.10104@kcl.ac.uk>
	<4FA93049.9030703@o2.pl> <4FA931E6.2010304@ultraslavonic.info>
	<4FA94962.8000109@o2.pl> <4FA95A10.1090105@ultraslavonic.info>
Message-ID: <Pine.LNX.4.64.1205081339400.14534@joust.gpcc.itd.umich.edu>

On Tue, 8 May 2012, Kevin Hawkins wrote:

> If we added <i> and then added a note to the definition of <hi> saying
> that it's equivalent to <hi rend="i"> (or <hi type="i">!), I would be
> happy because people who want to do undifferentiated italics would
> almost certainly choose <i> in this case, and our interchange problems
> (and stylesheet-writing problems!) would be mitigated.

A doltish side-question: why does this discussion assume that <i>
is equivalent to <hi rend="italic"> rather than to <seg rend="italic">?
I should have thought that using <hi> was at least a little abusive,
if all you want to do is record the fact that something is in
italics and avoid taking responsibility for saying why.

  <closer>
  <dateline><i>Pera</i> <r>18.</r> <i>Octob.</i> <r>1647.</r></dateline>
  <signed><r>Your friend to serve you,</r> <i>Tho. Bendish</i></signed>
  <signed><i>Vera Copia Examinatur &amp; concordat eum original.
  per nos.</i> <r>Jo. Williams, Ant. Isaacson.</r></signed>
  <closer>

pfs
--------------------------------------------------------------------
Paul Schaffner | PFSchaffner at umich.edu | http://www.umich.edu/~pfs/
316-C Hatcher Library N, Univ. of Michigan, Ann Arbor MI 48109-1190
--------------------------------------------------------------------

From James.Cummings at oucs.ox.ac.uk  Tue May  8 18:28:13 2012
From: James.Cummings at oucs.ox.ac.uk (James Cummings)
Date: Tue, 08 May 2012 23:28:13 +0100
Subject: [tei-council] TEI TITE question
In-Reply-To: <4FA9580A.5080100@kcl.ac.uk>
References: <4FA660AE.3080907@oucs.ox.ac.uk>	<012a76a2-c45a-4a92-8207-89917aa95067@HUB02.ad.oak.ox.ac.uk>	<4FA67772.8010104@retired.ox.ac.uk>	<8ec8c195-1428-4283-a7ba-a2ec89e2131f@HUB06.ad.oak.ox.ac.uk>	<4FA9096E.4050103@kcl.ac.uk>	<BACBD862-E8D4-4D18-967F-ACA528C093B4@oucs.ox.ac.uk>	<4FA922F6.906@kcl.ac.uk>	<4FA92676.5070901@retired.ox.ac.uk>	<4FA9285C.1020505@ultraslavonic.info>	<4FA92CCF.10104@kcl.ac.uk>	<4FA92EF4.10708@ultraslavonic.info>
	<4FA9310E.60102@kcl.ac.uk>	<4FA93C64.8050102@uvic.ca>	<94E37A2E-F70E-4AAF-8ABA-9E036E425638@oucs.ox.ac.uk>
	<4FA9580A.5080100@kcl.ac.uk>
Message-ID: <4FA99DFD.5030404@oucs.ox.ac.uk>

On 08/05/12 18:29, Gabriel BODARD wrote:
> (May I also put in a plea for James not to be so coy, and to summarise
> his arguments against on the ticket, because almost no one is going to
> click through to two blog posts from Sourceforge! I didn't. ;-) )

re: @rend ticket; Will do. (I'm for data.word use, but open to a 
suggested valList)

Lots of back and forth today on Tite, seemingly with no clear 
consensus.

I'm still of the opinion that using things like <b> and <i> are 
perfectly reasonable TEI Conformable customisations of the TEI. 
I did a TEI Corset customisation of the TEI for a project 
recently which was byte-reduced (because keying company was 
charging per kilobyte produced...weirdoes). Almost all 
elements/attributes/values were single letters. I've not seen any 
clear argument why such customisations need to be in TEI itself 
rather than just as a data-entry or data-generation schema prior 
to automatic conversion back to full TEI.

I had keyers do something like:

<d t="e"><h>Heading</h><p>And then here was <n>Mr smith</n></p></d>

and convert it back to full TEI.  The point is that it is a 
customisation with use of <equiv>, not a different schema.


-James

-- 
Dr James Cummings, InfoDev
Oxford University Computing Services
University of Oxford

From James.Cummings at oucs.ox.ac.uk  Tue May  8 18:33:40 2012
From: James.Cummings at oucs.ox.ac.uk (James Cummings)
Date: Tue, 08 May 2012 23:33:40 +0100
Subject: [tei-council] Possible September Meeting Dates
Message-ID: <4FA99F44.7060306@oucs.ox.ac.uk>


Looking at possible dates for an Autumn meeting, there are 
potential benefits in having our meeting just before or just 
after the EEBO-TCP Conference that will be happening in Oxford 
September 17-18. (e.g. I'm assuming that this might be easier for 
Becky and/or Paul??)

But the question is whether to have it before, say Weds 12 - Fri 
14 September, or after, say Weds 19 - Fri 21 September.

I'm slightly in favour of the latter, but instead of answering 
here, answer on a quick doodle poll:

http://www.doodle.com/csectyt4agcm58te

Fill in your name and which dates you can make.  If you think 
both dates are wrong then mark 'yes' in the third column and 
leave a comment at the bottom.

-James

-- 
Dr James Cummings, InfoDev
Oxford University Computing Services
University of Oxford

From sebastian.rahtz at oucs.ox.ac.uk  Wed May  9 04:55:56 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Wed, 9 May 2012 08:55:56 +0000
Subject: [tei-council] content model of <surface>
Message-ID: <B1268321-D450-474B-ACCE-63BD34E7E480@oucs.ox.ac.uk>

I am mildly horrified to see that we have got ourselves a non-deterministic content
model in here at some point, which has not been checked for (but will from now on)

If you look at this:

<content>
    <rng:group>
      <rng:zeroOrMore>
        <rng:ref name="model.glossLike"/>
      </rng:zeroOrMore>
      <rng:zeroOrMore>
        <rng:ref name="model.graphicLike"/>
      </rng:zeroOrMore>
      <rng:zeroOrMore>
	<rng:choice>
	  <rng:ref name="model.global"/>
	  <rng:ref name="zone"/>
	  <rng:ref name="line"/>
	  <rng:ref name="surface"/>
	  <rng:ref name="surfaceGrp"/>
	</rng:choice>
      </rng:zeroOrMore>
    </rng:group>
  </content>


you will realize that if <certainty> occurs as the only child  <surface>, it is a member of model.global (via model.global.meta) and of
model.glossLike (via model.cerLike), and thus we don't know where it came from (them's the rules of determinism).

I'd be interested to hear of a nice clean solution to this.... 

I suppose someone does know why we want <surface> to allow children of (eg) <pb/>?

Sebastian

From lou.burnard at retired.ox.ac.uk  Wed May  9 05:01:07 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Wed, 09 May 2012 10:01:07 +0100
Subject: [tei-council] content model of <surface>
In-Reply-To: <B1268321-D450-474B-ACCE-63BD34E7E480@oucs.ox.ac.uk>
References: <B1268321-D450-474B-ACCE-63BD34E7E480@oucs.ox.ac.uk>
Message-ID: <4FAA3253.3080105@retired.ox.ac.uk>

On 09/05/12 09:55, Sebastian Rahtz wrote:
>
> I suppose someone does know why we want<surface>  to allow children of (eg)<pb/>?
>

Cf earlier discussion about <signed>

Could remove model.global as top level content of <surface> I suppose. 
This would mean you'd need to define at least one zone.

From sebastian.rahtz at oucs.ox.ac.uk  Wed May  9 05:09:55 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Wed, 9 May 2012 09:09:55 +0000
Subject: [tei-council] content model of <surface>
In-Reply-To: <4FAA3253.3080105@retired.ox.ac.uk>
References: <B1268321-D450-474B-ACCE-63BD34E7E480@oucs.ox.ac.uk>
	<4FAA3253.3080105@retired.ox.ac.uk>
Message-ID: <7bb63c34-d91c-4a1c-b0fe-5b88443ebf63@HUB06.ad.oak.ox.ac.uk>


On 9 May 2012, at 10:01, Lou Burnard wrote:

> On 09/05/12 09:55, Sebastian Rahtz wrote:
>> 
>> I suppose someone does know why we want<surface>  to allow children of (eg)<pb/>?
>> 
> 
> Cf earlier discussion about <signed>
> 
> Could remove model.global as top level content of <surface> I suppose. 
> This would mean you'd need to define at least one zone.

I am thinking of shifting to this:

  <content>
    <group xmlns="http://relaxng.org/ns/structure/1.0" >
      <zeroOrMore>
        <ref name="model.glossLike"/>
      </zeroOrMore>
      <zeroOrMore>
        <ref name="model.graphicLike"/>
      </zeroOrMore>
      <zeroOrMore>
	<group>
	  <choice>
	    <ref name="zone"/>
	    <ref name="line"/>
	    <ref name="surface"/>
	    <ref name="surfaceGrp"/>
	  </choice>
	</group>
	<zeroOrMore>
	  <ref name="model.global"/>
	</zeroOrMore>
      </zeroOrMore>
    </group>
  </content>

what this would fail on is

   <surface>
     <graphic>
     <pb>
     <zone>
  </surface>

is that acceptable? 

Sebastian


From lou.burnard at retired.ox.ac.uk  Wed May  9 05:15:39 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Wed, 09 May 2012 10:15:39 +0100
Subject: [tei-council] content model of <surface>
In-Reply-To: <FD76B0BD-C29D-4865-A39B-C501839B81EC@oucs.ox.ac.uk>
References: <B1268321-D450-474B-ACCE-63BD34E7E480@oucs.ox.ac.uk>
	<4FAA3253.3080105@retired.ox.ac.uk>
	<FD76B0BD-C29D-4865-A39B-C501839B81EC@oucs.ox.ac.uk>
Message-ID: <4FAA35BB.5020006@retired.ox.ac.uk>

On 09/05/12 10:09, Sebastian Rahtz wrote:
>
> On 9 May 2012, at 10:01, Lou Burnard wrote:
>
>> On 09/05/12 09:55, Sebastian Rahtz wrote:
>>>
>>> I suppose someone does know why we want<surface>   to allow children of (eg)<pb/>?
>>>
>>
>> Cf earlier discussion about<signed>
>>
>> Could remove model.global as top level content of<surface>  I suppose.
>> This would mean you'd need to define at least one zone.
>
> I am thinking of shifting to this:
>
>    <content>
>      <group xmlns="http://relaxng.org/ns/structure/1.0">
>        <zeroOrMore>
>          <ref name="model.glossLike"/>
>        </zeroOrMore>
>        <zeroOrMore>
>          <ref name="model.graphicLike"/>
>        </zeroOrMore>
>        <zeroOrMore>
> 	<group>
> 	<choice>
> 	<ref name="zone"/>
> 	<ref name="line"/>
> 	<ref name="surface"/>
> 	<ref name="surfaceGrp"/>
> 	</choice>
> 	</group>
> 	<zeroOrMore>
> 	<ref name="model.global"/>
> 	</zeroOrMore>
>        </zeroOrMore>
>      </group>
>    </content>
>
>
>
>

Looks still non deterministic to me. If you have 
<surface><lb/></surface> which bit of the model is being matched?

b

From sebastian.rahtz at oucs.ox.ac.uk  Wed May  9 05:29:48 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Wed, 9 May 2012 09:29:48 +0000
Subject: [tei-council] content model of <surface>
In-Reply-To: <4FAA35BB.5020006@retired.ox.ac.uk>
References: <B1268321-D450-474B-ACCE-63BD34E7E480@oucs.ox.ac.uk>
	<4FAA3253.3080105@retired.ox.ac.uk>
	<FD76B0BD-C29D-4865-A39B-C501839B81EC@oucs.ox.ac.uk>
	<4FAA35BB.5020006@retired.ox.ac.uk>
Message-ID: <735aa694-17bf-45d1-a2a8-5b267c3f9904@HUB02.ad.oak.ox.ac.uk>

On 9 May 2012, at 10:15, Lou Burnard wrote:
> 
> Looks still non deterministic to me. If you have <surface><lb/></surface> which bit of the model is being matched?

the point is that once you enter the second half of the model, things from model.global
only occur after we have had at least one example of zone/line/surface/surfaceGrp

its the same technique used in div and postscript. 

is the intention that a <surface> must first get out of the way any graphics and glosslike elements, and
then get on with its main business?

if that main business can _start_ with anything from model.global, then we are screwed, cos
<certainty> comes in both the preliminary matter (glosslike) and the main matter (global), and
non-determinism fires.

the answer, of course, is to promiscuously interleave graphic and glosslike in the preliminary matter,
so I'm going to implement that. 

scream loudly if
  a) you have the faintest idea what I am talking about
  b) you care one jot about whether its important that all the glossLike children of <surface>
occur before  all the graphicLike children.

Trust me, I'm in the zone on this one.

Sebastian


From lou.burnard at retired.ox.ac.uk  Wed May  9 05:33:23 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Wed, 09 May 2012 10:33:23 +0100
Subject: [tei-council] content model of <surface>
In-Reply-To: <AD45501E-02E2-435B-B9B3-2FA38955C44D@oucs.ox.ac.uk>
References: <B1268321-D450-474B-ACCE-63BD34E7E480@oucs.ox.ac.uk>
	<4FAA3253.3080105@retired.ox.ac.uk>
	<FD76B0BD-C29D-4865-A39B-C501839B81EC@oucs.ox.ac.uk>
	<4FAA35BB.5020006@retired.ox.ac.uk>
	<AD45501E-02E2-435B-B9B3-2FA38955C44D@oucs.ox.ac.uk>
Message-ID: <4FAA39E3.7060802@retired.ox.ac.uk>

The reqsons it is this way is because the wg expressed the (admittedly 
rather vague) desire that old skool <surface> (for digital facsimile) 
and new skool (for genetic flummery) should have only limited co-existence.

My vote would be to do the P4 thing -- i.e. just alternate the whole lot 
and sort out any nonsense that surfaces later with schematron rules.


On 09/05/12 10:29, Sebastian Rahtz wrote:
> On 9 May 2012, at 10:15, Lou Burnard wrote:
>>
>> Looks still non deterministic to me. If you have<surface><lb/></surface>  which bit of the model is being matched?
>
> the point is that once you enter the second half of the model, things from model.global
> only occur after we have had at least one example of zone/line/surface/surfaceGrp
>
> its the same technique used in div and postscript.
>
> is the intention that a<surface>  must first get out of the way any graphics and glosslike elements, and
> then get on with its main business?
>
> if that main business can _start_ with anything from model.global, then we are screwed, cos
> <certainty>  comes in both the preliminary matter (glosslike) and the main matter (global), and
> non-determinism fires.
>
> the answer, of course, is to promiscuously interleave graphic and glosslike in the preliminary matter,
> so I'm going to implement that.
>
> scream loudly if
>    a) you have the faintest idea what I am talking about
>    b) you care one jot about whether its important that all the glossLike children of<surface>
> occur before  all the graphicLike children.
>
> Trust me, I'm in the zone on this one.
>
> Sebastian
>


From sebastian.rahtz at oucs.ox.ac.uk  Wed May  9 06:11:25 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Wed, 9 May 2012 10:11:25 +0000
Subject: [tei-council] content model of <surface>
In-Reply-To: <4FAA39E3.7060802@retired.ox.ac.uk>
References: <B1268321-D450-474B-ACCE-63BD34E7E480@oucs.ox.ac.uk>
	<4FAA3253.3080105@retired.ox.ac.uk>
	<FD76B0BD-C29D-4865-A39B-C501839B81EC@oucs.ox.ac.uk>
	<4FAA35BB.5020006@retired.ox.ac.uk>
	<AD45501E-02E2-435B-B9B3-2FA38955C44D@oucs.ox.ac.uk>
	<4FAA39E3.7060802@retired.ox.ac.uk>
Message-ID: <f02910c5-038b-44c6-9a3c-9d2277ab55df@HUB01.ad.oak.ox.ac.uk>


On 9 May 2012, at 10:33, Lou Burnard wrote:

> The reqsons it is this way is because the wg expressed the (admittedly rather vague) desire that old skool <surface> (for digital facsimile) and new skool (for genetic flummery) should have only limited co-existence.
> 
I think, then, that my solution fits their criteria. It fails to validate real examples, unfortunately.

Sebastian


From lou.burnard at retired.ox.ac.uk  Wed May  9 06:37:29 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Wed, 09 May 2012 11:37:29 +0100
Subject: [tei-council] content model of <surface>
In-Reply-To: <B9306827-267B-4714-8355-382033EDE2B0@oucs.ox.ac.uk>
References: <B1268321-D450-474B-ACCE-63BD34E7E480@oucs.ox.ac.uk>
	<4FAA3253.3080105@retired.ox.ac.uk>
	<FD76B0BD-C29D-4865-A39B-C501839B81EC@oucs.ox.ac.uk>
	<4FAA35BB.5020006@retired.ox.ac.uk>
	<AD45501E-02E2-435B-B9B3-2FA38955C44D@oucs.ox.ac.uk>
	<4FAA39E3.7060802@retired.ox.ac.uk>
	<B9306827-267B-4714-8355-382033EDE2B0@oucs.ox.ac.uk>
Message-ID: <4FAA48E9.50006@retired.ox.ac.uk>

On 09/05/12 11:11, Sebastian Rahtz wrote:
>
> On 9 May 2012, at 10:33, Lou Burnard wrote:
>
>> The reqsons it is this way is because the wg expressed the (admittedly rather vague) desire that old skool<surface>  (for digital facsimile) and new skool (for genetic flummery) should have only limited co-existence.
>>
> I think, then, that my solution fits their criteria. It fails to validate real examples, unfortunately.
>
>

Even with your recent adjustment, the model is arguably too complex. 
Remember that at some point in the future when we've forgotten why we 
did this, someone will have to explain it.
n

From sebastian.rahtz at oucs.ox.ac.uk  Wed May  9 06:41:00 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Wed, 9 May 2012 10:41:00 +0000
Subject: [tei-council] content model of <surface>
In-Reply-To: <f02910c5-038b-44c6-9a3c-9d2277ab55df@HUB01.ad.oak.ox.ac.uk>
References: <B1268321-D450-474B-ACCE-63BD34E7E480@oucs.ox.ac.uk>
	<4FAA3253.3080105@retired.ox.ac.uk>
	<FD76B0BD-C29D-4865-A39B-C501839B81EC@oucs.ox.ac.uk>
	<4FAA35BB.5020006@retired.ox.ac.uk>
	<AD45501E-02E2-435B-B9B3-2FA38955C44D@oucs.ox.ac.uk>
	<4FAA39E3.7060802@retired.ox.ac.uk>
	<f02910c5-038b-44c6-9a3c-9d2277ab55df@HUB01.ad.oak.ox.ac.uk>
Message-ID: <53F251F5-1979-49FB-94E4-34A6B746D1DC@oucs.ox.ac.uk>

In order to give <surface> a cats chance of hell of getting a deterministic content model,
I have changed it to be:
 
    <zeroOrMore>
	<choice>
	  <ref name="model.global"/>
	  <ref name="model.labelLike"/>
	  <ref name="model.graphicLike"/>
	</choice>
      </zeroOrMore>
      <zeroOrMore>
	<group>
	  <choice>
	    <ref name="zone"/>
	    <ref name="line"/>
	    <ref name="surface"/>
	    <ref name="surfaceGrp"/>
	  </choice>
	</group>
	<zeroOrMore>
	  <ref name="model.global"/>
	</zeroOrMore>
      </zeroOrMore>

where the change is that it no longer allows all of model.glossLike, only
model.labelLike at the start. This means we allow <label> where it was not allowed
before, and lose <altIdent>, <equiv> and <gloss>. 

So surface now allows a pretty promiscuous set of zone/line/surface/surfaceGrp + model.global (which includes
the certainly elements), but if you want <desc> or <graphic>, they must precede any of the zones or lines or
sub-surfaces.

I claim this is what the geneticists want.


PS why did all this come up, you ask? because I noticed that "testall" (== tei_all) had
been omitted from the normal test regime, and when I put it back  this non-determinism
revealed itself.


Sebastian


From sebastian.rahtz at oucs.ox.ac.uk  Wed May  9 06:42:29 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Wed, 9 May 2012 10:42:29 +0000
Subject: [tei-council] content model of <surface>
In-Reply-To: <4FAA48E9.50006@retired.ox.ac.uk>
References: <B1268321-D450-474B-ACCE-63BD34E7E480@oucs.ox.ac.uk>
	<4FAA3253.3080105@retired.ox.ac.uk>
	<FD76B0BD-C29D-4865-A39B-C501839B81EC@oucs.ox.ac.uk>
	<4FAA35BB.5020006@retired.ox.ac.uk>
	<AD45501E-02E2-435B-B9B3-2FA38955C44D@oucs.ox.ac.uk>
	<4FAA39E3.7060802@retired.ox.ac.uk>
	<B9306827-267B-4714-8355-382033EDE2B0@oucs.ox.ac.uk>
	<4FAA48E9.50006@retired.ox.ac.uk>
Message-ID: <852c3162-b6b1-47a5-9861-d9380ab14121@HUB03.ad.oak.ox.ac.uk>


On 9 May 2012, at 11:37, Lou Burnard wrote:

> 
> Even with your recent adjustment, the model is arguably too complex.
yes, I'll go along with that!

> Remember that at some point in the future when we've forgotten why we did this, someone will have to explain it.

I _hope_ my final version is a bit more readable.

sebastian


From gabriel.bodard at kcl.ac.uk  Thu May 10 10:27:07 2012
From: gabriel.bodard at kcl.ac.uk (Gabriel BODARD)
Date: Thu, 10 May 2012 15:27:07 +0100
Subject: [tei-council] Update on the activities of the TEI Pointer working
	group
In-Reply-To: <CAC_Lu0YjAvVdAkHQrrdiv8W3w4QByBz=NHbfgPQqF=nvCcLvWw@mail.gmail.com>
References: <CC225F40-EBAE-43B7-A1F7-F2C85F82F3CA@inria.fr>
	<20391.14578.878644.290962@emt.wwp.brown.edu>
	<D5167E33-F744-4510-A5E7-5C378B25381F@nyu.edu>
	<CAC_Lu0YHUWwxXm5trr9E8S-Q=LFrs4T1TBm2Y7Vmyb4GUAFevA@mail.gmail.com>
	<0C536FD4-BF00-4F38-8E8B-8F03D57D9BBF@nyu.edu>
	<4FA82C48.2020909@uvic.ca>
	<8BBD45BF-BB52-4199-A8FC-4587C56B1BDB@inria.fr>
	<4FA8C661.1010404@o2.pl> <4FA9102C.1000801@uvic.ca>
	<4FA9313F.9040907@o2.pl> <4FA97649.7050706@uvic.ca>
	<4FA982D7.7070404@o2.pl> <4FA98818.5090603@kcl.ac.uk>
	<4FAA5039.1030202@o2.pl>
	<CFE1BE6E-9D69-44D1-9A51-E99B6A185C91@nyu.edu>
	<4FAA7438.7040305@o2.pl>
	<CAC_Lu0YjAvVdAkHQrrdiv8W3w4QByBz=NHbfgPQqF=nvCcLvWw@mail.gmail.com>
Message-ID: <4FABD03B.3060007@kcl.ac.uk>

Dear Councillors,

Here is the feedback I was tasked to report at the last F2F:

The TEI Pointer/Stand-off mark up working group will eventually propose 
to TEI Council that the specifications of the various Pointer/XPointer 
methods in the guidelines be improved, both (a) by the addition of 
concrete examples of the use of TEI Pointer and other schemes, and some 
guidance as to which are appropriate in different contexts (and indeed 
in combination), and (b) by technical description, including examples, 
of precisely what an implementation of the TEI Pointer schemes is 
expected to do.

To this end we are building (very much ongoing) a page of examples of 
usage in the TEI Wiki 
(http://wiki.tei-c.org/index.php/Stand-off_use_cases), including 
examples of XML, the Pointers one might use to address them, the use one 
might make of these Pointers downstream, and a technical description of 
the output from any such uses. Anyone from Council who might like to 
contribute to this page is encouraged to do so.

Cheers,

G

-- 
Dr Gabriel BODARD
(Research Associate in Digital Epigraphy)

Department of Digital Humanities
King's College London
26-29 Drury Lane
London WC2B 5RL

Email: gabriel.bodard at kcl.ac.uk
Tel: +44 (0)20 7848 1388
Fax: +44 (0)20 7848 2980

http://www.digitalclassicist.org/
http://www.currentepigraphy.org/

From mholmes at uvic.ca  Tue May 15 12:13:49 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Tue, 15 May 2012 09:13:49 -0700
Subject: [tei-council] Editing the Guidelines
Message-ID: <4FB280BD.9090100@uvic.ca>

Hi all,

Becky has pointed out what looks like a slight flaw in the "Editing the 
Guidelines" document:

<http://www.tei-c.org/Activities/Council/Working/tcw20.xml>

It says this:

"Make your changes. Make sure your source is still valid against the 
p5odds.rnc schema."

p5odds.rnc is not in the repo, of course; it's generated during a build. 
That means that you don't have a copy of that file unless you do a 
build. In order to do a build, you need a range of stuff set up on your 
machine (for instance, you need the TEI Debian packages if you're on 
Ubuntu, otherwise "make" will fail as soon as it hits an "rnv" command; 
rnv doesn't appear to be in the Ubuntu repos any more, if it ever was). 
I don't know what happens if you're on a Mac or Windows, or what you'd 
need to install to get a build working.

What I suggested to Becky is that she validate any changes to the 
Guidelines in a two-stage process, like this:

1. Create a fully-expanded version of the guidelines by doing this in 
/trunk/P5/Source:

   xmllint --noent guidelines-en.xml -o guidelines-en_expanded.xml

2. Open that file in Oxygen, and do Document/Validate/Validate with... 
then point to the latest p5odds.rnc file generated by a Jenkins build:

<http://teijenkins.hcmc.uvic.ca:8080/job/TEIP5-Test/ws/p5odds.rng>

This is a bit onerous, and for most minor changes you might as well just 
let Jenkins do the job. It also requires that you have xmllint 
installed, but that's less problematic than what you need for a full build.

Does that seem reasonable, or is there a simpler approach?

Cheers,
Martin
-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From rwelzenbach at gmail.com  Tue May 15 22:52:36 2012
From: rwelzenbach at gmail.com (Rebecca Welzenbach)
Date: Tue, 15 May 2012 22:52:36 -0400
Subject: [tei-council] Editing the Guidelines
In-Reply-To: <4FB280BD.9090100@uvic.ca>
References: <4FB280BD.9090100@uvic.ca>
Message-ID: <CAA2irtLqnxu2MRJB3u24BFby5R+oABfeE4p+vqqpvh2C8NhBCQ@mail.gmail.com>

Thanks, Martin.

The bulleted list of steps at
http://www.tei-c.org/Activities/Council/Working/tcw20.xml#body.1_div.4
reads as though "Make sure your source is still valid against the
p5odds.rnc schema," is its own step, to be completed before either
doing a local build or committing to let Jenkins assess the changes.

Martin did indeed come up with a way to do this (which works just
fine, BTW!). However, the text that follows in
http://www.tei-c.org/Activities/Council/Working/tcw20.xml#body.1_div.4
gives lots of reasons for letting Jenkins do all the validation for
you, which suggests to me that validating against p5odds.rnc was never
really meant to be attempted by those who are choosing the
commit-and-wait option.

If that's right, instead of expanding this step, I suggest that the
sentence "Make sure your source is still valid against the p5odds.rnc
schema," either just be dropped altogether, or become part of the
bullet underneath, "If you have a locally installed P5 build
environment, make sure you can still build, and that the examples are
still valid," so that it's clear this is part of the process of
checking your work with a local build, but can be safely ignored if
you're just going to commit and wait for results from Jenkins.


Becky






On Tue, May 15, 2012 at 12:13 PM, Martin Holmes <mholmes at uvic.ca> wrote:
> Hi all,
>
> Becky has pointed out what looks like a slight flaw in the "Editing the
> Guidelines" document:
>
> <http://www.tei-c.org/Activities/Council/Working/tcw20.xml>
>
> It says this:
>
> "Make your changes. Make sure your source is still valid against the
> p5odds.rnc schema."
>
> p5odds.rnc is not in the repo, of course; it's generated during a build.
> That means that you don't have a copy of that file unless you do a
> build. In order to do a build, you need a range of stuff set up on your
> machine (for instance, you need the TEI Debian packages if you're on
> Ubuntu, otherwise "make" will fail as soon as it hits an "rnv" command;
> rnv doesn't appear to be in the Ubuntu repos any more, if it ever was).
> I don't know what happens if you're on a Mac or Windows, or what you'd
> need to install to get a build working.
>
> What I suggested to Becky is that she validate any changes to the
> Guidelines in a two-stage process, like this:
>
> 1. Create a fully-expanded version of the guidelines by doing this in
> /trunk/P5/Source:
>
> ? xmllint --noent guidelines-en.xml -o guidelines-en_expanded.xml
>
> 2. Open that file in Oxygen, and do Document/Validate/Validate with...
> then point to the latest p5odds.rnc file generated by a Jenkins build:
>
> <http://teijenkins.hcmc.uvic.ca:8080/job/TEIP5-Test/ws/p5odds.rng>
>
> This is a bit onerous, and for most minor changes you might as well just
> let Jenkins do the job. It also requires that you have xmllint
> installed, but that's less problematic than what you need for a full build.
>
> Does that seem reasonable, or is there a simpler approach?
>
> Cheers,
> Martin
> --
> Martin Holmes
> University of Victoria Humanities Computing and Media Centre
> (mholmes at uvic.ca)
> --
> tei-council mailing list
> tei-council at lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>
> PLEASE NOTE: postings to this list are publicly archived

From James.Cummings at oucs.ox.ac.uk  Wed May 16 05:58:41 2012
From: James.Cummings at oucs.ox.ac.uk (James Cummings)
Date: Wed, 16 May 2012 10:58:41 +0100
Subject: [tei-council] Editing the Guidelines
In-Reply-To: <CAA2irtLqnxu2MRJB3u24BFby5R+oABfeE4p+vqqpvh2C8NhBCQ@mail.gmail.com>
References: <4FB280BD.9090100@uvic.ca>
	<CAA2irtLqnxu2MRJB3u24BFby5R+oABfeE4p+vqqpvh2C8NhBCQ@mail.gmail.com>
Message-ID: <4FB37A51.2020002@oucs.ox.ac.uk>

On 16/05/12 03:52, Rebecca Welzenbach wrote:
> If that's right, instead of expanding this step, I suggest that the
> sentence "Make sure your source is still valid against the p5odds.rnc
> schema," either just be dropped altogether, or become part of the
> bullet underneath, "If you have a locally installed P5 build
> environment, make sure you can still build, and that the examples are
> still valid," so that it's clear this is part of the process of
> checking your work with a local build, but can be safely ignored if
> you're just going to commit and wait for results from Jenkins.

I do think that is right and that this should be made even more 
explicit. (i.e. say "You do not have to be able to build P5 
locally as Jenkins should test that P5 can still build and that 
the examples are still valid. Those with local P5 build 
environments can check locally that their changes are valid 
before committing, but this is not required."  (I like seeing the 
mistakes that others make, personally, it is informative.)

What do others think? I realise that if too many people are 
committing errors then we can get Jenkins into quite a state and 
it can be quite a delay, but I think the default assumption 
should be that we are relying on it, not on individual 
contributors to build/test/validate everything.

-James

-- 
Dr James Cummings, InfoDev,
Computing Services, University of Oxford

From syeates at gmail.com  Wed May 16 06:15:20 2012
From: syeates at gmail.com (stuart yeates)
Date: Wed, 16 May 2012 22:15:20 +1200
Subject: [tei-council] Fwd: [TEI-notify] SF.net SVN: tei:[10359]
	trunk/P5/Source/Specs/att.internetMedia.xml
In-Reply-To: <E1SUXcg-0002SL-H4@sfp-svn-6.v30.ch3.sourceforge.com>
References: <E1SUXcg-0002SL-H4@sfp-svn-6.v30.ch3.sourceforge.com>
Message-ID: <4FB37E38.6080809@gmail.com>

I added the following example to the att.internetMedia.xml and appear to 
have broken the subversion HEAD (a new and hopefully good version is 
rebuilding as I speak). The addition was:

<exemplum xml:lang="en">
   <p>In this example <att>mimeType</att> is used to indicate the URL 
points to a TEI XML file encoded in UTF-8.</p>
   <egXML xmlns="http://www.tei-c.org/ns/Examples">
     <ref mimeType="application/tei+xml; charset=UTF-8" 
target="http://tei.svn.sourceforge.net/viewvc/tei/trunk/P5/Source/guidelines-en.xml"/>
   </egXML>
</exemplum>

I'm not quite sure quite what I broke. I've rolled back my changes but 
things are still broken.

The console output is at: 
http://bits.nsms.ox.ac.uk:8080/jenkins/job/TEIP5-Documentation/482/console 
which makes it look like the breakage was in the middle of generating a 
PDF file.

My current best guesses are that something in there is clashing with the 
PDF generation; the disk is full; or I've done something really silly.

cheers
stuart


-------- Original Message --------
Subject: [TEI-notify] SF.net SVN: tei:[10359] 
trunk/P5/Source/Specs/att.internetMedia.xml
Date: Wed, 16 May 2012 06:22:10 +0000
From: stuartyeates at users.sourceforge.net
Reply-To: noreply at lists.sf.net
To: tei-notify at lists.sf.net

Revision: 10359
           http://tei.svn.sourceforge.net/tei/?rev=10359&view=rev
Author:   stuartyeates
Date:     2012-05-16 06:22:09 +0000 (Wed, 16 May 2012)
Log Message:
-----------
@mimeType example using charset=

Modified Paths:
--------------
     trunk/P5/Source/Specs/att.internetMedia.xml

This was sent by the SourceForge.net collaborative development platform, 
the world's largest Open Source development site.


------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
TEI-notify mailing list
TEI-notify at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tei-notify

From syeates at gmail.com  Wed May 16 06:15:48 2012
From: syeates at gmail.com (stuart yeates)
Date: Wed, 16 May 2012 22:15:48 +1200
Subject: [tei-council] Editing the Guidelines
In-Reply-To: <4FB37A51.2020002@oucs.ox.ac.uk>
References: <4FB280BD.9090100@uvic.ca>
	<CAA2irtLqnxu2MRJB3u24BFby5R+oABfeE4p+vqqpvh2C8NhBCQ@mail.gmail.com>
	<4FB37A51.2020002@oucs.ox.ac.uk>
Message-ID: <4FB37E54.8070407@gmail.com>

On 16/05/12 21:58, James Cummings wrote:
> On 16/05/12 03:52, Rebecca Welzenbach wrote:
>> If that's right, instead of expanding this step, I suggest that the
>> sentence "Make sure your source is still valid against the p5odds.rnc
>> schema," either just be dropped altogether, or become part of the
>> bullet underneath, "If you have a locally installed P5 build
>> environment, make sure you can still build, and that the examples are
>> still valid," so that it's clear this is part of the process of
>> checking your work with a local build, but can be safely ignored if
>> you're just going to commit and wait for results from Jenkins.
>
> I do think that is right and that this should be made even more
> explicit. (i.e. say "You do not have to be able to build P5
> locally as Jenkins should test that P5 can still build and that
> the examples are still valid. Those with local P5 build
> environments can check locally that their changes are valid
> before committing, but this is not required."  (I like seeing the
> mistakes that others make, personally, it is informative.)
>
> What do others think? I realise that if too many people are
> committing errors then we can get Jenkins into quite a state and
> it can be quite a delay, but I think the default assumption
> should be that we are relying on it, not on individual
> contributors to build/test/validate everything.

I'm with James on this. My local TEI build broke in a recent Ubuntu 
upgrade, and I was hoping not to have to spend the time working out 
what's wrong.

[Having said that, I broke jenkins this evening]

cheers
stuart




From sebastian.rahtz at oucs.ox.ac.uk  Wed May 16 07:30:22 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Wed, 16 May 2012 11:30:22 +0000
Subject: [tei-council] [TEI-notify] SF.net SVN:
	tei:[10359]	trunk/P5/Source/Specs/att.internetMedia.xml
In-Reply-To: <4FB37E38.6080809@gmail.com>
References: <E1SUXcg-0002SL-H4@sfp-svn-6.v30.ch3.sourceforge.com>
	<4FB37E38.6080809@gmail.com>
Message-ID: <69025296-88BC-4737-801E-287D7C43E3B3@oucs.ox.ac.uk>


On 16 May 2012, at 11:15, stuart yeates wrote:

> I'm not quite sure quite what I broke. I've rolled back my changes but 
> things are still broken.
> 
> The console output is at: 
> http://bits.nsms.ox.ac.uk:8080/jenkins/job/TEIP5-Documentation/482/console 
> which makes it look like the breakage was in the middle of generating a 
> PDF file.
> 
> My current best guesses are that something in there is clashing with the 
> PDF generation; the disk is full; or I've done something really silly.

i hate that stage. very hard to debug.

am testing much more verbose output
--
Sebastian Rahtz      
Head of Information and Support Group
Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431

S?lo le pido a Dios
que el futuro no me sea indiferente


From mholmes at uvic.ca  Wed May 16 08:42:33 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Wed, 16 May 2012 05:42:33 -0700
Subject: [tei-council] Editing the Guidelines
In-Reply-To: <4FB37A51.2020002@oucs.ox.ac.uk>
References: <4FB280BD.9090100@uvic.ca>
	<CAA2irtLqnxu2MRJB3u24BFby5R+oABfeE4p+vqqpvh2C8NhBCQ@mail.gmail.com>
	<4FB37A51.2020002@oucs.ox.ac.uk>
Message-ID: <4FB3A0B9.3040404@uvic.ca>

I agree that we should be relying on Jenkins primarily; in fact, it's 
the only thing we can really rely on, because local build environments 
can vary a lot, and what works locally may fail when you run it on 
Jenkins anyway. This is especially true now that we're building on 
Jenkins with the SVN version of the stylesheets; if you build locally 
with your Debian-packaged stylesheets, they'll be out of date compared 
with the SVN versions.

However, I think it's probably not a bad thing to provide instructions 
to help people do a basic validation of the Guidelines XML. When you 
start editing the Guidelines, it's slightly daunting to realize that 
you're editing fragmentary files that can't be validated as you work. 
The two-step xmllint -- noent... followed by validation against the 
Jenkins p5odds.rnc should work well to reassure people before they 
commit changes, especially the first few times they edit.

Cheers,
Martin

On 12-05-16 02:58 AM, James Cummings wrote:
> On 16/05/12 03:52, Rebecca Welzenbach wrote:
>> If that's right, instead of expanding this step, I suggest that the
>> sentence "Make sure your source is still valid against the p5odds.rnc
>> schema," either just be dropped altogether, or become part of the
>> bullet underneath, "If you have a locally installed P5 build
>> environment, make sure you can still build, and that the examples are
>> still valid," so that it's clear this is part of the process of
>> checking your work with a local build, but can be safely ignored if
>> you're just going to commit and wait for results from Jenkins.
>
> I do think that is right and that this should be made even more
> explicit. (i.e. say "You do not have to be able to build P5
> locally as Jenkins should test that P5 can still build and that
> the examples are still valid. Those with local P5 build
> environments can check locally that their changes are valid
> before committing, but this is not required."  (I like seeing the
> mistakes that others make, personally, it is informative.)
>
> What do others think? I realise that if too many people are
> committing errors then we can get Jenkins into quite a state and
> it can be quite a delay, but I think the default assumption
> should be that we are relying on it, not on individual
> contributors to build/test/validate everything.
>
> -James
>

From sebastian.rahtz at oucs.ox.ac.uk  Wed May 16 08:53:56 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Wed, 16 May 2012 12:53:56 +0000
Subject: [tei-council] [TEI-notify] SF.net SVN:
	tei:[10359]	trunk/P5/Source/Specs/att.internetMedia.xml
In-Reply-To: <69025296-88BC-4737-801E-287D7C43E3B3@oucs.ox.ac.uk>
References: <E1SUXcg-0002SL-H4@sfp-svn-6.v30.ch3.sourceforge.com>
	<4FB37E38.6080809@gmail.com>
	<69025296-88BC-4737-801E-287D7C43E3B3@oucs.ox.ac.uk>
Message-ID: <BCCEB71D-F1F7-4FCD-BFB4-F5D11CBD4175@oucs.ox.ac.uk>

I have located and fixed the problem with the PDF conversion, which was in the XSL stylesheets.
Don't ask me why it has not come up before, life is a mystery.
--
Sebastian Rahtz      
Head of Information and Support Group
Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431

S?lo le pido a Dios
que el futuro no me sea indiferente


From James.Cummings at oucs.ox.ac.uk  Wed May 16 08:57:10 2012
From: James.Cummings at oucs.ox.ac.uk (James Cummings)
Date: Wed, 16 May 2012 13:57:10 +0100
Subject: [tei-council] Editing the Guidelines
In-Reply-To: <4FB3A0B9.3040404@uvic.ca>
References: <4FB280BD.9090100@uvic.ca>
	<CAA2irtLqnxu2MRJB3u24BFby5R+oABfeE4p+vqqpvh2C8NhBCQ@mail.gmail.com>
	<4FB37A51.2020002@oucs.ox.ac.uk> <4FB3A0B9.3040404@uvic.ca>
Message-ID: <4FB3A426.70309@oucs.ox.ac.uk>

On 16/05/12 13:42, Martin Holmes wrote:
> I agree that we should be relying on Jenkins primarily; in fact,
> it's the only thing we can really rely on, because local build
> environments can vary a lot, and what works locally may fail when
> you run it on Jenkins anyway. This is especially true now that
> we're building on Jenkins with the SVN version of the
> stylesheets; if you build locally with your Debian-packaged
> stylesheets, they'll be out of date compared with the SVN versions.

That hadn't occurred to me. But yes, adds strength to the 'let 
Jenkins do it' side of things.

> However, I think it's probably not a bad thing to provide
> instructions to help people do a basic validation of the
> Guidelines XML. When you start editing the Guidelines, it's
> slightly daunting to realize that you're editing fragmentary
> files that can't be validated as you work. The two-step xmllint
> -- noent... followed by validation against the Jenkins p5odds.rnc
> should work well to reassure people before they commit changes,
> especially the first few times they edit.


Yes, I don't think we should remove instructions on how to do so 
locally (or, well, I guess I mean we should add the xmllint (or 
similar) validation against the expanded guidelines method.  (I'm 
assuming that wouldn't check schematron constraints we might have 
imposed, etc.?) The point of that should be local initial 
checking "Yup, I've not forgot to close an angle bracket or 
started that @xml:id value with a number" for those who don't 
want to go through the anguish of exposing their mistakes 
publicly. ;-)


-James

-- 
Dr James Cummings, InfoDev,
Computing Services, University of Oxford

From mholmes at uvic.ca  Wed May 16 11:07:56 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Wed, 16 May 2012 08:07:56 -0700
Subject: [tei-council] Editing the Guidelines
In-Reply-To: <4FB3A426.70309@oucs.ox.ac.uk>
References: <4FB280BD.9090100@uvic.ca>
	<CAA2irtLqnxu2MRJB3u24BFby5R+oABfeE4p+vqqpvh2C8NhBCQ@mail.gmail.com>
	<4FB37A51.2020002@oucs.ox.ac.uk> <4FB3A0B9.3040404@uvic.ca>
	<4FB3A426.70309@oucs.ox.ac.uk>
Message-ID: <4FB3C2CC.202@uvic.ca>



On 12-05-16 05:57 AM, James Cummings wrote:
> On 16/05/12 13:42, Martin Holmes wrote:
>> I agree that we should be relying on Jenkins primarily; in fact,
>> it's the only thing we can really rely on, because local build
>> environments can vary a lot, and what works locally may fail when
>> you run it on Jenkins anyway. This is especially true now that
>> we're building on Jenkins with the SVN version of the
>> stylesheets; if you build locally with your Debian-packaged
>> stylesheets, they'll be out of date compared with the SVN versions.
>
> That hadn't occurred to me. But yes, adds strength to the 'let
> Jenkins do it' side of things.
>
>> However, I think it's probably not a bad thing to provide
>> instructions to help people do a basic validation of the
>> Guidelines XML. When you start editing the Guidelines, it's
>> slightly daunting to realize that you're editing fragmentary
>> files that can't be validated as you work. The two-step xmllint
>> -- noent... followed by validation against the Jenkins p5odds.rnc
>> should work well to reassure people before they commit changes,
>> especially the first few times they edit.
>
>
> Yes, I don't think we should remove instructions on how to do so
> locally (or, well, I guess I mean we should add the xmllint (or
> similar) validation against the expanded guidelines method.  (I'm
> assuming that wouldn't check schematron constraints we might have
> imposed, etc.?)

No, it wouldn't catch anything like that. Just XML validation against 
the schema.

> The point of that should be local initial
> checking "Yup, I've not forgot to close an angle bracket or
> started that @xml:id value with a number" for those who don't
> want to go through the anguish of exposing their mistakes
> publicly. ;-)

Exactly. Like wot I did just before the last release: "pasted a bunch of 
content before the XML declaration in a file, committed the result 
without validating it, and then [went] off to have a leisurely breakfast 
while the Jinks servers choked and spat it out. On release day."

Cheers,
Martin

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From syeates at gmail.com  Thu May 17 05:05:41 2012
From: syeates at gmail.com (stuart yeates)
Date: Thu, 17 May 2012 21:05:41 +1200
Subject: [tei-council] [TEI-notify] SF.net SVN: tei:[10359]
	trunk/P5/Source/Specs/att.internetMedia.xml
In-Reply-To: <BCCEB71D-F1F7-4FCD-BFB4-F5D11CBD4175@oucs.ox.ac.uk>
References: <E1SUXcg-0002SL-H4@sfp-svn-6.v30.ch3.sourceforge.com>
	<4FB37E38.6080809@gmail.com>
	<69025296-88BC-4737-801E-287D7C43E3B3@oucs.ox.ac.uk>
	<BCCEB71D-F1F7-4FCD-BFB4-F5D11CBD4175@oucs.ox.ac.uk>
Message-ID: <4FB4BF65.6020304@gmail.com>

On 17/05/12 00:53, Sebastian Rahtz wrote:
> I have located and fixed the problem with the PDF conversion, which was in the XSL stylesheets.
> Don't ask me why it has not come up before, life is a mystery.

Thank you. I've re-made the changes that caused the problem and 
everything is now working fine. The update was a @mimeType example based 
on a discussion on the TEI-SOM at LISTSERV.BROWN.EDU mailing list.

http://bits.nsms.ox.ac.uk:8080/jenkins/job/TEIP5-Documentation/lastSuccessfulBuild/artifact/Guidelines-web/en/html/ref-att.internetMedia.html

cheers
stuart


From dsewell at virginia.edu  Fri May 18 09:00:02 2012
From: dsewell at virginia.edu (David Sewell)
Date: Fri, 18 May 2012 09:00:02 -0400 (EDT)
Subject: [tei-council] Setting up read-only access to TEI Council list?
Message-ID: <alpine.OSX.2.00.1205180854250.24330@lister.ei.virginia.edu>

Christof Sch?ch (http://www.christof-schoech.de/en) has just inquired about 
whether it is possible for him to get read-only access to TEI Council list 
email, either via email or an RSS feed. Of course the archives are publicly 
accessible, but to my knowledge we have never set up a feed that would enable 
people to view messages as they go out.

I know that there are various email-to-RSS services and programs out there. So 
two questions: (1) is this something the Council would want to enable, and (2) 
any suggestions on the best way to implement it, if so?

David

-- 
David Sewell, Editorial and Technical Manager
ROTUNDA, The University of Virginia Press
PO Box 400314, Charlottesville, VA 22904-4314 USA
Email: dsewell at virginia.edu   Tel: +1 434 924 9973
Web: http://rotunda.upress.virginia.edu/

From kevin.s.hawkins at ultraslavonic.info  Fri May 18 09:23:55 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Fri, 18 May 2012 09:23:55 -0400
Subject: [tei-council] Setting up read-only access to TEI Council list?
In-Reply-To: <alpine.OSX.2.00.1205180854250.24330@lister.ei.virginia.edu>
References: <alpine.OSX.2.00.1205180854250.24330@lister.ei.virginia.edu>
Message-ID: <4FB64D6B.8050904@ultraslavonic.info>

(1) Since we opened the list archives years ago in the interest of 
transparency, it seems that a mandate for transparency extends to ease 
of accessibility.  On those grounds, I support making it easier to 
follow Council discussions.

(2) I see two possible technical mechanisms for this:

a) Add as a member of tei-council an address like 
council-outsiders at lists.village.virginia.edu , which we would advertise 
so that those interested could subscribe.  Members of that list would 
receive messages sent to tei-council, and we would trust that they 
wouldn't ever send a message to tei-council with 
"council-outsiders at lists.village.virginia.edu" as the sender in order to 
post.

b) Add as a member of tei-council some email address hooked up to an 
email-to-RSS service and then publicize the feed URL.

The advantage to (a) is that it allows threading of messages, whereas 
feeds (b) do not.  But (a) would also create an entirely duplicated 
message archive.

On 5/18/2012 9:00 AM, David Sewell wrote:
> Christof Sch?ch (http://www.christof-schoech.de/en) has just inquired
> about whether it is possible for him to get read-only access to TEI
> Council list email, either via email or an RSS feed. Of course the
> archives are publicly accessible, but to my knowledge we have never set
> up a feed that would enable people to view messages as they go out.
>
> I know that there are various email-to-RSS services and programs out
> there. So two questions: (1) is this something the Council would want to
> enable, and (2) any suggestions on the best way to implement it, if so?
>
> David
>

From James.Cummings at oucs.ox.ac.uk  Fri May 18 10:21:33 2012
From: James.Cummings at oucs.ox.ac.uk (James Cummings)
Date: Fri, 18 May 2012 15:21:33 +0100
Subject: [tei-council] Setting up read-only access to TEI Council list?
In-Reply-To: <4FB64D6B.8050904@ultraslavonic.info>
References: <alpine.OSX.2.00.1205180854250.24330@lister.ei.virginia.edu>
	<4FB64D6B.8050904@ultraslavonic.info>
Message-ID: <4FB65AED.20407@oucs.ox.ac.uk>

On 18/05/12 14:23, Kevin Hawkins wrote:
> a) Add as a member of tei-council an address like
> council-outsiders at lists.village.virginia.edu , which we would advertise
> so that those interested could subscribe.  Members of that list would
> receive messages sent to tei-council, and we would trust that they
> wouldn't ever send a message to tei-council with
> "council-outsiders at lists.village.virginia.edu" as the sender in order to
> post.

They could most likely be set to not having posting abilities (or 
their posts to be moderated).

> b) Add as a member of tei-council some email address hooked up to an
> email-to-RSS service and then publicize the feed URL.
> The advantage to (a) is that it allows threading of messages, whereas
> feeds (b) do not.  But (a) would also create an entirely duplicated
> message archive.

Wouldn't another option be to get the mailing list archived by 
one of the services which currently archive the TEI-L mailing list?

-James

-- 
Dr James Cummings, InfoDev,
Computing Services, University of Oxford

From mholmes at uvic.ca  Fri May 18 10:51:26 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Fri, 18 May 2012 07:51:26 -0700
Subject: [tei-council] Setting up read-only access to TEI Council list?
In-Reply-To: <4FB65AED.20407@oucs.ox.ac.uk>
References: <alpine.OSX.2.00.1205180854250.24330@lister.ei.virginia.edu>
	<4FB64D6B.8050904@ultraslavonic.info>
	<4FB65AED.20407@oucs.ox.ac.uk>
Message-ID: <4FB661EE.6020307@uvic.ca>


On 12-05-18 07:21 AM, James Cummings wrote:
> On 18/05/12 14:23, Kevin Hawkins wrote:
>> a) Add as a member of tei-council an address like
>> council-outsiders at lists.village.virginia.edu , which we would advertise
>> so that those interested could subscribe.  Members of that list would
>> receive messages sent to tei-council, and we would trust that they
>> wouldn't ever send a message to tei-council with
>> "council-outsiders at lists.village.virginia.edu" as the sender in order to
>> post.
>
> They could most likely be set to not having posting abilities (or
> their posts to be moderated).
>
>> b) Add as a member of tei-council some email address hooked up to an
>> email-to-RSS service and then publicize the feed URL.
>> The advantage to (a) is that it allows threading of messages, whereas
>> feeds (b) do not.  But (a) would also create an entirely duplicated
>> message archive.
>
> Wouldn't another option be to get the mailing list archived by
> one of the services which currently archive the TEI-L mailing list?

I thought the archives were already public here:

<http://lists.village.virginia.edu/pipermail/tei-council/2012/date.html#start>

I don't see much point in duplicating the archive, unless the 
alternative site has better searching and browsing functionality.

Cheers,
Martin



From kevin.s.hawkins at ultraslavonic.info  Fri May 18 10:55:40 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Fri, 18 May 2012 10:55:40 -0400
Subject: [tei-council] Setting up read-only access to TEI Council list?
In-Reply-To: <4FB65AED.20407@oucs.ox.ac.uk>
References: <alpine.OSX.2.00.1205180854250.24330@lister.ei.virginia.edu>	<4FB64D6B.8050904@ultraslavonic.info>
	<4FB65AED.20407@oucs.ox.ac.uk>
Message-ID: <4FB662EC.2010906@ultraslavonic.info>

On 5/18/2012 10:21 AM, James Cummings wrote:
> On 18/05/12 14:23, Kevin Hawkins wrote:
>> a) Add as a member of tei-council an address like
>> council-outsiders at lists.village.virginia.edu , which we would advertise
>> so that those interested could subscribe.  Members of that list would
>> receive messages sent to tei-council, and we would trust that they
>> wouldn't ever send a message to tei-council with
>> "council-outsiders at lists.village.virginia.edu" as the sender in order to
>> post.
>
> They could most likely be set to not having posting abilities (or
> their posts to be moderated).

That's true: I wasn't thinking of the possibility that Virginia's 
mailing list system might allow people to be subscribed without open 
posting privileges.  That's more straightforward technically except that 
it requires that David manually add and remove addresses for those who 
want to follow the discussion.

>> b) Add as a member of tei-council some email address hooked up to an
>> email-to-RSS service and then publicize the feed URL.
>> The advantage to (a) is that it allows threading of messages, whereas
>> feeds (b) do not.  But (a) would also create an entirely duplicated
>> message archive.
>
> Wouldn't another option be to get the mailing list archived by
> one of the services which currently archive the TEI-L mailing list?

As Martin points out, the list is already archived by Virginia. 
Christian wants a push solution rather than the current pull solution, 
which requires him to visit the webpage and browse for new messages.

From gabriel.bodard at kcl.ac.uk  Fri May 18 10:56:54 2012
From: gabriel.bodard at kcl.ac.uk (Gabriel BODARD)
Date: Fri, 18 May 2012 15:56:54 +0100
Subject: [tei-council] Setting up read-only access to TEI Council list?
In-Reply-To: <4FB661EE.6020307@uvic.ca>
References: <alpine.OSX.2.00.1205180854250.24330@lister.ei.virginia.edu>
	<4FB64D6B.8050904@ultraslavonic.info>	<4FB65AED.20407@oucs.ox.ac.uk>
	<4FB661EE.6020307@uvic.ca>
Message-ID: <4FB66336.3040401@kcl.ac.uk>

Agreed. Not sure I like the idea of duplicating the list in any of the 
various ways suggested. If we're setting people up to be able to receive 
but not post, why not just make them moderated members of the existing 
list? It seems counter-intuitive, but it is identical in every way to 
what is being suggested with the "outsiders" list.

Is there a technically easy way to set up an RSS feed from the archives? 
Easier than web-scraping, I mean, for which there must exist tools 
already...

G

On 18/05/2012 15:51, Martin Holmes wrote:
>
> On 12-05-18 07:21 AM, James Cummings wrote:
>> On 18/05/12 14:23, Kevin Hawkins wrote:
>>> a) Add as a member of tei-council an address like
>>> council-outsiders at lists.village.virginia.edu , which we would advertise
>>> so that those interested could subscribe.  Members of that list would
>>> receive messages sent to tei-council, and we would trust that they
>>> wouldn't ever send a message to tei-council with
>>> "council-outsiders at lists.village.virginia.edu" as the sender in order to
>>> post.
>>
>> They could most likely be set to not having posting abilities (or
>> their posts to be moderated).
>>
>>> b) Add as a member of tei-council some email address hooked up to an
>>> email-to-RSS service and then publicize the feed URL.
>>> The advantage to (a) is that it allows threading of messages, whereas
>>> feeds (b) do not.  But (a) would also create an entirely duplicated
>>> message archive.
>>
>> Wouldn't another option be to get the mailing list archived by
>> one of the services which currently archive the TEI-L mailing list?
>
> I thought the archives were already public here:
>
> <http://lists.village.virginia.edu/pipermail/tei-council/2012/date.html#start>
>
> I don't see much point in duplicating the archive, unless the
> alternative site has better searching and browsing functionality.
>
> Cheers,
> Martin
>
>

-- 
Dr Gabriel BODARD
(Research Associate in Digital Epigraphy)

Department of Digital Humanities
King's College London
26-29 Drury Lane
London WC2B 5RL

Email: gabriel.bodard at kcl.ac.uk
Tel: +44 (0)20 7848 1388
Fax: +44 (0)20 7848 2980

http://www.digitalclassicist.org/
http://www.currentepigraphy.org/

From dsewell at virginia.edu  Fri May 18 10:58:53 2012
From: dsewell at virginia.edu (David Sewell)
Date: Fri, 18 May 2012 10:58:53 -0400 (EDT)
Subject: [tei-council] Setting up read-only access to TEI Council list?
In-Reply-To: <4FB661EE.6020307@uvic.ca>
References: <alpine.OSX.2.00.1205180854250.24330@lister.ei.virginia.edu>
	<4FB64D6B.8050904@ultraslavonic.info>
	<4FB65AED.20407@oucs.ox.ac.uk> <4FB661EE.6020307@uvic.ca>
Message-ID: <alpine.OSX.2.00.1205181055410.1112@koson.local>

I think it would be fairly easy for me to set up a new 
public-subscription email list using UVA's current standard list 
software (Sympa), such that (1) it would mirror posts to tei-council, 
(2) anyone could subscribe to it, and (3) it would have user-friendly 
searchable archives. Let me know if this is desired.

In the meantime, I am going to ask the UVA email list gurus if they 
would be willing to attempt migrating the archives of tei-council to 
Sympa. If so, the best option might be to make that transition instead. 
I will report back.

David

On Fri, 18 May 2012, Martin Holmes wrote:

>
> On 12-05-18 07:21 AM, James Cummings wrote:
>> On 18/05/12 14:23, Kevin Hawkins wrote:
>>> a) Add as a member of tei-council an address like
>>> council-outsiders at lists.village.virginia.edu , which we would advertise
>>> so that those interested could subscribe.  Members of that list would
>>> receive messages sent to tei-council, and we would trust that they
>>> wouldn't ever send a message to tei-council with
>>> "council-outsiders at lists.village.virginia.edu" as the sender in order to
>>> post.
>>
>> They could most likely be set to not having posting abilities (or
>> their posts to be moderated).
>>
>>> b) Add as a member of tei-council some email address hooked up to an
>>> email-to-RSS service and then publicize the feed URL.
>>> The advantage to (a) is that it allows threading of messages, whereas
>>> feeds (b) do not.  But (a) would also create an entirely duplicated
>>> message archive.
>>
>> Wouldn't another option be to get the mailing list archived by
>> one of the services which currently archive the TEI-L mailing list?
>
> I thought the archives were already public here:
>
> <http://lists.village.virginia.edu/pipermail/tei-council/2012/date.html#start>
>
> I don't see much point in duplicating the archive, unless the
> alternative site has better searching and browsing functionality.
>
> Cheers,
> Martin
>
>
>

-- 
David Sewell, Editorial and Technical Manager
ROTUNDA, The University of Virginia Press
PO Box 400314, Charlottesville, VA 22904-4314 USA
Email: dsewell at virginia.edu   Tel: +1 434 924 9973
Web: http://rotunda.upress.virginia.edu/

From James.Cummings at oucs.ox.ac.uk  Fri May 18 11:18:37 2012
From: James.Cummings at oucs.ox.ac.uk (James Cummings)
Date: Fri, 18 May 2012 16:18:37 +0100
Subject: [tei-council] Setting up read-only access to TEI Council list?
In-Reply-To: <alpine.OSX.2.00.1205181055410.1112@koson.local>
References: <alpine.OSX.2.00.1205180854250.24330@lister.ei.virginia.edu>
	<4FB64D6B.8050904@ultraslavonic.info>
	<4FB65AED.20407@oucs.ox.ac.uk> <4FB661EE.6020307@uvic.ca>
	<alpine.OSX.2.00.1205181055410.1112@koson.local>
Message-ID: <4FB6684D.4020600@oucs.ox.ac.uk>


David,

Does Sympa also provide RSS or Atom feeds, do you know? Just curious.

That was the only reason I was suggesting an additional archiver 
(like gmane or nabble)

e.g. http://tei-l.970651.n3.nabble.com/tei-l-f1692902.xml
or http://rss.gmane.org/gmane.text.tei.general

(I'd prefer the former because the latter changes "@rend" to 
"&lt; at &gt;rend" which is just weird. ;-) )

-James

On 18/05/12 15:58, David Sewell wrote:
> I think it would be fairly easy for me to set up a new
> public-subscription email list using UVA's current standard list
> software (Sympa), such that (1) it would mirror posts to
> tei-council, (2) anyone could subscribe to it, and (3) it would
> have user-friendly searchable archives. Let me know if this is
> desired.
>
> In the meantime, I am going to ask the UVA email list gurus if
> they would be willing to attempt migrating the archives of
> tei-council to Sympa. If so, the best option might be to make
> that transition instead. I will report back.
>
> David
>
> On Fri, 18 May 2012, Martin Holmes wrote:
>
>>
>> On 12-05-18 07:21 AM, James Cummings wrote:
>>> On 18/05/12 14:23, Kevin Hawkins wrote:
>>>> a) Add as a member of tei-council an address like
>>>> council-outsiders at lists.village.virginia.edu , which we would
>>>> advertise
>>>> so that those interested could subscribe. Members of that
>>>> list would
>>>> receive messages sent to tei-council, and we would trust that
>>>> they
>>>> wouldn't ever send a message to tei-council with
>>>> "council-outsiders at lists.village.virginia.edu" as the sender
>>>> in order to
>>>> post.
>>>
>>> They could most likely be set to not having posting abilities (or
>>> their posts to be moderated).
>>>
>>>> b) Add as a member of tei-council some email address hooked
>>>> up to an
>>>> email-to-RSS service and then publicize the feed URL.
>>>> The advantage to (a) is that it allows threading of messages,
>>>> whereas
>>>> feeds (b) do not. But (a) would also create an entirely
>>>> duplicated
>>>> message archive.
>>>
>>> Wouldn't another option be to get the mailing list archived by
>>> one of the services which currently archive the TEI-L mailing
>>> list?
>>
>> I thought the archives were already public here:
>>
>> <http://lists.village.virginia.edu/pipermail/tei-council/2012/date.html#start>
>>
>>
>> I don't see much point in duplicating the archive, unless the
>> alternative site has better searching and browsing functionality.
>>
>> Cheers,
>> Martin
>>
>>
>>
>


-- 
Dr James Cummings, InfoDev,
Computing Services, University of Oxford

From James.Cummings at oucs.ox.ac.uk  Fri May 18 11:37:27 2012
From: James.Cummings at oucs.ox.ac.uk (James Cummings)
Date: Fri, 18 May 2012 16:37:27 +0100
Subject: [tei-council] Council Meeting  and EEBO-TCP Conference
Message-ID: <4FB66CB7.8010909@oucs.ox.ac.uk>

Hi Council,

http://www.doodle.com/csectyt4agcm58te

Of those who responded it looks like the days just immediately 
following (19-21 Sept) the EEBO-TCP conference (17-18 Sept) here 
in Oxford make the best bet. Sincere apologies to Piotr in this 
instance though, since he is unable to make it.  Is there anyone 
else who is unable to make these dates? Please check now rather 
than assuming it is ok!

Does anyone have an argument that we should be either making it 
at a different date?  If not, can you please all add this to your 
diary *today* and start remembering to book flights etc soon.

And on that note, you may have noticed (see my recent post I 
forwarded to TEI-L) that the EEBO-TCP conference is still looking 
for more submissions and if you are doing anything that you think 
*might* be interesting to an EEBO and/or TCP audience I would 
encourage you to submit something. (If your institution is 
willing to pay for your registration/accommodation/etc.)

Sebastian and I have submitted a paper proposal and I'll probably 
also submit a poster proposal.

-James

-- 
Dr James Cummings, InfoDev,
Computing Services, University of Oxford

From bansp at o2.pl  Fri May 18 15:05:34 2012
From: bansp at o2.pl (=?ISO-8859-2?Q?Piotr_Ba=F1ski?=)
Date: Fri, 18 May 2012 21:05:34 +0200
Subject: [tei-council] Setting up read-only access to TEI Council list?
In-Reply-To: <4FB66336.3040401@kcl.ac.uk>
References: <alpine.OSX.2.00.1205180854250.24330@lister.ei.virginia.edu>
	<4FB64D6B.8050904@ultraslavonic.info>	<4FB65AED.20407@oucs.ox.ac.uk>
	<4FB661EE.6020307@uvic.ca> <4FB66336.3040401@kcl.ac.uk>
Message-ID: <4FB69D7E.10100@o2.pl>

Hi,

I think it's one thing to provide public access to e-mail archives in
the interest of full openness, and another to know that all the e-mails
we write ->to the other members of the Council<- are obligatorily sent
into the mailboxes of other people. This seems to me to be pushing the
boundaries of good practice and politeness into the zone of politically
overcorrect exhibitionism, and I don't like the thought of being
involved in that.

I don't write to "other people", when I write to this list -- I write to
the Council. When I want to write to other people, I use TEI-L, or, in
rare and I believe justified cases, CC them openly...

Thanks for considering this,

  P.

On 18/05/12 16:56, Gabriel BODARD wrote:
> Agreed. Not sure I like the idea of duplicating the list in any of the 
> various ways suggested. If we're setting people up to be able to receive 
> but not post, why not just make them moderated members of the existing 
> list? It seems counter-intuitive, but it is identical in every way to 
> what is being suggested with the "outsiders" list.
> 
> Is there a technically easy way to set up an RSS feed from the archives? 
> Easier than web-scraping, I mean, for which there must exist tools 
> already...
> 
> G
> 
> On 18/05/2012 15:51, Martin Holmes wrote:
>>
>> On 12-05-18 07:21 AM, James Cummings wrote:
>>> On 18/05/12 14:23, Kevin Hawkins wrote:
>>>> a) Add as a member of tei-council an address like
>>>> council-outsiders at lists.village.virginia.edu , which we would advertise
>>>> so that those interested could subscribe.  Members of that list would
>>>> receive messages sent to tei-council, and we would trust that they
>>>> wouldn't ever send a message to tei-council with
>>>> "council-outsiders at lists.village.virginia.edu" as the sender in order to
>>>> post.
>>>
>>> They could most likely be set to not having posting abilities (or
>>> their posts to be moderated).
>>>
>>>> b) Add as a member of tei-council some email address hooked up to an
>>>> email-to-RSS service and then publicize the feed URL.
>>>> The advantage to (a) is that it allows threading of messages, whereas
>>>> feeds (b) do not.  But (a) would also create an entirely duplicated
>>>> message archive.
>>>
>>> Wouldn't another option be to get the mailing list archived by
>>> one of the services which currently archive the TEI-L mailing list?
>>
>> I thought the archives were already public here:
>>
>> <http://lists.village.virginia.edu/pipermail/tei-council/2012/date.html#start>
>>
>> I don't see much point in duplicating the archive, unless the
>> alternative site has better searching and browsing functionality.
>>
>> Cheers,
>> Martin
>>
>>
> 


From bansp at o2.pl  Fri May 18 15:10:29 2012
From: bansp at o2.pl (=?ISO-8859-2?Q?Piotr_Ba=F1ski?=)
Date: Fri, 18 May 2012 21:10:29 +0200
Subject: [tei-council] Council Meeting  and EEBO-TCP Conference
In-Reply-To: <4FB66CB7.8010909@oucs.ox.ac.uk>
References: <4FB66CB7.8010909@oucs.ox.ac.uk>
Message-ID: <4FB69EA5.9000104@o2.pl>

On 18/05/12 17:37, James Cummings wrote:
> Hi Council,
> 
> http://www.doodle.com/csectyt4agcm58te
> 
> Of those who responded it looks like the days just immediately 
> following (19-21 Sept) the EEBO-TCP conference (17-18 Sept) here 
> in Oxford make the best bet. Sincere apologies to Piotr in this 
> instance though, since he is unable to make it. 

I've done some thinking since I saw how the doodle poll was going to
come out, and, well, please don't cross me out yet. I'm currently
thinking of getting a co-author for that conference talk and sending
them to Vienna to present... not sure yet how the dates match exactly,
and how my colleagues will react to this idea and I'll only be able to
check that next week, as I'm pretty far away now, with almost no Net access.

Best,

  P.


From mholmes at uvic.ca  Fri May 18 16:33:30 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Fri, 18 May 2012 13:33:30 -0700
Subject: [tei-council] Setting up read-only access to TEI Council list?
In-Reply-To: <4FB69D7E.10100@o2.pl>
References: <alpine.OSX.2.00.1205180854250.24330@lister.ei.virginia.edu>
	<4FB64D6B.8050904@ultraslavonic.info>	<4FB65AED.20407@oucs.ox.ac.uk>
	<4FB661EE.6020307@uvic.ca> <4FB66336.3040401@kcl.ac.uk>
	<4FB69D7E.10100@o2.pl>
Message-ID: <4FB6B21A.70409@uvic.ca>

On 12-05-18 12:05 PM, Piotr Ba?ski wrote:
> Hi,
>
> I think it's one thing to provide public access to e-mail archives in
> the interest of full openness, and another to know that all the e-mails
> we write ->to the other members of the Council<- are obligatorily sent
> into the mailboxes of other people. This seems to me to be pushing the
> boundaries of good practice and politeness into the zone of politically
> overcorrect exhibitionism, and I don't like the thought of being
> involved in that.
>
> I don't write to "other people", when I write to this list -- I write to
> the Council. When I want to write to other people, I use TEI-L, or, in
> rare and I believe justified cases, CC them openly...

I must admit I felt a little uneasy myself about this, but I couldn't 
pin down why; your post has clarified it a bit for me. I also wonder 
what the likely outcomes of this might be. When someone is subscribed to 
an email list, and reading it, they will inevitably feel at some point 
that they want to get involved in the conversation that's going on. The 
only ways open to a non-Council-member would be:

  - email Council members directly, and ask that their opinions be 
injected into the discussion

  - take the topic over to TEI-L, and invite the broader community to 
respond.

Neither of these options seems like a good outcome to me, and both would 
be likely to derail or inhibit discussions on the Council list to some 
degree. We would most likely see contentious issues being discussed more 
off-list than on, through private email, and then they wouldn't be 
archived.

I think I would write differently, and probably less frequently, if I 
felt the Council list was being distributed to a larger group of people, 
many of whom I didn't know. That feels somehow different from the 
discussion being archived at Virginia, although I'm not quite sure why.

Cheers,
Martin

>
> Thanks for considering this,
>
>    P.
>
> On 18/05/12 16:56, Gabriel BODARD wrote:
>> Agreed. Not sure I like the idea of duplicating the list in any of the
>> various ways suggested. If we're setting people up to be able to receive
>> but not post, why not just make them moderated members of the existing
>> list? It seems counter-intuitive, but it is identical in every way to
>> what is being suggested with the "outsiders" list.
>>
>> Is there a technically easy way to set up an RSS feed from the archives?
>> Easier than web-scraping, I mean, for which there must exist tools
>> already...
>>
>> G
>>
>> On 18/05/2012 15:51, Martin Holmes wrote:
>>>
>>> On 12-05-18 07:21 AM, James Cummings wrote:
>>>> On 18/05/12 14:23, Kevin Hawkins wrote:
>>>>> a) Add as a member of tei-council an address like
>>>>> council-outsiders at lists.village.virginia.edu , which we would advertise
>>>>> so that those interested could subscribe.  Members of that list would
>>>>> receive messages sent to tei-council, and we would trust that they
>>>>> wouldn't ever send a message to tei-council with
>>>>> "council-outsiders at lists.village.virginia.edu" as the sender in order to
>>>>> post.
>>>>
>>>> They could most likely be set to not having posting abilities (or
>>>> their posts to be moderated).
>>>>
>>>>> b) Add as a member of tei-council some email address hooked up to an
>>>>> email-to-RSS service and then publicize the feed URL.
>>>>> The advantage to (a) is that it allows threading of messages, whereas
>>>>> feeds (b) do not.  But (a) would also create an entirely duplicated
>>>>> message archive.
>>>>
>>>> Wouldn't another option be to get the mailing list archived by
>>>> one of the services which currently archive the TEI-L mailing list?
>>>
>>> I thought the archives were already public here:
>>>
>>> <http://lists.village.virginia.edu/pipermail/tei-council/2012/date.html#start>
>>>
>>> I don't see much point in duplicating the archive, unless the
>>> alternative site has better searching and browsing functionality.
>>>
>>> Cheers,
>>> Martin
>>>
>>>
>>
>

From kevin.s.hawkins at ultraslavonic.info  Fri May 18 16:40:36 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Fri, 18 May 2012 16:40:36 -0400
Subject: [tei-council] Setting up read-only access to TEI Council list?
In-Reply-To: <4FB6B21A.70409@uvic.ca>
References: <alpine.OSX.2.00.1205180854250.24330@lister.ei.virginia.edu>	<4FB64D6B.8050904@ultraslavonic.info>	<4FB65AED.20407@oucs.ox.ac.uk>	<4FB661EE.6020307@uvic.ca>
	<4FB66336.3040401@kcl.ac.uk>	<4FB69D7E.10100@o2.pl>
	<4FB6B21A.70409@uvic.ca>
Message-ID: <4FB6B3C4.2000309@ultraslavonic.info>

Thanks, Piotr and Martin, for offering these thoughts.  I too was 
thinking about these points, but then I thought the TEI-C as an 
organization funded by institutional members, with each of us elected by 
the TEI-C's institutional members.  In the "open government" movement, 
people try to make deliberations of elected bodies as accessible as 
possible.  In that spirit, I'm interested in us doing the same.

As for wanting to contribute, here's an analogy.  Just because members 
of the public can attend a meeting of a city council or legislature 
doesn't mean you have the right to address that body without being 
invited by the body.

--K.

From gabriel.bodard at kcl.ac.uk  Sat May 19 09:08:20 2012
From: gabriel.bodard at kcl.ac.uk (Gabriel BODARD)
Date: Sat, 19 May 2012 14:08:20 +0100
Subject: [tei-council] Setting up read-only access to TEI Council list?
In-Reply-To: <4FB6B21A.70409@uvic.ca>
References: <alpine.OSX.2.00.1205180854250.24330@lister.ei.virginia.edu>
	<4FB64D6B.8050904@ultraslavonic.info>	<4FB65AED.20407@oucs.ox.ac.uk>
	<4FB661EE.6020307@uvic.ca> <4FB66336.3040401@kcl.ac.uk>
	<4FB69D7E.10100@o2.pl> <4FB6B21A.70409@uvic.ca>
Message-ID: <4FB79B44.2020308@kcl.ac.uk>

I agree with both Piotr and Martin's positions: that's exactly what I 
was trying to say by pointing out that setting up a parallel read-only 
email list was just like subscribing people to the Council list itself. 
(And makes me just as uncomfortable.)

I get the point about open government and all that (although that 
argument would apply much more aptly to Board than to Council, I 
contend), but we are open. It's one thing to say that all our 
discussions are archived and publicly accessible--and that some people 
do quite actively read the archives regularly--quite another to have 
potentially dozens of people receiving each email in their inbox in real 
time. I just don't see the point of it--if it were a sufficiently widely 
interesting conversation, we should being having it on TEI-L, shouldn't 
we? (And maybe a few of conversations that take place on this list 
should be on TEI-L...?)

Now if someone wants to set up a web-scraper on the TEI-Council archives 
and turn it into an RSS feed, and send each item in that feed to a 
separate email in their inbox, that's their look-in, and I have no 
objection to it. But inviting people onto the list in this way seems 
excessive, and not any better practice or especially pointful. And 
really the point is that a lot of what we talk about here is 
administrivia, effectively. The point of having a council list is that 
there's a small group of people who've committed to being happy to 
receive lots of emails on sometimes technical sometimes trivial topics 
and respond to them as appropriate. As Martin says, knowing that an 
email exchange is going to fill the inbox of up to a dozen people is 
quite comfortable; knowing that it could be many more changes the 
flavour of it somewhat. We have conversations here that wouldn't would 
have on TEI-L, precisely because hundreds of people don't want their 
inbox to ping every time.

It's nothing to do with privilege, or secrecy, or closed-meetings, I 
think it's just comfort and courtesy and good practice that the council 
list should be populated by the council (and a few invited or assigned 
others).

I rambled a bit in the middle there. I think I should have kept to the 
first and last paragraphs above.

G

On 18/05/2012 21:33, Martin Holmes wrote:
> On 12-05-18 12:05 PM, Piotr Ba?ski wrote:
>> Hi,
>>
>> I think it's one thing to provide public access to e-mail archives in
>> the interest of full openness, and another to know that all the e-mails
>> we write ->to the other members of the Council<- are obligatorily sent
>> into the mailboxes of other people. This seems to me to be pushing the
>> boundaries of good practice and politeness into the zone of politically
>> overcorrect exhibitionism, and I don't like the thought of being
>> involved in that.
>>
>> I don't write to "other people", when I write to this list -- I write to
>> the Council. When I want to write to other people, I use TEI-L, or, in
>> rare and I believe justified cases, CC them openly...
>
> I must admit I felt a little uneasy myself about this, but I couldn't
> pin down why; your post has clarified it a bit for me. I also wonder
> what the likely outcomes of this might be. When someone is subscribed to
> an email list, and reading it, they will inevitably feel at some point
> that they want to get involved in the conversation that's going on. The
> only ways open to a non-Council-member would be:
>
>    - email Council members directly, and ask that their opinions be
> injected into the discussion
>
>    - take the topic over to TEI-L, and invite the broader community to
> respond.
>
> Neither of these options seems like a good outcome to me, and both would
> be likely to derail or inhibit discussions on the Council list to some
> degree. We would most likely see contentious issues being discussed more
> off-list than on, through private email, and then they wouldn't be
> archived.
>
> I think I would write differently, and probably less frequently, if I
> felt the Council list was being distributed to a larger group of people,
> many of whom I didn't know. That feels somehow different from the
> discussion being archived at Virginia, although I'm not quite sure why.
>
> Cheers,
> Martin
>
>>
>> Thanks for considering this,
>>
>>     P.
>>
>> On 18/05/12 16:56, Gabriel BODARD wrote:
>>> Agreed. Not sure I like the idea of duplicating the list in any of the
>>> various ways suggested. If we're setting people up to be able to receive
>>> but not post, why not just make them moderated members of the existing
>>> list? It seems counter-intuitive, but it is identical in every way to
>>> what is being suggested with the "outsiders" list.
>>>
>>> Is there a technically easy way to set up an RSS feed from the archives?
>>> Easier than web-scraping, I mean, for which there must exist tools
>>> already...
>>>
>>> G
>>>
>>> On 18/05/2012 15:51, Martin Holmes wrote:
>>>>
>>>> On 12-05-18 07:21 AM, James Cummings wrote:
>>>>> On 18/05/12 14:23, Kevin Hawkins wrote:
>>>>>> a) Add as a member of tei-council an address like
>>>>>> council-outsiders at lists.village.virginia.edu , which we would advertise
>>>>>> so that those interested could subscribe.  Members of that list would
>>>>>> receive messages sent to tei-council, and we would trust that they
>>>>>> wouldn't ever send a message to tei-council with
>>>>>> "council-outsiders at lists.village.virginia.edu" as the sender in order to
>>>>>> post.
>>>>>
>>>>> They could most likely be set to not having posting abilities (or
>>>>> their posts to be moderated).
>>>>>
>>>>>> b) Add as a member of tei-council some email address hooked up to an
>>>>>> email-to-RSS service and then publicize the feed URL.
>>>>>> The advantage to (a) is that it allows threading of messages, whereas
>>>>>> feeds (b) do not.  But (a) would also create an entirely duplicated
>>>>>> message archive.
>>>>>
>>>>> Wouldn't another option be to get the mailing list archived by
>>>>> one of the services which currently archive the TEI-L mailing list?
>>>>
>>>> I thought the archives were already public here:
>>>>
>>>> <http://lists.village.virginia.edu/pipermail/tei-council/2012/date.html#start>
>>>>
>>>> I don't see much point in duplicating the archive, unless the
>>>> alternative site has better searching and browsing functionality.
>>>>
>>>> Cheers,
>>>> Martin
>>>>
>>>>
>>>
>>

-- 
Dr Gabriel BODARD
(Research Associate in Digital Epigraphy)

Department of Digital Humanities
King's College London
26-29 Drury Lane
London WC2B 5RL

Email: gabriel.bodard at kcl.ac.uk
Tel: +44 (0)20 7848 1388
Fax: +44 (0)20 7848 2980

http://www.digitalclassicist.org/
http://www.currentepigraphy.org/

From syeates at gmail.com  Sat May 19 16:50:37 2012
From: syeates at gmail.com (stuart yeates)
Date: Sun, 20 May 2012 08:50:37 +1200
Subject: [tei-council] Setting up read-only access to TEI Council list?
In-Reply-To: <4FB79B44.2020308@kcl.ac.uk>
References: <alpine.OSX.2.00.1205180854250.24330@lister.ei.virginia.edu>
	<4FB64D6B.8050904@ultraslavonic.info>	<4FB65AED.20407@oucs.ox.ac.uk>
	<4FB661EE.6020307@uvic.ca> <4FB66336.3040401@kcl.ac.uk>
	<4FB69D7E.10100@o2.pl> <4FB6B21A.70409@uvic.ca>
	<4FB79B44.2020308@kcl.ac.uk>
Message-ID: <4FB8079D.8040208@gmail.com>

On 20/05/12 01:08, Gabriel BODARD wrote:
> I agree with both Piotr and Martin's positions: that's exactly what I
> was trying to say by pointing out that setting up a parallel read-only
> email list was just like subscribing people to the Council list itself.
> (And makes me just as uncomfortable.)

I pretty much agree with Piotr, Martin an Gabriel, however I note that 
Christof (or David on Christof's behalf) does not appear to have given a 
motivation for wanting access.

I'm going to say no, unless some compelling motivation is bought forward 
to overcome the opposition already expressed.

cheers
stuart



From rwelzenbach at gmail.com  Sun May 20 10:51:42 2012
From: rwelzenbach at gmail.com (Rebecca Welzenbach)
Date: Sun, 20 May 2012 10:51:42 -0400
Subject: [tei-council] Setting up read-only access to TEI Council list?
In-Reply-To: <4FB8079D.8040208@gmail.com>
References: <alpine.OSX.2.00.1205180854250.24330@lister.ei.virginia.edu>
	<4FB64D6B.8050904@ultraslavonic.info>
	<4FB65AED.20407@oucs.ox.ac.uk> <4FB661EE.6020307@uvic.ca>
	<4FB66336.3040401@kcl.ac.uk> <4FB69D7E.10100@o2.pl>
	<4FB6B21A.70409@uvic.ca> <4FB79B44.2020308@kcl.ac.uk>
	<4FB8079D.8040208@gmail.com>
Message-ID: <CAA2irtLR74aaA3SHz-o7Rip8ex36=1rdSCH5LVi-taOX9v7X1Q@mail.gmail.com>

 I take Kevin's point that even though the Council archives are
publicly accessible, by making it less convenient than it might be to
access them, we're rather violating the spirit of open government.

Nevertheless, I agree with Piotr, Martin, Gaby, and Stuart. Not
because messages to this list might land in other people's inboxes,
but because this violates my expectation of how email lists work. When
subscribing to a list that is structured as a conversation, not just
one-way blasts, I generally expect to be able to participate, even if
moderated. Since that wouldn't typically be case here, I suspect this
is likely to confuse and frustrate people.

Kevin made an analogy to the public being able to attend a city
council meeting, but only having the opportunity/right to address the
council if invited to do so. But in that setting, the boundaries are
clear: an audience watching and listening to those at the front of the
room. To me, both an open email archive and a feed set up a similarly
clear expectation/boundary (so I'm all in favor of those), while
actually allowing non-members to subscribe to the list obscures it.

Something I've learned from representing the TCP: don't put yourself
in a position to constantly have to explain to people that they can't
do what they expect to be able to do. It totally outweighs any
goodwill that you hope to build up by being conveniently transparent.
Operating by one set of rules in a medium that usually abides by a
different set of rules seems to invite headaches on all sides.

I'm very willing to be convinced otherwise if I'm wrong about how
unusual this is, and there's precedent for sharing and following email
business in this way. Otherwise it seems rather like a city council
member coming to your home to tell you about a new proposal, but then
not letting you respond without permission.

Sorry for the rambling....
Becky

On Sat, May 19, 2012 at 4:50 PM, stuart yeates <syeates at gmail.com> wrote:
> On 20/05/12 01:08, Gabriel BODARD wrote:
>> I agree with both Piotr and Martin's positions: that's exactly what I
>> was trying to say by pointing out that setting up a parallel read-only
>> email list was just like subscribing people to the Council list itself.
>> (And makes me just as uncomfortable.)
>
> I pretty much agree with Piotr, Martin an Gabriel, however I note that
> Christof (or David on Christof's behalf) does not appear to have given a
> motivation for wanting access.
>
> I'm going to say no, unless some compelling motivation is bought forward
> to overcome the opposition already expressed.
>
> cheers
> stuart
>
>
> --
> tei-council mailing list
> tei-council at lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>
> PLEASE NOTE: postings to this list are publicly archived

From kevin.s.hawkins at ultraslavonic.info  Sun May 20 13:10:04 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Sun, 20 May 2012 13:10:04 -0400
Subject: [tei-council] Setting up read-only access to TEI Council list?
In-Reply-To: <CAA2irtLR74aaA3SHz-o7Rip8ex36=1rdSCH5LVi-taOX9v7X1Q@mail.gmail.com>
References: <alpine.OSX.2.00.1205180854250.24330@lister.ei.virginia.edu>	<4FB64D6B.8050904@ultraslavonic.info>	<4FB65AED.20407@oucs.ox.ac.uk>
	<4FB661EE.6020307@uvic.ca>	<4FB66336.3040401@kcl.ac.uk>
	<4FB69D7E.10100@o2.pl>	<4FB6B21A.70409@uvic.ca>
	<4FB79B44.2020308@kcl.ac.uk>	<4FB8079D.8040208@gmail.com>
	<CAA2irtLR74aaA3SHz-o7Rip8ex36=1rdSCH5LVi-taOX9v7X1Q@mail.gmail.com>
Message-ID: <4FB9256C.7090703@ultraslavonic.info>

No need to apologize, Becky.

So, a few of us have objected to tei-council postings being pushed to 
users.  If I may generalize, it seems we are concerned about confused 
expectations: both (a) on the part of Council members in knowing that 
their conversations are more broadly exposed and (b) on the part of 
potential readers in being confused about the ability to participate in 
the discussions.

David mentions that Virginia's current mailing list system is Sympa; the 
tei-council list has been running on a legacy system.  While David said 
he would investigate moving tei-council to Sympa (which supports an RSS 
feed of postings), even if we ask him not to do this at this time, I 
think we can assume that the list will be moved to Sympa or another 
future system someday, and that this system will likely have RSS (or 
some sort of Linked Data) support, allowing users access to content in a 
way that's more convenient than the web interface in the current system.

Keeping in mind this eventuality, how would those who've objected feel 
if tei-council messages were available through an RSS feed?  In my 
opinion, if we can expose our postings in a way that doesn't involve 
messages coming to an email inbox (such as through an RSS feed), then 
concern (b) goes away.

--Kevin

From sebastian.rahtz at oucs.ox.ac.uk  Sun May 20 13:29:13 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Sun, 20 May 2012 17:29:13 +0000
Subject: [tei-council] Setting up read-only access to TEI Council list?
In-Reply-To: <4FB9256C.7090703@ultraslavonic.info>
References: <alpine.OSX.2.00.1205180854250.24330@lister.ei.virginia.edu>
	<4FB64D6B.8050904@ultraslavonic.info>	<4FB65AED.20407@oucs.ox.ac.uk>
	<4FB661EE.6020307@uvic.ca>	<4FB66336.3040401@kcl.ac.uk>
	<4FB69D7E.10100@o2.pl>	<4FB6B21A.70409@uvic.ca>	<4FB79B44.2020308@kcl.ac.uk>
	<4FB8079D.8040208@gmail.com>
	<CAA2irtLR74aaA3SHz-o7Rip8ex36=1rdSCH5LVi-taOX9v7X1Q@mail.gmail.com>,
	<4FB9256C.7090703@ultraslavonic.info>
Message-ID: <9A1F0C47-2555-40D8-88C2-E627D08C9467@oucs.ox.ac.uk>

Exposure as RSS is a bit weird for email. But, agreed, better than pseudo-subscription and the funny expectations that raises

Carved in stone on my iPad


From kevin.s.hawkins at ultraslavonic.info  Sun May 20 15:47:26 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Sun, 20 May 2012 15:47:26 -0400
Subject: [tei-council] soft deprecation of @key
Message-ID: <4FB94A4E.2040206@ultraslavonic.info>

All,

At last, I've implemented http://purl.org/TEI/fr/3437509.  See the "text 
changed" links at in case you're interested:

http://tei.svn.sourceforge.net/viewvc/tei?view=revision&revision=10374

Lou, over to you to review.

--Kevin

From kevin.s.hawkins at ultraslavonic.info  Sun May 20 16:04:02 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Sun, 20 May 2012 16:04:02 -0400
Subject: [tei-council] @xml:lang on <egXML>
Message-ID: <4FB94E32.4000506@ultraslavonic.info>

While implementing that ticket, I found a couple of <egXML>s in 
CO-CoreElements.xml which have xml:lang="en" but whose text isn't in 
English.  It seems like an error, but it also seems so obvious that I'm 
wondering if @xml:lang serves a special purpose on <egXML> having to do 
with Guidelines internationalization.  Could anyone shed light on this?

From James.Cummings at oucs.ox.ac.uk  Sun May 20 16:31:52 2012
From: James.Cummings at oucs.ox.ac.uk (James Cummings)
Date: Sun, 20 May 2012 21:31:52 +0100
Subject: [tei-council] Setting up read-only access to TEI Council list?
In-Reply-To: <9A1F0C47-2555-40D8-88C2-E627D08C9467@oucs.ox.ac.uk>
References: <alpine.OSX.2.00.1205180854250.24330@lister.ei.virginia.edu>
	<4FB64D6B.8050904@ultraslavonic.info>	<4FB65AED.20407@oucs.ox.ac.uk>
	<4FB661EE.6020307@uvic.ca>	<4FB66336.3040401@kcl.ac.uk>
	<4FB69D7E.10100@o2.pl>	<4FB6B21A.70409@uvic.ca>	<4FB79B44.2020308@kcl.ac.uk>
	<4FB8079D.8040208@gmail.com>
	<CAA2irtLR74aaA3SHz-o7Rip8ex36=1rdSCH5LVi-taOX9v7X1Q@mail.gmail.com>,
	<4FB9256C.7090703@ultraslavonic.info>
	<9A1F0C47-2555-40D8-88C2-E627D08C9467@oucs.ox.ac.uk>
Message-ID: <4FB954B8.6040003@oucs.ox.ac.uk>


It seems like we're coming to a consensus that:
- We want the council list to be readable by anyone (as it 
currently is) and archived
- We are willing to have it exposed as RSS/Atom for those who do 
want a 'feed' of some sort
- We _don't_ want a second mailing list or subscribers with 
moderation flags set, or things like that.

So, in the up-shot, no immediate change necessary but if DavidS 
does migrate us to Sympa and so RSS available, then that is all 
well and good.

-James


On 20/05/12 18:29, Sebastian Rahtz wrote:
> Exposure as RSS is a bit weird for email. But, agreed, better than pseudo-subscription and the funny expectations that raises
>
> Carved in stone on my iPad
>


-- 
Dr James Cummings, InfoDev
Oxford University Computing Services
University of Oxford

From James.Cummings at oucs.ox.ac.uk  Sun May 20 16:47:02 2012
From: James.Cummings at oucs.ox.ac.uk (James Cummings)
Date: Sun, 20 May 2012 21:47:02 +0100
Subject: [tei-council] next release?
In-Reply-To: <4F986673.7020201@kcl.ac.uk>
References: <0F18A249-5480-42D9-BFF2-538AC7B9E1EB@oucs.ox.ac.uk>
	<4F92F34D.2040103@uvic.ca>	<4F9579A0.8010002@oucs.ox.ac.uk>
	<4F95C7A1.1080707@o2.pl> <4F96756B.1060202@oucs.ox.ac.uk>
	<4F986673.7020201@kcl.ac.uk>
Message-ID: <4FB95846.7080308@oucs.ox.ac.uk>


Hi all,

I think events have caught up with us and that May 25th deadline 
is looming.  I know I've barely chipped the surface of things 
assigned to me, and the meeting minutes are still coming (almost 
there I'm told).  I propose that we push back the next release 
until the week ending 15 June.  Does that seem unreasonable for 
anyone, or any counter proposals?

-James

On 25/04/12 22:02, Gabriel BODARD wrote:
> The first week of June is likely to be bad for me; I'm back from
> international travel around the 4th, I think, and will be groggy the
> first couple days after that. So if not May 25th, then best to put it
> off by two weeks. (Or someone else be launch technician...)
>
> G
>
> On 24/04/2012 10:42, James Cummings wrote:
>>
>> What do others think? We can of course move releasing back to
>> whenever we've finished a majority of tickets, but I'd prefer
>> sooner rather than later and a deadline that forces us to get
>> stuff done.
>>
>> I'm of the opinion that we probably don't need to telco before
>> this release (we can, after all, conduct business on the mailing
>> list), but would do so shortly after the release to get updates
>> on the longer-term issues and reports from the council working
>> groups.
>>
>> thoughts?
>>
>> -James
>>
>>
>> On 23/04/12 22:20, Piotr Ba?ski wrote:
>>> Hi James,
>>>
>>> Isn't May 25 roughly in the middle of LREC? Could we shift by a week
>>> from then, please?
>>>
>>> (I actually intend to be ready with my stuff [and possibly more] in
>>> advance this time, but I've made some such totally honest promises to
>>> myself and to the world recently, several times, and with meager results...)
>>>
>>> Ah. Will we telco before releasing?
>>>
>>> Best,
>>>
>>>      P.
>>>
>>>
>>>
>>> On 23/04/12 17:47, James Cummings wrote:
>>>>
>>>> How about we set a notional target release date of 25 May?  (This
>>>> is about 5 weeks from now.) If we assume that we want most things
>>>> completed by the end of Sunday 20th, to allow time for
>>>> proofreading and error spotting.
>>>>
>>>> Does that sounds reasonable to most people?
>>>>
>>>> Gaby: Most importantly, does the proposed Release Technician like
>>>> these dates?
>>>>
>>>> -James
>>>>
>>>>
>>>> On 21/04/12 18:50, Martin Holmes wrote:
>>>>> Three weeks will be a bit tough for me, and a couple of the tickets I
>>>>> have might turn out to have unpredicted side-effects (like the tei_
>>>>> prefix). As long as we have the option to launch without the change if
>>>>> it proves difficult, we could go with three weeks.
>>>>>
>>>>> The attributes-without-examples problem is so large that we'll just have
>>>>> to hack away at it steadily.
>>>>>
>>>>> Cheers,
>>>>> Martin
>>>>>
>>>>> On 12-04-21 04:03 AM, Sebastian Rahtz wrote:
>>>>>> something we forgot to debate in Ann Arbor was a timetable
>>>>>> for the next release, I think? i.e. what is the due date for
>>>>>> everyone to complete their ticket work so that Sir Gabriel
>>>>>> of B'odard can undertake his Quest.
>>>>>>
>>>>>> speaking for myself, if I don't do my assignments
>>>>>> more or less immediately I will not get to them for ages,
>>>>>> so I favour a short window (say, 3 weeks).
>>>>>>
>>>>>> Sebastian
>>>>
>>>>
>>>
>>
>>
>


-- 
Dr James Cummings, InfoDev
Oxford University Computing Services
University of Oxford

From lou.burnard at retired.ox.ac.uk  Sun May 20 17:17:06 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Sun, 20 May 2012 22:17:06 +0100
Subject: [tei-council] soft deprecation of @key
In-Reply-To: <4FB94A4E.2040206@ultraslavonic.info>
References: <4FB94A4E.2040206@ultraslavonic.info>
Message-ID: <4FB95F52.70602@retired.ox.ac.uk>

On 20/05/12 20:47, Kevin Hawkins wrote:
> All,
>
> At last, I've implemented http://purl.org/TEI/fr/3437509.  See the "text
> changed" links at in case you're interested:
>
> http://tei.svn.sourceforge.net/viewvc/tei?view=revision&revision=10374
>
> Lou, over to you to review.
>
> --Kevin


Well, I think the proposed wording might be improved. The reference to 
<taxonomy> seems irrelevant -- if you use that, you'd use @ref to point 
at entries in it. And the term "magic token" is probably best not 
eternalised (magic cookie I've never heard of before -- it invites 
confusion with the other sorts of cookie.

Here's a suggested revision for the following passage added to CO :


"Since the value of the <att>key</att> attribute does not follow any 
standard syntax, can only be deciphered by a human reader (possibly by 
consulting the <gi>taxonomy</gi> element in the TEI header), and could 
coincide with a value used by another project, such <term>magic 
tokens</term> or <term>magic cookies</term> should be avoided. A 
preferred ..."


No particular syntax is proposed for the values of the <att>key</att> 
attribute, since its form will depend entirely on practice within a 
given project. For the same reason, this attribute is not recommended in 
data interchange, since there is no way of ensuring that the values used 
by one project are distinct from those used by another. In such a 
situation, a preferable ...



From kevin.s.hawkins at ultraslavonic.info  Sun May 20 17:39:10 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Sun, 20 May 2012 17:39:10 -0400
Subject: [tei-council] soft deprecation of @key
In-Reply-To: <4FB95F52.70602@retired.ox.ac.uk>
References: <4FB94A4E.2040206@ultraslavonic.info>
	<4FB95F52.70602@retired.ox.ac.uk>
Message-ID: <4FB9647E.9000901@ultraslavonic.info>

On 5/20/2012 5:17 PM, Lou Burnard wrote:
> On 20/05/12 20:47, Kevin Hawkins wrote:
>> All,
>>
>> At last, I've implemented http://purl.org/TEI/fr/3437509.  See the "text
>> changed" links at in case you're interested:
>>
>> http://tei.svn.sourceforge.net/viewvc/tei?view=revision&revision=10374
>>
>> Lou, over to you to review.
>>
>> --Kevin
>
>
> Well, I think the proposed wording might be improved. The reference to
> <taxonomy>  seems irrelevant -- if you use that, you'd use @ref to point
> at entries in it.

But couldn't someone use <taxonomy> to define a controlled vocabulary of 
terms used in @key throughout the document?  Why can only a @ref point 
to <taxonomy>?

 > And the term "magic token" is probably best not
> eternalised (magic cookie I've never heard of before -- it invites
> confusion with the other sorts of cookie.

I was taking a cue from:

http://wiki.tei-c.org/index.php/TEI-Council-FAQ#What_is_a_.22magic_token.22.3F

in which Stuart helpfully added a link to the Wikipedia page on "magic 
cookie".  It appears that in computer science, people call it that.  It 
seems that we should acknowledge the terminology of this community.

> Here's a suggested revision for the following passage added to CO :
>
>
> "Since the value of the<att>key</att>  attribute does not follow any
> standard syntax, can only be deciphered by a human reader (possibly by
> consulting the<gi>taxonomy</gi>  element in the TEI header), and could
> coincide with a value used by another project, such<term>magic
> tokens</term>  or<term>magic cookies</term>  should be avoided. A
> preferred ..."
>
>
> No particular syntax is proposed for the values of the<att>key</att>
> attribute, since its form will depend entirely on practice within a
> given project. For the same reason, this attribute is not recommended in
> data interchange, since there is no way of ensuring that the values used
> by one project are distinct from those used by another. In such a
> situation, a preferable ...

I prefer the stronger guidance in my version.  In yours, you say "in 
such a situation" (of data interchange) as if the TEI isn't always meant 
to promote data interchange.

--K.

From lou.burnard at retired.ox.ac.uk  Sun May 20 17:55:05 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Sun, 20 May 2012 22:55:05 +0100
Subject: [tei-council] soft deprecation of @key
In-Reply-To: <4FB9647E.9000901@ultraslavonic.info>
References: <4FB94A4E.2040206@ultraslavonic.info>
	<4FB95F52.70602@retired.ox.ac.uk>
	<4FB9647E.9000901@ultraslavonic.info>
Message-ID: <4FB96839.8090101@retired.ox.ac.uk>

On 20/05/12 22:39, Kevin Hawkins wrote:
> On 5/20/2012 5:17 PM, Lou Burnard wrote:
>> On 20/05/12 20:47, Kevin Hawkins wrote:
>>> All,
>>>
>>> At last, I've implemented http://purl.org/TEI/fr/3437509.  See the "text
>>> changed" links at in case you're interested:
>>>
>>> http://tei.svn.sourceforge.net/viewvc/tei?view=revision&revision=10374
>>>
>>> Lou, over to you to review.
>>>
>>> --Kevin
>>
>>
>> Well, I think the proposed wording might be improved. The reference to
>> <taxonomy>   seems irrelevant -- if you use that, you'd use @ref to point
>> at entries in it.
>
> But couldn't someone use<taxonomy>  to define a controlled vocabulary of
> terms used in @key throughout the document?

I suppose they could, though properly speaking <taxonomy> is for 
classification, not just controlled vocabulary.

  Why can only a @ref point
> to<taxonomy>?

My point was that if you *have* gone to the trouble of defining all your 
terms in a taxonomy, there's nothing to be gained by not using the 
simpler @ref="#foo" type syntax.


>
>   >  And the term "magic token" is probably best not
>> eternalised (magic cookie I've never heard of before -- it invites
>> confusion with the other sorts of cookie.
>
> I was taking a cue from:
>
> http://wiki.tei-c.org/index.php/TEI-Council-FAQ#What_is_a_.22magic_token.22.3F
>
> in which Stuart helpfully added a link to the Wikipedia page on "magic
> cookie".  It appears that in computer science, people call it that.  It
> seems that we should acknowledge the terminology of this community.

I'd rather not since that's not really our target community, but if you 
insist, I'd use that term only, and maybe reference the Wikipedia page.

>>
>> No particular syntax is proposed for the values of the<att>key</att>
>> attribute, since its form will depend entirely on practice within a
>> given project. For the same reason, this attribute is not recommended in
>> data interchange, since there is no way of ensuring that the values used
>> by one project are distinct from those used by another. In such a
>> situation, a preferable ...
>
> I prefer the stronger guidance in my version.  In yours, you say "in
> such a situation" (of data interchange) as if the TEI isn't always meant
> to promote data interchange.

Well, this may be something we have to agree to differ on. Although TEI 
is of course primarily for data interchange, it's not exclusively so.

I think of @key values as being like the PUA in Unicode -- they're 
useful, but you need to know what the risks of using them are.

By the way, did we actually agree to translate *every single one* of the 
@key instances into @ref:tag:wibble,foo ones? I thought we'd agreed to 
keep some, to show that the old methods were still usable.

From mholmes at uvic.ca  Sun May 20 20:09:02 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Sun, 20 May 2012 17:09:02 -0700
Subject: [tei-council] next release?
In-Reply-To: <4FB95846.7080308@oucs.ox.ac.uk>
References: <0F18A249-5480-42D9-BFF2-538AC7B9E1EB@oucs.ox.ac.uk>
	<4F92F34D.2040103@uvic.ca>	<4F9579A0.8010002@oucs.ox.ac.uk>
	<4F95C7A1.1080707@o2.pl> <4F96756B.1060202@oucs.ox.ac.uk>
	<4F986673.7020201@kcl.ac.uk> <4FB95846.7080308@oucs.ox.ac.uk>
Message-ID: <4FB9879E.5080702@uvic.ca>

That's great for me. I've been more or less AWOL for the last few weeks 
because I've been doing a course, which is just winding up. I'll be able 
to get some TEI work done in the next few weeks.

Cheers,
Martin

On 12-05-20 01:47 PM, James Cummings wrote:
>
> Hi all,
>
> I think events have caught up with us and that May 25th deadline
> is looming.  I know I've barely chipped the surface of things
> assigned to me, and the meeting minutes are still coming (almost
> there I'm told).  I propose that we push back the next release
> until the week ending 15 June.  Does that seem unreasonable for
> anyone, or any counter proposals?
>
> -James
>
> On 25/04/12 22:02, Gabriel BODARD wrote:
>> The first week of June is likely to be bad for me; I'm back from
>> international travel around the 4th, I think, and will be groggy the
>> first couple days after that. So if not May 25th, then best to put it
>> off by two weeks. (Or someone else be launch technician...)
>>
>> G
>>
>> On 24/04/2012 10:42, James Cummings wrote:
>>>
>>> What do others think? We can of course move releasing back to
>>> whenever we've finished a majority of tickets, but I'd prefer
>>> sooner rather than later and a deadline that forces us to get
>>> stuff done.
>>>
>>> I'm of the opinion that we probably don't need to telco before
>>> this release (we can, after all, conduct business on the mailing
>>> list), but would do so shortly after the release to get updates
>>> on the longer-term issues and reports from the council working
>>> groups.
>>>
>>> thoughts?
>>>
>>> -James
>>>
>>>
>>> On 23/04/12 22:20, Piotr Ba?ski wrote:
>>>> Hi James,
>>>>
>>>> Isn't May 25 roughly in the middle of LREC? Could we shift by a week
>>>> from then, please?
>>>>
>>>> (I actually intend to be ready with my stuff [and possibly more] in
>>>> advance this time, but I've made some such totally honest promises to
>>>> myself and to the world recently, several times, and with meager results...)
>>>>
>>>> Ah. Will we telco before releasing?
>>>>
>>>> Best,
>>>>
>>>>       P.
>>>>
>>>>
>>>>
>>>> On 23/04/12 17:47, James Cummings wrote:
>>>>>
>>>>> How about we set a notional target release date of 25 May?  (This
>>>>> is about 5 weeks from now.) If we assume that we want most things
>>>>> completed by the end of Sunday 20th, to allow time for
>>>>> proofreading and error spotting.
>>>>>
>>>>> Does that sounds reasonable to most people?
>>>>>
>>>>> Gaby: Most importantly, does the proposed Release Technician like
>>>>> these dates?
>>>>>
>>>>> -James
>>>>>
>>>>>
>>>>> On 21/04/12 18:50, Martin Holmes wrote:
>>>>>> Three weeks will be a bit tough for me, and a couple of the tickets I
>>>>>> have might turn out to have unpredicted side-effects (like the tei_
>>>>>> prefix). As long as we have the option to launch without the change if
>>>>>> it proves difficult, we could go with three weeks.
>>>>>>
>>>>>> The attributes-without-examples problem is so large that we'll just have
>>>>>> to hack away at it steadily.
>>>>>>
>>>>>> Cheers,
>>>>>> Martin
>>>>>>
>>>>>> On 12-04-21 04:03 AM, Sebastian Rahtz wrote:
>>>>>>> something we forgot to debate in Ann Arbor was a timetable
>>>>>>> for the next release, I think? i.e. what is the due date for
>>>>>>> everyone to complete their ticket work so that Sir Gabriel
>>>>>>> of B'odard can undertake his Quest.
>>>>>>>
>>>>>>> speaking for myself, if I don't do my assignments
>>>>>>> more or less immediately I will not get to them for ages,
>>>>>>> so I favour a short window (say, 3 weeks).
>>>>>>>
>>>>>>> Sebastian
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>
>

From dsewell at virginia.edu  Sun May 20 20:45:51 2012
From: dsewell at virginia.edu (David Sewell)
Date: Sun, 20 May 2012 20:45:51 -0400 (EDT)
Subject: [tei-council] Setting up read-only access to TEI Council list?
In-Reply-To: <4FB8079D.8040208@gmail.com>
References: <alpine.OSX.2.00.1205180854250.24330@lister.ei.virginia.edu>
	<4FB64D6B.8050904@ultraslavonic.info>
	<4FB65AED.20407@oucs.ox.ac.uk> <4FB661EE.6020307@uvic.ca>
	<4FB66336.3040401@kcl.ac.uk> <4FB69D7E.10100@o2.pl>
	<4FB6B21A.70409@uvic.ca>
	<4FB79B44.2020308@kcl.ac.uk> <4FB8079D.8040208@gmail.com>
Message-ID: <alpine.OSX.2.00.1205202042470.11880@koson.local>

On Sun, 20 May 2012, stuart yeates wrote:

> I pretty much agree with Piotr, Martin an Gabriel, however I note that
> Christof (or David on Christof's behalf) does not appear to have given a
> motivation for wanting access.

I didn't ask him specifically why he was interested. He is an active 
user of TEI, but of course many people are in that category.

-- 
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 kevin.s.hawkins at ultraslavonic.info  Sun May 20 21:43:45 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Sun, 20 May 2012 21:43:45 -0400
Subject: [tei-council] soft deprecation of @key
In-Reply-To: <4FB96839.8090101@retired.ox.ac.uk>
References: <4FB94A4E.2040206@ultraslavonic.info>
	<4FB95F52.70602@retired.ox.ac.uk>
	<4FB9647E.9000901@ultraslavonic.info>
	<4FB96839.8090101@retired.ox.ac.uk>
Message-ID: <4FB99DD1.8080204@ultraslavonic.info>

On 5/20/12 5:55 PM, Lou Burnard wrote:
>    Why can only a @ref point
>> to<taxonomy>?
>
> My point was that if you *have* gone to the trouble of defining all your
> terms in a taxonomy, there's nothing to be gained by not using the
> simpler @ref="#foo" type syntax.

I was thinking of a case like:

<persName key="lccn-n78-95332">Shakespeare, William, 1564-1616</persName>

<taxonomy xml:id="lccn">
   <bibl>Library of Congress Control Number</bibl>
</taxonomy>

While not machine-processable, it provides some information to help to 
help a human reader figure out the encoding.

>>    >   And the term "magic token" is probably best not
>>> eternalised (magic cookie I've never heard of before -- it invites
>>> confusion with the other sorts of cookie.
>>
>> I was taking a cue from:
>>
>> http://wiki.tei-c.org/index.php/TEI-Council-FAQ#What_is_a_.22magic_token.22.3F
>>
>> in which Stuart helpfully added a link to the Wikipedia page on "magic
>> cookie".  It appears that in computer science, people call it that.  It
>> seems that we should acknowledge the terminology of this community.
>
> I'd rather not since that's not really our target community, but if you
> insist, I'd use that term only, and maybe reference the Wikipedia page.

Well, our community uses the other term, so it would be a disservice not 
to use our own term here as well.  How about instead of "A or B" we had 
"A (also known as B)"?

>>> No particular syntax is proposed for the values of the<att>key</att>
>>> attribute, since its form will depend entirely on practice within a
>>> given project. For the same reason, this attribute is not recommended in
>>> data interchange, since there is no way of ensuring that the values used
>>> by one project are distinct from those used by another. In such a
>>> situation, a preferable ...
>>
>> I prefer the stronger guidance in my version.  In yours, you say "in
>> such a situation" (of data interchange) as if the TEI isn't always meant
>> to promote data interchange.
>
> Well, this may be something we have to agree to differ on. Although TEI
> is of course primarily for data interchange, it's not exclusively so.
>
> I think of @key values as being like the PUA in Unicode -- they're
> useful, but you need to know what the risks of using them are.
>
> By the way, did we actually agree to translate *every single one* of the
> @key instances into @ref:tag:wibble,foo ones? I thought we'd agreed to
> keep some, to show that the old methods were still usable.

We did not agree to translate every single one, and I did not in fact 
translate every single one.  according to the minutes from Paris, "We 
should modify the Guidelines to make the point that people should switch 
to @ref wherever @key is mentioned."  The ones I left were cases where:

* usage of @key is being illustrated
* instances in which the value of @key was a known public scheme, like 
<country key="FR"/> (per decision in Ann Arbor)

From sebastian.rahtz at oucs.ox.ac.uk  Mon May 21 04:04:19 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Mon, 21 May 2012 08:04:19 +0000
Subject: [tei-council] @xml:lang on <egXML>
In-Reply-To: <4FB94E32.4000506@ultraslavonic.info>
References: <4FB94E32.4000506@ultraslavonic.info>
Message-ID: <4599AA59-5E2B-47AB-BADC-FAA02F47E52E@oucs.ox.ac.uk>


On 20 May 2012, at 21:04, Kevin Hawkins wrote:

> While implementing that ticket, I found a couple of <egXML>s in 
> CO-CoreElements.xml which have xml:lang="en" but whose text isn't in 
> English.  It seems like an error, but it also seems so obvious that I'm 
> wondering if @xml:lang serves a special purpose on <egXML> having to do 
> with Guidelines internationalization.  Could anyone shed light on this?

sounds like an error to me. yes, the @xml:lang is used to produce the
I18ned outputs, but only in the way you'd expect.

which examples are they?

--
Sebastian Rahtz      
Head of Information and Support Group
Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431

S?lo le pido a Dios
que el futuro no me sea indiferente


From kevin.s.hawkins at ultraslavonic.info  Mon May 21 08:31:00 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Mon, 21 May 2012 08:31:00 -0400
Subject: [tei-council] @xml:lang on <egXML>
In-Reply-To: <4599AA59-5E2B-47AB-BADC-FAA02F47E52E@oucs.ox.ac.uk>
References: <4FB94E32.4000506@ultraslavonic.info>
	<4599AA59-5E2B-47AB-BADC-FAA02F47E52E@oucs.ox.ac.uk>
Message-ID: <4FBA3584.4060903@ultraslavonic.info>

On 5/21/2012 4:04 AM, Sebastian Rahtz wrote:
>
> On 20 May 2012, at 21:04, Kevin Hawkins wrote:
>
>> While implementing that ticket, I found a couple of<egXML>s in
>> CO-CoreElements.xml which have xml:lang="en" but whose text isn't in
>> English.  It seems like an error, but it also seems so obvious that I'm
>> wondering if @xml:lang serves a special purpose on<egXML>  having to do
>> with Guidelines internationalization.  Could anyone shed light on this?
>
> sounds like an error to me. yes, the @xml:lang is used to produce the
> I18ned outputs, but only in the way you'd expect.
>
> which examples are they?

See the "Mein Frisch schwebt" (once) and "Mme. de Volanges" examples 
(twice).

From gabriel.bodard at kcl.ac.uk  Mon May 21 09:06:50 2012
From: gabriel.bodard at kcl.ac.uk (Gabriel BODARD)
Date: Mon, 21 May 2012 14:06:50 +0100
Subject: [tei-council] @xml:lang on <egXML>
In-Reply-To: <4599AA59-5E2B-47AB-BADC-FAA02F47E52E@oucs.ox.ac.uk>
References: <4FB94E32.4000506@ultraslavonic.info>
	<4599AA59-5E2B-47AB-BADC-FAA02F47E52E@oucs.ox.ac.uk>
Message-ID: <4FBA3DEA.30401@kcl.ac.uk>

You may also find there are a couple of Greek or Latin examples (drawn 
from inscriptions) which say @xml:lang='en'. I meant to ask about this 
at the time, but assuming there is no 'la' or 'grc' internationalization 
of TEI, anything tagged thus would never appear, would it?

Just wondering...

G

On 21/05/2012 09:04, Sebastian Rahtz wrote:
>
> On 20 May 2012, at 21:04, Kevin Hawkins wrote:
>
>> While implementing that ticket, I found a couple of<egXML>s in
>> CO-CoreElements.xml which have xml:lang="en" but whose text isn't in
>> English.  It seems like an error, but it also seems so obvious that I'm
>> wondering if @xml:lang serves a special purpose on<egXML>  having to do
>> with Guidelines internationalization.  Could anyone shed light on this?
>
> sounds like an error to me. yes, the @xml:lang is used to produce the
> I18ned outputs, but only in the way you'd expect.
>
> which examples are they?
>
> --
> Sebastian Rahtz
> Head of Information and Support Group
> Oxford University Computing Services
> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>
> S?lo le pido a Dios
> que el futuro no me sea indiferente
>

-- 
Dr Gabriel BODARD
(Research Associate in Digital Epigraphy)

Department of Digital Humanities
King's College London
26-29 Drury Lane
London WC2B 5RL

Email: gabriel.bodard at kcl.ac.uk
Tel: +44 (0)20 7848 1388
Fax: +44 (0)20 7848 2980

http://www.digitalclassicist.org/
http://www.currentepigraphy.org/

From gabriel.bodard at kcl.ac.uk  Mon May 21 09:11:03 2012
From: gabriel.bodard at kcl.ac.uk (Gabriel BODARD)
Date: Mon, 21 May 2012 14:11:03 +0100
Subject: [tei-council] Setting up read-only access to TEI Council list?
In-Reply-To: <4FB954B8.6040003@oucs.ox.ac.uk>
References: <alpine.OSX.2.00.1205180854250.24330@lister.ei.virginia.edu>
	<4FB64D6B.8050904@ultraslavonic.info>	<4FB65AED.20407@oucs.ox.ac.uk>
	<4FB661EE.6020307@uvic.ca>	<4FB66336.3040401@kcl.ac.uk>
	<4FB69D7E.10100@o2.pl>	<4FB6B21A.70409@uvic.ca>	<4FB79B44.2020308@kcl.ac.uk>
	<4FB8079D.8040208@gmail.com>
	<CAA2irtLR74aaA3SHz-o7Rip8ex36=1rdSCH5LVi-taOX9v7X1Q@mail.gmail.com>,
	<4FB9256C.7090703@ultraslavonic.info>
	<9A1F0C47-2555-40D8-88C2-E627D08C9467@oucs.ox.ac.uk>
	<4FB954B8.6040003@oucs.ox.ac.uk>
Message-ID: <4FBA3EE7.8080405@kcl.ac.uk>

This sounds exactly right to me. I have no objection to the list 
archives being RSS-able; that could be very useful. (If it were already 
available, I might have set that up myself and set the list to NOMAIL 
while I was on research leave. ;-) )

G

On 20/05/2012 21:31, James Cummings wrote:
>
> It seems like we're coming to a consensus that:
> - We want the council list to be readable by anyone (as it
> currently is) and archived
> - We are willing to have it exposed as RSS/Atom for those who do
> want a 'feed' of some sort
> - We _don't_ want a second mailing list or subscribers with
> moderation flags set, or things like that.
>
> So, in the up-shot, no immediate change necessary but if DavidS
> does migrate us to Sympa and so RSS available, then that is all
> well and good.
>
> -James
>
>
> On 20/05/12 18:29, Sebastian Rahtz wrote:
>> Exposure as RSS is a bit weird for email. But, agreed, better than pseudo-subscription and the funny expectations that raises
>>
>> Carved in stone on my iPad
>>
>
>

-- 
Dr Gabriel BODARD
(Research Associate in Digital Epigraphy)

Department of Digital Humanities
King's College London
26-29 Drury Lane
London WC2B 5RL

Email: gabriel.bodard at kcl.ac.uk
Tel: +44 (0)20 7848 1388
Fax: +44 (0)20 7848 2980

http://www.digitalclassicist.org/
http://www.currentepigraphy.org/

From dsewell at virginia.edu  Mon May 21 09:14:52 2012
From: dsewell at virginia.edu (David Sewell)
Date: Mon, 21 May 2012 09:14:52 -0400 (EDT)
Subject: [tei-council] Setting up read-only access to TEI Council list?
In-Reply-To: <4FBA3EE7.8080405@kcl.ac.uk>
References: <alpine.OSX.2.00.1205180854250.24330@lister.ei.virginia.edu>
	<4FB64D6B.8050904@ultraslavonic.info>
	<4FB65AED.20407@oucs.ox.ac.uk> <4FB661EE.6020307@uvic.ca>
	<4FB66336.3040401@kcl.ac.uk> <4FB69D7E.10100@o2.pl>
	<4FB6B21A.70409@uvic.ca>
	<4FB79B44.2020308@kcl.ac.uk> <4FB8079D.8040208@gmail.com>
	<CAA2irtLR74aaA3SHz-o7Rip8ex36=1rdSCH5LVi-taOX9v7X1Q@mail.gmail.com>,
	<4FB9256C.7090703@ultraslavonic.info>
	<9A1F0C47-2555-40D8-88C2-E627D08C9467@oucs.ox.ac.uk>
	<4FB954B8.6040003@oucs.ox.ac.uk> <4FBA3EE7.8080405@kcl.ac.uk>
Message-ID: <alpine.OSX.2.00.1205210912250.17862@lister.ei.virginia.edu>

OK, thanks all for the input on this. So the only question, I believe, is 
whether it's worth spending the time right now to implement some sort of 
list-to-RSS feed that would presumably work off the current HTML archives:

http://lists.village.virginia.edu/pipermail/tei-council/2012/date.html

Personally, I think Council's time is maybe better spent on other things, but if 
there's a quick way to implement this and I can facilitate it let me know.

David

On Mon, 21 May 2012, Gabriel BODARD wrote:

> This sounds exactly right to me. I have no objection to the list
> archives being RSS-able; that could be very useful. (If it were already
> available, I might have set that up myself and set the list to NOMAIL
> while I was on research leave. ;-) )
>
> G
>
> On 20/05/2012 21:31, James Cummings wrote:
>>
>> It seems like we're coming to a consensus that:
>> - We want the council list to be readable by anyone (as it
>> currently is) and archived
>> - We are willing to have it exposed as RSS/Atom for those who do
>> want a 'feed' of some sort
>> - We _don't_ want a second mailing list or subscribers with
>> moderation flags set, or things like that.
>>
>> So, in the up-shot, no immediate change necessary but if DavidS
>> does migrate us to Sympa and so RSS available, then that is all
>> well and good.
>>
>> -James
>>
>>
>> On 20/05/12 18:29, Sebastian Rahtz wrote:
>>> Exposure as RSS is a bit weird for email. But, agreed, better than pseudo-subscription and the funny expectations that raises
>>>
>>> Carved in stone on my iPad
>>>
>>
>>
>
>

-- 
David Sewell, Editorial and Technical Manager
ROTUNDA, The University of Virginia Press
PO Box 400314, Charlottesville, VA 22904-4314 USA
Email: dsewell at virginia.edu   Tel: +1 434 924 9973
Web: http://rotunda.upress.virginia.edu/

From sebastian.rahtz at oucs.ox.ac.uk  Mon May 21 09:55:52 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Mon, 21 May 2012 13:55:52 +0000
Subject: [tei-council] @xml:lang on <egXML>
In-Reply-To: <4FBA3584.4060903@ultraslavonic.info>
References: <4FB94E32.4000506@ultraslavonic.info>
	<4599AA59-5E2B-47AB-BADC-FAA02F47E52E@oucs.ox.ac.uk>
	<4FBA3584.4060903@ultraslavonic.info>
Message-ID: <61FBF995-8942-4C17-8B83-B8CFC7D59790@oucs.ox.ac.uk>

I looked at how this works.

 a) <egXML> in the chapters will always get rendered. so just make the @xml:lang be right, for neatness.

  b) in *Spec, the language on the parent <exemplum> is the trigger used to decide whether or not to show the example,
 not the language on the <egXML>. so again, @xml:lang on <egXML> should reflect the truth
--
Sebastian Rahtz      
Head of Information and Support Group
Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431

S?lo le pido a Dios
que el futuro no me sea indiferente


From gabriel.bodard at kcl.ac.uk  Mon May 21 10:07:07 2012
From: gabriel.bodard at kcl.ac.uk (Gabriel BODARD)
Date: Mon, 21 May 2012 15:07:07 +0100
Subject: [tei-council] Setting up read-only access to TEI Council list?
In-Reply-To: <alpine.OSX.2.00.1205210912250.17862@lister.ei.virginia.edu>
References: <alpine.OSX.2.00.1205180854250.24330@lister.ei.virginia.edu>
	<4FB64D6B.8050904@ultraslavonic.info>
	<4FB65AED.20407@oucs.ox.ac.uk> <4FB661EE.6020307@uvic.ca>
	<4FB66336.3040401@kcl.ac.uk> <4FB69D7E.10100@o2.pl>
	<4FB6B21A.70409@uvic.ca> <4FB79B44.2020308@kcl.ac.uk>
	<4FB8079D.8040208@gmail.com>
	<CAA2irtLR74aaA3SHz-o7Rip8ex36=1rdSCH5LVi-taOX9v7X1Q@mail.gmail.com>,
	<4FB9256C.7090703@ultraslavonic.info>
	<9A1F0C47-2555-40D8-88C2-E627D08C9467@oucs.ox.ac.uk>
	<4FB954B8.6040003@oucs.ox.ac.uk> <4FBA3EE7.8080405@kcl.ac.uk>
	<alpine.OSX.2.00.1205210912250.17862@lister.ei.virginia.edu>
Message-ID: <4FBA4C0B.1010805@kcl.ac.uk>

No I agree. If we're going to get this via Sympa eventually, then I'd 
say it's not at all urgent.

G

On 21/05/2012 14:14, David Sewell wrote:
> OK, thanks all for the input on this. So the only question, I believe, is
> whether it's worth spending the time right now to implement some sort of
> list-to-RSS feed that would presumably work off the current HTML archives:
>
> http://lists.village.virginia.edu/pipermail/tei-council/2012/date.html
>
> Personally, I think Council's time is maybe better spent on other things, but if
> there's a quick way to implement this and I can facilitate it let me know.
>
> David
>
> On Mon, 21 May 2012, Gabriel BODARD wrote:
>
>> This sounds exactly right to me. I have no objection to the list
>> archives being RSS-able; that could be very useful. (If it were already
>> available, I might have set that up myself and set the list to NOMAIL
>> while I was on research leave. ;-) )
>>
>> G
>>
>> On 20/05/2012 21:31, James Cummings wrote:
>>>
>>> It seems like we're coming to a consensus that:
>>> - We want the council list to be readable by anyone (as it
>>> currently is) and archived
>>> - We are willing to have it exposed as RSS/Atom for those who do
>>> want a 'feed' of some sort
>>> - We _don't_ want a second mailing list or subscribers with
>>> moderation flags set, or things like that.
>>>
>>> So, in the up-shot, no immediate change necessary but if DavidS
>>> does migrate us to Sympa and so RSS available, then that is all
>>> well and good.
>>>
>>> -James
>>>
>>>
>>> On 20/05/12 18:29, Sebastian Rahtz wrote:
>>>> Exposure as RSS is a bit weird for email. But, agreed, better than pseudo-subscription and the funny expectations that raises
>>>>
>>>> Carved in stone on my iPad
>>>>
>>>
>>>
>>
>>
>

-- 
Dr Gabriel BODARD
(Research Associate in Digital Epigraphy)

Department of Digital Humanities
King's College London
26-29 Drury Lane
London WC2B 5RL

Email: gabriel.bodard at kcl.ac.uk
Tel: +44 (0)20 7848 1388
Fax: +44 (0)20 7848 2980

http://www.digitalclassicist.org/
http://www.currentepigraphy.org/

From sebastian.rahtz at oucs.ox.ac.uk  Mon May 21 11:40:47 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Mon, 21 May 2012 15:40:47 +0000
Subject: [tei-council] Build failed in Jenkins: TEIP5 #326
In-Reply-To: <943921171.5.1337614496322.JavaMail.jenkins@teijenkins>
References: <943921171.5.1337614496322.JavaMail.jenkins@teijenkins>
Message-ID: <4F6221FB-C05C-4C7C-8D67-76E8CCC3966B@oucs.ox.ac.uk>

hi commiter guys and gals

sometimes you'll see messages from Jenkins like this


> Copied 676 artifacts from "TEIP5-Test" build number 505
> ERROR: Failed to copy artifacts from TEIP5-Documentation with filter: release/**,*.stamp,Guidelines.*
> hudson.util.IOException2: Failed to copy /var/lib/jenkins/jobs/TEIP5-Documentation/workspace/release/**,*.stamp,Guidelines.* to <http://teijenkins.hcmc.uvic.ca:8080/job/TEIP5/ws/>
> 	at hudson.FilePath$34.invoke(FilePath.java:1689)


This seems to be a function of the way we chain jobs together, and several pending jobs. So far as I can
see, it sorts itself out in due course. If Martin and I were, like, *really* clever we'd see how to avoid this
in Jenkins, but for now just let it pass
--
Sebastian Rahtz      
Head of Information and Support Group
Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431

S?lo le pido a Dios
que el futuro no me sea indiferente


From kevin.s.hawkins at ultraslavonic.info  Mon May 21 12:43:30 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Mon, 21 May 2012 12:43:30 -0400
Subject: [tei-council] Setting up read-only access to TEI Council list?
In-Reply-To: <4FBA4C0B.1010805@kcl.ac.uk>
References: <alpine.OSX.2.00.1205180854250.24330@lister.ei.virginia.edu>	<4FB64D6B.8050904@ultraslavonic.info>	<4FB65AED.20407@oucs.ox.ac.uk>
	<4FB661EE.6020307@uvic.ca>	<4FB66336.3040401@kcl.ac.uk>
	<4FB69D7E.10100@o2.pl>	<4FB6B21A.70409@uvic.ca>
	<4FB79B44.2020308@kcl.ac.uk>	<4FB8079D.8040208@gmail.com>	<CAA2irtLR74aaA3SHz-o7Rip8ex36=1rdSCH5LVi-taOX9v7X1Q@mail.gmail.com>,
	<4FB9256C.7090703@ultraslavonic.info>	<9A1F0C47-2555-40D8-88C2-E627D08C9467@oucs.ox.ac.uk>	<4FB954B8.6040003@oucs.ox.ac.uk>
	<4FBA3EE7.8080405@kcl.ac.uk>	<alpine.OSX.2.00.1205210912250.17862@lister.ei.virginia.edu>
	<4FBA4C0B.1010805@kcl.ac.uk>
Message-ID: <4FBA70B2.8080404@ultraslavonic.info>

True that it's not urgent, but this also won't take long.

Any Council member who receives messages to tei-council using a Google 
Mail account can set up a feed using this app:

http://emails2rss.appspot.com/

and then we can publicize the feed address.  Looks very easy.

On 5/21/2012 10:07 AM, Gabriel BODARD wrote:
> No I agree. If we're going to get this via Sympa eventually, then I'd
> say it's not at all urgent.
>
> G
>
> On 21/05/2012 14:14, David Sewell wrote:
>> OK, thanks all for the input on this. So the only question, I believe, is
>> whether it's worth spending the time right now to implement some sort of
>> list-to-RSS feed that would presumably work off the current HTML archives:
>>
>> http://lists.village.virginia.edu/pipermail/tei-council/2012/date.html
>>
>> Personally, I think Council's time is maybe better spent on other things, but if
>> there's a quick way to implement this and I can facilitate it let me know.
>>
>> David

From mholmes at uvic.ca  Mon May 21 13:14:31 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Mon, 21 May 2012 10:14:31 -0700
Subject: [tei-council] Build failed in Jenkins: TEIP5 #326
In-Reply-To: <4F6221FB-C05C-4C7C-8D67-76E8CCC3966B@oucs.ox.ac.uk>
References: <943921171.5.1337614496322.JavaMail.jenkins@teijenkins>
	<4F6221FB-C05C-4C7C-8D67-76E8CCC3966B@oucs.ox.ac.uk>
Message-ID: <4FBA77F7.2040109@uvic.ca>

I have a nasty feeling this might be due to my Jinks running low on disk 
space. I'm going to cut back on the number of artifacts that it archives 
and see if that helps.

I'm about to start work on a new Jenkins-builder-script for the latest 
Ubuntu LTS, which is just about stable now, so that should result 
eventually in a better UVic Jenkins; I'll give it more disk space this 
time around.

Cheers,
Martin

On 12-05-21 08:40 AM, Sebastian Rahtz wrote:
> hi commiter guys and gals
>
> sometimes you'll see messages from Jenkins like this
>
>
>> Copied 676 artifacts from "TEIP5-Test" build number 505
>> ERROR: Failed to copy artifacts from TEIP5-Documentation with filter: release/**,*.stamp,Guidelines.*
>> hudson.util.IOException2: Failed to copy /var/lib/jenkins/jobs/TEIP5-Documentation/workspace/release/**,*.stamp,Guidelines.* to<http://teijenkins.hcmc.uvic.ca:8080/job/TEIP5/ws/>
>> 	at hudson.FilePath$34.invoke(FilePath.java:1689)
>
>
> This seems to be a function of the way we chain jobs together, and several pending jobs. So far as I can
> see, it sorts itself out in due course. If Martin and I were, like, *really* clever we'd see how to avoid this
> in Jenkins, but for now just let it pass
> --
> Sebastian Rahtz
> Head of Information and Support Group
> Oxford University Computing Services
> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>
> S?lo le pido a Dios
> que el futuro no me sea indiferente
>

From mholmes at uvic.ca  Mon May 21 13:27:15 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Mon, 21 May 2012 10:27:15 -0700
Subject: [tei-council] Build failed in Jenkins: TEIP5 #326
In-Reply-To: <4FBA77F7.2040109@uvic.ca>
References: <943921171.5.1337614496322.JavaMail.jenkins@teijenkins>
	<4F6221FB-C05C-4C7C-8D67-76E8CCC3966B@oucs.ox.ac.uk>
	<4FBA77F7.2040109@uvic.ca>
Message-ID: <4FBA7AF3.1040400@uvic.ca>

There's definitely something bad happening with my Jinks. I just updated 
it (to 1.464), and now all the site images are failing to show up, 
unless you log in as admin.

Today's a holiday, but I'll try to get this fixed as soon as I get back 
to work. Sorry about the lousy service.

Cheers,
Martin

On 12-05-21 10:14 AM, Martin Holmes wrote:
> I have a nasty feeling this might be due to my Jinks running low on disk
> space. I'm going to cut back on the number of artifacts that it archives
> and see if that helps.
>
> I'm about to start work on a new Jenkins-builder-script for the latest
> Ubuntu LTS, which is just about stable now, so that should result
> eventually in a better UVic Jenkins; I'll give it more disk space this
> time around.
>
> Cheers,
> Martin
>
> On 12-05-21 08:40 AM, Sebastian Rahtz wrote:
>> hi commiter guys and gals
>>
>> sometimes you'll see messages from Jenkins like this
>>
>>
>>> Copied 676 artifacts from "TEIP5-Test" build number 505
>>> ERROR: Failed to copy artifacts from TEIP5-Documentation with filter: release/**,*.stamp,Guidelines.*
>>> hudson.util.IOException2: Failed to copy /var/lib/jenkins/jobs/TEIP5-Documentation/workspace/release/**,*.stamp,Guidelines.* to<http://teijenkins.hcmc.uvic.ca:8080/job/TEIP5/ws/>
>>> 	at hudson.FilePath$34.invoke(FilePath.java:1689)
>>
>>
>> This seems to be a function of the way we chain jobs together, and several pending jobs. So far as I can
>> see, it sorts itself out in due course. If Martin and I were, like, *really* clever we'd see how to avoid this
>> in Jenkins, but for now just let it pass
>> --
>> Sebastian Rahtz
>> Head of Information and Support Group
>> Oxford University Computing Services
>> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>>
>> S?lo le pido a Dios
>> que el futuro no me sea indiferente
>>

From James.Cummings at oucs.ox.ac.uk  Tue May 22 02:19:55 2012
From: James.Cummings at oucs.ox.ac.uk (James Cummings)
Date: Tue, 22 May 2012 07:19:55 +0100
Subject: [tei-council] suggestion for tei-council accessibility
In-Reply-To: <4FBA55F0.3040306@kantl.be>
References: <4FBA55F0.3040306@kantl.be>
Message-ID: <4FBB300B.8050504@oucs.ox.ac.uk>


Dear TEI-council (CC'ed to Ron),

I like that others not on tei-council are following the 
conversation and commenting. (If it was a highly contentious 
discussion then I'd also have no problem them commenting publicly 
on TEI-L and referencing council discussions).

Ron suggests registering TEI-council with MarkMail as an 
additional archive which would then also provide RSS feeds, etc.

Ron: I understand your wish for an easier way to read the 
TEI-council posts, and having the list archived by MarkMail or 
similar is a possible solution.  However, David Sewell indicated 
that the list might be migrated to a newer service at virginia 
which would have the production of RSS feeds, etc. built in. 
That seems a better solution generally rather than a third party. 
  However, if this doesn't happen in a reasonable amount of time 
then we can look at MarkMail (etc.) again.

-James

On 21/05/12 15:49, ron.vandenbranden wrote:
> Hi James,
>
> Sorry for chiming in unsolicitedly, but I've been following the
> conversation about TEI-council accessibility at
> <http://lists.village.virginia.edu/pipermail/tei-council/2012/015498.html>.
> Proving the assumptions that outsiders eventually'll want to
> participate in such discussions, I can suggest a light-weight
> solution: the MarkMail service currently mirroring the TEI-L
> archive also provides an RSS feed. For example, the feed adress
> for TEI-L is
> <http://tei.markmail.org/atom/list:edu.brown.listserv.tei-l>.
> This doesn't require any specific setup, apart from a simple
> registration of the TEI-council list and import of the archive.
> Regarding accessibility, it also adds a quite powerful search
> engine.
>
> The only prerequisites are:
> -if the archive is to be imported to MarkMail, that should be
> done in mbox format (which proved rather straightforward even for
> the much bigger TEI-L archive)
> -subscription of a MarkMail-generated (bot) email address to
> TEI-council
>
> Best,
>
> Ron


-- 
Dr James Cummings, InfoDev,
Computing Services, University of Oxford

From kevin.s.hawkins at ultraslavonic.info  Tue May 22 12:41:23 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Tue, 22 May 2012 12:41:23 -0400
Subject: [tei-council] draft minutes from Ann Arbor
Message-ID: <4FBBC1B3.8080205@ultraslavonic.info>

Colleagues,

I've had an intern encode the Ann Arbor minutes; you can preview them at:

http://www.tei-c.org/Activities/Council/Meetings/tcm50.xml

While it's valid TEI, he'll be looking over the HTML version in the next 
few days to look for encoding errors he might not have caught while 
looking at the markup.

I take full blame for suggesting he use <sp> in those portions of the 
minutes where we record who said what.

Please let me know if you have any corrections.

Kevin

From lou.burnard at retired.ox.ac.uk  Tue May 22 16:43:48 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Tue, 22 May 2012 21:43:48 +0100
Subject: [tei-council] draft minutes from Ann Arbor
In-Reply-To: <4FBBC1B3.8080205@ultraslavonic.info>
References: <4FBBC1B3.8080205@ultraslavonic.info>
Message-ID: <4FBBFA84.4000106@retired.ox.ac.uk>

On 22/05/12 17:41, Kevin Hawkins wrote:
> Colleagues,
>
> I've had an intern encode the Ann Arbor minutes; you can preview them at:
>
> http://www.tei-c.org/Activities/Council/Meetings/tcm50.xml

Can someone remind me how one persuades that wretched CMS to give one 
the XML source instead of the HTML rendering of it?


From kevin.s.hawkins at ultraslavonic.info  Tue May 22 16:45:11 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Tue, 22 May 2012 16:45:11 -0400
Subject: [tei-council] draft minutes from Ann Arbor
In-Reply-To: <4FBBFA84.4000106@retired.ox.ac.uk>
References: <4FBBC1B3.8080205@ultraslavonic.info>
	<4FBBFA84.4000106@retired.ox.ac.uk>
Message-ID: <4FBBFAD7.7060703@ultraslavonic.info>

On 5/22/2012 4:43 PM, Lou Burnard wrote:
> On 22/05/12 17:41, Kevin Hawkins wrote:
>> Colleagues,
>>
>> I've had an intern encode the Ann Arbor minutes; you can preview them at:
>>
>> http://www.tei-c.org/Activities/Council/Meetings/tcm50.xml
>
> Can someone remind me how one persuades that wretched CMS to give one
> the XML source instead of the HTML rendering of it?

Scroll down to the bottom of the HTML page and click "XML View".

From mholmes at uvic.ca  Wed May 23 11:48:25 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Wed, 23 May 2012 08:48:25 -0700
Subject: [tei-council] @predeclare
Message-ID: <4FBD06C9.6080206@uvic.ca>

Hi all,

I've been working on adding a few examples for attributes which are 
short on them (http://purl.org/TEI/BUGS/3520704). It occurred to me to 
look specifically at those which feature in no examples at all, 
anywhere; there seem to be two of those:

@predeclare   (att.identified)
@versionDate  (att.translatable)

When I come to look at @predeclare, I find I don't really understand the 
purpose of it. It's available on these documentation elements:

moduleSpec schemaSpec elementSpec classSpec macroSpec constraintSpec attDef

and it's defined thus:

Says whether this object should be predeclared in the tei infrastructure 
module.
Status 	Optional
Datatype data.truthValue

When I look at the actual guidelines, the attribute is only used on 
<classSpec> elements, and it's only ever "true".

  - What is its default value?

In other words, for all the <classSpec>s on which it's _not_ declared, 
is it deemed true or false? After looking at some of the stylesheets, I 
have to assume the default is false, but there's something intrinsically 
odd in an attribute which is data.truthValue ("uncertainty is 
inappropriate"), but is optional and has no default value.

  - What would happen if it were set to false?

  - What _should_ happen when it's set to false?

  - What is it actually doing? In other words, what are the implications 
of a <classSpec> being predeclared or not predeclared?

I've gone through the Council archives, and I can only find the 
attribute being referred to a few times in 2005 (where it's one of a 
long list of atts whose datatypes are being determined), then again in 
2007 in passing, and 2008, when I think Lou response to this question:

>> *22.2 Modules and Schemas
>> *
>> For the line, "the order in which  element declarations appear within
>> the schema code generated from a <gi>moduleSpec</gi> element cannot be
>> altered, and is not affected by the order of declarations within a
>> <gi>specGrp</gi>.", I think it might be nice if mention were made as
>> to why it cannot be altered.
>>
> Because that's how the ODD processors work... well, also because there
> isn't any way of specifying the order ... except by means of the
> predeclare attribute, come to think of it.  Actually, I think I'll just
> delete "cannot...and".

Cheers,
Martin
-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From mholmes at uvic.ca  Wed May 23 11:59:02 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Wed, 23 May 2012 08:59:02 -0700
Subject: [tei-council] @versionDate
Message-ID: <4FBD0946.2040807@uvic.ca>

@versionDate is currently defined as:

versionDate	specifies the date on which the translated source text was taken

I don't think that's quite as clear as it could be -- doesn't it really 
mean "the date on which the source text was translated"?

Should we also add some clarification about the reason for the 
attribute's existence? -- along the lines of:

"This attribute can be used to determine whether a translation might 
need to be revisited, by comparing the modification date on the 
containing file with the @versionDate on the translation. If the file 
has changed, the SVN log can be checked to see whether the source text 
has changed since the translation was made."

Cheers,
Martin

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From PFSchaffner at umich.edu  Wed May 23 12:09:15 2012
From: PFSchaffner at umich.edu (Paul F. Schaffner)
Date: Wed, 23 May 2012 12:09:15 -0400 (EDT)
Subject: [tei-council] @versionDate
In-Reply-To: <4FBD0946.2040807@uvic.ca>
References: <4FBD0946.2040807@uvic.ca>
Message-ID: <Pine.LNX.4.64.1205231207010.3216@goldenaxe.gpcc.itd.umich.edu>

On Wed, 23 May 2012, Martin Holmes wrote:

> @versionDate is currently defined as:
>
> versionDate	specifies the date on which the translated source text was taken
>
> I don't think that's quite as clear as it could be -- doesn't it really
> mean "the date on which the source text was translated"?

Judging from the minutes of the AA mtg, it should mean the date (whatever
exactly that means: the release date?) of the English version on which
the translation was based--not the date the translation was done.

I understood this at the time. Why does the memory cloud over so?

pfs


>
> Should we also add some clarification about the reason for the
> attribute's existence? -- along the lines of:
>
> "This attribute can be used to determine whether a translation might
> need to be revisited, by comparing the modification date on the
> containing file with the @versionDate on the translation. If the file
> has changed, the SVN log can be checked to see whether the source text
> has changed since the translation was made."
>
> Cheers,
> Martin
>
> -- 
> Martin Holmes
> University of Victoria Humanities Computing and Media Centre
> (mholmes at uvic.ca)
> -- 
> tei-council mailing list
> tei-council at lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>
> PLEASE NOTE: postings to this list are publicly archived
>
>
>

--------------------------------------------------------------------
Paul Schaffner | PFSchaffner at umich.edu | http://www.umich.edu/~pfs/
316-C Hatcher Library N, Univ. of Michigan, Ann Arbor MI 48109-1190
--------------------------------------------------------------------

From gabriel.bodard at kcl.ac.uk  Wed May 23 12:12:18 2012
From: gabriel.bodard at kcl.ac.uk (Gabriel BODARD)
Date: Wed, 23 May 2012 17:12:18 +0100
Subject: [tei-council] @versionDate
In-Reply-To: <Pine.LNX.4.64.1205231207010.3216@goldenaxe.gpcc.itd.umich.edu>
References: <4FBD0946.2040807@uvic.ca>
	<Pine.LNX.4.64.1205231207010.3216@goldenaxe.gpcc.itd.umich.edu>
Message-ID: <4FBD0C62.3070309@kcl.ac.uk>

That would make a lot of sense. It's the only way the guidelines would 
be completely unambiguous as to whether an updated translation is 
required or not. (I wasn't at that conversation, but I would have agreed 
with this formulation had I been.)

On 23/05/2012 17:09, Paul F. Schaffner wrote:
> On Wed, 23 May 2012, Martin Holmes wrote:
>
>> @versionDate is currently defined as:
>>
>> versionDate	specifies the date on which the translated source text was taken
>>
>> I don't think that's quite as clear as it could be -- doesn't it really
>> mean "the date on which the source text was translated"?
>
> Judging from the minutes of the AA mtg, it should mean the date (whatever
> exactly that means: the release date?) of the English version on which
> the translation was based--not the date the translation was done.
>
> I understood this at the time. Why does the memory cloud over so?
>
> pfs
>
>
>>
>> Should we also add some clarification about the reason for the
>> attribute's existence? -- along the lines of:
>>
>> "This attribute can be used to determine whether a translation might
>> need to be revisited, by comparing the modification date on the
>> containing file with the @versionDate on the translation. If the file
>> has changed, the SVN log can be checked to see whether the source text
>> has changed since the translation was made."
>>
>> Cheers,
>> Martin
>>
>> --
>> Martin Holmes
>> University of Victoria Humanities Computing and Media Centre
>> (mholmes at uvic.ca)
>> --
>> tei-council mailing list
>> tei-council at lists.village.Virginia.EDU
>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>>
>> PLEASE NOTE: postings to this list are publicly archived
>>
>>
>>
>
> --------------------------------------------------------------------
> Paul Schaffner | PFSchaffner at umich.edu | http://www.umich.edu/~pfs/
> 316-C Hatcher Library N, Univ. of Michigan, Ann Arbor MI 48109-1190
> --------------------------------------------------------------------

-- 
Dr Gabriel BODARD
(Research Associate in Digital Epigraphy)

Department of Digital Humanities
King's College London
26-29 Drury Lane
London WC2B 5RL

Email: gabriel.bodard at kcl.ac.uk
Tel: +44 (0)20 7848 1388
Fax: +44 (0)20 7848 2980

http://www.digitalclassicist.org/
http://www.currentepigraphy.org/

From sebastian.rahtz at oucs.ox.ac.uk  Wed May 23 12:15:55 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Wed, 23 May 2012 16:15:55 +0000
Subject: [tei-council] @versionDate
In-Reply-To: <4FBD0946.2040807@uvic.ca>
References: <4FBD0946.2040807@uvic.ca>
Message-ID: <73CEC8BF-891D-469E-BF92-CB61C96CDAD9@oucs.ox.ac.uk>


On 23 May 2012, at 16:59, Martin Holmes wrote:

> @versionDate is currently defined as:
> 
> versionDate	specifies the date on which the translated source text was taken
> 
> I don't think that's quite as clear as it could be -- doesn't it really 
> mean "the date on which the source text was translated"?
no, it means the date on which we copied the text to the translator. it 
may have taken them months to do the actual work

gabby and paul are correct

--
Sebastian Rahtz      
Head of Information and Support Group
Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431

S?lo le pido a Dios
que el futuro no me sea indiferente


From sebastian.rahtz at oucs.ox.ac.uk  Wed May 23 12:27:35 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Wed, 23 May 2012 16:27:35 +0000
Subject: [tei-council] @predeclare
In-Reply-To: <4FBD06C9.6080206@uvic.ca>
References: <4FBD06C9.6080206@uvic.ca>
Message-ID: <7003FEFE-3E5B-4BC0-8D7C-854700896CC8@oucs.ox.ac.uk>


On 23 May 2012, at 16:48, Martin Holmes wrote:

> When I come to look at @predeclare, I find I don't really understand the 
> purpose of it.

few are chosen for the journey to the dark lands, fewer return

> 
> When I look at the actual guidelines, the attribute is only used on 
> <classSpec> elements, and it's only ever "true".
> 
>  - What is its default value?

the Spec says 

<defaultVal>false</defaultVal>

so I'd believe that :-}

> 
>  - What is it actually doing? In other words, what are the implications 
> of a <classSpec> being predeclared or not predeclared?
> 

when you make a DTD, the classes and macros are turned into DTD entities, in
the order in which they appear in the source. However, some are so
magical that they need to occur before all the others. These
are flagged with @predeclare=true

why, you ask, can't the ODD processor sort this out for itself?

cos. just cos.

come the revolution?..

--
Sebastian Rahtz      
Head of Information and Support Group
Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431

S?lo le pido a Dios
que el futuro no me sea indiferente


From mholmes at uvic.ca  Wed May 23 12:51:44 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Wed, 23 May 2012 09:51:44 -0700
Subject: [tei-council] @versionDate
In-Reply-To: <73CEC8BF-891D-469E-BF92-CB61C96CDAD9@oucs.ox.ac.uk>
References: <4FBD0946.2040807@uvic.ca>
	<73CEC8BF-891D-469E-BF92-CB61C96CDAD9@oucs.ox.ac.uk>
Message-ID: <4FBD15A0.1070003@uvic.ca>

On 12-05-23 09:15 AM, Sebastian Rahtz wrote:
>
> On 23 May 2012, at 16:59, Martin Holmes wrote:
>
>> @versionDate is currently defined as:
>>
>> versionDate	specifies the date on which the translated source text was taken
>>
>> I don't think that's quite as clear as it could be -- doesn't it really
>> mean "the date on which the source text was translated"?
> no, it means the date on which we copied the text to the translator. it
> may have taken them months to do the actual work

Like Paul's, my memory clouded over. But the description does need some 
clarification, if only for the sake of idiots like me. How about this:

"the date on which the source text was extracted and sent to the translator"

I'd still like to add the other bit, if no-one has any objections:

"This attribute can be used to determine whether a translation might
need to be revisited, by comparing the modification date on the
containing file with the @versionDate on the translation. If the file
has changed, the SVN log can be checked to see whether the source text
has changed since the translation was made."

Cheers,
Martin

> gabby and paul are correct
>
> --
> Sebastian Rahtz
> Head of Information and Support Group
> Oxford University Computing Services
> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>
> S?lo le pido a Dios
> que el futuro no me sea indiferente
>
>

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From mholmes at uvic.ca  Wed May 23 12:59:28 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Wed, 23 May 2012 09:59:28 -0700
Subject: [tei-council] @predeclare
In-Reply-To: <7003FEFE-3E5B-4BC0-8D7C-854700896CC8@oucs.ox.ac.uk>
References: <4FBD06C9.6080206@uvic.ca>
	<7003FEFE-3E5B-4BC0-8D7C-854700896CC8@oucs.ox.ac.uk>
Message-ID: <4FBD1770.7060701@uvic.ca>

On 12-05-23 09:27 AM, Sebastian Rahtz wrote:
>
> On 23 May 2012, at 16:48, Martin Holmes wrote:

>> When I look at the actual guidelines, the attribute is only used on
>> <classSpec>  elements, and it's only ever "true".
>>
>>   - What is its default value?
>
> the Spec says
>
> <defaultVal>false</defaultVal>
>
> so I'd believe that :-}

Curses, exposed as a fool again. I was looking at the reference page and 
expecting a default value to appear there:

<http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-att.identified.html>

But it doesn't.

It should, shouldn't it?

>>   - What is it actually doing? In other words, what are the implications
>> of a<classSpec>  being predeclared or not predeclared?
>>
>
> when you make a DTD, the classes and macros are turned into DTD entities, in
> the order in which they appear in the source. However, some are so
> magical that they need to occur before all the others. These
> are flagged with @predeclare=true
>
> why, you ask, can't the ODD processor sort this out for itself?
>
> cos. just cos.

This is the sort of thing that should cause the TEI to insure your life 
for millions of pounds. But in the absence of such insurance, I'd like 
to find out about such things and get them documented where we can. What 
determines whether a classSpec is so magical it needs to come be 
predeclared?

Cheers,
Martin

> come the revolution?..

...we'll be back where we started.

>
> --
> Sebastian Rahtz
> Head of Information and Support Group
> Oxford University Computing Services
> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>
> S?lo le pido a Dios
> que el futuro no me sea indiferente
>
> .
>

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From kevin.s.hawkins at ultraslavonic.info  Wed May 23 13:11:27 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Wed, 23 May 2012 13:11:27 -0400
Subject: [tei-council] @versionDate
In-Reply-To: <4FBD15A0.1070003@uvic.ca>
References: <4FBD0946.2040807@uvic.ca>	<73CEC8BF-891D-469E-BF92-CB61C96CDAD9@oucs.ox.ac.uk>
	<4FBD15A0.1070003@uvic.ca>
Message-ID: <4FBD1A3F.8060000@ultraslavonic.info>

Since someone could use the ODD tagset for something not involving the 
TEI's Subversion repository, we shouldn't refer to Subversion 
specifically.  So I suggest revising the last sentence to make a more 
generic statement about a version-control environment.

On 5/23/2012 12:51 PM, Martin Holmes wrote:
> I'd still like to add the other bit, if no-one has any objections:
>
> "This attribute can be used to determine whether a translation might
> need to be revisited, by comparing the modification date on the
> containing file with the @versionDate on the translation. If the file
> has changed, the SVN log can be checked to see whether the source text
> has changed since the translation was made."

From mholmes at uvic.ca  Wed May 23 13:20:58 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Wed, 23 May 2012 10:20:58 -0700
Subject: [tei-council] @versionDate
In-Reply-To: <4FBD1A3F.8060000@ultraslavonic.info>
References: <4FBD0946.2040807@uvic.ca>
	<73CEC8BF-891D-469E-BF92-CB61C96CDAD9@oucs.ox.ac.uk>
	<4FBD15A0.1070003@uvic.ca> <4FBD1A3F.8060000@ultraslavonic.info>
Message-ID: <4FBD1C7A.7040009@uvic.ca>

Good point. How about using the generic "changelogs" instead:

"This attribute can be used to determine whether a translation might
need to be revisited, by comparing the modification date on the
containing file with the @versionDate value on the translation. If the 
file has changed, changelogs can be checked to see whether the source 
text has been modified since the translation was made."

Cheers,
Martin

On 12-05-23 10:11 AM, Kevin Hawkins wrote:
> Since someone could use the ODD tagset for something not involving the
> TEI's Subversion repository, we shouldn't refer to Subversion
> specifically.  So I suggest revising the last sentence to make a more
> generic statement about a version-control environment.
>
> On 5/23/2012 12:51 PM, Martin Holmes wrote:
>> I'd still like to add the other bit, if no-one has any objections:
>>
>> "This attribute can be used to determine whether a translation might
>> need to be revisited, by comparing the modification date on the
>> containing file with the @versionDate on the translation. If the file
>> has changed, the SVN log can be checked to see whether the source text
>> has changed since the translation was made."

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From kevin.s.hawkins at ultraslavonic.info  Wed May 23 13:22:15 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Wed, 23 May 2012 13:22:15 -0400
Subject: [tei-council] @versionDate
In-Reply-To: <4FBD1C7A.7040009@uvic.ca>
References: <4FBD0946.2040807@uvic.ca>
	<73CEC8BF-891D-469E-BF92-CB61C96CDAD9@oucs.ox.ac.uk>
	<4FBD15A0.1070003@uvic.ca> <4FBD1A3F.8060000@ultraslavonic.info>
	<4FBD1C7A.7040009@uvic.ca>
Message-ID: <4FBD1CC7.1010401@ultraslavonic.info>

Fine by me.

On 5/23/2012 1:20 PM, Martin Holmes wrote:
> Good point. How about using the generic "changelogs" instead:
>
> "This attribute can be used to determine whether a translation might
> need to be revisited, by comparing the modification date on the
> containing file with the @versionDate value on the translation. If the
> file has changed, changelogs can be checked to see whether the source
> text has been modified since the translation was made."
>
> Cheers,
> Martin
>
> On 12-05-23 10:11 AM, Kevin Hawkins wrote:
>> Since someone could use the ODD tagset for something not involving the
>> TEI's Subversion repository, we shouldn't refer to Subversion
>> specifically. So I suggest revising the last sentence to make a more
>> generic statement about a version-control environment.
>>
>> On 5/23/2012 12:51 PM, Martin Holmes wrote:
>>> I'd still like to add the other bit, if no-one has any objections:
>>>
>>> "This attribute can be used to determine whether a translation might
>>> need to be revisited, by comparing the modification date on the
>>> containing file with the @versionDate on the translation. If the file
>>> has changed, the SVN log can be checked to see whether the source text
>>> has changed since the translation was made."
>

From gabriel.bodard at kcl.ac.uk  Wed May 23 13:23:53 2012
From: gabriel.bodard at kcl.ac.uk (Gabriel BODARD)
Date: Wed, 23 May 2012 18:23:53 +0100
Subject: [tei-council] @versionDate
In-Reply-To: <4FBD15A0.1070003@uvic.ca>
References: <4FBD0946.2040807@uvic.ca>
	<73CEC8BF-891D-469E-BF92-CB61C96CDAD9@oucs.ox.ac.uk>
	<4FBD15A0.1070003@uvic.ca>
Message-ID: <4FBD1D29.8010400@kcl.ac.uk>

On 23/05/2012 17:51, Martin Holmes wrote:
> Like Paul's, my memory clouded over. But the description does need some
> clarification, if only for the sake of idiots like me. How about this:
>
> "the date on which the source text was extracted and sent to the translator"

What about something like, "the date of the version of the source text 
on which this translation is based"?

A bit more vague about the actual workflow involved, since as Kevin 
points out, this attribute may be used outside of the specific TEI 
use-case; but also more accurate--no?--as presumably it depends on 
something more fixed than just when someone got around to emailing the 
translators...?


-- 
Dr Gabriel BODARD
(Research Associate in Digital Epigraphy)

Department of Digital Humanities
King's College London
26-29 Drury Lane
London WC2B 5RL

Email: gabriel.bodard at kcl.ac.uk
Tel: +44 (0)20 7848 1388
Fax: +44 (0)20 7848 2980

http://www.digitalclassicist.org/
http://www.currentepigraphy.org/

From mholmes at uvic.ca  Wed May 23 14:28:32 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Wed, 23 May 2012 11:28:32 -0700
Subject: [tei-council] @versionDate
In-Reply-To: <4FBD1D29.8010400@kcl.ac.uk>
References: <4FBD0946.2040807@uvic.ca>
	<73CEC8BF-891D-469E-BF92-CB61C96CDAD9@oucs.ox.ac.uk>
	<4FBD15A0.1070003@uvic.ca> <4FBD1D29.8010400@kcl.ac.uk>
Message-ID: <4FBD2C50.3050107@uvic.ca>

On 12-05-23 10:23 AM, Gabriel BODARD wrote:
> On 23/05/2012 17:51, Martin Holmes wrote:
>> Like Paul's, my memory clouded over. But the description does need some
>> clarification, if only for the sake of idiots like me. How about this:
>>
>> "the date on which the source text was extracted and sent to the translator"
>
> What about something like, "the date of the version of the source text
> on which this translation is based"?

OK, that's what I've gone with.

Cheers,
Martin

>
> A bit more vague about the actual workflow involved, since as Kevin
> points out, this attribute may be used outside of the specific TEI
> use-case; but also more accurate--no?--as presumably it depends on
> something more fixed than just when someone got around to emailing the
> translators...?
>
>

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From syeates at gmail.com  Wed May 23 15:46:52 2012
From: syeates at gmail.com (Stuart A. Yeates)
Date: Thu, 24 May 2012 07:46:52 +1200
Subject: [tei-council] @predeclare
In-Reply-To: <7003FEFE-3E5B-4BC0-8D7C-854700896CC8@oucs.ox.ac.uk>
References: <4FBD06C9.6080206@uvic.ca>
	<7003FEFE-3E5B-4BC0-8D7C-854700896CC8@oucs.ox.ac.uk>
Message-ID: <CAC_Lu0YhdANK2gm7Vc__67Fi-kQfUNE2MsJP2N4aJC2rHykYXA@mail.gmail.com>

On Thu, May 24, 2012 at 4:27 AM, Sebastian Rahtz
<sebastian.rahtz at oucs.ox.ac.uk> wrote:
>
> On 23 May 2012, at 16:48, Martin Holmes wrote:
>
>> ?- What is it actually doing? In other words, what are the implications
>> of a <classSpec> being predeclared or not predeclared?
>
> when you make a DTD, the classes and macros are turned into DTD entities, in
> the order in which they appear in the source. However, some are so
> magical that they need to occur before all the others. These
> are flagged with @predeclare=true
>
> why, you ask, can't the ODD processor sort this out for itself?
>
> cos. just cos.

If I understand the situation correctly, this is a case of breaking
cyclical dependencies.

The classic computer science approach is to pre-declare everything,
would that work here? It would increase the size of the DTD and but
remove a level of reasoning and a level of complexity from the ODD.

cheers
stuart

From sebastian.rahtz at oucs.ox.ac.uk  Wed May 23 17:27:39 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Wed, 23 May 2012 21:27:39 +0000
Subject: [tei-council] @predeclare
In-Reply-To: <CAC_Lu0YhdANK2gm7Vc__67Fi-kQfUNE2MsJP2N4aJC2rHykYXA@mail.gmail.com>
References: <4FBD06C9.6080206@uvic.ca>
	<7003FEFE-3E5B-4BC0-8D7C-854700896CC8@oucs.ox.ac.uk>
	<CAC_Lu0YhdANK2gm7Vc__67Fi-kQfUNE2MsJP2N4aJC2rHykYXA@mail.gmail.com>
Message-ID: <CB866C4D-714D-4CD6-8141-E50A7F6DEA5A@oucs.ox.ac.uk>

On 23 May 2012, at 20:46, Stuart A. Yeates wrote:

> 
> If I understand the situation correctly, this is a case of breaking
> cyclical dependencies.
> 
> The classic computer science approach is to pre-declare everything,
> would that work here? It would increase the size of the DTD and but
> remove a level of reasoning and a level of complexity from the ODD.

there is no difference between everything predeclared and nothing
predeclared, if they all group together. :-}

why would the size of the DTD change? but i think you may have
over-expectations of the word "predeclare" here - it just means
where the definition is placed.

Sebastian

From sebastian.rahtz at oucs.ox.ac.uk  Wed May 23 18:20:59 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Wed, 23 May 2012 22:20:59 +0000
Subject: [tei-council] @predeclare
In-Reply-To: <4FBD1770.7060701@uvic.ca>
References: <4FBD06C9.6080206@uvic.ca>
	<7003FEFE-3E5B-4BC0-8D7C-854700896CC8@oucs.ox.ac.uk>
	<4FBD1770.7060701@uvic.ca>
Message-ID: <D1CFC872-6AC3-40FF-863A-31831E6D3C3D@oucs.ox.ac.uk>

I built testall.dtd without the @predeclare tests, and its definitely
needed:


RomaResults/testall.dtd:263: parser warning : PEReference: %att.global.linking.attributes; not found
xml:space (default|preserve) #IMPLIED'> 
                                      ^
RomaResults/testall.dtd:263: parser warning : PEReference: %att.global.analytic.attributes; not found
xml:space (default|preserve) #IMPLIED'> 
                                      ^
RomaResults/testall.dtd:263: parser warning : PEReference: %att.global.facs.attributes; not found
xml:space (default|preserve) #IMPLIED'> 
                                      ^
RomaResults/testall.dtd:263: parser warning : PEReference: %att.global.change.attributes; not found
xml:space (default|preserve) #IMPLIED'> 
                                      


etc etc etc

What happens is that we declare as DTD entities all the model classes from the module
"tei" first, because they are needed by global macros. Then later modules make use of those.

But a model like att.global can be _extended_ by later
modules with eg att.global.analytic. So the entity for att.global.analytic
needs to be declared _before_ att.global itself (this is the way DTDs
work, sorry; RELAX NG is more rational). In the normal course
of events, modules are processed in declaration order, so 
att.global.analytic would not be met until much later - too late.
So, its tagged with predeclare=true, meaning that it will
get special treatment, and jump to the head of the queue.

if you look at the  things which are predeclared, they all
fall into this "extension" category.

att.datable.custom.xml
att.datable.iso.xml
att.duration.iso.xml
att.duration.w3c.xml
att.duration.xml
att.enjamb.xml
att.global.analytic.xml
att.global.change.xml
att.global.facs.xml
att.global.linking.xml
att.identified.xml
att.identified.xml
att.metrical.xml
att.msExcerpt.xml
att.ptrLike.form.xml
model.divPart.spoken.xml
model.entryLike.xml
model.entryPart.xml
model.global.spoken.xml
model.handDescPart.xml
model.orgPart.xml
model.orgStateLike.xml
model.persNamePart.xml
model.placeEventLike.xml
model.placeNamePart.xml
model.placeStateLike.xml
model.ptrLike.form.xml
model.resourceLike.xml

OK. now you can kill me.

Someone clever and patient could revisit this, and extrapolate the predeclaration thing
from properties of the classes, I think. If I am made redundant in our
upcoming departmental re-organisation[1], I'll certainly tackle this.

Sebastian

[1] so if you know of any jobs going...

From James.Cummings at oucs.ox.ac.uk  Thu May 24 08:09:22 2012
From: James.Cummings at oucs.ox.ac.uk (James Cummings)
Date: Thu, 24 May 2012 13:09:22 +0100
Subject: [tei-council] @predeclare
In-Reply-To: <4FBD1770.7060701@uvic.ca>
References: <4FBD06C9.6080206@uvic.ca>	<7003FEFE-3E5B-4BC0-8D7C-854700896CC8@oucs.ox.ac.uk>
	<4FBD1770.7060701@uvic.ca>
Message-ID: <4FBE24F2.8070802@oucs.ox.ac.uk>

On 23/05/12 17:59, Martin Holmes wrote:
> On 12-05-23 09:27 AM, Sebastian Rahtz wrote:
>> the Spec says
>> <defaultVal>false</defaultVal>
> Curses, exposed as a fool again. I was looking at the reference page and
> expecting a default value to appear there:
> <http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-att.identified.html>
> But it doesn't.
> It should, shouldn't it?

Yes, I'd agree any <defaultVal>s should be noted on the reference 
page.  (Put in a ticket so we don't forget about this?)

-James
-- 
Dr James Cummings, InfoDev,
Computing Services, University of Oxford

From James.Cummings at oucs.ox.ac.uk  Fri May 25 02:07:58 2012
From: James.Cummings at oucs.ox.ac.uk (James Cummings)
Date: Fri, 25 May 2012 07:07:58 +0100
Subject: [tei-council] @predeclare
In-Reply-To: <4FBE24F2.8070802@oucs.ox.ac.uk>
References: <4FBD06C9.6080206@uvic.ca>	<7003FEFE-3E5B-4BC0-8D7C-854700896CC8@oucs.ox.ac.uk>
	<4FBD1770.7060701@uvic.ca> <4FBE24F2.8070802@oucs.ox.ac.uk>
Message-ID: <4FBF21BE.5090506@oucs.ox.ac.uk>

On 24/05/12 13:09, James Cummings wrote:
> Yes, I'd agree any<defaultVal>s should be noted on the reference
> page.  (Put in a ticket so we don't forget about this?)

I'm told this has already been done. :-)

-James
-- 
Dr James Cummings, InfoDev,
Computing Services, University of Oxford

From sebastian.rahtz at oucs.ox.ac.uk  Fri May 25 04:15:26 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Fri, 25 May 2012 08:15:26 +0000
Subject: [tei-council] @predeclare
In-Reply-To: <4FBF21BE.5090506@oucs.ox.ac.uk>
References: <4FBD06C9.6080206@uvic.ca>
	<7003FEFE-3E5B-4BC0-8D7C-854700896CC8@oucs.ox.ac.uk>
	<4FBD1770.7060701@uvic.ca> <4FBE24F2.8070802@oucs.ox.ac.uk>
	<4FBF21BE.5090506@oucs.ox.ac.uk>
Message-ID: <1b4916d2-e4f7-4813-8db5-9548c9b05773@HUB02.ad.oak.ox.ac.uk>


On 25 May 2012, at 07:07, James Cummings wrote:

>> Yes, I'd agree any<defaultVal>s should be noted on the reference
>> page.  (Put in a ticket so we don't forget about this?)
> 
> I'm told this has already been done. :-)
> 

sure has. see http://bits.nsms.ox.ac.uk:8080/jenkins/job/TEIP5-Documentation/lastSuccessfulBuild/artifact/Guidelines-web/en/html/ref-att.identified.html
> 

--
Sebastian Rahtz      
Head of Information and Support Group
Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431

S?lo le pido a Dios
que el futuro no me sea indiferente


From kevin.s.hawkins at ultraslavonic.info  Mon May 28 20:01:33 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Mon, 28 May 2012 20:01:33 -0400
Subject: [tei-council] soft deprecation of @key
In-Reply-To: <4FB95F52.70602@retired.ox.ac.uk>
References: <4FB94A4E.2040206@ultraslavonic.info>
	<4FB95F52.70602@retired.ox.ac.uk>
Message-ID: <4FC411DD.2040200@ultraslavonic.info>

Subsequent offline correspondence with Lou convinced me that his wording 
on this is in fact better.  I've just committed at revision 10404.

On 5/20/12 5:17 PM, Lou Burnard wrote:
> On 20/05/12 20:47, Kevin Hawkins wrote:
>> All,
>>
>> At last, I've implemented http://purl.org/TEI/fr/3437509.  See the "text
>> changed" links at in case you're interested:
>>
>> http://tei.svn.sourceforge.net/viewvc/tei?view=revision&revision=10374
>>
>> Lou, over to you to review.
>>
>> --Kevin
>
>
> Well, I think the proposed wording might be improved. The reference to
> <taxonomy>  seems irrelevant -- if you use that, you'd use @ref to point
> at entries in it. And the term "magic token" is probably best not
> eternalised (magic cookie I've never heard of before -- it invites
> confusion with the other sorts of cookie.
>
> Here's a suggested revision for the following passage added to CO :
>
>
> "Since the value of the<att>key</att>  attribute does not follow any
> standard syntax, can only be deciphered by a human reader (possibly by
> consulting the<gi>taxonomy</gi>  element in the TEI header), and could
> coincide with a value used by another project, such<term>magic
> tokens</term>  or<term>magic cookies</term>  should be avoided. A
> preferred ..."
>
>
> No particular syntax is proposed for the values of the<att>key</att>
> attribute, since its form will depend entirely on practice within a
> given project. For the same reason, this attribute is not recommended in
> data interchange, since there is no way of ensuring that the values used
> by one project are distinct from those used by another. In such a
> situation, a preferable ...
>
>

From syeates at gmail.com  Fri Jun  1 19:42:09 2012
From: syeates at gmail.com (stuart yeates)
Date: Sat, 02 Jun 2012 11:42:09 +1200
Subject: [tei-council] next release?
In-Reply-To: <4FB95846.7080308@oucs.ox.ac.uk>
References: <0F18A249-5480-42D9-BFF2-538AC7B9E1EB@oucs.ox.ac.uk>
	<4F92F34D.2040103@uvic.ca>	<4F9579A0.8010002@oucs.ox.ac.uk>
	<4F95C7A1.1080707@o2.pl> <4F96756B.1060202@oucs.ox.ac.uk>
	<4F986673.7020201@kcl.ac.uk> <4FB95846.7080308@oucs.ox.ac.uk>
Message-ID: <4FC95351.9030005@gmail.com>

On 21/05/12 08:47, James Cummings wrote:
>
> Hi all,
>
> I think events have caught up with us and that May 25th deadline
> is looming.  I know I've barely chipped the surface of things
> assigned to me, and the meeting minutes are still coming (almost
> there I'm told).  I propose that we push back the next release
> until the week ending 15 June.  Does that seem unreasonable for
> anyone, or any counter proposals?

Could someone remind me please of the URL to the list of things meant to 
being done?

I know there's the list at 
http://wiki.tei-c.org/index.php/AttsWithoutEgs too.

cheers
stuart


From James.Cummings at oucs.ox.ac.uk  Sun Jun  3 01:44:03 2012
From: James.Cummings at oucs.ox.ac.uk (James Cummings)
Date: Sun, 03 Jun 2012 06:44:03 +0100
Subject: [tei-council] next release?
In-Reply-To: <4FC95351.9030005@gmail.com>
References: <0F18A249-5480-42D9-BFF2-538AC7B9E1EB@oucs.ox.ac.uk>
	<4F92F34D.2040103@uvic.ca>	<4F9579A0.8010002@oucs.ox.ac.uk>
	<4F95C7A1.1080707@o2.pl> <4F96756B.1060202@oucs.ox.ac.uk>
	<4F986673.7020201@kcl.ac.uk> <4FB95846.7080308@oucs.ox.ac.uk>
	<4FC95351.9030005@gmail.com>
Message-ID: <4FCAF9A3.3020800@oucs.ox.ac.uk>

On 02/06/12 00:42, stuart yeates wrote:
>> until the week ending 15 June.  Does that seem unreasonable for
>> anyone, or any counter proposals?
>
> Could someone remind me please of the URL to the list of things meant to
> being done?
>
> I know there's the list at
> http://wiki.tei-c.org/index.php/AttsWithoutEgs too.

The minutes are up at 
http://www.tei-c.org/Activities/Council/Meetings/tcm50.xml

-james




-- 
Dr James Cummings, InfoDev,
Computing Services, University of Oxford

From James.Cummings at oucs.ox.ac.uk  Sun Jun  3 14:37:48 2012
From: James.Cummings at oucs.ox.ac.uk (James Cummings)
Date: Sun, 03 Jun 2012 11:37:48 -0700
Subject: [tei-council] next release?
In-Reply-To: <4FCAF9A3.3020800@oucs.ox.ac.uk>
References: <0F18A249-5480-42D9-BFF2-538AC7B9E1EB@oucs.ox.ac.uk>
	<4F92F34D.2040103@uvic.ca>	<4F9579A0.8010002@oucs.ox.ac.uk>
	<4F95C7A1.1080707@o2.pl> <4F96756B.1060202@oucs.ox.ac.uk>
	<4F986673.7020201@kcl.ac.uk> <4FB95846.7080308@oucs.ox.ac.uk>
	<4FC95351.9030005@gmail.com> <4FCAF9A3.3020800@oucs.ox.ac.uk>
Message-ID: <4FCBAEFC.5070800@oucs.ox.ac.uk>

On 02/06/12 22:44, James Cummings wrote:
> The minutes are up at
> http://www.tei-c.org/Activities/Council/Meetings/tcm50.xml

And maybe more usefully, a table of actions with Name, Action, 
Result is up now at:

http://wiki.tei-c.org/index.php/AnnArbor2012-Actions

Please correct any errors, and put result of the actions (e.g. 
'Done') so we know that they have been finished or not.

-James

-- 
Dr James Cummings, InfoDev,
Computing Services, University of Oxford

From bansp at o2.pl  Sun Jun  3 16:29:25 2012
From: bansp at o2.pl (=?ISO-8859-2?Q?Piotr_Ba=F1ski?=)
Date: Sun, 03 Jun 2012 22:29:25 +0200
Subject: [tei-council] next release?
In-Reply-To: <4FCBAEFC.5070800@oucs.ox.ac.uk>
References: <0F18A249-5480-42D9-BFF2-538AC7B9E1EB@oucs.ox.ac.uk>
	<4F92F34D.2040103@uvic.ca>	<4F9579A0.8010002@oucs.ox.ac.uk>
	<4F95C7A1.1080707@o2.pl> <4F96756B.1060202@oucs.ox.ac.uk>
	<4F986673.7020201@kcl.ac.uk> <4FB95846.7080308@oucs.ox.ac.uk>
	<4FC95351.9030005@gmail.com> <4FCAF9A3.3020800@oucs.ox.ac.uk>
	<4FCBAEFC.5070800@oucs.ox.ac.uk>
Message-ID: <4FCBC925.6040303@o2.pl>

Thank you so much, James!

That's a very useful summary.

Best,

  P.


On 03/06/12 20:37, James Cummings wrote:
> On 02/06/12 22:44, James Cummings wrote:
>> The minutes are up at
>> http://www.tei-c.org/Activities/Council/Meetings/tcm50.xml
> 
> And maybe more usefully, a table of actions with Name, Action, 
> Result is up now at:
> 
> http://wiki.tei-c.org/index.php/AnnArbor2012-Actions
> 
> Please correct any errors, and put result of the actions (e.g. 
> 'Done') so we know that they have been finished or not.
> 
> -James
> 


From rwelzenbach at gmail.com  Mon Jun  4 11:47:51 2012
From: rwelzenbach at gmail.com (Rebecca Welzenbach)
Date: Mon, 4 Jun 2012 08:47:51 -0700
Subject: [tei-council] party in Victoria
Message-ID: <CAA2irtKfgw61F-=9A5zoeQqQ40RWEaOt_n410MZ-RzRA-Qtasg@mail.gmail.com>

Hi all,

Turns out a good group of us are here in Victoria for the Digital
Humanities Summer Institute: Martin, James, Sebastian, and me. I'm
hoping we'll eat, drink, be merry, and prod each other/guilt ourselves
to finish our work.

Nice to have so many of us in one time zone at once!

Becky

From sebastian.rahtz at oucs.ox.ac.uk  Mon Jun  4 12:14:04 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Mon, 4 Jun 2012 16:14:04 +0000
Subject: [tei-council] party in Victoria
In-Reply-To: <CAA2irtKfgw61F-=9A5zoeQqQ40RWEaOt_n410MZ-RzRA-Qtasg@mail.gmail.com>
References: <CAA2irtKfgw61F-=9A5zoeQqQ40RWEaOt_n410MZ-RzRA-Qtasg@mail.gmail.com>
Message-ID: <EB6CE08D-BFEF-45A7-AA47-14683E27E4E9@oucs.ox.ac.uk>

I am hoping to complete work on eebo conversion today, so expect a blizzard of of tickets on sf soon....


Carved in stone on my iPad

On 4 Jun 2012, at 08:47, "Rebecca Welzenbach" <rwelzenbach at gmail.com> wrote:

> Hi all,
> 
> Turns out a good group of us are here in Victoria for the Digital
> Humanities Summer Institute: Martin, James, Sebastian, and me. I'm
> hoping we'll eat, drink, be merry, and prod each other/guilt ourselves
> to finish our work.
> 
> Nice to have so many of us in one time zone at once!
> 
> Becky
> -- 
> tei-council mailing list
> tei-council at lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
> 
> PLEASE NOTE: postings to this list are publicly archived

From syeates at gmail.com  Tue Jun  5 05:45:16 2012
From: syeates at gmail.com (stuart yeates)
Date: Tue, 05 Jun 2012 21:45:16 +1200
Subject: [tei-council] FIXED: Re: Jenkins build is back to normal :
	TEIP5-Test #823
In-Reply-To: <3294072.13.1338889378052.JavaMail.jenkins@bits>
References: <27313131.12.1338885780854.JavaMail.jenkins@bits>
	<3294072.13.1338889378052.JavaMail.jenkins@bits>
Message-ID: <4FCDD52C.8050102@gmail.com>

Sorry for breaking Jenkins temporarily, all is now back to normal.

I've just added another four examples into attributes.

cheers
stuart

From James.Cummings at oucs.ox.ac.uk  Tue Jun  5 11:06:41 2012
From: James.Cummings at oucs.ox.ac.uk (James Cummings)
Date: Tue, 05 Jun 2012 08:06:41 -0700
Subject: [tei-council] party in Victoria
In-Reply-To: <EB6CE08D-BFEF-45A7-AA47-14683E27E4E9@oucs.ox.ac.uk>
References: <CAA2irtKfgw61F-=9A5zoeQqQ40RWEaOt_n410MZ-RzRA-Qtasg@mail.gmail.com>
	<EB6CE08D-BFEF-45A7-AA47-14683E27E4E9@oucs.ox.ac.uk>
Message-ID: <4FCE2081.1080701@oucs.ox.ac.uk>


I've had to put up with Sebastian swearing everytime he finds a 
new EEBO
oddity.

-James

On 04/06/12 09:14, Sebastian Rahtz wrote:
> I am hoping to complete work on eebo conversion today, so expect a blizzard of of tickets on sf soon....
>
>
> Carved in stone on my iPad
>
> On 4 Jun 2012, at 08:47, "Rebecca Welzenbach"<rwelzenbach at gmail.com>  wrote:
>
>> Hi all,
>>
>> Turns out a good group of us are here in Victoria for the Digital
>> Humanities Summer Institute: Martin, James, Sebastian, and me. I'm
>> hoping we'll eat, drink, be merry, and prod each other/guilt ourselves
>> to finish our work.
>>
>> Nice to have so many of us in one time zone at once!
>>
>> Becky
>> --
>> tei-council mailing list
>> tei-council at lists.village.Virginia.EDU
>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>>
>> PLEASE NOTE: postings to this list are publicly archived


-- 
Dr James Cummings, InfoDev,
Computing Services, University of Oxford

From PFSchaffner at umich.edu  Tue Jun  5 11:18:27 2012
From: PFSchaffner at umich.edu (Paul F. Schaffner)
Date: Tue, 5 Jun 2012 11:18:27 -0400 (EDT)
Subject: [tei-council] party in Victoria
In-Reply-To: <4FCE2081.1080701@oucs.ox.ac.uk>
References: <CAA2irtKfgw61F-=9A5zoeQqQ40RWEaOt_n410MZ-RzRA-Qtasg@mail.gmail.com>
	<EB6CE08D-BFEF-45A7-AA47-14683E27E4E9@oucs.ox.ac.uk>
	<4FCE2081.1080701@oucs.ox.ac.uk>
Message-ID: <Pine.LNX.4.64.1206051116220.30451@goldenaxe.gpcc.itd.umich.edu>

Oddity? in TCP? Surely you jest.

pfs

On Tue, 5 Jun 2012, James Cummings wrote:
> I've had to put up with Sebastian swearing everytime he finds a
> new EEBO
> oddity.
>
> -James
>
> On 04/06/12 09:14, Sebastian Rahtz wrote:
>> I am hoping to complete work on eebo conversion today, so expect a blizzard of of tickets on sf soon....
>>
>>
>> Carved in stone on my iPad
>>
>> On 4 Jun 2012, at 08:47, "Rebecca Welzenbach"<rwelzenbach at gmail.com>  wrote:
>>
>>> Hi all,
>>>
>>> Turns out a good group of us are here in Victoria for the Digital
>>> Humanities Summer Institute: Martin, James, Sebastian, and me. I'm
>>> hoping we'll eat, drink, be merry, and prod each other/guilt ourselves
>>> to finish our work.
>>>
>>> Nice to have so many of us in one time zone at once!
>>>
>>> Becky
>>> --
>>> tei-council mailing list
>>> tei-council at lists.village.Virginia.EDU
>>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>>>
>>> PLEASE NOTE: postings to this list are publicly archived
>
>
> -- 
> Dr James Cummings, InfoDev,
> Computing Services, University of Oxford
> -- 
> tei-council mailing list
> tei-council at lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>
> PLEASE NOTE: postings to this list are publicly archived
>
>
>

--------------------------------------------------------------------
Paul Schaffner | PFSchaffner at umich.edu | http://www.umich.edu/~pfs/
316-C Hatcher Library N, Univ. of Michigan, Ann Arbor MI 48109-1190
--------------------------------------------------------------------

From lou.burnard at retired.ox.ac.uk  Tue Jun  5 11:32:19 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Tue, 05 Jun 2012 17:32:19 +0200
Subject: [tei-council] [ tei-Bugs-3532022 ] <lg> should be allowed in <p>
In-Reply-To: <1338909911-30293@relay1.mail.ox.ac.uk>
References: <1338909911-30293@relay1.mail.ox.ac.uk>
Message-ID: <4FCE2683.3030007@retired.ox.ac.uk>

On 05/06/12 17:25, SourceForge.net wrote:
>> Comment By: Martin Holmes (martindholmes)
> Date: 2012-06-05 08:25
>
> Message:
> I think the simplest way to do this would be to add<lg>  to model.inter
> ("elements which can appear either within or between paragraph-like
> elements"). Does anyone see any objection to this?
>

by all means try this, but i predict that numerous non-deterministic 
content models will be the result

From mholmes at uvic.ca  Tue Jun  5 11:47:28 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Tue, 5 Jun 2012 08:47:28 -0700
Subject: [tei-council] [ tei-Bugs-3532022 ] <lg> should be allowed in <p>
In-Reply-To: <4FCE2683.3030007@retired.ox.ac.uk>
References: <1338909911-30293@relay1.mail.ox.ac.uk>
	<4FCE2683.3030007@retired.ox.ac.uk>
Message-ID: <4FCE2A10.4060502@uvic.ca>

On 12-06-05 08:32 AM, Lou Burnard wrote:
> On 05/06/12 17:25, SourceForge.net wrote:
>>> Comment By: Martin Holmes (martindholmes)
>> Date: 2012-06-05 08:25
>>
>> Message:
>> I think the simplest way to do this would be to add<lg>   to model.inter
>> ("elements which can appear either within or between paragraph-like
>> elements"). Does anyone see any objection to this?
>>
>
> by all means try this, but i predict that numerous non-deterministic
> content models will be the result

Why do you think so? How is <lg> being a member of model.inter likely to 
result in this when (say) <castList> being a member is not?

I'm asking rather than just steaming ahead and trying it because by the 
time the build breaks I'll be in a workshop and I won't be able to fix 
any resulting problem for hours.

Cheers,
Martin

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From lou.burnard at retired.ox.ac.uk  Tue Jun  5 11:53:35 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Tue, 05 Jun 2012 17:53:35 +0200
Subject: [tei-council] [ tei-Bugs-3532022 ] <lg> should be allowed in <p>
In-Reply-To: <4FCE2A10.4060502@uvic.ca>
References: <1338909911-30293@relay1.mail.ox.ac.uk>
	<4FCE2683.3030007@retired.ox.ac.uk> <4FCE2A10.4060502@uvic.ca>
Message-ID: <4FCE2B7F.4080307@retired.ox.ac.uk>

On 05/06/12 17:47, Martin Holmes wrote:

>>> I think the simplest way to do this would be to add<lg> to model.inter
>>> ("elements which can appear either within or between paragraph-like
>>> elements"). Does anyone see any objection to this?
>>>
>>
>> by all means try this, but i predict that numerous non-deterministic
>> content models will be the result
>
> Why do you think so? How is <lg> being a member of model.inter likely to
> result in this when (say) <castList> being a member is not?
>
> I'm asking rather than just steaming ahead and trying it because by the
> time the build breaks I'll be in a workshop and I won't be able to fix
> any resulting problem for hours.
>

I will try it locally if you like --- unlike castList, lg is likely to 
appear explicitly in some content models


From sebastian.rahtz at oucs.ox.ac.uk  Tue Jun  5 11:55:18 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Tue, 5 Jun 2012 15:55:18 +0000
Subject: [tei-council] party in Victoria
In-Reply-To: <4FCE2081.1080701@oucs.ox.ac.uk>
References: <CAA2irtKfgw61F-=9A5zoeQqQ40RWEaOt_n410MZ-RzRA-Qtasg@mail.gmail.com>
	<EB6CE08D-BFEF-45A7-AA47-14683E27E4E9@oucs.ox.ac.uk>,
	<4FCE2081.1080701@oucs.ox.ac.uk>
Message-ID: <b3ff73d0-11b6-4dba-b06a-5ad21ea40a73@HUB03.ad.oak.ox.ac.uk>





On 5 Jun 2012, at 08:09, "James Cummings" <James.Cummings at oucs.ox.ac.uk> wrote:

> 
> I've had to put up with Sebastian swearing everytime he finds a 
> new EEBO
> oddity.

Think of the benefits tho.

Sebastian

From sebastian.rahtz at oucs.ox.ac.uk  Tue Jun  5 12:12:22 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Tue, 5 Jun 2012 16:12:22 +0000
Subject: [tei-council] party in Victoria
In-Reply-To: <Pine.LNX.4.64.1206051116220.30451@goldenaxe.gpcc.itd.umich.edu>
References: <CAA2irtKfgw61F-=9A5zoeQqQ40RWEaOt_n410MZ-RzRA-Qtasg@mail.gmail.com>
	<EB6CE08D-BFEF-45A7-AA47-14683E27E4E9@oucs.ox.ac.uk>
	<4FCE2081.1080701@oucs.ox.ac.uk>
	<Pine.LNX.4.64.1206051116220.30451@goldenaxe.gpcc.itd.umich.edu>
Message-ID: <a453642e-9aa3-47c8-9e78-2552fdee18d6@HUB06.ad.oak.ox.ac.uk>


On 5 Jun 2012, at 08:18, Paul F. Schaffner wrote:

> Oddity? in TCP? Surely you jest.
> 

when he said "oddity" he meant "constructive use of TEI markup"..

--
Sebastian Rahtz      
Head of Information and Support Group
Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431







From sebastian.rahtz at oucs.ox.ac.uk  Tue Jun  5 12:16:00 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Tue, 5 Jun 2012 16:16:00 +0000
Subject: [tei-council] [ tei-Bugs-3532022 ] <lg> should be allowed in <p>
In-Reply-To: <4FCE2B7F.4080307@retired.ox.ac.uk>
References: <1338909911-30293@relay1.mail.ox.ac.uk>
	<4FCE2683.3030007@retired.ox.ac.uk> <4FCE2A10.4060502@uvic.ca>
	<4FCE2B7F.4080307@retired.ox.ac.uk>
Message-ID: <81765087-3c92-4894-9460-7fd40c655a28@HUB05.ad.oak.ox.ac.uk>

I share Lou's view that non-determinism will very likely jump up and bite us, but that doesn't mean
its not worth trying. it just might take some work..
--
Sebastian Rahtz      
Head of Information and Support Group
Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431







From sebastian.rahtz at oucs.ox.ac.uk  Tue Jun  5 13:26:38 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Tue, 5 Jun 2012 17:26:38 +0000
Subject: [tei-council] <stage> in divliminal
Message-ID: <AC630758-AEFF-43C5-83F5-042B198ACBC5@oucs.ox.ac.uk>

anyone got any views on this fragment of markup? in the TEI, it is illegal, because
of the <stage> in between the two <head> elements.

 <lg n="14" type="song">
                     <head>SONG.</head>
                     <stage>Sung by Priests.</stage>
                     <head>AIR XIV.</head>
                     <byline>Set by Mr. <hi>Charke.</hi>
                     </byline>

should <stage> be allowed up amongst the divliminal?
--
Sebastian Rahtz      
Head of Information and Support Group
Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431







From kevin.s.hawkins at ultraslavonic.info  Tue Jun  5 13:34:16 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Tue, 05 Jun 2012 13:34:16 -0400
Subject: [tei-council] <stage> in divliminal
In-Reply-To: <AC630758-AEFF-43C5-83F5-042B198ACBC5@oucs.ox.ac.uk>
References: <AC630758-AEFF-43C5-83F5-042B198ACBC5@oucs.ox.ac.uk>
Message-ID: <4FCE4318.1070508@ultraslavonic.info>

Do we find

AIR XV.
AIR XVI.
etc.

following this particular "AIR" set by Mr. Clarke?  If so, maybe it 
should be tagged:

<lg n="14" type="song">
   <head>SONG.</head>
   <stage>Sung by Priests.</stage>
   <lg type="air">
     <head>AIR XIV.</head>
     <byline>Set by Mr.<hi>Charke.</hi></byline>

in TEI.

On 6/5/2012 1:26 PM, Sebastian Rahtz wrote:
> anyone got any views on this fragment of markup? in the TEI, it is illegal, because
> of the<stage>  in between the two<head>  elements.
>
>   <lg n="14" type="song">
>                       <head>SONG.</head>
>                       <stage>Sung by Priests.</stage>
>                       <head>AIR XIV.</head>
>                       <byline>Set by Mr.<hi>Charke.</hi>
>                       </byline>
>
> should<stage>  be allowed up amongst the divliminal?
> --
> Sebastian Rahtz
> Head of Information and Support Group
> Oxford University Computing Services
> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>
>
>
>
>
>

From sebastian.rahtz at oucs.ox.ac.uk  Tue Jun  5 13:39:53 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Tue, 5 Jun 2012 17:39:53 +0000
Subject: [tei-council] <stage> in divliminal
In-Reply-To: <4FCE4318.1070508@ultraslavonic.info>
References: <AC630758-AEFF-43C5-83F5-042B198ACBC5@oucs.ox.ac.uk>
	<4FCE4318.1070508@ultraslavonic.info>
Message-ID: <3477976A-936A-46A4-9E16-6E9BE5AA4FAF@oucs.ox.ac.uk>


On 5 Jun 2012, at 10:34, Kevin Hawkins wrote:

> Do we find
> 
> AIR XV.
> AIR XVI.
> etc.
> 
> following this particular "AIR" set by Mr. Clarke?  

nice try, but sadly not.  XV comes later on in another part of the forest
--
Sebastian Rahtz      
Head of Information and Support Group
Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431







From lou.burnard at retired.ox.ac.uk  Tue Jun  5 13:44:48 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Tue, 05 Jun 2012 19:44:48 +0200
Subject: [tei-council] <stage> in divliminal
In-Reply-To: <AC630758-AEFF-43C5-83F5-042B198ACBC5@oucs.ox.ac.uk>
References: <AC630758-AEFF-43C5-83F5-042B198ACBC5@oucs.ox.ac.uk>
Message-ID: <4FCE4590.5000902@retired.ox.ac.uk>

On 05/06/12 19:26, Sebastian Rahtz wrote:
> anyone got any views on this fragment of markup? in the TEI, it is illegal, because
> of the<stage>  in between the two<head>  elements.
>
>   <lg n="14" type="song">
>                       <head>SONG.</head>
>                       <stage>Sung by Priests.</stage>
>                       <head>AIR XIV.</head>
>                       <byline>Set by Mr.<hi>Charke.</hi>
>                       </byline>
>
> should<stage>  be allowed up amongst the divliminal?


I would say no. It's another heading, arguably part of the first one 
(but I suppose you could put the <stage> inside the first <head> )


From sebastian.rahtz at oucs.ox.ac.uk  Tue Jun  5 13:52:47 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Tue, 5 Jun 2012 17:52:47 +0000
Subject: [tei-council] <stage> in divliminal
In-Reply-To: <4FCE4590.5000902@retired.ox.ac.uk>
References: <AC630758-AEFF-43C5-83F5-042B198ACBC5@oucs.ox.ac.uk>
	<4FCE4590.5000902@retired.ox.ac.uk>
Message-ID: <138267e9-058b-4ebf-8738-0259bd5c580f@HUB02.ad.oak.ox.ac.uk>


On 5 Jun 2012, at 10:44, Lou Burnard wrote:

> On 05/06/12 19:26, Sebastian Rahtz wrote:
>> anyone got any views on this fragment of markup? in the TEI, it is illegal, because
>> of the<stage>  in between the two<head>  elements.
>> 
>>  <lg n="14" type="song">
>>                      <head>SONG.</head>
>>                      <stage>Sung by Priests.</stage>
>>                      <head>AIR XIV.</head>
>>                      <byline>Set by Mr.<hi>Charke.</hi>
>>                      </byline>
>> 
>> should<stage>  be allowed up amongst the divliminal?
> 
> 
> I would say no. It's another heading, arguably part of the first one 
> (but I suppose you could put the <stage> inside the first <head> )
> 

check. I can solve this by wrapping the <stage> in a <head>. good.

--
Sebastian Rahtz      
Head of Information and Support Group
Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431







From PFSchaffner at umich.edu  Tue Jun  5 14:22:23 2012
From: PFSchaffner at umich.edu (Paul F. Schaffner)
Date: Tue, 5 Jun 2012 14:22:23 -0400 (EDT)
Subject: [tei-council] <stage> in divliminal
In-Reply-To: <138267e9-058b-4ebf-8738-0259bd5c580f@HUB02.ad.oak.ox.ac.uk>
References: <AC630758-AEFF-43C5-83F5-042B198ACBC5@oucs.ox.ac.uk>
	<4FCE4590.5000902@retired.ox.ac.uk>
	<138267e9-058b-4ebf-8738-0259bd5c580f@HUB02.ad.oak.ox.ac.uk>
Message-ID: <Pine.LNX.4.64.1206051412320.30451@goldenaxe.gpcc.itd.umich.edu>

FWIW, we have always been doubtful about the true character of
such performance notes. As Lou says, they are (given an expansive
definition of 'head'), a kind of heading; or may be regarded
as a kind of note; or a stage direction (which is, after all,
just a kind of note); or in some cases even a byline -- the
last in cases where the performer is regarded as consequential,
and parallel to other responsible parties:

      PROLOGUE
   Written by Mr. Jones
   Sung By Mrs. Bracegirdle
   Set to music by Mr. Smith

The particular example given by Sebastian I think I would be
inclined simply to include within the first <head>, or as
a second subhead, but without the <stage>. I.e., the defining
heading for this piece is "Song sung by priests" not SONG. (<< sung
by priests).

For purposes of conversion, wrapping in <head> sounds fine.

pfs




On Tue, 5 Jun 2012, Sebastian Rahtz wrote:

>
> On 5 Jun 2012, at 10:44, Lou Burnard wrote:
>
>> On 05/06/12 19:26, Sebastian Rahtz wrote:
>>> anyone got any views on this fragment of markup? in the TEI, it is illegal, because
>>> of the<stage>  in between the two<head>  elements.
>>>
>>>  <lg n="14" type="song">
>>>                      <head>SONG.</head>
>>>                      <stage>Sung by Priests.</stage>
>>>                      <head>AIR XIV.</head>
>>>                      <byline>Set by Mr.<hi>Charke.</hi>
>>>                      </byline>
>>>
>>> should<stage>  be allowed up amongst the divliminal?
>>
>>
>> I would say no. It's another heading, arguably part of the first one
>> (but I suppose you could put the <stage> inside the first <head> )
>>
>
> check. I can solve this by wrapping the <stage> in a <head>. good.
>
> --
> Sebastian Rahtz
> Head of Information and Support Group
> Oxford University Computing Services
> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>
>
>
>
>
>
> -- 
> tei-council mailing list
> tei-council at lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>
> PLEASE NOTE: postings to this list are publicly archived
>
>
>

--------------------------------------------------------------------
Paul Schaffner | PFSchaffner at umich.edu | http://www.umich.edu/~pfs/
316-C Hatcher Library N, Univ. of Michigan, Ann Arbor MI 48109-1190
--------------------------------------------------------------------

From james.cummings at oucs.ox.ac.uk  Tue Jun  5 16:18:28 2012
From: james.cummings at oucs.ox.ac.uk (James Cummings)
Date: Tue, 5 Jun 2012 20:18:28 +0000
Subject: [tei-council] <stage> in divliminal
In-Reply-To: <4FCE4590.5000902@retired.ox.ac.uk>
References: <AC630758-AEFF-43C5-83F5-042B198ACBC5@oucs.ox.ac.uk>,
	<4FCE4590.5000902@retired.ox.ac.uk>
Message-ID: <d19647fb-7e12-456b-9f35-638e8971f68c@HUB05.ad.oak.ox.ac.uk>


Note also that all of this is encoded inside a <sp> (mistakenly I would argue).

JamesC
--
James Cummings, InfoDev, OUCS, University of Oxford (from phone)

Lou Burnard <lou.burnard at retired.ox.ac.uk> wrote:


On 05/06/12 19:26, Sebastian Rahtz wrote:
> anyone got any views on this fragment of markup? in the TEI, it is illegal, because
> of the<stage>  in between the two<head>  elements.
>
>   <lg n="14" type="song">
>                       <head>SONG.</head>
>                       <stage>Sung by Priests.</stage>
>                       <head>AIR XIV.</head>
>                       <byline>Set by Mr.<hi>Charke.</hi>
>                       </byline>
>
> should<stage>  be allowed up amongst the divliminal?


I would say no. It's another heading, arguably part of the first one
(but I suppose you could put the <stage> inside the first <head> )

--
tei-council mailing list
tei-council at lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

PLEASE NOTE: postings to this list are publicly archived

From PFSchaffner at umich.edu  Tue Jun  5 17:05:27 2012
From: PFSchaffner at umich.edu (Paul F. Schaffner)
Date: Tue, 5 Jun 2012 17:05:27 -0400 (EDT)
Subject: [tei-council] <stage> in divliminal
In-Reply-To: <d19647fb-7e12-456b-9f35-638e8971f68c@HUB05.ad.oak.ox.ac.uk>
References: <AC630758-AEFF-43C5-83F5-042B198ACBC5@oucs.ox.ac.uk>,
	<4FCE4590.5000902@retired.ox.ac.uk>
	<d19647fb-7e12-456b-9f35-638e8971f68c@HUB05.ad.oak.ox.ac.uk>
Message-ID: <Pine.LNX.4.64.1206051648450.30451@goldenaxe.gpcc.itd.umich.edu>

On Tue, 5 Jun 2012, James Cummings wrote:

> Note also that all of this is encoded inside a <sp> (mistakenly I would argue).
>
> JamesC

FWIW, I've pasted in a somewhat fuller context below.
The page image, for those at ECCO-owning institutions, is on
the Gale site at
http://find.galegroup.com/ecco/infomark.do?docType=ECCOArticles&docLevel=FASCIMILE&prodId=ECCO&tabID=T001&type=multipage&version=1.0&docId=CW3307931635&contentSet=ECCOArticles&relevancePageBatch=CW107931610&source=gale

I'd say:
(1) this song is less speech-like than many, and could easily
     do without the <sp> tags. As James says.
(2) but other such songs often include overt signs of
     dramatic form and really do belong within <sp> tags.
(3) the more problematic choice, I think, was to tag the
     song as an <lg> -- a question that has arisen before.
     We do it, but have tended to move away from it, and
     now generally prefer to tag discreet songs in drama
     as floating texts. If the song is divided between
     speakers, floatingText is the only choice (now supplemented
     in some cases by <spGrp> -- though not if the song
     contains a <byline>).
(4) the reason we allow <stage> (rightly or wrongly in this case)
     in that unfortunate position amongst the div-liminals
     is that we regard <stage> as a specialization of <note>.

pfs

Context for Sebastian's passage:

<sp>
<speaker>King.</speaker>
<l><hi>Mirza,</hi> my Scourge of War, ploughs thro' the Main,</l>
<l>The Fear and Terror of proud neighb'ring <hi>Spain.</hi></l>
<l>Yet, happy as I seem, I've something here <stage>Aside.</stage></l>
<l>Which speaks a boding Revolution near. <stage>Aside.</stage></l>
<l>Let me have Music to compose my Breast,</l>
<l>And lull my Senses to a pleasing Rest.</l>
</sp>
<sp>
<lg n="14" type="song">
<head>SONG.</head>
<stage>Sung by Priests.</stage>
<head>AIR XIV.</head>
<byline>Set by Mr. <hi>Charke.</hi></byline>
<gap reason="music">
<lg>
<l>Great <hi>Amurath</hi> all Hearts obey,</l>
<l>Who rules the World with settled Sway,</l>
<l>And does with peaceful Homage meet:</l>
<pb n="24" ref="27">
<l>His silver Crescents shine so bright,</l>
<l>They put out ev'ry other Light,</l>
<l>And Nations bow beneath his Feet.</l>
</lg>
</lg>
</sp>
<stage>[After the Song, a Dance of Moors.]</stage>
<stage>Trumpets within.</stage>
<stage>Enter <hi>Mirza,</hi> attended. He Kneels.</stage>
<sp>
<speaker>Mirz.</speaker>
<l>Long live the mighty King and Queen of <hi>Tunis!</hi></l>
<l>May Conquest ever on their Arms attend,</l>
<l>And living Laurels crown their Royal Brows!</l>
</sp>
















> --
> James Cummings, InfoDev, OUCS, University of Oxford (from phone)
>
> Lou Burnard <lou.burnard at retired.ox.ac.uk> wrote:
>
>
> On 05/06/12 19:26, Sebastian Rahtz wrote:
>> anyone got any views on this fragment of markup? in the TEI, it is illegal, because
>> of the<stage>  in between the two<head>  elements.
>>
>>   <lg n="14" type="song">
>>                       <head>SONG.</head>
>>                       <stage>Sung by Priests.</stage>
>>                       <head>AIR XIV.</head>
>>                       <byline>Set by Mr.<hi>Charke.</hi>
>>                       </byline>
>>
>> should<stage>  be allowed up amongst the divliminal?
>
>
> I would say no. It's another heading, arguably part of the first one
> (but I suppose you could put the <stage> inside the first <head> )
>
> --
> 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
>
>
>

--------------------------------------------------------------------
Paul Schaffner | PFSchaffner at umich.edu | http://www.umich.edu/~pfs/
316-C Hatcher Library N, Univ. of Michigan, Ann Arbor MI 48109-1190
--------------------------------------------------------------------

From James.Cummings at oucs.ox.ac.uk  Tue Jun  5 17:11:29 2012
From: James.Cummings at oucs.ox.ac.uk (James Cummings)
Date: Tue, 05 Jun 2012 14:11:29 -0700
Subject: [tei-council] party in Victoria
In-Reply-To: <a453642e-9aa3-47c8-9e78-2552fdee18d6@HUB06.ad.oak.ox.ac.uk>
References: <CAA2irtKfgw61F-=9A5zoeQqQ40RWEaOt_n410MZ-RzRA-Qtasg@mail.gmail.com>
	<EB6CE08D-BFEF-45A7-AA47-14683E27E4E9@oucs.ox.ac.uk>
	<4FCE2081.1080701@oucs.ox.ac.uk>
	<Pine.LNX.4.64.1206051116220.30451@goldenaxe.gpcc.itd.umich.edu>
	<a453642e-9aa3-47c8-9e78-2552fdee18d6@HUB06.ad.oak.ox.ac.uk>
Message-ID: <4FCE7601.5020706@oucs.ox.ac.uk>

On 05/06/12 09:12, Sebastian Rahtz wrote:
>> Oddity? in TCP? Surely you jest.
> when he said "oddity" he meant "constructive use of TEI markup"..

I meant "imaginative use of TEI markup".

-James

-- 
Dr James Cummings, InfoDev,
Computing Services, University of Oxford

From James.Cummings at oucs.ox.ac.uk  Tue Jun  5 17:16:22 2012
From: James.Cummings at oucs.ox.ac.uk (James Cummings)
Date: Tue, 05 Jun 2012 14:16:22 -0700
Subject: [tei-council] <stage> in divliminal
In-Reply-To: <Pine.LNX.4.64.1206051648450.30451@goldenaxe.gpcc.itd.umich.edu>
References: <AC630758-AEFF-43C5-83F5-042B198ACBC5@oucs.ox.ac.uk>,
	<4FCE4590.5000902@retired.ox.ac.uk>
	<d19647fb-7e12-456b-9f35-638e8971f68c@HUB05.ad.oak.ox.ac.uk>
	<Pine.LNX.4.64.1206051648450.30451@goldenaxe.gpcc.itd.umich.edu>
Message-ID: <4FCE7726.1090601@oucs.ox.ac.uk>

On 05/06/12 14:05, Paul F. Schaffner wrote:
> (1) this song is less speech-like than many, and could easily
> do without the <sp> tags. As James says.

I've got a problem with <head>s inside <sp> (even if in a nested 
<lg>) because in my poor brain it suggests that the speaker 
spoke/sung the <head>, but in most cases I don't think that is 
what the author/printer intended to be conveyed. (Just that it is 
a non-spoken heading for the bit that is spoken/sung.)  So when I 
see this, I keep thinking it needed to be encoded differently, 
e.,g. as with floatingText as you suggest. I'm not saying this is 
wrong, just that it makes me do a double-take, imho.

> (4) the reason we allow <stage> (rightly or wrongly in this case)
> in that unfortunate position amongst the div-liminals
> is that we regard <stage> as a specialization of <note>.

That seems reasonable, it is a note in the same way a marginal 
annotation is a note.

-James
-- 
Dr James Cummings, InfoDev,
Computing Services, University of Oxford

From sebastian.rahtz at oucs.ox.ac.uk  Tue Jun  5 17:18:01 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Tue, 5 Jun 2012 21:18:01 +0000
Subject: [tei-council] EEBO and ECCO to P5
Message-ID: <A30FF574-9653-4D70-A6CD-1C0DE14D0B2E@oucs.ox.ac.uk>

I now have all 42496 texts from EEBO and ECCO in a state where they are valid
against a variant of P5. About 2000 of these are NOT valid against tei_all, for
one or more of the reasons listed below. Sorry, I don't have the data
to say which of these customizations triggers how many failed validations.

The transform is at http://tei.svn.sourceforge.net/viewvc/tei/trunk/Stylesheets/tcp/tcp2tei.xsl?revision=10451&view=markup
for those who like that sort of thing.

I thought it would be worth pasting in below my whole current ODD,
so you can see the relaxations to content models which 
I have had to put in. Some are also SF tickets.

Some of these things will come out of ongoing work around divliminal,
but most of what you see here are fairly mundanely allowing
combinations you may well think are weird, but do seem to occur
in the TCP wild.

Obviously, I'd be really really keen to see if we can resolve
these remaining things in time for the TCP conference in September,
but that may be a big ask. The rather hard task is to review the changes
I am doing in tcp2tei.xsl and see if any of them are Wrong.

Paul can probably supply examples faster than me as needed.

	<!-- relax data type of @n for now. This caters for n="?" . in SF as a bug report -->
	<classSpec ident="att.global" mode="change" xmlns="http://www.tei-c.org/ns/1.0">
	  <attList>
	    <attDef ident="n" mode="change">
	      <datatype>
		<text xmlns="http://relaxng.org/ns/structure/1.0"/>
	      </datatype>
	    </attDef>
	  </attList>
	</classSpec>

	<!-- signed gets looser content model (paraContent, not
	     phraseSeq) and allowed to appear at top of div as well as
	     bottom-->
        <elementSpec xmlns="http://www.tei-c.org/ns/1.0" mode="change" ident="signed">
	  <classes model="replace">
	    <memberOf key="att.global"/>
	    <memberOf key="model.divBottomPart"/>
	    <memberOf key="model.divTopPart"/>
	  </classes>
          <content>
            <ref xmlns="http://relaxng.org/ns/structure/1.0" name="macro.paraContent"/>
          </content>
        </elementSpec>

	<!-- stage gets placement attributes, and allowed in model.phrase -->
        <elementSpec xmlns="http://www.tei-c.org/ns/1.0" mode="change" ident="stage">
          <classes mode="replace">
            <memberOf key="att.global"/>
            <memberOf key="att.placement"/>
            <memberOf key="model.stageLike"/>
            <memberOf key="model.phrase"/>
          </classes>
        </elementSpec>

	<!-- salute gets looser content model (paraContent, not
	     phraseSeq) to let it contain <list> EEBO A00583, A15145 -->
        <elementSpec xmlns="http://www.tei-c.org/ns/1.0" mode="change" ident="salute">
	  <content>
	    <ref xmlns="http://relaxng.org/ns/structure/1.0" name="macro.paraContent"/>
	  </content>
        </elementSpec>

	<!-- trailer gets looser content model to let it contain <l> -->
        <elementSpec xmlns="http://www.tei-c.org/ns/1.0" mode="change" ident="trailer">
	  <content>
	    <zeroOrMore xmlns="http://relaxng.org/ns/structure/1.0">
	      <choice>
		<text/>
		<ref name="lg"/>
		<ref name="model.gLike"/>
		<ref name="model.phrase"/>
		<ref name="model.inter"/>
		<ref name="model.lLike"/>
		<ref name="model.global"/>
	      </choice>
	    </zeroOrMore>
	  </content>
        </elementSpec>

	<!-- cell gets looser content model (specialPara) -->
	<elementSpec xmlns="http://www.tei-c.org/ns/1.0" mode="change" ident="cell">
	  <content>
	    <ref xmlns="http://relaxng.org/ns/structure/1.0" name="macro.specialPara"/>
	  </content>
	</elementSpec>

	<!-- closer is allowed to have postscript inside -->
	<elementSpec xmlns="http://www.tei-c.org/ns/1.0" mode="change" ident="closer">
	  <content>
	    <zeroOrMore xmlns="http://relaxng.org/ns/structure/1.0">
	      <choice>
		<text/>
		<ref name="model.gLike"/>
		<ref name="signed"/>
		<ref name="postscript"/>
		<ref name="dateline"/>
		<ref name="salute"/>
		<ref name="model.phrase"/>
		<ref name="model.global"/>
	      </choice>
	    </zeroOrMore>
	  </content>
	</elementSpec>

	<!-- label gets looser content model -->
	<elementSpec xmlns="http://www.tei-c.org/ns/1.0" mode="change" ident="label">
	  <content>
	    <ref xmlns="http://relaxng.org/ns/structure/1.0" name="macro.specialPara"/>
	  </content>
	</elementSpec>

	<!-- 
	     table needs to allow model.divBottomPart at end, to cater for trailer 
	     https://sourceforge.net/tracker/?func=detail&aid=3531957&group_id=106328&atid=644065

	-->
	<elementSpec xmlns="http://www.tei-c.org/ns/1.0" mode="change" ident="table">
	  <content>
	    <group xmlns="http://relaxng.org/ns/structure/1.0">
	      <zeroOrMore>
		<choice>
		  <ref name="model.headLike"/>
		  <ref name="model.global"/>
		</choice>
	      </zeroOrMore>
	      <choice>
		<oneOrMore>
		  <ref name="row"/>
		  <zeroOrMore>
		    <ref name="model.global"/>
		  </zeroOrMore>
		</oneOrMore>
		<oneOrMore>
		  <group>
		    <ref name="model.graphicLike"/>
		  </group>
		  <zeroOrMore>
		    <ref name="model.global"/>
		  </zeroOrMore>
		</oneOrMore>
	      </choice>
	      <zeroOrMore>
		<ref name="model.divBottomPart"/>
	      </zeroOrMore>
	    </group>
	  </content>
	</elementSpec>

	<!-- a div with just figure and closer. see
	     https://sourceforge.net/tracker/?func=detail&aid=3531963&group_id=106328&atid=644062

             This is much harder than it looks, the solution below produces non-deterministic
	     DTDs
	-->
	<elementSpec xmlns="http://www.tei-c.org/ns/1.0" mode="change" ident="div">
	  <content>
	    <choice xmlns="http://relaxng.org/ns/structure/1.0">	      
	      <group>
		<zeroOrMore>
		  <choice>
		    <ref name="model.divTop"/>
		    <ref name="model.global"/>
		  </choice>
		</zeroOrMore>
		<optional>
		  <choice>
		    <group>
		      <oneOrMore>
			<choice>
			  <ref name="model.divLike"/>
			  <ref name="model.divGenLike"/>
			</choice>
			<zeroOrMore>
			  <ref name="model.global"/>
			</zeroOrMore>
		      </oneOrMore>
		    </group>
		    <group>
		      <oneOrMore>
			<group>
			  <ref name="model.common"/>
			</group>
			<zeroOrMore>
			  <ref name="model.global"/>
			</zeroOrMore>
		      </oneOrMore>
		      <zeroOrMore>
			<choice>
			  <ref name="model.divLike"/>
			  <ref name="model.divGenLike"/>
			</choice>
			<zeroOrMore>
			  <ref name="model.global"/>
			</zeroOrMore>
		      </zeroOrMore>
		    </group>
		  </choice>
		  <zeroOrMore>
		    <group>
		      <ref name="model.divBottom"/>
		    </group>
		    <zeroOrMore>
		      <ref name="model.global"/>
		    </zeroOrMore>
		  </zeroOrMore>
		</optional>
	      </group>

	      <group>
		<zeroOrMore>
		  <ref name="model.global"/>
		</zeroOrMore>
		<optional>
		  <group>
		    <ref name="model.divTop"/>		  
		  </group>
		  <zeroOrMore>
		    <choice>
		      <ref name="model.global"/>
		      <ref name="model.divTop"/>		 
		    </choice>
		  </zeroOrMore>
		</optional>
		<optional>
		  <group>
		    <ref name="model.divBottom"/>		  
		  </group>
		  <zeroOrMore>
		    <choice>
		      <ref name="model.global"/>
		      <ref name="model.divBottom"/>		 
		    </choice>
		  </zeroOrMore>
		</optional>
	      </group>	      
	    </choice>
	  </content>
	</elementSpec>	
--
Sebastian Rahtz      
Head of Information and Support Group
Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431







From sebastian.rahtz at oucs.ox.ac.uk  Tue Jun  5 17:24:18 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Tue, 5 Jun 2012 21:24:18 +0000
Subject: [tei-council] <stage> in divliminal
In-Reply-To: <4FCE7726.1090601@oucs.ox.ac.uk>
References: <AC630758-AEFF-43C5-83F5-042B198ACBC5@oucs.ox.ac.uk>,
	<4FCE4590.5000902@retired.ox.ac.uk>
	<d19647fb-7e12-456b-9f35-638e8971f68c@HUB05.ad.oak.ox.ac.uk>
	<Pine.LNX.4.64.1206051648450.30451@goldenaxe.gpcc.itd.umich.edu>
	<4FCE7726.1090601@oucs.ox.ac.uk>
Message-ID: <61665890-7077-4c64-b84d-4fc9eb4472ff@HUB03.ad.oak.ox.ac.uk>


On 5 Jun 2012, at 14:16, James Cummings wrote:

>  So when I 
> see this, I keep thinking it needed to be encoded differently, 
> e.,g. as with floatingText as you suggest. I'm not saying this is 
> wrong, just that it makes me do a double-take, imho.

But let's be clear, redoing the markup like that is
probably not within the scope of an automated transform
(unless you want to try....). 

You may like to try doing an analysis of the 40k texts
to see how many occurrences of this slightly dodgy
markup which you can find. 
> 
>> (4) the reason we allow <stage> (rightly or wrongly in this case)
>> in that unfortunate position amongst the div-liminals
>> is that we regard <stage> as a specialization of <note>.
> 
> That seems reasonable, it is a note in the same way a marginal 
> annotation is a note.



I am not convinced that the sequence head note head would be
legal either
--
Sebastian Rahtz      
Head of Information and Support Group
Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431







From lou.burnard at retired.ox.ac.uk  Tue Jun  5 17:32:08 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Tue, 05 Jun 2012 23:32:08 +0200
Subject: [tei-council] [ tei-Bugs-3532022 ] <lg> should be allowed in <p>
In-Reply-To: <4FCE2A10.4060502@uvic.ca>
References: <1338909911-30293@relay1.mail.ox.ac.uk>
	<4FCE2683.3030007@retired.ox.ac.uk> <4FCE2A10.4060502@uvic.ca>
Message-ID: <4FCE7AD8.8060301@retired.ox.ac.uk>

Looking at the content models, it's clear (and experiment confirms) that 
the way to do this would be to remove lg from membership in 
model.divPart before adding it to model.inter

Anything else is guaranteed to lead to tears before bedtime



On 05/06/12 17:47, Martin Holmes wrote:
> On 12-06-05 08:32 AM, Lou Burnard wrote:
>> On 05/06/12 17:25, SourceForge.net wrote:
>>>> Comment By: Martin Holmes (martindholmes)
>>> Date: 2012-06-05 08:25
>>>
>>> Message:
>>> I think the simplest way to do this would be to add<lg> to model.inter
>>> ("elements which can appear either within or between paragraph-like
>>> elements"). Does anyone see any objection to this?
>>>
>>
>> by all means try this, but i predict that numerous non-deterministic
>> content models will be the result
>
> Why do you think so? How is <lg> being a member of model.inter likely to
> result in this when (say) <castList> being a member is not?
>
> I'm asking rather than just steaming ahead and trying it because by the
> time the build breaks I'll be in a workshop and I won't be able to fix
> any resulting problem for hours.
>
> Cheers,
> Martin
>


From James.Cummings at oucs.ox.ac.uk  Tue Jun  5 17:38:12 2012
From: James.Cummings at oucs.ox.ac.uk (James Cummings)
Date: Tue, 05 Jun 2012 14:38:12 -0700
Subject: [tei-council] <stage> in divliminal
In-Reply-To: <F4EDCFCD-B48B-4E76-B3FC-C353DE4AC80B@oucs.ox.ac.uk>
References: <AC630758-AEFF-43C5-83F5-042B198ACBC5@oucs.ox.ac.uk>,
	<4FCE4590.5000902@retired.ox.ac.uk>
	<d19647fb-7e12-456b-9f35-638e8971f68c@HUB05.ad.oak.ox.ac.uk>
	<Pine.LNX.4.64.1206051648450.30451@goldenaxe.gpcc.itd.umich.edu>
	<4FCE7726.1090601@oucs.ox.ac.uk>
	<F4EDCFCD-B48B-4E76-B3FC-C353DE4AC80B@oucs.ox.ac.uk>
Message-ID: <4FCE7C44.70107@oucs.ox.ac.uk>

On 05/06/12 14:24, Sebastian Rahtz wrote:
> But let's be clear, redoing the markup like that is
> probably not within the scope of an automated transform
> (unless you want to try....).

Oh of course not.  But if we came up with some small number of 
instances where we thought TCP had got their markup just wrong, 
then maybe they would be willing to correct it.  (only if a small 
number of cases).

> You may like to try doing an analysis of the 40k texts
> to see how many occurrences of this slightly dodgy
> markup which you can find.

I would enjoy doing that (and other corpus markup queries)... 
when I've got a round tuit.

-JamesC

-- 
Dr James Cummings, InfoDev,
Computing Services, University of Oxford

From PFSchaffner at umich.edu  Tue Jun  5 18:13:05 2012
From: PFSchaffner at umich.edu (Paul F. Schaffner)
Date: Tue, 5 Jun 2012 18:13:05 -0400 (EDT)
Subject: [tei-council] <stage> in divliminal
In-Reply-To: <4FCE7C44.70107@oucs.ox.ac.uk>
References: <AC630758-AEFF-43C5-83F5-042B198ACBC5@oucs.ox.ac.uk>,
	<4FCE4590.5000902@retired.ox.ac.uk>
	<d19647fb-7e12-456b-9f35-638e8971f68c@HUB05.ad.oak.ox.ac.uk>
	<Pine.LNX.4.64.1206051648450.30451@goldenaxe.gpcc.itd.umich.edu>
	<4FCE7726.1090601@oucs.ox.ac.uk>
	<F4EDCFCD-B48B-4E76-B3FC-C353DE4AC80B@oucs.ox.ac.uk>
	<4FCE7C44.70107@oucs.ox.ac.uk>
Message-ID: <Pine.LNX.4.64.1206051810100.30451@goldenaxe.gpcc.itd.umich.edu>

> But if we came up with some small number of instances 
> where we thought TCP had got their markup just wrong, then maybe they would 
> be willing to correct it.  (only if a small number of cases).

Believe it or not, what you see now is the product of many
journeys back into the data, correcting existing books on the
basis of newly discovered inconsistencies or outright blunders.

So yes, to the extent that time allows, we (and that means
'I' because that's who does it) are always willing to correct.

pfs

--------------------------------------------------------------------
Paul Schaffner | PFSchaffner at umich.edu | http://www.umich.edu/~pfs/
316-C Hatcher Library N, Univ. of Michigan, Ann Arbor MI 48109-1190
--------------------------------------------------------------------

From sebastian.rahtz at oucs.ox.ac.uk  Tue Jun  5 19:02:18 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Tue, 5 Jun 2012 23:02:18 +0000
Subject: [tei-council] <stage> in divliminal
In-Reply-To: <4FCE7C44.70107@oucs.ox.ac.uk>
References: <AC630758-AEFF-43C5-83F5-042B198ACBC5@oucs.ox.ac.uk>,
	<4FCE4590.5000902@retired.ox.ac.uk>
	<d19647fb-7e12-456b-9f35-638e8971f68c@HUB05.ad.oak.ox.ac.uk>
	<Pine.LNX.4.64.1206051648450.30451@goldenaxe.gpcc.itd.umich.edu>
	<4FCE7726.1090601@oucs.ox.ac.uk>
	<F4EDCFCD-B48B-4E76-B3FC-C353DE4AC80B@oucs.ox.ac.uk>
	<4FCE7C44.70107@oucs.ox.ac.uk>
Message-ID: <7da7bd68-4d97-4f98-a295-d038f280b172@HUB01.ad.oak.ox.ac.uk>


On 5 Jun 2012, at 14:38, James Cummings wrote:
> 
> I would enjoy doing that (and other corpus markup queries)... when I've got a round tuit.
> 

we just saw one of those :-}

(James and I just witnessed the transit of venus)

--
Sebastian Rahtz      
Head of Information and Support Group
Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431







From mholmes at uvic.ca  Tue Jun  5 19:52:59 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Tue, 5 Jun 2012 16:52:59 -0700
Subject: [tei-council] [ tei-Bugs-3532022 ] <lg> should be allowed in <p>
In-Reply-To: <4FCE7AD8.8060301@retired.ox.ac.uk>
References: <1338909911-30293@relay1.mail.ox.ac.uk>
	<4FCE2683.3030007@retired.ox.ac.uk> <4FCE2A10.4060502@uvic.ca>
	<4FCE7AD8.8060301@retired.ox.ac.uk>
Message-ID: <4FCE9BDB.5050508@uvic.ca>

On 12-06-05 02:32 PM, Lou Burnard wrote:
> Looking at the content models, it's clear (and experiment confirms) that
> the way to do this would be to remove lg from membership in
> model.divPart before adding it to model.inter
>
> Anything else is guaranteed to lead to tears before bedtime

That makes sense.

model.divPart also includes model.lLike (<l>), and now I wonder if as 
soon as we do this for <lg> the case for doing it with <l> raises its 
ugly head too.

When I get a moment, I'll try to summarize all this on the ticket. I 
pointed Joe, who reported the problem, at the ticket so he could see how 
we dealt with it.

Cheers,
Martin

> On 05/06/12 17:47, Martin Holmes wrote:
>> On 12-06-05 08:32 AM, Lou Burnard wrote:
>>> On 05/06/12 17:25, SourceForge.net wrote:
>>>>> Comment By: Martin Holmes (martindholmes)
>>>> Date: 2012-06-05 08:25
>>>>
>>>> Message:
>>>> I think the simplest way to do this would be to add<lg>  to model.inter
>>>> ("elements which can appear either within or between paragraph-like
>>>> elements"). Does anyone see any objection to this?
>>>>
>>>
>>> by all means try this, but i predict that numerous non-deterministic
>>> content models will be the result
>>
>> Why do you think so? How is<lg>  being a member of model.inter likely to
>> result in this when (say)<castList>  being a member is not?
>>
>> I'm asking rather than just steaming ahead and trying it because by the
>> time the build breaks I'll be in a workshop and I won't be able to fix
>> any resulting problem for hours.
>>
>> Cheers,
>> Martin
>>
>

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From syeates at gmail.com  Mon Jun 11 04:52:30 2012
From: syeates at gmail.com (stuart yeates)
Date: Mon, 11 Jun 2012 20:52:30 +1200
Subject: [tei-council] error in Spec for node?
Message-ID: <4FD5B1CE.2010408@gmail.com>

The spec for node has a remark at the bottom which makes no sense to me 
as a remark on node. It does, however, make perfect sense as a remark 
for arc and there is a similar remark on the arc spec.

Unless someone has a sane explanation of it's existence, I'm proposing 
to delete the remark from node.

cheers
stuart

From lou.burnard at retired.ox.ac.uk  Mon Jun 11 05:00:57 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Mon, 11 Jun 2012 11:00:57 +0200
Subject: [tei-council] error in Spec for node?
In-Reply-To: <4FD5B1CE.2010408@gmail.com>
References: <4FD5B1CE.2010408@gmail.com>
Message-ID: <4FD5B3C9.9040803@retired.ox.ac.uk>

I think it's useful. The point is that in the TEI representation of a 
network, you can specify the arcs either explicitly, using <arc>, or 
implicitly using the attributes on <node> . In either case, there is a 
need to explain how arcs may be labelled, and to specify what it means 
if there is more than one of them.

Maybe the version of these remarks on <node> would be improved by 
changing "arc" to "implied arc" (or some such phrase)

On 11/06/12 10:52, stuart yeates wrote:
> The spec for node has a remark at the bottom which makes no sense to me
> as a remark on node. It does, however, make perfect sense as a remark
> for arc and there is a similar remark on the arc spec.
>
> Unless someone has a sane explanation of it's existence, I'm proposing
> to delete the remark from node.
>
> cheers
> stuart


From rwelzenbach at gmail.com  Mon Jun 11 22:23:42 2012
From: rwelzenbach at gmail.com (Rebecca Welzenbach)
Date: Mon, 11 Jun 2012 22:23:42 -0400
Subject: [tei-council] tei-c.org search acting up?
Message-ID: <CAA2irtJhH5M877419GGYv=3p3v2gWaOKV5V6LPL3vAjsQL3xeQ@mail.gmail.com>

Hi all,

I'm having trouble searching the TEI website (or either version of the
Guidelines). When I use the search bar to look for anything in the
website, I get this error:

<Error>
<Code>AllAccessDisabled</Code>
<Message>All access to this object has been disabled</Message>
<RequestId>81D19359192A7E39</RequestId>
<HostId>
sw0AljC21kcab29A9KiqDRTy6vNY3bSGUQGozMWH4ugwezhuararQGCb+cXOlCHK
</HostId>
</Error>
#next_pages_container { width: 5px; hight: 5px; position: absolute;
top: -100px; left: -100px; z-index: 2147483647 !important; }

Was definitely working earlier today (more than 12 hours ago)

Any ideas?

Becky

From dsewell at virginia.edu  Mon Jun 11 23:05:14 2012
From: dsewell at virginia.edu (David Sewell)
Date: Mon, 11 Jun 2012 23:05:14 -0400 (EDT)
Subject: [tei-council] tei-c.org search acting up?
In-Reply-To: <CAA2irtJhH5M877419GGYv=3p3v2gWaOKV5V6LPL3vAjsQL3xeQ@mail.gmail.com>
References: <CAA2irtJhH5M877419GGYv=3p3v2gWaOKV5V6LPL3vAjsQL3xeQ@mail.gmail.com>
Message-ID: <alpine.OSX.2.00.1206112304580.6752@betwix.local>

Some temporary Google glitch? I'm getting results at the moment.

On Mon, 11 Jun 2012, Rebecca Welzenbach wrote:

> Hi all,
>
> I'm having trouble searching the TEI website (or either version of the
> Guidelines). When I use the search bar to look for anything in the
> website, I get this error:
>
> <Error>
> <Code>AllAccessDisabled</Code>
> <Message>All access to this object has been disabled</Message>
> <RequestId>81D19359192A7E39</RequestId>
> <HostId>
> sw0AljC21kcab29A9KiqDRTy6vNY3bSGUQGozMWH4ugwezhuararQGCb+cXOlCHK
> </HostId>
> </Error>
> #next_pages_container { width: 5px; hight: 5px; position: absolute;
> top: -100px; left: -100px; z-index: 2147483647 !important; }
>
> Was definitely working earlier today (more than 12 hours ago)
>
> Any ideas?
>
> Becky
>

-- 
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 mholmes at uvic.ca  Tue Jun 12 19:42:07 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Tue, 12 Jun 2012 16:42:07 -0700
Subject: [tei-council] Location of <app>s for external apparatus
Message-ID: <4FD7D3CF.50605@uvic.ca>

Hi all,

This ticket landed on my plate following Ann Arbor:

<http://purl.org/tei/bug/3497356>

The basic issue was that Jens thought a <listApp> element might be 
useful, for collecting together a set of <app> elements in an apparatus 
which is not embedded in the base text.

These were my instructions:

"MH will ask the submitter (and the TEI-L, pointing to the ticket) for 
any examples of the use of <div> which suggest that <listApp> might be 
useful (for instance, organization of <apps> into multiple <div> s with 
@type). "

However, it seems from the ticket that James, Lou and Jens himself all 
agree that <listApp> is not necessary, so I see no reason to resurrect 
this, other than to add some clarification to the relevant guidelines 
section to suggest that <app>s might be stored in a <div 
type="apparatus"> element.

If no-one has any objections, that's what I'll do, rather than going 
back to Jens or TEI-L.

Cheers,
Martin
-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From mholmes at uvic.ca  Wed Jun 13 14:26:49 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Wed, 13 Jun 2012 11:26:49 -0700
Subject: [tei-council] Location of <app>s for external apparatus
In-Reply-To: <CAC_Lu0YjwL7GMc3UPvk2WUEXKDLenDPFWja_fj+1mjrz33HaKw@mail.gmail.com>
References: <4FD7D3CF.50605@uvic.ca>
	<CAC_Lu0YjwL7GMc3UPvk2WUEXKDLenDPFWja_fj+1mjrz33HaKw@mail.gmail.com>
Message-ID: <4FD8DB69.2060206@uvic.ca>

It turns out <app> cannot be a child of <div> (so either James 
customized his schema when listing <app>s in a <div>, or he's 
misremembering). I'm beginning to think that <listApp> might be a good 
idea as a way of collecting <app>s which are external to the base text, 
but I'm not sure where <listApp> should be available yet, or how. Any 
thoughts?

Cheers,
Martin

On 12-06-12 05:21 PM, Stuart A. Yeates wrote:
> On Wed, Jun 13, 2012 at 11:42 AM, Martin Holmes<mholmes at uvic.ca>  wrote:
>> Hi all,
>>
>> This ticket landed on my plate following Ann Arbor:
>>
>> <http://purl.org/tei/bug/3497356>
>>
>> The basic issue was that Jens thought a<listApp>  element might be
>> useful, for collecting together a set of<app>  elements in an apparatus
>> which is not embedded in the base text.
>>
>> These were my instructions:
>>
>> "MH will ask the submitter (and the TEI-L, pointing to the ticket) for
>> any examples of the use of<div>  which suggest that<listApp>  might be
>> useful (for instance, organization of<apps>  into multiple<div>  s with
>> @type). "
>>
>> However, it seems from the ticket that James, Lou and Jens himself all
>> agree that<listApp>  is not necessary, so I see no reason to resurrect
>> this, other than to add some clarification to the relevant guidelines
>> section to suggest that<app>s might be stored in a<div
>> type="apparatus">  element.
>>
>> If no-one has any objections, that's what I'll do, rather than going
>> back to Jens or TEI-L.
>
> Seems like a sane approach.
>
> cheers
> stuart

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From gabriel.bodard at kcl.ac.uk  Wed Jun 13 15:30:42 2012
From: gabriel.bodard at kcl.ac.uk (Gabriel BODARD)
Date: Wed, 13 Jun 2012 20:30:42 +0100
Subject: [tei-council] Location of <app>s for external apparatus
In-Reply-To: <4FD8DB69.2060206@uvic.ca>
References: <4FD7D3CF.50605@uvic.ca>
	<CAC_Lu0YjwL7GMc3UPvk2WUEXKDLenDPFWja_fj+1mjrz33HaKw@mail.gmail.com>
	<4FD8DB69.2060206@uvic.ca>
Message-ID: <4FD8EA62.6010400@kcl.ac.uk>

For the record, I think I just collect loose apps together in a <p> (or 
sometimes one per <p>, I think my XSLT doesn't care which). In principle 
a listApp would be useful (although it would only be *nice*, rather than 
fixing something that's actually broken), although app should of course 
continue to be available in <p> because we also use them for inline 
apparatus features.

</rambling>

On 13/06/2012 19:26, Martin Holmes wrote:
> It turns out<app>  cannot be a child of<div>  (so either James
> customized his schema when listing<app>s in a<div>, or he's
> misremembering). I'm beginning to think that<listApp>  might be a good
> idea as a way of collecting<app>s which are external to the base text,
> but I'm not sure where<listApp>  should be available yet, or how. Any
> thoughts?
>
> Cheers,
> Martin
>
> On 12-06-12 05:21 PM, Stuart A. Yeates wrote:
>> On Wed, Jun 13, 2012 at 11:42 AM, Martin Holmes<mholmes at uvic.ca>   wrote:
>>> Hi all,
>>>
>>> This ticket landed on my plate following Ann Arbor:
>>>
>>> <http://purl.org/tei/bug/3497356>
>>>
>>> The basic issue was that Jens thought a<listApp>   element might be
>>> useful, for collecting together a set of<app>   elements in an apparatus
>>> which is not embedded in the base text.
>>>
>>> These were my instructions:
>>>
>>> "MH will ask the submitter (and the TEI-L, pointing to the ticket) for
>>> any examples of the use of<div>   which suggest that<listApp>   might be
>>> useful (for instance, organization of<apps>   into multiple<div>   s with
>>> @type). "
>>>
>>> However, it seems from the ticket that James, Lou and Jens himself all
>>> agree that<listApp>   is not necessary, so I see no reason to resurrect
>>> this, other than to add some clarification to the relevant guidelines
>>> section to suggest that<app>s might be stored in a<div
>>> type="apparatus">   element.
>>>
>>> If no-one has any objections, that's what I'll do, rather than going
>>> back to Jens or TEI-L.
>>
>> Seems like a sane approach.
>>
>> cheers
>> stuart
>

-- 
Dr Gabriel BODARD
(Research Associate in Digital Epigraphy)

Department of Digital Humanities
King's College London
26-29 Drury Lane
London WC2B 5RL

Email: gabriel.bodard at kcl.ac.uk
Tel: +44 (0)20 7848 1388
Fax: +44 (0)20 7848 2980

http://www.digitalclassicist.org/
http://www.currentepigraphy.org/

From sebastian.rahtz at oucs.ox.ac.uk  Wed Jun 13 16:00:54 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Wed, 13 Jun 2012 20:00:54 +0000
Subject: [tei-council] Location of <app>s for external apparatus
In-Reply-To: <4FD8EA62.6010400@kcl.ac.uk>
References: <4FD7D3CF.50605@uvic.ca>
	<CAC_Lu0YjwL7GMc3UPvk2WUEXKDLenDPFWja_fj+1mjrz33HaKw@mail.gmail.com>
	<4FD8DB69.2060206@uvic.ca> <4FD8EA62.6010400@kcl.ac.uk>
Message-ID: <F28C0FE3-6B85-42DA-A40F-6AAF51F4E9E5@oucs.ox.ac.uk>

I'd like listApp, to avoid having to say

<back>
      <div type="apparatus">

which just looks wrong. I want to know that I can safely ignore this section when
I am doing simple processing.
--
Sebastian Rahtz      
Head of Information and Support Group
Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431







From mholmes at uvic.ca  Wed Jun 13 17:15:38 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Wed, 13 Jun 2012 14:15:38 -0700
Subject: [tei-council] Location of <app>s for external apparatus
In-Reply-To: <4FD8EA62.6010400@kcl.ac.uk>
References: <4FD7D3CF.50605@uvic.ca>
	<CAC_Lu0YjwL7GMc3UPvk2WUEXKDLenDPFWja_fj+1mjrz33HaKw@mail.gmail.com>
	<4FD8DB69.2060206@uvic.ca> <4FD8EA62.6010400@kcl.ac.uk>
Message-ID: <4FD902FA.3030001@uvic.ca>

I don't really like the idea that <app> inside <p> might be an embedded 
<app>, or it might be an external <app> relating to a <p> somewhere 
else, and the only way to tell is to read @type on the <p>.

In comments on the ticket, I'm suggesting <listApp> as looking rather 
like <listBibl>:

If <listApp> were a member of model.listLike, it would be available in 
core textstructure elements such as <div>. It should also presumably, 
like e.g. <listBibl>, be a member of:

att.global (@xml:id, @n, @xml:lang, @rend, @rendition, @xml:base,
@xml:space) (att.global.linking (@corresp, @synch, @sameAs, @copyOf, 
@next, @prev, @exclude, @select))

(att.global.analytic (@ana)) (att.global.facs (@facs)) 
(att.global.change (@change))

att.sortable (@sortKey)

att.declarable (@default)

att.typed (@type, @subtype)

Cheers,
Martin

On 12-06-13 12:30 PM, Gabriel BODARD wrote:
> For the record, I think I just collect loose apps together in a<p>  (or
> sometimes one per<p>, I think my XSLT doesn't care which). In principle
> a listApp would be useful (although it would only be *nice*, rather than
> fixing something that's actually broken), although app should of course
> continue to be available in<p>  because we also use them for inline
> apparatus features.
>
> </rambling>
>
> On 13/06/2012 19:26, Martin Holmes wrote:
>> It turns out<app>   cannot be a child of<div>   (so either James
>> customized his schema when listing<app>s in a<div>, or he's
>> misremembering). I'm beginning to think that<listApp>   might be a good
>> idea as a way of collecting<app>s which are external to the base text,
>> but I'm not sure where<listApp>   should be available yet, or how. Any
>> thoughts?
>>
>> Cheers,
>> Martin
>>
>> On 12-06-12 05:21 PM, Stuart A. Yeates wrote:
>>> On Wed, Jun 13, 2012 at 11:42 AM, Martin Holmes<mholmes at uvic.ca>    wrote:
>>>> Hi all,
>>>>
>>>> This ticket landed on my plate following Ann Arbor:
>>>>
>>>> <http://purl.org/tei/bug/3497356>
>>>>
>>>> The basic issue was that Jens thought a<listApp>    element might be
>>>> useful, for collecting together a set of<app>    elements in an apparatus
>>>> which is not embedded in the base text.
>>>>
>>>> These were my instructions:
>>>>
>>>> "MH will ask the submitter (and the TEI-L, pointing to the ticket) for
>>>> any examples of the use of<div>    which suggest that<listApp>    might be
>>>> useful (for instance, organization of<apps>    into multiple<div>    s with
>>>> @type). "
>>>>
>>>> However, it seems from the ticket that James, Lou and Jens himself all
>>>> agree that<listApp>    is not necessary, so I see no reason to resurrect
>>>> this, other than to add some clarification to the relevant guidelines
>>>> section to suggest that<app>s might be stored in a<div
>>>> type="apparatus">    element.
>>>>
>>>> If no-one has any objections, that's what I'll do, rather than going
>>>> back to Jens or TEI-L.
>>>
>>> Seems like a sane approach.
>>>
>>> cheers
>>> stuart
>>
>

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From kevin.s.hawkins at ultraslavonic.info  Wed Jun 13 17:43:46 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Wed, 13 Jun 2012 17:43:46 -0400
Subject: [tei-council] Location of <app>s for external apparatus
In-Reply-To: <4FD8EA62.6010400@kcl.ac.uk>
References: <4FD7D3CF.50605@uvic.ca>	<CAC_Lu0YjwL7GMc3UPvk2WUEXKDLenDPFWja_fj+1mjrz33HaKw@mail.gmail.com>	<4FD8DB69.2060206@uvic.ca>
	<4FD8EA62.6010400@kcl.ac.uk>
Message-ID: <4FD90992.9010302@ultraslavonic.info>

Isn't what's broken here the fact that P5 mentions use of an external 
apparatus but gives no clear guidance on how to do this?  Gabby says you 
can do this by "collecting loose apps together in a <p>" ... but this 
sounds like tag abuse to me.  If people want to encode a list of 
apparatus entries, then I think we need to offer <listApp>.

On 6/13/2012 3:30 PM, Gabriel BODARD wrote:
> For the record, I think I just collect loose apps together in a<p>  (or
> sometimes one per<p>, I think my XSLT doesn't care which). In principle
> a listApp would be useful (although it would only be *nice*, rather than
> fixing something that's actually broken), although app should of course
> continue to be available in<p>  because we also use them for inline
> apparatus features.
>
> </rambling>
>
> On 13/06/2012 19:26, Martin Holmes wrote:
>> It turns out<app>   cannot be a child of<div>   (so either James
>> customized his schema when listing<app>s in a<div>, or he's
>> misremembering). I'm beginning to think that<listApp>   might be a good
>> idea as a way of collecting<app>s which are external to the base text,
>> but I'm not sure where<listApp>   should be available yet, or how. Any
>> thoughts?
>>
>> Cheers,
>> Martin
>>
>> On 12-06-12 05:21 PM, Stuart A. Yeates wrote:
>>> On Wed, Jun 13, 2012 at 11:42 AM, Martin Holmes<mholmes at uvic.ca>    wrote:
>>>> Hi all,
>>>>
>>>> This ticket landed on my plate following Ann Arbor:
>>>>
>>>> <http://purl.org/tei/bug/3497356>
>>>>
>>>> The basic issue was that Jens thought a<listApp>    element might be
>>>> useful, for collecting together a set of<app>    elements in an apparatus
>>>> which is not embedded in the base text.
>>>>
>>>> These were my instructions:
>>>>
>>>> "MH will ask the submitter (and the TEI-L, pointing to the ticket) for
>>>> any examples of the use of<div>    which suggest that<listApp>    might be
>>>> useful (for instance, organization of<apps>    into multiple<div>    s with
>>>> @type). "
>>>>
>>>> However, it seems from the ticket that James, Lou and Jens himself all
>>>> agree that<listApp>    is not necessary, so I see no reason to resurrect
>>>> this, other than to add some clarification to the relevant guidelines
>>>> section to suggest that<app>s might be stored in a<div
>>>> type="apparatus">    element.
>>>>
>>>> If no-one has any objections, that's what I'll do, rather than going
>>>> back to Jens or TEI-L.
>>>
>>> Seems like a sane approach.
>>>
>>> cheers
>>> stuart
>>
>

From mholmes at uvic.ca  Wed Jun 13 17:54:56 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Wed, 13 Jun 2012 14:54:56 -0700
Subject: [tei-council] Jenkins builder script now working
Message-ID: <4FD90C30.7050606@uvic.ca>

Hi all,

For the last couple of weeks, I've been working on a new iteration of 
the Jenkins Builder Script which creates a Jenkins Continuous 
Integration server to build the TEI products, like the two we currently 
have running:

<http://tei.oucs.ox.ac.uk/jenkins/>
<http://teijenkins.hcmc.uvic.ca:8080/>

The new build script is intended for the latest Ubuntu Long Term Support 
server edition, which was released in April, and which has five years of 
support. (The last one was based on the 2010 LTS release.)

The script is now tested and working, and available in the TEI 
repository. There's a page on the wiki about it:

<http://wiki.tei-c.org/index.php/Setting_up_a_Jenkins_server>

which I've also updated, and which has links to the script in the repo.

In the next little while, I'll be building a new Jenkins server to run 
at the current UVic address, which will replace the old one.

A couple of points of interest: in this iteration, I've managed to 
remove the dependence on the Sun/Oracle Java JDK, and everything now 
runs on the OpenJDK. That means that there is only one non-free 
component: we still rely on the Microsoft MSTT Core Fonts package, which 
has fonts such as Verdana and Courier in it. How do you feel about 
making an effort to get away from this dependency?

The main Oxford server also creates Kindle output, using the Amazon 
kindlegen tool, but that's not open-source so I haven't included it in 
the Jenkins script. It's easy enough to add it later, and the make file 
detects whether it's there or not before trying to use it.

Note for Sebastian: Is the Hannom font still used? My script still 
downloads it from SourceForge, but when I search the repo, the only 
mentions of it I can find are in my script, and in the guidelines.log 
file I have from building the Guidelines at some point (these lines 
report that it's missing and can't be used). I do see lots of lines like 
this in my pdfbuild.log:

kpathsea: Invalid fontname `HAN NOM A', contains ' '

suggesting that it might not be found by the PDF generation process 
because of naming issues -- the font ttf files are here:

/usr/share/fonts/truetype/hannom/HAN_NOM_A.ttf
/usr/share/fonts/truetype/hannom/HAN_NOM_B.ttf

and they don't have spaces in them.

If we're failing to use the font anyway, without consequences, could we 
find an easier alternative -- something that's in the repos, to keep 
things simpler?

Cheers,
Martin
-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From mholmes at uvic.ca  Wed Jun 13 18:09:25 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Wed, 13 Jun 2012 15:09:25 -0700
Subject: [tei-council] Location of <app>s for external apparatus
In-Reply-To: <4FD90992.9010302@ultraslavonic.info>
References: <4FD7D3CF.50605@uvic.ca>
	<CAC_Lu0YjwL7GMc3UPvk2WUEXKDLenDPFWja_fj+1mjrz33HaKw@mail.gmail.com>
	<4FD8DB69.2060206@uvic.ca>	<4FD8EA62.6010400@kcl.ac.uk>
	<4FD90992.9010302@ultraslavonic.info>
Message-ID: <4FD90F95.8000903@uvic.ca>

Yes -- the issue is:

  - We don't offer guidance

  - The guidance Lou and James suggested offering (putting <app>s in a 
<div>) doesn't actually work

  - Similar solutions look a bit ad-hoc and flaky (putting <app>s in 
e.g. <p>)

So I think everything would be cleaner if we offered <listApp>, and it 
would also give people the option to sort <app>s into groups for 
specific purposes (not sure what those purposes would be, myself) and 
type them with @type and @subtype.

Cheers,
Martin

On 12-06-13 02:43 PM, Kevin Hawkins wrote:
> Isn't what's broken here the fact that P5 mentions use of an external
> apparatus but gives no clear guidance on how to do this?  Gabby says you
> can do this by "collecting loose apps together in a<p>" ... but this
> sounds like tag abuse to me.  If people want to encode a list of
> apparatus entries, then I think we need to offer<listApp>.
>
> On 6/13/2012 3:30 PM, Gabriel BODARD wrote:
>> For the record, I think I just collect loose apps together in a<p>   (or
>> sometimes one per<p>, I think my XSLT doesn't care which). In principle
>> a listApp would be useful (although it would only be *nice*, rather than
>> fixing something that's actually broken), although app should of course
>> continue to be available in<p>   because we also use them for inline
>> apparatus features.
>>
>> </rambling>
>>
>> On 13/06/2012 19:26, Martin Holmes wrote:
>>> It turns out<app>    cannot be a child of<div>    (so either James
>>> customized his schema when listing<app>s in a<div>, or he's
>>> misremembering). I'm beginning to think that<listApp>    might be a good
>>> idea as a way of collecting<app>s which are external to the base text,
>>> but I'm not sure where<listApp>    should be available yet, or how. Any
>>> thoughts?
>>>
>>> Cheers,
>>> Martin
>>>
>>> On 12-06-12 05:21 PM, Stuart A. Yeates wrote:
>>>> On Wed, Jun 13, 2012 at 11:42 AM, Martin Holmes<mholmes at uvic.ca>     wrote:
>>>>> Hi all,
>>>>>
>>>>> This ticket landed on my plate following Ann Arbor:
>>>>>
>>>>> <http://purl.org/tei/bug/3497356>
>>>>>
>>>>> The basic issue was that Jens thought a<listApp>     element might be
>>>>> useful, for collecting together a set of<app>     elements in an apparatus
>>>>> which is not embedded in the base text.
>>>>>
>>>>> These were my instructions:
>>>>>
>>>>> "MH will ask the submitter (and the TEI-L, pointing to the ticket) for
>>>>> any examples of the use of<div>     which suggest that<listApp>     might be
>>>>> useful (for instance, organization of<apps>     into multiple<div>     s with
>>>>> @type). "
>>>>>
>>>>> However, it seems from the ticket that James, Lou and Jens himself all
>>>>> agree that<listApp>     is not necessary, so I see no reason to resurrect
>>>>> this, other than to add some clarification to the relevant guidelines
>>>>> section to suggest that<app>s might be stored in a<div
>>>>> type="apparatus">     element.
>>>>>
>>>>> If no-one has any objections, that's what I'll do, rather than going
>>>>> back to Jens or TEI-L.
>>>>
>>>> Seems like a sane approach.
>>>>
>>>> cheers
>>>> stuart
>>>
>>

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From sebastian.rahtz at oucs.ox.ac.uk  Wed Jun 13 18:31:26 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Wed, 13 Jun 2012 22:31:26 +0000
Subject: [tei-council] Jenkins builder script now working
In-Reply-To: <4FD90C30.7050606@uvic.ca>
References: <4FD90C30.7050606@uvic.ca>
Message-ID: <5E4FD22B-A170-4EED-BBA5-7980BB1994A7@oucs.ox.ac.uk>


On 13 Jun 2012, at 22:54, Martin Holmes wrote:

> That means that there is only one non-free 
> component: we still rely on the Microsoft MSTT Core Fonts package, which 
> has fonts such as Verdana and Courier in it. How do you feel about 
> making an effort to get away from this dependency?

that would mean redefining the fonts used in the Guidelines PDF;
but I wonder which of them?

if you remove them, what fails?

> Note for Sebastian: Is the Hannom font still used?

yes, I am fairly sure its used by some minute fragment of chinese or japanese
in the guidelines.

>  I do see lots of lines like 
> this in my pdfbuild.log:
> 
> kpathsea: Invalid fontname `HAN NOM A', contains ' '
thats ok, its a warning. the font is found. its used on page 1487, by the look of things

> If we're failing to use the font anyway, without consequences, could we 
> find an easier alternative -- something that's in the repos, to keep 
> things simpler?


if there's another obvious free chinese font, I'm happy  to change :-}
--
Sebastian Rahtz      
Head of Information and Support Group
Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431







From sebastian.rahtz at oucs.ox.ac.uk  Wed Jun 13 18:33:55 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Wed, 13 Jun 2012 22:33:55 +0000
Subject: [tei-council] Jenkins builder script now working
In-Reply-To: <5E4FD22B-A170-4EED-BBA5-7980BB1994A7@oucs.ox.ac.uk>
References: <4FD90C30.7050606@uvic.ca>
	<5E4FD22B-A170-4EED-BBA5-7980BB1994A7@oucs.ox.ac.uk>
Message-ID: <C4F523D8-322D-4B4C-8C51-A04142011AD3@oucs.ox.ac.uk>

PS if you open Guidelines.pdf in Acrobat, and look at Properties, you can see a list of the fonts
actually used.
--
Sebastian Rahtz      
Head of Information and Support Group
Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431







From syeates at gmail.com  Wed Jun 13 18:54:19 2012
From: syeates at gmail.com (Stuart A. Yeates)
Date: Thu, 14 Jun 2012 10:54:19 +1200
Subject: [tei-council] Jenkins builder script now working
In-Reply-To: <C4F523D8-322D-4B4C-8C51-A04142011AD3@oucs.ox.ac.uk>
References: <4FD90C30.7050606@uvic.ca>
	<5E4FD22B-A170-4EED-BBA5-7980BB1994A7@oucs.ox.ac.uk>
	<C4F523D8-322D-4B4C-8C51-A04142011AD3@oucs.ox.ac.uk>
Message-ID: <CAC_Lu0bhXucELtAKnHyNnr8TV8WyvXhYrOsKwvVSdH+1xJQBXg@mail.gmail.com>

The site http://www.unifont.org/fontguide/ appears to have a good
script for downloading many free / open source fonts.

Downloading them en mass is probably a good idea if we're encouraging
examples in the guidelines from minority languages.

cheers
stuart

From mholmes at uvic.ca  Wed Jun 13 20:08:20 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Wed, 13 Jun 2012 17:08:20 -0700
Subject: [tei-council] Jenkins builder script now working
In-Reply-To: <C4F523D8-322D-4B4C-8C51-A04142011AD3@oucs.ox.ac.uk>
References: <4FD90C30.7050606@uvic.ca>
	<5E4FD22B-A170-4EED-BBA5-7980BB1994A7@oucs.ox.ac.uk>
	<C4F523D8-322D-4B4C-8C51-A04142011AD3@oucs.ox.ac.uk>
Message-ID: <4FD92B74.7070106@uvic.ca>

On 12-06-13 03:33 PM, Sebastian Rahtz wrote:
> PS if you open Guidelines.pdf in Acrobat, and look at Properties, you can see a list of the fonts
> actually used.

Good tip, and very revealing: it shows the following font families:

DejaVu (free)
Kochi-mincho (free)
Hannom (free)
Junicode (free)
UMingCN (free)

and

Times New Roman (NOT free)

I see no MS fonts in there. If we can find a good substitute for Times 
New Roman, we can dispense with the MS core fonts package, which 
eliminates the one remaining EULA interruption to my script.

Some free variants are listed here:

<http://en.wikipedia.org/wiki/Times_New_Roman#Free_variants>

Cheers,
Martin

> --
> Sebastian Rahtz
> Head of Information and Support Group
> Oxford University Computing Services
> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>
>
>
>
>
>
>

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From mholmes at uvic.ca  Wed Jun 13 20:09:39 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Wed, 13 Jun 2012 17:09:39 -0700
Subject: [tei-council] Jenkins builder script now working
In-Reply-To: <4FD92B74.7070106@uvic.ca>
References: <4FD90C30.7050606@uvic.ca>
	<5E4FD22B-A170-4EED-BBA5-7980BB1994A7@oucs.ox.ac.uk>
	<C4F523D8-322D-4B4C-8C51-A04142011AD3@oucs.ox.ac.uk>
	<4FD92B74.7070106@uvic.ca>
Message-ID: <4FD92BC3.4060804@uvic.ca>

Correction: "I see no OTHER MS fonts in there." (Only Times New Roman.)

On 12-06-13 05:08 PM, Martin Holmes wrote:
> On 12-06-13 03:33 PM, Sebastian Rahtz wrote:
>> PS if you open Guidelines.pdf in Acrobat, and look at Properties, you can see a list of the fonts
>> actually used.
>
> Good tip, and very revealing: it shows the following font families:
>
> DejaVu (free)
> Kochi-mincho (free)
> Hannom (free)
> Junicode (free)
> UMingCN (free)
>
> and
>
> Times New Roman (NOT free)
>
> I see no MS fonts in there. If we can find a good substitute for Times
> New Roman, we can dispense with the MS core fonts package, which
> eliminates the one remaining EULA interruption to my script.
>
> Some free variants are listed here:
>
> <http://en.wikipedia.org/wiki/Times_New_Roman#Free_variants>
>
> Cheers,
> Martin
>
>> --
>> Sebastian Rahtz
>> Head of Information and Support Group
>> Oxford University Computing Services
>> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>>
>>
>>
>>
>>
>>
>>
>

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From sebastian.rahtz at oucs.ox.ac.uk  Thu Jun 14 04:29:25 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Thu, 14 Jun 2012 08:29:25 +0000
Subject: [tei-council] Jenkins builder script now working
In-Reply-To: <CAC_Lu0bhXucELtAKnHyNnr8TV8WyvXhYrOsKwvVSdH+1xJQBXg@mail.gmail.com>
References: <4FD90C30.7050606@uvic.ca>
	<5E4FD22B-A170-4EED-BBA5-7980BB1994A7@oucs.ox.ac.uk>
	<C4F523D8-322D-4B4C-8C51-A04142011AD3@oucs.ox.ac.uk>
	<CAC_Lu0bhXucELtAKnHyNnr8TV8WyvXhYrOsKwvVSdH+1xJQBXg@mail.gmail.com>
Message-ID: <D75EA81B-0D9E-48E0-A1D5-306D6F624456@oucs.ox.ac.uk>


On 13 Jun 2012, at 23:54, Stuart A. Yeates wrote:

> The site http://www.unifont.org/fontguide/ appears to have a good
> script for downloading many free / open source fonts.
> 
> Downloading them en mass is probably a good idea if we're encouraging
> examples in the guidelines from minority languages.
> 

it is not as simple as that - they also have to be joined up in the XeTeX setup,
and incorporated in the web pages somehow.


--
Sebastian Rahtz      
Head of Information and Support Group
Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431

S?lo le pido a Dios
que el futuro no me sea indiferente


From sebastian.rahtz at oucs.ox.ac.uk  Thu Jun 14 04:37:15 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Thu, 14 Jun 2012 08:37:15 +0000
Subject: [tei-council] Jenkins builder script now working
In-Reply-To: <4FD92B74.7070106@uvic.ca>
References: <4FD90C30.7050606@uvic.ca>
	<5E4FD22B-A170-4EED-BBA5-7980BB1994A7@oucs.ox.ac.uk>
	<C4F523D8-322D-4B4C-8C51-A04142011AD3@oucs.ox.ac.uk>
	<4FD92B74.7070106@uvic.ca>
Message-ID: <1EF04476-0F57-4AE8-B5A8-B1B4581F7C5A@oucs.ox.ac.uk>


On 14 Jun 2012, at 01:08, Martin Holmes wrote:

> 
> Good tip, and very revealing: it shows the following font families:
> 
> DejaVu (free)
> Kochi-mincho (free)
> Hannom (free)
> Junicode (free)
> UMingCN (free)
> 
> and
> 
> Times New Roman (NOT free)
> 

changing the main body font of the Guidelines is something that should perhaps not be undertaken
lightly. what do people suggest we use instead?

I am of course suspicious of the open source gnu-ish alternative fonts, as they often
seem to be designed by computer scientists who think xkcd and michelangelo
are more or less the same quality. But hey, whatever makes folks happy :-}

Linux Libertine seems to be the obvious alternative
--
Sebastian Rahtz      
Head of Information and Support Group
Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431

S?lo le pido a Dios
que el futuro no me sea indiferente


From sebastian.rahtz at oucs.ox.ac.uk  Thu Jun 14 06:19:07 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Thu, 14 Jun 2012 10:19:07 +0000
Subject: [tei-council] Jenkins builder script now working
In-Reply-To: <1EF04476-0F57-4AE8-B5A8-B1B4581F7C5A@oucs.ox.ac.uk>
References: <4FD90C30.7050606@uvic.ca>
	<5E4FD22B-A170-4EED-BBA5-7980BB1994A7@oucs.ox.ac.uk>
	<C4F523D8-322D-4B4C-8C51-A04142011AD3@oucs.ox.ac.uk>
	<4FD92B74.7070106@uvic.ca>
	<1EF04476-0F57-4AE8-B5A8-B1B4581F7C5A@oucs.ox.ac.uk>
Message-ID: <156D216A-7D38-46F1-9080-DA0C8B565B7C@oucs.ox.ac.uk>

I have duly changed the Guidelines to build the PDF using Linux Libertine as the main body font; will cause Martin's setup to break briefly, I expect, depending on whether he has it installed already.

now its all pukka free fonts
--
Sebastian Rahtz      
Head of Information and Support Group
Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431

S?lo le pido a Dios
que el futuro no me sea indiferente


From gabriel.bodard at kcl.ac.uk  Thu Jun 14 07:48:51 2012
From: gabriel.bodard at kcl.ac.uk (Gabriel BODARD)
Date: Thu, 14 Jun 2012 12:48:51 +0100
Subject: [tei-council] Location of <app>s for external apparatus
In-Reply-To: <4FD90F95.8000903@uvic.ca>
References: <4FD7D3CF.50605@uvic.ca>
	<CAC_Lu0YjwL7GMc3UPvk2WUEXKDLenDPFWja_fj+1mjrz33HaKw@mail.gmail.com>
	<4FD8DB69.2060206@uvic.ca>	<4FD8EA62.6010400@kcl.ac.uk>
	<4FD90992.9010302@ultraslavonic.info> <4FD90F95.8000903@uvic.ca>
Message-ID: <4FD9CFA3.9080403@kcl.ac.uk>

I'm not sure that putting <app> in <p> is as abusive or flaky as has 
been implied (but I don't especially want to defend it too vigorously, 
as I like the alternative <listApp> being offered); in my usage, we have 
a div[type=edition] and a div[type=apparatus], and the apparatus 
contains a series of textual or philological comments that are presented 
in the original edition (or in the intended output, if this is a 
born-digital text) in one or more paragraphs. (Because epigraphic texts 
are short, the apparatus is usually a separate section after the text, 
rather than a footnote-like area at the bottom of each page.)

As for sorting appLists into typed groups, critical texts sometimes have 
more than one running apparatus at the bottom of the page, don't they? 
(I've seen up to three in particularly weird editions.) I suppose one is 
manuscript/witness collation, another may be philological/emendations, 
maybe stemmatic evidence listed separately? Again in epigraphic and 
papyrological texts, "apparatus" also includes notes on phsysical 
features of the text. ("The surviving stroke at the end of l. 3 includes 
a strong upper serif and is consistent with B, D, P, R or ?.") If you 
want examples of types, there might be a few.

Cheers,

G

On 13/06/2012 23:09, Martin Holmes wrote:
> Yes -- the issue is:
>
>    - We don't offer guidance
>
>    - The guidance Lou and James suggested offering (putting<app>s in a
> <div>) doesn't actually work
>
>    - Similar solutions look a bit ad-hoc and flaky (putting<app>s in
> e.g.<p>)
>
> So I think everything would be cleaner if we offered<listApp>, and it
> would also give people the option to sort<app>s into groups for
> specific purposes (not sure what those purposes would be, myself) and
> type them with @type and @subtype.
>
> Cheers,
> Martin
>
> On 12-06-13 02:43 PM, Kevin Hawkins wrote:
>> Isn't what's broken here the fact that P5 mentions use of an external
>> apparatus but gives no clear guidance on how to do this?  Gabby says you
>> can do this by "collecting loose apps together in a<p>" ... but this
>> sounds like tag abuse to me.  If people want to encode a list of
>> apparatus entries, then I think we need to offer<listApp>.
>>
>> On 6/13/2012 3:30 PM, Gabriel BODARD wrote:
>>> For the record, I think I just collect loose apps together in a<p>    (or
>>> sometimes one per<p>, I think my XSLT doesn't care which). In principle
>>> a listApp would be useful (although it would only be *nice*, rather than
>>> fixing something that's actually broken), although app should of course
>>> continue to be available in<p>    because we also use them for inline
>>> apparatus features.
>>>
>>> </rambling>
>>>
>>> On 13/06/2012 19:26, Martin Holmes wrote:
>>>> It turns out<app>     cannot be a child of<div>     (so either James
>>>> customized his schema when listing<app>s in a<div>, or he's
>>>> misremembering). I'm beginning to think that<listApp>     might be a good
>>>> idea as a way of collecting<app>s which are external to the base text,
>>>> but I'm not sure where<listApp>     should be available yet, or how. Any
>>>> thoughts?
>>>>
>>>> Cheers,
>>>> Martin
>>>>
>>>> On 12-06-12 05:21 PM, Stuart A. Yeates wrote:
>>>>> On Wed, Jun 13, 2012 at 11:42 AM, Martin Holmes<mholmes at uvic.ca>      wrote:
>>>>>> Hi all,
>>>>>>
>>>>>> This ticket landed on my plate following Ann Arbor:
>>>>>>
>>>>>> <http://purl.org/tei/bug/3497356>
>>>>>>
>>>>>> The basic issue was that Jens thought a<listApp>      element might be
>>>>>> useful, for collecting together a set of<app>      elements in an apparatus
>>>>>> which is not embedded in the base text.
>>>>>>
>>>>>> These were my instructions:
>>>>>>
>>>>>> "MH will ask the submitter (and the TEI-L, pointing to the ticket) for
>>>>>> any examples of the use of<div>      which suggest that<listApp>      might be
>>>>>> useful (for instance, organization of<apps>      into multiple<div>      s with
>>>>>> @type). "
>>>>>>
>>>>>> However, it seems from the ticket that James, Lou and Jens himself all
>>>>>> agree that<listApp>      is not necessary, so I see no reason to resurrect
>>>>>> this, other than to add some clarification to the relevant guidelines
>>>>>> section to suggest that<app>s might be stored in a<div
>>>>>> type="apparatus">      element.
>>>>>>
>>>>>> If no-one has any objections, that's what I'll do, rather than going
>>>>>> back to Jens or TEI-L.
>>>>>
>>>>> Seems like a sane approach.
>>>>>
>>>>> cheers
>>>>> stuart
>>>>
>>>
>

-- 
Dr Gabriel BODARD
(Research Associate in Digital Epigraphy)

Department of Digital Humanities
King's College London
26-29 Drury Lane
London WC2B 5RL

Email: gabriel.bodard at kcl.ac.uk
Tel: +44 (0)20 7848 1388
Fax: +44 (0)20 7848 2980

http://www.digitalclassicist.org/
http://www.currentepigraphy.org/

From mholmes at uvic.ca  Thu Jun 14 11:32:50 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Thu, 14 Jun 2012 08:32:50 -0700
Subject: [tei-council] Jenkins builder script now working
In-Reply-To: <1EF04476-0F57-4AE8-B5A8-B1B4581F7C5A@oucs.ox.ac.uk>
References: <4FD90C30.7050606@uvic.ca>
	<5E4FD22B-A170-4EED-BBA5-7980BB1994A7@oucs.ox.ac.uk>
	<C4F523D8-322D-4B4C-8C51-A04142011AD3@oucs.ox.ac.uk>
	<4FD92B74.7070106@uvic.ca>
	<1EF04476-0F57-4AE8-B5A8-B1B4581F7C5A@oucs.ox.ac.uk>
Message-ID: <4FDA0422.3010709@uvic.ca>

On 12-06-14 01:37 AM, Sebastian Rahtz wrote:
>
> On 14 Jun 2012, at 01:08, Martin Holmes wrote:
>
>>
>> Good tip, and very revealing: it shows the following font families:
>>
>> DejaVu (free)
>> Kochi-mincho (free)
>> Hannom (free)
>> Junicode (free)
>> UMingCN (free)
>>
>> and
>>
>> Times New Roman (NOT free)
>>
>
> changing the main body font of the Guidelines is something that should perhaps not be undertaken
> lightly.

Definitely not, but that doesn't mean it's not worth trying.

> what do people suggest we use instead?

Your suggestion of Libertine below was my initial thought too. The first 
stage is to find out whether it covers all the ranges we're using Times 
New Roman for in the Glines, and it does look promising:

"Developed as an open-source collaborative project, the Libertine serif 
has won some notice after being chosen for the Wikipedia logo (for which 
the foundry designed the emblematic "crossed W").

Currently, the font family only comes in Libertine Serif, which like 
most all alternative serifs is designed to emulate Times New Roman.

Libertine has a glyph base of over 2000 characters, meaning that it has 
its own Western, Greek, Cyrillic, IPA, and special characters along with 
the usual letter/number inclusions.

It comes with italic, bold, bold italic, and small-caps varieties...

Libertine is designed as a general-purpose print font, as opposed to 
Times and Times New Roman; font designer Philipp Poll says both the 
older fonts have limitations that his Libertine does not have.

Poll recommends Libertine primarily for print work, and says other Linux 
fonts such as Deja Vu Serif work better for screen displays. Bold and 
small-caps varieties are available, and, Poll says, a sans-serif version 
of Libertine is in the works."

<http://sixrevisions.com/web_design/a-web-designers-guide-to-linux-fonts/>

One approach would be to get a distinct list of all the characters in 
the Glines which are rendered using Times New Roman, and check them 
against what's in Libertine. That would be relatively straightforward 
for me if the PDFs were being created with XSL:FO, but LaTeX is a 
mystery to me.

> I am of course suspicious of the open source gnu-ish alternative fonts, as they often
> seem to be designed by computer scientists who think xkcd and michelangelo
> are more or less the same quality. But hey, whatever makes folks happy :-}

I think Libertine is a lovely font, actually.

Cheers,
Martin

> Linux Libertine seems to be the obvious alternative
> --
> Sebastian Rahtz
> Head of Information and Support Group
> Oxford University Computing Services
> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>
> S?lo le pido a Dios
> que el futuro no me sea indiferente
>
>

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From mholmes at uvic.ca  Thu Jun 14 11:44:37 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Thu, 14 Jun 2012 08:44:37 -0700
Subject: [tei-council] main font changed for gidlines
In-Reply-To: <A946B973-80AA-435C-B529-191950A64CA3@oucs.ox.ac.uk>
References: <A946B973-80AA-435C-B529-191950A64CA3@oucs.ox.ac.uk>
Message-ID: <4FDA06E5.3010104@uvic.ca>

Magic! No sooner thought of than done. But we should surely do some 
proofreading to make sure all the relevant characters are covered.

I'm running a complete new build which doesn't install the MS stuff, and 
we'll see if all the jobs complete properly and whether the resulting 
PDF looks OK. That'll take about three hours, I think. Meanwhile I've 
installed Libertine on my live Jenkins box, and I'm re-running the 
Documentation build which failed because of the missing font.

Cheers,
Martin

On 12-06-14 03:13 AM, Sebastian Rahtz wrote:
> can you add ttf-linux-libertine  to the install? now you can drop mstcorefonts
> --
> Sebastian Rahtz
> Head of Information and Support Group
> Oxford University Computing Services
> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>
> S?lo le pido a Dios
> que el futuro no me sea indiferente
>
>

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From sebastian.rahtz at oucs.ox.ac.uk  Thu Jun 14 11:48:27 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Thu, 14 Jun 2012 15:48:27 +0000
Subject: [tei-council] Jenkins builder script now working
In-Reply-To: <4FDA0422.3010709@uvic.ca>
References: <4FD90C30.7050606@uvic.ca>
	<5E4FD22B-A170-4EED-BBA5-7980BB1994A7@oucs.ox.ac.uk>
	<C4F523D8-322D-4B4C-8C51-A04142011AD3@oucs.ox.ac.uk>
	<4FD92B74.7070106@uvic.ca>
	<1EF04476-0F57-4AE8-B5A8-B1B4581F7C5A@oucs.ox.ac.uk>
	<4FDA0422.3010709@uvic.ca>
Message-ID: <6A787DF1-EFEB-4C7A-A465-B7D28CBE792C@oucs.ox.ac.uk>


On 14 Jun 2012, at 16:32, Martin Holmes wrote:
> 
> Currently, the font family only comes in Libertine Serif, which like most all alternative serifs is designed to emulate Times New Roman.
> 
yes, it seems to be more or less metric compatible
...
> 
> Poll recommends Libertine primarily for print work, and says other Linux fonts such as Deja Vu Serif work better for screen displays. 

it is a moot question as to whether our PDF is designed for screen or print.

> <http://sixrevisions.com/web_design/a-web-designers-guide-to-linux-fonts/>
> 
> One approach would be to get a distinct list of all the characters in the Glines which are rendered using Times New Roman, and check them against what's in Libertine. That would be relatively straightforward for me if the PDFs were being created with XSL:FO, but LaTeX is a mystery to me.

isdry-pro:public rahtz$ grep -i missing ~/TEI/Sourceforge/trunk/P5/Guidelines.log  | sort -u

Missing character: There is no ? in font DejaVu Sans Mono/ICU!
Missing character: There is no ? in font DejaVu Sans Mono/ICU!
Missing character: There is no ? in font DejaVu Sans Mono/ICU!
Missing character: There is no ? in font DejaVu Sans Mono/ICU!
Missing character: There is no ? in font Linux Libertine O/ICU!
Missing character: There is no ? in font DejaVu Sans Mono/ICU!
Missing character: There is no ? in font Linux Libertine O/ICU!
Missing character: There is no ? in font DejaVu Sans Mono/ICU!
Missing character: There is no ? in font DejaVu Sans Mono/ICU!
Missing character: There is no ? in font Linux Libertine O/ICU!
Missing character: There is no ? in font Linux Libertine O/ICU!
Missing character: There is no ? in font DejaVu Sans Mono/ICU!
Missing character: There is no ? in font Linux Libertine O/ICU!
Missing character: There is no ? in font DejaVu Sans Mono/ICU!

but now one has to find the damned things. the SansMono characters are in examples, the Libertine
ones in normal prose

> 
> I think Libertine is a lovely font, actually.
> 
if its a copy of Times, that hardly seems possible :-}

--
Sebastian Rahtz      
Head of Information and Support Group
Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431

S?lo le pido a Dios
que el futuro no me sea indiferente


From James.Cummings at oucs.ox.ac.uk  Thu Jun 14 11:50:27 2012
From: James.Cummings at oucs.ox.ac.uk (James Cummings)
Date: Thu, 14 Jun 2012 16:50:27 +0100
Subject: [tei-council] Location of <app>s for external apparatus
In-Reply-To: <4FD90F95.8000903@uvic.ca>
References: <4FD7D3CF.50605@uvic.ca>	<CAC_Lu0YjwL7GMc3UPvk2WUEXKDLenDPFWja_fj+1mjrz33HaKw@mail.gmail.com>	<4FD8DB69.2060206@uvic.ca>	<4FD8EA62.6010400@kcl.ac.uk>	<4FD90992.9010302@ultraslavonic.info>
	<4FD90F95.8000903@uvic.ca>
Message-ID: <4FDA0843.7080809@oucs.ox.ac.uk>

On 13/06/12 23:09, Martin Holmes wrote:
> Yes -- the issue is:
>
>    - We don't offer guidance
>
>    - The guidance Lou and James suggested offering (putting<app>s in a
> <div>) doesn't actually work

Apologies, I left out that I had wrapped these in an <ab> per 
grouping. (e.g. in case of poetry an <ab> for each large <lg> or 
poem, in the case of prose for each <div> or <p> depending on the 
number of variants and the granularity of the <app>.

So it is:

<div>
    <ab>
       <app xml:id="app1">...</app>
       <app xml:id="app2">...</app>
   <!-- ... -->
    </ab>
</div>


-James

>
>    - Similar solutions look a bit ad-hoc and flaky (putting<app>s in
> e.g.<p>)
>
> So I think everything would be cleaner if we offered<listApp>, and it
> would also give people the option to sort<app>s into groups for
> specific purposes (not sure what those purposes would be, myself) and
> type them with @type and @subtype.
>
> Cheers,
> Martin
>
> On 12-06-13 02:43 PM, Kevin Hawkins wrote:
>> Isn't what's broken here the fact that P5 mentions use of an external
>> apparatus but gives no clear guidance on how to do this?  Gabby says you
>> can do this by "collecting loose apps together in a<p>" ... but this
>> sounds like tag abuse to me.  If people want to encode a list of
>> apparatus entries, then I think we need to offer<listApp>.
>>
>> On 6/13/2012 3:30 PM, Gabriel BODARD wrote:
>>> For the record, I think I just collect loose apps together in a<p>    (or
>>> sometimes one per<p>, I think my XSLT doesn't care which). In principle
>>> a listApp would be useful (although it would only be *nice*, rather than
>>> fixing something that's actually broken), although app should of course
>>> continue to be available in<p>    because we also use them for inline
>>> apparatus features.
>>>
>>> </rambling>
>>>
>>> On 13/06/2012 19:26, Martin Holmes wrote:
>>>> It turns out<app>     cannot be a child of<div>     (so either James
>>>> customized his schema when listing<app>s in a<div>, or he's
>>>> misremembering). I'm beginning to think that<listApp>     might be a good
>>>> idea as a way of collecting<app>s which are external to the base text,
>>>> but I'm not sure where<listApp>     should be available yet, or how. Any
>>>> thoughts?
>>>>
>>>> Cheers,
>>>> Martin
>>>>
>>>> On 12-06-12 05:21 PM, Stuart A. Yeates wrote:
>>>>> On Wed, Jun 13, 2012 at 11:42 AM, Martin Holmes<mholmes at uvic.ca>      wrote:
>>>>>> Hi all,
>>>>>>
>>>>>> This ticket landed on my plate following Ann Arbor:
>>>>>>
>>>>>> <http://purl.org/tei/bug/3497356>
>>>>>>
>>>>>> The basic issue was that Jens thought a<listApp>      element might be
>>>>>> useful, for collecting together a set of<app>      elements in an apparatus
>>>>>> which is not embedded in the base text.
>>>>>>
>>>>>> These were my instructions:
>>>>>>
>>>>>> "MH will ask the submitter (and the TEI-L, pointing to the ticket) for
>>>>>> any examples of the use of<div>      which suggest that<listApp>      might be
>>>>>> useful (for instance, organization of<apps>      into multiple<div>      s with
>>>>>> @type). "
>>>>>>
>>>>>> However, it seems from the ticket that James, Lou and Jens himself all
>>>>>> agree that<listApp>      is not necessary, so I see no reason to resurrect
>>>>>> this, other than to add some clarification to the relevant guidelines
>>>>>> section to suggest that<app>s might be stored in a<div
>>>>>> type="apparatus">      element.
>>>>>>
>>>>>> If no-one has any objections, that's what I'll do, rather than going
>>>>>> back to Jens or TEI-L.
>>>>>
>>>>> Seems like a sane approach.
>>>>>
>>>>> cheers
>>>>> stuart
>>>>
>>>
>


-- 
Dr James Cummings, InfoDev,
Computing Services, University of Oxford

From mholmes at uvic.ca  Thu Jun 14 11:56:00 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Thu, 14 Jun 2012 08:56:00 -0700
Subject: [tei-council] Location of <app>s for external apparatus
In-Reply-To: <4FD9CFA3.9080403@kcl.ac.uk>
References: <4FD7D3CF.50605@uvic.ca>
	<CAC_Lu0YjwL7GMc3UPvk2WUEXKDLenDPFWja_fj+1mjrz33HaKw@mail.gmail.com>
	<4FD8DB69.2060206@uvic.ca>	<4FD8EA62.6010400@kcl.ac.uk>
	<4FD90992.9010302@ultraslavonic.info>
	<4FD90F95.8000903@uvic.ca> <4FD9CFA3.9080403@kcl.ac.uk>
Message-ID: <4FDA0990.3030704@uvic.ca>

On 12-06-14 04:48 AM, Gabriel BODARD wrote:
> I'm not sure that putting<app>  in<p>  is as abusive or flaky as has
> been implied

Fair enough. I suppose it can't be described as either if it was the 
only option previously available. :-)

> (but I don't especially want to defend it too vigorously,
> as I like the alternative<listApp>  being offered); in my usage, we have
> a div[type=edition] and a div[type=apparatus], and the apparatus
> contains a series of textual or philological comments that are presented
> in the original edition (or in the intended output, if this is a
> born-digital text) in one or more paragraphs. (Because epigraphic texts
> are short, the apparatus is usually a separate section after the text,
> rather than a footnote-like area at the bottom of each page.)

I think we might still want to provide some clearer guidance on where 
this stuff belongs in the file (presumably either in the header or in 
<back>).

> As for sorting appLists into typed groups, critical texts sometimes have
> more than one running apparatus at the bottom of the page, don't they?
> (I've seen up to three in particularly weird editions.) I suppose one is
> manuscript/witness collation, another may be philological/emendations,
> maybe stemmatic evidence listed separately? Again in epigraphic and
> papyrological texts, "apparatus" also includes notes on phsysical
> features of the text. ("The surviving stroke at the end of l. 3 includes
> a strong upper serif and is consistent with B, D, P, R or ?.") If you
> want examples of types, there might be a few.

That would be useful to have. I don't do a lot of apparatus work myself, 
so I don't have good examples to reach for.

The next question would be whether any other elements are allowed in 
<listApp> other than <app>, and if so, what should they be. I think 
people will want to provide some descriptive information about the list 
of <app>s, so I think <desc> and/or <note> would be appropriate. I don't 
see a need for anything else, though. Any thoughts on this?

Should it also nest, like other lists do? I don't see why not.

Cheers,
Martin




> Cheers,
>
> G
>
> On 13/06/2012 23:09, Martin Holmes wrote:
>> Yes -- the issue is:
>>
>>     - We don't offer guidance
>>
>>     - The guidance Lou and James suggested offering (putting<app>s in a
>> <div>) doesn't actually work
>>
>>     - Similar solutions look a bit ad-hoc and flaky (putting<app>s in
>> e.g.<p>)
>>
>> So I think everything would be cleaner if we offered<listApp>, and it
>> would also give people the option to sort<app>s into groups for
>> specific purposes (not sure what those purposes would be, myself) and
>> type them with @type and @subtype.
>>
>> Cheers,
>> Martin
>>
>> On 12-06-13 02:43 PM, Kevin Hawkins wrote:
>>> Isn't what's broken here the fact that P5 mentions use of an external
>>> apparatus but gives no clear guidance on how to do this?  Gabby says you
>>> can do this by "collecting loose apps together in a<p>" ... but this
>>> sounds like tag abuse to me.  If people want to encode a list of
>>> apparatus entries, then I think we need to offer<listApp>.
>>>
>>> On 6/13/2012 3:30 PM, Gabriel BODARD wrote:
>>>> For the record, I think I just collect loose apps together in a<p>     (or
>>>> sometimes one per<p>, I think my XSLT doesn't care which). In principle
>>>> a listApp would be useful (although it would only be *nice*, rather than
>>>> fixing something that's actually broken), although app should of course
>>>> continue to be available in<p>     because we also use them for inline
>>>> apparatus features.
>>>>
>>>> </rambling>
>>>>
>>>> On 13/06/2012 19:26, Martin Holmes wrote:
>>>>> It turns out<app>      cannot be a child of<div>      (so either James
>>>>> customized his schema when listing<app>s in a<div>, or he's
>>>>> misremembering). I'm beginning to think that<listApp>      might be a good
>>>>> idea as a way of collecting<app>s which are external to the base text,
>>>>> but I'm not sure where<listApp>      should be available yet, or how. Any
>>>>> thoughts?
>>>>>
>>>>> Cheers,
>>>>> Martin
>>>>>
>>>>> On 12-06-12 05:21 PM, Stuart A. Yeates wrote:
>>>>>> On Wed, Jun 13, 2012 at 11:42 AM, Martin Holmes<mholmes at uvic.ca>       wrote:
>>>>>>> Hi all,
>>>>>>>
>>>>>>> This ticket landed on my plate following Ann Arbor:
>>>>>>>
>>>>>>> <http://purl.org/tei/bug/3497356>
>>>>>>>
>>>>>>> The basic issue was that Jens thought a<listApp>       element might be
>>>>>>> useful, for collecting together a set of<app>       elements in an apparatus
>>>>>>> which is not embedded in the base text.
>>>>>>>
>>>>>>> These were my instructions:
>>>>>>>
>>>>>>> "MH will ask the submitter (and the TEI-L, pointing to the ticket) for
>>>>>>> any examples of the use of<div>       which suggest that<listApp>       might be
>>>>>>> useful (for instance, organization of<apps>       into multiple<div>       s with
>>>>>>> @type). "
>>>>>>>
>>>>>>> However, it seems from the ticket that James, Lou and Jens himself all
>>>>>>> agree that<listApp>       is not necessary, so I see no reason to resurrect
>>>>>>> this, other than to add some clarification to the relevant guidelines
>>>>>>> section to suggest that<app>s might be stored in a<div
>>>>>>> type="apparatus">       element.
>>>>>>>
>>>>>>> If no-one has any objections, that's what I'll do, rather than going
>>>>>>> back to Jens or TEI-L.
>>>>>>
>>>>>> Seems like a sane approach.
>>>>>>
>>>>>> cheers
>>>>>> stuart
>>>>>
>>>>
>>
>

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From gabriel.bodard at kcl.ac.uk  Thu Jun 14 12:02:13 2012
From: gabriel.bodard at kcl.ac.uk (Gabriel BODARD)
Date: Thu, 14 Jun 2012 17:02:13 +0100
Subject: [tei-council] Location of <app>s for external apparatus
In-Reply-To: <4FDA0990.3030704@uvic.ca>
References: <4FD7D3CF.50605@uvic.ca>
	<CAC_Lu0YjwL7GMc3UPvk2WUEXKDLenDPFWja_fj+1mjrz33HaKw@mail.gmail.com>
	<4FD8DB69.2060206@uvic.ca>	<4FD8EA62.6010400@kcl.ac.uk>
	<4FD90992.9010302@ultraslavonic.info>
	<4FD90F95.8000903@uvic.ca> <4FD9CFA3.9080403@kcl.ac.uk>
	<4FDA0990.3030704@uvic.ca>
Message-ID: <4FDA0B05.1070301@kcl.ac.uk>

On 14/06/2012 16:56, Martin Holmes wrote:
> I think we might still want to provide some clearer guidance on where
> this stuff belongs in the file (presumably either in the header or in
> <back>).

We emphatically put this in a div in the body, but this is because we're 
generally encoding an edition (rather than digitally birthing one, if 
you see what I mean).

> The next question would be whether any other elements are allowed in
> <listApp>  other than<app>, and if so, what should they be. I think
> people will want to provide some descriptive information about the list
> of<app>s, so I think<desc>  and/or<note>  would be appropriate. I don't
> see a need for anything else, though. Any thoughts on this?

I'm not sure I'm convinced it needs more than <head>. Notes and such 
like should be contained in individual apps, no? (Happy to hear 
counter-examples though.

> Should it also nest, like other lists do? I don't see why not.

Yes, I think it should. As you say, other list*s do, and if you can 
group things someone's eventually going to want to nest those groups.

G

-- 
Dr Gabriel BODARD
(Research Associate in Digital Epigraphy)

Department of Digital Humanities
King's College London
26-29 Drury Lane
London WC2B 5RL

Email: gabriel.bodard at kcl.ac.uk
Tel: +44 (0)20 7848 1388
Fax: +44 (0)20 7848 2980

http://www.digitalclassicist.org/
http://www.currentepigraphy.org/

From sebastian.rahtz at oucs.ox.ac.uk  Thu Jun 14 12:03:45 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Thu, 14 Jun 2012 16:03:45 +0000
Subject: [tei-council] main font changed for gidlines
In-Reply-To: <4FDA06E5.3010104@uvic.ca>
References: <A946B973-80AA-435C-B529-191950A64CA3@oucs.ox.ac.uk>
	<4FDA06E5.3010104@uvic.ca>
Message-ID: <0D2D2BE8-B1A9-4BC8-897E-751BF59D4586@oucs.ox.ac.uk>


On 14 Jun 2012, at 16:44, Martin Holmes wrote:

> Magic! No sooner thought of than done. But we should surely do some proofreading to make sure all the relevant characters are covered.
> 

see previous email. there are some Japanese characters needed, but wrapping in <seg xml:lang='ja'> fixes this, by forcing the LaTeX
to use a different font family.

now done, leaving just some stuff in examples, but thats no worse than it was yesterday.

Missing character: There is no ? in font DejaVu Sans Mono/ICU!
Missing character: There is no ? in font DejaVu Sans Mono/ICU!
Missing character: There is no ? in font DejaVu Sans Mono/ICU!
Missing character: There is no ? in font DejaVu Sans Mono/ICU!
Missing character: There is no ? in font DejaVu Sans Mono/ICU!
Missing character: There is no ? in font DejaVu Sans Mono/ICU!
Missing character: There is no ? in font DejaVu Sans Mono/ICU!
Missing character: There is no ? in font DejaVu Sans Mono/ICU!
Missing character: There is no ? in font DejaVu Sans Mono/ICU!

If there's a better monospaced font with these in, someone let me know
--
Sebastian Rahtz      
Head of Information and Support Group
Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431

S?lo le pido a Dios
que el futuro no me sea indiferente


From mholmes at uvic.ca  Thu Jun 14 12:07:31 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Thu, 14 Jun 2012 09:07:31 -0700
Subject: [tei-council] Jenkins builder script now working
In-Reply-To: <6A787DF1-EFEB-4C7A-A465-B7D28CBE792C@oucs.ox.ac.uk>
References: <4FD90C30.7050606@uvic.ca>
	<5E4FD22B-A170-4EED-BBA5-7980BB1994A7@oucs.ox.ac.uk>
	<C4F523D8-322D-4B4C-8C51-A04142011AD3@oucs.ox.ac.uk>
	<4FD92B74.7070106@uvic.ca>
	<1EF04476-0F57-4AE8-B5A8-B1B4581F7C5A@oucs.ox.ac.uk>
	<4FDA0422.3010709@uvic.ca>
	<6A787DF1-EFEB-4C7A-A465-B7D28CBE792C@oucs.ox.ac.uk>
Message-ID: <4FDA0C43.5060405@uvic.ca>

Hi Sebastian,

On 12-06-14 08:48 AM, Sebastian Rahtz wrote:
>
> On 14 Jun 2012, at 16:32, Martin Holmes wrote:
>>
>> Currently, the font family only comes in Libertine Serif, which like most all alternative serifs is designed to emulate Times New Roman.
>>
> yes, it seems to be more or less metric compatible
> ...
>>
>> Poll recommends Libertine primarily for print work, and says other Linux fonts such as Deja Vu Serif work better for screen displays.
>
> it is a moot question as to whether our PDF is designed for screen or print.

>> <http://sixrevisions.com/web_design/a-web-designers-guide-to-linux-fonts/>
>>
>> One approach would be to get a distinct list of all the characters in the Glines which are rendered using Times New Roman, and check them against what's in Libertine. That would be relatively straightforward for me if the PDFs were being created with XSL:FO, but LaTeX is a mystery to me.
>
> isdry-pro:public rahtz$ grep -i missing ~/TEI/Sourceforge/trunk/P5/Guidelines.log  | sort -u
>
> Missing character: There is no ? in font DejaVu Sans Mono/ICU!
> Missing character: There is no ? in font DejaVu Sans Mono/ICU!
> Missing character: There is no ? in font DejaVu Sans Mono/ICU!
> Missing character: There is no ? in font DejaVu Sans Mono/ICU!
> Missing character: There is no ? in font Linux Libertine O/ICU!
> Missing character: There is no ? in font DejaVu Sans Mono/ICU!
> Missing character: There is no ? in font Linux Libertine O/ICU!
> Missing character: There is no ? in font DejaVu Sans Mono/ICU!
> Missing character: There is no ? in font DejaVu Sans Mono/ICU!
> Missing character: There is no ? in font Linux Libertine O/ICU!
> Missing character: There is no ? in font Linux Libertine O/ICU!
> Missing character: There is no ? in font DejaVu Sans Mono/ICU!
> Missing character: There is no ? in font Linux Libertine O/ICU!
> Missing character: There is no ? in font DejaVu Sans Mono/ICU!

I did this on an old log built with Times:

mholmes at spud-2012:~/WorkData/tei/sf_repo/trunk/P5$ grep -i "in font 
Times New Roman" Guidelines.log  | sort -u
Missing character: There is no ? in font Times New Roman/ICU!
Missing character: There is no ? in font Times New Roman/ICU!
Missing character: There is no ? in font Times New Roman Italic/ICU!
Missing character: There is no ? in font Times New Roman/ICU!
Missing character: There is no ? in font Times New Roman/ICU!
Missing character: There is no ? in font Times New Roman/ICU!
Missing character: There is no ? in font Times New Roman/ICU!
Missing character: There is no ? in font Times New Roman/ICU!

So these problems are pre-existing. In fact Libertine seems to be doing 
a better job. These should all be rendered with Kincho or Ming anyway, 
shouldn't they?

> but now one has to find the damned things. the SansMono characters are in examples, the Libertine
> ones in normal prose

They presumably need tagging with @xml:lang to get the right font?

>> I think Libertine is a lovely font, actually.
>>
> if its a copy of Times, that hardly seems possible :-}

 From an interview with the designer:

Q: ? The Libertine family is based on Times New Roman.
A: ? Well, not quite. To be honest I absolutely dislike Times. The Times 
font was developed in the 1930ies to be readable on cheap, stained paper 
at weak illumination. It absolutely lacks livelyness and grace and is 
much overused. The link to the times is in fact my intention to create a 
font, that is so generally usable just like the Times.

Cheers,
Martin

>
> --
> Sebastian Rahtz
> Head of Information and Support Group
> Oxford University Computing Services
> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>
> S?lo le pido a Dios
> que el futuro no me sea indiferente
>

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From mholmes at uvic.ca  Thu Jun 14 12:25:49 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Thu, 14 Jun 2012 09:25:49 -0700
Subject: [tei-council] Location of <app>s for external apparatus
In-Reply-To: <4FDA0B05.1070301@kcl.ac.uk>
References: <4FD7D3CF.50605@uvic.ca>
	<CAC_Lu0YjwL7GMc3UPvk2WUEXKDLenDPFWja_fj+1mjrz33HaKw@mail.gmail.com>
	<4FD8DB69.2060206@uvic.ca>	<4FD8EA62.6010400@kcl.ac.uk>
	<4FD90992.9010302@ultraslavonic.info>	<4FD90F95.8000903@uvic.ca>
	<4FD9CFA3.9080403@kcl.ac.uk>	<4FDA0990.3030704@uvic.ca>
	<4FDA0B05.1070301@kcl.ac.uk>
Message-ID: <4FDA108D.9070401@uvic.ca>

On 12-06-14 09:02 AM, Gabriel BODARD wrote:
> On 14/06/2012 16:56, Martin Holmes wrote:
>> I think we might still want to provide some clearer guidance on where
>> this stuff belongs in the file (presumably either in the header or in
>> <back>).
>
> We emphatically put this in a div in the body, but this is because we're
> generally encoding an edition (rather than digitally birthing one, if
> you see what I mean).

That makes sense. I guess, then, we need a discussion of where it 
belongs in various different scenarios. I mentioned the header, but has 
anyone actually put external apparatus in a <teiHeader>?

>> The next question would be whether any other elements are allowed in
>> <listApp>   other than<app>, and if so, what should they be. I think
>> people will want to provide some descriptive information about the list
>> of<app>s, so I think<desc>   and/or<note>   would be appropriate. I don't
>> see a need for anything else, though. Any thoughts on this?
>
> I'm not sure I'm convinced it needs more than<head>. Notes and such
> like should be contained in individual apps, no? (Happy to hear
> counter-examples though.

I was thinking that <head> would be more appropriate for text that 
you're expecting to reproduce in an output somewhere, or which exists in 
an original source; <desc> seems more appropriate for editorial 
information about the apparatus, doesn't it?

Cheers,
Martin

>> Should it also nest, like other lists do? I don't see why not.
>
> Yes, I think it should. As you say, other list*s do, and if you can
> group things someone's eventually going to want to nest those groups.
>
> G
>

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From sebastian.rahtz at oucs.ox.ac.uk  Thu Jun 14 12:26:13 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Thu, 14 Jun 2012 16:26:13 +0000
Subject: [tei-council] Location of <app>s for external apparatus
In-Reply-To: <4FDA0843.7080809@oucs.ox.ac.uk>
References: <4FD7D3CF.50605@uvic.ca>
	<CAC_Lu0YjwL7GMc3UPvk2WUEXKDLenDPFWja_fj+1mjrz33HaKw@mail.gmail.com>
	<4FD8DB69.2060206@uvic.ca>	<4FD8EA62.6010400@kcl.ac.uk>
	<4FD90992.9010302@ultraslavonic.info> <4FD90F95.8000903@uvic.ca>
	<4FDA0843.7080809@oucs.ox.ac.uk>
Message-ID: <86d3352e-be37-484a-aa13-effa49d1e143@HUB01.ad.oak.ox.ac.uk>


On 14 Jun 2012, at 16:50, James Cummings wrote:

> Apologies, I left out that I had wrapped these in an <ab> per 
> grouping. (e.g. in case of poetry an <ab> for each large <lg> or 
> poem, in the case of prose for each <div> or <p> depending on the 
> number of variants and the granularity of the <app>.
> 
> So it is:
> 
> <div>
>    <ab>
>       <app xml:id="app1">...</app>
>       <app xml:id="app2">...</app>
>   <!-- ... -->
>    </ab>
> </div>


abuse as heck, then?..
--
Sebastian Rahtz      
Head of Information and Support Group
Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431

S?lo le pido a Dios
que el futuro no me sea indiferente


From mholmes at uvic.ca  Thu Jun 14 12:36:06 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Thu, 14 Jun 2012 09:36:06 -0700
Subject: [tei-council] main font changed for gidlines
In-Reply-To: <0D2D2BE8-B1A9-4BC8-897E-751BF59D4586@oucs.ox.ac.uk>
References: <A946B973-80AA-435C-B529-191950A64CA3@oucs.ox.ac.uk>
	<4FDA06E5.3010104@uvic.ca>
	<0D2D2BE8-B1A9-4BC8-897E-751BF59D4586@oucs.ox.ac.uk>
Message-ID: <4FDA12F6.5080701@uvic.ca>

If anyone wants

On 12-06-14 09:03 AM, Sebastian Rahtz wrote:
>
> On 14 Jun 2012, at 16:44, Martin Holmes wrote:
>
>> Magic! No sooner thought of than done. But we should surely do some proofreading to make sure all the relevant characters are covered.
>>
>
> see previous email. there are some Japanese characters needed, but wrapping in<seg xml:lang='ja'>  fixes this, by forcing the LaTeX
> to use a different font family.
>
> now done, leaving just some stuff in examples, but thats no worse than it was yesterday.
>
> Missing character: There is no ? in font DejaVu Sans Mono/ICU!
> Missing character: There is no ? in font DejaVu Sans Mono/ICU!
> Missing character: There is no ? in font DejaVu Sans Mono/ICU!
> Missing character: There is no ? in font DejaVu Sans Mono/ICU!
> Missing character: There is no ? in font DejaVu Sans Mono/ICU!
> Missing character: There is no ? in font DejaVu Sans Mono/ICU!
> Missing character: There is no ? in font DejaVu Sans Mono/ICU!
> Missing character: There is no ? in font DejaVu Sans Mono/ICU!
> Missing character: There is no ? in font DejaVu Sans Mono/ICU!
>
> If there's a better monospaced font with these in, someone let me know

The wynn (U+01BF) and yogh (U+021D) should be there, I think; in my 
DejaVu Sans Mono they're available. So maybe that's just an update 
that's needed somewhere.

The others are very basic CJK glyphs, and should be available in any 
font that supports CJK. How do they end up needing to be rendered in mono?

Cheers,
Martin

> --
> Sebastian Rahtz
> Head of Information and Support Group
> Oxford University Computing Services
> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>
> S?lo le pido a Dios
> que el futuro no me sea indiferente
>

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From James.Cummings at oucs.ox.ac.uk  Thu Jun 14 12:40:50 2012
From: James.Cummings at oucs.ox.ac.uk (James Cummings)
Date: Thu, 14 Jun 2012 17:40:50 +0100
Subject: [tei-council] Location of <app>s for external apparatus
In-Reply-To: <86d3352e-be37-484a-aa13-effa49d1e143@HUB01.ad.oak.ox.ac.uk>
References: <4FD7D3CF.50605@uvic.ca>	<CAC_Lu0YjwL7GMc3UPvk2WUEXKDLenDPFWja_fj+1mjrz33HaKw@mail.gmail.com>	<4FD8DB69.2060206@uvic.ca>	<4FD8EA62.6010400@kcl.ac.uk>	<4FD90992.9010302@ultraslavonic.info>
	<4FD90F95.8000903@uvic.ca>	<4FDA0843.7080809@oucs.ox.ac.uk>
	<86d3352e-be37-484a-aa13-effa49d1e143@HUB01.ad.oak.ox.ac.uk>
Message-ID: <4FDA1412.2050407@oucs.ox.ac.uk>

On 14/06/12 17:26, Sebastian Rahtz wrote:
>> <div>
>>     <ab>
>>        <app xml:id="app1">...</app>
>>        <app xml:id="app2">...</app>
>>    <!-- ... -->
>>     </ab>
>> </div>
> abuse as heck, then?..

Why so?  It is precisely non-semantic anonymous container 
groupings like this that <ab> is intended for.

But, to be honest, I think it adds credence to the case for listApp.

-James

-- 
Dr James Cummings, InfoDev,
Computing Services, University of Oxford

From mholmes at uvic.ca  Thu Jun 14 12:43:45 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Thu, 14 Jun 2012 09:43:45 -0700
Subject: [tei-council] main font changed for gidlines
In-Reply-To: <0D2D2BE8-B1A9-4BC8-897E-751BF59D4586@oucs.ox.ac.uk>
References: <A946B973-80AA-435C-B529-191950A64CA3@oucs.ox.ac.uk>
	<4FDA06E5.3010104@uvic.ca>
	<0D2D2BE8-B1A9-4BC8-897E-751BF59D4586@oucs.ox.ac.uk>
Message-ID: <4FDA14C1.5080309@uvic.ca>

If anyone wants to see the latest PDF with Libertine, there are copies 
on both Jinks boxes now:

<http://teijenkins.hcmc.uvic.ca:8080/job/TEIP5-Documentation/lastSuccessfulBuild/artifact/Guidelines.pdf>

<http://tei.oucs.ox.ac.uk/jenkins/job/TEIP5-Documentation/lastSuccessfulBuild/artifact/Guidelines.pdf>

I printed a couple of pages from the new version with Libertine and the 
old with Times, and my impression is that the Times is slightly heavier, 
with the Libertine a little easier on the eye. On screen, I think the 
Libertine is slightly more attractive, but there's not much to choose 
between them. Libertine takes up slightly more space (about one word 
every three or four lines, I think).

Cheers,
Martin

On 12-06-14 09:03 AM, Sebastian Rahtz wrote:
>
> On 14 Jun 2012, at 16:44, Martin Holmes wrote:
>
>> Magic! No sooner thought of than done. But we should surely do some proofreading to make sure all the relevant characters are covered.
>>
>
> see previous email. there are some Japanese characters needed, but wrapping in<seg xml:lang='ja'>  fixes this, by forcing the LaTeX
> to use a different font family.
>
> now done, leaving just some stuff in examples, but thats no worse than it was yesterday.
>
> Missing character: There is no ? in font DejaVu Sans Mono/ICU!
> Missing character: There is no ? in font DejaVu Sans Mono/ICU!
> Missing character: There is no ? in font DejaVu Sans Mono/ICU!
> Missing character: There is no ? in font DejaVu Sans Mono/ICU!
> Missing character: There is no ? in font DejaVu Sans Mono/ICU!
> Missing character: There is no ? in font DejaVu Sans Mono/ICU!
> Missing character: There is no ? in font DejaVu Sans Mono/ICU!
> Missing character: There is no ? in font DejaVu Sans Mono/ICU!
> Missing character: There is no ? in font DejaVu Sans Mono/ICU!
>
> If there's a better monospaced font with these in, someone let me know
> --
> Sebastian Rahtz
> Head of Information and Support Group
> Oxford University Computing Services
> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>
> S?lo le pido a Dios
> que el futuro no me sea indiferente
>

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From James.Cummings at oucs.ox.ac.uk  Thu Jun 14 12:48:44 2012
From: James.Cummings at oucs.ox.ac.uk (James Cummings)
Date: Thu, 14 Jun 2012 17:48:44 +0100
Subject: [tei-council] next release?
In-Reply-To: <4FB95846.7080308@oucs.ox.ac.uk>
References: <0F18A249-5480-42D9-BFF2-538AC7B9E1EB@oucs.ox.ac.uk>	<4F92F34D.2040103@uvic.ca>	<4F9579A0.8010002@oucs.ox.ac.uk>	<4F95C7A1.1080707@o2.pl>
	<4F96756B.1060202@oucs.ox.ac.uk>	<4F986673.7020201@kcl.ac.uk>
	<4FB95846.7080308@oucs.ox.ac.uk>
Message-ID: <4FDA15EC.5050700@oucs.ox.ac.uk>


A reminder to all that we're now coming up to our 15 June release 
date.

Get any changes in, soon, and mark them off:
http://wiki.tei-c.org/index.php/AnnArbor2012-Actions

-James

On 20/05/12 21:47, James Cummings wrote:
>
> Hi all,
>
> I think events have caught up with us and that May 25th deadline
> is looming.  I know I've barely chipped the surface of things
> assigned to me, and the meeting minutes are still coming (almost
> there I'm told).  I propose that we push back the next release
> until the week ending 15 June.  Does that seem unreasonable for
> anyone, or any counter proposals?
>
> -James
>
> On 25/04/12 22:02, Gabriel BODARD wrote:
>> The first week of June is likely to be bad for me; I'm back from
>> international travel around the 4th, I think, and will be groggy the
>> first couple days after that. So if not May 25th, then best to put it
>> off by two weeks. (Or someone else be launch technician...)
>>
>> G
>>
>> On 24/04/2012 10:42, James Cummings wrote:
>>>
>>> What do others think? We can of course move releasing back to
>>> whenever we've finished a majority of tickets, but I'd prefer
>>> sooner rather than later and a deadline that forces us to get
>>> stuff done.
>>>
>>> I'm of the opinion that we probably don't need to telco before
>>> this release (we can, after all, conduct business on the mailing
>>> list), but would do so shortly after the release to get updates
>>> on the longer-term issues and reports from the council working
>>> groups.
>>>
>>> thoughts?
>>>
>>> -James
>>>
>>>
>>> On 23/04/12 22:20, Piotr Ba?ski wrote:
>>>> Hi James,
>>>>
>>>> Isn't May 25 roughly in the middle of LREC? Could we shift by a week
>>>> from then, please?
>>>>
>>>> (I actually intend to be ready with my stuff [and possibly more] in
>>>> advance this time, but I've made some such totally honest promises to
>>>> myself and to the world recently, several times, and with meager results...)
>>>>
>>>> Ah. Will we telco before releasing?
>>>>
>>>> Best,
>>>>
>>>>       P.
>>>>
>>>>
>>>>
>>>> On 23/04/12 17:47, James Cummings wrote:
>>>>>
>>>>> How about we set a notional target release date of 25 May?  (This
>>>>> is about 5 weeks from now.) If we assume that we want most things
>>>>> completed by the end of Sunday 20th, to allow time for
>>>>> proofreading and error spotting.
>>>>>
>>>>> Does that sounds reasonable to most people?
>>>>>
>>>>> Gaby: Most importantly, does the proposed Release Technician like
>>>>> these dates?
>>>>>
>>>>> -James
>>>>>
>>>>>
>>>>> On 21/04/12 18:50, Martin Holmes wrote:
>>>>>> Three weeks will be a bit tough for me, and a couple of the tickets I
>>>>>> have might turn out to have unpredicted side-effects (like the tei_
>>>>>> prefix). As long as we have the option to launch without the change if
>>>>>> it proves difficult, we could go with three weeks.
>>>>>>
>>>>>> The attributes-without-examples problem is so large that we'll just have
>>>>>> to hack away at it steadily.
>>>>>>
>>>>>> Cheers,
>>>>>> Martin
>>>>>>
>>>>>> On 12-04-21 04:03 AM, Sebastian Rahtz wrote:
>>>>>>> something we forgot to debate in Ann Arbor was a timetable
>>>>>>> for the next release, I think? i.e. what is the due date for
>>>>>>> everyone to complete their ticket work so that Sir Gabriel
>>>>>>> of B'odard can undertake his Quest.
>>>>>>>
>>>>>>> speaking for myself, if I don't do my assignments
>>>>>>> more or less immediately I will not get to them for ages,
>>>>>>> so I favour a short window (say, 3 weeks).
>>>>>>>
>>>>>>> Sebastian
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>
>


-- 
Dr James Cummings, InfoDev,
Computing Services, University of Oxford

From mholmes at uvic.ca  Thu Jun 14 15:51:59 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Thu, 14 Jun 2012 12:51:59 -0700
Subject: [tei-council] main font changed for gidlines -- found the
 problem chars...
In-Reply-To: <4FDA14C1.5080309@uvic.ca>
References: <A946B973-80AA-435C-B529-191950A64CA3@oucs.ox.ac.uk>
	<4FDA06E5.3010104@uvic.ca>
	<0D2D2BE8-B1A9-4BC8-897E-751BF59D4586@oucs.ox.ac.uk>
	<4FDA14C1.5080309@uvic.ca>
Message-ID: <4FDA40DF.70304@uvic.ca>

Latest build results, which are identical on my brand-new Ubuntu 2012 
(which has never had any MS fonts on it) and on the current live teiJenkins:

$ grep -i missing Guidelines_teiJenkins.log | sort -u
Missing character: There is no ? in font DejaVu Sans Mono/ICU!
Missing character: There is no ? in font DejaVu Sans Mono/ICU!
Missing character: There is no ? in font DejaVu Sans Mono/ICU!
Missing character: There is no ? in font DejaVu Sans Mono/ICU!
Missing character: There is no ? in font DejaVu Sans Mono/ICU!
Missing character: There is no ? in font DejaVu Sans Mono/ICU!
Missing character: There is no ? in font DejaVu Sans Mono/ICU!

And I've found where they are, I think -- look at this:

<exemplum xml:lang="en">
     <egXML xmlns="http://www.tei-c.org/ns/Examples">
       <layoutDesc>
         <layout columns="2" ruledLines="42">
           <p><locus from="f12r" to="f15v"/>
    2 columns of 42 lines pricked and ruled in ink, with
    central rule between the columns.</p>
         </layout>
         <layout columns="3">
           <p><locus from="f16"/>???????.</p>
         </layout>
       </layoutDesc>
     </egXML>
   </exemplum>

It's in layoutDesc.xml.

I would fix it if I could figure out how; the "en" is correct for tje 
exemplum itself. If I add xml:lang="zh_TW" to the <p> tag surrounding 
the text, will that do it?

I'm assuming it's Chinese -- there are no hiragana or katakana -- but it 
could be early Japanese. Who should we ask?

Cheers,
Martin

On 12-06-14 09:43 AM, Martin Holmes wrote:
> If anyone wants to see the latest PDF with Libertine, there are copies
> on both Jinks boxes now:
>
> <http://teijenkins.hcmc.uvic.ca:8080/job/TEIP5-Documentation/lastSuccessfulBuild/artifact/Guidelines.pdf>
>
> <http://tei.oucs.ox.ac.uk/jenkins/job/TEIP5-Documentation/lastSuccessfulBuild/artifact/Guidelines.pdf>
>
> I printed a couple of pages from the new version with Libertine and the
> old with Times, and my impression is that the Times is slightly heavier,
> with the Libertine a little easier on the eye. On screen, I think the
> Libertine is slightly more attractive, but there's not much to choose
> between them. Libertine takes up slightly more space (about one word
> every three or four lines, I think).
>
> Cheers,
> Martin
>
> On 12-06-14 09:03 AM, Sebastian Rahtz wrote:
>>
>> On 14 Jun 2012, at 16:44, Martin Holmes wrote:
>>
>>> Magic! No sooner thought of than done. But we should surely do some proofreading to make sure all the relevant characters are covered.
>>>
>>
>> see previous email. there are some Japanese characters needed, but wrapping in<seg xml:lang='ja'>   fixes this, by forcing the LaTeX
>> to use a different font family.
>>
>> now done, leaving just some stuff in examples, but thats no worse than it was yesterday.
>>
>> Missing character: There is no ? in font DejaVu Sans Mono/ICU!
>> Missing character: There is no ? in font DejaVu Sans Mono/ICU!
>> Missing character: There is no ? in font DejaVu Sans Mono/ICU!
>> Missing character: There is no ? in font DejaVu Sans Mono/ICU!
>> Missing character: There is no ? in font DejaVu Sans Mono/ICU!
>> Missing character: There is no ? in font DejaVu Sans Mono/ICU!
>> Missing character: There is no ? in font DejaVu Sans Mono/ICU!
>> Missing character: There is no ? in font DejaVu Sans Mono/ICU!
>> Missing character: There is no ? in font DejaVu Sans Mono/ICU!
>>
>> If there's a better monospaced font with these in, someone let me know
>> --
>> Sebastian Rahtz
>> Head of Information and Support Group
>> Oxford University Computing Services
>> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>>
>> S?lo le pido a Dios
>> que el futuro no me sea indiferente
>>
>

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From mholmes at uvic.ca  Thu Jun 14 20:25:03 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Thu, 14 Jun 2012 17:25:03 -0700
Subject: [tei-council] main font changed for gidlines -- found the
 problem chars...
In-Reply-To: <4FDA40DF.70304@uvic.ca>
References: <A946B973-80AA-435C-B529-191950A64CA3@oucs.ox.ac.uk>
	<4FDA06E5.3010104@uvic.ca>
	<0D2D2BE8-B1A9-4BC8-897E-751BF59D4586@oucs.ox.ac.uk>
	<4FDA14C1.5080309@uvic.ca> <4FDA40DF.70304@uvic.ca>
Message-ID: <4FDA80DF.6050805@uvic.ca>

Latest build seems to be entirely free of missing character issues after 
my tweak to layoutDesc.xml:

grep -i missing Guidelines_teiJenkins_2.log | sort -u

* nothing *

So: do we like Libertine as a replacement for Times New Roman?

Cheers,
Martin

On 12-06-14 12:51 PM, Martin Holmes wrote:
> Latest build results, which are identical on my brand-new Ubuntu 2012
> (which has never had any MS fonts on it) and on the current live teiJenkins:
>
> $ grep -i missing Guidelines_teiJenkins.log | sort -u
> Missing character: There is no ? in font DejaVu Sans Mono/ICU!
> Missing character: There is no ? in font DejaVu Sans Mono/ICU!
> Missing character: There is no ? in font DejaVu Sans Mono/ICU!
> Missing character: There is no ? in font DejaVu Sans Mono/ICU!
> Missing character: There is no ? in font DejaVu Sans Mono/ICU!
> Missing character: There is no ? in font DejaVu Sans Mono/ICU!
> Missing character: There is no ? in font DejaVu Sans Mono/ICU!
>
> And I've found where they are, I think -- look at this:
>
> <exemplum xml:lang="en">
>       <egXML xmlns="http://www.tei-c.org/ns/Examples">
>         <layoutDesc>
>           <layout columns="2" ruledLines="42">
>             <p><locus from="f12r" to="f15v"/>
>      2 columns of 42 lines pricked and ruled in ink, with
>      central rule between the columns.</p>
>           </layout>
>           <layout columns="3">
>             <p><locus from="f16"/>???????.</p>
>           </layout>
>         </layoutDesc>
>       </egXML>
>     </exemplum>
>
> It's in layoutDesc.xml.
>
> I would fix it if I could figure out how; the "en" is correct for tje
> exemplum itself. If I add xml:lang="zh_TW" to the<p>  tag surrounding
> the text, will that do it?
>
> I'm assuming it's Chinese -- there are no hiragana or katakana -- but it
> could be early Japanese. Who should we ask?
>
> Cheers,
> Martin
>
> On 12-06-14 09:43 AM, Martin Holmes wrote:
>> If anyone wants to see the latest PDF with Libertine, there are copies
>> on both Jinks boxes now:
>>
>> <http://teijenkins.hcmc.uvic.ca:8080/job/TEIP5-Documentation/lastSuccessfulBuild/artifact/Guidelines.pdf>
>>
>> <http://tei.oucs.ox.ac.uk/jenkins/job/TEIP5-Documentation/lastSuccessfulBuild/artifact/Guidelines.pdf>
>>
>> I printed a couple of pages from the new version with Libertine and the
>> old with Times, and my impression is that the Times is slightly heavier,
>> with the Libertine a little easier on the eye. On screen, I think the
>> Libertine is slightly more attractive, but there's not much to choose
>> between them. Libertine takes up slightly more space (about one word
>> every three or four lines, I think).
>>
>> Cheers,
>> Martin
>>
>> On 12-06-14 09:03 AM, Sebastian Rahtz wrote:
>>>
>>> On 14 Jun 2012, at 16:44, Martin Holmes wrote:
>>>
>>>> Magic! No sooner thought of than done. But we should surely do some proofreading to make sure all the relevant characters are covered.
>>>>
>>>
>>> see previous email. there are some Japanese characters needed, but wrapping in<seg xml:lang='ja'>    fixes this, by forcing the LaTeX
>>> to use a different font family.
>>>
>>> now done, leaving just some stuff in examples, but thats no worse than it was yesterday.
>>>
>>> Missing character: There is no ? in font DejaVu Sans Mono/ICU!
>>> Missing character: There is no ? in font DejaVu Sans Mono/ICU!
>>> Missing character: There is no ? in font DejaVu Sans Mono/ICU!
>>> Missing character: There is no ? in font DejaVu Sans Mono/ICU!
>>> Missing character: There is no ? in font DejaVu Sans Mono/ICU!
>>> Missing character: There is no ? in font DejaVu Sans Mono/ICU!
>>> Missing character: There is no ? in font DejaVu Sans Mono/ICU!
>>> Missing character: There is no ? in font DejaVu Sans Mono/ICU!
>>> Missing character: There is no ? in font DejaVu Sans Mono/ICU!
>>>
>>> If there's a better monospaced font with these in, someone let me know
>>> --
>>> Sebastian Rahtz
>>> Head of Information and Support Group
>>> Oxford University Computing Services
>>> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>>>
>>> S?lo le pido a Dios
>>> que el futuro no me sea indiferente
>>>
>>
>

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From syeates at gmail.com  Thu Jun 14 20:33:40 2012
From: syeates at gmail.com (Stuart A. Yeates)
Date: Fri, 15 Jun 2012 12:33:40 +1200
Subject: [tei-council] main font changed for gidlines -- found the
	problem chars...
In-Reply-To: <4FDA80DF.6050805@uvic.ca>
References: <A946B973-80AA-435C-B529-191950A64CA3@oucs.ox.ac.uk>
	<4FDA06E5.3010104@uvic.ca>
	<0D2D2BE8-B1A9-4BC8-897E-751BF59D4586@oucs.ox.ac.uk>
	<4FDA14C1.5080309@uvic.ca> <4FDA40DF.70304@uvic.ca>
	<4FDA80DF.6050805@uvic.ca>
Message-ID: <CAC_Lu0ZhYddM4NKgK5HPkUFoFtP+VUecPoOZ5BM4OjyArLozoQ@mail.gmail.com>

On Fri, Jun 15, 2012 at 12:25 PM, Martin Holmes <mholmes at uvic.ca> wrote:
> Latest build seems to be entirely free of missing character issues after
> my tweak to layoutDesc.xml:
>
> grep -i missing Guidelines_teiJenkins_2.log | sort -u
>
> * nothing *
>
> So: do we like Libertine as a replacement for Times New Roman?

It looks good to my taste and my rending engines.

I suggest some text in the release announcement about this, because I
suspect I'm not the only one who rarely or never checks the PDF.
Maybe: "From this release the PDF version of the  guidelines use a
different selection of fonts. Users are encouraged to check the PDF
and provide feedback on any issues they may find."

cheers
stuart

From kevin.s.hawkins at ultraslavonic.info  Thu Jun 14 21:12:28 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Thu, 14 Jun 2012 21:12:28 -0400
Subject: [tei-council] release notes (was Re: main font changed for gidlines
 -- found the problem chars...)
In-Reply-To: <CAC_Lu0ZhYddM4NKgK5HPkUFoFtP+VUecPoOZ5BM4OjyArLozoQ@mail.gmail.com>
References: <A946B973-80AA-435C-B529-191950A64CA3@oucs.ox.ac.uk>
	<4FDA06E5.3010104@uvic.ca>
	<0D2D2BE8-B1A9-4BC8-897E-751BF59D4586@oucs.ox.ac.uk>
	<4FDA14C1.5080309@uvic.ca> <4FDA40DF.70304@uvic.ca>
	<4FDA80DF.6050805@uvic.ca>
	<CAC_Lu0ZhYddM4NKgK5HPkUFoFtP+VUecPoOZ5BM4OjyArLozoQ@mail.gmail.com>
Message-ID: <4FDA8BFC.80907@ultraslavonic.info>

This reminds me ... do we have a place to gather release notes?  I 
recall that every time Sebastian does a release, he has asked us to 
submit comments on significant changes, and then we all rack our brains 
trying to remember which things we've done since the last release.  If 
we could compile these as we go (and add a reminder about contributing 
to this list at the appropriate place in tcw20), we might be better off.

On 6/14/12 8:33 PM, Stuart A. Yeates wrote:
> I suggest some text in the release announcement about this, because I
> suspect I'm not the only one who rarely or never checks the PDF.
> Maybe: "From this release the PDF version of the  guidelines use a
> different selection of fonts. Users are encouraged to check the PDF
> and provide feedback on any issues they may find."

From syeates at gmail.com  Thu Jun 14 21:26:51 2012
From: syeates at gmail.com (Stuart A. Yeates)
Date: Fri, 15 Jun 2012 13:26:51 +1200
Subject: [tei-council] release notes (was Re: main font changed for
 gidlines -- found the problem chars...)
In-Reply-To: <4FDA8BFC.80907@ultraslavonic.info>
References: <A946B973-80AA-435C-B529-191950A64CA3@oucs.ox.ac.uk>
	<4FDA06E5.3010104@uvic.ca>
	<0D2D2BE8-B1A9-4BC8-897E-751BF59D4586@oucs.ox.ac.uk>
	<4FDA14C1.5080309@uvic.ca> <4FDA40DF.70304@uvic.ca>
	<4FDA80DF.6050805@uvic.ca>
	<CAC_Lu0ZhYddM4NKgK5HPkUFoFtP+VUecPoOZ5BM4OjyArLozoQ@mail.gmail.com>
	<4FDA8BFC.80907@ultraslavonic.info>
Message-ID: <CAC_Lu0bdTeNDG+n2Ckpo1cdhMvTwiMxiwkivB87P2OjnCiD15Q@mail.gmail.com>

The easy way to do this is (from the commandline, near the root of the
svn tree):

svn log | more

This shows you, a page at a time, all the subversion changes from the
most recent all the way back to the beginning of time (hit control-C
if you don't want to go back that far). As a group we seem to be
reasonable about sane commit messages and of course the user is
generated automagically. Selecting which are the important ones is
still a human job.

There's probably way to do the same thing using GUIs too.

cheers
stuart

On Fri, Jun 15, 2012 at 1:12 PM, Kevin Hawkins
<kevin.s.hawkins at ultraslavonic.info> wrote:
> This reminds me ... do we have a place to gather release notes? ?I
> recall that every time Sebastian does a release, he has asked us to
> submit comments on significant changes, and then we all rack our brains
> trying to remember which things we've done since the last release. ?If
> we could compile these as we go (and add a reminder about contributing
> to this list at the appropriate place in tcw20), we might be better off.
>
> On 6/14/12 8:33 PM, Stuart A. Yeates wrote:
>> I suggest some text in the release announcement about this, because I
>> suspect I'm not the only one who rarely or never checks the PDF.
>> Maybe: "From this release the PDF version of the ?guidelines use a
>> different selection of fonts. Users are encouraged to check the PDF
>> and provide feedback on any issues they may find."
> --
> tei-council mailing list
> tei-council at lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>
> PLEASE NOTE: postings to this list are publicly archived

From kevin.s.hawkins at ultraslavonic.info  Thu Jun 14 21:37:50 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Thu, 14 Jun 2012 21:37:50 -0400
Subject: [tei-council] release notes (was Re: main font changed for
 gidlines -- found the problem chars...)
In-Reply-To: <CAC_Lu0bdTeNDG+n2Ckpo1cdhMvTwiMxiwkivB87P2OjnCiD15Q@mail.gmail.com>
References: <A946B973-80AA-435C-B529-191950A64CA3@oucs.ox.ac.uk>
	<4FDA06E5.3010104@uvic.ca>
	<0D2D2BE8-B1A9-4BC8-897E-751BF59D4586@oucs.ox.ac.uk>
	<4FDA14C1.5080309@uvic.ca> <4FDA40DF.70304@uvic.ca>
	<4FDA80DF.6050805@uvic.ca>
	<CAC_Lu0ZhYddM4NKgK5HPkUFoFtP+VUecPoOZ5BM4OjyArLozoQ@mail.gmail.com>
	<4FDA8BFC.80907@ultraslavonic.info>
	<CAC_Lu0bdTeNDG+n2Ckpo1cdhMvTwiMxiwkivB87P2OjnCiD15Q@mail.gmail.com>
Message-ID: <4FDA91EE.3080103@ultraslavonic.info>

On 6/14/12 9:26 PM, Stuart A. Yeates wrote:
> The easy way to do this is (from the commandline, near the root of the
> svn tree):
>
> svn log | more
>
> This shows you, a page at a time, all the subversion changes from the
> most recent all the way back to the beginning of time (hit control-C
> if you don't want to go back that far). As a group we seem to be
> reasonable about sane commit messages and of course the user is
> generated automagically. Selecting which are the important ones is
> still a human job.

Right.

In looking through past tei-council messages, I've discovered reference 
to P5/ReleaseNotes/ , where we have been creating a new file for each 
release.  So it seems that:

1. tcw20 should be revised to say that people should add an <item> to 
the latest P5/ReleaseNotes/readme-N.N.N.xml that they find for any 
significant revision they make

2. tcw22 should be revised to say:

a) before a release, ask Council members to skim 
P5/ReleaseNotes/readme-N.N.N.xml and see if anything else comes to mind 
to add

b) after releasing, create a new file in 
P5/ReleaseNotes/readme-N.N.N.xml for the next release so that this is 
ready for editing

Does that sound right?

--Kevin

From syeates at gmail.com  Thu Jun 14 22:47:23 2012
From: syeates at gmail.com (Stuart A. Yeates)
Date: Fri, 15 Jun 2012 14:47:23 +1200
Subject: [tei-council] release notes (was Re: main font changed for
 gidlines -- found the problem chars...)
In-Reply-To: <4FDA91EE.3080103@ultraslavonic.info>
References: <A946B973-80AA-435C-B529-191950A64CA3@oucs.ox.ac.uk>
	<4FDA06E5.3010104@uvic.ca>
	<0D2D2BE8-B1A9-4BC8-897E-751BF59D4586@oucs.ox.ac.uk>
	<4FDA14C1.5080309@uvic.ca> <4FDA40DF.70304@uvic.ca>
	<4FDA80DF.6050805@uvic.ca>
	<CAC_Lu0ZhYddM4NKgK5HPkUFoFtP+VUecPoOZ5BM4OjyArLozoQ@mail.gmail.com>
	<4FDA8BFC.80907@ultraslavonic.info>
	<CAC_Lu0bdTeNDG+n2Ckpo1cdhMvTwiMxiwkivB87P2OjnCiD15Q@mail.gmail.com>
	<4FDA91EE.3080103@ultraslavonic.info>
Message-ID: <CAC_Lu0bK-M7ih3tmG7nhrqb9ZhmCPz2UGSVwrO7UJfXUbdKVtw@mail.gmail.com>

On a related note, could someone with a deeper knowledge than I
explain why the same content appears to be at both:

http://www.tei-c.org/release/doc/tei-p5-doc/readme-2.0.html

and

http://www.tei-c.org/release/doc/tei-p5-doc/release/tei-p5-doc/share/doc/tei-p5-doc/readme-2.0.html

and why they are slightly different...

cheers
stuart

From lou.burnard at retired.ox.ac.uk  Fri Jun 15 03:41:29 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Fri, 15 Jun 2012 08:41:29 +0100
Subject: [tei-council] release notes (was Re: main font changed for
 gidlines -- found the problem chars...)
In-Reply-To: <4FDA91EE.3080103@ultraslavonic.info>
References: <A946B973-80AA-435C-B529-191950A64CA3@oucs.ox.ac.uk>
	<4FDA06E5.3010104@uvic.ca>
	<0D2D2BE8-B1A9-4BC8-897E-751BF59D4586@oucs.ox.ac.uk>
	<4FDA14C1.5080309@uvic.ca> <4FDA40DF.70304@uvic.ca>
	<4FDA80DF.6050805@uvic.ca>
	<CAC_Lu0ZhYddM4NKgK5HPkUFoFtP+VUecPoOZ5BM4OjyArLozoQ@mail.gmail.com>
	<4FDA8BFC.80907@ultraslavonic.info>
	<CAC_Lu0bdTeNDG+n2Ckpo1cdhMvTwiMxiwkivB87P2OjnCiD15Q@mail.gmail.com>
	<4FDA91EE.3080103@ultraslavonic.info>
Message-ID: <4FDAE729.70307@retired.ox.ac.uk>

On 15/06/12 02:37, Kevin Hawkins wrote:
  it seems that:
>
> 1. tcw20 should be revised to say that people should add an<item>  to
> the latest P5/ReleaseNotes/readme-N.N.N.xml that they find for any
> significant revision they make
>


The trouble with this is that peoples view of what is significant is 
likely to vary. And there wont be any obvious way of summarising a lot 
of small unrelated changes.  What has happened in the past is that one 
person (usually me) has checked the log and summarised it, in the form 
that you have now discovered.

But the fact that you've only just discovered it suggests that maybe 
it's not that important!


> 2. tcw22 should be revised to say:
>
> a) before a release, ask Council members to skim
> P5/ReleaseNotes/readme-N.N.N.xml and see if anything else comes to mind
> to add

That would certainly be a good idea

>
> b) after releasing, create a new file in
> P5/ReleaseNotes/readme-N.N.N.xml for the next release so that this is
> ready for editing

Don't see the point of that -- the old version is always there as a 
template.





From James.Cummings at oucs.ox.ac.uk  Fri Jun 15 03:51:56 2012
From: James.Cummings at oucs.ox.ac.uk (James Cummings)
Date: Fri, 15 Jun 2012 08:51:56 +0100
Subject: [tei-council] release notes (was Re: main font changed for
 gidlines -- found the problem chars...)
In-Reply-To: <4FDAE729.70307@retired.ox.ac.uk>
References: <A946B973-80AA-435C-B529-191950A64CA3@oucs.ox.ac.uk>
	<4FDA06E5.3010104@uvic.ca>
	<0D2D2BE8-B1A9-4BC8-897E-751BF59D4586@oucs.ox.ac.uk>
	<4FDA14C1.5080309@uvic.ca> <4FDA40DF.70304@uvic.ca>
	<4FDA80DF.6050805@uvic.ca>
	<CAC_Lu0ZhYddM4NKgK5HPkUFoFtP+VUecPoOZ5BM4OjyArLozoQ@mail.gmail.com>
	<4FDA8BFC.80907@ultraslavonic.info>
	<CAC_Lu0bdTeNDG+n2Ckpo1cdhMvTwiMxiwkivB87P2OjnCiD15Q@mail.gmail.com>
	<4FDA91EE.3080103@ultraslavonic.info>
	<4FDAE729.70307@retired.ox.ac.uk>
Message-ID: <4FDAE99C.9000206@oucs.ox.ac.uk>

On 15/06/12 08:41, Lou Burnard wrote:
> The trouble with this is that peoples view of what is significant is
> likely to vary. And there wont be any obvious way of summarising a lot
> of small unrelated changes.  What has happened in the past is that one
> person (usually me) has checked the log and summarised it, in the form
> that you have now discovered.
>
> But the fact that you've only just discovered it suggests that maybe
> it's not that important!

No, it is important, because it is one of the things pointed to 
in the announcement of the release. Would you be willing to do so 
again for today's release?

>> 2. tcw22 should be revised to say:
>> a) before a release, ask Council members to skim
>> P5/ReleaseNotes/readme-N.N.N.xml and see if anything else comes to mind
>> to add
> That would certainly be a good idea

Agreed.

>> b) after releasing, create a new file in
>> P5/ReleaseNotes/readme-N.N.N.xml for the next release so that this is
>> ready for editing
> Don't see the point of that -- the old version is always there as a
> template.

also this is unable to be done because at time of release it is 
reasonably impossible to know what the next release number will 
be, because it is dependent on the nature of the changes. (i.e. 
if it is just a typo-correcting release vs a schema-changing 
release vs a major schema change.)


-James

-- 
Dr James Cummings, InfoDev
Oxford University Computing Services
University of Oxford

From sebastian.rahtz at oucs.ox.ac.uk  Fri Jun 15 04:05:10 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Fri, 15 Jun 2012 08:05:10 +0000
Subject: [tei-council] main font changed for gidlines -- found the
 problem chars...
In-Reply-To: <4FDA80DF.6050805@uvic.ca>
References: <A946B973-80AA-435C-B529-191950A64CA3@oucs.ox.ac.uk>
	<4FDA06E5.3010104@uvic.ca>
	<0D2D2BE8-B1A9-4BC8-897E-751BF59D4586@oucs.ox.ac.uk>
	<4FDA14C1.5080309@uvic.ca> <4FDA40DF.70304@uvic.ca>
	<4FDA80DF.6050805@uvic.ca>
Message-ID: <4D9DB3E8-90D6-4479-ABCD-E5B3FE892794@oucs.ox.ac.uk>


On 15 Jun 2012, at 01:25, Martin Holmes wrote:

> Latest build seems to be entirely free of missing character issues after 
> my tweak to layoutDesc.xml:
> 
> grep -i missing Guidelines_teiJenkins_2.log | sort -u
> 
> * nothing *
excellent!

> So: do we like Libertine as a replacement for Times New Roman?

seems OK to me.  In the interests of simplicity and open-sourceness,
lets stay there.

--
Sebastian Rahtz      
Head of Information and Support Group
Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431







From sebastian.rahtz at oucs.ox.ac.uk  Fri Jun 15 04:09:30 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Fri, 15 Jun 2012 08:09:30 +0000
Subject: [tei-council] Location of <app>s for external apparatus
In-Reply-To: <4FDA1412.2050407@oucs.ox.ac.uk>
References: <4FD7D3CF.50605@uvic.ca>
	<CAC_Lu0YjwL7GMc3UPvk2WUEXKDLenDPFWja_fj+1mjrz33HaKw@mail.gmail.com>
	<4FD8DB69.2060206@uvic.ca>	<4FD8EA62.6010400@kcl.ac.uk>
	<4FD90992.9010302@ultraslavonic.info> <4FD90F95.8000903@uvic.ca>
	<4FDA0843.7080809@oucs.ox.ac.uk>
	<86d3352e-be37-484a-aa13-effa49d1e143@HUB01.ad.oak.ox.ac.uk>
	<4FDA1412.2050407@oucs.ox.ac.uk>
Message-ID: <640eed6a-7db5-4e09-98f0-a35c0a8c2849@HUB02.ad.oak.ox.ac.uk>


On 14 Jun 2012, at 17:40, James Cummings wrote:

> On 14/06/12 17:26, Sebastian Rahtz wrote:
>>> <div>
>>>    <ab>
>>>       <app xml:id="app1">...</app>
>>>       <app xml:id="app2">...</app>
>>>   <!-- ... -->
>>>    </ab>
>>> </div>
>> abuse as heck, then?..
> 
> Why so?  It is precisely non-semantic anonymous container 
> groupings like this that <ab> is intended for.
> 
Because these <app>s are standoff markup, and the div/ab
structure implies (to me) that you can see them in the source text.
Or am I wrong, and we're not talking about standoff <app>s?

in that example we're working on from SOAS, James, the
set of <app>s is certainly in this category.

--
Sebastian Rahtz      
Head of Information and Support Group
Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431







From James.Cummings at oucs.ox.ac.uk  Fri Jun 15 04:18:58 2012
From: James.Cummings at oucs.ox.ac.uk (James Cummings)
Date: Fri, 15 Jun 2012 09:18:58 +0100
Subject: [tei-council] Location of <app>s for external apparatus
In-Reply-To: <640eed6a-7db5-4e09-98f0-a35c0a8c2849@HUB02.ad.oak.ox.ac.uk>
References: <4FD7D3CF.50605@uvic.ca>
	<CAC_Lu0YjwL7GMc3UPvk2WUEXKDLenDPFWja_fj+1mjrz33HaKw@mail.gmail.com>
	<4FD8DB69.2060206@uvic.ca>	<4FD8EA62.6010400@kcl.ac.uk>
	<4FD90992.9010302@ultraslavonic.info>
	<4FD90F95.8000903@uvic.ca> <4FDA0843.7080809@oucs.ox.ac.uk>
	<86d3352e-be37-484a-aa13-effa49d1e143@HUB01.ad.oak.ox.ac.uk>
	<4FDA1412.2050407@oucs.ox.ac.uk>
	<640eed6a-7db5-4e09-98f0-a35c0a8c2849@HUB02.ad.oak.ox.ac.uk>
Message-ID: <4FDAEFF2.6090705@oucs.ox.ac.uk>

On 15/06/12 09:09, Sebastian Rahtz wrote:
> Because these<app>s are standoff markup, and the div/ab
> structure implies (to me) that you can see them in the source text.
> Or am I wrong, and we're not talking about standoff<app>s?

If they are <app>s with <rdg>s then you *can* see them in one of 
the source texts (unless they contain <supplied>).  This is 
textual information, generally present in a source document, not 
metadata, it does *not* belong in the header, IMHO. A TEI file is 
not the product of a single source. Standoff <app>s are still 
<app>s, and <app>s contain readings from real source texts.

> in that example we're working on from SOAS, James, the
> set of<app>s is certainly in this category.

Yes, and those appear in manuscripts as real text. They should be 
in the body (ok, arguably 'back') of the TEI file, not in 
metadata about the file.

-James

-- 
Dr James Cummings, InfoDev
Oxford University Computing Services
University of Oxford

From sebastian.rahtz at oucs.ox.ac.uk  Fri Jun 15 04:20:11 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Fri, 15 Jun 2012 08:20:11 +0000
Subject: [tei-council] release notes (was Re: main font changed for
 gidlines -- found the problem chars...)
In-Reply-To: <CAC_Lu0bK-M7ih3tmG7nhrqb9ZhmCPz2UGSVwrO7UJfXUbdKVtw@mail.gmail.com>
References: <A946B973-80AA-435C-B529-191950A64CA3@oucs.ox.ac.uk>
	<4FDA06E5.3010104@uvic.ca>
	<0D2D2BE8-B1A9-4BC8-897E-751BF59D4586@oucs.ox.ac.uk>
	<4FDA14C1.5080309@uvic.ca> <4FDA40DF.70304@uvic.ca>
	<4FDA80DF.6050805@uvic.ca>
	<CAC_Lu0ZhYddM4NKgK5HPkUFoFtP+VUecPoOZ5BM4OjyArLozoQ@mail.gmail.com>
	<4FDA8BFC.80907@ultraslavonic.info>
	<CAC_Lu0bdTeNDG+n2Ckpo1cdhMvTwiMxiwkivB87P2OjnCiD15Q@mail.gmail.com>
	<4FDA91EE.3080103@ultraslavonic.info>
	<CAC_Lu0bK-M7ih3tmG7nhrqb9ZhmCPz2UGSVwrO7UJfXUbdKVtw@mail.gmail.com>
Message-ID: <684CFD10-ED53-46D3-A0C0-20F152FD3A53@oucs.ox.ac.uk>


On 15 Jun 2012, at 03:47, Stuart A. Yeates wrote:

> On a related note, could someone with a deeper knowledge than I
> explain why the same content appears to be at both:
> 
> http://www.tei-c.org/release/doc/tei-p5-doc/readme-2.0.html
> 
> and
> 
> http://www.tei-c.org/release/doc/tei-p5-doc/release/tei-p5-doc/share/doc/tei-p5-doc/readme-2.0.html
> 
> and why they are slightly different...
> 


I think the existence of the tree release/doc/tei-p5-doc/release is an error, and I have killed it

I dont believe it will be recreated, we'll see
--
Sebastian Rahtz      
Head of Information and Support Group
Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431







From sebastian.rahtz at oucs.ox.ac.uk  Fri Jun 15 04:24:12 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Fri, 15 Jun 2012 08:24:12 +0000
Subject: [tei-council] Location of <app>s for external apparatus
In-Reply-To: <4FDAEFF2.6090705@oucs.ox.ac.uk>
References: <4FD7D3CF.50605@uvic.ca>
	<CAC_Lu0YjwL7GMc3UPvk2WUEXKDLenDPFWja_fj+1mjrz33HaKw@mail.gmail.com>
	<4FD8DB69.2060206@uvic.ca>	<4FD8EA62.6010400@kcl.ac.uk>
	<4FD90992.9010302@ultraslavonic.info> <4FD90F95.8000903@uvic.ca>
	<4FDA0843.7080809@oucs.ox.ac.uk>
	<86d3352e-be37-484a-aa13-effa49d1e143@HUB01.ad.oak.ox.ac.uk>
	<4FDA1412.2050407@oucs.ox.ac.uk>
	<640eed6a-7db5-4e09-98f0-a35c0a8c2849@HUB02.ad.oak.ox.ac.uk>
	<4FDAEFF2.6090705@oucs.ox.ac.uk>
Message-ID: <d30a65be-9402-4bce-b4e9-0cb135d67d64@HUB01.ad.oak.ox.ac.uk>


On 15 Jun 2012, at 09:18, James Cummings wrote:

> 
> If they are <app>s with <rdg>s then you *can* see them in one of 
> the source texts (unless they contain <supplied>).  

yes, but they are out of place. the readings are not in with the rest
of the text. 

> Yes, and those appear in manuscripts as real text. They should be 
> in the body (ok, arguably 'back') of the TEI file, not in 
> metadata about the file.


agreed, they are not metadata, they are standoff readings. a bit like standoff notes,
and we dont have a natural home for them either, imho.
--
Sebastian Rahtz      
Head of Information and Support Group
Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431







From James.Cummings at oucs.ox.ac.uk  Fri Jun 15 04:32:44 2012
From: James.Cummings at oucs.ox.ac.uk (James Cummings)
Date: Fri, 15 Jun 2012 09:32:44 +0100
Subject: [tei-council] Location of <app>s for external apparatus
In-Reply-To: <8F61DC63-95B4-4951-BAE4-AC175BA05910@oucs.ox.ac.uk>
References: <4FD7D3CF.50605@uvic.ca>
	<CAC_Lu0YjwL7GMc3UPvk2WUEXKDLenDPFWja_fj+1mjrz33HaKw@mail.gmail.com>
	<4FD8DB69.2060206@uvic.ca>	<4FD8EA62.6010400@kcl.ac.uk>
	<4FD90992.9010302@ultraslavonic.info>
	<4FD90F95.8000903@uvic.ca> <4FDA0843.7080809@oucs.ox.ac.uk>
	<86d3352e-be37-484a-aa13-effa49d1e143@HUB01.ad.oak.ox.ac.uk>
	<4FDA1412.2050407@oucs.ox.ac.uk>
	<640eed6a-7db5-4e09-98f0-a35c0a8c2849@HUB02.ad.oak.ox.ac.uk>
	<4FDAEFF2.6090705@oucs.ox.ac.uk>
	<8F61DC63-95B4-4951-BAE4-AC175BA05910@oucs.ox.ac.uk>
Message-ID: <4FDAF32C.40501@oucs.ox.ac.uk>

On 15/06/12 09:24, Sebastian Rahtz wrote:
>
> On 15 Jun 2012, at 09:18, James Cummings wrote:
>
>>
>> If they are<app>s with<rdg>s then you *can* see them in one of
>> the source texts (unless they contain<supplied>).
>
> yes, but they are out of place. the readings are not in with the rest
> of the text.

Erm, isn't that the definition of *stand off*? ;-)

>> Yes, and those appear in manuscripts as real text. They should be
>> in the body (ok, arguably 'back') of the TEI file, not in
>> metadata about the file.
> agreed, they are not metadata, they are standoff readings. a bit like standoff notes,
> and we dont have a natural home for them either, imho.

Yes, and in a digitally-born edition, I would say that <back> 
makes a natural home for such appendices of textual information.

-James

-- 
Dr James Cummings, InfoDev
Oxford University Computing Services
University of Oxford

From sebastian.rahtz at oucs.ox.ac.uk  Fri Jun 15 04:38:36 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Fri, 15 Jun 2012 08:38:36 +0000
Subject: [tei-council] Location of <app>s for external apparatus
In-Reply-To: <4FDAF32C.40501@oucs.ox.ac.uk>
References: <4FD7D3CF.50605@uvic.ca>
	<CAC_Lu0YjwL7GMc3UPvk2WUEXKDLenDPFWja_fj+1mjrz33HaKw@mail.gmail.com>
	<4FD8DB69.2060206@uvic.ca>	<4FD8EA62.6010400@kcl.ac.uk>
	<4FD90992.9010302@ultraslavonic.info> <4FD90F95.8000903@uvic.ca>
	<4FDA0843.7080809@oucs.ox.ac.uk>
	<86d3352e-be37-484a-aa13-effa49d1e143@HUB01.ad.oak.ox.ac.uk>
	<4FDA1412.2050407@oucs.ox.ac.uk>
	<640eed6a-7db5-4e09-98f0-a35c0a8c2849@HUB02.ad.oak.ox.ac.uk>
	<4FDAEFF2.6090705@oucs.ox.ac.uk>
	<8F61DC63-95B4-4951-BAE4-AC175BA05910@oucs.ox.ac.uk>
	<4FDAF32C.40501@oucs.ox.ac.uk>
Message-ID: <127bcc21-e4c7-415e-9755-8abd6fd2d853@HUB04.ad.oak.ox.ac.uk>


On 15 Jun 2012, at 09:32, James Cummings wrote:

>> agreed, they are not metadata, they are standoff readings. a bit like standoff notes,
>> and we dont have a natural home for them either, imho.
> 
> Yes, and in a digitally-born edition, I would say that <back> makes a natural home for such appendices of textual information.
> 

<back> "contains any appendixes, etc. following the main part of a text"

if you use it as a container for standoff notes and apps, you lose its valuable function
as a place for appendices which are in normal reading order.

when I typeset a TEI document, I expect to render all of the <back> using just
the same techniques as when I render <front> or <body>. I don't expect
to render standoff notes and apps there where I meet them, I expect to be
given a clue that they are standoff.

--
Sebastian Rahtz      
Head of Information and Support Group
Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431







From syeates at gmail.com  Fri Jun 15 04:45:27 2012
From: syeates at gmail.com (stuart yeates)
Date: Fri, 15 Jun 2012 20:45:27 +1200
Subject: [tei-council] Location of <app>s for external apparatus
In-Reply-To: <127bcc21-e4c7-415e-9755-8abd6fd2d853@HUB04.ad.oak.ox.ac.uk>
References: <4FD7D3CF.50605@uvic.ca>
	<CAC_Lu0YjwL7GMc3UPvk2WUEXKDLenDPFWja_fj+1mjrz33HaKw@mail.gmail.com>
	<4FD8DB69.2060206@uvic.ca>	<4FD8EA62.6010400@kcl.ac.uk>
	<4FD90992.9010302@ultraslavonic.info>
	<4FD90F95.8000903@uvic.ca> <4FDA0843.7080809@oucs.ox.ac.uk>
	<86d3352e-be37-484a-aa13-effa49d1e143@HUB01.ad.oak.ox.ac.uk>
	<4FDA1412.2050407@oucs.ox.ac.uk>
	<640eed6a-7db5-4e09-98f0-a35c0a8c2849@HUB02.ad.oak.ox.ac.uk>
	<4FDAEFF2.6090705@oucs.ox.ac.uk>
	<8F61DC63-95B4-4951-BAE4-AC175BA05910@oucs.ox.ac.uk>
	<4FDAF32C.40501@oucs.ox.ac.uk>
	<127bcc21-e4c7-415e-9755-8abd6fd2d853@HUB04.ad.oak.ox.ac.uk>
Message-ID: <4FDAF627.1040002@gmail.com>

On 15/06/12 20:38, Sebastian Rahtz wrote:
>
> On 15 Jun 2012, at 09:32, James Cummings wrote:
>
>>> agreed, they are not metadata, they are standoff readings. a bit like standoff notes,
>>> and we dont have a natural home for them either, imho.
>>
>> Yes, and in a digitally-born edition, I would say that<back>  makes a natural home for such appendices of textual information.
>>
>
> <back>  "contains any appendixes, etc. following the main part of a text"
>
> if you use it as a container for standoff notes and apps, you lose its valuable function
> as a place for appendices which are in normal reading order.
>
> when I typeset a TEI document, I expect to render all of the<back>  using just
> the same techniques as when I render<front>  or<body>. I don't expect
> to render standoff notes and apps there where I meet them, I expect to be
> given a clue that they are standoff.

It would be useful to have a global clue that something is standoff (I 
anticipate a need for it on the SOM group, but we're not reached there 
yet).

Is there one?

cheers
stuart


From lou.burnard at retired.ox.ac.uk  Fri Jun 15 04:46:23 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Fri, 15 Jun 2012 09:46:23 +0100
Subject: [tei-council] release notes (was Re: main font changed for
 gidlines -- found the problem chars...)
In-Reply-To: <4FDAE99C.9000206@oucs.ox.ac.uk>
References: <A946B973-80AA-435C-B529-191950A64CA3@oucs.ox.ac.uk>
	<4FDA06E5.3010104@uvic.ca>
	<0D2D2BE8-B1A9-4BC8-897E-751BF59D4586@oucs.ox.ac.uk>
	<4FDA14C1.5080309@uvic.ca> <4FDA40DF.70304@uvic.ca>
	<4FDA80DF.6050805@uvic.ca>
	<CAC_Lu0ZhYddM4NKgK5HPkUFoFtP+VUecPoOZ5BM4OjyArLozoQ@mail.gmail.com>
	<4FDA8BFC.80907@ultraslavonic.info>
	<CAC_Lu0bdTeNDG+n2Ckpo1cdhMvTwiMxiwkivB87P2OjnCiD15Q@mail.gmail.com>
	<4FDA91EE.3080103@ultraslavonic.info>
	<4FDAE729.70307@retired.ox.ac.uk> <4FDAE99C.9000206@oucs.ox.ac.uk>
Message-ID: <4FDAF65F.20701@retired.ox.ac.uk>

On 15/06/12 08:51, James Cummings wrote:

> No, it is important, because it is one of the things pointed to
> in the announcement of the release. Would you be willing to do so
> again for today's release?

Sure, but cant do anything till this evening (I'm in a conference all day)


From James.Cummings at oucs.ox.ac.uk  Fri Jun 15 04:49:01 2012
From: James.Cummings at oucs.ox.ac.uk (James Cummings)
Date: Fri, 15 Jun 2012 09:49:01 +0100
Subject: [tei-council] Location of <app>s for external apparatus
In-Reply-To: <A4ABD9CD-3F4E-42BD-81F7-9D127782E016@oucs.ox.ac.uk>
References: <4FD7D3CF.50605@uvic.ca>
	<CAC_Lu0YjwL7GMc3UPvk2WUEXKDLenDPFWja_fj+1mjrz33HaKw@mail.gmail.com>
	<4FD8DB69.2060206@uvic.ca>	<4FD8EA62.6010400@kcl.ac.uk>
	<4FD90992.9010302@ultraslavonic.info>
	<4FD90F95.8000903@uvic.ca> <4FDA0843.7080809@oucs.ox.ac.uk>
	<86d3352e-be37-484a-aa13-effa49d1e143@HUB01.ad.oak.ox.ac.uk>
	<4FDA1412.2050407@oucs.ox.ac.uk>
	<640eed6a-7db5-4e09-98f0-a35c0a8c2849@HUB02.ad.oak.ox.ac.uk>
	<4FDAEFF2.6090705@oucs.ox.ac.uk>
	<8F61DC63-95B4-4951-BAE4-AC175BA05910@oucs.ox.ac.uk>
	<4FDAF32C.40501@oucs.ox.ac.uk>
	<A4ABD9CD-3F4E-42BD-81F7-9D127782E016@oucs.ox.ac.uk>
Message-ID: <4FDAF6FD.20004@oucs.ox.ac.uk>

On 15/06/12 09:38, Sebastian Rahtz wrote:
> <back>  "contains any appendixes, etc. following the main part of a text"
> if you use it as a container for standoff notes and apps, you lose its valuable function
> as a place for appendices which are in normal reading order.

I don't think that is true. You still have the ability to have 
other appendices. I dispute your claim that there is a 'normal 
reading order' when constructing a born-digital file that could 
have many forms of output.

> when I typeset a TEI document, I expect to render all of the<back>  using just
> the same techniques as when I render<front>  or<body>. I don't expect
> to render standoff notes and apps there where I meet them, I expect to be
> given a clue that they are standoff.

Isn't that what div/@type would do? Classify them in a way so 
your processing could know what to do with them? i.e.  If I had 
<div type="standoff-notes"> or <div type="standoff-apps">?

That said, <listApp> and then by extension <listNote> would 
provide containers for such things. However, they are 
significantly different from say <listBibl> in that if you ran 
across a <listBibl> somewhere in a <back> you would certainly be 
rendering it there, I suspect.

-James

-- 
Dr James Cummings, InfoDev
Oxford University Computing Services
University of Oxford

From sebastian.rahtz at oucs.ox.ac.uk  Fri Jun 15 04:49:42 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Fri, 15 Jun 2012 08:49:42 +0000
Subject: [tei-council] Location of <app>s for external apparatus
In-Reply-To: <4FDAF627.1040002@gmail.com>
References: <4FD7D3CF.50605@uvic.ca>
	<CAC_Lu0YjwL7GMc3UPvk2WUEXKDLenDPFWja_fj+1mjrz33HaKw@mail.gmail.com>
	<4FD8DB69.2060206@uvic.ca>	<4FD8EA62.6010400@kcl.ac.uk>
	<4FD90992.9010302@ultraslavonic.info> <4FD90F95.8000903@uvic.ca>
	<4FDA0843.7080809@oucs.ox.ac.uk>
	<86d3352e-be37-484a-aa13-effa49d1e143@HUB01.ad.oak.ox.ac.uk>
	<4FDA1412.2050407@oucs.ox.ac.uk>
	<640eed6a-7db5-4e09-98f0-a35c0a8c2849@HUB02.ad.oak.ox.ac.uk>
	<4FDAEFF2.6090705@oucs.ox.ac.uk>
	<8F61DC63-95B4-4951-BAE4-AC175BA05910@oucs.ox.ac.uk>
	<4FDAF32C.40501@oucs.ox.ac.uk>
	<127bcc21-e4c7-415e-9755-8abd6fd2d853@HUB04.ad.oak.ox.ac.uk>
	<4FDAF627.1040002@gmail.com>
Message-ID: <2343E158-1F56-494D-93C8-37A31F3FE7F0@oucs.ox.ac.uk>


On 15 Jun 2012, at 09:45, stuart yeates wrote:

> It would be useful to have a global clue that something is standoff (I 
> anticipate a need for it on the SOM group, but we're not reached there 
> yet).
> 
> Is there one?


I dont think so. in the case of eg <link>, its _always_ standoff, but <app>
and <note> can be used in either way, which is confusing (to me).

one could almost posit _another_ sibling of <text> called <standoffText> where
all this stuff lives. 
--
Sebastian Rahtz      
Head of Information and Support Group
Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431







From sebastian.rahtz at oucs.ox.ac.uk  Fri Jun 15 04:54:21 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Fri, 15 Jun 2012 08:54:21 +0000
Subject: [tei-council] Location of <app>s for external apparatus
In-Reply-To: <4FDAF6FD.20004@oucs.ox.ac.uk>
References: <4FD7D3CF.50605@uvic.ca>
	<CAC_Lu0YjwL7GMc3UPvk2WUEXKDLenDPFWja_fj+1mjrz33HaKw@mail.gmail.com>
	<4FD8DB69.2060206@uvic.ca>	<4FD8EA62.6010400@kcl.ac.uk>
	<4FD90992.9010302@ultraslavonic.info> <4FD90F95.8000903@uvic.ca>
	<4FDA0843.7080809@oucs.ox.ac.uk>
	<86d3352e-be37-484a-aa13-effa49d1e143@HUB01.ad.oak.ox.ac.uk>
	<4FDA1412.2050407@oucs.ox.ac.uk>
	<640eed6a-7db5-4e09-98f0-a35c0a8c2849@HUB02.ad.oak.ox.ac.uk>
	<4FDAEFF2.6090705@oucs.ox.ac.uk>
	<8F61DC63-95B4-4951-BAE4-AC175BA05910@oucs.ox.ac.uk>
	<4FDAF32C.40501@oucs.ox.ac.uk>
	<A4ABD9CD-3F4E-42BD-81F7-9D127782E016@oucs.ox.ac.uk>
	<4FDAF6FD.20004@oucs.ox.ac.uk>
Message-ID: <14001873-4fcb-45fa-833b-59b8d5f02ece@HUB03.ad.oak.ox.ac.uk>


On 15 Jun 2012, at 09:49, James Cummings wrote:

> 
> I don't think that is true. You still have the ability to have other appendices.
and how do you distinguish them?

> I dispute your claim that there is a 'normal reading order' when constructing a born-digital file that could have many forms of output.
> 
that's cos you are an idealist. ask 100 people in the technical writing sphere, and 99 will
agree that there is a normal reading order, i betcha

>> when I typeset a TEI document, I expect to render all of the<back>  using just
>> the same techniques as when I render<front>  or<body>. I don't expect
>> to render standoff notes and apps there where I meet them, I expect to be
>> given a clue that they are standoff.
> 
> Isn't that what div/@type would do? Classify them in a way so your processing could know what to do with them? i.e.  If I had <div type="standoff-notes"> or <div type="standoff-apps">?
> 
IFFFFF @type was in any way standardized or meaningful, yes. But since @type is a purely private notation, it cannot
remotely be relied on. cf discussions about @rend. Grrrrr

> That said, <listApp> and then by extension <listNote> would provide containers for such things. However, they are significantly different from say <listBibl> in that if you ran across a <listBibl> somewhere in a <back> you would certainly be rendering it there, I suspect.


true. but at least its an umbiguous rule - <listApp> would always be standoff. no?
--
Sebastian Rahtz      
Head of Information and Support Group
Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431







From syeates at gmail.com  Fri Jun 15 04:55:35 2012
From: syeates at gmail.com (stuart yeates)
Date: Fri, 15 Jun 2012 20:55:35 +1200
Subject: [tei-council] Location of <app>s for external apparatus
In-Reply-To: <2343E158-1F56-494D-93C8-37A31F3FE7F0@oucs.ox.ac.uk>
References: <4FD7D3CF.50605@uvic.ca>
	<CAC_Lu0YjwL7GMc3UPvk2WUEXKDLenDPFWja_fj+1mjrz33HaKw@mail.gmail.com>
	<4FD8DB69.2060206@uvic.ca>	<4FD8EA62.6010400@kcl.ac.uk>
	<4FD90992.9010302@ultraslavonic.info>
	<4FD90F95.8000903@uvic.ca> <4FDA0843.7080809@oucs.ox.ac.uk>
	<86d3352e-be37-484a-aa13-effa49d1e143@HUB01.ad.oak.ox.ac.uk>
	<4FDA1412.2050407@oucs.ox.ac.uk>
	<640eed6a-7db5-4e09-98f0-a35c0a8c2849@HUB02.ad.oak.ox.ac.uk>
	<4FDAEFF2.6090705@oucs.ox.ac.uk>
	<8F61DC63-95B4-4951-BAE4-AC175BA05910@oucs.ox.ac.uk>
	<4FDAF32C.40501@oucs.ox.ac.uk>
	<127bcc21-e4c7-415e-9755-8abd6fd2d853@HUB04.ad.oak.ox.ac.uk>
	<4FDAF627.1040002@gmail.com>
	<2343E158-1F56-494D-93C8-37A31F3FE7F0@oucs.ox.ac.uk>
Message-ID: <4FDAF887.2010505@gmail.com>

On 15/06/12 20:49, Sebastian Rahtz wrote:
>
> On 15 Jun 2012, at 09:45, stuart yeates wrote:
>
>> It would be useful to have a global clue that something is standoff (I
>> anticipate a need for it on the SOM group, but we're not reached there
>> yet).
>>
>> Is there one?
>
>
> I dont think so. in the case of eg<link>, its _always_ standoff, but<app>
> and<note>  can be used in either way, which is confusing (to me).
>
> one could almost posit _another_ sibling of<text>  called<standoffText>  where
> all this stuff lives.

I posit that it's premature to posit any such thing until the SOM group 
report back with real worked examples.

cheers
stuart


From James.Cummings at oucs.ox.ac.uk  Fri Jun 15 05:59:52 2012
From: James.Cummings at oucs.ox.ac.uk (James Cummings)
Date: Fri, 15 Jun 2012 10:59:52 +0100
Subject: [tei-council] Crit App, XPointer Schemes
Message-ID: <4FDB0798.9000707@oucs.ox.ac.uk>


As part of http://purl.org/tei/bug/3497369 I'm tasked with 
drafting a new short section on linking methods for critical 
apparatus to become a new 12.2.4 section.  My draft so far looks 
like the below.  Before committing it, does anyone have any 
suggestions or corrections they would like to make?

-James


12.2.4

Linking methods

When an apparatus is provided it does not need to be given at the 
location in the transcription where the variation occurs. Instead 
it may be stored in a separate place in the same file, or indeed 
in another file, and point to the location at which it is meant 
to be used. Storing apparatus entries separately can be 
beneficial when encoding multiple competing, potentially 
overlapping, interpretations of the same variation in the source 
texts.

The location-referenced method can be used to point a position in 
a text using the @loc attribute and a canonical reference that is 
understood and documented in the context of the file where it is 
used. Where possible it is recommended that other methods use the 
@from attribute to point to an @xml:id attribute on an <anchor/> 
or other element at the location where the variation takes place. 
The contents of an element pointed to are understood to be 
equivalent to a <lem> if none exists in the <app>, and if a <lem> 
does exist this should replace any content.

The @from attribute is a data.pointer datatype and thus contains 
a URI as a value.  This means that it can point directly to an 
@xml:id, an @xml:id in another local file, or indeed a file 
identified by any URL or URN.

===

<l n="1"><seg xml:id="WBP-so.1.1">Experience</seg> though noon 
Auctoritee</l>

<!-- In another file -->

  <app from="wbp.xml#WBP-so.1.1>
   <rdg wit="#La">Experiment</rdg>
   <rdg wit="#Ra2">Eryment</rdg>
  </app>

===

This could also be encoded as:

===

<l n="1"><anchor xml:id="WBP-so.1.1a"/> though noon Auctoritee</l>

<!-- In another file -->

  <app from="http://www.example.com/wbp.xml#WBP-so.1.1a>
   <lem>Experience</lem>
   <rdg wit="#La">Experiment</rdg>
   <rdg wit="#Ra2">Eryment</rdg>
  </app>

===

However, this should be considered more fragile since a full 
reading of the <lem> is not provided in the source file.

In addition, URLs can contain XPointer schemes including 
xpath1(), range, and string-range() which can be used in 
providing the location of an <app> that is stored separately from 
the text to which it applies. Both @from and @to can be used, as 
in the double end-point attachment method, to identify the 
starting and ending location for an apparatus using XPointer 
schemes to more precisely identify this location where beneficial.

===

<l n="1" xml:id="WP.1a">Experience though noon Auctoritee</l>

<!-- In another file -->

  <app from="wbp.xml#string-range(WBP.1a, 0, 10)">
   <lem>Experience</lem>
   <rdg wit="#La">Experiment</rdg>
   <rdg wit="#Ra2">Eryment</rdg>
  </app>

===


If only the @from attribute is provided then it should be 
understood that this supplies the location of the textual 
variance that the apparatus documents.  If the @from attribute 
contains an XPointer scheme that identifies a range of text (or 
elements) then this is understood to record the starting and 
ending of the range as in the double end-point attachment method.





-- 
Dr James Cummings, InfoDev
Oxford University Computing Services
University of Oxford

From gabriel.bodard at kcl.ac.uk  Fri Jun 15 07:04:51 2012
From: gabriel.bodard at kcl.ac.uk (Gabriel BODARD)
Date: Fri, 15 Jun 2012 12:04:51 +0100
Subject: [tei-council] next release?
In-Reply-To: <4FDA15EC.5050700@oucs.ox.ac.uk>
References: <0F18A249-5480-42D9-BFF2-538AC7B9E1EB@oucs.ox.ac.uk>
	<4F92F34D.2040103@uvic.ca>	<4F9579A0.8010002@oucs.ox.ac.uk>
	<4F95C7A1.1080707@o2.pl>	<4F96756B.1060202@oucs.ox.ac.uk>
	<4F986673.7020201@kcl.ac.uk>	<4FB95846.7080308@oucs.ox.ac.uk>
	<4FDA15EC.5050700@oucs.ox.ac.uk>
Message-ID: <4FDB16D3.2080007@kcl.ac.uk>

Dear fellow-Councillors,

James and I have decided to delay today's release until this coming 
Monday, June 18, to allow a couple of last minute fixes to go in, and so 
that we're not left trying to repair things right before and/or over the 
weekend if anything goes wrong. (This will be release 2.1.0, codename: 
"Earhart's Crossing".)

This means: (a) any tickets you've been meaning to close but not yet 
gotten around to, you now have the chance to do this weekend; (b) nobody 
should commit any changes to the TEI SVN from 09:00 GMT next Monday, 
until given the all clear by myself or James, hopefully later in the 
day. I'll send a further reminder to this effect on Monday morning.

Best,

Gabby

On 14/06/2012 17:48, James Cummings wrote:
>
> A reminder to all that we're now coming up to our 15 June release
> date.
>
> Get any changes in, soon, and mark them off:
> http://wiki.tei-c.org/index.php/AnnArbor2012-Actions
>
> -James
>
> On 20/05/12 21:47, James Cummings wrote:
>>
>> Hi all,
>>
>> I think events have caught up with us and that May 25th deadline
>> is looming.  I know I've barely chipped the surface of things
>> assigned to me, and the meeting minutes are still coming (almost
>> there I'm told).  I propose that we push back the next release
>> until the week ending 15 June.  Does that seem unreasonable for
>> anyone, or any counter proposals?
>>
>> -James
>>
>> On 25/04/12 22:02, Gabriel BODARD wrote:
>>> The first week of June is likely to be bad for me; I'm back from
>>> international travel around the 4th, I think, and will be groggy the
>>> first couple days after that. So if not May 25th, then best to put it
>>> off by two weeks. (Or someone else be launch technician...)
>>>
>>> G
>>>
>>> On 24/04/2012 10:42, James Cummings wrote:
>>>>
>>>> What do others think? We can of course move releasing back to
>>>> whenever we've finished a majority of tickets, but I'd prefer
>>>> sooner rather than later and a deadline that forces us to get
>>>> stuff done.
>>>>
>>>> I'm of the opinion that we probably don't need to telco before
>>>> this release (we can, after all, conduct business on the mailing
>>>> list), but would do so shortly after the release to get updates
>>>> on the longer-term issues and reports from the council working
>>>> groups.
>>>>
>>>> thoughts?
>>>>
>>>> -James
>>>>
>>>>
>>>> On 23/04/12 22:20, Piotr Ba?ski wrote:
>>>>> Hi James,
>>>>>
>>>>> Isn't May 25 roughly in the middle of LREC? Could we shift by a week
>>>>> from then, please?
>>>>>
>>>>> (I actually intend to be ready with my stuff [and possibly more] in
>>>>> advance this time, but I've made some such totally honest promises to
>>>>> myself and to the world recently, several times, and with meager results...)
>>>>>
>>>>> Ah. Will we telco before releasing?
>>>>>
>>>>> Best,
>>>>>
>>>>>        P.
>>>>>
>>>>>
>>>>>
>>>>> On 23/04/12 17:47, James Cummings wrote:
>>>>>>
>>>>>> How about we set a notional target release date of 25 May?  (This
>>>>>> is about 5 weeks from now.) If we assume that we want most things
>>>>>> completed by the end of Sunday 20th, to allow time for
>>>>>> proofreading and error spotting.
>>>>>>
>>>>>> Does that sounds reasonable to most people?
>>>>>>
>>>>>> Gaby: Most importantly, does the proposed Release Technician like
>>>>>> these dates?
>>>>>>
>>>>>> -James
>>>>>>
>>>>>>
>>>>>> On 21/04/12 18:50, Martin Holmes wrote:
>>>>>>> Three weeks will be a bit tough for me, and a couple of the tickets I
>>>>>>> have might turn out to have unpredicted side-effects (like the tei_
>>>>>>> prefix). As long as we have the option to launch without the change if
>>>>>>> it proves difficult, we could go with three weeks.
>>>>>>>
>>>>>>> The attributes-without-examples problem is so large that we'll just have
>>>>>>> to hack away at it steadily.
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Martin
>>>>>>>
>>>>>>> On 12-04-21 04:03 AM, Sebastian Rahtz wrote:
>>>>>>>> something we forgot to debate in Ann Arbor was a timetable
>>>>>>>> for the next release, I think? i.e. what is the due date for
>>>>>>>> everyone to complete their ticket work so that Sir Gabriel
>>>>>>>> of B'odard can undertake his Quest.
>>>>>>>>
>>>>>>>> speaking for myself, if I don't do my assignments
>>>>>>>> more or less immediately I will not get to them for ages,
>>>>>>>> so I favour a short window (say, 3 weeks).
>>>>>>>>
>>>>>>>> Sebastian
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
>
>

-- 
Dr Gabriel BODARD
(Research Associate in Digital Epigraphy)

Department of Digital Humanities
King's College London
26-29 Drury Lane
London WC2B 5RL

Email: gabriel.bodard at kcl.ac.uk
Tel: +44 (0)20 7848 1388
Fax: +44 (0)20 7848 2980

http://www.digitalclassicist.org/
http://www.currentepigraphy.org/

From kevin.s.hawkins at ultraslavonic.info  Fri Jun 15 08:49:59 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Fri, 15 Jun 2012 08:49:59 -0400
Subject: [tei-council] Location of <app>s for external apparatus
In-Reply-To: <4FDAEFF2.6090705@oucs.ox.ac.uk>
References: <4FD7D3CF.50605@uvic.ca>	<CAC_Lu0YjwL7GMc3UPvk2WUEXKDLenDPFWja_fj+1mjrz33HaKw@mail.gmail.com>	<4FD8DB69.2060206@uvic.ca>	<4FD8EA62.6010400@kcl.ac.uk>	<4FD90992.9010302@ultraslavonic.info>	<4FD90F95.8000903@uvic.ca>
	<4FDA0843.7080809@oucs.ox.ac.uk>	<86d3352e-be37-484a-aa13-effa49d1e143@HUB01.ad.oak.ox.ac.uk>	<4FDA1412.2050407@oucs.ox.ac.uk>	<640eed6a-7db5-4e09-98f0-a35c0a8c2849@HUB02.ad.oak.ox.ac.uk>
	<4FDAEFF2.6090705@oucs.ox.ac.uk>
Message-ID: <4FDB2F77.6020209@ultraslavonic.info>

I'd like to caution all of us against loose descriptions of how things 
work.  There are unarticulated assumptions here about whether the source 
document(s) contains a critical apparatus or whether this is supplied de 
novo in the TEI document.  Just want to make sure we're all on the same 
page about the use cases here ...

On 6/15/2012 4:18 AM, James Cummings wrote:
> On 15/06/12 09:09, Sebastian Rahtz wrote:
>> Because these<app>s are standoff markup, and the div/ab
>> structure implies (to me) that you can see them in the source text.
>> Or am I wrong, and we're not talking about standoff<app>s?
>
> If they are<app>s with<rdg>s then you *can* see them in one of
> the source texts (unless they contain<supplied>).  This is
> textual information, generally present in a source document, not
> metadata, it does *not* belong in the header, IMHO. A TEI file is
> not the product of a single source. Standoff<app>s are still
> <app>s, and<app>s contain readings from real source texts.
>
>> in that example we're working on from SOAS, James, the
>> set of<app>s is certainly in this category.
>
> Yes, and those appear in manuscripts as real text. They should be
> in the body (ok, arguably 'back') of the TEI file, not in
> metadata about the file.
>
> -James
>

From kevin.s.hawkins at ultraslavonic.info  Fri Jun 15 09:26:48 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Fri, 15 Jun 2012 09:26:48 -0400
Subject: [tei-council] release notes (was Re: main font changed for
 gidlines -- found the problem chars...)
In-Reply-To: <4FDAE99C.9000206@oucs.ox.ac.uk>
References: <A946B973-80AA-435C-B529-191950A64CA3@oucs.ox.ac.uk>	<4FDA06E5.3010104@uvic.ca>	<0D2D2BE8-B1A9-4BC8-897E-751BF59D4586@oucs.ox.ac.uk>	<4FDA14C1.5080309@uvic.ca>
	<4FDA40DF.70304@uvic.ca>	<4FDA80DF.6050805@uvic.ca>	<CAC_Lu0ZhYddM4NKgK5HPkUFoFtP+VUecPoOZ5BM4OjyArLozoQ@mail.gmail.com>	<4FDA8BFC.80907@ultraslavonic.info>	<CAC_Lu0bdTeNDG+n2Ckpo1cdhMvTwiMxiwkivB87P2OjnCiD15Q@mail.gmail.com>	<4FDA91EE.3080103@ultraslavonic.info>	<4FDAE729.70307@retired.ox.ac.uk>
	<4FDAE99C.9000206@oucs.ox.ac.uk>
Message-ID: <4FDB3818.7000404@ultraslavonic.info>

On 6/15/2012 3:51 AM, James Cummings wrote:
> On 15/06/12 08:41, Lou Burnard wrote:
>> The trouble with this is that peoples view of what is significant is
>> likely to vary. And there wont be any obvious way of summarising a lot
>> of small unrelated changes.  What has happened in the past is that one
>> person (usually me) has checked the log and summarised it, in the form
>> that you have now discovered.
>>
>> But the fact that you've only just discovered it suggests that maybe
>> it's not that important!
>
> No, it is important, because it is one of the things pointed to
> in the announcement of the release. Would you be willing to do so
> again for today's release?

Well, we need not point people to this file when releasing; however, we 
have recently been reproducing this file in the body of the announcement 
on TEI-L, and I think it's a good thing both to do this and to keep a 
summary of such changes in the repository.

>>> b) after releasing, create a new file in
>>> P5/ReleaseNotes/readme-N.N.N.xml for the next release so that this is
>>> ready for editing
>> Don't see the point of that -- the old version is always there as a
>> template.
>
> also this is unable to be done because at time of release it is
> reasonably impossible to know what the next release number will
> be, because it is dependent on the nature of the changes. (i.e.
> if it is just a typo-correcting release vs a schema-changing
> release vs a major schema change.)

Right, I wasn't thinking of the problem of not knowing the release 
number in advance.  However, since Lou prefer that the release technical 
create the readme so that there's a consistent standard of what's major, 
we can just do that.

I'll start a new thread on proposed changes to tcw22 (we don't need 
changes on tcw20 any more).

From kevin.s.hawkins at ultraslavonic.info  Fri Jun 15 09:29:56 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Fri, 15 Jun 2012 09:29:56 -0400
Subject: [tei-council] proposed additions to tcw22
Message-ID: <4FDB38D4.7010605@ultraslavonic.info>

I propose the following additions to tcw22 to clarify creation and 
maintenance of readme files for releases:

###

tcw22 should be revised so that:

a) Before a release, the release technical skims the log and summarizes 
significant changes in a new P5/ReleaseNotes/readme-N.N.N.xml , named 
according to the Unicode version conventions.  Then s/he asks Council 
members to skim P5/ReleaseNotes/readme-N.N.N.xml and see if anything 
else comes to mind to add.  (Note that this ends up being publicly 
accessible at http://www.tei-c.org/release/doc/tei-p5-doc/ .)

b) After a release, the Council chair emails TEI-L to announce the 
release and includes a copy of readme-N.N.N.xml.

###

Can anyone provide me a reference for Unicode version conventions?  I 
would like to add it to tcw22 and also to 
http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-data.version.html , 
which mentions this but does not explain the usage.

From James.Cummings at oucs.ox.ac.uk  Fri Jun 15 09:42:00 2012
From: James.Cummings at oucs.ox.ac.uk (James Cummings)
Date: Fri, 15 Jun 2012 14:42:00 +0100
Subject: [tei-council] proposed additions to tcw22
In-Reply-To: <4FDB38D4.7010605@ultraslavonic.info>
References: <4FDB38D4.7010605@ultraslavonic.info>
Message-ID: <4FDB3BA8.5030200@oucs.ox.ac.uk>


I'm not sure what we follow is strictly Unicode version 
numbering, but it is certainly similar to it.  There is 
documentation about this at:

http://unicode.org/versions/

This does Major.minor.update numbers, incrementing for major 
changes, minor changes, and small updates.

In our case we do Major.schema-changing.non-schema-changing 
numbering... but that is a bit of a mouthful.  The idea being we 
increment the second number only if changes that affect the 
schema have been introduced. If we correct some typos in the 
prose then we only increment the latter.  Note, if my 
understanding is correct, it might be theoretically possible to 
do a major change that wasn't schema changing. (e.g. if we 
rewrote most of the prose but didn't change element definitions 
or similar things which modify the TEI schema or abstract model). 
I think that would be very unlikely.

So for example, the previous release was 2.0.2, and this release 
will be 2.1.0 because we have made schema-related changes but not 
so many or of such a drastic nature that we have made a major 
increment.

-James

On 15/06/12 14:29, Kevin Hawkins wrote:
> I propose the following additions to tcw22 to clarify creation and
> maintenance of readme files for releases:
>
> ###
>
> tcw22 should be revised so that:
>
> a) Before a release, the release technical skims the log and summarizes
> significant changes in a new P5/ReleaseNotes/readme-N.N.N.xml , named
> according to the Unicode version conventions.  Then s/he asks Council
> members to skim P5/ReleaseNotes/readme-N.N.N.xml and see if anything
> else comes to mind to add.  (Note that this ends up being publicly
> accessible at http://www.tei-c.org/release/doc/tei-p5-doc/ .)
>
> b) After a release, the Council chair emails TEI-L to announce the
> release and includes a copy of readme-N.N.N.xml.
>
> ###
>
> Can anyone provide me a reference for Unicode version conventions?  I
> would like to add it to tcw22 and also to
> http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-data.version.html ,
> which mentions this but does not explain the usage.


-- 
Dr James Cummings, InfoDev
Oxford University Computing Services
University of Oxford

From James.Cummings at oucs.ox.ac.uk  Fri Jun 15 10:33:04 2012
From: James.Cummings at oucs.ox.ac.uk (James Cummings)
Date: Fri, 15 Jun 2012 15:33:04 +0100
Subject: [tei-council] Oxford Face2Face meeting: Accommodation
Message-ID: <4FDB47A0.2060601@oucs.ox.ac.uk>


As you will all know the next face 2 face meeting is scheduled 
for 19-21 September 2012. In order to see if I can get 
accommodation for this all in one place (as Becky did in Ann 
Arbor), it would be good if you could indicate what nights you 
will need accommodation (at the expense of the TEI-C).  If you 
are doing something else or have weird needs, please email me.

Otherwise, please fill out this poll: 
http://www.doodle.com/6n2uqbfq2wq6itdc

-James

-- 
Dr James Cummings, InfoDev
Oxford University Computing Services
University of Oxford

From PFSchaffner at umich.edu  Fri Jun 15 11:12:36 2012
From: PFSchaffner at umich.edu (Paul F. Schaffner)
Date: Fri, 15 Jun 2012 11:12:36 -0400 (EDT)
Subject: [tei-council] Oxford Face2Face meeting: Accommodation
In-Reply-To: <4FDB47A0.2060601@oucs.ox.ac.uk>
References: <4FDB47A0.2060601@oucs.ox.ac.uk>
Message-ID: <Pine.LNX.4.64.1206151110070.14872@joust.gpcc.itd.umich.edu>

James, since I'll be there for the TCP mini-conference earlier
in the week, and plan to bring my wife along, I've been assuming that I 
would try to book a week (16-22 Sept) at my usual hangout down
the Abingdon road. pfs

On Fri, 15 Jun 2012, James Cummings wrote:

>
> As you will all know the next face 2 face meeting is scheduled
> for 19-21 September 2012. In order to see if I can get
> accommodation for this all in one place (as Becky did in Ann
> Arbor), it would be good if you could indicate what nights you
> will need accommodation (at the expense of the TEI-C).  If you
> are doing something else or have weird needs, please email me.
>
> Otherwise, please fill out this poll:
> http://www.doodle.com/6n2uqbfq2wq6itdc
>
> -James
>
> -- 
> Dr James Cummings, InfoDev
> Oxford University Computing Services
> University of Oxford
> -- 
> tei-council mailing list
> tei-council at lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>
> PLEASE NOTE: postings to this list are publicly archived
>
>
>

--------------------------------------------------------------------
Paul Schaffner | PFSchaffner at umich.edu | http://www.umich.edu/~pfs/
316-C Hatcher Library N, Univ. of Michigan, Ann Arbor MI 48109-1190
--------------------------------------------------------------------

From mholmes at uvic.ca  Fri Jun 15 12:08:09 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Fri, 15 Jun 2012 09:08:09 -0700
Subject: [tei-council] Location of <app>s for external apparatus
In-Reply-To: <2343E158-1F56-494D-93C8-37A31F3FE7F0@oucs.ox.ac.uk>
References: <4FD7D3CF.50605@uvic.ca>
	<CAC_Lu0YjwL7GMc3UPvk2WUEXKDLenDPFWja_fj+1mjrz33HaKw@mail.gmail.com>
	<4FD8DB69.2060206@uvic.ca>	<4FD8EA62.6010400@kcl.ac.uk>
	<4FD90992.9010302@ultraslavonic.info>
	<4FD90F95.8000903@uvic.ca> <4FDA0843.7080809@oucs.ox.ac.uk>
	<86d3352e-be37-484a-aa13-effa49d1e143@HUB01.ad.oak.ox.ac.uk>
	<4FDA1412.2050407@oucs.ox.ac.uk>
	<640eed6a-7db5-4e09-98f0-a35c0a8c2849@HUB02.ad.oak.ox.ac.uk>
	<4FDAEFF2.6090705@oucs.ox.ac.uk>
	<8F61DC63-95B4-4951-BAE4-AC175BA05910@oucs.ox.ac.uk>
	<4FDAF32C.40501@oucs.ox.ac.uk>
	<127bcc21-e4c7-415e-9755-8abd6fd2d853@HUB04.ad.oak.ox.ac.uk>
	<4FDAF627.1040002@gmail.com>
	<2343E158-1F56-494D-93C8-37A31F3FE7F0@oucs.ox.ac.uk>
Message-ID: <4FDB5DE9.2040408@uvic.ca>

On 12-06-15 01:49 AM, Sebastian Rahtz wrote:
>
> On 15 Jun 2012, at 09:45, stuart yeates wrote:
>
>> It would be useful to have a global clue that something is standoff (I
>> anticipate a need for it on the SOM group, but we're not reached there
>> yet).
>>
>> Is there one?
>
>
> I dont think so. in the case of eg<link>, its _always_ standoff, but<app>
> and<note>  can be used in either way, which is confusing (to me).
>
> one could almost posit _another_ sibling of<text>  called<standoffText>  where
> all this stuff lives.

I think one should seriously posit such a thing. A born-digital document 
is a very different scenario from a traditional 
transcription-from-source, and leaving born-digitals aside for the 
moment, we have a situation where the original source document probably 
has <front>, <body> and <back>, and all the real original content would 
be transcribed there, in the order in which it appears. Adding in 
standoff content to <back> is ambiguous, and problematic for anyone 
writing stylesheets or other processors. And I share James's unhappiness 
with suggesting that something as ill-constrained as @type be used to 
distinguish the two cases.

So I like the idea of a fourth child of <text>, which explicitly 
contains stuff which is out-of-sequence, editorial, or otherwise not 
part of the normal flow of the source document. I don't like the name 
<standoffText>, though, because it may not always be textual stuff; 
<linkGrp>s and <link>s belong there too, for instance.

We need a name that incorporates the idea that these items are not part 
of the source document flow, although they may include text which ends 
up being rendered into that flow.

Cheers,
Martin

> --
> Sebastian Rahtz
> Head of Information and Support Group
> Oxford University Computing Services
> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>
>
>
>
>
>

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From mholmes at uvic.ca  Fri Jun 15 12:12:34 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Fri, 15 Jun 2012 09:12:34 -0700
Subject: [tei-council] proposed additions to tcw22
In-Reply-To: <4FDB38D4.7010605@ultraslavonic.info>
References: <4FDB38D4.7010605@ultraslavonic.info>
Message-ID: <4FDB5EF2.5060707@uvic.ca>

 > Can anyone provide me a reference for Unicode version conventions?  I
 > would like to add it to tcw22 and also to
 > 
http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-data.version.html ,
 > which mentions this but does not explain the usage.

<http://unicode.org/versions/#Version_Numbering>

On 12-06-15 06:29 AM, Kevin Hawkins wrote:
> I propose the following additions to tcw22 to clarify creation and
> maintenance of readme files for releases:
>
> ###
>
> tcw22 should be revised so that:
>
> a) Before a release, the release technical skims the log and summarizes
> significant changes in a new P5/ReleaseNotes/readme-N.N.N.xml , named
> according to the Unicode version conventions.  Then s/he asks Council
> members to skim P5/ReleaseNotes/readme-N.N.N.xml and see if anything
> else comes to mind to add.  (Note that this ends up being publicly
> accessible at http://www.tei-c.org/release/doc/tei-p5-doc/ .)
>
> b) After a release, the Council chair emails TEI-L to announce the
> release and includes a copy of readme-N.N.N.xml.
>
> ###
>
> Can anyone provide me a reference for Unicode version conventions?  I
> would like to add it to tcw22 and also to
> http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-data.version.html ,
> which mentions this but does not explain the usage.

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From mholmes at uvic.ca  Fri Jun 15 12:17:41 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Fri, 15 Jun 2012 09:17:41 -0700
Subject: [tei-council] Oxford Face2Face meeting: Accommodation
In-Reply-To: <4FDB47A0.2060601@oucs.ox.ac.uk>
References: <4FDB47A0.2060601@oucs.ox.ac.uk>
Message-ID: <4FDB6025.9070909@uvic.ca>

I noticed the restriction to three nights, but that might be difficult 
given the flights from over here. If I have to stay a fourth, at my 
expense, can it be booked as part of the same block, or will I have to 
make a separate booking?

Cheers,
Martin

On 12-06-15 07:33 AM, James Cummings wrote:
>
> As you will all know the next face 2 face meeting is scheduled
> for 19-21 September 2012. In order to see if I can get
> accommodation for this all in one place (as Becky did in Ann
> Arbor), it would be good if you could indicate what nights you
> will need accommodation (at the expense of the TEI-C).  If you
> are doing something else or have weird needs, please email me.
>
> Otherwise, please fill out this poll:
> http://www.doodle.com/6n2uqbfq2wq6itdc
>
> -James
>

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From james.cummings at oucs.ox.ac.uk  Fri Jun 15 12:37:17 2012
From: james.cummings at oucs.ox.ac.uk (James Cummings)
Date: Fri, 15 Jun 2012 16:37:17 +0000
Subject: [tei-council] Oxford Face2Face meeting: Accommodation
In-Reply-To: <4FDB6025.9070909@uvic.ca>
References: <4FDB47A0.2060601@oucs.ox.ac.uk>,<4FDB6025.9070909@uvic.ca>
Message-ID: <sha1t5s9d26gcwpiot46d2xi.1339778207132@email.android.com>


The budget is for 3 nights, but it depends on others arrangements and where these may save us money.  We can probably stretch to four nights, especially if it results in a cheaper air fare (e.g. for including a Saturday).  That is why I want everyone to fill in the poll, even if it is to indicate the TEI-C isn't paying anything to their accommodation. So put down what you need and we'll see what we can do. ;-)

Jamesc
--
James Cummings, InfoDev, OUCS, University of Oxford (from phone)

Martin Holmes <mholmes at uvic.ca> wrote:


I noticed the restriction to three nights, but that might be difficult
given the flights from over here. If I have to stay a fourth, at my
expense, can it be booked as part of the same block, or will I have to
make a separate booking?

Cheers,
Martin

On 12-06-15 07:33 AM, James Cummings wrote:
>
> As you will all know the next face 2 face meeting is scheduled
> for 19-21 September 2012. In order to see if I can get
> accommodation for this all in one place (as Becky did in Ann
> Arbor), it would be good if you could indicate what nights you
> will need accommodation (at the expense of the TEI-C).  If you
> are doing something else or have weird needs, please email me.
>
> Otherwise, please fill out this poll:
> http://www.doodle.com/6n2uqbfq2wq6itdc
>
> -James
>

--
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From mholmes at uvic.ca  Fri Jun 15 13:33:38 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Fri, 15 Jun 2012 10:33:38 -0700
Subject: [tei-council] Oxford Face2Face meeting: Accommodation
In-Reply-To: <sha1t5s9d26gcwpiot46d2xi.1339778207132@email.android.com>
References: <4FDB47A0.2060601@oucs.ox.ac.uk>, <4FDB6025.9070909@uvic.ca>
	<sha1t5s9d26gcwpiot46d2xi.1339778207132@email.android.com>
Message-ID: <4FDB71F2.7060200@uvic.ca>

I've put four in, but I am happy to pay for the fourth if I need it.

Cheers,
Martin

On 12-06-15 09:37 AM, James Cummings wrote:
>
> The budget is for 3 nights, but it depends on others arrangements and where these may save us money.  We can probably stretch to four nights, especially if it results in a cheaper air fare (e.g. for including a Saturday).  That is why I want everyone to fill in the poll, even if it is to indicate the TEI-C isn't paying anything to their accommodation. So put down what you need and we'll see what we can do. ;-)
>
> Jamesc
> --
> James Cummings, InfoDev, OUCS, University of Oxford (from phone)
>
> Martin Holmes<mholmes at uvic.ca>  wrote:
>
>
> I noticed the restriction to three nights, but that might be difficult
> given the flights from over here. If I have to stay a fourth, at my
> expense, can it be booked as part of the same block, or will I have to
> make a separate booking?
>
> Cheers,
> Martin
>
> On 12-06-15 07:33 AM, James Cummings wrote:
>>
>> As you will all know the next face 2 face meeting is scheduled
>> for 19-21 September 2012. In order to see if I can get
>> accommodation for this all in one place (as Becky did in Ann
>> Arbor), it would be good if you could indicate what nights you
>> will need accommodation (at the expense of the TEI-C).  If you
>> are doing something else or have weird needs, please email me.
>>
>> Otherwise, please fill out this poll:
>> http://www.doodle.com/6n2uqbfq2wq6itdc
>>
>> -James
>>
>
> --
> Martin Holmes
> University of Victoria Humanities Computing and Media Centre
> (mholmes at uvic.ca)
> .
>

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From mholmes at uvic.ca  Fri Jun 15 14:46:27 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Fri, 15 Jun 2012 11:46:27 -0700
Subject: [tei-council] Two quick questions about Schematron constraints
Message-ID: <4FDB8303.8010001@uvic.ca>

I'm rather belatedly getting around to implementing a couple of 
schematron constraints I was tasked with at Ann Arbor, and thinking 
about the explanatory bit on constraints that I'll be writing for "How 
to edit the Guidelines".

Looking at the existing constraints, I have a couple of questions:

In this constraint (from delSpan):

   <constraintSpec ident="spanTo" scheme="isoschematron">
     <constraint>
       <assert xmlns="http://purl.oclc.org/dsdl/schematron" 
test="@spanTo">The spanTo= attribute of <name/> is required.</assert>
     </constraint>
   </constraintSpec>

does <name/> automatically get replaced by ancestor::elementSpec/@ident? 
What happens in the case of constraints on attributes? There appears to 
be only one (on @targetLang in att.pointing), but if <name/> were used 
there, would it be replaced with @targetLang, or with the ancestor's 
@ident (att.pointing)?

Secondly, these constraints appear on the root TEI element:

   <constraintSpec ident="c1" scheme="isoschematron">
     <constraint>
       <ns xmlns="http://purl.oclc.org/dsdl/schematron" prefix="tei" 
uri="http://www.tei-c.org/ns/1.0"/>
     </constraint>
   </constraintSpec>
   <constraintSpec ident="c2" scheme="isoschematron">
     <constraint>
       <ns xmlns="http://purl.oclc.org/dsdl/schematron" prefix="rng" 
uri="http://relaxng.org/ns/structure/1.0"/>
     </constraint>
   </constraintSpec>

What are they actually doing, if anything?

Cheers,
Martin
-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From mholmes at uvic.ca  Fri Jun 15 15:10:47 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Fri, 15 Jun 2012 12:10:47 -0700
Subject: [tei-council] Two quick questions about Schematron constraints
In-Reply-To: <4FDB8303.8010001@uvic.ca>
References: <4FDB8303.8010001@uvic.ca>
Message-ID: <4FDB88B7.9000404@uvic.ca>

> ...constraints on attributes? There appears to
>> be only one (on @targetLang in att.pointing)

Apologies, there are two; the other is @prefix on moduleRef.

On 12-06-15 11:46 AM, Martin Holmes wrote:
> I'm rather belatedly getting around to implementing a couple of
> schematron constraints I was tasked with at Ann Arbor, and thinking
> about the explanatory bit on constraints that I'll be writing for "How
> to edit the Guidelines".
>
> Looking at the existing constraints, I have a couple of questions:
>
> In this constraint (from delSpan):
>
>     <constraintSpec ident="spanTo" scheme="isoschematron">
>       <constraint>
>         <assert xmlns="http://purl.oclc.org/dsdl/schematron"
> test="@spanTo">The spanTo= attribute of<name/>  is required.</assert>
>       </constraint>
>     </constraintSpec>
>
> does<name/>  automatically get replaced by ancestor::elementSpec/@ident?
> What happens in the case of constraints on attributes? There appears to
> be only one (on @targetLang in att.pointing), but if<name/>  were used
> there, would it be replaced with @targetLang, or with the ancestor's
> @ident (att.pointing)?
>
> Secondly, these constraints appear on the root TEI element:
>
>     <constraintSpec ident="c1" scheme="isoschematron">
>       <constraint>
>         <ns xmlns="http://purl.oclc.org/dsdl/schematron" prefix="tei"
> uri="http://www.tei-c.org/ns/1.0"/>
>       </constraint>
>     </constraintSpec>
>     <constraintSpec ident="c2" scheme="isoschematron">
>       <constraint>
>         <ns xmlns="http://purl.oclc.org/dsdl/schematron" prefix="rng"
> uri="http://relaxng.org/ns/structure/1.0"/>
>       </constraint>
>     </constraintSpec>
>
> What are they actually doing, if anything?
>
> Cheers,
> Martin

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From lou.burnard at retired.ox.ac.uk  Fri Jun 15 15:56:28 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Fri, 15 Jun 2012 20:56:28 +0100
Subject: [tei-council] Two quick questions about Schematron constraints
In-Reply-To: <4FDB8303.8010001@uvic.ca>
References: <4FDB8303.8010001@uvic.ca>
Message-ID: <4FDB936C.8060706@retired.ox.ac.uk>

On 15/06/12 19:46, Martin Holmes wrote:

> In this constraint (from delSpan):
>
>     <constraintSpec ident="spanTo" scheme="isoschematron">
>       <constraint>
>         <assert xmlns="http://purl.oclc.org/dsdl/schematron"
> test="@spanTo">The spanTo= attribute of<name/>  is required.</assert>
>       </constraint>
>     </constraintSpec>
>
> does<name/>  automatically get replaced by ancestor::elementSpec/@ident?

Judging from the output of the detest test file, yes. I think it's dark 
magic though.

> What happens in the case of constraints on attributes? There appears to
> be only one (on @targetLang in att.pointing), but if<name/>  were used
> there, would it be replaced with @targetLang, or with the ancestor's
> @ident (att.pointing)?

No idea, but my guess is neither : I think it would be replaced by the 
name of the gi of the element which was being processed when the rule 
fired. Try it!

>
> Secondly, these constraints appear on the root TEI element:
>
>     <constraintSpec ident="c1" scheme="isoschematron">
>       <constraint>
>         <ns xmlns="http://purl.oclc.org/dsdl/schematron" prefix="tei"
> uri="http://www.tei-c.org/ns/1.0"/>
>       </constraint>
>     </constraintSpec>
>     <constraintSpec ident="c2" scheme="isoschematron">
>       <constraint>
>         <ns xmlns="http://purl.oclc.org/dsdl/schematron" prefix="rng"
> uri="http://relaxng.org/ns/structure/1.0"/>
>       </constraint>
>     </constraintSpec>
>
> What are they actually doing, if anything?

I think this is more dark magic, the effect of which is to bung the 
required namespace declarations into the isosch file generated during 
the P5 build.


From mholmes at uvic.ca  Fri Jun 15 16:41:23 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Fri, 15 Jun 2012 13:41:23 -0700
Subject: [tei-council] At least one <rdg> in <app>
Message-ID: <4FDB9DF3.6000304@uvic.ca>

Hi all,

One of my tasks is this one, relating to <rdg>s in <app>:

"http://purl.org/tei/bug/3496958 (MH) We leave the content model alone 
(it?s horrible), but we use this as an example for Council to 
collaborate on the creation of one or more Schematron constraints which 
will enforce the presence of at least one <rdg> , to everyone?s 
edification."

I have actually done this, but I'm a little concerned that I shouldn't 
have, because if we look at the ticket:

<http://purl.org/TEI/BUGS/3496958>

it seems clear that Gaby at least is not in agreement with this.

Going back to the minutes of the Ann Arbor discussion, we have this:

3496958  (number of <rdg>s in <app>):

                 GB added a note to the ticket saying that the 
availability of a single <rdg> is intentional and required.

                 Action: (MH) We leave the content model alone (it?s 
horrible), but we use this as an example for Council to collaborate on 
the creation of one or more Schematron constraints which will enforce 
the presence of at least one <rdg>, to everyone?s edification.

This doesn't reflect quite what Gaby said on the ticket, which was that 
the original element definition "was deliberate to allow an <app> with 
no <rdg> as well. (The use-case envisaged was just a <ptr> [to an app, 
choice, subst or similar construction in the transcription] and/or a 
<note> with editorial observations on it.)"

So before we let this constraint out into the wild, I thought we should 
revisit it and confirm that we really do want to force at least one 
<rdg> in <app>. If so, I'll happily add a detailed comment on the ticket 
explaining how we got there, and close it, but if not I can remove the 
constraint.

Cheers,
Martin

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From kevin.s.hawkins at ultraslavonic.info  Fri Jun 15 18:21:19 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Fri, 15 Jun 2012 18:21:19 -0400
Subject: [tei-council] Location of <app>s for external apparatus
In-Reply-To: <4FDB5DE9.2040408@uvic.ca>
References: <4FD7D3CF.50605@uvic.ca>	<CAC_Lu0YjwL7GMc3UPvk2WUEXKDLenDPFWja_fj+1mjrz33HaKw@mail.gmail.com>	<4FD8DB69.2060206@uvic.ca>	<4FD8EA62.6010400@kcl.ac.uk>	<4FD90992.9010302@ultraslavonic.info>	<4FD90F95.8000903@uvic.ca>
	<4FDA0843.7080809@oucs.ox.ac.uk>	<86d3352e-be37-484a-aa13-effa49d1e143@HUB01.ad.oak.ox.ac.uk>	<4FDA1412.2050407@oucs.ox.ac.uk>	<640eed6a-7db5-4e09-98f0-a35c0a8c2849@HUB02.ad.oak.ox.ac.uk>	<4FDAEFF2.6090705@oucs.ox.ac.uk>	<8F61DC63-95B4-4951-BAE4-AC175BA05910@oucs.ox.ac.uk>	<4FDAF32C.40501@oucs.ox.ac.uk>	<127bcc21-e4c7-415e-9755-8abd6fd2d853@HUB04.ad.oak.ox.ac.uk>	<4FDAF627.1040002@gmail.com>	<2343E158-1F56-494D-93C8-37A31F3FE7F0@oucs.ox.ac.uk>
	<4FDB5DE9.2040408@uvic.ca>
Message-ID: <4FDBB55F.4070004@ultraslavonic.info>

See below ...

On 6/15/2012 12:08 PM, Martin Holmes wrote:
> On 12-06-15 01:49 AM, Sebastian Rahtz wrote:
>>
>> On 15 Jun 2012, at 09:45, stuart yeates wrote:
>>
>>> It would be useful to have a global clue that something is standoff (I
>>> anticipate a need for it on the SOM group, but we're not reached there
>>> yet).
>>>
>>> Is there one?
>>
>>
>> I dont think so. in the case of eg<link>, its _always_ standoff, but<app>
>> and<note>   can be used in either way, which is confusing (to me).
>>
>> one could almost posit _another_ sibling of<text>   called<standoffText>   where
>> all this stuff lives.
>
> I think one should seriously posit such a thing. A born-digital document
> is a very different scenario from a traditional
> transcription-from-source, and leaving born-digitals aside for the
> moment, we have a situation where the original source document probably
> has<front>,<body>  and<back>, and all the real original content would
> be transcribed there, in the order in which it appears. Adding in
> standoff content to<back>  is ambiguous, and problematic for anyone
> writing stylesheets or other processors. And I share James's unhappiness
> with suggesting that something as ill-constrained as @type be used to
> distinguish the two cases.
>
> So I like the idea of a fourth child of<text>, which explicitly
> contains stuff which is out-of-sequence, editorial, or otherwise not
> part of the normal flow of the source document. I don't like the name
> <standoffText>, though, because it may not always be textual stuff;
> <linkGrp>s and<link>s belong there too, for instance.

And <interpGrp>!  It has long driven me crazy that you insert this in 
<back> even though it basically never occurs in the source document but 
that there isn't a recommended way to indicate that such an element is 
not meant to be rendered as part of the encoded text.

So I would be very interested in the fourth child of <text> as well. 
But I wonder whether we can solve the <listApp> problem separately, even 
only for those who are encoding an apparatus that occurs in the source 
document.

> We need a name that incorporates the idea that these items are not part
> of the source document flow, although they may include text which ends
> up being rendered into that flow.

<supplements>?

From lou.burnard at retired.ox.ac.uk  Fri Jun 15 18:31:19 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Fri, 15 Jun 2012 23:31:19 +0100
Subject: [tei-council] Location of <app>s for external apparatus
In-Reply-To: <4FDBB55F.4070004@ultraslavonic.info>
References: <4FD7D3CF.50605@uvic.ca>	<CAC_Lu0YjwL7GMc3UPvk2WUEXKDLenDPFWja_fj+1mjrz33HaKw@mail.gmail.com>	<4FD8DB69.2060206@uvic.ca>	<4FD8EA62.6010400@kcl.ac.uk>	<4FD90992.9010302@ultraslavonic.info>	<4FD90F95.8000903@uvic.ca>
	<4FDA0843.7080809@oucs.ox.ac.uk>	<86d3352e-be37-484a-aa13-effa49d1e143@HUB01.ad.oak.ox.ac.uk>	<4FDA1412.2050407@oucs.ox.ac.uk>	<640eed6a-7db5-4e09-98f0-a35c0a8c2849@HUB02.ad.oak.ox.ac.uk>	<4FDAEFF2.6090705@oucs.ox.ac.uk>	<8F61DC63-95B4-4951-BAE4-AC175BA05910@oucs.ox.ac.uk>	<4FDAF32C.40501@oucs.ox.ac.uk>	<127bcc21-e4c7-415e-9755-8abd6fd2d853@HUB04.ad.oak.ox.ac.uk>	<4FDAF627.1040002@gmail.com>	<2343E158-1F56-494D-93C8-37A31F3FE7F0@oucs.ox.ac.uk>
	<4FDB5DE9.2040408@uvic.ca> <4FDBB55F.4070004@ultraslavonic.info>
Message-ID: <4FDBB7B7.8010208@retired.ox.ac.uk>

On 15/06/12 23:21, Kevin Hawkins wrote:
> See below ...
>
> On 6/15/2012 12:08 PM, Martin Holmes wrote:
>> On 12-06-15 01:49 AM, Sebastian Rahtz wrote:
>>>
>>> On 15 Jun 2012, at 09:45, stuart yeates wrote:
>>>
>>>> It would be useful to have a global clue that something is standoff (I
>>>> anticipate a need for it on the SOM group, but we're not reached there
>>>> yet).
>>>>
>>>> Is there one?
>>>
>>>
>>> I dont think so. in the case of eg<link>, its _always_ standoff, but<app>
>>> and<note>    can be used in either way, which is confusing (to me).
>>>
>>> one could almost posit _another_ sibling of<text>    called<standoffText>    where
>>> all this stuff lives.

[ snip ]


> So I would be very interested in the fourth child of<text>  as well.
> But I wonder whether we can solve the<listApp>  problem separately, even
> only for those who are encoding an apparatus that occurs in the source
> document.
>
>> We need a name that incorporates the idea that these items are not part
>> of the source document flow, although they may include text which ends
>> up being rendered into that flow.
>
> <supplements>?


We need to be clear what we're talking about here. Is it a child of 
<text> or a sibling?

I think the original suggestion was the latter. However, what if the 
<text> is inside a <group>? Do I have to sort out my <extraBits> so that 
they're with the appropriate <text> inside the <group> or do I put them 
all together along with the outer <text>?

When and why did we decide this thingie should not be in the Header? 
Makes perfectly good sense to me -- it's metadata isn't it? Why not put 
it inside say encodingDesc/editorialDecl/ ?

(BTW, the idea for this container is not new : it was mooted back in 
SGML days when we thought it might be amusing to call it 
"LinkedDataBlock" or ldb for short.)



From mholmes at uvic.ca  Sat Jun 16 02:02:16 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Fri, 15 Jun 2012 23:02:16 -0700
Subject: [tei-council] Location of <app>s for external apparatus
In-Reply-To: <4FDBB55F.4070004@ultraslavonic.info>
References: <4FD7D3CF.50605@uvic.ca>
	<CAC_Lu0YjwL7GMc3UPvk2WUEXKDLenDPFWja_fj+1mjrz33HaKw@mail.gmail.com>
	<4FD8DB69.2060206@uvic.ca>	<4FD8EA62.6010400@kcl.ac.uk>
	<4FD90992.9010302@ultraslavonic.info>	<4FD90F95.8000903@uvic.ca>
	<4FDA0843.7080809@oucs.ox.ac.uk>
	<86d3352e-be37-484a-aa13-effa49d1e143@HUB01.ad.oak.ox.ac.uk>
	<4FDA1412.2050407@oucs.ox.ac.uk>
	<640eed6a-7db5-4e09-98f0-a35c0a8c2849@HUB02.ad.oak.ox.ac.uk>
	<4FDAEFF2.6090705@oucs.ox.ac.uk>
	<8F61DC63-95B4-4951-BAE4-AC175BA05910@oucs.ox.ac.uk>
	<4FDAF32C.40501@oucs.ox.ac.uk>
	<127bcc21-e4c7-415e-9755-8abd6fd2d853@HUB04.ad.oak.ox.ac.uk>
	<4FDAF627.1040002@gmail.com>
	<2343E158-1F56-494D-93C8-37A31F3FE7F0@oucs.ox.ac.uk>
	<4FDB5DE9.2040408@uvic.ca> <4FDBB55F.4070004@ultraslavonic.info>
Message-ID: <4FDC2168.1070106@uvic.ca>

On 12-06-15 03:21 PM, Kevin Hawkins wrote:

>>>
>>> one could almost posit _another_ sibling of<text>    called<standoffText>    where
>>> all this stuff lives.
>>
>> I think one should seriously posit such a thing. A born-digital document
>> is a very different scenario from a traditional
>> transcription-from-source, and leaving born-digitals aside for the
>> moment, we have a situation where the original source document probably
>> has<front>,<body>   and<back>, and all the real original content would
>> be transcribed there, in the order in which it appears. Adding in
>> standoff content to<back>   is ambiguous, and problematic for anyone
>> writing stylesheets or other processors. And I share James's unhappiness
>> with suggesting that something as ill-constrained as @type be used to
>> distinguish the two cases.
>>
>> So I like the idea of a fourth child of<text>, which explicitly
>> contains stuff which is out-of-sequence, editorial, or otherwise not
>> part of the normal flow of the source document. I don't like the name
>> <standoffText>, though, because it may not always be textual stuff;
>> <linkGrp>s and<link>s belong there too, for instance.
>
> And<interpGrp>!  It has long driven me crazy that you insert this in
> <back>  even though it basically never occurs in the source document but
> that there isn't a recommended way to indicate that such an element is
> not meant to be rendered as part of the encoded text.

Good point! Are there any others I've forgotten?

> So I would be very interested in the fourth child of<text>  as well.
> But I wonder whether we can solve the<listApp>  problem separately, even
> only for those who are encoding an apparatus that occurs in the source
> document.

I think we definitely do need <listApp> anyway, and people will find it 
useful without this extra text child, but we're not going to have it 
ready for Monday's release, so we might as well think about the whole 
package together. It would be nice to be able to rewrite the Guidelines 
not only to introduce <listApp> but also to recommend a place to put it, 
along with other similar stuff.

>> We need a name that incorporates the idea that these items are not part
>> of the source document flow, although they may include text which ends
>> up being rendered into that flow.
>
> <supplements>?

Yes, or <supplementary>, or <extras>? None of these is quite right 
somehow...

Cheers,
Martin

-- 
Martin Holmes
mholmes at uvic.ca
UVic Humanities Computing and Media Centre

From mholmes at uvic.ca  Sat Jun 16 02:09:38 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Fri, 15 Jun 2012 23:09:38 -0700
Subject: [tei-council] Location of <app>s for external apparatus
In-Reply-To: <4FDBB7B7.8010208@retired.ox.ac.uk>
References: <4FD7D3CF.50605@uvic.ca>
	<CAC_Lu0YjwL7GMc3UPvk2WUEXKDLenDPFWja_fj+1mjrz33HaKw@mail.gmail.com>
	<4FD8DB69.2060206@uvic.ca>	<4FD8EA62.6010400@kcl.ac.uk>
	<4FD90992.9010302@ultraslavonic.info>	<4FD90F95.8000903@uvic.ca>
	<4FDA0843.7080809@oucs.ox.ac.uk>
	<86d3352e-be37-484a-aa13-effa49d1e143@HUB01.ad.oak.ox.ac.uk>
	<4FDA1412.2050407@oucs.ox.ac.uk>
	<640eed6a-7db5-4e09-98f0-a35c0a8c2849@HUB02.ad.oak.ox.ac.uk>
	<4FDAEFF2.6090705@oucs.ox.ac.uk>
	<8F61DC63-95B4-4951-BAE4-AC175BA05910@oucs.ox.ac.uk>
	<4FDAF32C.40501@oucs.ox.ac.uk>
	<127bcc21-e4c7-415e-9755-8abd6fd2d853@HUB04.ad.oak.ox.ac.uk>
	<4FDAF627.1040002@gmail.com>
	<2343E158-1F56-494D-93C8-37A31F3FE7F0@oucs.ox.ac.uk>
	<4FDB5DE9.2040408@uvic.ca> <4FDBB55F.4070004@ultraslavonic.info>
	<4FDBB7B7.8010208@retired.ox.ac.uk>
Message-ID: <4FDC2322.4000506@uvic.ca>

On 12-06-15 03:31 PM, Lou Burnard wrote:

>> So I would be very interested in the fourth child of<text>   as well.
>> But I wonder whether we can solve the<listApp>   problem separately, even
>> only for those who are encoding an apparatus that occurs in the source
>> document.
>>
>>> We need a name that incorporates the idea that these items are not part
>>> of the source document flow, although they may include text which ends
>>> up being rendered into that flow.
>>
>> <supplements>?
>
>
> We need to be clear what we're talking about here. Is it a child of
> <text>  or a sibling?

I had been thinking a child, because its proposed content is sometimes 
part of the "text" (in the case of <app>, for instance, where <rdg>s are 
part of one of the sources).

> I think the original suggestion was the latter. However, what if the
> <text>  is inside a<group>? Do I have to sort out my<extraBits>  so that
> they're with the appropriate<text>  inside the<group>  or do I put them
> all together along with the outer<text>?

A nice question. I think if the content of the element applies only to 
one <text>, then it belongs in that <text>, but if it applies to the 
<group>, then it should be a child of the <group>. So it needs to be 
allowed in both places. It should also, presumably, be available as a 
child of <teiCorpus>, for cases where its content applies to all the 
<TEI>s therein.

> When and why did we decide this thingie should not be in the Header?
> Makes perfectly good sense to me -- it's metadata isn't it? Why not put
> it inside say encodingDesc/editorialDecl/ ?

It's not metadata; at least in the case of <app>s, it's content from one 
or more source texts.

> (BTW, the idea for this container is not new : it was mooted back in
> SGML days when we thought it might be amusing to call it
> "LinkedDataBlock" or ldb for short.)

This is only amusing if your middle initial is d. Is it?

Cheers,
Martin

-- 
Martin Holmes
mholmes at uvic.ca
UVic Humanities Computing and Media Centre

From sebastian.rahtz at oucs.ox.ac.uk  Sat Jun 16 02:35:48 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Sat, 16 Jun 2012 06:35:48 +0000
Subject: [tei-council] Location of <app>s for external apparatus
In-Reply-To: <4FDC2168.1070106@uvic.ca>
References: <4FD7D3CF.50605@uvic.ca>
	<CAC_Lu0YjwL7GMc3UPvk2WUEXKDLenDPFWja_fj+1mjrz33HaKw@mail.gmail.com>
	<4FD8DB69.2060206@uvic.ca>	<4FD8EA62.6010400@kcl.ac.uk>
	<4FD90992.9010302@ultraslavonic.info>	<4FD90F95.8000903@uvic.ca>
	<4FDA0843.7080809@oucs.ox.ac.uk>
	<86d3352e-be37-484a-aa13-effa49d1e143@HUB01.ad.oak.ox.ac.uk>
	<4FDA1412.2050407@oucs.ox.ac.uk>
	<640eed6a-7db5-4e09-98f0-a35c0a8c2849@HUB02.ad.oak.ox.ac.uk>
	<4FDAEFF2.6090705@oucs.ox.ac.uk>
	<8F61DC63-95B4-4951-BAE4-AC175BA05910@oucs.ox.ac.uk>
	<4FDAF32C.40501@oucs.ox.ac.uk>
	<127bcc21-e4c7-415e-9755-8abd6fd2d853@HUB04.ad.oak.ox.ac.uk>
	<4FDAF627.1040002@gmail.com>
	<2343E158-1F56-494D-93C8-37A31F3FE7F0@oucs.ox.ac.uk>
	<4FDB5DE9.2040408@uvic.ca> <4FDBB55F.4070004@ultraslavonic.info>
	<4FDC2168.1070106@uvic.ca>
Message-ID: <EF153BCB-3A4F-4E1E-A9D8-946DF1CC7F93@oucs.ox.ac.uk>

I suggested  a sibling of <text>, alongside <sourceDoc> and <facsimile>, because its not in the natural reading order [1] (<text>)
but neither is it metadata (<teiHeader>). It's definitely content, either editorial or standoff, not supporting material (Imho).

for names, I'll add <dataBlock>, <dataDoc>, and <linkDoc> to the mix

btw, why do we want <listApp> and not <appGrp>? I can never remember the difference

[1] yeah yeah but you know what I mean
--
Sebastian Rahtz      
Head of Information and Support Group
Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431







From sebastian.rahtz at oucs.ox.ac.uk  Sat Jun 16 02:40:24 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Sat, 16 Jun 2012 06:40:24 +0000
Subject: [tei-council] Two quick questions about Schematron constraints
In-Reply-To: <4FDB8303.8010001@uvic.ca>
References: <4FDB8303.8010001@uvic.ca>
Message-ID: <C5DF557B-09BA-4C82-9086-7B7886DA9D07@oucs.ox.ac.uk>


On 15 Jun 2012, at 19:46, Martin Holmes wrote:

> 
> In this constraint (from delSpan):
> 
>   <constraintSpec ident="spanTo" scheme="isoschematron">
>     <constraint>
>       <assert xmlns="http://purl.oclc.org/dsdl/schematron" 
> test="@spanTo">The spanTo= attribute of <name/> is required.</assert>
>     </constraint>
>   </constraintSpec>
> 
> does <name/> automatically get replaced by ancestor::elementSpec/@ident? 

<name/> is the name of the element which the constraint matches. so no,
not that @ident, but the name() of the matching element. Similar, but
not the same.

> What happens in the case of constraints on attributes? There appears to 
> be only one (on @targetLang in att.pointing), but if <name/> were used 
> there, would it be replaced with @targetLang, or with the ancestor's 
> @ident (att.pointing)?
@targetLang

the replacement of <name/> is done in Schematron, not in ODD processing


> Secondly, these constraints appear on the root TEI element:
> 
>   <constraintSpec ident="c1" scheme="isoschematron">
>     <constraint>
>       <ns xmlns="http://purl.oclc.org/dsdl/schematron" prefix="tei" 
> uri="http://www.tei-c.org/ns/1.0"/>
>     </constraint>
>   </constraintSpec>
>   <constraintSpec ident="c2" scheme="isoschematron">
>     <constraint>
>       <ns xmlns="http://purl.oclc.org/dsdl/schematron" prefix="rng" 
> uri="http://relaxng.org/ns/structure/1.0"/>
>     </constraint>
>   </constraintSpec>
> 
> What are they actually doing, if anything?


declaring namespace prefixes. It is a pain having to do this, but its needed.
--
Sebastian Rahtz      
Head of Information and Support Group
Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431







From mholmes at uvic.ca  Sat Jun 16 02:42:02 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Fri, 15 Jun 2012 23:42:02 -0700
Subject: [tei-council] Location of <app>s for external apparatus
In-Reply-To: <EF153BCB-3A4F-4E1E-A9D8-946DF1CC7F93@oucs.ox.ac.uk>
References: <4FD7D3CF.50605@uvic.ca>
	<CAC_Lu0YjwL7GMc3UPvk2WUEXKDLenDPFWja_fj+1mjrz33HaKw@mail.gmail.com>
	<4FD8DB69.2060206@uvic.ca>	<4FD8EA62.6010400@kcl.ac.uk>
	<4FD90992.9010302@ultraslavonic.info>	<4FD90F95.8000903@uvic.ca>
	<4FDA0843.7080809@oucs.ox.ac.uk>
	<86d3352e-be37-484a-aa13-effa49d1e143@HUB01.ad.oak.ox.ac.uk>
	<4FDA1412.2050407@oucs.ox.ac.uk>
	<640eed6a-7db5-4e09-98f0-a35c0a8c2849@HUB02.ad.oak.ox.ac.uk>
	<4FDAEFF2.6090705@oucs.ox.ac.uk>
	<8F61DC63-95B4-4951-BAE4-AC175BA05910@oucs.ox.ac.uk>
	<4FDAF32C.40501@oucs.ox.ac.uk>
	<127bcc21-e4c7-415e-9755-8abd6fd2d853@HUB04.ad.oak.ox.ac.uk>
	<4FDAF627.1040002@gmail.com>
	<2343E158-1F56-494D-93C8-37A31F3FE7F0@oucs.ox.ac.uk>
	<4FDB5DE9.2040408@uvic.ca> <4FDBB55F.4070004@ultraslavonic.info>
	<4FDC2168.1070106@uvic.ca>
	<EF153BCB-3A4F-4E1E-A9D8-946DF1CC7F93@oucs.ox.ac.uk>
Message-ID: <4FDC2ABA.5020000@uvic.ca>

HI Sebastian,


 > btw, why do we want<listApp>  and not<appGrp>? I can never remember 
the difference

I think <appGrp> would imply that there's no meaningful order, but there 
usually is with <app>s; they go in document order.

How come you're up so early on a weekend? Or are you not in Oxford?

Cheers,
Martin

On 12-06-15 11:35 PM, Sebastian Rahtz wrote:
> I suggested  a sibling of<text>, alongside<sourceDoc>  and<facsimile>, because its not in the natural reading order [1] (<text>)
> but neither is it metadata (<teiHeader>). It's definitely content, either editorial or standoff, not supporting material (Imho).
>
> for names, I'll add<dataBlock>,<dataDoc>, and<linkDoc>  to the mix
>
> btw, why do we want<listApp>  and not<appGrp>? I can never remember the difference
>
> [1] yeah yeah but you know what I mean
> --
> Sebastian Rahtz
> Head of Information and Support Group
> Oxford University Computing Services
> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>
>
>
>
>
>

-- 
Martin Holmes
mholmes at uvic.ca
UVic Humanities Computing and Media Centre

From sebastian.rahtz at oucs.ox.ac.uk  Sat Jun 16 02:54:20 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Sat, 16 Jun 2012 06:54:20 +0000
Subject: [tei-council] Location of <app>s for external apparatus
In-Reply-To: <4FDC2ABA.5020000@uvic.ca>
References: <4FD7D3CF.50605@uvic.ca>
	<CAC_Lu0YjwL7GMc3UPvk2WUEXKDLenDPFWja_fj+1mjrz33HaKw@mail.gmail.com>
	<4FD8DB69.2060206@uvic.ca>	<4FD8EA62.6010400@kcl.ac.uk>
	<4FD90992.9010302@ultraslavonic.info>	<4FD90F95.8000903@uvic.ca>
	<4FDA0843.7080809@oucs.ox.ac.uk>
	<86d3352e-be37-484a-aa13-effa49d1e143@HUB01.ad.oak.ox.ac.uk>
	<4FDA1412.2050407@oucs.ox.ac.uk>
	<640eed6a-7db5-4e09-98f0-a35c0a8c2849@HUB02.ad.oak.ox.ac.uk>
	<4FDAEFF2.6090705@oucs.ox.ac.uk>
	<8F61DC63-95B4-4951-BAE4-AC175BA05910@oucs.ox.ac.uk>
	<4FDAF32C.40501@oucs.ox.ac.uk>
	<127bcc21-e4c7-415e-9755-8abd6fd2d853@HUB04.ad.oak.ox.ac.uk>
	<4FDAF627.1040002@gmail.com>
	<2343E158-1F56-494D-93C8-37A31F3FE7F0@oucs.ox.ac.uk>
	<4FDB5DE9.2040408@uvic.ca> <4FDBB55F.4070004@ultraslavonic.info>
	<4FDC2168.1070106@uvic.ca>
	<EF153BCB-3A4F-4E1E-A9D8-946DF1CC7F93@oucs.ox.ac.uk>
	<4FDC2ABA.5020000@uvic.ca>
Message-ID: <27EAB139-F76F-46DA-9A05-0DADDA03F512@oucs.ox.ac.uk>


On 16 Jun 2012, at 07:42, Martin Holmes wrote:

> > btw, why do we want<listApp>  and not<appGrp>? I can never remember the difference
> 
> I think <appGrp> would imply that there's no meaningful order, but there usually is with <app>s; they go in document order.
> 
ah, true

> How come you're up so early on a weekend? Or are you not in Oxford?


can't sleep, guilty conscience

anyway, I have to go running in half an hour. not much looking forward to it, been 3 weeks since
I ran a race
--
Sebastian Rahtz      
Head of Information and Support Group
Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431







From James.Cummings at oucs.ox.ac.uk  Sat Jun 16 05:59:10 2012
From: James.Cummings at oucs.ox.ac.uk (James Cummings)
Date: Sat, 16 Jun 2012 10:59:10 +0100
Subject: [tei-council] Location of <app>s for external apparatus
In-Reply-To: <4FDC2ABA.5020000@uvic.ca>
References: <4FD7D3CF.50605@uvic.ca>
	<CAC_Lu0YjwL7GMc3UPvk2WUEXKDLenDPFWja_fj+1mjrz33HaKw@mail.gmail.com>
	<4FD8DB69.2060206@uvic.ca>	<4FD8EA62.6010400@kcl.ac.uk>
	<4FD90992.9010302@ultraslavonic.info>	<4FD90F95.8000903@uvic.ca>
	<4FDA0843.7080809@oucs.ox.ac.uk>
	<86d3352e-be37-484a-aa13-effa49d1e143@HUB01.ad.oak.ox.ac.uk>
	<4FDA1412.2050407@oucs.ox.ac.uk>
	<640eed6a-7db5-4e09-98f0-a35c0a8c2849@HUB02.ad.oak.ox.ac.uk>
	<4FDAEFF2.6090705@oucs.ox.ac.uk>
	<8F61DC63-95B4-4951-BAE4-AC175BA05910@oucs.ox.ac.uk>
	<4FDAF32C.40501@oucs.ox.ac.uk>
	<127bcc21-e4c7-415e-9755-8abd6fd2d853@HUB04.ad.oak.ox.ac.uk>
	<4FDAF627.1040002@gmail.com>
	<2343E158-1F56-494D-93C8-37A31F3FE7F0@oucs.ox.ac.uk>
	<4FDB5DE9.2040408@uvic.ca> <4FDBB55F.4070004@ultraslavonic.info>
	<4FDC2168.1070106@uvic.ca>
	<EF153BCB-3A4F-4E1E-A9D8-946DF1CC7F93@oucs.ox.ac.uk>
	<4FDC2ABA.5020000@uvic.ca>
Message-ID: <4FDC58EE.10401@oucs.ox.ac.uk>

On 16/06/12 07:42, Martin Holmes wrote:
>> btw, why do we want<listApp>   and not<appGrp>? I can never
>> remember
> the difference
>
> I think<appGrp>  would imply that there's no meaningful order,
> but there usually is with<app>s; they go in document order.

Do they? I don't think that is necessarily the case, nor 
something we should require for anything that is recorded in a 
stand-off/out-of-line manner.  (Could you imagine if I told you 
that your <link> elements had to be in a particular order inside 
<linkGrp>?

-James
-- 
Dr James Cummings, InfoDev,
Computing Services, University of Oxford

From James.Cummings at oucs.ox.ac.uk  Sat Jun 16 06:02:15 2012
From: James.Cummings at oucs.ox.ac.uk (James Cummings)
Date: Sat, 16 Jun 2012 11:02:15 +0100
Subject: [tei-council] Location of <app>s for external apparatus
In-Reply-To: <4FDBB7B7.8010208@retired.ox.ac.uk>
References: <4FD7D3CF.50605@uvic.ca>	<CAC_Lu0YjwL7GMc3UPvk2WUEXKDLenDPFWja_fj+1mjrz33HaKw@mail.gmail.com>	<4FD8DB69.2060206@uvic.ca>	<4FD8EA62.6010400@kcl.ac.uk>	<4FD90992.9010302@ultraslavonic.info>	<4FD90F95.8000903@uvic.ca>
	<4FDA0843.7080809@oucs.ox.ac.uk>	<86d3352e-be37-484a-aa13-effa49d1e143@HUB01.ad.oak.ox.ac.uk>	<4FDA1412.2050407@oucs.ox.ac.uk>	<640eed6a-7db5-4e09-98f0-a35c0a8c2849@HUB02.ad.oak.ox.ac.uk>	<4FDAEFF2.6090705@oucs.ox.ac.uk>	<8F61DC63-95B4-4951-BAE4-AC175BA05910@oucs.ox.ac.uk>	<4FDAF32C.40501@oucs.ox.ac.uk>	<127bcc21-e4c7-415e-9755-8abd6fd2d853@HUB04.ad.oak.ox.ac.uk>	<4FDAF627.1040002@gmail.com>	<2343E158-1F56-494D-93C8-37A31F3FE7F0@oucs.ox.ac.uk>
	<4FDB5DE9.2040408@uvic.ca> <4FDBB55F.4070004@ultraslavonic.info>
	<4FDBB7B7.8010208@retired.ox.ac.uk>
Message-ID: <4FDC59A7.10603@oucs.ox.ac.uk>

On 15/06/12 23:31, Lou Burnard wrote:
> When and why did we decide this thingie should not be in the Header?
> Makes perfectly good sense to me -- it's metadata isn't it? Why not put
> it inside say encodingDesc/editorialDecl/ ?

<app>s are not metadata, they contain textual transcription.

> (BTW, the idea for this container is not new : it was mooted back in
> SGML days when we thought it might be amusing to call it
> "LinkedDataBlock" or ldb for short.)

Good initialism, I can see why you liked it.

-James

-- 
Dr James Cummings, InfoDev,
Computing Services, University of Oxford

From sebastian.rahtz at oucs.ox.ac.uk  Sat Jun 16 06:30:29 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Sat, 16 Jun 2012 10:30:29 +0000
Subject: [tei-council] Location of <app>s for external apparatus
In-Reply-To: <4FDC59A7.10603@oucs.ox.ac.uk>
References: <4FD7D3CF.50605@uvic.ca>
	<CAC_Lu0YjwL7GMc3UPvk2WUEXKDLenDPFWja_fj+1mjrz33HaKw@mail.gmail.com>
	<4FD8DB69.2060206@uvic.ca>	<4FD8EA62.6010400@kcl.ac.uk>
	<4FD90992.9010302@ultraslavonic.info>	<4FD90F95.8000903@uvic.ca>
	<4FDA0843.7080809@oucs.ox.ac.uk>
	<86d3352e-be37-484a-aa13-effa49d1e143@HUB01.ad.oak.ox.ac.uk>
	<4FDA1412.2050407@oucs.ox.ac.uk>
	<640eed6a-7db5-4e09-98f0-a35c0a8c2849@HUB02.ad.oak.ox.ac.uk>
	<4FDAEFF2.6090705@oucs.ox.ac.uk>
	<8F61DC63-95B4-4951-BAE4-AC175BA05910@oucs.ox.ac.uk>
	<4FDAF32C.40501@oucs.ox.ac.uk>
	<127bcc21-e4c7-415e-9755-8abd6fd2d853@HUB04.ad.oak.ox.ac.uk>
	<4FDAF627.1040002@gmail.com>
	<2343E158-1F56-494D-93C8-37A31F3FE7F0@oucs.ox.ac.uk>
	<4FDB5DE9.2040408@uvic.ca> <4FDBB55F.4070004@ultraslavonic.info>
	<4FDBB7B7.8010208@retired.ox.ac.uk> <4FDC59A7.10603@oucs.ox.ac.uk>
Message-ID: <09ffdc0e-aea5-46a9-9cc3-d4e5414f076d@HUB03.ad.oak.ox.ac.uk>


On 16 Jun 2012, at 11:02, James Cummings wrote:
>> (BTW, the idea for this container is not new : it was mooted back in
>> SGML days when we thought it might be amusing to call it
>> "LinkedDataBlock" or ldb for short.)
> 
> Good initialism, I can see why you liked it.



so why was the idea turned down, Lou, apart from the name?

were the arguments in favour the same?

--
Sebastian Rahtz      
Head of Information and Support Group
Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431







From gabriel.bodard at kcl.ac.uk  Sat Jun 16 11:14:56 2012
From: gabriel.bodard at kcl.ac.uk (Gabriel BODARD)
Date: Sat, 16 Jun 2012 16:14:56 +0100
Subject: [tei-council] Location of <app>s for external apparatus
In-Reply-To: <4FDC58EE.10401@oucs.ox.ac.uk>
References: <4FD7D3CF.50605@uvic.ca>
	<CAC_Lu0YjwL7GMc3UPvk2WUEXKDLenDPFWja_fj+1mjrz33HaKw@mail.gmail.com>
	<4FD8DB69.2060206@uvic.ca>	<4FD8EA62.6010400@kcl.ac.uk>
	<4FD90992.9010302@ultraslavonic.info>	<4FD90F95.8000903@uvic.ca>
	<4FDA0843.7080809@oucs.ox.ac.uk>
	<86d3352e-be37-484a-aa13-effa49d1e143@HUB01.ad.oak.ox.ac.uk>
	<4FDA1412.2050407@oucs.ox.ac.uk>
	<640eed6a-7db5-4e09-98f0-a35c0a8c2849@HUB02.ad.oak.ox.ac.uk>
	<4FDAEFF2.6090705@oucs.ox.ac.uk>
	<8F61DC63-95B4-4951-BAE4-AC175BA05910@oucs.ox.ac.uk>
	<4FDAF32C.40501@oucs.ox.ac.uk>
	<127bcc21-e4c7-415e-9755-8abd6fd2d853@HUB04.ad.oak.ox.ac.uk>
	<4FDAF627.1040002@gmail.com>
	<2343E158-1F56-494D-93C8-37A31F3FE7F0@oucs.ox.ac.uk>
	<4FDB5DE9.2040408@uvic.ca> <4FDBB55F.4070004@ultraslavonic.info>
	<4FDC2168.1070106@uvic.ca>
	<EF153BCB-3A4F-4E1E-A9D8-946DF1CC7F93@oucs.ox.ac.uk>
	<4FDC2ABA.5020000@uvic.ca> <4FDC58EE.10401@oucs.ox.ac.uk>
Message-ID: <4FDCA2F0.8030307@kcl.ac.uk>

On 16/06/2012 10:59, James Cummings wrote:
>> I think<appGrp>   would imply that there's no meaningful order,
>> but there usually is with<app>s; they go in document order.
>
> Do they? I don't think that is necessarily the case, nor
> something we should require for anything that is recorded in a
> stand-off/out-of-line manner.  (Could you imagine if I told you
> that your<link>  elements had to be in a particular order inside
> <linkGrp>?

That's the point, isn't it? The order of apps in an appList tends to be 
meaningful (even if not required or forced to follow any particular 
rule), whereas links in a linkGrp are assumed to be grouped in an 
arbitrary order. Because apps (like bibls and list items) are basically 
text, they have an order (not always static; a bibliography can be 
re-sorted on transformation) but there is usually *an* order.

G

-- 
Dr Gabriel BODARD
(Research Associate in Digital Epigraphy)

Department of Digital Humanities
King's College London
26-29 Drury Lane
London WC2B 5RL

Email: gabriel.bodard at kcl.ac.uk
Tel: +44 (0)20 7848 1388
Fax: +44 (0)20 7848 2980

http://www.digitalclassicist.org/
http://www.currentepigraphy.org/

From mholmes at uvic.ca  Sat Jun 16 14:04:24 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Sat, 16 Jun 2012 11:04:24 -0700
Subject: [tei-council] Location of <app>s for external apparatus
In-Reply-To: <4FDC58EE.10401@oucs.ox.ac.uk>
References: <4FD7D3CF.50605@uvic.ca>
	<CAC_Lu0YjwL7GMc3UPvk2WUEXKDLenDPFWja_fj+1mjrz33HaKw@mail.gmail.com>
	<4FD8DB69.2060206@uvic.ca>	<4FD8EA62.6010400@kcl.ac.uk>
	<4FD90992.9010302@ultraslavonic.info>	<4FD90F95.8000903@uvic.ca>
	<4FDA0843.7080809@oucs.ox.ac.uk>
	<86d3352e-be37-484a-aa13-effa49d1e143@HUB01.ad.oak.ox.ac.uk>
	<4FDA1412.2050407@oucs.ox.ac.uk>
	<640eed6a-7db5-4e09-98f0-a35c0a8c2849@HUB02.ad.oak.ox.ac.uk>
	<4FDAEFF2.6090705@oucs.ox.ac.uk>
	<8F61DC63-95B4-4951-BAE4-AC175BA05910@oucs.ox.ac.uk>
	<4FDAF32C.40501@oucs.ox.ac.uk>
	<127bcc21-e4c7-415e-9755-8abd6fd2d853@HUB04.ad.oak.ox.ac.uk>
	<4FDAF627.1040002@gmail.com>
	<2343E158-1F56-494D-93C8-37A31F3FE7F0@oucs.ox.ac.uk>
	<4FDB5DE9.2040408@uvic.ca> <4FDBB55F.4070004@ultraslavonic.info>
	<4FDC2168.1070106@uvic.ca>
	<EF153BCB-3A4F-4E1E-A9D8-946DF1CC7F93@oucs.ox.ac.uk>
	<4FDC2ABA.5020000@uvic.ca> <4FDC58EE.10401@oucs.ox.ac.uk>
Message-ID: <4FDCCAA8.6040402@uvic.ca>

On 12-06-16 02:59 AM, James Cummings wrote:
> On 16/06/12 07:42, Martin Holmes wrote:
>>> btw, why do we want<listApp>    and not<appGrp>? I can never
>>> remember
>> the difference
>>
>> I think<appGrp>   would imply that there's no meaningful order,
>> but there usually is with<app>s; they go in document order.
>
> Do they? I don't think that is necessarily the case, nor
> something we should require for anything that is recorded in a
> stand-off/out-of-line manner.  (Could you imagine if I told you
> that your<link>  elements had to be in a particular order inside
> <linkGrp>?

That was my point, surely -- <*Grp> doesn't imply any order, but <list*> 
either does, or may.

Cheers,
Martin

> -James

-- 
Martin Holmes
mholmes at uvic.ca
UVic Humanities Computing and Media Centre

From lou.burnard at retired.ox.ac.uk  Sat Jun 16 14:13:50 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Sat, 16 Jun 2012 19:13:50 +0100
Subject: [tei-council] readme for 2.1.0 release
Message-ID: <4FDCCCDE.8010004@retired.ox.ac.uk>

Some very unfortunate person fell onto the tracks outside the Gare du 
Nord this afternoon, and consequently I had a full extra hour sitting on 
the Eurostar home. Which means that although I did look through and 
sunmmarize all the tickets changed since the last release, I have only 
just now been able to check the result in to the repo.

I'm still working on it (some of the notes in the changelog were a bit 
too cryptic and without internet access I couldn't  decrypt them) but 
would appreciate having my attention drawn to anything council members 
feel is conspicuously missing or wrong.

The document is in the repo at P5/Releasenotes/readme-2.1.0.xml : you'll 
see that I've copied as XML comments the log messages summarized by each 
section, which form quite an entertaining corpus in themselves.

If you update your Stylesheets you'll find that there is now a "readme" 
profile for use with teitotxt which enables you to produce a plain text 
version of the file. I'll post the output from that here when I've 
finished tweaking, hopefully later today.




From lou.burnard at retired.ox.ac.uk  Sat Jun 16 18:09:10 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Sat, 16 Jun 2012 23:09:10 +0100
Subject: [tei-council] Release notes for 2.1.0
Message-ID: <4FDD0406.4060707@retired.ox.ac.uk>

I've stopped tweaking them now.

Plain text version, for distribution, follows:


TEI P5 version 2.1.0 release notes

   This is a maintenance release of the P5 Guidelines, which does 
however introduce some changes in existing content models.
   The majority of these changes and corrections are a consequence of 
feature requests or bugs reported by the TEI community, using the 
Sourceforge tracking system. The Council has also launched an initiative 
to make some systematic improvements in the prose of the Guidelines, 
notably in normalising some spelling and punctuation variations.
   Since the last release (14 February 2012), the Council has considered 
and disposed of 70 tickets entered in the sourceforge tracking system, 
from 15 different members of the TEI community. Full details may be 
found at http://tei.sf.net : an active list sorted by ticket number is 
available at the url http://bit.ly/N2P9Q2 and ticket numbers are also 
referenced in the subversion ChangeLog, as usual.

1  Schema Changes

   These changes should not affect existing documents, but do result in 
changes to the generated schemas.
   1  The content models of <availability> , <encodingDesc> , <formula> 
, <idno> <postscript> , <spGrp> , <surface> , and <table> have been 
modified to remove some inappropriate restrictions (3449887, 1650195, 
3437782, 3441658, 3305016)
   2  Additional schematron constraints have been implemented for 
several elements, notably for <attDef> , <delSpan> and other members of 
the att.spanning class.
   3  A new class att.datcat has been introduced to permit the use of 
ISO Standard Data Category Registry values where appropriate (3432520)
   4  The attribute version has been renamed versionDate to clarify its 
function (3393781)
   5  A new class att.witnessed was introduced to ensure that only 
appropriate elements carry the wit attribute (3496951)
   6  A new attribute targetLang was added to the att.pointing class to 
specify the language of the content of an element being pointed to 
(3288293)

2  Textual Changes

   A large number of minor enhancements of various kinds were 
implementing, ranging from correction of typos and normalisation of 
punctuation, to rewording of phrases considered needlessly obscure. In 
addition, a number of systematic checks and enhancements were carried out :
  * explicit usage examples are being added for all attributes 
specified, to complement those already provided for all elements;
  * several passages reported as misleading or ambiguous in sourceforge 
tickets were reworded or clarified;
  * some cosmetic changes were made to the formatting of the PDF and 
HTML versions of the Guidelines, notably to ensure that only open source 
fonts are used throughout;
  * a large number of typos were corrected, many of them reported by a 
few careful proofreaders from the TEI Community (particular thanks this 
time to Jens ?stergaard Petersen and to Pablo Rodriguez who between them 
reported over 30 errors!)

3  Environmental Changes

   The production of new releases of TEI P5 is now almost entirely 
automated, with all modifications continuously tested using a pair of 
Jenkins continuous integration servers. This has necessitated 
development and maintenance of a suite of scripts which have seen a 
large number of changes since the Council decided to ensure that a TEI 
P5 Release could be tested and delivered by any Council member. Full 
details of the current procedure for doing this are now provided in 
working document TCW20, which has been considerably enhanced during this 
period.

From kevin.s.hawkins at ultraslavonic.info  Sat Jun 16 18:31:59 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Sat, 16 Jun 2012 18:31:59 -0400
Subject: [tei-council] proposed additions to tcw22
In-Reply-To: <4FDB3BA8.5030200@oucs.ox.ac.uk>
References: <4FDB38D4.7010605@ultraslavonic.info>
	<4FDB3BA8.5030200@oucs.ox.ac.uk>
Message-ID: <4FDD095F.4050907@ultraslavonic.info>

Thanks.  Embarrassingly, some of what I proposed was already in the 
document, but I've just added a summary of the version number system as 
James explained it, plus a mention of Lou's readme profile for teitotxt, 
to tcw22.

On 6/15/12 9:42 AM, James Cummings wrote:
>
> I'm not sure what we follow is strictly Unicode version
> numbering, but it is certainly similar to it.  There is
> documentation about this at:
>
> http://unicode.org/versions/
>
> This does Major.minor.update numbers, incrementing for major
> changes, minor changes, and small updates.
>
> In our case we do Major.schema-changing.non-schema-changing
> numbering... but that is a bit of a mouthful.  The idea being we
> increment the second number only if changes that affect the
> schema have been introduced. If we correct some typos in the
> prose then we only increment the latter.  Note, if my
> understanding is correct, it might be theoretically possible to
> do a major change that wasn't schema changing. (e.g. if we
> rewrote most of the prose but didn't change element definitions
> or similar things which modify the TEI schema or abstract model).
> I think that would be very unlikely.
>
> So for example, the previous release was 2.0.2, and this release
> will be 2.1.0 because we have made schema-related changes but not
> so many or of such a drastic nature that we have made a major
> increment.
>
> -James
>
> On 15/06/12 14:29, Kevin Hawkins wrote:
>> I propose the following additions to tcw22 to clarify creation and
>> maintenance of readme files for releases:
>>
>> ###
>>
>> tcw22 should be revised so that:
>>
>> a) Before a release, the release technical skims the log and summarizes
>> significant changes in a new P5/ReleaseNotes/readme-N.N.N.xml , named
>> according to the Unicode version conventions.  Then s/he asks Council
>> members to skim P5/ReleaseNotes/readme-N.N.N.xml and see if anything
>> else comes to mind to add.  (Note that this ends up being publicly
>> accessible at http://www.tei-c.org/release/doc/tei-p5-doc/ .)
>>
>> b) After a release, the Council chair emails TEI-L to announce the
>> release and includes a copy of readme-N.N.N.xml.
>>
>> ###
>>
>> Can anyone provide me a reference for Unicode version conventions?  I
>> would like to add it to tcw22 and also to
>> http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-data.version.html ,
>> which mentions this but does not explain the usage.
>
>

From mholmes at uvic.ca  Sat Jun 16 19:15:23 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Sat, 16 Jun 2012 16:15:23 -0700
Subject: [tei-council] Release notes for 2.1.0
In-Reply-To: <4FDD0406.4060707@retired.ox.ac.uk>
References: <4FDD0406.4060707@retired.ox.ac.uk>
Message-ID: <4FDD138B.10202@uvic.ca>

Hi Lou,

Thanks for this painstaking work. I have only a couple of suggestions:

> 2  Additional schematron constraints have been implemented for
> several elements, notably for <attDef> , <delSpan> and other members of
> the att.spanning class.

We could add <app> to this -- I added a schematron constraint yesterday 
for it -- but as I reported to the group, I'm not sure if it was the 
right decision. If it doesn't get reversed, though, it could be included.

 >    * explicit usage examples are being added for all attributes
 > specified, to complement those already provided for all elements;

Given that we've only managed to add examples for six out of 221 cases 
so far, we should perhaps reword this to say that "We have just begun 
the process of adding examples..."

Finally, we could mention the fact that a new Jenkins-builder script is 
available in the repository at

trunk/Documents/Editing/Jenkins/jenkins_builder_script_2012.sh

and encourage people to try it out.

(I'm thinking of creating a variant of this script for desktops, with a 
set of instructions for building the TEI products on your own machine 
should you wish to.)

Cheers,
Martin

On 12-06-16 03:09 PM, Lou Burnard wrote:
> I've stopped tweaking them now.
>
> Plain text version, for distribution, follows:
>
>
> TEI P5 version 2.1.0 release notes
>
>     This is a maintenance release of the P5 Guidelines, which does
> however introduce some changes in existing content models.
>     The majority of these changes and corrections are a consequence of
> feature requests or bugs reported by the TEI community, using the
> Sourceforge tracking system. The Council has also launched an initiative
> to make some systematic improvements in the prose of the Guidelines,
> notably in normalising some spelling and punctuation variations.
>     Since the last release (14 February 2012), the Council has considered
> and disposed of 70 tickets entered in the sourceforge tracking system,
> from 15 different members of the TEI community. Full details may be
> found at http://tei.sf.net : an active list sorted by ticket number is
> available at the url http://bit.ly/N2P9Q2 and ticket numbers are also
> referenced in the subversion ChangeLog, as usual.
>
> 1  Schema Changes
>
>     These changes should not affect existing documents, but do result in
> changes to the generated schemas.
>     1  The content models of <availability> , <encodingDesc> , <formula>
> , <idno> <postscript> , <spGrp> , <surface> , and <table> have been
> modified to remove some inappropriate restrictions (3449887, 1650195,
> 3437782, 3441658, 3305016)
>     2  Additional schematron constraints have been implemented for
> several elements, notably for <attDef> , <delSpan> and other members of
> the att.spanning class.
>     3  A new class att.datcat has been introduced to permit the use of
> ISO Standard Data Category Registry values where appropriate (3432520)
>     4  The attribute version has been renamed versionDate to clarify its
> function (3393781)
>     5  A new class att.witnessed was introduced to ensure that only
> appropriate elements carry the wit attribute (3496951)
>     6  A new attribute targetLang was added to the att.pointing class to
> specify the language of the content of an element being pointed to
> (3288293)
>
> 2  Textual Changes
>
>     A large number of minor enhancements of various kinds were
> implementing, ranging from correction of typos and normalisation of
> punctuation, to rewording of phrases considered needlessly obscure. In
> addition, a number of systematic checks and enhancements were carried out :
>    * explicit usage examples are being added for all attributes
> specified, to complement those already provided for all elements;
>    * several passages reported as misleading or ambiguous in sourceforge
> tickets were reworded or clarified;
>    * some cosmetic changes were made to the formatting of the PDF and
> HTML versions of the Guidelines, notably to ensure that only open source
> fonts are used throughout;
>    * a large number of typos were corrected, many of them reported by a
> few careful proofreaders from the TEI Community (particular thanks this
> time to Jens ?stergaard Petersen and to Pablo Rodriguez who between them
> reported over 30 errors!)
>
> 3  Environmental Changes
>
>     The production of new releases of TEI P5 is now almost entirely
> automated, with all modifications continuously tested using a pair of
> Jenkins continuous integration servers. This has necessitated
> development and maintenance of a suite of scripts which have seen a
> large number of changes since the Council decided to ensure that a TEI
> P5 Release could be tested and delivered by any Council member. Full
> details of the current procedure for doing this are now provided in
> working document TCW20, which has been considerably enhanced during this
> period.
>


From James.Cummings at oucs.ox.ac.uk  Sun Jun 17 06:35:04 2012
From: James.Cummings at oucs.ox.ac.uk (James Cummings)
Date: Sun, 17 Jun 2012 11:35:04 +0100
Subject: [tei-council] next release?
In-Reply-To: <4FDB16D3.2080007@kcl.ac.uk>
References: <0F18A249-5480-42D9-BFF2-538AC7B9E1EB@oucs.ox.ac.uk>
	<4F92F34D.2040103@uvic.ca>	<4F9579A0.8010002@oucs.ox.ac.uk>
	<4F95C7A1.1080707@o2.pl>	<4F96756B.1060202@oucs.ox.ac.uk>
	<4F986673.7020201@kcl.ac.uk>	<4FB95846.7080308@oucs.ox.ac.uk>
	<4FDA15EC.5050700@oucs.ox.ac.uk> <4FDB16D3.2080007@kcl.ac.uk>
Message-ID: <4FDDB2D8.7090604@oucs.ox.ac.uk>



Just a reminder for everyone to finish off as many tickets as 
they can before tomorrow.

If you happen to check them off as done on 
http://wiki.tei-c.org/index.php/AnnArbor2012-Actions then that is 
good as well.

-James


On 15/06/12 12:04, Gabriel BODARD wrote:
> Dear fellow-Councillors,
>
> James and I have decided to delay today's release until this coming
> Monday, June 18, to allow a couple of last minute fixes to go in, and so
> that we're not left trying to repair things right before and/or over the
> weekend if anything goes wrong. (This will be release 2.1.0, codename:
> "Earhart's Crossing".)
>
> This means: (a) any tickets you've been meaning to close but not yet
> gotten around to, you now have the chance to do this weekend; (b) nobody
> should commit any changes to the TEI SVN from 09:00 GMT next Monday,
> until given the all clear by myself or James, hopefully later in the
> day. I'll send a further reminder to this effect on Monday morning.
>
> Best,
>
> Gabby
>
> On 14/06/2012 17:48, James Cummings wrote:
>>
>> A reminder to all that we're now coming up to our 15 June release
>> date.
>>
>> Get any changes in, soon, and mark them off:
>> http://wiki.tei-c.org/index.php/AnnArbor2012-Actions
>>
>> -James
>>
>> On 20/05/12 21:47, James Cummings wrote:
>>>
>>> Hi all,
>>>
>>> I think events have caught up with us and that May 25th deadline
>>> is looming.  I know I've barely chipped the surface of things
>>> assigned to me, and the meeting minutes are still coming (almost
>>> there I'm told).  I propose that we push back the next release
>>> until the week ending 15 June.  Does that seem unreasonable for
>>> anyone, or any counter proposals?
>>>
>>> -James
>>>
>>> On 25/04/12 22:02, Gabriel BODARD wrote:
>>>> The first week of June is likely to be bad for me; I'm back from
>>>> international travel around the 4th, I think, and will be groggy the
>>>> first couple days after that. So if not May 25th, then best to put it
>>>> off by two weeks. (Or someone else be launch technician...)
>>>>
>>>> G
>>>>
>>>> On 24/04/2012 10:42, James Cummings wrote:
>>>>>
>>>>> What do others think? We can of course move releasing back to
>>>>> whenever we've finished a majority of tickets, but I'd prefer
>>>>> sooner rather than later and a deadline that forces us to get
>>>>> stuff done.
>>>>>
>>>>> I'm of the opinion that we probably don't need to telco before
>>>>> this release (we can, after all, conduct business on the mailing
>>>>> list), but would do so shortly after the release to get updates
>>>>> on the longer-term issues and reports from the council working
>>>>> groups.
>>>>>
>>>>> thoughts?
>>>>>
>>>>> -James
>>>>>
>>>>>
>>>>> On 23/04/12 22:20, Piotr Ba?ski wrote:
>>>>>> Hi James,
>>>>>>
>>>>>> Isn't May 25 roughly in the middle of LREC? Could we shift by a week
>>>>>> from then, please?
>>>>>>
>>>>>> (I actually intend to be ready with my stuff [and possibly more] in
>>>>>> advance this time, but I've made some such totally honest promises to
>>>>>> myself and to the world recently, several times, and with meager results...)
>>>>>>
>>>>>> Ah. Will we telco before releasing?
>>>>>>
>>>>>> Best,
>>>>>>
>>>>>>         P.
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 23/04/12 17:47, James Cummings wrote:
>>>>>>>
>>>>>>> How about we set a notional target release date of 25 May?  (This
>>>>>>> is about 5 weeks from now.) If we assume that we want most things
>>>>>>> completed by the end of Sunday 20th, to allow time for
>>>>>>> proofreading and error spotting.
>>>>>>>
>>>>>>> Does that sounds reasonable to most people?
>>>>>>>
>>>>>>> Gaby: Most importantly, does the proposed Release Technician like
>>>>>>> these dates?
>>>>>>>
>>>>>>> -James
>>>>>>>
>>>>>>>
>>>>>>> On 21/04/12 18:50, Martin Holmes wrote:
>>>>>>>> Three weeks will be a bit tough for me, and a couple of the tickets I
>>>>>>>> have might turn out to have unpredicted side-effects (like the tei_
>>>>>>>> prefix). As long as we have the option to launch without the change if
>>>>>>>> it proves difficult, we could go with three weeks.
>>>>>>>>
>>>>>>>> The attributes-without-examples problem is so large that we'll just have
>>>>>>>> to hack away at it steadily.
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>> Martin
>>>>>>>>
>>>>>>>> On 12-04-21 04:03 AM, Sebastian Rahtz wrote:
>>>>>>>>> something we forgot to debate in Ann Arbor was a timetable
>>>>>>>>> for the next release, I think? i.e. what is the due date for
>>>>>>>>> everyone to complete their ticket work so that Sir Gabriel
>>>>>>>>> of B'odard can undertake his Quest.
>>>>>>>>>
>>>>>>>>> speaking for myself, if I don't do my assignments
>>>>>>>>> more or less immediately I will not get to them for ages,
>>>>>>>>> so I favour a short window (say, 3 weeks).
>>>>>>>>>
>>>>>>>>> Sebastian
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>>
>


-- 
Dr James Cummings, InfoDev
Oxford University Computing Services
University of Oxford

From lou.burnard at retired.ox.ac.uk  Sun Jun 17 10:12:53 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Sun, 17 Jun 2012 15:12:53 +0100
Subject: [tei-council] next release?
In-Reply-To: <4FDDB2D8.7090604@oucs.ox.ac.uk>
References: <0F18A249-5480-42D9-BFF2-538AC7B9E1EB@oucs.ox.ac.uk>
	<4F92F34D.2040103@uvic.ca>	<4F9579A0.8010002@oucs.ox.ac.uk>
	<4F95C7A1.1080707@o2.pl>	<4F96756B.1060202@oucs.ox.ac.uk>
	<4F986673.7020201@kcl.ac.uk>	<4FB95846.7080308@oucs.ox.ac.uk>
	<4FDA15EC.5050700@oucs.ox.ac.uk> <4FDB16D3.2080007@kcl.ac.uk>
	<4FDDB2D8.7090604@oucs.ox.ac.uk>
Message-ID: <4FDDE5E5.9000000@retired.ox.ac.uk>

On 17/06/12 11:35, James Cummings wrote:
>
>
> Just a reminder for everyone to finish off as many tickets as
> they can before tomorrow.
>
> If you happen to check them off as done on
> http://wiki.tei-c.org/index.php/AnnArbor2012-Actions then that is
> good as well.
>


I just took a look at the SF trackers, and noticed that although 70 
tickets have been closed since the last release, there are over 100 
still open. Of course, many of those are either new, or so old they 
might as well be, but quite a few look like ones that are just waiting 
for a little kick from someone....

Go on, you know you want to.





From lou.burnard at retired.ox.ac.uk  Sun Jun 17 14:33:55 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Sun, 17 Jun 2012 19:33:55 +0100
Subject: [tei-council] state of play
Message-ID: <4FDE2313.3080105@retired.ox.ac.uk>

I must say, I was a bit depressed when I found there were over 100 open 
tickets this morning. I spent the afternoon tidying up some of them, and 
the total is now below a hundred, but not much (91 to be exact).

As I said before, some of these are new, though not that many. What's a 
bit more worrying is the relatively high number to which no-one has been 
assigned. Just to reinforce the point, visit http://bit.ly/NI7yTq and 
you will see them listed sorted by assignee.

Maybe we should have a blitz on ticket *assignment*  -- maybe our 
beloved Chair could just allocate them to people rather than wait for 
volunteers? This doesn't have  to be done for the imminent release 
(obviously too late now) but would give people a bit more time to think 
about the tickets before the next FTF.


From sebastian.rahtz at oucs.ox.ac.uk  Sun Jun 17 14:49:17 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Sun, 17 Jun 2012 18:49:17 +0000
Subject: [tei-council] state of play
In-Reply-To: <4FDE2313.3080105@retired.ox.ac.uk>
References: <4FDE2313.3080105@retired.ox.ac.uk>
Message-ID: <84dd6acc-2a7e-4d5d-8098-09d3f79109fe@HUB05.ad.oak.ox.ac.uk>


On 17 Jun 2012, at 19:33, Lou Burnard wrote:

> What's a 
> bit more worrying is the relatively high number to which no-one has been 
> assigned. 

unless we have a round-robin system, on what basis
can they be semi-automatically assigned? I agree its
depressing how many we don't seem to look at. 

I just did a little trawl and killed half a dozen.

I note some categories of stayer-around:

   - Kevin's corrections to Tite
   - Roma bug reports
   - vague "rewrite the whole chapter" requests

which are understandably still open.
--
Sebastian Rahtz      
Head of Information and Support Group
Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431







From mholmes at uvic.ca  Sun Jun 17 15:25:20 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Sun, 17 Jun 2012 12:25:20 -0700
Subject: [tei-council] state of play
In-Reply-To: <84dd6acc-2a7e-4d5d-8098-09d3f79109fe@HUB05.ad.oak.ox.ac.uk>
References: <4FDE2313.3080105@retired.ox.ac.uk>
	<84dd6acc-2a7e-4d5d-8098-09d3f79109fe@HUB05.ad.oak.ox.ac.uk>
Message-ID: <4FDE2F20.7040309@uvic.ca>

I've also left open some tickets assigned to me that are mostly 
completed, to remind me to do some follow-up task, such as writing a 
section in the "How to Edit the Guidelines" document.

The problem with some semi-automated system of ticket assignment would 
be that most of us would end up getting tickets that are outside are 
areas of competence; I think that would lead to even more tickets being 
neglected in the long run. At least if you volunteer to take a ticket, 
you're doing so because you understand it fully, or because you feel it 
will be valuable for you to do the necessary background work to get to 
that point.

How about this: once every couple of weeks, James goes through the 
unassigned tickets and makes a determined effort to get someone to take 
each one on. That would also mean that when we get to the ftf, every 
ticket would have one person who's at least looked at it or done some 
work on it.

Cheers,
Martin

On 12-06-17 11:49 AM, Sebastian Rahtz wrote:
>
> On 17 Jun 2012, at 19:33, Lou Burnard wrote:
>
>> What's a
>> bit more worrying is the relatively high number to which no-one has been
>> assigned.
>
> unless we have a round-robin system, on what basis
> can they be semi-automatically assigned? I agree its
> depressing how many we don't seem to look at.
>
> I just did a little trawl and killed half a dozen.
>
> I note some categories of stayer-around:
>
>     - Kevin's corrections to Tite
>     - Roma bug reports
>     - vague "rewrite the whole chapter" requests
>
> which are understandably still open.
> --
> Sebastian Rahtz
> Head of Information and Support Group
> Oxford University Computing Services
> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>
>
>
>
>
>


From James.Cummings at oucs.ox.ac.uk  Sun Jun 17 16:10:19 2012
From: James.Cummings at oucs.ox.ac.uk (James Cummings)
Date: Sun, 17 Jun 2012 21:10:19 +0100
Subject: [tei-council] state of play
In-Reply-To: <4FDE2313.3080105@retired.ox.ac.uk>
References: <4FDE2313.3080105@retired.ox.ac.uk>
Message-ID: <4FDE39AB.80804@oucs.ox.ac.uk>


Very good idea.  Shortly after the release I'll go through and 
assign any unassigned tickets to people on council.  I'll try to 
do so based on who I think is best to deal with it.  If you think 
I've wrongly assigned you one, post here, or feel free to trade 
with another council member (commenting on ticket).

-James


On 17/06/12 19:33, Lou Burnard wrote:
> I must say, I was a bit depressed when I found there were over 100 open
> tickets this morning. I spent the afternoon tidying up some of them, and
> the total is now below a hundred, but not much (91 to be exact).
>
> As I said before, some of these are new, though not that many. What's a
> bit more worrying is the relatively high number to which no-one has been
> assigned. Just to reinforce the point, visit http://bit.ly/NI7yTq and
> you will see them listed sorted by assignee.
>
> Maybe we should have a blitz on ticket *assignment*  -- maybe our
> beloved Chair could just allocate them to people rather than wait for
> volunteers? This doesn't have  to be done for the imminent release
> (obviously too late now) but would give people a bit more time to think
> about the tickets before the next FTF.
>


-- 
Dr James Cummings, InfoDev,
Computing Services, University of Oxford

From bansp at o2.pl  Mon Jun 18 04:53:32 2012
From: bansp at o2.pl (=?UTF-8?B?UGlvdHIgQmHFhHNraQ==?=)
Date: Mon, 18 Jun 2012 10:53:32 +0200
Subject: [tei-council] BIB issues
Message-ID: <4FDEEC8C.4050506@o2.pl>

Hi all,

I'm afraid to touch the Guidelines right now, but I confess I did
something a bit ugly when citing the ISO DCR reference. In the text of
DI, I did:

...
which is a Web implementation of <ptr type="cit" target="#ISO-12620"/>
...

------------------------------------
in the BIB, I did:

<biblStruct xml:id="ISO-12620">
<monogr>
<author>International Organization for Standardization</author>
<title>ISO 12620:2009: Terminology and other language and content
resources ?
Specification of data categories and management of a Data Category Registry
for language resources</title>
<imprint>
<date>2009</date>
</imprint>
</monogr>
</biblStruct>


-----------------------------------
What gets displayed is:

"which is a Web implementation of International Organization for
Standardization (2009)."


And my question is: how can I make the Guidelines display either the
<title> from within the biblStruct, or maybe even display just "ISO
12620:2009" as a link to the full reference? I'm thinking of
experimenting with <ref> for the latter, but as I said, I don't know if
I can touch the Guidelines right now.

Is the @type for <ptr> here of any use? I.e., would I gain anything by
changing it to some other value than "cit"? And finally, do excuse my
ignorance and poor memory: do we have a guide to citing bibliographic
references in the Guidelines that I have overlooked, or is that still a
"todo" item?

Thanks!

  P.

From gabriel.bodard at kcl.ac.uk  Mon Jun 18 05:06:16 2012
From: gabriel.bodard at kcl.ac.uk (Gabriel BODARD)
Date: Mon, 18 Jun 2012 10:06:16 +0100
Subject: [tei-council] next release?
In-Reply-To: <4FDDE5E5.9000000@retired.ox.ac.uk>
References: <0F18A249-5480-42D9-BFF2-538AC7B9E1EB@oucs.ox.ac.uk>
	<4F92F34D.2040103@uvic.ca>	<4F9579A0.8010002@oucs.ox.ac.uk>
	<4F95C7A1.1080707@o2.pl>	<4F96756B.1060202@oucs.ox.ac.uk>
	<4F986673.7020201@kcl.ac.uk>	<4FB95846.7080308@oucs.ox.ac.uk>
	<4FDA15EC.5050700@oucs.ox.ac.uk> <4FDB16D3.2080007@kcl.ac.uk>
	<4FDDB2D8.7090604@oucs.ox.ac.uk>
	<4FDDE5E5.9000000@retired.ox.ac.uk>
Message-ID: <4FDEEF88.3020503@kcl.ac.uk>

Okay, I'm going in. Nobody's touched SVN for a while, right?

G

On 17/06/2012 15:12, Lou Burnard wrote:
> On 17/06/12 11:35, James Cummings wrote:
>>
>>
>> Just a reminder for everyone to finish off as many tickets as
>> they can before tomorrow.
>>
>> If you happen to check them off as done on
>> http://wiki.tei-c.org/index.php/AnnArbor2012-Actions then that is
>> good as well.
>>
>
>
> I just took a look at the SF trackers, and noticed that although 70
> tickets have been closed since the last release, there are over 100
> still open. Of course, many of those are either new, or so old they
> might as well be, but quite a few look like ones that are just waiting
> for a little kick from someone....
>
> Go on, you know you want to.
>
>
>
>

-- 
Dr Gabriel BODARD
(Research Associate in Digital Epigraphy)

Department of Digital Humanities
King's College London
26-29 Drury Lane
London WC2B 5RL

Email: gabriel.bodard at kcl.ac.uk
Tel: +44 (0)20 7848 1388
Fax: +44 (0)20 7848 2980

http://www.digitalclassicist.org/
http://www.currentepigraphy.org/

From lou.burnard at retired.ox.ac.uk  Mon Jun 18 05:10:58 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Mon, 18 Jun 2012 10:10:58 +0100
Subject: [tei-council] next release?
In-Reply-To: <4FDEEF88.3020503@kcl.ac.uk>
References: <0F18A249-5480-42D9-BFF2-538AC7B9E1EB@oucs.ox.ac.uk>
	<4F92F34D.2040103@uvic.ca>	<4F9579A0.8010002@oucs.ox.ac.uk>
	<4F95C7A1.1080707@o2.pl>	<4F96756B.1060202@oucs.ox.ac.uk>
	<4F986673.7020201@kcl.ac.uk>	<4FB95846.7080308@oucs.ox.ac.uk>
	<4FDA15EC.5050700@oucs.ox.ac.uk> <4FDB16D3.2080007@kcl.ac.uk>
	<4FDDB2D8.7090604@oucs.ox.ac.uk>
	<4FDDE5E5.9000000@retired.ox.ac.uk> <4FDEEF88.3020503@kcl.ac.uk>
Message-ID: <4FDEF0A2.1020400@retired.ox.ac.uk>

Last changes were Piotr's for version 10531

I dont intend to do anything more for the next few hours -- it's 
breakfast time

On 18/06/12 10:06, Gabriel BODARD wrote:
> Okay, I'm going in. Nobody's touched SVN for a while, right?
>
> G
>
> On 17/06/2012 15:12, Lou Burnard wrote:
>> On 17/06/12 11:35, James Cummings wrote:
>>>
>>>
>>> Just a reminder for everyone to finish off as many tickets as
>>> they can before tomorrow.
>>>
>>> If you happen to check them off as done on
>>> http://wiki.tei-c.org/index.php/AnnArbor2012-Actions then that is
>>> good as well.
>>>
>>
>>
>> I just took a look at the SF trackers, and noticed that although 70
>> tickets have been closed since the last release, there are over 100
>> still open. Of course, many of those are either new, or so old they
>> might as well be, but quite a few look like ones that are just waiting
>> for a little kick from someone....
>>
>> Go on, you know you want to.
>>
>>
>>
>>
>


From syeates at gmail.com  Mon Jun 18 05:12:25 2012
From: syeates at gmail.com (stuart yeates)
Date: Mon, 18 Jun 2012 21:12:25 +1200
Subject: [tei-council] next release?
In-Reply-To: <4FDEF0A2.1020400@retired.ox.ac.uk>
References: <0F18A249-5480-42D9-BFF2-538AC7B9E1EB@oucs.ox.ac.uk>
	<4F92F34D.2040103@uvic.ca>	<4F9579A0.8010002@oucs.ox.ac.uk>
	<4F95C7A1.1080707@o2.pl>	<4F96756B.1060202@oucs.ox.ac.uk>
	<4F986673.7020201@kcl.ac.uk>	<4FB95846.7080308@oucs.ox.ac.uk>
	<4FDA15EC.5050700@oucs.ox.ac.uk> <4FDB16D3.2080007@kcl.ac.uk>
	<4FDDB2D8.7090604@oucs.ox.ac.uk>
	<4FDDE5E5.9000000@retired.ox.ac.uk> <4FDEEF88.3020503@kcl.ac.uk>
	<4FDEF0A2.1020400@retired.ox.ac.uk>
Message-ID: <4FDEF0F9.7020303@gmail.com>

I've got no more changes for this release.

cheers
stuart

On 18/06/12 21:10, Lou Burnard wrote:
> Last changes were Piotr's for version 10531
>
> I dont intend to do anything more for the next few hours -- it's
> breakfast time
>
> On 18/06/12 10:06, Gabriel BODARD wrote:
>> Okay, I'm going in. Nobody's touched SVN for a while, right?
>>
>> G
>>
>> On 17/06/2012 15:12, Lou Burnard wrote:
>>> On 17/06/12 11:35, James Cummings wrote:
>>>>
>>>>
>>>> Just a reminder for everyone to finish off as many tickets as
>>>> they can before tomorrow.
>>>>
>>>> If you happen to check them off as done on
>>>> http://wiki.tei-c.org/index.php/AnnArbor2012-Actions then that is
>>>> good as well.
>>>>
>>>
>>>
>>> I just took a look at the SF trackers, and noticed that although 70
>>> tickets have been closed since the last release, there are over 100
>>> still open. Of course, many of those are either new, or so old they
>>> might as well be, but quite a few look like ones that are just waiting
>>> for a little kick from someone....
>>>
>>> Go on, you know you want to.
>>>
>>>
>>>
>>>
>>
>


From bansp at o2.pl  Mon Jun 18 05:16:32 2012
From: bansp at o2.pl (=?ISO-8859-2?Q?Piotr_Ba=F1ski?=)
Date: Mon, 18 Jun 2012 11:16:32 +0200
Subject: [tei-council] next release?
In-Reply-To: <4FDEF0A2.1020400@retired.ox.ac.uk>
References: <0F18A249-5480-42D9-BFF2-538AC7B9E1EB@oucs.ox.ac.uk>
	<4F92F34D.2040103@uvic.ca>	<4F9579A0.8010002@oucs.ox.ac.uk>
	<4F95C7A1.1080707@o2.pl>	<4F96756B.1060202@oucs.ox.ac.uk>
	<4F986673.7020201@kcl.ac.uk>	<4FB95846.7080308@oucs.ox.ac.uk>
	<4FDA15EC.5050700@oucs.ox.ac.uk> <4FDB16D3.2080007@kcl.ac.uk>
	<4FDDB2D8.7090604@oucs.ox.ac.uk>
	<4FDDE5E5.9000000@retired.ox.ac.uk> <4FDEEF88.3020503@kcl.ac.uk>
	<4FDEF0A2.1020400@retired.ox.ac.uk>
Message-ID: <4FDEF1F0.7020906@o2.pl>

On 18/06/12 11:10, Lou Burnard wrote:
> Last changes were Piotr's for version 10531
> 
> I dont intend to do anything more for the next few hours -- it's 
> breakfast time

;-)

I'm unhappy about the BIB thing, but it's bearable, just ugly, so I'm
not touching the SVN for now.

  P.

From sebastian.rahtz at oucs.ox.ac.uk  Mon Jun 18 05:23:41 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Mon, 18 Jun 2012 09:23:41 +0000
Subject: [tei-council] BIB issues
In-Reply-To: <4FDEEC8C.4050506@o2.pl>
References: <4FDEEC8C.4050506@o2.pl>
Message-ID: <8CCDF931-87D7-43DE-8449-FB26212F3209@oucs.ox.ac.uk>


On 18 Jun 2012, at 09:53, Piotr Ba?ski wrote:

> Hi all,
> 
> I'm afraid to touch the Guidelines right now, but I confess I did
> something a bit ugly when citing the ISO DCR reference. In the text of
> DI, I did:
> 
> ...
> which is a Web implementation of <ptr type="cit" target="#ISO-12620"/>
> ...
> 
> ...
> What gets displayed is:
> 
> "which is a Web implementation of International Organization for
> Standardization (2009)."
> 
just what I'd expect, that a pointer to a bib returns "$author ($year)". Just use
a <ref> if you don't like that.

so either 
> which is a Web implementation of <ref type="cit" target="#ISO-12620">ISO 12620</ref>

or

> which is a Web implementation of  ISO 12620 (<ptr type="cit" target="#ISO-12620"/>)

--
Sebastian Rahtz      
Head of Information and Support Group
Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431

S?lo le pido a Dios
que el futuro no me sea indiferente


From gabriel.bodard at kcl.ac.uk  Mon Jun 18 05:30:10 2012
From: gabriel.bodard at kcl.ac.uk (Gabriel BODARD)
Date: Mon, 18 Jun 2012 10:30:10 +0100
Subject: [tei-council] next release?
In-Reply-To: <4FDEF1F0.7020906@o2.pl>
References: <0F18A249-5480-42D9-BFF2-538AC7B9E1EB@oucs.ox.ac.uk>
	<4F92F34D.2040103@uvic.ca>	<4F9579A0.8010002@oucs.ox.ac.uk>
	<4F95C7A1.1080707@o2.pl>	<4F96756B.1060202@oucs.ox.ac.uk>
	<4F986673.7020201@kcl.ac.uk>	<4FB95846.7080308@oucs.ox.ac.uk>
	<4FDA15EC.5050700@oucs.ox.ac.uk> <4FDB16D3.2080007@kcl.ac.uk>
	<4FDDB2D8.7090604@oucs.ox.ac.uk>	<4FDDE5E5.9000000@retired.ox.ac.uk>
	<4FDEEF88.3020503@kcl.ac.uk>	<4FDEF0A2.1020400@retired.ox.ac.uk>
	<4FDEF1F0.7020906@o2.pl>
Message-ID: <4FDEF522.5040601@kcl.ac.uk>

Just to be clear, I'm now preparing the Earhart's Crossing release 
(2.1.0), so if you plan to make any urgent SVN commits that need to go 
in today STOP ME NOW, or forever hold your peace. (At least until 
further notice.)

If anybody who knows this stuff intimately (especially Sebastian, Lou 
and Martin [although I know it's not much after midnight where he is]) 
want to join us on irc://freenode#tei-c for occasional troubleshooting, 
that would be most welcome.

G

On 18/06/2012 10:16, Piotr Ba?ski wrote:
> On 18/06/12 11:10, Lou Burnard wrote:
>> Last changes were Piotr's for version 10531
>>
>> I dont intend to do anything more for the next few hours -- it's
>> breakfast time
>
> ;-)
>
> I'm unhappy about the BIB thing, but it's bearable, just ugly, so I'm
> not touching the SVN for now.
>
>    P.

-- 
Dr Gabriel BODARD
(Research Associate in Digital Epigraphy)

Department of Digital Humanities
King's College London
26-29 Drury Lane
London WC2B 5RL

Email: gabriel.bodard at kcl.ac.uk
Tel: +44 (0)20 7848 1388
Fax: +44 (0)20 7848 2980

http://www.digitalclassicist.org/
http://www.currentepigraphy.org/

From sebastian.rahtz at oucs.ox.ac.uk  Mon Jun 18 06:36:57 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Mon, 18 Jun 2012 10:36:57 +0000
Subject: [tei-council] next release?
In-Reply-To: <4FDEF522.5040601@kcl.ac.uk>
References: <0F18A249-5480-42D9-BFF2-538AC7B9E1EB@oucs.ox.ac.uk>
	<4F92F34D.2040103@uvic.ca>	<4F9579A0.8010002@oucs.ox.ac.uk>
	<4F95C7A1.1080707@o2.pl>	<4F96756B.1060202@oucs.ox.ac.uk>
	<4F986673.7020201@kcl.ac.uk>	<4FB95846.7080308@oucs.ox.ac.uk>
	<4FDA15EC.5050700@oucs.ox.ac.uk> <4FDB16D3.2080007@kcl.ac.uk>
	<4FDDB2D8.7090604@oucs.ox.ac.uk>	<4FDDE5E5.9000000@retired.ox.ac.uk>
	<4FDEEF88.3020503@kcl.ac.uk>	<4FDEF0A2.1020400@retired.ox.ac.uk>
	<4FDEF1F0.7020906@o2.pl> <4FDEF522.5040601@kcl.ac.uk>
Message-ID: <80CC39FB-126F-4433-85A4-4BDFD76E1692@oucs.ox.ac.uk>


On 18 Jun 2012, at 10:30, Gabriel BODARD wrote:

> irc://freenode#tei-c

I am now there if you need help
--
Sebastian Rahtz      
Head of Information and Support Group
Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431

S?lo le pido a Dios
que el futuro no me sea indiferente


From rwelzenbach at gmail.com  Mon Jun 18 09:36:06 2012
From: rwelzenbach at gmail.com (Rebecca Welzenbach)
Date: Mon, 18 Jun 2012 09:36:06 -0400
Subject: [tei-council] Oxford Face2Face meeting: Accommodation
In-Reply-To: <4FDB71F2.7060200@uvic.ca>
References: <4FDB47A0.2060601@oucs.ox.ac.uk> <4FDB6025.9070909@uvic.ca>
	<sha1t5s9d26gcwpiot46d2xi.1339778207132@email.android.com>
	<4FDB71F2.7060200@uvic.ca>
Message-ID: <CAA2irtLQ_YBq+VDOf6MusYRUrdtVNCnChYyNc=62t+F=FSLupg@mail.gmail.com>

As Wednesday was in Ann Arbor, will Friday, Sept. 21, be a half
day/flex day depending on travel plans? (Whether I need accommodation
Friday night depends on whether I can make a 6 p.m. flight from
Heathrow on Friday. Hmm. That also requires spending 20 hours in
Toronto).

Becky

On Fri, Jun 15, 2012 at 1:33 PM, Martin Holmes <mholmes at uvic.ca> wrote:
> I've put four in, but I am happy to pay for the fourth if I need it.
>
> Cheers,
> Martin
>
> On 12-06-15 09:37 AM, James Cummings wrote:
>>
>> The budget is for 3 nights, but it depends on others arrangements and where these may save us money. ?We can probably stretch to four nights, especially if it results in a cheaper air fare (e.g. for including a Saturday). ?That is why I want everyone to fill in the poll, even if it is to indicate the TEI-C isn't paying anything to their accommodation. So put down what you need and we'll see what we can do. ;-)
>>
>> Jamesc
>> --
>> James Cummings, InfoDev, OUCS, University of Oxford (from phone)
>>
>> Martin Holmes<mholmes at uvic.ca> ?wrote:
>>
>>
>> I noticed the restriction to three nights, but that might be difficult
>> given the flights from over here. If I have to stay a fourth, at my
>> expense, can it be booked as part of the same block, or will I have to
>> make a separate booking?
>>
>> Cheers,
>> Martin
>>
>> On 12-06-15 07:33 AM, James Cummings wrote:
>>>
>>> As you will all know the next face 2 face meeting is scheduled
>>> for 19-21 September 2012. In order to see if I can get
>>> accommodation for this all in one place (as Becky did in Ann
>>> Arbor), it would be good if you could indicate what nights you
>>> will need accommodation (at the expense of the TEI-C). ?If you
>>> are doing something else or have weird needs, please email me.
>>>
>>> Otherwise, please fill out this poll:
>>> http://www.doodle.com/6n2uqbfq2wq6itdc
>>>
>>> -James
>>>
>>
>> --
>> Martin Holmes
>> University of Victoria Humanities Computing and Media Centre
>> (mholmes at uvic.ca)
>> .
>>
>
> --
> Martin Holmes
> University of Victoria Humanities Computing and Media Centre
> (mholmes at uvic.ca)
> --
> tei-council mailing list
> tei-council at lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>
> PLEASE NOTE: postings to this list are publicly archived

From James.Cummings at oucs.ox.ac.uk  Mon Jun 18 10:13:37 2012
From: James.Cummings at oucs.ox.ac.uk (James Cummings)
Date: Mon, 18 Jun 2012 15:13:37 +0100
Subject: [tei-council] Oxford Face2Face meeting: Accommodation
In-Reply-To: <CAA2irtLQ_YBq+VDOf6MusYRUrdtVNCnChYyNc=62t+F=FSLupg@mail.gmail.com>
References: <4FDB47A0.2060601@oucs.ox.ac.uk> <4FDB6025.9070909@uvic.ca>
	<sha1t5s9d26gcwpiot46d2xi.1339778207132@email.android.com>
	<4FDB71F2.7060200@uvic.ca>
	<CAA2irtLQ_YBq+VDOf6MusYRUrdtVNCnChYyNc=62t+F=FSLupg@mail.gmail.com>
Message-ID: <4FDF3791.30904@oucs.ox.ac.uk>


That is the intention. Weds/Thurs full days, Friday 1/2 day 
officially and for those staying Friday an unofficial hack-a-thon 
on actions and tickets, etc.

Do check whether there is a much cheaper flight on Saturday.  If 
the flight is cheaper than spending the Friday night, and you've 
not got Saturday plans to rush back to, then that is always an 
option. ;-)

-James

On 18/06/12 14:36, Rebecca Welzenbach wrote:
> As Wednesday was in Ann Arbor, will Friday, Sept. 21, be a half
> day/flex day depending on travel plans? (Whether I need accommodation
> Friday night depends on whether I can make a 6 p.m. flight from
> Heathrow on Friday. Hmm. That also requires spending 20 hours in
> Toronto).
>
> Becky
>
> On Fri, Jun 15, 2012 at 1:33 PM, Martin Holmes<mholmes at uvic.ca>  wrote:
>> I've put four in, but I am happy to pay for the fourth if I need it.
>>
>> Cheers,
>> Martin
>>
>> On 12-06-15 09:37 AM, James Cummings wrote:
>>>
>>> The budget is for 3 nights, but it depends on others arrangements and where these may save us money.  We can probably stretch to four nights, especially if it results in a cheaper air fare (e.g. for including a Saturday).  That is why I want everyone to fill in the poll, even if it is to indicate the TEI-C isn't paying anything to their accommodation. So put down what you need and we'll see what we can do. ;-)
>>>
>>> Jamesc
>>> --
>>> James Cummings, InfoDev, OUCS, University of Oxford (from phone)
>>>
>>> Martin Holmes<mholmes at uvic.ca>    wrote:
>>>
>>>
>>> I noticed the restriction to three nights, but that might be difficult
>>> given the flights from over here. If I have to stay a fourth, at my
>>> expense, can it be booked as part of the same block, or will I have to
>>> make a separate booking?
>>>
>>> Cheers,
>>> Martin
>>>
>>> On 12-06-15 07:33 AM, James Cummings wrote:
>>>>
>>>> As you will all know the next face 2 face meeting is scheduled
>>>> for 19-21 September 2012. In order to see if I can get
>>>> accommodation for this all in one place (as Becky did in Ann
>>>> Arbor), it would be good if you could indicate what nights you
>>>> will need accommodation (at the expense of the TEI-C).  If you
>>>> are doing something else or have weird needs, please email me.
>>>>
>>>> Otherwise, please fill out this poll:
>>>> http://www.doodle.com/6n2uqbfq2wq6itdc
>>>>
>>>> -James
>>>>
>>>
>>> --
>>> Martin Holmes
>>> University of Victoria Humanities Computing and Media Centre
>>> (mholmes at uvic.ca)
>>> .
>>>
>>
>> --
>> Martin Holmes
>> University of Victoria Humanities Computing and Media Centre
>> (mholmes at uvic.ca)
>> --
>> tei-council mailing list
>> tei-council at lists.village.Virginia.EDU
>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>>
>> PLEASE NOTE: postings to this list are publicly archived


-- 
Dr James Cummings, InfoDev,
Computing Services, University of Oxford

From gabriel.bodard at kcl.ac.uk  Mon Jun 18 13:34:58 2012
From: gabriel.bodard at kcl.ac.uk (Gabriel BODARD)
Date: Mon, 18 Jun 2012 18:34:58 +0100
Subject: [tei-council] Release notes (was Re:  next release?)
In-Reply-To: <4FDEF522.5040601@kcl.ac.uk>
References: <0F18A249-5480-42D9-BFF2-538AC7B9E1EB@oucs.ox.ac.uk>
	<4F92F34D.2040103@uvic.ca>	<4F9579A0.8010002@oucs.ox.ac.uk>
	<4F95C7A1.1080707@o2.pl>	<4F96756B.1060202@oucs.ox.ac.uk>
	<4F986673.7020201@kcl.ac.uk>	<4FB95846.7080308@oucs.ox.ac.uk>
	<4FDA15EC.5050700@oucs.ox.ac.uk> <4FDB16D3.2080007@kcl.ac.uk>
	<4FDDB2D8.7090604@oucs.ox.ac.uk>	<4FDDE5E5.9000000@retired.ox.ac.uk>
	<4FDEEF88.3020503@kcl.ac.uk>	<4FDEF0A2.1020400@retired.ox.ac.uk>
	<4FDEF1F0.7020906@o2.pl> <4FDEF522.5040601@kcl.ac.uk>
Message-ID: <4FDF66C2.5070307@kcl.ac.uk>

Dear fellow-councillors,

The "Earhart's Crossing" release (TEI P5 2.1.0) is complete. You may now 
edit and commit to svn to your heart's content. I've made notes as I 
went through the step-by-step in tcw22, including just a couple of 
suggestions for improvement. On the whole it was pretty easy to follow, 
even for a tech-less boy like me.

1. Release notes: I assumed that this was all done by Lou (although I 
did add the SVN header and set svn:keywords property.

2. Version numbers updated. (I had to stop and think for a moment 
whether I was supposed to be updated the -fr version as well. Obviously 
yes, but just to note that with current wording I wondered.)

3. Version number updated. Clear.

4. Debian changelogs: the changelog files don't exist where they are 
listed in the sbs. I now understand that this is automated in Jenkins... 
so this point should be deleted from the doc.

5. Freeze announced. (I mentioned that already, right? :-) )

6. Committed. Waiting to see what happens.

<!-- couple hours later -->

7. This all seems okay to me, but I think the item in the doc could be 
spelled out a bit more explicitly what to look for.

8. Apparent problem with instructions in this item:

svnUp.sh runs as written, but
tei-install.sh needs the "sh" command before it. (Does this mean it is 
not executable?) Either that needs to be changed, or the instructions. 
(Note: James has already fixed the file so it is executable by user.)

Might not be a bad idea to make it possible to select one Jenkins server 
or the other with a parameter, rather than having to go in and edit the 
script.

Also: Sourceforge denied me permission to make the release at this step. 
We need to add a note that the user needs to add the public key from 
/home/tei/.ssh/id_dsa to their Sourceforge account before they can rsync 
the release zip. This probably belongs in the "What you need" section at 
the top of tcw22.

9. Database rebuild: seems painless

10. Defaults set. Fine. (Instructions could be clearer--I've done this 
before for other projects, but if not I might not have known where to look.)

11. SVN tags updated. That's easy. (Even using TortoiseSVN, fwiw)

12. Sebastian informed that debian can be released.

13. Sebastian informed that oxygen-tei can be updated.

14. Checking TEI website and downloads. (I wonder we shouldn't do this 
check before the previous two, and maybe before 10 as well. If there's a 
problem with the website we may have to start again.)

15. James informed, and will announce to TEI-L presently.

16. Unfreeze svn: that's what this email is doing.

17. Sebastian informed that stylesheet tests need updating.


-- 
Dr Gabriel BODARD
(Research Associate in Digital Epigraphy)

Department of Digital Humanities
King's College London
26-29 Drury Lane
London WC2B 5RL

Email: gabriel.bodard at kcl.ac.uk
Tel: +44 (0)20 7848 1388
Fax: +44 (0)20 7848 2980

http://www.digitalclassicist.org/
http://www.currentepigraphy.org/

From James.Cummings at oucs.ox.ac.uk  Mon Jun 18 14:09:23 2012
From: James.Cummings at oucs.ox.ac.uk (James Cummings)
Date: Mon, 18 Jun 2012 19:09:23 +0100
Subject: [tei-council] Next Release Technician?
Message-ID: <4FDF6ED3.6070207@oucs.ox.ac.uk>

Hi there,

This is a call for a volunteer to be the release technician for 
the next significant release.  Assuming there are no major bugs 
found in the current release that mean a quick maintenance 
release is needed, I propose that the next release be in mid-late 
October.

This is close to two important dates:

1) The November TEI Conference and Members' Meeting which 
traditionally has seen a release shortly before.

2) The cessation of guaranteed support for TEI P4. (5 years since 
the release of TEI P5 1.0.0)

In order to improve the release process even more, is there 
someone *who has not made a release already* who would like to be 
the release technician for this upcoming release? You'll have to 
be able to set aside a day to do this (in case there are minor 
hiccups), and we'll have to get you comfortable with the steps in 
tcw22.

-James

-- 
Dr James Cummings, InfoDev,
Computing Services, University of Oxford

From bansp at o2.pl  Mon Jun 18 15:29:35 2012
From: bansp at o2.pl (=?ISO-8859-2?Q?Piotr_Ba=F1ski?=)
Date: Mon, 18 Jun 2012 21:29:35 +0200
Subject: [tei-council] Next Release Technician?
In-Reply-To: <4FDF6ED3.6070207@oucs.ox.ac.uk>
References: <4FDF6ED3.6070207@oucs.ox.ac.uk>
Message-ID: <4FDF819F.8000806@o2.pl>

I guess I could do that. Sounds like an interesting challenge that would
make me focus a bit on the low-level technicalities.

Best,

  P.

On 18/06/12 20:09, James Cummings wrote:
> Hi there,
> 
> This is a call for a volunteer to be the release technician for 
> the next significant release.  Assuming there are no major bugs 
> found in the current release that mean a quick maintenance 
> release is needed, I propose that the next release be in mid-late 
> October.
> 
> This is close to two important dates:
> 
> 1) The November TEI Conference and Members' Meeting which 
> traditionally has seen a release shortly before.
> 
> 2) The cessation of guaranteed support for TEI P4. (5 years since 
> the release of TEI P5 1.0.0)
> 
> In order to improve the release process even more, is there 
> someone *who has not made a release already* who would like to be 
> the release technician for this upcoming release? You'll have to 
> be able to set aside a day to do this (in case there are minor 
> hiccups), and we'll have to get you comfortable with the steps in 
> tcw22.
> 
> -James
> 


From sebastian.rahtz at oucs.ox.ac.uk  Mon Jun 18 15:54:14 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Mon, 18 Jun 2012 19:54:14 +0000
Subject: [tei-council] updating oxygen-tei
Message-ID: <88006B2C-D88A-4B0C-9A42-9B24301BE6AF@oucs.ox.ac.uk>

for the record, this is a shell script I used to update the oxygen TEI setup. having checked out
http://code.google.com/p/oxygen-tei/. It is stored there as update-and-upload.sh

it would be helpful if others had a brief look and checked that this is meaningful.

JENKINS=http://tei.oucs.ox.ac.uk/jenkins
TEIVERSION=2.1.0
XSLVERSION=6.12
curl -o tei.zip $JENKINS/job/TEIP5/lastSuccessfulBuild/artifact/tei-$TEIVERSION.zip
curl -o xsl.zip $JENKINS/job/Stylesheets/lastSuccessfulBuild/artifact/tei-xsl-$XSLVERSION.zip
cd frameworks/tei
rm -rf xml/tei/stylesheet
rm -rf xml/tei/odd
rm -rf xml/tei/schema
rm -rf xml/tei/custom/schema
rm -rf xml/tei/custom/odd
rm -rf xml/tei/Test 
rm -rf xml/tei/xquery
unzip -o -q ../../tei.zip
unzip -o -q ../../xsl.zip
rm -rf doc
cd ../..
rm tei.zip xsl.zip
ant
mv dist/tei.zip tei-$TEIVERSION.zip
python googlecode_upload.py -u sebastian.rahtz at gmail.com -s "TEI release $TEIVERSION and XSL $XSLVERSION" -p oxygen-tei tei-$TEIVERSION.zip 
--
Sebastian Rahtz      
Head of Information and Support Group
Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431







From sebastian.rahtz at oucs.ox.ac.uk  Mon Jun 18 16:11:54 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Mon, 18 Jun 2012 20:11:54 +0000
Subject: [tei-council] updating oxygen-tei
In-Reply-To: <88006B2C-D88A-4B0C-9A42-9B24301BE6AF@oucs.ox.ac.uk>
References: <88006B2C-D88A-4B0C-9A42-9B24301BE6AF@oucs.ox.ac.uk>
Message-ID: <532C9330-5510-4DC5-8585-6B89E11460A7@oucs.ox.ac.uk>

can whoever is editing tcw22 add, in place of stage 13, the instruction:


> 
> Update the oXygen-ready distribution of TEI. If you have
write permission on the Google Code project, you can check out the source from
http://code.google.com/p/oxygen-tei/ and run the shell script
update-and-upload.sh. Otherwise, ask one of the maintainers to do
this for you.

by the way, whats the point of 
	./svnUp.sh (this updates the local copy of subversion)
in stage 8? the results are not used at all.
--
Sebastian Rahtz      
Head of Information and Support Group
Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431







From mholmes at uvic.ca  Mon Jun 18 17:16:40 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Mon, 18 Jun 2012 14:16:40 -0700
Subject: [tei-council] updating oxygen-tei
In-Reply-To: <88006B2C-D88A-4B0C-9A42-9B24301BE6AF@oucs.ox.ac.uk>
References: <88006B2C-D88A-4B0C-9A42-9B24301BE6AF@oucs.ox.ac.uk>
Message-ID: <4FDF9AB8.1090107@uvic.ca>

Looks good to me -- do you ssh to code.google.com to run it?

On 12-06-18 12:54 PM, Sebastian Rahtz wrote:
> for the record, this is a shell script I used to update the oxygen TEI setup. having checked out
> http://code.google.com/p/oxygen-tei/. It is stored there as update-and-upload.sh
>
> it would be helpful if others had a brief look and checked that this is meaningful.
>
> JENKINS=http://tei.oucs.ox.ac.uk/jenkins
> TEIVERSION=2.1.0
> XSLVERSION=6.12
> curl -o tei.zip $JENKINS/job/TEIP5/lastSuccessfulBuild/artifact/tei-$TEIVERSION.zip
> curl -o xsl.zip $JENKINS/job/Stylesheets/lastSuccessfulBuild/artifact/tei-xsl-$XSLVERSION.zip
> cd frameworks/tei
> rm -rf xml/tei/stylesheet
> rm -rf xml/tei/odd
> rm -rf xml/tei/schema
> rm -rf xml/tei/custom/schema
> rm -rf xml/tei/custom/odd
> rm -rf xml/tei/Test
> rm -rf xml/tei/xquery
> unzip -o -q ../../tei.zip
> unzip -o -q ../../xsl.zip
> rm -rf doc
> cd ../..
> rm tei.zip xsl.zip
> ant
> mv dist/tei.zip tei-$TEIVERSION.zip
> python googlecode_upload.py -u sebastian.rahtz at gmail.com -s "TEI release $TEIVERSION and XSL $XSLVERSION" -p oxygen-tei tei-$TEIVERSION.zip
> --
> Sebastian Rahtz
> Head of Information and Support Group
> Oxford University Computing Services
> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>
>
>
>
>
>


From mholmes at uvic.ca  Mon Jun 18 17:24:12 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Mon, 18 Jun 2012 14:24:12 -0700
Subject: [tei-council] updating oxygen-tei
In-Reply-To: <532C9330-5510-4DC5-8585-6B89E11460A7@oucs.ox.ac.uk>
References: <88006B2C-D88A-4B0C-9A42-9B24301BE6AF@oucs.ox.ac.uk>
	<532C9330-5510-4DC5-8585-6B89E11460A7@oucs.ox.ac.uk>
Message-ID: <4FDF9C7C.70902@uvic.ca>

Gabby said he would do the updates.

I don't know what svnUp.sh is for, unless the eXist db is populated from 
a local copy. Is it?

Cheers,
Martin

On 12-06-18 01:11 PM, Sebastian Rahtz wrote:
> can whoever is editing tcw22 add, in place of stage 13, the instruction:
>
>
>>
>> Update the oXygen-ready distribution of TEI. If you have
> write permission on the Google Code project, you can check out the source from
> http://code.google.com/p/oxygen-tei/ and run the shell script
> update-and-upload.sh. Otherwise, ask one of the maintainers to do
> this for you.
>
> by the way, whats the point of
> 	./svnUp.sh (this updates the local copy of subversion)
> in stage 8? the results are not used at all.
> --
> Sebastian Rahtz
> Head of Information and Support Group
> Oxford University Computing Services
> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>
>
>
>
>
>


From sebastian.rahtz at oucs.ox.ac.uk  Mon Jun 18 17:40:35 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Mon, 18 Jun 2012 21:40:35 +0000
Subject: [tei-council] updating oxygen-tei
In-Reply-To: <4FDF9AB8.1090107@uvic.ca>
References: <88006B2C-D88A-4B0C-9A42-9B24301BE6AF@oucs.ox.ac.uk>
	<4FDF9AB8.1090107@uvic.ca>
Message-ID: <DD672DBF-DE77-4A6A-B807-692D1500FAC1@oucs.ox.ac.uk>


On 18 Jun 2012, at 22:16, Martin Holmes wrote:

> Looks good to me -- do you ssh to code.google.com to run it?
> 

no, locally. svn checkout the code base, then run the script
--
Sebastian Rahtz      
Head of Information and Support Group
Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431







From sebastian.rahtz at oucs.ox.ac.uk  Mon Jun 18 17:41:16 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Mon, 18 Jun 2012 21:41:16 +0000
Subject: [tei-council] updating oxygen-tei
In-Reply-To: <4FDF9C7C.70902@uvic.ca>
References: <88006B2C-D88A-4B0C-9A42-9B24301BE6AF@oucs.ox.ac.uk>
	<532C9330-5510-4DC5-8585-6B89E11460A7@oucs.ox.ac.uk>
	<4FDF9C7C.70902@uvic.ca>
Message-ID: <D011000F-44F3-4D64-AD5B-C0DFD95B6300@oucs.ox.ac.uk>


On 18 Jun 2012, at 22:24, Martin Holmes wrote:

> 
> I don't know what svnUp.sh is for, unless the eXist db is populated from a local copy. Is it?
> 
no, it comes from the version installed by the main script

--
Sebastian Rahtz      
Head of Information and Support Group
Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431







From James.Cummings at oucs.ox.ac.uk  Mon Jun 18 17:49:15 2012
From: James.Cummings at oucs.ox.ac.uk (James Cummings)
Date: Mon, 18 Jun 2012 22:49:15 +0100
Subject: [tei-council] updating oxygen-tei
In-Reply-To: <D011000F-44F3-4D64-AD5B-C0DFD95B6300@oucs.ox.ac.uk>
References: <88006B2C-D88A-4B0C-9A42-9B24301BE6AF@oucs.ox.ac.uk>
	<532C9330-5510-4DC5-8585-6B89E11460A7@oucs.ox.ac.uk>
	<4FDF9C7C.70902@uvic.ca>
	<D011000F-44F3-4D64-AD5B-C0DFD95B6300@oucs.ox.ac.uk>
Message-ID: <4FDFA25B.3030405@oucs.ox.ac.uk>

On 18/06/12 22:41, Sebastian Rahtz wrote:
>
> On 18 Jun 2012, at 22:24, Martin Holmes wrote:
>
>>
>> I don't know what svnUp.sh is for, unless the eXist db is populated from a local copy. Is it?
>>
> no, it comes from the version installed by the main script

svnUp.sh updates the local copy of the subversion repository 
because the scripts in /home/tei/bin/ that the release technician 
is using are *in* subversion.  You should *not* be editing these 
scripts locally on tei-c.org instead, edit them and commit them 
to subversion.  Wherever possible there should be no special 
local magic files.

This message has been brought to you by the "Campaign to Reduce 
Apparent Magic and Processing Specifics".

-James

-- 
Dr James Cummings, InfoDev,
Computing Services, University of Oxford

From sebastian.rahtz at oucs.ox.ac.uk  Mon Jun 18 18:07:48 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Mon, 18 Jun 2012 22:07:48 +0000
Subject: [tei-council] updating oxygen-tei
In-Reply-To: <4FDFA25B.3030405@oucs.ox.ac.uk>
References: <88006B2C-D88A-4B0C-9A42-9B24301BE6AF@oucs.ox.ac.uk>
	<532C9330-5510-4DC5-8585-6B89E11460A7@oucs.ox.ac.uk>
	<4FDF9C7C.70902@uvic.ca>
	<D011000F-44F3-4D64-AD5B-C0DFD95B6300@oucs.ox.ac.uk>
	<4FDFA25B.3030405@oucs.ox.ac.uk>
Message-ID: <6749a4bc-17fe-462d-877f-bc9c400b49ad@HUB01.ad.oak.ox.ac.uk>


On 18 Jun 2012, at 22:49, James Cummings wrote:

> svnUp.sh updates the local copy of the subversion repository 
> because the scripts in /home/tei/bin/ that the release technician 
> is using are *in* subversion.

ah, that explains it, thanks

> This message has been brought to you by the "Campaign to Reduce 
> Apparent Magic and Processing Specifics".


I think we can honestly say that in the last 18 months we have
really made inroads with CRAMPS.  The battle is not over,
though. Only today I added a clause to odd2dtd.xsl which
said "if the body of the content model is the PI called 'NameList'
then generate the DTD model of ANY".  Not good.
--
Sebastian Rahtz      
Head of Information and Support Group
Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431







From mholmes at uvic.ca  Tue Jun 19 00:29:20 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Mon, 18 Jun 2012 21:29:20 -0700
Subject: [tei-council] Build failed in Jenkins: TEIP5-Documentation #411
In-Reply-To: <2006451446.3.1340070086486.JavaMail.jenkins@teijenkins>
References: <2006451446.3.1340070086486.JavaMail.jenkins@teijenkins>
Message-ID: <4FE00020.7080503@uvic.ca>

I put Lou's new readme profile into the Makefile, and the Documentation 
build broke.

This reveals that the readme part of the Documentation job, at least, 
not been using the XSL from the Stylesheets build:

 > ERROR: No support for profile readme: 
/usr/share/xml/tei/stylesheet/profiles/readme/html/to.xsl does not exist.

This is presumably because the script calls teitohtml, which doesn't 
know anything about the Jenkins job stylesheets at all; it defaults to 
APPHOME=/usr/share/xml/tei/stylesheet.

So the Makefile needs to pass the XSL dir into the teitohtml script 
which operates on the readmes. I've tried to implement that, and we'll 
see if it works.

I wonder if the teitohtml that gets called should be the one from SVN, 
rather than from the installed packages?

cheers,
Martin

On 12-06-18 06:41 PM, mholmes at uvic.ca wrote:
> See <http://teijenkins.hcmc.uvic.ca:8080/job/TEIP5-Documentation/411/changes>
>
> Changes:
>
> [martindholmes] Adding --profile=readme to the Makefile so that HTML readmes will be built with Lou's new profile.
>
> ------------------------------------------
> Started by upstream project "TEIP5-Test" build number 578
> Building in workspace <http://teijenkins.hcmc.uvic.ca:8080/job/TEIP5-Documentation/ws/>
> Updating https://tei.svn.sourceforge.net/svnroot/tei/trunk/P5
> U         Makefile
> At revision 10550
> [workspace] $ /bin/sh -xe /tmp/hudson980990287084911559.sh
> + pwd
> + make XSL=<http://teijenkins.hcmc.uvic.ca:8080/job/TEIP5-Documentation/ws/../../Stylesheets/lastSuccessful/archive/dist/xml/tei/stylesheet> clean dist-doc validate-html
> rm -rf release Guidelines Guidelines-web Schema DTD dtd Split RomaResults *~
> rm -rf Guidelines.??? Guidelines-* \
> 	p5odds-examples.rng  p5odds-examples.rnc \
> 	p5odds.rng p5odds.rnc \
> 	*.xsd \
> 	p5.sch p5.isosch \
> 	*.isosch.xsl \
> 	tei-*.zip \
> 	Test/*.isosch \
> 	p5subset.xml \
> 	Utilities/guidelines.xsl Utilities-1/guidelines.xsl
> find . -name "semantic.cache" | xargs rm -f
> (cd Test; make clean)
> make[1]: Entering directory `<http://teijenkins.hcmc.uvic.ca:8080/job/TEIP5-Documentation/ws/Test'>
> rm -f test*.doc.xml test*.rnc test*.dtd test*.compiled.* test*.teix.xsd test*.xsd test*.rnc test*.rng test*.xsl test*.isosch
> rm -rf LOG *~ *.xsd Schema RomaResults DTD
> rm -rf *.doc.*
> rm -f detest.log detest.log.all
> rm -f *-examples.rng *-examples.rnc *test*.nvdl *-ex.odd
> rm -f detest.rnc    detest.rng   detest.dtd   detest.isosch
> make[1]: Leaving directory `<http://teijenkins.hcmc.uvic.ca:8080/job/TEIP5-Documentation/ws/Test'>
> (cd Exemplars; make clean)
> make[1]: Entering directory `<http://teijenkins.hcmc.uvic.ca:8080/job/TEIP5-Documentation/ws/Exemplars'>
> rm -f *.xsd *.dtd *.doc.* *.rnc tei*.rng *.compiled.* *~ *.xi
> rm -f exnames.xml
> rm -f enrich.rng isofs.rng
> rm -f names.xml
> make[1]: Leaving directory `<http://teijenkins.hcmc.uvic.ca:8080/job/TEIP5-Documentation/ws/Exemplars'>
> rm -rf FASC-*
> rm -rf catalogue.* modList
> rm -f       p5.xml
> rm -f       Guidelines.epub
> rm -f       Guidelines.mobi
> rm -f       Test/detest.rnc
> rm -f       Test/detest.rng
> rm -f       Test/detest.dtd
> rm -rf valid v.xml
> rm -f v.body v.header missfont.log
> rm -f *.stamp
> rm -f tei-p5-*_*deb
> rm -f tei-p5-*_*changes
> rm -f tei-p5-*_*build
> rm -f teiwebsiteguidelines.zip
> BUILD: Make distribution directory for doc
> rm -rf release/tei-p5-doc*
> mkdir -p release/tei-p5-doc/share/doc/tei-p5-doc
> cp VERSION release/tei-p5-doc/share/doc/tei-p5-doc
> BUILD: Make web pages for release notes
> for i in ReleaseNotes/readme*xml; \
> 	do  teitohtml --css=en/html/guidelines.css --profile=readme $i  \
> 		./release/tei-p5-doc/share/doc/tei-p5-doc/`basename $i .xml`.html; \
> 	done
> ERROR: No support for profile readme: /usr/share/xml/tei/stylesheet/profiles/readme/html/to.xsl does not exist.
> This was a fatal error. 2012-06-18 18:41:25
> ERROR: No support for profile readme: /usr/share/xml/tei/stylesheet/profiles/readme/html/to.xsl does not exist.
> This was a fatal error. 2012-06-18 18:41:25
> ERROR: No support for profile readme: /usr/share/xml/tei/stylesheet/profiles/readme/html/to.xsl does not exist.
> This was a fatal error. 2012-06-18 18:41:25
> ERROR: No support for profile readme: /usr/share/xml/tei/stylesheet/profiles/readme/html/to.xsl does not exist.
> This was a fatal error. 2012-06-18 18:41:25
> ERROR: No support for profile readme: /usr/share/xml/tei/stylesheet/profiles/readme/html/to.xsl does not exist.
> This was a fatal error. 2012-06-18 18:41:25
> ERROR: No support for profile readme: /usr/share/xml/tei/stylesheet/profiles/readme/html/to.xsl does not exist.
> This was a fatal error. 2012-06-18 18:41:25
> ERROR: No support for profile readme: /usr/share/xml/tei/stylesheet/profiles/readme/html/to.xsl does not exist.
> This was a fatal error. 2012-06-18 18:41:25
> ERROR: No support for profile readme: /usr/share/xml/tei/stylesheet/profiles/readme/html/to.xsl does not exist.
> This was a fatal error. 2012-06-18 18:41:25
> ERROR: No support for profile readme: /usr/share/xml/tei/stylesheet/profiles/readme/html/to.xsl does not exist.
> This was a fatal error. 2012-06-18 18:41:25
> ERROR: No support for profile readme: /usr/share/xml/tei/stylesheet/profiles/readme/html/to.xsl does not exist.
> This was a fatal error. 2012-06-18 18:41:25
> ERROR: No support for profile readme: /usr/share/xml/tei/stylesheet/profiles/readme/html/to.xsl does not exist.
> This was a fatal error. 2012-06-18 18:41:25
> ERROR: No support for profile readme: /usr/share/xml/tei/stylesheet/profiles/readme/html/to.xsl does not exist.
> This was a fatal error. 2012-06-18 18:41:25
> ERROR: No support for profile readme: /usr/share/xml/tei/stylesheet/profiles/readme/html/to.xsl does not exist.
> This was a fatal error. 2012-06-18 18:41:25
> ERROR: No support for profile readme: /usr/share/xml/tei/stylesheet/profiles/readme/html/to.xsl does not exist.
> This was a fatal error. 2012-06-18 18:41:25
> ERROR: No support for profile readme: /usr/share/xml/tei/stylesheet/profiles/readme/html/to.xsl does not exist.
> This was a fatal error. 2012-06-18 18:41:25
> ERROR: No support for profile readme: /usr/share/xml/tei/stylesheet/profiles/readme/html/to.xsl does not exist.
> This was a fatal error. 2012-06-18 18:41:26
> ERROR: No support for profile readme: /usr/share/xml/tei/stylesheet/profiles/readme/html/to.xsl does not exist.
> This was a fatal error. 2012-06-18 18:41:26
> ERROR: No support for profile readme: /usr/share/xml/tei/stylesheet/profiles/readme/html/to.xsl does not exist.
> This was a fatal error. 2012-06-18 18:41:26
> make: *** [dist-doc.stamp] Error 1
> Build step 'Execute shell' marked build as failure
> Archiving artifacts
>


From James.Cummings at oucs.ox.ac.uk  Tue Jun 19 01:56:49 2012
From: James.Cummings at oucs.ox.ac.uk (James Cummings)
Date: Tue, 19 Jun 2012 06:56:49 +0100
Subject: [tei-council] Build failed in Jenkins: TEIP5-Documentation #411
In-Reply-To: <4FE00020.7080503@uvic.ca>
References: <2006451446.3.1340070086486.JavaMail.jenkins@teijenkins>
	<4FE00020.7080503@uvic.ca>
Message-ID: <4FE014A1.6000204@oucs.ox.ac.uk>

On 19/06/12 05:29, Martin Holmes wrote:
> I put Lou's new readme profile into the Makefile, and the Documentation
> build broke.
>
> This reveals that the readme part of the Documentation job, at least,
> not been using the XSL from the Stylesheets build:
>
>   >  ERROR: No support for profile readme:
> /usr/share/xml/tei/stylesheet/profiles/readme/html/to.xsl does not exist.
>
> This is presumably because the script calls teitohtml, which doesn't
> know anything about the Jenkins job stylesheets at all; it defaults to
> APPHOME=/usr/share/xml/tei/stylesheet.
>
> So the Makefile needs to pass the XSL dir into the teitohtml script
> which operates on the readmes. I've tried to implement that, and we'll
> see if it works.
>
> I wonder if the teitohtml that gets called should be the one from SVN,
> rather than from the installed packages?

Wouldn't another solution be that if a Stylesheet build is 
successful that then the Jenkins system will do the equivalent of 
a 'sudo make install'? Then the next build would use the updated 
stylesheets.  I'd worry about passing it the directory of the 
Jenkins job stylesheets because you don't know that those have 
built successful yet?  Or am I misunderstanding this?

I had an identical error, btw, when I used the readme profile to 
generate the text for my message to TEI-L, and then remembered it 
was because I hadn't updated my local copy of the stylesheets 
since Lou had added that. A quick sudo make install and it worked 
perfectly.

-James
-- 
Dr James Cummings, InfoDev
Oxford University Computing Services
University of Oxford

From sebastian.rahtz at oucs.ox.ac.uk  Tue Jun 19 03:48:41 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Tue, 19 Jun 2012 07:48:41 +0000
Subject: [tei-council] Build failed in Jenkins: TEIP5-Documentation #411
In-Reply-To: <4FE014A1.6000204@oucs.ox.ac.uk>
References: <2006451446.3.1340070086486.JavaMail.jenkins@teijenkins>
	<4FE00020.7080503@uvic.ca> <4FE014A1.6000204@oucs.ox.ac.uk>
Message-ID: <eac6c5f9-fcfc-4645-9472-ab3e4a789b56@HUB02.ad.oak.ox.ac.uk>


On 19 Jun 2012, at 06:56, James Cummings wrote:

> Wouldn't another solution be that if a Stylesheet build is 
> successful that then the Jenkins system will do the equivalent of 
> a 'sudo make install'?

you want to give jenkins root privileges? no thanks?..


--
Sebastian Rahtz      
Head of Information and Support Group
Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431

S?lo le pido a Dios
que el futuro no me sea indiferente


From syeates at gmail.com  Tue Jun 19 04:03:23 2012
From: syeates at gmail.com (stuart yeates)
Date: Tue, 19 Jun 2012 20:03:23 +1200
Subject: [tei-council] Build failed in Jenkins: TEIP5-Documentation #411
In-Reply-To: <eac6c5f9-fcfc-4645-9472-ab3e4a789b56@HUB02.ad.oak.ox.ac.uk>
References: <2006451446.3.1340070086486.JavaMail.jenkins@teijenkins>
	<4FE00020.7080503@uvic.ca> <4FE014A1.6000204@oucs.ox.ac.uk>
	<eac6c5f9-fcfc-4645-9472-ab3e4a789b56@HUB02.ad.oak.ox.ac.uk>
Message-ID: <4FE0324B.4070100@gmail.com>

On 19/06/12 19:48, Sebastian Rahtz wrote:
>
> On 19 Jun 2012, at 06:56, James Cummings wrote:
>
>> Wouldn't another solution be that if a Stylesheet build is
>> successful that then the Jenkins system will do the equivalent of
>> a 'sudo make install'?
>
> you want to give jenkins root privileges? no thanks?..

I'd like to second that thought from Sebastian.

Unless you're throwing away the VM every time you do a rebuild (which is 
conceivable, given a caching proxy and lots of free time), giving root 
to a build tool such as jenkins is almost certainly a bad idea.

cheers
stuart


From James.Cummings at oucs.ox.ac.uk  Tue Jun 19 05:06:14 2012
From: James.Cummings at oucs.ox.ac.uk (James Cummings)
Date: Tue, 19 Jun 2012 10:06:14 +0100
Subject: [tei-council] Build failed in Jenkins: TEIP5-Documentation #411
In-Reply-To: <eac6c5f9-fcfc-4645-9472-ab3e4a789b56@HUB02.ad.oak.ox.ac.uk>
References: <2006451446.3.1340070086486.JavaMail.jenkins@teijenkins>	<4FE00020.7080503@uvic.ca>
	<4FE014A1.6000204@oucs.ox.ac.uk>
	<eac6c5f9-fcfc-4645-9472-ab3e4a789b56@HUB02.ad.oak.ox.ac.uk>
Message-ID: <4FE04106.5050402@oucs.ox.ac.uk>

On 19/06/12 08:48, Sebastian Rahtz wrote:
>
> On 19 Jun 2012, at 06:56, James Cummings wrote:
>
>> Wouldn't another solution be that if a Stylesheet build is
>> successful that then the Jenkins system will do the equivalent of
>> a 'sudo make install'?
>
> you want to give jenkins root privileges? no thanks?..

That's why I said 'do the equivalent of' without being specific 
of how that might be done. When I wrote that I was thinking 'do a 
make install to a specified location and then always reference 
that. This could indeed be in /usr/share/xml/tei if the Jenkins 
machine was set to allow jenkins to write there.  (Which then 
needs no special privileges and doesn't really give much security 
risk.)

However, thinking about it, surely the stylesheet repository used 
should point to the last-successful-build location of the 
Stylesheets, no?

-James


-- 
Dr James Cummings, InfoDev,
Computing Services, University of Oxford

From mholmes at uvic.ca  Tue Jun 19 08:29:15 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Tue, 19 Jun 2012 05:29:15 -0700
Subject: [tei-council] Build failed in Jenkins: TEIP5-Documentation #411
In-Reply-To: <eac6c5f9-fcfc-4645-9472-ab3e4a789b56@HUB02.ad.oak.ox.ac.uk>
References: <2006451446.3.1340070086486.JavaMail.jenkins@teijenkins>
	<4FE00020.7080503@uvic.ca> <4FE014A1.6000204@oucs.ox.ac.uk>
	<eac6c5f9-fcfc-4645-9472-ab3e4a789b56@HUB02.ad.oak.ox.ac.uk>
Message-ID: <4FE0709B.90906@uvic.ca>

On 12-06-19 12:48 AM, Sebastian Rahtz wrote:
>
> On 19 Jun 2012, at 06:56, James Cummings wrote:
>
>> Wouldn't another solution be that if a Stylesheet build is
>> successful that then the Jenkins system will do the equivalent of
>> a 'sudo make install'?
>
> you want to give jenkins root privileges? no thanks?..

But the real issue is that the Stylesheets change all the time, and we 
don't want to require that Sebastian do a new release of them every time 
we need to see the results of those changes on the other builds.

Cheers,
Martin

>
>
> --
> Sebastian Rahtz
> Head of Information and Support Group
> Oxford University Computing Services
> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>
> S?lo le pido a Dios
> que el futuro no me sea indiferente
>


From mholmes at uvic.ca  Tue Jun 19 08:51:58 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Tue, 19 Jun 2012 05:51:58 -0700
Subject: [tei-council] Jenkins build failures are my fault
Message-ID: <4FE075EE.1080200@uvic.ca>

Just letting everyone know that I'm pretty sure I'm responsible for the 
Jenkins build failures, but I won't be able to fix the problem until I 
get to work in a couple of hours. Sorry about this. It's my first 
attempt to add a test for a Schematron constraint, and I seem to have 
screwed it up.

But there will be documentation arising out of this experience. :-)

Cheers,
Martin

From bbarney2 at unl.edu  Tue Jun 19 13:26:31 2012
From: bbarney2 at unl.edu (Brett Barney)
Date: Tue, 19 Jun 2012 17:26:31 +0000
Subject: [tei-council] Oxford Face2Face meeting: Accommodation
In-Reply-To: <sha1t5s9d26gcwpiot46d2xi.1339778207132@email.android.com>
References: <4FDB47A0.2060601@oucs.ox.ac.uk>,<4FDB6025.9070909@uvic.ca>
	<sha1t5s9d26gcwpiot46d2xi.1339778207132@email.android.com>
Message-ID: <2F799D65-8839-463B-9ADE-4DD8BA6B1B78@unl.edu>

On Jun 15, 2012, at 11:37 AM, James Cummings wrote:
> The budget is for 3 nights, but it depends on others arrangements and where these may save us money.  We can probably stretch to four nights, especially if it results in a cheaper air fare (e.g. for including a Saturday).  That is why I want everyone to fill in the poll, even if it is to indicate the TEI-C isn't paying anything to their accommodation. So put down what you need and we'll see what we can do. ;-)
> 
> Jamesc


Hi all,

Sorry to complicate things. I was puzzled by this talk about cheaper fares if you include a Saturday, since everywhere I shop I get all but identical fares for Friday or Saturday flights. They all seem expensive--c. $1650. But I did notice that a big discount seems to accrue if one *stays* Saturday night, i.e., flies out on Sunday. That would mean *two* extra nights, which seems a bit much to ask the TEI to fund. The price, however, gave me pause--c. $900. My miserly little soul hates to commit to a $1600 plane fare, but am I right in assuming that I should do that?

Regards,
Brett







From gabriel.bodard at kcl.ac.uk  Tue Jun 19 13:35:35 2012
From: gabriel.bodard at kcl.ac.uk (Gabriel BODARD)
Date: Tue, 19 Jun 2012 18:35:35 +0100
Subject: [tei-council] Oxford Face2Face meeting: Accommodation
In-Reply-To: <2F799D65-8839-463B-9ADE-4DD8BA6B1B78@unl.edu>
References: <4FDB47A0.2060601@oucs.ox.ac.uk>, <4FDB6025.9070909@uvic.ca>
	<sha1t5s9d26gcwpiot46d2xi.1339778207132@email.android.com>
	<2F799D65-8839-463B-9ADE-4DD8BA6B1B78@unl.edu>
Message-ID: <4FE0B867.9030008@kcl.ac.uk>

No that's right, it's only cheaper if you either stay a Saturday night 
or return on a Saturday night overnight flight (which returning from 
here to the US doesn't make much sense). In my experience, the 
person/body paying the expenses has *always* preferred to pay an extra 
couple nights accommodation that the extra $900 for a more expensive flight.


On 19/06/2012 18:26, Brett Barney wrote:
> On Jun 15, 2012, at 11:37 AM, James Cummings wrote:
>> The budget is for 3 nights, but it depends on others arrangements and where these may save us money.  We can probably stretch to four nights, especially if it results in a cheaper air fare (e.g. for including a Saturday).  That is why I want everyone to fill in the poll, even if it is to indicate the TEI-C isn't paying anything to their accommodation. So put down what you need and we'll see what we can do. ;-)
>>
>> Jamesc
>
>
> Hi all,
>
> Sorry to complicate things. I was puzzled by this talk about cheaper fares if you include a Saturday, since everywhere I shop I get all but identical fares for Friday or Saturday flights. They all seem expensive--c. $1650. But I did notice that a big discount seems to accrue if one *stays* Saturday night, i.e., flies out on Sunday. That would mean *two* extra nights, which seems a bit much to ask the TEI to fund. The price, however, gave me pause--c. $900. My miserly little soul hates to commit to a $1600 plane fare, but am I right in assuming that I should do that?
>
> Regards,
> Brett
>
>
>
>
>
>

-- 
Dr Gabriel BODARD
(Research Associate in Digital Epigraphy)

Department of Digital Humanities
King's College London
26-29 Drury Lane
London WC2B 5RL

Email: gabriel.bodard at kcl.ac.uk
Tel: +44 (0)20 7848 1388
Fax: +44 (0)20 7848 2980

http://www.digitalclassicist.org/
http://www.currentepigraphy.org/



From PFSchaffner at umich.edu  Tue Jun 19 15:18:30 2012
From: PFSchaffner at umich.edu (Paul F. Schaffner)
Date: Tue, 19 Jun 2012 15:18:30 -0400 (EDT)
Subject: [tei-council] Oxford Face2Face meeting: Accommodation
In-Reply-To: <4FE0B867.9030008@kcl.ac.uk>
References: <4FDB47A0.2060601@oucs.ox.ac.uk>, <4FDB6025.9070909@uvic.ca>
	<sha1t5s9d26gcwpiot46d2xi.1339778207132@email.android.com>
	<2F799D65-8839-463B-9ADE-4DD8BA6B1B78@unl.edu>
	<4FE0B867.9030008@kcl.ac.uk>
Message-ID: <Pine.LNX.4.64.1206191510370.21382@zaxxon.gpcc.itd.umich.edu>

Ok, I've taken all this as inspiration and booked a flight arriving at LHR
on the 9th of Sept and departing ditto on the 23rd. That should leave
space (working backwards) for the Council mtg; the TCP mini-conference;
the York (PBFA) Book Fair; a visit to the doll's house shop and Barbican
Books in Fossgate (etc.); and something else as yet undetermined, perhaps
in the Moors, the Dales, or the Yorkshire coast.

The flight costs ~ $1,000 nonstop -- to make it $50 cheaper would have 
required shifting to Monday travel and I'll gladly cover the difference.

I've also written to my usual Oxford B&B and asked if they have space
for that week.

So there!

Now I have to go catch a coach to a train to (after many many hours)
the Folger in D.C., where we will talk about repurposing TCP-transcribed
texts of non-Shakespearean drama.


pfs


On Tue, 19 Jun 2012, Gabriel BODARD wrote:

> No that's right, it's only cheaper if you either stay a Saturday night
> or return on a Saturday night overnight flight (which returning from
> here to the US doesn't make much sense). In my experience, the
> person/body paying the expenses has *always* preferred to pay an extra
> couple nights accommodation that the extra $900 for a more expensive flight.
>
>
> On 19/06/2012 18:26, Brett Barney wrote:
>> On Jun 15, 2012, at 11:37 AM, James Cummings wrote:
>>> The budget is for 3 nights, but it depends on others arrangements and where these may save us money.  We can probably stretch to four nights, especially if it results in a cheaper air fare (e.g. for including a Saturday).  That is why I want everyone to fill in the poll, even if it is to indicate the TEI-C isn't paying anything to their accommodation. So put down what you need and we'll see what we can do. ;-)
>>>
>>> Jamesc
>>
>>
>> Hi all,
>>
>> Sorry to complicate things. I was puzzled by this talk about cheaper fares if you include a Saturday, since everywhere I shop I get all but identical fares for Friday or Saturday flights. They all seem expensive--c. $1650. But I did notice that a big discount seems to accrue if one *stays* Saturday night, i.e., flies out on Sunday. That would mean *two* extra nights, which seems a bit much to ask the TEI to fund. The price, however, gave me pause--c. $900. My miserly little soul hates to commit to a $1600 plane fare, but am I right in assuming that I should do that?
>>
>> Regards,
>> Brett
>>
>>
>>
>>
>>
>>
>
> -- 
> Dr Gabriel BODARD
> (Research Associate in Digital Epigraphy)
>
> Department of Digital Humanities
> King's College London
> 26-29 Drury Lane
> London WC2B 5RL
>
> Email: gabriel.bodard at kcl.ac.uk
> Tel: +44 (0)20 7848 1388
> Fax: +44 (0)20 7848 2980
>
> http://www.digitalclassicist.org/
> http://www.currentepigraphy.org/
>
>
> -- 
> tei-council mailing list
> tei-council at lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>
> PLEASE NOTE: postings to this list are publicly archived
>
>
>

--------------------------------------------------------------------
Paul Schaffner | PFSchaffner at umich.edu | http://www.umich.edu/~pfs/
316-C Hatcher Library N, Univ. of Michigan, Ann Arbor MI 48109-1190
--------------------------------------------------------------------

From mholmes at uvic.ca  Tue Jun 19 15:53:38 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Tue, 19 Jun 2012 12:53:38 -0700
Subject: [tei-council] @min and @max
Message-ID: <4FE0D8C2.3070609@uvic.ca>

In the IRC chatroom, something came up that we need to look at.

There's a test in P5-Test which we think should be failing, but it's not 
failing. It's called testcardinality, and consists of:

/trunk/P5/Test/testcardinality.odd
                testcardinality.xml

The ODD file creates a constraint on the number of times a member of 
model.lLike can appear inside a parent:

<schemaSpec ident="testcardinality">
           <moduleRef key="tei"/>
           <moduleRef key="core"/>
           <moduleRef key="header"/>
           <moduleRef key="textstructure"/>
	  <elementSpec ident="l" mode="change">
	    <classes mode="replace">
	      <memberOf key="att.global"/>
	      <memberOf key="att.metrical"/>
	      <memberOf key="att.enjamb"/>	
	      <memberOf key="model.lLike" min="2" max="6"/>
	    </classes>
	  </elementSpec>
       </schemaSpec>

And the test.xml file has an <lg> which clearly violates that constraint:

           <lg>
<!--  Why doesn't this fail validation? It should, surely. MDH 
2012-06-19.          -->
             <l>Bent double, like old beggars under sacks, </l>
           </lg>

(It has only one <l>.)

I'm pretty sure that DTDs cannot support min and max occurrence 
constraints, but I think RNGs should; the RNG generated from this ODD 
file, however, allows a single model.lLike to occur:

<group>
         <zeroOrMore>
           <choice>
             <ref name="model.divTop"/>
             <ref name="model.global"/>
           </choice>
         </zeroOrMore>
         <choice>
           <ref name="model.lLike"/>
           <ref name="model.stageLike"/>
           <ref name="model.labelLike"/>
           <ref name="lg"/>
         </choice>
         <zeroOrMore>
           <choice>
             <ref name="model.lLike"/>
             <ref name="model.stageLike"/>
             <ref name="model.labelLike"/>
             <ref name="model.global"/>
             <ref name="lg"/>
           </choice>
         </zeroOrMore>
         <zeroOrMore>
           <group>
             <ref name="model.divBottom"/>
           </group>
           <zeroOrMore>
             <ref name="model.global"/>
           </zeroOrMore>
         </zeroOrMore>
       </group>

So my question is: is this supposed to work? If so, is it supposed to 
work in RNG files? And if so, is this an example of an ODD processing error?

If it's not supposed to work -- if it's just a feature of ODD, and not 
of schemas we currently generate from ODD -- then we can just switch off 
this test for the moment. But I don't know the background to @min and 
@max well enough to understand what should be happening.

Cheers,
Martin
-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From mholmes at uvic.ca  Tue Jun 19 16:44:42 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Tue, 19 Jun 2012 13:44:42 -0700
Subject: [tei-council] Interesting Oxygen behaviour
Message-ID: <4FE0E4BA.1070300@uvic.ca>

I have some an ex-TCP document that was failing to validate under the 
previous release of TEI because it had a <closer> in a <postscript>. 
With the new release out, I tried validating this document against the 
new tei_all:

http://www.tei-c.org/release/xml/tei/custom/schema/relaxng/tei_all.rng

It failed, complaining about the <closer>. I did Reset Cache and 
Validate, many times. I went to the documentation and to the schema 
itself to confirm that <closer> is now allowed in <postscript>. I did 
Validate With and put in the URL of the tei_all, and also had it in the 
document as an <?xml-model?> PI. No joy.

It wasn't till I actually downloaded the oxygen-tei packages and 
overwrote my TEI framework folder in Oxygen that I got the correct 
result. It appears that if you try to validate a file against a TEI 
schema on the TEI website, Oxygen is determined to use its own local 
copy, without checking whether they're the same or not. That wasted a 
bunch of my time.

Cheers,
Martin
-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From James.Cummings at oucs.ox.ac.uk  Tue Jun 19 16:50:22 2012
From: James.Cummings at oucs.ox.ac.uk (James Cummings)
Date: Tue, 19 Jun 2012 21:50:22 +0100
Subject: [tei-council] Interesting Oxygen behaviour
In-Reply-To: <4FE0E4BA.1070300@uvic.ca>
References: <4FE0E4BA.1070300@uvic.ca>
Message-ID: <4FE0E60E.1020608@oucs.ox.ac.uk>

On 19/06/12 21:44, Martin Holmes wrote:
> It wasn't till I actually downloaded the oxygen-tei packages and
> overwrote my TEI framework folder in Oxygen that I got the correct
> result. It appears that if you try to validate a file against a TEI
> schema on the TEI website, Oxygen is determined to use its own local
> copy, without checking whether they're the same or not. That wasted a
> bunch of my time.

Yes, I've noticed this several times. I think that if there is an 
<?xml-model..?> or <?oxygen..?> then oXygen should give priority 
to this, but as far as I can tell it doesn't.

We don't have a way for people to _easily_ update just the 
oxygen-tei framework used in their version of oXygen doing some 
quite geeky things.  (So by easy I mean go to a list of document 
type associations / frameworks and click 'check for updates' and 
have it automatically done if there is a new update.)  Maybe we 
should suggest to oXygen?

It would be good on new releases to be able to say 'Download it 
from here, or if you are in oXygen click the 'check for new tei 
releases' button.

-James

-- 
Dr James Cummings, InfoDev
Oxford University Computing Services
University of Oxford

From kevin.s.hawkins at ultraslavonic.info  Tue Jun 19 17:33:38 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Tue, 19 Jun 2012 17:33:38 -0400
Subject: [tei-council] Release notes (was Re:  next release?)
In-Reply-To: <4FDF66C2.5070307@kcl.ac.uk>
References: <0F18A249-5480-42D9-BFF2-538AC7B9E1EB@oucs.ox.ac.uk>
	<4F92F34D.2040103@uvic.ca>	<4F9579A0.8010002@oucs.ox.ac.uk>
	<4F95C7A1.1080707@o2.pl>	<4F96756B.1060202@oucs.ox.ac.uk>
	<4F986673.7020201@kcl.ac.uk>	<4FB95846.7080308@oucs.ox.ac.uk>
	<4FDA15EC.5050700@oucs.ox.ac.uk> <4FDB16D3.2080007@kcl.ac.uk>
	<4FDDB2D8.7090604@oucs.ox.ac.uk>	<4FDDE5E5.9000000@retired.ox.ac.uk>
	<4FDEEF88.3020503@kcl.ac.uk>	<4FDEF0A2.1020400@retired.ox.ac.uk>
	<4FDEF1F0.7020906@o2.pl> <4FDEF522.5040601@kcl.ac.uk>
	<4FDF66C2.5070307@kcl.ac.uk>
Message-ID: <4FE0F032.30207@ultraslavonic.info>

All,

I'm about to adjust tcw22 based on this and a few more emails sent in 
the past few days to make the instructions clearer.  Notes below, 
including some questions for Gabby and requests from anyone for 
clarification ...

On 6/18/12 1:34 PM, Gabriel BODARD wrote:
> 2. Version numbers updated. (I had to stop and think for a moment
> whether I was supposed to be updated the -fr version as well. Obviously
> yes, but just to note that with current wording I wondered.)

I'm not sure how to improve on the current wording.  Could you suggest 
something?

> 4. Debian changelogs: the changelog files don't exist where they are
> listed in the sbs. I now understand that this is automated in Jenkins...
> so this point should be deleted from the doc.

I've commented it out (and added a comment explaining that Jenkins now 
does it).

> 7. This all seems okay to me, but I think the item in the doc could be
> spelled out a bit more explicitly what to look for.

Suggestions?

> 8. Apparent problem with instructions in this item:
>
> svnUp.sh runs as written, but
> tei-install.sh needs the "sh" command before it. (Does this mean it is
> not executable?) Either that needs to be changed, or the instructions.
> (Note: James has already fixed the file so it is executable by user.)

Right, the problem was that it's not executable.  I hesitate to insert 
the "sh" command because maybe the script was written to assume you use 
csh or bash or something.  Best to leave the instructions as they are, 
in my opinion.

> Also: Sourceforge denied me permission to make the release at this step.
> We need to add a note that the user needs to add the public key from
> /home/tei/.ssh/id_dsa to their Sourceforge account before they can rsync
> the release zip. This probably belongs in the "What you need" section at
> the top of tcw22.

So I could add this to the "what you need" section:

* A copy of public key from tei-c.org:/home/tei/.ssh/id_dsa at ~/.ssh/ 
in your Sourceforge account's home directly. This is need to rsync the 
release zip.

Is that correct?  It seems to me that if you use your SF for anything 
else, this could overwrite keypairs that you might have on file.  But I 
guess if you're that advanced, you'll know how to do this properly. 
Still, I recommend suggestions on a better way to do this.

> 10. Defaults set. Fine. (Instructions could be clearer--I've done this
> before for other projects, but if not I might not have known where to look.)

Can you suggest a clarification?

> 12. Sebastian informed that debian can be released.
>
> 13. Sebastian informed that oxygen-tei can be updated.
>
> 14. Checking TEI website and downloads. (I wonder we shouldn't do this
> check before the previous two, and maybe before 10 as well. If there's a
> problem with the website we may have to start again.)

If someone tells me to move this step, I will gladly do it.

--Kevin

From kevin.s.hawkins at ultraslavonic.info  Tue Jun 19 17:37:08 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Tue, 19 Jun 2012 17:37:08 -0400
Subject: [tei-council] updating oxygen-tei
In-Reply-To: <532C9330-5510-4DC5-8585-6B89E11460A7@oucs.ox.ac.uk>
References: <88006B2C-D88A-4B0C-9A42-9B24301BE6AF@oucs.ox.ac.uk>
	<532C9330-5510-4DC5-8585-6B89E11460A7@oucs.ox.ac.uk>
Message-ID: <4FE0F104.904@ultraslavonic.info>

Okay, I have replaced the current step 13 with the text below.

On 6/18/12 4:11 PM, Sebastian Rahtz wrote:
> can whoever is editing tcw22 add, in place of stage 13, the instruction:
>
>
>>
>> Update the oXygen-ready distribution of TEI. If you have
> write permission on the Google Code project, you can check out the source from
> http://code.google.com/p/oxygen-tei/ and run the shell script
> update-and-upload.sh. Otherwise, ask one of the maintainers to do
> this for you.

From kevin.s.hawkins at ultraslavonic.info  Tue Jun 19 17:40:21 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Tue, 19 Jun 2012 17:40:21 -0400
Subject: [tei-council] updating oxygen-tei
In-Reply-To: <4FDFA25B.3030405@oucs.ox.ac.uk>
References: <88006B2C-D88A-4B0C-9A42-9B24301BE6AF@oucs.ox.ac.uk>
	<532C9330-5510-4DC5-8585-6B89E11460A7@oucs.ox.ac.uk>
	<4FDF9C7C.70902@uvic.ca>
	<D011000F-44F3-4D64-AD5B-C0DFD95B6300@oucs.ox.ac.uk>
	<4FDFA25B.3030405@oucs.ox.ac.uk>
Message-ID: <4FE0F1C5.3040905@ultraslavonic.info>

And I'm adding this bit of explanation as well.

On 6/18/12 5:49 PM, James Cummings wrote:
> On 18/06/12 22:41, Sebastian Rahtz wrote:
>>
>> On 18 Jun 2012, at 22:24, Martin Holmes wrote:
>>
>>>
>>> I don't know what svnUp.sh is for, unless the eXist db is populated from a local copy. Is it?
>>>
>> no, it comes from the version installed by the main script
>
> svnUp.sh updates the local copy of the subversion repository
> because the scripts in /home/tei/bin/ that the release technician
> is using are *in* subversion.  You should *not* be editing these
> scripts locally on tei-c.org instead, edit them and commit them
> to subversion.  Wherever possible there should be no special
> local magic files.
>
> This message has been brought to you by the "Campaign to Reduce
> Apparent Magic and Processing Specifics".
>
> -James
>

From James.Cummings at oucs.ox.ac.uk  Tue Jun 19 17:40:38 2012
From: James.Cummings at oucs.ox.ac.uk (James Cummings)
Date: Tue, 19 Jun 2012 22:40:38 +0100
Subject: [tei-council] Release notes (was Re:  next release?)
In-Reply-To: <4FE0F032.30207@ultraslavonic.info>
References: <0F18A249-5480-42D9-BFF2-538AC7B9E1EB@oucs.ox.ac.uk>
	<4F92F34D.2040103@uvic.ca>	<4F9579A0.8010002@oucs.ox.ac.uk>
	<4F95C7A1.1080707@o2.pl>	<4F96756B.1060202@oucs.ox.ac.uk>
	<4F986673.7020201@kcl.ac.uk>	<4FB95846.7080308@oucs.ox.ac.uk>
	<4FDA15EC.5050700@oucs.ox.ac.uk> <4FDB16D3.2080007@kcl.ac.uk>
	<4FDDB2D8.7090604@oucs.ox.ac.uk>	<4FDDE5E5.9000000@retired.ox.ac.uk>
	<4FDEEF88.3020503@kcl.ac.uk>	<4FDEF0A2.1020400@retired.ox.ac.uk>
	<4FDEF1F0.7020906@o2.pl> <4FDEF522.5040601@kcl.ac.uk>
	<4FDF66C2.5070307@kcl.ac.uk> <4FE0F032.30207@ultraslavonic.info>
Message-ID: <4FE0F1D6.2090703@oucs.ox.ac.uk>

On 19/06/12 22:33, Kevin Hawkins wrote:
>> svnUp.sh runs as written, but
>> tei-install.sh needs the "sh" command before it. (Does this mean it is
>> not executable?) Either that needs to be changed, or the instructions.
>> (Note: James has already fixed the file so it is executable by user.)
>
> Right, the problem was that it's not executable.  I hesitate to insert
> the "sh" command because maybe the script was written to assume you use
> csh or bash or something.  Best to leave the instructions as they are,
> in my opinion.

Already fixed on tei-c.org, it should be executable now as 
./tei-install

>> 14. Checking TEI website and downloads. (I wonder we shouldn't do this
>> check before the previous two, and maybe before 10 as well. If there's a
>> problem with the website we may have to start again.)
>
> If someone tells me to move this step, I will gladly do it.

Yes, I think it best to move it up.

We should also make some indication of what to check for?
Checking that the version number has updated on webpages is one 
thing, another could be that a change you know to have been 
committed is displayed... But the thing that delayed Gaby was a 
problem with the tei_all.dtd was noticed. Should the release 
technician be checking a file against all of these (but surely 
Jenkins has done this?)  Need better (but quicker) testing on 
Jenkins clearly.

-James

-- 
Dr James Cummings, InfoDev
Oxford University Computing Services
University of Oxford

From sebastian.rahtz at oucs.ox.ac.uk  Wed Jun 20 03:31:40 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Wed, 20 Jun 2012 07:31:40 +0000
Subject: [tei-council] @min and @max
In-Reply-To: <4FE0D8C2.3070609@uvic.ca>
References: <4FE0D8C2.3070609@uvic.ca>
Message-ID: <BB564121-8C8C-4F54-8897-2621D86B5093@oucs.ox.ac.uk>

the truth is that this is only part of the picture. the content model of <lg> has also to be changed to ask
for model.lLike_sequence in order for the @min and @max test to have an effect. If you look at the schema,
it comes out with

model.lLike = l | l | l? | l? | l? | l?
model.lLike_alternation = l | l | l? | l? | l? | l?
model.lLike_sequence = l, l, l?, l?, l?, l?
model.lLike_sequenceOptional = (l, l, l?, l?, l?, l?)?
model.lLike_sequenceOptionalRepeatable = (l, l, l?, l?, l?, l?)*
model.lLike_sequenceRepeatable = (l, l, l?, l?, l?, l?)+

where you can see why the standard model.lLike does not do the job.

so now you should watch P5 build fail :-}
--
Sebastian Rahtz      
Head of Information and Support Group
Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431







From lou.burnard at retired.ox.ac.uk  Wed Jun 20 05:35:03 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Wed, 20 Jun 2012 10:35:03 +0100
Subject: [tei-council] @min and @max
In-Reply-To: <4FE0D8C2.3070609@uvic.ca>
References: <4FE0D8C2.3070609@uvic.ca>
Message-ID: <4FE19947.6090001@retired.ox.ac.uk>

Maybe I am missing something, but this example seems Broken As Designed 
to me. It seems to be changing <l> so that it can appear some number of 
times within <l>, presumably to test the @min and @max attributes. But 
<l> cannot appear within <l> and this doesn't happen inside the test 
file anyway.



On 19/06/12 20:53, Martin Holmes wrote:
> In the IRC chatroom, something came up that we need to look at.
>
> There's a test in P5-Test which we think should be failing, but it's not
> failing. It's called testcardinality, and consists of:
>
> /trunk/P5/Test/testcardinality.odd
>                  testcardinality.xml
>
> The ODD file creates a constraint on the number of times a member of
> model.lLike can appear inside a parent:
>
> <schemaSpec ident="testcardinality">
>             <moduleRef key="tei"/>
>             <moduleRef key="core"/>
>             <moduleRef key="header"/>
>             <moduleRef key="textstructure"/>
> 	<elementSpec ident="l" mode="change">
> 	<classes mode="replace">
> 	<memberOf key="att.global"/>
> 	<memberOf key="att.metrical"/>
> 	<memberOf key="att.enjamb"/>	
> 	<memberOf key="model.lLike" min="2" max="6"/>
> 	</classes>
> 	</elementSpec>
>         </schemaSpec>
>
> And the test.xml file has an<lg>  which clearly violates that constraint:
>
>             <lg>
> <!--  Why doesn't this fail validation? It should, surely. MDH
> 2012-06-19.          -->
>               <l>Bent double, like old beggars under sacks,</l>
>             </lg>
>
> (It has only one<l>.)
>
> I'm pretty sure that DTDs cannot support min and max occurrence
> constraints, but I think RNGs should; the RNG generated from this ODD
> file, however, allows a single model.lLike to occur:
>
> <group>
>           <zeroOrMore>
>             <choice>
>               <ref name="model.divTop"/>
>               <ref name="model.global"/>
>             </choice>
>           </zeroOrMore>
>           <choice>
>             <ref name="model.lLike"/>
>             <ref name="model.stageLike"/>
>             <ref name="model.labelLike"/>
>             <ref name="lg"/>
>           </choice>
>           <zeroOrMore>
>             <choice>
>               <ref name="model.lLike"/>
>               <ref name="model.stageLike"/>
>               <ref name="model.labelLike"/>
>               <ref name="model.global"/>
>               <ref name="lg"/>
>             </choice>
>           </zeroOrMore>
>           <zeroOrMore>
>             <group>
>               <ref name="model.divBottom"/>
>             </group>
>             <zeroOrMore>
>               <ref name="model.global"/>
>             </zeroOrMore>
>           </zeroOrMore>
>         </group>
>
> So my question is: is this supposed to work? If so, is it supposed to
> work in RNG files? And if so, is this an example of an ODD processing error?
>
> If it's not supposed to work -- if it's just a feature of ODD, and not
> of schemas we currently generate from ODD -- then we can just switch off
> this test for the moment. But I don't know the background to @min and
> @max well enough to understand what should be happening.
>
> Cheers,
> Martin


From sebastian.rahtz at oucs.ox.ac.uk  Wed Jun 20 05:40:05 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Wed, 20 Jun 2012 09:40:05 +0000
Subject: [tei-council] @min and @max
In-Reply-To: <4FE19947.6090001@retired.ox.ac.uk>
References: <4FE0D8C2.3070609@uvic.ca> <4FE19947.6090001@retired.ox.ac.uk>
Message-ID: <94966744-b511-4984-bef4-adfaf0d312fa@HUB06.ad.oak.ox.ac.uk>


On 20 Jun 2012, at 10:35, Lou Burnard wrote:

> Maybe I am missing something, but this example seems Broken As Designed 
> to me. It seems to be changing <l> so that it can appear some number of 
> times within <l>, presumably to test the @min and @max attributes. But 
> <l> cannot appear within <l> and this doesn't happen inside the test 
> file anyway.


i think you are misunderstanding @min and @max, Lou. They say, for the current
element, how it should be modelled in the relevant model class.

"max	supplies the maximum number of times the element can occur in elements which use this model class in their content model"

--
Sebastian Rahtz      
Head of Information and Support Group
Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431

S?lo le pido a Dios
que el futuro no me sea indiferente


From lou.burnard at retired.ox.ac.uk  Wed Jun 20 05:46:44 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Wed, 20 Jun 2012 10:46:44 +0100
Subject: [tei-council] @min and @max
In-Reply-To: <C2DC9965-6F3C-4855-8820-8F7F3E379071@oucs.ox.ac.uk>
References: <4FE0D8C2.3070609@uvic.ca> <4FE19947.6090001@retired.ox.ac.uk>
	<C2DC9965-6F3C-4855-8820-8F7F3E379071@oucs.ox.ac.uk>
Message-ID: <4FE19C04.6000606@retired.ox.ac.uk>

On 20/06/12 10:40, Sebastian Rahtz wrote:
>
> On 20 Jun 2012, at 10:35, Lou Burnard wrote:
>
>> Maybe I am missing something, but this example seems Broken As Designed
>> to me. It seems to be changing<l>  so that it can appear some number of
>> times within<l>, presumably to test the @min and @max attributes. But
>> <l>  cannot appear within<l>  and this doesn't happen inside the test
>> file anyway.
>
>
> i think you are misunderstanding @min and @max, Lou. They say, for the current
> element, how it should be modelled in the relevant model class.
>
> "max	supplies the maximum number of times the element can occur in elements which use this model class in their content model"
>
> --

ok, i get it now. maybe we need to add some more attributes to memberOf 
(e.g. @opt and @seq with true and false values) to complete the picture?



From sebastian.rahtz at oucs.ox.ac.uk  Wed Jun 20 05:53:47 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Wed, 20 Jun 2012 09:53:47 +0000
Subject: [tei-council] @min and @max
In-Reply-To: <4FE19C04.6000606@retired.ox.ac.uk>
References: <4FE0D8C2.3070609@uvic.ca> <4FE19947.6090001@retired.ox.ac.uk>
	<C2DC9965-6F3C-4855-8820-8F7F3E379071@oucs.ox.ac.uk>
	<4FE19C04.6000606@retired.ox.ac.uk>
Message-ID: <8073b86e-c7cb-4130-bd7a-29f6eebe1d61@HUB02.ad.oak.ox.ac.uk>


On 20 Jun 2012, at 10:46, Lou Burnard wrote:

> 
> ok, i get it now. maybe we need to add some more attributes to memberOf 
> (e.g. @opt and @seq with true and false values) to complete the picture?



possibly. I agree, this seems like unfinished work we put in for Bertrand
without quite understanding it
--
Sebastian Rahtz      
Head of Information and Support Group
Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431

S?lo le pido a Dios
que el futuro no me sea indiferente


From gabriel.bodard at kcl.ac.uk  Wed Jun 20 07:50:07 2012
From: gabriel.bodard at kcl.ac.uk (Gabriel BODARD)
Date: Wed, 20 Jun 2012 12:50:07 +0100
Subject: [tei-council] Release notes (was Re:  next release?)
In-Reply-To: <4FE0F032.30207@ultraslavonic.info>
References: <0F18A249-5480-42D9-BFF2-538AC7B9E1EB@oucs.ox.ac.uk>
	<4F92F34D.2040103@uvic.ca>	<4F9579A0.8010002@oucs.ox.ac.uk>
	<4F95C7A1.1080707@o2.pl>	<4F96756B.1060202@oucs.ox.ac.uk>
	<4F986673.7020201@kcl.ac.uk>	<4FB95846.7080308@oucs.ox.ac.uk>
	<4FDA15EC.5050700@oucs.ox.ac.uk> <4FDB16D3.2080007@kcl.ac.uk>
	<4FDDB2D8.7090604@oucs.ox.ac.uk>	<4FDDE5E5.9000000@retired.ox.ac.uk>
	<4FDEEF88.3020503@kcl.ac.uk>	<4FDEF0A2.1020400@retired.ox.ac.uk>
	<4FDEF1F0.7020906@o2.pl> <4FDEF522.5040601@kcl.ac.uk>
	<4FDF66C2.5070307@kcl.ac.uk> <4FE0F032.30207@ultraslavonic.info>
Message-ID: <4FE1B8EF.5030907@kcl.ac.uk>

Hi Kevin,

Thanks for this. I was going to make various changes to tcw22 based on 
my experiences, but probably not until next week. Please feel free to go 
ahead and change anything you like, and I'll make further tweaks, 
suggest specific wording where I've said "clarify", etc., when I have time.

Re point 8 (the first part): yes this was already fixed before I sent 
the email, so nothing needs changed in tcw22 for this. I left it in my 
report for a paper trail.

(The second part) Sourceforge allows you to register any number of keys 
in your account, so you don't need to overwrite anything. This should be 
implicit if we phrase something like, "Add a copy of the public key from 
tei-c.org:/home/tei/.ssh/id_dsa to the list of registered SSH keys in 
your Sourceforge account." (There's a form for this, you don't need to 
copy files to a directory anywhere.) I can prepare more detailed 
step-by-step instructions later (it's very simple... I mean hell, *I* 
figured it out!).

Cheers,

G

On 19/06/2012 22:33, Kevin Hawkins wrote:
> All,
>
> I'm about to adjust tcw22 based on this and a few more emails sent in
> the past few days to make the instructions clearer.  Notes below,
> including some questions for Gabby and requests from anyone for
> clarification ...
>
> On 6/18/12 1:34 PM, Gabriel BODARD wrote:
>> 2. Version numbers updated. (I had to stop and think for a moment
>> whether I was supposed to be updated the -fr version as well. Obviously
>> yes, but just to note that with current wording I wondered.)
>
> I'm not sure how to improve on the current wording.  Could you suggest
> something?
>
>> 4. Debian changelogs: the changelog files don't exist where they are
>> listed in the sbs. I now understand that this is automated in Jenkins...
>> so this point should be deleted from the doc.
>
> I've commented it out (and added a comment explaining that Jenkins now
> does it).
>
>> 7. This all seems okay to me, but I think the item in the doc could be
>> spelled out a bit more explicitly what to look for.
>
> Suggestions?
>
>> 8. Apparent problem with instructions in this item:
>>
>> svnUp.sh runs as written, but
>> tei-install.sh needs the "sh" command before it. (Does this mean it is
>> not executable?) Either that needs to be changed, or the instructions.
>> (Note: James has already fixed the file so it is executable by user.)
>
> Right, the problem was that it's not executable.  I hesitate to insert
> the "sh" command because maybe the script was written to assume you use
> csh or bash or something.  Best to leave the instructions as they are,
> in my opinion.
>
>> Also: Sourceforge denied me permission to make the release at this step.
>> We need to add a note that the user needs to add the public key from
>> /home/tei/.ssh/id_dsa to their Sourceforge account before they can rsync
>> the release zip. This probably belongs in the "What you need" section at
>> the top of tcw22.
>
> So I could add this to the "what you need" section:
>
> * A copy of public key from tei-c.org:/home/tei/.ssh/id_dsa at ~/.ssh/
> in your Sourceforge account's home directly. This is need to rsync the
> release zip.
>
> Is that correct?  It seems to me that if you use your SF for anything
> else, this could overwrite keypairs that you might have on file.  But I
> guess if you're that advanced, you'll know how to do this properly.
> Still, I recommend suggestions on a better way to do this.
>
>> 10. Defaults set. Fine. (Instructions could be clearer--I've done this
>> before for other projects, but if not I might not have known where to look.)
>
> Can you suggest a clarification?
>
>> 12. Sebastian informed that debian can be released.
>>
>> 13. Sebastian informed that oxygen-tei can be updated.
>>
>> 14. Checking TEI website and downloads. (I wonder we shouldn't do this
>> check before the previous two, and maybe before 10 as well. If there's a
>> problem with the website we may have to start again.)
>
> If someone tells me to move this step, I will gladly do it.
>
> --Kevin
>

-- 
Dr Gabriel BODARD
(Research Associate in Digital Epigraphy)

Department of Digital Humanities
King's College London
26-29 Drury Lane
London WC2B 5RL

Email: gabriel.bodard at kcl.ac.uk
Tel: +44 (0)20 7848 1388
Fax: +44 (0)20 7848 2980

http://www.digitalclassicist.org/
http://www.currentepigraphy.org/



From sebastian.rahtz at oucs.ox.ac.uk  Wed Jun 20 08:54:30 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Wed, 20 Jun 2012 12:54:30 +0000
Subject: [tei-council] P5 test files
Message-ID: <7FFA13B3-8117-4B82-8841-D59346031297@oucs.ox.ac.uk>

stung by Martin and Gaby whinging, I pruned and combined the test files a fair bit just now.

there is a basic container, testbasic.{odd,xml} which you should add tests to if you can;
detest.{odd,xml} is for tests which should fail.

--
Sebastian Rahtz      
Head of Information and Support Group
Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431

S?lo le pido a Dios
que el futuro no me sea indiferente


From mholmes at uvic.ca  Wed Jun 20 08:54:50 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Wed, 20 Jun 2012 05:54:50 -0700
Subject: [tei-council] Order of release steps
Message-ID: <4FE1C81A.3080300@uvic.ca>

I woke at 4am with an attack of the bleedin obvious.

It seems to me that the first actions following the SVN freeze and the 
update of the version number by the release technician should be the 
update of the Debian packages. We should add a step to the effect that 
the new Debian packages should be installed on the Jenkins boxes, then a 
new build should be triggered. This should guarantee that the final 
release build is built with the latest version of all the Stylesheets 
code and scripts.

Then the rest of the release should go ahead.

I think several people, including release technicians, will have to have 
the right to trigger new builds on Jenkins boxes. That's easy to do.

Cheers,
Martin

From sebastian.rahtz at oucs.ox.ac.uk  Wed Jun 20 08:58:01 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Wed, 20 Jun 2012 12:58:01 +0000
Subject: [tei-council] Order of release steps
In-Reply-To: <4FE1C81A.3080300@uvic.ca>
References: <4FE1C81A.3080300@uvic.ca>
Message-ID: <A81085D1-6815-4C1B-92B3-92AA12034C06@oucs.ox.ac.uk>


On 20 Jun 2012, at 13:54, Martin Holmes wrote:

> It seems to me that the first actions following the SVN freeze and the 
> update of the version number by the release technician should be the 
> update of the Debian packages. We should add a step to the effect that 
> the new Debian packages should be installed on the Jenkins boxes, then a 
> new build should be triggered. 

um

a) what if the release process finds an error?

b) this implies a dependency on the Debian maintainer (me). not good?..
--
Sebastian Rahtz      
Head of Information and Support Group
Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431

S?lo le pido a Dios
que el futuro no me sea indiferente


From lou.burnard at retired.ox.ac.uk  Wed Jun 20 09:26:47 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Wed, 20 Jun 2012 14:26:47 +0100
Subject: [tei-council] Order of release steps
In-Reply-To: <4FE1C81A.3080300@uvic.ca>
References: <4FE1C81A.3080300@uvic.ca>
Message-ID: <4FE1CF97.1060709@retired.ox.ac.uk>

On 20/06/12 13:54, Martin Holmes wrote:
> I woke at 4am with an attack of the bleedin obvious.

You probably want to forego that extra helping of cheese after dinner...
>
> It seems to me that the first actions following the SVN freeze and the
> update of the version number by the release technician should be the
> update of the Debian packages.

Eh? Shurely this is backwards? The deb packages are a way of 
distributing the release, argal they are a version of it, argal they 
can't be created until it is finalised, in all its raging glory.

It's true that we use the deb packages to build the build environment 
(such is the glorious recursivity of the tei) but conceptually at least, 
we should be using the packages from release n-1 to build release.


From mholmes at uvic.ca  Wed Jun 20 11:04:22 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Wed, 20 Jun 2012 08:04:22 -0700
Subject: [tei-council] @min and @max
In-Reply-To: <BB564121-8C8C-4F54-8897-2621D86B5093@oucs.ox.ac.uk>
References: <4FE0D8C2.3070609@uvic.ca>
	<BB564121-8C8C-4F54-8897-2621D86B5093@oucs.ox.ac.uk>
Message-ID: <4FE1E676.6030202@uvic.ca>

OK, so we would now expect this test to fail. How is that failure 
handled? I was under the impression that all tests expected to fail were 
in detest.xml, and the failure was handled by putting the expected error 
messages into expected-results/detest.log. But in the latest revision of 
that file shows no error regarding the @min and @max constraints here 
(which is as expected, because this test isn't in detest.xml).

Is this expected failure handled by editing the hudson-log-parse-rules 
such that the error message resulting from the failure is flagged as OK? 
If so, that means only someone with Jenkins powers can add such 
constraints to the system.

Cheers,
Martin

On 12-06-20 12:31 AM, Sebastian Rahtz wrote:
> the truth is that this is only part of the picture. the content model of<lg>  has also to be changed to ask
> for model.lLike_sequence in order for the @min and @max test to have an effect. If you look at the schema,
> it comes out with
>
> model.lLike = l | l | l? | l? | l? | l?
> model.lLike_alternation = l | l | l? | l? | l? | l?
> model.lLike_sequence = l, l, l?, l?, l?, l?
> model.lLike_sequenceOptional = (l, l, l?, l?, l?, l?)?
> model.lLike_sequenceOptionalRepeatable = (l, l, l?, l?, l?, l?)*
> model.lLike_sequenceRepeatable = (l, l, l?, l?, l?, l?)+
>
> where you can see why the standard model.lLike does not do the job.
>
> so now you should watch P5 build fail :-}
> --
> Sebastian Rahtz
> Head of Information and Support Group
> Oxford University Computing Services
> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>
>
>
>
>
>
> .
>

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From mholmes at uvic.ca  Wed Jun 20 11:08:17 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Wed, 20 Jun 2012 08:08:17 -0700
Subject: [tei-council] P5 test files
In-Reply-To: <7FFA13B3-8117-4B82-8841-D59346031297@oucs.ox.ac.uk>
References: <7FFA13B3-8117-4B82-8841-D59346031297@oucs.ox.ac.uk>
Message-ID: <4FE1E761.6080903@uvic.ca>

On 12-06-20 05:54 AM, Sebastian Rahtz wrote:
> stung by Martin and Gaby whinging, I pruned and combined the test files a fair bit just now.
>
> there is a basic container, testbasic.{odd,xml} which you should add tests to if you can;
> detest.{odd,xml} is for tests which should fail.

This is great. I'll document this in detail with some examples, for the 
"How to Edit the Guidelines" document. Does anyone have any ideas for 
tests which I could add as part of the example process?

Cheers,
Martin

> --
> Sebastian Rahtz
> Head of Information and Support Group
> Oxford University Computing Services
> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>
> S?lo le pido a Dios
> que el futuro no me sea indiferente
>

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From mholmes at uvic.ca  Wed Jun 20 11:13:21 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Wed, 20 Jun 2012 08:13:21 -0700
Subject: [tei-council] Order of release steps
In-Reply-To: <A81085D1-6815-4C1B-92B3-92AA12034C06@oucs.ox.ac.uk>
References: <4FE1C81A.3080300@uvic.ca>
	<A81085D1-6815-4C1B-92B3-92AA12034C06@oucs.ox.ac.uk>
Message-ID: <4FE1E891.1070303@uvic.ca>

On 12-06-20 05:58 AM, Sebastian Rahtz wrote:
>
> On 20 Jun 2012, at 13:54, Martin Holmes wrote:
>
>> It seems to me that the first actions following the SVN freeze and the
>> update of the version number by the release technician should be the
>> update of the Debian packages. We should add a step to the effect that
>> the new Debian packages should be installed on the Jenkins boxes, then a
>> new build should be triggered.
>
> um
>
> a) what if the release process finds an error?

It's better to find an error in the Stylesheets/deb packages BEFORE we 
try to release anything else, because everything else depends on them 
(see the mess we got into with profile=readme this time around). Once we 
know the debs are OK, and are installed on Jinks, we know that when we 
build the final product, it will be built with the latest codebase. If 
in building the P5 jobs after that we get an error which arises out of 
the deb packages or Stylesheets, then obviously we have to go back and 
fix that before starting again.

> b) this implies a dependency on the Debian maintainer (me). not good?..

We have this anyway. It is definitely not good, but this at least gets 
your part out of the way first, before the rest goes ahead.

That said, we need to make some serious decisions about the dependency 
on the deb packages. I'd really like to find a way to make it go away if 
possible, at least on the Jinks boxes, so that we don't have this 
circularity of dependency.

Cheers,
Martin


> --
> Sebastian Rahtz
> Head of Information and Support Group
> Oxford University Computing Services
> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>
> S?lo le pido a Dios
> que el futuro no me sea indiferente
>
>

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From mholmes at uvic.ca  Wed Jun 20 11:17:12 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Wed, 20 Jun 2012 08:17:12 -0700
Subject: [tei-council] Order of release steps
In-Reply-To: <4FE1CF97.1060709@retired.ox.ac.uk>
References: <4FE1C81A.3080300@uvic.ca> <4FE1CF97.1060709@retired.ox.ac.uk>
Message-ID: <4FE1E978.7040907@uvic.ca>

Blast, I forgot that the actual products are also in the deb packages. I 
was thinking of them only being the required scripts (teitohtml etc.).

This is more messed up than I thought it was, then. We can't do 
everything without doing everything first. We have to build and install 
the deb packages, then build the products with them, then build and 
distribute new versions of the deb packages.

In which case, the real requirement is to make it possible for Jinks to 
build the products without any dependency on the installed deb packages 
at all. That's what Sebastian started trying to do the other day, but 
gave up. But that's where we have to go, I think.

Cheers,
Martin

On 12-06-20 06:26 AM, Lou Burnard wrote:
> On 20/06/12 13:54, Martin Holmes wrote:
>> I woke at 4am with an attack of the bleedin obvious.
>
> You probably want to forego that extra helping of cheese after dinner...
>>
>> It seems to me that the first actions following the SVN freeze and the
>> update of the version number by the release technician should be the
>> update of the Debian packages.
>
> Eh? Shurely this is backwards? The deb packages are a way of
> distributing the release, argal they are a version of it, argal they
> can't be created until it is finalised, in all its raging glory.
>
> It's true that we use the deb packages to build the build environment
> (such is the glorious recursivity of the tei) but conceptually at least,
> we should be using the packages from release n-1 to build release.
>

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From sebastian.rahtz at oucs.ox.ac.uk  Wed Jun 20 11:18:20 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Wed, 20 Jun 2012 15:18:20 +0000
Subject: [tei-council] P5 test files
In-Reply-To: <4FE1E761.6080903@uvic.ca>
References: <7FFA13B3-8117-4B82-8841-D59346031297@oucs.ox.ac.uk>
	<4FE1E761.6080903@uvic.ca>
Message-ID: <9CCF8497-212A-4E20-869E-CF63B1E02CB7@oucs.ox.ac.uk>


On 20 Jun 2012, at 16:08, Martin Holmes wrote:

> 
> This is great. I'll document this in detail with some examples, for the "How to Edit the Guidelines" document.

good.

the message should be that there are four sets which you use for
adding tests to

	testbare.{odd,xml}:   small possible schema
	testbasic.{odd,xml}:  typical TEI schema with customizations of all kinds, the place to add new tests
	testplus.{odd,xml}:    an extremist schema which includes all modules, XInclude SVG, Math, ITS etc
	detest.{odd,xml}:       things that fail, ie constraints and deliberate mistakes. you must update the expected results if you add to this

there are another dozen more specialized tests which you probably should leave like sleeping dogs.
--
Sebastian Rahtz      
Head of Information and Support Group
Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431

S?lo le pido a Dios
que el futuro no me sea indiferente


From sebastian.rahtz at oucs.ox.ac.uk  Wed Jun 20 11:20:10 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Wed, 20 Jun 2012 15:20:10 +0000
Subject: [tei-council] Order of release steps
In-Reply-To: <4FE1E891.1070303@uvic.ca>
References: <4FE1C81A.3080300@uvic.ca>
	<A81085D1-6815-4C1B-92B3-92AA12034C06@oucs.ox.ac.uk>
	<4FE1E891.1070303@uvic.ca>
Message-ID: <7352B149-BFB9-4736-9356-5C381A03FBC1@oucs.ox.ac.uk>

surely the moral is "dont tinker with Stylesheets at the same time as making a release"? we only got bit here cos
Lou rashly (understandably) suddenly added a dependency on something he only added to Stylesheets 5 minutes before.
thats not normal.
--
Sebastian Rahtz      
Head of Information and Support Group
Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431

S?lo le pido a Dios
que el futuro no me sea indiferente


From sebastian.rahtz at oucs.ox.ac.uk  Wed Jun 20 11:22:05 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Wed, 20 Jun 2012 15:22:05 +0000
Subject: [tei-council] @min and @max
In-Reply-To: <4FE1E676.6030202@uvic.ca>
References: <4FE0D8C2.3070609@uvic.ca>
	<BB564121-8C8C-4F54-8897-2621D86B5093@oucs.ox.ac.uk>
	<4FE1E676.6030202@uvic.ca>
Message-ID: <D161297C-20F0-4EE3-AE19-EA912B46C2BB@oucs.ox.ac.uk>


On 20 Jun 2012, at 16:04, Martin Holmes wrote:

> OK, so we would now expect this test to fail. How is that failure handled? I was under the impression that all tests expected to fail were in detest.xml, and the failure was handled by putting the expected error messages into expected-results/detest.log. But in the latest revision of that file shows no error regarding the @min and @max constraints here (which is as expected, because this test isn't in detest.xml).
> 
it is now?

i have changed loads stuff here

--
Sebastian Rahtz      
Head of Information and Support Group
Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431

S?lo le pido a Dios
que el futuro no me sea indiferente


From lou.burnard at retired.ox.ac.uk  Wed Jun 20 11:26:02 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Wed, 20 Jun 2012 16:26:02 +0100
Subject: [tei-council] Order of release steps
In-Reply-To: <7352B149-BFB9-4736-9356-5C381A03FBC1@oucs.ox.ac.uk>
References: <4FE1C81A.3080300@uvic.ca>
	<A81085D1-6815-4C1B-92B3-92AA12034C06@oucs.ox.ac.uk>
	<4FE1E891.1070303@uvic.ca>
	<7352B149-BFB9-4736-9356-5C381A03FBC1@oucs.ox.ac.uk>
Message-ID: <4FE1EB8A.1060808@retired.ox.ac.uk>

On 20/06/12 16:20, Sebastian Rahtz wrote:
> surely the moral is "dont tinker with Stylesheets at the same time as making a release"? we only got bit here cos
> Lou rashly (understandably) suddenly added a dependency on something he only added to Stylesheets 5 minutes before.
> thats not normal.
> --

... indeed. but it's not that I added a dependency, it's because people 
suddenly noticed something they didn't like in the stylesheet doing the 
conversion of the release notes. something would have had to be changed 
to resolve that, whether or not by means of the documented "profiles" 
mechanism.

incidentally, are we now generating a plain text readme for inclusion in 
the debian packages automagically?



From sebastian.rahtz at oucs.ox.ac.uk  Wed Jun 20 11:30:38 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Wed, 20 Jun 2012 15:30:38 +0000
Subject: [tei-council] Order of release steps
In-Reply-To: <4FE1EB8A.1060808@retired.ox.ac.uk>
References: <4FE1C81A.3080300@uvic.ca>
	<A81085D1-6815-4C1B-92B3-92AA12034C06@oucs.ox.ac.uk>
	<4FE1E891.1070303@uvic.ca>
	<7352B149-BFB9-4736-9356-5C381A03FBC1@oucs.ox.ac.uk>
	<4FE1EB8A.1060808@retired.ox.ac.uk>
Message-ID: <a3cab992-2f5b-4c1c-866b-078287351483@HUB05.ad.oak.ox.ac.uk>


On 20 Jun 2012, at 16:26, Lou Burnard wrote:

> ... indeed. but it's not that I added a dependency,
well, you added a dependency on a new profile

> it's because people 
> suddenly noticed something they didn't like in the stylesheet doing the 
> conversion of the release notes. something would have had to be changed 
> to resolve that, whether or not by means of the documented "profiles" 
> mechanism.

'strue. it may not be sensible to use the public stable (!) stylesheets in this way

> 
> incidentally, are we now generating a plain text readme for inclusion in 
> the debian packages automagically?
> 
lord knows

--
Sebastian Rahtz      
Head of Information and Support Group
Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431

S?lo le pido a Dios
que el futuro no me sea indiferente


From mholmes at uvic.ca  Wed Jun 20 11:34:53 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Wed, 20 Jun 2012 08:34:53 -0700
Subject: [tei-council] P5 test files
In-Reply-To: <9CCF8497-212A-4E20-869E-CF63B1E02CB7@oucs.ox.ac.uk>
References: <7FFA13B3-8117-4B82-8841-D59346031297@oucs.ox.ac.uk>
	<4FE1E761.6080903@uvic.ca>
	<9CCF8497-212A-4E20-869E-CF63B1E02CB7@oucs.ox.ac.uk>
Message-ID: <4FE1ED9D.2000506@uvic.ca>

On 12-06-20 08:18 AM, Sebastian Rahtz wrote:
>
> On 20 Jun 2012, at 16:08, Martin Holmes wrote:
>
>>
>> This is great. I'll document this in detail with some examples, for the "How to Edit the Guidelines" document.
>
> good.
>
> the message should be that there are four sets which you use for
> adding tests to
>
> 	testbare.{odd,xml}:   small possible schema
> 	testbasic.{odd,xml}:  typical TEI schema with customizations of all kinds, the place to add new tests
> 	testplus.{odd,xml}:    an extremist schema which includes all modules, XInclude SVG, Math, ITS etc
> 	detest.{odd,xml}:       things that fail, ie constraints and deliberate mistakes. you must update the expected results if you add to this

I'll try to create examples for all four scenarios (or perhaps just pick 
one from each to explain in detail -- given that I whinged about P5-Test 
taking so long, I should probably not invent novel tests just for the 
purposes of documentation).

> there are another dozen more specialized tests which you probably should leave like sleeping dogs.

This is the sort of thing that wakes me up at 4am (cheese is innocent).

Cheers,
Martin

> --
> Sebastian Rahtz
> Head of Information and Support Group
> Oxford University Computing Services
> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>
> S?lo le pido a Dios
> que el futuro no me sea indiferente
>
> .
>

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From mholmes at uvic.ca  Wed Jun 20 11:44:30 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Wed, 20 Jun 2012 08:44:30 -0700
Subject: [tei-council] Order of release steps
In-Reply-To: <7352B149-BFB9-4736-9356-5C381A03FBC1@oucs.ox.ac.uk>
References: <4FE1C81A.3080300@uvic.ca>
	<A81085D1-6815-4C1B-92B3-92AA12034C06@oucs.ox.ac.uk>
	<4FE1E891.1070303@uvic.ca>
	<7352B149-BFB9-4736-9356-5C381A03FBC1@oucs.ox.ac.uk>
Message-ID: <4FE1EFDE.1040602@uvic.ca>

On 12-06-20 08:20 AM, Sebastian Rahtz wrote:
> surely the moral is "dont tinker with Stylesheets at the same time as making a release"? we only got bit here cos
> Lou rashly (understandably) suddenly added a dependency on something he only added to Stylesheets 5 minutes before.
> thats not normal.

True, but unless we have a new build of the deb packages to build with, 
we're building the latest product with an out-of-date version of the deb 
package scripts. They may well not have changed recently, so we get away 
with it, but that's certainly not guaranteed.

Let's say, for instance, that at some point you make a change to teitohtml.

  - In order for that change to be incorporated in a release, it needs 
to be in the deb packages on the Jenkins servers, because when building 
P5 products, Jenkins still uses the teitohtml script which is in the deb 
packages, not the one from SVN.

  - In order to be in the deb packages, the deb packages have to be 
built and released, and updated on Jinks.

  - When they are built and released, they include a complete copy of 
the current state of the P5 products -- which is not a final release; 
it's an interim build. This interim build goes out into the wild to 
every user of deb packages.

   - Then once those deb packages are installed on Jinks, we can build 
the release packages using the changed teitohtml, and then release; but 
at that point, the deb packages have to be built and released again, so 
that they include a fresh build of the P5 products created with the new 
teitohtml.

This is clearly not ideal. And it's a problem that only really exists 
because the Jenkins servers are still dependent on the deb packages to 
build, rather than being able to build P5 products using the latest 
copies of everything (including eg teitohtml) from SVN. I think it's 
worth having another serious attempt at doing what you tried the other day.

If I'm still misunderstanding something in the process above, my apologies.

Cheers,
Martin

> --
> Sebastian Rahtz
> Head of Information and Support Group
> Oxford University Computing Services
> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>
> S?lo le pido a Dios
> que el futuro no me sea indiferente
>
>

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From lou.burnard at retired.ox.ac.uk  Wed Jun 20 11:46:49 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Wed, 20 Jun 2012 16:46:49 +0100
Subject: [tei-council] Order of release steps
In-Reply-To: <A0175BA3-388D-41FC-AC55-A83271AE2D9A@oucs.ox.ac.uk>
References: <4FE1C81A.3080300@uvic.ca>
	<A81085D1-6815-4C1B-92B3-92AA12034C06@oucs.ox.ac.uk>
	<4FE1E891.1070303@uvic.ca>
	<7352B149-BFB9-4736-9356-5C381A03FBC1@oucs.ox.ac.uk>
	<4FE1EB8A.1060808@retired.ox.ac.uk>
	<A0175BA3-388D-41FC-AC55-A83271AE2D9A@oucs.ox.ac.uk>
Message-ID: <4FE1F069.7010602@retired.ox.ac.uk>

On 20/06/12 16:30, Sebastian Rahtz wrote:
>
> 'strue. it may not be sensible to use the public stable (!) stylesheets in this way
>

would it be more sensible to have a hard wired stylesheet to do it? do 
the conversion outside the jenkins job?


>> incidentally, are we now generating a plain text readme for inclusion in
>> the debian packages automagically?
>>
> lord knows

if not, cant really see the point of generating the HTML one

From sebastian.rahtz at oucs.ox.ac.uk  Wed Jun 20 11:56:25 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Wed, 20 Jun 2012 15:56:25 +0000
Subject: [tei-council] Order of release steps
In-Reply-To: <4FE1EFDE.1040602@uvic.ca>
References: <4FE1C81A.3080300@uvic.ca>
	<A81085D1-6815-4C1B-92B3-92AA12034C06@oucs.ox.ac.uk>
	<4FE1E891.1070303@uvic.ca>
	<7352B149-BFB9-4736-9356-5C381A03FBC1@oucs.ox.ac.uk>
	<4FE1EFDE.1040602@uvic.ca>
Message-ID: <1C414BBB-EF2C-4C48-9247-F9E31302101D@oucs.ox.ac.uk>


On 20 Jun 2012, at 16:44, Martin Holmes wrote:
> 
> True, but unless we have a new build of the deb packages to build with, we're building the latest product with an out-of-date version of the deb package scripts. They may well not have changed recently, so we get away with it, but that's certainly not guaranteed.
> 

well, we're building a latest P5 with (possibly) an older version of Stylesheets. Inevitably

> Let's say, for instance, that at some point you make a change to teitohtml.
in the other package, yes

> 
> - In order for that change to be incorporated in a release, it needs to be in the deb packages on the Jenkins servers, because when building P5 products, Jenkins still uses the teitohtml script which is in the deb packages, not the one from SVN.
> 
true. 

> - In order to be in the deb packages, the deb packages have to be built and released, and updated on Jinks.
> 
true

> - When they are built and released, they include a complete copy of the current state of the P5 products -- which is not a final release; it's an interim build. This interim build goes out into the wild to every user of deb packages.
> 
no, not true. the Stylesheets deb release has nothing to do with P5 release, and has no copy of P5 in

I honestly think you're inventing a crisis when there is none. Two _different_, _distinct_ packages are being worked on by the same
people, and one uses the other to do its job. Sometimes we get in a mess, it happens.
--
Sebastian Rahtz      
Head of Information and Support Group
Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431

S?lo le pido a Dios
que el futuro no me sea indiferente


From gabriel.bodard at kcl.ac.uk  Wed Jun 20 11:56:01 2012
From: gabriel.bodard at kcl.ac.uk (Gabriel BODARD)
Date: Wed, 20 Jun 2012 16:56:01 +0100
Subject: [tei-council] Order of release steps
In-Reply-To: <4FE1EFDE.1040602@uvic.ca>
References: <4FE1C81A.3080300@uvic.ca>
	<A81085D1-6815-4C1B-92B3-92AA12034C06@oucs.ox.ac.uk>
	<4FE1E891.1070303@uvic.ca>
	<7352B149-BFB9-4736-9356-5C381A03FBC1@oucs.ox.ac.uk>
	<4FE1EFDE.1040602@uvic.ca>
Message-ID: <4FE1F291.4090107@kcl.ac.uk>

Maybe I'm missing something here (well, I certainly am, but sometimes 
naivet? can lead to valid suggestions) but is the answer not as simple 
as to freeze development, say 24 hours before starting the release, so 
that both the debian packages and all the other TEI materials can be 
generated in this stable time, then the release itself only involves 
changing the version numbers, waiting, testing, and pushing live?

On 20/06/2012 16:44, Martin Holmes wrote:
> True, but unless we have a new build of the deb packages to build with,
> we're building the latest product with an out-of-date version of the deb
> package scripts. They may well not have changed recently, so we get away
> with it, but that's certainly not guaranteed.
>
> Let's say, for instance, that at some point you make a change to teitohtml.
>
>    - In order for that change to be incorporated in a release, it needs
> to be in the deb packages on the Jenkins servers, because when building
> P5 products, Jenkins still uses the teitohtml script which is in the deb
> packages, not the one from SVN.
>
>    - In order to be in the deb packages, the deb packages have to be
> built and released, and updated on Jinks.
>
>    - When they are built and released, they include a complete copy of
> the current state of the P5 products -- which is not a final release;
> it's an interim build. This interim build goes out into the wild to
> every user of deb packages.
>
>     - Then once those deb packages are installed on Jinks, we can build
> the release packages using the changed teitohtml, and then release; but
> at that point, the deb packages have to be built and released again, so
> that they include a fresh build of the P5 products created with the new
> teitohtml.
>
> This is clearly not ideal. And it's a problem that only really exists
> because the Jenkins servers are still dependent on the deb packages to
> build, rather than being able to build P5 products using the latest
> copies of everything (including eg teitohtml) from SVN. I think it's
> worth having another serious attempt at doing what you tried the other day.
>
> If I'm still misunderstanding something in the process above, my apologies.
>
> Cheers,
> Martin
>
>> --
>> Sebastian Rahtz
>> Head of Information and Support Group
>> Oxford University Computing Services
>> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>>
>> S?lo le pido a Dios
>> que el futuro no me sea indiferente
>>
>>
>

-- 
Dr Gabriel BODARD
(Research Associate in Digital Epigraphy)

Department of Digital Humanities
King's College London
26-29 Drury Lane
London WC2B 5RL

Email: gabriel.bodard at kcl.ac.uk
Tel: +44 (0)20 7848 1388
Fax: +44 (0)20 7848 2980

http://www.digitalclassicist.org/
http://www.currentepigraphy.org/



From mholmes at uvic.ca  Wed Jun 20 13:14:40 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Wed, 20 Jun 2012 10:14:40 -0700
Subject: [tei-council] Order of release steps
In-Reply-To: <1C414BBB-EF2C-4C48-9247-F9E31302101D@oucs.ox.ac.uk>
References: <4FE1C81A.3080300@uvic.ca>
	<A81085D1-6815-4C1B-92B3-92AA12034C06@oucs.ox.ac.uk>
	<4FE1E891.1070303@uvic.ca>
	<7352B149-BFB9-4736-9356-5C381A03FBC1@oucs.ox.ac.uk>
	<4FE1EFDE.1040602@uvic.ca>
	<1C414BBB-EF2C-4C48-9247-F9E31302101D@oucs.ox.ac.uk>
Message-ID: <4FE20500.8010404@uvic.ca>

On 12-06-20 08:56 AM, Sebastian Rahtz wrote:
>
> On 20 Jun 2012, at 16:44, Martin Holmes wrote:
>>
>> True, but unless we have a new build of the deb packages to build
>> with, we're building the latest product with an out-of-date version
>> of the deb package scripts. They may well not have changed
>> recently, so we get away with it, but that's certainly not
>> guaranteed.
>>
>
> well, we're building a latest P5 with (possibly) an older version of
> Stylesheets. Inevitably
>
>> Let's say, for instance, that at some point you make a change to
>> teitohtml.
> in the other package, yes
>
>>
>> - In order for that change to be incorporated in a release, it
>> needs to be in the deb packages on the Jenkins servers, because
>> when building P5 products, Jenkins still uses the teitohtml script
>> which is in the deb packages, not the one from SVN.
>>
> true.
>
>> - In order to be in the deb packages, the deb packages have to be
>> built and released, and updated on Jinks.
>>
> true
>
>> - When they are built and released, they include a complete copy of
>> the current state of the P5 products -- which is not a final
>> release; it's an interim build. This interim build goes out into
>> the wild to every user of deb packages.
>>
> no, not true. the Stylesheets deb release has nothing to do with P5
> release, and has no copy of P5 in

I was assuming a release of the deb packages would include all of them, 
and as Lou says,

> The deb packages are a way of distributing the release, argal they
> are a version of it, argal they can't be created until it is
> finalised, in all its raging glory.

tei-p5-schema.deb, for instance, includes all the schemas 
(/usr/share/xml/tei/schema...)

But if you're saying that the only packages that get updated initially 
for Jinks are the Stylesheets packages, which contain none of the 
schemas or documentation, then that problem goes away. The stylesheets 
packages get released first, then the main products are built, then the 
rest of the debs are released.

> I honestly think you're inventing a crisis when there is none. Two
> _different_, _distinct_ packages are being worked on by the same
> people, and one uses the other to do its job. Sometimes we get in a
> mess, it happens.

OK, I'll shut up then.

Cheers,
Martin

  -- Sebastian Rahtz Head of Information and Support
> Group Oxford University Computing Services 13 Banbury Road, Oxford
> OX2 6NN. Phone +44 1865 283431
>
> S?lo le pido a Dios que el futuro no me sea indiferente
>
> .
>

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From lou.burnard at retired.ox.ac.uk  Wed Jun 20 14:44:57 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Wed, 20 Jun 2012 19:44:57 +0100
Subject: [tei-council] @facs on graphic
Message-ID: <4FE21A29.1030905@retired.ox.ac.uk>

Just checking up on something for another project and I notice that the 
<graphic> element, being a member of att.global, will get @facs when the 
transcription module is loaded.

How do we explain that? More specifically if I say

<zone><graphic url="foo.png" facs="foo2.png"/></zone>

inside a <sourceDoc> somewhere, what on earth does it mean?


From kevin.s.hawkins at ultraslavonic.info  Wed Jun 20 14:55:23 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Wed, 20 Jun 2012 14:55:23 -0400
Subject: [tei-council] @facs on graphic
In-Reply-To: <4FE21A29.1030905@retired.ox.ac.uk>
References: <4FE21A29.1030905@retired.ox.ac.uk>
Message-ID: <4FE21C9B.7030603@ultraslavonic.info>

On 6/20/2012 2:44 PM, Lou Burnard wrote:
> Just checking up on something for another project and I notice that the
> <graphic>  element, being a member of att.global, will get @facs when the
> transcription module is loaded.
>
> How do we explain that? More specifically if I say
>
> <zone><graphic url="foo.png" facs="foo2.png"/></zone>
>
> inside a<sourceDoc>  somewhere, what on earth does it mean?

You wrote att.global, but did you mean att.global.facs?  This seems to 
be the case not just with the transcription module but also with core.

How about we soft-deprecate graphic at url in favor of graphic at facs?  (That 
is, we don't yet put graphic at url on a timeline for removal, but we also 
change the Guidelines to always recommend @facs instead of @url.)

--Kevin

From sebastian.rahtz at oucs.ox.ac.uk  Wed Jun 20 15:45:33 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Wed, 20 Jun 2012 19:45:33 +0000
Subject: [tei-council] @facs on graphic
In-Reply-To: <4FE21A29.1030905@retired.ox.ac.uk>
References: <4FE21A29.1030905@retired.ox.ac.uk>
Message-ID: <3f9a3094-3e8c-485e-8d1e-1d3612302b93@HUB03.ad.oak.ox.ac.uk>


On 20 Jun 2012, at 19:44, Lou Burnard wrote:

> Just checking up on something for another project and I notice that the 
> <graphic> element, being a member of att.global, will get @facs when the 
> transcription module is loaded.
> 
> How do we explain that? More specifically if I say
> 
> <zone><graphic url="foo.png" facs="foo2.png"/></zone>
> 
> inside a <sourceDoc> somewhere, what on earth does it mean?
> 
in that case, nothing. but I can imagine graphic with @url
and @facs in the <text>, just about.

but there are surely few points to be got by making up examples
of TEI markup which are meaningless...

--
Sebastian Rahtz      
Head of Information and Support Group
Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431







From sebastian.rahtz at oucs.ox.ac.uk  Wed Jun 20 15:45:33 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Wed, 20 Jun 2012 19:45:33 +0000
Subject: [tei-council] @facs on graphic
In-Reply-To: <4FE21C9B.7030603@ultraslavonic.info>
References: <4FE21A29.1030905@retired.ox.ac.uk>
	<4FE21C9B.7030603@ultraslavonic.info>
Message-ID: <ABC2E044-0DDC-4E52-9C1B-43C14BB4E874@oucs.ox.ac.uk>


On 20 Jun 2012, at 19:55, Kevin Hawkins wrote:

> 
> How about we soft-deprecate graphic at url in favor of graphic at facs?  (That 
> is, we don't yet put graphic at url on a timeline for removal, but we also 
> change the Guidelines to always recommend @facs instead of @url.)
> 

aargh no, please. @facs generally points to a container which contains
a graphic, so that way madness lies. The shorthand of @facs pointing to
an external graphics file is an aberration which I'd be reluctant to build on.

As I said, I claim
  <graphic url="foo.png" facs="#area52"/>
is a possibly valid bit of markup.

--
Sebastian Rahtz      
Head of Information and Support Group
Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431







From sebastian.rahtz at oucs.ox.ac.uk  Wed Jun 20 15:45:33 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Wed, 20 Jun 2012 19:45:33 +0000
Subject: [tei-council] Order of release steps
In-Reply-To: <4FE20500.8010404@uvic.ca>
References: <4FE1C81A.3080300@uvic.ca>
	<A81085D1-6815-4C1B-92B3-92AA12034C06@oucs.ox.ac.uk>
	<4FE1E891.1070303@uvic.ca>
	<7352B149-BFB9-4736-9356-5C381A03FBC1@oucs.ox.ac.uk>
	<4FE1EFDE.1040602@uvic.ca>
	<1C414BBB-EF2C-4C48-9247-F9E31302101D@oucs.ox.ac.uk>
	<4FE20500.8010404@uvic.ca>
Message-ID: <51033F91-A330-4D4D-B40E-8C2024C74FCF@oucs.ox.ac.uk>


On 20 Jun 2012, at 18:14, Martin Holmes wrote:
>> no, not true. the Stylesheets deb release has nothing to do with P5
>> release, and has no copy of P5 in
> 
> I was assuming a release of the deb packages would include all of them, and as Lou says,
> 
this seems to be where the confusion lies. There are 6 debian packages in P5, and 3 in Stylesheets.
I can release these into the wild in whatever granularity I like. I'd normally do the 3 XSL together,
and the 6 P5 together, but seldom all at once.

> 
> tei-p5-schema.deb, for instance, includes all the schemas (/usr/share/xml/tei/schema...)
> 
it does, but that ones of the P5 ones, not XSL.

the rule is: if you're gonna mess with the XSL at the same time as the P5 release,
because you need some change in the XSL to get the P5 working (as we had here),
you'd better be prepared to divert from the scripted methods.
--
Sebastian Rahtz      
Head of Information and Support Group
Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431







From gabriel.bodard at kcl.ac.uk  Wed Jun 20 16:10:04 2012
From: gabriel.bodard at kcl.ac.uk (Gabriel BODARD)
Date: Wed, 20 Jun 2012 21:10:04 +0100
Subject: [tei-council] @facs on graphic
In-Reply-To: <ABC2E044-0DDC-4E52-9C1B-43C14BB4E874@oucs.ox.ac.uk>
References: <4FE21A29.1030905@retired.ox.ac.uk>
	<4FE21C9B.7030603@ultraslavonic.info>
	<ABC2E044-0DDC-4E52-9C1B-43C14BB4E874@oucs.ox.ac.uk>
Message-ID: <4FE22E1C.3000400@kcl.ac.uk>

Agree utterly.

It is to late (or too early) to suggest deprecating this aberration, 
perhaps in P6?

On 20/06/2012 20:45, Sebastian Rahtz wrote:
>
> aargh no, please. @facs generally points to a container which contains
> a graphic, so that way madness lies. The shorthand of @facs pointing to
> an external graphics file is an aberration which I'd be reluctant to build on.
>
> As I said, I claim
>    <graphic url="foo.png" facs="#area52"/>
> is a possibly valid bit of markup.
>
> --
> Sebastian Rahtz
> Head of Information and Support Group
> Oxford University Computing Services
> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>
>
>
>
>
>

-- 
Dr Gabriel BODARD
(Research Associate in Digital Epigraphy)

Department of Digital Humanities
King's College London
26-29 Drury Lane
London WC2B 5RL

Email: gabriel.bodard at kcl.ac.uk
Tel: +44 (0)20 7848 1388
Fax: +44 (0)20 7848 2980

http://www.digitalclassicist.org/
http://www.currentepigraphy.org/



From lou.burnard at retired.ox.ac.uk  Wed Jun 20 16:33:17 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Wed, 20 Jun 2012 21:33:17 +0100
Subject: [tei-council] @facs on graphic
In-Reply-To: <ABC2E044-0DDC-4E52-9C1B-43C14BB4E874@oucs.ox.ac.uk>
References: <4FE21A29.1030905@retired.ox.ac.uk>
	<4FE21C9B.7030603@ultraslavonic.info>
	<ABC2E044-0DDC-4E52-9C1B-43C14BB4E874@oucs.ox.ac.uk>
Message-ID: <4FE2338D.7040802@retired.ox.ac.uk>

On 20/06/12 20:45, Sebastian Rahtz wrote:
>
> On 20 Jun 2012, at 19:55, Kevin Hawkins wrote:
>
>>
>> How about we soft-deprecate graphic at url in favor of graphic at facs?  (That
>> is, we don't yet put graphic at url on a timeline for removal, but we also
>> change the Guidelines to always recommend @facs instead of @url.)

but they do different things! one says "the picture which should be here 
is actually over there", the other says "go there to find a picture of 
what is here"

>
> aargh no, please. @facs generally points to a container which contains
> a graphic, so that way madness lies. The shorthand of @facs pointing to
> an external graphics file is an aberration which I'd be reluctant to build on.
>

Why is it an aberration?

> As I said, I claim
>    <graphic url="foo.png" facs="#area52"/>
> is a possibly valid bit of markup.
>
>

Indeed yes, but what does it mean?

I *think* it means

(a) there is a graphic *here* (presumably in some text I am transcribing)
(b) there is a file representing said graphic over there at foo.png
(c) the graphic actually appears over there at area52 (presumably a zone 
in a sourceDoc)

Since when I get to area52, I confidently expect to find another 
<graphic url="foo.png"/>, I rayther think the correct answer is to have 
a schematron rule which says you cannot supply both @facs and @url on 
the same <graphic>






From kevin.s.hawkins at ultraslavonic.info  Wed Jun 20 17:02:05 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Wed, 20 Jun 2012 17:02:05 -0400
Subject: [tei-council] @facs on graphic
In-Reply-To: <4FE2338D.7040802@retired.ox.ac.uk>
References: <4FE21A29.1030905@retired.ox.ac.uk>	<4FE21C9B.7030603@ultraslavonic.info>	<ABC2E044-0DDC-4E52-9C1B-43C14BB4E874@oucs.ox.ac.uk>
	<4FE2338D.7040802@retired.ox.ac.uk>
Message-ID: <4FE23A4D.5090001@ultraslavonic.info>

Responses to two messages below ...

On 6/20/2012 4:33 PM, Lou Burnard wrote:
> On 20/06/12 20:45, Sebastian Rahtz wrote:
>>
>> On 20 Jun 2012, at 19:55, Kevin Hawkins wrote:
>>
>>>
>>> How about we soft-deprecate graphic at url in favor of graphic at facs?  (That
>>> is, we don't yet put graphic at url on a timeline for removal, but we also
>>> change the Guidelines to always recommend @facs instead of @url.)
>
> but they do different things! one says "the picture which should be here
> is actually over there", the other says "go there to find a picture of
> what is here"

Right, okay, sorry.  We've been through this one many times since I've 
been on Council, and I have trouble remembering it.  I must admit that I 
find the distinction meaningless for the <graphic> element in 
particular, but if others feel that what we need is @url and not @facs, 
so be it.

On 6/20/2012 4:10 PM, Gabriel BODARD wrote:
 > Agree utterly.
 >
 > It is to late (or too early) to suggest deprecating this aberration,
 > perhaps in P6?

It's only been out in the wild for a day or two, right?  I don't think 
it would break Birnbaum to remove the possibility of graphic at facs 
(somehow) if we really feel it's best.

--K.

From sebastian.rahtz at oucs.ox.ac.uk  Wed Jun 20 17:11:55 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Wed, 20 Jun 2012 21:11:55 +0000
Subject: [tei-council] @facs on graphic
In-Reply-To: <4FE2338D.7040802@retired.ox.ac.uk>
References: <4FE21A29.1030905@retired.ox.ac.uk>
	<4FE21C9B.7030603@ultraslavonic.info>
	<ABC2E044-0DDC-4E52-9C1B-43C14BB4E874@oucs.ox.ac.uk>
	<4FE2338D.7040802@retired.ox.ac.uk>
Message-ID: <b5417971-4cde-498a-b7cb-af41e9ebf185@HUB02.ad.oak.ox.ac.uk>


On 20 Jun 2012, at 21:33, Lou Burnard wrote:
> Indeed yes, but what does it mean?
> 
> I *think* it means
> 
> (a) there is a graphic *here* (presumably in some text I am transcribing)
> (b) there is a file representing said graphic over there at foo.png
> (c) the graphic actually appears over there at area52 (presumably a zone 
> in a sourceDoc)

> <graphic url="foo.png" facs="#area52"/>

I think it means that there is a zone in the source doc @area52 (of which we
may or may not have a picture, go there are find out); and what we have here is a picture
which is how to choose to represent that area in our edited text. 

Not the same as your interpretation, I think.

example: the zone may show an ornate character, which we  represent
here (in the edited text) with a graphic. not necessarily the same
graphic.

> 
> Since when I get to area52, I confidently expect to find another 
> <graphic url="foo.png"/>, I rayther think the correct answer is to have 
> a schematron rule which says you cannot supply both @facs and @url on 
> the same <graphic>


well, I think thats going a little far.
--
Sebastian Rahtz      
Head of Information and Support Group
Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431







From gabriel.bodard at kcl.ac.uk  Wed Jun 20 17:32:06 2012
From: gabriel.bodard at kcl.ac.uk (Gabriel BODARD)
Date: Wed, 20 Jun 2012 22:32:06 +0100
Subject: [tei-council] @facs on graphic
In-Reply-To: <4FE23A4D.5090001@ultraslavonic.info>
References: <4FE21A29.1030905@retired.ox.ac.uk>
	<4FE21C9B.7030603@ultraslavonic.info>
	<ABC2E044-0DDC-4E52-9C1B-43C14BB4E874@oucs.ox.ac.uk>
	<4FE2338D.7040802@retired.ox.ac.uk>
	<4FE23A4D.5090001@ultraslavonic.info>
Message-ID: <4FE24156.70702@kcl.ac.uk>

On 20/06/2012 22:02, Kevin Hawkins wrote:
> Responses to two messages below ...
> On 6/20/2012 4:10 PM, Gabriel BODARD wrote:
>   > Agree utterly.
>   >
>   > It is to late (or too early) to suggest deprecating this aberration,
>   > perhaps in P6?
>
> It's only been out in the wild for a day or two, right?  I don't think
> it would break Birnbaum to remove the possibility of graphic at facs
> (somehow) if we really feel it's best.

That's not what I was suggesting at all, sorry. As Sebastian says, if 
you can have <graphic> in <text>, then that graphic might be 
representing something that you choose to describe and/or provide one or 
more images of in a surface or zone in the <facsimile>, so @facs on 
<graphic> is (a) perfectly sensible and (b) not saying the same thing as 
@url at all.

What I was suggesting (to a resounding chorus of no support, I suspect) 
was repairing the situation where @facs can point directly to an image 
file rather than to a zone/surface which *represents* (and may also 
describe and/or provide 1+ images of) the part of the document bearing 
this attribute. I was arguing that in P6, we should not allow these two 
divergent uses of the same attribute. (Once we cross over to P6, 
Birnbaum will no longer apply, right? We *want* to break backward 
compatibility between P5 and P6. :-) )

G


-- 
Dr Gabriel BODARD
(Research Associate in Digital Epigraphy)

Department of Digital Humanities
King's College London
26-29 Drury Lane
London WC2B 5RL

Email: gabriel.bodard at kcl.ac.uk
Tel: +44 (0)20 7848 1388
Fax: +44 (0)20 7848 2980

http://www.digitalclassicist.org/
http://www.currentepigraphy.org/



From sebastian.rahtz at oucs.ox.ac.uk  Wed Jun 20 17:37:20 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Wed, 20 Jun 2012 21:37:20 +0000
Subject: [tei-council] @facs on graphic
In-Reply-To: <4FE24156.70702@kcl.ac.uk>
References: <4FE21A29.1030905@retired.ox.ac.uk>
	<4FE21C9B.7030603@ultraslavonic.info>
	<ABC2E044-0DDC-4E52-9C1B-43C14BB4E874@oucs.ox.ac.uk>
	<4FE2338D.7040802@retired.ox.ac.uk>
	<4FE23A4D.5090001@ultraslavonic.info> <4FE24156.70702@kcl.ac.uk>
Message-ID: <365D410E-6648-4A30-B007-065397C02EFA@oucs.ox.ac.uk>


On 20 Jun 2012, at 22:32, Gabriel BODARD wrote:

> 
> What I was suggesting (to a resounding chorus of no support, I suspect) 
> was repairing the situation where @facs can point directly to an image 
> file rather than to a zone/surface which *represents* (and may also 
> describe and/or provide 1+ images of) the part of the document bearing 
> this attribute.

+ 1 from me, to be sure.  just encouraging sloppy working, IMHO.

On the other hand, thats we what we decided to do, and we dont
really have a mandate at present to revisit old decisions.
--
Sebastian Rahtz      
Head of Information and Support Group
Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431







From gabriel.bodard at kcl.ac.uk  Wed Jun 20 17:40:12 2012
From: gabriel.bodard at kcl.ac.uk (Gabriel BODARD)
Date: Wed, 20 Jun 2012 22:40:12 +0100
Subject: [tei-council] @facs on graphic
In-Reply-To: <365D410E-6648-4A30-B007-065397C02EFA@oucs.ox.ac.uk>
References: <4FE21A29.1030905@retired.ox.ac.uk>
	<4FE21C9B.7030603@ultraslavonic.info>
	<ABC2E044-0DDC-4E52-9C1B-43C14BB4E874@oucs.ox.ac.uk>
	<4FE2338D.7040802@retired.ox.ac.uk>
	<4FE23A4D.5090001@ultraslavonic.info> <4FE24156.70702@kcl.ac.uk>
	<365D410E-6648-4A30-B007-065397C02EFA@oucs.ox.ac.uk>
Message-ID: <4FE2433C.3040705@kcl.ac.uk>

::shrug:: We do have a mandate to start thinking about P6 though. 
(Against my objections, in fact.) So anything that does need revisiting 
can be listed under that heading to be fixed in the future.

On 20/06/2012 22:37, Sebastian Rahtz wrote:
>
> On 20 Jun 2012, at 22:32, Gabriel BODARD wrote:
>
>>
>> What I was suggesting (to a resounding chorus of no support, I suspect)
>> was repairing the situation where @facs can point directly to an image
>> file rather than to a zone/surface which *represents* (and may also
>> describe and/or provide 1+ images of) the part of the document bearing
>> this attribute.
>
> + 1 from me, to be sure.  just encouraging sloppy working, IMHO.
>
> On the other hand, thats we what we decided to do, and we dont
> really have a mandate at present to revisit old decisions.
> --
> Sebastian Rahtz
> Head of Information and Support Group
> Oxford University Computing Services
> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>
>
>
>
>
>

-- 
Dr Gabriel BODARD
(Research Associate in Digital Epigraphy)

Department of Digital Humanities
King's College London
26-29 Drury Lane
London WC2B 5RL

Email: gabriel.bodard at kcl.ac.uk
Tel: +44 (0)20 7848 1388
Fax: +44 (0)20 7848 2980

http://www.digitalclassicist.org/
http://www.currentepigraphy.org/



From kevin.s.hawkins at ultraslavonic.info  Wed Jun 20 17:44:54 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Wed, 20 Jun 2012 17:44:54 -0400
Subject: [tei-council] @facs on graphic
In-Reply-To: <4FE2433C.3040705@kcl.ac.uk>
References: <4FE21A29.1030905@retired.ox.ac.uk>	<4FE21C9B.7030603@ultraslavonic.info>	<ABC2E044-0DDC-4E52-9C1B-43C14BB4E874@oucs.ox.ac.uk>	<4FE2338D.7040802@retired.ox.ac.uk>	<4FE23A4D.5090001@ultraslavonic.info>
	<4FE24156.70702@kcl.ac.uk>	<365D410E-6648-4A30-B007-065397C02EFA@oucs.ox.ac.uk>
	<4FE2433C.3040705@kcl.ac.uk>
Message-ID: <4FE24456.10007@ultraslavonic.info>

In fact, the place to list such things is:

http://wiki.tei-c.org/index.php/P6-dev

On 6/20/2012 5:40 PM, Gabriel BODARD wrote:
> ::shrug:: We do have a mandate to start thinking about P6 though.
> (Against my objections, in fact.) So anything that does need revisiting
> can be listed under that heading to be fixed in the future.

From syeates at gmail.com  Wed Jun 20 18:59:07 2012
From: syeates at gmail.com (Stuart A. Yeates)
Date: Thu, 21 Jun 2012 10:59:07 +1200
Subject: [tei-council] Order of release steps
In-Reply-To: <4FE1F291.4090107@kcl.ac.uk>
References: <4FE1C81A.3080300@uvic.ca>
	<A81085D1-6815-4C1B-92B3-92AA12034C06@oucs.ox.ac.uk>
	<4FE1E891.1070303@uvic.ca>
	<7352B149-BFB9-4736-9356-5C381A03FBC1@oucs.ox.ac.uk>
	<4FE1EFDE.1040602@uvic.ca> <4FE1F291.4090107@kcl.ac.uk>
Message-ID: <CAC_Lu0YcQjFs908Tb_sJL_bRSnFSRPU1Gkbe7-7RLobz6HPJWA@mail.gmail.com>

On Thu, Jun 21, 2012 at 3:56 AM, Gabriel BODARD
<gabriel.bodard at kcl.ac.uk> wrote:
> Maybe I'm missing something here (well, I certainly am, but sometimes
> naivet? can lead to valid suggestions) but is the answer not as simple
> as to freeze development, say 24 hours before starting the release, so
> that both the debian packages and all the other TEI materials can be
> generated in this stable time, then the release itself only involves
> changing the version numbers, waiting, testing, and pushing live?

This kind of thing is quite normal. Most software projects with a
formal release process have a period where only limited activity is
permitted. The exact nature of the permitted activity varies, but is
typically limited to translation work, textual changes (i.e. typo and
stylistic fixes), documentation updates and blocking bug fixes (i.e.
fixes to bugs which essentially break the system for large numbers of
users).

Personally I think a week where we were encouraged to proof-read
changed / updated / random sections of the standard might be a good
idea. Minor tweaks can be fixed live and bigger issues can be opened
as tickets (or fixed locally on people's machines but not committed
until after the release). With a week-long period we could even send a
call for proof-readers out to TEI-L.

cheers
stuart

From James.Cummings at oucs.ox.ac.uk  Thu Jun 21 03:41:42 2012
From: James.Cummings at oucs.ox.ac.uk (James Cummings)
Date: Thu, 21 Jun 2012 08:41:42 +0100
Subject: [tei-council] @facs on graphic
In-Reply-To: <4FE24456.10007@ultraslavonic.info>
References: <4FE21A29.1030905@retired.ox.ac.uk>	<4FE21C9B.7030603@ultraslavonic.info>	<ABC2E044-0DDC-4E52-9C1B-43C14BB4E874@oucs.ox.ac.uk>	<4FE2338D.7040802@retired.ox.ac.uk>	<4FE23A4D.5090001@ultraslavonic.info>
	<4FE24156.70702@kcl.ac.uk>	<365D410E-6648-4A30-B007-065397C02EFA@oucs.ox.ac.uk>
	<4FE2433C.3040705@kcl.ac.uk> <4FE24456.10007@ultraslavonic.info>
Message-ID: <4FE2D036.8050003@oucs.ox.ac.uk>

On 20/06/12 22:44, Kevin Hawkins wrote:
> In fact, the place to list such things is:
>
> http://wiki.tei-c.org/index.php/P6-dev

Which I was tasked with creating after Ann Arbor. ;-)   ... 
Specifically while anything can go there it is important to have 
a place to note things we are intentionally *not* doing because 
we are leaving consideration for them to P6.

-James

>
> On 6/20/2012 5:40 PM, Gabriel BODARD wrote:
>> ::shrug:: We do have a mandate to start thinking about P6 though.
>> (Against my objections, in fact.) So anything that does need revisiting
>> can be listed under that heading to be fixed in the future.


-- 
Dr James Cummings, InfoDev
Oxford University Computing Services
University of Oxford

From sebastian.rahtz at oucs.ox.ac.uk  Thu Jun 21 05:57:34 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Thu, 21 Jun 2012 09:57:34 +0000
Subject: [tei-council] tei build back
Message-ID: <1323778F-CA48-4D4B-AC24-9E6213FA0EF8@oucs.ox.ac.uk>

after a rapid series of hacks yesterday, the P5 build seems to be stable again now. The main
aim of the work was to have reports of typically broken things (guidelines validation and test suite)
return as quickly as possibly; it should now be under 10 minutes to get this main testing phase done.
Documentation building etc takes longer, typically another 1.5 hours
--
Sebastian Rahtz      
Head of Information and Support Group
Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431

S?lo le pido a Dios
que el futuro no me sea indiferente


From sebastian.rahtz at oucs.ox.ac.uk  Thu Jun 21 07:20:21 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Thu, 21 Jun 2012 11:20:21 +0000
Subject: [tei-council] P5 test files
In-Reply-To: <4FE1ED9D.2000506@uvic.ca>
References: <7FFA13B3-8117-4B82-8841-D59346031297@oucs.ox.ac.uk>
	<4FE1E761.6080903@uvic.ca>
	<9CCF8497-212A-4E20-869E-CF63B1E02CB7@oucs.ox.ac.uk>
	<4FE1ED9D.2000506@uvic.ca>
Message-ID: <25E79A77-EFA9-43CC-88BF-2F1CAECB6DEF@oucs.ox.ac.uk>


On 20 Jun 2012, at 16:34, Martin Holmes wrote:

> 
> I'll try to create examples for all four scenarios (or perhaps just pick one from each to explain in detail -- given that I whinged about P5-Test taking so long, I should probably not invent novel tests just for the purposes of documentation).

the time is taken in startup for each test. add in as much more stuff as you want to testbasic, it won't make a difference
> 
>> there are another dozen more specialized tests which you probably should leave like sleeping dogs.
> 
> This is the sort of thing that wakes me up at 4am (cheese is innocent).


well, have a look at the others, and you'll see why they are special cases which cant fit
in the main tests.

testbasic and detest are the key ones to understand
--
Sebastian Rahtz      
Head of Information and Support Group
Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431

S?lo le pido a Dios
que el futuro no me sea indiferente


From James.Cummings at oucs.ox.ac.uk  Sun Jun 24 04:43:25 2012
From: James.Cummings at oucs.ox.ac.uk (James Cummings)
Date: Sun, 24 Jun 2012 09:43:25 +0100
Subject: [tei-council] Next TEI Technical Council Teleconference
Message-ID: <4FE6D32D.5070101@oucs.ox.ac.uk>


Hi All,

We should probably have another teleconference between now and 
our face2face meeting.  I suggest this be in the last full week 
of July.  (This is the week immediately after DH for those going.)

I've put up a poll at http://www.doodle.com/ckkuv67w2bn5eqc2 for 
you to fill in. Please fill it in, especially if you can't make 
any of those dateTimes.

I've set the times from 18:00 - 21:00 UK time because 
timeanddate.com tells me that will be most convenient time to 
include everyone (especially Martin and Stuart).  If that is 
totally impossible for anyone, please fill out the poll. You can 
adjust the poll to show you the times in your timezone.

-James


-- 
Dr James Cummings, InfoDev
Oxford University Computing Services
University of Oxford

From mholmes at uvic.ca  Sun Jun 24 14:21:14 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Sun, 24 Jun 2012 11:21:14 -0700
Subject: [tei-council] Next TEI Technical Council Teleconference
In-Reply-To: <4FE6D32D.5070101@oucs.ox.ac.uk>
References: <4FE6D32D.5070101@oucs.ox.ac.uk>
Message-ID: <4FE75A9A.1040003@uvic.ca>

I'll be on vacation on Galliano Island for all of that week. There is an 
internet connection, but I don't know if it's up to Skyping, and there's 
no way to know in advance.

I'll put myself down as available for the whole time, but it would help 
to know as far in advance as possible what the time is, because I'll 
have to make sure I don't get scheduled into any holiday activities by 
my minders.

Cheers,
Martin

On 12-06-24 01:43 AM, James Cummings wrote:
>
> Hi All,
>
> We should probably have another teleconference between now and
> our face2face meeting.  I suggest this be in the last full week
> of July.  (This is the week immediately after DH for those going.)
>
> I've put up a poll at http://www.doodle.com/ckkuv67w2bn5eqc2 for
> you to fill in. Please fill it in, especially if you can't make
> any of those dateTimes.
>
> I've set the times from 18:00 - 21:00 UK time because
> timeanddate.com tells me that will be most convenient time to
> include everyone (especially Martin and Stuart).  If that is
> totally impossible for anyone, please fill out the poll. You can
> adjust the poll to show you the times in your timezone.
>
> -James
>
>


From bansp at o2.pl  Sun Jun 24 18:24:50 2012
From: bansp at o2.pl (=?ISO-8859-2?Q?Piotr_Ba=F1ski?=)
Date: Mon, 25 Jun 2012 00:24:50 +0200
Subject: [tei-council] Next TEI Technical Council Teleconference
In-Reply-To: <4FE75A9A.1040003@uvic.ca>
References: <4FE6D32D.5070101@oucs.ox.ac.uk> <4FE75A9A.1040003@uvic.ca>
Message-ID: <4FE793B2.9040004@o2.pl>

Hi all,

Just noting that since:

* Martin's presence at the telco would be greatly appreciated,
* keeping this hardworking guy away from his holiday activities is
simply cruel, and
* there is -- perhaps -- no necessity to hold the telco during that week
exactly,

perhaps we could reschedule?

With apologies for stirring up hassle where Martin tactfully tried to
avoid it,

  P.


On 24/06/12 20:21, Martin Holmes wrote:
> I'll be on vacation on Galliano Island for all of that week. There is an 
> internet connection, but I don't know if it's up to Skyping, and there's 
> no way to know in advance.
> 
> I'll put myself down as available for the whole time, but it would help 
> to know as far in advance as possible what the time is, because I'll 
> have to make sure I don't get scheduled into any holiday activities by 
> my minders.
> 
> Cheers,
> Martin
> 
> On 12-06-24 01:43 AM, James Cummings wrote:
>>
>> Hi All,
>>
>> We should probably have another teleconference between now and
>> our face2face meeting.  I suggest this be in the last full week
>> of July.  (This is the week immediately after DH for those going.)
>>
>> I've put up a poll at http://www.doodle.com/ckkuv67w2bn5eqc2 for
>> you to fill in. Please fill it in, especially if you can't make
>> any of those dateTimes.
>>
>> I've set the times from 18:00 - 21:00 UK time because
>> timeanddate.com tells me that will be most convenient time to
>> include everyone (especially Martin and Stuart).  If that is
>> totally impossible for anyone, please fill out the poll. You can
>> adjust the poll to show you the times in your timezone.
>>
>> -James
>>
>>
> 


From mholmes at uvic.ca  Sun Jun 24 19:32:43 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Sun, 24 Jun 2012 16:32:43 -0700
Subject: [tei-council] Next TEI Technical Council Teleconference
In-Reply-To: <4FE793B2.9040004@o2.pl>
References: <4FE6D32D.5070101@oucs.ox.ac.uk> <4FE75A9A.1040003@uvic.ca>
	<4FE793B2.9040004@o2.pl>
Message-ID: <4FE7A39B.3030204@uvic.ca>

Hi all,

I really don't mind attending a telco on my vacation, honestly. I like 
Council work, and hanging out with you all.

One thing that I realized might be a problem is if the telco is using 
the telephone system rather than Skype. I don't know whether the phone 
at the rental cottage will allow me to connect to systems like that, and 
my own cell will be roaming so it'll be too expensive to use.

Cheers,
Martin



On 12-06-24 03:24 PM, Piotr Ba?ski wrote:
> Hi all,
>
> Just noting that since:
>
> * Martin's presence at the telco would be greatly appreciated,
> * keeping this hardworking guy away from his holiday activities is
> simply cruel, and
> * there is -- perhaps -- no necessity to hold the telco during that week
> exactly,
>
> perhaps we could reschedule?
>
> With apologies for stirring up hassle where Martin tactfully tried to
> avoid it,
>
>    P.
>
>
> On 24/06/12 20:21, Martin Holmes wrote:
>> I'll be on vacation on Galliano Island for all of that week. There is an
>> internet connection, but I don't know if it's up to Skyping, and there's
>> no way to know in advance.
>>
>> I'll put myself down as available for the whole time, but it would help
>> to know as far in advance as possible what the time is, because I'll
>> have to make sure I don't get scheduled into any holiday activities by
>> my minders.
>>
>> Cheers,
>> Martin
>>
>> On 12-06-24 01:43 AM, James Cummings wrote:
>>>
>>> Hi All,
>>>
>>> We should probably have another teleconference between now and
>>> our face2face meeting.  I suggest this be in the last full week
>>> of July.  (This is the week immediately after DH for those going.)
>>>
>>> I've put up a poll at http://www.doodle.com/ckkuv67w2bn5eqc2 for
>>> you to fill in. Please fill it in, especially if you can't make
>>> any of those dateTimes.
>>>
>>> I've set the times from 18:00 - 21:00 UK time because
>>> timeanddate.com tells me that will be most convenient time to
>>> include everyone (especially Martin and Stuart).  If that is
>>> totally impossible for anyone, please fill out the poll. You can
>>> adjust the poll to show you the times in your timezone.
>>>
>>> -James
>>>
>>>
>>
>


From James.Cummings at oucs.ox.ac.uk  Mon Jun 25 07:15:45 2012
From: James.Cummings at oucs.ox.ac.uk (James Cummings)
Date: Mon, 25 Jun 2012 12:15:45 +0100
Subject: [tei-council] Next TEI Technical Council Teleconference
In-Reply-To: <4FE793B2.9040004@o2.pl>
References: <4FE6D32D.5070101@oucs.ox.ac.uk> <4FE75A9A.1040003@uvic.ca>
	<4FE793B2.9040004@o2.pl>
Message-ID: <4FE84861.6040601@oucs.ox.ac.uk>


Although Martin protests that hanging out with us is like a 
vacation, perhaps you are right, that week was only a suggestion.

Does anyone have any severe problem with the first full week in 
August? (i.e. 6-10 August)?

-James


On 24/06/12 23:24, Piotr Ba?ski wrote:
> Hi all,
>
> Just noting that since:
>
> * Martin's presence at the telco would be greatly appreciated,
> * keeping this hardworking guy away from his holiday activities is
> simply cruel, and
> * there is -- perhaps -- no necessity to hold the telco during that week
> exactly,
>
> perhaps we could reschedule?
>
> With apologies for stirring up hassle where Martin tactfully tried to
> avoid it,
>
>    P.
>
>
> On 24/06/12 20:21, Martin Holmes wrote:
>> I'll be on vacation on Galliano Island for all of that week. There is an
>> internet connection, but I don't know if it's up to Skyping, and there's
>> no way to know in advance.
>>
>> I'll put myself down as available for the whole time, but it would help
>> to know as far in advance as possible what the time is, because I'll
>> have to make sure I don't get scheduled into any holiday activities by
>> my minders.
>>
>> Cheers,
>> Martin
>>
>> On 12-06-24 01:43 AM, James Cummings wrote:
>>>
>>> Hi All,
>>>
>>> We should probably have another teleconference between now and
>>> our face2face meeting.  I suggest this be in the last full week
>>> of July.  (This is the week immediately after DH for those going.)
>>>
>>> I've put up a poll at http://www.doodle.com/ckkuv67w2bn5eqc2 for
>>> you to fill in. Please fill it in, especially if you can't make
>>> any of those dateTimes.
>>>
>>> I've set the times from 18:00 - 21:00 UK time because
>>> timeanddate.com tells me that will be most convenient time to
>>> include everyone (especially Martin and Stuart).  If that is
>>> totally impossible for anyone, please fill out the poll. You can
>>> adjust the poll to show you the times in your timezone.
>>>
>>> -James
>>>
>>>
>>
>


-- 
Dr James Cummings, InfoDev,
OUCS, University of Oxford

From mholmes at uvic.ca  Mon Jun 25 12:06:28 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Mon, 25 Jun 2012 09:06:28 -0700
Subject: [tei-council] Next TEI Technical Council Teleconference
In-Reply-To: <4FE84861.6040601@oucs.ox.ac.uk>
References: <4FE6D32D.5070101@oucs.ox.ac.uk> <4FE75A9A.1040003@uvic.ca>
	<4FE793B2.9040004@o2.pl> <4FE84861.6040601@oucs.ox.ac.uk>
Message-ID: <4FE88C84.4030806@uvic.ca>

6-10 August would be perfect for me; I'll be back to work. But any week 
you choose at this time of year will collide with some folks' holidays, 
so leave the original week on the table just in case.

I volunteer to do minutes.

Cheers,
Martin

On 12-06-25 04:15 AM, James Cummings wrote:
>
> Although Martin protests that hanging out with us is like a
> vacation, perhaps you are right, that week was only a suggestion.
>
> Does anyone have any severe problem with the first full week in
> August? (i.e. 6-10 August)?
>
> -James
>
>
> On 24/06/12 23:24, Piotr Ba?ski wrote:
>> Hi all,
>>
>> Just noting that since:
>>
>> * Martin's presence at the telco would be greatly appreciated,
>> * keeping this hardworking guy away from his holiday activities is
>> simply cruel, and
>> * there is -- perhaps -- no necessity to hold the telco during that week
>> exactly,
>>
>> perhaps we could reschedule?
>>
>> With apologies for stirring up hassle where Martin tactfully tried to
>> avoid it,
>>
>>     P.
>>
>>
>> On 24/06/12 20:21, Martin Holmes wrote:
>>> I'll be on vacation on Galliano Island for all of that week. There is an
>>> internet connection, but I don't know if it's up to Skyping, and there's
>>> no way to know in advance.
>>>
>>> I'll put myself down as available for the whole time, but it would help
>>> to know as far in advance as possible what the time is, because I'll
>>> have to make sure I don't get scheduled into any holiday activities by
>>> my minders.
>>>
>>> Cheers,
>>> Martin
>>>
>>> On 12-06-24 01:43 AM, James Cummings wrote:
>>>>
>>>> Hi All,
>>>>
>>>> We should probably have another teleconference between now and
>>>> our face2face meeting.  I suggest this be in the last full week
>>>> of July.  (This is the week immediately after DH for those going.)
>>>>
>>>> I've put up a poll at http://www.doodle.com/ckkuv67w2bn5eqc2 for
>>>> you to fill in. Please fill it in, especially if you can't make
>>>> any of those dateTimes.
>>>>
>>>> I've set the times from 18:00 - 21:00 UK time because
>>>> timeanddate.com tells me that will be most convenient time to
>>>> include everyone (especially Martin and Stuart).  If that is
>>>> totally impossible for anyone, please fill out the poll. You can
>>>> adjust the poll to show you the times in your timezone.
>>>>
>>>> -James
>>>>
>>>>
>>>
>>
>
>

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)



From James.Cummings at oucs.ox.ac.uk  Mon Jun 25 12:16:54 2012
From: James.Cummings at oucs.ox.ac.uk (James Cummings)
Date: Mon, 25 Jun 2012 17:16:54 +0100
Subject: [tei-council] Next TEI Technical Council Teleconference
In-Reply-To: <4FE88C84.4030806@uvic.ca>
References: <4FE6D32D.5070101@oucs.ox.ac.uk> <4FE75A9A.1040003@uvic.ca>
	<4FE793B2.9040004@o2.pl> <4FE84861.6040601@oucs.ox.ac.uk>
	<4FE88C84.4030806@uvic.ca>
Message-ID: <4FE88EF6.5010307@oucs.ox.ac.uk>

On 25/06/12 17:06, Martin Holmes wrote:
> 6-10 August would be perfect for me; I'll be back to work. But
> any week you choose at this time of year will collide with some
> folks' holidays, so leave the original week on the table just in
> case.

I'll give anyone a day to shout that they are away all that week 
or for some other reason it is impossible, before putting up 
another doodle poll.

> I volunteer to do minutes.

Many thanks!

-James

-- 
Dr James Cummings, InfoDev,
OUCS, University of Oxford

From mholmes at uvic.ca  Mon Jun 25 12:56:30 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Mon, 25 Jun 2012 09:56:30 -0700
Subject: [tei-council] Strange validation problem with ODD file
Message-ID: <4FE8983E.7080405@uvic.ca>

Hi all,

I'm working on a fairly simple ODD file and getting a validation error 
that I can't figure out. I'm working in Oxygen and letting Oxygen 
validate against the latest TEI framework release, installed from 
oxygen-tei, and getting a series of errors.

But if I validate against the latest release of tei_all, here:

<http://www.tei-c.org/release/xml/tei/custom/schema/relaxng/tei_all.rng>

there's no error.

The first error I'm getting  is this:

E [Jing] element "editionStmt" not allowed here; expected element 
"extent" or "publicationStmt"

but it makes no sense to me because <editionStmt> should come before 
<publicationStmt>. There's a series of similar errors.

  The header looks like this:

   <teiHeader>
     <fileDesc>
       <titleStmt>
         <title>TEI Customization for Map of London project</title>
         <author>Martin Holmes</author>
       </titleStmt>
       <editionStmt>
         <edition>Originally generated on 
<date>2012-06-19T14:04:46Z</date> </edition>
       </editionStmt>
       <publicationStmt>
         <p>See publication statement for Map of Early Modern London 
project.</p>
       </publicationStmt>
       <notesStmt>
          <note type="ns">http://www.example.org/ns/nonTEI</note>
       </notesStmt>
       <sourceDesc>
         <p>generated by oddbyexample.xsl, based on analyzing 817 files from
           /home/mholmes/WorkData/english/map_of_london/temp/. Subsequently
         modified manually several times, most significantly to allow 
the use
         of XInclude elements. </p>
       </sourceDesc>
     </fileDesc>
   </teiHeader>

As far as I can see, my document follows the sequence of fileDesc 
elements shown in the Guidelines:

<http://www.tei-c.org/release/doc/tei-p5-doc/en/html/HD.html#HD2>

i.e. <titleStmt>, <editionStmt>, <publicationStmt>, <notesStmt>, 
<sourceDesc>.

If anyone else has installed the latest TEI framework from oxygen-tei, 
could you check whether your teiHeaders are validated correctly? If 
there's a problem with the TEI framework, we should catch it before 
Oxygen do their release this week.

Cheers,
Martin

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)


From lou.burnard at retired.ox.ac.uk  Mon Jun 25 13:13:20 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Mon, 25 Jun 2012 18:13:20 +0100
Subject: [tei-council] Strange validation problem with ODD file
In-Reply-To: <4FE8983E.7080405@uvic.ca>
References: <4FE8983E.7080405@uvic.ca>
Message-ID: <4FE89C30.3080005@retired.ox.ac.uk>

On 25/06/12 17:56, Martin Holmes wrote:

> I'm working on a fairly simple ODD file and getting a validation error
> that I can't figure out. I'm working in Oxygen and letting Oxygen
> validate against the latest TEI framework release, installed from
> oxygen-tei, and getting a series of errors.


Forgive me for stating the obvious, especially as I dont know exactly 
what you mean by "the latest TEI framework release",  but the 
implication of the errors you're seeing is surely that the schema in use 
doesn't include <editionStmt>. Which is quite possible if you're using 
(say) tei_bare or some other customization which omits it.

Anyway, I havent noticed anything untoward with my installation of 
Oxygen since the release...

From mholmes at uvic.ca  Mon Jun 25 13:19:19 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Mon, 25 Jun 2012 10:19:19 -0700
Subject: [tei-council] Strange validation problem with ODD file
In-Reply-To: <4FE89C30.3080005@retired.ox.ac.uk>
References: <4FE8983E.7080405@uvic.ca> <4FE89C30.3080005@retired.ox.ac.uk>
Message-ID: <4FE89D97.5030608@uvic.ca>

On 12-06-25 10:13 AM, Lou Burnard wrote:
> On 25/06/12 17:56, Martin Holmes wrote:
>
>> I'm working on a fairly simple ODD file and getting a validation error
>> that I can't figure out. I'm working in Oxygen and letting Oxygen
>> validate against the latest TEI framework release, installed from
>> oxygen-tei, and getting a series of errors.
>
>
> Forgive me for stating the obvious, especially as I dont know exactly
> what you mean by "the latest TEI framework release",

What I mean is that I downloaded the latest oxygen-tei package from here:

<http://code.google.com/p/oxygen-tei/>

and installed it into my Oxygen setup. When you edit a TEI file which 
isn't directly linked to a specific schema through e.g. an xml-model PI, 
Oxygen by default validates it against tei_all in the installed 
framework (at least, I'm pretty sure that's the case, based on my 
previous experience). So what I'm wondering is whether there might be 
something wrong with the oxygen-tei package.

> but the
> implication of the errors you're seeing is surely that the schema in use
> doesn't include <editionStmt>. Which is quite possible if you're using
> (say) tei_bare or some other customization which omits it.

If it's the case that Oxygen in fact validates against some other 
customization rather than tei_all, then that makes sense, but my 
previous experience suggests that up to now it's been validating against 
a complete TEI schema.

> Anyway, I havent noticed anything untoward with my installation of
> Oxygen since the release...

Did you install the new TEI framework into your Oxygen frameworks directory?

Cheers,
Martin

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)



From sebastian.rahtz at oucs.ox.ac.uk  Mon Jun 25 13:22:28 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Mon, 25 Jun 2012 17:22:28 +0000
Subject: [tei-council] Strange validation problem with ODD file
In-Reply-To: <4FE89D97.5030608@uvic.ca>
References: <4FE8983E.7080405@uvic.ca>
	<4FE89C30.3080005@retired.ox.ac.uk>,<4FE89D97.5030608@uvic.ca>
Message-ID: <48af22b0-a40b-4682-9fb2-a424a36b3a2f@HUB05.ad.oak.ox.ac.uk>

It's not clear whether oxygen themselves use that framework, or build their own. 

Can you compare the tei_all schemas?

Carved in stone on my iPad

On 25 Jun 2012, at 18:19, "Martin Holmes" <mholmes at uvic.ca> wrote:

> On 12-06-25 10:13 AM, Lou Burnard wrote:
>> On 25/06/12 17:56, Martin Holmes wrote:
>> 
>>> I'm working on a fairly simple ODD file and getting a validation error
>>> that I can't figure out. I'm working in Oxygen and letting Oxygen
>>> validate against the latest TEI framework release, installed from
>>> oxygen-tei, and getting a series of errors.
>> 
>> 
>> Forgive me for stating the obvious, especially as I dont know exactly
>> what you mean by "the latest TEI framework release",
> 
> What I mean is that I downloaded the latest oxygen-tei package from here:
> 
> <http://code.google.com/p/oxygen-tei/>
> 
> and installed it into my Oxygen setup. When you edit a TEI file which 
> isn't directly linked to a specific schema through e.g. an xml-model PI, 
> Oxygen by default validates it against tei_all in the installed 
> framework (at least, I'm pretty sure that's the case, based on my 
> previous experience). So what I'm wondering is whether there might be 
> something wrong with the oxygen-tei package.
> 
>> but the
>> implication of the errors you're seeing is surely that the schema in use
>> doesn't include <editionStmt>. Which is quite possible if you're using
>> (say) tei_bare or some other customization which omits it.
> 
> If it's the case that Oxygen in fact validates against some other 
> customization rather than tei_all, then that makes sense, but my 
> previous experience suggests that up to now it's been validating against 
> a complete TEI schema.
> 
>> Anyway, I havent noticed anything untoward with my installation of
>> Oxygen since the release...
> 
> Did you install the new TEI framework into your Oxygen frameworks directory?
> 
> Cheers,
> Martin
> 
> -- 
> Martin Holmes
> University of Victoria Humanities Computing and Media Centre
> (mholmes at uvic.ca)
> 
> 
> -- 
> tei-council mailing list
> tei-council at lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
> 
> PLEASE NOTE: postings to this list are publicly archived

From mholmes at uvic.ca  Mon Jun 25 14:10:05 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Mon, 25 Jun 2012 11:10:05 -0700
Subject: [tei-council] Strange validation problem with ODD file
In-Reply-To: <48af22b0-a40b-4682-9fb2-a424a36b3a2f@HUB05.ad.oak.ox.ac.uk>
References: <4FE8983E.7080405@uvic.ca> <4FE89C30.3080005@retired.ox.ac.uk>,
	<4FE89D97.5030608@uvic.ca>
	<48af22b0-a40b-4682-9fb2-a424a36b3a2f@HUB05.ad.oak.ox.ac.uk>
Message-ID: <4FE8A97D.5080807@uvic.ca>

The only difference between the schemas is that the Oxygen one allows 
<idno> in model.personPart, because it was generated a day later. So 
that's not the source of the problem. I think it must indicate, as Lou 
suggests, that Oxygen now defaults to validating a TEI file which is not 
explicitly linked to a schema using something other than tei_all; but I 
don't know what it does use. I'm pretty sure it used to use tei_all.

Of course I should be validating my ODD files using tei_allPlus anyway, 
otherwise I get errors for all the RNG elements.

Do we care that the oxygen-tei package has a very slightly different 
schema from the official 2.1.0 release (allowing <idno> in 
model.personPart)?

Cheers,
Martin


On 12-06-25 10:22 AM, Sebastian Rahtz wrote:
> It's not clear whether oxygen themselves use that framework, or build their own.
>
> Can you compare the tei_all schemas?
>
> Carved in stone on my iPad
>
> On 25 Jun 2012, at 18:19, "Martin Holmes" <mholmes at uvic.ca> wrote:
>
>> On 12-06-25 10:13 AM, Lou Burnard wrote:
>>> On 25/06/12 17:56, Martin Holmes wrote:
>>>
>>>> I'm working on a fairly simple ODD file and getting a validation error
>>>> that I can't figure out. I'm working in Oxygen and letting Oxygen
>>>> validate against the latest TEI framework release, installed from
>>>> oxygen-tei, and getting a series of errors.
>>>
>>>
>>> Forgive me for stating the obvious, especially as I dont know exactly
>>> what you mean by "the latest TEI framework release",
>>
>> What I mean is that I downloaded the latest oxygen-tei package from here:
>>
>> <http://code.google.com/p/oxygen-tei/>
>>
>> and installed it into my Oxygen setup. When you edit a TEI file which
>> isn't directly linked to a specific schema through e.g. an xml-model PI,
>> Oxygen by default validates it against tei_all in the installed
>> framework (at least, I'm pretty sure that's the case, based on my
>> previous experience). So what I'm wondering is whether there might be
>> something wrong with the oxygen-tei package.
>>
>>> but the
>>> implication of the errors you're seeing is surely that the schema in use
>>> doesn't include <editionStmt>. Which is quite possible if you're using
>>> (say) tei_bare or some other customization which omits it.
>>
>> If it's the case that Oxygen in fact validates against some other
>> customization rather than tei_all, then that makes sense, but my
>> previous experience suggests that up to now it's been validating against
>> a complete TEI schema.
>>
>>> Anyway, I havent noticed anything untoward with my installation of
>>> Oxygen since the release...
>>
>> Did you install the new TEI framework into your Oxygen frameworks directory?
>>
>> Cheers,
>> Martin
>>
>> --
>> Martin Holmes
>> University of Victoria Humanities Computing and Media Centre
>> (mholmes at uvic.ca)
>>
>>
>> --
>> tei-council mailing list
>> tei-council at lists.village.Virginia.EDU
>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>>
>> PLEASE NOTE: postings to this list are publicly archived
> .
>

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)



From James.Cummings at oucs.ox.ac.uk  Mon Jun 25 14:53:19 2012
From: James.Cummings at oucs.ox.ac.uk (James Cummings)
Date: Mon, 25 Jun 2012 19:53:19 +0100
Subject: [tei-council] Strange validation problem with ODD file
In-Reply-To: <4FE8A97D.5080807@uvic.ca>
References: <4FE8983E.7080405@uvic.ca> <4FE89C30.3080005@retired.ox.ac.uk>,
	<4FE89D97.5030608@uvic.ca>
	<48af22b0-a40b-4682-9fb2-a424a36b3a2f@HUB05.ad.oak.ox.ac.uk>
	<4FE8A97D.5080807@uvic.ca>
Message-ID: <4FE8B39F.4060201@oucs.ox.ac.uk>

On 25/06/12 19:10, Martin Holmes wrote:
> The only difference between the schemas is that the Oxygen one allows
> <idno>  in model.personPart, because it was generated a day later.

That dates it at least, since Laurent added that shortly after 
the release.

> Do we care that the oxygen-tei package has a very slightly different
> schema from the official 2.1.0 release (allowing<idno>  in
> model.personPart)?

No, I'm not bothered by that slight difference personally.

-james

-- 
Dr James Cummings, InfoDev
Oxford University Computing Services
University of Oxford

From sebastian.rahtz at oucs.ox.ac.uk  Mon Jun 25 16:37:02 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Mon, 25 Jun 2012 20:37:02 +0000
Subject: [tei-council] Strange validation problem with ODD file
In-Reply-To: <4FE8A95F.6020707@uvic.ca>
References: <4FE8983E.7080405@uvic.ca>
	<4FE89C30.3080005@retired.ox.ac.uk>,<4FE89D97.5030608@uvic.ca>
	<48af22b0-a40b-4682-9fb2-a424a36b3a2f@HUB05.ad.oak.ox.ac.uk>
	<4FE8A95F.6020707@uvic.ca>
Message-ID: <166C8C07-FE94-4882-ACAF-1250BA002952@oucs.ox.ac.uk>

you ought to talk to oxygen support ASAP, IMHO...
--
Sebastian Rahtz      
Head of Information and Support Group
Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431







From mholmes at uvic.ca  Mon Jun 25 18:18:45 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Mon, 25 Jun 2012 15:18:45 -0700
Subject: [tei-council] Strange validation problem with ODD file
In-Reply-To: <166C8C07-FE94-4882-ACAF-1250BA002952@oucs.ox.ac.uk>
References: <4FE8983E.7080405@uvic.ca> <4FE89C30.3080005@retired.ox.ac.uk>,
	<4FE89D97.5030608@uvic.ca>
	<48af22b0-a40b-4682-9fb2-a424a36b3a2f@HUB05.ad.oak.ox.ac.uk>
	<4FE8A95F.6020707@uvic.ca>
	<166C8C07-FE94-4882-ACAF-1250BA002952@oucs.ox.ac.uk>
Message-ID: <4FE8E3C5.7070003@uvic.ca>

I've posted on their forum.

It's always bothered me a bit that Oxygen finds a schema to validate 
your files against without telling you. I've had a couple of situations 
in the past where a project schema has been moved, and the XML files 
linking to it were not correctly updated; instead of complaining that 
the schema was missing, Oxygen quietly began validating the files 
against something else from the framework (I think it was tei_all), 
which gave our encoders the freedom to use all sorts of stuff that 
wasn't in our project schema.

Cheers,
Martin

On 12-06-25 01:37 PM, Sebastian Rahtz wrote:
> you ought to talk to oxygen support ASAP, IMHO...
> --
> Sebastian Rahtz
> Head of Information and Support Group
> Oxford University Computing Services
> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>
>
>
>
>
>
>

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)



From bansp at o2.pl  Tue Jun 26 05:04:11 2012
From: bansp at o2.pl (=?ISO-8859-2?Q?Piotr_Ba=F1ski?=)
Date: Tue, 26 Jun 2012 11:04:11 +0200
Subject: [tei-council] tei-notify
Message-ID: <4FE97B0B.20608@o2.pl>

Hi all,

What's up with the TEI-notify list? It was set up as a hook for SVN
commits, now it appears to add messages from the Tracker, which seems
rather spammy.

Thanks,

  P.

From James.Cummings at oucs.ox.ac.uk  Tue Jun 26 05:37:41 2012
From: James.Cummings at oucs.ox.ac.uk (James Cummings)
Date: Tue, 26 Jun 2012 10:37:41 +0100
Subject: [tei-council] tei-notify
In-Reply-To: <4FE97B0B.20608@o2.pl>
References: <4FE97B0B.20608@o2.pl>
Message-ID: <4FE982E5.7050103@oucs.ox.ac.uk>

On 26/06/12 10:04, Piotr Ba?ski wrote:
> Hi all,
>
> What's up with the TEI-notify list? It was set up as a hook for SVN
> commits, now it appears to add messages from the Tracker, which seems
> rather spammy.

Hi Piotr.

That is my fault.  Some people seem to have problems getting 
notifications from SF trackers (even though subscribed, 
monitoring, and watching).  I was playing with having tei-notify 
do this as a potential solution.

If you guys think it is spammy, I'll turn it off.

-James

-- 
Dr James Cummings, InfoDev,
OUCS, University of Oxford

From kevin.s.hawkins at ultraslavonic.info  Tue Jun 26 05:52:31 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Tue, 26 Jun 2012 05:52:31 -0400
Subject: [tei-council] tei-notify
In-Reply-To: <4FE982E5.7050103@oucs.ox.ac.uk>
References: <4FE97B0B.20608@o2.pl> <4FE982E5.7050103@oucs.ox.ac.uk>
Message-ID: <4FE9865F.90603@ultraslavonic.info>

Let me just say that I have had trouble getting notifications from SF 
too.  I've been trying to notice a pattern, especially whether I get 
different results for feature requests and bugs, but I haven't tracked 
(ha!) on the problem closely enough.

On 6/26/12 5:37 AM, James Cummings wrote:
> On 26/06/12 10:04, Piotr Ba?ski wrote:
>> Hi all,
>>
>> What's up with the TEI-notify list? It was set up as a hook for SVN
>> commits, now it appears to add messages from the Tracker, which seems
>> rather spammy.
>
> Hi Piotr.
>
> That is my fault.  Some people seem to have problems getting
> notifications from SF trackers (even though subscribed,
> monitoring, and watching).  I was playing with having tei-notify
> do this as a potential solution.
>
> If you guys think it is spammy, I'll turn it off.
>
> -James
>


From bansp at o2.pl  Tue Jun 26 06:08:52 2012
From: bansp at o2.pl (=?ISO-8859-2?Q?Piotr_Ba=F1ski?=)
Date: Tue, 26 Jun 2012 12:08:52 +0200
Subject: [tei-council] tei-notify
In-Reply-To: <4FE982E5.7050103@oucs.ox.ac.uk>
References: <4FE97B0B.20608@o2.pl> <4FE982E5.7050103@oucs.ox.ac.uk>
Message-ID: <4FE98A34.8000809@o2.pl>

Hi James,

I don't think mixing these streams (...) is the right way to go -- you
might want to create another mailing list to gather Tracker
notifications, for those who have problems getting them, but, as it is,
some of us will get double mails, and these are two different kinds of
info really.

And in that hypothetical new list, you could set the topic prefix to be
null, perhaps.

Best,

  P.

On 26/06/12 11:37, James Cummings wrote:
> On 26/06/12 10:04, Piotr Ba?ski wrote:
>> Hi all,
>>
>> What's up with the TEI-notify list? It was set up as a hook for SVN
>> commits, now it appears to add messages from the Tracker, which seems
>> rather spammy.
> 
> Hi Piotr.
> 
> That is my fault.  Some people seem to have problems getting 
> notifications from SF trackers (even though subscribed, 
> monitoring, and watching).  I was playing with having tei-notify 
> do this as a potential solution.
> 
> If you guys think it is spammy, I'll turn it off.
> 
> -James
> 


From lou.burnard at retired.ox.ac.uk  Tue Jun 26 11:36:27 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Tue, 26 Jun 2012 16:36:27 +0100
Subject: [tei-council] Garagiste off piste?
Message-ID: <4FE9D6FB.50204@retired.ox.ac.uk>

Has anyone succeeded in getting Oxgarage to do a P4 to P5 conversion 
recently?

I've tried a couple of different P4 files on it, and always get the same 
inscrutable message:

"Error occured. Please check the filetype and try again.?

Error: class pl.psnc.dl.ege.exception.ConverterException

The requested initial template, with expanded name main, does not exist"


From mholmes at uvic.ca  Tue Jun 26 11:48:00 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Tue, 26 Jun 2012 08:48:00 -0700
Subject: [tei-council] Garagiste off piste?
In-Reply-To: <4FE9D6FB.50204@retired.ox.ac.uk>
References: <4FE9D6FB.50204@retired.ox.ac.uk>
Message-ID: <4FE9D9B0.8080302@uvic.ca>

I just tested this and got the same bug:

Error occured. Please check the filetype and try again.?
Error: class pl.psnc.dl.ege.exception.ConverterException
The requested initial template, with expanded name main, does not exist

Cheers,
Martin

On 12-06-26 08:36 AM, Lou Burnard wrote:
> Has anyone succeeded in getting Oxgarage to do a P4 to P5 conversion
> recently?
>
> I've tried a couple of different P4 files on it, and always get the same
> inscrutable message:
>
> "Error occured. Please check the filetype and try again.?
>
> Error: class pl.psnc.dl.ege.exception.ConverterException
>
> The requested initial template, with expanded name main, does not exist"
>

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)



From mholmes at uvic.ca  Tue Jun 26 11:57:34 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Tue, 26 Jun 2012 08:57:34 -0700
Subject: [tei-council] tei winita needs to be updated to RFC 4646 ???
Message-ID: <4FE9DBEE.8000508@uvic.ca>

I'm following up on the requirement to check that our CH chapter in fact 
conforms with BCP 47, and I see this in the CH file:

<?tei winita needs to be updated to RFC 4646 ?>

It looks like a processing instruction, but not of a type I've seen 
before, and I don't recall coming across anything called "winita". Can 
anyone clarify what this is? Does it do anything, and if not, could it 
be removed?

Cheers,
Martin
-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)


From sebastian.rahtz at oucs.ox.ac.uk  Tue Jun 26 12:07:57 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Tue, 26 Jun 2012 16:07:57 +0000
Subject: [tei-council] tei winita needs to be updated to RFC 4646 ???
In-Reply-To: <4FE9DBEE.8000508@uvic.ca>
References: <4FE9DBEE.8000508@uvic.ca>
Message-ID: <F37B8F6A-02AC-44EC-AE8F-81DB3518D22F@oucs.ox.ac.uk>


On 26 Jun 2012, at 16:57, Martin Holmes wrote:

> I'm following up on the requirement to check that our CH chapter in fact 
> conforms with BCP 47, and I see this in the CH file:
> 
> <?tei winita needs to be updated to RFC 4646 ?>
> 
> It looks like a processing instruction, but not of a type I've seen 
> before, and I don't recall coming across anything called "winita". Can 
> anyone clarify what this is? Does it do anything, and if not, could it 
> be removed?



it doesn't do anything.  it was a private annotation the editors used to use in
the Olde Tymes. I recall it is an acronym with some "amusing" expansion.
but you can safely remove if its redundant now.
--
Sebastian Rahtz      
Head of Information and Support Group
Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431

S?lo le pido a Dios
que el futuro no me sea indiferente


From James.Cummings at oucs.ox.ac.uk  Tue Jun 26 12:09:03 2012
From: James.Cummings at oucs.ox.ac.uk (James Cummings)
Date: Tue, 26 Jun 2012 17:09:03 +0100
Subject: [tei-council] tei winita needs to be updated to RFC 4646 ???
In-Reply-To: <F37B8F6A-02AC-44EC-AE8F-81DB3518D22F@oucs.ox.ac.uk>
References: <4FE9DBEE.8000508@uvic.ca>
	<F37B8F6A-02AC-44EC-AE8F-81DB3518D22F@oucs.ox.ac.uk>
Message-ID: <4FE9DE9F.8060200@oucs.ox.ac.uk>

On 26/06/12 17:07, Sebastian Rahtz wrote:
> it doesn't do anything.  it was a private annotation the editors used to use in
> the Olde Tymes. I recall it is an acronym with some "amusing" expansion.
> but you can safely remove if its redundant now.

At worst it should become a comment. ;-)

-James

-- 
Dr James Cummings, InfoDev,
OUCS, University of Oxford

From mholmes at uvic.ca  Tue Jun 26 12:17:45 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Tue, 26 Jun 2012 09:17:45 -0700
Subject: [tei-council] CH and BCP 47 again
Message-ID: <4FE9E0A9.4090302@uvic.ca>

Re-examining the CH chapter and BCP 47, I have a couple of things I'd 
like to run by you. The first is this bit:

"Languages are identified by a language subtag, which may be a two 
letter code taken from ISO 639-1 or a three letter code taken from ISO 
639-2."

This is in line with BCP 47, which does not AFAICS express a preference 
for two- or three-letter codes where both exist. However, in our own 
practice in the Guidelines, we decided to use two-letter codes from ISO 
639-1 where these exist, and only use three-letter codes from 639-2 
where there is no two-letter code. I have a feeling this was because 
this appears to be what the iana language-subtag-registry does:

<http://www.iana.org/assignments/language-subtag-registry>

You can see, for instance, that Modern Greek is "el" (639-1) rather than 
the available "ell" and "gre" from 639-2. (Both sets are listed in 
<http://www.loc.gov/standards/iso639-2/php/code_list.php>.)

Also BCP 47 notes this: "When languages have both an ISO 639-1 
two-character code and a three-character code (assigned by ISO 639-2, 
ISO 639-3, or ISO 639-5), only the ISO 639-1 two-character code is 
defined in the IANA registry."

Therefore I would like to supplement our explanation above, like this:

"Languages are identified by a language subtag, which may be a two 
letter code taken from ISO 639-1 or a three letter code taken from ISO 
639-2. The practice in these Guidelines is to prefer a two-letter code 
from ISO 639-1 where one exists, following the practice in the IANA 
Language Subtag Registry, and we recommend that encoders also follow 
this convention."

Secondly, there are two specific examples of extended tags in CH which I 
find it hard to parse according to the rules:

zh-s-nan (the Southern Min language of the macrolanguage Chinese)

zh-s-nan-Hans-CN (the Southern Min language of the macrolanguage Chinese 
as spoken in China written in simplified Characters)

The use of s-nan seems incorrect to me, and I can find no examples of it 
in the wild. If anyone remembers the source for these tags, could you 
explain it to me?

Cheers,
Martin

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)


From lou.burnard at retired.ox.ac.uk  Tue Jun 26 12:30:40 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Tue, 26 Jun 2012 17:30:40 +0100
Subject: [tei-council] CH and BCP 47 again
In-Reply-To: <4FE9E0A9.4090302@uvic.ca>
References: <4FE9E0A9.4090302@uvic.ca>
Message-ID: <4FE9E3B0.7060606@retired.ox.ac.uk>

On 26/06/12 17:17, Martin Holmes wrote:
  Secondly, there are two specific examples of extended tags in CH which I
> find it hard to parse according to the rules:
>
> zh-s-nan (the Southern Min language of the macrolanguage Chinese)
>
> zh-s-nan-Hans-CN (the Southern Min language of the macrolanguage Chinese
> as spoken in China written in simplified Characters)
>
> The use of s-nan seems incorrect to me, and I can find no examples of it
> in the wild. If anyone remembers the source for these tags, could you
> explain it to me?
>
>

These tags were originally suggested by Chris Wittern, I believe, though 
they may have been corrupted in transmission. CC-ing him to see.



From mholmes at uvic.ca  Tue Jun 26 12:32:26 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Tue, 26 Jun 2012 09:32:26 -0700
Subject: [tei-council] Extended language subtags must begin with the letter
	"s".???
Message-ID: <4FE9E41A.8010209@uvic.ca>

CH says:

"Extended language subtags must begin with the letter "s".
  They must follow the primary subtag and precede subtags that do
  define other properties of the language.  The order is significant."

I can't find any justification for this in BCP 47 or anywhere else, and 
it's surely untrue -- . Does anyone know where this came from? Basic 
examples from BCP 47 surely counter it, too:

"zh-gan", "zh-yue", "zh-cmn"

I'm copying Syd on this because he knows a lot about this stuff.

Cheers,
Martin
-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)


From sebastian.rahtz at oucs.ox.ac.uk  Tue Jun 26 12:36:38 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Tue, 26 Jun 2012 16:36:38 +0000
Subject: [tei-council] Garagiste off piste?
In-Reply-To: <4FE9D9B0.8080302@uvic.ca>
References: <4FE9D6FB.50204@retired.ox.ac.uk> <4FE9D9B0.8080302@uvic.ca>
Message-ID: <4006f7cc-a02c-49a2-9e53-716666f91144@HUB05.ad.oak.ox.ac.uk>

curl -s  -F upload=@testp4.xml  -o result.xml http://oxgarage.oucs.ox.ac.uk:8080/ege-webservice/Conversions/P4%3Atext%3Axml/TEI%3Atext%3Axml/

works fine for me

I expect you've done something like

 - uploaded a file with a DOCTYPE pointing to a local DTD
 - uploaded a file with entity refs but no DTD
 - used OxGarage when it was having its nap after lunch

why you two use OxGarage when the job is a command-line away, who knos :-}
--
Sebastian Rahtz      
Head of Information and Support Group
Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431

S?lo le pido a Dios
que el futuro no me sea indiferente


From lou.burnard at retired.ox.ac.uk  Tue Jun 26 12:39:24 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Tue, 26 Jun 2012 17:39:24 +0100
Subject: [tei-council] Garagiste off piste?
In-Reply-To: <4FE9D9B0.8080302@uvic.ca>
References: <4FE9D6FB.50204@retired.ox.ac.uk> <4FE9D9B0.8080302@uvic.ca>
Message-ID: <4FE9E5BC.2020503@retired.ox.ac.uk>

Yes, it's definitely shot. Tried it with the TEI Lite template P4 file 
from Oxygen and got the same result.

Since the underlying stylesheet (in svn at P4toP5/p4top5.xsl) seems to 
work ok, I assume this is a bug in the garage somewhere


On 26/06/12 16:48, Martin Holmes wrote:
> I just tested this and got the same bug:
>
> Error occured. Please check the filetype and try again.?
> Error: class pl.psnc.dl.ege.exception.ConverterException
> The requested initial template, with expanded name main, does not exist
>
> Cheers,
> Martin
>
> On 12-06-26 08:36 AM, Lou Burnard wrote:
>> Has anyone succeeded in getting Oxgarage to do a P4 to P5 conversion
>> recently?
>>
>> I've tried a couple of different P4 files on it, and always get the same
>> inscrutable message:
>>
>> "Error occured. Please check the filetype and try again.?
>>
>> Error: class pl.psnc.dl.ege.exception.ConverterException
>>
>> The requested initial template, with expanded name main, does not exist"
>>
>


From James.Cummings at oucs.ox.ac.uk  Tue Jun 26 12:44:40 2012
From: James.Cummings at oucs.ox.ac.uk (James Cummings)
Date: Tue, 26 Jun 2012 17:44:40 +0100
Subject: [tei-council] Council Face2Face in September
Message-ID: <4FE9E6F8.1040803@oucs.ox.ac.uk>


Hi all,

For the last two days of the three-day council face2face (19-21 
September) in Oxford, I've booked us into Wolfson College. The 
first day we will spend in OUCS. See 
http://www.wolfson.ox.ac.uk/conference

Ensuite Accommodation is also available at Wolfson College for 
those who need it and have not already booked elsewhere, and 
includes breakfast. As with the hotel in Ann Arbor, we will pay 
for the accommodation and claim it back as a block from TEI-C 
which should result in some cost efficiencies.  Wolfson, while 
quite modern itself, is in a very pretty location and a short 
countryside walk to a nice pub.

Please email your requirements to events at wolfson.ox.ac.uk quoting 
'TEI Council Meeting' as soon as possible.  (Possibly CC'ing me 
in on the initial email so I know that you have done so.)

Some information about the Wolfson College accommodation is below:

===
WOLFSON COLLEGE SUMMER B&B and HOLIDAY ACCOMMODATION

Here at Wolfson, we offer summertime accommodation ? both on a 
short-stay ?B&B? basis, and also for longer term holiday lets. In 
Summer 2012, bedrooms are available from 9th August through to 
25th September.

As a modern College, built in the mid-1970?s, all accommodation 
is in contemporary buildings. The bedrooms used for guest 
bookings are in our most recent buildings, well decorated and 
well maintained. Bedrooms are single rooms, all en-suite; not 
?posh? but very comfortable, immaculately clean (as is the whole 
of the College), well furnished and decorated. They are serviced 
(weekdays daily for B&B, weekly for long lets), with linens, 
towels, welcome toiletries and internet provided. A particularly 
attractive feature is that bedrooms are grouped in sets of 9 
along a corridor, with a large shared ?Common Room? comprising 
Kitchen/Lounge at the end. These have all modern appliances, and 
provide a very attractive and pleasant space for informal 
socialising and relaxing, with tea trays provided. A limited 
quantity of on-site parking is available, by prior arrangement. 
There is 24 hour access, and a very warm welcome.

For those on a ?B&B? August booking, breakfast is served in the 
College?s modern dining Hall with its very striking ?pyramid? 
ceiling. Breakfast cuisine is a seasonal and hearty buffet 
spread, enhancing the usual Continental format with trays of 
sliced meats and cheeses and fruit platters. Seating is at 
attractively laid tables, and hot drinks are served by attentive 
waiting staff.

Located in affluent, residential North Oxford, Wolfson is only a 
5 minute bus ride from the City Centre ? but feels like rustic 
English countryside. The College grounds are green and beautiful, 
with lush lawns leading down to a private harbour.  A rainbow 
arch bridge over the River Cherwell leads to open meadow land. 
  It?s a scenic and relaxing summertime setting, with a multitude 
of wild birds and blossoms, yet the convenience of Summertown?s 
shops and amenities just a short walk away.

Rates depend on number of rooms booked and length of stay, with 
pricing very good value indeed and payment terms very flexible. 
The booking process is very easy ? simply email or phone:

Louise Gordon, Conference Manager, Wolfson College
Email events at wolfson.ox.ac.uk
Telephone 01865 274083


Wolfson College: experience and enjoy ?Town, Gown and Country? 
rolled into one!
====


Best,
James


-- 
Dr James Cummings, InfoDev,
OUCS, University of Oxford

From lou.burnard at retired.ox.ac.uk  Tue Jun 26 12:45:25 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Tue, 26 Jun 2012 17:45:25 +0100
Subject: [tei-council] Garagiste off piste?
In-Reply-To: <9BDE18BE-7E60-4C19-849A-3AF802F60655@oucs.ox.ac.uk>
References: <4FE9D6FB.50204@retired.ox.ac.uk> <4FE9D9B0.8080302@uvic.ca>
	<9BDE18BE-7E60-4C19-849A-3AF802F60655@oucs.ox.ac.uk>
Message-ID: <4FE9E725.8020402@retired.ox.ac.uk>

On 26/06/12 17:36, Sebastian Rahtz wrote:
> curl -s  -F upload=@testp4.xml  -o result.xml http://oxgarage.oucs.ox.ac.uk:8080/ege-webservice/Conversions/P4%3Atext%3Axml/TEI%3Atext%3Axml/
>
> works fine for me
>
> I expect you've done something like
>
>   - uploaded a file with a DOCTYPE pointing to a local DTD
>   - uploaded a file with entity refs but no DTD
>   - used OxGarage when it was having its nap after lunch
>
> why you two use OxGarage when the job is a command-line away, who knos :-}

Well, speaking for myself, we have this naive idea that if  a nice 
simple web interface exists we might as well use it. And that if 
something is wrong with our input a nice simple interface might give us 
a bit of a clue as to what it was.





From sebastian.rahtz at oucs.ox.ac.uk  Tue Jun 26 12:46:27 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Tue, 26 Jun 2012 16:46:27 +0000
Subject: [tei-council] Garagiste off piste?
In-Reply-To: <4FE9E725.8020402@retired.ox.ac.uk>
References: <4FE9D6FB.50204@retired.ox.ac.uk> <4FE9D9B0.8080302@uvic.ca>
	<9BDE18BE-7E60-4C19-849A-3AF802F60655@oucs.ox.ac.uk>
	<4FE9E725.8020402@retired.ox.ac.uk>
Message-ID: <a644da2f-e2b5-4500-aaf7-908c945aef49@HUB01.ad.oak.ox.ac.uk>


On 26 Jun 2012, at 17:45, Lou Burnard wrote:
> 
> Well, speaking for myself, we have this naive idea that if  a nice simple web interface exists we might as well use it. And that if something is wrong with our input a nice simple interface might give us a bit of a clue as to what it was.

you're weird ?.. :-}

anyway, are you telling me it still fails?
--
Sebastian Rahtz      
Head of Information and Support Group
Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431

S?lo le pido a Dios
que el futuro no me sea indiferente


From kevin.s.hawkins at ultraslavonic.info  Tue Jun 26 13:11:00 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Tue, 26 Jun 2012 13:11:00 -0400
Subject: [tei-council] CH and BCP 47 again
In-Reply-To: <4FE9E0A9.4090302@uvic.ca>
References: <4FE9E0A9.4090302@uvic.ca>
Message-ID: <4FE9ED24.90907@ultraslavonic.info>

On 6/26/12 12:17 PM, Martin Holmes wrote:
> Re-examining the CH chapter and BCP 47, I have a couple of things I'd
> like to run by you. The first is this bit:
>
> "Languages are identified by a language subtag, which may be a two
> letter code taken from ISO 639-1 or a three letter code taken from ISO
> 639-2."
>
> This is in line with BCP 47, which does not AFAICS express a preference
> for two- or three-letter codes where both exist.

No, it does express this preference.  On page 4, it says that the 
language code must be the "shortest ISO 639 code".

--K.

From lou.burnard at retired.ox.ac.uk  Tue Jun 26 13:35:33 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Tue, 26 Jun 2012 18:35:33 +0100
Subject: [tei-council] Garagiste off piste?
In-Reply-To: <BFE52376-C256-4244-89F5-D691A6E8D515@oucs.ox.ac.uk>
References: <4FE9D6FB.50204@retired.ox.ac.uk> <4FE9D9B0.8080302@uvic.ca>
	<9BDE18BE-7E60-4C19-849A-3AF802F60655@oucs.ox.ac.uk>
	<4FE9E725.8020402@retired.ox.ac.uk>
	<BFE52376-C256-4244-89F5-D691A6E8D515@oucs.ox.ac.uk>
Message-ID: <4FE9F2E5.6060707@retired.ox.ac.uk>

On 26/06/12 17:46, Sebastian Rahtz wrote:
>
> On 26 Jun 2012, at 17:45, Lou Burnard wrote:
>>
>> Well, speaking for myself, we have this naive idea that if  a nice simple web interface exists we might as well use it. And that if something is wrong with our input a nice simple interface might give us a bit of a clue as to what it was.
>
> you're weird ?.. :-}
>
> anyway, are you telling me it still fails?
> --
>

Yus. There are two failures, both in the roma interface.

a) if you give it a crap document (the doc I was using turns out to be a 
TEI P3 SGML doc, not a P4 XML one at all: it was just lying to me), then 
it doesn't fail with a useful error message. It should say "Document 
format unrecognised" or something sensible.

b) more seriously, once you have uploaded a crap document, every time 
you try giving it a different one (even if it's not crap), yoiu get the 
same error message. That's my current theory anyway: I have two 
documents which work fine at the command line, but which now both give 
the rubbish error message quoted earlier in the web app. I even tried 
reloading the garage, but the same thing happens, so it must be on the 
server.




From mholmes at uvic.ca  Tue Jun 26 13:38:21 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Tue, 26 Jun 2012 10:38:21 -0700
Subject: [tei-council] Roma or Roma2?
Message-ID: <4FE9F38D.3080701@uvic.ca>

For a long time now, I've been using a bookmark that points to Roma2:

http://www.tei-c.org/Roma2/

and I assumed that was the current version of Roma. But the TEI site 
links to plain Roma:

http://www.tei-c.org/Roma/

and they're different (different wording on the landing page, at any rate).

Which is the most up-to-date version? Should the other one be made to 
disappear?

Cheers,
Martin
-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)


From lou.burnard at retired.ox.ac.uk  Tue Jun 26 13:59:11 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Tue, 26 Jun 2012 18:59:11 +0100
Subject: [tei-council] Garagiste off piste?
In-Reply-To: <4FE9F2E5.6060707@retired.ox.ac.uk>
References: <4FE9D6FB.50204@retired.ox.ac.uk> <4FE9D9B0.8080302@uvic.ca>
	<9BDE18BE-7E60-4C19-849A-3AF802F60655@oucs.ox.ac.uk>
	<4FE9E725.8020402@retired.ox.ac.uk>
	<BFE52376-C256-4244-89F5-D691A6E8D515@oucs.ox.ac.uk>
	<4FE9F2E5.6060707@retired.ox.ac.uk>
Message-ID: <4FE9F86F.9050105@retired.ox.ac.uk>

On 26/06/12 18:35, Lou Burnard wrote:
>
>
> b) more seriously, once you have uploaded a crap document, every time
> you try giving it a different one (even if it's not crap), yoiu get the
> same error message. That's my current theory anyway: I have two
> documents which work fine at the command line, but which now both give
> the rubbish error message quoted earlier in the web app. I even tried
> reloading the garage, but the same thing happens, so it must be on the
> server.
>

You'll be glad to know this hypothesis has now been entirely disproved.
User error.

However, the other problem remains...

From sebastian.rahtz at oucs.ox.ac.uk  Tue Jun 26 14:40:04 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Tue, 26 Jun 2012 18:40:04 +0000
Subject: [tei-council] Roma or Roma2?
In-Reply-To: <4FE9F38D.3080701@uvic.ca>
References: <4FE9F38D.3080701@uvic.ca>
Message-ID: <6BF5288F-B2A1-459D-B7FB-5B2C4DC5AECF@oucs.ox.ac.uk>


On 26 Jun 2012, at 18:38, Martin Holmes wrote:

> For a long time now, I've been using a bookmark that points to Roma2:
> 
> http://www.tei-c.org/Roma2/
> 
> and I assumed that was the current version of Roma. But the TEI site 
> links to plain Roma:
> 
> http://www.tei-c.org/Roma/
> 
> and they're different (different wording on the landing page, at any rate).
> 
> Which is the most up-to-date version? Should the other one be made to 
> disappear?


well I never. Roma2 is a relic. Kill it, someone?...
--
Sebastian Rahtz      
Head of Information and Support Group
Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431

S?lo le pido a Dios
que el futuro no me sea indiferente


From sebastian.rahtz at oucs.ox.ac.uk  Tue Jun 26 14:43:32 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Tue, 26 Jun 2012 18:43:32 +0000
Subject: [tei-council] Garagiste off piste?
In-Reply-To: <4FE9F2E5.6060707@retired.ox.ac.uk>
References: <4FE9D6FB.50204@retired.ox.ac.uk> <4FE9D9B0.8080302@uvic.ca>
	<9BDE18BE-7E60-4C19-849A-3AF802F60655@oucs.ox.ac.uk>
	<4FE9E725.8020402@retired.ox.ac.uk>
	<BFE52376-C256-4244-89F5-D691A6E8D515@oucs.ox.ac.uk>
	<4FE9F2E5.6060707@retired.ox.ac.uk>
Message-ID: <daad0bc6-1042-4c69-9859-5174b0ebeb52@HUB05.ad.oak.ox.ac.uk>


On 26 Jun 2012, at 18:35, Lou Burnard wrote:

> Yus. There are two failures, both in the roma interface.
> 
> a) if you give it a crap document (the doc I was using turns out to be a TEI P3 SGML doc, not a P4 XML one at all: it was just lying to me), then it doesn't fail with a useful error message. It should say "Document format unrecognised" or something sensible.
> 

I agree, it's a nice idea. I think the best we could do is build in a step which first does an XML well-formedness step
and reports on that. God knows how I can find time to look at that. one day.

but really, oxgarage does assume in general that what you feed it is what you claim it is, so this
isn't a bug. its a UX issue. 
--
Sebastian Rahtz      
Head of Information and Support Group
Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431

S?lo le pido a Dios
que el futuro no me sea indiferente


From dsewell at virginia.edu  Tue Jun 26 14:46:41 2012
From: dsewell at virginia.edu (David Sewell)
Date: Tue, 26 Jun 2012 14:46:41 -0400 (EDT)
Subject: [tei-council] Roma or Roma2?
In-Reply-To: <6BF5288F-B2A1-459D-B7FB-5B2C4DC5AECF@oucs.ox.ac.uk>
References: <4FE9F38D.3080701@uvic.ca>
	<6BF5288F-B2A1-459D-B7FB-5B2C4DC5AECF@oucs.ox.ac.uk>
Message-ID: <alpine.OSX.2.00.1206261442490.65194@lister.ei.virginia.edu>

Literally kill? I might or might not have user permissions to get rid of the 
directory, but I can try. Then in the Apache config file, redirect to standard 
Roma? I.e. change from

RewriteRule "^/Roma/(.*)" /usr/share/tei-roma/$1 [L]

to

RewriteRule "^/Roma2?/(.*)" /usr/share/tei-roma/$1 [L]

? (Shayne would have to do that I think).

On Tue, 26 Jun 2012, Sebastian Rahtz wrote:

>
> On 26 Jun 2012, at 18:38, Martin Holmes wrote:
>
>> For a long time now, I've been using a bookmark that points to Roma2:
>>
>> http://www.tei-c.org/Roma2/
>>
>> and I assumed that was the current version of Roma. But the TEI site
>> links to plain Roma:
>>
>> http://www.tei-c.org/Roma/
>>
>> and they're different (different wording on the landing page, at any rate).
>>
>> Which is the most up-to-date version? Should the other one be made to
>> disappear?
>
>
> well I never. Roma2 is a relic. Kill it, someone?...
> --
> Sebastian Rahtz
> Head of Information and Support Group
> Oxford University Computing Services
> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>
> S?lo le pido a Dios
> que el futuro no me sea indiferente
>
>

-- 
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 Jun 26 14:48:03 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Tue, 26 Jun 2012 18:48:03 +0000
Subject: [tei-council] Roma or Roma2?
In-Reply-To: <alpine.OSX.2.00.1206261442490.65194@lister.ei.virginia.edu>
References: <4FE9F38D.3080701@uvic.ca>
	<6BF5288F-B2A1-459D-B7FB-5B2C4DC5AECF@oucs.ox.ac.uk>
	<alpine.OSX.2.00.1206261442490.65194@lister.ei.virginia.edu>
Message-ID: <9C669017-B0A7-4413-90ED-D868147CACE8@oucs.ox.ac.uk>


On 26 Jun 2012, at 19:46, David Sewell wrote:

> Literally kill? I might or might not have user permissions to get rid of the directory, but I can try. Then in the Apache config file, redirect to standard Roma? I.e. change from
> 
> RewriteRule "^/Roma/(.*)" /usr/share/tei-roma/$1 [L]
> 
> to
> 
> RewriteRule "^/Roma2?/(.*)" /usr/share/tei-roma/$1 [L]
> 
> ? (Shayne would have to do that I think).


unless I am going mad, yes. certainly I have no concept of two romas in my head.
--
Sebastian Rahtz      
Head of Information and Support Group
Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431

S?lo le pido a Dios
que el futuro no me sea indiferente


From mholmes at uvic.ca  Tue Jun 26 15:30:08 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Tue, 26 Jun 2012 12:30:08 -0700
Subject: [tei-council] CH and BCP 47 again
In-Reply-To: <4FE9ED24.90907@ultraslavonic.info>
References: <4FE9E0A9.4090302@uvic.ca> <4FE9ED24.90907@ultraslavonic.info>
Message-ID: <4FEA0DC0.1030205@uvic.ca>

On 12-06-26 10:11 AM, Kevin Hawkins wrote:
> On 6/26/12 12:17 PM, Martin Holmes wrote:
>> Re-examining the CH chapter and BCP 47, I have a couple of things I'd
>> like to run by you. The first is this bit:
>>
>> "Languages are identified by a language subtag, which may be a two
>> letter code taken from ISO 639-1 or a three letter code taken from ISO
>> 639-2."
>>
>> This is in line with BCP 47, which does not AFAICS express a preference
>> for two- or three-letter codes where both exist.
>
> No, it does express this preference.  On page 4, it says that the
> language code must be the "shortest ISO 639 code".

Thanks Kevin, I missed that. I've made it explicit in our chapter now.

Cheers,
Martin

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)



From James.Cummings at oucs.ox.ac.uk  Tue Jun 26 15:35:09 2012
From: James.Cummings at oucs.ox.ac.uk (James Cummings)
Date: Tue, 26 Jun 2012 20:35:09 +0100
Subject: [tei-council] Roma or Roma2?
In-Reply-To: <9C669017-B0A7-4413-90ED-D868147CACE8@oucs.ox.ac.uk>
References: <4FE9F38D.3080701@uvic.ca>
	<6BF5288F-B2A1-459D-B7FB-5B2C4DC5AECF@oucs.ox.ac.uk>
	<alpine.OSX.2.00.1206261442490.65194@lister.ei.virginia.edu>
	<9C669017-B0A7-4413-90ED-D868147CACE8@oucs.ox.ac.uk>
Message-ID: <4FEA0EED.9000906@oucs.ox.ac.uk>

On 26/06/12 19:48, Sebastian Rahtz wrote:
> unless I am going mad, yes. certainly I have no concept of two romas in my head.

I think you set this up when you first moved to using xslt2 
stylesheets for roma.  That is my dim recollection at least.

-James
-- 
Dr James Cummings, InfoDev
Oxford University Computing Services
University of Oxford

From syeates at gmail.com  Tue Jun 26 17:14:56 2012
From: syeates at gmail.com (Stuart A. Yeates)
Date: Wed, 27 Jun 2012 09:14:56 +1200
Subject: [tei-council] CH and BCP 47 again
In-Reply-To: <4FEA0DC0.1030205@uvic.ca>
References: <4FE9E0A9.4090302@uvic.ca> <4FE9ED24.90907@ultraslavonic.info>
	<4FEA0DC0.1030205@uvic.ca>
Message-ID: <CAC_Lu0ZzE6eEF8rJGGaeGhnsuTzS+CRbaM6PxTvQfDBHHR9WRQ@mail.gmail.com>

On a related note (and not covered in CH or BCP 47 as far as I can tell):

Almost all the <pron/> examples in
http://www.tei-c.org/release/doc/tei-p5-doc/en/html/examples-pron.html
use a different script to the surrounding text, but none of them have
an xml:lang attribute describing that.

Does <pron/> have an exception from xml:lang, or do we need to add
them to the examples?

cheers
stuart

From kevin.s.hawkins at ultraslavonic.info  Tue Jun 26 22:07:19 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Tue, 26 Jun 2012 22:07:19 -0400
Subject: [tei-council] CH and BCP 47 again
In-Reply-To: <CAC_Lu0ZzE6eEF8rJGGaeGhnsuTzS+CRbaM6PxTvQfDBHHR9WRQ@mail.gmail.com>
References: <4FE9E0A9.4090302@uvic.ca> <4FE9ED24.90907@ultraslavonic.info>
	<4FEA0DC0.1030205@uvic.ca>
	<CAC_Lu0ZzE6eEF8rJGGaeGhnsuTzS+CRbaM6PxTvQfDBHHR9WRQ@mail.gmail.com>
Message-ID: <4FEA6AD7.1090102@ultraslavonic.info>

There is no particular exception to use of @xml:lang on <pron> that I am 
aware of.  As a global attribute, @xml:lang may be used on any element 
but need not be used anywhere.

I am inclined not to bother inserting @xml:lang on these examples.  If 
you encode a dictionary, every <pron> will likely use the same script as 
every other <pron>, and this will be the only part of the dictionary 
using this script (whatever it is).  I can't imagine a use case for 
recording on individual <pron>s.

--K.

On 6/26/12 5:14 PM, Stuart A. Yeates wrote:
> On a related note (and not covered in CH or BCP 47 as far as I can tell):
>
> Almost all the <pron/> examples in
> http://www.tei-c.org/release/doc/tei-p5-doc/en/html/examples-pron.html
> use a different script to the surrounding text, but none of them have
> an xml:lang attribute describing that.
>
> Does <pron/> have an exception from xml:lang, or do we need to add
> them to the examples?
>
> cheers
> stuart
>


From mholmes at uvic.ca  Tue Jun 26 23:09:38 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Tue, 26 Jun 2012 20:09:38 -0700
Subject: [tei-council] CH and BCP 47 again
In-Reply-To: <4FEA6AD7.1090102@ultraslavonic.info>
References: <4FE9E0A9.4090302@uvic.ca> <4FE9ED24.90907@ultraslavonic.info>
	<4FEA0DC0.1030205@uvic.ca>
	<CAC_Lu0ZzE6eEF8rJGGaeGhnsuTzS+CRbaM6PxTvQfDBHHR9WRQ@mail.gmail.com>
	<4FEA6AD7.1090102@ultraslavonic.info>
Message-ID: <4FEA7972.50306@uvic.ca>

If we were to tag it, we'd have to make a decision about what the script 
was. There is this:

Type: variant
Subtag: fonipa
Description: International Phonetic Alphabet
Added: 2006-12-11

but most of those items aren't IPA. I'd say it'll be more trouble than 
it's worth.

Cheers,
Martin

On 12-06-26 07:07 PM, Kevin Hawkins wrote:
> There is no particular exception to use of @xml:lang on <pron> that I am
> aware of.  As a global attribute, @xml:lang may be used on any element
> but need not be used anywhere.
>
> I am inclined not to bother inserting @xml:lang on these examples.  If
> you encode a dictionary, every <pron> will likely use the same script as
> every other <pron>, and this will be the only part of the dictionary
> using this script (whatever it is).  I can't imagine a use case for
> recording on individual <pron>s.
>
> --K.
>
> On 6/26/12 5:14 PM, Stuart A. Yeates wrote:
>> On a related note (and not covered in CH or BCP 47 as far as I can tell):
>>
>> Almost all the <pron/> examples in
>> http://www.tei-c.org/release/doc/tei-p5-doc/en/html/examples-pron.html
>> use a different script to the surrounding text, but none of them have
>> an xml:lang attribute describing that.
>>
>> Does <pron/> have an exception from xml:lang, or do we need to add
>> them to the examples?
>>
>> cheers
>> stuart
>>
>


From lou.burnard at retired.ox.ac.uk  Wed Jun 27 07:44:43 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Wed, 27 Jun 2012 12:44:43 +0100
Subject: [tei-council] P4toP5 stylesheet generates invalid P5
In-Reply-To: <9C669017-B0A7-4413-90ED-D868147CACE8@oucs.ox.ac.uk>
References: <4FE9F38D.3080701@uvic.ca>
	<6BF5288F-B2A1-459D-B7FB-5B2C4DC5AECF@oucs.ox.ac.uk>
	<alpine.OSX.2.00.1206261442490.65194@lister.ei.virginia.edu>
	<9C669017-B0A7-4413-90ED-D868147CACE8@oucs.ox.ac.uk>
Message-ID: <4FEAF22B.9030503@retired.ox.ac.uk>

I just noticed that we have introduced some schema breaking changes in 
P5 AFTER the P4toP5 stylesheet was last updated. The only one I've 
noticed so far is the way <index> works [see below] but there may well 
be others.

At present the stylesheet leaves things like <index level1="Here be 
dragons"/> alone, instead of turning them to <index 
indexName="level1"><term>here be dragons</term></index> (or whatever) -- 
which is invalid P5 because there is no attribute "level1"

I added this template to my local copy, but thought I should check here 
before updating the source in svn at P4toP5/p4top5.xsl


<xsl:template match="index">
<index indexName="level1">
<xsl:value-of select="@level1"/>
<xsl:if test="@level2">
<index indexName="level2">
<xsl:value-of select="@level1"/>
<xsl:if test="@level3">
<index indexName="level3">
<xsl:value-of select="@level1"/>
</index></xsl:if>
</index></xsl:if>
</index>
</xsl:template>
</xsl:stylesheet>

From sebastian.rahtz at oucs.ox.ac.uk  Wed Jun 27 08:20:48 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Wed, 27 Jun 2012 12:20:48 +0000
Subject: [tei-council] P4toP5 stylesheet generates invalid P5
In-Reply-To: <4FEAF22B.9030503@retired.ox.ac.uk>
References: <4FE9F38D.3080701@uvic.ca>
	<6BF5288F-B2A1-459D-B7FB-5B2C4DC5AECF@oucs.ox.ac.uk>
	<alpine.OSX.2.00.1206261442490.65194@lister.ei.virginia.edu>
	<9C669017-B0A7-4413-90ED-D868147CACE8@oucs.ox.ac.uk>
	<4FEAF22B.9030503@retired.ox.ac.uk>
Message-ID: <18fa0d58-29db-4c3c-a6dd-326914bc356c@HUB02.ad.oak.ox.ac.uk>

itsa fair cop.  <index> is rare in my wild, so I expect I never met one before.

feel free to update profiles/default/p4/from.xsl
--
Sebastian Rahtz      
Head of Information and Support Group
Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431

S?lo le pido a Dios
que el futuro no me sea indiferente


From lou.burnard at retired.ox.ac.uk  Wed Jun 27 08:45:11 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Wed, 27 Jun 2012 13:45:11 +0100
Subject: [tei-council] P4toP5 stylesheet generates invalid P5
In-Reply-To: <04C5CFC5-146C-4D6A-85E6-37A55C151996@oucs.ox.ac.uk>
References: <4FE9F38D.3080701@uvic.ca>
	<6BF5288F-B2A1-459D-B7FB-5B2C4DC5AECF@oucs.ox.ac.uk>
	<alpine.OSX.2.00.1206261442490.65194@lister.ei.virginia.edu>
	<9C669017-B0A7-4413-90ED-D868147CACE8@oucs.ox.ac.uk>
	<4FEAF22B.9030503@retired.ox.ac.uk>
	<04C5CFC5-146C-4D6A-85E6-37A55C151996@oucs.ox.ac.uk>
Message-ID: <4FEB0057.1080103@retired.ox.ac.uk>

On 27/06/12 13:20, Sebastian Rahtz wrote:
> itsa fair cop.<index>  is rare in my wild, so I expect I never met one before.

Mine too, but i just did. And we should probably be prepared for a flood 
of such exotica when support for P4 is officially withdrawn and people 
(hopefully) start trying to migrate to P5 en masse.

>
> feel free to update profiles/default/p4/from.xsl

OK, but then I'm confused about the status of P4toP5/p4top5.xsl
Are they the same thing? or is this another roma2 situation?


From sebastian.rahtz at oucs.ox.ac.uk  Wed Jun 27 09:34:52 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Wed, 27 Jun 2012 13:34:52 +0000
Subject: [tei-council] P4toP5 stylesheet generates invalid P5
In-Reply-To: <4FEB0057.1080103@retired.ox.ac.uk>
References: <4FE9F38D.3080701@uvic.ca>
	<6BF5288F-B2A1-459D-B7FB-5B2C4DC5AECF@oucs.ox.ac.uk>
	<alpine.OSX.2.00.1206261442490.65194@lister.ei.virginia.edu>
	<9C669017-B0A7-4413-90ED-D868147CACE8@oucs.ox.ac.uk>
	<4FEAF22B.9030503@retired.ox.ac.uk>
	<04C5CFC5-146C-4D6A-85E6-37A55C151996@oucs.ox.ac.uk>
	<4FEB0057.1080103@retired.ox.ac.uk>
Message-ID: <87d5f75d-3bdf-46a8-b51b-a85b18e9ded9@HUB03.ad.oak.ox.ac.uk>


On 27 Jun 2012, at 13:45, Lou Burnard wrote:

> On 27/06/12 13:20, Sebastian Rahtz wrote:
>> itsa fair cop.<index>  is rare in my wild, so I expect I never met one before.
> 
> Mine too, but i just did. And we should probably be prepared for a flood of such exotica when support for P4 is officially withdrawn and people (hopefully) start trying to migrate to P5 en masse.
> 
hahahahaha

>> feel free to update profiles/default/p4/from.xsl
> 
> OK, but then I'm confused about the status ofP4toP5/p4top5.xsl
> Are they the same thing? or is this another roma2 situation?
> 

its a roma2. have deleted the P4toP5 version in the interests of rationality.

--
Sebastian Rahtz      
Head of Information and Support Group
Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431

S?lo le pido a Dios
que el futuro no me sea indiferente


From James.Cummings at oucs.ox.ac.uk  Wed Jun 27 10:18:16 2012
From: James.Cummings at oucs.ox.ac.uk (James Cummings)
Date: Wed, 27 Jun 2012 15:18:16 +0100
Subject: [tei-council] P4toP5 stylesheet generates invalid P5
In-Reply-To: <87d5f75d-3bdf-46a8-b51b-a85b18e9ded9@HUB03.ad.oak.ox.ac.uk>
References: <4FE9F38D.3080701@uvic.ca>	<6BF5288F-B2A1-459D-B7FB-5B2C4DC5AECF@oucs.ox.ac.uk>	<alpine.OSX.2.00.1206261442490.65194@lister.ei.virginia.edu>	<9C669017-B0A7-4413-90ED-D868147CACE8@oucs.ox.ac.uk>	<4FEAF22B.9030503@retired.ox.ac.uk>	<04C5CFC5-146C-4D6A-85E6-37A55C151996@oucs.ox.ac.uk>	<4FEB0057.1080103@retired.ox.ac.uk>
	<87d5f75d-3bdf-46a8-b51b-a85b18e9ded9@HUB03.ad.oak.ox.ac.uk>
Message-ID: <4FEB1628.20206@oucs.ox.ac.uk>

On 27/06/12 14:34, Sebastian Rahtz wrote:
>
> On 27 Jun 2012, at 13:45, Lou Burnard wrote:
>
>> On 27/06/12 13:20, Sebastian Rahtz wrote:
>>> itsa fair cop.<index>   is rare in my wild, so I expect I
>>> never met one before.
>>
>> Mine too, but i just did. And we should probably be prepared
>> for a flood of such exotica when support for P4 is
>> officially withdrawn and people (hopefully) start trying to
>> migrate to P5 en masse.
>>
> hahahahaha

It is on the list of things to discuss at our next teleconference 
and face2face.

> its a roma2. have deleted the P4toP5 version in the interests
> of rationality.

Hurrah.

-James
-- 
Dr James Cummings, InfoDev,
OUCS, University of Oxford

From James.Cummings at oucs.ox.ac.uk  Wed Jun 27 12:51:21 2012
From: James.Cummings at oucs.ox.ac.uk (James Cummings)
Date: Wed, 27 Jun 2012 17:51:21 +0100
Subject: [tei-council] Next TEI Technical Council Teleconference
In-Reply-To: <4FE88EF6.5010307@oucs.ox.ac.uk>
References: <4FE6D32D.5070101@oucs.ox.ac.uk>
	<4FE75A9A.1040003@uvic.ca>	<4FE793B2.9040004@o2.pl>
	<4FE84861.6040601@oucs.ox.ac.uk>	<4FE88C84.4030806@uvic.ca>
	<4FE88EF6.5010307@oucs.ox.ac.uk>
Message-ID: <4FEB3A09.6000106@oucs.ox.ac.uk>

On 25/06/12 17:16, James Cummings wrote:
> On 25/06/12 17:06, Martin Holmes wrote:
>> 6-10 August would be perfect for me; I'll be back to work. But
>> any week you choose at this time of year will collide with some
>> folks' holidays, so leave the original week on the table just in
>> case.
>
> I'll give anyone a day to shout that they are away all that week
> or for some other reason it is impossible, before putting up
> another doodle poll.


Ok, no one screamed or shouted that this was much worse.  So here 
we go again, with another doodle poll, for 6-10 August for our 
teleconference.

http://www.doodle.com/ardsg2b954tdhg5g

-James

-- 
Dr James Cummings, InfoDev,
OUCS, University of Oxford

From mholmes at uvic.ca  Wed Jun 27 13:22:01 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Wed, 27 Jun 2012 10:22:01 -0700
Subject: [tei-council] Private URI Schemes
Message-ID: <4FEB4139.2010407@uvic.ca>

Hi all,

We've had a couple of discussions about the magic token vs. private URI 
scheme issue over the past couple of meetings, and now I've put together 
a brief description of the way I had imagined putting the use of private 
URI schemes on a more solid footing than magic tokens:

<http://wiki.tei-c.org/index.php/Private_URI_Schemes>

Could you take a look and let me know what you think?

Cheers,
Martin

From dsewell at virginia.edu  Wed Jun 27 13:32:59 2012
From: dsewell at virginia.edu (David Sewell)
Date: Wed, 27 Jun 2012 13:32:59 -0400 (EDT)
Subject: [tei-council] Roma2 is dead, long live Roma
Message-ID: <alpine.OSX.2.00.1206271332120.80505@lister.ei.virginia.edu>

www.tei-c.org/Roma2/ now redirects to www.tei-c.org/Roma/ (it may require a 
browser refresh to demonstrate that this is the case).

---------- Forwarded message ----------
Date: Wed, 27 Jun 2012 13:20:48 -0400
From: Shayne Brandon <wsb4q at virginia.edu>
To: David Sewell <dsewell at virginia.edu>
Subject: Re: TEI website maintenance request

Hi David

I've done these things and the redirect is in place.

Shayne


On 06/26/2012 02:55 PM, David Sewell wrote:
> Shayne,
> 
> We have an outdated directory on tei-c.org. Some people have it
> bookmarked so we'd like a redirect. Here are the details:
> 
> 1. tar an archive copy of /projects/tei/web/Roma2 and then delete the
> directory Roma2
> 
> 2. In httpd.conf:
> 
> - remove the alias and directory for Roma2
> 
> - delete: RewriteRule ^/Roma2(.*) - [L]
> 
> - add a redirect so any URL pointing to /Roma2 goes to /Roma
> 
> Thanks,
> 
> David
>


From syeates at gmail.com  Wed Jun 27 15:46:38 2012
From: syeates at gmail.com (Stuart A. Yeates)
Date: Thu, 28 Jun 2012 07:46:38 +1200
Subject: [tei-council] Private URI Schemes
In-Reply-To: <4FEB4139.2010407@uvic.ca>
References: <4FEB4139.2010407@uvic.ca>
Message-ID: <CAC_Lu0Z536583h7R+CFaosbpf20eijZSE41rK9Sd1E2r9n=aKw@mail.gmail.com>

I think the <listPrivateUri/> tag is unnecessary, can't we reuse one
of the existing TEI header tags for this purpose? <encodingDesc/>?
Unless of course there are some specific semantics you're trying to
model.

You also use the word 'project' in the examples, surely that should be
'document' or 'corpus'?

Other than that it looks really good.

cheers
stuart

On Thu, Jun 28, 2012 at 5:22 AM, Martin Holmes <mholmes at uvic.ca> wrote:
> Hi all,
>
> We've had a couple of discussions about the magic token vs. private URI
> scheme issue over the past couple of meetings, and now I've put together
> a brief description of the way I had imagined putting the use of private
> URI schemes on a more solid footing than magic tokens:
>
> <http://wiki.tei-c.org/index.php/Private_URI_Schemes>
>
> Could you take a look and let me know what you think?
>
> Cheers,
> Martin
> --
> tei-council mailing list
> tei-council at lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>
> PLEASE NOTE: postings to this list are publicly archived

From mholmes at uvic.ca  Wed Jun 27 17:03:45 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Wed, 27 Jun 2012 14:03:45 -0700
Subject: [tei-council] Private URI Schemes
In-Reply-To: <CAC_Lu0Z536583h7R+CFaosbpf20eijZSE41rK9Sd1E2r9n=aKw@mail.gmail.com>
References: <4FEB4139.2010407@uvic.ca>
	<CAC_Lu0Z536583h7R+CFaosbpf20eijZSE41rK9Sd1E2r9n=aKw@mail.gmail.com>
Message-ID: <4FEB7531.7050805@uvic.ca>

On 12-06-27 12:46 PM, Stuart A. Yeates wrote:
> I think the <listPrivateUri/> tag is unnecessary, can't we reuse one
> of the existing TEI header tags for this purpose? <encodingDesc/>?
> Unless of course there are some specific semantics you're trying to
> model.

I was assuming that many projects would use more than one private URI 
scheme -- mine do -- and so there would need to be a list or group 
element to keep them together. I assume they would be in <encodingDesc>.

> You also use the word 'project' in the examples, surely that should be
> 'document' or 'corpus'?

I think of a project as a corpus together with a lot of peripheral 
material (web application, documentation, etc.). If this were coded into 
elementSpecs, though, you're right that "corpus" would make more sense.

Cheers,
Martin

> Other than that it looks really good.
>
> cheers
> stuart
>
> On Thu, Jun 28, 2012 at 5:22 AM, Martin Holmes <mholmes at uvic.ca> wrote:
>> Hi all,
>>
>> We've had a couple of discussions about the magic token vs. private URI
>> scheme issue over the past couple of meetings, and now I've put together
>> a brief description of the way I had imagined putting the use of private
>> URI schemes on a more solid footing than magic tokens:
>>
>> <http://wiki.tei-c.org/index.php/Private_URI_Schemes>
>>
>> Could you take a look and let me know what you think?
>>
>> Cheers,
>> Martin
>> --
>> tei-council mailing list
>> tei-council at lists.village.Virginia.EDU
>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>>
>> PLEASE NOTE: postings to this list are publicly archived


From kevin.s.hawkins at ultraslavonic.info  Thu Jun 28 00:12:48 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Thu, 28 Jun 2012 00:12:48 -0400
Subject: [tei-council] Fwd: Re: Google Books > TEI
In-Reply-To: <CAHScxsVJ4-UfSOnZK-rGH6qYVWQHyEhe6yxRtHuF6kxctCQ+=w@mail.gmail.com>
References: <CAHScxsVJ4-UfSOnZK-rGH6qYVWQHyEhe6yxRtHuF6kxctCQ+=w@mail.gmail.com>
Message-ID: <4FEBD9C0.4030201@ultraslavonic.info>

All,

Now that the latest release is behind us, I'd like to follow up on a few 
things I've promised for you but which wouldn't have contributed to 
getting through bug fixes and feature requests in time for the release.

First of all, in Ann Arbor we agreed that we would ask Ranjith, our 
contact at Google, for the latest samples so we can calculate some 
statistics on accuracy and encourage Google towards making this format 
public.  See the two attachments and the correspondence below.

Our agenda is a bit vague on responsibility here.  I've asked for 
samples, but I think others will want to check for accuracy of encoding.

Kevin

-------- Original Message --------
Subject: 	Re: Google Books > TEI
Date: 	Mon, 23 Apr 2012 15:30:38 -0700
From: 	Ranjith Unnikrishnan <ranjith at google.com>
To: 	Kevin Hawkins <kevin.s.hawkins at ultraslavonic.info>
CC: 	James.Cummings at oucs.ox.ac.uk, mholmes at uvic.ca, laurent.romary at inria.fr



Yes, the last round of feedback I got was around that time frame, and 
came both from your group as well as another working group that included 
some of our library partners. I had incorporated the two sets of 
feedback into some improvements to the algorithm, but they were mostly 
related to style and had nothing to do with producing new output tags or 
such. Comments that were not addressed required improvements to existing 
text structure analysis algorithms that were at least partly based on 
the quality of obtained OCR text. Both of these are active research 
topics that are always on our agenda but are not quick fixes.
I've attached the latest Dicken's and Gulliver's Travels files, and can 
generate TEI files for others if you can send me links to their 
corresponding pages on Google Books.



On Mon, Apr 23, 2012 at 2:53 PM, Kevin Hawkins 
<kevin.s.hawkins at ultraslavonic.info 
<mailto:kevin.s.hawkins at ultraslavonic.info>> wrote:

    The last round of reviews I have is a sample of Dickens from July
    27, 2011.  I have earlier versions of other titles, but they aren't
    worth consulting at this point since you've improved other things.
      Has the algorithm changed since then?  It would be nice to have
    the latest version of not only Dickens but also of some other works
    in the public domain: perhaps an old bound volume of a journal and a
    non-fiction book?  Thanks.


    On 4/23/2012 12:50 PM, Ranjith Unnikrishnan wrote:

        Hi Kevin,

        I have not made any changes to the TEI generation algorithm
        since our
        last round of reviews withing the group. I've since diverted my
        energy
        towards getting buy-in and making progress on making the TEI files
        available on the Books site. I've had some success but it's
        still early
        days. Until this is launched, I don't plan to work on increasing
        the TEI
        markup depth or anything else related to the process apart from
        fixing
        any bugs that may arise during large-scale testing.

        ~R


        On Thu, Apr 19, 2012 at 6:05 PM, Kevin Hawkins
        <kevin.s.hawkins at ultraslavonic.info
        <mailto:kevin.s.hawkins at ultraslavonic.info>
        <mailto:kevin.s.hawkins at ultraslavonic.info
        <mailto:kevin.s.hawkins at ultraslavonic.info>>> wrote:

            Hi Ranjith,

            While we wait on your colleagues to integrate the code for
            generating TEI into your production pipeline (for which we
        hope our
            Google Docs brainstorming has helped you make that case),
        the TEI
            Technical Council is thinking about how we might publicize the
            availability of TEI documents in Google Books -- when that
        day comes
            -- and what it might mean for our community.  The sort of
        message we
            would promote depends on the depth and consistency of the markup
            that Google is able to create. Would you be able to provide
        us with
            some of samples generated by the latest version of your
        code?  (We
            saw early drafts, but I'm not sure that I have any of the final
            versions.)  I'd like to share them with the Technical Council.

            Thanks,

            Kevin


            On 2/6/12 12:24 PM, Ranjith Unnikrishnan wrote:

                Hi Kevin,

                The code has been reviewed and checked in but we're
        still working on
                some questions related to integrating the code in our
        production
                pipeline. There's probably not much you can help with at
        this
                point, but
                I might need some input from you guys as we get closer
        to deploying.

                Sorry this is not moving as fast as I'd like; this
        effort is one
                of my
                independent "20%" projects, and those have a general
        tendency of
                getting
                pushed down the priority list in light of more urgent
        tasks. So
                don't
                hesitate to check up once in a while.

                ~Ranjith

-------------- next part --------------
A non-text attachment was scrubbed...
Name: dickens.tei
Type: application/octet-stream
Size: 284908 bytes
Desc: not available
Url : http://lists.village.Virginia.EDU/pipermail/tei-council/attachments/20120628/1d5efce7/attachment-0002.obj 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gullivers_travels.tei
Type: application/octet-stream
Size: 278754 bytes
Desc: not available
Url : http://lists.village.Virginia.EDU/pipermail/tei-council/attachments/20120628/1d5efce7/attachment-0003.obj 

From kevin.s.hawkins at ultraslavonic.info  Thu Jun 28 00:15:01 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Thu, 28 Jun 2012 00:15:01 -0400
Subject: [tei-council] Fwd: Re: Google Books > TEI
In-Reply-To: <4FEBD9C0.4030201@ultraslavonic.info>
References: <CAHScxsVJ4-UfSOnZK-rGH6qYVWQHyEhe6yxRtHuF6kxctCQ+=w@mail.gmail.com>
	<4FEBD9C0.4030201@ultraslavonic.info>
Message-ID: <4FEBDA45.6060304@ultraslavonic.info>

Pardon me: I forgot to include the IDs for these books so you can 
compare against page images:

dickens.tei  (Google books ID i8_u_-YmG4MC)
gullivers_travels.tei (Google books ID srVbAAAAQAAJ)

On 6/28/12 12:12 AM, Kevin Hawkins wrote:
> All,
>
> Now that the latest release is behind us, I'd like to follow up on a few
> things I've promised for you but which wouldn't have contributed to
> getting through bug fixes and feature requests in time for the release.
>
> First of all, in Ann Arbor we agreed that we would ask Ranjith, our
> contact at Google, for the latest samples so we can calculate some
> statistics on accuracy and encourage Google towards making this format
> public.  See the two attachments and the correspondence below.
>
> Our agenda is a bit vague on responsibility here.  I've asked for
> samples, but I think others will want to check for accuracy of encoding.
>
> Kevin
>
> -------- Original Message --------
> Subject:     Re: Google Books > TEI
> Date:     Mon, 23 Apr 2012 15:30:38 -0700
> From:     Ranjith Unnikrishnan <ranjith at google.com>
> To:     Kevin Hawkins <kevin.s.hawkins at ultraslavonic.info>
> CC:     James.Cummings at oucs.ox.ac.uk, mholmes at uvic.ca,
> laurent.romary at inria.fr
>
>
>
> Yes, the last round of feedback I got was around that time frame, and
> came both from your group as well as another working group that included
> some of our library partners. I had incorporated the two sets of
> feedback into some improvements to the algorithm, but they were mostly
> related to style and had nothing to do with producing new output tags or
> such. Comments that were not addressed required improvements to existing
> text structure analysis algorithms that were at least partly based on
> the quality of obtained OCR text. Both of these are active research
> topics that are always on our agenda but are not quick fixes.
> I've attached the latest Dicken's and Gulliver's Travels files, and can
> generate TEI files for others if you can send me links to their
> corresponding pages on Google Books.
>
>
>
> On Mon, Apr 23, 2012 at 2:53 PM, Kevin Hawkins
> <kevin.s.hawkins at ultraslavonic.info
> <mailto:kevin.s.hawkins at ultraslavonic.info>> wrote:
>
>     The last round of reviews I have is a sample of Dickens from July
>     27, 2011.  I have earlier versions of other titles, but they aren't
>     worth consulting at this point since you've improved other things.
>       Has the algorithm changed since then?  It would be nice to have
>     the latest version of not only Dickens but also of some other works
>     in the public domain: perhaps an old bound volume of a journal and a
>     non-fiction book?  Thanks.
>
>
>     On 4/23/2012 12:50 PM, Ranjith Unnikrishnan wrote:
>
>         Hi Kevin,
>
>         I have not made any changes to the TEI generation algorithm
>         since our
>         last round of reviews withing the group. I've since diverted my
>         energy
>         towards getting buy-in and making progress on making the TEI files
>         available on the Books site. I've had some success but it's
>         still early
>         days. Until this is launched, I don't plan to work on increasing
>         the TEI
>         markup depth or anything else related to the process apart from
>         fixing
>         any bugs that may arise during large-scale testing.
>
>         ~R
>
>
>         On Thu, Apr 19, 2012 at 6:05 PM, Kevin Hawkins
>         <kevin.s.hawkins at ultraslavonic.info
>         <mailto:kevin.s.hawkins at ultraslavonic.info>
>         <mailto:kevin.s.hawkins at ultraslavonic.info
>         <mailto:kevin.s.hawkins at ultraslavonic.info>>> wrote:
>
>             Hi Ranjith,
>
>             While we wait on your colleagues to integrate the code for
>             generating TEI into your production pipeline (for which we
>         hope our
>             Google Docs brainstorming has helped you make that case),
>         the TEI
>             Technical Council is thinking about how we might publicize the
>             availability of TEI documents in Google Books -- when that
>         day comes
>             -- and what it might mean for our community.  The sort of
>         message we
>             would promote depends on the depth and consistency of the
> markup
>             that Google is able to create. Would you be able to provide
>         us with
>             some of samples generated by the latest version of your
>         code?  (We
>             saw early drafts, but I'm not sure that I have any of the final
>             versions.)  I'd like to share them with the Technical Council.
>
>             Thanks,
>
>             Kevin
>
>
>             On 2/6/12 12:24 PM, Ranjith Unnikrishnan wrote:
>
>                 Hi Kevin,
>
>                 The code has been reviewed and checked in but we're
>         still working on
>                 some questions related to integrating the code in our
>         production
>                 pipeline. There's probably not much you can help with at
>         this
>                 point, but
>                 I might need some input from you guys as we get closer
>         to deploying.
>
>                 Sorry this is not moving as fast as I'd like; this
>         effort is one
>                 of my
>                 independent "20%" projects, and those have a general
>         tendency of
>                 getting
>                 pushed down the priority list in light of more urgent
>         tasks. So
>                 don't
>                 hesitate to check up once in a while.
>
>                 ~Ranjith
>
>


From kevin.s.hawkins at ultraslavonic.info  Thu Jun 28 00:36:01 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Thu, 28 Jun 2012 00:36:01 -0400
Subject: [tei-council] Fwd: RE: latest Tite DTD?
In-Reply-To: <2FC5F4A7011AEF4C86B2EB7A6013CDC9851B97F54F@exchange07.acv.apexcovantage.com>
References: <2FC5F4A7011AEF4C86B2EB7A6013CDC9851B97F54F@exchange07.acv.apexcovantage.com>
Message-ID: <4FEBDF31.3050901@ultraslavonic.info>

During our February conference call, I was asked to check whether Apex 
claims ownership of their DTD, which they derived from the Tite DTD 
originally developed by Perry Trolard for the TEI-C.  I asked Apex in a 
different way: would they be willing to share their DTD publicly.  The 
answer from Greg (our technical contact) is yes, but they still haven't 
managed to do so.  However, Greg sent me the latest file as an email 
attachment, which I am forwarding.

My plan is to try creating a DTD from the latest Tite ODD in SourceForge 
and compare the results with this DTD.  Assuming I have correctly 
reconciled the Apex version and canonical Tite per notes gathered from 
various sources over the past year or two, the only differences 
remaining would be those changes introduced to P5 since the Apex DTD was 
created which happened to affect Tite as well -- that is, a change to a 
content model of an element.  If this is the case, these should 
generally be acceptable to everyone, so I would then ask Apex to use the 
DTD I've created instead because it's more closer to P5.  This would 
also encourage them to be in touch with us about any future changes they 
want to make to the encoding scheme so that they could be made in the 
canonical source.

However, I never seen to find time for this.  I recall some interest in 
this project from other quarters, so if anyone else wants to take this 
up, please do!

Kevin

-------- Original Message --------
Subject: RE: latest Tite DTD?
Date: Tue, 17 Apr 2012 10:22:32 -0400
From: Greg Suprock <gsuprock at apexcovantage.com>
To: Kevin Hawkins <kevin.s.hawkins at ultraslavonic.info>

Hi Kevin,

We've not gotten the dtd posted to the website yet.  Attached is the dtd 
that the teams are using.

I'll send a note when the dtd is available on the website.

Best regards,
Greg


-----Original Message-----
From: Kevin Hawkins [mailto:kevin.s.hawkins at ultraslavonic.info]
Sent: Saturday, April 07, 2012 11:35 PM
To: Greg Suprock
Subject: Re: latest Tite DTD?

Hi Greg, any progress on this?

On 3/5/12 9:50 PM, Greg Suprock wrote:
> Hi Kevin and Perry,
>
> Acknowledging receipt of your message.  I'll make arrangements for Apex to host the current DTD as you suggest.  Good idea.
>
> Best regards,
> Greg
>
>
> -----Original Message-----
> From: Kevin Hawkins [mailto:kevin.s.hawkins at ultraslavonic.info]
> Sent: Sunday, March 04, 2012 9:13 PM
> To: Greg Suprock
> Cc: trolard at gmail.com
> Subject: latest Tite DTD?
>
> Hi Greg,
>
> This fall I implemented the SourceForge tickets required to bring the canonical Tite into conformance with Apex's derived version.  Before going on to the other tickets (to make improvements to both versions of Tite), I've been meaning to create a DTD from the canonical ODD file and compare with Apex's DTD.  (I have a DTD generated on Mar. 2, 2010, which Virginia McClure sent to Dan O'Donnell in April 2010.)  Assuming this is the DTD These two DTDs should identical except for any changes introduced into TEI since Apex created its DTD, which I fear would take some time to work through.  I want to verify this in case I missed some things that needed to be reconciled.
>
> Since I can't seem to find time for this, I asked Council members for help, and this led to the realization that Apex's DTD is not publicly available.  It would be good if Apex linked to its DTD from http://accesstei.apexcovantage.com/Home/AboutTeiTite in addition to the link to the Apex prose guidelines.  That would also let me know that I do, in fact, have the latest version.
>
> Thanks,
>
> Kevin
>



-------------- next part --------------
A non-text attachment was scrubbed...
Name: tei_tite.dtd
Type: text/xml
Size: 61383 bytes
Desc: not available
Url : http://lists.village.Virginia.EDU/pipermail/tei-council/attachments/20120628/cd151219/attachment-0001.xml 

From kevin.s.hawkins at ultraslavonic.info  Thu Jun 28 00:46:56 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Thu, 28 Jun 2012 00:46:56 -0400
Subject: [tei-council] changes to data.pattern?
Message-ID: <4FEBE1C0.1000501@ultraslavonic.info>

All,

I have a note to self from Ann Arbor that says, "Create a ticket that 
ref-data.pattern.html should have a reference to W3C for each of the two 
members moved to here."

However, I can't find any action item in which we were going to put 
things in data.pattern, and I can't find any change in SF indicating 
such an action.  Does anyone recall what we were going to move to 
data.pattern and who was going to do it?

Kevin

From sebastian.rahtz at oucs.ox.ac.uk  Thu Jun 28 05:10:16 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Thu, 28 Jun 2012 09:10:16 +0000
Subject: [tei-council] latest Tite DTD?
In-Reply-To: <4FEBDF31.3050901@ultraslavonic.info>
References: <2FC5F4A7011AEF4C86B2EB7A6013CDC9851B97F54F@exchange07.acv.apexcovantage.com>
	<4FEBDF31.3050901@ultraslavonic.info>
Message-ID: <43CE60E8-DA3C-4F15-ABF7-AC98F50848BC@oucs.ox.ac.uk>

this is not so hard. compare it to 
http://www.tei-c.org/Vault/P5/1.7.0/xml/tei/custom/schema/dtd/tei_tite.dtd

which is what theirs says it is, and you find the only difference is that

   a) they have removed the copy and licence statement
   b) the differences below, which is adding argument to some titlePage patterns which I suspect are unused anyway


I conclude that Apex do not have their own variant of Tite at all, and that this is all a red herring. OR, Apex are not being entirely truthful and have a secret DTD underneath


< <!ENTITY % model.titlepagePart_sequence "graphic, byline, argument, epigraph, docTitle, titlePart, docAuthor, docEdition, docImprint, docDate, ornament"> 
< <!ENTITY % model.titlepagePart_sequenceOptional "graphic?, byline?, argument?, epigraph?, docTitle?, titlePart?, docAuthor?, docEdition?, docImprint?, docDate?, ornament?"> 
< <!ENTITY % model.titlepagePart_sequenceOptionalRepeatable "graphic*, byline*, argument*, epigraph*, docTitle*, titlePart*, docAuthor*, docEdition*, docImprint*, docDate*, ornament*"> 
< <!ENTITY % model.titlepagePart_sequenceRepeatable "graphic+, byline+, argument+, epigraph+, docTitle+, titlePart+, docAuthor+, docEdition+, docImprint+, docDate+, ornament+"> 
---
> <!ENTITY % model.titlepagePart_sequence "graphic, byline, epigraph, docTitle, titlePart, docAuthor, docEdition, docImprint, docDate, ornament"> 
> <!ENTITY % model.titlepagePart_sequenceOptional "graphic?, byline?, epigraph?, docTitle?, titlePart?, docAuthor?, docEdition?, docImprint?, docDate?, ornament?"> 
> <!ENTITY % model.titlepagePart_sequenceOptionalRepeatable "graphic*, byline*, epigraph*, docTitle*, titlePart*, docAuthor*, docEdition*, docImprint*, docDate*, ornament*"> 
> <!ENTITY % model.titlepagePart_sequenceRepeatable "graphic+, byline+, epigraph+, docTitle+, titlePart+, docAuthor+, docEdition+, docImprint+, docDate+, ornament+"> 


--
Sebastian Rahtz      
Head of Information and Support Group
Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431

S?lo le pido a Dios
que el futuro no me sea indiferente


From kevin.s.hawkins at ultraslavonic.info  Thu Jun 28 05:26:38 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Thu, 28 Jun 2012 05:26:38 -0400
Subject: [tei-council] latest Tite DTD?
In-Reply-To: <43CE60E8-DA3C-4F15-ABF7-AC98F50848BC@oucs.ox.ac.uk>
References: <2FC5F4A7011AEF4C86B2EB7A6013CDC9851B97F54F@exchange07.acv.apexcovantage.com>
	<4FEBDF31.3050901@ultraslavonic.info>
	<43CE60E8-DA3C-4F15-ABF7-AC98F50848BC@oucs.ox.ac.uk>
Message-ID: <4FEC234E.7010508@ultraslavonic.info>



On 6/28/12 5:10 AM, Sebastian Rahtz wrote:
> this is not so hard. compare it to
> http://www.tei-c.org/Vault/P5/1.7.0/xml/tei/custom/schema/dtd/tei_tite.dtd
>
> which is what theirs says it is, and you find the only difference is that
>
>     a) they have removed the copy and licence statement
>     b) the differences below, which is adding argument to some titlePage patterns which I suspect are unused anyway
>
>
> I conclude that Apex do not have their own variant of Tite at all, and that this is all a red herring. OR, Apex are not being entirely truthful and have a secret DTD underneath
>
>
> < <!ENTITY % model.titlepagePart_sequence "graphic, byline, argument, epigraph, docTitle, titlePart, docAuthor, docEdition, docImprint, docDate, ornament">
> < <!ENTITY % model.titlepagePart_sequenceOptional "graphic?, byline?, argument?, epigraph?, docTitle?, titlePart?, docAuthor?, docEdition?, docImprint?, docDate?, ornament?">
> < <!ENTITY % model.titlepagePart_sequenceOptionalRepeatable "graphic*, byline*, argument*, epigraph*, docTitle*, titlePart*, docAuthor*, docEdition*, docImprint*, docDate*, ornament*">
> < <!ENTITY % model.titlepagePart_sequenceRepeatable "graphic+, byline+, argument+, epigraph+, docTitle+, titlePart+, docAuthor+, docEdition+, docImprint+, docDate+, ornament+">
> ---
>> <!ENTITY % model.titlepagePart_sequence "graphic, byline, epigraph, docTitle, titlePart, docAuthor, docEdition, docImprint, docDate, ornament">
>> <!ENTITY % model.titlepagePart_sequenceOptional "graphic?, byline?, epigraph?, docTitle?, titlePart?, docAuthor?, docEdition?, docImprint?, docDate?, ornament?">
>> <!ENTITY % model.titlepagePart_sequenceOptionalRepeatable "graphic*, byline*, epigraph*, docTitle*, titlePart*, docAuthor*, docEdition*, docImprint*, docDate*, ornament*">
>> <!ENTITY % model.titlepagePart_sequenceRepeatable "graphic+, byline+, epigraph+, docTitle+, titlePart+, docAuthor+, docEdition+, docImprint+, docDate+, ornament+">

If you really find differences in (b), don't those count as a Tite 
variant?  Why would you conclude that they don't have their own variant?

In any case, something is still not right.  Their prose documentation 
mentions <handShift/>, does not mention <biblScope>, etc., yet all of 
these are still in the DTD.  So they never got around to changing the 
DTD, or they are as devious as Sebastian fears.  I suspect incompetence, 
not deviousness.  Will write back to Greg to inquire.

From sebastian.rahtz at oucs.ox.ac.uk  Thu Jun 28 05:36:05 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Thu, 28 Jun 2012 09:36:05 +0000
Subject: [tei-council] latest Tite DTD?
In-Reply-To: <4FEC234E.7010508@ultraslavonic.info>
References: <2FC5F4A7011AEF4C86B2EB7A6013CDC9851B97F54F@exchange07.acv.apexcovantage.com>
	<4FEBDF31.3050901@ultraslavonic.info>
	<43CE60E8-DA3C-4F15-ABF7-AC98F50848BC@oucs.ox.ac.uk>
	<4FEC234E.7010508@ultraslavonic.info>
Message-ID: <3E40B1AA-CD2C-4879-96FB-7D7030406544@oucs.ox.ac.uk>


On 28 Jun 2012, at 10:26, Kevin Hawkins wrote:
> 
> If you really find differences in (b), don't those count as a Tite 
> variant?  Why would you conclude that they don't have their own variant?
> 
because the differences are meaningless.  those entities are not referenced. I
suspect its some small 

> In any case, something is still not right.  Their prose documentation 
> mentions <handShift/>, does not mention <biblScope>, etc., yet all of 
> these are still in the DTD.  So they never got around to changing the 
> DTD, or they are as devious as Sebastian fears.  I suspect incompetence, 
> not deviousness.  

i'll vote for devious :-}

--
Sebastian Rahtz      
Head of Information and Support Group
Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431

S?lo le pido a Dios
que el futuro no me sea indiferente


From kevin.s.hawkins at ultraslavonic.info  Thu Jun 28 07:17:33 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Thu, 28 Jun 2012 07:17:33 -0400
Subject: [tei-council] Release notes (was Re:  next release?)
In-Reply-To: <4FE1B8EF.5030907@kcl.ac.uk>
References: <0F18A249-5480-42D9-BFF2-538AC7B9E1EB@oucs.ox.ac.uk>
	<4F92F34D.2040103@uvic.ca>	<4F9579A0.8010002@oucs.ox.ac.uk>
	<4F95C7A1.1080707@o2.pl>	<4F96756B.1060202@oucs.ox.ac.uk>
	<4F986673.7020201@kcl.ac.uk>	<4FB95846.7080308@oucs.ox.ac.uk>
	<4FDA15EC.5050700@oucs.ox.ac.uk> <4FDB16D3.2080007@kcl.ac.uk>
	<4FDDB2D8.7090604@oucs.ox.ac.uk>	<4FDDE5E5.9000000@retired.ox.ac.uk>
	<4FDEEF88.3020503@kcl.ac.uk>	<4FDEF0A2.1020400@retired.ox.ac.uk>
	<4FDEF1F0.7020906@o2.pl> <4FDEF522.5040601@kcl.ac.uk>
	<4FDF66C2.5070307@kcl.ac.uk> <4FE0F032.30207@ultraslavonic.info>
	<4FE1B8EF.5030907@kcl.ac.uk>
Message-ID: <4FEC3D4D.208@ultraslavonic.info>

See below ...

On 6/19/12 5:40 PM, James Cummings wrote:
 >>> 14. Checking TEI website and downloads. (I wonder we shouldn't do this
 >>> check before the previous two, and maybe before 10 as well. If 
there's a
 >>> problem with the website we may have to start again.)
 >>
 >> If someone tells me to move this step, I will gladly do it.
 >
 > Yes, I think it best to move it up.

Done.  (Note that the steps have different verion numbers now because of 
some other renumbering.)

 > We should also make some indication of what to check for?
 > Checking that the version number has updated on webpages is one
 > thing, another could be that a change you know to have been
 > committed is displayed...

There was some indication of what to check for, but I've added checking 
for a change that you know what committed.

 > But the thing that delayed Gaby was a
 > problem with the tei_all.dtd was noticed.Should the release
 > technician be checking a file against all of these (but surely
 > Jenkins has done this?)  Need better (but quicker) testing on
 > Jenkins clearly.

A question for Sebastian?

Still more below ...

On 6/20/12 7:50 AM, Gabriel BODARD wrote:
> Hi Kevin,
>
> Thanks for this. I was going to make various changes to tcw22 based on
> my experiences, but probably not until next week. Please feel free to go
> ahead and change anything you like, and I'll make further tweaks,
> suggest specific wording where I've said "clarify", etc., when I have time.

Over to you!

From mholmes at uvic.ca  Thu Jun 28 12:20:11 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Thu, 28 Jun 2012 09:20:11 -0700
Subject: [tei-council] Fwd: Re: Google Books > TEI
In-Reply-To: <4FEBD9C0.4030201@ultraslavonic.info>
References: <CAHScxsVJ4-UfSOnZK-rGH6qYVWQHyEhe6yxRtHuF6kxctCQ+=w@mail.gmail.com>
	<4FEBD9C0.4030201@ultraslavonic.info>
Message-ID: <4FEC843B.9040308@uvic.ca>

On 12-06-27 09:12 PM, Kevin Hawkins wrote:
> All,
>
> Now that the latest release is behind us, I'd like to follow up on a few
> things I've promised for you but which wouldn't have contributed to
> getting through bug fixes and feature requests in time for the release.
>
> First of all, in Ann Arbor we agreed that we would ask Ranjith, our
> contact at Google, for the latest samples so we can calculate some
> statistics on accuracy and encourage Google towards making this format
> public.  See the two attachments and the correspondence below.

Does anyone have any experience in calculating the accuracy of OCR and 
automated markup? Do we do errors-per-page? Is a word either wrong or 
right, or do we count errors inside words? Do we count missing or 
misplaced column or page breaks as errors?

Presumably we'll need to create "perfect" hand-crafted versions of a set 
of sample pages in order to do the accuracy calculation. How many do we 
need to get a reasonable sample?

Cheers,
Martin

> Our agenda is a bit vague on responsibility here.  I've asked for
> samples, but I think others will want to check for accuracy of encoding.
>
> Kevin
>
> -------- Original Message --------
> Subject: 	Re: Google Books > TEI
> Date: 	Mon, 23 Apr 2012 15:30:38 -0700
> From: 	Ranjith Unnikrishnan <ranjith at google.com>
> To: 	Kevin Hawkins <kevin.s.hawkins at ultraslavonic.info>
> CC: 	James.Cummings at oucs.ox.ac.uk, mholmes at uvic.ca, laurent.romary at inria.fr
>
>
>
> Yes, the last round of feedback I got was around that time frame, and
> came both from your group as well as another working group that included
> some of our library partners. I had incorporated the two sets of
> feedback into some improvements to the algorithm, but they were mostly
> related to style and had nothing to do with producing new output tags or
> such. Comments that were not addressed required improvements to existing
> text structure analysis algorithms that were at least partly based on
> the quality of obtained OCR text. Both of these are active research
> topics that are always on our agenda but are not quick fixes.
> I've attached the latest Dicken's and Gulliver's Travels files, and can
> generate TEI files for others if you can send me links to their
> corresponding pages on Google Books.
>
>
>
> On Mon, Apr 23, 2012 at 2:53 PM, Kevin Hawkins
> <kevin.s.hawkins at ultraslavonic.info
> <mailto:kevin.s.hawkins at ultraslavonic.info>> wrote:
>
>      The last round of reviews I have is a sample of Dickens from July
>      27, 2011.  I have earlier versions of other titles, but they aren't
>      worth consulting at this point since you've improved other things.
>        Has the algorithm changed since then?  It would be nice to have
>      the latest version of not only Dickens but also of some other works
>      in the public domain: perhaps an old bound volume of a journal and a
>      non-fiction book?  Thanks.
>
>
>      On 4/23/2012 12:50 PM, Ranjith Unnikrishnan wrote:
>
>          Hi Kevin,
>
>          I have not made any changes to the TEI generation algorithm
>          since our
>          last round of reviews withing the group. I've since diverted my
>          energy
>          towards getting buy-in and making progress on making the TEI files
>          available on the Books site. I've had some success but it's
>          still early
>          days. Until this is launched, I don't plan to work on increasing
>          the TEI
>          markup depth or anything else related to the process apart from
>          fixing
>          any bugs that may arise during large-scale testing.
>
>          ~R
>
>
>          On Thu, Apr 19, 2012 at 6:05 PM, Kevin Hawkins
>          <kevin.s.hawkins at ultraslavonic.info
>          <mailto:kevin.s.hawkins at ultraslavonic.info>
>          <mailto:kevin.s.hawkins at ultraslavonic.info
>          <mailto:kevin.s.hawkins at ultraslavonic.info>>> wrote:
>
>              Hi Ranjith,
>
>              While we wait on your colleagues to integrate the code for
>              generating TEI into your production pipeline (for which we
>          hope our
>              Google Docs brainstorming has helped you make that case),
>          the TEI
>              Technical Council is thinking about how we might publicize the
>              availability of TEI documents in Google Books -- when that
>          day comes
>              -- and what it might mean for our community.  The sort of
>          message we
>              would promote depends on the depth and consistency of the markup
>              that Google is able to create. Would you be able to provide
>          us with
>              some of samples generated by the latest version of your
>          code?  (We
>              saw early drafts, but I'm not sure that I have any of the final
>              versions.)  I'd like to share them with the Technical Council.
>
>              Thanks,
>
>              Kevin
>
>
>              On 2/6/12 12:24 PM, Ranjith Unnikrishnan wrote:
>
>                  Hi Kevin,
>
>                  The code has been reviewed and checked in but we're
>          still working on
>                  some questions related to integrating the code in our
>          production
>                  pipeline. There's probably not much you can help with at
>          this
>                  point, but
>                  I might need some input from you guys as we get closer
>          to deploying.
>
>                  Sorry this is not moving as fast as I'd like; this
>          effort is one
>                  of my
>                  independent "20%" projects, and those have a general
>          tendency of
>                  getting
>                  pushed down the priority list in light of more urgent
>          tasks. So
>                  don't
>                  hesitate to check up once in a while.
>
>                  ~Ranjith
>


From sebastian.rahtz at oucs.ox.ac.uk  Thu Jun 28 12:45:04 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Thu, 28 Jun 2012 16:45:04 +0000
Subject: [tei-council] Release notes (was Re:  next release?)
In-Reply-To: <4FEC3D4D.208@ultraslavonic.info>
References: <0F18A249-5480-42D9-BFF2-538AC7B9E1EB@oucs.ox.ac.uk>
	<4F92F34D.2040103@uvic.ca>	<4F9579A0.8010002@oucs.ox.ac.uk>
	<4F95C7A1.1080707@o2.pl>	<4F96756B.1060202@oucs.ox.ac.uk>
	<4F986673.7020201@kcl.ac.uk>	<4FB95846.7080308@oucs.ox.ac.uk>
	<4FDA15EC.5050700@oucs.ox.ac.uk> <4FDB16D3.2080007@kcl.ac.uk>
	<4FDDB2D8.7090604@oucs.ox.ac.uk>	<4FDDE5E5.9000000@retired.ox.ac.uk>
	<4FDEEF88.3020503@kcl.ac.uk>	<4FDEF0A2.1020400@retired.ox.ac.uk>
	<4FDEF1F0.7020906@o2.pl> <4FDEF522.5040601@kcl.ac.uk>
	<4FDF66C2.5070307@kcl.ac.uk> <4FE0F032.30207@ultraslavonic.info>
	<4FE1B8EF.5030907@kcl.ac.uk> <4FEC3D4D.208@ultraslavonic.info>
Message-ID: <9769DEEB-935A-41CD-B4EA-37B2D6AB0282@oucs.ox.ac.uk>


On 28 Jun 2012, at 12:17, Kevin Hawkins wrote:

> 
>> But the thing that delayed Gaby was a
>> problem with the tei_all.dtd was noticed.Should the release
>> technician be checking a file against all of these (but surely
>> Jenkins has done this?)  Need better (but quicker) testing on
>> Jenkins clearly.
> 
> A question for Sebastian?
> 
there is now code in Exemplars/Makefile to check the obvious candidates
against DTD and RNG validators, which should catch this. 

the quicker test now in Jenkins does not include this, but thats
designed to catch crude typos and invalid examples.

--
Sebastian Rahtz      
Head of Information and Support Group
Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431

S?lo le pido a Dios
que el futuro no me sea indiferente


From James.Cummings at oucs.ox.ac.uk  Thu Jun 28 14:15:17 2012
From: James.Cummings at oucs.ox.ac.uk (James Cummings)
Date: Thu, 28 Jun 2012 19:15:17 +0100
Subject: [tei-council] latest Tite DTD?
In-Reply-To: <3E40B1AA-CD2C-4879-96FB-7D7030406544@oucs.ox.ac.uk>
References: <2FC5F4A7011AEF4C86B2EB7A6013CDC9851B97F54F@exchange07.acv.apexcovantage.com>
	<4FEBDF31.3050901@ultraslavonic.info>
	<43CE60E8-DA3C-4F15-ABF7-AC98F50848BC@oucs.ox.ac.uk>
	<4FEC234E.7010508@ultraslavonic.info>
	<3E40B1AA-CD2C-4879-96FB-7D7030406544@oucs.ox.ac.uk>
Message-ID: <4FEC9F35.9010008@oucs.ox.ac.uk>



Could I just remind TEI Technical Council members that their 
posts are publicly archived? For example, I understand the joking 
about Apex is light-hearted but remember that some people may 
stumble across your messages out of context.  That the TEI Tite 
DTD diverged at all is unfortunate, but I'm sure you guys can 
bring everything back in line. As far as I'm aware Apex have been 
helpful and useful to the TEI-C in providing a membership 
benefit, and have always been above board in their dealings with us.


On 28/06/12 10:36, Sebastian Rahtz wrote:
>
> On 28 Jun 2012, at 10:26, Kevin Hawkins wrote:
>>
>> If you really find differences in (b), don't those count as a Tite
>> variant?  Why would you conclude that they don't have their own variant?
>>
> because the differences are meaningless.  those entities are not referenced. I
> suspect its some small
>
>> In any case, something is still not right.  Their prose documentation
>> mentions<handShift/>, does not mention<biblScope>, etc., yet all of
>> these are still in the DTD.  So they never got around to changing the
>> DTD, or they are as devious as Sebastian fears.  I suspect incompetence,
>> not deviousness.
>
> i'll vote for devious :-}
>
> --
> Sebastian Rahtz
> Head of Information and Support Group
> Oxford University Computing Services
> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>
> S?lo le pido a Dios
> que el futuro no me sea indiferente
>


-- 
Dr James Cummings, InfoDev
Oxford University Computing Services
University of Oxford

From lou.burnard at retired.ox.ac.uk  Thu Jun 28 14:20:53 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Thu, 28 Jun 2012 19:20:53 +0100
Subject: [tei-council] latest Tite DTD?
In-Reply-To: <4FEC9F35.9010008@oucs.ox.ac.uk>
References: <2FC5F4A7011AEF4C86B2EB7A6013CDC9851B97F54F@exchange07.acv.apexcovantage.com>
	<4FEBDF31.3050901@ultraslavonic.info>
	<43CE60E8-DA3C-4F15-ABF7-AC98F50848BC@oucs.ox.ac.uk>
	<4FEC234E.7010508@ultraslavonic.info>
	<3E40B1AA-CD2C-4879-96FB-7D7030406544@oucs.ox.ac.uk>
	<4FEC9F35.9010008@oucs.ox.ac.uk>
Message-ID: <4FECA085.7010209@retired.ox.ac.uk>

Well, at least no-one has (so far) said "You've got a week and a bit to 
get your shit together, otherwise I'm blowing the airport sky high!"


On 28/06/12 19:15, James Cummings wrote:
>
>
> Could I just remind TEI Technical Council members that their
> posts are publicly archived? For example, I understand the joking
> about Apex is light-hearted but remember that some people may
> stumble across your messages out of context.  That the TEI Tite
> DTD diverged at all is unfortunate, but I'm sure you guys can
> bring everything back in line. As far as I'm aware Apex have been
> helpful and useful to the TEI-C in providing a membership
> benefit, and have always been above board in their dealings with us.
>
>
> On 28/06/12 10:36, Sebastian Rahtz wrote:
>>
>> On 28 Jun 2012, at 10:26, Kevin Hawkins wrote:
>>>
>>> If you really find differences in (b), don't those count as a Tite
>>> variant?  Why would you conclude that they don't have their own variant?
>>>
>> because the differences are meaningless.  those entities are not referenced. I
>> suspect its some small
>>
>>> In any case, something is still not right.  Their prose documentation
>>> mentions<handShift/>, does not mention<biblScope>, etc., yet all of
>>> these are still in the DTD.  So they never got around to changing the
>>> DTD, or they are as devious as Sebastian fears.  I suspect incompetence,
>>> not deviousness.
>>
>> i'll vote for devious :-}
>>
>> --
>> Sebastian Rahtz
>> Head of Information and Support Group
>> Oxford University Computing Services
>> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>>
>> S?lo le pido a Dios
>> que el futuro no me sea indiferente
>>
>
>



From sebastian.rahtz at oucs.ox.ac.uk  Thu Jun 28 14:38:01 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Thu, 28 Jun 2012 18:38:01 +0000
Subject: [tei-council] latest Tite DTD?
In-Reply-To: <4FECA085.7010209@retired.ox.ac.uk>
References: <2FC5F4A7011AEF4C86B2EB7A6013CDC9851B97F54F@exchange07.acv.apexcovantage.com>
	<4FEBDF31.3050901@ultraslavonic.info>
	<43CE60E8-DA3C-4F15-ABF7-AC98F50848BC@oucs.ox.ac.uk>
	<4FEC234E.7010508@ultraslavonic.info>
	<3E40B1AA-CD2C-4879-96FB-7D7030406544@oucs.ox.ac.uk>
	<4FEC9F35.9010008@oucs.ox.ac.uk> <4FECA085.7010209@retired.ox.ac.uk>
Message-ID: <b2a361cb-3ecd-4e4e-a2fc-a0ccac5a1daa@HUB02.ad.oak.ox.ac.uk>


On 28 Jun 2012, at 19:20, Lou Burnard wrote:

> Well, at least no-one has (so far) said "You've got a week and a bit to 
> get your shit together, otherwise I'm blowing the airport sky high!"
> 


yes, that was indeed not to be found in the Council archives until
28 Jun 2012, at 19:20......

do you know the address of the Ecuadorian embassy?
--
Sebastian Rahtz      
Head of Information and Support Group
Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431







From mholmes at uvic.ca  Thu Jun 28 14:50:51 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Thu, 28 Jun 2012 11:50:51 -0700
Subject: [tei-council] Extended language subtags must begin with the
 letter "s".???
In-Reply-To: <4FE9E41A.8010209@uvic.ca>
References: <4FE9E41A.8010209@uvic.ca>
Message-ID: <4FECA78B.6070104@uvic.ca>

I'm throwing this out again to everyone, since I got no response last 
time. Does anyone know where this idea came from? I've been looking at 
some of the P5 files on CBETA, which I think is Chris's largest project, 
and I don't find anything more complex than "en", "zh, "pi" and "sa".

Unless anyone can come up with any source for this, I'm going to 
conclude that it's flat-out wrong, and remove it. I'll have to replace 
the two examples which use it, as well:

 > zh-s-nan (the Southern Min language of the macrolanguage Chinese)
 >
 > zh-s-nan-Hans-CN (the Southern Min language of the macrolanguage Chinese
 > as spoken in China written in simplified Characters)

Cheers,
Martin

On 12-06-26 09:32 AM, Martin Holmes wrote:
> CH says:
>
> "Extended language subtags must begin with the letter "s".
>    They must follow the primary subtag and precede subtags that do
>    define other properties of the language.  The order is significant."
>
> I can't find any justification for this in BCP 47 or anywhere else, and
> it's surely untrue -- . Does anyone know where this came from? Basic
> examples from BCP 47 surely counter it, too:
>
> "zh-gan", "zh-yue", "zh-cmn"
>
> I'm copying Syd on this because he knows a lot about this stuff.
>
> Cheers,
> Martin
>


From James.Cummings at oucs.ox.ac.uk  Thu Jun 28 15:39:46 2012
From: James.Cummings at oucs.ox.ac.uk (James Cummings)
Date: Thu, 28 Jun 2012 20:39:46 +0100
Subject: [tei-council] latest Tite DTD?
In-Reply-To: <b2a361cb-3ecd-4e4e-a2fc-a0ccac5a1daa@HUB02.ad.oak.ox.ac.uk>
References: <2FC5F4A7011AEF4C86B2EB7A6013CDC9851B97F54F@exchange07.acv.apexcovantage.com>
	<4FEBDF31.3050901@ultraslavonic.info>
	<43CE60E8-DA3C-4F15-ABF7-AC98F50848BC@oucs.ox.ac.uk>
	<4FEC234E.7010508@ultraslavonic.info>
	<3E40B1AA-CD2C-4879-96FB-7D7030406544@oucs.ox.ac.uk>
	<4FEC9F35.9010008@oucs.ox.ac.uk>
	<4FECA085.7010209@retired.ox.ac.uk>
	<b2a361cb-3ecd-4e4e-a2fc-a0ccac5a1daa@HUB02.ad.oak.ox.ac.uk>
Message-ID: <4FECB302.6020206@oucs.ox.ac.uk>

On 28/06/12 19:38, Sebastian Rahtz wrote:
>
> On 28 Jun 2012, at 19:20, Lou Burnard wrote:
>
>> Well, at least no-one has (so far) said "You've got a week and a bit to
>> get your shit together, otherwise I'm blowing the airport sky high!"

Just to clarify, I in no way want to stop the jokes which make 
tei-council such an amiable if sometimes mind-bogglingly 
confusing read.  Just reminding everyone that posts are archived 
publicly.  (Especially since according to google I'm partly 
responsible for the decision to make them public! 
http://lists.village.virginia.edu/pipermail/tei-council/2006/005757.html)

> do you know the address of the Ecuadorian embassy?

Ah good, back to humour which is much more impenetrable without 
context.

-James
-- 
Dr James Cummings, InfoDev
Oxford University Computing Services
University of Oxford

From lou.burnard at retired.ox.ac.uk  Thu Jun 28 16:03:59 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Thu, 28 Jun 2012 21:03:59 +0100
Subject: [tei-council] Extended language subtags must begin with the
 letter "s".???
In-Reply-To: <4FECA78B.6070104@uvic.ca>
References: <4FE9E41A.8010209@uvic.ca> <4FECA78B.6070104@uvic.ca>
Message-ID: <4FECB8AF.3040605@retired.ox.ac.uk>

Did Chris's response not reach you?

He said

"They look a bit strange, but looking at 
http://tools.ietf.org/html/bcp47#page-1-16 Section 2.2.6 they seem to be 
possible, no?

Christian"

a couple days ago, but maybe his mail to tei-council is getting bounced

I havent checked the reference he gives above though


On 28/06/12 19:50, Martin Holmes wrote:
> I'm throwing this out again to everyone, since I got no response last
> time. Does anyone know where this idea came from? I've been looking at
> some of the P5 files on CBETA, which I think is Chris's largest project,
> and I don't find anything more complex than "en", "zh, "pi" and "sa".
>
> Unless anyone can come up with any source for this, I'm going to
> conclude that it's flat-out wrong, and remove it. I'll have to replace
> the two examples which use it, as well:
>
>   > zh-s-nan (the Southern Min language of the macrolanguage Chinese)
>   >
>   > zh-s-nan-Hans-CN (the Southern Min language of the macrolanguage Chinese
>   > as spoken in China written in simplified Characters)
>
> Cheers,
> Martin
>
> On 12-06-26 09:32 AM, Martin Holmes wrote:
>> CH says:
>>
>> "Extended language subtags must begin with the letter "s".
>>     They must follow the primary subtag and precede subtags that do
>>     define other properties of the language.  The order is significant."
>>
>> I can't find any justification for this in BCP 47 or anywhere else, and
>> it's surely untrue -- . Does anyone know where this came from? Basic
>> examples from BCP 47 surely counter it, too:
>>
>> "zh-gan", "zh-yue", "zh-cmn"
>>
>> I'm copying Syd on this because he knows a lot about this stuff.
>>
>> Cheers,
>> Martin
>>
>



From mholmes at uvic.ca  Thu Jun 28 16:52:16 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Thu, 28 Jun 2012 13:52:16 -0700
Subject: [tei-council] Extended language subtags must begin with the
 letter "s".???
In-Reply-To: <4FECB8AF.3040605@retired.ox.ac.uk>
References: <4FE9E41A.8010209@uvic.ca> <4FECA78B.6070104@uvic.ca>
	<4FECB8AF.3040605@retired.ox.ac.uk>
Message-ID: <4FECC400.6040609@uvic.ca>

I never saw Chris's response -- maybe he just responded to you, or the 
list rejected his mail.

I've been reading through that section, and he's right that the 
extension subtag "s" is _possible_, assuming that the "s" extension is 
"allocated to a registration authority via the mechanism described in 
Section 3.7". This tells us that IANA is responsible for the assigning 
single-letter subtags. The only such list I can find on the IANA site is 
this one:

<http://www.iana.org/assignments/language-tag-extensions-registry>

which defines only two, "t" and "u".

So I'm pretty sure that although these are plausible examples, they're 
not actually real, unless someone has registered the singleton subtag, 
and I can find no evidence of that.

I'm copying Chris again in case he can remember where these examples 
actually came from. I think we can say for sure, though, that the 
sentence "Extended language subtags must begin with the letter "s"." is 
nonsense and should be removed. Unless I hear any objections, I'll do 
that tomorrow.

I'm not sure that it's a good idea, either, to provide examples which, 
while plausible, have never been seen in the wild, when we could stick 
to known good examples from the subtag registry. So I would vote for 
replacing those examples unless we can find out where they originate.

Cheers,
Martin

On 12-06-28 01:03 PM, Lou Burnard wrote:
> Did Chris's response not reach you?
>
> He said
>
> "They look a bit strange, but looking at
> http://tools.ietf.org/html/bcp47#page-1-16 Section 2.2.6 they seem to be
> possible, no?
>
> Christian"
>
> a couple days ago, but maybe his mail to tei-council is getting bounced
>
> I havent checked the reference he gives above though
>
>
> On 28/06/12 19:50, Martin Holmes wrote:
>> I'm throwing this out again to everyone, since I got no response last
>> time. Does anyone know where this idea came from? I've been looking at
>> some of the P5 files on CBETA, which I think is Chris's largest project,
>> and I don't find anything more complex than "en", "zh, "pi" and "sa".
>>
>> Unless anyone can come up with any source for this, I'm going to
>> conclude that it's flat-out wrong, and remove it. I'll have to replace
>> the two examples which use it, as well:
>>
>>    > zh-s-nan (the Southern Min language of the macrolanguage Chinese)
>>    >
>>    > zh-s-nan-Hans-CN (the Southern Min language of the macrolanguage Chinese
>>    > as spoken in China written in simplified Characters)
>>
>> Cheers,
>> Martin
>>
>> On 12-06-26 09:32 AM, Martin Holmes wrote:
>>> CH says:
>>>
>>> "Extended language subtags must begin with the letter "s".
>>>      They must follow the primary subtag and precede subtags that do
>>>      define other properties of the language.  The order is significant."
>>>
>>> I can't find any justification for this in BCP 47 or anywhere else, and
>>> it's surely untrue -- . Does anyone know where this came from? Basic
>>> examples from BCP 47 surely counter it, too:
>>>
>>> "zh-gan", "zh-yue", "zh-cmn"
>>>
>>> I'm copying Syd on this because he knows a lot about this stuff.
>>>
>>> Cheers,
>>> Martin
>>>
>>
>
>


From mholmes at uvic.ca  Thu Jun 28 21:15:18 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Thu, 28 Jun 2012 18:15:18 -0700
Subject: [tei-council] Extended language subtags must begin with the
 letter "s".???
In-Reply-To: <4FECFD96.40801@gmail.com>
References: <4FE9E41A.8010209@uvic.ca> <4FECA78B.6070104@uvic.ca>
	<4FECB8AF.3040605@retired.ox.ac.uk> <4FECC400.6040609@uvic.ca>
	<4FECFD96.40801@gmail.com>
Message-ID: <4FED01A6.7050406@uvic.ca>

HI Chris, (copying to Council list)

On 12-06-28 05:57 PM, Christian Wittern wrote:
> Hi Martin,
>
> I can't post to tei-council, so you might forward my answer there.
>
> On 2012-06-29 05:52, Martin Holmes wrote:
>> I never saw Chris's response -- maybe he just responded to you, or the
>> list rejected his mail.
>>
>> I've been reading through that section, and he's right that the extension
>> subtag "s" is _possible_, assuming that the "s" extension is "allocated to
>> a registration authority via the mechanism described in Section 3.7". This
>> tells us that IANA is responsible for the assigning single-letter subtags.
>> The only such list I can find on the IANA site is this one:
>>
>> <http://www.iana.org/assignments/language-tag-extensions-registry>
>>
>> which defines only two, "t" and "u".
>>
>> So I'm pretty sure that although these are plausible examples, they're not
>> actually real, unless someone has registered the singleton subtag, and I
>> can find no evidence of that.
>>
>> I'm copying Chris again in case he can remember where these examples
>> actually came from. I think we can say for sure, though, that the sentence
>> "Extended language subtags must begin with the letter "s"." is nonsense
>> and should be removed. Unless I hear any objections, I'll do that tomorrow.
>
> Quite right.  I do not remember exactly where these examples are from, but I
> remember that I copied stuff from the then current BP47 document (or maybe
> its predecessor), which might have included these.   But as I see now, these
> examples are nonsense and should be removed.

I think only the bit about "Extended language subtags must begin with 
the letter "s"." is nonsense; the examples are plausible, but perhaps 
not ideal because I don't think they actually could be used.

> Just as a matter of curiosity, how would you then encode "the Southern Min
> language of the macrolanguage Chinese as spoken in China written in
> simplified Characters"?

I honestly have no idea. The only things in the official list which are 
close is this:

Type: language
Subtag: nan
Description: Min Nan Chinese
Added: 2009-07-29
Macrolanguage: zh

which would formerly have been written zh-nan, but should now be written 
simply as nan, if I understand correctly. I think you could therefore do 
this:

nan-Hans-CN

to create the intended combination.

> Fortunately, in the CBETA context we did not
> encounter this:-)
>
> I would not object to made up examples, as long as they are correct
> according to the current rules.

Nor would I, but I think it's simpler to use real examples where they 
can be easily found.

Cheers,
Martin


From James.Cummings at oucs.ox.ac.uk  Fri Jun 29 06:00:44 2012
From: James.Cummings at oucs.ox.ac.uk (James Cummings)
Date: Fri, 29 Jun 2012 11:00:44 +0100
Subject: [tei-council] Assigning SF tracker items
Message-ID: <4FED7CCC.1030307@oucs.ox.ac.uk>


Hi all,

I'm going to be going through and assigning SF tracker items 
(bugs & FR) with no 'Assignee'.  I'll be doing this on a fairly 
superficial basis of "Oh, doesn't so-and-so know something about 
this".  If I mis-assign you an item, please don't take it 
personally.  If you honestly can't do it, either reassign it back 
to 'Nobody' putting a comment on the ticket noting why. If you 
think you know who _should_ be assigned it then liaise with them 
and if they are willing add a comment when changing the assignment.

-James


-- 
Dr James Cummings, InfoDev,
OUCS, University of Oxford

From kevin.s.hawkins at ultraslavonic.info  Fri Jun 29 06:37:49 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Fri, 29 Jun 2012 06:37:49 -0400
Subject: [tei-council] Release notes (was Re:  next release?)
In-Reply-To: <9769DEEB-935A-41CD-B4EA-37B2D6AB0282@oucs.ox.ac.uk>
References: <0F18A249-5480-42D9-BFF2-538AC7B9E1EB@oucs.ox.ac.uk>
	<4F92F34D.2040103@uvic.ca>	<4F9579A0.8010002@oucs.ox.ac.uk>
	<4F95C7A1.1080707@o2.pl>	<4F96756B.1060202@oucs.ox.ac.uk>
	<4F986673.7020201@kcl.ac.uk>	<4FB95846.7080308@oucs.ox.ac.uk>
	<4FDA15EC.5050700@oucs.ox.ac.uk> <4FDB16D3.2080007@kcl.ac.uk>
	<4FDDB2D8.7090604@oucs.ox.ac.uk>	<4FDDE5E5.9000000@retired.ox.ac.uk>
	<4FDEEF88.3020503@kcl.ac.uk>	<4FDEF0A2.1020400@retired.ox.ac.uk>
	<4FDEF1F0.7020906@o2.pl> <4FDEF522.5040601@kcl.ac.uk>
	<4FDF66C2.5070307@kcl.ac.uk> <4FE0F032.30207@ultraslavonic.info>
	<4FE1B8EF.5030907@kcl.ac.uk> <4FEC3D4D.208@ultraslavonic.info>
	<9769DEEB-935A-41CD-B4EA-37B2D6AB0282@oucs.ox.ac.uk>
Message-ID: <4FED857D.4040001@ultraslavonic.info>

On 6/28/12 12:45 PM, Sebastian Rahtz wrote:
>
> On 28 Jun 2012, at 12:17, Kevin Hawkins wrote:
>
>>
>>> But the thing that delayed Gaby was a
>>> problem with the tei_all.dtd was noticed.Should the release
>>> technician be checking a file against all of these (but surely
>>> Jenkins has done this?)  Need better (but quicker) testing on
>>> Jenkins clearly.
>>
>> A question for Sebastian?
>>
> there is now code in Exemplars/Makefile to check the obvious candidates
> against DTD and RNG validators, which should catch this.

So does any step already in tcw22 catch this?  Like maybe 
tei-install.sh?  Or do we need to add a step to tcw22 where you run this 
Makefile?

--K.

From sebastian.rahtz at oucs.ox.ac.uk  Fri Jun 29 06:42:00 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Fri, 29 Jun 2012 10:42:00 +0000
Subject: [tei-council] Release notes (was Re:  next release?)
In-Reply-To: <4FED857D.4040001@ultraslavonic.info>
References: <0F18A249-5480-42D9-BFF2-538AC7B9E1EB@oucs.ox.ac.uk>
	<4F92F34D.2040103@uvic.ca>	<4F9579A0.8010002@oucs.ox.ac.uk>
	<4F95C7A1.1080707@o2.pl>	<4F96756B.1060202@oucs.ox.ac.uk>
	<4F986673.7020201@kcl.ac.uk>	<4FB95846.7080308@oucs.ox.ac.uk>
	<4FDA15EC.5050700@oucs.ox.ac.uk> <4FDB16D3.2080007@kcl.ac.uk>
	<4FDDB2D8.7090604@oucs.ox.ac.uk>	<4FDDE5E5.9000000@retired.ox.ac.uk>
	<4FDEEF88.3020503@kcl.ac.uk>	<4FDEF0A2.1020400@retired.ox.ac.uk>
	<4FDEF1F0.7020906@o2.pl> <4FDEF522.5040601@kcl.ac.uk>
	<4FDF66C2.5070307@kcl.ac.uk> <4FE0F032.30207@ultraslavonic.info>
	<4FE1B8EF.5030907@kcl.ac.uk> <4FEC3D4D.208@ultraslavonic.info>
	<9769DEEB-935A-41CD-B4EA-37B2D6AB0282@oucs.ox.ac.uk>
	<4FED857D.4040001@ultraslavonic.info>
Message-ID: <F193046B-F937-4797-979A-BFEA5E89B93C@oucs.ox.ac.uk>


On 29 Jun 2012, at 11:37, Kevin Hawkins wrote:

>>> 
>> there is now code in Exemplars/Makefile to check the obvious candidates
>> against DTD and RNG validators, which should catch this.
> 
> So does any step already in tcw22 catch this?  Like maybe 
> tei-install.sh?  Or do we need to add a step to tcw22 where you run this 
> Makefile?


eh? no. its run by the standard Jenkins build, in phase 3. just that it will
take an hour or two to get there after a commit.

--
Sebastian Rahtz      
Head of Information and Support Group
Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431

S?lo le pido a Dios
que el futuro no me sea indiferente


From James.Cummings at oucs.ox.ac.uk  Fri Jun 29 08:33:37 2012
From: James.Cummings at oucs.ox.ac.uk (James Cummings)
Date: Fri, 29 Jun 2012 13:33:37 +0100
Subject: [tei-council] http://purl.org/tei/fr/3519866 (@rend datatype)
In-Reply-To: <4FED7CCC.1030307@oucs.ox.ac.uk>
References: <4FED7CCC.1030307@oucs.ox.ac.uk>
Message-ID: <4FEDA0A1.5050305@oucs.ox.ac.uk>


Is there someone who feels they can be neutral and objective who 
would like to take on http://purl.org/tei/fr/3519866 which is the 
ticket discussing whether @rend's datatype should be changed? 
I'd prefer someone who is not already very much for or against 
this to look at it.

I'm hideously biased against loosening its datatype and the 
existing recommendations that @rend values are separate tokens, 
so don't feel I should take it on myself.  If you've not been 
involved in the discussion so far and/or know nothing about it, 
you might be the right person to re-examine it.

-James
-- 
Dr James Cummings, InfoDev,
OUCS, University of Oxford

From mholmes at uvic.ca  Fri Jun 29 11:57:32 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Fri, 29 Jun 2012 08:57:32 -0700
Subject: [tei-council] Expanded proposal for private URI scheme system
Message-ID: <4FEDD06C.10600@uvic.ca>

With input from Kevin and Stuart, I've expanded the proposal:

<http://wiki.tei-c.org/index.php/Private_URI_Schemes>

Cheers,
Martin
-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)


From bansp at o2.pl  Fri Jun 29 15:59:27 2012
From: bansp at o2.pl (=?ISO-8859-2?Q?Piotr_Ba=F1ski?=)
Date: Fri, 29 Jun 2012 21:59:27 +0200
Subject: [tei-council] http://purl.org/tei/fr/3519866 (@rend datatype)
In-Reply-To: <4FEDA0A1.5050305@oucs.ox.ac.uk>
References: <4FED7CCC.1030307@oucs.ox.ac.uk> <4FEDA0A1.5050305@oucs.ox.ac.uk>
Message-ID: <4FEE091F.7060106@o2.pl>

My view is similar to yours, so I'm not sure whether I would properly
serve the greater good here. In case no one wants it, I can try, though
this is now, I think, a very sore issue. It might be a good idea for the
Council to act as a body on this.

Maybe we could take it on in September?

  P.

On 29/06/12 14:33, James Cummings wrote:
> 
> Is there someone who feels they can be neutral and objective who 
> would like to take on http://purl.org/tei/fr/3519866 which is the 
> ticket discussing whether @rend's datatype should be changed? 
> I'd prefer someone who is not already very much for or against 
> this to look at it.
> 
> I'm hideously biased against loosening its datatype and the 
> existing recommendations that @rend values are separate tokens, 
> so don't feel I should take it on myself.  If you've not been 
> involved in the discussion so far and/or know nothing about it, 
> you might be the right person to re-examine it.
> 
> -James
> 



From mholmes at uvic.ca  Fri Jun 29 16:40:08 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Fri, 29 Jun 2012 13:40:08 -0700
Subject: [tei-council] http://purl.org/tei/fr/3519866 (@rend datatype)
In-Reply-To: <4FEE091F.7060106@o2.pl>
References: <4FED7CCC.1030307@oucs.ox.ac.uk> <4FEDA0A1.5050305@oucs.ox.ac.uk>
	<4FEE091F.7060106@o2.pl>
Message-ID: <4FEE12A8.5050904@uvic.ca>

I'm on the other side of this debate, and equally biased. I agree that 
we need to take this on as a group, but I'd suggest scheduling it on the 
last day of the ftf so that if we get all heated about it, there'll be a 
natural end to the discussion. :-)

On 12-06-29 12:59 PM, Piotr Ba?ski wrote:
> My view is similar to yours, so I'm not sure whether I would properly
> serve the greater good here. In case no one wants it, I can try, though
> this is now, I think, a very sore issue. It might be a good idea for the
> Council to act as a body on this.
>
> Maybe we could take it on in September?
>
>    P.
>
> On 29/06/12 14:33, James Cummings wrote:
>>
>> Is there someone who feels they can be neutral and objective who
>> would like to take on http://purl.org/tei/fr/3519866 which is the
>> ticket discussing whether @rend's datatype should be changed?
>> I'd prefer someone who is not already very much for or against
>> this to look at it.
>>
>> I'm hideously biased against loosening its datatype and the
>> existing recommendations that @rend values are separate tokens,
>> so don't feel I should take it on myself.  If you've not been
>> involved in the discussion so far and/or know nothing about it,
>> you might be the right person to re-examine it.
>>
>> -James
>>
>
>

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)



From James.Cummings at oucs.ox.ac.uk  Sat Jun 30 10:29:37 2012
From: James.Cummings at oucs.ox.ac.uk (James Cummings)
Date: Sat, 30 Jun 2012 15:29:37 +0100
Subject: [tei-council] http://purl.org/tei/fr/3519866 (@rend datatype)
In-Reply-To: <4FEE12A8.5050904@uvic.ca>
References: <4FED7CCC.1030307@oucs.ox.ac.uk> <4FEDA0A1.5050305@oucs.ox.ac.uk>
	<4FEE091F.7060106@o2.pl> <4FEE12A8.5050904@uvic.ca>
Message-ID: <4FEF0D51.9010708@oucs.ox.ac.uk>


Would it make sense for two nice reasonable people (like Martin 
and Piotr) on opposite sides of the discussion to look at it as 
an ad-hoc group?  (Possibly with someone who doesn't have an 
opinion one way or the other?)  They could then report back to 
the face2face?

-James


On 29/06/12 21:40, Martin Holmes wrote:
> I'm on the other side of this debate, and equally biased. I agree that
> we need to take this on as a group, but I'd suggest scheduling it on the
> last day of the ftf so that if we get all heated about it, there'll be a
> natural end to the discussion. :-)
>
> On 12-06-29 12:59 PM, Piotr Ba?ski wrote:
>> My view is similar to yours, so I'm not sure whether I would properly
>> serve the greater good here. In case no one wants it, I can try, though
>> this is now, I think, a very sore issue. It might be a good idea for the
>> Council to act as a body on this.
>>
>> Maybe we could take it on in September?
>>
>>     P.
>>
>> On 29/06/12 14:33, James Cummings wrote:
>>>
>>> Is there someone who feels they can be neutral and objective who
>>> would like to take on http://purl.org/tei/fr/3519866 which is the
>>> ticket discussing whether @rend's datatype should be changed?
>>> I'd prefer someone who is not already very much for or against
>>> this to look at it.
>>>
>>> I'm hideously biased against loosening its datatype and the
>>> existing recommendations that @rend values are separate tokens,
>>> so don't feel I should take it on myself.  If you've not been
>>> involved in the discussion so far and/or know nothing about it,
>>> you might be the right person to re-examine it.
>>>
>>> -James
>>>
>>
>>
>


-- 
Dr James Cummings, InfoDev
Oxford University Computing Services
University of Oxford

From gabriel.bodard at kcl.ac.uk  Mon Jul  2 06:22:10 2012
From: gabriel.bodard at kcl.ac.uk (Gabriel Bodard)
Date: Mon, 2 Jul 2012 11:22:10 +0100
Subject: [tei-council] http://purl.org/tei/fr/3519866 (@rend datatype)
In-Reply-To: <4FEF0D51.9010708@oucs.ox.ac.uk>
References: <4FED7CCC.1030307@oucs.ox.ac.uk>
	<4FEDA0A1.5050305@oucs.ox.ac.uk>	<4FEE091F.7060106@o2.pl>
	<4FEE12A8.5050904@uvic.ca> <4FEF0D51.9010708@oucs.ox.ac.uk>
Message-ID: <4FF17652.70701@kcl.ac.uk>

I have no objection to that, if they don't. :-)

That said, I also feel fairly strongly that @rend shouldn't be devalued 
as is being proposed, because it would break (my) existing usage without 
in my view gaining anything, but I don't think that makes me 
unconscionably biased or anything. We all have opinions--let's be proud 
of them! :-)

Good luck!

G

On 2012-06-30 15:29, James Cummings wrote:
>
> Would it make sense for two nice reasonable people (like Martin
> and Piotr) on opposite sides of the discussion to look at it as
> an ad-hoc group?  (Possibly with someone who doesn't have an
> opinion one way or the other?)  They could then report back to
> the face2face?
>
> -James
>
>
> On 29/06/12 21:40, Martin Holmes wrote:
>> I'm on the other side of this debate, and equally biased. I agree that
>> we need to take this on as a group, but I'd suggest scheduling it on the
>> last day of the ftf so that if we get all heated about it, there'll be a
>> natural end to the discussion. :-)
>>
>> On 12-06-29 12:59 PM, Piotr Ba?ski wrote:
>>> My view is similar to yours, so I'm not sure whether I would properly
>>> serve the greater good here. In case no one wants it, I can try, though
>>> this is now, I think, a very sore issue. It might be a good idea for the
>>> Council to act as a body on this.
>>>
>>> Maybe we could take it on in September?
>>>
>>>      P.
>>>
>>> On 29/06/12 14:33, James Cummings wrote:
>>>>
>>>> Is there someone who feels they can be neutral and objective who
>>>> would like to take on http://purl.org/tei/fr/3519866 which is the
>>>> ticket discussing whether @rend's datatype should be changed?
>>>> I'd prefer someone who is not already very much for or against
>>>> this to look at it.
>>>>
>>>> I'm hideously biased against loosening its datatype and the
>>>> existing recommendations that @rend values are separate tokens,
>>>> so don't feel I should take it on myself.  If you've not been
>>>> involved in the discussion so far and/or know nothing about it,
>>>> you might be the right person to re-examine it.
>>>>
>>>> -James
>>>>
>>>
>>>
>>
>
>

-- 
Dr Gabriel BODARD
(Research Associate in Digital Epigraphy)

Department of Digital Humanities
King's College London
26-29 Drury Lane
London WC2B 5RL

Email: gabriel.bodard at kcl.ac.uk
Tel: +44 (0)20 7848 1388
Fax: +44 (0)20 7848 2980

http://www.digitalclassicist.org/
http://www.currentepigraphy.org/



From bansp at o2.pl  Mon Jul  2 08:30:29 2012
From: bansp at o2.pl (Piotr Banski)
Date: Mon, 02 Jul 2012 14:30:29 +0200
Subject: [tei-council] CH and BCP 47 again
In-Reply-To: <4FEA6AD7.1090102@ultraslavonic.info>
References: <4FE9E0A9.4090302@uvic.ca> <4FE9ED24.90907@ultraslavonic.info>
	<4FEA0DC0.1030205@uvic.ca>
	<CAC_Lu0ZzE6eEF8rJGGaeGhnsuTzS+CRbaM6PxTvQfDBHHR9WRQ@mail.gmail.com>
	<4FEA6AD7.1090102@ultraslavonic.info>
Message-ID: <4FF19465.3030908@o2.pl>

(found this message accidentally)

By this logic, we shouldn't bother to insert xml:langs in bilingual 
dictionaries. I'd have no problem with a uniform declaration that <pron> 
in that very dictionary is always to be interpreted as this-and-that 
script, and that <quote> inside <cit @type="translation"> is to be 
interpreted so-and-so.

Except we don't seem to have such a mechanism, do we? In which case, I 
can't see a good reason to skip this very relevant information. The 
result is massive redundancy, but well, that's a fact, this is what we 
recommend, so why avoid stating this openly in the Guidelines?

Best,

   P.


On 27/06/12 04:07, Kevin Hawkins wrote:
> There is no particular exception to use of @xml:lang on <pron> that I am
> aware of.  As a global attribute, @xml:lang may be used on any element
> but need not be used anywhere.
>
> I am inclined not to bother inserting @xml:lang on these examples.  If
> you encode a dictionary, every <pron> will likely use the same script as
> every other <pron>, and this will be the only part of the dictionary
> using this script (whatever it is).  I can't imagine a use case for
> recording on individual <pron>s.
>
> --K.
>
> On 6/26/12 5:14 PM, Stuart A. Yeates wrote:
>> On a related note (and not covered in CH or BCP 47 as far as I can tell):
>>
>> Almost all the <pron/> examples in
>> http://www.tei-c.org/release/doc/tei-p5-doc/en/html/examples-pron.html
>> use a different script to the surrounding text, but none of them have
>> an xml:lang attribute describing that.
>>
>> Does <pron/> have an exception from xml:lang, or do we need to add
>> them to the examples?
>>
>> cheers
>> stuart
>>
>



From kevin.s.hawkins at ultraslavonic.info  Mon Jul  2 08:48:26 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Mon, 02 Jul 2012 08:48:26 -0400
Subject: [tei-council] CH and BCP 47 again
In-Reply-To: <4FF19465.3030908@o2.pl>
References: <4FE9E0A9.4090302@uvic.ca> <4FE9ED24.90907@ultraslavonic.info>
	<4FEA0DC0.1030205@uvic.ca>
	<CAC_Lu0ZzE6eEF8rJGGaeGhnsuTzS+CRbaM6PxTvQfDBHHR9WRQ@mail.gmail.com>
	<4FEA6AD7.1090102@ultraslavonic.info> <4FF19465.3030908@o2.pl>
Message-ID: <4FF1989A.9030308@ultraslavonic.info>



On 7/2/12 8:30 AM, Piotr Banski wrote:
> By this logic, we shouldn't bother to insert xml:langs in bilingual
> dictionaries. I'd have no problem with a uniform declaration that <pron>
> in that very dictionary is always to be interpreted as this-and-that
> script, and that <quote> inside <cit @type="translation"> is to be
> interpreted so-and-so.

That's all that I was implying!  I didn't mean to say that there is any 
sort of global mechanism.

My point was that these examples are supposed to look like someone's 
real-life encoding.  And in real-life encoding, you're unlikely to add 
@xml:lang to every <pron> (or to <quote> inside <cit 
@type="translation">) in a single bilingual dictionary.

> On 27/06/12 04:07, Kevin Hawkins wrote:
>> There is no particular exception to use of @xml:lang on <pron> that I am
>> aware of.  As a global attribute, @xml:lang may be used on any element
>> but need not be used anywhere.
>>
>> I am inclined not to bother inserting @xml:lang on these examples.  If
>> you encode a dictionary, every <pron> will likely use the same script as
>> every other <pron>, and this will be the only part of the dictionary
>> using this script (whatever it is).  I can't imagine a use case for
>> recording on individual <pron>s.
>>
>> --K.
>>
>> On 6/26/12 5:14 PM, Stuart A. Yeates wrote:
>>> On a related note (and not covered in CH or BCP 47 as far as I can tell):
>>>
>>> Almost all the <pron/> examples in
>>> http://www.tei-c.org/release/doc/tei-p5-doc/en/html/examples-pron.html
>>> use a different script to the surrounding text, but none of them have
>>> an xml:lang attribute describing that.
>>>
>>> Does <pron/> have an exception from xml:lang, or do we need to add
>>> them to the examples?
>>>
>>> cheers
>>> stuart
>>>
>>
>
>


From bansp at o2.pl  Mon Jul  2 09:21:43 2012
From: bansp at o2.pl (Piotr Banski)
Date: Mon, 02 Jul 2012 15:21:43 +0200
Subject: [tei-council] CH and BCP 47 again
In-Reply-To: <4FF1989A.9030308@ultraslavonic.info>
References: <4FE9E0A9.4090302@uvic.ca> <4FE9ED24.90907@ultraslavonic.info>
	<4FEA0DC0.1030205@uvic.ca>
	<CAC_Lu0ZzE6eEF8rJGGaeGhnsuTzS+CRbaM6PxTvQfDBHHR9WRQ@mail.gmail.com>
	<4FEA6AD7.1090102@ultraslavonic.info> <4FF19465.3030908@o2.pl>
	<4FF1989A.9030308@ultraslavonic.info>
Message-ID: <4FF1A067.9040508@o2.pl>

My point is that this is what we are actually led to recommend for 
real-life encoding, if that is to be machine-readable in the absence of 
any extra mechanisms.

And further, that if we are indeed recommending this, then that should 
be recorded in the Guidelines.

And next, that if we choose not to recommend using @xml:lang in such 
cases, we should probably indicate that in the Guidelines, as a 
"feature" of our encoding proposals.

I fully agree with you that this means massive redundancy, I'm just 
saying that I can't see a way to avoid that, given our recommendations.

We might always say that for many/most projects, this can be handled at 
the level of the ODD, and only those projects which can't use ODD for 
that have to resort to massive redundancy straight inside XML instances.

Best,

   P.

On 02/07/12 14:48, Kevin Hawkins wrote:
>
>
> On 7/2/12 8:30 AM, Piotr Banski wrote:
>> By this logic, we shouldn't bother to insert xml:langs in bilingual
>> dictionaries. I'd have no problem with a uniform declaration that <pron>
>> in that very dictionary is always to be interpreted as this-and-that
>> script, and that <quote> inside <cit @type="translation"> is to be
>> interpreted so-and-so.
>
> That's all that I was implying!  I didn't mean to say that there is any
> sort of global mechanism.
>
> My point was that these examples are supposed to look like someone's
> real-life encoding.  And in real-life encoding, you're unlikely to add
> @xml:lang to every <pron> (or to <quote> inside <cit
> @type="translation">) in a single bilingual dictionary.
>
>> On 27/06/12 04:07, Kevin Hawkins wrote:
>>> There is no particular exception to use of @xml:lang on <pron> that I am
>>> aware of.  As a global attribute, @xml:lang may be used on any element
>>> but need not be used anywhere.
>>>
>>> I am inclined not to bother inserting @xml:lang on these examples.  If
>>> you encode a dictionary, every <pron> will likely use the same script as
>>> every other <pron>, and this will be the only part of the dictionary
>>> using this script (whatever it is).  I can't imagine a use case for
>>> recording on individual <pron>s.
>>>
>>> --K.
>>>
>>> On 6/26/12 5:14 PM, Stuart A. Yeates wrote:
>>>> On a related note (and not covered in CH or BCP 47 as far as I can tell):
>>>>
>>>> Almost all the <pron/> examples in
>>>> http://www.tei-c.org/release/doc/tei-p5-doc/en/html/examples-pron.html
>>>> use a different script to the surrounding text, but none of them have
>>>> an xml:lang attribute describing that.
>>>>
>>>> Does <pron/> have an exception from xml:lang, or do we need to add
>>>> them to the examples?
>>>>
>>>> cheers
>>>> stuart
>>>>
>>>
>>
>>
>



From kevin.s.hawkins at ultraslavonic.info  Tue Jul  3 01:34:13 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Tue, 03 Jul 2012 01:34:13 -0400
Subject: [tei-council] CH and BCP 47 again
In-Reply-To: <4FF1A067.9040508@o2.pl>
References: <4FE9E0A9.4090302@uvic.ca> <4FE9ED24.90907@ultraslavonic.info>
	<4FEA0DC0.1030205@uvic.ca>
	<CAC_Lu0ZzE6eEF8rJGGaeGhnsuTzS+CRbaM6PxTvQfDBHHR9WRQ@mail.gmail.com>
	<4FEA6AD7.1090102@ultraslavonic.info> <4FF19465.3030908@o2.pl>
	<4FF1989A.9030308@ultraslavonic.info> <4FF1A067.9040508@o2.pl>
Message-ID: <4FF28455.8070406@ultraslavonic.info>

Okay, I see what Piotr is saying now.

Such advice -- add elements and attributes to mark up only those 
features of a text that are useful for processing, not everything you 
can identify -- is a sort of high-level recommendation that applies not 
just to dictionaries.  Maybe we should add a sentence or two to

http://www.tei-c.org/release/doc/tei-p5-doc/en/html/AB.html#ABAPP

?

By the way, who maintains the XSLT/CSS to generate HTML of the 
Guidelines?  I just noticed that "Intended Use" and "Use in Text Capture 
and Text Creation" are showing up in the same font size even though the 
latter is a lower-level heading.

On 7/2/12 9:21 AM, Piotr Banski wrote:
> My point is that this is what we are actually led to recommend for
> real-life encoding, if that is to be machine-readable in the absence of
> any extra mechanisms.
>
> And further, that if we are indeed recommending this, then that should
> be recorded in the Guidelines.
>
> And next, that if we choose not to recommend using @xml:lang in such
> cases, we should probably indicate that in the Guidelines, as a
> "feature" of our encoding proposals.
>
> I fully agree with you that this means massive redundancy, I'm just
> saying that I can't see a way to avoid that, given our recommendations.
>
> We might always say that for many/most projects, this can be handled at
> the level of the ODD, and only those projects which can't use ODD for
> that have to resort to massive redundancy straight inside XML instances.
>
> Best,
>
>     P.
>
> On 02/07/12 14:48, Kevin Hawkins wrote:
>>
>>
>> On 7/2/12 8:30 AM, Piotr Banski wrote:
>>> By this logic, we shouldn't bother to insert xml:langs in bilingual
>>> dictionaries. I'd have no problem with a uniform declaration that <pron>
>>> in that very dictionary is always to be interpreted as this-and-that
>>> script, and that <quote> inside <cit @type="translation"> is to be
>>> interpreted so-and-so.
>>
>> That's all that I was implying!  I didn't mean to say that there is any
>> sort of global mechanism.
>>
>> My point was that these examples are supposed to look like someone's
>> real-life encoding.  And in real-life encoding, you're unlikely to add
>> @xml:lang to every <pron> (or to <quote> inside <cit
>> @type="translation">) in a single bilingual dictionary.
>>
>>> On 27/06/12 04:07, Kevin Hawkins wrote:
>>>> There is no particular exception to use of @xml:lang on <pron> that I am
>>>> aware of.  As a global attribute, @xml:lang may be used on any element
>>>> but need not be used anywhere.
>>>>
>>>> I am inclined not to bother inserting @xml:lang on these examples.  If
>>>> you encode a dictionary, every <pron> will likely use the same script as
>>>> every other <pron>, and this will be the only part of the dictionary
>>>> using this script (whatever it is).  I can't imagine a use case for
>>>> recording on individual <pron>s.
>>>>
>>>> --K.
>>>>
>>>> On 6/26/12 5:14 PM, Stuart A. Yeates wrote:
>>>>> On a related note (and not covered in CH or BCP 47 as far as I can tell):
>>>>>
>>>>> Almost all the <pron/> examples in
>>>>> http://www.tei-c.org/release/doc/tei-p5-doc/en/html/examples-pron.html
>>>>> use a different script to the surrounding text, but none of them have
>>>>> an xml:lang attribute describing that.
>>>>>
>>>>> Does <pron/> have an exception from xml:lang, or do we need to add
>>>>> them to the examples?
>>>>>
>>>>> cheers
>>>>> stuart
>>>>>
>>>>
>>>
>>>
>>
>
>


From sebastian.rahtz at oucs.ox.ac.uk  Tue Jul  3 03:51:32 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Tue, 3 Jul 2012 07:51:32 +0000
Subject: [tei-council] CH and BCP 47 again
In-Reply-To: <4FF28455.8070406@ultraslavonic.info>
References: <4FE9E0A9.4090302@uvic.ca> <4FE9ED24.90907@ultraslavonic.info>
	<4FEA0DC0.1030205@uvic.ca>
	<CAC_Lu0ZzE6eEF8rJGGaeGhnsuTzS+CRbaM6PxTvQfDBHHR9WRQ@mail.gmail.com>
	<4FEA6AD7.1090102@ultraslavonic.info> <4FF19465.3030908@o2.pl>
	<4FF1989A.9030308@ultraslavonic.info> <4FF1A067.9040508@o2.pl>
	<4FF28455.8070406@ultraslavonic.info>
Message-ID: <0180A445-70BA-4C1A-904F-811CC3E0354A@oucs.ox.ac.uk>


On 3 Jul 2012, at 06:34, Kevin Hawkins wrote:

> 
> By the way, who maintains the XSLT/CSS to generate HTML of the 
> Guidelines?

we all are.  P5/guidelines.css is your friend

>  I just noticed that "Intended Use" and "Use in Text Capture 
> and Text Creation" are showing up in the same font size even though the 
> latter is a lower-level heading.


its true. h4, h5 and h6 are all font-size: 100%

who fancies themselves as designer to look at this?
--
Sebastian Rahtz      
Head of Information and Support Group
Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431







From mholmes at uvic.ca  Tue Jul  3 11:28:39 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Tue, 3 Jul 2012 08:28:39 -0700
Subject: [tei-council] Sourceforge retiring Hosted Apps
Message-ID: <4FF30FA7.7020607@uvic.ca>

Hi all,

I got a warning from SF this morning, which I guess everyone else will 
also have got, about the retirement of Hosted Apps:

<http://sourceforge.net/blog/hosted-apps-retirement/>

For TEI, I guess this means that WordPress will be going away. I don't 
think we use any other Hosted Apps, do we? I see that LimeSurvey, 
MediaWiki and Trac are all enabled in our SF profile, but the only one I 
recall using was WordPress, for making some kind of announcement during 
the process of a release.

Do we still really need this functionality, or can we let all the Hosted 
Apps die a natural death?

Cheers,
Martin
-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)


From dsewell at virginia.edu  Tue Jul  3 11:46:00 2012
From: dsewell at virginia.edu (David Sewell)
Date: Tue, 3 Jul 2012 11:46:00 -0400 (EDT)
Subject: [tei-council] Sourceforge retiring Hosted Apps
In-Reply-To: <4FF30FA7.7020607@uvic.ca>
References: <4FF30FA7.7020607@uvic.ca>
Message-ID: <alpine.OSX.2.00.1207031132230.45167@lister.ei.virginia.edu>

This is not good news. We have been relying on the SourceForge Wordpress blog to 
feed the newsfeed used on the home page of tei-c.org. It's a clunky mechanism, 
but it's what we have at the moment.

In principle, it shouldn't be difficult to migrate the WordPress content to a 
different platform and continue that procedure, only it would mean (1) coming up 
with an appropriate host, (2) doing the migration, (3) creating new WordPress 
user accounts with appropriate permissions, (4) rewriting James's newsfeed 
grabbing code to use the new site. It doesn't help matters that the SF WordPress 
area (http://sourceforge.net/apps/wordpress/tei/) has been offline more often 
than not lately.

It might almost be simpler to go back to hand-editing the page at 
http://www.tei-c.org/News/ (via OpenCMS), and then making the home-page sidebar 
static and updating links there manually.

David

On Tue, 3 Jul 2012, Martin Holmes wrote:

> Hi all,
>
> I got a warning from SF this morning, which I guess everyone else will
> also have got, about the retirement of Hosted Apps:
>
> <http://sourceforge.net/blog/hosted-apps-retirement/>
>
> For TEI, I guess this means that WordPress will be going away. I don't
> think we use any other Hosted Apps, do we? I see that LimeSurvey,
> MediaWiki and Trac are all enabled in our SF profile, but the only one I
> recall using was WordPress, for making some kind of announcement during
> the process of a release.
>
> Do we still really need this functionality, or can we let all the Hosted
> Apps die a natural death?
>
> Cheers,
> Martin
>

-- 
David Sewell, Editorial and Technical Manager
ROTUNDA, The University of Virginia Press
PO Box 400314, Charlottesville, VA 22904-4314 USA
Email: dsewell at virginia.edu   Tel: +1 434 924 9973
Web: http://rotunda.upress.virginia.edu/

From james.cummings at oucs.ox.ac.uk  Tue Jul  3 11:48:39 2012
From: james.cummings at oucs.ox.ac.uk (James Cummings)
Date: Tue, 3 Jul 2012 15:48:39 +0000
Subject: [tei-council] Sourceforge retiring Hosted Apps
In-Reply-To: <4FF30FA7.7020607@uvic.ca>
References: <4FF30FA7.7020607@uvic.ca>
Message-ID: <2lsgtvbqwh5cnijejqlhc4u3.1341330484177@email.android.com>


We will need a replacement for wordpress as that is what powers our Newsfeed. Maybe Virginia could be talked into hosting it as part of the website.

Jamesc
--
James Cummings, InfoDev, OUCS, University of Oxford (from phone)

Martin Holmes <mholmes at uvic.ca> wrote:


Hi all,

I got a warning from SF this morning, which I guess everyone else will
also have got, about the retirement of Hosted Apps:

<http://sourceforge.net/blog/hosted-apps-retirement/>

For TEI, I guess this means that WordPress will be going away. I don't
think we use any other Hosted Apps, do we? I see that LimeSurvey,
MediaWiki and Trac are all enabled in our SF profile, but the only one I
recall using was WordPress, for making some kind of announcement during
the process of a release.

Do we still really need this functionality, or can we let all the Hosted
Apps die a natural death?

Cheers,
Martin
--
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

--
tei-council mailing list
tei-council at lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

PLEASE NOTE: postings to this list are publicly archived

From james.cummings at oucs.ox.ac.uk  Tue Jul  3 11:50:29 2012
From: james.cummings at oucs.ox.ac.uk (James Cummings)
Date: Tue, 3 Jul 2012 15:50:29 +0000
Subject: [tei-council] Sourceforge retiring Hosted Apps
In-Reply-To: <alpine.OSX.2.00.1207031132230.45167@lister.ei.virginia.edu>
References: <4FF30FA7.7020607@uvic.ca>,
	<alpine.OSX.2.00.1207031132230.45167@lister.ei.virginia.edu>
Message-ID: <novv5cpd8gi8wwtcvbv9lres.1341330594418@email.android.com>


David,

If Virginia didn't want to host it, we could also use wordpress.com

Jamesc
--
James Cummings, InfoDev, OUCS, University of Oxford (from phone)

David Sewell <dsewell at virginia.edu> wrote:


This is not good news. We have been relying on the SourceForge Wordpress blog to
feed the newsfeed used on the home page of tei-c.org. It's a clunky mechanism,
but it's what we have at the moment.

In principle, it shouldn't be difficult to migrate the WordPress content to a
different platform and continue that procedure, only it would mean (1) coming up
with an appropriate host, (2) doing the migration, (3) creating new WordPress
user accounts with appropriate permissions, (4) rewriting James's newsfeed
grabbing code to use the new site. It doesn't help matters that the SF WordPress
area (http://sourceforge.net/apps/wordpress/tei/) has been offline more often
than not lately.

It might almost be simpler to go back to hand-editing the page at
http://www.tei-c.org/News/ (via OpenCMS), and then making the home-page sidebar
static and updating links there manually.

David

On Tue, 3 Jul 2012, Martin Holmes wrote:

> Hi all,
>
> I got a warning from SF this morning, which I guess everyone else will
> also have got, about the retirement of Hosted Apps:
>
> <http://sourceforge.net/blog/hosted-apps-retirement/>
>
> For TEI, I guess this means that WordPress will be going away. I don't
> think we use any other Hosted Apps, do we? I see that LimeSurvey,
> MediaWiki and Trac are all enabled in our SF profile, but the only one I
> recall using was WordPress, for making some kind of announcement during
> the process of a release.
>
> Do we still really need this functionality, or can we let all the Hosted
> Apps die a natural death?
>
> Cheers,
> Martin
>

--
David Sewell, Editorial and Technical Manager
ROTUNDA, The University of Virginia Press
PO Box 400314, Charlottesville, VA 22904-4314 USA
Email: dsewell at virginia.edu   Tel: +1 434 924 9973
Web: http://rotunda.upress.virginia.edu/
--
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 Jul  3 11:52:42 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Tue, 3 Jul 2012 15:52:42 +0000
Subject: [tei-council] Sourceforge retiring Hosted Apps
In-Reply-To: <4FF30FA7.7020607@uvic.ca>
References: <4FF30FA7.7020607@uvic.ca>
Message-ID: <034D1A8A-F366-4DF8-B4FD-10D214EADE23@oucs.ox.ac.uk>

i reckoned we're ok when I reead that. we don't need their apps for anything critical, it think
--
Sebastian Rahtz      
Head of Information and Support Group
Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431







From mholmes at uvic.ca  Tue Jul  3 11:59:27 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Tue, 3 Jul 2012 08:59:27 -0700
Subject: [tei-council] Sourceforge retiring Hosted Apps
In-Reply-To: <2lsgtvbqwh5cnijejqlhc4u3.1341330484177@email.android.com>
References: <4FF30FA7.7020607@uvic.ca>
	<2lsgtvbqwh5cnijejqlhc4u3.1341330484177@email.android.com>
Message-ID: <4FF316DF.1020705@uvic.ca>

If all we're doing with WordPress is creating a newsfeed, couldn't we 
just create an RSS document which we update manually? RSS isn't that 
complicated.

Cheers,
Martin

On 12-07-03 08:48 AM, James Cummings wrote:
>
> We will need a replacement for wordpress as that is what powers our Newsfeed. Maybe Virginia could be talked into hosting it as part of the website.
>
> Jamesc
> --
> James Cummings, InfoDev, OUCS, University of Oxford (from phone)
>
> Martin Holmes <mholmes at uvic.ca> wrote:
>
>
> Hi all,
>
> I got a warning from SF this morning, which I guess everyone else will
> also have got, about the retirement of Hosted Apps:
>
> <http://sourceforge.net/blog/hosted-apps-retirement/>
>
> For TEI, I guess this means that WordPress will be going away. I don't
> think we use any other Hosted Apps, do we? I see that LimeSurvey,
> MediaWiki and Trac are all enabled in our SF profile, but the only one I
> recall using was WordPress, for making some kind of announcement during
> the process of a release.
>
> Do we still really need this functionality, or can we let all the Hosted
> Apps die a natural death?
>
> Cheers,
> Martin
> --
> Martin Holmes
> University of Victoria Humanities Computing and Media Centre
> (mholmes at uvic.ca)
>
> --
> tei-council mailing list
> tei-council at lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>
> PLEASE NOTE: postings to this list are publicly archived
> .
>

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)



From gabriel.bodard at kcl.ac.uk  Tue Jul  3 12:00:59 2012
From: gabriel.bodard at kcl.ac.uk (Gabriel Bodard)
Date: Tue, 3 Jul 2012 17:00:59 +0100
Subject: [tei-council] Sourceforge retiring Hosted Apps
In-Reply-To: <4FF316DF.1020705@uvic.ca>
References: <4FF30FA7.7020607@uvic.ca>
	<2lsgtvbqwh5cnijejqlhc4u3.1341330484177@email.android.com>
	<4FF316DF.1020705@uvic.ca>
Message-ID: <4FF3173B.90807@kcl.ac.uk>

There must be a TEI-to-RSS stylesheet somewhere, mustn't there? (Or if 
there isn't there should be...)

On 2012-07-03 16:59, Martin Holmes wrote:
> If all we're doing with WordPress is creating a newsfeed, couldn't we
> just create an RSS document which we update manually? RSS isn't that
> complicated.
>
> Cheers,
> Martin
>
> On 12-07-03 08:48 AM, James Cummings wrote:
>>
>> We will need a replacement for wordpress as that is what powers our Newsfeed. Maybe Virginia could be talked into hosting it as part of the website.
>>
>> Jamesc
>> --
>> James Cummings, InfoDev, OUCS, University of Oxford (from phone)
>>
>> Martin Holmes <mholmes at uvic.ca> wrote:
>>
>>
>> Hi all,
>>
>> I got a warning from SF this morning, which I guess everyone else will
>> also have got, about the retirement of Hosted Apps:
>>
>> <http://sourceforge.net/blog/hosted-apps-retirement/>
>>
>> For TEI, I guess this means that WordPress will be going away. I don't
>> think we use any other Hosted Apps, do we? I see that LimeSurvey,
>> MediaWiki and Trac are all enabled in our SF profile, but the only one I
>> recall using was WordPress, for making some kind of announcement during
>> the process of a release.
>>
>> Do we still really need this functionality, or can we let all the Hosted
>> Apps die a natural death?
>>
>> Cheers,
>> Martin
>> --
>> Martin Holmes
>> University of Victoria Humanities Computing and Media Centre
>> (mholmes at uvic.ca)
>>
>> --
>> tei-council mailing list
>> tei-council at lists.village.Virginia.EDU
>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>>
>> PLEASE NOTE: postings to this list are publicly archived
>> .
>>
>

-- 
Dr Gabriel BODARD
(Research Associate in Digital Epigraphy)

Department of Digital Humanities
King's College London
26-29 Drury Lane
London WC2B 5RL

Email: gabriel.bodard at kcl.ac.uk
Tel: +44 (0)20 7848 1388
Fax: +44 (0)20 7848 2980

http://www.digitalclassicist.org/
http://www.currentepigraphy.org/



From sebastian.rahtz at oucs.ox.ac.uk  Tue Jul  3 12:09:24 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Tue, 3 Jul 2012 16:09:24 +0000
Subject: [tei-council] Sourceforge retiring Hosted Apps
In-Reply-To: <2lsgtvbqwh5cnijejqlhc4u3.1341330484177@email.android.com>
References: <4FF30FA7.7020607@uvic.ca>
	<2lsgtvbqwh5cnijejqlhc4u3.1341330484177@email.android.com>
Message-ID: <f2b435de-bd7b-40f7-8824-526d2dc7caad@HUB03.ad.oak.ox.ac.uk>

shows how much i know, I completely forgot the WP thing :-{

why not just get a free one from wordpress.com?
--
Sebastian Rahtz      
Head of Information and Support Group
Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431







From james.cummings at oucs.ox.ac.uk  Tue Jul  3 12:10:09 2012
From: james.cummings at oucs.ox.ac.uk (James Cummings)
Date: Tue, 3 Jul 2012 16:10:09 +0000
Subject: [tei-council] Sourceforge retiring Hosted Apps
In-Reply-To: <4FF316DF.1020705@uvic.ca>
References: <4FF30FA7.7020607@uvic.ca>
	<2lsgtvbqwh5cnijejqlhc4u3.1341330484177@email.android.com>,
	<4FF316DF.1020705@uvic.ca>
Message-ID: <ydc9kb743rjld8w550hygjlj.1341331774291@email.android.com>


If you were handling the newsfeed ... fine. But I think our volunteers would prefer a blog interface to paste into.  We can use wordpress.com

Jamesc

Jamesc
--
James Cummings, InfoDev, OUCS, University of Oxford (from phone)

Martin Holmes <mholmes at uvic.ca> wrote:


If all we're doing with WordPress is creating a newsfeed, couldn't we
just create an RSS document which we update manually? RSS isn't that
complicated.

Cheers,
Martin

On 12-07-03 08:48 AM, James Cummings wrote:
>
> We will need a replacement for wordpress as that is what powers our Newsfeed. Maybe Virginia could be talked into hosting it as part of the website.
>
> Jamesc
> --
> James Cummings, InfoDev, OUCS, University of Oxford (from phone)
>
> Martin Holmes <mholmes at uvic.ca> wrote:
>
>
> Hi all,
>
> I got a warning from SF this morning, which I guess everyone else will
> also have got, about the retirement of Hosted Apps:
>
> <http://sourceforge.net/blog/hosted-apps-retirement/>
>
> For TEI, I guess this means that WordPress will be going away. I don't
> think we use any other Hosted Apps, do we? I see that LimeSurvey,
> MediaWiki and Trac are all enabled in our SF profile, but the only one I
> recall using was WordPress, for making some kind of announcement during
> the process of a release.
>
> Do we still really need this functionality, or can we let all the Hosted
> Apps die a natural death?
>
> Cheers,
> Martin
> --
> Martin Holmes
> University of Victoria Humanities Computing and Media Centre
> (mholmes at uvic.ca)
>
> --
> tei-council mailing list
> tei-council at lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>
> PLEASE NOTE: postings to this list are publicly archived
> .
>

--
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)



From sebastian.rahtz at oucs.ox.ac.uk  Tue Jul  3 12:11:33 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Tue, 3 Jul 2012 16:11:33 +0000
Subject: [tei-council] Sourceforge retiring Hosted Apps
In-Reply-To: <ydc9kb743rjld8w550hygjlj.1341331774291@email.android.com>
References: <4FF30FA7.7020607@uvic.ca>
	<2lsgtvbqwh5cnijejqlhc4u3.1341330484177@email.android.com>,
	<4FF316DF.1020705@uvic.ca>
	<ydc9kb743rjld8w550hygjlj.1341331774291@email.android.com>
Message-ID: <e1251fe6-3eb2-41b5-bfba-46ccfec39dba@HUB01.ad.oak.ox.ac.uk>

I am very nerdy, but even I wouldn't write RSS by hand....
--
Sebastian Rahtz      
Head of Information and Support Group
Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431







From james.cummings at oucs.ox.ac.uk  Tue Jul  3 12:12:23 2012
From: james.cummings at oucs.ox.ac.uk (James Cummings)
Date: Tue, 3 Jul 2012 16:12:23 +0000
Subject: [tei-council] Sourceforge retiring Hosted Apps
In-Reply-To: <4FF3173B.90807@kcl.ac.uk>
References: <4FF30FA7.7020607@uvic.ca>
	<2lsgtvbqwh5cnijejqlhc4u3.1341330484177@email.android.com>
	<4FF316DF.1020705@uvic.ca>,<4FF3173B.90807@kcl.ac.uk>
Message-ID: <5lai3ruwo19tvj15uqtmgjy5.1341331908743@email.android.com>

Yes... but adds another barrier for our volunteers.

Jamesc
--
James Cummings, InfoDev, OUCS, University of Oxford (from phone)

Gabriel Bodard <gabriel.bodard at kcl.ac.uk> wrote:


There must be a TEI-to-RSS stylesheet somewhere, mustn't there? (Or if
there isn't there should be...)

On 2012-07-03 16:59, Martin Holmes wrote:
> If all we're doing with WordPress is creating a newsfeed, couldn't we
> just create an RSS document which we update manually? RSS isn't that
> complicated.
>
> Cheers,
> Martin
>
> On 12-07-03 08:48 AM, James Cummings wrote:
>>
>> We will need a replacement for wordpress as that is what powers our Newsfeed. Maybe Virginia could be talked into hosting it as part of the website.
>>
>> Jamesc
>> --
>> James Cummings, InfoDev, OUCS, University of Oxford (from phone)
>>
>> Martin Holmes <mholmes at uvic.ca> wrote:
>>
>>
>> Hi all,
>>
>> I got a warning from SF this morning, which I guess everyone else will
>> also have got, about the retirement of Hosted Apps:
>>
>> <http://sourceforge.net/blog/hosted-apps-retirement/>
>>
>> For TEI, I guess this means that WordPress will be going away. I don't
>> think we use any other Hosted Apps, do we? I see that LimeSurvey,
>> MediaWiki and Trac are all enabled in our SF profile, but the only one I
>> recall using was WordPress, for making some kind of announcement during
>> the process of a release.
>>
>> Do we still really need this functionality, or can we let all the Hosted
>> Apps die a natural death?
>>
>> Cheers,
>> Martin
>> --
>> Martin Holmes
>> University of Victoria Humanities Computing and Media Centre
>> (mholmes at uvic.ca)
>>
>> --
>> tei-council mailing list
>> tei-council at lists.village.Virginia.EDU
>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>>
>> PLEASE NOTE: postings to this list are publicly archived
>> .
>>
>

--
Dr Gabriel BODARD
(Research Associate in Digital Epigraphy)

Department of Digital Humanities
King's College London
26-29 Drury Lane
London WC2B 5RL

Email: gabriel.bodard at kcl.ac.uk
Tel: +44 (0)20 7848 1388
Fax: +44 (0)20 7848 2980

http://www.digitalclassicist.org/
http://www.currentepigraphy.org/


--
tei-council mailing list
tei-council at lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

PLEASE NOTE: postings to this list are publicly archived

From mholmes at uvic.ca  Tue Jul  3 12:19:29 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Tue, 3 Jul 2012 09:19:29 -0700
Subject: [tei-council] Sourceforge retiring Hosted Apps
In-Reply-To: <5lai3ruwo19tvj15uqtmgjy5.1341331908743@email.android.com>
References: <4FF30FA7.7020607@uvic.ca>
	<2lsgtvbqwh5cnijejqlhc4u3.1341330484177@email.android.com>
	<4FF316DF.1020705@uvic.ca>, <4FF3173B.90807@kcl.ac.uk>
	<5lai3ruwo19tvj15uqtmgjy5.1341331908743@email.android.com>
Message-ID: <4FF31B91.9060502@uvic.ca>

What volunteers are these? I didn't know anyone except Council did this 
stuff.

Incidentally, judging by the home page, that stage in the release 
process got missed out:

<http://www.tei-c.org/index.xml>

I don't see any news of release 2.1 there. And WordPress on SF seems to 
be down at the moment, as well.

Cheers,
Martin

On 12-07-03 09:12 AM, James Cummings wrote:
> Yes... but adds another barrier for our volunteers.
>
> Jamesc
> --
> James Cummings, InfoDev, OUCS, University of Oxford (from phone)
>
> Gabriel Bodard <gabriel.bodard at kcl.ac.uk> wrote:
>
>
> There must be a TEI-to-RSS stylesheet somewhere, mustn't there? (Or if
> there isn't there should be...)
>
> On 2012-07-03 16:59, Martin Holmes wrote:
>> If all we're doing with WordPress is creating a newsfeed, couldn't we
>> just create an RSS document which we update manually? RSS isn't that
>> complicated.
>>
>> Cheers,
>> Martin
>>
>> On 12-07-03 08:48 AM, James Cummings wrote:
>>>
>>> We will need a replacement for wordpress as that is what powers our Newsfeed. Maybe Virginia could be talked into hosting it as part of the website.
>>>
>>> Jamesc
>>> --
>>> James Cummings, InfoDev, OUCS, University of Oxford (from phone)
>>>
>>> Martin Holmes <mholmes at uvic.ca> wrote:
>>>
>>>
>>> Hi all,
>>>
>>> I got a warning from SF this morning, which I guess everyone else will
>>> also have got, about the retirement of Hosted Apps:
>>>
>>> <http://sourceforge.net/blog/hosted-apps-retirement/>
>>>
>>> For TEI, I guess this means that WordPress will be going away. I don't
>>> think we use any other Hosted Apps, do we? I see that LimeSurvey,
>>> MediaWiki and Trac are all enabled in our SF profile, but the only one I
>>> recall using was WordPress, for making some kind of announcement during
>>> the process of a release.
>>>
>>> Do we still really need this functionality, or can we let all the Hosted
>>> Apps die a natural death?
>>>
>>> Cheers,
>>> Martin
>>> --
>>> Martin Holmes
>>> University of Victoria Humanities Computing and Media Centre
>>> (mholmes at uvic.ca)
>>>
>>> --
>>> tei-council mailing list
>>> tei-council at lists.village.Virginia.EDU
>>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>>>
>>> PLEASE NOTE: postings to this list are publicly archived
>>> .
>>>
>>
>
> --
> Dr Gabriel BODARD
> (Research Associate in Digital Epigraphy)
>
> Department of Digital Humanities
> King's College London
> 26-29 Drury Lane
> London WC2B 5RL
>
> Email: gabriel.bodard at kcl.ac.uk
> Tel: +44 (0)20 7848 1388
> Fax: +44 (0)20 7848 2980
>
> http://www.digitalclassicist.org/
> http://www.currentepigraphy.org/
>
>
> --
> tei-council mailing list
> tei-council at lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>
> PLEASE NOTE: postings to this list are publicly archived
>

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)



From dsewell at virginia.edu  Tue Jul  3 13:44:34 2012
From: dsewell at virginia.edu (David Sewell)
Date: Tue, 3 Jul 2012 13:44:34 -0400 (EDT)
Subject: [tei-council] Sourceforge retiring Hosted Apps
In-Reply-To: <4FF31B91.9060502@uvic.ca>
References: <4FF30FA7.7020607@uvic.ca>
	<2lsgtvbqwh5cnijejqlhc4u3.1341330484177@email.android.com>
	<4FF316DF.1020705@uvic.ca>, <4FF3173B.90807@kcl.ac.uk>
	<5lai3ruwo19tvj15uqtmgjy5.1341331908743@email.android.com>
	<4FF31B91.9060502@uvic.ca>
Message-ID: <alpine.OSX.2.00.1207031343140.47849@lister.ei.virginia.edu>

On Tue, 3 Jul 2012, Martin Holmes wrote:

> What volunteers are these? I didn't know anyone except Council did this
> stuff.
>
> Incidentally, judging by the home page, that stage in the release
> process got missed out:
>
> <http://www.tei-c.org/index.xml>
>
> I don't see any news of release 2.1 there. And WordPress on SF seems to
> be down at the moment, as well.

That is effect and cause, I believe.

I have wanted to post news items a couple of times in the recent past but 
couldn't get into the Sourceforge WordPress instance. I don't blame SF for 
phasing out their hosted apps but it is a nuisance to have them not working at 
all prior to the ability to back up contents.


> Cheers,
> Martin
>
> On 12-07-03 09:12 AM, James Cummings wrote:
>> Yes... but adds another barrier for our volunteers.
>>
>> Jamesc
>> --
>> James Cummings, InfoDev, OUCS, University of Oxford (from phone)
>>
>> Gabriel Bodard <gabriel.bodard at kcl.ac.uk> wrote:
>>
>>
>> There must be a TEI-to-RSS stylesheet somewhere, mustn't there? (Or if
>> there isn't there should be...)
>>
>> On 2012-07-03 16:59, Martin Holmes wrote:
>>> If all we're doing with WordPress is creating a newsfeed, couldn't we
>>> just create an RSS document which we update manually? RSS isn't that
>>> complicated.
>>>
>>> Cheers,
>>> Martin
>>>
>>> On 12-07-03 08:48 AM, James Cummings wrote:
>>>>
>>>> We will need a replacement for wordpress as that is what powers our Newsfeed. Maybe Virginia could be talked into hosting it as part of the website.
>>>>
>>>> Jamesc
>>>> --
>>>> James Cummings, InfoDev, OUCS, University of Oxford (from phone)
>>>>
>>>> Martin Holmes <mholmes at uvic.ca> wrote:
>>>>
>>>>
>>>> Hi all,
>>>>
>>>> I got a warning from SF this morning, which I guess everyone else will
>>>> also have got, about the retirement of Hosted Apps:
>>>>
>>>> <http://sourceforge.net/blog/hosted-apps-retirement/>
>>>>
>>>> For TEI, I guess this means that WordPress will be going away. I don't
>>>> think we use any other Hosted Apps, do we? I see that LimeSurvey,
>>>> MediaWiki and Trac are all enabled in our SF profile, but the only one I
>>>> recall using was WordPress, for making some kind of announcement during
>>>> the process of a release.
>>>>
>>>> Do we still really need this functionality, or can we let all the Hosted
>>>> Apps die a natural death?
>>>>
>>>> Cheers,
>>>> Martin
>>>> --
>>>> Martin Holmes
>>>> University of Victoria Humanities Computing and Media Centre
>>>> (mholmes at uvic.ca)
>>>>
>>>> --
>>>> tei-council mailing list
>>>> tei-council at lists.village.Virginia.EDU
>>>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>>>>
>>>> PLEASE NOTE: postings to this list are publicly archived
>>>> .
>>>>
>>>
>>
>> --
>> Dr Gabriel BODARD
>> (Research Associate in Digital Epigraphy)
>>
>> Department of Digital Humanities
>> King's College London
>> 26-29 Drury Lane
>> London WC2B 5RL
>>
>> Email: gabriel.bodard at kcl.ac.uk
>> Tel: +44 (0)20 7848 1388
>> Fax: +44 (0)20 7848 2980
>>
>> http://www.digitalclassicist.org/
>> http://www.currentepigraphy.org/
>>
>>
>> --
>> tei-council mailing list
>> tei-council at lists.village.Virginia.EDU
>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>>
>> PLEASE NOTE: postings to this list are publicly archived
>>
>
>

-- 
David Sewell, Editorial and Technical Manager
ROTUNDA, The University of Virginia Press
PO Box 400314, Charlottesville, VA 22904-4314 USA
Email: dsewell at virginia.edu   Tel: +1 434 924 9973
Web: http://rotunda.upress.virginia.edu/

From james.cummings at oucs.ox.ac.uk  Tue Jul  3 13:48:55 2012
From: james.cummings at oucs.ox.ac.uk (James Cummings)
Date: Tue, 3 Jul 2012 17:48:55 +0000
Subject: [tei-council] Sourceforge retiring Hosted Apps
In-Reply-To: <alpine.OSX.2.00.1207031343140.47849@lister.ei.virginia.edu>
References: <4FF30FA7.7020607@uvic.ca>
	<2lsgtvbqwh5cnijejqlhc4u3.1341330484177@email.android.com>
	<4FF316DF.1020705@uvic.ca>, <4FF3173B.90807@kcl.ac.uk>
	<5lai3ruwo19tvj15uqtmgjy5.1341331908743@email.android.com>
	<4FF31B91.9060502@uvic.ca>,
	<alpine.OSX.2.00.1207031343140.47849@lister.ei.virginia.edu>
Message-ID: <dv2odmdp7c7p8aj5y3w9t4bb.1341337696227@email.android.com>


We have the atom feed so all is backed up. Don't know how to import that into wordpress.com

Jamesc We
--
James Cummings, InfoDev, OUCS, University of Oxford (from phone)

David Sewell <dsewell at virginia.edu> wrote:


On Tue, 3 Jul 2012, Martin Holmes wrote:

> What volunteers are these? I didn't know anyone except Council did this
> stuff.
>
> Incidentally, judging by the home page, that stage in the release
> process got missed out:
>
> <http://www.tei-c.org/index.xml>
>
> I don't see any news of release 2.1 there. And WordPress on SF seems to
> be down at the moment, as well.

That is effect and cause, I believe.

I have wanted to post news items a couple of times in the recent past but
couldn't get into the Sourceforge WordPress instance. I don't blame SF for
phasing out their hosted apps but it is a nuisance to have them not working at
all prior to the ability to back up contents.


> Cheers,
> Martin
>
> On 12-07-03 09:12 AM, James Cummings wrote:
>> Yes... but adds another barrier for our volunteers.
>>
>> Jamesc
>> --
>> James Cummings, InfoDev, OUCS, University of Oxford (from phone)
>>
>> Gabriel Bodard <gabriel.bodard at kcl.ac.uk> wrote:
>>
>>
>> There must be a TEI-to-RSS stylesheet somewhere, mustn't there? (Or if
>> there isn't there should be...)
>>
>> On 2012-07-03 16:59, Martin Holmes wrote:
>>> If all we're doing with WordPress is creating a newsfeed, couldn't we
>>> just create an RSS document which we update manually? RSS isn't that
>>> complicated.
>>>
>>> Cheers,
>>> Martin
>>>
>>> On 12-07-03 08:48 AM, James Cummings wrote:
>>>>
>>>> We will need a replacement for wordpress as that is what powers our Newsfeed. Maybe Virginia could be talked into hosting it as part of the website.
>>>>
>>>> Jamesc
>>>> --
>>>> James Cummings, InfoDev, OUCS, University of Oxford (from phone)
>>>>
>>>> Martin Holmes <mholmes at uvic.ca> wrote:
>>>>
>>>>
>>>> Hi all,
>>>>
>>>> I got a warning from SF this morning, which I guess everyone else will
>>>> also have got, about the retirement of Hosted Apps:
>>>>
>>>> <http://sourceforge.net/blog/hosted-apps-retirement/>
>>>>
>>>> For TEI, I guess this means that WordPress will be going away. I don't
>>>> think we use any other Hosted Apps, do we? I see that LimeSurvey,
>>>> MediaWiki and Trac are all enabled in our SF profile, but the only one I
>>>> recall using was WordPress, for making some kind of announcement during
>>>> the process of a release.
>>>>
>>>> Do we still really need this functionality, or can we let all the Hosted
>>>> Apps die a natural death?
>>>>
>>>> Cheers,
>>>> Martin
>>>> --
>>>> Martin Holmes
>>>> University of Victoria Humanities Computing and Media Centre
>>>> (mholmes at uvic.ca)
>>>>
>>>> --
>>>> tei-council mailing list
>>>> tei-council at lists.village.Virginia.EDU
>>>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>>>>
>>>> PLEASE NOTE: postings to this list are publicly archived
>>>> .
>>>>
>>>
>>
>> --
>> Dr Gabriel BODARD
>> (Research Associate in Digital Epigraphy)
>>
>> Department of Digital Humanities
>> King's College London
>> 26-29 Drury Lane
>> London WC2B 5RL
>>
>> Email: gabriel.bodard at kcl.ac.uk
>> Tel: +44 (0)20 7848 1388
>> Fax: +44 (0)20 7848 2980
>>
>> http://www.digitalclassicist.org/
>> http://www.currentepigraphy.org/
>>
>>
>> --
>> tei-council mailing list
>> tei-council at lists.village.Virginia.EDU
>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>>
>> PLEASE NOTE: postings to this list are publicly archived
>>
>
>

--
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 syeates at gmail.com  Tue Jul  3 16:10:00 2012
From: syeates at gmail.com (Stuart A. Yeates)
Date: Wed, 4 Jul 2012 08:10:00 +1200
Subject: [tei-council] Sourceforge retiring Hosted Apps
In-Reply-To: <dv2odmdp7c7p8aj5y3w9t4bb.1341337696227@email.android.com>
References: <4FF30FA7.7020607@uvic.ca>
	<2lsgtvbqwh5cnijejqlhc4u3.1341330484177@email.android.com>
	<4FF316DF.1020705@uvic.ca> <4FF3173B.90807@kcl.ac.uk>
	<5lai3ruwo19tvj15uqtmgjy5.1341331908743@email.android.com>
	<4FF31B91.9060502@uvic.ca>
	<alpine.OSX.2.00.1207031343140.47849@lister.ei.virginia.edu>
	<dv2odmdp7c7p8aj5y3w9t4bb.1341337696227@email.android.com>
Message-ID: <CAC_Lu0Yx1WuGL0PZFuZ9Pg6JSZTF_gFLF_eNTvBBHnwz-cYchg@mail.gmail.com>

Some time ago I tested wordpress and blogger and came to the
conclusion that wordpress was better for technical things like quoted
XML.

ng? mihi
stuart

On Wed, Jul 4, 2012 at 5:48 AM, James Cummings
<james.cummings at oucs.ox.ac.uk> wrote:
>
> We have the atom feed so all is backed up. Don't know how to import that into wordpress.com
>
> Jamesc We
> --
> James Cummings, InfoDev, OUCS, University of Oxford (from phone)
>
> David Sewell <dsewell at virginia.edu> wrote:
>
>
> On Tue, 3 Jul 2012, Martin Holmes wrote:
>
>> What volunteers are these? I didn't know anyone except Council did this
>> stuff.
>>
>> Incidentally, judging by the home page, that stage in the release
>> process got missed out:
>>
>> <http://www.tei-c.org/index.xml>
>>
>> I don't see any news of release 2.1 there. And WordPress on SF seems to
>> be down at the moment, as well.
>
> That is effect and cause, I believe.
>
> I have wanted to post news items a couple of times in the recent past but
> couldn't get into the Sourceforge WordPress instance. I don't blame SF for
> phasing out their hosted apps but it is a nuisance to have them not working at
> all prior to the ability to back up contents.
>
>
>> Cheers,
>> Martin
>>
>> On 12-07-03 09:12 AM, James Cummings wrote:
>>> Yes... but adds another barrier for our volunteers.
>>>
>>> Jamesc
>>> --
>>> James Cummings, InfoDev, OUCS, University of Oxford (from phone)
>>>
>>> Gabriel Bodard <gabriel.bodard at kcl.ac.uk> wrote:
>>>
>>>
>>> There must be a TEI-to-RSS stylesheet somewhere, mustn't there? (Or if
>>> there isn't there should be...)
>>>
>>> On 2012-07-03 16:59, Martin Holmes wrote:
>>>> If all we're doing with WordPress is creating a newsfeed, couldn't we
>>>> just create an RSS document which we update manually? RSS isn't that
>>>> complicated.
>>>>
>>>> Cheers,
>>>> Martin
>>>>
>>>> On 12-07-03 08:48 AM, James Cummings wrote:
>>>>>
>>>>> We will need a replacement for wordpress as that is what powers our Newsfeed. Maybe Virginia could be talked into hosting it as part of the website.
>>>>>
>>>>> Jamesc
>>>>> --
>>>>> James Cummings, InfoDev, OUCS, University of Oxford (from phone)
>>>>>
>>>>> Martin Holmes <mholmes at uvic.ca> wrote:
>>>>>
>>>>>
>>>>> Hi all,
>>>>>
>>>>> I got a warning from SF this morning, which I guess everyone else will
>>>>> also have got, about the retirement of Hosted Apps:
>>>>>
>>>>> <http://sourceforge.net/blog/hosted-apps-retirement/>
>>>>>
>>>>> For TEI, I guess this means that WordPress will be going away. I don't
>>>>> think we use any other Hosted Apps, do we? I see that LimeSurvey,
>>>>> MediaWiki and Trac are all enabled in our SF profile, but the only one I
>>>>> recall using was WordPress, for making some kind of announcement during
>>>>> the process of a release.
>>>>>
>>>>> Do we still really need this functionality, or can we let all the Hosted
>>>>> Apps die a natural death?
>>>>>
>>>>> Cheers,
>>>>> Martin
>>>>> --
>>>>> Martin Holmes
>>>>> University of Victoria Humanities Computing and Media Centre
>>>>> (mholmes at uvic.ca)
>>>>>
>>>>> --
>>>>> tei-council mailing list
>>>>> tei-council at lists.village.Virginia.EDU
>>>>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>>>>>
>>>>> PLEASE NOTE: postings to this list are publicly archived
>>>>> .
>>>>>
>>>>
>>>
>>> --
>>> Dr Gabriel BODARD
>>> (Research Associate in Digital Epigraphy)
>>>
>>> Department of Digital Humanities
>>> King's College London
>>> 26-29 Drury Lane
>>> London WC2B 5RL
>>>
>>> Email: gabriel.bodard at kcl.ac.uk
>>> Tel: +44 (0)20 7848 1388
>>> Fax: +44 (0)20 7848 2980
>>>
>>> http://www.digitalclassicist.org/
>>> http://www.currentepigraphy.org/
>>>
>>>
>>> --
>>> tei-council mailing list
>>> tei-council at lists.village.Virginia.EDU
>>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>>>
>>> PLEASE NOTE: postings to this list are publicly archived
>>>
>>
>>
>
> --
> David Sewell, Editorial and Technical Manager
> ROTUNDA, The University of Virginia Press
> PO Box 400314, Charlottesville, VA 22904-4314 USA
> Email: dsewell at virginia.edu   Tel: +1 434 924 9973
> Web: http://rotunda.upress.virginia.edu/
> --
> tei-council mailing list
> tei-council at lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>
> PLEASE NOTE: postings to this list are publicly archived

From mholmes at uvic.ca  Tue Jul  3 17:01:43 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Tue, 3 Jul 2012 14:01:43 -0700
Subject: [tei-council] New Jenkins coming online
Message-ID: <4FF35DB7.3030608@uvic.ca>

Hi all,

A third Jenkins server is now up and running at this URL:

<http://teijenkins1204.hcmc.uvic.ca:8080/>

This is built with Ubuntu Precise Server, which is an LTS version with 
guaranteed support for five years. It will eventually replace the other 
UVic Jenkins (http://teijenkins.hcmc.uvic.ca:8080/>, but I plan to run 
them both together for a month or so till I'm sure it's stable and reliable.

So if you commit a change to SVN which breaks a build, you'll now get 
three emails, one from each of my servers and one from Sebastian's. 
Forgive the duplication; it's only temporary.

I'm still not sure whether to proxy it through Apache so it can run on 
port 80. Seems like overkill to run Apache just to do that, but Ubuntu 
seems to have a built-in hatred of running other services on port 80, 
and I haven't figured out a way around it.

Cheers,
Martin
-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)


From kevin.s.hawkins at ultraslavonic.info  Tue Jul  3 21:45:11 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Tue, 03 Jul 2012 21:45:11 -0400
Subject: [tei-council] Sourceforge retiring Hosted Apps
In-Reply-To: <4FF31B91.9060502@uvic.ca>
References: <4FF30FA7.7020607@uvic.ca>
	<2lsgtvbqwh5cnijejqlhc4u3.1341330484177@email.android.com>
	<4FF316DF.1020705@uvic.ca>, <4FF3173B.90807@kcl.ac.uk>
	<5lai3ruwo19tvj15uqtmgjy5.1341331908743@email.android.com>
	<4FF31B91.9060502@uvic.ca>
Message-ID: <4FF3A027.6010107@ultraslavonic.info>

On 7/3/12 12:19 PM, Martin Holmes wrote:
> What volunteers are these? I didn't know anyone except Council did this
> stuff.

James was referring to the volunteer members of the community who notice 
messages to TEI-L worth reposting to the news feed on the TEI-C website.

> Incidentally, judging by the home page, that stage in the release
> process got missed out:
>
> <http://www.tei-c.org/index.xml>
>
> I don't see any news of release 2.1 there. And WordPress on SF seems to
> be down at the moment, as well.

One of the steps in the building-a-release process is to add a message 
about the new release, but we got stuck at this stage because WordPress 
had disappeared without warning.  As David indicated, we now know why 
it's missing.

From mholmes at uvic.ca  Wed Jul  4 11:26:54 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Wed, 4 Jul 2012 08:26:54 -0700
Subject: [tei-council] CH and Language Tags
Message-ID: <4FF460BE.2020706@uvic.ca>

Hi all,

The more I look at the instructions for constructing language tags in 
the CH chapter, the less I like them. I do, however, like these two 
excellent guides, one higher-level and the other more practical:

<http://www.w3.org/International/articles/language-tags/>

<http://www.w3.org/International/questions/qa-choosing-language-tags>

I'm inclined to replace all of our confusing and outdated info with 
something which simply says:

  - BCP47 is the authoritative guide to best practice.

  - IANA's language subtag registry is the authoritative list of 
recommended subtags.

  - The first document above (language-tags) gives a solid overview of 
the process of constructing language tags.

- The second document (qa-choosing-language-tags) gives a detailed set 
of step-by-step instructions for choosing appropriate language tags.

Does anyone see any objection to this? Right now we have vague and 
misleading instructions, and although we could rewrite them, where 
better authoritative sources exist, it makes more sense, I think, to 
refer readers to them.

Cheers,
Martin
-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)


From syeates at gmail.com  Wed Jul  4 16:38:30 2012
From: syeates at gmail.com (Stuart A. Yeates)
Date: Thu, 5 Jul 2012 08:38:30 +1200
Subject: [tei-council] CH and Language Tags
In-Reply-To: <4FF460BE.2020706@uvic.ca>
References: <4FF460BE.2020706@uvic.ca>
Message-ID: <CAC_Lu0ZdDUMfOkmjJZGuK11iRtJV-3YxYLh=d__dAboXwW5B7A@mail.gmail.com>

On Thu, Jul 5, 2012 at 3:26 AM, Martin Holmes <mholmes at uvic.ca> wrote:
> Hi all,
>
> The more I look at the instructions for constructing language tags in
> the CH chapter, the less I like them. I do, however, like these two
> excellent guides, one higher-level and the other more practical:
>
> <http://www.w3.org/International/articles/language-tags/>
>
> <http://www.w3.org/International/questions/qa-choosing-language-tags>
>
> I'm inclined to replace all of our confusing and outdated info with
> something which simply says:
>
>   - BCP47 is the authoritative guide to best practice.
>
>   - IANA's language subtag registry is the authoritative list of
> recommended subtags.
>
>   - The first document above (language-tags) gives a solid overview of
> the process of constructing language tags.
>
> - The second document (qa-choosing-language-tags) gives a detailed set
> of step-by-step instructions for choosing appropriate language tags.
>
> Does anyone see any objection to this? Right now we have vague and
> misleading instructions, and although we could rewrite them, where
> better authoritative sources exist, it makes more sense, I think, to
> refer readers to them.

I completely agree with this approach.

It may be worth touching on the fact that on modern *NIX systems XML
lists of many ISO codes can be found in /usr/share/xml/iso-codes/

cheers
stuart

From syeates at gmail.com  Thu Jul  5 04:45:34 2012
From: syeates at gmail.com (stuart yeates)
Date: Thu, 05 Jul 2012 20:45:34 +1200
Subject: [tei-council] proposed new <entry/> example with xml:lang attributes
Message-ID: <4FF5542E.80206@gmail.com>

I would like to propose adding a new example to <entry/> which differs 
from the current examples in  systematic use of xml:lang and use of 
@corresp rather than @type="translation", as per other uses elsewhere in 
TEI.

I'm still not 100% sure I've got the subtags right.

Thoughts?

cheers
stuart


<entry n='42' xml:lang="en">
  <form>
   <!-- word as written according to M?ori Language Commission -->
   <orth xml:lang="mi-modern">W?w?</orth>
   <!-- word as written by Biggs (see 
https://en.wikipedia.org/wiki/Bruce_Biggs ) -->
   <orth xml:lang="mi-biggs">Wiiwii</orth>
   <!-- word as written in IPA, according to the MLC standardised 
pronounciation -->
   <pron xml:lang="mi-fonipa">wi?.wi?</pron>
  </form>
  <gramGrp><pos>stative</pos></gramGrp>
  <sense>
   <def>French (language)</def>
   <def>France (place)</def>
   <def>French (collective plural)</def>
   <def>French (adjective)</def>
  </sense>
  <etym>
   <lang>French</lang> <mentioned xml:lang="fr">oui oui</mentioned>
  </etym>
  <cit>
   <quote xml:lang="mi-modn" xml:id="q1"> E k&#299;ia ana n&#333; te tau 
1603 i t&#299;mataria ai te mahi o t&#275;nei patu, o te p&#275;neti, 
&#257; n&#257; ng&#257; iwi <b>W&#299;w&#299;</b> i kite te mahi o taua 
patu</quote>
   <quote xml:lang="en" corresp="#q1"> It is said that the use of the 
weapon, the bayonet, started in the year 1603 and it was the French who 
invented that weapon.</quote>
   <bibl><ref 
target="http://www.maoridictionary.co.nz/index.cfm?wordID=9284">Te 
Pihinga Textbook (Ed. 2): 70;</ref></bibl>
  </cit>
</entry>

From kevin.s.hawkins at ultraslavonic.info  Thu Jul  5 06:21:59 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Thu, 05 Jul 2012 06:21:59 -0400
Subject: [tei-council] proposed new <entry/> example with xml:lang
	attributes
In-Reply-To: <4FF5542E.80206@gmail.com>
References: <4FF5542E.80206@gmail.com>
Message-ID: <4FF56AC7.9090800@ultraslavonic.info>

Stuart,

If I understand correctly, you propose to add an example to section 
9.3.3.2 of a translation of *an example usage* of the headword.  Whereas 
the way currently specified in 9.3.3.2 would be:

<cit type="example">
   <quote> E k&#299;ia ana n&#333; te tau
1603 i t&#299;mataria ai te mahi o t&#275;nei patu, o te p&#275;neti,
&#257; n&#257; ng&#257; iwi <b>W&#299;w&#299;</b> i kite te mahi o taua
patu</quote>
   <cit type="translation">
     <quote>It is said that the use of the
weapon, the bayonet, started in the year 1603 and it was the French who
invented that weapon.</quote>
     <bibl><ref
target="http://www.maoridictionary.co.nz/index.cfm?wordID=9284">Te
Pihinga Textbook (Ed. 2): 70;</ref></bibl>
   </cit>
</cit>

You would also offer this option:

<cit type="example">
    <quote xml:lang="mi-modn" xml:id="q1"> E k&#299;ia ana n&#333; te tau
1603 i t&#299;mataria ai te mahi o t&#275;nei patu, o te p&#275;neti,
&#257; n&#257; ng&#257; iwi <b>W&#299;w&#299;</b> i kite te mahi o taua
patu</quote>
    <quote xml:lang="en" corresp="#q1"> It is said that the use of the
weapon, the bayonet, started in the year 1603 and it was the French who
invented that weapon.</quote>
    <bibl><ref
target="http://www.maoridictionary.co.nz/index.cfm?wordID=9284">Te
Pihinga Textbook (Ed. 2): 70;</ref></bibl>
   </cit>

I'm not clear on what you would do in the case not of a translation of 
*an example usage of the headword* but simply a translation of *the 
headword*.  In section 9.3.3.2 this is currently done like this:

<form>
   <orth>dresser</orth>
  </form>
  <sense n="a">
   <sense>
    <usg type="dom">Theat</usg>
    <cit type="translation" xml:lang="fr">
     <quote>habilleur</quote>
     <gen>m</gen>
    </cit>
    <cit type="translation" xml:lang="fr">
     <quote>-euse</quote>
     <gen>f</gen>
    </cit>
   </sense>
   <!-- . . . -->
</form>

Would you add a @corresp to each <quote> that points to the value of 
@xml:id on <orth>?

I don't yet see the reason for adding your alternative encoding to the 
Guidelines.  Having another way of encoding translations makes 
processing a corpus TEI documents from various sources all the more 
difficult, and it's not clear to me that there's any particular 
philosophical view of text that we could support in your encoding.  In 
short, we shouldn't support needless variation of encoding practice.

--K.

On 7/5/12 4:45 AM, stuart yeates wrote:
> I would like to propose adding a new example to <entry/> which differs
> from the current examples in  systematic use of xml:lang and use of
> @corresp rather than @type="translation", as per other uses elsewhere in
> TEI.
>
> I'm still not 100% sure I've got the subtags right.
>
> Thoughts?
>
> cheers
> stuart
>
>
> <entry n='42' xml:lang="en">
>    <form>
>     <!-- word as written according to M?ori Language Commission -->
>     <orth xml:lang="mi-modern">W?w?</orth>
>     <!-- word as written by Biggs (see
> https://en.wikipedia.org/wiki/Bruce_Biggs ) -->
>     <orth xml:lang="mi-biggs">Wiiwii</orth>
>     <!-- word as written in IPA, according to the MLC standardised
> pronounciation -->
>     <pron xml:lang="mi-fonipa">wi?.wi?</pron>
>    </form>
>    <gramGrp><pos>stative</pos></gramGrp>
>    <sense>
>     <def>French (language)</def>
>     <def>France (place)</def>
>     <def>French (collective plural)</def>
>     <def>French (adjective)</def>
>    </sense>
>    <etym>
>     <lang>French</lang> <mentioned xml:lang="fr">oui oui</mentioned>
>    </etym>
>    <cit>
>     <quote xml:lang="mi-modn" xml:id="q1"> E k&#299;ia ana n&#333; te tau
> 1603 i t&#299;mataria ai te mahi o t&#275;nei patu, o te p&#275;neti,
> &#257; n&#257; ng&#257; iwi <b>W&#299;w&#299;</b> i kite te mahi o taua
> patu</quote>
>     <quote xml:lang="en" corresp="#q1"> It is said that the use of the
> weapon, the bayonet, started in the year 1603 and it was the French who
> invented that weapon.</quote>
>     <bibl><ref
> target="http://www.maoridictionary.co.nz/index.cfm?wordID=9284">Te
> Pihinga Textbook (Ed. 2): 70;</ref></bibl>
>    </cit>
> </entry>
>


From bansp at o2.pl  Thu Jul  5 06:38:02 2012
From: bansp at o2.pl (Piotr Banski)
Date: Thu, 05 Jul 2012 12:38:02 +0200
Subject: [tei-council] proposed new <entry/> example with xml:lang
	attributes
In-Reply-To: <4FF56AC7.9090800@ultraslavonic.info>
References: <4FF5542E.80206@gmail.com> <4FF56AC7.9090800@ultraslavonic.info>
Message-ID: <4FF56E8A.4010609@o2.pl>

Hi all,

I somehow managed to miss the @corresp proposal, need to search the past 
messages, I guess.

I had the impression that one would normally go for the same "box" 
containing the translation (equivalent), whether it corresponds to the 
<trans> or <dicteg> of old:

equivalent:

<cit type="translation">
<quote>--equivalent--</quote>
</cit>

example:

<cit type="example">
<quote>--example here--</quote>
<cit type="translation">
<quote>--translation of the example--</quote>
</cit>
</cit>

On this approach, there is probably (?) no need for @corresp, because 
the relevant relationship is expressed by containment.

Or am I missing the point? (scanning mails ultraquickly today, apologies 
in advance)

   P>



On 05/07/12 12:21, Kevin Hawkins wrote:
> Stuart,
>
> If I understand correctly, you propose to add an example to section
> 9.3.3.2 of a translation of *an example usage* of the headword.  Whereas
> the way currently specified in 9.3.3.2 would be:
>
> <cit type="example">
>     <quote> E k&#299;ia ana n&#333; te tau
> 1603 i t&#299;mataria ai te mahi o t&#275;nei patu, o te p&#275;neti,
> &#257; n&#257; ng&#257; iwi <b>W&#299;w&#299;</b> i kite te mahi o taua
> patu</quote>
>     <cit type="translation">
>       <quote>It is said that the use of the
> weapon, the bayonet, started in the year 1603 and it was the French who
> invented that weapon.</quote>
>       <bibl><ref
> target="http://www.maoridictionary.co.nz/index.cfm?wordID=9284">Te
> Pihinga Textbook (Ed. 2): 70;</ref></bibl>
>     </cit>
> </cit>
>
> You would also offer this option:
>
> <cit type="example">
>      <quote xml:lang="mi-modn" xml:id="q1"> E k&#299;ia ana n&#333; te tau
> 1603 i t&#299;mataria ai te mahi o t&#275;nei patu, o te p&#275;neti,
> &#257; n&#257; ng&#257; iwi <b>W&#299;w&#299;</b> i kite te mahi o taua
> patu</quote>
>      <quote xml:lang="en" corresp="#q1"> It is said that the use of the
> weapon, the bayonet, started in the year 1603 and it was the French who
> invented that weapon.</quote>
>      <bibl><ref
> target="http://www.maoridictionary.co.nz/index.cfm?wordID=9284">Te
> Pihinga Textbook (Ed. 2): 70;</ref></bibl>
>     </cit>
>
> I'm not clear on what you would do in the case not of a translation of
> *an example usage of the headword* but simply a translation of *the
> headword*.  In section 9.3.3.2 this is currently done like this:
>
> <form>
>     <orth>dresser</orth>
>    </form>
>    <sense n="a">
>     <sense>
>      <usg type="dom">Theat</usg>
>      <cit type="translation" xml:lang="fr">
>       <quote>habilleur</quote>
>       <gen>m</gen>
>      </cit>
>      <cit type="translation" xml:lang="fr">
>       <quote>-euse</quote>
>       <gen>f</gen>
>      </cit>
>     </sense>
>     <!-- . . . -->
> </form>
>
> Would you add a @corresp to each <quote> that points to the value of
> @xml:id on <orth>?
>
> I don't yet see the reason for adding your alternative encoding to the
> Guidelines.  Having another way of encoding translations makes
> processing a corpus TEI documents from various sources all the more
> difficult, and it's not clear to me that there's any particular
> philosophical view of text that we could support in your encoding.  In
> short, we shouldn't support needless variation of encoding practice.
>
> --K.
>
> On 7/5/12 4:45 AM, stuart yeates wrote:
>> I would like to propose adding a new example to <entry/> which differs
>> from the current examples in  systematic use of xml:lang and use of
>> @corresp rather than @type="translation", as per other uses elsewhere in
>> TEI.
>>
>> I'm still not 100% sure I've got the subtags right.
>>
>> Thoughts?
>>
>> cheers
>> stuart
>>
>>
>> <entry n='42' xml:lang="en">
>>     <form>
>>      <!-- word as written according to M?ori Language Commission -->
>>      <orth xml:lang="mi-modern">W?w?</orth>
>>      <!-- word as written by Biggs (see
>> https://en.wikipedia.org/wiki/Bruce_Biggs ) -->
>>      <orth xml:lang="mi-biggs">Wiiwii</orth>
>>      <!-- word as written in IPA, according to the MLC standardised
>> pronounciation -->
>>      <pron xml:lang="mi-fonipa">wi?.wi?</pron>
>>     </form>
>>     <gramGrp><pos>stative</pos></gramGrp>
>>     <sense>
>>      <def>French (language)</def>
>>      <def>France (place)</def>
>>      <def>French (collective plural)</def>
>>      <def>French (adjective)</def>
>>     </sense>
>>     <etym>
>>      <lang>French</lang> <mentioned xml:lang="fr">oui oui</mentioned>
>>     </etym>
>>     <cit>
>>      <quote xml:lang="mi-modn" xml:id="q1"> E k&#299;ia ana n&#333; te tau
>> 1603 i t&#299;mataria ai te mahi o t&#275;nei patu, o te p&#275;neti,
>> &#257; n&#257; ng&#257; iwi <b>W&#299;w&#299;</b> i kite te mahi o taua
>> patu</quote>
>>      <quote xml:lang="en" corresp="#q1"> It is said that the use of the
>> weapon, the bayonet, started in the year 1603 and it was the French who
>> invented that weapon.</quote>
>>      <bibl><ref
>> target="http://www.maoridictionary.co.nz/index.cfm?wordID=9284">Te
>> Pihinga Textbook (Ed. 2): 70;</ref></bibl>
>>     </cit>
>> </entry>
>>
>



From mholmes at uvic.ca  Thu Jul  5 08:45:44 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Thu, 5 Jul 2012 05:45:44 -0700
Subject: [tei-council] proposed new <entry/> example with xml:lang
	attributes
In-Reply-To: <4FF5542E.80206@gmail.com>
References: <4FF5542E.80206@gmail.com>
Message-ID: <4FF58C78.2050008@uvic.ca>

HI Stuart,

I don't see "biggs" or "modern" in the subtag registry. If these are 
unregistered, shouldn't you be using "-x-"?

Cheers,
Martin

On 12-07-05 01:45 AM, stuart yeates wrote:
> I would like to propose adding a new example to <entry/> which differs
> from the current examples in  systematic use of xml:lang and use of
> @corresp rather than @type="translation", as per other uses elsewhere in
> TEI.
>
> I'm still not 100% sure I've got the subtags right.
>
> Thoughts?
>
> cheers
> stuart
>
>
> <entry n='42' xml:lang="en">
>    <form>
>     <!-- word as written according to M?ori Language Commission -->
>     <orth xml:lang="mi-modern">W?w?</orth>
>     <!-- word as written by Biggs (see
> https://en.wikipedia.org/wiki/Bruce_Biggs ) -->
>     <orth xml:lang="mi-biggs">Wiiwii</orth>
>     <!-- word as written in IPA, according to the MLC standardised
> pronounciation -->
>     <pron xml:lang="mi-fonipa">wi?.wi?</pron>
>    </form>
>    <gramGrp><pos>stative</pos></gramGrp>
>    <sense>
>     <def>French (language)</def>
>     <def>France (place)</def>
>     <def>French (collective plural)</def>
>     <def>French (adjective)</def>
>    </sense>
>    <etym>
>     <lang>French</lang> <mentioned xml:lang="fr">oui oui</mentioned>
>    </etym>
>    <cit>
>     <quote xml:lang="mi-modn" xml:id="q1"> E k&#299;ia ana n&#333; te tau
> 1603 i t&#299;mataria ai te mahi o t&#275;nei patu, o te p&#275;neti,
> &#257; n&#257; ng&#257; iwi <b>W&#299;w&#299;</b> i kite te mahi o taua
> patu</quote>
>     <quote xml:lang="en" corresp="#q1"> It is said that the use of the
> weapon, the bayonet, started in the year 1603 and it was the French who
> invented that weapon.</quote>
>     <bibl><ref
> target="http://www.maoridictionary.co.nz/index.cfm?wordID=9284">Te
> Pihinga Textbook (Ed. 2): 70;</ref></bibl>
>    </cit>
> </entry>
>


From mholmes at uvic.ca  Thu Jul  5 11:26:39 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Thu, 5 Jul 2012 08:26:39 -0700
Subject: [tei-council] Private URI Schemes
In-Reply-To: <4FF5828B.6070005@retired.ox.ac.uk>
References: <4FEB4139.2010407@uvic.ca> <4FF5828B.6070005@retired.ox.ac.uk>
Message-ID: <4FF5B22F.80109@uvic.ca>

Lou responded to me directly on this -- hope it's OK to quote his 
comments to the list.

He's absolutely right that the attribute names should be harmonized with 
<cRefPattern>; I've now done that, and expanded the proposal a bit so it 
places the attributes in a proposed new attribute class:

<http://wiki.tei-c.org/index.php/Private_URI_Schemes>

Cheers,
Martin

On 12-07-05 05:03 AM, Lou Burnard wrote:
> On 27/06/12 18:22, Martin Holmes wrote:
>> Hi all,
>>
>> We've had a couple of discussions about the magic token vs. private URI
>> scheme issue over the past couple of meetings, and now I've put together
>> a brief description of the way I had imagined putting the use of private
>> URI schemes on a more solid footing than magic tokens:
>>
>> <http://wiki.tei-c.org/index.php/Private_URI_Schemes>
>>
>> Could you take a look and let me know what you think?
>>
>
> At first glance, this looks really useful.
>
> It is almost the same mechanism as that we currently use for
> <cRefPattern>, except that the latter has slightly divergent attribute
> names. Can we harmonise the two? Can we find other cases where this sort
> of meta-mechanism should be fitted?
>
>

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)



From lou.burnard at retired.ox.ac.uk  Thu Jul  5 12:00:43 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Thu, 05 Jul 2012 17:00:43 +0100
Subject: [tei-council] http://purl.org/tei/fr/3519866 (@rend datatype)
In-Reply-To: <4FEF0D51.9010708@oucs.ox.ac.uk>
References: <4FED7CCC.1030307@oucs.ox.ac.uk> <4FEDA0A1.5050305@oucs.ox.ac.uk>
	<4FEE091F.7060106@o2.pl> <4FEE12A8.5050904@uvic.ca>
	<4FEF0D51.9010708@oucs.ox.ac.uk>
Message-ID: <4FF5BA2B.2040503@retired.ox.ac.uk>

I'm a very nice reasonable person, and I have quite strong views on this 
subject too! Not to pre-empt further discussion, I observe that the 
current datatype (1:n data.words) was a change deliberately (and quite 
recently) introduced to appease those who were uncomfortable with the 
requirement to predefine styles, implicit in using @rendition.

It does not really permit arbitrary syntax (like rendition ladders or 
local CSS), so that (legacy) constituency remains unsatisfied. At the 
same time, it requires the user to tell fibs, so that progressive (if 
anal) thinkers are also dissatisfied with it. As I said on the ticket, 
the only sensible way to resolve this issue is to return to the status 
quo ante bellum.


  On 30/06/12 15:29, James Cummings wrote:
>
> Would it make sense for two nice reasonable people (like Martin
> and Piotr) on opposite sides of the discussion to look at it as
> an ad-hoc group?  (Possibly with someone who doesn't have an
> opinion one way or the other?)  They could then report back to
> the face2face?
>
> -James
>
>
> On 29/06/12 21:40, Martin Holmes wrote:
>> I'm on the other side of this debate, and equally biased. I agree that
>> we need to take this on as a group, but I'd suggest scheduling it on the
>> last day of the ftf so that if we get all heated about it, there'll be a
>> natural end to the discussion. :-)
>>
>> On 12-06-29 12:59 PM, Piotr Ba?ski wrote:
>>> My view is similar to yours, so I'm not sure whether I would properly
>>> serve the greater good here. In case no one wants it, I can try, though
>>> this is now, I think, a very sore issue. It might be a good idea for the
>>> Council to act as a body on this.
>>>
>>> Maybe we could take it on in September?
>>>
>>>      P.
>>>
>>> On 29/06/12 14:33, James Cummings wrote:
>>>>
>>>> Is there someone who feels they can be neutral and objective who
>>>> would like to take on http://purl.org/tei/fr/3519866 which is the
>>>> ticket discussing whether @rend's datatype should be changed?
>>>> I'd prefer someone who is not already very much for or against
>>>> this to look at it.
>>>>
>>>> I'm hideously biased against loosening its datatype and the
>>>> existing recommendations that @rend values are separate tokens,
>>>> so don't feel I should take it on myself.  If you've not been
>>>> involved in the discussion so far and/or know nothing about it,
>>>> you might be the right person to re-examine it.
>>>>
>>>> -James
>>>>
>>>
>>>
>>
>
>



From sebastian.rahtz at oucs.ox.ac.uk  Thu Jul  5 12:30:27 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Thu, 5 Jul 2012 16:30:27 +0000
Subject: [tei-council] http://purl.org/tei/fr/3519866 (@rend datatype)
In-Reply-To: <4FF5BA2B.2040503@retired.ox.ac.uk>
References: <4FED7CCC.1030307@oucs.ox.ac.uk>
	<4FEDA0A1.5050305@oucs.ox.ac.uk> <4FEE091F.7060106@o2.pl>
	<4FEE12A8.5050904@uvic.ca> <4FEF0D51.9010708@oucs.ox.ac.uk>
	<4FF5BA2B.2040503@retired.ox.ac.uk>
Message-ID: <0409f830-2dc1-49f0-a117-aefd7d0b223e@HUB06.ad.oak.ox.ac.uk>


On 5 Jul 2012, at 17:00, Lou Burnard wrote:

>  Not to pre-empt further discussion, I observe that the 
> current datatype (1:n data.words) was a change deliberately (and quite 
> recently)

well, it was there at the start of P5, so not _that_recent. I can spot
the idea as far back as 2005.

> It does not really permit arbitrary syntax (like rendition ladders or 
> local CSS), so that (legacy) constituency remains unsatisfied. At the 
> same time, it requires the user to tell fibs, so that progressive (if 
> anal) thinkers are also dissatisfied with it. As I said on the ticket, 
> the only sensible way to resolve this issue is to return to the status 
> quo ante bellum.


which bellum? you want to go back to P4 and just allow anything?

I'm coming round to the idea of a mandatory indicator in the header which says how
@rend is to be interpreted (with a closed list of (eg) "token", "free" and "CSS"), 
since its unlikely we'll ever now close this awful Pandora's box. 
--
Sebastian Rahtz      
Head of Information and Support Group
Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431







From mholmes at uvic.ca  Thu Jul  5 12:51:16 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Thu, 5 Jul 2012 09:51:16 -0700
Subject: [tei-council] http://purl.org/tei/fr/3519866 (@rend datatype)
In-Reply-To: <4FF5BA2B.2040503@retired.ox.ac.uk>
References: <4FED7CCC.1030307@oucs.ox.ac.uk>
	<4FEDA0A1.5050305@oucs.ox.ac.uk>	<4FEE091F.7060106@o2.pl>
	<4FEE12A8.5050904@uvic.ca>	<4FEF0D51.9010708@oucs.ox.ac.uk>
	<4FF5BA2B.2040503@retired.ox.ac.uk>
Message-ID: <4FF5C604.8030806@uvic.ca>

On 12-07-05 09:00 AM, Lou Burnard wrote:
> I'm a very nice reasonable person, and I have quite strong views on this
> subject too! Not to pre-empt further discussion, I observe that the
> current datatype (1:n data.words) was a change deliberately (and quite
> recently) introduced to appease those who were uncomfortable with the
> requirement to predefine styles, implicit in using @rendition.
>
> It does not really permit arbitrary syntax (like rendition ladders or
> local CSS), so that (legacy) constituency remains unsatisfied. At the
> same time, it requires the user to tell fibs, so that progressive (if
> anal) thinkers are also dissatisfied with it. As I said on the ticket,
> the only sensible way to resolve this issue is to return to the status
> quo ante bellum.

I don't think that's the only solution. Surely @style (content = CSS) 
would solve the problem for those who want to use inline CSS? It's that 
group who raised the issue, and they're just asking for a legitimate way 
to use inline CSS, without offending the sensibilities of those who 
believe strongly that 1:n data.words is right and proper.

Cheers,
Martin

>    On 30/06/12 15:29, James Cummings wrote:
>>
>> Would it make sense for two nice reasonable people (like Martin
>> and Piotr) on opposite sides of the discussion to look at it as
>> an ad-hoc group?  (Possibly with someone who doesn't have an
>> opinion one way or the other?)  They could then report back to
>> the face2face?
>>
>> -James
>>
>>
>> On 29/06/12 21:40, Martin Holmes wrote:
>>> I'm on the other side of this debate, and equally biased. I agree that
>>> we need to take this on as a group, but I'd suggest scheduling it on the
>>> last day of the ftf so that if we get all heated about it, there'll be a
>>> natural end to the discussion. :-)
>>>
>>> On 12-06-29 12:59 PM, Piotr Ba?ski wrote:
>>>> My view is similar to yours, so I'm not sure whether I would properly
>>>> serve the greater good here. In case no one wants it, I can try, though
>>>> this is now, I think, a very sore issue. It might be a good idea for the
>>>> Council to act as a body on this.
>>>>
>>>> Maybe we could take it on in September?
>>>>
>>>>       P.
>>>>
>>>> On 29/06/12 14:33, James Cummings wrote:
>>>>>
>>>>> Is there someone who feels they can be neutral and objective who
>>>>> would like to take on http://purl.org/tei/fr/3519866 which is the
>>>>> ticket discussing whether @rend's datatype should be changed?
>>>>> I'd prefer someone who is not already very much for or against
>>>>> this to look at it.
>>>>>
>>>>> I'm hideously biased against loosening its datatype and the
>>>>> existing recommendations that @rend values are separate tokens,
>>>>> so don't feel I should take it on myself.  If you've not been
>>>>> involved in the discussion so far and/or know nothing about it,
>>>>> you might be the right person to re-examine it.
>>>>>
>>>>> -James
>>>>>
>>>>
>>>>
>>>
>>
>>
>
>

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)



From sebastian.rahtz at oucs.ox.ac.uk  Thu Jul  5 12:56:49 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Thu, 5 Jul 2012 16:56:49 +0000
Subject: [tei-council] http://purl.org/tei/fr/3519866 (@rend datatype)
In-Reply-To: <4FF5C604.8030806@uvic.ca>
References: <4FED7CCC.1030307@oucs.ox.ac.uk>
	<4FEDA0A1.5050305@oucs.ox.ac.uk>	<4FEE091F.7060106@o2.pl>
	<4FEE12A8.5050904@uvic.ca>	<4FEF0D51.9010708@oucs.ox.ac.uk>
	<4FF5BA2B.2040503@retired.ox.ac.uk> <4FF5C604.8030806@uvic.ca>
Message-ID: <8d8d362f-28d9-466a-b455-81b372dc223a@HUB05.ad.oak.ox.ac.uk>


On 5 Jul 2012, at 17:51, Martin Holmes wrote:

> I don't think that's the only solution. Surely @style (content = CSS) 
> would solve the problem for those who want to use inline CSS?

bother me a bit that we special-case CSS with this; and it is also not clear
whether you can have @rend _and_ @style, ie what are precedence
and inheritance rules?
--
Sebastian Rahtz      
Head of Information and Support Group
Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431







From mholmes at uvic.ca  Thu Jul  5 12:58:26 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Thu, 5 Jul 2012 09:58:26 -0700
Subject: [tei-council] http://purl.org/tei/fr/3519866 (@rend datatype)
In-Reply-To: <0409f830-2dc1-49f0-a117-aefd7d0b223e@HUB06.ad.oak.ox.ac.uk>
References: <4FED7CCC.1030307@oucs.ox.ac.uk> <4FEDA0A1.5050305@oucs.ox.ac.uk>
	<4FEE091F.7060106@o2.pl> <4FEE12A8.5050904@uvic.ca>
	<4FEF0D51.9010708@oucs.ox.ac.uk>
	<4FF5BA2B.2040503@retired.ox.ac.uk>
	<0409f830-2dc1-49f0-a117-aefd7d0b223e@HUB06.ad.oak.ox.ac.uk>
Message-ID: <4FF5C7B2.7070804@uvic.ca>

On 12-07-05 09:30 AM, Sebastian Rahtz wrote:
>
> On 5 Jul 2012, at 17:00, Lou Burnard wrote:
>
>>   Not to pre-empt further discussion, I observe that the
>> current datatype (1:n data.words) was a change deliberately (and quite
>> recently)
>
> well, it was there at the start of P5, so not _that_recent. I can spot
> the idea as far back as 2005.
>
>> It does not really permit arbitrary syntax (like rendition ladders or
>> local CSS), so that (legacy) constituency remains unsatisfied. At the
>> same time, it requires the user to tell fibs, so that progressive (if
>> anal) thinkers are also dissatisfied with it. As I said on the ticket,
>> the only sensible way to resolve this issue is to return to the status
>> quo ante bellum.
>
>
> which bellum? you want to go back to P4 and just allow anything?
>
> I'm coming round to the idea of a mandatory indicator in the header which says how
> @rend is to be interpreted (with a closed list of (eg) "token", "free" and "CSS"),
> since its unlikely we'll ever now close this awful Pandora's box.

I don't see why not. I think everyone (like me) currently abusing @rend 
by putting CSS in there can very easily switch to a new attribute 
(@style) instead. Anyone who refused to do so would remain guilty of 
attribute abuse, but without the excuse that they had no alternative 
(yes, I know there's always customization, but...). We could perhaps 
back up the move with a Schematron constraint that would complain at the 
appearance of semi-colons and colons in @rend, to encourage compliance, 
and we could even provide some degree of Schematron validation for CSS 
in @style.

Cheers,
Martin

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)



From dsewell at virginia.edu  Thu Jul  5 12:59:10 2012
From: dsewell at virginia.edu (David Sewell)
Date: Thu, 5 Jul 2012 12:59:10 -0400 (EDT)
Subject: [tei-council] http://purl.org/tei/fr/3519866 (@rend datatype)
In-Reply-To: <0409f830-2dc1-49f0-a117-aefd7d0b223e@HUB06.ad.oak.ox.ac.uk>
References: <4FED7CCC.1030307@oucs.ox.ac.uk> <4FEDA0A1.5050305@oucs.ox.ac.uk>
	<4FEE091F.7060106@o2.pl> <4FEE12A8.5050904@uvic.ca>
	<4FEF0D51.9010708@oucs.ox.ac.uk>
	<4FF5BA2B.2040503@retired.ox.ac.uk>
	<0409f830-2dc1-49f0-a117-aefd7d0b223e@HUB06.ad.oak.ox.ac.uk>
Message-ID: <alpine.OSX.2.00.1207051257500.75493@lister.ei.virginia.edu>

On Thu, 5 Jul 2012, Sebastian Rahtz wrote:

> I'm coming round to the idea of a mandatory indicator in the header which says how
> @rend is to be interpreted (with a closed list of (eg) "token", "free" and "CSS"),
> since its unlikely we'll ever now close this awful Pandora's box.

Speaking as a nonvoting observer, this seems to me as close to a Solomonic 
compromise as it is likely to get.

-- 
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 mholmes at uvic.ca  Thu Jul  5 13:09:25 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Thu, 5 Jul 2012 10:09:25 -0700
Subject: [tei-council] http://purl.org/tei/fr/3519866 (@rend datatype)
In-Reply-To: <8d8d362f-28d9-466a-b455-81b372dc223a@HUB05.ad.oak.ox.ac.uk>
References: <4FED7CCC.1030307@oucs.ox.ac.uk>
	<4FEDA0A1.5050305@oucs.ox.ac.uk>	<4FEE091F.7060106@o2.pl>
	<4FEE12A8.5050904@uvic.ca>	<4FEF0D51.9010708@oucs.ox.ac.uk>
	<4FF5BA2B.2040503@retired.ox.ac.uk> <4FF5C604.8030806@uvic.ca>
	<8d8d362f-28d9-466a-b455-81b372dc223a@HUB05.ad.oak.ox.ac.uk>
Message-ID: <4FF5CA45.6050902@uvic.ca>

On 12-07-05 09:56 AM, Sebastian Rahtz wrote:
>
> On 5 Jul 2012, at 17:51, Martin Holmes wrote:
>
>> I don't think that's the only solution. Surely @style (content = CSS)
>> would solve the problem for those who want to use inline CSS?
>
> bother me a bit that we special-case CSS with this; and it is also not clear
> whether you can have @rend _and_ @style, ie what are precedence
> and inheritance rules?

That's up to the project, surely. Most would presumably only use one or 
the other. If you're wondering what the default TEI stylesheets should 
do, then that's another question; but the stylesheets already have to 
guess at what any given value(s) appearing in @rend are supposed to 
mean. I'd be inclined to say that if @style is present, then ignore 
@rend, but you could also combine the two. Redundancy in an HTML @style 
attribute is ignored, isn't it?

Cheers,
Martin

> --
> Sebastian Rahtz
> Head of Information and Support Group
> Oxford University Computing Services
> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>
>
>
>
>
>
>

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)



From gabriel.bodard at kcl.ac.uk  Thu Jul  5 13:13:50 2012
From: gabriel.bodard at kcl.ac.uk (Gabriel Bodard)
Date: Thu, 5 Jul 2012 18:13:50 +0100
Subject: [tei-council] http://purl.org/tei/fr/3519866 (@rend datatype)
In-Reply-To: <4FF5C7B2.7070804@uvic.ca>
References: <4FED7CCC.1030307@oucs.ox.ac.uk>
	<4FEDA0A1.5050305@oucs.ox.ac.uk>	<4FEE091F.7060106@o2.pl>
	<4FEE12A8.5050904@uvic.ca>	<4FEF0D51.9010708@oucs.ox.ac.uk>
	<4FF5BA2B.2040503@retired.ox.ac.uk>
	<0409f830-2dc1-49f0-a117-aefd7d0b223e@HUB06.ad.oak.ox.ac.uk>
	<4FF5C7B2.7070804@uvic.ca>
Message-ID: <4FF5CB4E.2090600@kcl.ac.uk>

This makes a lot of sense to me. (I mean, I'm still in favour of the 
"What's wrong with @rendition if you're a CSS-head" approach, but that's 
less Solomonic as it doesn't seem to please anyone.)

I certainly think if we're allowing CSS somewhere, we should make some 
attempt to validate that css (or at least make sure someone isn't 
putting RTF style instructions in there, vel sim.).

And I'm not a big fan of the token|free|css choice in the header, 
because are we *sure* that everyone is always going to want to treat 
@rend the same way on *all* elements? (I can imagine using @rend, @style 
and even @rendition concurrently in different contexts in one teiCorpus.)

On 2012-07-05 17:58, Martin Holmes wrote:

> On 12-07-05 09:30 AM, Sebastian Rahtz wrote:
>> since its unlikely we'll ever now close this awful Pandora's box.
>
> I don't see why not. I think everyone (like me) currently abusing @rend
> by putting CSS in there can very easily switch to a new attribute
> (@style) instead. Anyone who refused to do so would remain guilty of
> attribute abuse, but without the excuse that they had no alternative
> (yes, I know there's always customization, but...). We could perhaps
> back up the move with a Schematron constraint that would complain at the
> appearance of semi-colons and colons in @rend, to encourage compliance,
> and we could even provide some degree of Schematron validation for CSS
> in @style.
>
> Cheers,
> Martin
>

-- 
Dr Gabriel BODARD
(Research Associate in Digital Epigraphy)

Department of Digital Humanities
King's College London
26-29 Drury Lane
London WC2B 5RL

Email: gabriel.bodard at kcl.ac.uk
Tel: +44 (0)20 7848 1388
Fax: +44 (0)20 7848 2980

http://www.digitalclassicist.org/
http://www.currentepigraphy.org/



From sebastian.rahtz at oucs.ox.ac.uk  Thu Jul  5 13:14:41 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Thu, 5 Jul 2012 17:14:41 +0000
Subject: [tei-council] http://purl.org/tei/fr/3519866 (@rend datatype)
In-Reply-To: <4FF5CA45.6050902@uvic.ca>
References: <4FED7CCC.1030307@oucs.ox.ac.uk>
	<4FEDA0A1.5050305@oucs.ox.ac.uk>	<4FEE091F.7060106@o2.pl>
	<4FEE12A8.5050904@uvic.ca>	<4FEF0D51.9010708@oucs.ox.ac.uk>
	<4FF5BA2B.2040503@retired.ox.ac.uk> <4FF5C604.8030806@uvic.ca>
	<8d8d362f-28d9-466a-b455-81b372dc223a@HUB05.ad.oak.ox.ac.uk>
	<4FF5CA45.6050902@uvic.ca>
Message-ID: <113f0faa-ce41-4aab-8d28-b0f1b1f701e6@HUB03.ad.oak.ox.ac.uk>


On 5 Jul 2012, at 18:09, Martin Holmes wrote:
> That's up to the project, surely.

isn't that sort of approach just Back to the Bad Old Days? if we're going to revisit @rend, lets
take the chance to set some better standards on interoperability and a start on a
proper processing model.

> I'd be inclined to say that if @style is present, then ignore @rend, but you could also combine the two. Redundancy in an HTML @style attribute is ignored, isn't it?


so if you met 

<p rend="bold italic" style="font-weight:normal">

you'd ignore the italic?
--
Sebastian Rahtz      
Head of Information and Support Group
Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431







From sebastian.rahtz at oucs.ox.ac.uk  Thu Jul  5 13:17:34 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Thu, 5 Jul 2012 17:17:34 +0000
Subject: [tei-council] http://purl.org/tei/fr/3519866 (@rend datatype)
In-Reply-To: <4FF5CB4E.2090600@kcl.ac.uk>
References: <4FED7CCC.1030307@oucs.ox.ac.uk>
	<4FEDA0A1.5050305@oucs.ox.ac.uk>	<4FEE091F.7060106@o2.pl>
	<4FEE12A8.5050904@uvic.ca>	<4FEF0D51.9010708@oucs.ox.ac.uk>
	<4FF5BA2B.2040503@retired.ox.ac.uk>
	<0409f830-2dc1-49f0-a117-aefd7d0b223e@HUB06.ad.oak.ox.ac.uk>
	<4FF5C7B2.7070804@uvic.ca> <4FF5CB4E.2090600@kcl.ac.uk>
Message-ID: <6DD17721-9DB4-493A-9647-6FBE7F8BB836@oucs.ox.ac.uk>


On 5 Jul 2012, at 18:13, Gabriel Bodard wrote:

> And I'm not a big fan of the token|free|css choice in the header, 
> because are we *sure* that everyone is always going to want to treat 
> @rend the same way on *all* elements?

goodness me. if they don't use @rend consistently across the document,
we might as well shoot ourselves now! you think someone may be saying

   <p rend="standout"><hi rend="font-style: italic">

??

God help us all, said Tiny Tim.
--
Sebastian Rahtz      
Head of Information and Support Group
Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431







From gabriel.bodard at kcl.ac.uk  Thu Jul  5 13:20:17 2012
From: gabriel.bodard at kcl.ac.uk (Gabriel Bodard)
Date: Thu, 5 Jul 2012 18:20:17 +0100
Subject: [tei-council] http://purl.org/tei/fr/3519866 (@rend datatype)
In-Reply-To: <6DD17721-9DB4-493A-9647-6FBE7F8BB836@oucs.ox.ac.uk>
References: <4FED7CCC.1030307@oucs.ox.ac.uk>
	<4FEDA0A1.5050305@oucs.ox.ac.uk>	<4FEE091F.7060106@o2.pl>
	<4FEE12A8.5050904@uvic.ca>	<4FEF0D51.9010708@oucs.ox.ac.uk>
	<4FF5BA2B.2040503@retired.ox.ac.uk>
	<0409f830-2dc1-49f0-a117-aefd7d0b223e@HUB06.ad.oak.ox.ac.uk>
	<4FF5C7B2.7070804@uvic.ca> <4FF5CB4E.2090600@kcl.ac.uk>
	<6DD17721-9DB4-493A-9647-6FBE7F8BB836@oucs.ox.ac.uk>
Message-ID: <4FF5CCD1.6080608@kcl.ac.uk>

Yes, exactly. I *bet* we'll see that. At least Martin's proposal of 
@style (partially) resolves that problem.

I mean, there are some things you want to highlight with @rend that 
there's no CSS syntax for.

<p rend="handwritten"><hi rend="insular-majuscule">

On 2012-07-05 18:17, Sebastian Rahtz wrote:
>
> On 5 Jul 2012, at 18:13, Gabriel Bodard wrote:
>
>> And I'm not a big fan of the token|free|css choice in the header,
>> because are we *sure* that everyone is always going to want to treat
>> @rend the same way on *all* elements?
>
> goodness me. if they don't use @rend consistently across the document,
> we might as well shoot ourselves now! you think someone may be saying
>
>     <p rend="standout"><hi rend="font-style: italic">
>
> ??
>
> God help us all, said Tiny Tim.
> --
> Sebastian Rahtz
> Head of Information and Support Group
> Oxford University Computing Services
> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>
>
>
>
>
>

-- 
Dr Gabriel BODARD
(Research Associate in Digital Epigraphy)

Department of Digital Humanities
King's College London
26-29 Drury Lane
London WC2B 5RL

Email: gabriel.bodard at kcl.ac.uk
Tel: +44 (0)20 7848 1388
Fax: +44 (0)20 7848 2980

http://www.digitalclassicist.org/
http://www.currentepigraphy.org/



From sebastian.rahtz at oucs.ox.ac.uk  Thu Jul  5 13:26:23 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Thu, 5 Jul 2012 17:26:23 +0000
Subject: [tei-council] http://purl.org/tei/fr/3519866 (@rend datatype)
In-Reply-To: <4FF5CCD1.6080608@kcl.ac.uk>
References: <4FED7CCC.1030307@oucs.ox.ac.uk>
	<4FEDA0A1.5050305@oucs.ox.ac.uk>	<4FEE091F.7060106@o2.pl>
	<4FEE12A8.5050904@uvic.ca>	<4FEF0D51.9010708@oucs.ox.ac.uk>
	<4FF5BA2B.2040503@retired.ox.ac.uk>
	<0409f830-2dc1-49f0-a117-aefd7d0b223e@HUB06.ad.oak.ox.ac.uk>
	<4FF5C7B2.7070804@uvic.ca> <4FF5CB4E.2090600@kcl.ac.uk>
	<6DD17721-9DB4-493A-9647-6FBE7F8BB836@oucs.ox.ac.uk>
	<4FF5CCD1.6080608@kcl.ac.uk>
Message-ID: <ACFAE930-54FA-4015-A374-3241A17089EF@oucs.ox.ac.uk>


On 5 Jul 2012, at 18:20, Gabriel Bodard wrote:

> Yes, exactly. I *bet* we'll see that. At least Martin's proposal of 
> @style (partially) resolves that problem.
> 
> I mean, there are some things you want to highlight with @rend that 
> there's no CSS syntax for.
> 
> <p rend="handwritten"><hi rend="insular-majuscule">


So it's
     <p rend="font-size: large"> Hello <add rend="handwritten">pussycat</add>, Happy Birthday!</p>
on one of Lou's postcards?

in that case, single-shot @rend is inutterably doomed, and Martin's @style is the
only way ahead. Unless we introduce an arcane rule that the presence of a colon
means it is CSS!

--
Sebastian Rahtz      
Head of Information and Support Group
Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431







From kevin.s.hawkins at ultraslavonic.info  Thu Jul  5 13:38:03 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Thu, 05 Jul 2012 13:38:03 -0400
Subject: [tei-council] http://purl.org/tei/fr/3519866 (@rend datatype)
In-Reply-To: <ACFAE930-54FA-4015-A374-3241A17089EF@oucs.ox.ac.uk>
References: <4FED7CCC.1030307@oucs.ox.ac.uk>
	<4FEDA0A1.5050305@oucs.ox.ac.uk>	<4FEE091F.7060106@o2.pl>
	<4FEE12A8.5050904@uvic.ca>	<4FEF0D51.9010708@oucs.ox.ac.uk>
	<4FF5BA2B.2040503@retired.ox.ac.uk>
	<0409f830-2dc1-49f0-a117-aefd7d0b223e@HUB06.ad.oak.ox.ac.uk>
	<4FF5C7B2.7070804@uvic.ca> <4FF5CB4E.2090600@kcl.ac.uk>
	<6DD17721-9DB4-493A-9647-6FBE7F8BB836@oucs.ox.ac.uk>
	<4FF5CCD1.6080608@kcl.ac.uk>
	<ACFAE930-54FA-4015-A374-3241A17089EF@oucs.ox.ac.uk>
Message-ID: <4FF5D0FB.6050504@ultraslavonic.info>

Sebastian, can you please be less cryptic?  Supposedly we're both native 
speakers of English, and I often have trouble following what you write 
on tei-council.  But your latest message completely baffles me. 
Specifically ...

On 7/5/12 1:26 PM, Sebastian Rahtz wrote:
>
> On 5 Jul 2012, at 18:20, Gabriel Bodard wrote:
>
>> Yes, exactly. I *bet* we'll see that. At least Martin's proposal of
>> @style (partially) resolves that problem.
>>
>> I mean, there are some things you want to highlight with @rend that
>> there's no CSS syntax for.
>>
>> <p rend="handwritten"><hi rend="insular-majuscule">
>
>
> So it's
>       <p rend="font-size: large"> Hello <add rend="handwritten">pussycat</add>, Happy Birthday!</p>
> on one of Lou's postcards?

I don't know whether there's anything I'm supposed to know about Lou's 
postcards.  But perhaps you meant

<p style="font-size: large">Hello <add 
rend="handwritten">pussycat</add>, Happy Birthday!</p>

?

> in that case, single-shot @rend is inutterably doomed, and Martin's @style is the
> only way ahead. Unless we introduce an arcane rule that the presence of a colon
> means it is CSS!

What is a single-shot @rend?  And what does "inutterably" mean?

--K.

From gabriel.bodard at kcl.ac.uk  Thu Jul  5 13:45:04 2012
From: gabriel.bodard at kcl.ac.uk (Gabriel Bodard)
Date: Thu, 5 Jul 2012 18:45:04 +0100
Subject: [tei-council] http://purl.org/tei/fr/3519866 (@rend datatype)
In-Reply-To: <4FF5D0FB.6050504@ultraslavonic.info>
References: <4FED7CCC.1030307@oucs.ox.ac.uk>
	<4FEDA0A1.5050305@oucs.ox.ac.uk>	<4FEE091F.7060106@o2.pl>
	<4FEE12A8.5050904@uvic.ca>	<4FEF0D51.9010708@oucs.ox.ac.uk>
	<4FF5BA2B.2040503@retired.ox.ac.uk>
	<0409f830-2dc1-49f0-a117-aefd7d0b223e@HUB06.ad.oak.ox.ac.uk>
	<4FF5C7B2.7070804@uvic.ca> <4FF5CB4E.2090600@kcl.ac.uk>
	<6DD17721-9DB4-493A-9647-6FBE7F8BB836@oucs.ox.ac.uk>
	<4FF5CCD1.6080608@kcl.ac.uk>
	<ACFAE930-54FA-4015-A374-3241A17089EF@oucs.ox.ac.uk>
	<4FF5D0FB.6050504@ultraslavonic.info>
Message-ID: <4FF5D2A0.5040909@kcl.ac.uk>

On 2012-07-05 18:38, Kevin Hawkins wrote:
> I don't know whether there's anything I'm supposed to know about Lou's
> postcards.  But perhaps you meant
>
> <p style="font-size: large">Hello <add
> rend="handwritten">pussycat</add>, Happy Birthday!</p>
> ?

That's what we hope for with Martin's new attribute, but in the status 
quo they would both be @rend, as Sebastian wrote.

>> in that case, single-shot @rend is inutterably doomed, and Martin's @style is the
>> only way ahead. Unless we introduce an arcane rule that the presence of a colon
>> means it is CSS!
>
> What is a single-shot @rend?  And what does "inutterably" mean?

I think my "single-shot @rend" he refers to the idea that the single 
attribute @rend is used to contain both css and tokens, and the XSLT 
renderer knows which is which because of some label somewhere in the 
header. I would take "inutterably" as a Bush-esque neologism, but 
clearly an intensifier. Totally doomed. Inescapably doomed. Irredeemably 
doomed. So doomed I can't even bear to say it.

:-)

-- 
Dr Gabriel BODARD
(Research Associate in Digital Epigraphy)

Department of Digital Humanities
King's College London
26-29 Drury Lane
London WC2B 5RL

Email: gabriel.bodard at kcl.ac.uk
Tel: +44 (0)20 7848 1388
Fax: +44 (0)20 7848 2980

http://www.digitalclassicist.org/
http://www.currentepigraphy.org/



From mholmes at uvic.ca  Thu Jul  5 14:17:57 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Thu, 5 Jul 2012 11:17:57 -0700
Subject: [tei-council] http://purl.org/tei/fr/3519866 (@rend datatype)
In-Reply-To: <113f0faa-ce41-4aab-8d28-b0f1b1f701e6@HUB03.ad.oak.ox.ac.uk>
References: <4FED7CCC.1030307@oucs.ox.ac.uk>
	<4FEDA0A1.5050305@oucs.ox.ac.uk>	<4FEE091F.7060106@o2.pl>
	<4FEE12A8.5050904@uvic.ca>	<4FEF0D51.9010708@oucs.ox.ac.uk>
	<4FF5BA2B.2040503@retired.ox.ac.uk> <4FF5C604.8030806@uvic.ca>
	<8d8d362f-28d9-466a-b455-81b372dc223a@HUB05.ad.oak.ox.ac.uk>
	<4FF5CA45.6050902@uvic.ca>
	<113f0faa-ce41-4aab-8d28-b0f1b1f701e6@HUB03.ad.oak.ox.ac.uk>
Message-ID: <4FF5DA55.8020904@uvic.ca>

Hi Sebastian,

On 12-07-05 10:14 AM, Sebastian Rahtz wrote:
>
> On 5 Jul 2012, at 18:09, Martin Holmes wrote:
>> That's up to the project, surely.
>
> isn't that sort of approach just Back to the Bad Old Days? if we're going to revisit @rend, lets
> take the chance to set some better standards on interoperability and a start on a
> proper processing model.

But I'm not suggesting that we revisit @rend. I've been proposing that 
we add @style instead.

>> I'd be inclined to say that if @style is present, then ignore @rend, but you could also combine the two. Redundancy in an HTML @style attribute is ignored, isn't it?
>
>
> so if you met
>
> <p rend="bold italic" style="font-weight:normal">
>
> you'd ignore the italic?

No, I didn't explain that very well. I meant that if you had this (IMHO 
silly, but possible) encoding:

<p rend="italic" style="font-style: italic">

and your XSL rules translated @rend="italic" to font-style: italic, then 
you'd have this output:

<p style="font-style: italic; font-style: italic;">

and I think such redundancy would be ignored by an HTML user-agent.

But the other option would be to say that if @style is there, ignore @rend.

Cheers,
Martin

> --
> Sebastian Rahtz
> Head of Information and Support Group
> Oxford University Computing Services
> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>
>
>
>
>
>
>

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)



From mholmes at uvic.ca  Thu Jul  5 14:20:11 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Thu, 5 Jul 2012 11:20:11 -0700
Subject: [tei-council] http://purl.org/tei/fr/3519866 (@rend datatype)
In-Reply-To: <6DD17721-9DB4-493A-9647-6FBE7F8BB836@oucs.ox.ac.uk>
References: <4FED7CCC.1030307@oucs.ox.ac.uk>
	<4FEDA0A1.5050305@oucs.ox.ac.uk>	<4FEE091F.7060106@o2.pl>
	<4FEE12A8.5050904@uvic.ca>	<4FEF0D51.9010708@oucs.ox.ac.uk>
	<4FF5BA2B.2040503@retired.ox.ac.uk>
	<0409f830-2dc1-49f0-a117-aefd7d0b223e@HUB06.ad.oak.ox.ac.uk>
	<4FF5C7B2.7070804@uvic.ca> <4FF5CB4E.2090600@kcl.ac.uk>
	<6DD17721-9DB4-493A-9647-6FBE7F8BB836@oucs.ox.ac.uk>
Message-ID: <4FF5DADB.50800@uvic.ca>

On 12-07-05 10:17 AM, Sebastian Rahtz wrote:
>
> On 5 Jul 2012, at 18:13, Gabriel Bodard wrote:
>
>> And I'm not a big fan of the token|free|css choice in the header,
>> because are we *sure* that everyone is always going to want to treat
>> @rend the same way on *all* elements?
>
> goodness me. if they don't use @rend consistently across the document,
> we might as well shoot ourselves now! you think someone may be saying
>
>     <p rend="standout"><hi rend="font-style: italic">

For a little while in one of my projects, I had exactly this, as we 
transitioned a large document collection from token values to CSS in 
@rend. I handled it easily in the XSLT by checking for a colon in the 
value; if there was a colon there, then I assumed CSS, and if not, I 
assumed one or more of the earlier token values. It worked fine.

It would be a silly approach as an encoding strategy, though.

Cheers,
Martin

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)



From lou.burnard at retired.ox.ac.uk  Thu Jul  5 14:27:57 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Thu, 05 Jul 2012 19:27:57 +0100
Subject: [tei-council] http://purl.org/tei/fr/3519866 (@rend datatype)
In-Reply-To: <4FF5CA45.6050902@uvic.ca>
References: <4FED7CCC.1030307@oucs.ox.ac.uk>
	<4FEDA0A1.5050305@oucs.ox.ac.uk>	<4FEE091F.7060106@o2.pl>
	<4FEE12A8.5050904@uvic.ca>	<4FEF0D51.9010708@oucs.ox.ac.uk>
	<4FF5BA2B.2040503@retired.ox.ac.uk> <4FF5C604.8030806@uvic.ca>
	<8d8d362f-28d9-466a-b455-81b372dc223a@HUB05.ad.oak.ox.ac.uk>
	<4FF5CA45.6050902@uvic.ca>
Message-ID: <4FF5DCAD.8060605@retired.ox.ac.uk>

On 05/07/12 18:09, Martin Holmes wrote:
s wrote:
>>
>>> I don't think that's the only solution. Surely @style (content = CSS)
>>> would solve the problem for those who want to use inline CSS?
>>
>> bother me a bit that we special-case CSS with this; and it is also not
>> clear
>> whether you can have @rend _and_ @style, ie what are precedence
>> and inheritance rules?
>
> That's up to the project, surely. Most would presumably only use one or
> the other. If you're wondering what the default TEI stylesheets should
> do, then that's another question; but the stylesheets already have to
> guess at what any given value(s) appearing in @rend are supposed to
> mean. I'd be inclined to say that if @style is present, then ignore
> @rend, but you could also combine the two. Redundancy in an HTML @style
> attribute is ignored, isn't it?
>


I can't believe we're seriously considering adding a THIRD possible way 
of specifying rendition!

But if we are, did you mean @html:style or @tei:style?

Presumably the former is always a possibility (thus giving us FOUR ways 
of saying 'output this in "Incredulous Bold"')

From mholmes at uvic.ca  Thu Jul  5 14:43:14 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Thu, 5 Jul 2012 11:43:14 -0700
Subject: [tei-council] http://purl.org/tei/fr/3519866 (@rend datatype)
In-Reply-To: <4FF5DCAD.8060605@retired.ox.ac.uk>
References: <4FED7CCC.1030307@oucs.ox.ac.uk>
	<4FEDA0A1.5050305@oucs.ox.ac.uk>	<4FEE091F.7060106@o2.pl>
	<4FEE12A8.5050904@uvic.ca>	<4FEF0D51.9010708@oucs.ox.ac.uk>
	<4FF5BA2B.2040503@retired.ox.ac.uk> <4FF5C604.8030806@uvic.ca>
	<8d8d362f-28d9-466a-b455-81b372dc223a@HUB05.ad.oak.ox.ac.uk>
	<4FF5CA45.6050902@uvic.ca> <4FF5DCAD.8060605@retired.ox.ac.uk>
Message-ID: <4FF5E042.9070609@uvic.ca>

On 12-07-05 11:27 AM, Lou Burnard wrote:
> On 05/07/12 18:09, Martin Holmes wrote:
> s wrote:
>>>
>>>> I don't think that's the only solution. Surely @style (content = CSS)
>>>> would solve the problem for those who want to use inline CSS?
>>>
>>> bother me a bit that we special-case CSS with this; and it is also not
>>> clear
>>> whether you can have @rend _and_ @style, ie what are precedence
>>> and inheritance rules?
>>
>> That's up to the project, surely. Most would presumably only use one or
>> the other. If you're wondering what the default TEI stylesheets should
>> do, then that's another question; but the stylesheets already have to
>> guess at what any given value(s) appearing in @rend are supposed to
>> mean. I'd be inclined to say that if @style is present, then ignore
>> @rend, but you could also combine the two. Redundancy in an HTML @style
>> attribute is ignored, isn't it?
>>
>
>
> I can't believe we're seriously considering adding a THIRD possible way
> of specifying rendition!
>
> But if we are, did you mean @html:style or @tei:style?

As far as I know, there is no such thing as either of these. The @style 
in XHTML is a regular attribute, and therefore exists in the 
no-namespace namespace; and the same would apply to @style if defined in 
TEI:

"Attributes are never subject to the default namespace. An attribute 
without an explicit namespace prefix is considered not to be in any 
namespace."

<http://en.wikipedia.org/wiki/XML_namespace>

So TEI's @rend attribute is not @tei:rend (it's not in the TEI 
namespace), and HTML's @style is similarly not in the XHTML namespace. 
And as far as I know, there is no way to import an attribute (such as 
@style) from an external schema unless it has an explicitly-defined 
namespace, which HTML's @style doesn't AFAIK.

So there's no way to use HTML's @style anyway. We might define our 
@style to be identical to it, if that suits us, but since that is

style = CDATA [...] The syntax of the value of the style attribute is 
determined by the default style sheet language...

that doesn't help us much. I would prefer to define it as CSS, and add 
some Schematron rules to enforce the syntax. (We don't want to define 
constrain the actual ruleset content because CSS is a developing standard.)

> Presumably the former is always a possibility (thus giving us FOUR ways
> of saying 'output this in "Incredulous Bold"')

I think we have only @rendition and @rend so far. @style would make 
three, but it has significant advantages over @rend because it uses an 
existing and powerful standard, and is easy to handle in rendering.

Cheers,
Martin

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)



From syeates at gmail.com  Thu Jul  5 14:55:54 2012
From: syeates at gmail.com (stuart yeates)
Date: Fri, 06 Jul 2012 06:55:54 +1200
Subject: [tei-council] proposed new <entry/> example with xml:lang
	attributes
In-Reply-To: <4FF58C78.2050008@uvic.ca>
References: <4FF5542E.80206@gmail.com> <4FF58C78.2050008@uvic.ca>
Message-ID: <4FF5E33A.9000408@gmail.com>

On 06/07/12 00:45, Martin Holmes wrote:
> HI Stuart,
>
> I don't see "biggs" or "modern" in the subtag registry. If these are
> unregistered, shouldn't you be using "-x-"?

Yes.

cheers
stuart

From syeates at gmail.com  Thu Jul  5 15:05:34 2012
From: syeates at gmail.com (stuart yeates)
Date: Fri, 06 Jul 2012 07:05:34 +1200
Subject: [tei-council] proposed new <entry/> example with xml:lang
	attributes
In-Reply-To: <4FF56E8A.4010609@o2.pl>
References: <4FF5542E.80206@gmail.com> <4FF56AC7.9090800@ultraslavonic.info>
	<4FF56E8A.4010609@o2.pl>
Message-ID: <4FF5E57E.6000500@gmail.com>

On 05/07/12 22:38, Piotr Banski wrote:
> Hi all,
>
> I somehow managed to miss the @corresp proposal, need to search the past
> messages, I guess.

There's a good long example / discussion at:

http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-att.global.linking.html

> I had the impression that one would normally go for the same "box"
> containing the translation (equivalent), whether it corresponds to the
> <trans> or <dicteg> of old:
>
> equivalent:
>
> <cit type="translation">
> <quote>--equivalent--</quote>
> </cit>
>
> example:
>
> <cit type="example">
> <quote>--example here--</quote>
> <cit type="translation">
> <quote>--translation of the example--</quote>
> </cit>
> </cit>
>
> On this approach, there is probably (?) no need for @corresp, because
> the relevant relationship is expressed by containment.

If that is true (and it may be) then we can write xslt to regularize 
these dictionary entries to standard TEI, but I'm not seeing that level 
of consistency.

> Or am I missing the point? (scanning mails ultraquickly today, apologies
> in advance)

The point is that I'm trying to be consistent, consistent identification 
of parallel texts, consistent with the use of xml:lang in other kinds of 
XML.

cheers
stuart

From syeates at gmail.com  Thu Jul  5 16:41:36 2012
From: syeates at gmail.com (Stuart A. Yeates)
Date: Fri, 6 Jul 2012 08:41:36 +1200
Subject: [tei-council] proposed new <entry/> example with xml:lang
	attributes
In-Reply-To: <4FF5E57E.6000500@gmail.com>
References: <4FF5542E.80206@gmail.com> <4FF56AC7.9090800@ultraslavonic.info>
	<4FF56E8A.4010609@o2.pl> <4FF5E57E.6000500@gmail.com>
Message-ID: <CAC_Lu0aiq0ErQ8zU4L=+cdcyXSFo6W5b_AzRGJtVgTYzy6BgrQ@mail.gmail.com>

The more I think about it,

 <etym>
  <lang>French</lang> <mentioned xml:lang="fr">oui oui</mentioned>
 </etym>

should actually be

<langUsage>
 <language ident="fr" xml:id="french">French</language>
  ...
</langUsage>

...

 <etym>
  <lang corresp="#french">French</lang> <mentioned xml:lang="fr">oui
oui</mentioned>
 </etym>

cheers
stuart


On Fri, Jul 6, 2012 at 7:05 AM, stuart yeates <syeates at gmail.com> wrote:
> On 05/07/12 22:38, Piotr Banski wrote:
>>
>> Hi all,
>>
>> I somehow managed to miss the @corresp proposal, need to search the past
>> messages, I guess.
>
>
> There's a good long example / discussion at:
>
> http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-att.global.linking.html
>
>
>> I had the impression that one would normally go for the same "box"
>> containing the translation (equivalent), whether it corresponds to the
>> <trans> or <dicteg> of old:
>>
>> equivalent:
>>
>> <cit type="translation">
>> <quote>--equivalent--</quote>
>> </cit>
>>
>> example:
>>
>> <cit type="example">
>> <quote>--example here--</quote>
>> <cit type="translation">
>> <quote>--translation of the example--</quote>
>> </cit>
>> </cit>
>>
>> On this approach, there is probably (?) no need for @corresp, because
>> the relevant relationship is expressed by containment.
>
>
> If that is true (and it may be) then we can write xslt to regularize these
> dictionary entries to standard TEI, but I'm not seeing that level of
> consistency.
>
>
>> Or am I missing the point? (scanning mails ultraquickly today, apologies
>> in advance)
>
>
> The point is that I'm trying to be consistent, consistent identification of
> parallel texts, consistent with the use of xml:lang in other kinds of XML.
>
> cheers
> stuart

From sebastian.rahtz at oucs.ox.ac.uk  Thu Jul  5 17:54:28 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Thu, 5 Jul 2012 21:54:28 +0000
Subject: [tei-council] http://purl.org/tei/fr/3519866 (@rend datatype)
In-Reply-To: <4FF5E042.9070609@uvic.ca>
References: <4FED7CCC.1030307@oucs.ox.ac.uk>
	<4FEDA0A1.5050305@oucs.ox.ac.uk>	<4FEE091F.7060106@o2.pl>
	<4FEE12A8.5050904@uvic.ca>	<4FEF0D51.9010708@oucs.ox.ac.uk>
	<4FF5BA2B.2040503@retired.ox.ac.uk> <4FF5C604.8030806@uvic.ca>
	<8d8d362f-28d9-466a-b455-81b372dc223a@HUB05.ad.oak.ox.ac.uk>
	<4FF5CA45.6050902@uvic.ca> <4FF5DCAD.8060605@retired.ox.ac.uk>
	<4FF5E042.9070609@uvic.ca>
Message-ID: <5c09c47c-11d1-4755-b43b-9da4880770b4@HUB06.ad.oak.ox.ac.uk>


On 5 Jul 2012, at 19:43, Martin Holmes wrote:

> 
> I think we have only @rendition and @rend so far. @style would make three, but it has significant advantages over @rend because it uses an existing and powerful standard, and is easy to handle in rendering.
> 

hmm. in _some_ rendering situations.

I am slightly worried that we have engineered @rendition to be potentially independent of CSS, but are talking of tying down @style explicitly to CSS, so not
as elegant symmetry as one would like.  Still, I would always vote for short-term pragmatism, so count me in.

--
Sebastian Rahtz      
Head of Information and Support Group
Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431







From sebastian.rahtz at oucs.ox.ac.uk  Thu Jul  5 18:01:32 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Thu, 5 Jul 2012 22:01:32 +0000
Subject: [tei-council] http://purl.org/tei/fr/3519866 (@rend datatype)
In-Reply-To: <4FF5D0FB.6050504@ultraslavonic.info>
References: <4FED7CCC.1030307@oucs.ox.ac.uk>
	<4FEDA0A1.5050305@oucs.ox.ac.uk>	<4FEE091F.7060106@o2.pl>
	<4FEE12A8.5050904@uvic.ca>	<4FEF0D51.9010708@oucs.ox.ac.uk>
	<4FF5BA2B.2040503@retired.ox.ac.uk>
	<0409f830-2dc1-49f0-a117-aefd7d0b223e@HUB06.ad.oak.ox.ac.uk>
	<4FF5C7B2.7070804@uvic.ca> <4FF5CB4E.2090600@kcl.ac.uk>
	<6DD17721-9DB4-493A-9647-6FBE7F8BB836@oucs.ox.ac.uk>
	<4FF5CCD1.6080608@kcl.ac.uk>
	<ACFAE930-54FA-4015-A374-3241A17089EF@oucs.ox.ac.uk>
	<4FF5D0FB.6050504@ultraslavonic.info>
Message-ID: <BA0F1660-43A0-4EE8-A25D-27267E7D2D20@oucs.ox.ac.uk>


On 5 Jul 2012, at 18:38, Kevin Hawkins wrote:

> Sebastian, can you please be less cryptic?  

Sorry, not deliberate at all. Just a combination of poor typing skills,
Apple auto-"correct", my incipient dementia, and being in a hurry.

>> So it's
>>      <p rend="font-size: large"> Hello <add rend="handwritten">pussycat</add>, Happy Birthday!</p>
>> on one of Lou's postcards?
> 
> I don't know whether there's anything I'm supposed to know about Lou's 
> postcards.

Lou has recently been promoting the idea of using a corpus of picture postcards
in TEI teaching

>  But perhaps you meant
> 
> <p style="font-size: large">Hello <add 
> rend="handwritten">pussycat</add>, Happy Birthday!</p>
> 

no, I meant to give an example of the nonsensical situation we can end up
with if we use @rend for everything.

> What is a single-shot @rend?

"put whatever you like in just the single attribute, @rend. you only get one shot at the target."

I agree, that was pretty obscure, sorry. It was elegant, though :-}

>  And what does "inutterably" mean?
> 
unutterably.

--
Sebastian Rahtz      
Head of Information and Support Group
Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431







From mholmes at uvic.ca  Fri Jul  6 13:05:39 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Fri, 6 Jul 2012 10:05:39 -0700
Subject: [tei-council] Unintended comments showing up in GLines
Message-ID: <4FF71AE3.4000000@uvic.ca>

Hi all,

Take a look at the example on this page:

<http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-valList.html>

Lou's comment and commented-out stuff is showing up, and it shouldn't. I 
think this is just a question of going in and deleting the stuff, but 
I'll leave it to Lou to do in case he wants to leave an explanation of 
what was commented out outside of the <egXML>.

Cheers,
Martin
-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)


From lou.burnard at retired.ox.ac.uk  Fri Jul  6 13:16:22 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Fri, 06 Jul 2012 18:16:22 +0100
Subject: [tei-council] Unintended comments showing up in GLines
In-Reply-To: <4FF71AE3.4000000@uvic.ca>
References: <4FF71AE3.4000000@uvic.ca>
Message-ID: <4FF71D66.9050107@retired.ox.ac.uk>

On 06/07/12 18:05, Martin Holmes wrote:
> Hi all,
>
> Take a look at the example on this page:
>
> <http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-valList.html>
>
> Lou's comment and commented-out stuff is showing up, and it shouldn't. I
> think this is just a question of going in and deleting the stuff, but
> I'll leave it to Lou to do in case he wants to leave an explanation of
> what was commented out outside of the <egXML>.
>

LR is Laurent in fact, but I've deleted the comment anyway.

Comments inside <egXML> in my view *should* be showing up. This is not 
an error.






From mholmes at uvic.ca  Fri Jul  6 13:41:25 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Fri, 6 Jul 2012 10:41:25 -0700
Subject: [tei-council] Default values in valList
Message-ID: <4FF72345.2090901@uvic.ca>

I have a question about the creation of RNG schemas from ODD files. I 
have a situation in which I want to specify a closed list of values for 
an attribute, but without a default value. If I specify any kind of list 
(closed or semi), Roma generates the RNG schema with the first value set 
as default.

This is a problem because it makes it impossible to do any kind of 
Schematron check to see if the attribute exists; it appears that where 
the attribute is specified in the RNG schema as having a default value, 
a Schematron assertion like this:

<assert test="@status">

will not fire. If I manually delete the default value setting from the 
generated RNG file, then the Schematron constraint DOES fire, but I 
often regenerate my schemas from my ODD file, so I'd need to remember to 
go in and delete that default value every time.

This is all a surprise to me, because I had not suspected that 
Schematron referred to the RNG file at all, but it seems to; it appears 
to test its assertions against the XML file as expanded with default 
attribute values based on the RNG schema.

Has anyone come across this? Is it meaningful to have a closed value 
list with no default value? (RNG seems to allow it.) Should Roma force a 
default value on the schema even though none has been specified?

Cheers,
Martin

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)


From mholmes at uvic.ca  Fri Jul  6 13:53:55 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Fri, 6 Jul 2012 10:53:55 -0700
Subject: [tei-council] Default values in valList
In-Reply-To: <4FF72345.2090901@uvic.ca>
References: <4FF72345.2090901@uvic.ca>
Message-ID: <4FF72633.9090103@uvic.ca>

Sorry, I withdraw this. I hadn't realized that "draft" was set as a 
<defaultVal> in att.docStatus.xml. I just needed to override that.

Cheers,
Martin

On 12-07-06 10:41 AM, Martin Holmes wrote:
> I have a question about the creation of RNG schemas from ODD files. I
> have a situation in which I want to specify a closed list of values for
> an attribute, but without a default value. If I specify any kind of list
> (closed or semi), Roma generates the RNG schema with the first value set
> as default.
>
> This is a problem because it makes it impossible to do any kind of
> Schematron check to see if the attribute exists; it appears that where
> the attribute is specified in the RNG schema as having a default value,
> a Schematron assertion like this:
>
> <assert test="@status">
>
> will not fire. If I manually delete the default value setting from the
> generated RNG file, then the Schematron constraint DOES fire, but I
> often regenerate my schemas from my ODD file, so I'd need to remember to
> go in and delete that default value every time.
>
> This is all a surprise to me, because I had not suspected that
> Schematron referred to the RNG file at all, but it seems to; it appears
> to test its assertions against the XML file as expanded with default
> attribute values based on the RNG schema.
>
> Has anyone come across this? Is it meaningful to have a closed value
> list with no default value? (RNG seems to allow it.) Should Roma force a
> default value on the schema even though none has been specified?
>
> Cheers,
> Martin
>

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)



From mholmes at uvic.ca  Fri Jul  6 13:55:14 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Fri, 6 Jul 2012 10:55:14 -0700
Subject: [tei-council] Unintended comments showing up in GLines
In-Reply-To: <4FF71D66.9050107@retired.ox.ac.uk>
References: <4FF71AE3.4000000@uvic.ca> <4FF71D66.9050107@retired.ox.ac.uk>
Message-ID: <4FF72682.80608@uvic.ca>

Sorry Lou -- should be able to tell the difference between LR and LB. I 
know that comments are supposed to show up; I just meant that those 
particular ones were not intended by the commenter to show up.

Cheers,
Martin

On 12-07-06 10:16 AM, Lou Burnard wrote:
> On 06/07/12 18:05, Martin Holmes wrote:
>> Hi all,
>>
>> Take a look at the example on this page:
>>
>> <http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-valList.html>
>>
>> Lou's comment and commented-out stuff is showing up, and it shouldn't. I
>> think this is just a question of going in and deleting the stuff, but
>> I'll leave it to Lou to do in case he wants to leave an explanation of
>> what was commented out outside of the <egXML>.
>>
>
> LR is Laurent in fact, but I've deleted the comment anyway.
>
> Comments inside <egXML> in my view *should* be showing up. This is not
> an error.
>
>
>
>
>

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)



From lou.burnard at retired.ox.ac.uk  Fri Jul  6 15:52:33 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Fri, 06 Jul 2012 20:52:33 +0100
Subject: [tei-council] editors@tei-c.org
In-Reply-To: <11731401098501363@jngomktg.net>
References: <11731401098501363@jngomktg.net>
Message-ID: <4FF74201.7020700@retired.ox.ac.uk>

This latest piece of spam reminds me that I think it's probably time to 
wind down the address "editors at tei-c.org", either by making it point to 
a black hole somewhere, or bounce. I cannot remember having seen 
anything but spam addressed to it in the last five-plus years.

I assume it's somewhere in the depths of the UVA website that this 
redirection takes place, so knocking it on the head is presumably David 
Sewell's job?


-------- Original Message --------
Subject: 	Advertising on www.tei-c.org
Date: 	Fri, 6 Jul 2012 19:30:43 +0000
From: 	<advertising at sparkplusmedia.com>
Reply-To: 	<advertising at sparkplusmedia.com>
To: 	<editors at tei-c.org>



Hello,

I am Tammy with Spark Plus Media. My company represents a leading book
and ebook publishing company . They would like to purchase ad space on
your site's page, www.tei-c.org/release/doc/tei-p5-doc/en/html/SG.html.

Ideally, we'd like to mention our client in a sentence on your site,
which would link to our client's site. We could pay you via PayPal as
soon as an agreement is made.

Please let me know if you are interested so we can discuss the details.
Thanks for your time and consideration.

Tammy
Advertising Representative
Spark Plus Media
www.sparkplusmedia.com

Reference Code: 1114413#




From dsewell at virginia.edu  Fri Jul  6 16:00:34 2012
From: dsewell at virginia.edu (David Sewell)
Date: Fri, 6 Jul 2012 16:00:34 -0400 (EDT)
Subject: [tei-council] editors@tei-c.org
In-Reply-To: <4FF74201.7020700@retired.ox.ac.uk>
References: <11731401098501363@jngomktg.net>
	<4FF74201.7020700@retired.ox.ac.uk>
Message-ID: <alpine.OSX.2.00.1207061556260.95447@lister.ei.virginia.edu>

Currently, editors at tei-c.org delivers to you and Syd.

It's easy enough to delete the alias, but before we undertake that it might be 
worth considering the results of this Goggle query:

http://www.google.com/search?q=%22editors+tei-c.org%22&sitesearch=http%3A%2F%2Fwww.tei-c.org%2F

A lot of those references are in Vault aka archival documents, but that address 
has been out there for a long time and it might not be politic to start 
bouncing email addressed to it.

But if everyone agrees, I can remove it and excise references to it where I find 
them on tei-c.org; that would need to be done in the generated Guidelines as 
well.

David

On Fri, 6 Jul 2012, Lou Burnard wrote:

> This latest piece of spam reminds me that I think it's probably time to
> wind down the address "editors at tei-c.org", either by making it point to
> a black hole somewhere, or bounce. I cannot remember having seen
> anything but spam addressed to it in the last five-plus years.
>
> I assume it's somewhere in the depths of the UVA website that this
> redirection takes place, so knocking it on the head is presumably David
> Sewell's job?
>
>
> -------- Original Message --------
> Subject: 	Advertising on www.tei-c.org
> Date: 	Fri, 6 Jul 2012 19:30:43 +0000
> From: 	<advertising at sparkplusmedia.com>
> Reply-To: 	<advertising at sparkplusmedia.com>
> To: 	<editors at tei-c.org>
>
>
>
> Hello,
>
> I am Tammy with Spark Plus Media. My company represents a leading book
> and ebook publishing company . They would like to purchase ad space on
> your site's page, www.tei-c.org/release/doc/tei-p5-doc/en/html/SG.html.
>
> Ideally, we'd like to mention our client in a sentence on your site,
> which would link to our client's site. We could pay you via PayPal as
> soon as an agreement is made.
>
> Please let me know if you are interested so we can discuss the details.
> Thanks for your time and consideration.
>
> Tammy
> Advertising Representative
> Spark Plus Media
> www.sparkplusmedia.com
>
> Reference Code: 1114413#
>
>
>
>

-- 
David Sewell, Editorial and Technical Manager
ROTUNDA, The University of Virginia Press
PO Box 400314, Charlottesville, VA 22904-4314 USA
Email: dsewell at virginia.edu   Tel: +1 434 924 9973
Web: http://rotunda.upress.virginia.edu/

From lou.burnard at retired.ox.ac.uk  Fri Jul  6 17:20:18 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Fri, 06 Jul 2012 22:20:18 +0100
Subject: [tei-council] editors@tei-c.org
In-Reply-To: <alpine.OSX.2.00.1207061556260.95447@lister.ei.virginia.edu>
References: <11731401098501363@jngomktg.net>
	<4FF74201.7020700@retired.ox.ac.uk>
	<alpine.OSX.2.00.1207061556260.95447@lister.ei.virginia.edu>
Message-ID: <4FF75692.6080403@retired.ox.ac.uk>

On 06/07/12 21:00, David Sewell wrote:
> Currently, editors at tei-c.org delivers to you and Syd.

Well, if that address is meant to go anywhere it ought probably to go 
the Council, since the role of "editor" was abolished several years ago. 
And Syd hasn't been involved officially for years either!

But since, as I said, it hasn't delivered anything but spam for years, I 
cannot see any reason to prolong its life.

>
> It's easy enough to delete the alias, but before we undertake that it
> might be worth considering the results of this Goggle query:
>
> http://www.google.com/search?q=%22editors+tei-c.org%22&sitesearch=http%3A%2F%2Fwww.tei-c.org%2F
>

Surely all this proves is that addresses on fairly static web pages are 
likely to be harvested for spambots?


>
> A lot of those references are in Vault aka archival documents, but that
> address has been out there for a long time and it might not be politic
> to start bouncing email addressed to it.


>
> But if everyone agrees, I can remove it and excise references to it
> where I find them on tei-c.org; that would need to be done in the
> generated Guidelines as well.

The only place this address appears in the Guidelines is as an example 
in the spec for the email element, which I have just zapped it.

yrs

Gamp


From mholmes at uvic.ca  Fri Jul  6 18:21:53 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Fri, 6 Jul 2012 15:21:53 -0700
Subject: [tei-council] CH and Language Tags
In-Reply-To: <4FF460BE.2020706@uvic.ca>
References: <4FF460BE.2020706@uvic.ca>
Message-ID: <4FF76501.3080205@uvic.ca>

Last call for responses on this. If no-one has any objections, I'm going 
to go ahead and do it in the next couple of days...

On 12-07-04 08:26 AM, Martin Holmes wrote:
> Hi all,
>
> The more I look at the instructions for constructing language tags in
> the CH chapter, the less I like them. I do, however, like these two
> excellent guides, one higher-level and the other more practical:
>
> <http://www.w3.org/International/articles/language-tags/>
>
> <http://www.w3.org/International/questions/qa-choosing-language-tags>
>
> I'm inclined to replace all of our confusing and outdated info with
> something which simply says:
>
>    - BCP47 is the authoritative guide to best practice.
>
>    - IANA's language subtag registry is the authoritative list of
> recommended subtags.
>
>    - The first document above (language-tags) gives a solid overview of
> the process of constructing language tags.
>
> - The second document (qa-choosing-language-tags) gives a detailed set
> of step-by-step instructions for choosing appropriate language tags.
>
> Does anyone see any objection to this? Right now we have vague and
> misleading instructions, and although we could rewrite them, where
> better authoritative sources exist, it makes more sense, I think, to
> refer readers to them.
>
> Cheers,
> Martin
>

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)



From kevin.s.hawkins at ultraslavonic.info  Sat Jul  7 15:29:09 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Sat, 07 Jul 2012 15:29:09 -0400
Subject: [tei-council] editors@tei-c.org
In-Reply-To: <4FF75692.6080403@retired.ox.ac.uk>
References: <11731401098501363@jngomktg.net>
	<4FF74201.7020700@retired.ox.ac.uk>
	<alpine.OSX.2.00.1207061556260.95447@lister.ei.virginia.edu>
	<4FF75692.6080403@retired.ox.ac.uk>
Message-ID: <4FF88E05.2090101@ultraslavonic.info>

On 7/6/12 5:20 PM, Lou Burnard wrote:
> On 06/07/12 21:00, David Sewell wrote:
>> Currently, editors at tei-c.org delivers to you and Syd.
>
> Well, if that address is meant to go anywhere it ought probably to go
> the Council, since the role of "editor" was abolished several years ago.
> And Syd hasn't been involved officially for years either!
>
> But since, as I said, it hasn't delivered anything but spam for years, I
> cannot see any reason to prolong its life.
>
>>
>> It's easy enough to delete the alias, but before we undertake that it
>> might be worth considering the results of this Goggle query:
>>
>> http://www.google.com/search?q=%22editors+tei-c.org%22&sitesearch=http%3A%2F%2Fwww.tei-c.org%2F
>>
>
> Surely all this proves is that addresses on fairly static web pages are
> likely to be harvested for spambots?

No, that's not all this proves.  See these three prominent pages that 
give that address:

http://www.tei-c.org/Guidelines/Customization/

http://www.tei-c.org/About/contact.xml

http://www.tei-c.org/Activities/SIG/rules.xml

I am happy to update them but am not sure how to change them.

>> A lot of those references are in Vault aka archival documents, but that
>> address has been out there for a long time and it might not be politic
>> to start bouncing email addressed to it.

I'm okay with bouncing to an address found in Vault documents, in past 
minutes, working papers, etc. ... but not in webpages that are actively 
maintained.

--Kevin


From lou.burnard at retired.ox.ac.uk  Sat Jul  7 17:54:18 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Sat, 7 Jul 2012 21:54:18 +0000
Subject: [tei-council] editors@tei-c.org
In-Reply-To: <4FF88E05.2090101@ultraslavonic.info>
References: <11731401098501363@jngomktg.net>
	<4FF74201.7020700@retired.ox.ac.uk>
	<alpine.OSX.2.00.1207061556260.95447@lister.ei.virginia.edu>
	<4FF75692.6080403@retired.ox.ac.uk>,
	<4FF88E05.2090101@ultraslavonic.info>
Message-ID: <762A68C71238E2469EBDCDF70ADB24940734E3@MBX01.ad.oak.ox.ac.uk>


http://www.tei-c.org/Guidelines/Customization/

http://www.tei-c.org/About/contact.xml

http://www.tei-c.org/Activities/SIG/rules.xml

I am happy to update them but am not sure how to change them.


In each case, I'd suggest simply deleting the sentence that refers to editors at tei-c.org  .

I note that the last one still refers to Susan Schreibman as the point of contact for would-be sig-makers. 


From kevin.s.hawkins at ultraslavonic.info  Sat Jul  7 18:05:38 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Sat, 07 Jul 2012 18:05:38 -0400
Subject: [tei-council] editors@tei-c.org
In-Reply-To: <762A68C71238E2469EBDCDF70ADB24940734E3@MBX01.ad.oak.ox.ac.uk>
References: <11731401098501363@jngomktg.net>
	<4FF74201.7020700@retired.ox.ac.uk>
	<alpine.OSX.2.00.1207061556260.95447@lister.ei.virginia.edu>
	<4FF75692.6080403@retired.ox.ac.uk>,
	<4FF88E05.2090101@ultraslavonic.info>
	<762A68C71238E2469EBDCDF70ADB24940734E3@MBX01.ad.oak.ox.ac.uk>
Message-ID: <4FF8B2B2.7020401@ultraslavonic.info>

On 7/7/12 5:54 PM, Lou Burnard wrote:
>
> http://www.tei-c.org/Guidelines/Customization/
>
> http://www.tei-c.org/About/contact.xml
>
> http://www.tei-c.org/Activities/SIG/rules.xml
>
> I am happy to update them but am not sure how to change them.
>
>
> In each case, I'd suggest simply deleting the sentence that refers to editors at tei-c.org  .

Will do, but first ...

> I note that the last one still refers to Susan Schreibman as the point of contact for would-be sig-makers.

... has the Board appointed a new SIG coordinator?

From James.Cummings at oucs.ox.ac.uk  Sun Jul  8 11:25:02 2012
From: James.Cummings at oucs.ox.ac.uk (James Cummings)
Date: Sun, 08 Jul 2012 16:25:02 +0100
Subject: [tei-council] editors@tei-c.org
In-Reply-To: <4FF8B2B2.7020401@ultraslavonic.info>
References: <11731401098501363@jngomktg.net>
	<4FF74201.7020700@retired.ox.ac.uk>
	<alpine.OSX.2.00.1207061556260.95447@lister.ei.virginia.edu>
	<4FF75692.6080403@retired.ox.ac.uk>,
	<4FF88E05.2090101@ultraslavonic.info>
	<762A68C71238E2469EBDCDF70ADB24940734E3@MBX01.ad.oak.ox.ac.uk>
	<4FF8B2B2.7020401@ultraslavonic.info>
Message-ID: <4FF9A64E.3060409@oucs.ox.ac.uk>


Apologies for the delay in responding, it has been our summer 
school here the last week and I'm just catching up on emails I 
didn't have time to answer.

In the case of editors at tei-c.org what about changing this to 
council at tei-c.org which goes to the council chair?  I don't mind 
filtering out the extra spam.

-James


On 07/07/12 23:05, Kevin Hawkins wrote:
> On 7/7/12 5:54 PM, Lou Burnard wrote:
>>
>> http://www.tei-c.org/Guidelines/Customization/
>>
>> http://www.tei-c.org/About/contact.xml
>>
>> http://www.tei-c.org/Activities/SIG/rules.xml
>>
>> I am happy to update them but am not sure how to change them.
>>
>>
>> In each case, I'd suggest simply deleting the sentence that refers to editors at tei-c.org  .
>
> Will do, but first ...
>
>> I note that the last one still refers to Susan Schreibman as the point of contact for would-be sig-makers.
>
> ... has the Board appointed a new SIG coordinator?


-- 
Dr James Cummings, InfoDev
Oxford University Computing Services
University of Oxford

From dsewell at virginia.edu  Sun Jul  8 16:48:24 2012
From: dsewell at virginia.edu (David Sewell)
Date: Sun, 8 Jul 2012 16:48:24 -0400 (EDT)
Subject: [tei-council] editors@tei-c.org
In-Reply-To: <4FF9A64E.3060409@oucs.ox.ac.uk>
References: <11731401098501363@jngomktg.net>
	<4FF74201.7020700@retired.ox.ac.uk>
	<alpine.OSX.2.00.1207061556260.95447@lister.ei.virginia.edu>
	<4FF75692.6080403@retired.ox.ac.uk>,
	<4FF88E05.2090101@ultraslavonic.info>
	<762A68C71238E2469EBDCDF70ADB24940734E3@MBX01.ad.oak.ox.ac.uk>
	<4FF8B2B2.7020401@ultraslavonic.info> <4FF9A64E.3060409@oucs.ox.ac.uk>
Message-ID: <alpine.OSX.2.00.1207081646010.3631@va-67-233-115-16.dhcp.embarqhsd.net>

There are two likely candidates for replacing editors at tei-c.org where 
needed, the council@ alias as James notes, and info at tei-c.org, which is 
the current catch-all that comes to me. I have a pretty good mechanism 
for spam filtering so I don't mind revising pages to redirect there (if 
Kevin hasn't already done some rewriting).

Can we come to a consensus on this by tomorrow? (I'm going to be offline 
shortly tonight as here in central VA we've had yet another massive 
thunderstorm that has taken out the house power, and I'm running on the 
UPS at the moment.)

David

On Sun, 8 Jul 2012, James Cummings wrote:

>
> Apologies for the delay in responding, it has been our summer
> school here the last week and I'm just catching up on emails I
> didn't have time to answer.
>
> In the case of editors at tei-c.org what about changing this to
> council at tei-c.org which goes to the council chair?  I don't mind
> filtering out the extra spam.
>
> -James
>
>
> On 07/07/12 23:05, Kevin Hawkins wrote:
>> On 7/7/12 5:54 PM, Lou Burnard wrote:
>>>
>>> http://www.tei-c.org/Guidelines/Customization/
>>>
>>> http://www.tei-c.org/About/contact.xml
>>>
>>> http://www.tei-c.org/Activities/SIG/rules.xml
>>>
>>> I am happy to update them but am not sure how to change them.
>>>
>>>
>>> In each case, I'd suggest simply deleting the sentence that refers to editors at tei-c.org  .
>>
>> Will do, but first ...
>>
>>> I note that the last one still refers to Susan Schreibman as the point of contact for would-be sig-makers.
>>
>> ... has the Board appointed a new SIG coordinator?
>
>
>

-- 
David Sewell, Editorial and Technical Manager
ROTUNDA, The University of Virginia Press
PO Box 400314, Charlottesville, VA 22904-4314 USA
Email: dsewell at virginia.edu   Tel: +1 434 924 9973
Web: http://rotunda.upress.virginia.edu/

From James.Cummings at oucs.ox.ac.uk  Mon Jul  9 05:08:23 2012
From: James.Cummings at oucs.ox.ac.uk (James Cummings)
Date: Mon, 09 Jul 2012 10:08:23 +0100
Subject: [tei-council] editors@tei-c.org
In-Reply-To: <alpine.OSX.2.00.1207081646010.3631@va-67-233-115-16.dhcp.embarqhsd.net>
References: <11731401098501363@jngomktg.net>
	<4FF74201.7020700@retired.ox.ac.uk>
	<alpine.OSX.2.00.1207061556260.95447@lister.ei.virginia.edu>
	<4FF75692.6080403@retired.ox.ac.uk>,
	<4FF88E05.2090101@ultraslavonic.info>
	<762A68C71238E2469EBDCDF70ADB24940734E3@MBX01.ad.oak.ox.ac.uk>
	<4FF8B2B2.7020401@ultraslavonic.info>
	<4FF9A64E.3060409@oucs.ox.ac.uk>
	<alpine.OSX.2.00.1207081646010.3631@va-67-233-115-16.dhcp.embarqhsd.net>
Message-ID: <4FFA9F87.6050007@oucs.ox.ac.uk>


I'm more than happy for a blanket conversion to info at tei-c.org 
... I'm sure David will forward anything to Council that is relevant.

Thanks David!

-James


On 08/07/12 21:48, David Sewell wrote:
> There are two likely candidates for replacing editors at tei-c.org
> where needed, the council@ alias as James notes, and
> info at tei-c.org, which is the current catch-all that comes to me.
> I have a pretty good mechanism for spam filtering so I don't mind
> revising pages to redirect there (if Kevin hasn't already done
> some rewriting).
>
> Can we come to a consensus on this by tomorrow? (I'm going to be
> offline shortly tonight as here in central VA we've had yet
> another massive thunderstorm that has taken out the house power,
> and I'm running on the UPS at the moment.)
>
> David
>
> On Sun, 8 Jul 2012, James Cummings wrote:
>
>>
>> Apologies for the delay in responding, it has been our summer
>> school here the last week and I'm just catching up on emails I
>> didn't have time to answer.
>>
>> In the case of editors at tei-c.org what about changing this to
>> council at tei-c.org which goes to the council chair? I don't mind
>> filtering out the extra spam.
>>
>> -James
>>
>>
>> On 07/07/12 23:05, Kevin Hawkins wrote:
>>> On 7/7/12 5:54 PM, Lou Burnard wrote:
>>>>
>>>> http://www.tei-c.org/Guidelines/Customization/
>>>>
>>>> http://www.tei-c.org/About/contact.xml
>>>>
>>>> http://www.tei-c.org/Activities/SIG/rules.xml
>>>>
>>>> I am happy to update them but am not sure how to change them.
>>>>
>>>>
>>>> In each case, I'd suggest simply deleting the sentence that
>>>> refers to editors at tei-c.org .
>>>
>>> Will do, but first ...
>>>
>>>> I note that the last one still refers to Susan Schreibman as
>>>> the point of contact for would-be sig-makers.
>>>
>>> ... has the Board appointed a new SIG coordinator?
>>
>>
>>
>


-- 
Dr James Cummings, InfoDev,
OUCS, University of Oxford

From dsewell at virginia.edu  Mon Jul  9 11:42:15 2012
From: dsewell at virginia.edu (David Sewell)
Date: Mon, 9 Jul 2012 11:42:15 -0400 (EDT)
Subject: [tei-council] editors@tei-c.org
In-Reply-To: <762A68C71238E2469EBDCDF70ADB24940734E3@MBX01.ad.oak.ox.ac.uk>
References: <11731401098501363@jngomktg.net>
	<4FF74201.7020700@retired.ox.ac.uk>
	<alpine.OSX.2.00.1207061556260.95447@lister.ei.virginia.edu>
	<4FF75692.6080403@retired.ox.ac.uk>,
	<4FF88E05.2090101@ultraslavonic.info>
	<762A68C71238E2469EBDCDF70ADB24940734E3@MBX01.ad.oak.ox.ac.uk>
Message-ID: <alpine.OSX.2.00.1207091139310.46380@lister.ei.virginia.edu>

I've removed or edited the main references to "editors at tei-c.org" on the TEI 
website. It appears that in some cases our raw XML refers people to that email 
address for permission to reprint/reuse content, so for the time being I am 
going to keep the address live but have redirected it to me.

A grep of the TEI sourceforge files shows that "editors at tei-c.org" appears in 
the following files, mainly in the context of an example for the <email> 
element. In those cases it could simply be changed to "info at tei-c.org". Is this 
safe to do as a global fix?

Documents/notatedMusic/tei_notatedmusic.doc.html
Documents/Object/object.doc.html
I18N/allexamples.xml
I18N/examples-fr/exemples-fr.xml
I18N/examples-fr/original.en
I18N/examples-zh-tw/allexamples.xml
I18N/results-ja/analysis.rng
I18N/results-ja/certainty.rng
I18N/results-ja/core.rng
I18N/results-ja/corpus.rng
I18N/results-ja/declarefs.rng
I18N/results-ja/dictionaries.rng
I18N/results-ja/drama.rng
I18N/results-ja/email.xml
I18N/results-ja/figures.rng
I18N/results-ja/gaiji.rng
I18N/results-ja/header.rng
I18N/results-ja/iso-fs.rng
I18N/results-ja/linking.rng
I18N/results-ja/msdescription.rng
I18N/results-ja/namesdates.rng
I18N/results-ja/nets.rng
I18N/results-ja/spoken.rng
I18N/results-ja/tagdocs.rng
I18N/results-ja/tei.rng
I18N/results-ja/textcrit.rng
I18N/results-ja/textstructure.rng
I18N/results-ja/transcr.rng
I18N/results-ja/verse.rng
I18N/results-zh-tw/examples/allExamples20080530.xml
Stylesheets/Test/expected-results/testdrama.compiled.xml
Vesta/resources/local/p5subset.xml

-- 
David Sewell, Editorial and Technical Manager
ROTUNDA, The University of Virginia Press
PO Box 400314, Charlottesville, VA 22904-4314 USA
Email: dsewell at virginia.edu   Tel: +1 434 924 9973
Web: http://rotunda.upress.virginia.edu/

From James.Cummings at oucs.ox.ac.uk  Thu Jul 12 06:26:21 2012
From: James.Cummings at oucs.ox.ac.uk (James Cummings)
Date: Thu, 12 Jul 2012 11:26:21 +0100
Subject: [tei-council] Next TEI Technical Council Teleconference
In-Reply-To: <4FEB3A09.6000106@oucs.ox.ac.uk>
References: <4FE6D32D.5070101@oucs.ox.ac.uk>	<4FE75A9A.1040003@uvic.ca>	<4FE793B2.9040004@o2.pl>	<4FE84861.6040601@oucs.ox.ac.uk>	<4FE88C84.4030806@uvic.ca>	<4FE88EF6.5010307@oucs.ox.ac.uk>
	<4FEB3A09.6000106@oucs.ox.ac.uk>
Message-ID: <4FFEA64D.90506@oucs.ox.ac.uk>


Based on the people who answered this poll, there were lots of 
good times for our next teleconference.  So I've chosen Thursday 
9 August at 20:00 BST (current London time).

If I have my calculations right, this should be:
19:00 - GMT
15:00 - EDT New York
12:00 - PDT Vancouver
and
Friday 10 August at 07:00 for NZST in New Zealand.

See also 
http://www.timeanddate.com/worldclock/meetingdetails.html?year=2012&month=8&day=9&hour=19&min=0&sec=0&p1=1233&p2=179&p3=256&p4=264

We'll build up an agenda on the wiki and I'll circulate 
teleconference details closer to the date.

-James

On 27/06/12 17:51, James Cummings wrote:
> On 25/06/12 17:16, James Cummings wrote:
>> On 25/06/12 17:06, Martin Holmes wrote:
>>> 6-10 August would be perfect for me; I'll be back to work. But
>>> any week you choose at this time of year will collide with some
>>> folks' holidays, so leave the original week on the table just in
>>> case.
>>
>> I'll give anyone a day to shout that they are away all that week
>> or for some other reason it is impossible, before putting up
>> another doodle poll.
>
>
> Ok, no one screamed or shouted that this was much worse.  So here
> we go again, with another doodle poll, for 6-10 August for our
> teleconference.
>
> http://www.doodle.com/ardsg2b954tdhg5g
>
> -James
>


-- 
Dr James Cummings, InfoDev,
OUCS, University of Oxford

From James.Cummings at oucs.ox.ac.uk  Thu Jul 12 06:27:46 2012
From: James.Cummings at oucs.ox.ac.uk (James Cummings)
Date: Thu, 12 Jul 2012 11:27:46 +0100
Subject: [tei-council] Ann Arbor Actions
Message-ID: <4FFEA6A2.3020409@oucs.ox.ac.uk>


While many of you finished your actions from Ann Arbor before the 
release (hurrah!), a fair number of actions are still left to do.

http://wiki.tei-c.org/index.php/AnnArbor2012-Actions

Could we make a push to try and complete these in good time 
before the teleconference on 9 August?

-James

-- 
Dr James Cummings, InfoDev,
OUCS, University of Oxford

From gabriel.bodard at kcl.ac.uk  Thu Jul 12 06:36:06 2012
From: gabriel.bodard at kcl.ac.uk (Gabriel Bodard)
Date: Thu, 12 Jul 2012 11:36:06 +0100
Subject: [tei-council] Ann Arbor Actions
In-Reply-To: <4FFEA6A2.3020409@oucs.ox.ac.uk>
References: <4FFEA6A2.3020409@oucs.ox.ac.uk>
Message-ID: <4FFEA896.6060008@kcl.ac.uk>

I know I'm one of the major culprits re unfinished work from that list; 
just to say that I plan to put a day aside (I hope next week) to 
dedicate to this. (I'll have lots of questions for Council when I do.)

On 2012-07-12 11:27, James Cummings wrote:
>
> While many of you finished your actions from Ann Arbor before the
> release (hurrah!), a fair number of actions are still left to do.
>
> http://wiki.tei-c.org/index.php/AnnArbor2012-Actions
>
> Could we make a push to try and complete these in good time
> before the teleconference on 9 August?
>
> -James
>

-- 
Dr Gabriel BODARD
(Research Associate in Digital Epigraphy)

Department of Digital Humanities
King's College London
26-29 Drury Lane
London WC2B 5RL

Email: gabriel.bodard at kcl.ac.uk
Tel: +44 (0)20 7848 1388
Fax: +44 (0)20 7848 2980

http://www.digitalclassicist.org/
http://www.currentepigraphy.org/



From kevin.s.hawkins at ultraslavonic.info  Thu Jul 12 07:32:21 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Thu, 12 Jul 2012 07:32:21 -0400
Subject: [tei-council] Next TEI Technical Council Teleconference
In-Reply-To: <4FEB3A09.6000106@oucs.ox.ac.uk>
References: <4FE6D32D.5070101@oucs.ox.ac.uk>
	<4FE75A9A.1040003@uvic.ca>	<4FE793B2.9040004@o2.pl>
	<4FE84861.6040601@oucs.ox.ac.uk>	<4FE88C84.4030806@uvic.ca>
	<4FE88EF6.5010307@oucs.ox.ac.uk> <4FEB3A09.6000106@oucs.ox.ac.uk>
Message-ID: <4FFEB5C5.6040407@ultraslavonic.info>

James mentioned that our call will be on 9 August, but I don't see a 
time chosen in this poll (and never received an email to that effect). 
Has the time been chosen?

On 6/27/12 12:51 PM, James Cummings wrote:
> On 25/06/12 17:16, James Cummings wrote:
>> On 25/06/12 17:06, Martin Holmes wrote:
>>> 6-10 August would be perfect for me; I'll be back to work. But
>>> any week you choose at this time of year will collide with some
>>> folks' holidays, so leave the original week on the table just in
>>> case.
>>
>> I'll give anyone a day to shout that they are away all that week
>> or for some other reason it is impossible, before putting up
>> another doodle poll.
>
>
> Ok, no one screamed or shouted that this was much worse.  So here
> we go again, with another doodle poll, for 6-10 August for our
> teleconference.
>
> http://www.doodle.com/ardsg2b954tdhg5g
>
> -James
>


From kevin.s.hawkins at ultraslavonic.info  Thu Jul 12 07:33:57 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Thu, 12 Jul 2012 07:33:57 -0400
Subject: [tei-council] Next TEI Technical Council Teleconference
In-Reply-To: <4FFEA64D.90506@oucs.ox.ac.uk>
References: <4FE6D32D.5070101@oucs.ox.ac.uk>	<4FE75A9A.1040003@uvic.ca>	<4FE793B2.9040004@o2.pl>	<4FE84861.6040601@oucs.ox.ac.uk>	<4FE88C84.4030806@uvic.ca>	<4FE88EF6.5010307@oucs.ox.ac.uk>
	<4FEB3A09.6000106@oucs.ox.ac.uk> <4FFEA64D.90506@oucs.ox.ac.uk>
Message-ID: <4FFEB625.40400@ultraslavonic.info>

Ah, never mind.  Reading my inbox in the wrong order.  :(

On 7/12/12 6:26 AM, James Cummings wrote:
>
> Based on the people who answered this poll, there were lots of
> good times for our next teleconference.  So I've chosen Thursday
> 9 August at 20:00 BST (current London time).
>
> If I have my calculations right, this should be:
> 19:00 - GMT
> 15:00 - EDT New York
> 12:00 - PDT Vancouver
> and
> Friday 10 August at 07:00 for NZST in New Zealand.
>
> See also
> http://www.timeanddate.com/worldclock/meetingdetails.html?year=2012&month=8&day=9&hour=19&min=0&sec=0&p1=1233&p2=179&p3=256&p4=264
>
> We'll build up an agenda on the wiki and I'll circulate
> teleconference details closer to the date.
>
> -James
>
> On 27/06/12 17:51, James Cummings wrote:
>> On 25/06/12 17:16, James Cummings wrote:
>>> On 25/06/12 17:06, Martin Holmes wrote:
>>>> 6-10 August would be perfect for me; I'll be back to work. But
>>>> any week you choose at this time of year will collide with some
>>>> folks' holidays, so leave the original week on the table just in
>>>> case.
>>>
>>> I'll give anyone a day to shout that they are away all that week
>>> or for some other reason it is impossible, before putting up
>>> another doodle poll.
>>
>>
>> Ok, no one screamed or shouted that this was much worse.  So here
>> we go again, with another doodle poll, for 6-10 August for our
>> teleconference.
>>
>> http://www.doodle.com/ardsg2b954tdhg5g
>>
>> -James
>>
>
>


From mholmes at uvic.ca  Sat Jul 14 14:24:00 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Sat, 14 Jul 2012 11:24:00 -0700
Subject: [tei-council] Creating new element specs
Message-ID: <5001B940.3060406@uvic.ca>

Hi all,

A couple of the tickets on my plate at the moment are proposals for new 
elements (<listApp>, and the stuff surrounding private URI schemes). I'd 
like to create element and attribute class files for these proposals and 
put them somewhere for people to examine them. Is there a standard way 
of doing this? If not, then I see two obvious options:

1. Create a new directory in trunk/P5/Source/ called "Specs-Proposed" 
(by analogy with "Specs-Unused", where discarded specs go to die).

2. Put the content of the proposed files up on the TEI wiki where people 
can read them.

The second is more open and user-friendly (more people can look at the 
wiki more easily than checking out source code), but I can imagine all 
sorts of hassles with escaping the code.

Any preferences?

Cheers,
Martin

From James.Cummings at oucs.ox.ac.uk  Sat Jul 14 18:53:46 2012
From: James.Cummings at oucs.ox.ac.uk (James Cummings)
Date: Sat, 14 Jul 2012 23:53:46 +0100
Subject: [tei-council] Creating new element specs
In-Reply-To: <5001B940.3060406@uvic.ca>
References: <5001B940.3060406@uvic.ca>
Message-ID: <5001F87A.5090304@oucs.ox.ac.uk>


Wouldn't another solution be to create them as proper in the 
P5/Source/Specs but just clearly mark them as 'a proposed 
element...'

My preference in all cases would be to have them in the same 
general location (ok, Specs-Proposed if you really want them 
separate from the main location) so that they can be processed by 
Jenkins, tested, etc.

My two bits,

-James


On 14/07/12 19:24, Martin Holmes wrote:
> Hi all,
>
> A couple of the tickets on my plate at the moment are proposals for new
> elements (<listApp>, and the stuff surrounding private URI schemes). I'd
> like to create element and attribute class files for these proposals and
> put them somewhere for people to examine them. Is there a standard way
> of doing this? If not, then I see two obvious options:
>
> 1. Create a new directory in trunk/P5/Source/ called "Specs-Proposed"
> (by analogy with "Specs-Unused", where discarded specs go to die).
>
> 2. Put the content of the proposed files up on the TEI wiki where people
> can read them.
>
> The second is more open and user-friendly (more people can look at the
> wiki more easily than checking out source code), but I can imagine all
> sorts of hassles with escaping the code.
>
> Any preferences?
>
> Cheers,
> Martin


-- 
Dr James Cummings, InfoDev
Oxford University Computing Services
University of Oxford

From mholmes at uvic.ca  Sat Jul 14 19:00:45 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Sat, 14 Jul 2012 16:00:45 -0700
Subject: [tei-council] Creating new element specs
In-Reply-To: <5001F87A.5090304@oucs.ox.ac.uk>
References: <5001B940.3060406@uvic.ca> <5001F87A.5090304@oucs.ox.ac.uk>
Message-ID: <5001FA1D.7020008@uvic.ca>

On 12-07-14 03:53 PM, James Cummings wrote:
>
> Wouldn't another solution be to create them as proper in the
> P5/Source/Specs but just clearly mark them as 'a proposed
> element...'

It might take a day or two to work through all the stuff you need to do 
before a spec is complete and functional; you'd either have to avoid 
committing it throughout that time, or put up with a couple of days of 
broken builds and odd side-effects until you got it to where you want it.

> My preference in all cases would be to have them in the same
> general location (ok, Specs-Proposed if you really want them
> separate from the main location) so that they can be processed by
> Jenkins, tested, etc.

I agree that once they're ready to go, they should be placed in Specs. 
But there's usually some discussion that needs to happen, especially if 
you haven't created a lot of these from scratch (like me).

But since <listApp> looks fairly straightforward and uncontroversial, 
I'll try creating it in Specs and see what happens.

Cheers,
Martin

> My two bits,
>
> -James
>
>
> On 14/07/12 19:24, Martin Holmes wrote:
>> Hi all,
>>
>> A couple of the tickets on my plate at the moment are proposals for new
>> elements (<listApp>, and the stuff surrounding private URI schemes). I'd
>> like to create element and attribute class files for these proposals and
>> put them somewhere for people to examine them. Is there a standard way
>> of doing this? If not, then I see two obvious options:
>>
>> 1. Create a new directory in trunk/P5/Source/ called "Specs-Proposed"
>> (by analogy with "Specs-Unused", where discarded specs go to die).
>>
>> 2. Put the content of the proposed files up on the TEI wiki where people
>> can read them.
>>
>> The second is more open and user-friendly (more people can look at the
>> wiki more easily than checking out source code), but I can imagine all
>> sorts of hassles with escaping the code.
>>
>> Any preferences?
>>
>> Cheers,
>> Martin
>
>


From mholmes at uvic.ca  Sat Jul 14 20:11:33 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Sat, 14 Jul 2012 17:11:33 -0700
Subject: [tei-council] Request for comments on a ticket
Message-ID: <50020AB5.3040604@uvic.ca>

Hi all,

I've got this ticket:

<http://purl.org/tei/bugs/3537452>

The remaining issue on the ticket boils down to the similarity between:

milestone/@unit:

<http://teijenkins.hcmc.uvic.ca:8080/job/TEIP5-Documentation/lastSuccessfulBuild/artifact/Guidelines-web/en/html/ref-milestone.html#tei_att.unit>

and refState/@unit:

<http://teijenkins.hcmc.uvic.ca:8080/job/TEIP5-Documentation/lastSuccessfulBuild/artifact/Guidelines-web/en/html/ref-refState.html#tei_att.unit>

[Note our new ability to point directly at an attribute in an element or 
class reference page, as of today.]

They have the same lengthy set of suggested values, except that the 
first has two extra values ("speaker" and "unnumbered"). If the 
discrepancy between them is accidental, then they should be brought into 
line, and perhaps a new attribute class for these two definitions of 
@unit (distinct from the one in att.dimensions) should be created. 
However, if there is a reason for the discrepancy, then they will need 
to be maintained separately.

Can you take a quick look at this, and see if you can see, or remember, 
any reason for these attribute definitions to be different? Please write 
back to the list or comment on the ticket.

Cheers,
Martin

From James.Cummings at oucs.ox.ac.uk  Sun Jul 15 07:38:12 2012
From: James.Cummings at oucs.ox.ac.uk (James Cummings)
Date: Sun, 15 Jul 2012 12:38:12 +0100
Subject: [tei-council] Fwd: TITE again
In-Reply-To: <7D89C1F94A704245AF5254CFAE7AA1A801CABC4A@evcspmbx1.ads.northwestern.edu>
References: <7D89C1F94A704245AF5254CFAE7AA1A801CABC4A@evcspmbx1.ads.northwestern.edu>
Message-ID: <5002ABA4.2000006@oucs.ox.ac.uk>


For your consideration.

-James


-------- Original Message --------
Subject: 	TITE again
Date: 	Sun, 15 Jul 2012 10:32:41 +0000
From: 	Martin Mueller <martinmueller at northwestern.edu>
To: 	James Cummings <James.Cummings at OUCS.OX.AC.UK>



Dear James,

As you know, some time ago I raised the question whether the TITE
convenience elements <b>, <i>, <u>, <sup>, and <sub> should
become part of P5 on the grounds that <i> relates to <hi
rend="italics"> in the same in which <lb/> relates to <milestone
unit="line"/>. There followed a lively discussion on the Council
list, which you accurately summarized as not very conclusive.

I'd like to come back to this discussion and argue that on
balance the case for 'yes' is a little stronger than the case for
'no'. Please take this letter to the Council. If you think it
would be helpful to put it on TEI list please do so.

I read through the thread again in the particular context of
wondering how many of the varied and commons superscripts in the
TCP texts could be expressed through Unicode characters, a
possibility raised by Lou Burnard. There were other comments
Piotr Banski, James Cummings, Martin Holmes, Kevin Hawkins,
Sebastian Rahtz, and Paul Schaffner.

The thread consisted of a mixture of theoretical and pragmatic
arguments. On the more theoretical side, James, Piotr, and Gabby
had reservations about mixing up semantic and presentational
markup, coming too close to HTML, or encouraging encoders to be
lazy. Piotr shared James's sense that <lb> and <pb> were somehow
different from <i> or <sup>. I don't see the difference, but I
respect such intuitions and recognize that they are hard to
resolve by argument.

On the pragmatic side, Kevin, Paul, and Sebastian argued in
favour of various options for inclusion. Paul said that elements
like <i> and <sup> have a "reassuring rootedness in actual page
phenomena." In that regard, they may be like line or page breaks:
you can't really argue about "the fact that." But most page or
line breaks have a compelling reason: there is no more space.
Italics and similar phenomena are never compulsory in that way
(perhaps that is the reason why you and Piotr think they are
different. They must have a reason even if it is hard to figure out).

If you admit things like <i> or <sup>, where do you stop? Paul
raised that question when he said that from the TCP perspective
the list of TITE elements was inadequate and <b> wasn't needed.
Implicit in Sebastian's comments, I think, is the argument that
Frequency is King and a good enough guide to a tightly limited
set of canned options. Sebastian suggested a kiss module (keep it
simple stupid?) of i/b/u/bl/larger/smaller/sup/sub and removing
the rend attribute.

Martin Holmes replied that you'd always need a rend option to
cover eventualities and wondered whether there would be a
continued stream of feature request for more canned options.
Kevin on the other hand argued that a limited set of canned
options helps the cause of interoperability.

To return to Lou's suggestion about superscripts, it turns out
that you can represent a high percentage of superscripts in the
TCP texts (perhaps as many as 98% of tokens) with Unicode
characters. But there doesn't seem to be a superscripted 'c',
which rules out the common w<sup>ch</sup>, there is no lower-case
'i' (so much for the common superscripted forms of 'Majestie'),
and there is no superscripted period sign, which is also common.
But 98% is 98%, and the various Unicode characters, although
cobbled together from different lists, play well with each other
in browser displays.

Where does that leave us? In some ways, the question of
convenience or syntactic sugar elements is like that of
'favourites' on Windows or OS X. Commonly used directories are
freed from their status in the hierarchy and given a sort of VIP
treatment. This works as long as two conditions are met:

  1. The list must be short
  2. The candidates must be really obvious in terms of their
     frequency across a lot of different document types

I would say that <i> and <sup> clearly meet the second criterion.
If you're not bound by Systemzwang you would probably throw out
<sub>, because it is much less common than <sup>. The TITE
inclusion of <b> and <u> may have more to do with HTML than with
conventions of print culture. So I'd urge the Council to go with
the pragmatists and come up with a really short list that covers
a high percentage of cases and is worth the trade-off of giving
up a little consistency for a lot of convenience.

Perhaps there is no such list. But I think there is.



From mholmes at uvic.ca  Sun Jul 15 12:29:06 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Sun, 15 Jul 2012 09:29:06 -0700
Subject: [tei-council] Fwd: TITE again
In-Reply-To: <5002ABA4.2000006@oucs.ox.ac.uk>
References: <7D89C1F94A704245AF5254CFAE7AA1A801CABC4A@evcspmbx1.ads.northwestern.edu>
	<5002ABA4.2000006@oucs.ox.ac.uk>
Message-ID: <5002EFD2.9090303@uvic.ca>

This makes me rather uncomfortable, because we're unambiguously 
importing presentational elements into the schema. On the other hand, I 
have to admit that this>:

<b>stuff</b>

is simpler, clearer and more user-friendly than either of these:

<hi rend="bold">stuff</hi>
<hi rend="font-weight: bold;">stuff</hi>
<hi style="font-weight: bold;">stuff</hi>

So I think on balance I like Sebastian's idea of a "kiss" module 
containing these elements, but I think we obviously have to keep @rend 
(and I still think we need @style for CSS). I disagree that the list 
should be as short as possible, though; if we include <sup> but not 
<sub>, for instance, we'll just get lots of feature requests which 
rightly point out that such a choice is essentially arbitrary -- unless 
we're prepared to do a huge amount of research and statistical analysis 
to support the exclusions.

There is one other option, though: the kiss module could explicitly 
import elements from the XHTML namespace.

Cheers,
Martin

On 12-07-15 04:38 AM, James Cummings wrote:
>
> For your consideration.
>
> -James
>
>
> -------- Original Message --------
> Subject: 	TITE again
> Date: 	Sun, 15 Jul 2012 10:32:41 +0000
> From: 	Martin Mueller <martinmueller at northwestern.edu>
> To: 	James Cummings <James.Cummings at OUCS.OX.AC.UK>
>
>
>
> Dear James,
>
> As you know, some time ago I raised the question whether the TITE
> convenience elements <b>, <i>, <u>, <sup>, and <sub> should
> become part of P5 on the grounds that <i> relates to <hi
> rend="italics"> in the same in which <lb/> relates to <milestone
> unit="line"/>. There followed a lively discussion on the Council
> list, which you accurately summarized as not very conclusive.
>
> I'd like to come back to this discussion and argue that on
> balance the case for 'yes' is a little stronger than the case for
> 'no'. Please take this letter to the Council. If you think it
> would be helpful to put it on TEI list please do so.
>
> I read through the thread again in the particular context of
> wondering how many of the varied and commons superscripts in the
> TCP texts could be expressed through Unicode characters, a
> possibility raised by Lou Burnard. There were other comments
> Piotr Banski, James Cummings, Martin Holmes, Kevin Hawkins,
> Sebastian Rahtz, and Paul Schaffner.
>
> The thread consisted of a mixture of theoretical and pragmatic
> arguments. On the more theoretical side, James, Piotr, and Gabby
> had reservations about mixing up semantic and presentational
> markup, coming too close to HTML, or encouraging encoders to be
> lazy. Piotr shared James's sense that <lb> and <pb> were somehow
> different from <i> or <sup>. I don't see the difference, but I
> respect such intuitions and recognize that they are hard to
> resolve by argument.
>
> On the pragmatic side, Kevin, Paul, and Sebastian argued in
> favour of various options for inclusion. Paul said that elements
> like <i> and <sup> have a "reassuring rootedness in actual page
> phenomena." In that regard, they may be like line or page breaks:
> you can't really argue about "the fact that." But most page or
> line breaks have a compelling reason: there is no more space.
> Italics and similar phenomena are never compulsory in that way
> (perhaps that is the reason why you and Piotr think they are
> different. They must have a reason even if it is hard to figure out).
>
> If you admit things like <i> or <sup>, where do you stop? Paul
> raised that question when he said that from the TCP perspective
> the list of TITE elements was inadequate and <b> wasn't needed.
> Implicit in Sebastian's comments, I think, is the argument that
> Frequency is King and a good enough guide to a tightly limited
> set of canned options. Sebastian suggested a kiss module (keep it
> simple stupid?) of i/b/u/bl/larger/smaller/sup/sub and removing
> the rend attribute.
>
> Martin Holmes replied that you'd always need a rend option to
> cover eventualities and wondered whether there would be a
> continued stream of feature request for more canned options.
> Kevin on the other hand argued that a limited set of canned
> options helps the cause of interoperability.
>
> To return to Lou's suggestion about superscripts, it turns out
> that you can represent a high percentage of superscripts in the
> TCP texts (perhaps as many as 98% of tokens) with Unicode
> characters. But there doesn't seem to be a superscripted 'c',
> which rules out the common w<sup>ch</sup>, there is no lower-case
> 'i' (so much for the common superscripted forms of 'Majestie'),
> and there is no superscripted period sign, which is also common.
> But 98% is 98%, and the various Unicode characters, although
> cobbled together from different lists, play well with each other
> in browser displays.
>
> Where does that leave us? In some ways, the question of
> convenience or syntactic sugar elements is like that of
> 'favourites' on Windows or OS X. Commonly used directories are
> freed from their status in the hierarchy and given a sort of VIP
> treatment. This works as long as two conditions are met:
>
>    1. The list must be short
>    2. The candidates must be really obvious in terms of their
>       frequency across a lot of different document types
>
> I would say that <i> and <sup> clearly meet the second criterion.
> If you're not bound by Systemzwang you would probably throw out
> <sub>, because it is much less common than <sup>. The TITE
> inclusion of <b> and <u> may have more to do with HTML than with
> conventions of print culture. So I'd urge the Council to go with
> the pragmatists and come up with a really short list that covers
> a high percentage of cases and is worth the trade-off of giving
> up a little consistency for a lot of convenience.
>
> Perhaps there is no such list. But I think there is.
>
>

-- 
Martin Holmes
mholmes at uvic.ca
UVic Humanities Computing and Media Centre



From sebastian.rahtz at oucs.ox.ac.uk  Sun Jul 15 12:53:20 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Sun, 15 Jul 2012 16:53:20 +0000
Subject: [tei-council] Fwd: TITE again
In-Reply-To: <5002EFD2.9090303@uvic.ca>
References: <7D89C1F94A704245AF5254CFAE7AA1A801CABC4A@evcspmbx1.ads.northwestern.edu>
	<5002ABA4.2000006@oucs.ox.ac.uk> <5002EFD2.9090303@uvic.ca>
Message-ID: <43253F51-E75C-4668-8B0F-E8FA4E622D97@oucs.ox.ac.uk>


On 15 Jul 2012, at 17:29, Martin Holmes wrote:

> This makes me rather uncomfortable, because we're unambiguously 
> importing presentational elements into the schema.

sure. but this is just somewhere a bit further along the 
scale on which lists, tables, page breaks,  etc sit, I would
argue. I don't think there can be a black and white case against <b>,
<i>, <sup> and <sub>. 

> 
> There is one other option, though: the kiss module could explicitly 
> import elements from the XHTML namespace.
> 
that surely defeats the point, if you have to say <xhtml:b> and declare
the prefix? One could certainly use <equiv> to note the relationship,
I think.

a module called "typesetting" or "presentation" (not "kiss" :-}) 
would do the job, and would even allow for a <font> element
(no, I am not joking).

There is a question, perhaps, over whether we should start
talking about a TEI profile called "core", which we promote
instead of "tei_all" as the normal test of TEI goodness. and that
would not include the "typesetting" module. Cue lengthy argument.

All that said, I don't think this request is so urgent that we shouldn't
just put it on the agenda for the autumn. I'd much rather
we resolved some requests which more genuinely block TCP translation,
eg  3531957, 3531963, 3439980 - especially the latter!
--
Sebastian Rahtz      
Head of Information and Support Group
Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431







From sebastian.rahtz at oucs.ox.ac.uk  Sun Jul 15 12:54:56 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Sun, 15 Jul 2012 16:54:56 +0000
Subject: [tei-council] Creating new element specs
In-Reply-To: <5001FA1D.7020008@uvic.ca>
References: <5001B940.3060406@uvic.ca> <5001F87A.5090304@oucs.ox.ac.uk>
	<5001FA1D.7020008@uvic.ca>
Message-ID: <fea0fef2-9c61-4f0a-97dd-34cb4912c8b0@HUB06.ad.oak.ox.ac.uk>


On 15 Jul 2012, at 00:00, Martin Holmes wrote:

> 
> It might take a day or two to work through all the stuff you need to do 
> before a spec is complete and functional; you'd either have to avoid 
> committing it throughout that time, or put up with a couple of days of 
> broken builds and odd side-effects until you got it to where you want it.

frankly, is that such a big deal, midway between releases? especially
now your command-line build works, you can test at home for the
more obvious errors.


--
Sebastian Rahtz      
Head of Information and Support Group
Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431







From mholmes at uvic.ca  Sun Jul 15 13:08:49 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Sun, 15 Jul 2012 10:08:49 -0700
Subject: [tei-council] Creating new element specs
In-Reply-To: <fea0fef2-9c61-4f0a-97dd-34cb4912c8b0@HUB06.ad.oak.ox.ac.uk>
References: <5001B940.3060406@uvic.ca> <5001F87A.5090304@oucs.ox.ac.uk>
	<5001FA1D.7020008@uvic.ca>
	<fea0fef2-9c61-4f0a-97dd-34cb4912c8b0@HUB06.ad.oak.ox.ac.uk>
Message-ID: <5002F921.5070005@uvic.ca>

On 12-07-15 09:54 AM, Sebastian Rahtz wrote:
>
> On 15 Jul 2012, at 00:00, Martin Holmes wrote:
>
>>
>> It might take a day or two to work through all the stuff you need to do
>> before a spec is complete and functional; you'd either have to avoid
>> committing it throughout that time, or put up with a couple of days of
>> broken builds and odd side-effects until you got it to where you want it.
>
> frankly, is that such a big deal, midway between releases? especially
> now your command-line build works, you can test at home for the
> more obvious errors.

Fair enough. I've already added <listApp> (currently incomplete) in 
Specs. But I have had quite a struggle to get a local build system 
working, so I think it would be a good idea to create a desktop version 
of the Jenkins build script to enable contributors to test local builds 
when they're going to do something that might take a lot of testing 
before it's right, along with some instructions for what targets to make 
when you're e.g. building only the web guidelines or testing the 
stylesheets.

Cheers,
Martin

-- 
Martin Holmes
mholmes at uvic.ca
UVic Humanities Computing and Media Centre



From kevin.s.hawkins at ultraslavonic.info  Sun Jul 15 13:10:24 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Sun, 15 Jul 2012 13:10:24 -0400
Subject: [tei-council] Request for comments on a ticket
In-Reply-To: <50020AB5.3040604@uvic.ca>
References: <50020AB5.3040604@uvic.ca>
Message-ID: <5002F980.6000106@ultraslavonic.info>

On 7/14/12 8:11 PM, Martin Holmes wrote:
> Hi all,
>
> I've got this ticket:
>
> <http://purl.org/tei/bugs/3537452>

[. . .]

> [Note our new ability to point directly at an attribute in an element or
> class reference page, as of today.]

Nice.  Could we have a little gray paragraph symbol next to each 
attribute which includes an <a href=""> pointing to that section?  See 
the prose of the Guidelines for how this looks.  This would allow users 
to discover these links and easily access them.

> Can you take a quick look at this, and see if you can see, or remember,
> any reason for these attribute definitions to be different? Please write
> back to the list or comment on the ticket.

I've lent my support on the ticket.

--K.

From kevin.s.hawkins at ultraslavonic.info  Sun Jul 15 13:14:30 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Sun, 15 Jul 2012 13:14:30 -0400
Subject: [tei-council] rooting out some mentions of SGML in the Guidelines
Message-ID: <5002FA76.1020307@ultraslavonic.info>

There are a number of instances in the TEI Guidelines of "SGML or XML". 
  Is it safe to drop the reference to SGML in cases where current 
practice, and not history, is being discussed?  The Guidelines, after 
all, switched to XML syntax with P5, so I can't see any reason to keep 
these.

Also okay to change examples where the value of ref at target contains 
".sgm" to ".xml"?

--K.

From sebastian.rahtz at oucs.ox.ac.uk  Sun Jul 15 13:17:35 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Sun, 15 Jul 2012 17:17:35 +0000
Subject: [tei-council] rooting out some mentions of SGML in the
 Guidelines
In-Reply-To: <5002FA76.1020307@ultraslavonic.info>
References: <5002FA76.1020307@ultraslavonic.info>
Message-ID: <0F84958A-73C4-44B8-B317-23B49BF479E9@oucs.ox.ac.uk>


On 15 Jul 2012, at 18:14, Kevin Hawkins wrote:

> There are a number of instances in the TEI Guidelines of "SGML or XML". 
>  Is it safe to drop the reference to SGML in cases where current 
> practice, and not history, is being discussed?  The Guidelines, after 
> all, switched to XML syntax with P5, so I can't see any reason to keep 
> these.
> 
> Also okay to change examples where the value of ref at target contains 
> ".sgm" to ".xml"?


+1 from me.
--
Sebastian Rahtz      
Head of Information and Support Group
Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431







From James.Cummings at oucs.ox.ac.uk  Sun Jul 15 13:33:39 2012
From: James.Cummings at oucs.ox.ac.uk (James Cummings)
Date: Sun, 15 Jul 2012 18:33:39 +0100
Subject: [tei-council] rooting out some mentions of SGML in the
	Guidelines
In-Reply-To: <0F84958A-73C4-44B8-B317-23B49BF479E9@oucs.ox.ac.uk>
References: <5002FA76.1020307@ultraslavonic.info>
	<0F84958A-73C4-44B8-B317-23B49BF479E9@oucs.ox.ac.uk>
Message-ID: <5002FEF3.8000804@oucs.ox.ac.uk>

On 15/07/12 18:17, Sebastian Rahtz wrote:
> On 15 Jul 2012, at 18:14, Kevin Hawkins wrote:
>> There are a number of instances in the TEI Guidelines of "SGML or XML".
>>   Is it safe to drop the reference to SGML in cases where current
>> practice, and not history, is being discussed?  The Guidelines, after
>> all, switched to XML syntax with P5, so I can't see any reason to keep
>> these.
>> Also okay to change examples where the value of ref at target contains
>> ".sgm" to ".xml"?
> +1 from me.

Likewise from me. Anywhere where the theory of markup languages 
and/or their history is not being discussed, then mention of SGML 
and in my opinion DTDs should be slowly removed.  ;-)

-James
-- 
Dr James Cummings, InfoDev
Oxford University Computing Services
University of Oxford

From syeates at gmail.com  Sun Jul 15 19:47:47 2012
From: syeates at gmail.com (Stuart A. Yeates)
Date: Mon, 16 Jul 2012 11:47:47 +1200
Subject: [tei-council] rooting out some mentions of SGML in the
	Guidelines
In-Reply-To: <5002FA76.1020307@ultraslavonic.info>
References: <5002FA76.1020307@ultraslavonic.info>
Message-ID: <CAC_Lu0Y02Xq_GMmqKfD=Nv=bOQ-dx4ecvQMk786jnA_XedF+bA@mail.gmail.com>

On Mon, Jul 16, 2012 at 5:14 AM, Kevin Hawkins
<kevin.s.hawkins at ultraslavonic.info> wrote:

> Also okay to change examples where the value of ref at target contains
> ".sgm" to ".xml"?

Yes.

There are likely to be some examples of linking to to non-XML content
coming out of the xpointer work. These may contain considered links to
.sgm files which cohuld not be covered by this blanket change.

cheers
stuart

From syeates at gmail.com  Sun Jul 15 19:58:47 2012
From: syeates at gmail.com (Stuart A. Yeates)
Date: Mon, 16 Jul 2012 11:58:47 +1200
Subject: [tei-council] Xpointer technical work
Message-ID: <CAC_Lu0YHs7rRUQDYQwArciMiv30LcU5rntGfz_UVHSdWvtTh=w@mail.gmail.com>

[Kevin's SGML email reminded me that I should have circulated this earlier.]

Coming out of the xpointer work, I decided to see exactly how hard it
would be to implement string-range().

You can see the results at https://github.com/stuartyeates/xpointer To
quote from the README "My plan is to give it up as too hard if I don't
have the most complete xpointer suite within ~ two months."

Along the way I'm actually finding a lots more xpointer
implementations than I'd expected, and accumulating links to some of
them in the README.

cheers
stuart

From mholmes at uvic.ca  Sun Jul 15 20:53:31 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Sun, 15 Jul 2012 17:53:31 -0700
Subject: [tei-council] Request for comments on a ticket
In-Reply-To: <5002F980.6000106@ultraslavonic.info>
References: <50020AB5.3040604@uvic.ca> <5002F980.6000106@ultraslavonic.info>
Message-ID: <5003660B.5060908@uvic.ca>

On 12-07-15 10:10 AM, Kevin Hawkins wrote:

>> [Note our new ability to point directly at an attribute in an element or
>> class reference page, as of today.]
>
> Nice.  Could we have a little gray paragraph symbol next to each
> attribute which includes an <a href=""> pointing to that section?  See
> the prose of the Guidelines for how this looks.  This would allow users
> to discover these links and easily access them.

Good point. I've just committed a better approach to this, using a 
proper hook to a named template. Results should be built in an hour or two.

>
>> Can you take a quick look at this, and see if you can see, or remember,
>> any reason for these attribute definitions to be different? Please write
>> back to the list or comment on the ticket.
>
> I've lent my support on the ticket.

Thanks. I think I'll go ahead with this one.

Cheers,
Martin


From kevin.s.hawkins at ultraslavonic.info  Mon Jul 16 17:29:25 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Mon, 16 Jul 2012 17:29:25 -0400
Subject: [tei-council] rooting out some mentions of SGML in the
	Guidelines
In-Reply-To: <CAC_Lu0Y02Xq_GMmqKfD=Nv=bOQ-dx4ecvQMk786jnA_XedF+bA@mail.gmail.com>
References: <5002FA76.1020307@ultraslavonic.info>
	<CAC_Lu0Y02Xq_GMmqKfD=Nv=bOQ-dx4ecvQMk786jnA_XedF+bA@mail.gmail.com>
Message-ID: <500487B5.6070902@ultraslavonic.info>

I've made revisions that I think are safe:

http://tei.svn.sourceforge.net/viewvc/tei?view=revision&revision=10662

I didn't see anything related to XPointer among these.

On 7/15/2012 7:47 PM, Stuart A. Yeates wrote:
> On Mon, Jul 16, 2012 at 5:14 AM, Kevin Hawkins
> <kevin.s.hawkins at ultraslavonic.info>  wrote:
>
>> Also okay to change examples where the value of ref at target contains
>> ".sgm" to ".xml"?
>
> Yes.
>
> There are likely to be some examples of linking to to non-XML content
> coming out of the xpointer work. These may contain considered links to
> .sgm files which cohuld not be covered by this blanket change.
>
> cheers
> stuart

From bansp at o2.pl  Tue Jul 17 05:13:25 2012
From: bansp at o2.pl (Piotr Banski)
Date: Tue, 17 Jul 2012 11:13:25 +0200
Subject: [tei-council] Xpointer technical work
In-Reply-To: <CAC_Lu0YHs7rRUQDYQwArciMiv30LcU5rntGfz_UVHSdWvtTh=w@mail.gmail.com>
References: <CAC_Lu0YHs7rRUQDYQwArciMiv30LcU5rntGfz_UVHSdWvtTh=w@mail.gmail.com>
Message-ID: <50052CB5.2020303@o2.pl>

This is exciting, and I hope you won't give up. With material so 
complex, 2 months sounds like a challenge. I'm keeping my fingers crossed.

Best,

   P.

On 16/07/12 01:58, Stuart A. Yeates wrote:
> [Kevin's SGML email reminded me that I should have circulated this earlier.]
>
> Coming out of the xpointer work, I decided to see exactly how hard it
> would be to implement string-range().
>
> You can see the results at https://github.com/stuartyeates/xpointer To
> quote from the README "My plan is to give it up as too hard if I don't
> have the most complete xpointer suite within ~ two months."
>
> Along the way I'm actually finding a lots more xpointer
> implementations than I'd expected, and accumulating links to some of
> them in the README.
>
> cheers
> stuart
>



From kevin.s.hawkins at ultraslavonic.info  Tue Jul 17 11:32:37 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Tue, 17 Jul 2012 11:32:37 -0400
Subject: [tei-council] proposed additions to tcw22
In-Reply-To: <4FDB3BA8.5030200@oucs.ox.ac.uk>
References: <4FDB38D4.7010605@ultraslavonic.info>
	<4FDB3BA8.5030200@oucs.ox.ac.uk>
Message-ID: <50058595.7070605@ultraslavonic.info>

I just noticed that the "Future Developments" section of the "About 
these Guidelines" chapter of P5 makes reference to a version numbering 
system with two parts:

http://www.tei-c.org/release/doc/tei-p5-doc/en/html/AB.html#ABTEI4

We now have ONLY three-part version numbers using the Unicode 
Consortium's system, right?  That is, whatever we were intended when 
this was written no longer applies, right?  If so, I'll revise this 
ticket to reference the Unicode system, just as I did in tcw22 and 
data.version.xml.

On 6/15/2012 9:42 AM, James Cummings wrote:

> http://unicode.org/versions/

> On 15/06/12 14:29, Kevin Hawkins wrote:

>> Can anyone provide me a reference for Unicode version conventions?  I
>> would like to add it to tcw22 and also to
>> http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-data.version.html ,
>> which mentions this but does not explain the usage.
>
>

From syeates at gmail.com  Tue Jul 17 16:15:02 2012
From: syeates at gmail.com (Stuart A. Yeates)
Date: Wed, 18 Jul 2012 08:15:02 +1200
Subject: [tei-council] Xpointer technical work
In-Reply-To: <50052CB5.2020303@o2.pl>
References: <CAC_Lu0YHs7rRUQDYQwArciMiv30LcU5rntGfz_UVHSdWvtTh=w@mail.gmail.com>
	<50052CB5.2020303@o2.pl>
Message-ID: <CAC_Lu0aiFq5xZHRLMQV7S7zF6C7M35ficACJRRuvVs8DiiYNKw@mail.gmail.com>

As of last night the xpointer element() scheme appears to work, at
least for me handful of test cases. I'm now working on string-range().

I'm tracking the status in the README at
https://github.com/stuartyeates/xpointer/blob/master/README.md which
lists a number of things that I'm aware of that aren't working
(xml:base, xml:lang, namespaces, concatenation schemes, etc).

cheers
stuart



On Tue, Jul 17, 2012 at 9:13 PM, Piotr Banski <bansp at o2.pl> wrote:
> This is exciting, and I hope you won't give up. With material so complex, 2
> months sounds like a challenge. I'm keeping my fingers crossed.
>
> Best,
>
>   P.
>
>
> On 16/07/12 01:58, Stuart A. Yeates wrote:
>>
>> [Kevin's SGML email reminded me that I should have circulated this
>> earlier.]
>>
>> Coming out of the xpointer work, I decided to see exactly how hard it
>> would be to implement string-range().
>>
>> You can see the results at https://github.com/stuartyeates/xpointer To
>> quote from the README "My plan is to give it up as too hard if I don't
>> have the most complete xpointer suite within ~ two months."
>>
>> Along the way I'm actually finding a lots more xpointer
>> implementations than I'd expected, and accumulating links to some of
>> them in the README.
>>
>> cheers
>> stuart
>>
>
>

From kevin.s.hawkins at ultraslavonic.info  Tue Jul 17 17:37:47 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Tue, 17 Jul 2012 17:37:47 -0400
Subject: [tei-council] proposed additions to tcw22
In-Reply-To: <50058595.7070605@ultraslavonic.info>
References: <4FDB38D4.7010605@ultraslavonic.info>	<4FDB3BA8.5030200@oucs.ox.ac.uk>
	<50058595.7070605@ultraslavonic.info>
Message-ID: <5005DB2B.4050003@ultraslavonic.info>

Sorry, "revise this ticket" should read "revise this page".

On 7/17/2012 11:32 AM, Kevin Hawkins wrote:
> I just noticed that the "Future Developments" section of the "About
> these Guidelines" chapter of P5 makes reference to a version numbering
> system with two parts:
>
> http://www.tei-c.org/release/doc/tei-p5-doc/en/html/AB.html#ABTEI4
>
> We now have ONLY three-part version numbers using the Unicode
> Consortium's system, right?  That is, whatever we were intended when
> this was written no longer applies, right?  If so, I'll revise this
> ticket to reference the Unicode system, just as I did in tcw22 and
> data.version.xml.
>
> On 6/15/2012 9:42 AM, James Cummings wrote:
>
>> http://unicode.org/versions/
>
>> On 15/06/12 14:29, Kevin Hawkins wrote:
>
>>> Can anyone provide me a reference for Unicode version conventions?  I
>>> would like to add it to tcw22 and also to
>>> http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-data.version.html ,
>>> which mentions this but does not explain the usage.
>>
>>

From syeates at gmail.com  Wed Jul 18 05:44:44 2012
From: syeates at gmail.com (stuart yeates)
Date: Wed, 18 Jul 2012 21:44:44 +1200
Subject: [tei-council] string-range question
Message-ID: <5006858C.9030602@gmail.com>

I've got a question about string-range, as defined by: 
http://www.tei-c.org/release/doc/tei-p5-doc/en/html/SA.html#SATSSR

Do characters in comments count?

I'm guessing not, but mainly due to the similarity of the term 
"character positions" used there with the term "character data" in the 
XML standard. But it's a guess.

cheers
stuart



From rwelzenbach at gmail.com  Wed Jul 18 10:38:50 2012
From: rwelzenbach at gmail.com (Rebecca Welzenbach)
Date: Wed, 18 Jul 2012 10:38:50 -0400
Subject: [tei-council] Fwd: TITE again
In-Reply-To: <43253F51-E75C-4668-8B0F-E8FA4E622D97@oucs.ox.ac.uk>
References: <7D89C1F94A704245AF5254CFAE7AA1A801CABC4A@evcspmbx1.ads.northwestern.edu>
	<5002ABA4.2000006@oucs.ox.ac.uk> <5002EFD2.9090303@uvic.ca>
	<43253F51-E75C-4668-8B0F-E8FA4E622D97@oucs.ox.ac.uk>
Message-ID: <CAA2irtKzTDQaBT0gSgMa-XVN-WB0foAyQVv0U2ej8SZjXjFENQ@mail.gmail.com>

As I recall, one of the concerns about bringing these elements into P5 is
that it provides even more ways of doing things--it makes the landscape
more complicated, rather than less complicated.

As Martin Holmes said:

> <b>stuff</b>
>
> is simpler, clearer and more user-friendly than either of these:
>
> <hi rend="bold">stuff</hi>
> <hi rend="font-weight: bold;">stuff</hi>
> <hi style="font-weight: bold;">stuff</hi>

In and of itself <b>stuff</b> is simpler, but bringing it into P5
complicates things by offering yet another apparently equivalent choice,
right?

Rather than incorporating these convenience elements into P5, what if we
instead explicitly acknowledge that people might use any number of
shortcuts for efficiency in their own projects, and offer some basic
support for transforming such texts to P5? I don't know if this would fit
best in the Guidelines or somewhere else like the wiki (I guess it depends
on how formally we want to support it), but I can imagine a document saying
something like:

"Many people find it convenient/effective to help vendors/students/the
crowd, who have limited experience with TEI and/or with the textual
material at hand, encode consistently by using "shortcut elements" for
common, easily recognizable features. When encoding is complete, the texts
are processed, and these shortcut elements are expanded into valid TEI P5
elements.

For example: *stuff * might be transitionally captured as <b>stuff</b>, and
then transformed in processing to <hi rend="bold">stuff</hi>

TEI Tite (
http://www.tei-c.org/release/doc/tei-p5-exemplars/html/tei_tite.doc.html)
is an example of an entire schema designed around supporting this kind of
off-site text encoding. TEI Tite uses the following shortcut elements:
b<http://www.tei-c.org/release/doc/tei-p5-exemplars/html/tei_tite.doc.html#b>
, i<http://www.tei-c.org/release/doc/tei-p5-exemplars/html/tei_tite.doc.html#i>
, ul<http://www.tei-c.org/release/doc/tei-p5-exemplars/html/tei_tite.doc.html#ul>
, sup<http://www.tei-c.org/release/doc/tei-p5-exemplars/html/tei_tite.doc.html#sup>
, sub<http://www.tei-c.org/release/doc/tei-p5-exemplars/html/tei_tite.doc.html#sub>
, smcap<http://www.tei-c.org/release/doc/tei-p5-exemplars/html/tei_tite.doc.html#smcap>
,cols<http://www.tei-c.org/release/doc/tei-p5-exemplars/html/tei_tite.doc.html#cols>
 and ornament<http://www.tei-c.org/release/doc/tei-p5-exemplars/html/tei_tite.doc.html#ornament>

Regardless of the schema you use for your project, if you use this list of
shortcut elements in your project, you can use [this transformation/this
set of regular expressions] to expand your shortcut elements to P5. Of
course, you may also invent any shortcuts that are useful for the purposes
of your project, and design your own post-processing workflow to transform
the transitional encoding to conform to the archival schema you have
selected for your project."

I like this for a few reasons:

   - it offers support for a customizable approach to encoding projects,
   rather than rubber-stamping some shortcuts as valid and others as not
   (regardless of how much more frequently <sup> is used than <sub>, it just
   seems unbalanced, in many ways, to allow one and not the other).
   - It also lets encoders go either way: fallback on convenience and rely
   on some default expansion of the shortcut element (which I guess we would
   define for them), or choose for themselves how they really want the bold
   text to be encoded.

However, this suggestion does not really get at the problem of making
things more interoperable, because in the final TEI document, text that was
bold in the original might still be encoded in several different ways.

Becky

On Sun, Jul 15, 2012 at 12:53 PM, Sebastian Rahtz <
sebastian.rahtz at oucs.ox.ac.uk> wrote:
>
> On 15 Jul 2012, at 17:29, Martin Holmes wrote:
>
>> This makes me rather uncomfortable, because we're unambiguously
>> importing presentational elements into the schema.
>
> sure. but this is just somewhere a bit further along the
> scale on which lists, tables, page breaks,  etc sit, I would
> argue. I don't think there can be a black and white case against <b>,
> <i>, <sup> and <sub>.
>
>>
>> There is one other option, though: the kiss module could explicitly
>> import elements from the XHTML namespace.
>>
> that surely defeats the point, if you have to say <xhtml:b> and declare
> the prefix? One could certainly use <equiv> to note the relationship,
> I think.
>
> a module called "typesetting" or "presentation" (not "kiss" :-})
> would do the job, and would even allow for a <font> element
> (no, I am not joking).
>
> There is a question, perhaps, over whether we should start
> talking about a TEI profile called "core", which we promote
> instead of "tei_all" as the normal test of TEI goodness. and that
> would not include the "typesetting" module. Cue lengthy argument.
>
> All that said, I don't think this request is so urgent that we shouldn't
> just put it on the agenda for the autumn. I'd much rather
> we resolved some requests which more genuinely block TCP translation,
> eg  3531957, 3531963, 3439980 - especially the latter!
> --
> Sebastian Rahtz
> Head of Information and Support Group
> Oxford University Computing Services
> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>
>
>
>
>
>
> --
> tei-council mailing list
> tei-council at lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>
> PLEASE NOTE: postings to this list are publicly archived

From sebastian.rahtz at oucs.ox.ac.uk  Thu Jul 19 05:09:04 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Thu, 19 Jul 2012 09:09:04 +0000
Subject: [tei-council] TITE again
In-Reply-To: <CAA2irtKzTDQaBT0gSgMa-XVN-WB0foAyQVv0U2ej8SZjXjFENQ@mail.gmail.com>
References: <7D89C1F94A704245AF5254CFAE7AA1A801CABC4A@evcspmbx1.ads.northwestern.edu>
	<5002ABA4.2000006@oucs.ox.ac.uk> <5002EFD2.9090303@uvic.ca>
	<43253F51-E75C-4668-8B0F-E8FA4E622D97@oucs.ox.ac.uk>
	<CAA2irtKzTDQaBT0gSgMa-XVN-WB0foAyQVv0U2ej8SZjXjFENQ@mail.gmail.com>
Message-ID: <8E7F4D7C-F0FE-4740-AE49-2893DD80B572@oucs.ox.ac.uk>


On 18 Jul 2012, at 16:38, Rebecca Welzenbach wrote:

> Rather than incorporating these convenience elements into P5, what if we instead explicitly acknowledge that people might use any number of shortcuts for efficiency in their own projects, and offer some basic support for transforming such texts to P5?

That is what we've been doing for ages with Tite (since it was launched, in fact), but no-one ever seems to notice. 
The transform mechanisms are built into Tite, and tite to TEI is delivered via the generic stylesheets.

I despair of anyone ever grokking this use of the <equiv> element.
--
Sebastian Rahtz      
Head of Information and Support Group
Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431







From kevin.s.hawkins at ultraslavonic.info  Sat Jul 21 14:41:04 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Sat, 21 Jul 2012 14:41:04 -0400
Subject: [tei-council] title page recto of P5 in HTML version
Message-ID: <500AF7C0.6010900@ultraslavonic.info>

The first page of 
http://www.tei-c.org/release/doc/tei-p5-doc/en/Guidelines.pdf says this:

###

TEI P5: Guidelines for Electronic Text Encoding and Inter?ange
by the TEI Consortium
Originally edited by C.M. Sperberg-Mc?een and Lou Burnard for the 
ACH-ALLC-ACL Text Encoding Initiative Now entirely revised and expanded 
under the supervision of the Te?nical Council of the TEI Consortium
edited by Lou Burnard and Syd Bauman 2.1.0. Last updated on 17th June 2012.
Text Encoding Initiative Consortium Charlo?esville, Virginia 2012
?e TEI Consortium

###

(Those characters that didn't copy and paste correctly are typographical 
glyphs for purely presentational effect.  You can ignore them for the 
purposes of this discussion, though a side question would be whether we 
can and should stop inserting these since they make the PDF less 
searchable.)

I can't find anything following "TEI P5: Guidelines for Electronic Text 
Encoding and Interchange" anywhere in the HTML version of the 
Guidelines, making me think it's hard-coded somewhere in the process 
that creates the PDF.  That would be a shame since it means that these 
two versions of the Guidelines differ in content, not just rendering. 
Furthermore, since I think we all agree that we want to encourage people 
to cite the HTML version and not just the PDF version (by page number!), 
it would be good if we had not only

http://www.tei-c.org/release/doc/tei-p5-doc/en/html/TitlePageVerso.html

online but also a

http://www.tei-c.org/release/doc/tei-p5-doc/en/html/TitlePageRecto.html

that included this stuff.  I'm open to this information instead being 
included somewhere at 
http://www.tei-c.org/release/doc/tei-p5-doc/en/html/index-toc.html , but 
I'm not sure where else to put it.

From sebastian.rahtz at oucs.ox.ac.uk  Mon Jul 23 05:29:43 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Mon, 23 Jul 2012 09:29:43 +0000
Subject: [tei-council] TEI stylesheets in silly season
Message-ID: <D57D3C6A-5712-4935-8207-690073C614F5@oucs.ox.ac.uk>

forgive me, folks, I am working on http://sourceforge.net/tracker/?func=detail&aid=3415801&group_id=106328&atid=644065;
while it mostly works, there are things which cause the Jenkins builds to fail.   The setup will remain broken for maybe
a few days while I resolve things.

if I cant sort it, I will back out, but these changes are complex (and important) so I want to get this done.
--
Sebastian Rahtz      
Head of Information and Support Group
Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431

S?lo le pido a Dios
que el futuro no me sea indiferente


From sebastian.rahtz at oucs.ox.ac.uk  Mon Jul 23 11:34:53 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Mon, 23 Jul 2012 15:34:53 +0000
Subject: [tei-council] title page recto of P5 in HTML version
In-Reply-To: <500AF7C0.6010900@ultraslavonic.info>
References: <500AF7C0.6010900@ultraslavonic.info>
Message-ID: <3829AC12-D84B-4829-8100-0B98A3533F64@oucs.ox.ac.uk>


On 21 Jul 2012, at 19:41, Kevin Hawkins wrote:

> 
> I can't find anything following "TEI P5: Guidelines for Electronic Text 
> Encoding and Interchange" anywhere in the HTML version of the 
> Guidelines, making me think it's hard-coded somewhere in the process 
> that creates the PDF.

no, those words are in the Guidelines source. See P5/Source/guidelines-en.xml

curious that they don't appear in the HTML, I agree. An interesting
bit of archaeology for someone to trace through the process
and see why not.
--
Sebastian Rahtz      
Head of Information and Support Group
Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431

S?lo le pido a Dios
que el futuro no me sea indiferente


From sebastian.rahtz at oucs.ox.ac.uk  Mon Jul 23 13:48:27 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Mon, 23 Jul 2012 17:48:27 +0000
Subject: [tei-council] local overrides to class attributes In P5 source
Message-ID: <06F62A4C-5C91-4E94-BC69-7E1638CFFAD5@oucs.ox.ac.uk>

This functionality is now ready, I am glad to say. If anyone wants to step up and test it, 
I'll be very interested to hear of problems. I am expecting some - this was a complex
change, but I hope the result is worth the candle.

The power we now have with this simple change is awesome, as it also
allows for chaining together ODD specifications:

   roma --compile  my1.odd .
   roma --localsource=my1.odd.compiled my2.odd

if that doesn't work, I want to hear about it

(of course, this assumes you use Stylesheets fresh-minted in Sourceforge)
--
Sebastian Rahtz      
Head of Information and Support Group
Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431

S?lo le pido a Dios
que el futuro no me sea indiferente


From sebastian.rahtz at oucs.ox.ac.uk  Tue Jul 24 04:20:38 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Tue, 24 Jul 2012 08:20:38 +0000
Subject: [tei-council] logical madness in class attribute inheritance
Message-ID: <6C7957B9-6F0A-4B33-8988-791D32901EF5@oucs.ox.ac.uk>

We have 4 attribute classes which define the attribute "type":

../Source/Specs/att.entryLike.xml:    <attDef ident="type" usage="opt">
../Source/Specs/att.interpLike.xml:    <attDef ident="type" usage="rec">
../Source/Specs/att.textCritical.xml:    <attDef ident="type" usage="opt">
../Source/Specs/att.typed.xml:    <attDef ident="type" usage="opt">

This is, frankly, bonkers. An element can freely be a member of all four classes,
and then what?

I have met this while fixing the local override of class attributes, and
find that if an element is in both classes, and overrides @type, I have no idea which one
it is overriding!

Sadly, I have thereby got the P5 build in a broken state because of ambiguities
here.
--
Sebastian Rahtz      
Head of Information and Support Group
Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431

S?lo le pido a Dios
que el futuro no me sea indiferente


From bansp at o2.pl  Tue Jul 24 06:22:18 2012
From: bansp at o2.pl (Piotr Banski)
Date: Tue, 24 Jul 2012 12:22:18 +0200
Subject: [tei-council] they spread the word
Message-ID: <500E775A.7060808@o2.pl>

The passage below comes from a recent contribution to the Linguistic 
Annotation Workshop co-located with the ACL conference in Jeju. I am not 
sure how to comment on it, so I'm just forwarding it for your 
information. This workshop is well-known among linguistic annotation 
researchers.

   P.

The Text Encoding Initiative (TEI) provides
guidelines for representing a variety of literary and
linguistic texts. The XML-based format is very rich
and among other provides means for encoding linguistic
annotation as well as some generic markup
for graphs, networks, trees, feature-structures, and
links. On the other hand, it lacks explicit support
for stand-off annotation style and makes use of entities,
an almost obsoleted feature of XML, that originates
in SGML. There are no tools supporting the
full specification.

http://faculty.washington.edu/fxia/LAWVI/proceedings/cdrom/pdf/LAWVI03.pdf

PS. One comment may be that the distinction between attributes and 
elements also originates in SGML. But what worries me is that while we 
can comment on the two issues (stand-off and entities) and justify the 
state of affairs or reject them as an accusation, they are the kind of 
statements that are easy to slap onto one's back but take time and 
explaining to unglue.

From gabriel.bodard at kcl.ac.uk  Tue Jul 24 06:43:23 2012
From: gabriel.bodard at kcl.ac.uk (Gabriel Bodard)
Date: Tue, 24 Jul 2012 11:43:23 +0100
Subject: [tei-council] logical madness in class attribute inheritance
In-Reply-To: <6C7957B9-6F0A-4B33-8988-791D32901EF5@oucs.ox.ac.uk>
References: <6C7957B9-6F0A-4B33-8988-791D32901EF5@oucs.ox.ac.uk>
Message-ID: <500E7C4B.5040409@kcl.ac.uk>

Presumably the correct way to resolve this is to have the other classes 
(other than att.typed, I guess), be members of but modify att.typed, by: 
omitting @subtype; making @type rec rather than opt; etc.?

On 2012-07-24 09:20, Sebastian Rahtz wrote:
> We have 4 attribute classes which define the attribute "type":
>
> ../Source/Specs/att.entryLike.xml:    <attDef ident="type" usage="opt">
> ../Source/Specs/att.interpLike.xml:    <attDef ident="type" usage="rec">
> ../Source/Specs/att.textCritical.xml:    <attDef ident="type" usage="opt">
> ../Source/Specs/att.typed.xml:    <attDef ident="type" usage="opt">
>
> This is, frankly, bonkers. An element can freely be a member of all four classes,
> and then what?
>
> I have met this while fixing the local override of class attributes, and
> find that if an element is in both classes, and overrides @type, I have no idea which one
> it is overriding!
>
> Sadly, I have thereby got the P5 build in a broken state because of ambiguities
> here.
> --
> Sebastian Rahtz
> Head of Information and Support Group
> Oxford University Computing Services
> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>
> S?lo le pido a Dios
> que el futuro no me sea indiferente
>

-- 
Dr Gabriel BODARD
(Research Associate in Digital Epigraphy)

Department of Digital Humanities
King's College London
26-29 Drury Lane
London WC2B 5RL

Email: gabriel.bodard at kcl.ac.uk
Tel: +44 (0)20 7848 1388
Fax: +44 (0)20 7848 2980

http://www.digitalclassicist.org/
http://www.currentepigraphy.org/

From sebastian.rahtz at oucs.ox.ac.uk  Tue Jul 24 06:45:30 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Tue, 24 Jul 2012 10:45:30 +0000
Subject: [tei-council] logical madness in class attribute inheritance
In-Reply-To: <500E7C4B.5040409@kcl.ac.uk>
References: <6C7957B9-6F0A-4B33-8988-791D32901EF5@oucs.ox.ac.uk>
	<500E7C4B.5040409@kcl.ac.uk>
Message-ID: <1160F71C-F926-4A4E-B220-EDB2689CADA8@oucs.ox.ac.uk>


On 24 Jul 2012, at 11:43, Gabriel Bodard wrote:

> Presumably the correct way to resolve this is to have the other classes 
> (other than att.typed, I guess), be members of but modify att.typed, by: 
> omitting @subtype; making @type rec rather than opt; etc.?


or at the element level. and that will test whether the new functionality works.

I am not sure whether local overrides in classes will work at the moment
--
Sebastian Rahtz      
Head of Information and Support Group
Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431

S?lo le pido a Dios
que el futuro no me sea indiferente


From sebastian.rahtz at oucs.ox.ac.uk  Tue Jul 24 06:47:44 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Tue, 24 Jul 2012 10:47:44 +0000
Subject: [tei-council] they spread the word
In-Reply-To: <500E775A.7060808@o2.pl>
References: <500E775A.7060808@o2.pl>
Message-ID: <9A78F063-DD78-45F6-9C7B-7AE868AA3129@oucs.ox.ac.uk>

dear me.  I think we are in the hands of people like you to correct these misunderstandings in your communities.

of course, its true that there are no "tools which support all of  TEI", whatever that might mean
--
Sebastian Rahtz      
Head of Information and Support Group
Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431

S?lo le pido a Dios
que el futuro no me sea indiferente


From James.Cummings at oucs.ox.ac.uk  Tue Jul 24 07:59:16 2012
From: James.Cummings at oucs.ox.ac.uk (James Cummings)
Date: Tue, 24 Jul 2012 12:59:16 +0100
Subject: [tei-council] TEI Newsfeed
Message-ID: <500E8E14.3090505@oucs.ox.ac.uk>


Hi all,

As you know SourceForge are terminating support for 'hosted 
apps'. This means they were going to shut down the wordpress blog 
that we use to power our newsfeed on TEI-C. Simultaneously many 
of us have had problems accessing the wordpress blog on 
SourceForge, so couldn't get a proper wordpress 'export' of the 
site.

I could, however, get a database dump of the wordpress database 
from SourceForge. I set up wordpress on my own machine 
temporarily, then imported this database, then manually edited it 
to create a real admin account (SourceForge always did this with 
a bit of indirection) and modify some necessary URLs. Once I 
could get into the local wordpress as an admin I exported the 
wordpress posts/categories/etc as a wordpress xml file. I then 
reimported these into 
http://textencodinginitiative.wordpress.com/ as a new location.

I've modified the shell script and XSLT in SVN under 
TEIC/newsfeed/ and updated those up on the tei-c.org machine. I 
put in a test post about the newsfeed move, and it all seems to 
be working.

However, there are bound to be some problems, especially with 
legacy URLs inside posts, etc.  If you happen across any please 
do let me know.

-James

-- 
Dr James Cummings, InfoDev,
OUCS, University of Oxford

From bansp at o2.pl  Tue Jul 24 08:14:14 2012
From: bansp at o2.pl (Piotr Banski)
Date: Tue, 24 Jul 2012 14:14:14 +0200
Subject: [tei-council] they spread the word
In-Reply-To: <9A78F063-DD78-45F6-9C7B-7AE868AA3129@oucs.ox.ac.uk>
References: <500E775A.7060808@o2.pl>
	<9A78F063-DD78-45F6-9C7B-7AE868AA3129@oucs.ox.ac.uk>
Message-ID: <500E9196.6040807@o2.pl>

On 24/07/12 12:47, Sebastian Rahtz wrote:
> dear me.  I think we are in the hands of people like you to correct these misunderstandings in your communities.

I'm rather sure that Adam Przepi?rkowski has reacted to the stand-off 
issue, given e.g. the NCP encoding [1].

http://nlp.ipipan.waw.pl/TEI4NKJP/

> of course, its true that there are no "tools which support all of  TEI", whatever that might mean

Oh, yes, that bit I've actually ignored :-)


Posted a FR on the XInclude issue:

https://sourceforge.net/tracker/?func=detail&aid=3547869&group_id=106328&atid=644065

Best,

   P.

From dsewell at virginia.edu  Tue Jul 24 09:27:57 2012
From: dsewell at virginia.edu (David Sewell)
Date: Tue, 24 Jul 2012 09:27:57 -0400 (EDT)
Subject: [tei-council] TEI Newsfeed
In-Reply-To: <500E8E14.3090505@oucs.ox.ac.uk>
References: <500E8E14.3090505@oucs.ox.ac.uk>
Message-ID: <alpine.OSX.2.00.1207240926270.48156@lister.ei.virginia.edu>

James, thanks! That's an act of heroism (for geeky values of "hero").

I'll take a look at the setup when I have a chance and will see about 
retroactively posting news items that went missing during the Sourceforge 
downtime.

David

On Tue, 24 Jul 2012, James Cummings wrote:

>
> Hi all,
>
> As you know SourceForge are terminating support for 'hosted
> apps'. This means they were going to shut down the wordpress blog
> that we use to power our newsfeed on TEI-C. Simultaneously many
> of us have had problems accessing the wordpress blog on
> SourceForge, so couldn't get a proper wordpress 'export' of the
> site.
>
> I could, however, get a database dump of the wordpress database
> from SourceForge. I set up wordpress on my own machine
> temporarily, then imported this database, then manually edited it
> to create a real admin account (SourceForge always did this with
> a bit of indirection) and modify some necessary URLs. Once I
> could get into the local wordpress as an admin I exported the
> wordpress posts/categories/etc as a wordpress xml file. I then
> reimported these into
> http://textencodinginitiative.wordpress.com/ as a new location.
>
> I've modified the shell script and XSLT in SVN under
> TEIC/newsfeed/ and updated those up on the tei-c.org machine. I
> put in a test post about the newsfeed move, and it all seems to
> be working.
>
> However, there are bound to be some problems, especially with
> legacy URLs inside posts, etc.  If you happen across any please
> do let me know.
>
> -James
>
>

-- 
David Sewell, Editorial and Technical Manager
ROTUNDA, The University of Virginia Press
PO Box 400314, Charlottesville, VA 22904-4314 USA
Email: dsewell at virginia.edu   Tel: +1 434 924 9973
Web: http://rotunda.upress.virginia.edu/

From James.Cummings at oucs.ox.ac.uk  Tue Jul 24 09:33:44 2012
From: James.Cummings at oucs.ox.ac.uk (James Cummings)
Date: Tue, 24 Jul 2012 14:33:44 +0100
Subject: [tei-council] TEI Newsfeed
In-Reply-To: <alpine.OSX.2.00.1207240926270.48156@lister.ei.virginia.edu>
References: <500E8E14.3090505@oucs.ox.ac.uk>
	<alpine.OSX.2.00.1207240926270.48156@lister.ei.virginia.edu>
Message-ID: <500EA438.9090207@oucs.ox.ac.uk>

On 24/07/12 14:27, David Sewell wrote:
> James, thanks! That's an act of heroism (for geeky values of
> "hero").

There might have been an easier way, but over the course of a 
couple hours that was the best that occurred to me.

> I'll take a look at the setup when I have a chance and will see
> about retroactively posting news items that went missing during
> the Sourceforge downtime.

Yes, you can post something retrospectively (by setting the 
publish date in the past), and you might want to uncheck the 
advertising of it to twitter (which I think I've set up as a 
blog-wide option for posting).

-James

-- 
Dr James Cummings, InfoDev,
OUCS, University of Oxford

From James.Cummings at oucs.ox.ac.uk  Tue Jul 24 12:05:48 2012
From: James.Cummings at oucs.ox.ac.uk (James Cummings)
Date: Tue, 24 Jul 2012 17:05:48 +0100
Subject: [tei-council] floatingDiv
Message-ID: <500EC7DC.7000107@oucs.ox.ac.uk>

Hi all,

One of the things I was tasked with in Ann Arbor that fell to the 
bottom of my to-do list was: "JC will reply to the message on 
TEI-L: In light of the current text and examples in the 
Guidelines on <floatingText> and <spGrp> , we?d like examples of 
proposed ?floating divs? and how they would differ from 
<floatingText> s."

Being a cautious sort, I've drafted up my response and put it here:

http://tinyurl.com/teicouncil-floatingdiv2012-07

If you have any additions/corrections, please feel free to make 
them before Wednesday at 5pm BST (about 24 hours from when this 
message was sent.)

-James

-- 
Dr James Cummings, InfoDev,
OUCS, University of Oxford

From mholmes at uvic.ca  Tue Jul 24 16:11:19 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Tue, 24 Jul 2012 13:11:19 -0700
Subject: [tei-council] they spread the word
In-Reply-To: <9A78F063-DD78-45F6-9C7B-7AE868AA3129@oucs.ox.ac.uk>
References: <500E775A.7060808@o2.pl>
	<9A78F063-DD78-45F6-9C7B-7AE868AA3129@oucs.ox.ac.uk>
Message-ID: <500F0167.9030402@uvic.ca>

Doesn't Oxygen support all of the TEI? Ditto Roma and Oxgarage? 
Depending, of course, on your definition of "support".

Cheers,
Martin

On 12-07-24 03:47 AM, Sebastian Rahtz wrote:
> dear me.  I think we are in the hands of people like you to correct these misunderstandings in your communities.
>
> of course, its true that there are no "tools which support all of  TEI", whatever that might mean
> --
> Sebastian Rahtz
> Head of Information and Support Group
> Oxford University Computing Services
> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>
> S?lo le pido a Dios
> que el futuro no me sea indiferente
>

-- 
Martin Holmes
mholmes at uvic.ca
UVic Humanities Computing and Media Centre

From bansp at o2.pl  Tue Jul 24 16:23:31 2012
From: bansp at o2.pl (Piotr Banski)
Date: Tue, 24 Jul 2012 22:23:31 +0200
Subject: [tei-council] they spread the word
In-Reply-To: <500F0167.9030402@uvic.ca>
References: <500E775A.7060808@o2.pl>
	<9A78F063-DD78-45F6-9C7B-7AE868AA3129@oucs.ox.ac.uk>
	<500F0167.9030402@uvic.ca>
Message-ID: <500F0443.1020602@o2.pl>

So does Emacs, in some sense. But I doubt that the authors wanted to go 
deeper into these issues. They needed to discard the potential 
alternatives to their proposal. ISO LAF was dealt with right after the 
TEI, so well, at least we're in good, CLARINesque company...

   P.


On 24/07/12 22:11, Martin Holmes wrote:
> Doesn't Oxygen support all of the TEI? Ditto Roma and Oxgarage?
> Depending, of course, on your definition of "support".
>
> Cheers,
> Martin
>
> On 12-07-24 03:47 AM, Sebastian Rahtz wrote:
>> dear me.  I think we are in the hands of people like you to correct these misunderstandings in your communities.
>>
>> of course, its true that there are no "tools which support all of  TEI", whatever that might mean
>> --
>> Sebastian Rahtz
>> Head of Information and Support Group
>> Oxford University Computing Services
>> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>>
>> S?lo le pido a Dios
>> que el futuro no me sea indiferente
>>
>


From james.cummings at oucs.ox.ac.uk  Tue Jul 24 16:25:38 2012
From: james.cummings at oucs.ox.ac.uk (James Cummings)
Date: Tue, 24 Jul 2012 20:25:38 +0000
Subject: [tei-council] they spread the word
In-Reply-To: <500F0167.9030402@uvic.ca>
References: <500E775A.7060808@o2.pl>
	<9A78F063-DD78-45F6-9C7B-7AE868AA3129@oucs.ox.ac.uk>,
	<500F0167.9030402@uvic.ca>
Message-ID: <aqj9kbly3uxd3t5wk8nri1sr.1343161532528@email.android.com>


Likewise I'm sure most of us could write a processor or XSLT script or something that could deal with "all of the TEI".... just depends if you want something sensible or something generalized that does something useful at all. (Mine just draws boxes around each element in html and CSS ... rounded corners and all. ;-) )

The question is how best to correct such mistaken understandings of the TEI and the purpose of descriptive markup that doesn't necessarily target a single output.

Jamesc
--
James Cummings, InfoDev, OUCS, University of Oxford (from phone)

Martin Holmes <mholmes at uvic.ca> wrote:


Doesn't Oxygen support all of the TEI? Ditto Roma and Oxgarage?
Depending, of course, on your definition of "support".

Cheers,
Martin

On 12-07-24 03:47 AM, Sebastian Rahtz wrote:
> dear me.  I think we are in the hands of people like you to correct these misunderstandings in your communities.
>
> of course, its true that there are no "tools which support all of  TEI", whatever that might mean
> --
> Sebastian Rahtz
> Head of Information and Support Group
> Oxford University Computing Services
> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>
> S?lo le pido a Dios
> que el futuro no me sea indiferente
>

--
Martin Holmes
mholmes at uvic.ca
UVic Humanities Computing and Media Centre
--
tei-council mailing list
tei-council at lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

PLEASE NOTE: postings to this list are publicly archived

From syeates at gmail.com  Tue Jul 24 16:40:14 2012
From: syeates at gmail.com (Stuart A. Yeates)
Date: Wed, 25 Jul 2012 08:40:14 +1200
Subject: [tei-council] floatingDiv
In-Reply-To: <500EC7DC.7000107@oucs.ox.ac.uk>
References: <500EC7DC.7000107@oucs.ox.ac.uk>
Message-ID: <CAC_Lu0aSKxNhJd4J2BHCd6er-TSf13qbyh8CjLEgr3_Op5kioA@mail.gmail.com>

Looks good to me.

You can sign yourself "(on behalf of the TEI Council)" or something to
add to the impression that this reflects consensus.

ng? mihi
stuart

On Wed, Jul 25, 2012 at 4:05 AM, James Cummings
<James.Cummings at oucs.ox.ac.uk> wrote:
> Hi all,
>
> One of the things I was tasked with in Ann Arbor that fell to the
> bottom of my to-do list was: "JC will reply to the message on
> TEI-L: In light of the current text and examples in the
> Guidelines on <floatingText> and <spGrp> , we?d like examples of
> proposed ?floating divs? and how they would differ from
> <floatingText> s."
>
> Being a cautious sort, I've drafted up my response and put it here:
>
> http://tinyurl.com/teicouncil-floatingdiv2012-07
>
> If you have any additions/corrections, please feel free to make
> them before Wednesday at 5pm BST (about 24 hours from when this
> message was sent.)
>
> -James
>
> --
> Dr James Cummings, InfoDev,
> OUCS, University of Oxford
> --
> tei-council mailing list
> tei-council at lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>
> PLEASE NOTE: postings to this list are publicly archived

From lou.burnard at retired.ox.ac.uk  Tue Jul 24 17:17:12 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Tue, 24 Jul 2012 22:17:12 +0100
Subject: [tei-council] they spread the word
In-Reply-To: <500F0443.1020602@o2.pl>
References: <500E775A.7060808@o2.pl>
	<9A78F063-DD78-45F6-9C7B-7AE868AA3129@oucs.ox.ac.uk>
	<500F0167.9030402@uvic.ca> <500F0443.1020602@o2.pl>
Message-ID: <500F10D8.3090007@retired.ox.ac.uk>

And what was their proposal exactly?

On 24/07/12 21:23, Piotr Banski wrote:
> So does Emacs, in some sense. But I doubt that the authors wanted to go
> deeper into these issues. They needed to discard the potential
> alternatives to their proposal. ISO LAF was dealt with right after the
> TEI, so well, at least we're in good, CLARINesque company...
>
>     P.
>
>
> On 24/07/12 22:11, Martin Holmes wrote:
>> Doesn't Oxygen support all of the TEI? Ditto Roma and Oxgarage?
>> Depending, of course, on your definition of "support".
>>
>> Cheers,
>> Martin
>>
>> On 12-07-24 03:47 AM, Sebastian Rahtz wrote:
>>> dear me.  I think we are in the hands of people like you to correct these misunderstandings in your communities.
>>>
>>> of course, its true that there are no "tools which support all of  TEI", whatever that might mean
>>> --
>>> Sebastian Rahtz
>>> Head of Information and Support Group
>>> Oxford University Computing Services
>>> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>>>
>>> S?lo le pido a Dios
>>> que el futuro no me sea indiferente
>>>
>>
>



From bbarney2 at unl.edu  Tue Jul 24 17:30:58 2012
From: bbarney2 at unl.edu (Brett Barney)
Date: Tue, 24 Jul 2012 21:30:58 +0000
Subject: [tei-council] floatingDiv
In-Reply-To: <500EC7DC.7000107@oucs.ox.ac.uk>
References: <500EC7DC.7000107@oucs.ox.ac.uk>
Message-ID: <81E1D480-1FD2-445D-B8E1-4812A0F22C79@unl.edu>

Nicely done.

On Jul 24, 2012, at 11:05 AM, James Cummings wrote:

> Hi all,
> 
> One of the things I was tasked with in Ann Arbor that fell to the 
> bottom of my to-do list was: "JC will reply to the message on 
> TEI-L: In light of the current text and examples in the 
> Guidelines on <floatingText> and <spGrp> , we?d like examples of 
> proposed ?floating divs? and how they would differ from 
> <floatingText> s."
> 
> Being a cautious sort, I've drafted up my response and put it here:
> 
> http://tinyurl.com/teicouncil-floatingdiv2012-07
> 
> If you have any additions/corrections, please feel free to make 
> them before Wednesday at 5pm BST (about 24 hours from when this 
> message was sent.)
> 
> -James
> 
> -- 
> Dr James Cummings, InfoDev,
> OUCS, University of Oxford
> -- 
> tei-council mailing list
> tei-council at lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
> 
> PLEASE NOTE: postings to this list are publicly archived
> 

----------------
Brett Barney
Associate Research Professor
Center for Digital Research in the Humanities
bbarney2 at unl.edu






From syeates at gmail.com  Tue Jul 24 17:47:09 2012
From: syeates at gmail.com (Stuart A. Yeates)
Date: Wed, 25 Jul 2012 09:47:09 +1200
Subject: [tei-council] they spread the word
In-Reply-To: <500F10D8.3090007@retired.ox.ac.uk>
References: <500E775A.7060808@o2.pl>
	<9A78F063-DD78-45F6-9C7B-7AE868AA3129@oucs.ox.ac.uk>
	<500F0167.9030402@uvic.ca> <500F0443.1020602@o2.pl>
	<500F10D8.3090007@retired.ox.ac.uk>
Message-ID: <CAC_Lu0bc0RiW=o+=TbZs-3kjiBG6+bnp1j2pBT66yD1jxPyDuQ@mail.gmail.com>

On Wed, Jul 25, 2012 at 9:17 AM, Lou Burnard
<lou.burnard at retired.ox.ac.uk> wrote:
> And what was their proposal exactly?

To reinvent the wheel, finding all the existing ones insufficiently elliptical.

cheers
stuart

From bansp at o2.pl  Tue Jul 24 18:12:04 2012
From: bansp at o2.pl (Piotr Banski)
Date: Wed, 25 Jul 2012 00:12:04 +0200
Subject: [tei-council] they spread the word
In-Reply-To: <500F10D8.3090007@retired.ox.ac.uk>
References: <500E775A.7060808@o2.pl>
	<9A78F063-DD78-45F6-9C7B-7AE868AA3129@oucs.ox.ac.uk>
	<500F0167.9030402@uvic.ca> <500F0443.1020602@o2.pl>
	<500F10D8.3090007@retired.ox.ac.uk>
Message-ID: <500F1DB4.4050702@o2.pl>

Theirs is actually a serious proposal, and well-tested, with a solid 
suite of tools. Designed for linguistic annotation (PDF linked from my 
first message). The point is that it's so good that they needn't have to 
resort to this kind of careless bashing. But they did, and coming from 
serious people, the claims unfortunately may look serious to some.

   P.

On 24/07/12 23:17, Lou Burnard wrote:
> And what was their proposal exactly?
>
> On 24/07/12 21:23, Piotr Banski wrote:
>> So does Emacs, in some sense. But I doubt that the authors wanted to go
>> deeper into these issues. They needed to discard the potential
>> alternatives to their proposal. ISO LAF was dealt with right after the
>> TEI, so well, at least we're in good, CLARINesque company...
>>
>>      P.
>>
>>
>> On 24/07/12 22:11, Martin Holmes wrote:
>>> Doesn't Oxygen support all of the TEI? Ditto Roma and Oxgarage?
>>> Depending, of course, on your definition of "support".
>>>
>>> Cheers,
>>> Martin
>>>
>>> On 12-07-24 03:47 AM, Sebastian Rahtz wrote:
>>>> dear me.  I think we are in the hands of people like you to correct these misunderstandings in your communities.
>>>>
>>>> of course, its true that there are no "tools which support all of  TEI", whatever that might mean
>>>> --
>>>> Sebastian Rahtz
>>>> Head of Information and Support Group
>>>> Oxford University Computing Services
>>>> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>>>>
>>>> S?lo le pido a Dios
>>>> que el futuro no me sea indiferente
>>>>
>>>
>>
>
>


From syeates at gmail.com  Tue Jul 24 18:15:50 2012
From: syeates at gmail.com (Stuart A. Yeates)
Date: Wed, 25 Jul 2012 10:15:50 +1200
Subject: [tei-council] they spread the word
In-Reply-To: <CAC_Lu0bc0RiW=o+=TbZs-3kjiBG6+bnp1j2pBT66yD1jxPyDuQ@mail.gmail.com>
References: <500E775A.7060808@o2.pl>
	<9A78F063-DD78-45F6-9C7B-7AE868AA3129@oucs.ox.ac.uk>
	<500F0167.9030402@uvic.ca> <500F0443.1020602@o2.pl>
	<500F10D8.3090007@retired.ox.ac.uk>
	<CAC_Lu0bc0RiW=o+=TbZs-3kjiBG6+bnp1j2pBT66yD1jxPyDuQ@mail.gmail.com>
Message-ID: <CAC_Lu0Zq=619DKeFsQRsAqHmevkC7o-Y4H=510Q-FbwyguVZ5g@mail.gmail.com>

On Wed, Jul 25, 2012 at 9:47 AM, Stuart A. Yeates <syeates at gmail.com> wrote:
> To reinvent the wheel, finding all the existing ones insufficiently elliptical.

I take that back. I shouldn't respond to emails before my first coffee
of the day.

cheers
stuart

From sebastian.rahtz at oucs.ox.ac.uk  Tue Jul 24 18:25:17 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Tue, 24 Jul 2012 22:25:17 +0000
Subject: [tei-council] they spread the word
In-Reply-To: <500F0167.9030402@uvic.ca>
References: <500E775A.7060808@o2.pl>
	<9A78F063-DD78-45F6-9C7B-7AE868AA3129@oucs.ox.ac.uk>
	<500F0167.9030402@uvic.ca>
Message-ID: <8E1B77E0-2A77-44EF-9D24-CFBFA3148933@oucs.ox.ac.uk>


On 24 Jul 2012, at 21:11, Martin Holmes wrote:

> Doesn't Oxygen support all of the TEI? Ditto Roma and Oxgarage? 
> Depending, of course, on your definition of "support".


how do you "support" the <link> element (etc)? its too general
a markup.

as someone said, the author of that paragraph plainly has an agenda,
and makes rhetorical remarks to support his/her thesis.
--
Sebastian Rahtz      
Head of Information and Support Group
Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431







From sebastian.rahtz at oucs.ox.ac.uk  Wed Jul 25 04:31:52 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Wed, 25 Jul 2012 08:31:52 +0000
Subject: [tei-council] floatingDiv
In-Reply-To: <500EC7DC.7000107@oucs.ox.ac.uk>
References: <500EC7DC.7000107@oucs.ox.ac.uk>
Message-ID: <11098e28-001d-483d-ad8b-4d6bada6d4a8@HUB06.ad.oak.ox.ac.uk>

seems fine to me
--
Sebastian Rahtz      
Head of Information and Support Group
Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431

S?lo le pido a Dios
que el futuro no me sea indiferente


From lou.burnard at retired.ox.ac.uk  Wed Jul 25 08:56:26 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Wed, 25 Jul 2012 13:56:26 +0100
Subject: [tei-council] floatingDiv
In-Reply-To: <11098e28-001d-483d-ad8b-4d6bada6d4a8@HUB06.ad.oak.ox.ac.uk>
References: <500EC7DC.7000107@oucs.ox.ac.uk>
	<11098e28-001d-483d-ad8b-4d6bada6d4a8@HUB06.ad.oak.ox.ac.uk>
Message-ID: <500FECFA.5020002@retired.ox.ac.uk>

I think the basic point is well made, but I think it could be more 
clearly expressed. I started trying to do that, but found I couldnt edit 
the google doc. So I made a copy and edited that as follows:


----------

The TEI Technical Council discussed the <floatingDiv> proposal 
http://purl.org/tei/fr/3504690 at its last face to face meeting. After 
much wide ranging discussion and many examples by one of the submitters 
of the proposal (Paul Schaffner), the general consensus which emerged 
was that the examples presented could be dealt with by various other 
existing means. It was felt that that the need to use floatingText/body 
did not present ta significant encoding burden for the textual phenomena 
discussed. Council also noted that the specific case of drama could now 
be handled by the <spGrp>. Council found it hard to identify a distinct 
use case where <floatingDiv> would be more appropriate than (or 
distinguishable from) <floatingText> element. This may also be because 
the prose describing <floatingText> has been relaxed from its first 
inception in P5 ver 1.0.0 and also its relationship with quote clarified.

The TEI Technical Council is willing to continue to consider this matter 
but requires:

     A clear categorisation of how to distinguish between <floatingText> 
and the proposed <floatingDiv>
     More examples of proposed <floatingDiv> candidates which are not 
adequately marked up using either <floatingText> or <spGrp>


Council requests that any further rremarks concerning the proposed 
<floatingDiv> element  be added to the http://purl.org/tei/fr/3504690 
SourceForge ticket for ease of discussion.


------------
On 25/07/12 09:31, Sebastian Rahtz wrote:
> seems fine to me
> --
> Sebastian Rahtz


> Head of Information and Support Group
> Oxford University Computing Services
> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>
> S?lo le pido a Dios
> que el futuro no me sea indiferente
>


From James.Cummings at oucs.ox.ac.uk  Wed Jul 25 09:52:12 2012
From: James.Cummings at oucs.ox.ac.uk (James Cummings)
Date: Wed, 25 Jul 2012 14:52:12 +0100
Subject: [tei-council] floatingDiv
In-Reply-To: <500FECFA.5020002@retired.ox.ac.uk>
References: <500EC7DC.7000107@oucs.ox.ac.uk>	<11098e28-001d-483d-ad8b-4d6bada6d4a8@HUB06.ad.oak.ox.ac.uk>
	<500FECFA.5020002@retired.ox.ac.uk>
Message-ID: <500FFA0C.3090003@oucs.ox.ac.uk>

On 25/07/12 13:56, Lou Burnard wrote:
> I think the basic point is well made, but I think it could be more
> clearly expressed. I started trying to do that, but found I couldnt edit
> the google doc. So I made a copy and edited that as follows:

That's strange... it is shared and world editable, honest.

I'll try to merge in your changes.

-James
>
>
> ----------
>
> The TEI Technical Council discussed the<floatingDiv>  proposal
> http://purl.org/tei/fr/3504690 at its last face to face meeting. After
> much wide ranging discussion and many examples by one of the submitters
> of the proposal (Paul Schaffner), the general consensus which emerged
> was that the examples presented could be dealt with by various other
> existing means. It was felt that that the need to use floatingText/body
> did not present ta significant encoding burden for the textual phenomena
> discussed. Council also noted that the specific case of drama could now
> be handled by the<spGrp>. Council found it hard to identify a distinct
> use case where<floatingDiv>  would be more appropriate than (or
> distinguishable from)<floatingText>  element. This may also be because
> the prose describing<floatingText>  has been relaxed from its first
> inception in P5 ver 1.0.0 and also its relationship with quote clarified.
>
> The TEI Technical Council is willing to continue to consider this matter
> but requires:
>
>       A clear categorisation of how to distinguish between<floatingText>
> and the proposed<floatingDiv>
>       More examples of proposed<floatingDiv>  candidates which are not
> adequately marked up using either<floatingText>  or<spGrp>
>
>
> Council requests that any further rremarks concerning the proposed
> <floatingDiv>  element  be added to the http://purl.org/tei/fr/3504690
> SourceForge ticket for ease of discussion.
>
>
> ------------
> On 25/07/12 09:31, Sebastian Rahtz wrote:
>> seems fine to me
>> --
>> Sebastian Rahtz
>
>
>> Head of Information and Support Group
>> Oxford University Computing Services
>> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>>
>> S?lo le pido a Dios
>> que el futuro no me sea indiferente
>>
>


-- 
Dr James Cummings, InfoDev,
OUCS, University of Oxford

From PFSchaffner at umich.edu  Wed Jul 25 11:48:22 2012
From: PFSchaffner at umich.edu (Paul F. Schaffner)
Date: Wed, 25 Jul 2012 11:48:22 -0400 (EDT)
Subject: [tei-council] floatingDiv
In-Reply-To: <500EC7DC.7000107@oucs.ox.ac.uk>
References: <500EC7DC.7000107@oucs.ox.ac.uk>
Message-ID: <Pine.LNX.4.64.1207251147160.12490@joust.gpcc.itd.umich.edu>

Looks ok to me. I have myself been collecting a handful of
use-case examples for floatingDiv, FWIW.

pfs


On Tue, 24 Jul 2012, James Cummings wrote:

> Hi all,
>
> One of the things I was tasked with in Ann Arbor that fell to the
> bottom of my to-do list was: "JC will reply to the message on
> TEI-L: In light of the current text and examples in the
> Guidelines on <floatingText> and <spGrp> , we?d like examples of
> proposed ?floating divs? and how they would differ from
> <floatingText> s."
>
> Being a cautious sort, I've drafted up my response and put it here:
>
> http://tinyurl.com/teicouncil-floatingdiv2012-07
>
> If you have any additions/corrections, please feel free to make
> them before Wednesday at 5pm BST (about 24 hours from when this
> message was sent.)
>
> -James
>
> -- 
> Dr James Cummings, InfoDev,
> OUCS, University of Oxford
> -- 
> tei-council mailing list
> tei-council at lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>
> PLEASE NOTE: postings to this list are publicly archived
>
>
>

--------------------------------------------------------------------
Paul Schaffner | PFSchaffner at umich.edu | http://www.umich.edu/~pfs/
316-C Hatcher Library N, Univ. of Michigan, Ann Arbor MI 48109-1190
--------------------------------------------------------------------

From lou.burnard at retired.ox.ac.uk  Wed Jul 25 17:10:47 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Wed, 25 Jul 2012 22:10:47 +0100
Subject: [tei-council] Lite and/or _Lite?
Message-ID: <501060D7.2050407@retired.ox.ac.uk>

I'm finally getting round to the action placed on me at last Council 
meeting concerning the ever popular "TEI Lite" document, and would 
appreciate confirmation that I'm about to do the right thing.

There are still two versions of this ODD in the svn repository under 
Exemplars: one (called tei_lite.odd) is defined by inclusion; the other 
(called teilite.odd) is defined by exclusion.

I'm pretty sure we agreed that we would henceforth maintain this 
document only in the "inclusion" form, if only so that we don't have to 
keep fixing it every time some new element is added to the Guidelines 
(which happens surprisingly often). But I'd like confirmation on that 
before zapping teilite.odd or moving it to the "Deprecated-old-junk" 
folder. Another possibility would of course be to maintain the two of 
them (possibly with some slightly less obscure naming difference) but I 
am hoping we don't want to do that.

Needless to say, the two versions have diverged slightly, with some 
recent minor updates being made independently by different people to the 
two files, or to  only one of them: I will in any case sort that out.




From lou.burnard at retired.ox.ac.uk  Wed Jul 25 17:13:26 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Wed, 25 Jul 2012 22:13:26 +0100
Subject: [tei-council] Lite and/or _Lite?
In-Reply-To: <501060D7.2050407@retired.ox.ac.uk>
References: <501060D7.2050407@retired.ox.ac.uk>
Message-ID: <50106176.4000707@retired.ox.ac.uk>

I should also add that the Makefile in Exemplars (and presumably 
therefore also Mr Jinks) only builds the tei_lite version. As it should.

On 25/07/12 22:10, Lou Burnard wrote:
> I'm finally getting round to the action placed on me at last Council
> meeting concerning the ever popular "TEI Lite" document, and would
> appreciate confirmation that I'm about to do the right thing.
>
> There are still two versions of this ODD in the svn repository under
> Exemplars: one (called tei_lite.odd) is defined by inclusion; the other
> (called teilite.odd) is defined by exclusion.
>
> I'm pretty sure we agreed that we would henceforth maintain this
> document only in the "inclusion" form, if only so that we don't have to
> keep fixing it every time some new element is added to the Guidelines
> (which happens surprisingly often). But I'd like confirmation on that
> before zapping teilite.odd or moving it to the "Deprecated-old-junk"
> folder. Another possibility would of course be to maintain the two of
> them (possibly with some slightly less obscure naming difference) but I
> am hoping we don't want to do that.
>
> Needless to say, the two versions have diverged slightly, with some
> recent minor updates being made independently by different people to the
> two files, or to  only one of them: I will in any case sort that out.
>
>
>


From kevin.s.hawkins at ultraslavonic.info  Wed Jul 25 17:26:03 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Wed, 25 Jul 2012 17:26:03 -0400
Subject: [tei-council] Lite and/or _Lite?
In-Reply-To: <50106176.4000707@retired.ox.ac.uk>
References: <501060D7.2050407@retired.ox.ac.uk>
	<50106176.4000707@retired.ox.ac.uk>
Message-ID: <5010646B.4010107@ultraslavonic.info>

Hmm, according to:

http://www.tei-c.org/Activities/Council/Meetings/tcm50.xml#body.1_div.1_div.2_div.2

we are using the exclusion version (teilite.odd) to generate schemas. 
That could be an error in the minutes, or someone may have misspoken.

On 7/25/2012 5:13 PM, Lou Burnard wrote:
> I should also add that the Makefile in Exemplars (and presumably
> therefore also Mr Jinks) only builds the tei_lite version. As it should.
>
> On 25/07/12 22:10, Lou Burnard wrote:
>> I'm finally getting round to the action placed on me at last Council
>> meeting concerning the ever popular "TEI Lite" document, and would
>> appreciate confirmation that I'm about to do the right thing.
>>
>> There are still two versions of this ODD in the svn repository under
>> Exemplars: one (called tei_lite.odd) is defined by inclusion; the other
>> (called teilite.odd) is defined by exclusion.
>>
>> I'm pretty sure we agreed that we would henceforth maintain this
>> document only in the "inclusion" form, if only so that we don't have to
>> keep fixing it every time some new element is added to the Guidelines
>> (which happens surprisingly often). But I'd like confirmation on that
>> before zapping teilite.odd or moving it to the "Deprecated-old-junk"
>> folder. Another possibility would of course be to maintain the two of
>> them (possibly with some slightly less obscure naming difference) but I
>> am hoping we don't want to do that.
>>
>> Needless to say, the two versions have diverged slightly, with some
>> recent minor updates being made independently by different people to the
>> two files, or to  only one of them: I will in any case sort that out.
>>
>>
>>
>

From sebastian.rahtz at oucs.ox.ac.uk  Wed Jul 25 17:32:35 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Wed, 25 Jul 2012 21:32:35 +0000
Subject: [tei-council] Lite and/or _Lite?
In-Reply-To: <501060D7.2050407@retired.ox.ac.uk>
References: <501060D7.2050407@retired.ox.ac.uk>
Message-ID: <31d1b2e9-d217-423a-863c-1b6f5b90d15b@HUB05.ad.oak.ox.ac.uk>

I thought this was sorted ages ago, to use the inclusion method. I'd say go for it

of course, as you have noted elsewhere, this will confuse Roma users,
who will find the inclusion converted to exclusion :-{
--
Sebastian Rahtz      
Head of Information and Support Group
Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431







From lou.burnard at retired.ox.ac.uk  Wed Jul 25 18:03:58 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Wed, 25 Jul 2012 23:03:58 +0100
Subject: [tei-council] Fwd: Re:  Lite and/or _Lite?
In-Reply-To: <50106D3C.3040809@retired.ox.ac.uk>
References: <50106D3C.3040809@retired.ox.ac.uk>
Message-ID: <50106D4E.3090109@retired.ox.ac.uk>




-------- Original Message --------
Subject: Re: [tei-council] Lite and/or _Lite?
Date: Wed, 25 Jul 2012 23:03:40 +0100
From: Lou Burnard <lou.burnard at retired.ox.ac.uk>
To: Kevin Hawkins <kevin.s.hawkins at ultraslavonic.info>

The minutes from Ann Arbor could be mistaken, or someone may have been
mistaken in asserting that we were actually still using teilite rather
than tei_lite . Does it matter? The current state of affairs is what we
all agreed we wanted!

I dont know when we started generating from tei_lite, but I think
Sebastian is right in suggesting it was well before the AA meeting.


On 25/07/12 22:58, Kevin Hawkins wrote:
> So are you saying that someone has changed what we are generating in
> Jenkins since Ann Arbor?  That is, what was stated in Ann Arbor is no
> longer true?
>
> On 7/25/2012 5:32 PM, Lou Burnard wrote:
>> Yes, as my second mail points out, we are indeed currently generating
>> from the "inclusion" version. Which is what the minutes say we agreed
>> (inter alia) to do.
>>
>>
>> On 25/07/12 22:26, Kevin Hawkins wrote:
>>> Hmm, according to:
>>>
>>> http://www.tei-c.org/Activities/Council/Meetings/tcm50.xml#body.1_div.1_div.2_div.2
>>>
>>>
>>>
>>> we are using the exclusion version (teilite.odd) to generate schemas.
>>> That could be an error in the minutes, or someone may have misspoken.
>>>
>>> On 7/25/2012 5:13 PM, Lou Burnard wrote:
>>>> I should also add that the Makefile in Exemplars (and presumably
>>>> therefore also Mr Jinks) only builds the tei_lite version. As it
>>>> should.
>>>>
>>>> On 25/07/12 22:10, Lou Burnard wrote:
>>>>> I'm finally getting round to the action placed on me at last Council
>>>>> meeting concerning the ever popular "TEI Lite" document, and would
>>>>> appreciate confirmation that I'm about to do the right thing.
>>>>>
>>>>> There are still two versions of this ODD in the svn repository under
>>>>> Exemplars: one (called tei_lite.odd) is defined by inclusion; the
>>>>> other
>>>>> (called teilite.odd) is defined by exclusion.
>>>>>
>>>>> I'm pretty sure we agreed that we would henceforth maintain this
>>>>> document only in the "inclusion" form, if only so that we don't
>>>>> have to
>>>>> keep fixing it every time some new element is added to the Guidelines
>>>>> (which happens surprisingly often). But I'd like confirmation on that
>>>>> before zapping teilite.odd or moving it to the "Deprecated-old-junk"
>>>>> folder. Another possibility would of course be to maintain the two of
>>>>> them (possibly with some slightly less obscure naming difference)
>>>>> but I
>>>>> am hoping we don't want to do that.
>>>>>
>>>>> Needless to say, the two versions have diverged slightly, with some
>>>>> recent minor updates being made independently by different people to
>>>>> the
>>>>> two files, or to only one of them: I will in any case sort that out.
>>>>>
>>>>>
>>>>>
>>>>
>>




From kevin.s.hawkins at ultraslavonic.info  Wed Jul 25 20:17:52 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Wed, 25 Jul 2012 20:17:52 -0400
Subject: [tei-council] Fwd: Re:  Lite and/or _Lite?
In-Reply-To: <50106D4E.3090109@retired.ox.ac.uk>
References: <50106D3C.3040809@retired.ox.ac.uk>
	<50106D4E.3090109@retired.ox.ac.uk>
Message-ID: <50108CB0.8050605@ultraslavonic.info>

Just like you, I am trying to clarify things.  I bring it up hoping that 
someone will say, "Ah, I made that change shortly after Ann Arbor" or 
something like that.  Then I can perhaps add a note in the minutes so 
that future historians of the TEI can make sense of them.

On 7/25/12 6:03 PM, Lou Burnard wrote:
>
>
>
> -------- Original Message --------
> Subject: Re: [tei-council] Lite and/or _Lite?
> Date: Wed, 25 Jul 2012 23:03:40 +0100
> From: Lou Burnard <lou.burnard at retired.ox.ac.uk>
> To: Kevin Hawkins <kevin.s.hawkins at ultraslavonic.info>
>
> The minutes from Ann Arbor could be mistaken, or someone may have been
> mistaken in asserting that we were actually still using teilite rather
> than tei_lite . Does it matter? The current state of affairs is what we
> all agreed we wanted!
>
> I dont know when we started generating from tei_lite, but I think
> Sebastian is right in suggesting it was well before the AA meeting.
>
>
> On 25/07/12 22:58, Kevin Hawkins wrote:
>> So are you saying that someone has changed what we are generating in
>> Jenkins since Ann Arbor?  That is, what was stated in Ann Arbor is no
>> longer true?
>>
>> On 7/25/2012 5:32 PM, Lou Burnard wrote:
>>> Yes, as my second mail points out, we are indeed currently generating
>>> from the "inclusion" version. Which is what the minutes say we agreed
>>> (inter alia) to do.
>>>
>>>
>>> On 25/07/12 22:26, Kevin Hawkins wrote:
>>>> Hmm, according to:
>>>>
>>>> http://www.tei-c.org/Activities/Council/Meetings/tcm50.xml#body.1_div.1_div.2_div.2
>>>>
>>>>
>>>>
>>>> we are using the exclusion version (teilite.odd) to generate schemas.
>>>> That could be an error in the minutes, or someone may have misspoken.
>>>>
>>>> On 7/25/2012 5:13 PM, Lou Burnard wrote:
>>>>> I should also add that the Makefile in Exemplars (and presumably
>>>>> therefore also Mr Jinks) only builds the tei_lite version. As it
>>>>> should.
>>>>>
>>>>> On 25/07/12 22:10, Lou Burnard wrote:
>>>>>> I'm finally getting round to the action placed on me at last Council
>>>>>> meeting concerning the ever popular "TEI Lite" document, and would
>>>>>> appreciate confirmation that I'm about to do the right thing.
>>>>>>
>>>>>> There are still two versions of this ODD in the svn repository under
>>>>>> Exemplars: one (called tei_lite.odd) is defined by inclusion; the
>>>>>> other
>>>>>> (called teilite.odd) is defined by exclusion.
>>>>>>
>>>>>> I'm pretty sure we agreed that we would henceforth maintain this
>>>>>> document only in the "inclusion" form, if only so that we don't
>>>>>> have to
>>>>>> keep fixing it every time some new element is added to the Guidelines
>>>>>> (which happens surprisingly often). But I'd like confirmation on that
>>>>>> before zapping teilite.odd or moving it to the "Deprecated-old-junk"
>>>>>> folder. Another possibility would of course be to maintain the two of
>>>>>> them (possibly with some slightly less obscure naming difference)
>>>>>> but I
>>>>>> am hoping we don't want to do that.
>>>>>>
>>>>>> Needless to say, the two versions have diverged slightly, with some
>>>>>> recent minor updates being made independently by different people to
>>>>>> the
>>>>>> two files, or to only one of them: I will in any case sort that out.
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>
>
>
>

From sebastian.rahtz at oucs.ox.ac.uk  Thu Jul 26 06:20:36 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Thu, 26 Jul 2012 10:20:36 +0000
Subject: [tei-council] TEI P5 back working
Message-ID: <6B90F017-1D81-43C9-942A-5006FD02A4AD@oucs.ox.ac.uk>

in case any of you were wondering, the TEI P5 build is now clean again. Apologies for 3 days of disruption.
--
Sebastian Rahtz      
Head of Information and Support Group
Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431

S?lo le pido a Dios
que el futuro no me sea indiferente


From lou.burnard at retired.ox.ac.uk  Thu Jul 26 06:21:27 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Thu, 26 Jul 2012 11:21:27 +0100
Subject: [tei-council] TEI P5 back working
In-Reply-To: <6B90F017-1D81-43C9-942A-5006FD02A4AD@oucs.ox.ac.uk>
References: <6B90F017-1D81-43C9-942A-5006FD02A4AD@oucs.ox.ac.uk>
Message-ID: <50111A27.1010904@retired.ox.ac.uk>

On 26/07/12 11:20, Sebastian Rahtz wrote:
> in case any of you were wondering, the TEI P5 build is now clean again. Apologies for 3 days of disruption.
> --
>
I blame that Ludwig van Beethoven. A real troublemaker.




From sebastian.rahtz at oucs.ox.ac.uk  Thu Jul 26 06:28:30 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Thu, 26 Jul 2012 10:28:30 +0000
Subject: [tei-council] TEI P5 back working
In-Reply-To: <50111A27.1010904@retired.ox.ac.uk>
References: <6B90F017-1D81-43C9-942A-5006FD02A4AD@oucs.ox.ac.uk>
	<50111A27.1010904@retired.ox.ac.uk>
Message-ID: <32eeaa8e-96ca-45e1-970d-738582822fb4@HUB06.ad.oak.ox.ac.uk>


On 26 Jul 2012, at 11:21, Lou Burnard wrote:

>> in case any of you were wondering, the TEI P5 build is now clean again. Apologies for 3 days of disruption.
>> --
>> 
> I blame that Ludwig van Beethoven. A real troublemaker.
> 

that is so unfair! my outing to Beethoven is what let me charge my spiritual batteries
and find the remaining bugs.

Bach B minor Mass next week.

and then Bruckner 9 with Bernard Haitink in September. I am _so_ excited
about that one. It fulfills an ambition I have had since 1977, no joking.

--
Sebastian Rahtz      
Head of Information and Support Group
Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431

S?lo le pido a Dios
que el futuro no me sea indiferente


From lou.burnard at retired.ox.ac.uk  Thu Jul 26 10:30:36 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Thu, 26 Jul 2012 15:30:36 +0100
Subject: [tei-council] Lite Final
Message-ID: <5011548C.9040206@retired.ox.ac.uk>

I've written up some comments on what may or may not need changing to 
produce a "final" version of the TEI Lite tutorial and put them on the 
vicky thang.

see http://wiki.tei-c.org/index.php/LiteFinal

This contains 22 questions. You can answer them either there (but 
remember to sign you answer) or in an email here.




From sebastian.rahtz at oucs.ox.ac.uk  Thu Jul 26 10:45:32 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Thu, 26 Jul 2012 14:45:32 +0000
Subject: [tei-council] Lite Final
In-Reply-To: <5011548C.9040206@retired.ox.ac.uk>
References: <5011548C.9040206@retired.ox.ac.uk>
Message-ID: <f9c42ace-f970-4d31-be37-f93456c5f1a9@HUB06.ad.oak.ox.ac.uk>


On 26 Jul 2012, at 15:30, Lou Burnard wrote:

> I've written up some comments on what may or may not need changing to 
> produce a "final" version of the TEI Lite tutorial and put them on the 
> vicky thang.
> 
> see http://wiki.tei-c.org/index.php/LiteFinal
> 
> This contains 22 questions. You can answer them either there (but 
> remember to sign you answer) or in an email here.



1. maybe. not urgent?

2. no, its weird to remove standard XML things

3. no. leave sleeping dogs

4.  pass

5. ok

6. pass

7. NO!!!!!!!

8. document <said>

9. pass

10. pass

11. pass

12. not now. one day.

13. no. too many dragons

14.  I'd drop 16.1 entirely.  

15.  pass

16. yes, put in @facs. good idea.

17.  dunno. I kind of like that stuff  well, up to 19.2 at least. but  probably leave alone

   <change who="EMB"> 

shocking. missing the hash


The formal stuff at the end is amusing. it shows att.global as changed, but does not indicate how or why. drat.
--
Sebastian Rahtz      
Head of Information and Support Group
Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431

S?lo le pido a Dios
que el futuro no me sea indiferente


From James.Cummings at oucs.ox.ac.uk  Thu Jul 26 11:30:30 2012
From: James.Cummings at oucs.ox.ac.uk (James Cummings)
Date: Thu, 26 Jul 2012 16:30:30 +0100
Subject: [tei-council] Lite Final
In-Reply-To: <5011548C.9040206@retired.ox.ac.uk>
References: <5011548C.9040206@retired.ox.ac.uk>
Message-ID: <50116296.5000405@oucs.ox.ac.uk>

On 26/07/12 15:30, Lou Burnard wrote:
> This contains 22 questions. You can answer them either there
> (but remember to sign you answer) or in an email here.

My votes below.

> 1. The discussion of the Jane Eyre example should be improved,
> for example to comment on the treatment of end-of-line
> hyphenation (is it honeymoon or honey-moon ?) Should the list
> of cool things following the example not be linked to the
> section in which said cool thing is discussed?

Yes, the discussion could be improved slightly, and yes, the list 
could point to the appropriate sections of the TEI Guidelines. 
(However, I would point to the Vault version for which this 
version of TEI Lite is fixed against.)


> 2. should xml:base and xnl:space be removed from the schema?
> Neither is discussed -- if we keep them, they must be.

Remove them.

> 3. Should the section on divisions warn against some vulgar
> errors (mono-div bodies, misuse of @n to contain <head>
> values, attempts to evade the tessellation requirement)?

If so, only very briefly.

> 4. Should section 4.3 (and the schema) include discussion of
> <spGroup> ?

No, that sounds heavy not Lite.

> 5. A simpler prose drama example should be added to 4.3 before
> it launches into the complexities of overlapping hierarchies.
> It should be contrasted with the Fish example: which last
> should not use the @who attribute since this is explained
> later.

Yes, simpler prose drama would be good.

> 6. "the names used for editions referred to by the @ed
> attribute... [is] documented in the header" Is it? But where?

Using editionStmt mentioned further down?

> 7. Should the discussion of @rend (6.1) mention the
> possibility of using CSS as value?

No, absolutely not, in my opinion.

> 8. In 6.2 we define q and quote but not said. My preference
> would be to remove quote, but if we add it we should either
> remove q or add said as well.

I'd probably add said.

> 9. I havent checked whether the discussion of xml:lang values
> in footnote in section 6.3 is still politically correct. Is
> it?

The document it points to has been deprecated. Should it point 
instead to: http://www.loc.gov/standards/iso639-2/php/code_list.php ?

> 10. Section 7 (just before the first example) has another
> vague reference to the Header, which should be made more
> precise or removed.

Agreed, should be made more precise.  (Though I'm not entirely 
sure what it should say.)

> 11. Sections 8 and 9 seem to have stood the test of time quite
> well, and I see no need to modify them

In 8.3 @ana "links an element with its interpretation" maybe 
shouldn't be singular? 'one or more interpretations'.  Otherwise, 
nothing jumped out at me.


> 12. Should section 10 say something about linked data? At
> least a reference to the existence of the @ref attribute? (In
> that context, we should probably also include somewhere a
> comment that elements with a value for their xml:id attribute
> -- at the least the TEI element itself -- can ipso facto be
> exposed as LOD.

Maybe two sentences, one of the @ref attribute and one on what a 
good idea putting @xml:id's on things are since it simplifies 
people pointing into their files.  Otherwise, I wouldn't get into 
LOD etc. here.

> 13. Does section 12 (on bibliographies) need expanding?

I'd vote no. You'd want to change it too much.

> 14. Should section 16 also contain a reference to egXML, and
> hence some discussion of name spaces? Should it at least
> explain what an ODD is?

Unlike SPQR, I'd leave 16.1 and include a link to the USE chapter 
explaining that these are more elements are used for storing TEI 
customisations.

> 15. Is the extended example in 16.3 actually useful enough to
> keep? Wouldn't a brief discussion of what an ODD is and how
> you might use one to define your own technical manual be much
> more useful?

While I'd probably like that this isn't a manual for me. I'd 
leave it as is.


> 16. Should the @facs attribute be added to the schema and to
> the discussion in section 14? I think so : lots of people
> produce simple Lite-based "digital editions"

Yes, add @facs and document very briefly (point to chapter for 
more information?)

> 17. Is the treatment of front and back matter too detailed?
> Which parts would you remove? (Me, I love it all; except maybe
> the list of suggested values for @types of prefatory matter)

Leave it. (But yes, potentially nuke suggested values of @type 
there.)

> 18. Something went wrong (probably a rogue #uri) at the end of
> section 18 sv "index"

yes. That should be fixed.

> 19. 19.1.4 should probably include an example using <licence>
> . OTOH, I think elements <notesStmt> and <biblFull> could
> probably go.

Yes, include licence, keep notesStmt, ditch biblFull would be my 
vote.

> 20 19.3 needs an example of using >catRef

potentially

> 21. 19.4 might profitably say that there better ways of
> handling revision history

It might point out that these change elements can be updated by 
proper version control systems. (But I'd stay vague and neutral 
on what those are and how to do so.)


> 22. The appendix "Substantive changes from the P4 version"
> should go. It's out of date and incomplete.

Agreed.


-James


-- 
Dr James Cummings, InfoDev,
OUCS, University of Oxford

From dsewell at virginia.edu  Thu Jul 26 16:32:50 2012
From: dsewell at virginia.edu (David Sewell)
Date: Thu, 26 Jul 2012 16:32:50 -0400 (EDT)
Subject: [tei-council] Query on manuscript catalogue records from Chilean
	museum
Message-ID: <alpine.OSX.2.00.1207261628210.45652@lister.ei.virginia.edu>

Council,

Any suggestions on how to reply to this questioner? They may be under a 
misapprehension about the necessity for TEI membership (or the idea that we're 
interested in selling a product). But is there anyone in the museum community to 
point them to?

---------- Forwarded message ----------
Date: Thu, 26 Jul 2012 16:12:20 -0400
From: FELIPE ANDRES CONTRERAS <fscontre at uc.cl>
To: info at tei-c.org, Daniel Gonz?lez Erices <dgonzalez.erices at gmail.com>,
     valentina caceres <vdcaceres at gmail.com>
Subject: Querry

To whom it may concern,

My name is Felipe Contreras, and I'm currently collaborating with a
research project on three Illuminated Manuscripts of the second half of the
15th Century at the Museo de Artes Decorativas de Santiago de Chile. One of
our objectives is to produce a catalogue record of each manuscript, and we
are very interested in the services of your website. In order to propose to
the museum the purchase of a memebership, we want to ask you for an example
of a document using the TEI system, and also if you can tell us the
highlights of your product, as well, why it would be the best option for us.

Yours sincerely,

Felipe Contreras
Research Assistant
Illuminated Manuscripts Research Group
Museo de Artes Decorativas

From mholmes at uvic.ca  Thu Jul 26 18:45:52 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Thu, 26 Jul 2012 15:45:52 -0700
Subject: [tei-council] Lite Final
In-Reply-To: <5011548C.9040206@retired.ox.ac.uk>
References: <5011548C.9040206@retired.ox.ac.uk>
Message-ID: <5011C8A0.9040207@uvic.ca>

I took a look at the @xml:lang stuff, since that's fresh in my mind, and 
it's all wrong. I'll rewrite it at some point when I get back from 
vacation. Since the main Guidelines section on this is now much simpler, 
and basically hands off the explanation to two W3C documents and the 
authoritative IANA subtag registry, TEI Lite might as well do the same 
thing. All the examples will need fixing, though.

Cheers,
Martin

On 12-07-26 07:30 AM, Lou Burnard wrote:
> I've written up some comments on what may or may not need changing to
> produce a "final" version of the TEI Lite tutorial and put them on the
> vicky thang.
>
> see http://wiki.tei-c.org/index.php/LiteFinal
>
> This contains 22 questions. You can answer them either there (but
> remember to sign you answer) or in an email here.
>
>
>

-- 
Martin Holmes
mholmes at uvic.ca
UVic Humanities Computing and Media Centre

From mholmes at uvic.ca  Thu Jul 26 18:51:38 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Thu, 26 Jul 2012 15:51:38 -0700
Subject: [tei-council] Lite Final
In-Reply-To: <50116296.5000405@oucs.ox.ac.uk>
References: <5011548C.9040206@retired.ox.ac.uk>
	<50116296.5000405@oucs.ox.ac.uk>
Message-ID: <5011C9FA.7000603@uvic.ca>

On 12-07-26 08:30 AM, James Cummings wrote:
>> 9. I havent checked whether the discussion of xml:lang values
>> >in footnote in section 6.3 is still politically correct. Is
>> >it?
> The document it points to has been deprecated. Should it point
> instead to:http://www.loc.gov/standards/iso639-2/php/code_list.php  ?

No. Some 639-2 3-letter codes are used, but basically only where there 
is no eequivalent 2-letter code from 639-1. The authority is the IANA 
subtag registry, though. See the latest build of the guidelines for 
pointers to good explanations.

Cheers,
Martin

-- 
Martin Holmes
mholmes at uvic.ca
UVic Humanities Computing and Media Centre

From kevin.s.hawkins at ultraslavonic.info  Thu Jul 26 20:46:25 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Thu, 26 Jul 2012 20:46:25 -0400
Subject: [tei-council] Query on manuscript catalogue records from
 Chilean museum
In-Reply-To: <alpine.OSX.2.00.1207261628210.45652@lister.ei.virginia.edu>
References: <alpine.OSX.2.00.1207261628210.45652@lister.ei.virginia.edu>
Message-ID: <5011E4E1.7050105@ultraslavonic.info>

The people in the TEI community most knowledgeable about the museum 
community are probably the ontologists working with CIDOC-CRM.  Oyvind 
comes to mind.

But there are many more people who are doing manuscript catalogues. 
Jindrich Marek, Matija Ogrin, and Matthew Driscoll come to mind. 
Instead of referring to individuals, you might simply suggest they join 
TEI-L and post there to explain what they want to do and ask for 
samples, as is common practice.

--K.

On 7/26/12 4:32 PM, David Sewell wrote:
> Council,
>
> Any suggestions on how to reply to this questioner? They may be under a
> misapprehension about the necessity for TEI membership (or the idea that
> we're interested in selling a product). But is there anyone in the
> museum community to point them to?
>
> ---------- Forwarded message ----------
> Date: Thu, 26 Jul 2012 16:12:20 -0400
> From: FELIPE ANDRES CONTRERAS <fscontre at uc.cl>
> To: info at tei-c.org, Daniel Gonz?lez Erices <dgonzalez.erices at gmail.com>,
>      valentina caceres <vdcaceres at gmail.com>
> Subject: Querry
>
> To whom it may concern,
>
> My name is Felipe Contreras, and I'm currently collaborating with a
> research project on three Illuminated Manuscripts of the second half of the
> 15th Century at the Museo de Artes Decorativas de Santiago de Chile. One of
> our objectives is to produce a catalogue record of each manuscript, and we
> are very interested in the services of your website. In order to propose to
> the museum the purchase of a memebership, we want to ask you for an example
> of a document using the TEI system, and also if you can tell us the
> highlights of your product, as well, why it would be the best option for
> us.
>
> Yours sincerely,
>
> Felipe Contreras
> Research Assistant
> Illuminated Manuscripts Research Group
> Museo de Artes Decorativas
>
>

From lou.burnard at retired.ox.ac.uk  Sat Jul 28 12:02:42 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Sat, 28 Jul 2012 17:02:42 +0100
Subject: [tei-council] Lite Final
In-Reply-To: <5011548C.9040206@retired.ox.ac.uk>
References: <5011548C.9040206@retired.ox.ac.uk>
Message-ID: <50140D22.8000208@retired.ox.ac.uk>

I've now added the comments from James, Sebastian, and Martin into the 
wiki page, and it seems clear that we should make at least the following 
major changes:

5. add simpler example for prose drama

9. correct the discussion of xml:lang values

16. add @facs

There are several bits we agree should be left alone.

There are some points of contention, e.g.

7. James and Sebastian object strongly to mentioning CSS in discussing 
@rend, I think it's not such a bad idea, since we don't discuss any of 
the other options for documenting rendition.

8. I would prefer to remove <quote> rather than add <said>, leaving just 
<q> and explaining that this is ambiguous between <quote> and <said>. SR 
and JC prefer to add <said> to the mix, retaining <q>, which seems like 
tag overload to me.

And there are several points of uncertainty...

I propose to wait until Monday morning for further input from Council 
members, and then start hacking the source. OK?


On 26/07/12 15:30, Lou Burnard wrote:
> I've written up some comments on what may or may not need changing to
> produce a "final" version of the TEI Lite tutorial and put them on the
> vicky thang.
>
> see http://wiki.tei-c.org/index.php/LiteFinal
>
> This contains 22 questions. You can answer them either there (but
> remember to sign you answer) or in an email here.
>
>
>


From sebastian.rahtz at oucs.ox.ac.uk  Sat Jul 28 12:35:30 2012
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Sat, 28 Jul 2012 16:35:30 +0000
Subject: [tei-council] Lite Final
In-Reply-To: <50140D22.8000208@retired.ox.ac.uk>
References: <5011548C.9040206@retired.ox.ac.uk>
	<50140D22.8000208@retired.ox.ac.uk>
Message-ID: <0c1ee9d3-a999-4e2b-a583-eb5a2d087bc6@HUB06.ad.oak.ox.ac.uk>


On 28 Jul 2012, at 17:02, Lou Burnard <lou.burnard at retired.ox.ac.uk> wrote:

> 
> 7. James and Sebastian object strongly to mentioning CSS in discussing 
> @rend, I think it's not such a bad idea, since we don't discuss any of 
> the other options for documenting rendition.

I think that if we mention CSS in the Lite doc, it is effectively making
a decision to come down 100% on the side of John Walsh's
SF ticket. If we don't want to do that, then it is highly inappropriate
to sneak it into Lite by the back door. So let us make the CSS decision
first....

(I claim that the mood of the meeting is more on the side of adding
a new @style attribute than other solutions)
> 
> 8. I would prefer to remove <quote> rather than add <said>, leaving just 
> <q> and explaining that this is ambiguous between <quote> and <said>. SR 
> and JC prefer to add <said> to the mix, retaining <q>, which seems like 
> tag overload to me.

I'm easy on that one. 

--
Sebastian Rahtz      
Head of Information and Support Group
Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431







From gabriel.bodard at kcl.ac.uk  Mon Jul 30 11:05:00 2012
From: gabriel.bodard at kcl.ac.uk (Gabriel BODARD)
Date: Mon, 30 Jul 2012 16:05:00 +0100
Subject: [tei-council] Lite Final
In-Reply-To: <0c1ee9d3-a999-4e2b-a583-eb5a2d087bc6@HUB06.ad.oak.ox.ac.uk>
References: <5011548C.9040206@retired.ox.ac.uk>
	<50140D22.8000208@retired.ox.ac.uk>
	<0c1ee9d3-a999-4e2b-a583-eb5a2d087bc6@HUB06.ad.oak.ox.ac.uk>
Message-ID: <5016A29C.6050608@kcl.ac.uk>

On 28/07/2012 17:35, Sebastian Rahtz wrote:
> I think that if we mention CSS in the Lite doc, it is effectively making
> a decision to come down 100% on the side of John Walsh's
> SF ticket. If we don't want to do that, then it is highly inappropriate
> to sneak it into Lite by the back door. So let us make the CSS decision
> first....

I agree. Mentioning CSS in Lite would be going against what it looks 
like we're about to decide in response to ticket 
<http://purl.org/tei/fr/3519866>. Instead, why not mention @rendition in 
Lite?

G


-- 
Dr Gabriel BODARD
(Research Associate in Digital Epigraphy)

Department of Digital Humanities
King's College London
26-29 Drury Lane
London WC2B 5RL

Email: gabriel.bodard at kcl.ac.uk
Tel: +44 (0)20 7848 1388
Fax: +44 (0)20 7848 2980

http://www.digitalclassicist.org/
http://www.currentepigraphy.org/

From gabriel.bodard at kcl.ac.uk  Tue Jul 31 10:45:50 2012
From: gabriel.bodard at kcl.ac.uk (Gabriel BODARD)
Date: Tue, 31 Jul 2012 15:45:50 +0100
Subject: [tei-council] Certainty within milestoneLike
Message-ID: <5017EF9E.2000804@kcl.ac.uk>

At Ann Arbor I was asked to do a survey of the TEI Guidelines to see 
what sort of changes would be involved in adding the certLike elements 
(certainty, precision and respons) to the content model of milestoneLike 
elements, as discussed in ticket <http://purl.org/tei/fr/3416130> (tl;dr 
version: this would allow the use of @match='..' to point to these 
elements and make various kinds of certainty/precision statements about 
various aspects/attributes of these elements). I have surveyed the 44 
currently empty elements in the TEI, and have the following recommendations:

MILESTONE (cb, gb, lb, milestone, pb): these are the element that my 
feature request as written proposes to add certLike to.

TRANSCRIPTIONAL (caesura, handShift, pause, redo, shift, undo, move): 
these elements involve aspects of the transcription of the text and so 
are potentially subject to interpretation, uncertainty or other 
qualification. For consistency's sake, you might argue that these should 
be treated like the milestone elements too.

TRANSCRIPTIONAL, SPANNING (addSpan, anchor, damageSpan, delSpan, 
lacunaEnd, lacunaStart, witEnd, witStart): these are also 
transcriptional elements, but since they all mark the beginning and end 
of ranges or spans, there may be less features of such elements that are 
subject to interpretation, so the argument for allowing certLike inside 
them may be weaker. I am agnostic.

LINKING (alt, link): in principle these are not transcriptional but 
stand-off elements, so probably don't need certLike in any event. (Cf. 
however <join>, which is already only pseudo-empty.)

ODD (attRef, catRef, classRef, elementRef, equiv, macroRef, specDesc, 
specGrpRef): obviously not. These should remain empty.

FS (binary, default, fsdLink, iff, numeric, symbol, then, when): 
presumably not either, although I don't pretend to have any idea what FS 
is about.

ADMIN (graphic, ptr, variantEncoding, refState): for want of a better 
label--these elements are not really transcription but rather support 
the markup, so I suspect they don't need certLike at all.

DICTIONARIES (oRef, pRef): my instinct is to say these don't either, but 
is this module ever used to transcribe existing print dictionaries, and 
so subject to the sorts of uncertainty that other transcription elements 
are? If so, then yes, they deserve in as much as TRANSCRIPTIONAL (above) do.

*My Proposal:* to accept the ticket and add certLike to the content 
model of the milestoneLike and transcriptional elements listed above. If 
anyone feels strongly that the transcriptional/spanning elements and/or 
the dictionary elements should also be added to this group, then please 
shout now.

Objections and counter-proposals welcome, of course.

Cheers,

Gabby

-- 
Dr Gabriel BODARD
(Research Associate in Digital Epigraphy)

Department of Digital Humanities
King's College London
26-29 Drury Lane
London WC2B 5RL

Email: gabriel.bodard at kcl.ac.uk
Tel: +44 (0)20 7848 1388
Fax: +44 (0)20 7848 2980

http://www.digitalclassicist.org/
http://www.currentepigraphy.org/

From kevin.s.hawkins at ultraslavonic.info  Tue Jul 31 12:41:31 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Tue, 31 Jul 2012 12:41:31 -0400
Subject: [tei-council] Certainty within milestoneLike
In-Reply-To: <5017EF9E.2000804@kcl.ac.uk>
References: <5017EF9E.2000804@kcl.ac.uk>
Message-ID: <50180ABB.7050500@ultraslavonic.info>

Gabby and all,

On 7/31/2012 10:45 AM, Gabriel BODARD wrote:
> TRANSCRIPTIONAL (caesura, handShift, pause, redo, shift, undo, move):
> these elements involve aspects of the transcription of the text and so
> are potentially subject to interpretation, uncertainty or other
> qualification. For consistency's sake, you might argue that these should
> be treated like the milestone elements too.

I can imagine uncertainty over where exactly a shift in hand 
(<handShift/>) occurs or whether a pause (<pause/>) occurs at all.  So I 
treat these like the milestone elements.

> TRANSCRIPTIONAL, SPANNING (addSpan, anchor, damageSpan, delSpan,
> lacunaEnd, lacunaStart, witEnd, witStart): these are also
> transcriptional elements, but since they all mark the beginning and end
> of ranges or spans, there may be less features of such elements that are
> subject to interpretation, so the argument for allowing certLike inside
> them may be weaker. I am agnostic.

If you use <addSpan/> instead of <add> or <delSpan/> instead of <del/> 
to get around an overlapping hierarchy problem, you could have a 
situation where, when transcribing a manuscript, you can't tell exactly 
which text was added or deleted.  So I would treat these like the 
milestone elements.

> LINKING (alt, link): in principle these are not transcriptional but
> stand-off elements, so probably don't need certLike in any event. (Cf.
> however<join>, which is already only pseudo-empty.)
>
> ODD (attRef, catRef, classRef, elementRef, equiv, macroRef, specDesc,
> specGrpRef): obviously not. These should remain empty.
>
> FS (binary, default, fsdLink, iff, numeric, symbol, then, when):
> presumably not either, although I don't pretend to have any idea what FS
> is about.
>
> ADMIN (graphic, ptr, variantEncoding, refState): for want of a better
> label--these elements are not really transcription but rather support
> the markup, so I suspect they don't need certLike at all.

You sometimes use <ptr/> to mark sigla, and I suppose there might be old 
printed books where it's unclear whether a smudge is a siglum or, say, a 
quotation mark.  But I'm willing to let this go until someone raises it 
as an issue.

> DICTIONARIES (oRef, pRef): my instinct is to say these don't either, but
> is this module ever used to transcribe existing print dictionaries, and
> so subject to the sorts of uncertainty that other transcription elements
> are? If so, then yes, they deserve in as much as TRANSCRIPTIONAL (above) do.

The dictionaries chapter used to be named "print dictionaries" but was 
renamed in order to suppport encoding of born-digital dictionaries.  I 
strongly suspect these elements predate the renaming, and even if they 
don't, we can't really say that no one uses these in encoding print 
dictionaries.  I can imagine uncertainty about the placement of these 
elements when transcribing an old dictionary, so I vote to treat like 
the milestone elements.

--Kevin

From sebastian.rahtz at it.ox.ac.uk  Wed Aug  1 13:01:40 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Wed, 1 Aug 2012 17:01:40 +0000
Subject: [tei-council] new email
Message-ID: <5AF45B53-B1D5-4385-BB1E-9E4B8081D2B8@oucs.ox.ac.uk>

fi anyone of you want to get me right in your contact lists, I am now @it.ox.ac.uk
rather than @oucs.ox.ac.uk

oldtimers amongst you may like to know that OUCS died yesterday
at midnight. Le roi est mort, vive le "IT Services" roi. 
--
Sebastian Rahtz      
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
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 it.ox.ac.uk  Wed Aug  1 13:17:50 2012
From: James.Cummings at it.ox.ac.uk (James Cummings)
Date: Wed, 01 Aug 2012 19:17:50 +0200
Subject: [tei-council] new email
In-Reply-To: <5AF45B53-B1D5-4385-BB1E-9E4B8081D2B8@oucs.ox.ac.uk>
References: <5AF45B53-B1D5-4385-BB1E-9E4B8081D2B8@oucs.ox.ac.uk>
Message-ID: <501964BE.4040605@it.ox.ac.uk>


What he said.  OUCS is dead, long live IT Services.

-James

On 01/08/12 19:01, Sebastian Rahtz wrote:
> fi anyone of you want to get me right in your contact lists, I am now @it.ox.ac.uk
> rather than @oucs.ox.ac.uk
>
> oldtimers amongst you may like to know that OUCS died yesterday
> at midnight. Le roi est mort, vive le "IT Services" roi.
> --
> Sebastian Rahtz
> Director (Research Support) of Academic IT Services
> University of Oxford IT Services
> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>
> S?lo le pido a Dios
> que el futuro no me sea indiferente
>


-- 
Dr James Cummings, InfoDev,
IT Services, University of Oxford

From mholmes at uvic.ca  Thu Aug  2 13:58:55 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Thu, 2 Aug 2012 10:58:55 -0700
Subject: [tei-council] Examples for <listApp>
Message-ID: <501ABFDF.3060707@uvic.ca>

Hi all,

I'm still working on the spec for the new <listApp> element, and I have 
one very good example use deriving from a SOAS project, which Sebastian 
found for me. We're still working out the appropriate @xml:lang values 
for that, but we're nearly there. In the meantime, I'd really like to 
have one more example in a European language, if possible, just to make 
it a bit more accessible. Does anyone have documents which have:

  - <app> elements encoded in stand-off manner, outside the main text

  - at least two different sets of <app> elements grouped together for 
some reason (by language, families of witnesses, or for any other reason


Thanks,
Martin

From kevin.s.hawkins at ultraslavonic.info  Fri Aug  3 00:28:04 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Fri, 03 Aug 2012 00:28:04 -0400
Subject: [tei-council] Fwd: Re:  Lite and/or _Lite?
In-Reply-To: <50108CB0.8050605@ultraslavonic.info>
References: <50106D3C.3040809@retired.ox.ac.uk>
	<50106D4E.3090109@retired.ox.ac.uk>
	<50108CB0.8050605@ultraslavonic.info>
Message-ID: <501B5354.8070806@ultraslavonic.info>

For the record, I've added the note to the minutes.

On 7/25/12 8:17 PM, Kevin Hawkins wrote:
> Just like you, I am trying to clarify things.  I bring it up hoping that
> someone will say, "Ah, I made that change shortly after Ann Arbor" or
> something like that.  Then I can perhaps add a note in the minutes so
> that future historians of the TEI can make sense of them.
>
> On 7/25/12 6:03 PM, Lou Burnard wrote:
>>
>>
>>
>> -------- Original Message --------
>> Subject: Re: [tei-council] Lite and/or _Lite?
>> Date: Wed, 25 Jul 2012 23:03:40 +0100
>> From: Lou Burnard <lou.burnard at retired.ox.ac.uk>
>> To: Kevin Hawkins <kevin.s.hawkins at ultraslavonic.info>
>>
>> The minutes from Ann Arbor could be mistaken, or someone may have been
>> mistaken in asserting that we were actually still using teilite rather
>> than tei_lite . Does it matter? The current state of affairs is what we
>> all agreed we wanted!
>>
>> I dont know when we started generating from tei_lite, but I think
>> Sebastian is right in suggesting it was well before the AA meeting.
>>
>>
>> On 25/07/12 22:58, Kevin Hawkins wrote:
>>> So are you saying that someone has changed what we are generating in
>>> Jenkins since Ann Arbor?  That is, what was stated in Ann Arbor is no
>>> longer true?
>>>
>>> On 7/25/2012 5:32 PM, Lou Burnard wrote:
>>>> Yes, as my second mail points out, we are indeed currently generating
>>>> from the "inclusion" version. Which is what the minutes say we agreed
>>>> (inter alia) to do.
>>>>
>>>>
>>>> On 25/07/12 22:26, Kevin Hawkins wrote:
>>>>> Hmm, according to:
>>>>>
>>>>> http://www.tei-c.org/Activities/Council/Meetings/tcm50.xml#body.1_div.1_div.2_div.2
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> we are using the exclusion version (teilite.odd) to generate schemas.
>>>>> That could be an error in the minutes, or someone may have misspoken.
>>>>>
>>>>> On 7/25/2012 5:13 PM, Lou Burnard wrote:
>>>>>> I should also add that the Makefile in Exemplars (and presumably
>>>>>> therefore also Mr Jinks) only builds the tei_lite version. As it
>>>>>> should.
>>>>>>
>>>>>> On 25/07/12 22:10, Lou Burnard wrote:
>>>>>>> I'm finally getting round to the action placed on me at last Council
>>>>>>> meeting concerning the ever popular "TEI Lite" document, and would
>>>>>>> appreciate confirmation that I'm about to do the right thing.
>>>>>>>
>>>>>>> There are still two versions of this ODD in the svn repository under
>>>>>>> Exemplars: one (called tei_lite.odd) is defined by inclusion; the
>>>>>>> other
>>>>>>> (called teilite.odd) is defined by exclusion.
>>>>>>>
>>>>>>> I'm pretty sure we agreed that we would henceforth maintain this
>>>>>>> document only in the "inclusion" form, if only so that we don't
>>>>>>> have to
>>>>>>> keep fixing it every time some new element is added to the
>>>>>>> Guidelines
>>>>>>> (which happens surprisingly often). But I'd like confirmation on
>>>>>>> that
>>>>>>> before zapping teilite.odd or moving it to the "Deprecated-old-junk"
>>>>>>> folder. Another possibility would of course be to maintain the
>>>>>>> two of
>>>>>>> them (possibly with some slightly less obscure naming difference)
>>>>>>> but I
>>>>>>> am hoping we don't want to do that.
>>>>>>>
>>>>>>> Needless to say, the two versions have diverged slightly, with some
>>>>>>> recent minor updates being made independently by different people to
>>>>>>> the
>>>>>>> two files, or to only one of them: I will in any case sort that out.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>
>>
>>
>>

From kevin.s.hawkins at ultraslavonic.info  Fri Aug  3 00:33:14 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Fri, 03 Aug 2012 00:33:14 -0400
Subject: [tei-council] title page recto of P5 in HTML version
In-Reply-To: <3829AC12-D84B-4829-8100-0B98A3533F64@oucs.ox.ac.uk>
References: <500AF7C0.6010900@ultraslavonic.info>
	<3829AC12-D84B-4829-8100-0B98A3533F64@oucs.ox.ac.uk>
Message-ID: <501B548A.9040502@ultraslavonic.info>

On 7/23/12 11:34 AM, Sebastian Rahtz wrote:
>
> On 21 Jul 2012, at 19:41, Kevin Hawkins wrote:
>
>>
>> I can't find anything following "TEI P5: Guidelines for Electronic Text
>> Encoding and Interchange" anywhere in the HTML version of the
>> Guidelines, making me think it's hard-coded somewhere in the process
>> that creates the PDF.
>
> no, those words are in the Guidelines source. See P5/Source/guidelines-en.xml
>
> curious that they don't appear in the HTML, I agree. An interesting
> bit of archaeology for someone to trace through the process
> and see why not.

This is now a bug:

http://purl.org/tei/bug/3553911

I'll leave it to our illustrious chair to assign this to Sebastian.  ;-)

From James.Cummings at it.ox.ac.uk  Fri Aug  3 06:11:00 2012
From: James.Cummings at it.ox.ac.uk (James Cummings)
Date: Fri, 03 Aug 2012 11:11:00 +0100
Subject: [tei-council] title page recto of P5 in HTML version
In-Reply-To: <501B548A.9040502@ultraslavonic.info>
References: <500AF7C0.6010900@ultraslavonic.info>
	<3829AC12-D84B-4829-8100-0B98A3533F64@oucs.ox.ac.uk>
	<501B548A.9040502@ultraslavonic.info>
Message-ID: <501BA3B4.8000705@it.ox.ac.uk>

On 03/08/12 05:33, Kevin Hawkins wrote:
> This is now a bug:
>
> http://purl.org/tei/bug/3553911
>
> I'll leave it to our illustrious chair to assign this to Sebastian.  ;-)

This has now been done. :-)

-James

-- 
Dr James Cummings, InfoDev,
Computing Services, University of Oxford

From gabriel.bodard at kcl.ac.uk  Fri Aug  3 07:04:12 2012
From: gabriel.bodard at kcl.ac.uk (Gabriel BODARD)
Date: Fri, 3 Aug 2012 12:04:12 +0100
Subject: [tei-council] Certainty within milestoneLike
In-Reply-To: <50180ABB.7050500@ultraslavonic.info>
References: <5017EF9E.2000804@kcl.ac.uk> <50180ABB.7050500@ultraslavonic.info>
Message-ID: <501BB02C.9040102@kcl.ac.uk>

On 31/07/2012 17:41, Kevin Hawkins wrote:
> I can imagine uncertainty over where exactly a shift in hand
> (<handShift/>) occurs or whether a pause (<pause/>) occurs at all.  So I
> treat these like the milestone elements.

I agree. Or which hand you're shifting to here, or various other 
information that might be recorded in attributes of these empty 
elements. I think this is right.

> If you use <addSpan/> instead of <add> or <delSpan/> instead of <del/>
> to get around an overlapping hierarchy problem, you could have a
> situation where, when transcribing a manuscript, you can't tell exactly
> which text was added or deleted.  So I would treat these like the
> milestone elements.

True. Or how a text is marked for deletion, or if you're recording an 
edition, various other information about the deletion or damage that is 
imperfectly recorded. Okay, I'm persuaded.

> You sometimes use <ptr/> to mark sigla, and I suppose there might be old
> printed books where it's unclear whether a smudge is a siglum or, say, a
> quotation mark.  But I'm willing to let this go until someone raises it
> as an issue.

I'm so not convinced by this, to be honest, maybe because in my usage at 
least <ptr/> never represents something that's in the source text 
itself, but is used to indicate some kind of technical relationship 
within the markup. If anyone feels strongly I'm happy to revisit this, 
though.

> The dictionaries chapter used to be named "print dictionaries" but was
> renamed in order to suppport encoding of born-digital dictionaries.  I
> strongly suspect these elements predate the renaming, and even if they
> don't, we can't really say that no one uses these in encoding print
> dictionaries.  I can imagine uncertainty about the placement of these
> elements when transcribing an old dictionary, so I vote to treat like
> the milestone elements.

Fair enough. I don't know how the dictionary elements are used, but if 
oRef and pRef can take various interpretive meaning-bearing attributes, 
then there's surely call for asserting certainty/responsibility/etc on 
these attributes as well.

According to James's comment on the ticket (and the minutes from AA), 
"unless there is great disagreement the FR should be approved and 
implemented". Does the lack of dissent over the last 4 days count as not 
great disagreement? Shall I go ahead and implement this?

And are we talking about just adding model.certLike to the model of 
these elements, or model.glossLike (which will bring certLike with it)? 
I'm a bit confused to find that <precision> is a member of the latter 
but not the former, since I thought we explicitly created it as a 
<certainty>-like element...

G


-- 
Dr Gabriel BODARD
(Research Associate in Digital Epigraphy)

Department of Digital Humanities
King's College London
26-29 Drury Lane
London WC2B 5RL

Email: gabriel.bodard at kcl.ac.uk
Tel: +44 (0)20 7848 1388
Fax: +44 (0)20 7848 2980

http://www.digitalclassicist.org/
http://www.currentepigraphy.org/

From lou.burnard at retired.ox.ac.uk  Fri Aug  3 08:21:20 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Fri, 03 Aug 2012 13:21:20 +0100
Subject: [tei-council] Certainty within milestoneLike
In-Reply-To: <501BB02C.9040102@kcl.ac.uk>
References: <5017EF9E.2000804@kcl.ac.uk> <50180ABB.7050500@ultraslavonic.info>
	<501BB02C.9040102@kcl.ac.uk>
Message-ID: <501BC240.7030608@retired.ox.ac.uk>

I don't think it's hard to find lots of cases where indication of 
uncertainty or imprecision *might be* needed. As soon as you accept that 
the markup is making an assertion, you may want to hedge that assertion. 
But that's why the <certainty> and <precision> elements are defined for 
use in a standoffish way -- so that they can be used generically as 
necessary. It's not an argument for introducing what I persist in seeing 
as an unnecessary complication into the way empty tags are defined however.

So far the only real case we've seen discussed (uncertainty about the 
location of a line break) can easily be solved by adding @cert and @resp 
to <lb/> -- a linebreak is *only* about location, so there's no need to 
specify the type of uncertainty concerned. Even if there were, a 
<certainty> element pointing to the <lb/> concerned doesn't seem to me 
to be much of an overhead.

I have commented to this effect on the ticket and look forward to being 
shouted down...


On 03/08/12 12:04, Gabriel BODARD wrote:
> On 31/07/2012 17:41, Kevin Hawkins wrote:
>> I can imagine uncertainty over where exactly a shift in hand
>> (<handShift/>) occurs or whether a pause (<pause/>) occurs at all.  So I
>> treat these like the milestone elements.
>
> I agree. Or which hand you're shifting to here, or various other
> information that might be recorded in attributes of these empty
> elements. I think this is right.
>
>> If you use <addSpan/> instead of <add> or <delSpan/> instead of <del/>
>> to get around an overlapping hierarchy problem, you could have a
>> situation where, when transcribing a manuscript, you can't tell exactly
>> which text was added or deleted.  So I would treat these like the
>> milestone elements.
>
> True. Or how a text is marked for deletion, or if you're recording an
> edition, various other information about the deletion or damage that is
> imperfectly recorded. Okay, I'm persuaded.
>
>> You sometimes use <ptr/> to mark sigla, and I suppose there might be old
>> printed books where it's unclear whether a smudge is a siglum or, say, a
>> quotation mark.  But I'm willing to let this go until someone raises it
>> as an issue.
>
> I'm so not convinced by this, to be honest, maybe because in my usage at
> least <ptr/> never represents something that's in the source text
> itself, but is used to indicate some kind of technical relationship
> within the markup. If anyone feels strongly I'm happy to revisit this,
> though.
>
>> The dictionaries chapter used to be named "print dictionaries" but was
>> renamed in order to suppport encoding of born-digital dictionaries.  I
>> strongly suspect these elements predate the renaming, and even if they
>> don't, we can't really say that no one uses these in encoding print
>> dictionaries.  I can imagine uncertainty about the placement of these
>> elements when transcribing an old dictionary, so I vote to treat like
>> the milestone elements.
>
> Fair enough. I don't know how the dictionary elements are used, but if
> oRef and pRef can take various interpretive meaning-bearing attributes,
> then there's surely call for asserting certainty/responsibility/etc on
> these attributes as well.
>
> According to James's comment on the ticket (and the minutes from AA),
> "unless there is great disagreement the FR should be approved and
> implemented". Does the lack of dissent over the last 4 days count as not
> great disagreement? Shall I go ahead and implement this?
>
> And are we talking about just adding model.certLike to the model of
> these elements, or model.glossLike (which will bring certLike with it)?
> I'm a bit confused to find that <precision> is a member of the latter
> but not the former, since I thought we explicitly created it as a
> <certainty>-like element...
>
> G
>
>


From lou.burnard at retired.ox.ac.uk  Fri Aug  3 11:11:52 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Fri, 03 Aug 2012 16:11:52 +0100
Subject: [tei-council] Fwd: Re:  Lite and/or _Lite?
In-Reply-To: <501AFC05.2060601@uvic.ca>
References: <50106D3C.3040809@retired.ox.ac.uk>
	<50106D4E.3090109@retired.ox.ac.uk> <501ACB7B.3090509@uvic.ca>
	<501AE212.1010802@retired.ox.ac.uk> <501AFC05.2060601@uvic.ca>
Message-ID: <501BEA38.7080802@retired.ox.ac.uk>

On 02/08/12 23:15, Martin Holmes wrote:
> Now we should figure out why Oxygen (not sure if it's just my version or
> all of them) is set up to validate against brown_odds.rng, for some
> reason (and validation fails with that).

It's a mystery to me how Oxygen decides these things, though I suspect 
Sebastian may have had a hand in it. Maybe Syd tweaked the default 
association to pick up whatever subset of tei_odd it is he uses to teach 
with, and that got picked up?




From gabriel.bodard at kcl.ac.uk  Fri Aug  3 12:18:29 2012
From: gabriel.bodard at kcl.ac.uk (Gabriel BODARD)
Date: Fri, 3 Aug 2012 17:18:29 +0100
Subject: [tei-council] Certainty within milestoneLike
In-Reply-To: <501BC240.7030608@retired.ox.ac.uk>
References: <5017EF9E.2000804@kcl.ac.uk>
	<50180ABB.7050500@ultraslavonic.info>	<501BB02C.9040102@kcl.ac.uk>
	<501BC240.7030608@retired.ox.ac.uk>
Message-ID: <501BF9D5.8030103@kcl.ac.uk>

I'll answer in more detail on the ticket (since I think that is the 
proper place for it), but one point below:

On 03/08/2012 13:21, Lou Burnard wrote:
> So far the only real case we've seen discussed (uncertainty about the
> location of a line break) can easily be solved by adding @cert and @resp
> to <lb/> -- a linebreak is *only* about location, so there's no need to
> specify the type of uncertainty concerned.

That's not true at all. The position of the <lb/> element is about 
location, sure, but the element can also carry @n giving a line number 
to the following line; @ed giving the edition(s) in which this is the 
position of a line-break/beginning; @break saying whether this should or 
should not be considered word-dividing; @type; @corresp; etc. We might 
not only want to be able to indicate one or more different types of 
uncertainty (or precision or attribution) about many of these 
attributes, but we might want to offer alternative values using 
@assertedValue on <certainty/>.

-- 
Dr Gabriel BODARD
(Research Associate in Digital Epigraphy)

Department of Digital Humanities
King's College London
26-29 Drury Lane
London WC2B 5RL

Email: gabriel.bodard at kcl.ac.uk
Tel: +44 (0)20 7848 1388
Fax: +44 (0)20 7848 2980

http://www.digitalclassicist.org/
http://www.currentepigraphy.org/

From kevin.s.hawkins at ultraslavonic.info  Sat Aug  4 16:42:54 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Sat, 04 Aug 2012 16:42:54 -0400
Subject: [tei-council] TEI deprecation practices
Message-ID: <501D894E.3030504@ultraslavonic.info>

Councilors (cc'ing Laurent),

I've been having some confused discussions with various people about 
deprecation practices for the Guidelines, and I realized that I was not 
even sure of our practice any more.  I've done lots of archeology in 
meeting minutes and in Sourceforge and have produced what I think is a 
summary of our deprecation practices, plus some questions:

http://wiki.tei-c.org/index.php/Deprecation

Please review.

I hope once we sort this out, I will be able to move forward on 
http://purl.org/tei/bug/3376456 , and it might also help James with 
http://purl.org/tei/bug/3435326 .

By the way, I've added a link to the wiki page from a new question and 
answer I've just added to the Council FAQ:

http://wiki.tei-c.org/index.php/TEI-Council-FAQ#In_what_ways_will_Council_break_backwards_compatibility.3F

Thanks,

Kevin

From lou.burnard at retired.ox.ac.uk  Sat Aug  4 19:03:47 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Sun, 05 Aug 2012 00:03:47 +0100
Subject: [tei-council] lite final update -- wot about w?
Message-ID: <501DAA53.2060207@retired.ox.ac.uk>

Thanks to he;lpful comments from Sebastian, James, and Kevin, I'm making 
good progress on finalising the TEI Lite document, and hope to finish it 
off tomorrow. Or the next day. See the wiki for exciting blow by blow 
details.

However, I've just noticed something a bit odd which I missed on my 
first go round and would like to ask Council's views about. I very 
vaguely remember someone complaining that Lite does not include <w> -- 
although it does include <seg> <s> and <pc>.

Shall I add it?


From sebastian.rahtz at it.ox.ac.uk  Sun Aug  5 08:13:26 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Sun, 5 Aug 2012 12:13:26 +0000
Subject: [tei-council] lite final update -- wot about w?
In-Reply-To: <501DAA53.2060207@retired.ox.ac.uk>
References: <501DAA53.2060207@retired.ox.ac.uk>
Message-ID: <64671b7a-94b2-40a9-bfde-b1437e9c988d@HUB01.ad.oak.ox.ac.uk>


On 5 Aug 2012, at 00:03, Lou Burnard <lou.burnard at retired.ox.ac.uk> wrote:

> 
> However, I've just noticed something a bit odd which I missed on my 
> first go round and would like to ask Council's views about. I very 
> vaguely remember someone complaining that Lite does not include <w> -- 
> although it does include <seg> <s> and <pc>.
> 

thats a very puzzling omission. it seems like a no-brainer to include it.

--
Sebastian Rahtz      
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431








From mholmes at uvic.ca  Sun Aug  5 13:39:31 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Sun, 5 Aug 2012 10:39:31 -0700
Subject: [tei-council] TEI deprecation practices
In-Reply-To: <501D894E.3030504@ultraslavonic.info>
References: <501D894E.3030504@ultraslavonic.info>
Message-ID: <501EAFD3.6030703@uvic.ca>

HI Kevin,

This is very helpful. The first thing that occurs to me is that the 
"soft deprecation" method is hard to notice in the Guidelines; the Note 
in which it's mentioned in e.g. <relationGrp> is right at the bottom of 
the page:

<http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-relationGrp.html>

and many people would use the tag unknowingly without getting that far. 
The fact that <relationGrp> is no longer mentioned in the chapter linked 
from the element page is perhaps a clue, but not a very good one. We 
could make the deprecation more evident by putting some signal directly 
into the first row/cell of the element page (such as the red text shown 
in the hard-deprecated @targets definition).

Personally, I don't like the distinction between hard and soft 
deprecation. What "soft" really means in the case of e.g. relationGrp is 
that the element is retained for backwards-compatibility; I think that 
should always be temporary, albeit perhaps long-lasting, and the 
end-result of deprecation should be eventual removal/replacement.

Cheers,
Martin

On 12-08-04 01:42 PM, Kevin Hawkins wrote:
> Councilors (cc'ing Laurent),
>
> I've been having some confused discussions with various people about
> deprecation practices for the Guidelines, and I realized that I was not
> even sure of our practice any more.  I've done lots of archeology in
> meeting minutes and in Sourceforge and have produced what I think is a
> summary of our deprecation practices, plus some questions:
>
> http://wiki.tei-c.org/index.php/Deprecation
>
> Please review.
>
> I hope once we sort this out, I will be able to move forward on
> http://purl.org/tei/bug/3376456 , and it might also help James with
> http://purl.org/tei/bug/3435326 .
>
> By the way, I've added a link to the wiki page from a new question and
> answer I've just added to the Council FAQ:
>
> http://wiki.tei-c.org/index.php/TEI-Council-FAQ#In_what_ways_will_Council_break_backwards_compatibility.3F
>
> Thanks,
>
> Kevin
>

From mholmes at uvic.ca  Sun Aug  5 13:54:58 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Sun, 5 Aug 2012 10:54:58 -0700
Subject: [tei-council] lite final update -- wot about w?
In-Reply-To: <64671b7a-94b2-40a9-bfde-b1437e9c988d@HUB01.ad.oak.ox.ac.uk>
References: <501DAA53.2060207@retired.ox.ac.uk>
	<64671b7a-94b2-40a9-bfde-b1437e9c988d@HUB01.ad.oak.ox.ac.uk>
Message-ID: <501EB372.1080201@uvic.ca>

Perhaps it was omitted because you can use <seg type="word"> (and use 
<seg> for all the other bits and pieces in the same way). I see <cl> and 
<phr>, for instance, are also missing. Perhaps the oddity here is the 
inclusion of <s>?

Cheers,
Martin

On 12-08-05 05:13 AM, Sebastian Rahtz wrote:
>
> On 5 Aug 2012, at 00:03, Lou Burnard <lou.burnard at retired.ox.ac.uk> wrote:
>
>>
>> However, I've just noticed something a bit odd which I missed on my
>> first go round and would like to ask Council's views about. I very
>> vaguely remember someone complaining that Lite does not include <w> --
>> although it does include <seg> <s> and <pc>.
>>
>
> thats a very puzzling omission. it seems like a no-brainer to include it.
>
> --
> Sebastian Rahtz
> Director (Research Support) of Academic IT Services
> University of Oxford IT Services
> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>
>
>
>
>
>
>

From lou.burnard at retired.ox.ac.uk  Sun Aug  5 13:59:10 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Sun, 05 Aug 2012 18:59:10 +0100
Subject: [tei-council] lite final update -- wot about w?
In-Reply-To: <501EB372.1080201@uvic.ca>
References: <501DAA53.2060207@retired.ox.ac.uk>
	<64671b7a-94b2-40a9-bfde-b1437e9c988d@HUB01.ad.oak.ox.ac.uk>
	<501EB372.1080201@uvic.ca>
Message-ID: <501EB46E.5060703@retired.ox.ac.uk>

Indeed yes, and there is an example showing how to use <seg type="lex">.

The counter argument is

a) lots of people do tokenisation and it seems sensible to offer a 
simple solution for that as well as the generic <seg> -- just as we 
offer both pb and milestone

b) why then do we have pc (which is sugar for <seg type="punct"> or 
something? )


<s> is slightly different from <seg>, since it's for end to end 
segmentation.



On 05/08/12 18:54, Martin Holmes wrote:
> Perhaps it was omitted because you can use <seg type="word"> (and use
> <seg> for all the other bits and pieces in the same way). I see <cl> and
> <phr>, for instance, are also missing. Perhaps the oddity here is the
> inclusion of <s>?
>
> Cheers,
> Martin
>
> On 12-08-05 05:13 AM, Sebastian Rahtz wrote:
>>
>> On 5 Aug 2012, at 00:03, Lou Burnard <lou.burnard at retired.ox.ac.uk>
>> wrote:
>>
>>>
>>> However, I've just noticed something a bit odd which I missed on my
>>> first go round and would like to ask Council's views about. I very
>>> vaguely remember someone complaining that Lite does not include <w> --
>>> although it does include <seg> <s> and <pc>.
>>>
>>
>> thats a very puzzling omission. it seems like a no-brainer to include it.
>>
>> --
>> Sebastian Rahtz
>> Director (Research Support) of Academic IT Services
>> University of Oxford IT Services
>> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>>
>>
>>
>>
>>
>>
>>


From bansp at o2.pl  Sun Aug  5 14:02:30 2012
From: bansp at o2.pl (Piotr Banski)
Date: Sun, 05 Aug 2012 20:02:30 +0200
Subject: [tei-council] lite final update -- wot about w?
In-Reply-To: <501EB46E.5060703@retired.ox.ac.uk>
References: <501DAA53.2060207@retired.ox.ac.uk>
	<64671b7a-94b2-40a9-bfde-b1437e9c988d@HUB01.ad.oak.ox.ac.uk>
	<501EB372.1080201@uvic.ca> <501EB46E.5060703@retired.ox.ac.uk>
Message-ID: <501EB536.2060904@o2.pl>

I understand Martin's objections but tend to lean towards a 
user-friendly, not-so-theoretically-supercoherent set of devices for 
Lite. <w> tastes lite. Or, conversely, its lack will litely raise eyebrows.

   P.

On 05/08/12 19:59, Lou Burnard wrote:
> Indeed yes, and there is an example showing how to use <seg type="lex">.
>
> The counter argument is
>
> a) lots of people do tokenisation and it seems sensible to offer a
> simple solution for that as well as the generic <seg> -- just as we
> offer both pb and milestone
>
> b) why then do we have pc (which is sugar for <seg type="punct"> or
> something? )
>
>
> <s> is slightly different from <seg>, since it's for end to end
> segmentation.
>
>
>
> On 05/08/12 18:54, Martin Holmes wrote:
>> Perhaps it was omitted because you can use <seg type="word"> (and use
>> <seg> for all the other bits and pieces in the same way). I see <cl> and
>> <phr>, for instance, are also missing. Perhaps the oddity here is the
>> inclusion of <s>?
>>
>> Cheers,
>> Martin
>>
>> On 12-08-05 05:13 AM, Sebastian Rahtz wrote:
>>>
>>> On 5 Aug 2012, at 00:03, Lou Burnard <lou.burnard at retired.ox.ac.uk>
>>> wrote:
>>>
>>>>
>>>> However, I've just noticed something a bit odd which I missed on my
>>>> first go round and would like to ask Council's views about. I very
>>>> vaguely remember someone complaining that Lite does not include <w> --
>>>> although it does include <seg> <s> and <pc>.
>>>>
>>>
>>> thats a very puzzling omission. it seems like a no-brainer to include it.
>>>
>>> --
>>> Sebastian Rahtz
>>> Director (Research Support) of Academic IT Services
>>> University of Oxford IT Services
>>> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>


From syeates at gmail.com  Sun Aug  5 14:16:49 2012
From: syeates at gmail.com (stuart yeates)
Date: Mon, 06 Aug 2012 06:16:49 +1200
Subject: [tei-council] lite final update -- wot about w?
In-Reply-To: <501EB536.2060904@o2.pl>
References: <501DAA53.2060207@retired.ox.ac.uk>
	<64671b7a-94b2-40a9-bfde-b1437e9c988d@HUB01.ad.oak.ox.ac.uk>
	<501EB372.1080201@uvic.ca> <501EB46E.5060703@retired.ox.ac.uk>
	<501EB536.2060904@o2.pl>
Message-ID: <501EB891.9000901@gmail.com>

I agree. A lack of surprises is always a good thing; especially in terms 
of encouraging TEI newbies.

cheers
stuart

On 06/08/12 06:02, Piotr Banski wrote:
> I understand Martin's objections but tend to lean towards a
> user-friendly, not-so-theoretically-supercoherent set of devices for
> Lite. <w> tastes lite. Or, conversely, its lack will litely raise eyebrows.
>
>     P.
>
> On 05/08/12 19:59, Lou Burnard wrote:
>> Indeed yes, and there is an example showing how to use <seg type="lex">.
>>
>> The counter argument is
>>
>> a) lots of people do tokenisation and it seems sensible to offer a
>> simple solution for that as well as the generic <seg> -- just as we
>> offer both pb and milestone
>>
>> b) why then do we have pc (which is sugar for <seg type="punct"> or
>> something? )
>>
>>
>> <s> is slightly different from <seg>, since it's for end to end
>> segmentation.
>>
>>
>>
>> On 05/08/12 18:54, Martin Holmes wrote:
>>> Perhaps it was omitted because you can use <seg type="word"> (and use
>>> <seg> for all the other bits and pieces in the same way). I see <cl> and
>>> <phr>, for instance, are also missing. Perhaps the oddity here is the
>>> inclusion of <s>?
>>>
>>> Cheers,
>>> Martin
>>>
>>> On 12-08-05 05:13 AM, Sebastian Rahtz wrote:
>>>>
>>>> On 5 Aug 2012, at 00:03, Lou Burnard <lou.burnard at retired.ox.ac.uk>
>>>> wrote:
>>>>
>>>>>
>>>>> However, I've just noticed something a bit odd which I missed on my
>>>>> first go round and would like to ask Council's views about. I very
>>>>> vaguely remember someone complaining that Lite does not include <w> --
>>>>> although it does include <seg> <s> and <pc>.
>>>>>
>>>>
>>>> thats a very puzzling omission. it seems like a no-brainer to include it.
>>>>
>>>> --
>>>> Sebastian Rahtz
>>>> Director (Research Support) of Academic IT Services
>>>> University of Oxford IT Services
>>>> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>
>


From gabriel.bodard at kcl.ac.uk  Mon Aug  6 05:48:25 2012
From: gabriel.bodard at kcl.ac.uk (Gabriel BODARD)
Date: Mon, 6 Aug 2012 10:48:25 +0100
Subject: [tei-council] active/passive again
Message-ID: <501F92E9.8080104@kcl.ac.uk>

Since Council were unconvinced of the value of renaming the 
@active/@passive attributes on <relation> to something more rational 
such as @subject/@object, do you think we could at least express the 
definitions of these attributes in a way that is both grammatically and 
RDF-wise more comprehensible and sensible?

E.g. changing:
@active	identifies the ?active? participants in a non-mutual 
relationship, or all the participants in a mutual one.
--->
@active	identifies the subjects of the relationship statement defined by 
this element[, or all the participants in a mutual one<note 
resp="GB">although I don't think this is true, is it? What is @mutual 
for, then?</note>].

@passive	identifies the ?passive? participants in a non-mutual relationship.
--->
@passive	identifies the object(s) of the relationship statement made by 
this element.

(I think the existing definitions presuppose that relation points to two 
persons, whereas it is now explicitly defined as appropriate for 
pointing between persons, places, objects and events.)

You can probably find a better way to put this.

This is a small thing, but if it's considered controversial then I can 
create a ticket for it.

G

-- 
Dr Gabriel BODARD
(Research Associate in Digital Epigraphy)

Department of Digital Humanities
King's College London
26-29 Drury Lane
London WC2B 5RL

Email: gabriel.bodard at kcl.ac.uk
Tel: +44 (0)20 7848 1388
Fax: +44 (0)20 7848 2980

http://www.digitalclassicist.org/
http://www.currentepigraphy.org/

From lou.burnard at retired.ox.ac.uk  Mon Aug  6 08:50:03 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Mon, 06 Aug 2012 13:50:03 +0100
Subject: [tei-council] active/passive again
In-Reply-To: <501F92E9.8080104@kcl.ac.uk>
References: <501F92E9.8080104@kcl.ac.uk>
Message-ID: <501FBD7B.7070203@retired.ox.ac.uk>

On 06/08/12 10:48, Gabriel BODARD wrote:
> Since Council were unconvinced of the value of renaming the
> @active/@passive attributes on <relation> to something more rational
> such as @subject/@object, do you think we could at least express the
> definitions of these attributes in a way that is both grammatically and
> RDF-wise more comprehensible and sensible?

The word "RDF-wise" seems to me neither comprehensible nor sensible. I 
take it you mean "more abstract".


> E.g. changing:
> @active	identifies the ?active? participants in a non-mutual
> relationship, or all the participants in a mutual one.
> --->
> @active	identifies the subjects of the relationship statement defined by
> this element[, or all the participants in a mutual one<note
> resp="GB">although I don't think this is true, is it? What is @mutual
> for, then?</note>].

The 3 attributes are intended to indicate two different things
(a) the entities participating in the relationship
(b) whether or not the relationship is directed i.e. whether or not the 
existence of a relation between entities a and b implies an equivalent 
relation between b and a. The relations fatherOf(a,b) or northOf(a,b) 
are directed in this sense, the relations siblingOf(a,b) or 
adjacent(a,b) are not.

If you specify participants only on the @active attribute, then either 
you made a mistake or you meant to imply that @mutual is true. However, 
I agree that the @mutual attribute is redundant, if you assume people 
never make mistakes.

>
> @passive	identifies the ?passive? participants in a non-mutual relationship.
> --->
> @passive	identifies the object(s) of the relationship statement made by
> this element.
>
> (I think the existing definitions presuppose that relation points to two
> persons, whereas it is now explicitly defined as appropriate for
> pointing between persons, places, objects and events.)

While I agree that this element was not originally envisaged for 
non-personal relations, I don't see anything particularly 
anthropomorphic in its current definitions. The words "subject" and 
"object" also carry some semantic baggage.

But I certainly agree that the definitions could be improved!



From lou.burnard at retired.ox.ac.uk  Mon Aug  6 09:29:37 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Mon, 06 Aug 2012 14:29:37 +0100
Subject: [tei-council] @rend in Lite
In-Reply-To: <2635CF3A-C730-4296-9269-E8FB190D89D1@oucs.ox.ac.uk>
References: <4CE1D0DB-1CF6-42D2-8A82-60806E0865D2@oucs.ox.ac.uk>
	<501FC378.2030401@retired.ox.ac.uk>
	<2635CF3A-C730-4296-9269-E8FB190D89D1@oucs.ox.ac.uk>
Message-ID: <501FC6C1.4090103@retired.ox.ac.uk>

I'm thinking  of adding the following para to Lite, where @rend is 
discussed:

"
<p>The global <att>rend</att> attribute can be attached to any element, 
and used wherever necessary to specify details of the highlighting used 
for it. For example, a heading rendered in bold might be tagged 
<code>&lt;head rend="bold"&gt;</code>, and one in italic
        <code>&lt;head rend="italic"&gt;</code>.
</p>
<p>The values to be used for the <att>rend</att> attribute are not 
specified by the TEI Guidelines, since they will depend entirely on the 
needs of the particular project. Some typical values might include 
<code>italic</code>, <code>bold</code>, <code>sup</code>(erior) 
<code>smcap</code> etc. for font variations; <code>centre</code>, 
<code>right</code> etc. for alignment; <code>large</code>, 
<code>small</code> etc. for size. Several such words may be used in 
combination as necessary, but no formal syntax is proposed. The full TEI 
Guidelines also provide more rigorous mechanisms, using other W3C 
standards such as CSS, as an alternative. </p>

All in favour?


From sebastian.rahtz at it.ox.ac.uk  Mon Aug  6 10:00:26 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Mon, 6 Aug 2012 14:00:26 +0000
Subject: [tei-council] @rend in Lite
In-Reply-To: <501FC6C1.4090103@retired.ox.ac.uk>
References: <4CE1D0DB-1CF6-42D2-8A82-60806E0865D2@oucs.ox.ac.uk>
	<501FC378.2030401@retired.ox.ac.uk>
	<2635CF3A-C730-4296-9269-E8FB190D89D1@oucs.ox.ac.uk>
	<501FC6C1.4090103@retired.ox.ac.uk>
Message-ID: <f5ce7645-909f-4faa-aa03-cb1759c3ac9b@HUB01.ad.oak.ox.ac.uk>

The idea is fine. some niggles

> <p>The values to be used for the <att>rend</att> attribute are not 
> specified by the TEI Guidelines, since they will depend entirely on the 
> needs of the particular project. Some typical values might include 
> <code>italic</code>, <code>bold</code>, <code>sup</code>(erior) 
> <code>smcap</code> etc. for font variations; <code>centre</code>, 
> <code>right</code> etc. for alignment; <code>large</code>, 
> <code>small</code> etc. for size.

I'd be happier if this list came from a recognized (and quoted) source;
"sup" is not a font variation, and where does "smcap" come from?
sadly "centre" should probably be "center"


> Several such words may be used in 
> combination as necessary, but no formal syntax is proposed. The full TEI 
> Guidelines also provide more rigorous mechanisms, using other W3C 
> standards such as CSS, as an alternative. </p>

hmm, you are implying one can use CSS in @rend here, if you use full TEI. 
this is potentially very misleading. in place of "more rigorous mechanisms"
maybe you mean "other, more rigorous mechanisms than <att>rend</att>"
--
Sebastian Rahtz      
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431

S?lo le pido a Dios
que el futuro no me sea indiferente


From kevin.s.hawkins at ultraslavonic.info  Mon Aug  6 10:06:21 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Mon, 06 Aug 2012 10:06:21 -0400
Subject: [tei-council] Fwd: Re: TEI deprecation practices
Message-ID: <501FCF5D.8070404@ultraslavonic.info>

Forwarding Laurent's message (since it was likely rejected by the 
mailing list as coming from a non-member) ...

-------- Original Message --------
Subject: Re: TEI deprecation practices
Date: Mon, 6 Aug 2012 14:10:06 +0200
From: Laurent Romary <Laurent.Romary at inria.fr>
To: Kevin Hawkins <kevin.s.hawkins at ULTRASLAVONIC.INFO>
CC: TEI Council <tei-council at lists.village.Virginia.EDU>

Hi Kevin,
Let me try at least to state the workflow I would have in mind for the 
use of tickets for deprecation:
- when the council decides to deprecate "something", a ticket with 
status="deprecated" is created that describes the actual deprecation 
thing. This ticket also states a deprecation period (or open until the 
council decides the "thing" should definitely disappear)
- closing the ticket means that the deprecation period is over, namely 
that the element, attribute,feature etc. has been removed from the guideline

The ticket has thus a multiple roe:
- it documents the deprecation (thus making it easy to publicize (in 
particular on the TEI website)), as a sort of reified warning
- it allows the community to react to the ticket ("no, stop! I have a 
zillion documents using this")
- trace back decisions/reasons for changes

In no way, IMHO, "old" tickets should be changed to status="deprecated" 
, but a new one should be made, which in turn may point to the initial 
discussion(s) that lead to its creation.

And this for both soft and hard, I would say.

Does this help?
Cheers,
Laurent


Le 4 ao?t 2012 ? 22:42, Kevin Hawkins a ?crit :

> Councilors (cc'ing Laurent),
>
> I've been having some confused discussions with various people about deprecation practices for the Guidelines, and I realized that I was not even sure of our practice any more.  I've done lots of archeology in meeting minutes and in Sourceforge and have produced what I think is a summary of our deprecation practices, plus some questions:
>
> http://wiki.tei-c.org/index.php/Deprecation
>
> Please review.
>
> I hope once we sort this out, I will be able to move forward on http://purl.org/tei/bug/3376456 , and it might also help James with http://purl.org/tei/bug/3435326 .
>
> By the way, I've added a link to the wiki page from a new question and answer I've just added to the Council FAQ:
>
> http://wiki.tei-c.org/index.php/TEI-Council-FAQ#In_what_ways_will_Council_break_backwards_compatibility.3F
>
> Thanks,
>
> Kevin

Laurent Romary
INRIA & HUB-IDSL
laurent.romary at inria.fr




From lou.burnard at retired.ox.ac.uk  Mon Aug  6 10:08:28 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Mon, 06 Aug 2012 15:08:28 +0100
Subject: [tei-council] @rend in Lite
In-Reply-To: <A2B7624E-8756-46C4-8877-0375F4C7CA15@oucs.ox.ac.uk>
References: <4CE1D0DB-1CF6-42D2-8A82-60806E0865D2@oucs.ox.ac.uk>
	<501FC378.2030401@retired.ox.ac.uk>
	<2635CF3A-C730-4296-9269-E8FB190D89D1@oucs.ox.ac.uk>
	<501FC6C1.4090103@retired.ox.ac.uk>
	<A2B7624E-8756-46C4-8877-0375F4C7CA15@oucs.ox.ac.uk>
Message-ID: <501FCFDC.4010301@retired.ox.ac.uk>

On 06/08/12 15:00, Sebastian Rahtz wrote:
> The idea is fine. some niggles
>
>> <p>The values to be used for the <att>rend</att> attribute are not
>> specified by the TEI Guidelines, since they will depend entirely on the
>> needs of the particular project. Some typical values might include
>> <code>italic</code>, <code>bold</code>, <code>sup</code>(erior)
>> <code>smcap</code> etc. for font variations; <code>centre</code>,
>> <code>right</code> etc. for alignment; <code>large</code>,
>> <code>small</code> etc. for size.
>
> I'd be happier if this list came from a recognized (and quoted) source;
> "sup" is not a font variation, and where does "smcap" come from?
> sadly "centre" should probably be "center"
>

I beg to differ. The whole point of this list is that it does NOT come 
from any recognized or quotable source.  It's just "typical values" 
which one might expect to encounter.


>
>> Several such words may be used in
>> combination as necessary, but no formal syntax is proposed. The full TEI
>> Guidelines also provide more rigorous mechanisms, using other W3C
>> standards such as CSS, as an alternative. </p>
>
> hmm, you are implying one can use CSS in @rend here, if you use full TEI.
> this is potentially very misleading. in place of "more rigorous mechanisms"
> maybe you mean "other, more rigorous mechanisms than <att>rend</att>"
> --

I don't see any implication that CSS is available with @rend. It does 
say "as an alternative". But I agree it doesn't say as an alternative to 
what, so I've added your revisions.



From rwelzenbach at gmail.com  Mon Aug  6 10:11:10 2012
From: rwelzenbach at gmail.com (Rebecca Welzenbach)
Date: Mon, 6 Aug 2012 10:11:10 -0400
Subject: [tei-council] Third-person vs. First-person in the Guidelines
Message-ID: <CAA2irtLCMqeBcFz5nQh+7ec=FHk4_+kwoh-qgAPwQAE0CmOoVg@mail.gmail.com>

Hi all,

I'm putting together the first draft of our style guide, which for now
consists of the "Style Notes," "House style: notes on usage," and
"House style: preferred orthography sections of
http://www.tei-c.org/Activities/Council/Working/tcw20.xml," plus our
conclusions about hyphenation and some other bits and pieces.

While editing it occurred to me to add a note about the voice in which
the Guidelines are written. I assumed that the Guidelines were written
in the third person, but in Chapter 1 alone, I saw several instances
of "we":

* "we refer to such a document informally as an ODD document"
* "which we call a module"
* "we also say that class B is a superclass of class A"
* "We do not describe them in detail here"

Should the Style Guide address the overall voice of the Guidelines,
and if so, which of the following do you prefer?:

* First-person (in which case it may be necessary to check for
ambiguity about whether "we" refers to the editors, the Technical
Council, all TEI users, or some other group, and find a way to
document/clarify this).
* Third-person (in which case sentences currently using "we" will
probably be flipped around into the passive voice, e.g. from "which we
call a module" to "which is called a module" This annoys some readers
and writers more than others).
* Or something like "choose clarity and efficiency of language over
any particular voice"

Thanks for your input,

Becky

From lou.burnard at retired.ox.ac.uk  Mon Aug  6 10:12:41 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Mon, 06 Aug 2012 15:12:41 +0100
Subject: [tei-council] Lite Final, finally
Message-ID: <501FD0D9.7000806@retired.ox.ac.uk>

OK, that's it. I've now checked in what I hope is a relatively stable 
and final version of the TEI Lite tutorial, and don't intend to change 
it again except for the usual typo fixing as a consequence of the 
careful reading I hope it will now be receiving from you all!

I have also checked in a sample Lite file to which I may add some new 
features shortly.

One thing I haven't done is change the name of the schema generated -- 
it's still called "teilite" rather than "tei_lite". Easy to change if 
people think this is important.


From sebastian.rahtz at it.ox.ac.uk  Mon Aug  6 10:13:49 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Mon, 6 Aug 2012 14:13:49 +0000
Subject: [tei-council] @rend in Lite
In-Reply-To: <501FCFDC.4010301@retired.ox.ac.uk>
References: <4CE1D0DB-1CF6-42D2-8A82-60806E0865D2@oucs.ox.ac.uk>
	<501FC378.2030401@retired.ox.ac.uk>
	<2635CF3A-C730-4296-9269-E8FB190D89D1@oucs.ox.ac.uk>
	<501FC6C1.4090103@retired.ox.ac.uk>
	<A2B7624E-8756-46C4-8877-0375F4C7CA15@oucs.ox.ac.uk>
	<501FCFDC.4010301@retired.ox.ac.uk>
Message-ID: <1cb99306-1828-4e19-b85f-5b027199f073@HUB03.ad.oak.ox.ac.uk>


On 6 Aug 2012, at 15:08, Lou Burnard wrote:
> 
> I beg to differ. The whole point of this list is that it does NOT come from any recognized or quotable source.  It's just "typical values" which one might expect to encounter.
> 
yes, but it would be nice to be able to back up that "typical" :-}

doesn't matter a lot.

--
Sebastian Rahtz      
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
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 it.ox.ac.uk  Mon Aug  6 10:18:01 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Mon, 6 Aug 2012 14:18:01 +0000
Subject: [tei-council] Lite Final, finally
In-Reply-To: <501FD0D9.7000806@retired.ox.ac.uk>
References: <501FD0D9.7000806@retired.ox.ac.uk>
Message-ID: <08d2e388-f671-48d4-a19f-3ec01029a542@HUB02.ad.oak.ox.ac.uk>


On 6 Aug 2012, at 15:12, Lou Burnard wrote:
> 
> I have also checked in a sample Lite file to which I may add some new 
> features shortly.
> 
where are you thinking of putting that? how would people find it?

> One thing I haven't done is change the name of the schema generated -- 
> it's still called "teilite" rather than "tei_lite". Easy to change if 
> people think this is important.
> 

it bothers me a bit. I think, for good or bad, "teilite" is a fixed point,
so the ODD should be teilite.odd

--
Sebastian Rahtz      
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431

S?lo le pido a Dios
que el futuro no me sea indiferente


From kevin.s.hawkins at ultraslavonic.info  Mon Aug  6 10:18:28 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Mon, 06 Aug 2012 10:18:28 -0400
Subject: [tei-council] Third-person vs. First-person in the Guidelines
In-Reply-To: <CAA2irtLCMqeBcFz5nQh+7ec=FHk4_+kwoh-qgAPwQAE0CmOoVg@mail.gmail.com>
References: <CAA2irtLCMqeBcFz5nQh+7ec=FHk4_+kwoh-qgAPwQAE0CmOoVg@mail.gmail.com>
Message-ID: <501FD234.8020403@ultraslavonic.info>

It would also be good to give guidance on whether to speak to reader 
using "you", as in "you should" or "you should not".  Alternatives are 
clumsy constructions like "one should not" and "it is advised not to".

On 8/6/2012 10:11 AM, Rebecca Welzenbach wrote:
> Hi all,
>
> I'm putting together the first draft of our style guide, which for now
> consists of the "Style Notes," "House style: notes on usage," and
> "House style: preferred orthography sections of
> http://www.tei-c.org/Activities/Council/Working/tcw20.xml," plus our
> conclusions about hyphenation and some other bits and pieces.
>
> While editing it occurred to me to add a note about the voice in which
> the Guidelines are written. I assumed that the Guidelines were written
> in the third person, but in Chapter 1 alone, I saw several instances
> of "we":
>
> * "we refer to such a document informally as an ODD document"
> * "which we call a module"
> * "we also say that class B is a superclass of class A"
> * "We do not describe them in detail here"
>
> Should the Style Guide address the overall voice of the Guidelines,
> and if so, which of the following do you prefer?:
>
> * First-person (in which case it may be necessary to check for
> ambiguity about whether "we" refers to the editors, the Technical
> Council, all TEI users, or some other group, and find a way to
> document/clarify this).
> * Third-person (in which case sentences currently using "we" will
> probably be flipped around into the passive voice, e.g. from "which we
> call a module" to "which is called a module" This annoys some readers
> and writers more than others).
> * Or something like "choose clarity and efficiency of language over
> any particular voice"
>
> Thanks for your input,
>
> Becky

From bansp at o2.pl  Mon Aug  6 10:53:25 2012
From: bansp at o2.pl (Piotr Banski)
Date: Mon, 06 Aug 2012 16:53:25 +0200
Subject: [tei-council] Third-person vs. First-person in the Guidelines
In-Reply-To: <CAA2irtLCMqeBcFz5nQh+7ec=FHk4_+kwoh-qgAPwQAE0CmOoVg@mail.gmail.com>
References: <CAA2irtLCMqeBcFz5nQh+7ec=FHk4_+kwoh-qgAPwQAE0CmOoVg@mail.gmail.com>
Message-ID: <501FDA65.5060305@o2.pl>

Hi Becky,

Firstly, I would have nothing against if all four examples that you cite 
were expressed in the passive, maybe sometimes just by the participle 
(", called a module,") rather that copula+participle.

Secondly, I would still rather choose the third option that you mention, 
i.e., clarity, maybe even without mentioning "particular voice". Our 
contributor base is rather varied, and imposing on them a stiff 
stylistic/grammatical constraint beyond clarity could lead to 
difficulties in both encoding and decoding, so to say. Let's keep it 
simple at the stage of creation/contribution, and possibly smooth it out 
later, if really necessary.

Best,

   Piotr

On 06/08/12 16:11, Rebecca Welzenbach wrote:
> Hi all,
>
> I'm putting together the first draft of our style guide, which for now
> consists of the "Style Notes," "House style: notes on usage," and
> "House style: preferred orthography sections of
> http://www.tei-c.org/Activities/Council/Working/tcw20.xml," plus our
> conclusions about hyphenation and some other bits and pieces.
>
> While editing it occurred to me to add a note about the voice in which
> the Guidelines are written. I assumed that the Guidelines were written
> in the third person, but in Chapter 1 alone, I saw several instances
> of "we":
>
> * "we refer to such a document informally as an ODD document"
> * "which we call a module"
> * "we also say that class B is a superclass of class A"
> * "We do not describe them in detail here"
>
> Should the Style Guide address the overall voice of the Guidelines,
> and if so, which of the following do you prefer?:
>
> * First-person (in which case it may be necessary to check for
> ambiguity about whether "we" refers to the editors, the Technical
> Council, all TEI users, or some other group, and find a way to
> document/clarify this).
> * Third-person (in which case sentences currently using "we" will
> probably be flipped around into the passive voice, e.g. from "which we
> call a module" to "which is called a module" This annoys some readers
> and writers more than others).
> * Or something like "choose clarity and efficiency of language over
> any particular voice"
>
> Thanks for your input,
>
> Becky
>


From mholmes at uvic.ca  Mon Aug  6 11:02:11 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Mon, 6 Aug 2012 08:02:11 -0700
Subject: [tei-council] active/passive again
In-Reply-To: <501F92E9.8080104@kcl.ac.uk>
References: <501F92E9.8080104@kcl.ac.uk>
Message-ID: <501FDC73.8020408@uvic.ca>

On 12-08-06 02:48 AM, Gabriel BODARD wrote:
> Since Council were unconvinced of the value of renaming the
> @active/@passive attributes on <relation> to something more rational
> such as @subject/@object, do you think we could at least express the
> definitions of these attributes in a way that is both grammatically and
> RDF-wise more comprehensible and sensible?
>
> E.g. changing:
> @active	identifies the ?active? participants in a non-mutual
> relationship, or all the participants in a mutual one.
> --->
> @active	identifies the subjects of the relationship statement defined by
> this element[, or all the participants in a mutual one<note
> resp="GB">although I don't think this is true, is it? What is @mutual
> for, then?</note>].

This rather suggests to me that where @mutual is used, @active and 
@passive should not be, and vice versa. Are the examples of relations in 
which there are active and passive participants, but also groups of 
mutual ones?

>
> @passive	identifies the ?passive? participants in a non-mutual relationship.
> --->
> @passive	identifies the object(s) of the relationship statement made by
> this element.
>
> (I think the existing definitions presuppose that relation points to two
> persons, whereas it is now explicitly defined as appropriate for
> pointing between persons, places, objects and events.)
>
> You can probably find a better way to put this.

I can't, but I feel as though there must be a better terminology than 
subject/object, which comes loaded with linguistic baggage.

Cheers,
Martin

>
> This is a small thing, but if it's considered controversial then I can
> create a ticket for it.
>
> G
>

From mholmes at uvic.ca  Mon Aug  6 11:03:53 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Mon, 6 Aug 2012 08:03:53 -0700
Subject: [tei-council] @rend in Lite
In-Reply-To: <501FC6C1.4090103@retired.ox.ac.uk>
References: <4CE1D0DB-1CF6-42D2-8A82-60806E0865D2@oucs.ox.ac.uk>
	<501FC378.2030401@retired.ox.ac.uk>
	<2635CF3A-C730-4296-9269-E8FB190D89D1@oucs.ox.ac.uk>
	<501FC6C1.4090103@retired.ox.ac.uk>
Message-ID: <501FDCD9.2090607@uvic.ca>

Aye.

On 12-08-06 06:29 AM, Lou Burnard wrote:
> I'm thinking  of adding the following para to Lite, where @rend is
> discussed:
>
> "
> <p>The global <att>rend</att> attribute can be attached to any element,
> and used wherever necessary to specify details of the highlighting used
> for it. For example, a heading rendered in bold might be tagged
> <code>&lt;head rend="bold"&gt;</code>, and one in italic
>          <code>&lt;head rend="italic"&gt;</code>.
> </p>
> <p>The values to be used for the <att>rend</att> attribute are not
> specified by the TEI Guidelines, since they will depend entirely on the
> needs of the particular project. Some typical values might include
> <code>italic</code>, <code>bold</code>, <code>sup</code>(erior)
> <code>smcap</code> etc. for font variations; <code>centre</code>,
> <code>right</code> etc. for alignment; <code>large</code>,
> <code>small</code> etc. for size. Several such words may be used in
> combination as necessary, but no formal syntax is proposed. The full TEI
> Guidelines also provide more rigorous mechanisms, using other W3C
> standards such as CSS, as an alternative. </p>
>
> All in favour?
>

From mholmes at uvic.ca  Mon Aug  6 11:13:04 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Mon, 6 Aug 2012 08:13:04 -0700
Subject: [tei-council] Third-person vs. First-person in the Guidelines
In-Reply-To: <CAA2irtLCMqeBcFz5nQh+7ec=FHk4_+kwoh-qgAPwQAE0CmOoVg@mail.gmail.com>
References: <CAA2irtLCMqeBcFz5nQh+7ec=FHk4_+kwoh-qgAPwQAE0CmOoVg@mail.gmail.com>
Message-ID: <501FDF00.8040008@uvic.ca>

I think the use of "we" is OK when it's clearly (as in the examples 
below) a reference to the authors of the Guidelines. I would be against 
its use where it might suggest (for instance) that a community of 
scholars takes a particular view, or the whole TEI community does.

So I like your formulation "choose clarity and efficiency of language 
over any particular voice," but it might be worth adding "but use the 
first person only when the referent is clearly the authors of the 
Guidelines".

Cheers,
Martin

On 12-08-06 07:11 AM, Rebecca Welzenbach wrote:
> Hi all,
>
> I'm putting together the first draft of our style guide, which for now
> consists of the "Style Notes," "House style: notes on usage," and
> "House style: preferred orthography sections of
> http://www.tei-c.org/Activities/Council/Working/tcw20.xml," plus our
> conclusions about hyphenation and some other bits and pieces.
>
> While editing it occurred to me to add a note about the voice in which
> the Guidelines are written. I assumed that the Guidelines were written
> in the third person, but in Chapter 1 alone, I saw several instances
> of "we":
>
> * "we refer to such a document informally as an ODD document"
> * "which we call a module"
> * "we also say that class B is a superclass of class A"
> * "We do not describe them in detail here"
>
> Should the Style Guide address the overall voice of the Guidelines,
> and if so, which of the following do you prefer?:
>
> * First-person (in which case it may be necessary to check for
> ambiguity about whether "we" refers to the editors, the Technical
> Council, all TEI users, or some other group, and find a way to
> document/clarify this).
> * Third-person (in which case sentences currently using "we" will
> probably be flipped around into the passive voice, e.g. from "which we
> call a module" to "which is called a module" This annoys some readers
> and writers more than others).
> * Or something like "choose clarity and efficiency of language over
> any particular voice"
>
> Thanks for your input,
>
> Becky
>

From lou.burnard at retired.ox.ac.uk  Mon Aug  6 11:35:00 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Mon, 06 Aug 2012 16:35:00 +0100
Subject: [tei-council] Third-person vs. First-person in the Guidelines
In-Reply-To: <CAA2irtLCMqeBcFz5nQh+7ec=FHk4_+kwoh-qgAPwQAE0CmOoVg@mail.gmail.com>
References: <CAA2irtLCMqeBcFz5nQh+7ec=FHk4_+kwoh-qgAPwQAE0CmOoVg@mail.gmail.com>
Message-ID: <501FE424.50200@retired.ox.ac.uk>

On 06/08/12 15:11, Rebecca Welzenbach wrote:

> * First-person (in which case it may be necessary to check for
> ambiguity about whether "we" refers to the editors, the Technical
> Council, all TEI users, or some other group, and find a way to
> document/clarify this).

"We" is almost always (sfaik) used in passages of formal textual 
exposition, and thus refers both to the reader and the authorial voice.

> * Third-person (in which case sentences currently using "we" will
> probably be flipped around into the passive voice, e.g. from "which we
> call a module" to "which is called a module" This annoys some readers
> and writers more than others).

Annoys the hell out of me

> * Or something like "choose clarity and efficiency of language over
> any particular voice"

That's the one for me!


From lou.burnard at retired.ox.ac.uk  Mon Aug  6 11:36:40 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Mon, 06 Aug 2012 16:36:40 +0100
Subject: [tei-council] Third-person vs. First-person in the Guidelines
In-Reply-To: <501FD234.8020403@ultraslavonic.info>
References: <CAA2irtLCMqeBcFz5nQh+7ec=FHk4_+kwoh-qgAPwQAE0CmOoVg@mail.gmail.com>
	<501FD234.8020403@ultraslavonic.info>
Message-ID: <501FE488.5040707@retired.ox.ac.uk>

In general I think imperative constructions are very rare in the 
Guidelines, and should stay that way.



On 06/08/12 15:18, Kevin Hawkins wrote:
> It would also be good to give guidance on whether to speak to reader
> using "you", as in "you should" or "you should not".  Alternatives are
> clumsy constructions like "one should not" and "it is advised not to".
>
> On 8/6/2012 10:11 AM, Rebecca Welzenbach wrote:
>> Hi all,
>>
>> I'm putting together the first draft of our style guide, which for now
>> consists of the "Style Notes," "House style: notes on usage," and
>> "House style: preferred orthography sections of
>> http://www.tei-c.org/Activities/Council/Working/tcw20.xml," plus our
>> conclusions about hyphenation and some other bits and pieces.
>>
>> While editing it occurred to me to add a note about the voice in which
>> the Guidelines are written. I assumed that the Guidelines were written
>> in the third person, but in Chapter 1 alone, I saw several instances
>> of "we":
>>
>> * "we refer to such a document informally as an ODD document"
>> * "which we call a module"
>> * "we also say that class B is a superclass of class A"
>> * "We do not describe them in detail here"
>>
>> Should the Style Guide address the overall voice of the Guidelines,
>> and if so, which of the following do you prefer?:
>>
>> * First-person (in which case it may be necessary to check for
>> ambiguity about whether "we" refers to the editors, the Technical
>> Council, all TEI users, or some other group, and find a way to
>> document/clarify this).
>> * Third-person (in which case sentences currently using "we" will
>> probably be flipped around into the passive voice, e.g. from "which we
>> call a module" to "which is called a module" This annoys some readers
>> and writers more than others).
>> * Or something like "choose clarity and efficiency of language over
>> any particular voice"
>>
>> Thanks for your input,
>>
>> Becky


From dsewell at virginia.edu  Mon Aug  6 11:44:47 2012
From: dsewell at virginia.edu (David Sewell)
Date: Mon, 6 Aug 2012 11:44:47 -0400 (EDT)
Subject: [tei-council] Third-person vs. First-person in the Guidelines
In-Reply-To: <501FE488.5040707@retired.ox.ac.uk>
References: <CAA2irtLCMqeBcFz5nQh+7ec=FHk4_+kwoh-qgAPwQAE0CmOoVg@mail.gmail.com>
	<501FD234.8020403@ultraslavonic.info>
	<501FE488.5040707@retired.ox.ac.uk>
Message-ID: <alpine.OSX.2.00.1208061143550.1218@lister.ei.virginia.edu>

As the Cretan liar said, You should never tell people what to do!

(sorry...)

On Mon, 6 Aug 2012, Lou Burnard wrote:

> In general I think imperative constructions are very rare in the
> Guidelines, and should stay that way.
>
>
>
> On 06/08/12 15:18, Kevin Hawkins wrote:
>> It would also be good to give guidance on whether to speak to reader
>> using "you", as in "you should" or "you should not".  Alternatives are
>> clumsy constructions like "one should not" and "it is advised not to".
>>
>> On 8/6/2012 10:11 AM, Rebecca Welzenbach wrote:
>>> Hi all,
>>>
>>> I'm putting together the first draft of our style guide, which for now
>>> consists of the "Style Notes," "House style: notes on usage," and
>>> "House style: preferred orthography sections of
>>> http://www.tei-c.org/Activities/Council/Working/tcw20.xml," plus our
>>> conclusions about hyphenation and some other bits and pieces.
>>>
>>> While editing it occurred to me to add a note about the voice in which
>>> the Guidelines are written. I assumed that the Guidelines were written
>>> in the third person, but in Chapter 1 alone, I saw several instances
>>> of "we":
>>>
>>> * "we refer to such a document informally as an ODD document"
>>> * "which we call a module"
>>> * "we also say that class B is a superclass of class A"
>>> * "We do not describe them in detail here"
>>>
>>> Should the Style Guide address the overall voice of the Guidelines,
>>> and if so, which of the following do you prefer?:
>>>
>>> * First-person (in which case it may be necessary to check for
>>> ambiguity about whether "we" refers to the editors, the Technical
>>> Council, all TEI users, or some other group, and find a way to
>>> document/clarify this).
>>> * Third-person (in which case sentences currently using "we" will
>>> probably be flipped around into the passive voice, e.g. from "which we
>>> call a module" to "which is called a module" This annoys some readers
>>> and writers more than others).
>>> * Or something like "choose clarity and efficiency of language over
>>> any particular voice"
>>>
>>> Thanks for your input,
>>>
>>> Becky
>
>

-- 
David Sewell, Editorial and Technical Manager
ROTUNDA, The University of Virginia Press
PO Box 400314, Charlottesville, VA 22904-4314 USA
Email: dsewell at virginia.edu   Tel: +1 434 924 9973
Web: http://rotunda.upress.virginia.edu/

From James.Cummings at it.ox.ac.uk  Mon Aug  6 12:11:34 2012
From: James.Cummings at it.ox.ac.uk (James Cummings)
Date: Mon, 06 Aug 2012 17:11:34 +0100
Subject: [tei-council] TEI deprecation practices
In-Reply-To: <501EAFD3.6030703@uvic.ca>
References: <501D894E.3030504@ultraslavonic.info> <501EAFD3.6030703@uvic.ca>
Message-ID: <501FECB6.50101@it.ox.ac.uk>


I've always viewed soft deprecation as an entirely unofficial 
form of deprecation. I.e. we're not yet stating that this is 
deprecated, we're just trying to remove active recommendations 
for its use. (i.e. making sure our examples use @ref instead of @key)

I believe that what Laurent recommends in a later message 
forwarded by Kevin is the deprecation procedure we agreed to 
previously. That when we decide to really really deprecate 
something, that we not only add a @status="deprecated" to it, 
remarks noting that it is deprecated, but open a ticket with the 
deprecated category on sf as a place to document and have 
discussion concerning it post-deprecation. That ticket should 
contain a date by which the object should be removed from the 
guidelines.

An example of where we've partly done this is @targets on 
alt/join/link but I've no recollection if we created a ticket 
concerning it?

-james




On 05/08/12 18:39, Martin Holmes wrote:
> HI Kevin,
>
> This is very helpful. The first thing that occurs to me is that the
> "soft deprecation" method is hard to notice in the Guidelines; the Note
> in which it's mentioned in e.g. <relationGrp> is right at the bottom of
> the page:
>
> <http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-relationGrp.html>
>
> and many people would use the tag unknowingly without getting that far.
> The fact that <relationGrp> is no longer mentioned in the chapter linked
> from the element page is perhaps a clue, but not a very good one. We
> could make the deprecation more evident by putting some signal directly
> into the first row/cell of the element page (such as the red text shown
> in the hard-deprecated @targets definition).
>
> Personally, I don't like the distinction between hard and soft
> deprecation. What "soft" really means in the case of e.g. relationGrp is
> that the element is retained for backwards-compatibility; I think that
> should always be temporary, albeit perhaps long-lasting, and the
> end-result of deprecation should be eventual removal/replacement.
>
> Cheers,
> Martin
>
> On 12-08-04 01:42 PM, Kevin Hawkins wrote:
>> Councilors (cc'ing Laurent),
>>
>> I've been having some confused discussions with various people about
>> deprecation practices for the Guidelines, and I realized that I was not
>> even sure of our practice any more.  I've done lots of archeology in
>> meeting minutes and in Sourceforge and have produced what I think is a
>> summary of our deprecation practices, plus some questions:
>>
>> http://wiki.tei-c.org/index.php/Deprecation
>>
>> Please review.
>>
>> I hope once we sort this out, I will be able to move forward on
>> http://purl.org/tei/bug/3376456 , and it might also help James with
>> http://purl.org/tei/bug/3435326 .
>>
>> By the way, I've added a link to the wiki page from a new question and
>> answer I've just added to the Council FAQ:
>>
>> http://wiki.tei-c.org/index.php/TEI-Council-FAQ#In_what_ways_will_Council_break_backwards_compatibility.3F
>>
>> Thanks,
>>
>> Kevin
>>


-- 
Dr James Cummings, James.Cummings at it.ox.ac.uk
Research Support, IT Services, University of Oxford

From James.Cummings at it.ox.ac.uk  Mon Aug  6 12:16:03 2012
From: James.Cummings at it.ox.ac.uk (James Cummings)
Date: Mon, 06 Aug 2012 17:16:03 +0100
Subject: [tei-council] Lite Final, finally
In-Reply-To: <08d2e388-f671-48d4-a19f-3ec01029a542@HUB02.ad.oak.ox.ac.uk>
References: <501FD0D9.7000806@retired.ox.ac.uk>
	<08d2e388-f671-48d4-a19f-3ec01029a542@HUB02.ad.oak.ox.ac.uk>
Message-ID: <501FEDC3.5000109@it.ox.ac.uk>


Yes, we need to decide what this is called. Our naming convention 
seems to indicate that tei_lite.odd is the standard format.

Someone has already got rid of teilite.odd, but teilite_ns.odd is 
still there. Could we agree on a single name and remove the 
others from the repository to avoid confusion?

Since we are *freezing* this version of TEI Lite, should it now 
have a @source pointing to the version of the TEI in the Vault?

-James


On 06/08/12 15:18, Sebastian Rahtz wrote:
>
> On 6 Aug 2012, at 15:12, Lou Burnard wrote:
>>
>> I have also checked in a sample Lite file to which I may add some new
>> features shortly.
>>
> where are you thinking of putting that? how would people find it?
>
>> One thing I haven't done is change the name of the schema generated --
>> it's still called "teilite" rather than "tei_lite". Easy to change if
>> people think this is important.
>>
>
> it bothers me a bit. I think, for good or bad, "teilite" is a fixed point,
> so the ODD should be teilite.odd
>
> --
> Sebastian Rahtz
> Director (Research Support) of Academic IT Services
> University of Oxford IT Services
> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>
> S?lo le pido a Dios
> que el futuro no me sea indiferente
>


-- 
Dr James Cummings, James.Cummings at it.ox.ac.uk
Research Support, IT Services, University of Oxford

From kevin.s.hawkins at ultraslavonic.info  Mon Aug  6 13:49:16 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Mon, 06 Aug 2012 13:49:16 -0400
Subject: [tei-council] explanation of version numbers in AB-About.xml (was
 Re: proposed additions to tcw22)
In-Reply-To: <5005DB2B.4050003@ultraslavonic.info>
References: <4FDB38D4.7010605@ultraslavonic.info>	<4FDB3BA8.5030200@oucs.ox.ac.uk>	<50058595.7070605@ultraslavonic.info>
	<5005DB2B.4050003@ultraslavonic.info>
Message-ID: <5020039C.7030300@ultraslavonic.info>

This is now done at revision 10718:

http://tei.svn.sourceforge.net/viewvc/tei/trunk/P5/Source/Guidelines/en/AB-About.xml?r1=10718&r2=10717&pathrev=10718

On 7/17/2012 5:37 PM, Kevin Hawkins wrote:
> Sorry, "revise this ticket" should read "revise this page".
>
> On 7/17/2012 11:32 AM, Kevin Hawkins wrote:
>> I just noticed that the "Future Developments" section of the "About
>> these Guidelines" chapter of P5 makes reference to a version numbering
>> system with two parts:
>>
>> http://www.tei-c.org/release/doc/tei-p5-doc/en/html/AB.html#ABTEI4
>>
>> We now have ONLY three-part version numbers using the Unicode
>> Consortium's system, right?  That is, whatever we were intended when
>> this was written no longer applies, right?  If so, I'll revise this
>> ticket to reference the Unicode system, just as I did in tcw22 and
>> data.version.xml.
>>
>> On 6/15/2012 9:42 AM, James Cummings wrote:
>>
>>> http://unicode.org/versions/
>>
>>> On 15/06/12 14:29, Kevin Hawkins wrote:
>>
>>>> Can anyone provide me a reference for Unicode version conventions?  I
>>>> would like to add it to tcw22 and also to
>>>> http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-data.version.html ,
>>>> which mentions this but does not explain the usage.
>>>
>>>

From gabriel.bodard at kcl.ac.uk  Mon Aug  6 14:48:00 2012
From: gabriel.bodard at kcl.ac.uk (Gabriel BODARD)
Date: Mon, 6 Aug 2012 19:48:00 +0100
Subject: [tei-council] active/passive again
In-Reply-To: <501FDC73.8020408@uvic.ca>
References: <501F92E9.8080104@kcl.ac.uk> <501FDC73.8020408@uvic.ca>
Message-ID: <50201160.9030406@kcl.ac.uk>

On 06/08/2012 16:02, Martin Holmes wrote:
>> @active	identifies the ?active? participants in a non-mutual
>> relationship, or all the participants in a mutual one.
>
> This rather suggests to me that where @mutual is used, @active and
> @passive should not be, and vice versa. Are the examples of relations in
> which there are active and passive participants, but also groups of
> mutual ones?

Right, it is saying that @active/@passive and @mutual should not be used 
simultaneously, but that @active may be used on its own, and its meaning 
would be (as far as I can tell) identical to @mutual.

> I can't, but I feel as though there must be a better terminology than
> subject/object, which comes loaded with linguistic baggage.

That's true, but they have the advantage over active/passive in that the 
linguistic/grammatical baggage they bring with them is more likely to be 
correct. In the phrase A is father of B, A is both grammatically active 
and the subject of the sentence, and B is both grammatically passive and 
the object of the sentence. But in the phrase A was killed by B, the 
active/passive definitions are broken (or at the very least confusing), 
whereas subject/object are still grammatically (and logically) true.

-- 
Dr Gabriel BODARD
(Research Associate in Digital Epigraphy)

Department of Digital Humanities
King's College London
26-29 Drury Lane
London WC2B 5RL

Email: gabriel.bodard at kcl.ac.uk
Tel: +44 (0)20 7848 1388
Fax: +44 (0)20 7848 2980

http://www.digitalclassicist.org/
http://www.currentepigraphy.org/

From syeates at gmail.com  Mon Aug  6 18:58:35 2012
From: syeates at gmail.com (Stuart A. Yeates)
Date: Tue, 7 Aug 2012 10:58:35 +1200
Subject: [tei-council] My role on the council
Message-ID: <CAC_Lu0YopUJq=OGkq769wAGSAvJys_czB2nu8AU4C-wxum56AQ@mail.gmail.com>

Due to a couple of unforeseen family developments, I'm going to have
to relinquish my role on the council.

Anyone keen for the gory details can contact me off list.

My motivations remain the same, but temporarily in abeyance.

cheers
stuart

From James.Cummings at it.ox.ac.uk  Tue Aug  7 05:57:08 2012
From: James.Cummings at it.ox.ac.uk (James Cummings)
Date: Tue, 07 Aug 2012 10:57:08 +0100
Subject: [tei-council] My role on the council
In-Reply-To: <CAC_Lu0YopUJq=OGkq769wAGSAvJys_czB2nu8AU4C-wxum56AQ@mail.gmail.com>
References: <CAC_Lu0YopUJq=OGkq769wAGSAvJys_czB2nu8AU4C-wxum56AQ@mail.gmail.com>
Message-ID: <5020E674.2050801@it.ox.ac.uk>


Hi Stuart,

I am of course sad to hear this, I hope everything is well. Thank 
you for your work on the council.

I believe Stuart's term was until the end of this year. (So 
coming up for re-election at the members' meeting in November.) 
The bylaws seem vague on what we should do. Should we hold a 
special election to replace him, appoint a successor (from 
previous candidates), or just leave the spot vacant until 
November?  Of all of these, I'm probably in favour of the last 
one since it is the least complicated.

Thoughts?

-James


On 06/08/12 23:58, Stuart A. Yeates wrote:
> Due to a couple of unforeseen family developments, I'm going to have
> to relinquish my role on the council.
>
> Anyone keen for the gory details can contact me off list.
>
> My motivations remain the same, but temporarily in abeyance.
>
> cheers
> stuart
>


-- 
Dr James Cummings, James.Cummings at it.ox.ac.uk
Research Support, IT Services, University of Oxford

From sebastian.rahtz at it.ox.ac.uk  Tue Aug  7 06:10:00 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Tue, 7 Aug 2012 10:10:00 +0000
Subject: [tei-council] My role on the council
In-Reply-To: <5020E674.2050801@it.ox.ac.uk>
References: <CAC_Lu0YopUJq=OGkq769wAGSAvJys_czB2nu8AU4C-wxum56AQ@mail.gmail.com>
	<5020E674.2050801@it.ox.ac.uk>
Message-ID: <b0683a53-aa19-46b6-8d24-75b3ae860551@HUB04.ad.oak.ox.ac.uk>

It does not seem worth appointing someone for 3-4 months, I agree.

Which reminds me, the call for nominations for elections to Council and Board
are usually out well before this?
--
Sebastian Rahtz      
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431


From gabriel.bodard at kcl.ac.uk  Tue Aug  7 06:21:48 2012
From: gabriel.bodard at kcl.ac.uk (Gabriel BODARD)
Date: Tue, 7 Aug 2012 11:21:48 +0100
Subject: [tei-council] My role on the council
In-Reply-To: <b0683a53-aa19-46b6-8d24-75b3ae860551@HUB04.ad.oak.ox.ac.uk>
References: <CAC_Lu0YopUJq=OGkq769wAGSAvJys_czB2nu8AU4C-wxum56AQ@mail.gmail.com>
	<5020E674.2050801@it.ox.ac.uk>
	<b0683a53-aa19-46b6-8d24-75b3ae860551@HUB04.ad.oak.ox.ac.uk>
Message-ID: <5020EC3C.8090309@kcl.ac.uk>

In similar circumstances I seem to recall the board appointing someone 
ad hoc for a temporary period. While I agree we don't want to go to a 
lot of trouble to appoint someone for 3-4 months, if there's anyone we 
could think of who would be useful we could consider inviting them to 
Oxford. (E.g. Laurent?)

Do we have a nominations committee for the council election yet? I 
suspect this has all been held up by delays on the board until recently, 
but is there anything we would normally be doing?

On 07/08/2012 11:10, Sebastian Rahtz wrote:
> It does not seem worth appointing someone for 3-4 months, I agree.
>
> Which reminds me, the call for nominations for elections to Council and Board
> are usually out well before this?
> --
> Sebastian Rahtz
> Director (Research Support) of Academic IT Services
> University of Oxford IT Services
> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>

-- 
Dr Gabriel BODARD
(Research Associate in Digital Epigraphy)

Department of Digital Humanities
King's College London
26-29 Drury Lane
London WC2B 5RL

Email: gabriel.bodard at kcl.ac.uk
Tel: +44 (0)20 7848 1388
Fax: +44 (0)20 7848 2980

http://www.digitalclassicist.org/
http://www.currentepigraphy.org/

From sebastian.rahtz at it.ox.ac.uk  Tue Aug  7 06:25:00 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Tue, 7 Aug 2012 10:25:00 +0000
Subject: [tei-council] My role on the council
In-Reply-To: <5020EC3C.8090309@kcl.ac.uk>
References: <CAC_Lu0YopUJq=OGkq769wAGSAvJys_czB2nu8AU4C-wxum56AQ@mail.gmail.com>
	<5020E674.2050801@it.ox.ac.uk>
	<b0683a53-aa19-46b6-8d24-75b3ae860551@HUB04.ad.oak.ox.ac.uk>,
	<5020EC3C.8090309@kcl.ac.uk>
Message-ID: <3D11821D65070D4BADB84B46F7FE203C845231@MBX01.ad.oak.ox.ac.uk>

by the way, remember this list is public. it may be unwise to discuss named individuals here.

Sebastian

From gabriel.bodard at kcl.ac.uk  Tue Aug  7 06:28:32 2012
From: gabriel.bodard at kcl.ac.uk (Gabriel BODARD)
Date: Tue, 7 Aug 2012 11:28:32 +0100
Subject: [tei-council] My role on the council
In-Reply-To: <3D11821D65070D4BADB84B46F7FE203C845231@MBX01.ad.oak.ox.ac.uk>
References: <CAC_Lu0YopUJq=OGkq769wAGSAvJys_czB2nu8AU4C-wxum56AQ@mail.gmail.com>
	<5020E674.2050801@it.ox.ac.uk>
	<b0683a53-aa19-46b6-8d24-75b3ae860551@HUB04.ad.oak.ox.ac.uk>,
	<5020EC3C.8090309@kcl.ac.uk>
	<3D11821D65070D4BADB84B46F7FE203C845231@MBX01.ad.oak.ox.ac.uk>
Message-ID: <5020EDD0.1070504@kcl.ac.uk>

My bad. I assumed that was an uncontroversial suggestion (I was more 
worried about whether the idea of appointing someone ad hoc might be 
seen as unconstitutional). But I'll refrain from suggesting names here. 
(In any case, my erstwhile nominee would probably not thank me for the 
suggestion! ;-) )

On 07/08/2012 11:25, Sebastian Rahtz wrote:
> by the way, remember this list is public. it may be unwise to discuss named individuals here.
>
> Sebastian
>

-- 
Dr Gabriel BODARD
(Research Associate in Digital Epigraphy)

Department of Digital Humanities
King's College London
26-29 Drury Lane
London WC2B 5RL

Email: gabriel.bodard at kcl.ac.uk
Tel: +44 (0)20 7848 1388
Fax: +44 (0)20 7848 2980

http://www.digitalclassicist.org/
http://www.currentepigraphy.org/

From James.Cummings at it.ox.ac.uk  Tue Aug  7 06:31:40 2012
From: James.Cummings at it.ox.ac.uk (James Cummings)
Date: Tue, 07 Aug 2012 11:31:40 +0100
Subject: [tei-council] My role on the council
In-Reply-To: <5020EC3C.8090309@kcl.ac.uk>
References: <CAC_Lu0YopUJq=OGkq769wAGSAvJys_czB2nu8AU4C-wxum56AQ@mail.gmail.com>
	<5020E674.2050801@it.ox.ac.uk>
	<b0683a53-aa19-46b6-8d24-75b3ae860551@HUB04.ad.oak.ox.ac.uk>
	<5020EC3C.8090309@kcl.ac.uk>
Message-ID: <5020EE8C.6050001@it.ox.ac.uk>

On 07/08/12 11:21, Gabriel BODARD wrote:
> Do we have a nominations committee for the council election yet? I
> suspect this has all been held up by delays on the board until recently,
> but is there anything we would normally be doing?

There is a nominating ad-hoc committee set up by the board 
consisting of David Sewell, John Walsh, and me.  It will be 
circulating a call for nominations soon.

-James

-- 
Dr James Cummings, James.Cummings at it.ox.ac.uk
Research Support, IT Services, University of Oxford

From James.Cummings at it.ox.ac.uk  Tue Aug  7 06:42:00 2012
From: James.Cummings at it.ox.ac.uk (James Cummings)
Date: Tue, 07 Aug 2012 11:42:00 +0100
Subject: [tei-council] My role on the council
In-Reply-To: <5020EDD0.1070504@kcl.ac.uk>
References: <CAC_Lu0YopUJq=OGkq769wAGSAvJys_czB2nu8AU4C-wxum56AQ@mail.gmail.com>
	<5020E674.2050801@it.ox.ac.uk>
	<b0683a53-aa19-46b6-8d24-75b3ae860551@HUB04.ad.oak.ox.ac.uk>,
	<5020EC3C.8090309@kcl.ac.uk>
	<3D11821D65070D4BADB84B46F7FE203C845231@MBX01.ad.oak.ox.ac.uk>
	<5020EDD0.1070504@kcl.ac.uk>
Message-ID: <5020F0F8.4090709@it.ox.ac.uk>

On 07/08/12 11:28, Gabriel BODARD wrote:
> My bad. I assumed that was an uncontroversial suggestion (I was more
> worried about whether the idea of appointing someone ad hoc might be
> seen as unconstitutional). But I'll refrain from suggesting names here.
> (In any case, my erstwhile nominee would probably not thank me for the
> suggestion! ;-) )

There is precedent for that.

I am of the opinion that re-election or proposal of someone to 
fill Stuart's place with a short time left on the term is not a 
good use of time. The Council has always had the ability to 
invite others to its meetings, especially to speak to particular 
matters up for discussion. We could of course do this in 
September if people feel it useful. (If you do, feel free to 
email me offlist and i'll report at the teleconference this 
Thursday.

  The TEI Council teleconference is this Thursday from 8pm BST. 
Please add things to the agenda at:

http://wiki.tei-c.org/index.php/Council#Teleconference_-_2012-08-09_20:00_BST

And just a reminder to double-check your diaries and make sure 
you've blocked out the time! The TEI Council meeting is 19 - 21 
September in Oxford. Please let me know _now_ if you aren't going 
to be able to make it to either of these meetings.

-James

-- 
Dr James Cummings, James.Cummings at it.ox.ac.uk
Research Support, IT Services, University of Oxford

From sebastian.rahtz at it.ox.ac.uk  Tue Aug  7 07:29:31 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Tue, 7 Aug 2012 11:29:31 +0000
Subject: [tei-council] extra artefacts
Message-ID: <C1D73CB7-8C06-48D1-BBE8-FA3194B576D2@it.ox.ac.uk>

I have taken it upon myself to generate:

(example urls)
http://bits.nsms.ox.ac.uk:8080/jenkins/job/TEIP5/lastSuccessfulBuild/artifact/release/xml/tei/odd/p5attlist.txt
http://bits.nsms.ox.ac.uk:8080/jenkins/job/TEIP5/lastSuccessfulBuild/artifact/release/xml/tei/odd/stripspace.model
http://bits.nsms.ox.ac.uk:8080/jenkins/job/TEIP5/lastSuccessfulBuild/artifact/release/xml/tei/odd/p5subset.json

as requested by John McCaskey and Rafaele Viglianti

Does anyone have objections to this?
--
Sebastian Rahtz      
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431


From James.Cummings at it.ox.ac.uk  Tue Aug  7 07:39:47 2012
From: James.Cummings at it.ox.ac.uk (James Cummings)
Date: Tue, 07 Aug 2012 12:39:47 +0100
Subject: [tei-council] extra artefacts
In-Reply-To: <C1D73CB7-8C06-48D1-BBE8-FA3194B576D2@it.ox.ac.uk>
References: <C1D73CB7-8C06-48D1-BBE8-FA3194B576D2@it.ox.ac.uk>
Message-ID: <5020FE83.8070908@it.ox.ac.uk>


Only that the second got me a 404.

Where will the existence of these be documented?

-James


On 07/08/12 12:29, Sebastian Rahtz wrote:
> I have taken it upon myself to generate:
>
> (example urls)
> http://bits.nsms.ox.ac.uk:8080/jenkins/job/TEIP5/lastSuccessfulBuild/artifact/release/xml/tei/odd/p5attlist.txt
> http://bits.nsms.ox.ac.uk:8080/jenkins/job/TEIP5/lastSuccessfulBuild/artifact/release/xml/tei/odd/stripspace.model
> http://bits.nsms.ox.ac.uk:8080/jenkins/job/TEIP5/lastSuccessfulBuild/artifact/release/xml/tei/odd/p5subset.json
>
> as requested by John McCaskey and Rafaele Viglianti
>
> Does anyone have objections to this?
> --
> Sebastian Rahtz
> Director (Research Support) of Academic IT Services
> University of Oxford IT Services
> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>


-- 
Dr James Cummings, James.Cummings at it.ox.ac.uk
Research Support, IT Services, University of Oxford

From lou.burnard at retired.ox.ac.uk  Tue Aug  7 07:40:47 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Tue, 07 Aug 2012 12:40:47 +0100
Subject: [tei-council] extra artefacts
In-Reply-To: <C1D73CB7-8C06-48D1-BBE8-FA3194B576D2@it.ox.ac.uk>
References: <C1D73CB7-8C06-48D1-BBE8-FA3194B576D2@it.ox.ac.uk>
Message-ID: <5020FEBF.90609@retired.ox.ac.uk>

The second of these doesn't seem to work  -- Firefox gives me a 404

My only objection is the absence of any documentation of their function 
or how to use them. Which means they will just contribute to that image 
of the TEI as an accumulation of esoteric arcana.

Could someone maybe at least write a wiki page, or a link from the tools 
page to mention their existence?


On 07/08/12 12:29, Sebastian Rahtz wrote:
> I have taken it upon myself to generate:
>
> (example urls)
> http://bits.nsms.ox.ac.uk:8080/jenkins/job/TEIP5/lastSuccessfulBuild/artifact/release/xml/tei/odd/p5attlist.txt
> http://bits.nsms.ox.ac.uk:8080/jenkins/job/TEIP5/lastSuccessfulBuild/artifact/release/xml/tei/odd/stripspace.model
> http://bits.nsms.ox.ac.uk:8080/jenkins/job/TEIP5/lastSuccessfulBuild/artifact/release/xml/tei/odd/p5subset.json
>
> as requested by John McCaskey and Rafaele Viglianti
>
> Does anyone have objections to this?
> --
> Sebastian Rahtz
> Director (Research Support) of Academic IT Services
> University of Oxford IT Services
> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>


From James.Cummings at it.ox.ac.uk  Tue Aug  7 07:42:45 2012
From: James.Cummings at it.ox.ac.uk (James Cummings)
Date: Tue, 07 Aug 2012 12:42:45 +0100
Subject: [tei-council] extra artefacts
In-Reply-To: <5020FEBF.90609@retired.ox.ac.uk>
References: <C1D73CB7-8C06-48D1-BBE8-FA3194B576D2@it.ox.ac.uk>
	<5020FEBF.90609@retired.ox.ac.uk>
Message-ID: <5020FF35.30005@it.ox.ac.uk>


Well, presumably, the links provided shouldn't be the Jenkins 
one, but their location under release/ at tei-c.org for each 
stable release (from the next one).

-James


On 07/08/12 12:40, Lou Burnard wrote:
> The second of these doesn't seem to work  -- Firefox gives me a 404
>
> My only objection is the absence of any documentation of their function
> or how to use them. Which means they will just contribute to that image
> of the TEI as an accumulation of esoteric arcana.
>
> Could someone maybe at least write a wiki page, or a link from the tools
> page to mention their existence?
>
>
> On 07/08/12 12:29, Sebastian Rahtz wrote:
>> I have taken it upon myself to generate:
>>
>> (example urls)
>> http://bits.nsms.ox.ac.uk:8080/jenkins/job/TEIP5/lastSuccessfulBuild/artifact/release/xml/tei/odd/p5attlist.txt
>> http://bits.nsms.ox.ac.uk:8080/jenkins/job/TEIP5/lastSuccessfulBuild/artifact/release/xml/tei/odd/stripspace.model
>> http://bits.nsms.ox.ac.uk:8080/jenkins/job/TEIP5/lastSuccessfulBuild/artifact/release/xml/tei/odd/p5subset.json
>>
>> as requested by John McCaskey and Rafaele Viglianti
>>
>> Does anyone have objections to this?
>> --
>> Sebastian Rahtz
>> Director (Research Support) of Academic IT Services
>> University of Oxford IT Services
>> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>>
>


-- 
Dr James Cummings, James.Cummings at it.ox.ac.uk
Research Support, IT Services, University of Oxford

From lou.burnard at retired.ox.ac.uk  Tue Aug  7 07:44:14 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Tue, 07 Aug 2012 12:44:14 +0100
Subject: [tei-council] extra artefacts
In-Reply-To: <5020FF35.30005@it.ox.ac.uk>
References: <C1D73CB7-8C06-48D1-BBE8-FA3194B576D2@it.ox.ac.uk>
	<5020FEBF.90609@retired.ox.ac.uk> <5020FF35.30005@it.ox.ac.uk>
Message-ID: <5020FF8E.1050109@retired.ox.ac.uk>

Only if we agree that they should be part of the release. And I for one 
am loth to agree to that in the absence of any decent or indeed any 
documentation.


On 07/08/12 12:42, James Cummings wrote:
>
> Well, presumably, the links provided shouldn't be the Jenkins
> one, but their location under release/ at tei-c.org for each
> stable release (from the next one).
>
> -James
>
>
> On 07/08/12 12:40, Lou Burnard wrote:
>> The second of these doesn't seem to work  -- Firefox gives me a 404
>>
>> My only objection is the absence of any documentation of their function
>> or how to use them. Which means they will just contribute to that image
>> of the TEI as an accumulation of esoteric arcana.
>>
>> Could someone maybe at least write a wiki page, or a link from the tools
>> page to mention their existence?
>>
>>
>> On 07/08/12 12:29, Sebastian Rahtz wrote:
>>> I have taken it upon myself to generate:
>>>
>>> (example urls)
>>> http://bits.nsms.ox.ac.uk:8080/jenkins/job/TEIP5/lastSuccessfulBuild/artifact/release/xml/tei/odd/p5attlist.txt
>>> http://bits.nsms.ox.ac.uk:8080/jenkins/job/TEIP5/lastSuccessfulBuild/artifact/release/xml/tei/odd/stripspace.model
>>> http://bits.nsms.ox.ac.uk:8080/jenkins/job/TEIP5/lastSuccessfulBuild/artifact/release/xml/tei/odd/p5subset.json
>>>
>>> as requested by John McCaskey and Rafaele Viglianti
>>>
>>> Does anyone have objections to this?
>>> --
>>> Sebastian Rahtz
>>> Director (Research Support) of Academic IT Services
>>> University of Oxford IT Services
>>> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>>>
>>
>
>


From James.Cummings at it.ox.ac.uk  Tue Aug  7 07:48:57 2012
From: James.Cummings at it.ox.ac.uk (James Cummings)
Date: Tue, 07 Aug 2012 12:48:57 +0100
Subject: [tei-council] extra artefacts
In-Reply-To: <5020FF8E.1050109@retired.ox.ac.uk>
References: <C1D73CB7-8C06-48D1-BBE8-FA3194B576D2@it.ox.ac.uk>
	<5020FEBF.90609@retired.ox.ac.uk> <5020FF35.30005@it.ox.ac.uk>
	<5020FF8E.1050109@retired.ox.ac.uk>
Message-ID: <502100A9.6020208@it.ox.ac.uk>


I was assuming that if we agree they should be part of the 
release, one of the tasks on the person proposing them is that 
they should write documentation for them.  I think we're really 
in agreement here.

-James


On 07/08/12 12:44, Lou Burnard wrote:
> Only if we agree that they should be part of the release. And I for one
> am loth to agree to that in the absence of any decent or indeed any
> documentation.
>
>
> On 07/08/12 12:42, James Cummings wrote:
>>
>> Well, presumably, the links provided shouldn't be the Jenkins
>> one, but their location under release/ at tei-c.org for each
>> stable release (from the next one).
>>
>> -James
>>
>>
>> On 07/08/12 12:40, Lou Burnard wrote:
>>> The second of these doesn't seem to work  -- Firefox gives me a 404
>>>
>>> My only objection is the absence of any documentation of their function
>>> or how to use them. Which means they will just contribute to that image
>>> of the TEI as an accumulation of esoteric arcana.
>>>
>>> Could someone maybe at least write a wiki page, or a link from the tools
>>> page to mention their existence?
>>>
>>>
>>> On 07/08/12 12:29, Sebastian Rahtz wrote:
>>>> I have taken it upon myself to generate:
>>>>
>>>> (example urls)
>>>> http://bits.nsms.ox.ac.uk:8080/jenkins/job/TEIP5/lastSuccessfulBuild/artifact/release/xml/tei/odd/p5attlist.txt
>>>> http://bits.nsms.ox.ac.uk:8080/jenkins/job/TEIP5/lastSuccessfulBuild/artifact/release/xml/tei/odd/stripspace.model
>>>> http://bits.nsms.ox.ac.uk:8080/jenkins/job/TEIP5/lastSuccessfulBuild/artifact/release/xml/tei/odd/p5subset.json
>>>>
>>>> as requested by John McCaskey and Rafaele Viglianti
>>>>
>>>> Does anyone have objections to this?
>>>> --
>>>> Sebastian Rahtz
>>>> Director (Research Support) of Academic IT Services
>>>> University of Oxford IT Services
>>>> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>>>>
>>>
>>
>>
>


-- 
Dr James Cummings, James.Cummings at it.ox.ac.uk
Research Support, IT Services, University of Oxford

From sebastian.rahtz at it.ox.ac.uk  Tue Aug  7 08:02:24 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Tue, 7 Aug 2012 12:02:24 +0000
Subject: [tei-council] extra artefacts
In-Reply-To: <5020FE83.8070908@it.ox.ac.uk>
References: <C1D73CB7-8C06-48D1-BBE8-FA3194B576D2@it.ox.ac.uk>
	<5020FE83.8070908@it.ox.ac.uk>
Message-ID: <ca944981-5714-4852-8e4c-a4d1b1479d63@HUB02.ad.oak.ox.ac.uk>


On 7 Aug 2012, at 12:39, James Cummings wrote:

> 
> Only that the second got me a 404.
> 

>> http://bits.nsms.ox.ac.uk:8080/jenkins/job/TEIP5/lastSuccessfulBuild/artifact/release/xml/tei/odd/stripspace.xsl.model

> Where will the existence of these be documented?


a good question. got a suggestion? ditto for p5subset.xml (which is badly named, sign)
--
Sebastian Rahtz      
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
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 it.ox.ac.uk  Tue Aug  7 08:09:44 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Tue, 7 Aug 2012 12:09:44 +0000
Subject: [tei-council] extra artefacts
In-Reply-To: <502100A9.6020208@it.ox.ac.uk>
References: <C1D73CB7-8C06-48D1-BBE8-FA3194B576D2@it.ox.ac.uk>
	<5020FEBF.90609@retired.ox.ac.uk> <5020FF35.30005@it.ox.ac.uk>
	<5020FF8E.1050109@retired.ox.ac.uk> <502100A9.6020208@it.ox.ac.uk>
Message-ID: <68ece956-e9f2-45d8-a066-9a28ef55972f@HUB03.ad.oak.ox.ac.uk>

I am happy indeed to write the paragraph or two explaining what the extra artefacts are that we can offer,
along with the ones we already have

but that needs some careful, thought, no? I mean, where do people expect to read
what they will find in every release? not in a wiki, I hope and pray. 

have I forgotten some document which already explains this?
--
Sebastian Rahtz      
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
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 it.ox.ac.uk  Tue Aug  7 08:17:08 2012
From: James.Cummings at it.ox.ac.uk (James Cummings)
Date: Tue, 07 Aug 2012 13:17:08 +0100
Subject: [tei-council] extra artefacts
In-Reply-To: <68ece956-e9f2-45d8-a066-9a28ef55972f@HUB03.ad.oak.ox.ac.uk>
References: <C1D73CB7-8C06-48D1-BBE8-FA3194B576D2@it.ox.ac.uk>
	<5020FEBF.90609@retired.ox.ac.uk> <5020FF35.30005@it.ox.ac.uk>
	<5020FF8E.1050109@retired.ox.ac.uk> <502100A9.6020208@it.ox.ac.uk>
	<68ece956-e9f2-45d8-a066-9a28ef55972f@HUB03.ad.oak.ox.ac.uk>
Message-ID: <50210744.9000508@it.ox.ac.uk>


Would http://www.tei-c.org/Guidelines/P5/ be the correct place?

It certainly seems not to be: 
http://www.tei-c.org/release/00readme.txt

-James


On 07/08/12 13:09, Sebastian Rahtz wrote:
> I am happy indeed to write the paragraph or two explaining what the extra artefacts are that we can offer,
> along with the ones we already have
>
> but that needs some careful, thought, no? I mean, where do people expect to read
> what they will find in every release? not in a wiki, I hope and pray.
>
> have I forgotten some document which already explains this?
> --
> Sebastian Rahtz
> Director (Research Support) of Academic IT Services
> University of Oxford IT Services
> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>
> S?lo le pido a Dios
> que el futuro no me sea indiferente
>


-- 
Dr James Cummings, James.Cummings at it.ox.ac.uk
Research Support, IT Services, University of Oxford

From sebastian.rahtz at it.ox.ac.uk  Tue Aug  7 08:29:43 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Tue, 7 Aug 2012 12:29:43 +0000
Subject: [tei-council] extra artefacts
In-Reply-To: <50210744.9000508@it.ox.ac.uk>
References: <C1D73CB7-8C06-48D1-BBE8-FA3194B576D2@it.ox.ac.uk>
	<5020FEBF.90609@retired.ox.ac.uk> <5020FF35.30005@it.ox.ac.uk>
	<5020FF8E.1050109@retired.ox.ac.uk> <502100A9.6020208@it.ox.ac.uk>
	<68ece956-e9f2-45d8-a066-9a28ef55972f@HUB03.ad.oak.ox.ac.uk>
	<50210744.9000508@it.ox.ac.uk>
Message-ID: <aac58c97-a5a9-41b1-b975-aba86cc0d6d5@HUB02.ad.oak.ox.ac.uk>


On 7 Aug 2012, at 13:17, James Cummings wrote:

> 
> Would http://www.tei-c.org/Guidelines/P5/ be the correct place?
> 
yes, I suppose so. I guess I'll try to draft (drat) some prose

--
Sebastian Rahtz      
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
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 unl.edu  Tue Aug  7 10:19:25 2012
From: bbarney2 at unl.edu (Brett Barney)
Date: Tue, 7 Aug 2012 14:19:25 +0000
Subject: [tei-council] Third-person vs. First-person in the Guidelines
In-Reply-To: <501FE424.50200@retired.ox.ac.uk>
References: <CAA2irtLCMqeBcFz5nQh+7ec=FHk4_+kwoh-qgAPwQAE0CmOoVg@mail.gmail.com>
	<501FE424.50200@retired.ox.ac.uk>
Message-ID: <F2EF032F-F9E1-458D-AEE1-F262E10347CA@unl.edu>


On Aug 6, 2012, at 10:35 AM, Lou Burnard wrote:

> On 06/08/12 15:11, Rebecca Welzenbach wrote:
> 
>> * First-person (in which case it may be necessary to check for
>> ambiguity about whether "we" refers to the editors, the Technical
>> Council, all TEI users, or some other group, and find a way to
>> document/clarify this).
> 
> "We" is almost always (sfaik) used in passages of formal textual 
> exposition, and thus refers both to the reader and the authorial voice.

I hadn't consciously articulated it this way, but Lou's right here, I think. And I think it's an effective construction. Of the examples Rebecca gives from chapter 1, the last is an exception:

* "We do not describe them in detail here"

I wouldn't mind having in the style guide a non-binding hint to avoid such authorial "we." In their stead, passive constructions would be dandy, I think.

>> * Third-person (in which case sentences currently using "we" will
>> probably be flipped around into the passive voice, e.g. from "which we
>> call a module" to "which is called a module" This annoys some readers
>> and writers more than others).
> 
> Annoys the hell out of me
> 
>> * Or something like "choose clarity and efficiency of language over
>> any particular voice"
> 
> That's the one for me!
> 
> -- 
> 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
> 

----------------
Brett Barney
Associate Research Professor
Center for Digital Research in the Humanities
bbarney2 at unl.edu






From dsewell at virginia.edu  Tue Aug  7 10:44:08 2012
From: dsewell at virginia.edu (David Sewell)
Date: Tue, 7 Aug 2012 10:44:08 -0400 (EDT)
Subject: [tei-council] My role on the council
In-Reply-To: <5020E674.2050801@it.ox.ac.uk>
References: <CAC_Lu0YopUJq=OGkq769wAGSAvJys_czB2nu8AU4C-wxum56AQ@mail.gmail.com>
	<5020E674.2050801@it.ox.ac.uk>
Message-ID: <alpine.OSX.2.00.1208071041530.14419@lister.ei.virginia.edu>

Council list members,

Following this message, I will set Stuart's tei-council list status to "nomail" 
so he'll no longer receive mail, but will leave him as a subscriber until the 
end of the year or until Council appoints a replacement (should you choose), 
whichever comes first.

David

-- 
David Sewell, Editorial and Technical Manager
ROTUNDA, The University of Virginia Press
PO Box 400314, Charlottesville, VA 22904-4314 USA
Email: dsewell at virginia.edu   Tel: +1 434 924 9973
Web: http://rotunda.upress.virginia.edu/

From lou.burnard at retired.ox.ac.uk  Tue Aug  7 11:14:58 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Tue, 07 Aug 2012 16:14:58 +0100
Subject: [tei-council] Third-person vs. First-person in the Guidelines
In-Reply-To: <F2EF032F-F9E1-458D-AEE1-F262E10347CA@unl.edu>
References: <CAA2irtLCMqeBcFz5nQh+7ec=FHk4_+kwoh-qgAPwQAE0CmOoVg@mail.gmail.com>
	<501FE424.50200@retired.ox.ac.uk>
	<F2EF032F-F9E1-458D-AEE1-F262E10347CA@unl.edu>
Message-ID: <502130F2.8020300@retired.ox.ac.uk>

On 07/08/12 15:19, Brett Barney wrote:
>

> I hadn't consciously articulated it this way, but Lou's right here, I think. And I think it's an effective construction. Of the examples Rebecca gives from chapter 1, the last is an exception:
>
> * "We do not describe them in detail here"
>

Yes, I missed that one -- It should of course be passivized eg. "They 
are not described in detail here".

The difference /test is probably to ask something like  "is the material 
being asserted -- typically a technical term or usage -- something that 
the reader is expected to internalise and use themselves thereafter or 
during the exposition?" If so, use "we"; otherwise consider 
passivization, err, passivizationing is to be considered appropriate.



From James.Cummings at it.ox.ac.uk  Tue Aug  7 11:21:26 2012
From: James.Cummings at it.ox.ac.uk (James Cummings)
Date: Tue, 07 Aug 2012 16:21:26 +0100
Subject: [tei-council] My role on the council
In-Reply-To: <alpine.OSX.2.00.1208071041530.14419@lister.ei.virginia.edu>
References: <CAC_Lu0YopUJq=OGkq769wAGSAvJys_czB2nu8AU4C-wxum56AQ@mail.gmail.com>
	<5020E674.2050801@it.ox.ac.uk>
	<alpine.OSX.2.00.1208071041530.14419@lister.ei.virginia.edu>
Message-ID: <50213276.9040900@it.ox.ac.uk>


Thanks David.  And once again many thanks to Stuart for his work 
on the council.

Best,

-James

On 07/08/12 15:44, David Sewell wrote:
> Council list members,
>
> Following this message, I will set Stuart's tei-council list status to "nomail"
> so he'll no longer receive mail, but will leave him as a subscriber until the
> end of the year or until Council appoints a replacement (should you choose),
> whichever comes first.
>
> David
>


-- 
Dr James Cummings, James.Cummings at it.ox.ac.uk
Research Support, IT Services, University of Oxford

From sebastian.rahtz at it.ox.ac.uk  Tue Aug  7 18:13:45 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Tue, 7 Aug 2012 22:13:45 +0000
Subject: [tei-council] extra artefacts
In-Reply-To: <50210744.9000508@it.ox.ac.uk>
References: <C1D73CB7-8C06-48D1-BBE8-FA3194B576D2@it.ox.ac.uk>
	<5020FEBF.90609@retired.ox.ac.uk> <5020FF35.30005@it.ox.ac.uk>
	<5020FF8E.1050109@retired.ox.ac.uk> <502100A9.6020208@it.ox.ac.uk>
	<68ece956-e9f2-45d8-a066-9a28ef55972f@HUB03.ad.oak.ox.ac.uk>
	<50210744.9000508@it.ox.ac.uk>
Message-ID: <33c3ad62-1a3a-472e-965f-257a2914d61b@HUB03.ad.oak.ox.ac.uk>

How about this:

Source and data support files for TEI Guidelines

In addition to the schema modules and example customizations generated for each
release of the Guidelines, a set of files are provided in the xml/tei/odd/ directory
which are for use by those writing TEI tools such as editors or visualizations.

	p5attlist.txt
This is a text file with a comma-separated cataligue of all the attributes available on TEI elements,
list the element or class name, the attribute name, the datatype, and  an indication ("multiple"
or "single") as to whether it can contain multiple values. eg
	att.ascribed,who,data.pointer,multiple


	p5subset.json
This is a representation of all TEI modules, classes, elements and attributes (with their
descriptions) in JSON format for consumption by Javascript tools in web applications. For
example, this fragment provides summary information about the <gi>ab</gi> element:

	p5subset.xml
This is copy of the reference component of the TEI source, extracting all
the <gi>elementSpec</gi>, <gi>classSpec</gi>, <gi>macroSpec</gi>
and <gi>moduleSpec</gi> elements, with descriptions. It does not include
the text of the chapters of the Guidelines, and is intended for use by ODD processors
which need to access all of the TEI components in a convenient single file.

	stripspace.xsl.model
This is a fragmeht of XSL which can be added to any transformation which 
is being applied to a TEI document. It consists of a <xsl:strip-space> element
which lists all the elements which can <emph>not</emph> contain character
data. This tells the processor it can ignore white space around child components
of these elements.
--
Sebastian Rahtz      
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431


From sebastian.rahtz at it.ox.ac.uk  Tue Aug  7 18:28:54 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Tue, 7 Aug 2012 22:28:54 +0000
Subject: [tei-council] Lite Final, finally
In-Reply-To: <501FEDC3.5000109@it.ox.ac.uk>
References: <501FD0D9.7000806@retired.ox.ac.uk>
	<08d2e388-f671-48d4-a19f-3ec01029a542@HUB02.ad.oak.ox.ac.uk>
	<501FEDC3.5000109@it.ox.ac.uk>
Message-ID: <8384baad-bce4-4bb8-9b4c-7cad0ab45065@HUB01.ad.oak.ox.ac.uk>


On 6 Aug 2012, at 17:16, James Cummings <james.cummings at it.ox.ac.uk> wrote:

> 
> Yes, we need to decide what this is called. Our naming convention 
> seems to indicate that tei_lite.odd is the standard format.
> 

but many people, I suspect, reference "teilite.XXX" at the appropriate
location.

> Since we are *freezing* this version of TEI Lite, should it now 
> have a @source pointing to the version of the TEI in the Vault?


are we freezing it? i didnt remember that decision.
its frozen in the sense that it now uses @include.
--
Sebastian Rahtz      
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431


From mholmes at uvic.ca  Tue Aug  7 20:49:13 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Tue, 7 Aug 2012 17:49:13 -0700
Subject: [tei-council] No scheme-based formal way to refer to a
	contributor's role?
Message-ID: <5021B789.10907@uvic.ca>

Hi all,

I find myself wanting to classify the contributions of people to my 
project using a formal classification scheme, such as that provided by 
the MARC Code List for Relators:

<http://www.loc.gov/marc/relators/relacode.html>

I don't need all those values, so I've selected some, and turned them 
into a <taxonomy> in the header of the personography (referring back to 
the original source, of course).

Now I'm trying to find a formal way to link to the <category> elements 
from <person>. The only way I can find to do it is to use 
occupation/@code, since occupation allows @scheme, from which you can 
point to the taxonomy. But that doesn't seem quite right; these are not 
actually "occupations". There is @role, but that's data.enumerated, not 
data.pointer(s).

Am I missing an obvious way to do this, or should I put in a FR for an 
attribute on <person> that can point to a <taxonomy>/<category> (e.g. 
@roleCode)?

Cheers,
Martin
-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From James.Cummings at oucs.ox.ac.uk  Wed Aug  8 04:30:02 2012
From: James.Cummings at oucs.ox.ac.uk (James Cummings)
Date: Wed, 08 Aug 2012 09:30:02 +0100
Subject: [tei-council] No scheme-based formal way to refer to a
 contributor's role?
In-Reply-To: <5021B789.10907@uvic.ca>
References: <5021B789.10907@uvic.ca>
Message-ID: <5022238A.7060002@oucs.ox.ac.uk>

On 08/08/12 01:49, Martin Holmes wrote:
> Now I'm trying to find a formal way to link to the <category> elements
> from <person>. The only way I can find to do it is to use
> occupation/@code, since occupation allows @scheme, from which you can
> point to the taxonomy. But that doesn't seem quite right; these are not
> actually "occupations". There is @role, but that's data.enumerated, not
> data.pointer(s).

Wouldn't @ana on <person> do this? Or indeed maybe more 
accurately on <occupation>? What you're doing is providing an 
analysis of the role by linking it to a <category>, so doesn't 
seem abusive to me.

-James

-- 
Dr James Cummings, James.Cummings at it.ox.ac.uk
Research Support, IT Services, University of Oxford

From mholmes at uvic.ca  Wed Aug  8 11:42:18 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Wed, 8 Aug 2012 08:42:18 -0700
Subject: [tei-council] No scheme-based formal way to refer to a
 contributor's role?
In-Reply-To: <5022238A.7060002@oucs.ox.ac.uk>
References: <5021B789.10907@uvic.ca> <5022238A.7060002@oucs.ox.ac.uk>
Message-ID: <502288DA.5030600@uvic.ca>

On 12-08-08 01:30 AM, James Cummings wrote:
> On 08/08/12 01:49, Martin Holmes wrote:
>> Now I'm trying to find a formal way to link to the <category> elements
>> from <person>. The only way I can find to do it is to use
>> occupation/@code, since occupation allows @scheme, from which you can
>> point to the taxonomy. But that doesn't seem quite right; these are not
>> actually "occupations". There is @role, but that's data.enumerated, not
>> data.pointer(s).
>
> Wouldn't @ana on <person> do this? Or indeed maybe more
> accurately on <occupation>? What you're doing is providing an
> analysis of the role by linking it to a <category>, so doesn't
> seem abusive to me.

If <occupation> is the way to do it, then using @scheme and @code is 
definitely correct. I'm just a bit uncomfortable with the use of 
<occupation> itself:

"<occupation> contains an informal description of a person's trade, 
profession or occupation. "

"Editorial Board member" isn't really an occupation; it's one of 
potentially many roles played by a person in a project. What I want, 
perhaps, is something closer to <resp>, but that's not available in 
<person>.

However, I have just come across <respons>:

"<respons> (responsibility) identifies the individual(s) responsible for 
some aspect of the markup of particular element(s)."

which I didn't notice because it's hiding in the "certainty" module 
(why?). That looks much better, although its restriction to "some aspect 
of the markup of particular elements" is not really going to cover "site 
design" or "Editorial Board member". It does have @resp, which is 
data.pointer:

"a pointer to one of the identifiers typically but not necessarily 
declared in the current document header, associated with a person 
asserted as responsible for some aspect of the text's creation, 
transcription, editing, or encoding".

That looks a bit better.

Cheers,
Martin



-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From lou.burnard at retired.ox.ac.uk  Wed Aug  8 14:38:33 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Wed, 08 Aug 2012 19:38:33 +0100
Subject: [tei-council] Lite Final, finally
In-Reply-To: <501FEDC3.5000109@it.ox.ac.uk>
References: <501FD0D9.7000806@retired.ox.ac.uk>
	<08d2e388-f671-48d4-a19f-3ec01029a542@HUB02.ad.oak.ox.ac.uk>
	<501FEDC3.5000109@it.ox.ac.uk>
Message-ID: <5022B229.5070004@retired.ox.ac.uk>

Have removed teilite_ns.odd

Consistency suggests:

Exemplars/tei_lite.odd : canonical home of the ODD
Exemplars/tei_lite.xml : skeletal template file, Oxygen for the use of
tei_lite : name of schema generated

This does indeed make a break with existing tradition, but that may not 
be a bad thing -- this is a new version after all, and we want people to 
know that.

Alternatively, we turn all the "tei_lite" s back into "teilite" s, and 
have to explain why this one exemplar is different. (Historical reasons 
we might say wisely)

Your votes?

I can happily move my test file to the Test directory, or drop it entirely.

And yes, James, it probably should.

On 06/08/12 17:16, James Cummings wrote:
>
> Yes, we need to decide what this is called. Our naming convention
> seems to indicate that tei_lite.odd is the standard format.
>
> Someone has already got rid of teilite.odd, but teilite_ns.odd is
> still there. Could we agree on a single name and remove the
> others from the repository to avoid confusion?
>
> Since we are *freezing* this version of TEI Lite, should it now
> have a @source pointing to the version of the TEI in the Vault?
>
> -James
>
>
> On 06/08/12 15:18, Sebastian Rahtz wrote:
>>
>> On 6 Aug 2012, at 15:12, Lou Burnard wrote:
>>>
>>> I have also checked in a sample Lite file to which I may add some new
>>> features shortly.
>>>
>> where are you thinking of putting that? how would people find it?
>>
>>> One thing I haven't done is change the name of the schema generated --
>>> it's still called "teilite" rather than "tei_lite". Easy to change if
>>> people think this is important.
>>>
>>
>> it bothers me a bit. I think, for good or bad, "teilite" is a fixed point,
>> so the ODD should be teilite.odd
>>
>> --
>> Sebastian Rahtz
>> Director (Research Support) of Academic IT Services
>> University of Oxford IT Services
>> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>>
>> S?lo le pido a Dios
>> que el futuro no me sea indiferente
>>
>
>


From kevin.s.hawkins at ultraslavonic.info  Wed Aug  8 14:41:49 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Wed, 08 Aug 2012 14:41:49 -0400
Subject: [tei-council] Lite Final, finally
In-Reply-To: <5022B229.5070004@retired.ox.ac.uk>
References: <501FD0D9.7000806@retired.ox.ac.uk>	<08d2e388-f671-48d4-a19f-3ec01029a542@HUB02.ad.oak.ox.ac.uk>	<501FEDC3.5000109@it.ox.ac.uk>
	<5022B229.5070004@retired.ox.ac.uk>
Message-ID: <5022B2ED.7030109@ultraslavonic.info>

On 8/8/2012 2:38 PM, Lou Burnard wrote:
> Have removed teilite_ns.odd
>
> Consistency suggests:
>
> Exemplars/tei_lite.odd : canonical home of the ODD
> Exemplars/tei_lite.xml : skeletal template file, Oxygen for the use of
> tei_lite : name of schema generated
>
> This does indeed make a break with existing tradition, but that may not
> be a bad thing -- this is a new version after all, and we want people to
> know that.

I vote for renaming to include "_".  That way anyone who automatically 
loads the DTD from 
http://www.tei-c.org/release/xml/tei/custom/schema/dtd/teilite.dtd will 
notice the breakage and be clued in that we made major changes to the DTD.

At the time of the next release, we will also need to update the Lite 
links on these two pages:

http://www.tei-c.org/Guidelines/Customization/

http://www.tei-c.org/Guidelines/Customization/Lite/

I will try to remember to do this.

From kevin.s.hawkins at ultraslavonic.info  Wed Aug  8 14:43:26 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Wed, 08 Aug 2012 14:43:26 -0400
Subject: [tei-council] Lite Final, finally
In-Reply-To: <8384baad-bce4-4bb8-9b4c-7cad0ab45065@HUB01.ad.oak.ox.ac.uk>
References: <501FD0D9.7000806@retired.ox.ac.uk>	<08d2e388-f671-48d4-a19f-3ec01029a542@HUB02.ad.oak.ox.ac.uk>	<501FEDC3.5000109@it.ox.ac.uk>
	<8384baad-bce4-4bb8-9b4c-7cad0ab45065@HUB01.ad.oak.ox.ac.uk>
Message-ID: <5022B34E.1040203@ultraslavonic.info>

On 8/7/2012 6:28 PM, Sebastian Rahtz wrote:
>> Since we are *freezing* this version of TEI Lite, should it now
>> have a @source pointing to the version of the TEI in the Vault?
>
>
> are we freezing it? i didnt remember that decision.
> its frozen in the sense that it now uses @include.

See 
http://www.tei-c.org/Activities/Council/Meetings/tcm50.xml#body.1_div.1_div.2_div.2 
.

From mholmes at uvic.ca  Wed Aug  8 15:22:51 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Wed, 8 Aug 2012 12:22:51 -0700
Subject: [tei-council] Lite Final, finally
In-Reply-To: <5022B34E.1040203@ultraslavonic.info>
References: <501FD0D9.7000806@retired.ox.ac.uk>
	<08d2e388-f671-48d4-a19f-3ec01029a542@HUB02.ad.oak.ox.ac.uk>
	<501FEDC3.5000109@it.ox.ac.uk>
	<8384baad-bce4-4bb8-9b4c-7cad0ab45065@HUB01.ad.oak.ox.ac.uk>
	<5022B34E.1040203@ultraslavonic.info>
Message-ID: <5022BC8B.4090507@uvic.ca>

On 12-08-08 11:43 AM, Kevin Hawkins wrote:
> On 8/7/2012 6:28 PM, Sebastian Rahtz wrote:
>>> Since we are *freezing* this version of TEI Lite, should it now
>>> have a @source pointing to the version of the TEI in the Vault?
>>
>>
>> are we freezing it? i didnt remember that decision.
>> its frozen in the sense that it now uses @include.
>
> See
> http://www.tei-c.org/Activities/Council/Meetings/tcm50.xml#body.1_div.1_div.2_div.2
> .

We apparently didn't say very clearly what we meant. If what we meant 
was we will no longer maintain either the schemas or the prose, then we 
will need to archive the entire package (presumably somewhere outside 
the regular customization directory, because schemas in there are 
regenerated and tested), and remove its build instructions from the 
build jobs, as well as re-pointing any existing links to the new location.

+1 from me for the tei_lite naming convention, by the way.

Cheers,
Martin


-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From sebastian.rahtz at it.ox.ac.uk  Wed Aug  8 15:41:19 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Wed, 8 Aug 2012 19:41:19 +0000
Subject: [tei-council] Lite Final, finally
In-Reply-To: <5022B229.5070004@retired.ox.ac.uk>
References: <501FD0D9.7000806@retired.ox.ac.uk>
	<08d2e388-f671-48d4-a19f-3ec01029a542@HUB02.ad.oak.ox.ac.uk>
	<501FEDC3.5000109@it.ox.ac.uk> <5022B229.5070004@retired.ox.ac.uk>
Message-ID: <67bfd7c1-945c-4a57-8459-e18ad6b0199e@HUB05.ad.oak.ox.ac.uk>


On 8 Aug 2012, at 19:38, Lou Burnard <lou.burnard at retired.ox.ac.uk>
 wrote:
> Your votes?
> 
I vote for moving name of schema to tei_lite, but I predict
howls of protest at some point in the future

> I can happily move my test file to the Test directory, or drop it entirely.
> 
if you put in Test dir, you need a copy of lite there, or a tricksy change to Makefile

--
Sebastian Rahtz      
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431


From sebastian.rahtz at it.ox.ac.uk  Wed Aug  8 15:46:27 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Wed, 8 Aug 2012 19:46:27 +0000
Subject: [tei-council] Lite Final, finally
In-Reply-To: <5022BC8B.4090507@uvic.ca>
References: <501FD0D9.7000806@retired.ox.ac.uk>
	<08d2e388-f671-48d4-a19f-3ec01029a542@HUB02.ad.oak.ox.ac.uk>
	<501FEDC3.5000109@it.ox.ac.uk>
	<8384baad-bce4-4bb8-9b4c-7cad0ab45065@HUB01.ad.oak.ox.ac.uk>
	<5022B34E.1040203@ultraslavonic.info> <5022BC8B.4090507@uvic.ca>
Message-ID: <6D1D9F1C-8F49-47BD-8030-9A778F7B6266@it.ox.ac.uk>


On 8 Aug 2012, at 20:22, Martin Holmes <mholmes at uvic.ca>
 wrote:
>> 
>> See
>> http://www.tei-c.org/Activities/Council/Meetings/tcm50.xml#body.1_div.1_div.2_div.2
>> .
> 
> We apparently didn't say very clearly what we meant.

agreed.

"The result should be packaged and archived as a stable and unchanging resource."

Its true that if you take this literally it should be moved outside the whole build tree.
--
Sebastian Rahtz      
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431


From James.Cummings at it.ox.ac.uk  Wed Aug  8 15:54:57 2012
From: James.Cummings at it.ox.ac.uk (James Cummings)
Date: Wed, 08 Aug 2012 20:54:57 +0100
Subject: [tei-council] Lite Final, finally
In-Reply-To: <6D1D9F1C-8F49-47BD-8030-9A778F7B6266@it.ox.ac.uk>
References: <501FD0D9.7000806@retired.ox.ac.uk>
	<08d2e388-f671-48d4-a19f-3ec01029a542@HUB02.ad.oak.ox.ac.uk>
	<501FEDC3.5000109@it.ox.ac.uk>
	<8384baad-bce4-4bb8-9b4c-7cad0ab45065@HUB01.ad.oak.ox.ac.uk>
	<5022B34E.1040203@ultraslavonic.info> <5022BC8B.4090507@uvic.ca>
	<6D1D9F1C-8F49-47BD-8030-9A778F7B6266@it.ox.ac.uk>
Message-ID: <5022C411.5080701@it.ox.ac.uk>


I've added this as a topic for discussion for tomorrow's 
teleconference, with Lou's initials next to it to report on it.

If there is anything else that should be on the agenda please add 
it at:
http://wiki.tei-c.org/index.php?title=Council&action=edit&section=1

-James

On 08/08/12 20:46, Sebastian Rahtz wrote:
>
> On 8 Aug 2012, at 20:22, Martin Holmes<mholmes at uvic.ca>
>   wrote:
>>>
>>> See
>>> http://www.tei-c.org/Activities/Council/Meetings/tcm50.xml#body.1_div.1_div.2_div.2
>>> .
>>
>> We apparently didn't say very clearly what we meant.
>
> agreed.
>
> "The result should be packaged and archived as a stable and unchanging resource."
>
> Its true that if you take this literally it should be moved outside the whole build tree.
> --
> Sebastian Rahtz
> Director (Research Support) of Academic IT Services
> University of Oxford IT Services
> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>


-- 
Dr James Cummings, InfoDev,
Computing Services, University of Oxford

From James.Cummings at it.ox.ac.uk  Wed Aug  8 16:11:01 2012
From: James.Cummings at it.ox.ac.uk (James Cummings)
Date: Wed, 08 Aug 2012 21:11:01 +0100
Subject: [tei-council] TEI Council Teleconference, Thursday 9 August 2012,
	20:00 BST
Message-ID: <5022C7D5.5060703@it.ox.ac.uk>

Hi all,

For the teleconference on Thursday 9 August 2012 at 20:00 BST, 
we'll be dialling into a conferencing service run by 
economyconferencecall.com.  This should allow you to dial in 
toll-free and is using an account that is being used for the 
Board as well and the TEI-C will pay for the toll-free calls. 
(Though the cost is per call so if  you are in the same location 
as another council member, do consider sharing a 
conference/speaker phone.)

I'm not entirely sure where all of you will be on Wednesday, so 
I've retrieved the toll free numbers for:

US and Canada: 866-906-0040
France (excl. Monaco): 0-800-916-758
Germany: 0-800-182-0270
New Zealand: 0-800-446-259
Poland: 00-800-112-4271 (0.35 zloty charge)
UK: 0-800-635-0541

(If you need a different country number, please contact me asap.)

Dial the appropriate number, and then enter the access code:
4614041 followed by the # button.

You'll be asked to give your name. I'm told you can mute/unmute 
your line using *6 but have never tried it myself.

There is a draft agenda at 
http://wiki.tei-c.org/index.php/Council to which any members of 
the council can add items. Please do!

Can I have a volunteer to take minutes?

I'll be logged into skype simultaneously if people want a 
text-chat back-channel. (An alternative is the #tei-c IRC chat 
room on the chat.freenode.net server.)

-James

-- 
Dr James Cummings, researchsupport at it.ox.ac.uk
Research Support, IT Services, University of Oxford

From gabriel.bodard at kcl.ac.uk  Thu Aug  9 10:17:15 2012
From: gabriel.bodard at kcl.ac.uk (Gabriel BODARD)
Date: Thu, 9 Aug 2012 15:17:15 +0100
Subject: [tei-council] Fwd: Draft of updated XPointer schemes
In-Reply-To: <9D835FB5-6594-407A-AEEC-1B83ECB2F444@nyu.edu>
References: <9D835FB5-6594-407A-AEEC-1B83ECB2F444@nyu.edu>
Message-ID: <5023C66B.3030005@kcl.ac.uk>

Forwarded from the SOM list. I suggest we discuss this briefly at 
tonight's telecon, although if there's to be any in-depth discussion it 
might be an idea to ask Hugh to answer questions on it, as no one else 
on Council has volunteered to champion this proposal as far as I know. 
(And of us all Stuart probably had the best understanding of the details.)


-------- Original Message --------
Subject: Draft of updated XPointer schemes
Date: Wed, 8 Aug 2012 16:49:02 +0100
From: Hugh Cayless <hugh.cayless at NYU.EDU>
To: TEI-SOM at LISTSERV.BROWN.EDU <TEI-SOM at LISTSERV.BROWN.EDU>

Gabby tells me there's a Council meeting upcoming. I've got the document 
up to the point where I'd be happy to open it up for wider comment. Feel 
free to share the link 
(https://docs.google.com/document/d/1JsMA-gOGrevyY-crzHGiC7eZ8XdV5H_wFTlUGzrf20w/edit). 
Anyone can view and comment on it.

Thanks,
Hugh

/**
  * Hugh A. Cayless, Ph.D.
  * NYU Digital Library Technology Services
  * http://papyri.info
  */



From James.Cummings at it.ox.ac.uk  Thu Aug  9 11:00:51 2012
From: James.Cummings at it.ox.ac.uk (James Cummings)
Date: Thu, 09 Aug 2012 16:00:51 +0100
Subject: [tei-council] TEI ODD Meeting
Message-ID: <5023D0A3.5050106@it.ox.ac.uk>


Hi Council,

This is my initial report to Council on the the TEI ODD meeting 
after DH2012, emailed before the teleconference to save time in 
the meeting.

As you know there was a meeting of those interested in TEI ODD 
who happened to be going to DH2012 in Hamburg immediately after 
the conference. Partly this was because there was a panel on the 
future of ODD and it made sense having such a group of people in 
one place, to ask others to join us, and discuss the future and 
possible developments for ODD.

You can see the abstract for the panel at:

http://www.dh2012.uni-hamburg.de/conference/programme/abstracts/future-developments-for-tei-odd/

And even see the panel itself as it was recorded at:
http://lecture2go.uni-hamburg.de/konferenzen/-/k/13922

Then on the Saturday and Sunday after the conference instead of 
going on excursions a hearty band of people including:

Brett Barney, Syd Bauman, Piotr Banski, Lou Burnard, James 
Cummings, Bertrand Gaiffe, Stefan Majewski, Trevor Mu?oz, Brian 
Pytlik Zillig, Doug Reside, Raffaele Viglianti, Ron Van den 
Branden, Peter Stadler, Sebastian Rahtz, Laurent Romary (skype)

sat in a room together and discussed a variety of ODD-related 
topics. I will be coming up with a fuller report and converting 
any proposals to SF tickets in time for the face2face meeting. 
Sebastian's comments on the take-home messages for him were:
    * ODD2 has life in it. we don't need to consider an 
incompatible ODD3 at this stage
    * we _badly_ need that new Roma implementation
    * it probably _is_ possible to replace the dependency on 
RELAX NG with a new set of elements, needs proof of concept
    * the use of <specGrp> and <specGrpRef> is not well-enough 
understood, but can be a powerful technique
    * locally scoped changes are in theory possible, but it needs 
much more thought
    * the Gaiffe Manoeuvre should be formalized, possibly with a 
new attribute or element, as it is clever. I think it justifies 
an element cloning method
    * chaining of ODDS is an interesting technique which needs 
some examples and experiments

You can see these and many more interesting partly-formed 
thoughts and experiments in a set of haphazard notes that we took 
at: http://tinyurl.com/odd-dev-dh2012 which is open to commenting 
by the world if you wish.

All in all I think the meeting was a success and has created some 
suggestions for where ODD might go in the future.

Best,
James

-- 
Dr James Cummings, researchsupport at it.ox.ac.uk
Research Support, IT Services, University of Oxford

From mholmes at uvic.ca  Thu Aug  9 11:11:45 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Thu, 9 Aug 2012 08:11:45 -0700
Subject: [tei-council] Problem with the TEI site?
Message-ID: <5023D331.4010801@uvic.ca>

The TEI website drop-down menu "Guidelines" is showing some garbage 
characters at the beginning of the "Table of Contents" link (Firefox on 
Ubuntu 12.04). Does everyone else see the same thing?

Cheers,
Martin
-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From kevin.s.hawkins at ultraslavonic.info  Thu Aug  9 11:17:51 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Thu, 09 Aug 2012 11:17:51 -0400
Subject: [tei-council] Problem with the TEI site?
In-Reply-To: <5023D331.4010801@uvic.ca>
References: <5023D331.4010801@uvic.ca>
Message-ID: <5023D49F.1080804@ultraslavonic.info>

I previously saw this but don't know.  It's the dash character not being 
handled with the proper character encoding.  Sebastian, David Sewell, 
and I were working through it, and I thought we had fixed it.  Can you 
point to a specific page that is showing like that?

Also, I notice that at

http://www.tei-c.org/release/doc/tei-p5-doc/en/html/index-toc.html

none of the menus are dropping down for me.  :(

On 8/9/2012 11:11 AM, Martin Holmes wrote:
> The TEI website drop-down menu "Guidelines" is showing some garbage
> characters at the beginning of the "Table of Contents" link (Firefox on
> Ubuntu 12.04). Does everyone else see the same thing?
>
> Cheers,
> Martin

From James.Cummings at it.ox.ac.uk  Thu Aug  9 11:17:53 2012
From: James.Cummings at it.ox.ac.uk (James Cummings)
Date: Thu, 09 Aug 2012 16:17:53 +0100
Subject: [tei-council] Problem with the TEI site?
In-Reply-To: <5023D331.4010801@uvic.ca>
References: <5023D331.4010801@uvic.ca>
Message-ID: <5023D4A1.8080206@it.ox.ac.uk>

On 09/08/12 16:11, Martin Holmes wrote:
> The TEI website drop-down menu "Guidelines" is showing some garbage
> characters at the beginning of the "Table of Contents" link (Firefox on
> Ubuntu 12.04). Does everyone else see the same thing?

Looks fine to me. I see an  em-dash / hyphen of some sort before 
Table of Contents.

-James

-- 
Dr James Cummings, researchsupport at it.ox.ac.uk
Research Support, IT Services, University of Oxford

From James.Cummings at it.ox.ac.uk  Thu Aug  9 11:19:17 2012
From: James.Cummings at it.ox.ac.uk (James Cummings)
Date: Thu, 09 Aug 2012 16:19:17 +0100
Subject: [tei-council] Problem with the TEI site?
In-Reply-To: <5023D49F.1080804@ultraslavonic.info>
References: <5023D331.4010801@uvic.ca> <5023D49F.1080804@ultraslavonic.info>
Message-ID: <5023D4F5.4010004@it.ox.ac.uk>

On 09/08/12 16:17, Kevin Hawkins wrote:
> Also, I notice that at
>
> http://www.tei-c.org/release/doc/tei-p5-doc/en/html/index-toc.html
>
> none of the menus are dropping down for me.  :(

Same for me on all guidelines-generated pages. At least in Chrome.

-James


-- 
Dr James Cummings, researchsupport at it.ox.ac.uk
Research Support, IT Services, University of Oxford

From dsewell at virginia.edu  Thu Aug  9 11:20:03 2012
From: dsewell at virginia.edu (David Sewell)
Date: Thu, 9 Aug 2012 11:20:03 -0400 (EDT)
Subject: [tei-council] Problem with the TEI site?
In-Reply-To: <5023D331.4010801@uvic.ca>
References: <5023D331.4010801@uvic.ca>
Message-ID: <alpine.OSX.2.00.1208091118580.32309@lister.ei.virginia.edu>

Nope. I think it's probably an en-dash there (U+2013). If you are seeing 
garbage, it sounds like bad browser character set choice. The server is sending 
UTF-8 as the page encoding.

On Thu, 9 Aug 2012, Martin Holmes wrote:

> The TEI website drop-down menu "Guidelines" is showing some garbage
> characters at the beginning of the "Table of Contents" link (Firefox on
> Ubuntu 12.04). Does everyone else see the same thing?
>
> Cheers,
> Martin
>

-- 
David Sewell, Editorial and Technical Manager
ROTUNDA, The University of Virginia Press
PO Box 400314, Charlottesville, VA 22904-4314 USA
Email: dsewell at virginia.edu   Tel: +1 434 924 9973
Web: http://rotunda.upress.virginia.edu/

From lou.burnard at retired.ox.ac.uk  Thu Aug  9 11:20:07 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Thu, 09 Aug 2012 16:20:07 +0100
Subject: [tei-council] Problem with the TEI site?
In-Reply-To: <5023D49F.1080804@ultraslavonic.info>
References: <5023D331.4010801@uvic.ca> <5023D49F.1080804@ultraslavonic.info>
Message-ID: <5023D527.4060504@retired.ox.ac.uk>

On 09/08/12 16:17, Kevin Hawkins wrote:

> Also, I notice that at
>
> http://www.tei-c.org/release/doc/tei-p5-doc/en/html/index-toc.html
>
> none of the menus are dropping down for me.  :(

for me they all work (i.e. drop down) except the last two "news" amd 
"online store"


From dsewell at virginia.edu  Thu Aug  9 11:21:06 2012
From: dsewell at virginia.edu (David Sewell)
Date: Thu, 9 Aug 2012 11:21:06 -0400 (EDT)
Subject: [tei-council] Problem with the TEI site?
In-Reply-To: <5023D527.4060504@retired.ox.ac.uk>
References: <5023D331.4010801@uvic.ca> <5023D49F.1080804@ultraslavonic.info>
	<5023D527.4060504@retired.ox.ac.uk>
Message-ID: <alpine.OSX.2.00.1208091120530.32350@lister.ei.virginia.edu>

"News" and "Online Store" are just links, no drop-down.

On Thu, 9 Aug 2012, Lou Burnard wrote:

> On 09/08/12 16:17, Kevin Hawkins wrote:
>
>> Also, I notice that at
>>
>> http://www.tei-c.org/release/doc/tei-p5-doc/en/html/index-toc.html
>>
>> none of the menus are dropping down for me.  :(
>
> for me they all work (i.e. drop down) except the last two "news" amd
> "online store"
>
>

-- 
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 mholmes at uvic.ca  Thu Aug  9 12:24:54 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Thu, 9 Aug 2012 09:24:54 -0700
Subject: [tei-council] Problem with the TEI site?
In-Reply-To: <5023D49F.1080804@ultraslavonic.info>
References: <5023D331.4010801@uvic.ca> <5023D49F.1080804@ultraslavonic.info>
Message-ID: <5023E456.50604@uvic.ca>

This is the page where I saw the problem:

<http://www.tei-c.org/release/doc/tei-p5-doc/en/html/index-toc.html>

I suspect it was generated during the last release build of the Glines, 
and so any changes you made to the current setup might not have been 
inherited by it. Could that be it?

I do see drop-down menus on the page below.

Cheers,
Martin

On 12-08-09 08:17 AM, Kevin Hawkins wrote:
> I previously saw this but don't know.  It's the dash character not being
> handled with the proper character encoding.  Sebastian, David Sewell,
> and I were working through it, and I thought we had fixed it.  Can you
> point to a specific page that is showing like that?
>
> Also, I notice that at
>
> http://www.tei-c.org/release/doc/tei-p5-doc/en/html/index-toc.html
>
> none of the menus are dropping down for me.  :(
>
> On 8/9/2012 11:11 AM, Martin Holmes wrote:
>> The TEI website drop-down menu "Guidelines" is showing some garbage
>> characters at the beginning of the "Table of Contents" link (Firefox on
>> Ubuntu 12.04). Does everyone else see the same thing?
>>
>> Cheers,
>> Martin

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From rwelzenbach at gmail.com  Thu Aug  9 12:27:00 2012
From: rwelzenbach at gmail.com (Rebecca Welzenbach)
Date: Thu, 9 Aug 2012 12:27:00 -0400
Subject: [tei-council] Third-person vs. First-person in the Guidelines
In-Reply-To: <502130F2.8020300@retired.ox.ac.uk>
References: <CAA2irtLCMqeBcFz5nQh+7ec=FHk4_+kwoh-qgAPwQAE0CmOoVg@mail.gmail.com>
	<501FE424.50200@retired.ox.ac.uk>
	<F2EF032F-F9E1-458D-AEE1-F262E10347CA@unl.edu>
	<502130F2.8020300@retired.ox.ac.uk>
Message-ID: <CAA2irtKc_HrKxUAa6Dd+4ot6SqEdAiaSAkWJozmhO_i3iNHgEQ@mail.gmail.com>

Thanks, all, for your feedback--I like Lou's test for determining when
"we" is appropriate. I'll also add a note about generally avoiding
imperatives.

Talk to you soon!
Becky

On Tue, Aug 7, 2012 at 11:14 AM, Lou Burnard
<lou.burnard at retired.ox.ac.uk> wrote:
> On 07/08/12 15:19, Brett Barney wrote:
>>
>
>> I hadn't consciously articulated it this way, but Lou's right here, I think. And I think it's an effective construction. Of the examples Rebecca gives from chapter 1, the last is an exception:
>>
>> * "We do not describe them in detail here"
>>
>
> Yes, I missed that one -- It should of course be passivized eg. "They
> are not described in detail here".
>
> The difference /test is probably to ask something like  "is the material
> being asserted -- typically a technical term or usage -- something that
> the reader is expected to internalise and use themselves thereafter or
> during the exposition?" If so, use "we"; otherwise consider
> passivization, err, passivizationing is to be considered appropriate.
>
>
> --
> 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 dsewell at virginia.edu  Thu Aug  9 12:42:03 2012
From: dsewell at virginia.edu (David Sewell)
Date: Thu, 9 Aug 2012 12:42:03 -0400 (EDT)
Subject: [tei-council] Problem with the TEI site?
In-Reply-To: <5023E456.50604@uvic.ca>
References: <5023D331.4010801@uvic.ca> <5023D49F.1080804@ultraslavonic.info>
	<5023E456.50604@uvic.ca>
Message-ID: <alpine.OSX.2.00.1208091238260.32692@lister.ei.virginia.edu>

Ah, I see, you're right.

The HTML for the Guidelines pages is pulled in from static HTML files, generated 
as part of the TEI release process. On tei-c.org, the file in question does have 
the correct META element in the head:

<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />

but the content for the drop-down itself contains buggy text, namely

    ???&#128;&#147; Table of Contents

So... Sebastian, maybe you can check to find out where those dropdown menus 
exist as variables in the XSLT, and see if there is a character set problem?

David

On Thu, 9 Aug 2012, Martin Holmes wrote:

> This is the page where I saw the problem:
>
> <http://www.tei-c.org/release/doc/tei-p5-doc/en/html/index-toc.html>
>
> I suspect it was generated during the last release build of the Glines,
> and so any changes you made to the current setup might not have been
> inherited by it. Could that be it?
>
> I do see drop-down menus on the page below.
>
> Cheers,
> Martin
>
> On 12-08-09 08:17 AM, Kevin Hawkins wrote:
>> I previously saw this but don't know.  It's the dash character not being
>> handled with the proper character encoding.  Sebastian, David Sewell,
>> and I were working through it, and I thought we had fixed it.  Can you
>> point to a specific page that is showing like that?
>>
>> Also, I notice that at
>>
>> http://www.tei-c.org/release/doc/tei-p5-doc/en/html/index-toc.html
>>
>> none of the menus are dropping down for me.  :(
>>
>> On 8/9/2012 11:11 AM, Martin Holmes wrote:
>>> The TEI website drop-down menu "Guidelines" is showing some garbage
>>> characters at the beginning of the "Table of Contents" link (Firefox on
>>> Ubuntu 12.04). Does everyone else see the same thing?
>>>
>>> Cheers,
>>> Martin
>
>

-- 
David Sewell, Editorial and Technical Manager
ROTUNDA, The University of Virginia Press
PO Box 400314, Charlottesville, VA 22904-4314 USA
Email: dsewell at virginia.edu   Tel: +1 434 924 9973
Web: http://rotunda.upress.virginia.edu/

From kevin.s.hawkins at ultraslavonic.info  Thu Aug  9 12:54:36 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Thu, 09 Aug 2012 12:54:36 -0400
Subject: [tei-council] Problem with the TEI site?
In-Reply-To: <5023E456.50604@uvic.ca>
References: <5023D331.4010801@uvic.ca> <5023D49F.1080804@ultraslavonic.info>
	<5023E456.50604@uvic.ca>
Message-ID: <5023EB4C.5010503@ultraslavonic.info>

Seems to be a Chrome problem ...

On 8/9/2012 12:24 PM, Martin Holmes wrote:
> I do see drop-down menus on the page below.

> On 12-08-09 08:17 AM, Kevin Hawkins wrote:
>> Also, I notice that at
>>
>> http://www.tei-c.org/release/doc/tei-p5-doc/en/html/index-toc.html
>>
>> none of the menus are dropping down for me. :(

From sebastian.rahtz at it.ox.ac.uk  Thu Aug  9 12:57:49 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Thu, 9 Aug 2012 16:57:49 +0000
Subject: [tei-council] Problem with the TEI site?
In-Reply-To: <alpine.OSX.2.00.1208091238260.32692@lister.ei.virginia.edu>
References: <5023D331.4010801@uvic.ca> <5023D49F.1080804@ultraslavonic.info>
	<5023E456.50604@uvic.ca>
	<alpine.OSX.2.00.1208091238260.32692@lister.ei.virginia.edu>
Message-ID: <02F67854-3D9C-4E07-A437-0BC9872324F9@it.ox.ac.uk>

we've been here before.  all that stuff is added in by grabbing a portion of the current website
and inserting the HTML. the encoding was not being kept, but was fixed in the build script on June 26th

it won't be visible in public until we make a new release.
--
Sebastian Rahtz      
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431


From sebastian.rahtz at it.ox.ac.uk  Thu Aug  9 12:59:24 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Thu, 9 Aug 2012 16:59:24 +0000
Subject: [tei-council] utf-8 decl in TEI web pages
In-Reply-To: <5023EBCC.4040307@ultraslavonic.info>
References: <78D1A97C-E664-4E18-B3FB-406E705B2E98@oucs.ox.ac.uk>
	<alpine.OSX.2.00.1206262151001.725@betwix.local>
	<DF13C20D-725A-4F36-AE59-96BA76CC5CD6@oucs.ox.ac.uk>
	<alpine.OSX.2.00.1206270952300.78414@lister.ei.virginia.edu>
	<5023EBCC.4040307@ultraslavonic.info>
Message-ID: <283DE005-1D66-4C24-A17D-C5A0572C31B2@it.ox.ac.uk>

for the nerds amongst us, here is what we do now

curl -s http://www.tei-c.org/index.xml | sed 's/content="text\/html"/content="text\/html; charset=utf-8"/' | xmllint --html --noent --dropdtd --xmlout - > Utilities/teic-index.xml


--
Sebastian Rahtz      
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431


From James.Cummings at it.ox.ac.uk  Thu Aug  9 13:27:01 2012
From: James.Cummings at it.ox.ac.uk (James Cummings)
Date: Thu, 09 Aug 2012 18:27:01 +0100
Subject: [tei-council] Feedback from SIGs for 2012-08-09 teleconference
Message-ID: <5023F2E5.5070808@it.ox.ac.uk>

To report to council, I emailed all of the SIG conveners
currently listed at:

http://www.tei-c.org/Activities/SIG/

Asking them to let me have either the details of the new SIG
convener (since I think the page is out of date) or any report on
SIG activities they wished to share. (I also mentioned our
meeting in September and said that they could prepare a report
for that).

The answers I got were as follows:

Correspondence SIG: Peter Stadler says:
> nothing much from the correspondence sig as well. We hope to
> regain momentum for a merging of DALF and the WeGA
> correspondence schema but would propably need some sort of
> financial support for meetings. (That's been on our agenda for
> two years now ...)

TEI for Linguists SIG: Piotr will prepare a report for September

Music SIG: Raffaele says:

> The Music SIG will be dormant for at least this members
> meeting. There are plans for the future, but I am focusing on
> the PhD more so they're likely to be slow moving. A loose
> agenda for the future is available here:
> http://wiki.tei-c.org/index.php/SIG:Music:Meeting2011


Scholarly Publishing SIG: Dan says:
> At the moment nothing much here. Largely my fault. I think
> there is a lot of interest. I don't see much in what I have
> seen to do particularly with Council meetings: most of what
> I;ve seen has to do with implementation and tools, and very
> little with actual syntax and semantics.


Libraries: Kevin will deliver a report during the teleconference
but the highlights are:
> I'll mention a research project that Michelle and I are just
> starting on to study the use of TEI in libraries (not a SIG
> thing per se).
>
> I'll also ask Council's opinion on creating a category or
> group in SF for tickets related to incorporating parts of the
> Best Practices into P5.


I didn't hear back from Education (No Convener Listed),
Manuscripts, Ontologies, Text and Graphics, or Tools.

The board is currently re-examining how SIGs are run and
organised and thinking about changing the rules at:
http://www.tei-c.org/Activities/SIG/rules.xml

Best,
-James
-- 
Dr James Cummings, researchsupport at it.ox.ac.uk
Research Support, IT Services, University of Oxford

From gabriel.bodard at kcl.ac.uk  Thu Aug  9 13:31:38 2012
From: gabriel.bodard at kcl.ac.uk (Gabriel BODARD)
Date: Thu, 9 Aug 2012 18:31:38 +0100
Subject: [tei-council] Feedback from SIGs for 2012-08-09 teleconference
In-Reply-To: <5023F2E5.5070808@it.ox.ac.uk>
References: <5023F2E5.5070808@it.ox.ac.uk>
Message-ID: <5023F3FA.1040507@kcl.ac.uk>

On 09/08/2012 18:27, James Cummings wrote:
> The board is currently re-examining how SIGs are run and
> organised and thinking about changing the rules at:
> http://www.tei-c.org/Activities/SIG/rules.xml

I thought we had decided a couple of years ago that the management of 
SIGs should be the responsibility of Council, not the Board?

(Of course, we can *decide* that, but only the Board can decree it...)

:-)


-- 
Dr Gabriel BODARD
(Research Associate in Digital Epigraphy)

Department of Digital Humanities
King's College London
26-29 Drury Lane
London WC2B 5RL

Email: gabriel.bodard at kcl.ac.uk
Tel: +44 (0)20 7848 1388
Fax: +44 (0)20 7848 2980

http://www.digitalclassicist.org/
http://www.currentepigraphy.org/

From James.Cummings at it.ox.ac.uk  Thu Aug  9 13:43:20 2012
From: James.Cummings at it.ox.ac.uk (James Cummings)
Date: Thu, 09 Aug 2012 18:43:20 +0100
Subject: [tei-council] Feedback from SIGs for 2012-08-09 teleconference
In-Reply-To: <5023F3FA.1040507@kcl.ac.uk>
References: <5023F2E5.5070808@it.ox.ac.uk> <5023F3FA.1040507@kcl.ac.uk>
Message-ID: <5023F6B8.9030008@it.ox.ac.uk>

On 09/08/12 18:31, Gabriel BODARD wrote:
> On 09/08/2012 18:27, James Cummings wrote:
>> The board is currently re-examining how SIGs are run and
>> organised and thinking about changing the rules at:
>> http://www.tei-c.org/Activities/SIG/rules.xml
>
> I thought we had decided a couple of years ago that the management of
> SIGs should be the responsibility of Council, not the Board?
>
> (Of course, we can *decide* that, but only the Board can decree it...)
>
> :-)

Yes, if you read that rules page you'll see that a SIG 
Coordinator is to be appointed by the Council from among its 
members. I'm currently awaiting the outcome of the board 
discussion before approaching someone on Council.  A flaw in this 
system, I've suggested, is that Council members are elected for 2 
year terms. They then may get to grips with the SIGs a year into 
their term at the first members meeting since their election, and 
then only have a year to go. I'm of the opinion that it would be 
better for the Council to appoint someone *outside* of the 
Council to do this.

I would be interested in Council's views though, and htis is what 
I was going to raise in the meeting (in another hour and fifteen 
minutes from time of sending this). ;-)


-James


-- 
Dr James Cummings, researchsupport at it.ox.ac.uk
Research Support, IT Services, University of Oxford

From gabriel.bodard at kcl.ac.uk  Thu Aug  9 13:58:37 2012
From: gabriel.bodard at kcl.ac.uk (Gabriel BODARD)
Date: Thu, 9 Aug 2012 18:58:37 +0100
Subject: [tei-council] Feedback from SIGs for 2012-08-09 teleconference
In-Reply-To: <5023F6B8.9030008@it.ox.ac.uk>
References: <5023F2E5.5070808@it.ox.ac.uk> <5023F3FA.1040507@kcl.ac.uk>
	<5023F6B8.9030008@it.ox.ac.uk>
Message-ID: <5023FA4D.9010902@kcl.ac.uk>

Or I'd rather say for Council to have the option to appoint someone on 
Council or outside of it (or for that matter on Board), as some people 
have been on Council for a few years and will continue to be involved 
whether or not they are re-elected, so we're not automatically 
disqualified. (Note that I am emphatically *not* angling for said post, 
just speaking in principle.)

On 09/08/2012 18:43, James Cummings wrote:
> Yes, if you read that rules page you'll see that a SIG
> Coordinator is to be appointed by the Council from among its
> members. I'm currently awaiting the outcome of the board
> discussion before approaching someone on Council.  A flaw in this
> system, I've suggested, is that Council members are elected for 2
> year terms. They then may get to grips with the SIGs a year into
> their term at the first members meeting since their election, and
> then only have a year to go. I'm of the opinion that it would be
> better for the Council to appoint someone *outside* of the
> Council to do this.
>
> I would be interested in Council's views though, and htis is what
> I was going to raise in the meeting (in another hour and fifteen
> minutes from time of sending this). ;-)
>
>
> -James
>
>

-- 
Dr Gabriel BODARD
(Research Associate in Digital Epigraphy)

Department of Digital Humanities
King's College London
26-29 Drury Lane
London WC2B 5RL

Email: gabriel.bodard at kcl.ac.uk
Tel: +44 (0)20 7848 1388
Fax: +44 (0)20 7848 2980

http://www.digitalclassicist.org/
http://www.currentepigraphy.org/

From James.Cummings at it.ox.ac.uk  Thu Aug  9 14:01:01 2012
From: James.Cummings at it.ox.ac.uk (James Cummings)
Date: Thu, 09 Aug 2012 19:01:01 +0100
Subject: [tei-council] Feedback from SIGs for 2012-08-09 teleconference
In-Reply-To: <5023FA4D.9010902@kcl.ac.uk>
References: <5023F2E5.5070808@it.ox.ac.uk> <5023F3FA.1040507@kcl.ac.uk>
	<5023F6B8.9030008@it.ox.ac.uk> <5023FA4D.9010902@kcl.ac.uk>
Message-ID: <5023FADD.6080204@it.ox.ac.uk>


Yes, that is closer to what I meant... that the Council can 
appoint someone and that person does not have to be on the Council.

It still sounds like you're volunteering to my ears...maybe I 
should wash them.

-James

On 09/08/12 18:58, Gabriel BODARD wrote:
> Or I'd rather say for Council to have the option to appoint someone on
> Council or outside of it (or for that matter on Board), as some people
> have been on Council for a few years and will continue to be involved
> whether or not they are re-elected, so we're not automatically
> disqualified. (Note that I am emphatically *not* angling for said post,
> just speaking in principle.)
>
> On 09/08/2012 18:43, James Cummings wrote:
>> Yes, if you read that rules page you'll see that a SIG
>> Coordinator is to be appointed by the Council from among its
>> members. I'm currently awaiting the outcome of the board
>> discussion before approaching someone on Council.  A flaw in this
>> system, I've suggested, is that Council members are elected for 2
>> year terms. They then may get to grips with the SIGs a year into
>> their term at the first members meeting since their election, and
>> then only have a year to go. I'm of the opinion that it would be
>> better for the Council to appoint someone *outside* of the
>> Council to do this.
>>
>> I would be interested in Council's views though, and htis is what
>> I was going to raise in the meeting (in another hour and fifteen
>> minutes from time of sending this). ;-)
>>
>>
>> -James
>>
>>
>


-- 
Dr James Cummings, researchsupport at it.ox.ac.uk
Research Support, IT Services, University of Oxford

From mholmes at uvic.ca  Thu Aug  9 16:13:23 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Thu, 9 Aug 2012 13:13:23 -0700
Subject: [tei-council] Link to minutes of August list
Message-ID: <502419E3.8060608@uvic.ca>

<http://tinyurl.com/council2012-08-09>

Please fix, tweak and enhance as appropriate.
-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From dsewell at virginia.edu  Thu Aug  9 16:50:19 2012
From: dsewell at virginia.edu (David Sewell)
Date: Thu, 9 Aug 2012 16:50:19 -0400 (EDT)
Subject: [tei-council] question about analysis (fwd)
Message-ID: <alpine.OSX.2.00.1208091647470.34799@lister.ei.virginia.edu>

I'm forwarding a query about an apparent TEI-related corpus analysis program. I 
have no clue about this--if anyone does, let me know and I will relay the reply.

If the attachment does not go through, it is also at 
http://lister.ei.virginia.edu/~drs2n/corpus.png

David

---------- Forwarded message ----------
Date: Thu, 9 Aug 2012 16:44:56 -0400
From: Loren Dent <lorendent at gmail.com>
To: info at tei-c.org
Subject: question about analysis

Hi,

I'm attaching a screenshot of some program used to analyze a metaphor corpus 
that was done through tei-c by a group from Amsterdam.  Do you recognize the 
program?  And if so, could you give me some guidance on how to access it?

Thanks!
Loren
-------------- next part --------------
A non-text attachment was scrubbed...
Name: corpus.png
Type: image/png
Size: 162694 bytes
Desc: 
Url : http://lists.village.Virginia.EDU/pipermail/tei-council/attachments/20120809/27be4413/attachment-0001.png 

From james.cummings at it.ox.ac.uk  Thu Aug  9 17:25:51 2012
From: james.cummings at it.ox.ac.uk (James Cummings)
Date: Thu, 9 Aug 2012 21:25:51 +0000
Subject: [tei-council] question about analysis (fwd)
In-Reply-To: <alpine.OSX.2.00.1208091647470.34799@lister.ei.virginia.edu>
References: <alpine.OSX.2.00.1208091647470.34799@lister.ei.virginia.edu>
Message-ID: <si64gy2r98jxfhgub9q4vlma.1344547550177@email.android.com>



I was involved in this project, I'm guessing, as we did work for people marking up metaphors in the BNC.

I'll contact those involved off list.

Jamesc
--
James Cummings, Research Support, IT Services, University of Oxford (from phone)

David Sewell <dsewell at virginia.edu> wrote:


I'm forwarding a query about an apparent TEI-related corpus analysis program. I
have no clue about this--if anyone does, let me know and I will relay the reply.

If the attachment does not go through, it is also at
http://lister.ei.virginia.edu/~drs2n/corpus.png

David

---------- Forwarded message ----------
Date: Thu, 9 Aug 2012 16:44:56 -0400
From: Loren Dent <lorendent at gmail.com>
To: info at tei-c.org
Subject: question about analysis

Hi,

I'm attaching a screenshot of some program used to analyze a metaphor corpus
that was done through tei-c by a group from Amsterdam.  Do you recognize the
program?  And if so, could you give me some guidance on how to access it?

Thanks!
Loren

From mholmes at uvic.ca  Thu Aug  9 19:30:53 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Thu, 9 Aug 2012 16:30:53 -0700
Subject: [tei-council] Options for freezing and/or archiving Lite
Message-ID: <5024482D.1060307@uvic.ca>

Following our telco today, I was tasked with starting the conversation 
about what we mean by whatever it was we decided to do with Lite at Ann 
Arbor. This has been variously referred to as archiving, retiring, or 
freezing. Here are some of the options as I see them:

1. Full archiving (no more development, no more building, no more 
changes, no more testing):

	Lite would be compiled and released as normal with the next release, so 
it would end up in the Vault for that release. Following that, it would 
be removed from the development trunk, and all links to it would point 
to the Vault version. The Lite ODD file <schemaSpec> would be linked to 
the version of P5 it was compiled with.

	Advantages:
		- Lite would be a fixed, known quantity.
		- We would not have to do anything at all with it from that point.

	Disadvantages:
		- We could not respond to any requests for updates, no matter how 
useful they might be.
		- The Lite ODD file might not continue to "work"; although it would be 
hard-linked to its release version, subsequent changes in the ODD spec, 
the build process, or the ODD processing behaviour could break it, so 
people trying to customize it might have problems.

2. Freezing (no more development, but Lite continues to be built and 
tested as part of the build process, and remains in trunk and in the 
release package):

	Lite would be compiled and released with every release. It's not clear 
whether it would be hard-linked to the P5 version in force at the time 
of the freeze or not; there are advantages and disadvantages each way. 
Bugs emerging out of testing would be fixed, but no other development 
would take place, no matter how apparently attractive the suggestions 
might be.

	Advantages:
		- Not much work for Council.
		- Lite remains functional and people should still be able to create 
their own customizations of it.

	Disadvantages:
		- We appear to be continuing to "maintain" it, so we will be subject 
to pressure to implement feature requests, especially when useful new 
features are added to trunk which people would like to see in Lite.

3. Active maintenance (no active development except where there are 
strong arguments in favour, but Lite is actively built and released as 
normal):

	What happens now would continue to happen, and we would respond to bug 
reports and entertain feature requests, although we would try to resist 
acting on the latter.

	Advantages:
		- Lite users are presumably happy because their customization is 
actively maintained.

	Disadvantages:
		- More work for Council.


Does anyone see other possible scenarios?

Cheers,
Martin
-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From kevin.s.hawkins at ultraslavonic.info  Thu Aug  9 22:24:54 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Thu, 09 Aug 2012 22:24:54 -0400
Subject: [tei-council] Fwd: Re: Google Books > TEI
In-Reply-To: <4FEC843B.9040308@uvic.ca>
References: <CAHScxsVJ4-UfSOnZK-rGH6qYVWQHyEhe6yxRtHuF6kxctCQ+=w@mail.gmail.com>
	<4FEBD9C0.4030201@ultraslavonic.info> <4FEC843B.9040308@uvic.ca>
Message-ID: <502470F6.8010508@ultraslavonic.info>

We agreed at today's meeting that I would remind you all to consult my 
emails from 28 June to see sample TEI books created by Google.  A number 
of people have expressed feedback in reviewing the samples.

I see now that no one answered Martin's question on this thread ...

On 6/28/12 12:20 PM, Martin Holmes wrote:
> Does anyone have any experience in calculating the accuracy of OCR and
> automated markup? Do we do errors-per-page? Is a word either wrong or
> right, or do we count errors inside words? Do we count missing or
> misplaced column or page breaks as errors?
>
> Presumably we'll need to create "perfect" hand-crafted versions of a set
> of sample pages in order to do the accuracy calculation. How many do we
> need to get a reasonable sample?

Paul has extensive documentation on error rates for double-keyboarded 
text: http://www.textcreationpartnership.org/docs/errors/errors1.html . 
  Nothing else comes to mind in that area.

Still, I don't think we should worry about the OCR accuracy.  There are 
a couple of reasons for this:

1) Google keeps reprocessing images as their OCR technology improves, so 
they keep generating new OCR.

2) The processes for creating TEI are separate from the OCR processes.

So instead focus on the correct application of TEI markup.  See if there 
are things that, when compared with the page images, get misidentified. 
  For example, it might turn out that their heuristics for identifying 
block quotes assume a wider indentation of the text than found in 
certain books, leading such blockquotes to be missed.

All of this means you basically have to skim markup and look for oddities.

From James.Cummings at it.ox.ac.uk  Fri Aug 10 09:47:10 2012
From: James.Cummings at it.ox.ac.uk (James Cummings)
Date: Fri, 10 Aug 2012 14:47:10 +0100
Subject: [tei-council] minutes
Message-ID: <502510DE.9020600@it.ox.ac.uk>

Hi all,

A quick reminder to go and check through the minutes of our 
teleconference at
http://tinyurl.com/council2012-08-09
before 5pm tonight EST.

-James
-- 
Dr James Cummings, researchsupport at it.ox.ac.uk
Research Support, IT Services, University of Oxford

From gabriel.bodard at kcl.ac.uk  Fri Aug 10 11:04:03 2012
From: gabriel.bodard at kcl.ac.uk (Gabriel BODARD)
Date: Fri, 10 Aug 2012 16:04:03 +0100
Subject: [tei-council] minutes
In-Reply-To: <502510DE.9020600@it.ox.ac.uk>
References: <502510DE.9020600@it.ox.ac.uk>
Message-ID: <502522E3.3010401@kcl.ac.uk>

I would suggest changing the language in the report of the discussion of 
the XPointer proposal to be a bit less insulting. Hugh put together this 
proposal in his own time, *having been requested to do so by Council* , 
and has as yet received no feedback on it via the SOM list where he 
circulated it a few days ago. Having the permanent record of the Council 
meeting label it "pointless" (even with a question mark) seems to me 
highly disrespectful of that effort.

On 10/08/2012 14:47, James Cummings wrote:
> Hi all,
>
> A quick reminder to go and check through the minutes of our
> teleconference at
> http://tinyurl.com/council2012-08-09
> before 5pm tonight EST.
>
> -James
>

-- 
Dr Gabriel BODARD
(Research Associate in Digital Epigraphy)

Department of Digital Humanities
King's College London
26-29 Drury Lane
London WC2B 5RL

Email: gabriel.bodard at kcl.ac.uk
Tel: +44 (0)20 7848 1388
Fax: +44 (0)20 7848 2980

http://www.digitalclassicist.org/
http://www.currentepigraphy.org/

From James.Cummings at it.ox.ac.uk  Fri Aug 10 11:32:00 2012
From: James.Cummings at it.ox.ac.uk (James Cummings)
Date: Fri, 10 Aug 2012 16:32:00 +0100
Subject: [tei-council] minutes
In-Reply-To: <502522E3.3010401@kcl.ac.uk>
References: <502510DE.9020600@it.ox.ac.uk> <502522E3.3010401@kcl.ac.uk>
Message-ID: <50252970.405@it.ox.ac.uk>


Apologies to Hugh, the 'pointless' was meant as a joke since it 
is about XPointers.. pointing, pointless... oh never mind. 
You're right, it isn't fair, and I've already changed the minutes 
(and included a link to the proposal).

-James

On 10/08/12 16:04, Gabriel BODARD wrote:
> I would suggest changing the language in the report of the discussion of
> the XPointer proposal to be a bit less insulting. Hugh put together this
> proposal in his own time, *having been requested to do so by Council* ,
> and has as yet received no feedback on it via the SOM list where he
> circulated it a few days ago. Having the permanent record of the Council
> meeting label it "pointless" (even with a question mark) seems to me
> highly disrespectful of that effort.
>
> On 10/08/2012 14:47, James Cummings wrote:
>> Hi all,
>>
>> A quick reminder to go and check through the minutes of our
>> teleconference at
>> http://tinyurl.com/council2012-08-09
>> before 5pm tonight EST.
>>
>> -James
>>
>


-- 
Dr James Cummings, researchsupport at it.ox.ac.uk
Research Support, IT Services, University of Oxford

From mholmes at uvic.ca  Fri Aug 10 11:55:07 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Fri, 10 Aug 2012 08:55:07 -0700
Subject: [tei-council] minutes
In-Reply-To: <502522E3.3010401@kcl.ac.uk>
References: <502510DE.9020600@it.ox.ac.uk> <502522E3.3010401@kcl.ac.uk>
Message-ID: <50252EDB.7000605@uvic.ca>

Agreed. This is exactly why I don't really want to be the point person 
on this topic. I really don't want to insult anyone, and I appreciate 
the really hard work Hugh has put into this, but I can't get behind it. 
I shouldn't have said anything, really, but since you couldn't connect 
to the telco I was the only one.

That being said, you've now left a permanent record of this issue in the 
public Council list. :-)

Cheers,
Martin

On 12-08-10 08:04 AM, Gabriel BODARD wrote:
> I would suggest changing the language in the report of the discussion of
> the XPointer proposal to be a bit less insulting. Hugh put together this
> proposal in his own time, *having been requested to do so by Council* ,
> and has as yet received no feedback on it via the SOM list where he
> circulated it a few days ago. Having the permanent record of the Council
> meeting label it "pointless" (even with a question mark) seems to me
> highly disrespectful of that effort.
>
> On 10/08/2012 14:47, James Cummings wrote:
>> Hi all,
>>
>> A quick reminder to go and check through the minutes of our
>> teleconference at
>> http://tinyurl.com/council2012-08-09
>> before 5pm tonight EST.
>>
>> -James
>>
>

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From mholmes at uvic.ca  Fri Aug 10 12:58:51 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Fri, 10 Aug 2012 09:58:51 -0700
Subject: [tei-council] Target of links in Guidelines generation
Message-ID: <50253DCB.3060805@uvic.ca>

Hi all,

I regularly use the "last successful build" version of the guidelines 
provided by our jenkins servers to see the current state of the glines, 
and I occasionally point other people to it. One thing that's a bit 
annoying when you do that is that links in the reference pages are 
generated hard-coded to the release version of the glines on the TEI 
site. So if you go here:

<http://teijenkins.hcmc.uvic.ca:8080/job/TEIP5-Documentation/lastSuccessfulBuild/artifact/Guidelines-web/en/html/ref-variantEncoding.html>

you'll see that the link to the relevant chapter dealing with 
<variantEncoding/> points to 
<http://www.tei-c.org/release/doc/tei-p5-doc/en/html/TC.html#TCAPEN>.

It would be nice if these could be turned into relative links, so that 
when you browse around the latest state of the glines, you don't find 
yourself jumping out to the release version without realizing it.

Before I start trying to figure out where and how this happens, does 
anyone think it _should_ happen? Would there be any disadvantage to 
making these links relative?

Cheers,
Martin
-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From kevin.s.hawkins at ultraslavonic.info  Fri Aug 10 15:21:57 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Fri, 10 Aug 2012 15:21:57 -0400
Subject: [tei-council] Target of links in Guidelines generation
In-Reply-To: <50253DCB.3060805@uvic.ca>
References: <50253DCB.3060805@uvic.ca>
Message-ID: <50255F55.9060106@ultraslavonic.info>

Martin probably meant to ask if anyone thinks it _shouln't_ happen.  I 
agree with him that it should.

On 8/10/2012 12:58 PM, Martin Holmes wrote:
> Hi all,
>
> I regularly use the "last successful build" version of the guidelines
> provided by our jenkins servers to see the current state of the glines,
> and I occasionally point other people to it. One thing that's a bit
> annoying when you do that is that links in the reference pages are
> generated hard-coded to the release version of the glines on the TEI
> site. So if you go here:
>
> <http://teijenkins.hcmc.uvic.ca:8080/job/TEIP5-Documentation/lastSuccessfulBuild/artifact/Guidelines-web/en/html/ref-variantEncoding.html>
>
> you'll see that the link to the relevant chapter dealing with
> <variantEncoding/>  points to
> <http://www.tei-c.org/release/doc/tei-p5-doc/en/html/TC.html#TCAPEN>.
>
> It would be nice if these could be turned into relative links, so that
> when you browse around the latest state of the glines, you don't find
> yourself jumping out to the release version without realizing it.
>
> Before I start trying to figure out where and how this happens, does
> anyone think it _should_ happen? Would there be any disadvantage to
> making these links relative?
>
> Cheers,
> Martin

From mholmes at uvic.ca  Fri Aug 10 16:26:57 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Fri, 10 Aug 2012 13:26:57 -0700
Subject: [tei-council] Target of links in Guidelines generation
In-Reply-To: <50255F55.9060106@ultraslavonic.info>
References: <50253DCB.3060805@uvic.ca> <50255F55.9060106@ultraslavonic.info>
Message-ID: <50256E91.8030206@uvic.ca>

Sorry, I expressed myself really stupidly there. What I meant was:

"I'm surprised that these hard-coded links appear, and I think they 
should be relative instead, but perhaps there's a reason they're done 
like that -- if you know of one, let me know."

I've found lots of places in the XSLT where links like this are 
constructed. I see no reason why we couldn't get rid of them, but but 
maybe Sebastian or someone else is aware of a deal-breaker issue. One 
annoyance for regular users would be that if you customize the 
guidelines to build yourself a special version for your project, all the 
links will go back to the main TEI site.

Cheers,
Martin

On 12-08-10 12:21 PM, Kevin Hawkins wrote:
> Martin probably meant to ask if anyone thinks it _shouln't_ happen.  I
> agree with him that it should.
>
> On 8/10/2012 12:58 PM, Martin Holmes wrote:
>> Hi all,
>>
>> I regularly use the "last successful build" version of the guidelines
>> provided by our jenkins servers to see the current state of the glines,
>> and I occasionally point other people to it. One thing that's a bit
>> annoying when you do that is that links in the reference pages are
>> generated hard-coded to the release version of the glines on the TEI
>> site. So if you go here:
>>
>> <http://teijenkins.hcmc.uvic.ca:8080/job/TEIP5-Documentation/lastSuccessfulBuild/artifact/Guidelines-web/en/html/ref-variantEncoding.html>
>>
>> you'll see that the link to the relevant chapter dealing with
>> <variantEncoding/>  points to
>> <http://www.tei-c.org/release/doc/tei-p5-doc/en/html/TC.html#TCAPEN>.
>>
>> It would be nice if these could be turned into relative links, so that
>> when you browse around the latest state of the glines, you don't find
>> yourself jumping out to the release version without realizing it.
>>
>> Before I start trying to figure out where and how this happens, does
>> anyone think it _should_ happen? Would there be any disadvantage to
>> making these links relative?
>>
>> Cheers,
>> Martin

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From mholmes at uvic.ca  Fri Aug 10 17:07:09 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Fri, 10 Aug 2012 14:07:09 -0700
Subject: [tei-council] Dates and calendars
Message-ID: <502577FD.1070603@uvic.ca>

Hi all,

I've just been working on date/calendar issues, and I've come up against 
what looks like rather an anomaly. Our default values for @when etc. are 
this:

data.temporal.w3c =
    xsd:date
  | xsd:gYear
  | xsd:gMonth
  | xsd:gDay
  | xsd:gYearMonth
  | xsd:gMonthDay
  | xsd:time
  | xsd:dateTime

So I went to the W3C site to find out about calendar issues, and I 
discovered this:

"The ?primitive? datatypes duration, dateTime, time, date, gYearMonth, 
gMonthDay, gDay, gMonth and gYear use lexical formats inspired by [ISO 
8601]... [ISO 8601] "specifies the representation of dates in the 
proleptic Gregorian calendar and times and representations of periods of 
time". The proleptic Gregorian calendar includes dates prior to 1582 
(the year it came into use as an ecclesiastical calendar).

[...]

"gYearMonth represents a specific gregorian month in a specific 
gregorian year."

[...]

"gYear represents a gregorian calendar year."

<http://www.w3.org/TR/xmlschema-2/#date>

So what on earth are we doing when we encode something like this?

<date when="1424-02" calendar="#julian"/>

The XSD specification for @when insists that it's Gregorian, yet our 
@calendar says something different.

This is problematic, surely?

Cheers,
Martin

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From James.Cummings at it.ox.ac.uk  Sat Aug 11 09:03:48 2012
From: James.Cummings at it.ox.ac.uk (James Cummings)
Date: Sat, 11 Aug 2012 14:03:48 +0100
Subject: [tei-council] Target of links in Guidelines generation
In-Reply-To: <50256E91.8030206@uvic.ca>
References: <50253DCB.3060805@uvic.ca> <50255F55.9060106@ultraslavonic.info>
	<50256E91.8030206@uvic.ca>
Message-ID: <50265834.5010807@it.ox.ac.uk>

Martin,

I'm not aware of any deal-breaker issue, and agree with you that 
relative links would be desirable.  That doesn't mean that if you 
change them things won't break horribly, just that I'm ignorant 
of what those things might be. ;-)

-James

On 10/08/12 21:26, Martin Holmes wrote:
> Sorry, I expressed myself really stupidly there. What I meant was:
>
> "I'm surprised that these hard-coded links appear, and I think they
> should be relative instead, but perhaps there's a reason they're done
> like that -- if you know of one, let me know."
>
> I've found lots of places in the XSLT where links like this are
> constructed. I see no reason why we couldn't get rid of them, but but
> maybe Sebastian or someone else is aware of a deal-breaker issue. One
> annoyance for regular users would be that if you customize the
> guidelines to build yourself a special version for your project, all the
> links will go back to the main TEI site.
>
> Cheers,
> Martin
>
> On 12-08-10 12:21 PM, Kevin Hawkins wrote:
>> Martin probably meant to ask if anyone thinks it _shouln't_ happen.  I
>> agree with him that it should.
>>
>> On 8/10/2012 12:58 PM, Martin Holmes wrote:
>>> Hi all,
>>>
>>> I regularly use the "last successful build" version of the guidelines
>>> provided by our jenkins servers to see the current state of the glines,
>>> and I occasionally point other people to it. One thing that's a bit
>>> annoying when you do that is that links in the reference pages are
>>> generated hard-coded to the release version of the glines on the TEI
>>> site. So if you go here:
>>>
>>> <http://teijenkins.hcmc.uvic.ca:8080/job/TEIP5-Documentation/lastSuccessfulBuild/artifact/Guidelines-web/en/html/ref-variantEncoding.html>
>>>
>>> you'll see that the link to the relevant chapter dealing with
>>> <variantEncoding/>   points to
>>> <http://www.tei-c.org/release/doc/tei-p5-doc/en/html/TC.html#TCAPEN>.
>>>
>>> It would be nice if these could be turned into relative links, so that
>>> when you browse around the latest state of the glines, you don't find
>>> yourself jumping out to the release version without realizing it.
>>>
>>> Before I start trying to figure out where and how this happens, does
>>> anyone think it _should_ happen? Would there be any disadvantage to
>>> making these links relative?
>>>
>>> Cheers,
>>> Martin
>


-- 
Dr James Cummings, researchsupport at it.ox.ac.uk
Research Support, IT Services, University of Oxford

From kevin.s.hawkins at ultraslavonic.info  Sun Aug 12 10:48:13 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Sun, 12 Aug 2012 10:48:13 -0400
Subject: [tei-council] TEI deprecation practices
In-Reply-To: <501FECB6.50101@it.ox.ac.uk>
References: <501D894E.3030504@ultraslavonic.info> <501EAFD3.6030703@uvic.ca>
	<501FECB6.50101@it.ox.ac.uk>
Message-ID: <5027C22D.6020307@ultraslavonic.info>

Thanks to those who've commented so far.  I've moved the comments to

http://wiki.tei-c.org/index.php/Talk:Deprecation

so we can keep track of this conversation more clearly.  I think we 
might need to discuss this in Oxford in order to rationalize our process 
so that next time we contemplate "deprecating" something, we're all 
clear on what that entails.

K.

From lou.burnard at retired.ox.ac.uk  Sun Aug 12 12:37:19 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Sun, 12 Aug 2012 17:37:19 +0100
Subject: [tei-council] Dates and calendars
In-Reply-To: <502577FD.1070603@uvic.ca>
References: <502577FD.1070603@uvic.ca>
Message-ID: <5027DBBF.7080008@retired.ox.ac.uk>

Exactly why I argued against introducing @calendar.

The only logical thing I can see would be to impose a schematron 
constraint which says that if @calendar is present, the other 
normalizationss are not permitted.


On 10/08/12 22:07, Martin Holmes wrote:
> Hi all,
>
> I've just been working on date/calendar issues, and I've come up against
> what looks like rather an anomaly. Our default values for @when etc. are
> this:
>
> data.temporal.w3c =
>      xsd:date
>    | xsd:gYear
>    | xsd:gMonth
>    | xsd:gDay
>    | xsd:gYearMonth
>    | xsd:gMonthDay
>    | xsd:time
>    | xsd:dateTime
>
> So I went to the W3C site to find out about calendar issues, and I
> discovered this:
>
> "The ?primitive? datatypes duration, dateTime, time, date, gYearMonth,
> gMonthDay, gDay, gMonth and gYear use lexical formats inspired by [ISO
> 8601]... [ISO 8601] "specifies the representation of dates in the
> proleptic Gregorian calendar and times and representations of periods of
> time". The proleptic Gregorian calendar includes dates prior to 1582
> (the year it came into use as an ecclesiastical calendar).
>
> [...]
>
> "gYearMonth represents a specific gregorian month in a specific
> gregorian year."
>
> [...]
>
> "gYear represents a gregorian calendar year."
>
> <http://www.w3.org/TR/xmlschema-2/#date>
>
> So what on earth are we doing when we encode something like this?
>
> <date when="1424-02" calendar="#julian"/>
>
> The XSD specification for @when insists that it's Gregorian, yet our
> @calendar says something different.
>
> This is problematic, surely?
>
> Cheers,
> Martin
>


From lou.burnard at retired.ox.ac.uk  Sun Aug 12 12:43:58 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Sun, 12 Aug 2012 17:43:58 +0100
Subject: [tei-council] Options for freezing and/or archiving Lite
In-Reply-To: <5024482D.1060307@uvic.ca>
References: <5024482D.1060307@uvic.ca>
Message-ID: <5027DD4E.10400@retired.ox.ac.uk>

On 10/08/12 00:30, Martin Holmes wrote:
ons as I see them:
>
> 1. Full archiving (no more development, no more building, no more
> changes, no more testing):
>
> 	Lite would be compiled and released as normal with the next release, so
> it would end up in the Vault for that release. Following that, it would
> be removed from the development trunk, and all links to it would point
> to the Vault version. The Lite ODD file <schemaSpec> would be linked to
> the version of P5 it was compiled with.


I can live with that option, so long as Lite remains accessible. One of 
the minor concerns I have is that the term "vault" does rather suggest 
(and does currently contain) stuff which no-one needs access to in a hurry.

>
> 2. Freezing (no more development, but Lite continues to be built and
> tested as part of the build process, and remains in trunk and in the
> release package):
>
> 	Lite would be compiled and released with every release. It's not clear
> whether it would be hard-linked to the P5 version in force at the time
> of the freeze or not; there are advantages and disadvantages each way.
> Bugs emerging out of testing would be fixed, but no other development
> would take place, no matter how apparently attractive the suggestions
> might be.


I think we did agree that Lite will be hard-linked to the P5 version 
current at its time of freezing. This would be my preferred option.


>
> 3. Active maintenance (no active development except where there are
> strong arguments in favour, but Lite is actively built and released as
> normal):
>
> 	What happens now would continue to happen, and we would respond to bug
> reports and entertain feature requests, although we would try to resist
> acting on the latter.
>

I would rather not go down this route. If we want to invent a new "lite" 
let's do that, and maintain it. This one has too much historical baggage.


> Does anyone see other possible scenarios?

Well, I suppose we could just throw it away...



From kevin.s.hawkins at ultraslavonic.info  Sun Aug 12 14:32:03 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Sun, 12 Aug 2012 14:32:03 -0400
Subject: [tei-council] Options for freezing and/or archiving Lite
In-Reply-To: <5027DD4E.10400@retired.ox.ac.uk>
References: <5024482D.1060307@uvic.ca> <5027DD4E.10400@retired.ox.ac.uk>
Message-ID: <5027F6A3.8060201@ultraslavonic.info>

I think Martin has summarized the options well ...

On 8/12/12 12:43 PM, Lou Burnard wrote:
> On 10/08/12 00:30, Martin Holmes wrote:
>> 2. Freezing (no more development, but Lite continues to be built and
>> tested as part of the build process, and remains in trunk and in the
>> release package):
>>
>> 	Lite would be compiled and released with every release. It's not clear
>> whether it would be hard-linked to the P5 version in force at the time
>> of the freeze or not; there are advantages and disadvantages each way.
>> Bugs emerging out of testing would be fixed, but no other development
>> would take place, no matter how apparently attractive the suggestions
>> might be.
>
>
> I think we did agree that Lite will be hard-linked to the P5 version
> current at its time of freezing. This would be my preferred option.

... and this option sounds the best to me.  Can someone remind us what 
the disadvantages are to tying Lite to the latest P5?

From James.Cummings at it.ox.ac.uk  Sun Aug 12 15:13:10 2012
From: James.Cummings at it.ox.ac.uk (James Cummings)
Date: Sun, 12 Aug 2012 20:13:10 +0100
Subject: [tei-council] Options for freezing and/or archiving Lite
In-Reply-To: <5027DD4E.10400@retired.ox.ac.uk>
References: <5024482D.1060307@uvic.ca> <5027DD4E.10400@retired.ox.ac.uk>
Message-ID: <50280046.30103@it.ox.ac.uk>

On 12/08/12 17:43, Lou Burnard wrote:
> On 10/08/12 00:30, Martin Holmes wrote:
> ons as I see them:
>>
>> 1. Full archiving (no more development, no more building, no more
>> changes, no more testing):
> I can live with that option, so long as Lite remains accessible. One of
> the minor concerns I have is that the term "vault" does rather suggest
> (and does currently contain) stuff which no-one needs access to in a hurry.

I don't think this really is the case. The current release of P5 
is in the Vault and there is just an apache rewrite making it 
look like it is elsewhere on the site.  I think the same could be 
done with our frozen version of Lite.  It could remain at the 
same URL, just be stored in the Vault and removed from the build 
process.

> I think we did agree that Lite will be hard-linked to the P5 version
> current at its time of freezing. This would be my preferred option.

Mine as well.

>> Does anyone see other possible scenarios?
> Well, I suppose we could just throw it away...

I don't think that would be popular. ;-)

-James


-- 
Dr James Cummings, researchsupport at it.ox.ac.uk
Research Support, IT Services, University of Oxford

From James.Cummings at it.ox.ac.uk  Sun Aug 12 15:16:47 2012
From: James.Cummings at it.ox.ac.uk (James Cummings)
Date: Sun, 12 Aug 2012 20:16:47 +0100
Subject: [tei-council] Attributes without examples
Message-ID: <5028011F.4050007@it.ox.ac.uk>


One of the things that Kevin reminded me of recently was that we 
still have lots of attributes without examples:

http://wiki.tei-c.org/index.php/AttsWithoutEgs

I'm as guilty as the others who have not signed up to provide 
some, but will try to do so in the next week or two.  Any other 
suggestions? Can everyone sign up to provide some examples?

-James

-- 
Dr James Cummings, researchsupport at it.ox.ac.uk
Research Support, IT Services, University of Oxford

From kevin.s.hawkins at ultraslavonic.info  Sun Aug 12 15:22:44 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Sun, 12 Aug 2012 15:22:44 -0400
Subject: [tei-council] Attributes without examples
In-Reply-To: <5028011F.4050007@it.ox.ac.uk>
References: <5028011F.4050007@it.ox.ac.uk>
Message-ID: <50280284.1050702@ultraslavonic.info>

Besides struggling to find times for the other things I've agreed to do, 
my main problem is that I have no corpus of encoded literature to 
consult to find real examples.  So I would be creating fake ones.  While 
that's okay for some attributes, for many it's painfully obvious if it's 
faked.

Since James asked for other suggestions, what if we put out a call to 
the wider community for examples?  We could create a column in the wiki 
for the examples, filling in <pre> or <code> or whatever tag is needed 
so that people don't need to escape angle brackets before pasting.  And 
then people can drop in some and we can choose the best to insert into 
SourceForge

--K.

On 8/12/12 3:16 PM, James Cummings wrote:
>
> One of the things that Kevin reminded me of recently was that we
> still have lots of attributes without examples:
>
> http://wiki.tei-c.org/index.php/AttsWithoutEgs
>
> I'm as guilty as the others who have not signed up to provide
> some, but will try to do so in the next week or two.  Any other
> suggestions? Can everyone sign up to provide some examples?
>
> -James
>

From sebastian.rahtz at it.ox.ac.uk  Sun Aug 12 15:22:52 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Sun, 12 Aug 2012 19:22:52 +0000
Subject: [tei-council] Options for freezing and/or archiving Lite
In-Reply-To: <50280046.30103@it.ox.ac.uk>
References: <5024482D.1060307@uvic.ca> <5027DD4E.10400@retired.ox.ac.uk>
	<50280046.30103@it.ox.ac.uk>
Message-ID: <b2bdff8d-aa05-417a-82b4-5bd1345f5d7a@HUB05.ad.oak.ox.ac.uk>


On 12 Aug 2012, at 20:13, James Cummings <James.Cummings at it.ox.ac.uk>
 wrote:
> I don't think this really is the case. The current release of P5 
> is in the Vault and there is just an apache rewrite making it 
> look like it is elsewhere on the site.  I think the same could be 
> done with our frozen version of Lite.  It could remain at the 
> same URL, just be stored in the Vault and removed from the build 
> process.

um. actually, its all done with symlinks. to make the next release appear
as part of all subsequent releases would be mildly painful. Possible,
of course. Just highly misleading (IMHO).


--
Sebastian Rahtz      
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431


From mholmes at uvic.ca  Sun Aug 12 20:22:29 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Sun, 12 Aug 2012 17:22:29 -0700
Subject: [tei-council] Attributes without examples
In-Reply-To: <5028011F.4050007@it.ox.ac.uk>
References: <5028011F.4050007@it.ox.ac.uk>
Message-ID: <502848C5.5030504@uvic.ca>

The last time I took a look through these, I seem to remember coming to 
the conclusion that one situation in particular is most urgent: where 
attributes are declared in an attribute class, and none of the elements 
which are members of that attribute class have examples which illustrate 
the use of that attribute.

I'm not sure how many of these there are -- I was halfway through some 
XSLT to find out, but I got distracted. I'll try to finish that.

Cheers,
Martin

On 12-08-12 12:16 PM, James Cummings wrote:
>
> One of the things that Kevin reminded me of recently was that we
> still have lots of attributes without examples:
>
> http://wiki.tei-c.org/index.php/AttsWithoutEgs
>
> I'm as guilty as the others who have not signed up to provide
> some, but will try to do so in the next week or two.  Any other
> suggestions? Can everyone sign up to provide some examples?
>
> -James
>

From sebastian.rahtz at it.ox.ac.uk  Sun Aug 12 14:43:01 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Sun, 12 Aug 2012 18:43:01 +0000
Subject: [tei-council] Options for freezing and/or archiving Lite
In-Reply-To: <5027DD4E.10400@retired.ox.ac.uk>
References: <5024482D.1060307@uvic.ca> <5027DD4E.10400@retired.ox.ac.uk>
Message-ID: <2b593217-f9a0-4203-9bb5-459a183e319a@HUB03.ad.oak.ox.ac.uk>


On 12 Aug 2012, at 17:43, Lou Burnard <lou.burnard at retired.ox.ac.uk>
 wrote:

>> 	Lite would be compiled and released as normal with the next release, so
>> it would end up in the Vault for that release. Following that, it would
>> be removed from the development trunk, and all links to it would point
>> to the Vault version. The Lite ODD file <schemaSpec> would be linked to
>> the version of P5 it was compiled with.
> 
> 
> I can live with that option, so long as Lite remains accessible. One of 
> the minor concerns I have is that the term "vault" does rather suggest 
> (and does currently contain) stuff which no-one needs access to in a hurry.
> 
obviously it would remain accessible if you know the URL (ie by following
links from the web page. But it would not appear in eg oXYgen,
in any of the distribution stes, in Roma etc. So this would be fairly dramatic.

>> 
>> 2. Freezing (no more development, but Lite continues to be built and
>> tested as part of the build process, and remains in trunk and in the
>> release package):
>> 
>> 	Lite would be compiled and released with every release. It's not clear
>> whether it would be hard-linked to the P5 version in force at the time
>> of the freeze or not; there are advantages and disadvantages each way.
>> Bugs emerging out of testing would be fixed, but no other development
>> would take place, no matter how apparently attractive the suggestions
>> might be.
> 
> 
> I think we did agree that Lite will be hard-linked to the P5 version 
> current at its time of freezing. This would be my preferred option.

I can live with that one, but it is weird. We'd have something
in the development tree which uses everything in its current state
_except_ the source. Doesn't that look odd? We find an awful
long-standing error in the content mode of <div>, its much debated
on TEI-L, a fix is implemented with much trumpeting, and people
look for it at the next release. But one, just one, amongst the 
distributed schemas does not have the lovely fix. Will users grok
the magic distinction?
> 
> 
>> 
>> 3. Active maintenance (no active development except where there are
>> strong arguments in favour, but Lite is actively built and released as
>> normal):
>> 
>> 	What happens now would continue to happen, and we would respond to bug
>> reports and entertain feature requests, although we would try to resist
>> acting on the latter.
>> 
> 
> I would rather not go down this route. If we want to invent a new "lite" 
> let's do that, and maintain it. This one has too much historical baggage.
> 
> 
>> Does anyone see other possible scenarios?
> 
> Well, I suppose we could just throw it away...


attractive, but I am not sure what message that would send :-}

I have a pragmatic suggestion - keep Lite in full support
_until_ there is a replacement. And that could be the TEI
in Libraries set; though I have many reservations whenever
I look at that, I think the approach is correct.

Are we really prepared to have no fully supported 80/20 customization
of the TEI in circulation? if we thinks thats the right place to be,
then lets archive Lite fully in the Vault and there's an end to it; otherwise,
maintain it fully. The intermediate frozen one seems (to me)
the worst sort of vacillation.

If we opt for archiving, then we need do nothing in fact.
Lite is part of each TEI P5 release, and fully available in the
Vault.
--
Sebastian Rahtz      
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431


From James.Cummings at it.ox.ac.uk  Mon Aug 13 04:01:04 2012
From: James.Cummings at it.ox.ac.uk (James Cummings)
Date: Mon, 13 Aug 2012 09:01:04 +0100
Subject: [tei-council] Options for freezing and/or archiving Lite
In-Reply-To: <2b593217-f9a0-4203-9bb5-459a183e319a@HUB03.ad.oak.ox.ac.uk>
References: <5024482D.1060307@uvic.ca> <5027DD4E.10400@retired.ox.ac.uk>
	<2b593217-f9a0-4203-9bb5-459a183e319a@HUB03.ad.oak.ox.ac.uk>
Message-ID: <5028B440.4000906@it.ox.ac.uk>

On 12/08/12 19:43, Sebastian Rahtz wrote:
> obviously it would remain accessible if you know the URL (ie by following
> links from the web page. But it would not appear in eg oXYgen,
> in any of the distribution stes, in Roma etc. So this would be fairly dramatic.

Why would this necessarily be the case? Couldn't the build 
process copy the pre-built vault copy to the right place for the 
oxygen-tei framework?


> I have a pragmatic suggestion - keep Lite in full support
> _until_ there is a replacement. And that could be the TEI
> in Libraries set; though I have many reservations whenever
> I look at that, I think the approach is correct.

If we wanted to do that, would it be better not to have the 
Council produce this customisation but the community?  (I.e. 
Council could suggest to the Board that the Community Grants, if 
it does them, should be focussed on producing an 80/20 
customisation with documentation and examples.) Though there are 
down sides to this as well.  Or do we feel that this is something 
that should be under Council control?

> Are we really prepared to have no fully supported 80/20 customization
> of the TEI in circulation? if we thinks thats the right place to be,
> then lets archive Lite fully in the Vault and there's an end to it; otherwise,
> maintain it fully. The intermediate frozen one seems (to me)
> the worst sort of vacillation.

I'm for archiving it, but making it available in oxygen-tei and 
clearly from the website and from Roma. I don't think it is wrong 
to have something actively available but frozen and archived.

> If we opt for archiving, then we need do nothing in fact.
> Lite is part of each TEI P5 release, and fully available in the
> Vault.

We would need to rewrite the page on Lite to mention that it has 
been frozen, and inform the community (possibly soliciting 
replacements).

-James

-- 
Dr James Cummings, researchsupport at it.ox.ac.uk
Research Support, IT Services, University of Oxford

From sebastian.rahtz at it.ox.ac.uk  Mon Aug 13 04:38:31 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Mon, 13 Aug 2012 08:38:31 +0000
Subject: [tei-council] Options for freezing and/or archiving Lite
In-Reply-To: <5028B440.4000906@it.ox.ac.uk>
References: <5024482D.1060307@uvic.ca> <5027DD4E.10400@retired.ox.ac.uk>
	<2b593217-f9a0-4203-9bb5-459a183e319a@HUB03.ad.oak.ox.ac.uk>
	<5028B440.4000906@it.ox.ac.uk>
Message-ID: <459bfd59-01d9-4c60-ae45-09bcfbfb12bd@HUB02.ad.oak.ox.ac.uk>


On 13 Aug 2012, at 09:01, James Cummings <james.cummings at it.ox.ac.uk> wrote:

> On 12/08/12 19:43, Sebastian Rahtz wrote:
>> obviously it would remain accessible if you know the URL (ie by following
>> links from the web page. But it would not appear in eg oXYgen,
>> in any of the distribution stes, in Roma etc. So this would be fairly dramatic.
> 
> Why would this necessarily be the case? Couldn't the build 
> process copy the pre-built vault copy to the right place for the 
> oxygen-tei framework?

it could, yes. but surely this would be a fairly odd thing to do?
> 
> 
>> I have a pragmatic suggestion - keep Lite in full support
>> _until_ there is a replacement. And that could be the TEI
>> in Libraries set; though I have many reservations whenever
>> I look at that, I think the approach is correct.
> 
> If we wanted to do that, would it be better not to have the 
> Council produce this customisation but the community?

well, they did. the TEI in Lib is a community effort. but i think the casual user
will find the distinction fairly un-understandable.

> . I don't think it is wrong 
> to have something actively available but frozen and archived.


it all depends on the meaning of "actively available", doesn't it.

the phrase "active but frozen" seems to me to sum up why this is wrong.
--
Sebastian Rahtz      
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431


From gabriel.bodard at kcl.ac.uk  Mon Aug 13 06:16:01 2012
From: gabriel.bodard at kcl.ac.uk (Gabriel Bodard)
Date: Mon, 13 Aug 2012 11:16:01 +0100
Subject: [tei-council] Dates and calendars
In-Reply-To: <502577FD.1070603@uvic.ca>
References: <502577FD.1070603@uvic.ca>
Message-ID: <5028D3E1.80708@kcl.ac.uk>

The @calendar attribute on datable elements is defined as "indicat[ing] 
the system or calendar to which the date represented by the _content of 
this element_ belongs"; in other words the markup:

<date when="1424-02" calendar="#julian"/>

Means: "A date in the Julian calendar which corresponds to February 1424 
CE in the proleptic Gregorian calendar." If you want to encode a 
normalized version of the Julian date, the only legal way to do so is to 
use @when-custom and @datingMethod.

(This is exactly the use-case for which we introduced the whole 
http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-att.datable.custom.html 
class, of which Lou so disapproves. ;-) )

G

On 2012-08-10 22:07, Martin Holmes wrote:
> Hi all,
>
> I've just been working on date/calendar issues, and I've come up against
> what looks like rather an anomaly. Our default values for @when etc. are
> this:
>
> data.temporal.w3c =
>      xsd:date
>    | xsd:gYear
>    | xsd:gMonth
>    | xsd:gDay
>    | xsd:gYearMonth
>    | xsd:gMonthDay
>    | xsd:time
>    | xsd:dateTime
>
> So I went to the W3C site to find out about calendar issues, and I
> discovered this:
>
> "The ?primitive? datatypes duration, dateTime, time, date, gYearMonth,
> gMonthDay, gDay, gMonth and gYear use lexical formats inspired by [ISO
> 8601]... [ISO 8601] "specifies the representation of dates in the
> proleptic Gregorian calendar and times and representations of periods of
> time". The proleptic Gregorian calendar includes dates prior to 1582
> (the year it came into use as an ecclesiastical calendar).
>
> [...]
>
> "gYearMonth represents a specific gregorian month in a specific
> gregorian year."
>
> [...]
>
> "gYear represents a gregorian calendar year."
>
> <http://www.w3.org/TR/xmlschema-2/#date>
>
> So what on earth are we doing when we encode something like this?
>
> <date when="1424-02" calendar="#julian"/>
>
> The XSD specification for @when insists that it's Gregorian, yet our
> @calendar says something different.
>
> This is problematic, surely?
>
> Cheers,
> Martin
>

-- 
Dr Gabriel BODARD
(Research Associate in Digital Epigraphy)

Department of Digital Humanities
King's College London
26-29 Drury Lane
London WC2B 5RL

Email: gabriel.bodard at kcl.ac.uk
Tel: +44 (0)20 7848 1388
Fax: +44 (0)20 7848 2980

http://www.digitalclassicist.org/
http://www.currentepigraphy.org/

From lou.burnard at retired.ox.ac.uk  Mon Aug 13 07:38:27 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Mon, 13 Aug 2012 12:38:27 +0100
Subject: [tei-council] Dates and calendars
In-Reply-To: <5028D3E1.80708@kcl.ac.uk>
References: <502577FD.1070603@uvic.ca> <5028D3E1.80708@kcl.ac.uk>
Message-ID: <5028E733.3070706@retired.ox.ac.uk>

I am an eejut.  Gabby is of course completely right. (I knew I 
disapproved of something, but I misremembered what)

I wonder though whether this specific example (where @calendar is 
supplied but there is no content) shouldn't therefore trigger a 
schematron error. It doesn't make a lot of sense to say "there's a date 
in this calendar here but I'm not telling you what it is" surely?



On 13/08/12 11:16, Gabriel Bodard wrote:
> The @calendar attribute on datable elements is defined as "indicat[ing]
> the system or calendar to which the date represented by the _content of
> this element_ belongs"; in other words the markup:
>
> <date when="1424-02" calendar="#julian"/>
>
> Means: "A date in the Julian calendar which corresponds to February 1424
> CE in the proleptic Gregorian calendar." If you want to encode a
> normalized version of the Julian date, the only legal way to do so is to
> use @when-custom and @datingMethod.
>
> (This is exactly the use-case for which we introduced the whole
> http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-att.datable.custom.html
> class, of which Lou so disapproves. ;-) )
>
>


From sebastian.rahtz at it.ox.ac.uk  Mon Aug 13 08:07:25 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Mon, 13 Aug 2012 12:07:25 +0000
Subject: [tei-council] teilite vs tei_lite
Message-ID: <2E32B935-B0C0-47DD-A16A-E79EB10B55B8@it.ox.ac.uk>

As per previous discussion

The logic of the TEI build procedure means that things mess up when "tei_XX" produces "teiXX.rng",
so I have now actually changed tei_lite.odd to generate tei_lite.rng (etc) pro tem. 

if this is deemed bad, can I revert to teilite.odd producing teilite,rng? but not a mixture, please?
--
Sebastian Rahtz      
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431


From sebastian.rahtz at it.ox.ac.uk  Mon Aug 13 08:23:21 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Mon, 13 Aug 2012 12:23:21 +0000
Subject: [tei-council] local @type
Message-ID: <2C63E952-8B13-4469-A67F-1220EEEBBEBF@it.ox.ac.uk>

Now that we can locally redefine class attributes at source, I have started the experiment of making <title> and <abbr>
members of att. typed, and expressing their @type as a change to the one from the class. 

We may start to see curious side effects as we go on, so be warned. Its hard to think through
all the combinations when a local customisation comes in and does its own changes.

Obviously, shout if you think this is all a Bad Thing
--
Sebastian Rahtz      
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431


From PFSchaffner at umich.edu  Mon Aug 13 10:23:42 2012
From: PFSchaffner at umich.edu (Paul F. Schaffner)
Date: Mon, 13 Aug 2012 10:23:42 -0400 (EDT)
Subject: [tei-council] Attributes without examples
In-Reply-To: <50280284.1050702@ultraslavonic.info>
References: <5028011F.4050007@it.ox.ac.uk>
	<50280284.1050702@ultraslavonic.info>
Message-ID: <Pine.LNX.4.64.1208131020050.30010@goldenaxe.gpcc.itd.umich.edu>

On Sun, 12 Aug 2012, Kevin Hawkins wrote:

> Besides struggling to find times for the other things I've agreed to do,
> my main problem is that I have no corpus of encoded literature to
> consult to find real examples.  So I would be creating fake ones.  While
> that's okay for some attributes, for many it's painfully obvious if it's
> faked.

It is possible, of course, that some of the more obscure attributes
are used by .. no one (or used correctly by no one!).

There are a few common ones in there, however, including a few for which
I have lots of examples (mainly the three table atts, @cols, @rows, and
@role), so I grabbed those.

pfs



>
> Since James asked for other suggestions, what if we put out a call to
> the wider community for examples?  We could create a column in the wiki
> for the examples, filling in <pre> or <code> or whatever tag is needed
> so that people don't need to escape angle brackets before pasting.  And
> then people can drop in some and we can choose the best to insert into
> SourceForge
>
> --K.
>
> On 8/12/12 3:16 PM, James Cummings wrote:
>>
>> One of the things that Kevin reminded me of recently was that we
>> still have lots of attributes without examples:
>>
>> http://wiki.tei-c.org/index.php/AttsWithoutEgs
>>
>> I'm as guilty as the others who have not signed up to provide
>> some, but will try to do so in the next week or two.  Any other
>> suggestions? Can everyone sign up to provide some examples?
>>
>> -James
>>
> -- 
> tei-council mailing list
> tei-council at lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>
> PLEASE NOTE: postings to this list are publicly archived
>
>
>

--------------------------------------------------------------------
Paul Schaffner | PFSchaffner at umich.edu | http://www.umich.edu/~pfs/
316-C Hatcher Library N, Univ. of Michigan, Ann Arbor MI 48109-1190
--------------------------------------------------------------------

From lou.burnard at retired.ox.ac.uk  Mon Aug 13 10:32:44 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Mon, 13 Aug 2012 15:32:44 +0100
Subject: [tei-council] Attributes without examples
In-Reply-To: <Pine.LNX.4.64.1208131020050.30010@goldenaxe.gpcc.itd.umich.edu>
References: <5028011F.4050007@it.ox.ac.uk>
	<50280284.1050702@ultraslavonic.info>
	<Pine.LNX.4.64.1208131020050.30010@goldenaxe.gpcc.itd.umich.edu>
Message-ID: <5029100C.9040801@retired.ox.ac.uk>

On 13/08/12 15:23, Paul F. Schaffner wrote:
> On Sun, 12 Aug 2012, Kevin Hawkins wrote:
>
>> Besides struggling to find times for the other things I've agreed to do,
>> my main problem is that I have no corpus of encoded literature to
>> consult to find real examples.  So I would be creating fake ones.  While
>> that's okay for some attributes, for many it's painfully obvious if it's
>> faked.
>

There's an obvious boot-strapping problem here! If we'd confined 
ourselves to pre-existing examples of TEI-encoded texts during the 
writing of the Guidelines we wouldn't have got very far. I wonder 
whether Kevin is interpreting "real examples" rather too literally -- 
for me it means that the text being encoded is a real one, not that the 
encoding already exists. So I think it's perfectly OK (as I just did in 
fact for the Lite tutorial) to grab an example from a favourite real 
text and encode it so as to demonstrate the feature concerned.

So Kevin, I happen to know from experience that just a few minutes walk 
from your office you have a pretty interesting collecion of books!



From kevin.s.hawkins at ultraslavonic.info  Mon Aug 13 10:41:31 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Mon, 13 Aug 2012 10:41:31 -0400
Subject: [tei-council] Attributes without examples
In-Reply-To: <5029100C.9040801@retired.ox.ac.uk>
References: <5028011F.4050007@it.ox.ac.uk>	<50280284.1050702@ultraslavonic.info>	<Pine.LNX.4.64.1208131020050.30010@goldenaxe.gpcc.itd.umich.edu>
	<5029100C.9040801@retired.ox.ac.uk>
Message-ID: <5029121B.4040709@ultraslavonic.info>

Finding an example from a real text is the hard part.  Why not "pick the 
low-hanging fruit" -- and simultaneously engage the community! -- by 
giving people the opportunity to contribute examples to the TEI Guidelines?

For any attributes left, we can go digging through the library stacks.

On 8/13/2012 10:32 AM, Lou Burnard wrote:
> There's an obvious boot-strapping problem here! If we'd confined
> ourselves to pre-existing examples of TEI-encoded texts during the
> writing of the Guidelines we wouldn't have got very far. I wonder
> whether Kevin is interpreting "real examples" rather too literally --
> for me it means that the text being encoded is a real one, not that the
> encoding already exists. So I think it's perfectly OK (as I just did in
> fact for the Lite tutorial) to grab an example from a favourite real
> text and encode it so as to demonstrate the feature concerned.
>
> So Kevin, I happen to know from experience that just a few minutes walk
> from your office you have a pretty interesting collecion of books!
>
>

From lou.burnard at retired.ox.ac.uk  Mon Aug 13 10:49:50 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Mon, 13 Aug 2012 15:49:50 +0100
Subject: [tei-council] Attributes without examples
In-Reply-To: <5029121B.4040709@ultraslavonic.info>
References: <5028011F.4050007@it.ox.ac.uk>	<50280284.1050702@ultraslavonic.info>	<Pine.LNX.4.64.1208131020050.30010@goldenaxe.gpcc.itd.umich.edu>
	<5029100C.9040801@retired.ox.ac.uk>
	<5029121B.4040709@ultraslavonic.info>
Message-ID: <5029140E.2030809@retired.ox.ac.uk>

Ah well, that's a different question. By all means, let's invite 
contributions from anyone who's interested and motivated to provide 
them! But let's not impose the unrealistic requirement that they should 
be pre-existing usages of the attributes concerned.


On 13/08/12 15:41, Kevin Hawkins wrote:
> Finding an example from a real text is the hard part.  Why not "pick the
> low-hanging fruit" -- and simultaneously engage the community! -- by
> giving people the opportunity to contribute examples to the TEI Guidelines?
>
> For any attributes left, we can go digging through the library stacks.
>
> On 8/13/2012 10:32 AM, Lou Burnard wrote:
>> There's an obvious boot-strapping problem here! If we'd confined
>> ourselves to pre-existing examples of TEI-encoded texts during the
>> writing of the Guidelines we wouldn't have got very far. I wonder
>> whether Kevin is interpreting "real examples" rather too literally --
>> for me it means that the text being encoded is a real one, not that the
>> encoding already exists. So I think it's perfectly OK (as I just did in
>> fact for the Lite tutorial) to grab an example from a favourite real
>> text and encode it so as to demonstrate the feature concerned.
>>
>> So Kevin, I happen to know from experience that just a few minutes walk
>> from your office you have a pretty interesting collecion of books!
>>
>>


From James.Cummings at it.ox.ac.uk  Mon Aug 13 11:16:29 2012
From: James.Cummings at it.ox.ac.uk (James Cummings)
Date: Mon, 13 Aug 2012 16:16:29 +0100
Subject: [tei-council] deadline for ticket submission before face2face
Message-ID: <50291A4D.4050102@it.ox.ac.uk>


Hiya,

I was thinking of announcing to TEI-L that we are having a 
face2face meeting in September, and more specifically that we'll 
be looking at any tickets submitted before 2 September.  I 
thought if SIGs or others were working on proposals this might 
help spur them on to submit tickets.

Does that seem a good idea?

Lou has agreed to do an initial triage of the tickets after that 
date.

-James

-- 
Dr James Cummings, researchsupport at it.ox.ac.uk
Research Support, IT Services, University of Oxford

From James.Cummings at it.ox.ac.uk  Mon Aug 13 11:31:52 2012
From: James.Cummings at it.ox.ac.uk (James Cummings)
Date: Mon, 13 Aug 2012 16:31:52 +0100
Subject: [tei-council] Attributes without examples
In-Reply-To: <5029140E.2030809@retired.ox.ac.uk>
References: <5028011F.4050007@it.ox.ac.uk>	<50280284.1050702@ultraslavonic.info>	<Pine.LNX.4.64.1208131020050.30010@goldenaxe.gpcc.itd.umich.edu>
	<5029100C.9040801@retired.ox.ac.uk>
	<5029121B.4040709@ultraslavonic.info>
	<5029140E.2030809@retired.ox.ac.uk>
Message-ID: <50291DE8.2030607@it.ox.ac.uk>


How about a compromise, that Council try to do as many of these 
as possible before our face2face and afterwards we ask the 
community? Those without lots of tickets assigned to them on 
SourceForge should feel free to take extra attributes.

-James

On 13/08/12 15:49, Lou Burnard wrote:
> Ah well, that's a different question. By all means, let's invite
> contributions from anyone who's interested and motivated to provide
> them! But let's not impose the unrealistic requirement that they should
> be pre-existing usages of the attributes concerned.
>
>
> On 13/08/12 15:41, Kevin Hawkins wrote:
>> Finding an example from a real text is the hard part.  Why not "pick the
>> low-hanging fruit" -- and simultaneously engage the community! -- by
>> giving people the opportunity to contribute examples to the TEI Guidelines?
>>
>> For any attributes left, we can go digging through the library stacks.
>>
>> On 8/13/2012 10:32 AM, Lou Burnard wrote:
>>> There's an obvious boot-strapping problem here! If we'd confined
>>> ourselves to pre-existing examples of TEI-encoded texts during the
>>> writing of the Guidelines we wouldn't have got very far. I wonder
>>> whether Kevin is interpreting "real examples" rather too literally --
>>> for me it means that the text being encoded is a real one, not that the
>>> encoding already exists. So I think it's perfectly OK (as I just did in
>>> fact for the Lite tutorial) to grab an example from a favourite real
>>> text and encode it so as to demonstrate the feature concerned.
>>>
>>> So Kevin, I happen to know from experience that just a few minutes walk
>>> from your office you have a pretty interesting collecion of books!
>>>
>>>
>


-- 
Dr James Cummings, researchsupport at it.ox.ac.uk
Research Support, IT Services, University of Oxford

From sebastian.rahtz at it.ox.ac.uk  Mon Aug 13 12:12:57 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Mon, 13 Aug 2012 16:12:57 +0000
Subject: [tei-council] Target of links in Guidelines generation
In-Reply-To: <50253DCB.3060805@uvic.ca>
References: <50253DCB.3060805@uvic.ca>
Message-ID: <E7BE3A5B-9835-4634-B88B-E20DA2450E28@it.ox.ac.uk>

I confess, I cannot see a reason why I did it this way, so duly fixed back at base
--
Sebastian Rahtz      
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431


From mholmes at uvic.ca  Mon Aug 13 12:16:03 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Mon, 13 Aug 2012 09:16:03 -0700
Subject: [tei-council] Options for freezing and/or archiving Lite
In-Reply-To: <2b593217-f9a0-4203-9bb5-459a183e319a@HUB03.ad.oak.ox.ac.uk>
References: <5024482D.1060307@uvic.ca> <5027DD4E.10400@retired.ox.ac.uk>
	<2b593217-f9a0-4203-9bb5-459a183e319a@HUB03.ad.oak.ox.ac.uk>
Message-ID: <50292843.80700@uvic.ca>

>> I think we did agree that Lite will be hard-linked to the P5 version
>> current at its time of freezing. This would be my preferred option.
>
> I can live with that one, but it is weird. We'd have something
> in the development tree which uses everything in its current state
> _except_ the source. Doesn't that look odd? We find an awful
> long-standing error in the content mode of <div>, its much debated
> on TEI-L, a fix is implemented with much trumpeting, and people
> look for it at the next release. But one, just one, amongst the
> distributed schemas does not have the lovely fix. Will users grok
> the magic distinction?

I agree with this -- it's going to require endless explanation.

Can someone remind me why the idea of freezing Lite came up in the first 
place? It seems to me that if it's as widely used as it seems to be, 
perhaps it should be maintained or replaced.

Would it be possible to create a version of TEI Lite that is constructed 
entirely through inclusion, without any subsequent customization? Didn't 
we talk recently about having a sort of shortcut/conveniences module 
that would provide tags such as <b> and <i>? A new TEI Lite could be 
defined as consisting of the four base modules (or most of them), plus 
the convenience module. Other people could use the convenience module in 
their schemas too, if they wanted to.

Cheers,
Martin

On 12-08-12 11:43 AM, Sebastian Rahtz wrote:
>
> On 12 Aug 2012, at 17:43, Lou Burnard <lou.burnard at retired.ox.ac.uk>
>   wrote:
>
>>> 	Lite would be compiled and released as normal with the next release, so
>>> it would end up in the Vault for that release. Following that, it would
>>> be removed from the development trunk, and all links to it would point
>>> to the Vault version. The Lite ODD file <schemaSpec> would be linked to
>>> the version of P5 it was compiled with.
>>
>>
>> I can live with that option, so long as Lite remains accessible. One of
>> the minor concerns I have is that the term "vault" does rather suggest
>> (and does currently contain) stuff which no-one needs access to in a hurry.
>>
> obviously it would remain accessible if you know the URL (ie by following
> links from the web page. But it would not appear in eg oXYgen,
> in any of the distribution stes, in Roma etc. So this would be fairly dramatic.
>
>>>
>>> 2. Freezing (no more development, but Lite continues to be built and
>>> tested as part of the build process, and remains in trunk and in the
>>> release package):
>>>
>>> 	Lite would be compiled and released with every release. It's not clear
>>> whether it would be hard-linked to the P5 version in force at the time
>>> of the freeze or not; there are advantages and disadvantages each way.
>>> Bugs emerging out of testing would be fixed, but no other development
>>> would take place, no matter how apparently attractive the suggestions
>>> might be.
>>
>>
>> I think we did agree that Lite will be hard-linked to the P5 version
>> current at its time of freezing. This would be my preferred option.
>
> I can live with that one, but it is weird. We'd have something
> in the development tree which uses everything in its current state
> _except_ the source. Doesn't that look odd? We find an awful
> long-standing error in the content mode of <div>, its much debated
> on TEI-L, a fix is implemented with much trumpeting, and people
> look for it at the next release. But one, just one, amongst the
> distributed schemas does not have the lovely fix. Will users grok
> the magic distinction?
>>
>>
>>>
>>> 3. Active maintenance (no active development except where there are
>>> strong arguments in favour, but Lite is actively built and released as
>>> normal):
>>>
>>> 	What happens now would continue to happen, and we would respond to bug
>>> reports and entertain feature requests, although we would try to resist
>>> acting on the latter.
>>>
>>
>> I would rather not go down this route. If we want to invent a new "lite"
>> let's do that, and maintain it. This one has too much historical baggage.
>>
>>
>>> Does anyone see other possible scenarios?
>>
>> Well, I suppose we could just throw it away...
>
>
> attractive, but I am not sure what message that would send :-}
>
> I have a pragmatic suggestion - keep Lite in full support
> _until_ there is a replacement. And that could be the TEI
> in Libraries set; though I have many reservations whenever
> I look at that, I think the approach is correct.
>
> Are we really prepared to have no fully supported 80/20 customization
> of the TEI in circulation? if we thinks thats the right place to be,
> then lets archive Lite fully in the Vault and there's an end to it; otherwise,
> maintain it fully. The intermediate frozen one seems (to me)
> the worst sort of vacillation.
>
> If we opt for archiving, then we need do nothing in fact.
> Lite is part of each TEI P5 release, and fully available in the
> Vault.
> --
> Sebastian Rahtz
> Director (Research Support) of Academic IT Services
> University of Oxford IT Services
> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From lou.burnard at retired.ox.ac.uk  Mon Aug 13 12:16:16 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Mon, 13 Aug 2012 17:16:16 +0100
Subject: [tei-council] Target of links in Guidelines generation
In-Reply-To: <E7BE3A5B-9835-4634-B88B-E20DA2450E28@it.ox.ac.uk>
References: <50253DCB.3060805@uvic.ca>
	<E7BE3A5B-9835-4634-B88B-E20DA2450E28@it.ox.ac.uk>
Message-ID: <50292850.90102@retired.ox.ac.uk>

On 13/08/12 17:12, Sebastian Rahtz wrote:
> I confess, I cannot see a reason why I did it this way, so duly fixed back at base
> --

"back at xml:base" ha ha i see what you did there


From lou.burnard at retired.ox.ac.uk  Mon Aug 13 12:19:20 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Mon, 13 Aug 2012 17:19:20 +0100
Subject: [tei-council] Options for freezing and/or archiving Lite
In-Reply-To: <50292843.80700@uvic.ca>
References: <5024482D.1060307@uvic.ca> <5027DD4E.10400@retired.ox.ac.uk>
	<2b593217-f9a0-4203-9bb5-459a183e319a@HUB03.ad.oak.ox.ac.uk>
	<50292843.80700@uvic.ca>
Message-ID: <50292908.1070709@retired.ox.ac.uk>

On 13/08/12 17:16, Martin Holmes wrote:

>
> Would it be possible to create a version of TEI Lite that is constructed
> entirely through inclusion, without any subsequent customization?

Not sure what you mean by this, but if you mean the same as I do, then 
that's what we currently have. Lite specifies all and only the elements 
you want from a bunch of modules. The only other "customization" it does 
is to remove some otiose attributes.


Didn't
> we talk recently about having a sort of shortcut/conveniences module
> that would provide tags such as <b> and <i>? A new TEI Lite could be
> defined as consisting of the four base modules (or most of them), plus
> the convenience module. Other people could use the convenience module in
> their schemas too, if they wanted to.

This seems like an entirely different project to me.


From mholmes at uvic.ca  Mon Aug 13 13:44:28 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Mon, 13 Aug 2012 10:44:28 -0700
Subject: [tei-council] Dates and calendars
In-Reply-To: <5028E733.3070706@retired.ox.ac.uk>
References: <502577FD.1070603@uvic.ca> <5028D3E1.80708@kcl.ac.uk>
	<5028E733.3070706@retired.ox.ac.uk>
Message-ID: <50293CFC.7090208@uvic.ca>

On 12-08-13 04:38 AM, Lou Burnard wrote:
> I am an eejut.  Gabby is of course completely right. (I knew I
> disapproved of something, but I misremembered what)
>
> I wonder though whether this specific example (where @calendar is
> supplied but there is no content) shouldn't therefore trigger a
> schematron error. It doesn't make a lot of sense to say "there's a date
> in this calendar here but I'm not telling you what it is" surely?

I claim eejut status too. Of course I should be using @when-custom. And 
I'm glad it's there, because what I really want to do is to be able to 
calculate the equivalent gregorian date automatically from a julian 
date, so I need a formal attribute (which I can constrain with 
schematron) for encoding the julian date. So I disapprove of your 
disapproval of att.datable.custom.

This does seem to be a good candidate for a schematron rule, so I'll do 
that, assuming Gabby agrees, and I'll also use it as the basis for the 
little guide to writing constraints that I've been supposed to be 
creating for ages.

Cheers,
Martin

> On 13/08/12 11:16, Gabriel Bodard wrote:
>> The @calendar attribute on datable elements is defined as "indicat[ing]
>> the system or calendar to which the date represented by the _content of
>> this element_ belongs"; in other words the markup:
>>
>> <date when="1424-02" calendar="#julian"/>
>>
>> Means: "A date in the Julian calendar which corresponds to February 1424
>> CE in the proleptic Gregorian calendar." If you want to encode a
>> normalized version of the Julian date, the only legal way to do so is to
>> use @when-custom and @datingMethod.
>>
>> (This is exactly the use-case for which we introduced the whole
>> http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-att.datable.custom.html
>> class, of which Lou so disapproves. ;-) )
>>
>>
>

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From mholmes at uvic.ca  Mon Aug 13 14:03:08 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Mon, 13 Aug 2012 11:03:08 -0700
Subject: [tei-council] deadline for ticket submission before face2face
In-Reply-To: <50291A4D.4050102@it.ox.ac.uk>
References: <50291A4D.4050102@it.ox.ac.uk>
Message-ID: <5029415C.4010303@uvic.ca>

Good idea, I think. If we can turn around quite a few recent tickets at 
the ftf, we'll give a healthy impression of responsiveness.

Cheers,
Martin

On 12-08-13 08:16 AM, James Cummings wrote:
>
> Hiya,
>
> I was thinking of announcing to TEI-L that we are having a
> face2face meeting in September, and more specifically that we'll
> be looking at any tickets submitted before 2 September.  I
> thought if SIGs or others were working on proposals this might
> help spur them on to submit tickets.
>
> Does that seem a good idea?
>
> Lou has agreed to do an initial triage of the tickets after that
> date.
>
> -James
>

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From mholmes at uvic.ca  Mon Aug 13 14:12:48 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Mon, 13 Aug 2012 11:12:48 -0700
Subject: [tei-council] Options for freezing and/or archiving Lite
In-Reply-To: <50292908.1070709@retired.ox.ac.uk>
References: <5024482D.1060307@uvic.ca> <5027DD4E.10400@retired.ox.ac.uk>
	<2b593217-f9a0-4203-9bb5-459a183e319a@HUB03.ad.oak.ox.ac.uk>
	<50292843.80700@uvic.ca> <50292908.1070709@retired.ox.ac.uk>
Message-ID: <502943A0.3060500@uvic.ca>

On 12-08-13 09:19 AM, Lou Burnard wrote:
> On 13/08/12 17:16, Martin Holmes wrote:
>
>>
>> Would it be possible to create a version of TEI Lite that is constructed
>> entirely through inclusion, without any subsequent customization?
>
> Not sure what you mean by this, but if you mean the same as I do, then
> that's what we currently have. Lite specifies all and only the elements
> you want from a bunch of modules. The only other "customization" it does
> is to remove some otiose attributes.

I was thinking about the bulk of the documentation too. In other words, 
could the Lite documentation consist of a custom intro explaining what 
it is, then a set of inclusions (XInclude?) from other parts of the 
Guidelines. When I think about it, though, that's completely impractical.

Cheers,
Martin

> Didn't
>> we talk recently about having a sort of shortcut/conveniences module
>> that would provide tags such as <b> and <i>? A new TEI Lite could be
>> defined as consisting of the four base modules (or most of them), plus
>> the convenience module. Other people could use the convenience module in
>> their schemas too, if they wanted to.
>
> This seems like an entirely different project to me.



-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From sebastian.rahtz at it.ox.ac.uk  Mon Aug 13 14:19:19 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Mon, 13 Aug 2012 18:19:19 +0000
Subject: [tei-council] Options for freezing and/or archiving Lite
In-Reply-To: <502943A0.3060500@uvic.ca>
References: <5024482D.1060307@uvic.ca> <5027DD4E.10400@retired.ox.ac.uk>
	<2b593217-f9a0-4203-9bb5-459a183e319a@HUB03.ad.oak.ox.ac.uk>
	<50292843.80700@uvic.ca> <50292908.1070709@retired.ox.ac.uk>
	<502943A0.3060500@uvic.ca>
Message-ID: <e576c082-8b47-4a44-bbe5-72754c548e8a@HUB05.ad.oak.ox.ac.uk>


On 13 Aug 2012, at 19:12, Martin Holmes <mholmes at uvic.ca>
 wrote:

> I was thinking about the bulk of the documentation too. In other words, 
> could the Lite documentation consist of a custom intro explaining what 
> it is, then a set of inclusions (XInclude?) from other parts of the 
> Guidelines. When I think about it, though, that's completely impractical.


equally, one might well argue that managing the useful prose of Lite inside
the Guidelines would be efficient, and then extracting it.

this is distracting us from the question at hand, tho?

--
Sebastian Rahtz      
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431


From James.Cummings at it.ox.ac.uk  Tue Aug 14 06:50:16 2012
From: James.Cummings at it.ox.ac.uk (James Cummings)
Date: Tue, 14 Aug 2012 11:50:16 +0100
Subject: [tei-council] Teleconference Minutes, tcm 51
Message-ID: <502A2D68.4080907@it.ox.ac.uk>


Hi All,

Kevin has put the minutes (converted by another intern of his) 
onto the TEI-C website at:

http://www.tei-c.org/Activities/Council/Meetings/tcm51.xml

Please look over these before 5pm BST (current London time) 
tomorrow (Weds 15 Aug), at which point I'll announce them to TEI-L.

Send corrections to the Council list or Kevin.

Many thanks,

-James

-- 
Dr James Cummings, researchsupport at it.ox.ac.uk
Research Support, IT Services, University of Oxford

From gabriel.bodard at kcl.ac.uk  Tue Aug 14 07:15:14 2012
From: gabriel.bodard at kcl.ac.uk (Gabriel Bodard)
Date: Tue, 14 Aug 2012 12:15:14 +0100
Subject: [tei-council] Dates and calendars
In-Reply-To: <50293CFC.7090208@uvic.ca>
References: <502577FD.1070603@uvic.ca> <5028D3E1.80708@kcl.ac.uk>
	<5028E733.3070706@retired.ox.ac.uk> <50293CFC.7090208@uvic.ca>
Message-ID: <502A3342.6090301@kcl.ac.uk>

On 2012-08-13 18:44, Martin Holmes wrote:
> This does seem to be a good candidate for a schematron rule, so I'll do
> that, assuming Gabby agrees, and I'll also use it as the basis for the
> little guide to writing constraints that I've been supposed to be
> creating for ages.

What is this schematron supposed to be constraining? No @calendar if 
<date> (etc) is empty? No *-custom without @datingPoint|@datingMethod?


-- 
Dr Gabriel BODARD
(Research Associate in Digital Epigraphy)

Department of Digital Humanities
King's College London
26-29 Drury Lane
London WC2B 5RL

Email: gabriel.bodard at kcl.ac.uk
Tel: +44 (0)20 7848 1388
Fax: +44 (0)20 7848 2980

http://www.digitalclassicist.org/
http://www.currentepigraphy.org/

From mholmes at uvic.ca  Tue Aug 14 11:31:53 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Tue, 14 Aug 2012 08:31:53 -0700
Subject: [tei-council] Dates and calendars
In-Reply-To: <502A3342.6090301@kcl.ac.uk>
References: <502577FD.1070603@uvic.ca> <5028D3E1.80708@kcl.ac.uk>
	<5028E733.3070706@retired.ox.ac.uk> <50293CFC.7090208@uvic.ca>
	<502A3342.6090301@kcl.ac.uk>
Message-ID: <502A6F69.40008@uvic.ca>

On 12-08-14 04:15 AM, Gabriel Bodard wrote:
> On 2012-08-13 18:44, Martin Holmes wrote:
>> This does seem to be a good candidate for a schematron rule, so I'll do
>> that, assuming Gabby agrees, and I'll also use it as the basis for the
>> little guide to writing constraints that I've been supposed to be
>> creating for ages.
>
> What is this schematron supposed to be constraining? No @calendar if
> <date> (etc) is empty?

I think so. That should be true, shouldn't it?

> No *-custom without @datingPoint|@datingMethod?

I had thought so, but then I realized I wouldn't want to enforce either 
of those things. If @calendar points to a <calendar> with a detailed 
description of the dating system, then there's no point in @datingMethod 
(which also "supplies a pointer to a <calendarDesc> element or other 
means of interpreting the values of the custom dating attributes". 
(Incidentally, should that be <calendarDesc> or just <calendar>?) 
Similarly, @datingPoint is obviously optional.

However, I think it's true to say, isn't it, that if you have any of 
@*-custom, you should have one of @calendar, @datingMethod or @datingPoint?

Cheers,
Martin

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From mholmes at uvic.ca  Tue Aug 14 13:53:05 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Tue, 14 Aug 2012 10:53:05 -0700
Subject: [tei-council] Take a look at <listApp> spec
Message-ID: <502A9081.9070203@uvic.ca>

Hi all,

As part of work arising out of Ann Arbor, I've created an elementSpec 
for the new <listApp> element, and added a mention of it to the 
Guidelines. You can see the results here:

<http://teijenkins.hcmc.uvic.ca:8080/job/TEIP5-Documentation/lastSuccessfulBuild/artifact/Guidelines-web/en/html/ref-listApp.html>

<http://teijenkins.hcmc.uvic.ca:8080/job/TEIP5-Documentation/lastSuccessfulBuild/artifact/Guidelines-web/en/html/TC.html#TCAPLK>

Could you take a look and see if there's anything you think should be 
changed?

There is currently only one example for the element; although I have 
been asking around, no others have been forthcoming. I'm not sure 
whether we really need another example; I have considered fabricating 
one based on other examples in the TC chapter, but I'm not sure it's 
really needed -- <listApp> is pretty straightforward -- and I always 
think twice these days about making the Guidelines any bigger.

Cheers,
Martin
-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From gabriel.bodard at kcl.ac.uk  Tue Aug 14 14:13:12 2012
From: gabriel.bodard at kcl.ac.uk (Gabriel Bodard)
Date: Tue, 14 Aug 2012 19:13:12 +0100
Subject: [tei-council] Dates and calendars
In-Reply-To: <502A6F69.40008@uvic.ca>
References: <502577FD.1070603@uvic.ca> <5028D3E1.80708@kcl.ac.uk>
	<5028E733.3070706@retired.ox.ac.uk> <50293CFC.7090208@uvic.ca>
	<502A3342.6090301@kcl.ac.uk> <502A6F69.40008@uvic.ca>
Message-ID: <502A9538.8060809@kcl.ac.uk>

On 2012-08-14 16:31, Martin Holmes wrote:
>> What is this schematron supposed to be constraining? No @calendar if
>> <date> (etc) is empty?
> I think so. That should be true, shouldn't it?

I'm not clear what an empty <date> means, myself, so I'm not sure I can 
imagine what the danger of allowing @calendar on it is. Is the idea that 
@calendar should only be used when the date is used in transcription of 
a primary text?

>> No *-custom without @datingPoint|@datingMethod?
> I had thought so, but then I realized I wouldn't want to enforce either
> of those things. If @calendar points to a <calendar> with a detailed
> description of the dating system, then there's no point in @datingMethod
> (which also "supplies a pointer to a <calendarDesc> element or other
> means of interpreting the values of the custom dating attributes".
> (Incidentally, should that be <calendarDesc> or just <calendar>?)
> Similarly, @datingPoint is obviously optional.
>
> However, I think it's true to say, isn't it, that if you have any of
> @*-custom, you should have one of @calendar, @datingMethod or @datingPoint?

Yes, that is almost certainly true. So is the rule, report @*-custom 
without @calendar|@datingPoint|@datingMethod? That seems responsible, 
although I'm one of those people who often uses sloppy behaviour in 
practice that would fall foul of this.

I worry a bit about the two above rules being a bit contradictory, 
though. We don't complain about @*-custom on an empty element; but we do 
complain about @*-custom without @calendar|@dP|@dM, so I add @calendar 
to make it valid, and it then complains about @calendar on the empty 
element. (Maybe @calendar has no bearing on @*-custom at all, though?)

-- 
Dr Gabriel BODARD
(Research Associate in Digital Epigraphy)

Department of Digital Humanities
King's College London
26-29 Drury Lane
London WC2B 5RL

Email: gabriel.bodard at kcl.ac.uk
Tel: +44 (0)20 7848 1388
Fax: +44 (0)20 7848 2980

http://www.digitalclassicist.org/
http://www.currentepigraphy.org/

From mholmes at uvic.ca  Tue Aug 14 15:27:32 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Tue, 14 Aug 2012 12:27:32 -0700
Subject: [tei-council] Dates and calendars
In-Reply-To: <502A9538.8060809@kcl.ac.uk>
References: <502577FD.1070603@uvic.ca> <5028D3E1.80708@kcl.ac.uk>
	<5028E733.3070706@retired.ox.ac.uk> <50293CFC.7090208@uvic.ca>
	<502A3342.6090301@kcl.ac.uk> <502A6F69.40008@uvic.ca>
	<502A9538.8060809@kcl.ac.uk>
Message-ID: <502AA6A4.8050605@uvic.ca>

On 12-08-14 11:13 AM, Gabriel Bodard wrote:
> On 2012-08-14 16:31, Martin Holmes wrote:
>>> What is this schematron supposed to be constraining? No @calendar if
>>> <date> (etc) is empty?
>> I think so. That should be true, shouldn't it?
>
> I'm not clear what an empty <date> means, myself, so I'm not sure I can
> imagine what the danger of allowing @calendar on it is.

As Lou pointed out, @calendar "indicates the system or calendar to which 
the date represented by the content of this element belongs." If there 
is no content, then having @calendar is presumably wrong. However, I 
don't think it really should be; I think it's perfectly reasonable to 
encode something like this:

<date when-custom="1642-02-02" calendar="#julian"/>

when you want to encode a Julian date in a formal manner without 
transcribing any particular source from which it came. Consider this 
title of a modern document:

<title level="a">Management and Mismanagement at
               Bedlam, 1547 to 1633</title>

The two years in the title are presumably Julian, with the year running 
from March 25 to March 24. If you wanted to document the temporal 
coverage of this article, you might encode it like this:

<date from-custom="1547" to-custom="1633" calendar="#julian"/>

including the calendar information because those years are not 
equivalent to the proleptic Gregorian years with the same numbers.

> Is the idea that
> @calendar should only be used when the date is used in transcription of
> a primary text?

That would seem to be the intention of the attribute definition, 
although I think that's a bit too restrictive.

>>> No *-custom without @datingPoint|@datingMethod?
>> I had thought so, but then I realized I wouldn't want to enforce either
>> of those things. If @calendar points to a <calendar> with a detailed
>> description of the dating system, then there's no point in @datingMethod
>> (which also "supplies a pointer to a <calendarDesc> element or other
>> means of interpreting the values of the custom dating attributes".
>> (Incidentally, should that be <calendarDesc> or just <calendar>?)
>> Similarly, @datingPoint is obviously optional.
>>
>> However, I think it's true to say, isn't it, that if you have any of
>> @*-custom, you should have one of @calendar, @datingMethod or @datingPoint?
>
> Yes, that is almost certainly true. So is the rule, report @*-custom
> without @calendar|@datingPoint|@datingMethod? That seems responsible,
> although I'm one of those people who often uses sloppy behaviour in
> practice that would fall foul of this.
>
> I worry a bit about the two above rules being a bit contradictory,
> though. We don't complain about @*-custom on an empty element; but we do
> complain about @*-custom without @calendar|@dP|@dM, so I add @calendar
> to make it valid, and it then complains about @calendar on the empty
> element. (Maybe @calendar has no bearing on @*-custom at all, though?)

That would be worrying, because the purpose of @*-custom is to provide a 
formal way of recording a date in a non-gregorian calendar.

On balance, I think only the one rule is realistic: if you have any of 
@*-custom, you should have one of @calendar, @datingMethod or @datingPoint.

Cheers,
Martin

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From lou.burnard at retired.ox.ac.uk  Tue Aug 14 15:57:03 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Tue, 14 Aug 2012 20:57:03 +0100
Subject: [tei-council] Dates and calendars
In-Reply-To: <502A9538.8060809@kcl.ac.uk>
References: <502577FD.1070603@uvic.ca> <5028D3E1.80708@kcl.ac.uk>
	<5028E733.3070706@retired.ox.ac.uk> <50293CFC.7090208@uvic.ca>
	<502A3342.6090301@kcl.ac.uk> <502A6F69.40008@uvic.ca>
	<502A9538.8060809@kcl.ac.uk>
Message-ID: <502AAD8F.4040607@retired.ox.ac.uk>

On 14/08/12 19:13, Gabriel Bodard wrote:
> On 2012-08-14 16:31, Martin Holmes wrote:
>>> What is this schematron supposed to be constraining? No @calendar if
>>> <date> (etc) is empty?
>> I think so. That should be true, shouldn't it?
>
> I'm not clear what an empty <date> means, myself, so I'm not sure I can
> imagine what the danger of allowing @calendar on it is. Is the idea that
> @calendar should only be used when the date is used in transcription of
> a primary text?


I think (with some trepidation, having already got  several things wrong 
on this thread) that an empty <date> is to a <date> with content like a 
<ptr> is to a <ref>. You might want to have your software generate the 
content for the date, you might not actually want any content at all. 
But you do want to reference a date.

My first thought was that @calendar by definition tells you how to 
interpret the content of the <date>. Ergo if there is no content, but 
there is a @when (or, for that matter, a @when-custom), specifying 
@calendar can only lead to confusion. The @calendar value does NOT apply 
to either @when or @when-custom (or you would not be able to supply both)


So the rule should be something like "if a <date> is empty, then either 
@when or @when-custom (or both) should be supplied AND  @calendar must 
NOT be supplied"


> >>> No *-custom without @datingPoint|@datingMethod?
>> I had thought so, but then I realized I wouldn't want to enforce either
>> of those things. If @calendar points to a <calendar> with a detailed
>> description of the dating system, then there's no point in @datingMethod
>> (which also "supplies a pointer to a <calendarDesc> element or other
>> means of interpreting the values of the custom dating attributes".
>> (Incidentally, should that be <calendarDesc> or just <calendar>?)

See above. I think this is based on the mistaken assumption that 
@calendar refers to the value of the attributes on <date> rather than to 
its content.


This would all be much easier if there were some clear examples of how 
to use these various things in combination in the Guidelines...

>> Similarly, @datingPoint is obviously optional.

Yes. Though I do wonder why it is not treated as a kind of calendar.

>>
>> However, I think it's true to say, isn't it, that if you have any of
>> @*-custom, you should have one of @calendar, @datingMethod or @datingPoint?
>
> Yes, that is almost certainly true.

Almost, but I think not quite. @calendar doesn't help you interpret your 
@*.customs much.

So is the rule, report @*-custom
> without @calendar|@datingPoint|@datingMethod? That seems responsible,
> although I'm one of those people who often uses sloppy behaviour in
> practice that would fall foul of this.
>
> I worry a bit about the two above rules being a bit contradictory,
> though. We don't complain about @*-custom on an empty element; but we do
> complain about @*-custom without @calendar|@dP|@dM, so I add @calendar
> to make it valid, and it then complains about @calendar on the empty
> element. (Maybe @calendar has no bearing on @*-custom at all, though?)
>

exactly!


From James.Cummings at it.ox.ac.uk  Tue Aug 14 16:05:12 2012
From: James.Cummings at it.ox.ac.uk (James Cummings)
Date: Tue, 14 Aug 2012 21:05:12 +0100
Subject: [tei-council] Dates and calendars
In-Reply-To: <502AAD8F.4040607@retired.ox.ac.uk>
References: <502577FD.1070603@uvic.ca> <5028D3E1.80708@kcl.ac.uk>
	<5028E733.3070706@retired.ox.ac.uk> <50293CFC.7090208@uvic.ca>
	<502A3342.6090301@kcl.ac.uk> <502A6F69.40008@uvic.ca>
	<502A9538.8060809@kcl.ac.uk> <502AAD8F.4040607@retired.ox.ac.uk>
Message-ID: <502AAF78.9040602@it.ox.ac.uk>

On 14/08/12 20:57, Lou Burnard wrote:
> So the rule should be something like "if a<date>  is empty, then either
> @when or @when-custom (or both) should be supplied AND  @calendar must
> NOT be supplied"

I don't feel confident with a lot of this thread, but I know that 
I use empty date elements with @from and @to, no @when.

But I've not yet used @calendar...

-James

-- 
Dr James Cummings, researchsupport at it.ox.ac.uk
Research Support, IT Services, University of Oxford

From lou.burnard at retired.ox.ac.uk  Tue Aug 14 16:08:48 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Tue, 14 Aug 2012 21:08:48 +0100
Subject: [tei-council] Dates and calendars
In-Reply-To: <502AAF78.9040602@it.ox.ac.uk>
References: <502577FD.1070603@uvic.ca> <5028D3E1.80708@kcl.ac.uk>
	<5028E733.3070706@retired.ox.ac.uk> <50293CFC.7090208@uvic.ca>
	<502A3342.6090301@kcl.ac.uk> <502A6F69.40008@uvic.ca>
	<502A9538.8060809@kcl.ac.uk> <502AAD8F.4040607@retired.ox.ac.uk>
	<502AAF78.9040602@it.ox.ac.uk>
Message-ID: <502AB050.9060005@retired.ox.ac.uk>

On 14/08/12 21:05, James Cummings wrote:
> On 14/08/12 20:57, Lou Burnard wrote:
>> So the rule should be something like "if a<date>  is empty, then either
>> @when or @when-custom (or both) should be supplied AND  @calendar must
>> NOT be supplied"
>
> I don't feel confident with a lot of this thread, but I know that
> I use empty date elements with @from and @to, no @when.
>

sorry, in my earlier posting for "@when" and "@custom-when", plz read 
"any member of att.datable.w3c" and "any member of att.datable.custom" 
respectively.




From mholmes at uvic.ca  Tue Aug 14 16:46:36 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Tue, 14 Aug 2012 13:46:36 -0700
Subject: [tei-council] Dates and calendars
In-Reply-To: <502AAD8F.4040607@retired.ox.ac.uk>
References: <502577FD.1070603@uvic.ca> <5028D3E1.80708@kcl.ac.uk>
	<5028E733.3070706@retired.ox.ac.uk> <50293CFC.7090208@uvic.ca>
	<502A3342.6090301@kcl.ac.uk> <502A6F69.40008@uvic.ca>
	<502A9538.8060809@kcl.ac.uk> <502AAD8F.4040607@retired.ox.ac.uk>
Message-ID: <502AB92C.80503@uvic.ca>

Lou says:

> My first thought was that @calendar by definition tells you how to
> interpret the content of the <date>. Ergo if there is no content, but
> there is a @when (or, for that matter, a @when-custom), specifying
> @calendar can only lead to confusion. The @calendar value does NOT apply
> to either @when or @when-custom (or you would not be able to supply both)

Here's my problem with that: att.datable.custom provides "attributes for 
normalization of elements that contain datable events to a custom dating 
system (i.e. other than the Gregorian used by W3 and ISO)."

In other words, if you use @when-custom and friends, it's because the 
calendar is not Gregorian.

So somewhere you have to specify what that calendar is. The obvious 
place is in @calendar. This is especially important if there is no 
workable conversion between the calendar in use in the host element and 
the Gregorian (as in the case of Anno Mundi dates, for instance, about 
which there is potential disagreement to the extent of 1500 years).

So I think it's important to be able to use @calendar whenever you use 
@*-custom, and @calendar SHOULD be taken to refer to the values of 
@*-custom. In other words, I think the definition of @calendar should be 
expanded thus:

"indicates the system or calendar to which the date represented by the 
content of this element, and/or the dates expressed in attributes from 
att.datable.custom, belong."

Without this, there's no way to provide a formal link from a date like this:

<date when-custom="3050"/>

to a calendar (e.g. Anno Mundi). You can say that we should do this:

<date when-custom="3050" calendar="#anno_mundi">3050</date>

which is true, but the value of the custom attribute is that it can be 
constrained according to known rules (documented in <calendar>) and 
therefore processed. And it's surely perverse to say that in this 
situation, the @calendar refers to the text content, but NOT to the 
@when-custom attribute, when the purpose of the @when-custom attribute 
is to allow you to encode non-Gregorian dates in a formal way.

So I think we should expand @calendar as suggested above.

Cheers,
Martin

On 12-08-14 12:57 PM, Lou Burnard wrote:
> On 14/08/12 19:13, Gabriel Bodard wrote:
>> On 2012-08-14 16:31, Martin Holmes wrote:
>>>> What is this schematron supposed to be constraining? No @calendar if
>>>> <date> (etc) is empty?
>>> I think so. That should be true, shouldn't it?
>>
>> I'm not clear what an empty <date> means, myself, so I'm not sure I can
>> imagine what the danger of allowing @calendar on it is. Is the idea that
>> @calendar should only be used when the date is used in transcription of
>> a primary text?
>
>
> I think (with some trepidation, having already got  several things wrong
> on this thread) that an empty <date> is to a <date> with content like a
> <ptr> is to a <ref>. You might want to have your software generate the
> content for the date, you might not actually want any content at all.
> But you do want to reference a date.
>
> My first thought was that @calendar by definition tells you how to
> interpret the content of the <date>. Ergo if there is no content, but
> there is a @when (or, for that matter, a @when-custom), specifying
> @calendar can only lead to confusion. The @calendar value does NOT apply
> to either @when or @when-custom (or you would not be able to supply both)
>
>
> So the rule should be something like "if a <date> is empty, then either
> @when or @when-custom (or both) should be supplied AND  @calendar must
> NOT be supplied"
>
>
>>>>> No *-custom without @datingPoint|@datingMethod?
>>> I had thought so, but then I realized I wouldn't want to enforce either
>>> of those things. If @calendar points to a <calendar> with a detailed
>>> description of the dating system, then there's no point in @datingMethod
>>> (which also "supplies a pointer to a <calendarDesc> element or other
>>> means of interpreting the values of the custom dating attributes".
>>> (Incidentally, should that be <calendarDesc> or just <calendar>?)
>
> See above. I think this is based on the mistaken assumption that
> @calendar refers to the value of the attributes on <date> rather than to
> its content.
>
>
> This would all be much easier if there were some clear examples of how
> to use these various things in combination in the Guidelines...
>
>>> Similarly, @datingPoint is obviously optional.
>
> Yes. Though I do wonder why it is not treated as a kind of calendar.
>
>>>
>>> However, I think it's true to say, isn't it, that if you have any of
>>> @*-custom, you should have one of @calendar, @datingMethod or @datingPoint?
>>
>> Yes, that is almost certainly true.
>
> Almost, but I think not quite. @calendar doesn't help you interpret your
> @*.customs much.
>
> So is the rule, report @*-custom
>> without @calendar|@datingPoint|@datingMethod? That seems responsible,
>> although I'm one of those people who often uses sloppy behaviour in
>> practice that would fall foul of this.
>>
>> I worry a bit about the two above rules being a bit contradictory,
>> though. We don't complain about @*-custom on an empty element; but we do
>> complain about @*-custom without @calendar|@dP|@dM, so I add @calendar
>> to make it valid, and it then complains about @calendar on the empty
>> element. (Maybe @calendar has no bearing on @*-custom at all, though?)
>>
>
> exactly!
>

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From kevin.s.hawkins at ultraslavonic.info  Tue Aug 14 20:15:30 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Tue, 14 Aug 2012 20:15:30 -0400
Subject: [tei-council] Take a look at <listApp> spec
In-Reply-To: <502A9081.9070203@uvic.ca>
References: <502A9081.9070203@uvic.ca>
Message-ID: <502AEA22.3080401@ultraslavonic.info>

Two things:

a) I notice that <ptr/>s are rendered differently in your build than in 
the latest release.  I suspect this is fallout from the fix that you 
and/or Sebastian did to make URLs relative instead of absolute.

So as not to confuse the matter, here's a different element definition. 
  Compare the links after the <desc>:

http://teijenkins.hcmc.uvic.ca:8080/job/TEIP5-Documentation/lastSuccessfulBuild/artifact/Guidelines-web/en/html/ref-p.html

http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-p.html

b) I see the note you added for <listApp>, but it feels wrong to me to 
include this note if we don't also include it for <interpGrp> and any 
other elements that feel a bit like metadata to most of us but can 
appear within <text> because they sometimes occur there in source 
documents.  So I'm inclined to add this point to clarification to 
<interpGrp> as well, plus any other such elements.  (I know there are 
others out there because people have mentioned them, but I don't 
remember any of them or how to find them.)

--K.

On 8/14/12 1:53 PM, Martin Holmes wrote:
> Hi all,
>
> As part of work arising out of Ann Arbor, I've created an elementSpec
> for the new <listApp> element, and added a mention of it to the
> Guidelines. You can see the results here:
>
> <http://teijenkins.hcmc.uvic.ca:8080/job/TEIP5-Documentation/lastSuccessfulBuild/artifact/Guidelines-web/en/html/ref-listApp.html>
>
> <http://teijenkins.hcmc.uvic.ca:8080/job/TEIP5-Documentation/lastSuccessfulBuild/artifact/Guidelines-web/en/html/TC.html#TCAPLK>
>
> Could you take a look and see if there's anything you think should be
> changed?
>
> There is currently only one example for the element; although I have
> been asking around, no others have been forthcoming. I'm not sure
> whether we really need another example; I have considered fabricating
> one based on other examples in the TC chapter, but I'm not sure it's
> really needed -- <listApp> is pretty straightforward -- and I always
> think twice these days about making the Guidelines any bigger.
>
> Cheers,
> Martin
>

From gabriel.bodard at kcl.ac.uk  Wed Aug 15 07:37:35 2012
From: gabriel.bodard at kcl.ac.uk (Gabriel Bodard)
Date: Wed, 15 Aug 2012 12:37:35 +0100
Subject: [tei-council] Dates and calendars
In-Reply-To: <502AB92C.80503@uvic.ca>
References: <502577FD.1070603@uvic.ca> <5028D3E1.80708@kcl.ac.uk>
	<5028E733.3070706@retired.ox.ac.uk> <50293CFC.7090208@uvic.ca>
	<502A3342.6090301@kcl.ac.uk> <502A6F69.40008@uvic.ca>
	<502A9538.8060809@kcl.ac.uk>
	<502AAD8F.4040607@retired.ox.ac.uk> <502AB92C.80503@uvic.ca>
Message-ID: <502B89FF.3080400@kcl.ac.uk>

On 2012-08-14 21:46, Martin Holmes wrote:
> So I think it's important to be able to use @calendar whenever you use
> @*-custom, and @calendar SHOULD be taken to refer to the values of
> @*-custom. In other words, I think the definition of @calendar should be
> expanded thus:
>
> "indicates the system or calendar to which the date represented by the
> content of this element, and/or the dates expressed in attributes from
> att.datable.custom, belong."
>
> Without this, there's no way to provide a formal link from a date like this:
>
> <date when-custom="3050"/>
>
> to a calendar (e.g. Anno Mundi).

Surely that's precisely what @datingMethod is for? <date 
when-custom="3050" datingMethod="#anno_mundi"/> means I'm normalizing a 
date to the AM calendar (which is defined in a <calendar> element with 
@xml:id=anno_mundi).

The distinction between @calendar and @datingMethod is very clear (the 
former defines the content of the element, the latter the @*-custom 
attributes). Martin's suggestion is premised on the fact that in all of 
the examples we are imagining the two are the same, so it seems an odd 
redundancy to say:

<date from-custom="1547" to-custom="1633" calendar="#julian" 
datingMethod="#julian">1547-1633</date>

Which is indeed a pain (I might be inclined to say that when 
@datingMethod is absent, we assume the *-custom attributes follow the 
same calendar as defined in @calendar, but that makes me slightly nervous).

But consider the following cases where the transcribed date and the 
non-Gregorian normalization are different calendars. It is the norm in 
classical studies to normalize all dates to the proleptic Julian 
calendar, to avoid saying something like: <date when="-0044-03-13">the 
Ides of March</date> (which should be March 15th). This is true even if 
the date we're encoding is not Julian, but in some other form: "Pachon 
19, 12th year of the reign of Tiberius" or "11 October, 4th Indiction"

For these we'd use something like @calendar="#romano-egyptian" 
@datingMethod="#julian".

I'm not sure it's a very good idea to expect @calendar to serve double 
service as Martin suggests...

G


-- 
Dr Gabriel BODARD
(Research Associate in Digital Epigraphy)

Department of Digital Humanities
King's College London
26-29 Drury Lane
London WC2B 5RL

Email: gabriel.bodard at kcl.ac.uk
Tel: +44 (0)20 7848 1388
Fax: +44 (0)20 7848 2980

http://www.digitalclassicist.org/
http://www.currentepigraphy.org/

From lou.burnard at retired.ox.ac.uk  Wed Aug 15 08:10:48 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Wed, 15 Aug 2012 13:10:48 +0100
Subject: [tei-council] Dates and calendars
In-Reply-To: <502B89FF.3080400@kcl.ac.uk>
References: <502577FD.1070603@uvic.ca> <5028D3E1.80708@kcl.ac.uk>
	<5028E733.3070706@retired.ox.ac.uk> <50293CFC.7090208@uvic.ca>
	<502A3342.6090301@kcl.ac.uk> <502A6F69.40008@uvic.ca>
	<502A9538.8060809@kcl.ac.uk>
	<502AAD8F.4040607@retired.ox.ac.uk> <502AB92C.80503@uvic.ca>
	<502B89FF.3080400@kcl.ac.uk>
Message-ID: <502B91C8.50104@retired.ox.ac.uk>

On 15/08/12 12:37, Gabriel Bodard wrote:
> I'm not sure it's a very good idea to expect @calendar to serve double
> service as Martin suggests...

I agree with Gabby. In fact I'd say it's a downright bad idea. And 
repeat my request for a better set of examples demonstrating how all 
these attributes are supposed to be used together. At present the 
discussion is dispersed across several places in the Guidelines and far 
from perspicuous or complete.



From sebastian.rahtz at it.ox.ac.uk  Wed Aug 15 08:13:34 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Wed, 15 Aug 2012 12:13:34 +0000
Subject: [tei-council] Fwd:  extra artefacts
References: <DD0D8D0E-0A60-41D5-A4C7-EC724C13B72C@it.ox.ac.uk>
Message-ID: <A0D4AE2D-2AE0-406D-A07D-00BB11E6785A@it.ox.ac.uk>

my message below didn't get any yay or nay responses.

can I get some feeling from folks over whether we should be
providing these beasts?

Sebastian

Begin forwarded message:

> From: Sebastian Rahtz <sebastian.rahtz at it.ox.ac.uk>
> Subject: Re: [tei-council] extra artefacts
> Date: 7 August 2012 23:14:01 BST
> To: <James.Cummings at it.ox.ac.uk>
> Cc: <tei-council at lists.village.Virginia.EDU>
> 
> How about this:
> 
> Source and data support files for TEI Guidelines
> 
> In addition to the schema modules and example customizations generated for each
> release of the Guidelines, a set of files are provided in the xml/tei/odd/ directory
> which are for use by those writing TEI tools such as editors or visualizations.
> 
> 	p5attlist.txt
> This is a text file with a comma-separated cataligue of all the attributes available on TEI elements,
> list the element or class name, the attribute name, the datatype, and  an indication ("multiple"
> or "single") as to whether it can contain multiple values. eg
> 	att.ascribed,who,data.pointer,multiple
> 
> 
> 	p5subset.json
> This is a representation of all TEI modules, classes, elements and attributes (with their
> descriptions) in JSON format for consumption by Javascript tools in web applications. For
> example, this fragment provides summary information about the <gi>ab</gi> element:
> 
> 	p5subset.xml
> This is copy of the reference component of the TEI source, extracting all
> the <gi>elementSpec</gi>, <gi>classSpec</gi>, <gi>macroSpec</gi>
> and <gi>moduleSpec</gi> elements, with descriptions. It does not include
> the text of the chapters of the Guidelines, and is intended for use by ODD processors
> which need to access all of the TEI components in a convenient single file.
> 
> 	stripspace.xsl.model
> This is a fragmeht of XSL which can be added to any transformation which 
> is being applied to a TEI document. It consists of a <xsl:strip-space> element
> which lists all the elements which can <emph>not</emph> contain character
> data. This tells the processor it can ignore white space around child components
> of these elements.

--
Sebastian Rahtz      
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431


From gabriel.bodard at kcl.ac.uk  Wed Aug 15 08:42:57 2012
From: gabriel.bodard at kcl.ac.uk (Gabriel Bodard)
Date: Wed, 15 Aug 2012 13:42:57 +0100
Subject: [tei-council] Dates and calendars
In-Reply-To: <502B91C8.50104@retired.ox.ac.uk>
References: <502577FD.1070603@uvic.ca> <5028D3E1.80708@kcl.ac.uk>
	<5028E733.3070706@retired.ox.ac.uk> <50293CFC.7090208@uvic.ca>
	<502A3342.6090301@kcl.ac.uk> <502A6F69.40008@uvic.ca>
	<502A9538.8060809@kcl.ac.uk>	<502AAD8F.4040607@retired.ox.ac.uk>
	<502AB92C.80503@uvic.ca>	<502B89FF.3080400@kcl.ac.uk>
	<502B91C8.50104@retired.ox.ac.uk>
Message-ID: <502B9951.6030207@kcl.ac.uk>

That last is at least partly my fault. I was tasked to write the specs 
and document the dating.custom and calendarDesc stuff, and I did the 
former but not the latter. I'll try to come up with some examples for 
discussion here soon.

G

On 2012-08-15 13:10, Lou Burnard wrote:
> On 15/08/12 12:37, Gabriel Bodard wrote:
>> I'm not sure it's a very good idea to expect @calendar to serve double
>> service as Martin suggests...
>
> I agree with Gabby. In fact I'd say it's a downright bad idea. And
> repeat my request for a better set of examples demonstrating how all
> these attributes are supposed to be used together. At present the
> discussion is dispersed across several places in the Guidelines and far
> from perspicuous or complete.
>
>

-- 
Dr Gabriel BODARD
(Research Associate in Digital Epigraphy)

Department of Digital Humanities
King's College London
26-29 Drury Lane
London WC2B 5RL

Email: gabriel.bodard at kcl.ac.uk
Tel: +44 (0)20 7848 1388
Fax: +44 (0)20 7848 2980

http://www.digitalclassicist.org/
http://www.currentepigraphy.org/

From James.Cummings at it.ox.ac.uk  Wed Aug 15 09:06:42 2012
From: James.Cummings at it.ox.ac.uk (James Cummings)
Date: Wed, 15 Aug 2012 14:06:42 +0100
Subject: [tei-council] Fwd:  extra artefacts
In-Reply-To: <A0D4AE2D-2AE0-406D-A07D-00BB11E6785A@it.ox.ac.uk>
References: <DD0D8D0E-0A60-41D5-A4C7-EC724C13B72C@it.ox.ac.uk>
	<A0D4AE2D-2AE0-406D-A07D-00BB11E6785A@it.ox.ac.uk>
Message-ID: <502B9EE2.7040808@it.ox.ac.uk>


I'm in favour of us providing them.

-James

On 15/08/12 13:13, Sebastian Rahtz wrote:
> my message below didn't get any yay or nay responses.
>
> can I get some feeling from folks over whether we should be
> providing these beasts?
>
> Sebastian
>
> Begin forwarded message:
>
>> From: Sebastian Rahtz<sebastian.rahtz at it.ox.ac.uk>
>> Subject: Re: [tei-council] extra artefacts
>> Date: 7 August 2012 23:14:01 BST
>> To:<James.Cummings at it.ox.ac.uk>
>> Cc:<tei-council at lists.village.Virginia.EDU>
>>
>> How about this:
>>
>> Source and data support files for TEI Guidelines
>>
>> In addition to the schema modules and example customizations generated for each
>> release of the Guidelines, a set of files are provided in the xml/tei/odd/ directory
>> which are for use by those writing TEI tools such as editors or visualizations.
>>
>> 	p5attlist.txt
>> This is a text file with a comma-separated cataligue of all the attributes available on TEI elements,
>> list the element or class name, the attribute name, the datatype, and  an indication ("multiple"
>> or "single") as to whether it can contain multiple values. eg
>> 	att.ascribed,who,data.pointer,multiple
>>
>>
>> 	p5subset.json
>> This is a representation of all TEI modules, classes, elements and attributes (with their
>> descriptions) in JSON format for consumption by Javascript tools in web applications. For
>> example, this fragment provides summary information about the<gi>ab</gi>  element:
>>
>> 	p5subset.xml
>> This is copy of the reference component of the TEI source, extracting all
>> the<gi>elementSpec</gi>,<gi>classSpec</gi>,<gi>macroSpec</gi>
>> and<gi>moduleSpec</gi>  elements, with descriptions. It does not include
>> the text of the chapters of the Guidelines, and is intended for use by ODD processors
>> which need to access all of the TEI components in a convenient single file.
>>
>> 	stripspace.xsl.model
>> This is a fragmeht of XSL which can be added to any transformation which
>> is being applied to a TEI document. It consists of a<xsl:strip-space>  element
>> which lists all the elements which can<emph>not</emph>  contain character
>> data. This tells the processor it can ignore white space around child components
>> of these elements.
>
> --
> Sebastian Rahtz
> Director (Research Support) of Academic IT Services
> University of Oxford IT Services
> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>


-- 
Dr James Cummings, researchsupport at it.ox.ac.uk
Research Support, IT Services, University of Oxford

From kevin.s.hawkins at ultraslavonic.info  Wed Aug 15 09:57:49 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Wed, 15 Aug 2012 09:57:49 -0400
Subject: [tei-council] Fwd:  extra artefacts
In-Reply-To: <502B9EE2.7040808@it.ox.ac.uk>
References: <DD0D8D0E-0A60-41D5-A4C7-EC724C13B72C@it.ox.ac.uk>	<A0D4AE2D-2AE0-406D-A07D-00BB11E6785A@it.ox.ac.uk>
	<502B9EE2.7040808@it.ox.ac.uk>
Message-ID: <502BAADD.1020004@ultraslavonic.info>

Seconded.  But did we agree on where this documentation that Sebastian 
wrote will live?  In comments at the top of each file?  Are there other 
XSLTs in the release that could also use their own sentence or two of 
documentation?

On 8/15/2012 9:06 AM, James Cummings wrote:
>
> I'm in favour of us providing them.
>
> -James
>
> On 15/08/12 13:13, Sebastian Rahtz wrote:
>> my message below didn't get any yay or nay responses.
>>
>> can I get some feeling from folks over whether we should be
>> providing these beasts?
>>
>> Sebastian
>>
>> Begin forwarded message:
>>
>>> From: Sebastian Rahtz<sebastian.rahtz at it.ox.ac.uk>
>>> Subject: Re: [tei-council] extra artefacts
>>> Date: 7 August 2012 23:14:01 BST
>>> To:<James.Cummings at it.ox.ac.uk>
>>> Cc:<tei-council at lists.village.Virginia.EDU>
>>>
>>> How about this:
>>>
>>> Source and data support files for TEI Guidelines
>>>
>>> In addition to the schema modules and example customizations generated for each
>>> release of the Guidelines, a set of files are provided in the xml/tei/odd/ directory
>>> which are for use by those writing TEI tools such as editors or visualizations.
>>>
>>> 	p5attlist.txt
>>> This is a text file with a comma-separated cataligue of all the attributes available on TEI elements,
>>> list the element or class name, the attribute name, the datatype, and  an indication ("multiple"
>>> or "single") as to whether it can contain multiple values. eg
>>> 	att.ascribed,who,data.pointer,multiple
>>>
>>>
>>> 	p5subset.json
>>> This is a representation of all TEI modules, classes, elements and attributes (with their
>>> descriptions) in JSON format for consumption by Javascript tools in web applications. For
>>> example, this fragment provides summary information about the<gi>ab</gi>   element:
>>>
>>> 	p5subset.xml
>>> This is copy of the reference component of the TEI source, extracting all
>>> the<gi>elementSpec</gi>,<gi>classSpec</gi>,<gi>macroSpec</gi>
>>> and<gi>moduleSpec</gi>   elements, with descriptions. It does not include
>>> the text of the chapters of the Guidelines, and is intended for use by ODD processors
>>> which need to access all of the TEI components in a convenient single file.
>>>
>>> 	stripspace.xsl.model
>>> This is a fragmeht of XSL which can be added to any transformation which
>>> is being applied to a TEI document. It consists of a<xsl:strip-space>   element
>>> which lists all the elements which can<emph>not</emph>   contain character
>>> data. This tells the processor it can ignore white space around child components
>>> of these elements.
>>
>> --
>> Sebastian Rahtz
>> Director (Research Support) of Academic IT Services
>> University of Oxford IT Services
>> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>>
>
>

From sebastian.rahtz at it.ox.ac.uk  Wed Aug 15 10:00:32 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Wed, 15 Aug 2012 14:00:32 +0000
Subject: [tei-council] Fwd:  extra artefacts
In-Reply-To: <502BAADD.1020004@ultraslavonic.info>
References: <DD0D8D0E-0A60-41D5-A4C7-EC724C13B72C@it.ox.ac.uk>
	<A0D4AE2D-2AE0-406D-A07D-00BB11E6785A@it.ox.ac.uk>
	<502B9EE2.7040808@it.ox.ac.uk> <502BAADD.1020004@ultraslavonic.info>
Message-ID: <271EFFD6-0443-4A57-852A-D4F5A577E3EC@it.ox.ac.uk>


On 15 Aug 2012, at 14:57, Kevin Hawkins <kevin.s.hawkins at ultraslavonic.info>
 wrote:

> Seconded.  But did we agree on where this documentation that Sebastian 
> wrote will live?

somewhere near http://www.tei-c.org/Guidelines/P5/, is what was suggested

>    Are there other 
> XSLTs in the release that could also use their own sentence or two of 
> documentation?


probably. but there aren't any which we have promoted before.
i think thats an open question, what other artefacts would
our users find helpful.
--
Sebastian Rahtz      
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431


From lou.burnard at retired.ox.ac.uk  Wed Aug 15 10:03:05 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Wed, 15 Aug 2012 15:03:05 +0100
Subject: [tei-council] Fwd:  extra artefacts
In-Reply-To: <271EFFD6-0443-4A57-852A-D4F5A577E3EC@it.ox.ac.uk>
References: <DD0D8D0E-0A60-41D5-A4C7-EC724C13B72C@it.ox.ac.uk>
	<A0D4AE2D-2AE0-406D-A07D-00BB11E6785A@it.ox.ac.uk>
	<502B9EE2.7040808@it.ox.ac.uk>
	<502BAADD.1020004@ultraslavonic.info>
	<271EFFD6-0443-4A57-852A-D4F5A577E3EC@it.ox.ac.uk>
Message-ID: <502BAC19.9050505@retired.ox.ac.uk>

On 15/08/12 15:00, Sebastian Rahtz wrote:
>
>
>>     Are there other
>> XSLTs in the release that could also use their own sentence or two of
>> documentation?
>
>
> probably. but there aren't any which we have promoted before.
> i think thats an open question, what other artefacts would
> our users find helpful.

Yes indeed, which makes me think that we should perhaps present these in 
a slightly different way. I'll try to produce a more precise proposal 
later on today or tomorrow. Off the cuff I'd say that information about 
(the existence of) p5subset is something useful to way more people than 
the others.


From mholmes at uvic.ca  Wed Aug 15 11:35:35 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Wed, 15 Aug 2012 08:35:35 -0700
Subject: [tei-council] Take a look at <listApp> spec
In-Reply-To: <502AEA22.3080401@ultraslavonic.info>
References: <502A9081.9070203@uvic.ca> <502AEA22.3080401@ultraslavonic.info>
Message-ID: <502BC1C7.2070002@uvic.ca>

Hi Kevin,

Re the <ptr> thing: I think Sebastian has already fixed it.

On this question:

> b) I see the note you added for <listApp>, but it feels wrong to me to
> include this note if we don't also include it for <interpGrp> and any
> other elements that feel a bit like metadata to most of us but can
> appear within <text> because they sometimes occur there in source
> documents.  So I'm inclined to add this point to clarification to
> <interpGrp> as well, plus any other such elements.  (I know there are
> others out there because people have mentioned them, but I don't
> remember any of them or how to find them.)

That's a good point, and I think it perhaps should be included elsewhere 
too. The note is:

"<listApp> elements would normally be located in the back part of a 
document, but they may appear elsewhere."

My intention was to give some guidance on where lists of standoff <app>s 
might appear in the document, for people who were simply looking for a 
recommendation, and encourage a common practice, without shutting the 
door to other options. With regard to elements that can appear virtually 
anywhere in a document, I often find myself asking "Where do people 
_usually_ put them?"

I think <listApp> differs a bit from <interpGrp> et al because it 
contains actual transcription from source texts (in the <app> element), 
so it does actually seem wrong to put it in the header.

But do you really think the note should be removed from <listApp> until 
it is also added elsewhere? It seems perverse to remove a useful note 
simply because there are other places where similarly useful notes 
aren't yet provided.

Cheers,
Martin


On 12-08-14 05:15 PM, Kevin Hawkins wrote:
> Two things:
>
> a) I notice that <ptr/>s are rendered differently in your build than in
> the latest release.  I suspect this is fallout from the fix that you
> and/or Sebastian did to make URLs relative instead of absolute.
>
> So as not to confuse the matter, here's a different element definition.
>    Compare the links after the <desc>:
>
> http://teijenkins.hcmc.uvic.ca:8080/job/TEIP5-Documentation/lastSuccessfulBuild/artifact/Guidelines-web/en/html/ref-p.html
>
> http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-p.html
>
> b) I see the note you added for <listApp>, but it feels wrong to me to
> include this note if we don't also include it for <interpGrp> and any
> other elements that feel a bit like metadata to most of us but can
> appear within <text> because they sometimes occur there in source
> documents.  So I'm inclined to add this point to clarification to
> <interpGrp> as well, plus any other such elements.  (I know there are
> others out there because people have mentioned them, but I don't
> remember any of them or how to find them.)
>
> --K.
>
> On 8/14/12 1:53 PM, Martin Holmes wrote:
>> Hi all,
>>
>> As part of work arising out of Ann Arbor, I've created an elementSpec
>> for the new <listApp> element, and added a mention of it to the
>> Guidelines. You can see the results here:
>>
>> <http://teijenkins.hcmc.uvic.ca:8080/job/TEIP5-Documentation/lastSuccessfulBuild/artifact/Guidelines-web/en/html/ref-listApp.html>
>>
>> <http://teijenkins.hcmc.uvic.ca:8080/job/TEIP5-Documentation/lastSuccessfulBuild/artifact/Guidelines-web/en/html/TC.html#TCAPLK>
>>
>> Could you take a look and see if there's anything you think should be
>> changed?
>>
>> There is currently only one example for the element; although I have
>> been asking around, no others have been forthcoming. I'm not sure
>> whether we really need another example; I have considered fabricating
>> one based on other examples in the TC chapter, but I'm not sure it's
>> really needed -- <listApp> is pretty straightforward -- and I always
>> think twice these days about making the Guidelines any bigger.
>>
>> Cheers,
>> Martin
>>

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From sebastian.rahtz at it.ox.ac.uk  Wed Aug 15 11:38:02 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Wed, 15 Aug 2012 15:38:02 +0000
Subject: [tei-council] Take a look at <listApp> spec
In-Reply-To: <502BC1C7.2070002@uvic.ca>
References: <502A9081.9070203@uvic.ca> <502AEA22.3080401@ultraslavonic.info>
	<502BC1C7.2070002@uvic.ca>
Message-ID: <B0D8CD00-A210-4AE3-AB56-73D5E2EBBF26@it.ox.ac.uk>


On 15 Aug 2012, at 16:35, Martin Holmes <mholmes at uvic.ca>
 wrote:

> 
> Re the <ptr> thing: I think Sebastian has already fixed it.
> 
yeah, spotted the mistake. wrong order of events in a <choose>

with that, I shall go off on holiday :-}

(if you want to know that my stylesheets now generate valid fixed-layout
ePub3, I can now reassure they do, in case you were worrying
I wouldn't get it finished)

--
Sebastian Rahtz      
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431


From lou.burnard at retired.ox.ac.uk  Wed Aug 15 11:39:20 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Wed, 15 Aug 2012 16:39:20 +0100
Subject: [tei-council] Take a look at <listApp> spec
In-Reply-To: <B0D8CD00-A210-4AE3-AB56-73D5E2EBBF26@it.ox.ac.uk>
References: <502A9081.9070203@uvic.ca> <502AEA22.3080401@ultraslavonic.info>
	<502BC1C7.2070002@uvic.ca>
	<B0D8CD00-A210-4AE3-AB56-73D5E2EBBF26@it.ox.ac.uk>
Message-ID: <502BC2A8.8020805@retired.ox.ac.uk>

On 15/08/12 16:38, Sebastian Rahtz wrote:

>
> (if you want to know that my stylesheets now generate valid fixed-layout
> ePub3, I can now reassure they do, in case you were worrying
> I wouldn't get it finished)

phew, that's a relief  :-)



From lou.burnard at retired.ox.ac.uk  Wed Aug 15 11:39:32 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Wed, 15 Aug 2012 16:39:32 +0100
Subject: [tei-council] Take a look at <listApp> spec
In-Reply-To: <502BC1C7.2070002@uvic.ca>
References: <502A9081.9070203@uvic.ca> <502AEA22.3080401@ultraslavonic.info>
	<502BC1C7.2070002@uvic.ca>
Message-ID: <502BC2B4.8090605@retired.ox.ac.uk>

On 15/08/12 16:35, Martin Holmes wrote:

> I think <listApp> differs a bit from <interpGrp> et al because it
> contains actual transcription from source texts (in the <app> element),
> so it does actually seem wrong to put it in the header.

Entirely agree.

From kevin.s.hawkins at ultraslavonic.info  Wed Aug 15 11:42:09 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Wed, 15 Aug 2012 11:42:09 -0400
Subject: [tei-council] Take a look at <listApp> spec
In-Reply-To: <502BC1C7.2070002@uvic.ca>
References: <502A9081.9070203@uvic.ca> <502AEA22.3080401@ultraslavonic.info>
	<502BC1C7.2070002@uvic.ca>
Message-ID: <502BC351.5050009@ultraslavonic.info>

While the text inside <listApp> may be found in the text of the source 
document in various places, the fact that this info is pulled together 
in one place but the encoder doesn't know where to put it makes it seem 
to me much like descriptive bibliographic metadata.  But in any case, I 
would like to see the note added not only to <listApp> *but also to 
<interpGrp> and any other similar elements*.  I know that I have been in 
Council meetings where <interpGrp> was compared to some other element, 
but I no longer remember what it was.  :(

On 8/15/2012 11:35 AM, Martin Holmes wrote:
> Hi Kevin,
>
> Re the <ptr> thing: I think Sebastian has already fixed it.
>
> On this question:
>
>> b) I see the note you added for <listApp>, but it feels wrong to me to
>> include this note if we don't also include it for <interpGrp> and any
>> other elements that feel a bit like metadata to most of us but can
>> appear within <text> because they sometimes occur there in source
>> documents. So I'm inclined to add this point to clarification to
>> <interpGrp> as well, plus any other such elements. (I know there are
>> others out there because people have mentioned them, but I don't
>> remember any of them or how to find them.)
>
> That's a good point, and I think it perhaps should be included elsewhere
> too. The note is:
>
> "<listApp> elements would normally be located in the back part of a
> document, but they may appear elsewhere."
>
> My intention was to give some guidance on where lists of standoff <app>s
> might appear in the document, for people who were simply looking for a
> recommendation, and encourage a common practice, without shutting the
> door to other options. With regard to elements that can appear virtually
> anywhere in a document, I often find myself asking "Where do people
> _usually_ put them?"
>
> I think <listApp> differs a bit from <interpGrp> et al because it
> contains actual transcription from source texts (in the <app> element),
> so it does actually seem wrong to put it in the header.
>
> But do you really think the note should be removed from <listApp> until
> it is also added elsewhere? It seems perverse to remove a useful note
> simply because there are other places where similarly useful notes
> aren't yet provided.
>
> Cheers,
> Martin
>
>
> On 12-08-14 05:15 PM, Kevin Hawkins wrote:
>> Two things:
>>
>> a) I notice that <ptr/>s are rendered differently in your build than in
>> the latest release. I suspect this is fallout from the fix that you
>> and/or Sebastian did to make URLs relative instead of absolute.
>>
>> So as not to confuse the matter, here's a different element definition.
>> Compare the links after the <desc>:
>>
>> http://teijenkins.hcmc.uvic.ca:8080/job/TEIP5-Documentation/lastSuccessfulBuild/artifact/Guidelines-web/en/html/ref-p.html
>>
>>
>> http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-p.html
>>
>> b) I see the note you added for <listApp>, but it feels wrong to me to
>> include this note if we don't also include it for <interpGrp> and any
>> other elements that feel a bit like metadata to most of us but can
>> appear within <text> because they sometimes occur there in source
>> documents. So I'm inclined to add this point to clarification to
>> <interpGrp> as well, plus any other such elements. (I know there are
>> others out there because people have mentioned them, but I don't
>> remember any of them or how to find them.)
>>
>> --K.
>>
>> On 8/14/12 1:53 PM, Martin Holmes wrote:
>>> Hi all,
>>>
>>> As part of work arising out of Ann Arbor, I've created an elementSpec
>>> for the new <listApp> element, and added a mention of it to the
>>> Guidelines. You can see the results here:
>>>
>>> <http://teijenkins.hcmc.uvic.ca:8080/job/TEIP5-Documentation/lastSuccessfulBuild/artifact/Guidelines-web/en/html/ref-listApp.html>
>>>
>>>
>>> <http://teijenkins.hcmc.uvic.ca:8080/job/TEIP5-Documentation/lastSuccessfulBuild/artifact/Guidelines-web/en/html/TC.html#TCAPLK>
>>>
>>>
>>> Could you take a look and see if there's anything you think should be
>>> changed?
>>>
>>> There is currently only one example for the element; although I have
>>> been asking around, no others have been forthcoming. I'm not sure
>>> whether we really need another example; I have considered fabricating
>>> one based on other examples in the TC chapter, but I'm not sure it's
>>> really needed -- <listApp> is pretty straightforward -- and I always
>>> think twice these days about making the Guidelines any bigger.
>>>
>>> Cheers,
>>> Martin
>>>
>

From lou.burnard at retired.ox.ac.uk  Wed Aug 15 11:52:59 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Wed, 15 Aug 2012 16:52:59 +0100
Subject: [tei-council] Take a look at <listApp> spec
In-Reply-To: <502BC351.5050009@ultraslavonic.info>
References: <502A9081.9070203@uvic.ca> <502AEA22.3080401@ultraslavonic.info>
	<502BC1C7.2070002@uvic.ca> <502BC351.5050009@ultraslavonic.info>
Message-ID: <502BC5DB.1090902@retired.ox.ac.uk>

There was a question about this on TEI-L just last week, so I agree that 
there is need to explain generically and consistently where we recommend 
people put elements such as <interpGrp> and other members of 
model.global.meta ... but I think we probably need to look at it as a 
distinct issue. There's nothing wrong with leaving Martin's note as it 
stands in <listApp> -- we can always come back to it if we decide it 
should be primetime viewing for all of these things.

And I do continue to think that <listApp> is not in quite the same 
league since <app> is at least some of the time for encoding an 
apparatus already existing in a text, not a set of interpretations added 
to it by the encoder.

   On 15/08/12 16:42, Kevin Hawkins wrote:
> While the text inside <listApp> may be found in the text of the source
> document in various places, the fact that this info is pulled together
> in one place but the encoder doesn't know where to put it makes it seem
> to me much like descriptive bibliographic metadata.  But in any case, I
> would like to see the note added not only to <listApp> *but also to
> <interpGrp> and any other similar elements*.  I know that I have been in
> Council meetings where <interpGrp> was compared to some other element,
> but I no longer remember what it was.  :(
>
> On 8/15/2012 11:35 AM, Martin Holmes wrote:
>> Hi Kevin,
>>
>> Re the <ptr> thing: I think Sebastian has already fixed it.
>>
>> On this question:
>>
>>> b) I see the note you added for <listApp>, but it feels wrong to me to
>>> include this note if we don't also include it for <interpGrp> and any
>>> other elements that feel a bit like metadata to most of us but can
>>> appear within <text> because they sometimes occur there in source
>>> documents. So I'm inclined to add this point to clarification to
>>> <interpGrp> as well, plus any other such elements. (I know there are
>>> others out there because people have mentioned them, but I don't
>>> remember any of them or how to find them.)
>>
>> That's a good point, and I think it perhaps should be included elsewhere
>> too. The note is:
>>
>> "<listApp> elements would normally be located in the back part of a
>> document, but they may appear elsewhere."
>>
>> My intention was to give some guidance on where lists of standoff <app>s
>> might appear in the document, for people who were simply looking for a
>> recommendation, and encourage a common practice, without shutting the
>> door to other options. With regard to elements that can appear virtually
>> anywhere in a document, I often find myself asking "Where do people
>> _usually_ put them?"
>>
>> I think <listApp> differs a bit from <interpGrp> et al because it
>> contains actual transcription from source texts (in the <app> element),
>> so it does actually seem wrong to put it in the header.
>>
>> But do you really think the note should be removed from <listApp> until
>> it is also added elsewhere? It seems perverse to remove a useful note
>> simply because there are other places where similarly useful notes
>> aren't yet provided.
>>
>> Cheers,
>> Martin
>>
>>
>> On 12-08-14 05:15 PM, Kevin Hawkins wrote:
>>> Two things:
>>>
>>> a) I notice that <ptr/>s are rendered differently in your build than in
>>> the latest release. I suspect this is fallout from the fix that you
>>> and/or Sebastian did to make URLs relative instead of absolute.
>>>
>>> So as not to confuse the matter, here's a different element definition.
>>> Compare the links after the <desc>:
>>>
>>> http://teijenkins.hcmc.uvic.ca:8080/job/TEIP5-Documentation/lastSuccessfulBuild/artifact/Guidelines-web/en/html/ref-p.html
>>>
>>>
>>> http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-p.html
>>>
>>> b) I see the note you added for <listApp>, but it feels wrong to me to
>>> include this note if we don't also include it for <interpGrp> and any
>>> other elements that feel a bit like metadata to most of us but can
>>> appear within <text> because they sometimes occur there in source
>>> documents. So I'm inclined to add this point to clarification to
>>> <interpGrp> as well, plus any other such elements. (I know there are
>>> others out there because people have mentioned them, but I don't
>>> remember any of them or how to find them.)
>>>
>>> --K.
>>>
>>> On 8/14/12 1:53 PM, Martin Holmes wrote:
>>>> Hi all,
>>>>
>>>> As part of work arising out of Ann Arbor, I've created an elementSpec
>>>> for the new <listApp> element, and added a mention of it to the
>>>> Guidelines. You can see the results here:
>>>>
>>>> <http://teijenkins.hcmc.uvic.ca:8080/job/TEIP5-Documentation/lastSuccessfulBuild/artifact/Guidelines-web/en/html/ref-listApp.html>
>>>>
>>>>
>>>> <http://teijenkins.hcmc.uvic.ca:8080/job/TEIP5-Documentation/lastSuccessfulBuild/artifact/Guidelines-web/en/html/TC.html#TCAPLK>
>>>>
>>>>
>>>> Could you take a look and see if there's anything you think should be
>>>> changed?
>>>>
>>>> There is currently only one example for the element; although I have
>>>> been asking around, no others have been forthcoming. I'm not sure
>>>> whether we really need another example; I have considered fabricating
>>>> one based on other examples in the TC chapter, but I'm not sure it's
>>>> really needed -- <listApp> is pretty straightforward -- and I always
>>>> think twice these days about making the Guidelines any bigger.
>>>>
>>>> Cheers,
>>>> Martin
>>>>
>>


From mholmes at uvic.ca  Wed Aug 15 11:53:29 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Wed, 15 Aug 2012 08:53:29 -0700
Subject: [tei-council] Dates and calendars
In-Reply-To: <502B89FF.3080400@kcl.ac.uk>
References: <502577FD.1070603@uvic.ca> <5028D3E1.80708@kcl.ac.uk>
	<5028E733.3070706@retired.ox.ac.uk> <50293CFC.7090208@uvic.ca>
	<502A3342.6090301@kcl.ac.uk> <502A6F69.40008@uvic.ca>
	<502A9538.8060809@kcl.ac.uk>	<502AAD8F.4040607@retired.ox.ac.uk>
	<502AB92C.80503@uvic.ca> <502B89FF.3080400@kcl.ac.uk>
Message-ID: <502BC5F9.2030501@uvic.ca>

On 12-08-15 04:37 AM, Gabriel Bodard wrote:
> On 2012-08-14 21:46, Martin Holmes wrote:
>> So I think it's important to be able to use @calendar whenever you use
>> @*-custom, and @calendar SHOULD be taken to refer to the values of
>> @*-custom. In other words, I think the definition of @calendar should be
>> expanded thus:
>>
>> "indicates the system or calendar to which the date represented by the
>> content of this element, and/or the dates expressed in attributes from
>> att.datable.custom, belong."
>>
>> Without this, there's no way to provide a formal link from a date like this:
>>
>> <date when-custom="3050"/>
>>
>> to a calendar (e.g. Anno Mundi).
>
> Surely that's precisely what @datingMethod is for? <date
> when-custom="3050" datingMethod="#anno_mundi"/> means I'm normalizing a
> date to the AM calendar (which is defined in a <calendar> element with
> @xml:id=anno_mundi).

I had completely misunderstood that. I assumed that because it's defined 
like this:

"datingMethod	supplies a pointer to a calendarDesc element or other 
means of interpreting the values of the custom dating attributes."

i.e. pointing to a <calendarDesc> rather than a <calendar>, it was 
pointing to some kind of textual description of how the dating method 
actually worked, rather than what calendar it was. Obviously not, since 
<calendarDesc> can contain only <calendar> elements.

(But shouldn't that definition be amended to "...pointer to a <calendar> 
element..."? A <calendarDesc> is likely to contain multiple <calendar> 
elements, and you'd presumably want to point to only one of them.)

> The distinction between @calendar and @datingMethod is very clear (the
> former defines the content of the element, the latter the @*-custom
> attributes). Martin's suggestion is premised on the fact that in all of
> the examples we are imagining the two are the same, so it seems an odd
> redundancy to say:
>
> <date from-custom="1547" to-custom="1633" calendar="#julian"
> datingMethod="#julian">1547-1633</date>
>
> Which is indeed a pain (I might be inclined to say that when
> @datingMethod is absent, we assume the *-custom attributes follow the
> same calendar as defined in @calendar, but that makes me slightly nervous).

It is a pain, indeed, although I see your point. I stand corrected. I'll 
use both together, then.

Cheers,
Martin

> But consider the following cases where the transcribed date and the
> non-Gregorian normalization are different calendars. It is the norm in
> classical studies to normalize all dates to the proleptic Julian
> calendar, to avoid saying something like: <date when="-0044-03-13">the
> Ides of March</date> (which should be March 15th). This is true even if
> the date we're encoding is not Julian, but in some other form: "Pachon
> 19, 12th year of the reign of Tiberius" or "11 October, 4th Indiction"
>
> For these we'd use something like @calendar="#romano-egyptian"
> @datingMethod="#julian".
>
> I'm not sure it's a very good idea to expect @calendar to serve double
> service as Martin suggests...
>
> G
>
>

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From mholmes at uvic.ca  Wed Aug 15 12:09:46 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Wed, 15 Aug 2012 09:09:46 -0700
Subject: [tei-council] Fwd:  extra artefacts
In-Reply-To: <A0D4AE2D-2AE0-406D-A07D-00BB11E6785A@it.ox.ac.uk>
References: <DD0D8D0E-0A60-41D5-A4C7-EC724C13B72C@it.ox.ac.uk>
	<A0D4AE2D-2AE0-406D-A07D-00BB11E6785A@it.ox.ac.uk>
Message-ID: <502BC9CA.90101@uvic.ca>

I think these are an all-around Good Thing, and I'd definitely like to 
see them included. Where should they go? How about P5/Utilities/support?

Cheers,
Martin

On 12-08-15 05:13 AM, Sebastian Rahtz wrote:
> my message below didn't get any yay or nay responses.
>
> can I get some feeling from folks over whether we should be
> providing these beasts?
>
> Sebastian
>
> Begin forwarded message:
>
>> From: Sebastian Rahtz <sebastian.rahtz at it.ox.ac.uk>
>> Subject: Re: [tei-council] extra artefacts
>> Date: 7 August 2012 23:14:01 BST
>> To: <James.Cummings at it.ox.ac.uk>
>> Cc: <tei-council at lists.village.Virginia.EDU>
>>
>> How about this:
>>
>> Source and data support files for TEI Guidelines
>>
>> In addition to the schema modules and example customizations generated for each
>> release of the Guidelines, a set of files are provided in the xml/tei/odd/ directory
>> which are for use by those writing TEI tools such as editors or visualizations.
>>
>> 	p5attlist.txt
>> This is a text file with a comma-separated cataligue of all the attributes available on TEI elements,
>> list the element or class name, the attribute name, the datatype, and  an indication ("multiple"
>> or "single") as to whether it can contain multiple values. eg
>> 	att.ascribed,who,data.pointer,multiple
>>
>>
>> 	p5subset.json
>> This is a representation of all TEI modules, classes, elements and attributes (with their
>> descriptions) in JSON format for consumption by Javascript tools in web applications. For
>> example, this fragment provides summary information about the <gi>ab</gi> element:
>>
>> 	p5subset.xml
>> This is copy of the reference component of the TEI source, extracting all
>> the <gi>elementSpec</gi>, <gi>classSpec</gi>, <gi>macroSpec</gi>
>> and <gi>moduleSpec</gi> elements, with descriptions. It does not include
>> the text of the chapters of the Guidelines, and is intended for use by ODD processors
>> which need to access all of the TEI components in a convenient single file.
>>
>> 	stripspace.xsl.model
>> This is a fragmeht of XSL which can be added to any transformation which
>> is being applied to a TEI document. It consists of a <xsl:strip-space> element
>> which lists all the elements which can <emph>not</emph> contain character
>> data. This tells the processor it can ignore white space around child components
>> of these elements.
>
> --
> Sebastian Rahtz
> Director (Research Support) of Academic IT Services
> University of Oxford IT Services
> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From sebastian.rahtz at it.ox.ac.uk  Wed Aug 15 12:12:05 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Wed, 15 Aug 2012 16:12:05 +0000
Subject: [tei-council] Fwd:  extra artefacts
In-Reply-To: <502BC9CA.90101@uvic.ca>
References: <DD0D8D0E-0A60-41D5-A4C7-EC724C13B72C@it.ox.ac.uk>
	<A0D4AE2D-2AE0-406D-A07D-00BB11E6785A@it.ox.ac.uk>
	<502BC9CA.90101@uvic.ca>
Message-ID: <5CECD2C1-9C1D-4EC5-90A0-59D3C4C06508@it.ox.ac.uk>


On 15 Aug 2012, at 17:09, Martin Holmes <mholmes at uvic.ca>
 wrote:

> I think these are an all-around Good Thing, and I'd definitely like to see them included. Where should they go? How about P5/Utilities/support?



it does say there

"a set of files are provided in the xml/tei/odd/ directory"

so unless you feel strongly, I'd rather leave them there, alongside p5subset.xml
--
Sebastian Rahtz      
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431


From gabriel.bodard at kcl.ac.uk  Wed Aug 15 12:49:24 2012
From: gabriel.bodard at kcl.ac.uk (Gabriel Bodard)
Date: Wed, 15 Aug 2012 17:49:24 +0100
Subject: [tei-council] Dates and calendars
In-Reply-To: <502BC5F9.2030501@uvic.ca>
References: <502577FD.1070603@uvic.ca> <5028D3E1.80708@kcl.ac.uk>
	<5028E733.3070706@retired.ox.ac.uk> <50293CFC.7090208@uvic.ca>
	<502A3342.6090301@kcl.ac.uk> <502A6F69.40008@uvic.ca>
	<502A9538.8060809@kcl.ac.uk>	<502AAD8F.4040607@retired.ox.ac.uk>
	<502AB92C.80503@uvic.ca> <502B89FF.3080400@kcl.ac.uk>
	<502BC5F9.2030501@uvic.ca>
Message-ID: <502BD314.9040202@kcl.ac.uk>

On 2012-08-15 16:53, Martin Holmes wrote:
> i.e. pointing to a <calendarDesc> rather than a <calendar>, it was
> pointing to some kind of textual description of how the dating method
> actually worked, rather than what calendar it was. Obviously not, since
> <calendarDesc> can contain only <calendar> elements.
>
> (But shouldn't that definition be amended to "...pointer to a <calendar>
> element..."? A <calendarDesc> is likely to contain multiple <calendar>
> elements, and you'd presumably want to point to only one of them.)

Agreed. Whoever wrote <calendarDesc> there was not thinking clearly. 
You'd think this was a half-assed element that someone only invented a 
few months ago, or something. ;-)

No seriously, fix it. (Or I can.)

G

-- 
Dr Gabriel BODARD
(Research Associate in Digital Epigraphy)

Department of Digital Humanities
King's College London
26-29 Drury Lane
London WC2B 5RL

Email: gabriel.bodard at kcl.ac.uk
Tel: +44 (0)20 7848 1388
Fax: +44 (0)20 7848 2980

http://www.digitalclassicist.org/
http://www.currentepigraphy.org/

From mholmes at uvic.ca  Wed Aug 15 13:27:49 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Wed, 15 Aug 2012 10:27:49 -0700
Subject: [tei-council] Dates and calendars
In-Reply-To: <502BD314.9040202@kcl.ac.uk>
References: <502577FD.1070603@uvic.ca> <5028D3E1.80708@kcl.ac.uk>
	<5028E733.3070706@retired.ox.ac.uk> <50293CFC.7090208@uvic.ca>
	<502A3342.6090301@kcl.ac.uk> <502A6F69.40008@uvic.ca>
	<502A9538.8060809@kcl.ac.uk>	<502AAD8F.4040607@retired.ox.ac.uk>
	<502AB92C.80503@uvic.ca> <502B89FF.3080400@kcl.ac.uk>
	<502BC5F9.2030501@uvic.ca> <502BD314.9040202@kcl.ac.uk>
Message-ID: <502BDC15.1060104@uvic.ca>

On 12-08-15 09:49 AM, Gabriel Bodard wrote:
> On 2012-08-15 16:53, Martin Holmes wrote:
>> i.e. pointing to a <calendarDesc> rather than a <calendar>, it was
>> pointing to some kind of textual description of how the dating method
>> actually worked, rather than what calendar it was. Obviously not, since
>> <calendarDesc> can contain only <calendar> elements.
>>
>> (But shouldn't that definition be amended to "...pointer to a <calendar>
>> element..."? A <calendarDesc> is likely to contain multiple <calendar>
>> elements, and you'd presumably want to point to only one of them.)
>
> Agreed. Whoever wrote <calendarDesc> there was not thinking clearly.
> You'd think this was a half-assed element that someone only invented a
> few months ago, or something. ;-)
>
> No seriously, fix it. (Or I can.)

Done.

Cheers,
Martin

>
> G
>

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From dsewell at virginia.edu  Thu Aug 16 10:25:19 2012
From: dsewell at virginia.edu (David Sewell)
Date: Thu, 16 Aug 2012 10:25:19 -0400 (EDT)
Subject: [tei-council] Self-nominations for Council, Board
Message-ID: <alpine.OSX.2.00.1208161021400.4740@lister.ei.virginia.edu>

This is just to encourage any of you whose term is expiring at the end of 2012, 
and who are willing to serve for another term on Board or Council, to send a 
self-nomination to the nominating committee (nominations at tei-c.org). It's not a 
mark of hubris! It will help the committee judge whether we're going to have an 
adequate pool of candidates, or whether we all may need to do active recruiting.

Also, I think a conditional self-nomination would be okay: in other words, 
indicate that you are willing to serve, but with the option of withdrawing your 
self-nomination if we get plenty of qualified candidates.

Thanks,

David

-- 
David Sewell, Editorial and Technical Manager
ROTUNDA, The University of Virginia Press
PO Box 400314, Charlottesville, VA 22904-4314 USA
Email: dsewell at virginia.edu   Tel: +1 434 924 9973
Web: http://rotunda.upress.virginia.edu/

From dsewell at virginia.edu  Fri Aug 31 10:30:06 2012
From: dsewell at virginia.edu (David Sewell)
Date: Fri, 31 Aug 2012 10:30:06 -0400 (EDT)
Subject: [tei-council] Vacation schedule
Message-ID: <alpine.OSX.2.00.1208311022540.8753@lister.ei.virginia.edu>

Dear Board and Council members,

This is to let you know that I will be away from the office September 4-10 
inclusive, and will have limited and intermittent access to email while I am 
gone. If you have any urgent email to my attention, please use my GMail account, 
DavidR.Sewell at gmail.com.

For matters connected with the TEI website or server: James, Lou, and Kevin are 
among the people who know how to add and edit pages via OpenCMS; and I gather 
that Sebastian is now backed up by Gabby and Martin Holmes as release 
technicians. If the server itself is offline or Roma is broken, contact system 
administrator Shayne Brandon: wsb4q at Virginia.EDU.

David

-- 
David Sewell, Editorial and Technical Manager
ROTUNDA, The University of Virginia Press
PO Box 400314, Charlottesville, VA 22904-4314 USA
Email: dsewell at virginia.edu   Tel: +1 434 924 9973
Web: http://rotunda.upress.virginia.edu/

From kevin.s.hawkins at ultraslavonic.info  Sat Sep  1 21:12:17 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Sat, 01 Sep 2012 21:12:17 -0400
Subject: [tei-council] experimental modules?
Message-ID: <5042B271.5070909@ultraslavonic.info>

I just noticed that both 
http://www.tei-c.org/Guidelines/Customization/odds.xml and the Roma 
interface show tei_xinclude and tei_dictionaries as experimental.  Is 
this still the case?  They're not listed that way at 
http://www.tei-c.org/Guidelines/Customization/ .

From kevin.s.hawkins at ultraslavonic.info  Mon Sep  3 22:28:05 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Mon, 03 Sep 2012 22:28:05 -0400
Subject: [tei-council] experimental modules?
In-Reply-To: <3D11821D65070D4BADB84B46F7FE203C8BCF88@MBX09.ad.oak.ox.ac.uk>
References: <5042B271.5070909@ultraslavonic.info>
	<3D11821D65070D4BADB84B46F7FE203C8BCF88@MBX09.ad.oak.ox.ac.uk>
Message-ID: <50456735.5050603@ultraslavonic.info>

Sebastian responded to me, but I'm going to take this back to the list.

I've just realized that http://www.tei-c.org/Guidelines/Customization/ 
only lists XInclude as experimental but shows the dictionaries one as 
non-experimental.  Who would know which customizations are experimental?

I am unaware of any re-examination of sample customizations, so I will 
leave everything as it is for now.

On 9/3/12 6:04 AM, Sebastian Rahtz wrote:
> its not the _modules_ which are experimental, but the customization.
>
> I think we should zap the dictionary one entirely, actually. But isnt this
> part of a re-examination of the sample customizations?
>
> Sebastian Rahtz
> Oxford University Computing Services
>
> ________________________________________
> From: tei-council-bounces at lists.village.Virginia.EDU [tei-council-bounces at lists.village.Virginia.EDU] on behalf of Kevin Hawkins [kevin.s.hawkins at ultraslavonic.info]
> Sent: 02 September 2012 02:12
> To: tei-council at lists.village.virginia.edu
> Subject: [tei-council] experimental modules?
>
> I just noticed that both
> http://www.tei-c.org/Guidelines/Customization/odds.xml and the Roma
> interface show tei_xinclude and tei_dictionaries as experimental.  Is
> this still the case?  They're not listed that way at
> http://www.tei-c.org/Guidelines/Customization/ .
> --
> 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 it.ox.ac.uk  Tue Sep  4 06:52:24 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Tue, 4 Sep 2012 10:52:24 +0000
Subject: [tei-council] experimental modules?
In-Reply-To: <50456735.5050603@ultraslavonic.info>
References: <5042B271.5070909@ultraslavonic.info>
	<3D11821D65070D4BADB84B46F7FE203C8BCF88@MBX09.ad.oak.ox.ac.uk>
	<50456735.5050603@ultraslavonic.info>
Message-ID: <79128BC8-9893-4913-9C9E-D3E20A5DFB41@it.ox.ac.uk>


On 4 Sep 2012, at 03:28, Kevin Hawkins <kevin.s.hawkins at ultraslavonic.info> wrote:

> Sebastian responded to me, but I'm going to take this back to the list.
> 
sorry, my mistake, meant to be to list


> I've just realized that http://www.tei-c.org/Guidelines/Customization/ 
> only lists XInclude as experimental but shows the dictionaries one as 
> non-experimental.  Who would know which customizations are experimental?
> 
I don't think any are any more, are they?

I just changed Roma (for next release) to remove MS, dict, speech, drama, corpus from list;
I think they are misleading. do you all agree? 

> I am unaware of any re-examination of sample customisations

um, where _is_ this being discussed? i thought it was here but I may well misremember
and its just a party conversation with Syd
--
Sebastian Rahtz      
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431


From mholmes at uvic.ca  Tue Sep  4 11:54:10 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Tue, 4 Sep 2012 08:54:10 -0700
Subject: [tei-council] experimental modules?
In-Reply-To: <79128BC8-9893-4913-9C9E-D3E20A5DFB41@it.ox.ac.uk>
References: <5042B271.5070909@ultraslavonic.info>
	<3D11821D65070D4BADB84B46F7FE203C8BCF88@MBX09.ad.oak.ox.ac.uk>
	<50456735.5050603@ultraslavonic.info>
	<79128BC8-9893-4913-9C9E-D3E20A5DFB41@it.ox.ac.uk>
Message-ID: <50462422.8020707@uvic.ca>



On 12-09-04 03:52 AM, Sebastian Rahtz wrote:
>
> On 4 Sep 2012, at 03:28, Kevin Hawkins <kevin.s.hawkins at ultraslavonic.info> wrote:
>
>> Sebastian responded to me, but I'm going to take this back to the list.
>>
> sorry, my mistake, meant to be to list
>
>
>> I've just realized that http://www.tei-c.org/Guidelines/Customization/
>> only lists XInclude as experimental but shows the dictionaries one as
>> non-experimental.  Who would know which customizations are experimental?
>>
> I don't think any are any more, are they?
>
> I just changed Roma (for next release) to remove MS, dict, speech, drama, corpus from list;
> I think they are misleading. do you all agree?

Could you explain exactly what you've done there? I'm not following. 
What list have they been removed from, and why are they misleading?

Cheers,
Martin

>> I am unaware of any re-examination of sample customisations
>
> um, where _is_ this being discussed? i thought it was here but I may well misremember
> and its just a party conversation with Syd
> --
> Sebastian Rahtz
> Director (Research Support) of Academic IT Services
> University of Oxford IT Services
> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From lou.burnard at retired.ox.ac.uk  Tue Sep  4 12:02:39 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Tue, 4 Sep 2012 16:02:39 +0000
Subject: [tei-council] experimental modules?
In-Reply-To: <50462422.8020707@uvic.ca>
References: <5042B271.5070909@ultraslavonic.info>
	<3D11821D65070D4BADB84B46F7FE203C8BCF88@MBX09.ad.oak.ox.ac.uk>
	<50456735.5050603@ultraslavonic.info>
	<79128BC8-9893-4913-9C9E-D3E20A5DFB41@it.ox.ac.uk>,
	<50462422.8020707@uvic.ca>
Message-ID: <762A68C71238E2469EBDCDF70ADB2494098A8A@MBX01.ad.oak.ox.ac.uk>

Once you start looking there are quite a few things to improve on this page...

1. Why is there a link to the doc for Lite but not for any of the others?

2. Why is ODD regarded as experimental or restricted? dont we want anyone to use it?

3. On what basis are these "TEI community" customisations selected? Is MEP still being maintained or used? has it progressed beyond P3?


________________________________________
From: tei-council-bounces at lists.village.Virginia.EDU [tei-council-bounces at lists.village.Virginia.EDU] on behalf of Martin Holmes [mholmes at uvic.ca]
Sent: 04 September 2012 16:54
To: <tei-council at lists.village.virginia.edu>
Subject: Re: [tei-council] experimental modules?

On 12-09-04 03:52 AM, Sebastian Rahtz wrote:
>
> On 4 Sep 2012, at 03:28, Kevin Hawkins <kevin.s.hawkins at ultraslavonic.info> wrote:
>
>> Sebastian responded to me, but I'm going to take this back to the list.
>>
> sorry, my mistake, meant to be to list
>
>
>> I've just realized that http://www.tei-c.org/Guidelines/Customization/
>> only lists XInclude as experimental but shows the dictionaries one as
>> non-experimental.  Who would know which customizations are experimental?
>>
> I don't think any are any more, are they?
>
> I just changed Roma (for next release) to remove MS, dict, speech, drama, corpus from list;
> I think they are misleading. do you all agree?

Could you explain exactly what you've done there? I'm not following.
What list have they been removed from, and why are they misleading?

Cheers,
Martin

>> I am unaware of any re-examination of sample customisations
>
> um, where _is_ this being discussed? i thought it was here but I may well misremember
> and its just a party conversation with Syd
> --
> Sebastian Rahtz
> Director (Research Support) of Academic IT Services
> University of Oxford IT Services
> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>

--
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)
--
tei-council mailing list
tei-council at lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

PLEASE NOTE: postings to this list are publicly archived

From kevin.s.hawkins at ultraslavonic.info  Tue Sep  4 12:34:51 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Tue, 04 Sep 2012 12:34:51 -0400
Subject: [tei-council] experimental modules?
In-Reply-To: <762A68C71238E2469EBDCDF70ADB2494098A8A@MBX01.ad.oak.ox.ac.uk>
References: <5042B271.5070909@ultraslavonic.info>	<3D11821D65070D4BADB84B46F7FE203C8BCF88@MBX09.ad.oak.ox.ac.uk>	<50456735.5050603@ultraslavonic.info>	<79128BC8-9893-4913-9C9E-D3E20A5DFB41@it.ox.ac.uk>,
	<50462422.8020707@uvic.ca>
	<762A68C71238E2469EBDCDF70ADB2494098A8A@MBX01.ad.oak.ox.ac.uk>
Message-ID: <50462DAB.3060806@ultraslavonic.info>

To address those questions of Lou's that I feel I can address ...

On 9/4/2012 12:02 PM, Lou Burnard wrote:
> Once you start looking there are quite a few things to improve on this page...
>
> 1. Why is there a link to the doc for Lite but not for any of the others?

I assume Lou is referring to 
http://www.tei-c.org/Guidelines/Customization/ and not 
http://www.tei-c.org/Guidelines/Customization/odds.xml .  The former 
includes a link to the HTML and PDF versions of Lite and Tite.  Only 
these are included because they are on the only ones I have ever found 
within http://www.tei-c.org/release/doc/tei-p5-exemplars/ .  (I see that 
the PDF links no longer work.  Sebastian, have they moved?)

If we can and should produce documentation of the other customzations, I 
would be happy to add them to the site.

> 2. Why is ODD regarded as experimental or restricted? dont we want anyone to use it?

Right, this is what I've been trying to get at with this email thread.

> 3. On what basis are these "TEI community" customisations selected? Is MEP still being maintained or used? has it progressed beyond P3?

(These customizations are listed at 
http://www.tei-c.org/Guidelines/Customization/ .)

I'm not sure who created this list, but since becoming assistant 
webmaster for the TEI-C I have added the link to TEI with Music Notation 
after it was announced on TEI-L and added the Best Practices for TEI in 
Libraries to this list as we've agreed in our recent meetings.  My 
understanding is that any customization not maintained by the Council 
can be added here.  While we could formulate some sort of selection 
process, I find "TEI Community Customizations" to be clear that these 
are not endorsed by the TEI, so I'm not sure this is needed.  We could 
add a brief statement to this effect just after the heading.  Thoughts?

On the question of MEP, since the website no longer exists, I am not 
opposed to removing it from the list.  MEP is incidentally included in 
the list of projects on TEI website, so it won't disappear from the 
historical record by removing it.  Thoughts?

--Kevin

From kevin.s.hawkins at ultraslavonic.info  Tue Sep  4 20:50:38 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Tue, 04 Sep 2012 20:50:38 -0400
Subject: [tei-council] tagdocs elements inside <graphic>
Message-ID: <5046A1DE.2000409@ultraslavonic.info>

In implementing bug 2812295 ( http://purl.org/tei/bug/2812295 ) in 
spring 2010, we made <graphic> a non-empty element that can contain 
model.glossLike*.  But this had what I suspect was an unintended 
consequence: permitting two members of the tagdocs module as children of 
<graphic>: altIdent and equiv.  Do we want to revisit either the way 
this was implemented or take a look at the membership of model.glossLike?

From rwelzenbach at gmail.com  Tue Sep  4 20:52:23 2012
From: rwelzenbach at gmail.com (Rebecca Welzenbach)
Date: Tue, 4 Sep 2012 20:52:23 -0400
Subject: [tei-council] experimental modules?
In-Reply-To: <50462DAB.3060806@ultraslavonic.info>
References: <5042B271.5070909@ultraslavonic.info>
	<3D11821D65070D4BADB84B46F7FE203C8BCF88@MBX09.ad.oak.ox.ac.uk>
	<50456735.5050603@ultraslavonic.info>
	<79128BC8-9893-4913-9C9E-D3E20A5DFB41@it.ox.ac.uk>
	<50462422.8020707@uvic.ca>
	<762A68C71238E2469EBDCDF70ADB2494098A8A@MBX01.ad.oak.ox.ac.uk>
	<50462DAB.3060806@ultraslavonic.info>
Message-ID: <CAA2irtJFqktwUFOYQGrrRzjNMVOubRuU8OeswFSWMQZTWkKyiw@mail.gmail.com>

Earlier, Sebastian wrote

> I just changed Roma (for next release) to remove MS, dict, speech, drama, corpus from list;
> I think they are misleading. do you all agree?

Do you mean you removed them from the "Create Customization from
template" drop down menu at http://www.tei-c.org/Roma/?  I second
Martin's request for clarification about why it is misleading to
include them here.

I agree that http://www.tei-c.org/Guidelines/Customization/ could be
clearer in several ways.

1) Would it make sense to change the heading of "Customizations
provided by the TEI Consortium" to "Customizations maintained by the
TEI Consortium"? (or "supported"?) To me, this clarifies that
customizations on this list involve modules that are part of the
Guidelines and are updated with each release.

2) I agree that the label "more restricted or experimental" is a
problem. "Restricted" and "experimental" aren't the same thing, and
it's not clear whether a customization on this list falls under one or
the other, so this grouping isn't useful. It's also not clear what or
who is "restricted," and in what way. I think it means "customization
with a small, highly specialized set of tags," but it would be easy to
interpret this as "only available to subscribers/experts/anyone but
you." Further, if you did guess the right meaning of "restricted," you
might be even more confused because most of the customizations on this
list are expansive (TEI plus), not restricted!

My guess is that the Odds customization is listed here not because
it's experimental, but because it's a very restricted tag set. But
this should be changed so that Odds is presented on its own. It's
designed for a totally different purpose than the other
customizations. Presenting it as belonging to the same group as "TEI
with MathML" is misleading.

The experimental customizations, if they can be confirmed, could be
grouped together, but it might be better to just do away with this
grouping altogether.

3) To reply to Kevin's comment:

>I find "TEI Community Customizations" to be clear that these
> are not endorsed by the TEI, so I'm not sure this is needed.  We could
> add a brief statement to this effect just after the heading.  Thoughts?

Once the other categories are clarified, I think "TEI Community
Customizations" becomes sufficiently clear,

Becky

From rwelzenbach at gmail.com  Tue Sep  4 21:27:39 2012
From: rwelzenbach at gmail.com (Rebecca Welzenbach)
Date: Tue, 4 Sep 2012 21:27:39 -0400
Subject: [tei-council] tagdocs elements inside <graphic>
In-Reply-To: <5046A1DE.2000409@ultraslavonic.info>
References: <5046A1DE.2000409@ultraslavonic.info>
Message-ID: <CAA2irtJ_cbmpm7TxHxn66GYmnn9XC0t1XV-FbMk=y08UR=dVZw@mail.gmail.com>

Running with Kevin's second option: I'm not sure I understand why
<altIdent> and <equiv> are members of model.glossLike. What's the
history here?

If allowing <altIdent> and <equiv> via model.glossLike is
unintended/undesirable for <graphic>, is it also
unintended/undesirable for the other elements and classes that use
model.glossLike and are not part of the tagdocs module?

Becky

On Tue, Sep 4, 2012 at 8:50 PM, Kevin Hawkins
<kevin.s.hawkins at ultraslavonic.info> wrote:
> In implementing bug 2812295 ( http://purl.org/tei/bug/2812295 ) in
> spring 2010, we made <graphic> a non-empty element that can contain
> model.glossLike*.  But this had what I suspect was an unintended
> consequence: permitting two members of the tagdocs module as children of
> <graphic>: altIdent and equiv.  Do we want to revisit either the way
> this was implemented or take a look at the membership of model.glossLike?
> --
> 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 it.ox.ac.uk  Wed Sep  5 04:05:01 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Wed, 5 Sep 2012 08:05:01 +0000
Subject: [tei-council] tagdocs elements inside <graphic>
In-Reply-To: <CAA2irtJ_cbmpm7TxHxn66GYmnn9XC0t1XV-FbMk=y08UR=dVZw@mail.gmail.com>
References: <5046A1DE.2000409@ultraslavonic.info>
	<CAA2irtJ_cbmpm7TxHxn66GYmnn9XC0t1XV-FbMk=y08UR=dVZw@mail.gmail.com>
Message-ID: <72E10C04-16B9-4E90-B950-AE7427ED09B2@it.ox.ac.uk>

Sorry for being cryptic.

At the moment, Roma offers you a choice of


<option value="tei_bare.odd">TEI Absolutely Bare</option>
<option value="teilite.odd">TEI Lite</option>
<option value="tei_tite.odd">TEI Tite</option>
<option value="tei_corpus.odd">TEI for Linguistic Corpora</option>
<option value="tei_ms.odd">TEI for Manuscript Description</option>
<option value="tei_drama.odd">TEI with Drama</option>
<option value="tei_speech.odd">TEI for Speech Representation</option>
<option value="tei_odds.odd">TEI for authoring ODD</option>
<option value="tei_svg.odd">TEI with SVG</option>
<option value="tei_math.odd">TEI with MathML</option>
<option value="tei_xinclude.odd">TEI with XInclude (experimental)</option>
<option value="tei_its.odd">TEI with W3C ITS</option>
<option value="tei_dictionaries.odd">TEI for Dictionaries (experimental)</option>


as customisations to build on.

Bare, Lite, and Tite make sense; they are coherent and have a purpose. 
SVG, MathML, XInclude, ITS and ODD are also sensible,
as they involve non-obvious techniques which you can't easily
do in plain Roma.

So that leaves Drama, Speech, MS, and Dictionaries. I claim
that none of these are meaningfully useful, documented,
or follow any known recommendation.

Would anyone like to defend them?
--
Sebastian Rahtz      
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431


From sebastian.rahtz at it.ox.ac.uk  Wed Sep  5 04:05:46 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Wed, 5 Sep 2012 08:05:46 +0000
Subject: [tei-council] customisations (was Re: tagdocs elements inside
 <graphic>)
In-Reply-To: <72E10C04-16B9-4E90-B950-AE7427ED09B2@it.ox.ac.uk>
References: <5046A1DE.2000409@ultraslavonic.info>
	<CAA2irtJ_cbmpm7TxHxn66GYmnn9XC0t1XV-FbMk=y08UR=dVZw@mail.gmail.com>
	<72E10C04-16B9-4E90-B950-AE7427ED09B2@it.ox.ac.uk>
Message-ID: <C11E000A-C0B1-43F8-8C28-750FD0FBA246@it.ox.ac.uk>

sorry for being a klutz. replied to wrong message
--
Sebastian Rahtz      
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431


From sebastian.rahtz at it.ox.ac.uk  Wed Sep  5 04:11:09 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Wed, 5 Sep 2012 08:11:09 +0000
Subject: [tei-council] tagdocs elements inside <graphic>
In-Reply-To: <CAA2irtJ_cbmpm7TxHxn66GYmnn9XC0t1XV-FbMk=y08UR=dVZw@mail.gmail.com>
References: <5046A1DE.2000409@ultraslavonic.info>
	<CAA2irtJ_cbmpm7TxHxn66GYmnn9XC0t1XV-FbMk=y08UR=dVZw@mail.gmail.com>
Message-ID: <EA3A00E4-3E33-4648-B3FD-961296835A98@it.ox.ac.uk>


On 5 Sep 2012, at 02:27, Rebecca Welzenbach <rwelzenbach at gmail.com>
 wrote:

> Running with Kevin's second option: I'm not sure I understand why
> <altIdent> and <equiv> are members of model.glossLike. What's the
> history here?
> 
i _think_ we put them in glossLike when that was used mainly
by ODD elements; and then forgot about them when glossLike
was more widely adopted.

> If allowing <altIdent> and <equiv> via model.glossLike is
> unintended/undesirable for <graphic>, is it also
> unintended/undesirable for the other elements and classes that use
> model.glossLike and are not part of the tagdocs module?
> 
I find it difficult to defend equiv and altIdent for most users
of glossLike, I must admit. Were Laurent here, I think he would
find a way of doing it, but the simplest solution would seem
to be to move them to (a new) model.equivLike, and use that
only in classSpec, constrainSpec, elementSpec, macroSpec and valItem

--
Sebastian Rahtz      
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431


From sebastian.rahtz at it.ox.ac.uk  Wed Sep  5 04:46:18 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Wed, 5 Sep 2012 08:46:18 +0000
Subject: [tei-council] experimental modules?
In-Reply-To: <50462DAB.3060806@ultraslavonic.info>
References: <5042B271.5070909@ultraslavonic.info>
	<3D11821D65070D4BADB84B46F7FE203C8BCF88@MBX09.ad.oak.ox.ac.uk>
	<50456735.5050603@ultraslavonic.info>
	<79128BC8-9893-4913-9C9E-D3E20A5DFB41@it.ox.ac.uk>,
	<50462422.8020707@uvic.ca>
	<762A68C71238E2469EBDCDF70ADB2494098A8A@MBX01.ad.oak.ox.ac.uk>
	<50462DAB.3060806@ultraslavonic.info>
Message-ID: <AEDB1292-5B3D-4654-B5F1-6BA04DB8B274@it.ox.ac.uk>


On 4 Sep 2012, at 17:34, Kevin Hawkins <kevin.s.hawkins at ultraslavonic.info>
 wrote:

> I assume Lou is referring to 
> http://www.tei-c.org/Guidelines/Customization/ and not 
> http://www.tei-c.org/Guidelines/Customization/odds.xml .  The former 
> includes a link to the HTML and PDF versions of Lite and Tite.  Only 
> these are included because they are on the only ones I have ever found 
> within http://www.tei-c.org/release/doc/tei-p5-exemplars/ .  (I see that 
> the PDF links no longer work.  Sebastian, have they moved?)
> 
yes, they are (wrongly) in ../html/ instead of ../pdf/

I have just corrected the build script for the next release,
so I suggest you leave the links broken for the moment,
and they will work in future

> If we can and should produce documentation of the other customzations, I 
> would be happy to add them to the site.
> 
what do folks think? I explicitly made Tite and Lite generate docs, as they are

I would remove Speech, Drama, MS, Corpus, Dictionaries
from http://www.tei-c.org/Guidelines/Customization/
for reasons given earlier. they are too trivial, IMHO

but then again, I don't feel that strongly. tell me if they should be restored
to Roma interface
--
Sebastian Rahtz      
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431


From James.Cummings at it.ox.ac.uk  Wed Sep  5 05:13:53 2012
From: James.Cummings at it.ox.ac.uk (James Cummings)
Date: Wed, 05 Sep 2012 10:13:53 +0100
Subject: [tei-council] experimental modules?
In-Reply-To: <AEDB1292-5B3D-4654-B5F1-6BA04DB8B274@it.ox.ac.uk>
References: <5042B271.5070909@ultraslavonic.info>
	<3D11821D65070D4BADB84B46F7FE203C8BCF88@MBX09.ad.oak.ox.ac.uk>
	<50456735.5050603@ultraslavonic.info>
	<79128BC8-9893-4913-9C9E-D3E20A5DFB41@it.ox.ac.uk>,
	<50462422.8020707@uvic.ca>
	<762A68C71238E2469EBDCDF70ADB2494098A8A@MBX01.ad.oak.ox.ac.uk>
	<50462DAB.3060806@ultraslavonic.info>
	<AEDB1292-5B3D-4654-B5F1-6BA04DB8B274@it.ox.ac.uk>
Message-ID: <504717D1.40701@it.ox.ac.uk>

On 05/09/12 09:46, Sebastian Rahtz wrote:
>> If we can and should produce documentation of the other customzations, I
>> would be happy to add them to the site.
>>
> what do folks think? I explicitly made Tite and Lite generate docs, as they are

Does the process of freezing of Lite and Tite affect this at all?

> I would remove Speech, Drama, MS, Corpus, Dictionaries
> from http://www.tei-c.org/Guidelines/Customization/
> for reasons given earlier. they are too trivial, IMHO
>
> but then again, I don't feel that strongly. tell me if they should be restored
> to Roma interface

They were originally supplied as simple example customisations 
but admittedly are really just a selection of modules which isn't 
really a hard stumbling block.

What I do wonder is whether we should be providing templates for 
community-created customisations in Roma that are reasonably 
mature, well-supported, etc. with the prime example here being 
EpiDoc? Is this something communities like that would like? 
Obviously they would need to meet some basic standards (e.g. 
'mature', 'works', 'support to update before releases', etc.)

-James

-- 
Dr James Cummings, researchsupport at it.ox.ac.uk
Research Support, IT Services, University of Oxford

From sebastian.rahtz at it.ox.ac.uk  Wed Sep  5 06:52:11 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Wed, 5 Sep 2012 10:52:11 +0000
Subject: [tei-council] experimental modules?
In-Reply-To: <504717D1.40701@it.ox.ac.uk>
References: <5042B271.5070909@ultraslavonic.info>
	<3D11821D65070D4BADB84B46F7FE203C8BCF88@MBX09.ad.oak.ox.ac.uk>
	<50456735.5050603@ultraslavonic.info>
	<79128BC8-9893-4913-9C9E-D3E20A5DFB41@it.ox.ac.uk>,
	<50462422.8020707@uvic.ca>
	<762A68C71238E2469EBDCDF70ADB2494098A8A@MBX01.ad.oak.ox.ac.uk>
	<50462DAB.3060806@ultraslavonic.info>
	<AEDB1292-5B3D-4654-B5F1-6BA04DB8B274@it.ox.ac.uk>
	<504717D1.40701@it.ox.ac.uk>
Message-ID: <4945534d-6d5d-4c68-99a6-520eef844a44@HUB05.ad.oak.ox.ac.uk>


On 5 Sep 2012, at 10:13, James Cummings <James.Cummings at it.ox.ac.uk>
 wrote:

> On 05/09/12 09:46, Sebastian Rahtz wrote:
>>> If we can and should produce documentation of the other customzations, I
>>> would be happy to add them to the site.
>>> 
>> what do folks think? I explicitly made Tite and Lite generate docs, as they are
> 
> Does the process of freezing of Lite and Tite affect this at all?

no, I don't think so

but the "freezing" of Lite and Tite is (in my memory)
very much up in the air still. I don't sense a consensus
on what to do

> 
> What I do wonder is whether we should be providing templates for 
> community-created customisations in Roma that are reasonably 
> mature, well-supported, etc. with the prime example here being 
> EpiDoc? 

indeed. but you'd have to work out a management process
for this.
--
Sebastian Rahtz      
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431


From gabriel.bodard at kcl.ac.uk  Wed Sep  5 07:26:48 2012
From: gabriel.bodard at kcl.ac.uk (Gabriel Bodard)
Date: Wed, 5 Sep 2012 12:26:48 +0100
Subject: [tei-council] experimental modules?
In-Reply-To: <4945534d-6d5d-4c68-99a6-520eef844a44@HUB05.ad.oak.ox.ac.uk>
References: <5042B271.5070909@ultraslavonic.info>
	<3D11821D65070D4BADB84B46F7FE203C8BCF88@MBX09.ad.oak.ox.ac.uk>
	<50456735.5050603@ultraslavonic.info>
	<79128BC8-9893-4913-9C9E-D3E20A5DFB41@it.ox.ac.uk>,
	<50462422.8020707@uvic.ca>
	<762A68C71238E2469EBDCDF70ADB2494098A8A@MBX01.ad.oak.ox.ac.uk>
	<50462DAB.3060806@ultraslavonic.info>
	<AEDB1292-5B3D-4654-B5F1-6BA04DB8B274@it.ox.ac.uk>
	<504717D1.40701@it.ox.ac.uk>
	<4945534d-6d5d-4c68-99a6-520eef844a44@HUB05.ad.oak.ox.ac.uk>
Message-ID: <504736F8.1020004@kcl.ac.uk>

On 2012-09-05 11:52, Sebastian Rahtz wrote:
> On 5 Sep 2012, at 10:13, James Cummings <James.Cummings at it.ox.ac.uk> wrote:
>> What I do wonder is whether we should be providing templates for
>> community-created customisations in Roma that are reasonably
>> mature, well-supported, etc. with the prime example here being
>> EpiDoc?
>
> indeed. but you'd have to work out a management process
> for this.

I'm tempted by this, but as Sebastian says we'd need to think about how 
we a) manage this process, and b) how the EpiDoc odd releases and TEI 
releases line up (currently I normally make an EpiDoc release a few days 
after each TEI release, to take advantage of new features).

Happy to discuss this (and perhaps float it on the EpiDoc list if that 
would be useful).

G

-- 
Dr Gabriel BODARD
(Research Associate in Digital Epigraphy)

Department of Digital Humanities
King's College London
26-29 Drury Lane
London WC2B 5RL

Email: gabriel.bodard at kcl.ac.uk
Tel: +44 (0)20 7848 1388
Fax: +44 (0)20 7848 2980

http://www.digitalclassicist.org/
http://www.currentepigraphy.org/

From mholmes at uvic.ca  Wed Sep  5 11:06:07 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Wed, 5 Sep 2012 08:06:07 -0700
Subject: [tei-council] tagdocs elements inside <graphic>
In-Reply-To: <72E10C04-16B9-4E90-B950-AE7427ED09B2@it.ox.ac.uk>
References: <5046A1DE.2000409@ultraslavonic.info>
	<CAA2irtJ_cbmpm7TxHxn66GYmnn9XC0t1XV-FbMk=y08UR=dVZw@mail.gmail.com>
	<72E10C04-16B9-4E90-B950-AE7427ED09B2@it.ox.ac.uk>
Message-ID: <50476A5F.3000806@uvic.ca>

> So that leaves Drama, Speech, MS, and Dictionaries. I claim
> that none of these are meaningfully useful, documented,
> or follow any known recommendation.

I think the reason these are there is as an echo of the old Pizza Chef 
kind of model. For people coming to Roma for the first time, not 
understanding the module system or how to customize, I think they 
represent an unthreatening way to get started. But when they're bundled 
together with a bunch of absolutely inscrutable ones (TEI with XInclude, 
TEI with W3C ITS), then they're probably not helpful at all.

I'd really like to see a reborn Roma able to hand-hold novice users 
through this part of the process in a more helpful way, perhaps by 
asking them what kind of document they're going to mark up, and then 
suggesting some customizations to get started with, and explaining what 
actually happens when you choose one of these options. Meanwhile, the 
more offbeat stuff could be separated out and labelled as "advanced" or 
something like that.

Cheers,
Martin

On 12-09-05 01:05 AM, Sebastian Rahtz wrote:
> Sorry for being cryptic.
>
> At the moment, Roma offers you a choice of
>
>
> <option value="tei_bare.odd">TEI Absolutely Bare</option>
> <option value="teilite.odd">TEI Lite</option>
> <option value="tei_tite.odd">TEI Tite</option>
> <option value="tei_corpus.odd">TEI for Linguistic Corpora</option>
> <option value="tei_ms.odd">TEI for Manuscript Description</option>
> <option value="tei_drama.odd">TEI with Drama</option>
> <option value="tei_speech.odd">TEI for Speech Representation</option>
> <option value="tei_odds.odd">TEI for authoring ODD</option>
> <option value="tei_svg.odd">TEI with SVG</option>
> <option value="tei_math.odd">TEI with MathML</option>
> <option value="tei_xinclude.odd">TEI with XInclude (experimental)</option>
> <option value="tei_its.odd">TEI with W3C ITS</option>
> <option value="tei_dictionaries.odd">TEI for Dictionaries (experimental)</option>
>
>
> as customisations to build on.
>
> Bare, Lite, and Tite make sense; they are coherent and have a purpose.
> SVG, MathML, XInclude, ITS and ODD are also sensible,
> as they involve non-obvious techniques which you can't easily
> do in plain Roma.
>
> So that leaves Drama, Speech, MS, and Dictionaries. I claim
> that none of these are meaningfully useful, documented,
> or follow any known recommendation.
>
> Would anyone like to defend them?
> --
> Sebastian Rahtz
> Director (Research Support) of Academic IT Services
> University of Oxford IT Services
> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From James.Cummings at it.ox.ac.uk  Wed Sep  5 11:07:26 2012
From: James.Cummings at it.ox.ac.uk (James Cummings)
Date: Wed, 05 Sep 2012 16:07:26 +0100
Subject: [tei-council] experimental modules?
In-Reply-To: <504736F8.1020004@kcl.ac.uk>
References: <5042B271.5070909@ultraslavonic.info>
	<3D11821D65070D4BADB84B46F7FE203C8BCF88@MBX09.ad.oak.ox.ac.uk>
	<50456735.5050603@ultraslavonic.info>
	<79128BC8-9893-4913-9C9E-D3E20A5DFB41@it.ox.ac.uk>,
	<50462422.8020707@uvic.ca>
	<762A68C71238E2469EBDCDF70ADB2494098A8A@MBX01.ad.oak.ox.ac.uk>
	<50462DAB.3060806@ultraslavonic.info>
	<AEDB1292-5B3D-4654-B5F1-6BA04DB8B274@it.ox.ac.uk>
	<504717D1.40701@it.ox.ac.uk>
	<4945534d-6d5d-4c68-99a6-520eef844a44@HUB05.ad.oak.ox.ac.uk>
	<504736F8.1020004@kcl.ac.uk>
Message-ID: <50476AAE.60101@it.ox.ac.uk>

On 05/09/12 12:26, Gabriel Bodard wrote:
>>> What I do wonder is whether we should be providing templates for
>>> community-created customisations in Roma that are reasonably
>>> mature, well-supported, etc. with the prime example here being
>>> EpiDoc?
>> indeed. but you'd have to work out a management process
>> for this.
> I'm tempted by this, but as Sebastian says we'd need to think about how
> we a) manage this process, and b) how the EpiDoc odd releases and TEI
> releases line up (currently I normally make an EpiDoc release a few days
> after each TEI release, to take advantage of new features).

I agree that this is a not a trivial process -- i.e. when we make 
a release we need to know that template X is now non-functioning 
and an update hasn't been received so email maintainer Y and 
remove it from roma until it is fixed. (Or something like that)

> Happy to discuss this (and perhaps float it on the EpiDoc list if that
> would be useful).

Would it make sense for us to discuss it at the face to face, 
decide how we think it should work, and then approach potential 
community contributors? EpiDoc was really just an example in this 
case. ;-) (But the obvious contributor as well. ;-) )

-James


-- 
Dr James Cummings, researchsupport at it.ox.ac.uk
Research Support, IT Services, University of Oxford

From James.Cummings at it.ox.ac.uk  Wed Sep  5 12:49:12 2012
From: James.Cummings at it.ox.ac.uk (James Cummings)
Date: Wed, 05 Sep 2012 17:49:12 +0100
Subject: [tei-council] Oxford Face to Face Meeting: Skeleton Agenda
Message-ID: <50478288.7070308@it.ox.ac.uk>

Dear TEI Technical Council,

I've put a skeleton agenda in the wiki at:
http://wiki.tei-c.org/index.php/Council
for our Face to Face Meeting here in Oxford on the 19-21 September.

Please fill this in with more detail of things from previous 
meetings you need to report on, things that have come up since, 
etc. If you want to make sure we talk about something, please add it.

I'll be circulating a link to a google doc with more information 
about the meeting in the next few days.

-James


-- 
Dr James Cummings, researchsupport at it.ox.ac.uk
Research Support, IT Services, University of Oxford

From kevin.s.hawkins at ultraslavonic.info  Wed Sep  5 20:14:26 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Wed, 05 Sep 2012 20:14:26 -0400
Subject: [tei-council] experimental modules?
In-Reply-To: <50476AAE.60101@it.ox.ac.uk>
References: <5042B271.5070909@ultraslavonic.info>
	<3D11821D65070D4BADB84B46F7FE203C8BCF88@MBX09.ad.oak.ox.ac.uk>
	<50456735.5050603@ultraslavonic.info>
	<79128BC8-9893-4913-9C9E-D3E20A5DFB41@it.ox.ac.uk>,
	<50462422.8020707@uvic.ca>
	<762A68C71238E2469EBDCDF70ADB2494098A8A@MBX01.ad.oak.ox.ac.uk>
	<50462DAB.3060806@ultraslavonic.info>
	<AEDB1292-5B3D-4654-B5F1-6BA04DB8B274@it.ox.ac.uk>
	<504717D1.40701@it.ox.ac.uk>
	<4945534d-6d5d-4c68-99a6-520eef844a44@HUB05.ad.oak.ox.ac.uk>
	<504736F8.1020004@kcl.ac.uk> <50476AAE.60101@it.ox.ac.uk>
Message-ID: <5047EAE2.50805@ultraslavonic.info>

This has all turned into a messy discussion, so I have tried to 
summarize all of the questions related to experimental modules and lists 
of customizations for us to discuss in Oxford:

http://wiki.tei-c.org/index.php/Council#Friday_21_September_2012

I suggest we resume the discussion there.

On 9/5/12 11:07 AM, James Cummings wrote:
> Would it make sense for us to discuss it at the face to face,
> decide how we think it should work, and then approach potential
> community contributors? EpiDoc was really just an example in this
> case. ;-) (But the obvious contributor as well. ;-) )
>
> -James
>
>

From kevin.s.hawkins at ultraslavonic.info  Wed Sep  5 20:52:41 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Wed, 05 Sep 2012 20:52:41 -0400
Subject: [tei-council] tagdocs elements inside <graphic>
In-Reply-To: <EA3A00E4-3E33-4648-B3FD-961296835A98@it.ox.ac.uk>
References: <5046A1DE.2000409@ultraslavonic.info>
	<CAA2irtJ_cbmpm7TxHxn66GYmnn9XC0t1XV-FbMk=y08UR=dVZw@mail.gmail.com>
	<EA3A00E4-3E33-4648-B3FD-961296835A98@it.ox.ac.uk>
Message-ID: <5047F3D9.6090402@ultraslavonic.info>

Okay, this is turning out to be complicated as well.  I have created a 
ticket:

http://purl.org/tei/bug/3565137

On 9/5/12 4:11 AM, Sebastian Rahtz wrote:
>
> On 5 Sep 2012, at 02:27, Rebecca Welzenbach <rwelzenbach at gmail.com>
>   wrote:
>
>> Running with Kevin's second option: I'm not sure I understand why
>> <altIdent> and <equiv> are members of model.glossLike. What's the
>> history here?
>>
> i _think_ we put them in glossLike when that was used mainly
> by ODD elements; and then forgot about them when glossLike
> was more widely adopted.
>
>> If allowing <altIdent> and <equiv> via model.glossLike is
>> unintended/undesirable for <graphic>, is it also
>> unintended/undesirable for the other elements and classes that use
>> model.glossLike and are not part of the tagdocs module?
>>
> I find it difficult to defend equiv and altIdent for most users
> of glossLike, I must admit. Were Laurent here, I think he would
> find a way of doing it, but the simplest solution would seem
> to be to move them to (a new) model.equivLike, and use that
> only in classSpec, constrainSpec, elementSpec, macroSpec and valItem
>
> --
> Sebastian Rahtz
> Director (Research Support) of Academic IT Services
> University of Oxford IT Services
> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>

From mholmes at uvic.ca  Thu Sep  6 14:13:38 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Thu, 6 Sep 2012 11:13:38 -0700
Subject: [tei-council] tcw20.xml (Editing the TEI Guidelines)
Message-ID: <5048E7D2.6030904@uvic.ca>

Hi all,

I've just completed one of my Ann Arbor obligations by documenting the 
process of adding a Schematron constraint along with tests for that 
constraint. I've written quite a long section, and you can see the 
results here:

<http://hcmc.uvic.ca/people/martin/tcw20.html#schematron>

All comments appreciated.

However, writing it required the use of <exemplum>, <egXML> and friends. 
Unfortunately, the TCW documents (and I assume their associated 
transformation) are TEI Lite documents, so when I add my code to the 
tcw20.xml file on the TEI site (in CMS), the transform fails and the 
page does not show up. So I've had to comment out my new section for the 
moment.

What should we do about this? Could we transition the tcw files to full 
TEI, and use the default P5 XHTML conversion to render them on the CMS? 
It's going to be a bit difficult to provide good documentation for 
ourselves if we're prevented from using documentation elements.

Cheers,
Martin
-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From James.Cummings at it.ox.ac.uk  Thu Sep  6 20:29:16 2012
From: James.Cummings at it.ox.ac.uk (James Cummings)
Date: Fri, 07 Sep 2012 01:29:16 +0100
Subject: [tei-council] Oxford Face to Face Meeting: Dietary Requirements
Message-ID: <50493FDC.9060203@it.ox.ac.uk>


Hi All,

Could any one with specific dietary requirements email them to me 
before 5pm their local time today (this Friday) or as soon as 
possible there after?

This is to make sure you are catered for in the, erm, catering.

-James

-- 
Dr James Cummings, researchsupport at it.ox.ac.uk
Research Support, IT Services, University of Oxford

From James.Cummings at it.ox.ac.uk  Thu Sep  6 20:41:13 2012
From: James.Cummings at it.ox.ac.uk (James Cummings)
Date: Fri, 07 Sep 2012 01:41:13 +0100
Subject: [tei-council] tcw20.xml (Editing the TEI Guidelines)
In-Reply-To: <5048E7D2.6030904@uvic.ca>
References: <5048E7D2.6030904@uvic.ca>
Message-ID: <504942A9.2010900@it.ox.ac.uk>

On 06/09/12 19:13, Martin Holmes wrote:
> However, writing it required the use of<exemplum>,<egXML>  and friends.
> Unfortunately, the TCW documents (and I assume their associated
> transformation) are TEI Lite documents, so when I add my code to the
> tcw20.xml file on the TEI site (in CMS), the transform fails and the
> page does not show up. So I've had to comment out my new section for the
> moment.
>
> What should we do about this? Could we transition the tcw files to full
> TEI, and use the default P5 XHTML conversion to render them on the CMS?
> It's going to be a bit difficult to provide good documentation for
> ourselves if we're prevented from using documentation elements.

Interesting problem -- I might suggest we wait until David Sewell 
is back off holiday to double check with him how difficult this 
might be in openCMS.

-James

-- 
Dr James Cummings, researchsupport at it.ox.ac.uk
Research Support, IT Services, University of Oxford

From sebastian.rahtz at it.ox.ac.uk  Fri Sep  7 03:20:09 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Fri, 7 Sep 2012 07:20:09 +0000
Subject: [tei-council] tcw20.xml (Editing the TEI Guidelines)
In-Reply-To: <5048E7D2.6030904@uvic.ca>
References: <5048E7D2.6030904@uvic.ca>
Message-ID: <6ACDEEEF-C713-44CB-ABAC-21BC2D8B4F8A@oucs.ox.ac.uk>


Implementing egXML, ie pretty printing XML, is amusing. I am not surprised the xsl used in that opencms didn't include it. But should be just a matter of editing xsl, the cms won't care either way.

Sebastian

From mholmes at uvic.ca  Fri Sep  7 08:46:02 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Fri, 07 Sep 2012 05:46:02 -0700
Subject: [tei-council] tcw20.xml (Editing the TEI Guidelines)
In-Reply-To: <6ACDEEEF-C713-44CB-ABAC-21BC2D8B4F8A@oucs.ox.ac.uk>
References: <5048E7D2.6030904@uvic.ca>
	<6ACDEEEF-C713-44CB-ABAC-21BC2D8B4F8A@oucs.ox.ac.uk>
Message-ID: <5049EC8A.4060001@uvic.ca>

On 12-09-07 12:20 AM, Sebastian Rahtz wrote:
>>
>> Implementing egXML, ie pretty printing XML, is amusing. I am not
>> surprised the xsl used in that opencms didn't include it. But should
>> be just a matter of editing xsl, the cms won't care either way.

We'd have to change the schema the file conforms to as well. Could be 
tei_all, or we could create a more constrained schema for TCW purposes.

Cheers,
Martin

>
> Sebastian

-- 
Martin Holmes
mholmes at uvic.ca
UVic Humanities Computing and Media Centre

From sebastian.rahtz at it.ox.ac.uk  Fri Sep  7 09:13:53 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Fri, 7 Sep 2012 13:13:53 +0000
Subject: [tei-council] tcw20.xml (Editing the TEI Guidelines)
In-Reply-To: <5049EC8A.4060001@uvic.ca>
References: <5048E7D2.6030904@uvic.ca>
	<6ACDEEEF-C713-44CB-ABAC-21BC2D8B4F8A@oucs.ox.ac.uk>
	<5049EC8A.4060001@uvic.ca>
Message-ID: <B5EBE4E9-A33C-4624-8ED3-EF0EE62972E3@it.ox.ac.uk>


On 7 Sep 2012, at 13:46, Martin Holmes <mholmes at uvic.ca>
 wrote:

> On 12-09-07 12:20 AM, Sebastian Rahtz wrote:
>>> 
>>> Implementing egXML, ie pretty printing XML, is amusing. I am not
>>> surprised the xsl used in that opencms didn't include it. But should
>>> be just a matter of editing xsl, the cms won't care either way.
> 
> We'd have to change the schema the file conforms to as well. Could be tei_all, or we could create a more constrained schema for TCW purposes.
> 

does the site validate the file at all? I'd be surprised if it did

--
Sebastian Rahtz      
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431


From mholmes at uvic.ca  Fri Sep  7 11:30:04 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Fri, 7 Sep 2012 08:30:04 -0700
Subject: [tei-council] tcw20.xml (Editing the TEI Guidelines)
In-Reply-To: <B5EBE4E9-A33C-4624-8ED3-EF0EE62972E3@it.ox.ac.uk>
References: <5048E7D2.6030904@uvic.ca>
	<6ACDEEEF-C713-44CB-ABAC-21BC2D8B4F8A@oucs.ox.ac.uk>
	<5049EC8A.4060001@uvic.ca>
	<B5EBE4E9-A33C-4624-8ED3-EF0EE62972E3@it.ox.ac.uk>
Message-ID: <504A12FC.80602@uvic.ca>

On 12-09-07 06:13 AM, Sebastian Rahtz wrote:
>
> On 7 Sep 2012, at 13:46, Martin Holmes <mholmes at uvic.ca>
>   wrote:
>
>> On 12-09-07 12:20 AM, Sebastian Rahtz wrote:
>>>>
>>>> Implementing egXML, ie pretty printing XML, is amusing. I am not
>>>> surprised the xsl used in that opencms didn't include it. But should
>>>> be just a matter of editing xsl, the cms won't care either way.
>>
>> We'd have to change the schema the file conforms to as well. Could be tei_all, or we could create a more constrained schema for TCW purposes.
>>
>
> does the site validate the file at all? I'd be surprised if it did

I can't figure that out from the error that comes up when you try to 
view the page. Below is what you get. It looks to me as though it's the 
XSLT transformation that throws up the problem. The odd thing is that if 
a template doesn't exist for <egXML> etc., I would expect the default 
behaviour -- spit out the text -- but it actually fails instead.

javax.servlet.ServletException: javax.servlet.jsp.JspException: 
javax.servlet.ServletException: java.lang.AssertionError: Unknown value 
representation
	at 
org.apache.jasper.runtime.PageContextImpl.doHandlePageException(PageContextImpl.java:846)
	at 
org.apache.jasper.runtime.PageContextImpl.handlePageException(PageContextImpl.java:779)
	at 
org.apache.jsp.WEB_002dINF.jsp.offline.system.modules.org_tei_www.templates.transformer_jsp._jspService(transformer_jsp.java:101)
	at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
	at 
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:393)
	at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:320)
	at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:266)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)

Cheers,
Martin



-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From sebastian.rahtz at it.ox.ac.uk  Fri Sep  7 11:43:38 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Fri, 7 Sep 2012 15:43:38 +0000
Subject: [tei-council] tcw20.xml (Editing the TEI Guidelines)
In-Reply-To: <504A12FC.80602@uvic.ca>
References: <5048E7D2.6030904@uvic.ca>
	<6ACDEEEF-C713-44CB-ABAC-21BC2D8B4F8A@oucs.ox.ac.uk>
	<5049EC8A.4060001@uvic.ca>
	<B5EBE4E9-A33C-4624-8ED3-EF0EE62972E3@it.ox.ac.uk>
	<504A12FC.80602@uvic.ca>
Message-ID: <C65792CE-F372-4073-9F44-1E5E546F6D9B@it.ox.ac.uk>


On 7 Sep 2012, at 16:30, Martin Holmes <mholmes at uvic.ca> wrote:

> I can't figure that out from the error that comes up when you try to view the page. Below is what you get. It looks to me as though it's the XSLT transformation that throws up the problem. The odd thing is that if a template doesn't exist for <egXML> etc., I would expect the default behaviour -- spit out the text -- but it actually fails instead.
> 
> javax.servlet.ServletException: javax.servlet.jsp.JspException: javax.servlet.ServletException: java.lang.AssertionError: Unknown value representation
> 	at org.apache.jasper.runtime.PageContextImpl.doHandlePageException(PageContextImpl.java:846)
> 	at org.apache.jasper.runtime.PageContextImpl.handlePageException(PageContextImpl.java:779)
> 	at org.apache.jsp.WEB_002dINF.jsp.offline.system.modules.org_tei_www.templates.transformer_jsp._jspService(transformer_jsp.java:101)
> 	at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
> 	at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:393)
> 	at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:320)
> 	at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:266)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
> 

honestly, I have no idea what thats about :-{

--
Sebastian Rahtz      
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431


From kevin.s.hawkins at ultraslavonic.info  Mon Sep 10 21:33:53 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Mon, 10 Sep 2012 21:33:53 -0400
Subject: [tei-council] Fwd: Re:  Lite and/or _Lite?
In-Reply-To: <501B5354.8070806@ultraslavonic.info>
References: <50106D3C.3040809@retired.ox.ac.uk>
	<50106D4E.3090109@retired.ox.ac.uk>
	<50108CB0.8050605@ultraslavonic.info>
	<501B5354.8070806@ultraslavonic.info>
Message-ID: <504E9501.4070201@ultraslavonic.info>

So, even with a note in the minutes for posterity, we still have both 
"teilite.xml" and "tei_lite.odd" in the repository.  Can we get rid of 
the one that uses exclusion and keep only the one that uses inclusion? 
Right now it's very easy for someone to accidentally consult or even 
edit the wrong file.  --Kevin

On 8/3/12 12:28 AM, Kevin Hawkins wrote:
> For the record, I've added the note to the minutes.
>
> On 7/25/12 8:17 PM, Kevin Hawkins wrote:
>> Just like you, I am trying to clarify things.  I bring it up hoping that
>> someone will say, "Ah, I made that change shortly after Ann Arbor" or
>> something like that.  Then I can perhaps add a note in the minutes so
>> that future historians of the TEI can make sense of them.
>>
>> On 7/25/12 6:03 PM, Lou Burnard wrote:
>>>
>>>
>>>
>>> -------- Original Message --------
>>> Subject: Re: [tei-council] Lite and/or _Lite?
>>> Date: Wed, 25 Jul 2012 23:03:40 +0100
>>> From: Lou Burnard <lou.burnard at retired.ox.ac.uk>
>>> To: Kevin Hawkins <kevin.s.hawkins at ultraslavonic.info>
>>>
>>> The minutes from Ann Arbor could be mistaken, or someone may have been
>>> mistaken in asserting that we were actually still using teilite rather
>>> than tei_lite . Does it matter? The current state of affairs is what we
>>> all agreed we wanted!
>>>
>>> I dont know when we started generating from tei_lite, but I think
>>> Sebastian is right in suggesting it was well before the AA meeting.
>>>
>>>
>>> On 25/07/12 22:58, Kevin Hawkins wrote:
>>>> So are you saying that someone has changed what we are generating in
>>>> Jenkins since Ann Arbor?  That is, what was stated in Ann Arbor is no
>>>> longer true?
>>>>
>>>> On 7/25/2012 5:32 PM, Lou Burnard wrote:
>>>>> Yes, as my second mail points out, we are indeed currently generating
>>>>> from the "inclusion" version. Which is what the minutes say we agreed
>>>>> (inter alia) to do.
>>>>>
>>>>>
>>>>> On 25/07/12 22:26, Kevin Hawkins wrote:
>>>>>> Hmm, according to:
>>>>>>
>>>>>> http://www.tei-c.org/Activities/Council/Meetings/tcm50.xml#body.1_div.1_div.2_div.2
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> we are using the exclusion version (teilite.odd) to generate schemas.
>>>>>> That could be an error in the minutes, or someone may have misspoken.
>>>>>>
>>>>>> On 7/25/2012 5:13 PM, Lou Burnard wrote:
>>>>>>> I should also add that the Makefile in Exemplars (and presumably
>>>>>>> therefore also Mr Jinks) only builds the tei_lite version. As it
>>>>>>> should.
>>>>>>>
>>>>>>> On 25/07/12 22:10, Lou Burnard wrote:
>>>>>>>> I'm finally getting round to the action placed on me at last
>>>>>>>> Council
>>>>>>>> meeting concerning the ever popular "TEI Lite" document, and would
>>>>>>>> appreciate confirmation that I'm about to do the right thing.
>>>>>>>>
>>>>>>>> There are still two versions of this ODD in the svn repository
>>>>>>>> under
>>>>>>>> Exemplars: one (called tei_lite.odd) is defined by inclusion; the
>>>>>>>> other
>>>>>>>> (called teilite.odd) is defined by exclusion.
>>>>>>>>
>>>>>>>> I'm pretty sure we agreed that we would henceforth maintain this
>>>>>>>> document only in the "inclusion" form, if only so that we don't
>>>>>>>> have to
>>>>>>>> keep fixing it every time some new element is added to the
>>>>>>>> Guidelines
>>>>>>>> (which happens surprisingly often). But I'd like confirmation on
>>>>>>>> that
>>>>>>>> before zapping teilite.odd or moving it to the
>>>>>>>> "Deprecated-old-junk"
>>>>>>>> folder. Another possibility would of course be to maintain the
>>>>>>>> two of
>>>>>>>> them (possibly with some slightly less obscure naming difference)
>>>>>>>> but I
>>>>>>>> am hoping we don't want to do that.
>>>>>>>>
>>>>>>>> Needless to say, the two versions have diverged slightly, with some
>>>>>>>> recent minor updates being made independently by different
>>>>>>>> people to
>>>>>>>> the
>>>>>>>> two files, or to only one of them: I will in any case sort that
>>>>>>>> out.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>
>>>
>>>
>>>

From kevin.s.hawkins at ultraslavonic.info  Mon Sep 10 21:40:58 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Mon, 10 Sep 2012 21:40:58 -0400
Subject: [tei-council] Options for freezing and/or archiving Lite
In-Reply-To: <e576c082-8b47-4a44-bbe5-72754c548e8a@HUB05.ad.oak.ox.ac.uk>
References: <5024482D.1060307@uvic.ca> <5027DD4E.10400@retired.ox.ac.uk>
	<2b593217-f9a0-4203-9bb5-459a183e319a@HUB03.ad.oak.ox.ac.uk>
	<50292843.80700@uvic.ca> <50292908.1070709@retired.ox.ac.uk>
	<502943A0.3060500@uvic.ca>
	<e576c082-8b47-4a44-bbe5-72754c548e8a@HUB05.ad.oak.ox.ac.uk>
Message-ID: <504E96AA.5060309@ultraslavonic.info>

All,

I have added the topic "options for freezing and/or archiving Lite" to 
the Oxford agenda in the wiki, though without the extensive summary of 
the discussion so far that I created for another agenda item: 
"experimental modules, lists of customisations, etc.".

--Kevin

From sebastian.rahtz at it.ox.ac.uk  Tue Sep 11 02:19:24 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Tue, 11 Sep 2012 06:19:24 +0000
Subject: [tei-council] Fwd: Re:  Lite and/or _Lite?
In-Reply-To: <504E9501.4070201@ultraslavonic.info>
References: <50106D3C.3040809@retired.ox.ac.uk>
	<50106D4E.3090109@retired.ox.ac.uk>	<50108CB0.8050605@ultraslavonic.info>
	<501B5354.8070806@ultraslavonic.info>,
	<504E9501.4070201@ultraslavonic.info>
Message-ID: <D7868AE4-764E-4463-B1E8-CF9F0126FC3B@oucs.ox.ac.uk>

Surely teilite.xml is the template file?

Doesn't solve the naming or freezing issue, of course

Carved in stone on my iPad

From sebastian.rahtz at it.ox.ac.uk  Tue Sep 11 03:48:18 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Tue, 11 Sep 2012 07:48:18 +0000
Subject: [tei-council] Lite and/or _Lite?
In-Reply-To: <504E9501.4070201@ultraslavonic.info>
References: <50106D3C.3040809@retired.ox.ac.uk>
	<50106D4E.3090109@retired.ox.ac.uk>
	<50108CB0.8050605@ultraslavonic.info>
	<501B5354.8070806@ultraslavonic.info>
	<504E9501.4070201@ultraslavonic.info>
Message-ID: <8412932F-0076-48DE-8C62-9CBFDEF8BADB@it.ox.ac.uk>


On 11 Sep 2012, at 02:33, Kevin Hawkins <kevin.s.hawkins at ultraslavonic.info> wrote:

> So, even with a note in the minutes for posterity, we still have both 
> "teilite.xml" and "tei_lite.odd" in the repository.  Can we get rid of 
> the one that uses exclusion and keep only the one that uses inclusion? 
> Right now it's very easy for someone to accidentally consult or even 
> edit the wrong file.

surely it is _tite_ which is the problem:

-rw-r--r--  1 rahtz  staff  56906 11 Sep 08:31 tei_tite.odd
-rw-r--r--  1 rahtz  staff  58635 17 Sep  2010 tei_tite_ns.odd


--
Sebastian Rahtz      
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431


From sebastian.rahtz at it.ox.ac.uk  Tue Sep 11 09:00:48 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Tue, 11 Sep 2012 13:00:48 +0000
Subject: [tei-council] oxford tei-related servers
Message-ID: <E96A48C3-08D6-4492-958F-88B206446B1A@it.ox.ac.uk>

if any of you were puzzled/discommoded by various servers at Oxford (tei.oucs, bits.nsms, oxgarage.oucs) in the
last few days, this was because the VMs that host them were being migrated to our new local cloud setup.

we seem to have resolved all the problems[1] now, so I don't expect any more disruption

[1] they were using this group of VMs to test procedures :-}
--
Sebastian Rahtz      
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431


From kevin.s.hawkins at ultraslavonic.info  Tue Sep 11 09:45:00 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Tue, 11 Sep 2012 09:45:00 -0400
Subject: [tei-council] Lite and/or _Lite?
In-Reply-To: <8412932F-0076-48DE-8C62-9CBFDEF8BADB@it.ox.ac.uk>
References: <50106D3C.3040809@retired.ox.ac.uk>
	<50106D4E.3090109@retired.ox.ac.uk>
	<50108CB0.8050605@ultraslavonic.info>
	<501B5354.8070806@ultraslavonic.info>
	<504E9501.4070201@ultraslavonic.info>
	<8412932F-0076-48DE-8C62-9CBFDEF8BADB@it.ox.ac.uk>
Message-ID: <504F405C.6060901@ultraslavonic.info>

Responding to Sebastian's two messages ...

On 9/11/2012 2:19 AM, Sebastian Rahtz wrote:
 > Surely teilite.xml is the template file?

For the record, since I wrote, Sebastian has renamed the template file 
to tei_lite.xml.

Still, when I wrote, I could have sworn there were two versions of the 
schema -- teilite.xml and tei_lite.odd -- in addition to a template 
named tei_lite.xml.

So I guess ignore that.

However ...

On 9/11/2012 3:48 AM, Sebastian Rahtz wrote:
>
> On 11 Sep 2012, at 02:33, Kevin Hawkins<kevin.s.hawkins at ultraslavonic.info>  wrote:
>
>> So, even with a note in the minutes for posterity, we still have both
>> "teilite.xml" and "tei_lite.odd" in the repository.  Can we get rid of
>> the one that uses exclusion and keep only the one that uses inclusion?
>> Right now it's very easy for someone to accidentally consult or even
>> edit the wrong file.
>
> surely it is _tite_ which is the problem:
>
> -rw-r--r--  1 rahtz  staff  56906 11 Sep 08:31 tei_tite.odd
> -rw-r--r--  1 rahtz  staff  58635 17 Sep  2010 tei_tite_ns.odd

Ah yes, the same problem applies here.  Can we get rid of the exclusion one?

From dsewell at virginia.edu  Tue Sep 11 09:49:56 2012
From: dsewell at virginia.edu (David Sewell)
Date: Tue, 11 Sep 2012 09:49:56 -0400 (EDT)
Subject: [tei-council] ICT Standards Consortia survey (fwd)
Message-ID: <alpine.OSX.2.00.1209110946040.16588@lister.ei.virginia.edu>

Dear Board and Council people,

The TEI is listed in a survey of standardization consortia hosted by the 
European Committee for standardization. They are asking for any updates to the 
information they have on file. I don't know if all the attachments will go 
through, but if you go to 
http://www.cen.eu/cen/Sectors/Sectors/ISSS/Consortia/Pages/default.aspx#t and 
click on the link for "TEI-C" in the list you will see a PDF with the 
information for us. If you notice anything that needs changing, please let me 
know by the end of the week (Sept. 14) and I will take care of forwarding the 
information.

(I would guess that Laurent was the person who originally got us on this list.)

David

-- 
David Sewell, Editorial and Technical Manager
ROTUNDA, The University of Virginia Press
PO Box 400314, Charlottesville, VA 22904-4314 USA
Email: dsewell at virginia.edu   Tel: +1 434 924 9973
Web: http://rotunda.upress.virginia.edu/
-------------- next part --------------
Dear Consortium colleagues

For many years, we have published a survey of standardization consortia in the ICT domain, providing comparable basic data on the organisations including scope, contact points, membership arrangements, where outputs can be obtained from, any IPR policy etc.  Whilst no doubt we are missing quite a number of bodies, and also the usual disclaimers concerning the accuracy of the data have to be applied, the list is one of the most complete and consistent there is at a global level.

I am writing because your organisation is one figuring on our list; the time has come for us to provide an updated edition, and we would very much appreciate your re-validation of the information we provide, much of which has been obtained from the web.  You can find the current edition of the survey at http://www.cen.eu/cen/Sectors/Sectors/ISSS/Consortia/Pages/default.aspx, with an alphabetical link to the consortia covered.  Please check the information and let us have any updates using the simple template attached, if possible before the end of September 2012.  We will send you a link to the revised publication version.  Please also inform us of any other consortia you feel are missing from our current list, and we will contact them.  Contributions should be sent to H?l?ne Hennico in our Innovation Department (hhennico at cencenelec.eu<mailto:hhennico at cencenelec.eu>).

Whilst I am writing, you may also wish to note that CEN and CENELEC are keen to improve our inter-relationships with standards consortia within our broad activity fields, maximising the complementarities with formal standards processes in Europe (but linked closely to international standards activities) and at national level in our 33 member organisations.  This outreach is also to be seen in the context of new policy initiatives of the European Commission, which are seeking to ensure certain consortia specifications meeting relevant criteria may be referenced in public procurement.  The EU Commission has established a consultative group (the "Multi-Stakeholder Platform") platform that includes the formal standards bodies and a number of large consortia with a European presence, as well as a wide range other stakeholders including EU member states, but clearly many standards consortia cannot routinely be represented there - we shall be pleased to collaborate with such bodies.

Please let us know if you need further information on these aspects.



Best regards
John KETCHELL
Strategic Adviser
[cid:image001.jpg at 01CD8B6F.8699A7A0]

Avenue Marnix 17 - 1000 Brussels, Belgium
Tel: +32 2 550 08 46 - Fax: +32 2 550 08 19
GSM: +32 475 594 828
jketchell at cencenelec.eu<mailto:jketchell at cencenelec.eu>
[cid:image002.png at 01CD8B6F.8699A7A0]<http://www.facebook.com/CENCENELEC> [cid:image003.png at 01CD8B6F.8699A7A0] <http://www.linkedin.com/company/1092118?trk=tyah>  [cid:image004.png at 01CD8B6F.8699A7A0] <http://twitter.com/#/Standards4RDI>

CEN - European Committee for Standardization
CENELEC - European Committee for Electrotechnical Standardization
www.cencenelec.eu

[cid:image005.gif at 01CD8B6F.8699A7A0] Please consider your impact on the environment before printing this email.
This email may contain confidential information and is intended for the use of the addressee only. Any unauthorised use may be unlawful. If you receive this email by mistake, please advise the sender immediately by using the reply facility in your email software. Thank you for your co-operation.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.village.Virginia.EDU/pipermail/tei-council/attachments/20120911/5f4a2468/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 6254 bytes
Desc: image001.jpg
Url : http://lists.village.Virginia.EDU/pipermail/tei-council/attachments/20120911/5f4a2468/attachment-0001.jpg 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 3760 bytes
Desc: image002.png
Url : http://lists.village.Virginia.EDU/pipermail/tei-council/attachments/20120911/5f4a2468/attachment-0003.png 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.png
Type: image/png
Size: 908 bytes
Desc: image003.png
Url : http://lists.village.Virginia.EDU/pipermail/tei-council/attachments/20120911/5f4a2468/attachment-0004.png 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image004.png
Type: image/png
Size: 3709 bytes
Desc: image004.png
Url : http://lists.village.Virginia.EDU/pipermail/tei-council/attachments/20120911/5f4a2468/attachment-0005.png 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image005.gif
Type: image/gif
Size: 233 bytes
Desc: image005.gif
Url : http://lists.village.Virginia.EDU/pipermail/tei-council/attachments/20120911/5f4a2468/attachment-0001.gif 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Consortium template.doc
Type: application/msword
Size: 32256 bytes
Desc: Consortium template.doc
Url : http://lists.village.Virginia.EDU/pipermail/tei-council/attachments/20120911/5f4a2468/attachment-0001.doc 

From lou.burnard at retired.ox.ac.uk  Tue Sep 11 09:54:25 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Tue, 11 Sep 2012 14:54:25 +0100
Subject: [tei-council] Lite
In-Reply-To: <504F405C.6060901@ultraslavonic.info>
References: <50106D3C.3040809@retired.ox.ac.uk>
	<50106D4E.3090109@retired.ox.ac.uk>
	<50108CB0.8050605@ultraslavonic.info>
	<501B5354.8070806@ultraslavonic.info>
	<504E9501.4070201@ultraslavonic.info>
	<8412932F-0076-48DE-8C62-9CBFDEF8BADB@it.ox.ac.uk>
	<504F405C.6060901@ultraslavonic.info>
Message-ID: <504F4291.7010302@retired.ox.ac.uk>

Do we think it might be a good idea to make a small song and dance about 
the revision/updating/freezing/whatever  of TEI Lite on TEI-L?

Happy to draft something, if so.

Sfaict, our plan is to make no further substantive changes in the source 
of the ODD, but to check its compatibility with future P5 releasess. If 
it ceases to work in the future, the wrath of Birnbaum should be 
considered to ensue. As such it's a usefu;l (if not unique) conscience 
checker. Think of it as a canary in a cage...



From sebastian.rahtz at it.ox.ac.uk  Tue Sep 11 09:56:25 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Tue, 11 Sep 2012 13:56:25 +0000
Subject: [tei-council] Lite and/or _Lite?
In-Reply-To: <504F405C.6060901@ultraslavonic.info>
References: <50106D3C.3040809@retired.ox.ac.uk>
	<50106D4E.3090109@retired.ox.ac.uk>
	<50108CB0.8050605@ultraslavonic.info>
	<501B5354.8070806@ultraslavonic.info>
	<504E9501.4070201@ultraslavonic.info>
	<8412932F-0076-48DE-8C62-9CBFDEF8BADB@it.ox.ac.uk>
	<504F405C.6060901@ultraslavonic.info>
Message-ID: <0A1008F7-23A0-4A06-9CA1-B6D82361AC5B@it.ox.ac.uk>


On 11 Sep 2012, at 14:45, Kevin Hawkins <kevin.s.hawkins at ultraslavonic.info>
 wrote:

> 
> Still, when I wrote, I could have sworn there were two versions of the 
> schema -- teilite.xml and tei_lite.odd -- in addition to a template 
> named tei_lite.xml.

mysterious creatures, computers :-}

>> 
>> -rw-r--r--  1 rahtz  staff  56906 11 Sep 08:31 tei_tite.odd
>> -rw-r--r--  1 rahtz  staff  58635 17 Sep  2010 tei_tite_ns.odd
> 
> Ah yes, the same problem applies here.  Can we get rid of the exclusion one?

I think you and/or Lou need to check there is nothing useful in  tei_tite_ns.odd
you need to keep. Lou was merging them at one time
--
Sebastian Rahtz      
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431


From sebastian.rahtz at it.ox.ac.uk  Tue Sep 11 09:59:13 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Tue, 11 Sep 2012 13:59:13 +0000
Subject: [tei-council] Lite
In-Reply-To: <504F4291.7010302@retired.ox.ac.uk>
References: <50106D3C.3040809@retired.ox.ac.uk>
	<50106D4E.3090109@retired.ox.ac.uk>
	<50108CB0.8050605@ultraslavonic.info>
	<501B5354.8070806@ultraslavonic.info>
	<504E9501.4070201@ultraslavonic.info>
	<8412932F-0076-48DE-8C62-9CBFDEF8BADB@it.ox.ac.uk>
	<504F405C.6060901@ultraslavonic.info>
	<504F4291.7010302@retired.ox.ac.uk>
Message-ID: <1be8a5c5-9eba-4baf-a3d6-1ed50f043a42@HUB06.ad.oak.ox.ac.uk>


On 11 Sep 2012, at 14:54, Lou Burnard <lou.burnard at retired.ox.ac.uk>
 wrote:

> Do we think it might be a good idea to make a small song and dance about 
> the revision/updating/freezing/whatever  of TEI Lite on TEI-L?

yes. very much so, but I don't think we are agreed yet
on what we mean, or plan to do.

> Sfaict, our plan is to make no further substantive changes in the source 
> of the ODD, but to check its compatibility with future P5 releasess. If 
> it ceases to work in the future, the wrath of Birnbaum should be 
> considered to ensue. As such it's a usefu;l (if not unique) conscience 
> checker. Think of it as a canary in a cage...


I agree with this, but its not what several other folks proposed.
this is effectively no change to what happens now.

don't forget we have renamed the DTD/Schema, by the way,
so anyone with a stashed-away URL will lose Lite immediately ?

I suspect a redirect may be in order
--
Sebastian Rahtz      
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431


From dsewell at virginia.edu  Tue Sep 11 10:02:04 2012
From: dsewell at virginia.edu (David Sewell)
Date: Tue, 11 Sep 2012 10:02:04 -0400 (EDT)
Subject: [tei-council] TEI schema (fwd)
Message-ID: <alpine.OSX.2.00.1209111001000.16588@lister.ei.virginia.edu>

Could someone on Council volunteer to reply to this query? (I can give them the 
short answer, "Yes, TEI and EPUB are compatible", but can't fill in the details 
they probably want.)

David

---------- Forwarded message ----------
Date: Mon, 10 Sep 2012 19:14:32 +0000
From: "Burgoyne, Rebecca" <RBURGOYNE at umpublishing.org>
To: "info at tei-c.org" <info at tei-c.org>
Subject: TEI schema

Greetings!

We at The United Methodist Publishing House are exploring options for XML schema that is compatible with EPUB. Is TEI compatible with EPUB? Is there a TEI schema, per se, or does each House develop their own?

Thanks much.


[cid:698311319 at 10092012-18BC]


Rebecca C. Burgoyne
Director, Publishing Operations
The United Methodist Publishing House
201 Eighth Avenue South, P. O. Box 801
Nashville, TN 37202
Office: 1.615.749.6555
email: rburgoyne at umpublishing.org<mailto:rburgoyne at umpublishing.org>



From lou.burnard at retired.ox.ac.uk  Tue Sep 11 10:04:51 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Tue, 11 Sep 2012 15:04:51 +0100
Subject: [tei-council] Lite
In-Reply-To: <D972C63B-D72E-4DD0-99A9-78D33FB08282@it.ox.ac.uk>
References: <50106D3C.3040809@retired.ox.ac.uk>
	<50106D4E.3090109@retired.ox.ac.uk>
	<50108CB0.8050605@ultraslavonic.info>
	<501B5354.8070806@ultraslavonic.info>
	<504E9501.4070201@ultraslavonic.info>
	<8412932F-0076-48DE-8C62-9CBFDEF8BADB@it.ox.ac.uk>
	<504F405C.6060901@ultraslavonic.info>
	<504F4291.7010302@retired.ox.ac.uk>
	<D972C63B-D72E-4DD0-99A9-78D33FB08282@it.ox.ac.uk>
Message-ID: <504F4503.4030307@retired.ox.ac.uk>

On 11/09/12 14:59, Sebastian Rahtz wrote:

>> Sfaict, our plan is to make no further substantive changes in the source
>> of the ODD, but to check its compatibility with future P5 releasess. If
>> it ceases to work in the future, the wrath of Birnbaum should be
>> considered to ensue. As such it's a usefu;l (if not unique) conscience
>> checker. Think of it as a canary in a cage...
>
>
> I agree with this, but its not what several other folks proposed.
> this is effectively no change to what happens now.

well maybe them other folks could speak up with what they think wwe 
should do, cos I frankly cannot see any other sensible way forward

>
> don't forget we have renamed the DTD/Schema, by the way,
> so anyone with a stashed-away URL will lose Lite immediately ?

yes, that should obviously be part of the annoiuncement. It makes good 
sense, since there is quite a lot of variation in the various things 
called "teilite" -- we are making a final clean P5 co,mpatible version, 
and the name changes emphasizes that all preceding bets are now off.

>
> I suspect a redirect may be in order

for the reasons above, i feel less sure about this. If people are 
currently happily linking to something called "teilite" locally that 
will almost certainly not be the same as what they will get in the next 
release under the name of "tei_lite". If they are linking to the 
"teilite" on the website, I suppose it would be plausible to make that 
point instead to "tei_lite" though. Do you mean the doc, the dtd, the 
schema, the odd, or all of them?

Of course, another option would be to undo the name change, and go back 
to the underscore_free variant.






From sebastian.rahtz at it.ox.ac.uk  Tue Sep 11 10:09:19 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Tue, 11 Sep 2012 14:09:19 +0000
Subject: [tei-council] Lite
In-Reply-To: <504F4503.4030307@retired.ox.ac.uk>
References: <50106D3C.3040809@retired.ox.ac.uk>
	<50106D4E.3090109@retired.ox.ac.uk>
	<50108CB0.8050605@ultraslavonic.info>
	<501B5354.8070806@ultraslavonic.info>
	<504E9501.4070201@ultraslavonic.info>
	<8412932F-0076-48DE-8C62-9CBFDEF8BADB@it.ox.ac.uk>
	<504F405C.6060901@ultraslavonic.info>
	<504F4291.7010302@retired.ox.ac.uk>
	<D972C63B-D72E-4DD0-99A9-78D33FB08282@it.ox.ac.uk>
	<504F4503.4030307@retired.ox.ac.uk>
Message-ID: <ada461bf-5768-4eeb-b9f5-b86af18554f9@HUB03.ad.oak.ox.ac.uk>


On 11 Sep 2012, at 15:04, Lou Burnard <lou.burnard at retired.ox.ac.uk>
 wrote:
> 
> well maybe them other folks could speak up with what they think wwe should do, cos I frankly cannot see any other sensible way forward
> 

you need to decide what you are proposing. Is Lite to be rebuilt using current source
at each release, or not, that is the question. What is frozen, the output or the input?


>> 
>> I suspect a redirect may be in order
> 
> for the reasons above, i feel less sure about this. If people are currently happily linking to something called "teilite" locally that will almost certainly not be the same as what they will get in the next release under the name of "tei_lite".

yes, fair point.  I wonder how many do link to the www.tei-c.org copy. the logs will tell us, I suspect

> If they are linking to the "teilite" on the website, I suppose it would be plausible to make that point instead to "tei_lite" though. Do you mean the doc, the dtd, the schema, the odd, or all of them?
> 
I mean just the DTD

> Of course, another option would be to undo the name change, and go back to the underscore_free variant.

yup.

I just want to avoid the  XX_YY generating XXYY, unlike all other other files.

--
Sebastian Rahtz      
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431


From lou.burnard at retired.ox.ac.uk  Tue Sep 11 10:12:05 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Tue, 11 Sep 2012 15:12:05 +0100
Subject: [tei-council] Lite
In-Reply-To: <3023B5DE-42DD-4A90-B098-C1A79E544679@it.ox.ac.uk>
References: <50106D3C.3040809@retired.ox.ac.uk>
	<50106D4E.3090109@retired.ox.ac.uk>
	<50108CB0.8050605@ultraslavonic.info>
	<501B5354.8070806@ultraslavonic.info>
	<504E9501.4070201@ultraslavonic.info>
	<8412932F-0076-48DE-8C62-9CBFDEF8BADB@it.ox.ac.uk>
	<504F405C.6060901@ultraslavonic.info>
	<504F4291.7010302@retired.ox.ac.uk>
	<D972C63B-D72E-4DD0-99A9-78D33FB08282@it.ox.ac.uk>
	<504F4503.4030307@retired.ox.ac.uk>
	<3023B5DE-42DD-4A90-B098-C1A79E544679@it.ox.ac.uk>
Message-ID: <504F46B5.7050502@retired.ox.ac.uk>

On 11/09/12 15:09, Sebastian Rahtz wrote:

>
> you need to decide what you are proposing. Is Lite to be rebuilt using current source
> at each release, or not, that is the question.

My vote is yes, it is. Others?




From sebastian.rahtz at it.ox.ac.uk  Tue Sep 11 10:15:23 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Tue, 11 Sep 2012 14:15:23 +0000
Subject: [tei-council] Lite
In-Reply-To: <504F46B5.7050502@retired.ox.ac.uk>
References: <50106D3C.3040809@retired.ox.ac.uk>
	<50106D4E.3090109@retired.ox.ac.uk>
	<50108CB0.8050605@ultraslavonic.info>
	<501B5354.8070806@ultraslavonic.info>
	<504E9501.4070201@ultraslavonic.info>
	<8412932F-0076-48DE-8C62-9CBFDEF8BADB@it.ox.ac.uk>
	<504F405C.6060901@ultraslavonic.info>
	<504F4291.7010302@retired.ox.ac.uk>
	<D972C63B-D72E-4DD0-99A9-78D33FB08282@it.ox.ac.uk>
	<504F4503.4030307@retired.ox.ac.uk>
	<3023B5DE-42DD-4A90-B098-C1A79E544679@it.ox.ac.uk>
	<504F46B5.7050502@retired.ox.ac.uk>
Message-ID: <925f2228-d74c-46f1-ad05-fe3dc1540d05@HUB06.ad.oak.ox.ac.uk>


On 11 Sep 2012, at 15:12, Lou Burnard <lou.burnard at retired.ox.ac.uk>
 wrote:

> On 11/09/12 15:09, Sebastian Rahtz wrote:
> 
>> 
>> you need to decide what you are proposing. Is Lite to be rebuilt using current source
>> at each release, or not, that is the question.
> 
> My vote is yes, it is. Others?

+1 from me.


--
Sebastian Rahtz      
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431


From mholmes at uvic.ca  Tue Sep 11 11:53:44 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Tue, 11 Sep 2012 08:53:44 -0700
Subject: [tei-council] Lite
In-Reply-To: <504F46B5.7050502@retired.ox.ac.uk>
References: <50106D3C.3040809@retired.ox.ac.uk>
	<50106D4E.3090109@retired.ox.ac.uk>	<50108CB0.8050605@ultraslavonic.info>
	<501B5354.8070806@ultraslavonic.info>	<504E9501.4070201@ultraslavonic.info>
	<8412932F-0076-48DE-8C62-9CBFDEF8BADB@it.ox.ac.uk>
	<504F405C.6060901@ultraslavonic.info>	<504F4291.7010302@retired.ox.ac.uk>
	<D972C63B-D72E-4DD0-99A9-78D33FB08282@it.ox.ac.uk>
	<504F4503.4030307@retired.ox.ac.uk>
	<3023B5DE-42DD-4A90-B098-C1A79E544679@it.ox.ac.uk>
	<504F46B5.7050502@retired.ox.ac.uk>
Message-ID: <504F5E88.8010200@uvic.ca>

On 12-09-11 07:12 AM, Lou Burnard wrote:
> On 11/09/12 15:09, Sebastian Rahtz wrote:
>
>>
>> you need to decide what you are proposing. Is Lite to be rebuilt using current source
>> at each release, or not, that is the question.
>
> My vote is yes, it is. Others?

If we continue to offer it as part of the package, then I think we also 
have an obligation to maintain it.

We then have to decide what we mean by "maintain".

- If an update to trunk were to remove an element or attribute in Lite, 
what would we do?

- If a novel addition to trunk is deemed desirable by Lite users, what 
would we do?

- If an update to trunk substantially changed the definition of an 
element or attribute also used in Lite, what would we do?

I think if we lay out all these possibilities and answer all those 
questions in advance, then it'll be easier to explain our intentions and 
stick to them.

Cheers,
Martin


-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From lou.burnard at retired.ox.ac.uk  Tue Sep 11 12:23:09 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Tue, 11 Sep 2012 17:23:09 +0100
Subject: [tei-council] Lite
In-Reply-To: <504F5E88.8010200@uvic.ca>
References: <50106D3C.3040809@retired.ox.ac.uk>
	<50106D4E.3090109@retired.ox.ac.uk>	<50108CB0.8050605@ultraslavonic.info>
	<501B5354.8070806@ultraslavonic.info>	<504E9501.4070201@ultraslavonic.info>
	<8412932F-0076-48DE-8C62-9CBFDEF8BADB@it.ox.ac.uk>
	<504F405C.6060901@ultraslavonic.info>	<504F4291.7010302@retired.ox.ac.uk>
	<D972C63B-D72E-4DD0-99A9-78D33FB08282@it.ox.ac.uk>
	<504F4503.4030307@retired.ox.ac.uk>
	<3023B5DE-42DD-4A90-B098-C1A79E544679@it.ox.ac.uk>
	<504F46B5.7050502@retired.ox.ac.uk> <504F5E88.8010200@uvic.ca>
Message-ID: <504F656D.3090108@retired.ox.ac.uk>

On 11/09/12 16:53, Martin Holmes wrote:

> - If an update to trunk were to remove an element or attribute in Lite,
> what would we do?

We might try to evade the WOB (wrath of Birnbaum) by seeking a new 
identity or pretending it never happened, but basically, no, this cannot 
be allowed to happen.

>
> - If a novel addition to trunk is deemed desirable by Lite users, what
> would we do?

Tell them to make a new Lite all of their own. This one is not going 
anywhere further than it has already.

>
> - If an update to trunk substantially changed the definition of an
> element or attribute also used in Lite, what would we do?
>

Depending on what you mean by "substantially", I think this may be the 
same as your first question. If however it's just a matter of the 
wording of a definition being changed, then Lite would inherit the new 
wording, which is fine.




From James.Cummings at it.ox.ac.uk  Tue Sep 11 15:38:08 2012
From: James.Cummings at it.ox.ac.uk (James Cummings)
Date: Tue, 11 Sep 2012 20:38:08 +0100
Subject: [tei-council] Joining Instructions for TEI Council Face to Face
	2012-09-19 to 20
Message-ID: <504F9320.20006@it.ox.ac.uk>

Hi All,

I've done some meeting notes / joining instructions at:

http://tinyurl.com/teicouncil-2012-09-notes

If you have any questions, feel free to email me (and Sebastian 
who I've given write access to) and we'll update them.

One of the items on this is Food. Thank you for those who sent 
their dietary preferences, below is some of the thoughts on food 
from the notes document. Let us know if you think any of these 
are not viable.

= Food =

Breakfast: Most of this should be included in your accommodation. 
Local people should not claim breakfasts.

Lunch: This will be provided each day.

Supper:
- Wednesday: We?re suggesting a nearby Lebanese place: 
http://www.al-shami.co.uk/

- Thursday: If weather is nice, we thought about walking up the 
river from Wolfson to: http://www.victoriaarms.co.uk a nearby pub 
run by the Oxford Preservation Trust. If weather is not so good 
we?ll go elsewhere.

-Friday: We?re thinking of http://www.mysichuan.co.uk/
In all cases I believe these can cope with 
Vegetarian/Vegan/NoDairyNoPork dietary requirements, and I will 
note these on booking. But do question waiters and make them 
aware of your requirements on arrival.

Maps:

There is a custom google map at: http://goo.gl/maps/kb1kO let me 
know if there is something I should add to it. I have the venue 
locations,

-James

-- 
Dr James Cummings, researchsupport at it.ox.ac.uk
Research Support, IT Services, University of Oxford

From mholmes at uvic.ca  Tue Sep 11 16:26:27 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Tue, 11 Sep 2012 13:26:27 -0700
Subject: [tei-council] tcw20.xml (Editing the TEI Guidelines): Attention
 David
In-Reply-To: <504942A9.2010900@it.ox.ac.uk>
References: <5048E7D2.6030904@uvic.ca> <504942A9.2010900@it.ox.ac.uk>
Message-ID: <504F9E73.5020805@uvic.ca>

Hi David,

Now you're back, when you have a moment, could you comment on this? How 
easy would it be to edit the XSLT tranformation that handles the TCW 
documents in the CMS?

On 12-09-06 05:41 PM, James Cummings wrote:
> On 06/09/12 19:13, Martin Holmes wrote:

>>
> I've just completed one of my Ann Arbor obligations by documenting the
>> process of adding a Schematron constraint along with tests for that
>> constraint. I've written quite a long section, and you can see the
>> results here:
>>
>> <http://hcmc.uvic.ca/people/martin/tcw20.html#schematron>
>>
>> All comments appreciated.
 >>
>>However, writing it required the use of<exemplum>,<egXML>  and friends.
>> Unfortunately, the TCW documents (and I assume their associated
>> transformation) are TEI Lite documents, so when I add my code to the
>> tcw20.xml file on the TEI site (in CMS), the transform fails and the
>> page does not show up. So I've had to comment out my new section for the
>> moment.
>>
>> What should we do about this? Could we transition the tcw files to full
>> TEI, and use the default P5 XHTML conversion to render them on the CMS?
>> It's going to be a bit difficult to provide good documentation for
>> ourselves if we're prevented from using documentation elements.
>
> Interesting problem -- I might suggest we wait until David Sewell
> is back off holiday to double check with him how difficult this
> might be in openCMS.
>
> -James

Cheers,
Martin

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From kevin.s.hawkins at ultraslavonic.info  Tue Sep 11 17:38:41 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Tue, 11 Sep 2012 17:38:41 -0400
Subject: [tei-council] TEI schema (fwd)
In-Reply-To: <alpine.OSX.2.00.1209111001000.16588@lister.ei.virginia.edu>
References: <alpine.OSX.2.00.1209111001000.16588@lister.ei.virginia.edu>
Message-ID: <504FAF61.4080803@ultraslavonic.info>

I'll take it.

On 9/11/2012 10:02 AM, David Sewell wrote:
> Could someone on Council volunteer to reply to this query? (I can give them the
> short answer, "Yes, TEI and EPUB are compatible", but can't fill in the details
> they probably want.)
>
> David
>
> ---------- Forwarded message ----------
> Date: Mon, 10 Sep 2012 19:14:32 +0000
> From: "Burgoyne, Rebecca"<RBURGOYNE at umpublishing.org>
> To: "info at tei-c.org"<info at tei-c.org>
> Subject: TEI schema
>
> Greetings!
>
> We at The United Methodist Publishing House are exploring options for XML schema that is compatible with EPUB. Is TEI compatible with EPUB? Is there a TEI schema, per se, or does each House develop their own?
>
> Thanks much.
>
>
> [cid:698311319 at 10092012-18BC]
>
>
> Rebecca C. Burgoyne
> Director, Publishing Operations
> The United Methodist Publishing House
> 201 Eighth Avenue South, P. O. Box 801
> Nashville, TN 37202
> Office: 1.615.749.6555
> email: rburgoyne at umpublishing.org<mailto:rburgoyne at umpublishing.org>
>
>

From dsewell at virginia.edu  Tue Sep 11 21:22:26 2012
From: dsewell at virginia.edu (David Sewell)
Date: Tue, 11 Sep 2012 21:22:26 -0400 (EDT)
Subject: [tei-council] tcw20.xml (Editing the TEI Guidelines): Attention
 David
In-Reply-To: <504F9E73.5020805@uvic.ca>
References: <5048E7D2.6030904@uvic.ca> <504942A9.2010900@it.ox.ac.uk>
	<504F9E73.5020805@uvic.ca>
Message-ID: <alpine.OSX.2.00.1209112117070.6930@betwix.local>

The problem with what you added doesn't seem to be the use of 
exemplum/egXML per se. Rather, it looks like something in there is 
triggering a Java parser bug. I'm in the middle of a process of 
elimination to try to figure out what's going on.

David

On Tue, 11 Sep 2012, Martin Holmes wrote:

> Hi David,
>
> Now you're back, when you have a moment, could you comment on this? How
> easy would it be to edit the XSLT tranformation that handles the TCW
> documents in the CMS?
>
> On 12-09-06 05:41 PM, James Cummings wrote:
>> On 06/09/12 19:13, Martin Holmes wrote:
>
>>>
>> I've just completed one of my Ann Arbor obligations by documenting the
>>> process of adding a Schematron constraint along with tests for that
>>> constraint. I've written quite a long section, and you can see the
>>> results here:
>>>
>>> <http://hcmc.uvic.ca/people/martin/tcw20.html#schematron>
>>>
>>> All comments appreciated.
> >>
>>> However, writing it required the use of<exemplum>,<egXML>  and friends.
>>> Unfortunately, the TCW documents (and I assume their associated
>>> transformation) are TEI Lite documents, so when I add my code to the
>>> tcw20.xml file on the TEI site (in CMS), the transform fails and the
>>> page does not show up. So I've had to comment out my new section for the
>>> moment.
>>>
>>> What should we do about this? Could we transition the tcw files to full
>>> TEI, and use the default P5 XHTML conversion to render them on the CMS?
>>> It's going to be a bit difficult to provide good documentation for
>>> ourselves if we're prevented from using documentation elements.
>>
>> Interesting problem -- I might suggest we wait until David Sewell
>> is back off holiday to double check with him how difficult this
>> might be in openCMS.
>>
>> -James
>
> Cheers,
> Martin
>
>

-- 
David Sewell, Editorial and Technical Manager
ROTUNDA, The University of Virginia Press
PO Box 400314, Charlottesville, VA 22904-4314 USA
Email: dsewell at virginia.edu   Tel: +1 434 924 9973
Web: http://rotunda.upress.virginia.edu/

From dsewell at virginia.edu  Tue Sep 11 23:08:31 2012
From: dsewell at virginia.edu (David Sewell)
Date: Tue, 11 Sep 2012 23:08:31 -0400 (EDT)
Subject: [tei-council] tcw20.xml (Editing the TEI Guidelines)
In-Reply-To: <5048E7D2.6030904@uvic.ca>
References: <5048E7D2.6030904@uvic.ca>
Message-ID: <alpine.OSX.2.00.1209112259140.6930@betwix.local>

Martin et al.,

The added code in tcw20.html was throwing a server error because 
something in the XSLT stylesheets is triggering a bug when <ref> is a 
child of <q>. The workaround was to transform the one instance of that 
construct to replace <q>...</q> with ?...?. (Googling, I find Michael 
Kay referring to a bug involving tunnel parameters and an older version 
of Saxon; not sure if that's what is biting our OpenCMS as I don't know 
if it's using Saxon for a parser.)

The XSLT stylesheet within OpenCMS does in fact have a template rule for 
<egXML> but it is not very robust.

I hate to say it, but for purposes of the ordinary web pages (as opposed 
to the Guidelines) I think you'd be better off using <ab> with CDATA 
content formatted as desired.

Anyway, if you go into OpenCMS now and take a look at tcw20.xml you'll 
see your section appear; you can steal the lock and edit/publish if you 
wish.

It might be time to try a wholesale replacement of the version of 
tei2.xsl used to format the OpenCMS pages, only I'm not sure there's a 
current one using XSLT 1.0? And the other problem affecting changes to 
the XSLT is that I believe the stylesheet must be "published" to take 
effect even within the offline context of OpenCMS, meaning if it is 
buggy it affects the world-viewable site as well.

David

On Thu, 6 Sep 2012, Martin Holmes wrote:

> Hi all,
>
> I've just completed one of my Ann Arbor obligations by documenting the
> process of adding a Schematron constraint along with tests for that
> constraint. I've written quite a long section, and you can see the
> results here:
>
> <http://hcmc.uvic.ca/people/martin/tcw20.html#schematron>
>
> All comments appreciated.
>
> However, writing it required the use of <exemplum>, <egXML> and friends.
> Unfortunately, the TCW documents (and I assume their associated
> transformation) are TEI Lite documents, so when I add my code to the
> tcw20.xml file on the TEI site (in CMS), the transform fails and the
> page does not show up. So I've had to comment out my new section for the
> moment.
>
> What should we do about this? Could we transition the tcw files to full
> TEI, and use the default P5 XHTML conversion to render them on the CMS?
> It's going to be a bit difficult to provide good documentation for
> ourselves if we're prevented from using documentation elements.
>
> Cheers,
> Martin
>

-- 
David Sewell, Editorial and Technical Manager
ROTUNDA, The University of Virginia Press
PO Box 400314, Charlottesville, VA 22904-4314 USA
Email: dsewell at virginia.edu   Tel: +1 434 924 9973
Web: http://rotunda.upress.virginia.edu/

From mholmes at uvic.ca  Wed Sep 12 11:23:18 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Wed, 12 Sep 2012 08:23:18 -0700
Subject: [tei-council] tcw20.xml (Editing the TEI Guidelines)
In-Reply-To: <alpine.OSX.2.00.1209112259140.6930@betwix.local>
References: <5048E7D2.6030904@uvic.ca>
	<alpine.OSX.2.00.1209112259140.6930@betwix.local>
Message-ID: <5050A8E6.6040101@uvic.ca>

Thanks indeed for debugging this. I've tweaked the whitespace a bit and 
I think it looks fine now.

Any comments from Council on the actual content would be welcome -- 
imagine yourself in the position of having to add a Schematron 
constraint to a classSpec or an elementSpec -- would my instructions be 
clear and helpful enough?

<http://www.tei-c.org/Activities/Council/Working/tcw20.xml#schematron>

Cheers,
Martin

On 12-09-11 08:08 PM, David Sewell wrote:
> Martin et al.,
>
> The added code in tcw20.html was throwing a server error because
> something in the XSLT stylesheets is triggering a bug when <ref> is a
> child of <q>. The workaround was to transform the one instance of that
> construct to replace <q>...</q> with ?...?. (Googling, I find Michael
> Kay referring to a bug involving tunnel parameters and an older version
> of Saxon; not sure if that's what is biting our OpenCMS as I don't know
> if it's using Saxon for a parser.)
>
> The XSLT stylesheet within OpenCMS does in fact have a template rule for
> <egXML> but it is not very robust.
>
> I hate to say it, but for purposes of the ordinary web pages (as opposed
> to the Guidelines) I think you'd be better off using <ab> with CDATA
> content formatted as desired.
>
> Anyway, if you go into OpenCMS now and take a look at tcw20.xml you'll
> see your section appear; you can steal the lock and edit/publish if you
> wish.
>
> It might be time to try a wholesale replacement of the version of
> tei2.xsl used to format the OpenCMS pages, only I'm not sure there's a
> current one using XSLT 1.0? And the other problem affecting changes to
> the XSLT is that I believe the stylesheet must be "published" to take
> effect even within the offline context of OpenCMS, meaning if it is
> buggy it affects the world-viewable site as well.
>
> David
>
> On Thu, 6 Sep 2012, Martin Holmes wrote:
>
>> Hi all,
>>
>> I've just completed one of my Ann Arbor obligations by documenting the
>> process of adding a Schematron constraint along with tests for that
>> constraint. I've written quite a long section, and you can see the
>> results here:
>>
>> <http://hcmc.uvic.ca/people/martin/tcw20.html#schematron>
>>
>> All comments appreciated.
>>
>> However, writing it required the use of <exemplum>, <egXML> and friends.
>> Unfortunately, the TCW documents (and I assume their associated
>> transformation) are TEI Lite documents, so when I add my code to the
>> tcw20.xml file on the TEI site (in CMS), the transform fails and the
>> page does not show up. So I've had to comment out my new section for the
>> moment.
>>
>> What should we do about this? Could we transition the tcw files to full
>> TEI, and use the default P5 XHTML conversion to render them on the CMS?
>> It's going to be a bit difficult to provide good documentation for
>> ourselves if we're prevented from using documentation elements.
>>
>> Cheers,
>> Martin
>>
>

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From kevin.s.hawkins at ultraslavonic.info  Wed Sep 12 22:43:58 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Wed, 12 Sep 2012 22:43:58 -0400
Subject: [tei-council] tcw20.xml (Editing the TEI Guidelines)
In-Reply-To: <5050A8E6.6040101@uvic.ca>
References: <5048E7D2.6030904@uvic.ca>
	<alpine.OSX.2.00.1209112259140.6930@betwix.local>
	<5050A8E6.6040101@uvic.ca>
Message-ID: <5051486E.9060807@ultraslavonic.info>

While this is very helpful, it seems that the first half of it needs to 
be adapted for inclusion in chapter 23 of the Guidelines.  That is, we 
would not refer to specific files like att.datable.xml and not refer to 
something that has already been added into the Guidelines.  After all, 
if anyone not on Council wants to use Schematron, they would never think 
to look at tcw20 (or even know it exists)!  What you would leave here is 
the explanation of how trunk/P5/Text works and what follows.

Still, here are a few comments for now:

a) You write, "Inside <constraintSpec> , <constraints> s have <assert> 
elements, which have @test attributes, which are XPath".

Are @test attributes always expressed in XPath, or is that just the case 
in this example?

b) I don't care for use of "to fire" and "to be fired" in reference to a 
test condition.

c) Is <report> (fires when true) being contrasted with <assert> (fires 
when false)?  This is implied but not stated explicitly.

d) For clarity, you might explain that a Schematron schema checks only 
the Schematron constraints but nothing else typically expressed in a 
DTD, RELAX NG, or XML Schema (or maybe I'm wrong about that).

e) You write, "We'll go through the process of adding a constraint like 
this."

Like what?

f) You have an example with @xmlns:sch on <constraintSpec> but in the 
following paragraph say that the user needs to add the Schematron 
namespace "to the <classSpec> root element".  Regardless of which way 
you meant it, strictly speaking the namespace isn't required to be in 
just one place or the other: you can do it different ways.  So you might 
want to say something about making sure the namespace is declared.  This 
unfortunately relies on the user to understand how namespaces work and 
your various options for declaring them.

g) Why do the pampelmousse and later code snippets have @xmlns:sch at 
all?  I would remove them for clarity.

--K.

On 9/12/12 11:23 AM, Martin Holmes wrote:
> Thanks indeed for debugging this. I've tweaked the whitespace a bit and
> I think it looks fine now.
>
> Any comments from Council on the actual content would be welcome --
> imagine yourself in the position of having to add a Schematron
> constraint to a classSpec or an elementSpec -- would my instructions be
> clear and helpful enough?
>
> <http://www.tei-c.org/Activities/Council/Working/tcw20.xml#schematron>
>
> Cheers,
> Martin
>
> On 12-09-11 08:08 PM, David Sewell wrote:
>> Martin et al.,
>>
>> The added code in tcw20.html was throwing a server error because
>> something in the XSLT stylesheets is triggering a bug when <ref> is a
>> child of <q>. The workaround was to transform the one instance of that
>> construct to replace <q>...</q> with ?...?. (Googling, I find Michael
>> Kay referring to a bug involving tunnel parameters and an older version
>> of Saxon; not sure if that's what is biting our OpenCMS as I don't know
>> if it's using Saxon for a parser.)
>>
>> The XSLT stylesheet within OpenCMS does in fact have a template rule for
>> <egXML> but it is not very robust.
>>
>> I hate to say it, but for purposes of the ordinary web pages (as opposed
>> to the Guidelines) I think you'd be better off using <ab> with CDATA
>> content formatted as desired.
>>
>> Anyway, if you go into OpenCMS now and take a look at tcw20.xml you'll
>> see your section appear; you can steal the lock and edit/publish if you
>> wish.
>>
>> It might be time to try a wholesale replacement of the version of
>> tei2.xsl used to format the OpenCMS pages, only I'm not sure there's a
>> current one using XSLT 1.0? And the other problem affecting changes to
>> the XSLT is that I believe the stylesheet must be "published" to take
>> effect even within the offline context of OpenCMS, meaning if it is
>> buggy it affects the world-viewable site as well.
>>
>> David
>>
>> On Thu, 6 Sep 2012, Martin Holmes wrote:
>>
>>> Hi all,
>>>
>>> I've just completed one of my Ann Arbor obligations by documenting the
>>> process of adding a Schematron constraint along with tests for that
>>> constraint. I've written quite a long section, and you can see the
>>> results here:
>>>
>>> <http://hcmc.uvic.ca/people/martin/tcw20.html#schematron>
>>>
>>> All comments appreciated.
>>>
>>> However, writing it required the use of <exemplum>, <egXML> and friends.
>>> Unfortunately, the TCW documents (and I assume their associated
>>> transformation) are TEI Lite documents, so when I add my code to the
>>> tcw20.xml file on the TEI site (in CMS), the transform fails and the
>>> page does not show up. So I've had to comment out my new section for the
>>> moment.
>>>
>>> What should we do about this? Could we transition the tcw files to full
>>> TEI, and use the default P5 XHTML conversion to render them on the CMS?
>>> It's going to be a bit difficult to provide good documentation for
>>> ourselves if we're prevented from using documentation elements.
>>>
>>> Cheers,
>>> Martin
>>>
>>
>

From mholmes at uvic.ca  Thu Sep 13 00:00:54 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Wed, 12 Sep 2012 21:00:54 -0700
Subject: [tei-council] tcw20.xml (Editing the TEI Guidelines)
In-Reply-To: <5051486E.9060807@ultraslavonic.info>
References: <5048E7D2.6030904@uvic.ca>
	<alpine.OSX.2.00.1209112259140.6930@betwix.local>	<5050A8E6.6040101@uvic.ca>
	<5051486E.9060807@ultraslavonic.info>
Message-ID: <50515A76.5060108@uvic.ca>

Hi Kevin,

On 12-09-12 07:43 PM, Kevin Hawkins wrote:
> While this is very helpful, it seems that the first half of it needs to
> be adapted for inclusion in chapter 23 of the Guidelines.  That is, we
> would not refer to specific files like att.datable.xml and not refer to
> something that has already been added into the Guidelines.  After all,
> if anyone not on Council wants to use Schematron, they would never think
> to look at tcw20 (or even know it exists)!  What you would leave here is
> the explanation of how trunk/P5/Text works and what follows.

I have nothing against including it in the Guidelines, but I think if we 
do start explaining how to use Schematron in the Glines we'll have to 
start from the assumption that readers know less and are much less 
familiar that Council members are with the TEI infrastructure. That 
wasn't my brief. I'm trying to write specifically for people with enough 
understanding of the system that they've made some edits in trunk 
already, seen Jenkins build, and are ready to move on to something 
slightly more challenging.

> Still, here are a few comments for now:
>
> a) You write, "Inside <constraintSpec> , <constraints> s have <assert>
> elements, which have @test attributes, which are XPath".
>
> Are @test attributes always expressed in XPath, or is that just the case
> in this example?

As far as I know. I don't think you can express Schematron constraints 
any other way.

> b) I don't care for use of "to fire" and "to be fired" in reference to a
> test condition.

I think it's pretty much exactly what happens. We could use "triggered" 
too. What else do you suggest?

> c) Is <report> (fires when true) being contrasted with <assert> (fires
> when false)?  This is implied but not stated explicitly.

Yes. I should have made that clearer. I guess I was starting from the 
assumption that people would know a little bit about Schematron already, 
but you're probably right that I shouldn't make that assumption.

> d) For clarity, you might explain that a Schematron schema checks only
> the Schematron constraints but nothing else typically expressed in a
> DTD, RELAX NG, or XML Schema (or maybe I'm wrong about that).

You're right; each Schematron constraint constitutes its own little 
test, and runs only when its exact context conditions are met. It 
doesn't interact with the other validation processes.

> e) You write, "We'll go through the process of adding a constraint like
> this."
>
> Like what?

I guess I meant "like the one above". I'll make it so.

> f) You have an example with @xmlns:sch on <constraintSpec> but in the
> following paragraph say that the user needs to add the Schematron
> namespace "to the <classSpec> root element".  Regardless of which way
> you meant it, strictly speaking the namespace isn't required to be in
> just one place or the other: you can do it different ways.  So you might
> want to say something about making sure the namespace is declared.  This
> unfortunately relies on the user to understand how namespaces work and
> your various options for declaring them.

Good point. I think I was declaring it on the root because I had a vague 
expectation of adding more constraints to the same file, but perhaps we 
should come up with a standard way that we intend to do this, for the 
sake of clarity.

> g) Why do the pampelmousse and later code snippets have @xmlns:sch at
> all?  I would remove them for clarity.

They were in the code already, so I left them as they were. If we make a 
decision to do this one particular way (e.g. always declare the 
namespace on the root element of the file, and use the sch prefix 
everywhere else) then we can normalize all existing practice. But 
Sebastian may know of a reason why not -- perhaps there's a non-XML 
process somewhere that lifts out the Schematron snippets and needs them 
to be internally coherent.

Cheers,
Martin

> --K.
>
> On 9/12/12 11:23 AM, Martin Holmes wrote:
>> Thanks indeed for debugging this. I've tweaked the whitespace a bit and
>> I think it looks fine now.
>>
>> Any comments from Council on the actual content would be welcome --
>> imagine yourself in the position of having to add a Schematron
>> constraint to a classSpec or an elementSpec -- would my instructions be
>> clear and helpful enough?
>>
>> <http://www.tei-c.org/Activities/Council/Working/tcw20.xml#schematron>
>>
>> Cheers,
>> Martin
>>
>> On 12-09-11 08:08 PM, David Sewell wrote:
>>> Martin et al.,
>>>
>>> The added code in tcw20.html was throwing a server error because
>>> something in the XSLT stylesheets is triggering a bug when <ref> is a
>>> child of <q>. The workaround was to transform the one instance of that
>>> construct to replace <q>...</q> with ?...?. (Googling, I find Michael
>>> Kay referring to a bug involving tunnel parameters and an older version
>>> of Saxon; not sure if that's what is biting our OpenCMS as I don't know
>>> if it's using Saxon for a parser.)
>>>
>>> The XSLT stylesheet within OpenCMS does in fact have a template rule for
>>> <egXML> but it is not very robust.
>>>
>>> I hate to say it, but for purposes of the ordinary web pages (as opposed
>>> to the Guidelines) I think you'd be better off using <ab> with CDATA
>>> content formatted as desired.
>>>
>>> Anyway, if you go into OpenCMS now and take a look at tcw20.xml you'll
>>> see your section appear; you can steal the lock and edit/publish if you
>>> wish.
>>>
>>> It might be time to try a wholesale replacement of the version of
>>> tei2.xsl used to format the OpenCMS pages, only I'm not sure there's a
>>> current one using XSLT 1.0? And the other problem affecting changes to
>>> the XSLT is that I believe the stylesheet must be "published" to take
>>> effect even within the offline context of OpenCMS, meaning if it is
>>> buggy it affects the world-viewable site as well.
>>>
>>> David
>>>
>>> On Thu, 6 Sep 2012, Martin Holmes wrote:
>>>
>>>> Hi all,
>>>>
>>>> I've just completed one of my Ann Arbor obligations by documenting the
>>>> process of adding a Schematron constraint along with tests for that
>>>> constraint. I've written quite a long section, and you can see the
>>>> results here:
>>>>
>>>> <http://hcmc.uvic.ca/people/martin/tcw20.html#schematron>
>>>>
>>>> All comments appreciated.
>>>>
>>>> However, writing it required the use of <exemplum>, <egXML> and friends.
>>>> Unfortunately, the TCW documents (and I assume their associated
>>>> transformation) are TEI Lite documents, so when I add my code to the
>>>> tcw20.xml file on the TEI site (in CMS), the transform fails and the
>>>> page does not show up. So I've had to comment out my new section for the
>>>> moment.
>>>>
>>>> What should we do about this? Could we transition the tcw files to full
>>>> TEI, and use the default P5 XHTML conversion to render them on the CMS?
>>>> It's going to be a bit difficult to provide good documentation for
>>>> ourselves if we're prevented from using documentation elements.
>>>>
>>>> Cheers,
>>>> Martin
>>>>
>>>
>>

From mholmes at uvic.ca  Thu Sep 13 11:59:46 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Thu, 13 Sep 2012 08:59:46 -0700
Subject: [tei-council] tcw20.xml (Editing the TEI Guidelines)
In-Reply-To: <50515A76.5060108@uvic.ca>
References: <5048E7D2.6030904@uvic.ca>
	<alpine.OSX.2.00.1209112259140.6930@betwix.local>	<5050A8E6.6040101@uvic.ca>
	<5051486E.9060807@ultraslavonic.info> <50515A76.5060108@uvic.ca>
Message-ID: <505202F2.8010602@uvic.ca>

Hi Kevin,

I've made some changes based on your input, for which many thanks. One 
thing I have discovered is that the profusion of xmlns:sch definitions 
in the examples is actually the fault of the transformation in the CMS; 
they're not there in the source code. I wonder if we could get that 
fixed? For instance, this in the source:

         <exemplum xml:lang="en">
           <egXML xmlns="http://www.tei-c.org/ns/Examples" valid="true">
<date calendar="#julian">January, 1622</date>
           </egXML>
         </exemplum>

gives rise to this in the rendered output:

  <date calendar="#julian" 
xmlns:sch="http://purl.oclc.org/dsdl/schematron">January, 1622</date>

which is actually misleading. The Schematron namespace is declared in 
the root TEI element of the TCW20 XML doc, which might be the reason for 
its being copied into every example. Perhaps David can tell us if it 
would be an easy tweak to fix that?

Cheers,
Martin

On 12-09-12 09:00 PM, Martin Holmes wrote:
> Hi Kevin,
>
> On 12-09-12 07:43 PM, Kevin Hawkins wrote:
>> While this is very helpful, it seems that the first half of it needs to
>> be adapted for inclusion in chapter 23 of the Guidelines.  That is, we
>> would not refer to specific files like att.datable.xml and not refer to
>> something that has already been added into the Guidelines.  After all,
>> if anyone not on Council wants to use Schematron, they would never think
>> to look at tcw20 (or even know it exists)!  What you would leave here is
>> the explanation of how trunk/P5/Text works and what follows.
>
> I have nothing against including it in the Guidelines, but I think if we
> do start explaining how to use Schematron in the Glines we'll have to
> start from the assumption that readers know less and are much less
> familiar that Council members are with the TEI infrastructure. That
> wasn't my brief. I'm trying to write specifically for people with enough
> understanding of the system that they've made some edits in trunk
> already, seen Jenkins build, and are ready to move on to something
> slightly more challenging.
>
>> Still, here are a few comments for now:
>>
>> a) You write, "Inside <constraintSpec> , <constraints> s have <assert>
>> elements, which have @test attributes, which are XPath".
>>
>> Are @test attributes always expressed in XPath, or is that just the case
>> in this example?
>
> As far as I know. I don't think you can express Schematron constraints
> any other way.
>
>> b) I don't care for use of "to fire" and "to be fired" in reference to a
>> test condition.
>
> I think it's pretty much exactly what happens. We could use "triggered"
> too. What else do you suggest?
>
>> c) Is <report> (fires when true) being contrasted with <assert> (fires
>> when false)?  This is implied but not stated explicitly.
>
> Yes. I should have made that clearer. I guess I was starting from the
> assumption that people would know a little bit about Schematron already,
> but you're probably right that I shouldn't make that assumption.
>
>> d) For clarity, you might explain that a Schematron schema checks only
>> the Schematron constraints but nothing else typically expressed in a
>> DTD, RELAX NG, or XML Schema (or maybe I'm wrong about that).
>
> You're right; each Schematron constraint constitutes its own little
> test, and runs only when its exact context conditions are met. It
> doesn't interact with the other validation processes.
>
>> e) You write, "We'll go through the process of adding a constraint like
>> this."
>>
>> Like what?
>
> I guess I meant "like the one above". I'll make it so.
>
>> f) You have an example with @xmlns:sch on <constraintSpec> but in the
>> following paragraph say that the user needs to add the Schematron
>> namespace "to the <classSpec> root element".  Regardless of which way
>> you meant it, strictly speaking the namespace isn't required to be in
>> just one place or the other: you can do it different ways.  So you might
>> want to say something about making sure the namespace is declared.  This
>> unfortunately relies on the user to understand how namespaces work and
>> your various options for declaring them.
>
> Good point. I think I was declaring it on the root because I had a vague
> expectation of adding more constraints to the same file, but perhaps we
> should come up with a standard way that we intend to do this, for the
> sake of clarity.
>
>> g) Why do the pampelmousse and later code snippets have @xmlns:sch at
>> all?  I would remove them for clarity.
>
> They were in the code already, so I left them as they were. If we make a
> decision to do this one particular way (e.g. always declare the
> namespace on the root element of the file, and use the sch prefix
> everywhere else) then we can normalize all existing practice. But
> Sebastian may know of a reason why not -- perhaps there's a non-XML
> process somewhere that lifts out the Schematron snippets and needs them
> to be internally coherent.
>
> Cheers,
> Martin
>
>> --K.
>>
>> On 9/12/12 11:23 AM, Martin Holmes wrote:
>>> Thanks indeed for debugging this. I've tweaked the whitespace a bit and
>>> I think it looks fine now.
>>>
>>> Any comments from Council on the actual content would be welcome --
>>> imagine yourself in the position of having to add a Schematron
>>> constraint to a classSpec or an elementSpec -- would my instructions be
>>> clear and helpful enough?
>>>
>>> <http://www.tei-c.org/Activities/Council/Working/tcw20.xml#schematron>
>>>
>>> Cheers,
>>> Martin
>>>
>>> On 12-09-11 08:08 PM, David Sewell wrote:
>>>> Martin et al.,
>>>>
>>>> The added code in tcw20.html was throwing a server error because
>>>> something in the XSLT stylesheets is triggering a bug when <ref> is a
>>>> child of <q>. The workaround was to transform the one instance of that
>>>> construct to replace <q>...</q> with ?...?. (Googling, I find Michael
>>>> Kay referring to a bug involving tunnel parameters and an older version
>>>> of Saxon; not sure if that's what is biting our OpenCMS as I don't know
>>>> if it's using Saxon for a parser.)
>>>>
>>>> The XSLT stylesheet within OpenCMS does in fact have a template rule for
>>>> <egXML> but it is not very robust.
>>>>
>>>> I hate to say it, but for purposes of the ordinary web pages (as opposed
>>>> to the Guidelines) I think you'd be better off using <ab> with CDATA
>>>> content formatted as desired.
>>>>
>>>> Anyway, if you go into OpenCMS now and take a look at tcw20.xml you'll
>>>> see your section appear; you can steal the lock and edit/publish if you
>>>> wish.
>>>>
>>>> It might be time to try a wholesale replacement of the version of
>>>> tei2.xsl used to format the OpenCMS pages, only I'm not sure there's a
>>>> current one using XSLT 1.0? And the other problem affecting changes to
>>>> the XSLT is that I believe the stylesheet must be "published" to take
>>>> effect even within the offline context of OpenCMS, meaning if it is
>>>> buggy it affects the world-viewable site as well.
>>>>
>>>> David
>>>>
>>>> On Thu, 6 Sep 2012, Martin Holmes wrote:
>>>>
>>>>> Hi all,
>>>>>
>>>>> I've just completed one of my Ann Arbor obligations by documenting the
>>>>> process of adding a Schematron constraint along with tests for that
>>>>> constraint. I've written quite a long section, and you can see the
>>>>> results here:
>>>>>
>>>>> <http://hcmc.uvic.ca/people/martin/tcw20.html#schematron>
>>>>>
>>>>> All comments appreciated.
>>>>>
>>>>> However, writing it required the use of <exemplum>, <egXML> and friends.
>>>>> Unfortunately, the TCW documents (and I assume their associated
>>>>> transformation) are TEI Lite documents, so when I add my code to the
>>>>> tcw20.xml file on the TEI site (in CMS), the transform fails and the
>>>>> page does not show up. So I've had to comment out my new section for the
>>>>> moment.
>>>>>
>>>>> What should we do about this? Could we transition the tcw files to full
>>>>> TEI, and use the default P5 XHTML conversion to render them on the CMS?
>>>>> It's going to be a bit difficult to provide good documentation for
>>>>> ourselves if we're prevented from using documentation elements.
>>>>>
>>>>> Cheers,
>>>>> Martin
>>>>>
>>>>
>>>

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From sebastian.rahtz at it.ox.ac.uk  Thu Sep 13 12:05:27 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Thu, 13 Sep 2012 16:05:27 +0000
Subject: [tei-council] tcw20.xml (Editing the TEI Guidelines)
In-Reply-To: <505202F2.8010602@uvic.ca>
References: <5048E7D2.6030904@uvic.ca>
	<alpine.OSX.2.00.1209112259140.6930@betwix.local>	<5050A8E6.6040101@uvic.ca>
	<5051486E.9060807@ultraslavonic.info> <50515A76.5060108@uvic.ca>
	<505202F2.8010602@uvic.ca>
Message-ID: <4BDCE833-7826-4F16-82D3-DB7629BAEA8C@it.ox.ac.uk>


On 13 Sep 2012, at 16:59, Martin Holmes <mholmes at uvic.ca>
 wrote:

> 
> 
> which is actually misleading. The Schematron namespace is declared in 
> the root TEI element of the TCW20 XML doc, which might be the reason for 
> its being copied into every example. Perhaps David can tell us if it 
> would be an easy tweak to fix that?


you could work around that by adding xmlns="http://purl.oclc.org/dsdl/schematron" to each
example

if you wanted
--
Sebastian Rahtz      
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431


From mholmes at uvic.ca  Thu Sep 13 12:26:08 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Thu, 13 Sep 2012 09:26:08 -0700
Subject: [tei-council] tcw20.xml (Editing the TEI Guidelines)
In-Reply-To: <4BDCE833-7826-4F16-82D3-DB7629BAEA8C@it.ox.ac.uk>
References: <5048E7D2.6030904@uvic.ca>
	<alpine.OSX.2.00.1209112259140.6930@betwix.local>	<5050A8E6.6040101@uvic.ca>
	<5051486E.9060807@ultraslavonic.info>
	<50515A76.5060108@uvic.ca> <505202F2.8010602@uvic.ca>
	<4BDCE833-7826-4F16-82D3-DB7629BAEA8C@it.ox.ac.uk>
Message-ID: <50520920.3070304@uvic.ca>

On 12-09-13 09:05 AM, Sebastian Rahtz wrote:
>
> On 13 Sep 2012, at 16:59, Martin Holmes <mholmes at uvic.ca>
>   wrote:
>
>>
>>
>> which is actually misleading. The Schematron namespace is declared in
>> the root TEI element of the TCW20 XML doc, which might be the reason for
>> its being copied into every example. Perhaps David can tell us if it
>> would be an easy tweak to fix that?
>
>
> you could work around that by adding xmlns="http://purl.oclc.org/dsdl/schematron" to each
> example
>
> if you wanted

I'll try that. I don't actually remember adding the Schematron ns 
declaration to the <TEI> element in TCW20, so I should perhaps be 
cautious about removing it. I'll experiment in a bit.

Cheers,
Martin

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From kevin.s.hawkins at ultraslavonic.info  Thu Sep 13 13:48:23 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Thu, 13 Sep 2012 13:48:23 -0400
Subject: [tei-council] tcw20.xml (Editing the TEI Guidelines)
In-Reply-To: <50515A76.5060108@uvic.ca>
References: <5048E7D2.6030904@uvic.ca>
	<alpine.OSX.2.00.1209112259140.6930@betwix.local>	<5050A8E6.6040101@uvic.ca>
	<5051486E.9060807@ultraslavonic.info> <50515A76.5060108@uvic.ca>
Message-ID: <50521C67.5030908@ultraslavonic.info>

On 9/13/2012 12:00 AM, Martin Holmes wrote:
> Hi Kevin,
>
> On 12-09-12 07:43 PM, Kevin Hawkins wrote:
>> While this is very helpful, it seems that the first half of it needs to
>> be adapted for inclusion in chapter 23 of the Guidelines. That is, we
>> would not refer to specific files like att.datable.xml and not refer to
>> something that has already been added into the Guidelines. After all,
>> if anyone not on Council wants to use Schematron, they would never think
>> to look at tcw20 (or even know it exists)! What you would leave here is
>> the explanation of how trunk/P5/Text works and what follows.
>
> I have nothing against including it in the Guidelines, but I think if we
> do start explaining how to use Schematron in the Glines we'll have to
> start from the assumption that readers know less and are much less
> familiar that Council members are with the TEI infrastructure. That
> wasn't my brief. I'm trying to write specifically for people with enough
> understanding of the system that they've made some edits in trunk
> already, seen Jenkins build, and are ready to move on to something
> slightly more challenging.

Right, I understand.  But the first half of 
http://hcmc.uvic.ca/people/martin/tcw20.html#schematron does not assume 
that a user knows anything about the TEI infrastructure beyond what's 
already in the Guidelines.  So I think it could be incorporated easily 
enough.

>> b) I don't care for use of "to fire" and "to be fired" in reference to a
>> test condition.
>
> I think it's pretty much exactly what happens. We could use "triggered"
> too. What else do you suggest?

While "triggered" is okay, I prefer something more neutral like saying 
that a condition is met or satisfied.  "To fire" wouldn't easily 
understood by a non-native speaker.

--K.

From mholmes at uvic.ca  Thu Sep 13 14:23:38 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Thu, 13 Sep 2012 11:23:38 -0700
Subject: [tei-council] tcw20.xml (Editing the TEI Guidelines)
In-Reply-To: <50521C67.5030908@ultraslavonic.info>
References: <5048E7D2.6030904@uvic.ca>
	<alpine.OSX.2.00.1209112259140.6930@betwix.local>	<5050A8E6.6040101@uvic.ca>
	<5051486E.9060807@ultraslavonic.info> <50515A76.5060108@uvic.ca>
	<50521C67.5030908@ultraslavonic.info>
Message-ID: <505224AA.3090902@uvic.ca>

Hi Kevin,

On 12-09-13 10:48 AM, Kevin Hawkins wrote:
> On 9/13/2012 12:00 AM, Martin Holmes wrote:
>> Hi Kevin,
>>
>> On 12-09-12 07:43 PM, Kevin Hawkins wrote:
>>> While this is very helpful, it seems that the first half of it needs to
>>> be adapted for inclusion in chapter 23 of the Guidelines. That is, we
>>> would not refer to specific files like att.datable.xml and not refer to
>>> something that has already been added into the Guidelines. After all,
>>> if anyone not on Council wants to use Schematron, they would never think
>>> to look at tcw20 (or even know it exists)! What you would leave here is
>>> the explanation of how trunk/P5/Text works and what follows.
>>
>> I have nothing against including it in the Guidelines, but I think if we
>> do start explaining how to use Schematron in the Glines we'll have to
>> start from the assumption that readers know less and are much less
>> familiar that Council members are with the TEI infrastructure. That
>> wasn't my brief. I'm trying to write specifically for people with enough
>> understanding of the system that they've made some edits in trunk
>> already, seen Jenkins build, and are ready to move on to something
>> slightly more challenging.
>
> Right, I understand.  But the first half of
> http://hcmc.uvic.ca/people/martin/tcw20.html#schematron does not assume
> that a user knows anything about the TEI infrastructure beyond what's
> already in the Guidelines.  So I think it could be incorporated easily
> enough.

We should decide whether it's the business of the Guidelines to cover 
slightly peripheral and advanced topics such as Schematron. If so, it 
would be easy to write a full section which assumes no knowledge on the 
part of the reader. The TCW20 section could then refer to that part of 
the Guidelines. But I'm not sure we really want to deal with Schematron 
in the Guidelines in any more detail than is already here:

<http://www.tei-c.org/release/doc/tei-p5-doc/en/html/TD.html#TDTAGCONS>

>>> b) I don't care for use of "to fire" and "to be fired" in reference to a
>>> test condition.
>>
>> I think it's pretty much exactly what happens. We could use "triggered"
>> too. What else do you suggest?
>
> While "triggered" is okay, I prefer something more neutral like saying
> that a condition is met or satisfied.  "To fire" wouldn't easily
> understood by a non-native speaker.

I went for "triggered", because it seems to me a better way to capture 
the notion that when a condition is met, something happens (or in the 
case of <report>, when a condition is not met, something happens).

Cheers,
Martin

> --K.
>

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From lou.burnard at retired.ox.ac.uk  Thu Sep 13 14:47:42 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Thu, 13 Sep 2012 19:47:42 +0100
Subject: [tei-council] tcw20.xml (Editing the TEI Guidelines)
In-Reply-To: <505224AA.3090902@uvic.ca>
References: <5048E7D2.6030904@uvic.ca>
	<alpine.OSX.2.00.1209112259140.6930@betwix.local>	<5050A8E6.6040101@uvic.ca>
	<5051486E.9060807@ultraslavonic.info> <50515A76.5060108@uvic.ca>
	<50521C67.5030908@ultraslavonic.info> <505224AA.3090902@uvic.ca>
Message-ID: <50522A4E.1090500@retired.ox.ac.uk>

On 13/09/12 19:23, Martin Holmes wrote:

> We should decide whether it's the business of the Guidelines to cover
> slightly peripheral and advanced topics such as Schematron. If so, it
> would be easy to write a full section which assumes no knowledge on the
> part of the reader. The TCW20 section could then refer to that part of
> the Guidelines. But I'm not sure we really want to deal with Schematron
> in the Guidelines in any more detail than is already here:
>
> <http://www.tei-c.org/release/doc/tei-p5-doc/en/html/TD.html#TDTAGCONS>
>


I suggest that if there is any place where schematron per se needs to be 
discussed in the Guidelines, it should be in the "Gentle Intro" chapter, 
since this "...attempts to give an informal introduction to those parts 
of XML of which a proper understanding is necessary to make best use of 
these Guidelines"

Of course, Schematron isn't exactly XML, but then neither is RelaXNG, 
which is also informally presented in this chapter, precisely because "a 
proper understanding" (read : cocktail party chat competence) of it is 
needed to grok how the Guidelines work. Same thing for Schematron, surely?

How much needs to be added to what is already there in 
http://www.tei-c.org/release/doc/tei-p5-doc/en/html/SG.html#SG-val ?




From kevin.s.hawkins at ultraslavonic.info  Thu Sep 13 15:05:27 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Thu, 13 Sep 2012 15:05:27 -0400
Subject: [tei-council] tcw20.xml (Editing the TEI Guidelines)
In-Reply-To: <50522A4E.1090500@retired.ox.ac.uk>
References: <5048E7D2.6030904@uvic.ca>	<alpine.OSX.2.00.1209112259140.6930@betwix.local>	<5050A8E6.6040101@uvic.ca>	<5051486E.9060807@ultraslavonic.info>
	<50515A76.5060108@uvic.ca>	<50521C67.5030908@ultraslavonic.info>
	<505224AA.3090902@uvic.ca> <50522A4E.1090500@retired.ox.ac.uk>
Message-ID: <50522E77.5050005@ultraslavonic.info>

On 9/13/2012 2:47 PM, Lou Burnard wrote:
> On 13/09/12 19:23, Martin Holmes wrote:
>
>> We should decide whether it's the business of the Guidelines to cover
>> slightly peripheral and advanced topics such as Schematron. If so, it
>> would be easy to write a full section which assumes no knowledge on the
>> part of the reader. The TCW20 section could then refer to that part of
>> the Guidelines. But I'm not sure we really want to deal with Schematron
>> in the Guidelines in any more detail than is already here:
>>
>> <http://www.tei-c.org/release/doc/tei-p5-doc/en/html/TD.html#TDTAGCONS>
>>
>
>
> I suggest that if there is any place where schematron per se needs to be
> discussed in the Guidelines, it should be in the "Gentle Intro" chapter,
> since this "...attempts to give an informal introduction to those parts
> of XML of which a proper understanding is necessary to make best use of
> these Guidelines"
>
> Of course, Schematron isn't exactly XML, but then neither is RelaXNG,
> which is also informally presented in this chapter, precisely because "a
> proper understanding" (read : cocktail party chat competence) of it is
> needed to grok how the Guidelines work. Same thing for Schematron, surely?
>
> How much needs to be added to what is already there in
> http://www.tei-c.org/release/doc/tei-p5-doc/en/html/SG.html#SG-val ?

Oh dear.  I always forget about chapter 22.  (In fact, I would probably 
be better at writing customizations if I consulted it in addition to 
chapter 23.)  So chap. 22 does indeed discuss Schematron.

Still, I think we should have a cross-reference from somewhere in 
chapter 23 to 
http://www.tei-c.org/release/doc/tei-p5-doc/en/html/TD.html#TDTAGCONS so 
that people know they might write some constraints as part of their 
customization.

I think Schematron is already sufficiently covered in 
http://www.tei-c.org/release/doc/tei-p5-doc/en/html/SG.html#SG-val , but 
if someone wants to say more, I wouldn't be opposed to adding more.

--K.

From mholmes at uvic.ca  Thu Sep 13 15:43:42 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Thu, 13 Sep 2012 12:43:42 -0700
Subject: [tei-council] tcw20.xml (Editing the TEI Guidelines)
In-Reply-To: <50522A4E.1090500@retired.ox.ac.uk>
References: <5048E7D2.6030904@uvic.ca>
	<alpine.OSX.2.00.1209112259140.6930@betwix.local>	<5050A8E6.6040101@uvic.ca>
	<5051486E.9060807@ultraslavonic.info> <50515A76.5060108@uvic.ca>
	<50521C67.5030908@ultraslavonic.info>
	<505224AA.3090902@uvic.ca> <50522A4E.1090500@retired.ox.ac.uk>
Message-ID: <5052376E.8090006@uvic.ca>

On 12-09-13 11:47 AM, Lou Burnard wrote:
> On 13/09/12 19:23, Martin Holmes wrote:
>
>> We should decide whether it's the business of the Guidelines to cover
>> slightly peripheral and advanced topics such as Schematron. If so, it
>> would be easy to write a full section which assumes no knowledge on the
>> part of the reader. The TCW20 section could then refer to that part of
>> the Guidelines. But I'm not sure we really want to deal with Schematron
>> in the Guidelines in any more detail than is already here:
>>
>> <http://www.tei-c.org/release/doc/tei-p5-doc/en/html/TD.html#TDTAGCONS>
>>
>
>
> I suggest that if there is any place where schematron per se needs to be
> discussed in the Guidelines, it should be in the "Gentle Intro" chapter,
> since this "...attempts to give an informal introduction to those parts
> of XML of which a proper understanding is necessary to make best use of
> these Guidelines"
>
> Of course, Schematron isn't exactly XML, but then neither is RelaXNG,
> which is also informally presented in this chapter, precisely because "a
> proper understanding" (read : cocktail party chat competence) of it is
> needed to grok how the Guidelines work. Same thing for Schematron, surely?
>
> How much needs to be added to what is already there in
> http://www.tei-c.org/release/doc/tei-p5-doc/en/html/SG.html#SG-val ?

I would say there's enough there. Schematron is not very hard to figure 
out, assuming you know XPath, and impossible if you don't, so XPath 
would be the actual stumbling block; would we want to start teaching 
people XPath too? I think where good tutorials and intros exist outside 
the Guidelines for topics like this, we should try to stay away from 
covering them, in the interest of keeping the size of the Guidelines 
under control.

An brief listing of related technologies (schema languages, XPath, XSLT, 
XQuery, Schematron, etc. etc.), along with links to good tutorials and 
reasons why you might (or might not) find it useful to learn about them 
would be a good idea, though.

Cheers,
Martin

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From mholmes at uvic.ca  Fri Sep 14 15:36:13 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Fri, 14 Sep 2012 12:36:13 -0700
Subject: [tei-council] New UVic Jenkins server is now the default
Message-ID: <5053872D.6050701@uvic.ca>

Hi all,

I've just finished the process of switching from our old Jenkins server 
(built on Ubuntu 10.04) to the new one (built on 12.04, the latest 
Long-Term Support edition). The server is here:

http://teijenkins.hcmc.uvic.ca

The old URL with the 8080 port number will still work:

http://teijenkins.hcmc.uvic.ca:8080

but I've proxied it through Apache on port 8080 so that when we find 
ourselves in those silly environments where port 8080 is blocked we're 
not inconvenienced.

I've updated TCW20 and 22 with the new address (without port 8080), as 
well as the wiki page about the Jenkins build script. I don't think the 
URL is mentioned anywhere else, but if you come across an instance with 
8080, let me know.

The plan is for this subdomain to be stable in the long term, with new 
servers rotated in as Ubuntu releases come out.

Cheers,
Martin
-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From lou.burnard at retired.ox.ac.uk  Sat Sep 15 07:54:49 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Sat, 15 Sep 2012 12:54:49 +0100
Subject: [tei-council] State of play on GREEN tickets
Message-ID: <50546C89.1050303@retired.ox.ac.uk>

There are only SIX GREEN tickets still open on 15 sep 12. I don't think 
any of them needs any particular discussion at the meeting, unless the 
assignee wants to decline the honour, or report progress. Here's the 
list, just for completeness.

* Allow local modification of attributes belonging to a class FR/3415801
- assigned to rahtz.

* 1.3.2.1 needs repair (clarification of "chunks", "components", and 
related terminology) B/3547934
- assigned to louburnard. Some comments on ticket. Revised wording to be 
drafted for mtg

* Names and Dates chapter does not mention calendar - B/3540863
- assigned to jcummings

* AdBlock blocks 'msad' - B/3472477
- assigned to martindholmes : requires action at next release to 
generate prefixed identifiers throughout text of GL

* i18n revision due - B/3432216
- assigned to rahtz

* change all references to "hosts" to "partners" - B/3395448
- assigned to kshawkin. Waiting on decision as to status of Virginia. 
(Maybe we shd close ticket now all the same?)




From sebastian.rahtz at it.ox.ac.uk  Sat Sep 15 08:19:48 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Sat, 15 Sep 2012 12:19:48 +0000
Subject: [tei-council] State of play on GREEN tickets
In-Reply-To: <50546C89.1050303@retired.ox.ac.uk>
References: <50546C89.1050303@retired.ox.ac.uk>
Message-ID: <4a53f6f5-9b75-4916-be16-fb4491122ab6@HUB04.ad.oak.ox.ac.uk>


On 15 Sep 2012, at 12:54, Lou Burnard <lou.burnard at retired.ox.ac.uk>
 wrote:
> * Allow local modification of attributes belonging to a class FR/3415801
> - assigned to rahtz.
> 
I have closed this one, cos I believe the work is done. But I added 
a new follow on ticket (3567935) to remind us we now need to make
use of the new facility

> 
> * i18n revision due - B/3432216
> - assigned to rahtz
> 
I have reassigned this one to Martin, cos he foolishly agreed in Michigan to make
the next pass at the script which works out the list of things which need
changing.

--
Sebastian Rahtz      
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431


From lou.burnard at retired.ox.ac.uk  Sat Sep 15 08:29:51 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Sat, 15 Sep 2012 13:29:51 +0100
Subject: [tei-council] State of play on GREEN tickets
In-Reply-To: <2A93F138-1C90-4762-9EEA-6F38CFB10153@it.ox.ac.uk>
References: <50546C89.1050303@retired.ox.ac.uk>
	<2A93F138-1C90-4762-9EEA-6F38CFB10153@it.ox.ac.uk>
Message-ID: <505474BF.6000509@retired.ox.ac.uk>

Thanks for the quick update.

I have just made one of the amber tickets green (FR 3526975) since the 
action is clear, has already been agreed by Council, and is just waiting 
for implementation. Action was assigned to Piotr but I am willing to do 
it if he is too busy.



On 15/09/12 13:19, Sebastian Rahtz wrote:
>
> On 15 Sep 2012, at 12:54, Lou Burnard <lou.burnard at retired.ox.ac.uk>
>   wrote:
>> * Allow local modification of attributes belonging to a class FR/3415801
>> - assigned to rahtz.
>>
> I have closed this one, cos I believe the work is done. But I added
> a new follow on ticket (3567935) to remind us we now need to make
> use of the new facility
>
>>
>> * i18n revision due - B/3432216
>> - assigned to rahtz
>>
> I have reassigned this one to Martin, cos he foolishly agreed in Michigan to make
> the next pass at the script which works out the list of things which need
> changing.
>
> --
> Sebastian Rahtz
> Director (Research Support) of Academic IT Services
> University of Oxford IT Services
> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>


From lou.burnard at retired.ox.ac.uk  Sat Sep 15 09:59:54 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Sat, 15 Sep 2012 14:59:54 +0100
Subject: [tei-council] State of play on AMBER tickets
Message-ID: <505489DA.3030105@retired.ox.ac.uk>

There are only 19 AMBER tickets as of 15/09.

Of these, I think three are actually fairly clear and just need action: 
with a bit of tidying they could be green:

F/3531957  allow a footer for a <table>
F/3511398  Need to implement Schematron rules for attribute values
F/2834511  Add more elements to att.spanning with schematron constraint

Three further tickets indicate clearly enough for drafting purposes some 
places where clarifications and revisions to text of Glines are needed:

  B/3496949  Guidelines, p. 388 - "<wit>[unattested]</wit>" (bodard)
  B/3496958  Guidelines, p. 384 - number of <rdg> in <app>  (bodard)
  F/3496494  make attributes from and to (as pointers) part of a class

And two more are concerned with some tweaking of current attribute 
classes -- they just need some careful fiddling about, but nothing 
controversial.

F/3291540  att.editLike should not bring att.dimensions & att.ranging
F/3284816  att.canonical for model.persTraitLike

Council probably needs to allocate time to discuss the following EIGHT 
tickets, where the action proposed is controversial or may be 
unnecessary. I've put them in (my perceived) descending order of priority.

B/3440771  Multiple <geo> tags in <location> (rahtz)
B/3439980  content model of <signed> (rahtz)
F/3526114  add @type to msDesc
F/3060867  Grouping traitlike, statelike, and eventlike elements
F/3536363  rationalize content models of org and place (etc)
F/3504690  floatingDiv proposal
B/3439587  Problems introduced by content models of bibl and imprint 
(kshawkin)
B/3555602  oddbyexample non-tei:TEI start	(rahtz)

Which leaves just one ticket that seems to be concerned only with 
meta-issues (how to indicate deprecation, if we wish to discuss that)

B/3376456  deprecate use of gram except as a child of gramGrp (kshawkin)

and two which are stuck, pending action elsewhere

F/3423686  an <object> element
F/3495987  members of model.respLike should be members of att.declarabl




From lou.burnard at retired.ox.ac.uk  Sat Sep 15 11:07:12 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Sat, 15 Sep 2012 16:07:12 +0100
Subject: [tei-council] State of play on RED tickets
Message-ID: <505499A0.8050402@retired.ox.ac.uk>

And finally, there are 8 RED tickets as of 15/09

Two of these have had extensive discussion and clarification and I think 
should be recategorised as Amber. A both more discussion at the ftf, and 
I think these could both be resolved:
  F/3519866	@rend from data.word to text
  F/3416130	Allow certainty etc. inside milestoneLike elements

Hopefully the ISO meeting on 22 Oct will give some ideas for progressing 
the following two:
F/2724997	Cater for audio/video facsimile
F/2507305	Alignment and documentation of sound files

Unless anyone objects, I think this one can be closed
   3064757	XML construct encoding within Schematron
If there's anything further to be done here, it should be discussed when 
we review MH's update to TCW20 about schematron

Which leaves the following three definitely red, all of which are still 
in need of considerable amounts of work/discussion...

F/3475007	New section on encoding text directionality
  B/3480650	@cRef is a mess
  B/3413346	Deprecation of data.key and data.word attributes



From kevin.s.hawkins at ultraslavonic.info  Sat Sep 15 23:09:29 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Sat, 15 Sep 2012 23:09:29 -0400
Subject: [tei-council] State of play on GREEN tickets
In-Reply-To: <50546C89.1050303@retired.ox.ac.uk>
References: <50546C89.1050303@retired.ox.ac.uk>
Message-ID: <505542E9.8020606@ultraslavonic.info>

On 9/15/12 7:54 AM, Lou Burnard wrote:
> * change all references to "hosts" to "partners" - B/3395448
> - assigned to kshawkin. Waiting on decision as to status of Virginia.
> (Maybe we shd close ticket now all the same?)

This reminds me that I David mentioned to me that Virginia's status was 
about to be resolved.  I've pinged him for an update.

From kevin.s.hawkins at ultraslavonic.info  Sat Sep 15 23:45:41 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Sat, 15 Sep 2012 23:45:41 -0400
Subject: [tei-council] TEI deprecation practices
In-Reply-To: <5027C22D.6020307@ultraslavonic.info>
References: <501D894E.3030504@ultraslavonic.info> <501EAFD3.6030703@uvic.ca>
	<501FECB6.50101@it.ox.ac.uk> <5027C22D.6020307@ultraslavonic.info>
Message-ID: <50554B65.2060204@ultraslavonic.info>

I'm not for the record of anyone doing email list archeology that this 
is now on the agenda for Oxford.

On 8/12/12 10:48 AM, Kevin Hawkins wrote:
> Thanks to those who've commented so far.  I've moved the comments to
>
> http://wiki.tei-c.org/index.php/Talk:Deprecation
>
> so we can keep track of this conversation more clearly.  I think we
> might need to discuss this in Oxford in order to rationalize our process
> so that next time we contemplate "deprecating" something, we're all
> clear on what that entails.
>
> K.

From lou.burnard at retired.ox.ac.uk  Sun Sep 16 07:32:20 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Sun, 16 Sep 2012 12:32:20 +0100
Subject: [tei-council] SF group "None"
In-Reply-To: <50554C3F.7060904@ultraslavonic.info>
References: <50554C3F.7060904@ultraslavonic.info>
Message-ID: <5055B8C4.9080904@retired.ox.ac.uk>

On 16/09/12 04:49, Kevin Hawkins wrote:
> Lou, what about tickets in group "None" such as
> http://purl.org/TEI/FR/3522043 ?  I'm not sure what the workflow is for
> things to go from this group to GREEN, AMBER, or RED.

Well, this is embarassing. I had been relying on TCW17 to tell me which 
tickets were in the "no group" group, and it was assuring me that there 
were none. Which is not, I now discover, the case, so either it's always 
been broken and I hadn't noticed, or something has changed and broken 
it, and I didn't notice. Either way, I have now discovered about fifty 
uncategorised tickets :-(

The workflow is supposed to be that I do a triage of these tickets, 
proposing a group for each for council's review. Alas this should have 
been done about a week ago, *before* proceeding to the work I've just 
done reviewing grouped tickets.

I'll see what I can do this afternoon....







From lou.burnard at retired.ox.ac.uk  Sun Sep 16 14:18:14 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Sun, 16 Sep 2012 19:18:14 +0100
Subject: [tei-council] Ungrouped tickets
Message-ID: <505617E6.1080100@retired.ox.ac.uk>

I've now reviewed  all the previously ungrouped tickets (apologies again 
for the delay) and made some tentative groupings of them, as indicated 
below.

Where I've marked something GREEN it's because I think I know what 
should be done, and it's clear, and the owner of the ticket should just 
go ahead and do it unless anyone on council calls foul. I've tried to 
add a comment clarifying what's to be done if it's not clear.

Where I've marked a ticket AMBER, I usually also have a clear idea of 
what should be done, but am (un)comfortably aware that other views 
exist. So Council needs to state firmly that it agrees with me (or of 
course, conceivably, the other guy) before this ticket can move to GREEN 
or (in most cases) be implemented. And of course there are some cases 
where I actually have no view at all, and it's still not clear what to do.

There are also a few RED tickets, where the issue lacks clarity, or 
requires lots of work before it is clear what actions are needed.

I've tried to group tickets by topic, on the assumption that we may want 
to tackle some of them in breakout groups.

=== Various bibliographic matters, proposals for change===

http://purl.org/TEI/FR/3555190 : Improve guidance and restrict usage of 
biblScope GREEN
http://purl.org/TEI/FR/3555191	New element <citedRange> for bibliography 
AMBER
http://purl.org/TEI/FR/3513147	biblStruct for Patent citations AMBER
http://purl.org/TEI/FR/3553304	Add idno as child to biblFull  GREEN
http://purl.org/TEI/FR/3565878	where to put <idno> within <biblStruct>? 
AMBER

=== Ongoing activities for review ===

http://purl.org/TEI/BUGS/3520704 : Most attributes lack good examples 
GREEN
http://purl.org/TEI/BUGS/3557497 : New schematron constraint for datable 
elements AMBER

=== Suggestions for new content models/elements/classes ===

http://purl.org/TEI/BUGS/3565137 : reconsider membership or use of 
model.glossLike	 GREEN
http://purl.org/TEI/FR/3561933 : Encoding of Standoff annotations      AMBER
http://purl.org/TEI/BUGS/3532022 : <lg> should be allowed in <p>	AMBER
http://purl.org/TEI/BUGS/3519806 : <name> should be a member of 
att.datable  AMBER
http://purl.org/TEI/FR/3523791 : an addition to <timeline> to record 
stretches of time AMBER
http://purl.org/TEI/FR/3518932 : Use @range instead of abusing @from on 
<span>   AMBER
http://purl.org/TEI/FR/3523225 : New attribute @keepHyphen  AMBER
http://purl.org/TEI/FR/3547289 : model.gramPart and <cit>  AMBER
http://purl.org/TEI/FR/3547558 : *Spec elements could have <keywords> or 
use @ana  RED
http://purl.org/TEI/FR/3561938 : New tag element for grouping elements 
  RED


=== Revisions of the Guidelines documentation ===
http://purl.org/TEI/FR/3565152 : reference application/tei+xml somewhere 
in the Guidelines  GREEN
http://purl.org/TEI/FR/3554294 : @xml:space GREEN
http://purl.org/TEI/FR/3547869 : system entities vs. XInclude  GREEN
http://purl.org/TEI/BUGS/3539329 : Inconsistency in data.name GREEN 
(same as http://purl.org/TEI/FR/3511398)
http://purl.org/TEI/BUGS/3520414 : Example does not conform with 
description in Core chapter	GREEN
http://purl.org/TEI/BUGS/3521714 : revise valList and valItem, revise 
ch. 22 accordingly	GREEN

http://purl.org/TEI/FR/3556778 : retaining punctuation marks in the text 
of a TEI document AMBER
http://purl.org/TEI/BUGS/3515805 : confusing semantics of @ns   AMBER
http://purl.org/TEI/FR/3548625 : Extend the enumerated values for 
list/@type	AMBER
http://purl.org/TEI/FR/3521288 : Dead Link for 
http://www.ons.gov.uk/about-statistics/classif AMBER	
  http://purl.org/TEI/FR/3522043 : Version numbers link to page about 
versions?  AMBER
http://purl.org/TEI/BUGS/3523082 : XPointer schemes may not nest, but 
see ch. 16  RED




From mholmes at uvic.ca  Tue Sep 18 10:40:05 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Tue, 18 Sep 2012 07:40:05 -0700
Subject: [tei-council] Arrived in Oxford but FORGOT MY POWER ADAPTER curses
Message-ID: <505887C5.6060404@uvic.ca>

I just got to Wolfson Hall only to realize that I forgot to bring any 
power adapter for UK plugs with me, so I only have the power left in my 
laptop battery and my phone, and I can't charge them.

Does anyone know the nearest place where I might be able to buy one?

Cheers,
Martin
-- 
Martin Holmes
mholmes at uvic.ca
UVic Humanities Computing and Media Centre

From sebastian.rahtz at it.ox.ac.uk  Tue Sep 18 11:03:09 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Tue, 18 Sep 2012 15:03:09 +0000
Subject: [tei-council] Arrived in Oxford but FORGOT MY POWER ADAPTER
 curses
In-Reply-To: <505887C5.6060404@uvic.ca>
References: <505887C5.6060404@uvic.ca>
Message-ID: <1913BB87-C7BD-4D51-8F07-BA592CDEA9D4@it.ox.ac.uk>


On 18 Sep 2012, at 15:40, Martin Holmes <mholmes at uvic.ca>
 wrote:

> I just got to Wolfson Hall only to realize that I forgot to bring any 
> power adapter for UK plugs with me, so I only have the power left in my 
> laptop battery and my phone, and I can't charge them.
> 
> Does anyone know the nearest place where I might be able to buy one?
> 
I can lend you one tomorrow, thanks to DH2012. in the meanwhile,
I would look in Boswells, on Cornmarket, I think


--
Sebastian Rahtz      
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431


From sebastian.rahtz at it.ox.ac.uk  Tue Sep 18 11:25:08 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Tue, 18 Sep 2012 15:25:08 +0000
Subject: [tei-council] Arrived in Oxford but FORGOT MY POWER ADAPTER
 curses
In-Reply-To: <505887C5.6060404@uvic.ca>
References: <505887C5.6060404@uvic.ca>
Message-ID: <3902FADE-8968-4199-BB36-07DC3A577B58@it.ox.ac.uk>

if all else fails, I'll be home by about 6.15, which is about 10 minutes walk north of you

have you asked the conference office in Wolfson for a loan?
--
Sebastian Rahtz      
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431


From James.Cummings at it.ox.ac.uk  Tue Sep 18 12:09:02 2012
From: James.Cummings at it.ox.ac.uk (James Cummings)
Date: Tue, 18 Sep 2012 17:09:02 +0100
Subject: [tei-council] Arrived in Oxford but FORGOT MY POWER ADAPTER
	curses
In-Reply-To: <1913BB87-C7BD-4D51-8F07-BA592CDEA9D4@it.ox.ac.uk>
References: <505887C5.6060404@uvic.ca>
	<1913BB87-C7BD-4D51-8F07-BA592CDEA9D4@it.ox.ac.uk>
Message-ID: <50589C9E.1020109@it.ox.ac.uk>


Likewise, I've a universal travel adapter at home and can bring 
it in tomorrow if you need it.

-james

On 18/09/12 16:03, Sebastian Rahtz wrote:
>
> On 18 Sep 2012, at 15:40, Martin Holmes<mholmes at uvic.ca>
>   wrote:
>
>> I just got to Wolfson Hall only to realize that I forgot to bring any
>> power adapter for UK plugs with me, so I only have the power left in my
>> laptop battery and my phone, and I can't charge them.
>>
>> Does anyone know the nearest place where I might be able to buy one?
>>
> I can lend you one tomorrow, thanks to DH2012. in the meanwhile,
> I would look in Boswells, on Cornmarket, I think
>
>
> --
> Sebastian Rahtz
> Director (Research Support) of Academic IT Services
> University of Oxford IT Services
> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>


-- 
Dr James Cummings, researchsupport at it.ox.ac.uk
Research Support, IT Services, University of Oxford

From bansp at o2.pl  Tue Sep 18 13:21:09 2012
From: bansp at o2.pl (=?ISO-8859-2?Q?Piotr_Ba=F1ski?=)
Date: Tue, 18 Sep 2012 19:21:09 +0200
Subject: [tei-council] Arrived in Oxford but FORGOT MY POWER ADAPTER
	curses
In-Reply-To: <505887C5.6060404@uvic.ca>
References: <505887C5.6060404@uvic.ca>
Message-ID: <5058AD85.5040102@o2.pl>

I'm going to be the hero of tonight and Martin will be forever in my debt.

@Martin: please send me your room number.

So long,

  P.

On 18/09/12 16:40, Martin Holmes wrote:
> I just got to Wolfson Hall only to realize that I forgot to bring any 
> power adapter for UK plugs with me, so I only have the power left in my 
> laptop battery and my phone, and I can't charge them.
> 
> Does anyone know the nearest place where I might be able to buy one?
> 
> Cheers,
> Martin
> 


From bbarney2 at unl.edu  Tue Sep 18 13:23:33 2012
From: bbarney2 at unl.edu (Brett Barney)
Date: Tue, 18 Sep 2012 17:23:33 +0000
Subject: [tei-council] Arrived in Oxford but FORGOT MY POWER ADAPTER
 curses
In-Reply-To: <505887C5.6060404@uvic.ca>
References: <505887C5.6060404@uvic.ca>
Message-ID: <769686ED-5042-47B7-883E-292C58C84C53@unl.edu>

Sort-of related question: Anyone know of a place I might be able to buy an ethernet-to-USB adapter? I'm in the ethernet only block of dorms with a USB-only Macbook . . . .


On Sep 18, 2012, at 9:40 AM, Martin Holmes wrote:

> I just got to Wolfson Hall only to realize that I forgot to bring any 
> power adapter for UK plugs with me, so I only have the power left in my 
> laptop battery and my phone, and I can't charge them.
> 
> Does anyone know the nearest place where I might be able to buy one?
> 
> Cheers,
> Martin
> -- 
> Martin Holmes
> mholmes at uvic.ca
> UVic Humanities Computing and Media Centre
> -- 
> 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
> 

----------------
Brett Barney
Associate Research Professor
Center for Digital Research in the Humanities
bbarney2 at unl.edu






From mholmes at uvic.ca  Tue Sep 18 13:44:39 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Tue, 18 Sep 2012 18:44:39 +0100
Subject: [tei-council] Arrived in Oxford but FORGOT MY POWER ADAPTER
	curses
In-Reply-To: <1913BB87-C7BD-4D51-8F07-BA592CDEA9D4@it.ox.ac.uk>
References: <505887C5.6060404@uvic.ca>
	<1913BB87-C7BD-4D51-8F07-BA592CDEA9D4@it.ox.ac.uk>
Message-ID: <5058B307.2030503@uvic.ca>

Good call! Had time to nip into town and get one. All is saved.

Someone else nearly had to do the minutes then.

Cheers,
Martin

On 12-09-18 04:03 PM, Sebastian Rahtz wrote:
>
> On 18 Sep 2012, at 15:40, Martin Holmes <mholmes at uvic.ca>
>   wrote:
>
>> I just got to Wolfson Hall only to realize that I forgot to bring any
>> power adapter for UK plugs with me, so I only have the power left in my
>> laptop battery and my phone, and I can't charge them.
>>
>> Does anyone know the nearest place where I might be able to buy one?
>>
> I can lend you one tomorrow, thanks to DH2012. in the meanwhile,
> I would look in Boswells, on Cornmarket, I think
>
>
> --
> Sebastian Rahtz
> Director (Research Support) of Academic IT Services
> University of Oxford IT Services
> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>

-- 
Martin Holmes
mholmes at uvic.ca
UVic Humanities Computing and Media Centre

From sebastian.rahtz at it.ox.ac.uk  Tue Sep 18 13:53:23 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Tue, 18 Sep 2012 17:53:23 +0000
Subject: [tei-council] Arrived in Oxford but FORGOT MY POWER ADAPTER
 curses
In-Reply-To: <5058B307.2030503@uvic.ca>
References: <505887C5.6060404@uvic.ca>
	<1913BB87-C7BD-4D51-8F07-BA592CDEA9D4@it.ox.ac.uk>,
	<5058B307.2030503@uvic.ca>
Message-ID: <927030EB-FA45-49BC-BDDD-7548854E5449@it.ox.ac.uk>

Doesn't Wolfson have wireless? I didn't know USB to Ethernet existed.

There is certainly wireless in the common room area.

But there is a Mac shop on Broad Street, Western Computers, which may help.

Carved in stone on my iPad



From James.Cummings at it.ox.ac.uk  Tue Sep 18 14:58:35 2012
From: James.Cummings at it.ox.ac.uk (James Cummings)
Date: Tue, 18 Sep 2012 19:58:35 +0100
Subject: [tei-council] Oxford Face to Face: Further Reading
Message-ID: <5058C45B.7040802@it.ox.ac.uk>


In preparation for the Council meeting, in addition to 
familiarising yourself with the tickets on sourceforge, you may 
wish to read some of the items linked to from: 
http://wiki.tei-c.org/index.php/Council#Face_to_Face_Meeting:_Oxford_2012-09-19_to_2012-09-21

Namely:

Deprecation policy:
  http://wiki.tei-c.org/index.php/Deprecation
  http://wiki.tei-c.org/index.php/Talk:Deprecation

Private URI Schemes:
  http://wiki.tei-c.org/index.php/Private_URI_Schemes

XPointer Proposal:
 
https://docs.google.com/document/d/1JsMA-gOGrevyY-crzHGiC7eZ8XdV5H_wFTlUGzrf20w/edit

Durand Conundrum:
http://foxglove.hypotheses.org/368

-James

-- 
Dr James Cummings, researchsupport at it.ox.ac.uk
Research Support, IT Services, University of Oxford

From James.Cummings at it.ox.ac.uk  Tue Sep 18 18:23:37 2012
From: James.Cummings at it.ox.ac.uk (James Cummings)
Date: Tue, 18 Sep 2012 23:23:37 +0100
Subject: [tei-council] Ticket Summary
Message-ID: <5058F469.1070303@it.ox.ac.uk>


For convenience, I pasted Lou's four messages into a single wiki 
page at:

http://wiki.tei-c.org/index.php/Council-ticketTriage

with links for each one.


For what it is worth: I agree with Lou that those GREEN tickets 
(one already resolved by @rahtz) are basically just awaiting 
completion.

-James

-- 
Dr James Cummings, researchsupport at it.ox.ac.uk
Research Support, IT Services, University of Oxford

From rwelzenbach at gmail.com  Wed Sep 19 03:27:52 2012
From: rwelzenbach at gmail.com (Rebecca Welzenbach)
Date: Wed, 19 Sep 2012 08:27:52 +0100
Subject: [tei-council] Arrived in Oxford but FORGOT MY POWER ADAPTER
	curses
In-Reply-To: <927030EB-FA45-49BC-BDDD-7548854E5449@it.ox.ac.uk>
References: <505887C5.6060404@uvic.ca>
	<1913BB87-C7BD-4D51-8F07-BA592CDEA9D4@it.ox.ac.uk>
	<5058B307.2030503@uvic.ca>
	<927030EB-FA45-49BC-BDDD-7548854E5449@it.ox.ac.uk>
Message-ID: <CAA2irtLUpyu_O_-EneC8bGk4xms-jGYfSFA_GHowJniWERDP9A@mail.gmail.com>

FWIW, while the paperwork I received at check-in specifically claims
that Block M doesn't have wireless, I've been able to pick up the OWL
network without a problem.

Becky

On Tue, Sep 18, 2012 at 6:53 PM, Sebastian Rahtz
<sebastian.rahtz at it.ox.ac.uk> wrote:
> Doesn't Wolfson have wireless? I didn't know USB to Ethernet existed.
>
> There is certainly wireless in the common room area.
>
> But there is a Mac shop on Broad Street, Western Computers, which may help.
>
> Carved in stone on my iPad
>
>
> --
> 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 it.ox.ac.uk  Wed Sep 19 03:38:59 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Wed, 19 Sep 2012 07:38:59 +0000
Subject: [tei-council] Arrived in Oxford but FORGOT MY POWER ADAPTER
 curses
In-Reply-To: <CAA2irtLUpyu_O_-EneC8bGk4xms-jGYfSFA_GHowJniWERDP9A@mail.gmail.com>
References: <505887C5.6060404@uvic.ca>
	<1913BB87-C7BD-4D51-8F07-BA592CDEA9D4@it.ox.ac.uk>
	<5058B307.2030503@uvic.ca>
	<927030EB-FA45-49BC-BDDD-7548854E5449@it.ox.ac.uk>
	<CAA2irtLUpyu_O_-EneC8bGk4xms-jGYfSFA_GHowJniWERDP9A@mail.gmail.com>
Message-ID: <418E7680-E078-4513-942F-13B180FB40CE@it.ox.ac.uk>


On 19 Sep 2012, at 08:27, Rebecca Welzenbach <rwelzenbach at gmail.com>
 wrote:

> FWIW, while the paperwork I received at check-in specifically claims
> that Block M doesn't have wireless, I've been able to pick up the OWL
> network without a problem.


seems like some of you all have setup on wireless already?

we have credentials here as well if you need.
--
Sebastian Rahtz      
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431


From PFSchaffner at umich.edu  Wed Sep 19 03:48:09 2012
From: PFSchaffner at umich.edu (Paul Schaffner)
Date: Wed, 19 Sep 2012 03:48:09 -0400
Subject: [tei-council] Arrived in Oxford but FORGOT MY POWER ADAPTER
	curses
In-Reply-To: <418E7680-E078-4513-942F-13B180FB40CE@it.ox.ac.uk>
References: <505887C5.6060404@uvic.ca>
	<1913BB87-C7BD-4D51-8F07-BA592CDEA9D4@it.ox.ac.uk>
	<5058B307.2030503@uvic.ca>
	<927030EB-FA45-49BC-BDDD-7548854E5449@it.ox.ac.uk>
	<CAA2irtLUpyu_O_-EneC8bGk4xms-jGYfSFA_GHowJniWERDP9A@mail.gmail.com>
	<418E7680-E078-4513-942F-13B180FB40CE@it.ox.ac.uk>
Message-ID: <CAH=xBNDQXgX=qD4Xgk-QF18bLJ2gSVSzOMucrkisEgt7RY2UVA@mail.gmail.com>

Becky and I have OWL credentials from the TCP conference that are a little
ambiguous as to how long they last. The sheet reads:

"Valid for up to 14 consecutive days from Fri Sep 14 08:30 until Thu
Sep 20 08:30"

It would seem likely that they expire tonight.

pfs



On 19 September 2012 03:38, Sebastian Rahtz <sebastian.rahtz at it.ox.ac.uk> wrote:
>
> On 19 Sep 2012, at 08:27, Rebecca Welzenbach <rwelzenbach at gmail.com>
>  wrote:
>
>> FWIW, while the paperwork I received at check-in specifically claims
>> that Block M doesn't have wireless, I've been able to pick up the OWL
>> network without a problem.
>
>
> seems like some of you all have setup on wireless already?
>
> we have credentials here as well if you need.
> --
> Sebastian Rahtz
> Director (Research Support) of Academic IT Services
> University of Oxford IT Services
> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>
> --
> tei-council mailing list
> tei-council at lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>
> PLEASE NOTE: postings to this list are publicly archived



-- 
-- 
Paul Schaffner | http://www.umich.edu/~pfs | PFSchaffner at umich.edu

From sebastian.rahtz at it.ox.ac.uk  Wed Sep 19 03:50:40 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Wed, 19 Sep 2012 07:50:40 +0000
Subject: [tei-council] Arrived in Oxford but FORGOT MY POWER ADAPTER
 curses
In-Reply-To: <CAH=xBNDQXgX=qD4Xgk-QF18bLJ2gSVSzOMucrkisEgt7RY2UVA@mail.gmail.com>
References: <505887C5.6060404@uvic.ca>
	<1913BB87-C7BD-4D51-8F07-BA592CDEA9D4@it.ox.ac.uk>
	<5058B307.2030503@uvic.ca>
	<927030EB-FA45-49BC-BDDD-7548854E5449@it.ox.ac.uk>
	<CAA2irtLUpyu_O_-EneC8bGk4xms-jGYfSFA_GHowJniWERDP9A@mail.gmail.com>
	<418E7680-E078-4513-942F-13B180FB40CE@it.ox.ac.uk>
	<CAH=xBNDQXgX=qD4Xgk-QF18bLJ2gSVSzOMucrkisEgt7RY2UVA@mail.gmail.com>
Message-ID: <CE2BBA5D-95FA-471A-807A-DFF6ED6A5878@it.ox.ac.uk>


On 19 Sep 2012, at 08:48, Paul Schaffner <PFSchaffner at umich.edu>
 wrote:

> Becky and I have OWL credentials from the TCP conference that are a little
> ambiguous as to how long they last. The sheet reads:
> 
> "Valid for up to 14 consecutive days from Fri Sep 14 08:30 until Thu
> Sep 20 08:30"
> 
> It would seem likely that they expire tonight.


we'll give replacements sheets of paper today then
--
Sebastian Rahtz      
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431


From lou.burnard at retired.ox.ac.uk  Wed Sep 19 03:52:57 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Wed, 19 Sep 2012 07:52:57 +0000
Subject: [tei-council] Arrived in Oxford but FORGOT MY POWER
	ADAPTER	curses
In-Reply-To: <CAH=xBNDQXgX=qD4Xgk-QF18bLJ2gSVSzOMucrkisEgt7RY2UVA@mail.gmail.com>
References: <505887C5.6060404@uvic.ca>
	<1913BB87-C7BD-4D51-8F07-BA592CDEA9D4@it.ox.ac.uk>
	<5058B307.2030503@uvic.ca>
	<927030EB-FA45-49BC-BDDD-7548854E5449@it.ox.ac.uk>
	<CAA2irtLUpyu_O_-EneC8bGk4xms-jGYfSFA_GHowJniWERDP9A@mail.gmail.com>
	<418E7680-E078-4513-942F-13B180FB40CE@it.ox.ac.uk>,
	<CAH=xBNDQXgX=qD4Xgk-QF18bLJ2gSVSzOMucrkisEgt7RY2UVA@mail.gmail.com>
Message-ID: <d8a2fb6d-8050-4111-a239-1bc94498ca7b@HUB06.ad.oak.ox.ac.uk>

Eduroam is also widely available in Wolfson if that helps.

Sent from my HTC

----- Reply message -----
From: "Paul Schaffner" <PFSchaffner at umich.edu>
To: "Sebastian Rahtz" <sebastian.rahtz at it.ox.ac.uk>
Cc: "TEI Council" <tei-council at lists.village.virginia.edu>
Subject: [tei-council] Arrived in Oxford but FORGOT MY POWER ADAPTER curses
Date: Wed, Sep 19, 2012 08:48



Becky and I have OWL credentials from the TCP conference that are a little
ambiguous as to how long they last. The sheet reads:

"Valid for up to 14 consecutive days from Fri Sep 14 08:30 until Thu
Sep 20 08:30"

It would seem likely that they expire tonight.

pfs



On 19 September 2012 03:38, Sebastian Rahtz <sebastian.rahtz at it.ox.ac.uk> wrote:
>
> On 19 Sep 2012, at 08:27, Rebecca Welzenbach <rwelzenbach at gmail.com>
>  wrote:
>
>> FWIW, while the paperwork I received at check-in specifically claims
>> that Block M doesn't have wireless, I've been able to pick up the OWL
>> network without a problem.
>
>
> seems like some of you all have setup on wireless already?
>
> we have credentials here as well if you need.
> --
> Sebastian Rahtz
> Director (Research Support) of Academic IT Services
> University of Oxford IT Services
> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>
> --
> tei-council mailing list
> tei-council at lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>
> PLEASE NOTE: postings to this list are publicly archived



--
--
Paul Schaffner | http://www.umich.edu/~pfs | PFSchaffner at umich.edu
--
tei-council mailing list
tei-council at lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

PLEASE NOTE: postings to this list are publicly archived

From James.Cummings at it.ox.ac.uk  Wed Sep 19 04:16:02 2012
From: James.Cummings at it.ox.ac.uk (James Cummings)
Date: Wed, 19 Sep 2012 09:16:02 +0100
Subject: [tei-council] Arrived in Oxford but FORGOT MY POWER ADAPTER
	curses
In-Reply-To: <CE2BBA5D-95FA-471A-807A-DFF6ED6A5878@it.ox.ac.uk>
References: <505887C5.6060404@uvic.ca>
	<1913BB87-C7BD-4D51-8F07-BA592CDEA9D4@it.ox.ac.uk>
	<5058B307.2030503@uvic.ca>
	<927030EB-FA45-49BC-BDDD-7548854E5449@it.ox.ac.uk>
	<CAA2irtLUpyu_O_-EneC8bGk4xms-jGYfSFA_GHowJniWERDP9A@mail.gmail.com>
	<418E7680-E078-4513-942F-13B180FB40CE@it.ox.ac.uk>
	<CAH=xBNDQXgX=qD4Xgk-QF18bLJ2gSVSzOMucrkisEgt7RY2UVA@mail.gmail.com>
	<CE2BBA5D-95FA-471A-807A-DFF6ED6A5878@it.ox.ac.uk>
Message-ID: <50597F42.6090309@it.ox.ac.uk>

On 19/09/12 08:50, Sebastian Rahtz wrote:
>> Becky and I have OWL credentials from the TCP conference that are a little
>> ambiguous as to how long they last. The sheet reads:
>>
>> "Valid for up to 14 consecutive days from Fri Sep 14 08:30 until Thu
>> Sep 20 08:30"
>>
>> It would seem likely that they expire tonight.
> we'll give replacements sheets of paper today then

Already printed out and waiting. ;-)

-James

-- 
Dr James Cummings, researchsupport at it.ox.ac.uk
Research Support, IT Services, University of Oxford

From James.Cummings at it.ox.ac.uk  Wed Sep 19 04:29:53 2012
From: James.Cummings at it.ox.ac.uk (James Cummings)
Date: Wed, 19 Sep 2012 09:29:53 +0100
Subject: [tei-council] SIG Reports
Message-ID: <50598281.7040105@it.ox.ac.uk>


SIG Report: TEI Council Face to Face Oxford 2012-09


Tools:
Serge Heiden: I have been in contact with Marjorie Burghart, as 
TEI Board member,
about the future of the Tools SIG this summer. The board seems to
have ideas for that SIG, and I think this is good.

Music:
Raffaele Viglianti: I think it would be helpful to have a SIG 
coordinator of some sorts. I imagine that these are some of the 
tasks for a coordinator (they're are not too different form my 
previous experience of SIG coordinators):
- ping the convenors regularly to see if the SIGs are still 
active or have plans to be so
- receive proposals for new SIGs and present them to the council
- coordinate funding rounds (when there's money that can be 
allocated)
For regular queries to and interaction with the council, I have 
found the "contact person" to be a more helpful figure.

Correspondence:
Joachim Veit: If Raffaele would have left some space below his 
mail this would have been the best place for "signing in" to 
consent with his mail! We from the SIG correspondence found it 
very helpful to have someone who coordinated the establishement 
and work of the SIG a bit. So I think this is a very senseful 
post for the TEI and thus I sign "above" Raffaele's mail to 
confirm his arguments.

Text&Graphics:
John Walsh:
	I apologize for not responding sooner. I don't have anything of 
substance to report from the Text and Graphics SIG. A small group 
met in W?rzburg, and we had an interesting discussion, but 
nothing specific to report.  I do believe the SIG would be a 
useful contributor if and when the Council decides its time to 
revise or revisit things in the Guidelines related to facsimile, 
figure, and other graphic components.
	Although not a direct result of SIG work, I did finally publish 
(in DHQ) a long article on Comic Book Markup Language, which is 
related to the general topic of the SIG, and I hope the article, 
ODD, etc. is a useful contribution to this are of the TEI. And in 
recent years work has continued on projects like uVic's Image 
Markup Tool, TextGrid's TBLE/TILE, and the other TILE from MITH 
and Indiana U. So I think topic of TEI, Text, and Graphics 
remains an important area of interest to some TEIers, and there 
is reason for the SIG to continue, both as an intellectual 
community and as a potential resource for the Council and others.

LingSIG: Piotr Banski will talk tomorrow.

Ontologies: ?yvind Eide:
Sorry about the delay in replying. Since the last TEI meeting, 
the Ontologies SIG has issued several feature requests, and are 
currently working on at least one more.



-- 
Dr James Cummings, researchsupport at it.ox.ac.uk
Research Support, IT Services, University of Oxford

From James.Cummings at it.ox.ac.uk  Wed Sep 19 08:48:50 2012
From: James.Cummings at it.ox.ac.uk (James Cummings)
Date: Wed, 19 Sep 2012 13:48:50 +0100
Subject: [tei-council] Summary of TEI ODD meeting
Message-ID: <5059BF32.7080502@it.ox.ac.uk>


Here is my summary of the DH2012 TEI ODD meeting that is much 
more concise, with recommendations where we reached them.

http://tinyurl.com/teicouncil-oddsummary

-James

-- 
Dr James Cummings, researchsupport at it.ox.ac.uk
Research Support, IT Services, University of Oxford

From dsewell at virginia.edu  Wed Sep 19 10:36:03 2012
From: dsewell at virginia.edu (David Sewell)
Date: Wed, 19 Sep 2012 10:36:03 -0400 (EDT)
Subject: [tei-council] FTF agenda item request: discuss "Questions for
	Candidates"
Message-ID: <alpine.OSX.2.00.1209191029500.96895@lister.ei.virginia.edu>

Council folk,

Last year, for the first time, we asked candidates for TEI Council and Board 
election to submit responses to a set of prepared questions:

http://www.tei-c.org/Membership/Meetings/2011/mm54.xml#body.1_div.4

That was largely in response to the fact that controversies over Board decisions 
had made it seem more critical for candidates to identify where they stood on 
key issues. Do we want to continue the practice (in addition to asking for a 
short autobiography and personal statement)?

Could you find a few minutes during the Oxford meeting to decide whether (1) 
Council would like to see prepared questions again this year, and (2) if so, 
agree on a procedure to supply a list of questions to the Nominating Committee 
(nominations at tei-c.org) by the 24th if possible?

David

-- 
David Sewell, Editorial and Technical Manager
ROTUNDA, The University of Virginia Press
PO Box 400314, Charlottesville, VA 22904-4314 USA
Email: dsewell at virginia.edu   Tel: +1 434 924 9973
Web: http://rotunda.upress.virginia.edu/

From James.Cummings at it.ox.ac.uk  Wed Sep 19 10:56:37 2012
From: James.Cummings at it.ox.ac.uk (James Cummings)
Date: Wed, 19 Sep 2012 15:56:37 +0100
Subject: [tei-council] FTF agenda item request: discuss "Questions for
 Candidates"
In-Reply-To: <alpine.OSX.2.00.1209191029500.96895@lister.ei.virginia.edu>
References: <alpine.OSX.2.00.1209191029500.96895@lister.ei.virginia.edu>
Message-ID: <5059DD25.20007@it.ox.ac.uk>


Added to agenda for tomorrow (when Elena will also be here).

-James


On 19/09/12 15:36, David Sewell wrote:
> Council folk,
>
> Last year, for the first time, we asked candidates for TEI Council and Board
> election to submit responses to a set of prepared questions:
>
> http://www.tei-c.org/Membership/Meetings/2011/mm54.xml#body.1_div.4
>
> That was largely in response to the fact that controversies over Board decisions
> had made it seem more critical for candidates to identify where they stood on
> key issues. Do we want to continue the practice (in addition to asking for a
> short autobiography and personal statement)?
>
> Could you find a few minutes during the Oxford meeting to decide whether (1)
> Council would like to see prepared questions again this year, and (2) if so,
> agree on a procedure to supply a list of questions to the Nominating Committee
> (nominations at tei-c.org) by the 24th if possible?
>
> David
>


-- 
Dr James Cummings, researchsupport at it.ox.ac.uk
Research Support, IT Services, University of Oxford

From James.Cummings at it.ox.ac.uk  Thu Sep 20 04:12:47 2012
From: James.Cummings at it.ox.ac.uk (James Cummings)
Date: Thu, 20 Sep 2012 09:12:47 +0100
Subject: [tei-council] Change of Meeting room
Message-ID: <505ACFFF.3060103@it.ox.ac.uk>


Hiya,

Just to note that Wolfson College have moved us from the Private 
Dining Room to the Buttery.  This is a larger room with with some 
better potential breakout areas. It doesn't have as nice a room 
though. I'll update the agenda.

We've got a reserved table and buffet in the dining hall at 
exactly 12:30.

-James

-- 
Dr James Cummings, researchsupport at it.ox.ac.uk
Research Support, IT Services, University of Oxford

From sebastian.rahtz at it.ox.ac.uk  Thu Sep 20 08:38:25 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Thu, 20 Sep 2012 12:38:25 +0000
Subject: [tei-council] new draft Roma
Message-ID: <9C738B7B-EE61-4256-A976-74B3B83DA3C6@it.ox.ac.uk>

please review wording on http://tei.oucs.ox.ac.uk/Roma/index.html
and feel free to edit on Sourceforge _ad lib_
--
Sebastian Rahtz      
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431


From bbarney2 at unl.edu  Thu Sep 20 09:47:17 2012
From: bbarney2 at unl.edu (Brett Barney)
Date: Thu, 20 Sep 2012 13:47:17 +0000
Subject: [tei-council] new draft Roma
In-Reply-To: <9C738B7B-EE61-4256-A976-74B3B83DA3C6@it.ox.ac.uk>
References: <9C738B7B-EE61-4256-A976-74B3B83DA3C6@it.ox.ac.uk>
Message-ID: <7791F6F7-8A7A-4DD9-A025-EA32D906B325@unl.edu>

I think this is a really solid step forward. Huzzah. 

I paused for a minute over the wording of the fourth and fifth bullet points. My first concern was that #4 uses "Create" and #5 uses "Edit" to mean the same things. I also think that "existing" is a bit vague. And, finally, I'm a *tiny* bit dissatisfied with "template" in #4. Here are my thoughts about what I might propose instead for those two radio buttons:


Edit model [example/boilerplate?] customization

Edit your own (previously created) customization

My proposed language for #5 is quite a bit longer. That's unfortunate, but I think clarity is trump. Maybe it could be further edited to be both clear and shorter?

----------------
Brett Barney
Associate Research Professor
Center for Digital Research in the Humanities
bbarney2 at unl.edu
On Sep 20, 2012, at 1:38 PM, Sebastian Rahtz wrote:

> please review wording on http://tei.oucs.ox.ac.uk/Roma/index.html
> and feel free to edit on Sourceforge _ad lib_
> --
> Sebastian Rahtz      
> Director (Research Support) of Academic IT Services 
> University of Oxford IT Services
> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
> 
> -- 
> tei-council mailing list
> tei-council at lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
> 
> PLEASE NOTE: postings to this list are publicly archived
> 







From kevin.s.hawkins at ultraslavonic.info  Thu Sep 20 09:52:32 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Thu, 20 Sep 2012 09:52:32 -0400
Subject: [tei-council] new draft Roma
In-Reply-To: <7791F6F7-8A7A-4DD9-A025-EA32D906B325@unl.edu>
References: <9C738B7B-EE61-4256-A976-74B3B83DA3C6@it.ox.ac.uk>
	<7791F6F7-8A7A-4DD9-A025-EA32D906B325@unl.edu>
Message-ID: <505B1FA0.2070005@ultraslavonic.info>

Sebastian, where can we find the code on Sourceforge that you've edited 
(that you asking us to tweak directly)?

For the wiki link, I would use 
http://wiki.tei-c.org/index.php/Category:Customization so that people 
know where to find these.

--K.

On 9/20/12 9:47 AM, Brett Barney wrote:
> I think this is a really solid step forward. Huzzah.
>
> I paused for a minute over the wording of the fourth and fifth bullet points. My first concern was that #4 uses "Create" and #5 uses "Edit" to mean the same things. I also think that "existing" is a bit vague. And, finally, I'm a *tiny* bit dissatisfied with "template" in #4. Here are my thoughts about what I might propose instead for those two radio buttons:
>
>
> Edit model [example/boilerplate?] customization
>
> Edit your own (previously created) customization
>
> My proposed language for #5 is quite a bit longer. That's unfortunate, but I think clarity is trump. Maybe it could be further edited to be both clear and shorter?
>
> ----------------
> Brett Barney
> Associate Research Professor
> Center for Digital Research in the Humanities
> bbarney2 at unl.edu
> On Sep 20, 2012, at 1:38 PM, Sebastian Rahtz wrote:
>
>> please review wording on http://tei.oucs.ox.ac.uk/Roma/index.html
>> and feel free to edit on Sourceforge _ad lib_
>> --
>> Sebastian Rahtz
>> Director (Research Support) of Academic IT Services
>> University of Oxford IT Services
>> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>>
>> --
>> 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 it.ox.ac.uk  Thu Sep 20 09:54:52 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Thu, 20 Sep 2012 13:54:52 +0000
Subject: [tei-council] new draft Roma
In-Reply-To: <505B1FA0.2070005@ultraslavonic.info>
References: <9C738B7B-EE61-4256-A976-74B3B83DA3C6@it.ox.ac.uk>
	<7791F6F7-8A7A-4DD9-A025-EA32D906B325@unl.edu>
	<505B1FA0.2070005@ultraslavonic.info>
Message-ID: <0941DF3E-B6D6-4FEE-AA86-AE6ABB666848@it.ox.ac.uk>


On 20 Sep 2012, at 14:52, Kevin Hawkins <kevin.s.hawkins at ultraslavonic.info>
 wrote:

> Sebastian, where can we find the code on Sourceforge that you've edited 
> (that you asking us to tweak directly)?
> 

check out https://tei.svn.sourceforge.net/svnroot/tei/trunk/Roma

> For the wiki link, I would use 
> http://wiki.tei-c.org/index.php/Category:Customization so that people 
> know where to find these.
done that

--
Sebastian Rahtz      
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431


From sebastian.rahtz at it.ox.ac.uk  Thu Sep 20 09:57:11 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Thu, 20 Sep 2012 13:57:11 +0000
Subject: [tei-council] new draft Roma
In-Reply-To: <7791F6F7-8A7A-4DD9-A025-EA32D906B325@unl.edu>
References: <9C738B7B-EE61-4256-A976-74B3B83DA3C6@it.ox.ac.uk>
	<7791F6F7-8A7A-4DD9-A025-EA32D906B325@unl.edu>
Message-ID: <077F5E5E-7DDC-4768-A3F6-81F66E57BD0D@it.ox.ac.uk>

do you mean thus?

http://tei.oucs.ox.ac.uk/Roma/

--
Sebastian Rahtz      
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431


From lou.burnard at retired.ox.ac.uk  Thu Sep 20 10:06:29 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Thu, 20 Sep 2012 15:06:29 +0100
Subject: [tei-council] new draft roma
Message-ID: <505B22E5.5090608@retired.ox.ac.uk>

I'd rewrite as follows:

---
TEI Roma is a tool for working with TEI customizations. A TEI 
customization is a document from which you can generate a schema
defining which elements and attributes from the TEI system you want to 
use, along with customized HTML or PDF documentation of it. The schema 
generated can be expressed in any of DTD, RELAXNG W3C Schema or 
Schematron languages.

You can make or modify your TEI customization in a number of different ways:

-   Build up: create a new customization by adding elements and modules 
to the smallest recommended schema
-    Reduce: create a new customization by removing elements and modules 
from the largest possible schema
-    Create: create a new customization starting from a predefined template
-   Edit : create a new customization starting from an existing 
TEI-defined customization  [tite/lite]
     Open : Upload and use an existing customization [browse fpor local 
file]

A number of community-maintained customizations are listed on the TEI wiki.

----

The link to the TEI wiki currently doesnt go anywhere useful, but maybe 
the page it should go to isnt there yet.

We shouldn't use the word "ODD" on this start page without defining it.

From sebastian.rahtz at it.ox.ac.uk  Thu Sep 20 10:13:50 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Thu, 20 Sep 2012 14:13:50 +0000
Subject: [tei-council] new draft roma
In-Reply-To: <505B22E5.5090608@retired.ox.ac.uk>
References: <505B22E5.5090608@retired.ox.ac.uk>
Message-ID: <50158a0f-5980-46e5-8bb2-cb6ba4328887@HUB02.ad.oak.ox.ac.uk>

If I was you, I'd go ahead and just do it. Possission 9/10ths of the law and all that
--
Sebastian Rahtz      
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431


From bbarney2 at unl.edu  Thu Sep 20 10:29:21 2012
From: bbarney2 at unl.edu (Brett Barney)
Date: Thu, 20 Sep 2012 14:29:21 +0000
Subject: [tei-council] new draft roma
In-Reply-To: <50158a0f-5980-46e5-8bb2-cb6ba4328887@HUB02.ad.oak.ox.ac.uk>
References: <505B22E5.5090608@retired.ox.ac.uk>
	<50158a0f-5980-46e5-8bb2-cb6ba4328887@HUB02.ad.oak.ox.ac.uk>
Message-ID: <B15B1EC0-2EDC-42F6-899A-44ACC5703112@unl.edu>

I can't recall your first draft version (and it's been replaced now), but I don't have any objections to Lou's proposed language.


On Sep 20, 2012, at 3:13 PM, Sebastian Rahtz wrote:

> If I was you, I'd go ahead and just do it. Possission 9/10ths of the law and all that
> --
> Sebastian Rahtz      
> Director (Research Support) of Academic IT Services 
> University of Oxford IT Services
> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
> 
> -- 
> 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
> 

----------------
Brett Barney
Associate Research Professor
Center for Digital Research in the Humanities
bbarney2 at unl.edu






From sebastian.rahtz at it.ox.ac.uk  Thu Sep 20 10:37:17 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Thu, 20 Sep 2012 14:37:17 +0000
Subject: [tei-council] new draft roma
In-Reply-To: <B15B1EC0-2EDC-42F6-899A-44ACC5703112@unl.edu>
References: <505B22E5.5090608@retired.ox.ac.uk>
	<50158a0f-5980-46e5-8bb2-cb6ba4328887@HUB02.ad.oak.ox.ac.uk>
	<B15B1EC0-2EDC-42F6-899A-44ACC5703112@unl.edu>
Message-ID: <718D1359-04A1-4D10-99BE-B50642F52D71@it.ox.ac.uk>

see http://tei.oucs.ox.ac.uk/Roma/ now with Lou's changes
--
Sebastian Rahtz      
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431


From dsewell at virginia.edu  Thu Sep 20 12:07:22 2012
From: dsewell at virginia.edu (David Sewell)
Date: Thu, 20 Sep 2012 12:07:22 -0400 (EDT)
Subject: [tei-council] Status of Board/Council nominations
Message-ID: <alpine.OSX.2.00.1209201205030.2838@lister.ei.virginia.edu>

All,

As of today, we have the following totals of nominees willing to serve:

Board: 8

Council: 6 ( plus one probable yes)

and that is not counting some additional nominations that came from Lou and 
Gabby today. So I think we are in good shape.

David

-- 
David Sewell, Editorial and Technical Manager
ROTUNDA, The University of Virginia Press
PO Box 400314, Charlottesville, VA 22904-4314 USA
Email: dsewell at virginia.edu   Tel: +1 434 924 9973
Web: http://rotunda.upress.virginia.edu/

From bbarney2 at unl.edu  Thu Sep 20 17:59:55 2012
From: bbarney2 at unl.edu (Brett Barney)
Date: Thu, 20 Sep 2012 21:59:55 +0000
Subject: [tei-council] new draft roma
In-Reply-To: <718D1359-04A1-4D10-99BE-B50642F52D71@it.ox.ac.uk>
References: <505B22E5.5090608@retired.ox.ac.uk>
	<50158a0f-5980-46e5-8bb2-cb6ba4328887@HUB02.ad.oak.ox.ac.uk>
	<B15B1EC0-2EDC-42F6-899A-44ACC5703112@unl.edu>
	<718D1359-04A1-4D10-99BE-B50642F52D71@it.ox.ac.uk>
Message-ID: <255FF5EA-D6DB-4CAA-AE47-8C9C8251FFE2@unl.edu>

FWIW, there are a couple of ways that this deviates from what Lou actually suggested. I suspect that these were intentional changes on Sebastian's part, but maybe not? In general, I prefer Sebastian's implementation, though the parallelism in Lou's original (i.e., having each of the radio button labels begin with a short distinctive-ish label) is appealing. The trouble, though, is that those labels don't really bear scrutiny. So all in all I'm happy with this latest draft. I'm just now noticing the phrase "A number of" which always jars a bit, but I'm now just being nitpicky.

----------------
Brett Barney
Associate Research Professor
Center for Digital Research in the Humanities
bbarney2 at unl.edu


On Sep 20, 2012, at 3:37 PM, Sebastian Rahtz wrote:

> see http://tei.oucs.ox.ac.uk/Roma/ now with Lou's changes
> --
> Sebastian Rahtz      
> Director (Research Support) of Academic IT Services 
> University of Oxford IT Services
> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
> 
> 








From sebastian.rahtz at it.ox.ac.uk  Thu Sep 20 18:08:58 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Thu, 20 Sep 2012 22:08:58 +0000
Subject: [tei-council] new draft roma
In-Reply-To: <255FF5EA-D6DB-4CAA-AE47-8C9C8251FFE2@unl.edu>
References: <505B22E5.5090608@retired.ox.ac.uk>
	<50158a0f-5980-46e5-8bb2-cb6ba4328887@HUB02.ad.oak.ox.ac.uk>
	<B15B1EC0-2EDC-42F6-899A-44ACC5703112@unl.edu>
	<718D1359-04A1-4D10-99BE-B50642F52D71@it.ox.ac.uk>
	<255FF5EA-D6DB-4CAA-AE47-8C9C8251FFE2@unl.edu>
Message-ID: <FACA2355-797A-4743-A5C7-853789DABFAF@it.ox.ac.uk>

no, I didn't change anything, Lou did this.

I freely admit that UX is not my area of expertise, so I am expecting others to
edit that page to make it a thing of beauty.
--
Sebastian Rahtz      
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431


From sebastian.rahtz at it.ox.ac.uk  Thu Sep 20 18:25:16 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Thu, 20 Sep 2012 22:25:16 +0000
Subject: [tei-council] oddbyexample
Message-ID: <B5E2A40F-41D0-4D1B-8104-149E0F736206@it.ox.ac.uk>

since this came up, I "amused" myself by redoing it so that it does include the functionality of making a "new style" ODD file
(ie the odd2nuodd process). 

god bless all who sail (or punt) in her.
--
Sebastian Rahtz      
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431


From lou.burnard at retired.ox.ac.uk  Sun Sep 23 17:37:03 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Sun, 23 Sep 2012 22:37:03 +0100
Subject: [tei-council] reconsidering model.glossLike (bugs 3565137)
Message-ID: <505F80FF.5000808@retired.ox.ac.uk>

I started looking at 3565137, and then got cold feet.

Current members of model.glossLike are: model.certLike [certainty
respons] desc gloss precision equiv altIdent

Seems to me that of these only equiv and altIdent are really "gloss
like". Equally, model.certLike and precision seem rather inappropriate
inside *Spec elements.

I fear a fairly major reorganization is needed. Here's my first shot
at it.

The elements currently containing model.glossLike are : attDef
category certainty char classSpec constraintSpec elementSpec gap glyph
graphic incident interp interpGrp join joinGrp kinesic macroSpec
moduleSpec precision respons schemaSpec space substJoin taxonomy
valItem and vocal.

The only thing that all these elements actually have in common is that
they all need a <desc>. Apart from that:

The following  need gloss, equiv, altIdent:
     attDef, category, classSpec, constraintSpec, elementSpec,
     macroSpec moduleSpec schemaSpec taxonomy, valItem

The following need precision and model.certLike
     certainty gap precision respons space substJoin

So, cautiously, I am thinking of doing the following:

(1) define (new) model.descLike, with <desc> as its sole member
(2) redefine model.glossLike with <gloss>, <equiv>, and <altIdent> as
its members
(3) Add <precision> to  model.certLike

Revise class memberships as follows:

attDef    (1) (2)
category  (1) (2)
certainty (1)  (3)
char      (1)
classSpec (1) (2)
constraintSpec (1) (2)
elementSpec (1) (2)
gap      (1)  (3)
glyph    (1)
graphic  (1)
incident  (1)  (3)
interp  (1)  (3)
interpGrp  (1)  (3)
join  (1)  (3)
joinGrp  (1)  (3)
kinesic (1)
macroSpec (1) (2)
moduleSpec (1) (2)
precision  (1)  (3)
respons  (1)  (3)
schemaSpec (1) (2)
space  (1)  (3)
substJoin  (1)  (3)
taxonomy (1) (2)
valItem (1) (2)
vocal  (1)

But I think I'll sleep on it first.



From James.Cummings at it.ox.ac.uk  Sun Sep 23 18:11:02 2012
From: James.Cummings at it.ox.ac.uk (James Cummings)
Date: Sun, 23 Sep 2012 23:11:02 +0100
Subject: [tei-council] reconsidering model.glossLike (bugs 3565137)
In-Reply-To: <505F80FF.5000808@retired.ox.ac.uk>
References: <505F80FF.5000808@retired.ox.ac.uk>
Message-ID: <505F88F6.4090809@it.ox.ac.uk>


Lou,

If I'm understanding correctly, does that mean that the list of 
elements with (1) (2) will not have <certainty> as a child, and 
those with (1)(3) will lose <gloss>,<equiv>, and <altIdent>?

I don't think many people will have used <gloss> on those 
elements, and as long as they retain <desc>, I don't see bad 
side-effects from doing this.

Anyone else?

-James


On 23/09/12 22:37, Lou Burnard wrote:
> I started looking at 3565137, and then got cold feet.
>
> Current members of model.glossLike are: model.certLike [certainty
> respons] desc gloss precision equiv altIdent
>
> Seems to me that of these only equiv and altIdent are really "gloss
> like". Equally, model.certLike and precision seem rather inappropriate
> inside *Spec elements.
>
> I fear a fairly major reorganization is needed. Here's my first shot
> at it.
>
> The elements currently containing model.glossLike are : attDef
> category certainty char classSpec constraintSpec elementSpec gap glyph
> graphic incident interp interpGrp join joinGrp kinesic macroSpec
> moduleSpec precision respons schemaSpec space substJoin taxonomy
> valItem and vocal.
>
> The only thing that all these elements actually have in common is that
> they all need a<desc>. Apart from that:
>
> The following  need gloss, equiv, altIdent:
>       attDef, category, classSpec, constraintSpec, elementSpec,
>       macroSpec moduleSpec schemaSpec taxonomy, valItem
>
> The following need precision and model.certLike
>       certainty gap precision respons space substJoin
>
> So, cautiously, I am thinking of doing the following:
>
> (1) define (new) model.descLike, with<desc>  as its sole member
> (2) redefine model.glossLike with<gloss>,<equiv>, and<altIdent>  as
> its members
> (3) Add<precision>  to  model.certLike
>
> Revise class memberships as follows:
>
> attDef    (1) (2)
> category  (1) (2)
> certainty (1)  (3)
> char      (1)
> classSpec (1) (2)
> constraintSpec (1) (2)
> elementSpec (1) (2)
> gap      (1)  (3)
> glyph    (1)
> graphic  (1)
> incident  (1)  (3)
> interp  (1)  (3)
> interpGrp  (1)  (3)
> join  (1)  (3)
> joinGrp  (1)  (3)
> kinesic (1)
> macroSpec (1) (2)
> moduleSpec (1) (2)
> precision  (1)  (3)
> respons  (1)  (3)
> schemaSpec (1) (2)
> space  (1)  (3)
> substJoin  (1)  (3)
> taxonomy (1) (2)
> valItem (1) (2)
> vocal  (1)
>
> But I think I'll sleep on it first.
>
>


-- 
Dr James Cummings, researchsupport at it.ox.ac.uk
Research Support, IT Services, University of Oxford

From James.Cummings at it.ox.ac.uk  Mon Sep 24 02:11:24 2012
From: James.Cummings at it.ox.ac.uk (James Cummings)
Date: Mon, 24 Sep 2012 07:11:24 +0100
Subject: [tei-council] reconsidering model.glossLike (bugs 3565137)
In-Reply-To: <505F88F6.4090809@it.ox.ac.uk>
References: <505F80FF.5000808@retired.ox.ac.uk> <505F88F6.4090809@it.ox.ac.uk>
Message-ID: <505FF98C.4000507@it.ox.ac.uk>


Btw. If we are messing about with what has <desc>, we should 
probably simply reinstate <desc> to <zone> as per Conal's email 
on TEI-L. I can think of no good reason for it not to have it back.

-James

On 23/09/12 23:11, James Cummings wrote:
>
> Lou,
>
> If I'm understanding correctly, does that mean that the list of
> elements with (1) (2) will not have <certainty> as a child, and
> those with (1)(3) will lose <gloss>,<equiv>, and <altIdent>?
>
> I don't think many people will have used <gloss> on those
> elements, and as long as they retain <desc>, I don't see bad
> side-effects from doing this.
>
> Anyone else?
>
> -James
>
>
> On 23/09/12 22:37, Lou Burnard wrote:
>> I started looking at 3565137, and then got cold feet.
>>
>> Current members of model.glossLike are: model.certLike [certainty
>> respons] desc gloss precision equiv altIdent
>>
>> Seems to me that of these only equiv and altIdent are really "gloss
>> like". Equally, model.certLike and precision seem rather inappropriate
>> inside *Spec elements.
>>
>> I fear a fairly major reorganization is needed. Here's my first shot
>> at it.
>>
>> The elements currently containing model.glossLike are : attDef
>> category certainty char classSpec constraintSpec elementSpec gap glyph
>> graphic incident interp interpGrp join joinGrp kinesic macroSpec
>> moduleSpec precision respons schemaSpec space substJoin taxonomy
>> valItem and vocal.
>>
>> The only thing that all these elements actually have in common is that
>> they all need a<desc>. Apart from that:
>>
>> The following  need gloss, equiv, altIdent:
>>        attDef, category, classSpec, constraintSpec, elementSpec,
>>        macroSpec moduleSpec schemaSpec taxonomy, valItem
>>
>> The following need precision and model.certLike
>>        certainty gap precision respons space substJoin
>>
>> So, cautiously, I am thinking of doing the following:
>>
>> (1) define (new) model.descLike, with<desc>  as its sole member
>> (2) redefine model.glossLike with<gloss>,<equiv>, and<altIdent>  as
>> its members
>> (3) Add<precision>  to  model.certLike
>>
>> Revise class memberships as follows:
>>
>> attDef    (1) (2)
>> category  (1) (2)
>> certainty (1)  (3)
>> char      (1)
>> classSpec (1) (2)
>> constraintSpec (1) (2)
>> elementSpec (1) (2)
>> gap      (1)  (3)
>> glyph    (1)
>> graphic  (1)
>> incident  (1)  (3)
>> interp  (1)  (3)
>> interpGrp  (1)  (3)
>> join  (1)  (3)
>> joinGrp  (1)  (3)
>> kinesic (1)
>> macroSpec (1) (2)
>> moduleSpec (1) (2)
>> precision  (1)  (3)
>> respons  (1)  (3)
>> schemaSpec (1) (2)
>> space  (1)  (3)
>> substJoin  (1)  (3)
>> taxonomy (1) (2)
>> valItem (1) (2)
>> vocal  (1)
>>
>> But I think I'll sleep on it first.
>>
>>
>
>


-- 
Dr James Cummings, researchsupport at it.ox.ac.uk
Research Support, IT Services, University of Oxford

From James.Cummings at it.ox.ac.uk  Mon Sep 24 11:24:59 2012
From: James.Cummings at it.ox.ac.uk (James Cummings)
Date: Mon, 24 Sep 2012 16:24:59 +0100
Subject: [tei-council] TEI Candidate Question Prompt
Message-ID: <50607B4B.4050502@it.ox.ac.uk>


Dear Council,

You may have remembered that David Sewell asked us to consider if 
we wanted candidates to answer specific questions. As with the 
Board we said no.   However our minutes[1] say:

ACTION on JC: Council will discuss on list the precise wording of 
such a prompt, JC to initiate, and report back to nominations 
committee.

So this is my attempt to do so.

In addition to other information, the reminder for their 
candidate statement might say something like:

===
In addition to your own qualifications for election to the TEI 
Board or TEI Technical Council you may wish to address issues in 
your candidate statement concerning the nature of the TEI 
Consortium as an organization, membership, finances, technical 
improvements, or areas on which you feel the TEI Consortium 
should focus.
===

If we can have any corrections, emendations, modifications, or 
suggestions to the council list up until 10am GMT on Weds 26 
September (i.e. this weds), I'll feed it back to the nominations 
committee at that point.

Many thanks,

-James
[1] Yes, the minutes... please proofread these up until this 
Friday 28th. Take special note of actions assigned to you.

-- 
Dr James Cummings, researchsupport at it.ox.ac.uk
Research Support, IT Services, University of Oxford

From James.Cummings at it.ox.ac.uk  Mon Sep 24 11:31:08 2012
From: James.Cummings at it.ox.ac.uk (James Cummings)
Date: Mon, 24 Sep 2012 16:31:08 +0100
Subject: [tei-council] TEI Oxford Face 2 Face Minutes
In-Reply-To: <50607B4B.4050502@it.ox.ac.uk>
References: <50607B4B.4050502@it.ox.ac.uk>
Message-ID: <50607CBC.8000306@it.ox.ac.uk>

My early message mentioned:

On 24/09/12 16:24, James Cummings wrote:
> Yes, the minutes... please proofread these up until this
> Friday 28th. Take special note of actions assigned to you.

If you do not have access to the minutes, email MartinH. Please 
proofread them up until Friday 28th.

-James

-- 
Dr James Cummings, researchsupport at it.ox.ac.uk
Research Support, IT Services, University of Oxford

From mholmes at uvic.ca  Mon Sep 24 11:51:43 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Mon, 24 Sep 2012 16:51:43 +0100
Subject: [tei-council] TEI Oxford Face 2 Face Minutes
In-Reply-To: <50607CBC.8000306@it.ox.ac.uk>
References: <50607B4B.4050502@it.ox.ac.uk> <50607CBC.8000306@it.ox.ac.uk>
Message-ID: <5060818F.7000202@uvic.ca>

I'll tag them up and put them on the TEI site next week, and I'll also 
generate a table of actions like the one James did last time for the wiki.

Thanks to the Oxford gang for a lovely time last week. Everything was 
really well organized, and I think we got a lot of work done.

Cheers,
Martin

On 12-09-24 04:31 PM, James Cummings wrote:
> My early message mentioned:
>
> On 24/09/12 16:24, James Cummings wrote:
>> Yes, the minutes... please proofread these up until this
>> Friday 28th. Take special note of actions assigned to you.
>
> If you do not have access to the minutes, email MartinH. Please
> proofread them up until Friday 28th.
>
> -James
>

-- 
Martin Holmes
mholmes at uvic.ca
UVic Humanities Computing and Media Centre

From mholmes at uvic.ca  Mon Sep 24 11:54:01 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Mon, 24 Sep 2012 16:54:01 +0100
Subject: [tei-council] TEI Candidate Question Prompt
In-Reply-To: <50607B4B.4050502@it.ox.ac.uk>
References: <50607B4B.4050502@it.ox.ac.uk>
Message-ID: <50608219.4090008@uvic.ca>

Looks good to me. I wonder if there's some way to add a proviso that 
wading in on the organization and finances etc. of the TEI is definitely 
not part of the job of the Council?

Cheers,
Martin

On 12-09-24 04:24 PM, James Cummings wrote:
>
> Dear Council,
>
> You may have remembered that David Sewell asked us to consider if
> we wanted candidates to answer specific questions. As with the
> Board we said no.   However our minutes[1] say:
>
> ACTION on JC: Council will discuss on list the precise wording of
> such a prompt, JC to initiate, and report back to nominations
> committee.
>
> So this is my attempt to do so.
>
> In addition to other information, the reminder for their
> candidate statement might say something like:
>
> ===
> In addition to your own qualifications for election to the TEI
> Board or TEI Technical Council you may wish to address issues in
> your candidate statement concerning the nature of the TEI
> Consortium as an organization, membership, finances, technical
> improvements, or areas on which you feel the TEI Consortium
> should focus.
> ===
>
> If we can have any corrections, emendations, modifications, or
> suggestions to the council list up until 10am GMT on Weds 26
> September (i.e. this weds), I'll feed it back to the nominations
> committee at that point.
>
> Many thanks,
>
> -James
> [1] Yes, the minutes... please proofread these up until this
> Friday 28th. Take special note of actions assigned to you.
>

-- 
Martin Holmes
mholmes at uvic.ca
UVic Humanities Computing and Media Centre

From mholmes at uvic.ca  Mon Sep 24 12:53:49 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Mon, 24 Sep 2012 17:53:49 +0100
Subject: [tei-council] Schematron embedded in RelaxNG
Message-ID: <5060901D.4030603@uvic.ca>

Hi all,

During the FTF I was talking to Sebastian about the fact that our 
Schematron constraints are embedded directly into RelaxNG files; he 
believed that this meant that normal validation would cause them to be 
triggered, but I couldn't remember having been caught by a Schematron 
constraint when validating against a RelaxNG schema, even though I know 
I know I've violated them. So I've just started testing this.

The RelaxNG schema for tei_all:

<http://www.tei-c.org/release/xml/tei/custom/schema/relaxng/tei_all.rng>

does indeed contain our handful of existing Schematron rules; if you 
look at the element definition for <lg>, you'll see the constraint we 
recently added, which says that an <lg> must contain at least one child 
<l>, <lg> or <gap>.

However, when I create a test document violating this constraint and one 
of the others, and validate it against this schema in Oxygen 14, nothing 
happens. (The test document is below.)

So I went digging to try to figure out whether it was realistic to 
expect Schematron validation as part of RelaxNG validation. According to 
the Jing home page, Jing only has "experimental" support for Schematron, 
and it's Schematron 1.5, not ISO Schematron. The documentation also says 
that "Jing's implementation is not based on the reference Schematron 1.5 
implementation. It is implemented partly in XSLT and partly in Java. 
This implementation requires that the Schematron elements be properly 
namespaced using the namespace URI http://www.ascc.net/xml/schematron." 
However, our schema uses the ISO Schematron namespace, 
"http://purl.oclc.org/dsdl/schematron". They often do define a prefix 
for the old namespace, but they use the new one instead -- as they 
should, I think, since we're using ISO Schematron.

Looking at the other available RelaxNG validators, the only one that 
promises the possibility of Schematron support is the Sun MSV validator, 
which seems to have disappeared from the web with the Oracle take-over.

So we don't seem to have a working validation mechanism for Schematron 
embedded in RelaxNG schemas, unless I've missed some key configuration 
option in Oxygen or at the command line.

So the next thing I thought I'd do was to generate a Schematron schema 
from Roma based on tei_all. I went to the latest and greatest Roma, here:

<http://tei.oucs.ox.ac.uk/Roma/>

chose to reduce a schema from the maximum possible schema, and made no 
changes. I generated an ISO Schematron schema from that, and got a file 
with no constraints in it at all:

<?xml version="1.0" encoding="utf-8"?>
<schema xmlns="http://purl.oclc.org/dsdl/schematron"
         xmlns:oxdoc="http://www.oxygenxml.com/ns/doc/xsl"
         queryBinding="xslt2">
    <title>ISO Schematron rules</title>
 
<!--namespaces:--><!--keys:--><!--patterns:--><!--constraints:--></schema>

So that doesn't work, for some reason. Instead, I downloaded 
tei_all.odd, and ran this:

roma --isoschematron tei_all.odd .

to get an ISO Schematron file. Validating my test file against that 
produced the expected errors.

So unless I'm missing something, it's unlikely that most people are 
getting any benefit from our Schematron constraints, unless they're 
aware that they have to manually generate a schematron schema and link 
it into their XML files. If this is the case, I think we should be 
documenting this process somewhere.


This is my test doc, which violates two of our Schematron constraints:

<?xml version="1.0" encoding="UTF-8"?>
<?xml-model 
href="http://www.tei-c.org/release/xml/tei/custom/schema/relaxng/tei_all.rng" 
type="application/xml" schematypens="http://relaxng.org/ns/structure/1.0"?>
<TEI xmlns="http://www.tei-c.org/ns/1.0">
     <teiHeader>
         <fileDesc>
             <titleStmt>
                 <title>Testing Schematron constraints in RelaxNG</title>
             </titleStmt>
             <publicationStmt><p>Public test document</p></publicationStmt>
             <sourceDesc><p>Born digital</p></sourceDesc>
         </fileDesc>
     </teiHeader>
     <text>
         <body>
             <div>
                 <lg>
                     <stage>Enter James stage left, looking shifty.</stage>
                     <figure><figDesc>Picture of some lines of 
poetry.</figDesc></figure>
                 </lg>
                 <p><ref target="http://www.uvic.ca/" 
cRef="UVic">UVic</ref></p>
             </div>
         </body>
     </text>
</TEI>

Cheers,
Martin
-- 
Martin Holmes
mholmes at uvic.ca
UVic Humanities Computing and Media Centre

From sebastian.rahtz at it.ox.ac.uk  Mon Sep 24 13:27:30 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Mon, 24 Sep 2012 17:27:30 +0000
Subject: [tei-council] Schematron embedded in RelaxNG
In-Reply-To: <5060901D.4030603@uvic.ca>
References: <5060901D.4030603@uvic.ca>
Message-ID: <B97365E3-F8F2-4326-8FD9-27A1FD812244@it.ox.ac.uk>

This is worrying me somewhat. I will look at why Roma doesn't generate the schematron,
but I had thought there was something else in oXygen.

hmmm

Sebastian

From gabriel.bodard at kcl.ac.uk  Mon Sep 24 13:41:25 2012
From: gabriel.bodard at kcl.ac.uk (Gabriel Bodard)
Date: Mon, 24 Sep 2012 18:41:25 +0100
Subject: [tei-council] Schematron embedded in RelaxNG
In-Reply-To: <B97365E3-F8F2-4326-8FD9-27A1FD812244@it.ox.ac.uk>
References: <5060901D.4030603@uvic.ca>
	<B97365E3-F8F2-4326-8FD9-27A1FD812244@it.ox.ac.uk>
Message-ID: <50609B45.3000502@kcl.ac.uk>

Can you point at the rng and tell Oxygen to expect schematron? (Of 
course the schematron implementation is pretty crude anyway, and won't 
give you auto-complete assistance or anything, but validation is better 
than nothing.)

On 2012-09-24 18:27, Sebastian Rahtz wrote:
> This is worrying me somewhat. I will look at why Roma doesn't generate the schematron,
> but I had thought there was something else in oXygen.
>
> hmmm
>
> Sebastian
>

-- 
Dr Gabriel BODARD
(Research Associate in Digital Epigraphy)

Department of Digital Humanities
King's College London
26-29 Drury Lane
London WC2B 5RL

Email: gabriel.bodard at kcl.ac.uk
Tel: +44 (0)20 7848 1388
Fax: +44 (0)20 7848 2980

http://www.digitalclassicist.org/
http://www.currentepigraphy.org/

From James.Cummings at it.ox.ac.uk  Mon Sep 24 13:43:56 2012
From: James.Cummings at it.ox.ac.uk (James Cummings)
Date: Mon, 24 Sep 2012 18:43:56 +0100
Subject: [tei-council] TEI Candidate Question Prompt
In-Reply-To: <50608219.4090008@uvic.ca>
References: <50607B4B.4050502@it.ox.ac.uk> <50608219.4090008@uvic.ca>
Message-ID: <50609BDC.8000802@it.ox.ac.uk>

On 24/09/12 16:54, Martin Holmes wrote:
> Looks good to me. I wonder if there's some way to add a proviso that
> wading in on the organization and finances etc. of the TEI is definitely
> not part of the job of the Council?

I believe that is already covered by the general description of 
the Board and Council duties that will be included. However, 
DavidS (CC'ed here to get his attention) might be able to comment 
more on that.

Of course council members (and anyone else) are free to comment 
on TEI organization and finances via the Board representative on 
Council (Lou) or via me (or indeed any other member of the board) 
should they wish.

-James


-- 
Dr James Cummings, researchsupport at it.ox.ac.uk
Research Support, IT Services, University of Oxford

From James.Cummings at it.ox.ac.uk  Mon Sep 24 13:56:23 2012
From: James.Cummings at it.ox.ac.uk (James Cummings)
Date: Mon, 24 Sep 2012 18:56:23 +0100
Subject: [tei-council] Schematron embedded in RelaxNG
In-Reply-To: <5060901D.4030603@uvic.ca>
References: <5060901D.4030603@uvic.ca>
Message-ID: <50609EC7.905@it.ox.ac.uk>


Martin,

When I start a new XML document, then manually type in a root 
node, then associate a schema with it (and check the 'use 
schematron' checkbox), then correct my TEI until I ahve a valid 
document... the top looks like this:

<?xml version="1.0" encoding="UTF-8"?>
<?xml-model 
href="http://www.tei-c.org/release/xml/tei/custom/schema/relaxng/tei_all.rng" 
type="application/xml" 
schematypens="http://purl.oclc.org/dsdl/schematron"?>
<?xml-model 
href="http://www.tei-c.org/release/xml/tei/custom/schema/relaxng/tei_all.rng" 
type="application/xml" 
schematypens="http://relaxng.org/ns/structure/1.0"?>

i.e. has both a schematron xml-model and a relaxng one.

If I do this I get an error if I don't have an <l> inside my <lg> 
(or a nested <lg>). However, this is just a vague schema based 
error because it says:
"E [Jing] element "lg" incomplete; expected element "addSpan", 
"alt", "altGrp", "anchor", "argument", "byline", "camera", 
"caption", "cb", "certainty", "damageSpan", "dateline", 
"delSpan", "desc", "docAuthor", "docDate", "epigraph", "fLib", 
"figure", "fs", "fvLib", "fw", "gap", "gb", "head", "incident", 
"index", "interp", "interpGrp", "join", "joinGrp", "kinesic", 
"l", "label", "lb", "lg", "link", "linkGrp", "listTranspose", 
"meeting", "metamark", "milestone", "move", "notatedMusic", 
"note", "opener", "pause", "pb", "precision", "respons", 
"salute", "shift", "sound", "space", "span", "spanGrp", "stage", 
"substJoin", "tech", "timeline", "view", "vocal", "witDetail" or 
"writing"

Although the only thing that makes the error go away is an lg or 
an l, it isn't a very useful error message.

Is there another schematron constraint I can test instead?


-James

On 24/09/12 17:53, Martin Holmes wrote:
> Hi all,
>
> During the FTF I was talking to Sebastian about the fact that our
> Schematron constraints are embedded directly into RelaxNG files; he
> believed that this meant that normal validation would cause them to be
> triggered, but I couldn't remember having been caught by a Schematron
> constraint when validating against a RelaxNG schema, even though I know
> I know I've violated them. So I've just started testing this.
>
> The RelaxNG schema for tei_all:
>
> <http://www.tei-c.org/release/xml/tei/custom/schema/relaxng/tei_all.rng>
>
> does indeed contain our handful of existing Schematron rules; if you
> look at the element definition for <lg>, you'll see the constraint we
> recently added, which says that an <lg> must contain at least one child
> <l>, <lg> or <gap>.
>
> However, when I create a test document violating this constraint and one
> of the others, and validate it against this schema in Oxygen 14, nothing
> happens. (The test document is below.)
>
> So I went digging to try to figure out whether it was realistic to
> expect Schematron validation as part of RelaxNG validation. According to
> the Jing home page, Jing only has "experimental" support for Schematron,
> and it's Schematron 1.5, not ISO Schematron. The documentation also says
> that "Jing's implementation is not based on the reference Schematron 1.5
> implementation. It is implemented partly in XSLT and partly in Java.
> This implementation requires that the Schematron elements be properly
> namespaced using the namespace URI http://www.ascc.net/xml/schematron."
> However, our schema uses the ISO Schematron namespace,
> "http://purl.oclc.org/dsdl/schematron". They often do define a prefix
> for the old namespace, but they use the new one instead -- as they
> should, I think, since we're using ISO Schematron.
>
> Looking at the other available RelaxNG validators, the only one that
> promises the possibility of Schematron support is the Sun MSV validator,
> which seems to have disappeared from the web with the Oracle take-over.
>
> So we don't seem to have a working validation mechanism for Schematron
> embedded in RelaxNG schemas, unless I've missed some key configuration
> option in Oxygen or at the command line.
>
> So the next thing I thought I'd do was to generate a Schematron schema
> from Roma based on tei_all. I went to the latest and greatest Roma, here:
>
> <http://tei.oucs.ox.ac.uk/Roma/>
>
> chose to reduce a schema from the maximum possible schema, and made no
> changes. I generated an ISO Schematron schema from that, and got a file
> with no constraints in it at all:
>
> <?xml version="1.0" encoding="utf-8"?>
> <schema xmlns="http://purl.oclc.org/dsdl/schematron"
>           xmlns:oxdoc="http://www.oxygenxml.com/ns/doc/xsl"
>           queryBinding="xslt2">
>      <title>ISO Schematron rules</title>
>
> <!--namespaces:--><!--keys:--><!--patterns:--><!--constraints:--></schema>
>
> So that doesn't work, for some reason. Instead, I downloaded
> tei_all.odd, and ran this:
>
> roma --isoschematron tei_all.odd .
>
> to get an ISO Schematron file. Validating my test file against that
> produced the expected errors.
>
> So unless I'm missing something, it's unlikely that most people are
> getting any benefit from our Schematron constraints, unless they're
> aware that they have to manually generate a schematron schema and link
> it into their XML files. If this is the case, I think we should be
> documenting this process somewhere.
>
>
> This is my test doc, which violates two of our Schematron constraints:
>
> <?xml version="1.0" encoding="UTF-8"?>
> <?xml-model
> href="http://www.tei-c.org/release/xml/tei/custom/schema/relaxng/tei_all.rng"
> type="application/xml" schematypens="http://relaxng.org/ns/structure/1.0"?>
> <TEI xmlns="http://www.tei-c.org/ns/1.0">
>       <teiHeader>
>           <fileDesc>
>               <titleStmt>
>                   <title>Testing Schematron constraints in RelaxNG</title>
>               </titleStmt>
>               <publicationStmt><p>Public test document</p></publicationStmt>
>               <sourceDesc><p>Born digital</p></sourceDesc>
>           </fileDesc>
>       </teiHeader>
>       <text>
>           <body>
>               <div>
>                   <lg>
>                       <stage>Enter James stage left, looking shifty.</stage>
>                       <figure><figDesc>Picture of some lines of
> poetry.</figDesc></figure>
>                   </lg>
>                   <p><ref target="http://www.uvic.ca/"
> cRef="UVic">UVic</ref></p>
>               </div>
>           </body>
>       </text>
> </TEI>
>
> Cheers,
> Martin
>


-- 
Dr James Cummings, researchsupport at it.ox.ac.uk
Research Support, IT Services, University of Oxford

From bansp at o2.pl  Mon Sep 24 16:03:38 2012
From: bansp at o2.pl (Piotr Banski)
Date: Mon, 24 Sep 2012 22:03:38 +0200
Subject: [tei-council] Schematron embedded in RelaxNG
In-Reply-To: <5060901D.4030603@uvic.ca>
References: <5060901D.4030603@uvic.ca>
Message-ID: <5060BC9A.50102@o2.pl>

Hi Martin,

On 24/09/12 18:53, Martin Holmes wrote:
[...]
> So unless I'm missing something, it's unlikely that most people are
> getting any benefit from our Schematron constraints, unless they're
> aware that they have to manually generate a schematron schema and link
> it into their XML files. If this is the case, I think we should be
> documenting this process somewhere.
>
[...]

Oh I did get it to work all right, but I can only find an old example 
now, from when xml-model[1] was still merely a proposal, and oXygen 
rolled its own. What I did then was:

<?oxygen RNGSchema="OCTC_alignment.rng" type="xml"?>
<?oxygen SCHSchema="OCTC_alignment.rng"?>

In other words, two separate schema-association PIs pointing at the same 
schema doc for two different types of validation.

And I can't find the xml-model versions of that, although I am so sure 
that I eventually used those too, with schematypens, etc.

Please try that, at first in oXygen, with its under-the-hood validation 
magic, for whatever it currently uses to validate Schematron.

Best,

   P.


[1]: http://www.w3.org/TR/xml-model/

From bansp at o2.pl  Mon Sep 24 16:08:21 2012
From: bansp at o2.pl (Piotr Banski)
Date: Mon, 24 Sep 2012 22:08:21 +0200
Subject: [tei-council] Schematron embedded in RelaxNG
In-Reply-To: <50609EC7.905@it.ox.ac.uk>
References: <5060901D.4030603@uvic.ca> <50609EC7.905@it.ox.ac.uk>
Message-ID: <5060BDB5.5080807@o2.pl>

Hmmmm... next time, I am going to read through the entire thread before 
replying.

The reproachful look in the eye of a dead horse... priceless.

   P.


On 24/09/12 19:56, James Cummings wrote:
>
> Martin,
>
> When I start a new XML document, then manually type in a root
> node, then associate a schema with it (and check the 'use
> schematron' checkbox), then correct my TEI until I ahve a valid
> document... the top looks like this:
>
> <?xml version="1.0" encoding="UTF-8"?>
> <?xml-model
> href="http://www.tei-c.org/release/xml/tei/custom/schema/relaxng/tei_all.rng"
> type="application/xml"
> schematypens="http://purl.oclc.org/dsdl/schematron"?>
> <?xml-model
> href="http://www.tei-c.org/release/xml/tei/custom/schema/relaxng/tei_all.rng"
> type="application/xml"
> schematypens="http://relaxng.org/ns/structure/1.0"?>
>
> i.e. has both a schematron xml-model and a relaxng one.
>


From sebastian.rahtz at it.ox.ac.uk  Mon Sep 24 17:52:58 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Mon, 24 Sep 2012 21:52:58 +0000
Subject: [tei-council] Schematron embedded in RelaxNG
In-Reply-To: <5060901D.4030603@uvic.ca>
References: <5060901D.4030603@uvic.ca>
Message-ID: <8FC0A95D-8A80-4033-8086-5EE996E0274D@it.ox.ac.uk>


On 24 Sep 2012, at 17:53, Martin Holmes <mholmes at uvic.ca> wrote:
> 
> So the next thing I thought I'd do was to generate a Schematron schema 
> from Roma based on tei_all. I went to the latest and greatest Roma, here:
> 
> <http://tei.oucs.ox.ac.uk/Roma/>
thats not the latest and greatest really :-}
> 
> chose to reduce a schema from the maximum possible schema, and made no 
> changes. I generated an ISO Schematron schema from that, and got a file 
> with no constraints in it at all:
> 
> <?xml version="1.0" encoding="utf-8"?>
> <schema xmlns="http://purl.oclc.org/dsdl/schematron"
>         xmlns:oxdoc="http://www.oxygenxml.com/ns/doc/xsl"
>         queryBinding="xslt2">
>    <title>ISO Schematron rules</title>
> 
> <!--namespaces:--><!--keys:--><!--patterns:--><!--constraints:--></schema>

sorry, I cant reproduce this. I get a properly full .isosch 3 times in a row



--
Sebastian Rahtz      
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431


From sebastian.rahtz at it.ox.ac.uk  Mon Sep 24 17:55:04 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Mon, 24 Sep 2012 21:55:04 +0000
Subject: [tei-council] Schematron embedded in RelaxNG
In-Reply-To: <50609EC7.905@it.ox.ac.uk>
References: <5060901D.4030603@uvic.ca> <50609EC7.905@it.ox.ac.uk>
Message-ID: <f18fceaa-0a94-45be-8dfc-1c5c72e16275@HUB06.ad.oak.ox.ac.uk>


On 24 Sep 2012, at 18:56, James Cummings <james.cummings at it.ox.ac.uk> wrote:
> Although the only thing that makes the error go away is an lg or 
> an l, it isn't a very useful error message.
> 
> Is there another schematron constraint I can test instead?


try using @target and @cRef together on a <ptr>
--
Sebastian Rahtz      
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431


From mholmes at uvic.ca  Mon Sep 24 18:51:12 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Mon, 24 Sep 2012 23:51:12 +0100
Subject: [tei-council] TEI Candidate Question Prompt
In-Reply-To: <50609BDC.8000802@it.ox.ac.uk>
References: <50607B4B.4050502@it.ox.ac.uk> <50608219.4090008@uvic.ca>
	<50609BDC.8000802@it.ox.ac.uk>
Message-ID: <5060E3E0.1000508@uvic.ca>

On 12-09-24 06:43 PM, James Cummings wrote:
> On 24/09/12 16:54, Martin Holmes wrote:
>> Looks good to me. I wonder if there's some way to add a proviso that
>> wading in on the organization and finances etc. of the TEI is definitely
>> not part of the job of the Council?
>
> I believe that is already covered by the general description of
> the Board and Council duties that will be included. However,
> DavidS (CC'ed here to get his attention) might be able to comment
> more on that.
>
> Of course council members (and anyone else) are free to comment
> on TEI organization and finances via the Board representative on
> Council (Lou) or via me (or indeed any other member of the board)
> should they wish.

I take your point, but I wouldn't want to give the impression that 
standing for Council involves some sort of political orientation, or 
that your opinions on finances or whatever might bear on whether you get 
elected or not.

Cheers,
Martin

>
> -James
>
>

-- 
Martin Holmes
mholmes at uvic.ca
UVic Humanities Computing and Media Centre

From mholmes at uvic.ca  Mon Sep 24 18:59:37 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Mon, 24 Sep 2012 23:59:37 +0100
Subject: [tei-council] Schematron embedded in RelaxNG
In-Reply-To: <50609EC7.905@it.ox.ac.uk>
References: <5060901D.4030603@uvic.ca> <50609EC7.905@it.ox.ac.uk>
Message-ID: <5060E5D9.2010509@uvic.ca>

Ah -- James has figured out what I hadn't: that if you associate your 
RNG file with your XML file twice, once as RelaxNG and once as 
Schematron, then it works.

I had no idea that you could do that, and I don't really know how anyone 
else would know either. I thought an xml-model PI with 
schematypens="http://purl.oclc.org/dsdl/schematron" had to point to a 
Schematron file. Perhaps there should be a way for people to find out 
how to do this? I almost never create a new XML document in the way 
James describes; usually I'm taking an existing document and changing 
it, so if my existing documents didn't have that link to the RelaxNG 
schema as Schematron, then my new one wouldn't either, and I'd never 
know anything about Schematron.

To answer your question below, my message (below yours below) has a test 
document which is valid RNG-wise, but violates two simple Schematron 
constraints. That should work to test your system (it does for me).

Cheers,
Martin

On 12-09-24 06:56 PM, James Cummings wrote:
>
> Martin,
>
> When I start a new XML document, then manually type in a root
> node, then associate a schema with it (and check the 'use
> schematron' checkbox), then correct my TEI until I ahve a valid
> document... the top looks like this:
>
> <?xml version="1.0" encoding="UTF-8"?>
> <?xml-model
> href="http://www.tei-c.org/release/xml/tei/custom/schema/relaxng/tei_all.rng"
> type="application/xml"
> schematypens="http://purl.oclc.org/dsdl/schematron"?>
> <?xml-model
> href="http://www.tei-c.org/release/xml/tei/custom/schema/relaxng/tei_all.rng"
> type="application/xml"
> schematypens="http://relaxng.org/ns/structure/1.0"?>
>
> i.e. has both a schematron xml-model and a relaxng one.
>
> If I do this I get an error if I don't have an <l> inside my <lg>
> (or a nested <lg>). However, this is just a vague schema based
> error because it says:
> "E [Jing] element "lg" incomplete; expected element "addSpan",
> "alt", "altGrp", "anchor", "argument", "byline", "camera",
> "caption", "cb", "certainty", "damageSpan", "dateline",
> "delSpan", "desc", "docAuthor", "docDate", "epigraph", "fLib",
> "figure", "fs", "fvLib", "fw", "gap", "gb", "head", "incident",
> "index", "interp", "interpGrp", "join", "joinGrp", "kinesic",
> "l", "label", "lb", "lg", "link", "linkGrp", "listTranspose",
> "meeting", "metamark", "milestone", "move", "notatedMusic",
> "note", "opener", "pause", "pb", "precision", "respons",
> "salute", "shift", "sound", "space", "span", "spanGrp", "stage",
> "substJoin", "tech", "timeline", "view", "vocal", "witDetail" or
> "writing"
>
> Although the only thing that makes the error go away is an lg or
> an l, it isn't a very useful error message.
>
> Is there another schematron constraint I can test instead?
>
>
> -James
>
> On 24/09/12 17:53, Martin Holmes wrote:
>> Hi all,
>>
>> During the FTF I was talking to Sebastian about the fact that our
>> Schematron constraints are embedded directly into RelaxNG files; he
>> believed that this meant that normal validation would cause them to be
>> triggered, but I couldn't remember having been caught by a Schematron
>> constraint when validating against a RelaxNG schema, even though I know
>> I know I've violated them. So I've just started testing this.
>>
>> The RelaxNG schema for tei_all:
>>
>> <http://www.tei-c.org/release/xml/tei/custom/schema/relaxng/tei_all.rng>
>>
>> does indeed contain our handful of existing Schematron rules; if you
>> look at the element definition for <lg>, you'll see the constraint we
>> recently added, which says that an <lg> must contain at least one child
>> <l>, <lg> or <gap>.
>>
>> However, when I create a test document violating this constraint and one
>> of the others, and validate it against this schema in Oxygen 14, nothing
>> happens. (The test document is below.)
>>
>> So I went digging to try to figure out whether it was realistic to
>> expect Schematron validation as part of RelaxNG validation. According to
>> the Jing home page, Jing only has "experimental" support for Schematron,
>> and it's Schematron 1.5, not ISO Schematron. The documentation also says
>> that "Jing's implementation is not based on the reference Schematron 1.5
>> implementation. It is implemented partly in XSLT and partly in Java.
>> This implementation requires that the Schematron elements be properly
>> namespaced using the namespace URI http://www.ascc.net/xml/schematron."
>> However, our schema uses the ISO Schematron namespace,
>> "http://purl.oclc.org/dsdl/schematron". They often do define a prefix
>> for the old namespace, but they use the new one instead -- as they
>> should, I think, since we're using ISO Schematron.
>>
>> Looking at the other available RelaxNG validators, the only one that
>> promises the possibility of Schematron support is the Sun MSV validator,
>> which seems to have disappeared from the web with the Oracle take-over.
>>
>> So we don't seem to have a working validation mechanism for Schematron
>> embedded in RelaxNG schemas, unless I've missed some key configuration
>> option in Oxygen or at the command line.
>>
>> So the next thing I thought I'd do was to generate a Schematron schema
>> from Roma based on tei_all. I went to the latest and greatest Roma, here:
>>
>> <http://tei.oucs.ox.ac.uk/Roma/>
>>
>> chose to reduce a schema from the maximum possible schema, and made no
>> changes. I generated an ISO Schematron schema from that, and got a file
>> with no constraints in it at all:
>>
>> <?xml version="1.0" encoding="utf-8"?>
>> <schema xmlns="http://purl.oclc.org/dsdl/schematron"
>>            xmlns:oxdoc="http://www.oxygenxml.com/ns/doc/xsl"
>>            queryBinding="xslt2">
>>       <title>ISO Schematron rules</title>
>>
>> <!--namespaces:--><!--keys:--><!--patterns:--><!--constraints:--></schema>
>>
>> So that doesn't work, for some reason. Instead, I downloaded
>> tei_all.odd, and ran this:
>>
>> roma --isoschematron tei_all.odd .
>>
>> to get an ISO Schematron file. Validating my test file against that
>> produced the expected errors.
>>
>> So unless I'm missing something, it's unlikely that most people are
>> getting any benefit from our Schematron constraints, unless they're
>> aware that they have to manually generate a schematron schema and link
>> it into their XML files. If this is the case, I think we should be
>> documenting this process somewhere.
>>
>>
>> This is my test doc, which violates two of our Schematron constraints:
>>
>> <?xml version="1.0" encoding="UTF-8"?>
>> <?xml-model
>> href="http://www.tei-c.org/release/xml/tei/custom/schema/relaxng/tei_all.rng"
>> type="application/xml" schematypens="http://relaxng.org/ns/structure/1.0"?>
>> <TEI xmlns="http://www.tei-c.org/ns/1.0">
>>        <teiHeader>
>>            <fileDesc>
>>                <titleStmt>
>>                    <title>Testing Schematron constraints in RelaxNG</title>
>>                </titleStmt>
>>                <publicationStmt><p>Public test document</p></publicationStmt>
>>                <sourceDesc><p>Born digital</p></sourceDesc>
>>            </fileDesc>
>>        </teiHeader>
>>        <text>
>>            <body>
>>                <div>
>>                    <lg>
>>                        <stage>Enter James stage left, looking shifty.</stage>
>>                        <figure><figDesc>Picture of some lines of
>> poetry.</figDesc></figure>
>>                    </lg>
>>                    <p><ref target="http://www.uvic.ca/"
>> cRef="UVic">UVic</ref></p>
>>                </div>
>>            </body>
>>        </text>
>> </TEI>
>>
>> Cheers,
>> Martin
>>
>
>

-- 
Martin Holmes
mholmes at uvic.ca
UVic Humanities Computing and Media Centre

From mholmes at uvic.ca  Mon Sep 24 19:04:56 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Tue, 25 Sep 2012 00:04:56 +0100
Subject: [tei-council] Schematron embedded in RelaxNG
In-Reply-To: <8FC0A95D-8A80-4033-8086-5EE996E0274D@it.ox.ac.uk>
References: <5060901D.4030603@uvic.ca>
	<8FC0A95D-8A80-4033-8086-5EE996E0274D@it.ox.ac.uk>
Message-ID: <5060E718.8020003@uvic.ca>

On 12-09-24 10:52 PM, Sebastian Rahtz wrote:
>
> On 24 Sep 2012, at 17:53, Martin Holmes <mholmes at uvic.ca> wrote:
>>
>> So the next thing I thought I'd do was to generate a Schematron schema
>> from Roma based on tei_all. I went to the latest and greatest Roma, here:
>>
>> <http://tei.oucs.ox.ac.uk/Roma/>
> thats not the latest and greatest really :-}
>>
>> chose to reduce a schema from the maximum possible schema, and made no
>> changes. I generated an ISO Schematron schema from that, and got a file
>> with no constraints in it at all:
>>
>> <?xml version="1.0" encoding="utf-8"?>
>> <schema xmlns="http://purl.oclc.org/dsdl/schematron"
>>          xmlns:oxdoc="http://www.oxygenxml.com/ns/doc/xsl"
>>          queryBinding="xslt2">
>>     <title>ISO Schematron rules</title>
>>
>> <!--namespaces:--><!--keys:--><!--patterns:--><!--constraints:--></schema>
>
> sorry, I cant reproduce this. I get a properly full .isosch 3 times in a row

OK, I go here:

<http://tei.oucs.ox.ac.uk/Roma/>

I choose the second option:

Reduce: create a new customization by removing elements and modules from 
the largest possible schema

I press Start, then I click on Schema, then select ISO Schematron in the 
drop-down select. I hit Generate, then Save. I get a 296-byte file 
called myTei.isosch, which consists only of this:

<?xml version="1.0" encoding="utf-8"?>
<schema xmlns="http://purl.oclc.org/dsdl/schematron"
         xmlns:oxdoc="http://www.oxygenxml.com/ns/doc/xsl"
         queryBinding="xslt2">
    <title>ISO Schematron rules</title>
 
<!--namespaces:--><!--keys:--><!--patterns:--><!--constraints:--></schema>

Could you go through the steps you took to generate a working file?

This might just be a simple case of Roma behaving a bit weirdly if you 
do exactly what I happened to do, which is ever-so-slightly different 
from what you happen to do when trying to achieve the same result.

Cheers,
Martin


>
>
>
> --
> Sebastian Rahtz
> Director (Research Support) of Academic IT Services
> University of Oxford IT Services
> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>

-- 
Martin Holmes
mholmes at uvic.ca
UVic Humanities Computing and Media Centre

From dsewell at virginia.edu  Mon Sep 24 21:01:09 2012
From: dsewell at virginia.edu (David Sewell)
Date: Mon, 24 Sep 2012 21:01:09 -0400 (EDT)
Subject: [tei-council] TEI Candidate Question Prompt
In-Reply-To: <5060E3E0.1000508@uvic.ca>
References: <50607B4B.4050502@it.ox.ac.uk> <50608219.4090008@uvic.ca>
	<50609BDC.8000802@it.ox.ac.uk> <5060E3E0.1000508@uvic.ca>
Message-ID: <alpine.OSX.2.00.1209242057240.552@betwix.local>

Maybe the solution would be to add to James's " ... areas on which you 
feel the TEI Consortium should focus" a parenthetical phrase like 
"(bearing in mind that the Board and Council are responsible for 
different areas of overall Consortium activity)"?

There's no reason Board candidates can't address features of the 
Guidelines they feel are important, or Council candidates weigh in on 
general TEI-C organization, but they should be reminded that the two 
entitities differ in their *responsibility* for such things.

David

On Mon, 24 Sep 2012, Martin Holmes wrote:

> On 12-09-24 06:43 PM, James Cummings wrote:
>> On 24/09/12 16:54, Martin Holmes wrote:
>>> Looks good to me. I wonder if there's some way to add a proviso that
>>> wading in on the organization and finances etc. of the TEI is definitely
>>> not part of the job of the Council?
>>
>> I believe that is already covered by the general description of
>> the Board and Council duties that will be included. However,
>> DavidS (CC'ed here to get his attention) might be able to comment
>> more on that.
>>
>> Of course council members (and anyone else) are free to comment
>> on TEI organization and finances via the Board representative on
>> Council (Lou) or via me (or indeed any other member of the board)
>> should they wish.
>
> I take your point, but I wouldn't want to give the impression that
> standing for Council involves some sort of political orientation, or
> that your opinions on finances or whatever might bear on whether you get
> elected or not.
>
> Cheers,
> Martin
>
>>
>> -James
>>
>>
>
>

-- 
David Sewell, Editorial and Technical Manager
ROTUNDA, The University of Virginia Press
PO Box 400314, Charlottesville, VA 22904-4314 USA
Email: dsewell at virginia.edu   Tel: +1 434 924 9973
Web: http://rotunda.upress.virginia.edu/

From sebastian.rahtz at it.ox.ac.uk  Tue Sep 25 04:30:17 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Tue, 25 Sep 2012 08:30:17 +0000
Subject: [tei-council] Schematron embedded in RelaxNG
In-Reply-To: <5060E718.8020003@uvic.ca>
References: <5060901D.4030603@uvic.ca>
	<8FC0A95D-8A80-4033-8086-5EE996E0274D@it.ox.ac.uk>
	<5060E718.8020003@uvic.ca>
Message-ID: <9230EFA7-F55B-459F-A806-55989CE0F929@it.ox.ac.uk>

ah, that Roma is broke. I need to investigate. the one at www.tei-c.org/Roma/ works right
--
Sebastian Rahtz      
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431


From sebastian.rahtz at it.ox.ac.uk  Tue Sep 25 04:39:16 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Tue, 25 Sep 2012 08:39:16 +0000
Subject: [tei-council] Schematron embedded in RelaxNG
In-Reply-To: <9230EFA7-F55B-459F-A806-55989CE0F929@it.ox.ac.uk>
References: <5060901D.4030603@uvic.ca>
	<8FC0A95D-8A80-4033-8086-5EE996E0274D@it.ox.ac.uk>
	<5060E718.8020003@uvic.ca>
	<9230EFA7-F55B-459F-A806-55989CE0F929@it.ox.ac.uk>
Message-ID: <A13A6C62-9FBE-45F8-8D7E-BDB52C592685@it.ox.ac.uk>

I fixed the Roma on tei.oucs.ox.ac.uk to do the right thing, apologies for disruption
--
Sebastian Rahtz      
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431


From James.Cummings at it.ox.ac.uk  Tue Sep 25 09:23:24 2012
From: James.Cummings at it.ox.ac.uk (James Cummings)
Date: Tue, 25 Sep 2012 14:23:24 +0100
Subject: [tei-council] Schematron embedded in RelaxNG
In-Reply-To: <5060E5D9.2010509@uvic.ca>
References: <5060901D.4030603@uvic.ca> <50609EC7.905@it.ox.ac.uk>
	<5060E5D9.2010509@uvic.ca>
Message-ID: <5061B04C.4090104@it.ox.ac.uk>


Yes, that works for me and seems to have the correct error 
messages... don't know why it didn't before.

There is a question here, isn't there... should our default 
oXygen templates have the extra schematron constraint?

-James


On 24/09/12 23:59, Martin Holmes wrote:
> Ah -- James has figured out what I hadn't: that if you associate your
> RNG file with your XML file twice, once as RelaxNG and once as
> Schematron, then it works.
>
> I had no idea that you could do that, and I don't really know how anyone
> else would know either. I thought an xml-model PI with
> schematypens="http://purl.oclc.org/dsdl/schematron" had to point to a
> Schematron file. Perhaps there should be a way for people to find out
> how to do this? I almost never create a new XML document in the way
> James describes; usually I'm taking an existing document and changing
> it, so if my existing documents didn't have that link to the RelaxNG
> schema as Schematron, then my new one wouldn't either, and I'd never
> know anything about Schematron.
>
> To answer your question below, my message (below yours below) has a test
> document which is valid RNG-wise, but violates two simple Schematron
> constraints. That should work to test your system (it does for me).
>
> Cheers,
> Martin
>
> On 12-09-24 06:56 PM, James Cummings wrote:
>>
>> Martin,
>>
>> When I start a new XML document, then manually type in a root
>> node, then associate a schema with it (and check the 'use
>> schematron' checkbox), then correct my TEI until I ahve a valid
>> document... the top looks like this:
>>
>> <?xml version="1.0" encoding="UTF-8"?>
>> <?xml-model
>> href="http://www.tei-c.org/release/xml/tei/custom/schema/relaxng/tei_all.rng"
>> type="application/xml"
>> schematypens="http://purl.oclc.org/dsdl/schematron"?>
>> <?xml-model
>> href="http://www.tei-c.org/release/xml/tei/custom/schema/relaxng/tei_all.rng"
>> type="application/xml"
>> schematypens="http://relaxng.org/ns/structure/1.0"?>
>>
>> i.e. has both a schematron xml-model and a relaxng one.
>>
>> If I do this I get an error if I don't have an <l> inside my <lg>
>> (or a nested <lg>). However, this is just a vague schema based
>> error because it says:
>> "E [Jing] element "lg" incomplete; expected element "addSpan",
>> "alt", "altGrp", "anchor", "argument", "byline", "camera",
>> "caption", "cb", "certainty", "damageSpan", "dateline",
>> "delSpan", "desc", "docAuthor", "docDate", "epigraph", "fLib",
>> "figure", "fs", "fvLib", "fw", "gap", "gb", "head", "incident",
>> "index", "interp", "interpGrp", "join", "joinGrp", "kinesic",
>> "l", "label", "lb", "lg", "link", "linkGrp", "listTranspose",
>> "meeting", "metamark", "milestone", "move", "notatedMusic",
>> "note", "opener", "pause", "pb", "precision", "respons",
>> "salute", "shift", "sound", "space", "span", "spanGrp", "stage",
>> "substJoin", "tech", "timeline", "view", "vocal", "witDetail" or
>> "writing"
>>
>> Although the only thing that makes the error go away is an lg or
>> an l, it isn't a very useful error message.
>>
>> Is there another schematron constraint I can test instead?
>>
>>
>> -James
>>
>> On 24/09/12 17:53, Martin Holmes wrote:
>>> Hi all,
>>>
>>> During the FTF I was talking to Sebastian about the fact that our
>>> Schematron constraints are embedded directly into RelaxNG files; he
>>> believed that this meant that normal validation would cause them to be
>>> triggered, but I couldn't remember having been caught by a Schematron
>>> constraint when validating against a RelaxNG schema, even though I know
>>> I know I've violated them. So I've just started testing this.
>>>
>>> The RelaxNG schema for tei_all:
>>>
>>> <http://www.tei-c.org/release/xml/tei/custom/schema/relaxng/tei_all.rng>
>>>
>>> does indeed contain our handful of existing Schematron rules; if you
>>> look at the element definition for <lg>, you'll see the constraint we
>>> recently added, which says that an <lg> must contain at least one child
>>> <l>, <lg> or <gap>.
>>>
>>> However, when I create a test document violating this constraint and one
>>> of the others, and validate it against this schema in Oxygen 14, nothing
>>> happens. (The test document is below.)
>>>
>>> So I went digging to try to figure out whether it was realistic to
>>> expect Schematron validation as part of RelaxNG validation. According to
>>> the Jing home page, Jing only has "experimental" support for Schematron,
>>> and it's Schematron 1.5, not ISO Schematron. The documentation also says
>>> that "Jing's implementation is not based on the reference Schematron 1.5
>>> implementation. It is implemented partly in XSLT and partly in Java.
>>> This implementation requires that the Schematron elements be properly
>>> namespaced using the namespace URI http://www.ascc.net/xml/schematron."
>>> However, our schema uses the ISO Schematron namespace,
>>> "http://purl.oclc.org/dsdl/schematron". They often do define a prefix
>>> for the old namespace, but they use the new one instead -- as they
>>> should, I think, since we're using ISO Schematron.
>>>
>>> Looking at the other available RelaxNG validators, the only one that
>>> promises the possibility of Schematron support is the Sun MSV validator,
>>> which seems to have disappeared from the web with the Oracle take-over.
>>>
>>> So we don't seem to have a working validation mechanism for Schematron
>>> embedded in RelaxNG schemas, unless I've missed some key configuration
>>> option in Oxygen or at the command line.
>>>
>>> So the next thing I thought I'd do was to generate a Schematron schema
>>> from Roma based on tei_all. I went to the latest and greatest Roma, here:
>>>
>>> <http://tei.oucs.ox.ac.uk/Roma/>
>>>
>>> chose to reduce a schema from the maximum possible schema, and made no
>>> changes. I generated an ISO Schematron schema from that, and got a file
>>> with no constraints in it at all:
>>>
>>> <?xml version="1.0" encoding="utf-8"?>
>>> <schema xmlns="http://purl.oclc.org/dsdl/schematron"
>>>             xmlns:oxdoc="http://www.oxygenxml.com/ns/doc/xsl"
>>>             queryBinding="xslt2">
>>>        <title>ISO Schematron rules</title>
>>>
>>> <!--namespaces:--><!--keys:--><!--patterns:--><!--constraints:--></schema>
>>>
>>> So that doesn't work, for some reason. Instead, I downloaded
>>> tei_all.odd, and ran this:
>>>
>>> roma --isoschematron tei_all.odd .
>>>
>>> to get an ISO Schematron file. Validating my test file against that
>>> produced the expected errors.
>>>
>>> So unless I'm missing something, it's unlikely that most people are
>>> getting any benefit from our Schematron constraints, unless they're
>>> aware that they have to manually generate a schematron schema and link
>>> it into their XML files. If this is the case, I think we should be
>>> documenting this process somewhere.
>>>
>>>
>>> This is my test doc, which violates two of our Schematron constraints:
>>>
>>> <?xml version="1.0" encoding="UTF-8"?>
>>> <?xml-model
>>> href="http://www.tei-c.org/release/xml/tei/custom/schema/relaxng/tei_all.rng"
>>> type="application/xml" schematypens="http://relaxng.org/ns/structure/1.0"?>
>>> <TEI xmlns="http://www.tei-c.org/ns/1.0">
>>>         <teiHeader>
>>>             <fileDesc>
>>>                 <titleStmt>
>>>                     <title>Testing Schematron constraints in RelaxNG</title>
>>>                 </titleStmt>
>>>                 <publicationStmt><p>Public test document</p></publicationStmt>
>>>                 <sourceDesc><p>Born digital</p></sourceDesc>
>>>             </fileDesc>
>>>         </teiHeader>
>>>         <text>
>>>             <body>
>>>                 <div>
>>>                     <lg>
>>>                         <stage>Enter James stage left, looking shifty.</stage>
>>>                         <figure><figDesc>Picture of some lines of
>>> poetry.</figDesc></figure>
>>>                     </lg>
>>>                     <p><ref target="http://www.uvic.ca/"
>>> cRef="UVic">UVic</ref></p>
>>>                 </div>
>>>             </body>
>>>         </text>
>>> </TEI>
>>>
>>> Cheers,
>>> Martin
>>>
>>
>>
>


-- 
Dr James Cummings, researchsupport at it.ox.ac.uk
Research Support, IT Services, University of Oxford

From sebastian.rahtz at it.ox.ac.uk  Tue Sep 25 09:33:08 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Tue, 25 Sep 2012 13:33:08 +0000
Subject: [tei-council] Schematron embedded in RelaxNG
In-Reply-To: <5061B04C.4090104@it.ox.ac.uk>
References: <5060901D.4030603@uvic.ca> <50609EC7.905@it.ox.ac.uk>
	<5060E5D9.2010509@uvic.ca> <5061B04C.4090104@it.ox.ac.uk>
Message-ID: <4093ea26-df6e-48e9-912a-345a1cafa552@HUB01.ad.oak.ox.ac.uk>


On 25 Sep 2012, at 14:23, James Cummings <James.Cummings at it.ox.ac.uk>
 wrote:

> There is a question here, isn't there... should our default 
> oXygen templates have the extra schematron constraint?
> 

eh? that doesn't make sense to me at first blush. what do you mean?

--
Sebastian Rahtz      
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431


From James.Cummings at it.ox.ac.uk  Tue Sep 25 09:48:36 2012
From: James.Cummings at it.ox.ac.uk (James Cummings)
Date: Tue, 25 Sep 2012 14:48:36 +0100
Subject: [tei-council] Schematron embedded in RelaxNG
In-Reply-To: <4093ea26-df6e-48e9-912a-345a1cafa552@HUB01.ad.oak.ox.ac.uk>
References: <5060901D.4030603@uvic.ca> <50609EC7.905@it.ox.ac.uk>
	<5060E5D9.2010509@uvic.ca> <5061B04C.4090104@it.ox.ac.uk>
	<4093ea26-df6e-48e9-912a-345a1cafa552@HUB01.ad.oak.ox.ac.uk>
Message-ID: <5061B634.4010004@it.ox.ac.uk>

On 25/09/12 14:33, Sebastian Rahtz wrote:
>
> On 25 Sep 2012, at 14:23, James Cummings <James.Cummings at it.ox.ac.uk>
>   wrote:
>
>> There is a question here, isn't there... should our default
>> oXygen templates have the extra schematron constraint?
>>
>
> eh? that doesn't make sense to me at first blush. what do you mean?

I'm abusing the word constraint there, sorry.

What I mean is should our template TEI files for oXygen have both 
the <?xml-model?> for the relaxng and (pointing to the same file) 
the <?xml-model?> for the schematron?

If you just have the relaxng <?xml-model?> you don't get the 
schematron constraints.  The doc of the document must have both:
<?xml-model 
href="http://www.tei-c.org/release/xml/tei/custom/schema/relaxng/tei_all.rng" 
schematypens="http://relaxng.org/ns/structure/1.0"?>
<?xml-model 
href="http://www.tei-c.org/release/xml/tei/custom/schema/relaxng/tei_all.rng" 
type="application/xml" 
schematypens="http://purl.oclc.org/dsdl/schematron"?>

My question is whether that should be the default.  Currently we 
only provide:

<?xml-model 
href="http://www.tei-c.org/release/xml/tei/custom/schema/relaxng/tei_all.rng" 
schematypens="http://relaxng.org/ns/structure/1.0"?>

This will affect users who, for example, have <lg> without a 
single <l> in it which is valid under the relaxng but not if you 
add the schematron.

Is that clearer?



-- 
Dr James Cummings, researchsupport at it.ox.ac.uk
Research Support, IT Services, University of Oxford

From sebastian.rahtz at it.ox.ac.uk  Tue Sep 25 09:53:44 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Tue, 25 Sep 2012 13:53:44 +0000
Subject: [tei-council] Schematron embedded in RelaxNG
In-Reply-To: <5061B634.4010004@it.ox.ac.uk>
References: <5060901D.4030603@uvic.ca> <50609EC7.905@it.ox.ac.uk>
	<5060E5D9.2010509@uvic.ca> <5061B04C.4090104@it.ox.ac.uk>
	<4093ea26-df6e-48e9-912a-345a1cafa552@HUB01.ad.oak.ox.ac.uk>
	<5061B634.4010004@it.ox.ac.uk>
Message-ID: <fa623552-4276-4c35-97ee-e6dcaead0dff@HUB05.ad.oak.ox.ac.uk>

hmm. the <?xml-model> stuff is not in our template files at all.

Can you engage with oxygen folks and ask how that is added
when one says File/New and chooses TEI P5, and how
we can get it to add the Schematron thang?
--
Sebastian Rahtz      
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431


From sebastian.rahtz at it.ox.ac.uk  Tue Sep 25 10:35:37 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Tue, 25 Sep 2012 14:35:37 +0000
Subject: [tei-council] oxygen, schematron
Message-ID: <B99C360E-B20C-43F4-9EA9-80BD268A5714@it.ox.ac.uk>

I did a little poking. I now understand how the TEI P5 framework maps the root element and namespace to a schema, and I have
changed that to include the Schematron thang. I also found the template files which have explicit <?xml-model PIs in place.
We can the Schematron thing to them.

Question: should we manage these oxygen templates as part of the Guidelines?

My proposal is that we 

 * rename Exemplars CustomizationTemplates
 * remove the .xml files from there
 * put the oxygen templates in a new directory called Templates, with RNG and ISOSCHEMATRON xml-model PIs
 * redo packaging accordingly, to build oxygen from our new Templates dir

how does that sound?
--
Sebastian Rahtz      
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431


From sebastian.rahtz at it.ox.ac.uk  Tue Sep 25 10:41:39 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Tue, 25 Sep 2012 14:41:39 +0000
Subject: [tei-council] schematron constraints
Message-ID: <CB5E5DF4-77A2-46AD-9ED8-49F02E34722F@it.ox.ac.uk>

the message


Description: An &lt;lg&gt; must contain at least one child &lt;l&gt;, &lt;lg&gt; or &lt;gap&gt;. (count(descendant::tei:lg|descendant::tei:l|descendant::tei:gap) &gt; 0) [assert]


is actually rather unpleasant. shall we make a note to ourselves to remove the &lt; and &gt;? excessively nerdy.

(http://community.wizards.com/go/thread/view/75882/29313583/Q._How_many_geeks_does_it_take_to_ruin_a_joke)
--
Sebastian Rahtz      
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431


From bbarney2 at unl.edu  Tue Sep 25 11:39:45 2012
From: bbarney2 at unl.edu (Brett Barney)
Date: Tue, 25 Sep 2012 15:39:45 +0000
Subject: [tei-council] TEI Candidate Question Prompt
In-Reply-To: <alpine.OSX.2.00.1209242057240.552@betwix.local>
References: <50607B4B.4050502@it.ox.ac.uk> <50608219.4090008@uvic.ca>
	<50609BDC.8000802@it.ox.ac.uk> <5060E3E0.1000508@uvic.ca>
	<alpine.OSX.2.00.1209242057240.552@betwix.local>
Message-ID: <3EF593C0-A152-48F2-B250-B48B2719FFCC@unl.edu>


On Sep 24, 2012, at 8:01 PM, David Sewell wrote:
> 
> There's no reason Board candidates can't address features of the 
> Guidelines they feel are important, or Council candidates weigh in on 
> general TEI-C organization, but they should be reminded that the two 
> entitities differ in their *responsibility* for such things.

That's pretty much what I was thinking. And I think the wording David proposes works fine.


----------------
Brett Barney
Associate Research Professor
Center for Digital Research in the Humanities
bbarney2 at unl.edu






From mholmes at uvic.ca  Tue Sep 25 12:06:24 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Tue, 25 Sep 2012 17:06:24 +0100
Subject: [tei-council] Schematron embedded in RelaxNG
In-Reply-To: <A13A6C62-9FBE-45F8-8D7E-BDB52C592685@it.ox.ac.uk>
References: <5060901D.4030603@uvic.ca>
	<8FC0A95D-8A80-4033-8086-5EE996E0274D@it.ox.ac.uk>
	<5060E718.8020003@uvic.ca>
	<9230EFA7-F55B-459F-A806-55989CE0F929@it.ox.ac.uk>
	<A13A6C62-9FBE-45F8-8D7E-BDB52C592685@it.ox.ac.uk>
Message-ID: <5061D680.6000601@uvic.ca>

Thanks Sebastian. Both working perfectly now.

Cheers,
Martin

On 12-09-25 09:39 AM, Sebastian Rahtz wrote:
> I fixed the Roma on tei.oucs.ox.ac.uk to do the right thing, apologies for disruption
> --
> Sebastian Rahtz
> Director (Research Support) of Academic IT Services
> University of Oxford IT Services
> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>

-- 
Martin Holmes
mholmes at uvic.ca
UVic Humanities Computing and Media Centre

From kevin.s.hawkins at ultraslavonic.info  Wed Sep 26 10:46:56 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Wed, 26 Sep 2012 10:46:56 -0400
Subject: [tei-council] TEI Oxford Face 2 Face Minutes
In-Reply-To: <5060818F.7000202@uvic.ca>
References: <50607B4B.4050502@it.ox.ac.uk> <50607CBC.8000306@it.ox.ac.uk>
	<5060818F.7000202@uvic.ca>
Message-ID: <50631560.3070206@ultraslavonic.info>

Okay, so if I recall, Martin said he would edit a bit as he tags, so 
that means we should wait till he puts them online (without being linked 
to) before we look them over for errors and omissions?  --K.

On 9/24/2012 11:51 AM, Martin Holmes wrote:
> I'll tag them up and put them on the TEI site next week, and I'll also
> generate a table of actions like the one James did last time for the wiki.
>
> Thanks to the Oxford gang for a lovely time last week. Everything was
> really well organized, and I think we got a lot of work done.
>
> Cheers,
> Martin
>
> On 12-09-24 04:31 PM, James Cummings wrote:
>> My early message mentioned:
>>
>> On 24/09/12 16:24, James Cummings wrote:
>>> Yes, the minutes... please proofread these up until this
>>> Friday 28th. Take special note of actions assigned to you.
>>
>> If you do not have access to the minutes, email MartinH. Please
>> proofread them up until Friday 28th.
>>
>> -James
>>
>

From James.Cummings at it.ox.ac.uk  Wed Sep 26 10:51:46 2012
From: James.Cummings at it.ox.ac.uk (James Cummings)
Date: Wed, 26 Sep 2012 15:51:46 +0100
Subject: [tei-council] TEI Oxford Face 2 Face Minutes
In-Reply-To: <50631560.3070206@ultraslavonic.info>
References: <50607B4B.4050502@it.ox.ac.uk> <50607CBC.8000306@it.ox.ac.uk>
	<5060818F.7000202@uvic.ca> <50631560.3070206@ultraslavonic.info>
Message-ID: <50631682.8050803@it.ox.ac.uk>


Kevin,

Both. You should have a look at them before Friday, he will edit 
them before he converts them (I doubt he will manually tag 
things, automatic conversion of lists by our existing stylesheets 
is straightforward).  After he has put them on the website he 
will tell us and we'll double-check.

Better that omissions are rectified before conversion.

-James


On 26/09/12 15:46, Kevin Hawkins wrote:
> Okay, so if I recall, Martin said he would edit a bit as he tags, so
> that means we should wait till he puts them online (without being linked
> to) before we look them over for errors and omissions?  --K.
>
> On 9/24/2012 11:51 AM, Martin Holmes wrote:
>> I'll tag them up and put them on the TEI site next week, and I'll also
>> generate a table of actions like the one James did last time for the wiki.
>>
>> Thanks to the Oxford gang for a lovely time last week. Everything was
>> really well organized, and I think we got a lot of work done.
>>
>> Cheers,
>> Martin
>>
>> On 12-09-24 04:31 PM, James Cummings wrote:
>>> My early message mentioned:
>>>
>>> On 24/09/12 16:24, James Cummings wrote:
>>>> Yes, the minutes... please proofread these up until this
>>>> Friday 28th. Take special note of actions assigned to you.
>>>
>>> If you do not have access to the minutes, email MartinH. Please
>>> proofread them up until Friday 28th.
>>>
>>> -James
>>>
>>


-- 
Dr James Cummings, researchsupport at it.ox.ac.uk
Research Support, IT Services, University of Oxford

From kevin.s.hawkins at ultraslavonic.info  Wed Sep 26 15:53:40 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Wed, 26 Sep 2012 15:53:40 -0400
Subject: [tei-council] reimbursement form: Virginia or Brandeis?
Message-ID: <50635D44.90307@ultraslavonic.info>

James (cc'ing Council),

In Oxford you (or maybe Elena) mentioned that treasurer responsibilities 
were in between institutions right now.  Who should we send our 
reimbursement paperwork to?  The form still says Virginia, but perhaps 
that just hasn't been updated yet.

Kevin

From James.Cummings at it.ox.ac.uk  Wed Sep 26 15:54:44 2012
From: James.Cummings at it.ox.ac.uk (James Cummings)
Date: Wed, 26 Sep 2012 20:54:44 +0100
Subject: [tei-council] reimbursement form: Virginia or Brandeis?
In-Reply-To: <50635D44.90307@ultraslavonic.info>
References: <50635D44.90307@ultraslavonic.info>
Message-ID: <50635D84.60108@it.ox.ac.uk>


Hi All,

You should send your paperwork to Virginia. The bank accounts 
haven't yet been sorted out for John Unsworth to take over.

-James

On 26/09/12 20:53, Kevin Hawkins wrote:
> James (cc'ing Council),
>
> In Oxford you (or maybe Elena) mentioned that treasurer responsibilities
> were in between institutions right now.  Who should we send our
> reimbursement paperwork to?  The form still says Virginia, but perhaps
> that just hasn't been updated yet.
>
> Kevin


-- 
Dr James Cummings, researchsupport at it.ox.ac.uk
Research Support, IT Services, University of Oxford

From bansp at o2.pl  Wed Sep 26 19:24:15 2012
From: bansp at o2.pl (=?ISO-8859-2?Q?Piotr_Ba=F1ski?=)
Date: Thu, 27 Sep 2012 01:24:15 +0200
Subject: [tei-council] reimbursement form: Virginia or Brandeis?
In-Reply-To: <50635D84.60108@it.ox.ac.uk>
References: <50635D44.90307@ultraslavonic.info> <50635D84.60108@it.ox.ac.uk>
Message-ID: <50638E9F.1060406@o2.pl>

I've sent mine to the address mentioned in the form, which, I most
sincerely believe, should redirect to whoever in the world is on it now,
right?

Got no response so far, but I come from *nix culture, so no news is good
news to me.

Best,

  P.

On 26/09/12 21:54, James Cummings wrote:
> 
> Hi All,
> 
> You should send your paperwork to Virginia. The bank accounts 
> haven't yet been sorted out for John Unsworth to take over.
> 
> -James
> 
> On 26/09/12 20:53, Kevin Hawkins wrote:
>> James (cc'ing Council),
>>
>> In Oxford you (or maybe Elena) mentioned that treasurer responsibilities
>> were in between institutions right now.  Who should we send our
>> reimbursement paperwork to?  The form still says Virginia, but perhaps
>> that just hasn't been updated yet.
>>
>> Kevin
> 
> 


From mholmes at uvic.ca  Thu Sep 27 08:30:17 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Thu, 27 Sep 2012 13:30:17 +0100
Subject: [tei-council] TEI Oxford Face 2 Face Minutes
In-Reply-To: <50631560.3070206@ultraslavonic.info>
References: <50607B4B.4050502@it.ox.ac.uk> <50607CBC.8000306@it.ox.ac.uk>
	<5060818F.7000202@uvic.ca> <50631560.3070206@ultraslavonic.info>
Message-ID: <506446D9.4040703@uvic.ca>

People should edit before I tag, if possible. Once they're on the CMS, 
only a few of us can edit them.

Cheers,
Martin

On 12-09-26 03:46 PM, Kevin Hawkins wrote:
> Okay, so if I recall, Martin said he would edit a bit as he tags, so
> that means we should wait till he puts them online (without being linked
> to) before we look them over for errors and omissions?  --K.
>
> On 9/24/2012 11:51 AM, Martin Holmes wrote:
>> I'll tag them up and put them on the TEI site next week, and I'll also
>> generate a table of actions like the one James did last time for the wiki.
>>
>> Thanks to the Oxford gang for a lovely time last week. Everything was
>> really well organized, and I think we got a lot of work done.
>>
>> Cheers,
>> Martin
>>
>> On 12-09-24 04:31 PM, James Cummings wrote:
>>> My early message mentioned:
>>>
>>> On 24/09/12 16:24, James Cummings wrote:
>>>> Yes, the minutes... please proofread these up until this
>>>> Friday 28th. Take special note of actions assigned to you.
>>>
>>> If you do not have access to the minutes, email MartinH. Please
>>> proofread them up until Friday 28th.
>>>
>>> -James
>>>
>>

-- 
Martin Holmes
mholmes at uvic.ca
UVic Humanities Computing and Media Centre

From kevin.s.hawkins at ultraslavonic.info  Sun Sep 30 17:51:38 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Sun, 30 Sep 2012 17:51:38 -0400
Subject: [tei-council] biblstruct for patent citations: comments by 15 Oct.
	please
Message-ID: <5068BEEA.5020203@ultraslavonic.info>

All,

During our meeting in Oxford we set aside a ticket on changes requested 
for <biblStruct> in order to use it to encode patent citations:

http://purl.org/tei/fr/3513147

I was scheduled to have a Skype conversation with the requestor (Javier 
Pose) after our meeting and thought that it would be best to wait till 
after then to consider this as a group.

Javier and I have now discussed it and my latest recommendation is on 
the ticket.  While a few alternative encodings have been considered 
throughout past discussion on the ticket, Javier said that he will 
accept the recommendation of Council on the specifics of the encoding. 
However, he would like to know as soon as possible what will make it 
into the Guidelines so that the European Patent Office can adapt their 
encoding to conform to the Guidelines.  The EPO is keen to be able to 
claim full TEI compliance and make use of the TEI instead of an 
alternative, and is required to release data by the end of the year.  So 
it would be good for us to help along their high-profile work.

Could we reach consensus on this by email?  Perhaps everyone could look 
and raise objections by Oct. 15; otherwise, I will implement the schema 
changes and get documentation from Javier.  If that's too rushed, 
perhaps Council can have a conf call sometime this fall?

Kevin

From mholmes at uvic.ca  Mon Oct  1 19:26:57 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Mon, 1 Oct 2012 16:26:57 -0700
Subject: [tei-council] FTF Minutes coming soon
Message-ID: <506A26C1.7080708@uvic.ca>

Hi all,

I made the mistake of trying to convert the ODT file directly to P5 as 
the basis for my tagging of the minutes, and the results were not happy. 
Word-processors sure are dumb. I've finally got a basic P5 file up on 
the TEI site, but it's pretty ugly and doesn't have a decent table of 
contents because it ended up with no useful document divisions. I'll get 
it finished in the next couple of days. What I have been doing is making 
sure that all the action items are tagged in such a way that they can be 
retrieved into a table of outstanding actions for the wiki like the one 
James created last time around, using XSLT, so that should be available 
within the next couple of days too.

Apologies for the delay.

Cheers,
Martin
-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From mholmes at uvic.ca  Tue Oct  2 11:56:53 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Tue, 2 Oct 2012 08:56:53 -0700
Subject: [tei-council] Meeting minutes and action list done
Message-ID: <506B0EC5.5010505@uvic.ca>

Hi all,

The minutes from Oxford are here:

<http://www.tei-c.org/Activities/Council/Meetings/tcm52.xml>

and there's now a wiki page with a list of actions for us all, on the 
model of the one James created from Ann Arbor, here:

<http://wiki.tei-c.org/index.php/Oxford2012-Actions>

Cheers,
Martin
-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From sebastian.rahtz at it.ox.ac.uk  Wed Oct  3 12:42:20 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Wed, 3 Oct 2012 16:42:20 +0000
Subject: [tei-council] datatype of unclear/@reason
Message-ID: <C619B3B4-5787-42CF-8959-75CA6F1714B0@it.ox.ac.uk>

cf https://sourceforge.net/tracker/?func=detail&aid=3573757&group_id=106328&atid=644062

We set the value of this attribute to be data.word+, and then give examples liked "faded ink".

This can't be right. Either its
   * there can be many reasons, supply a tokenized lists
or
   * the datatype should be free text

Inclining to the former as per our usual arguments, I have regarded the request as corrigible,
and Just Went Ahead.

Please shout if you think I Did Wrong, and I will revert.
--
Sebastian Rahtz      
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431


From sebastian.rahtz at it.ox.ac.uk  Fri Oct  5 12:37:55 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Fri, 5 Oct 2012 16:37:55 +0000
Subject: [tei-council] oxygen, schematron
In-Reply-To: <B99C360E-B20C-43F4-9EA9-80BD268A5714@it.ox.ac.uk>
References: <B99C360E-B20C-43F4-9EA9-80BD268A5714@it.ox.ac.uk>
Message-ID: <69992D4E-9E73-4DE9-BD67-F13693506BAB@it.ox.ac.uk>

would anyone like to forbid me moving ahead as per below?


On 25 Sep 2012, at 15:35, Sebastian Rahtz <sebastian.rahtz at it.ox.ac.uk> wrote:

> I did a little poking. I now understand how the TEI P5 framework maps the root element and namespace to a schema, and I have
> changed that to include the Schematron thang. I also found the template files which have explicit <?xml-model PIs in place.
> We can the Schematron thing to them.
> 
> Question: should we manage these oxygen templates as part of the Guidelines?
> 
> My proposal is that we 
> 
> * rename Exemplars CustomizationTemplates
> * remove the .xml files from there
> * put the oxygen templates in a new directory called Templates, with RNG and ISOSCHEMATRON xml-model PIs
> * redo packaging accordingly, to build oxygen from our new Templates dir
> 

--
Sebastian Rahtz      
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431


From lou.burnard at retired.ox.ac.uk  Fri Oct  5 12:43:54 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Fri, 05 Oct 2012 17:43:54 +0100
Subject: [tei-council] oxygen, schematron
In-Reply-To: <69992D4E-9E73-4DE9-BD67-F13693506BAB@it.ox.ac.uk>
References: <B99C360E-B20C-43F4-9EA9-80BD268A5714@it.ox.ac.uk>
	<69992D4E-9E73-4DE9-BD67-F13693506BAB@it.ox.ac.uk>
Message-ID: <506F0E4A.7040208@retired.ox.ac.uk>

On 05/10/12 17:37, Sebastian Rahtz wrote:
> would anyone like to forbid me moving ahead as per below

Sorry, but for the slow-witted amongst us, what is the purpose of this 
change? Simply to have a separate "Templates" directory containing 
appropriate template files for use within Oxygen? That sounds like a 
good idea. I don't mind renaming Exemplars either, but calling it 
"anything-templates" seems likely to lead to confusion with the new 
Templates directory. How about "Customisations"?

>
> On 25 Sep 2012, at 15:35, Sebastian Rahtz <sebastian.rahtz at it.ox.ac.uk> wrote:
>
>> I did a little poking. I now understand how the TEI P5 framework maps the root element and namespace to a schema, and I have
>> changed that to include the Schematron thang. I also found the template files which have explicit <?xml-model PIs in place.
>> We can the Schematron thing to them.
>>
>> Question: should we manage these oxygen templates as part of the Guidelines?
>>
>> My proposal is that we
>>
>> * rename Exemplars CustomizationTemplates
>> * remove the .xml files from there
>> * put the oxygen templates in a new directory called Templates, with RNG and ISOSCHEMATRON xml-model PIs
>> * redo packaging accordingly, to build oxygen from our new Templates dir
>>
>
> --
> Sebastian Rahtz
> Director (Research Support) of Academic IT Services
> University of Oxford IT Services
> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>


From mholmes at uvic.ca  Fri Oct  5 13:03:37 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Fri, 5 Oct 2012 10:03:37 -0700
Subject: [tei-council] oxygen, schematron
In-Reply-To: <69992D4E-9E73-4DE9-BD67-F13693506BAB@it.ox.ac.uk>
References: <B99C360E-B20C-43F4-9EA9-80BD268A5714@it.ox.ac.uk>
	<69992D4E-9E73-4DE9-BD67-F13693506BAB@it.ox.ac.uk>
Message-ID: <506F12E9.6050409@uvic.ca>

I think perhaps we should be explicit in calling the templates directory 
"Oxygen-Templates". It would be easier for the likes of me to figure 
out, a year from now, where that Oxygen-related stuff is coming from. It 
would also help regular users who might want to grab the 
latest-and-greatest templates from SVN and put them into their Oxygen 
directory.

Cheers,
Martin

On 12-10-05 09:37 AM, Sebastian Rahtz wrote:
> would anyone like to forbid me moving ahead as per below?
>
>
> On 25 Sep 2012, at 15:35, Sebastian Rahtz <sebastian.rahtz at it.ox.ac.uk> wrote:
>
>> I did a little poking. I now understand how the TEI P5 framework maps the root element and namespace to a schema, and I have
>> changed that to include the Schematron thang. I also found the template files which have explicit <?xml-model PIs in place.
>> We can the Schematron thing to them.
>>
>> Question: should we manage these oxygen templates as part of the Guidelines?
>>
>> My proposal is that we
>>
>> * rename Exemplars CustomizationTemplates
>> * remove the .xml files from there
>> * put the oxygen templates in a new directory called Templates, with RNG and ISOSCHEMATRON xml-model PIs
>> * redo packaging accordingly, to build oxygen from our new Templates dir
>>
>
> --
> Sebastian Rahtz
> Director (Research Support) of Academic IT Services
> University of Oxford IT Services
> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From lou.burnard at retired.ox.ac.uk  Fri Oct  5 13:04:22 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Fri, 05 Oct 2012 18:04:22 +0100
Subject: [tei-council] oxygen, schematron
In-Reply-To: <506F12E9.6050409@uvic.ca>
References: <B99C360E-B20C-43F4-9EA9-80BD268A5714@it.ox.ac.uk>
	<69992D4E-9E73-4DE9-BD67-F13693506BAB@it.ox.ac.uk>
	<506F12E9.6050409@uvic.ca>
Message-ID: <506F1316.5010904@retired.ox.ac.uk>

+1 from me. (But please lose the hyphen)

On 05/10/12 18:03, Martin Holmes wrote:
> I think perhaps we should be explicit in calling the templates directory
> "Oxygen-Templates". It would be easier for the likes of me to figure
> out, a year from now, where that Oxygen-related stuff is coming from. It
> would also help regular users who might want to grab the
> latest-and-greatest templates from SVN and put them into their Oxygen
> directory.
>
> Cheers,
> Martin
>
> On 12-10-05 09:37 AM, Sebastian Rahtz wrote:
>> would anyone like to forbid me moving ahead as per below?
>>
>>
>> On 25 Sep 2012, at 15:35, Sebastian Rahtz <sebastian.rahtz at it.ox.ac.uk> wrote:
>>
>>> I did a little poking. I now understand how the TEI P5 framework maps the root element and namespace to a schema, and I have
>>> changed that to include the Schematron thang. I also found the template files which have explicit <?xml-model PIs in place.
>>> We can the Schematron thing to them.
>>>
>>> Question: should we manage these oxygen templates as part of the Guidelines?
>>>
>>> My proposal is that we
>>>
>>> * rename Exemplars CustomizationTemplates
>>> * remove the .xml files from there
>>> * put the oxygen templates in a new directory called Templates, with RNG and ISOSCHEMATRON xml-model PIs
>>> * redo packaging accordingly, to build oxygen from our new Templates dir
>>>
>>
>> --
>> Sebastian Rahtz
>> Director (Research Support) of Academic IT Services
>> University of Oxford IT Services
>> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>>
>


From sebastian.rahtz at it.ox.ac.uk  Fri Oct  5 13:16:42 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Fri, 5 Oct 2012 17:16:42 +0000
Subject: [tei-council] oxygen, schematron
In-Reply-To: <506F0E4A.7040208@retired.ox.ac.uk>
References: <B99C360E-B20C-43F4-9EA9-80BD268A5714@it.ox.ac.uk>
	<69992D4E-9E73-4DE9-BD67-F13693506BAB@it.ox.ac.uk>,
	<506F0E4A.7040208@retired.ox.ac.uk>
Message-ID: <42e513d0-5f34-41d4-9fa5-1e97eb117c51@HUB04.ad.oak.ox.ac.uk>



> 
> Sorry, but for the slow-witted amongst us, what is the purpose of this 
> change? Simply to have a separate "Templates" directory containing 
> appropriate template files for use within Oxygen? 

Yes. To make clear that we have a) document templates on offer, and b) customization examples ( lite and tite) and c) customization templates. If want to combine b) and c) into Customizations, that's fine by me. I do think that aligning the names will help. So tei-drama has an odd customization template, a document template, and a test file. Maybe can do all in one dir. My priority is making it clear which the doc templates are, so I can generate the oxygen package from our source. I want no chance of divergence between gidlines and oygygen's "create a ne TEI doc of type Xxx" functionality

Yeah for apple auto spell. Not.

S

From lou.burnard at retired.ox.ac.uk  Fri Oct  5 13:41:34 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Fri, 05 Oct 2012 18:41:34 +0100
Subject: [tei-council] @style
Message-ID: <506F1BCE.4010102@retired.ox.ac.uk>

I am currently working my way through CO, HD, and ST implementing our 
decision to introduce @style. Mostly it's pretty plain sailing, but I 
have just hit a passage in  CO where I'd appreciate Council's guidance.

At the end of COHQQ I find the following rather exotic examples :

<egXML xmlns="http://www.tei-c.org/ns/Examples" 
corresp="#DSHD-eg-30"><said rend="PRE lsquo POST rsquo">Who-e debel
  you?</said> ? he at last said ?
  <said rend="PRE lsquo POST rsquo">you no speak-e,
  damme, I kill-e.</said>  And so saying,
  the lighted tomahawk began flourishing
  about me in the dark.</egXML>

  <egXML xmlns="http://www.tei-c.org/ns/Examples"
	corresp="#COHQQ-eg-23" xml:lang="fr">Adolphe se tourna vers lui :
  <said>? Alors, Albert, quoi de neuf?</said>
  <said>? Pas grand-chose.</said>
  <said>? Il fait beau,</said> dit Robert.</egXML>

<egXML xmlns="http://www.tei-c.org/ns/Examples" corresp="#COHQQ-eg-23" 
xml:lang="fr">Adolphe se tourna vers lui :
  <said rend="PRE mdash">Alors,
  Albert, quoi de neuf ?</said>
  <said rend="PRE mdash">Pas grand-chose.</said>
  <said rend="PRE mdash">Il fait beau,</said>
  dit Robert.</egXML>
  </p>

Would someone like to propose better encodings for these, using @style 
and/or @rendition? Or should we leave them?




From lou.burnard at retired.ox.ac.uk  Fri Oct  5 14:08:22 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Fri, 05 Oct 2012 19:08:22 +0100
Subject: [tei-council] @style /rend/rendition coexistence
Message-ID: <506F2216.3010703@retired.ox.ac.uk>

Just to make sure we're all on the same page, here are some suggested 
rules on style/rend/rendition usage, to be documented in STGA as part of 
my introduction of @style.


1. An element's style can be specified generically using the <rendition> 
element. i.e. if I find a <foo> AND  there's a  <rendition> is supplied 
within <tagUsage ident="foo">, then that's the default

Unless...

2. ... <foo rendition="#something"> means that the rendition supplied by 
<rendition xml:id="something"> over-rides (or complements?) any default.

or

3. ... <foo style="text:style whatever"> works in the same way i.e. any 
default is over-ridden (or complemented?)

or

4. ... <foo rend="wibble"> is entirely independent of any rendition 
rules inherited from <rendition>. My applications Just Have To Know what 
wibbled text is and deal accordingly.

If that's so...

A. What does

<foo rendition="#something" style="something else"> mean?

Is it illegal? or does it mean that "#something" and "something else" 
have to be unified, in just the same way as they would if "something 
else" were the default <rendition> for <foo> and I had supplied just the 
@rendition attribute.

B. What does

<foo style="something else" rend="wibble"> mean?

By rule 4, we Just Don't Know. But we don't feel brave enough to outlaw 
it. Or do we?

Outstanding questions.

-- What does "unification" mean if the expressions come from different 
languages? (e.g FO and CSS)

-- Where do we specify the language in which @style values are expressed ?




From mholmes at uvic.ca  Fri Oct  5 14:09:20 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Fri, 5 Oct 2012 11:09:20 -0700
Subject: [tei-council] @style
In-Reply-To: <506F1BCE.4010102@retired.ox.ac.uk>
References: <506F1BCE.4010102@retired.ox.ac.uk>
Message-ID: <506F2250.2010705@uvic.ca>

This is interesting. These are actually instances where a CSS 
pseudo-element is needed, so they're not naturals for @style or even 
@rendition/<rendition>. For instance, in the case of the first, in 
XHTML/CSS, you would do:

#el:before{
	content: '\2018';
}
#el:after{
	content: '\2019';
}

It's not possible to put this kind of CSS into an XHTML @style attribute 
AFAIK, because a key part of the information is in the selector, not the 
ruleset. You could do something like this:

<rendition xml:id="saidBefore">content: '\2018';</rendition>
<rendition xml:id="saidAfter">content: '\2019';</rendition>

and then link with:

<said rendition="#saidBefore #saidAfter">...

but this relies on the processor "knowing" that <rendition>s with 
"Before" or "After" suffixes in their @xml:ids are to be converted into 
pseudo-elements in CSS.

Can anyone see a more elegant way to do this?

Cheers,
Martin

On 12-10-05 10:41 AM, Lou Burnard wrote:
> I am currently working my way through CO, HD, and ST implementing our
> decision to introduce @style. Mostly it's pretty plain sailing, but I
> have just hit a passage in  CO where I'd appreciate Council's guidance.
>
> At the end of COHQQ I find the following rather exotic examples :
>
> <egXML xmlns="http://www.tei-c.org/ns/Examples"
> corresp="#DSHD-eg-30"><said rend="PRE lsquo POST rsquo">Who-e debel
>    you?</said> ? he at last said ?
>    <said rend="PRE lsquo POST rsquo">you no speak-e,
>    damme, I kill-e.</said>  And so saying,
>    the lighted tomahawk began flourishing
>    about me in the dark.</egXML>
>
>    <egXML xmlns="http://www.tei-c.org/ns/Examples"
> 	corresp="#COHQQ-eg-23" xml:lang="fr">Adolphe se tourna vers lui :
>    <said>? Alors, Albert, quoi de neuf?</said>
>    <said>? Pas grand-chose.</said>
>    <said>? Il fait beau,</said> dit Robert.</egXML>
>
> <egXML xmlns="http://www.tei-c.org/ns/Examples" corresp="#COHQQ-eg-23"
> xml:lang="fr">Adolphe se tourna vers lui :
>    <said rend="PRE mdash">Alors,
>    Albert, quoi de neuf ?</said>
>    <said rend="PRE mdash">Pas grand-chose.</said>
>    <said rend="PRE mdash">Il fait beau,</said>
>    dit Robert.</egXML>
>    </p>
>
> Would someone like to propose better encodings for these, using @style
> and/or @rendition? Or should we leave them?
>
>
>

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From sebastian.rahtz at it.ox.ac.uk  Fri Oct  5 14:32:36 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Fri, 5 Oct 2012 18:32:36 +0000
Subject: [tei-council] @style
In-Reply-To: <506F2250.2010705@uvic.ca>
References: <506F1BCE.4010102@retired.ox.ac.uk> <506F2250.2010705@uvic.ca>
Message-ID: <E3395C5E-1499-402C-8279-4DC91E059B2F@it.ox.ac.uk>


On 5 Oct 2012, at 19:09, Martin Holmes <mholmes at uvic.ca>
 wrote:

> 
> <rendition xml:id="saidBefore">content: '\2018';</rendition>
> <rendition xml:id="saidAfter">content: '\2019';</rendition>
> 
<rendiition xml:id="saidBefore" scope="before">content: '\2018';</rendition>

this is what @scope was put in for.


--
Sebastian Rahtz      
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431


From mholmes at uvic.ca  Fri Oct  5 14:35:32 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Fri, 5 Oct 2012 11:35:32 -0700
Subject: [tei-council] @style /rend/rendition coexistence
In-Reply-To: <506F2216.3010703@retired.ox.ac.uk>
References: <506F2216.3010703@retired.ox.ac.uk>
Message-ID: <506F2874.5070104@uvic.ca>

I think insofar as we can, we should mimic what HTML does. So in this case:

<foo rendition="#something" style="something else">

the rules in #something are first applied, and then the rules in @style 
complement/override them. This means that any rule in @style overrides 
any rule for the same property which has been defined in #something.

In the case of this:

<foo style="something else" rend="wibble">

I see no reason to outlaw it; there will be cases in which no property 
exists in CSS (or whatever formal language is in use) is available to 
cover a particular feature, so @rend can be used to specify it; since 
there is no way of doing whatever-it-is in CSS, then there's no 
requirement to specify formally how they interact, because they can't. 
It would make no sense to do this:

<foo style="font-style: normal;" rend="italic">

but I don't think it's our job to try to prevent people creating 
oxymoronic encodings.

On these:

 > -- What does "unification" mean if the expressions come from different
 > languages? (e.g FO and CSS)

In that specific case, FO uses CSS, so I'm not really clear on why you 
would use both. But where such questions arise, they have to be dealt 
with in encodingDesc, I think.

 > -- Where do we specify the language in which @style values are 
expressed ?

There has to be an element in the header, presumably in <tagsDecl>. 
Something like this:

<style scheme="css"></style>

although I'm not sure we want to go with the same potential confusion as 
we've already got with <rendition> vs @rendition. Perhaps:

<styleDesc scheme="css">
[More detailed prose explanations go here.]
</styleDesc>

Cheers,
Martin

On 12-10-05 11:08 AM, Lou Burnard wrote:
> Just to make sure we're all on the same page, here are some suggested
> rules on style/rend/rendition usage, to be documented in STGA as part of
> my introduction of @style.
>
>
> 1. An element's style can be specified generically using the <rendition>
> element. i.e. if I find a <foo> AND  there's a  <rendition> is supplied
> within <tagUsage ident="foo">, then that's the default
>
> Unless...
>
> 2. ... <foo rendition="#something"> means that the rendition supplied by
> <rendition xml:id="something"> over-rides (or complements?) any default.
>
> or
>
> 3. ... <foo style="text:style whatever"> works in the same way i.e. any
> default is over-ridden (or complemented?)
>
> or
>
> 4. ... <foo rend="wibble"> is entirely independent of any rendition
> rules inherited from <rendition>. My applications Just Have To Know what
> wibbled text is and deal accordingly.
>
> If that's so...
>
> A. What does
>
> <foo rendition="#something" style="something else"> mean?
>
> Is it illegal? or does it mean that "#something" and "something else"
> have to be unified, in just the same way as they would if "something
> else" were the default <rendition> for <foo> and I had supplied just the
> @rendition attribute.
>
> B. What does
>
> <foo style="something else" rend="wibble"> mean?
>
> By rule 4, we Just Don't Know. But we don't feel brave enough to outlaw
> it. Or do we?
>
> Outstanding questions.
>
> -- What does "unification" mean if the expressions come from different
> languages? (e.g FO and CSS)
>
> -- Where do we specify the language in which @style values are expressed ?
>
>
>

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From sebastian.rahtz at it.ox.ac.uk  Fri Oct  5 14:36:16 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Fri, 5 Oct 2012 18:36:16 +0000
Subject: [tei-council] @style
In-Reply-To: <506F1BCE.4010102@retired.ox.ac.uk>
References: <506F1BCE.4010102@retired.ox.ac.uk>
Message-ID: <40a87654-5210-483d-9bde-0ddb68781559@HUB02.ad.oak.ox.ac.uk>


On 5 Oct 2012, at 18:41, Lou Burnard <lou.burnard at retired.ox.ac.uk>
 wrote:

> At the end of COHQQ I find the following rather exotic examples :
> 
> <egXML xmlns="http://www.tei-c.org/ns/Examples" 
> corresp="#DSHD-eg-30"><said rend="PRE lsquo POST rsquo">Who-e debel
>  you?</said> ? he at last said ?
>  <said rend="PRE lsquo POST rsquo">you no speak-e,
>  damme, I kill-e.</said>  And so saying,
>  the lighted tomahawk began flourishing
>  about me in the dark.</egXML>


you _could_ do it as
 rend="PRE+lsquo+POST+lsquo"
I think? (or some other character). That
would preserve the horror the horror forever in amber

or point at a rendition, as Martin suggested. He is right,
you can't use @style for this.

--
Sebastian Rahtz      
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431


From sebastian.rahtz at it.ox.ac.uk  Fri Oct  5 14:41:43 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Fri, 5 Oct 2012 18:41:43 +0000
Subject: [tei-council] @style /rend/rendition coexistence
In-Reply-To: <506F2216.3010703@retired.ox.ac.uk>
References: <506F2216.3010703@retired.ox.ac.uk>
Message-ID: <212fb5a7-8946-4794-bcfa-5e9ef6e7622d@HUB04.ad.oak.ox.ac.uk>


On 5 Oct 2012, at 19:08, Lou Burnard <lou.burnard at retired.ox.ac.uk>
 wrote:

> 1. An element's style can be specified generically using the <rendition> 
> element. i.e. if I find a <foo> AND  there's a  <rendition> is supplied 
> within <tagUsage ident="foo">, then that's the default
> 
agreed. this is the fallback if none of rend/edition/style are found

> Unless...
> 
> 2. ... <foo rendition="#something"> means that the rendition supplied by 
> <rendition xml:id="something"> over-rides (or complements?) any default.

I would say overrides. The tagsDecl one is an alternative to the whole scheme.
> 
> or
> 
> 3. ... <foo style="text:style whatever"> works in the same way i.e. any 
> default is over-ridden (or complemented?)
I would say it overrides the default, and complements the context
> 
> or
> 
> 4. ... <foo rend="wibble"> is entirely independent of any rendition 
> rules inherited from <rendition>. My applications Just Have To Know what 
> wibbled text is and deal accordingly.

I would say @rend, @rendition and @style are mutually complementary
to the extent possible.

> 
> If that's so...
> 
> A. What does
> 
> <foo rendition="#something" style="something else"> mean?
> 
> Is it illegal? or does it mean that "#something" and "something else" 
> have to be unified,
yes,that

> B. What does
> 
> <foo style="something else" rend="wibble"> mean?
> 
> By rule 4, we Just Don't Know. But we don't feel brave enough to outlaw 
> it. Or do we?
> 
I would  say you unify it as best you can

> Outstanding questions.
> 
> -- What does "unification" mean if the expressions come from different 
> languages? (e.g FO and CSS)
you do the best you can. in the same way you interpret colour changes
on a black and white output

> 
> -- Where do we specify the language in which @style values are expressed ?


ah, now you're talking. we have to have a decl for it somewhere. i thought we
discussed that at F2F?
--
Sebastian Rahtz      
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431


From sebastian.rahtz at it.ox.ac.uk  Fri Oct  5 14:46:57 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Fri, 5 Oct 2012 18:46:57 +0000
Subject: [tei-council] @style /rend/rendition coexistence
In-Reply-To: <506F2216.3010703@retired.ox.ac.uk>
References: <506F2216.3010703@retired.ox.ac.uk>
Message-ID: <e38c3e27-e5b7-42f7-8b0b-9026ffffe9a0@HUB01.ad.oak.ox.ac.uk>


On 5 Oct 2012, at 19:08, Lou Burnard <lou.burnard at retired.ox.ac.uk>
 wrote:

> 
> <foo style="something else" rend="wibble"> mean?
> 

If I meet <hi style="font-weight:bold;" rend="italic">hello</hi>
I guess I am just going to swallow nervously and generate
  <span style="font-weight:bold; font-style:italic">hello</span>
and
 {\bfseries\itshape hello}
etc

but equally I dont mind being told that @rend wipes out @style/@rendition
--
Sebastian Rahtz      
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431


From James.Cummings at it.ox.ac.uk  Fri Oct  5 15:00:42 2012
From: James.Cummings at it.ox.ac.uk (James Cummings)
Date: Fri, 05 Oct 2012 20:00:42 +0100
Subject: [tei-council] @style /rend/rendition coexistence
In-Reply-To: <506F2216.3010703@retired.ox.ac.uk>
References: <506F2216.3010703@retired.ox.ac.uk>
Message-ID: <506F2E5A.1020408@it.ox.ac.uk>


I worry about some of the phrasing (which I realise are just 
shorthand discussion here). When we talk about 'overriding' and 
'processing' we have to make sure we are clear and consistent 
that this is documenting how phenomena appeared in the source, 
not how it is to be rendered in any particular output.  One may 
be taking the source text and generating a word list and want to 
exclude words which were originally in italics or red or 
something because this has a particular semantics.  I only make a 
plea that the Guidelines should be fairly agnostic about what a 
processor does with rendition documentation.  (This is entirely 
separate from what Sebastian (and others) choose to implement as 
default actions in the conversion stylesheets.)

Consistently pure,  ;-)
-James

On 05/10/12 19:08, Lou Burnard wrote:
> Just to make sure we're all on the same page, here are some suggested
> rules on style/rend/rendition usage, to be documented in STGA as part of
> my introduction of @style.
>
>
> 1. An element's style can be specified generically using the<rendition>
> element. i.e. if I find a<foo>  AND  there's a<rendition>  is supplied
> within<tagUsage ident="foo">, then that's the default
>
> Unless...
>
> 2. ...<foo rendition="#something">  means that the rendition supplied by
> <rendition xml:id="something">  over-rides (or complements?) any default.
>
> or
>
> 3. ...<foo style="text:style whatever">  works in the same way i.e. any
> default is over-ridden (or complemented?)
>
> or
>
> 4. ...<foo rend="wibble">  is entirely independent of any rendition
> rules inherited from<rendition>. My applications Just Have To Know what
> wibbled text is and deal accordingly.
>
> If that's so...
>
> A. What does
>
> <foo rendition="#something" style="something else">  mean?
>
> Is it illegal? or does it mean that "#something" and "something else"
> have to be unified, in just the same way as they would if "something
> else" were the default<rendition>  for<foo>  and I had supplied just the
> @rendition attribute.
>
> B. What does
>
> <foo style="something else" rend="wibble">  mean?
>
> By rule 4, we Just Don't Know. But we don't feel brave enough to outlaw
> it. Or do we?
>
> Outstanding questions.
>
> -- What does "unification" mean if the expressions come from different
> languages? (e.g FO and CSS)
>
> -- Where do we specify the language in which @style values are expressed ?
>
>
>


-- 
Dr James Cummings, researchsupport at it.ox.ac.uk
Research Support, IT Services, University of Oxford

From James.Cummings at it.ox.ac.uk  Fri Oct  5 15:12:34 2012
From: James.Cummings at it.ox.ac.uk (James Cummings)
Date: Fri, 05 Oct 2012 20:12:34 +0100
Subject: [tei-council] @style /rend/rendition coexistence
In-Reply-To: <e38c3e27-e5b7-42f7-8b0b-9026ffffe9a0@HUB01.ad.oak.ox.ac.uk>
References: <506F2216.3010703@retired.ox.ac.uk>
	<e38c3e27-e5b7-42f7-8b0b-9026ffffe9a0@HUB01.ad.oak.ox.ac.uk>
Message-ID: <506F3122.30507@it.ox.ac.uk>

On 05/10/12 19:46, Sebastian Rahtz wrote:
> On 5 Oct 2012, at 19:08, Lou Burnard<lou.burnard at retired.ox.ac.uk>
>   wrote:
>> <foo style="something else" rend="wibble">  mean?
> If I meet<hi style="font-weight:bold;" rend="italic">hello</hi>
> I guess I am just going to swallow nervously and generate
>    <span style="font-weight:bold; font-style:italic">hello</span> and
>   {\bfseries\itshape hello}
> etc
> but equally I dont mind being told that @rend wipes out @style/@rendition

I would argue against this. I can envision quite easily a project 
workflow where one person is adding @rend values from a 
constrained list because that is all they are capable and someone 
else is looking at _different_ features and adding @rendtion 
rules because they know XSL-FO in the same project.  Ok, the 
@rend values may be converted at a later point to @rendition for 
consistency but it should not be seen and wrong or bad practice 
to have both.

But again, you are interpreting based on your need and fears of 
implementation in the stylesheet suite. (Which is good, laudable, 
and understandable.) But we can't let stylesheet implementation 
drive the definition of the documentation aspect of this. The 
user is documenting their interpretation of the original, not 
coding to a particular output. Or at least, they *shouldn't* be 
and one of my arguments against @style was that I feel it 
encourages this, especially in processing born digital documents. 
  (If I was being extreme I might be tempted to argue we should 
never have <hi style="font-weight:bold">...</hi> in born digital 
documents because we shouldn't be marking 'highlighting' only 
semantic instances of 'emphasis' or 'distinct' or similar for 
which we have elements.)

-James

-- 
Dr James Cummings, researchsupport at it.ox.ac.uk
Research Support, IT Services, University of Oxford

From sebastian.rahtz at it.ox.ac.uk  Fri Oct  5 15:12:52 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Fri, 5 Oct 2012 19:12:52 +0000
Subject: [tei-council] @style /rend/rendition coexistence
In-Reply-To: <506F2E5A.1020408@it.ox.ac.uk>
References: <506F2216.3010703@retired.ox.ac.uk> <506F2E5A.1020408@it.ox.ac.uk>
Message-ID: <42475b4b-9882-4fd2-98c8-4c0c21f6d5a4@HUB03.ad.oak.ox.ac.uk>

James is right, of course. but does not affect the problem over the rules, surely?
--
Sebastian Rahtz      
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431


From James.Cummings at it.ox.ac.uk  Fri Oct  5 15:19:30 2012
From: James.Cummings at it.ox.ac.uk (James Cummings)
Date: Fri, 05 Oct 2012 20:19:30 +0100
Subject: [tei-council] @style /rend/rendition coexistence
In-Reply-To: <42475b4b-9882-4fd2-98c8-4c0c21f6d5a4@HUB03.ad.oak.ox.ac.uk>
References: <506F2216.3010703@retired.ox.ac.uk> <506F2E5A.1020408@it.ox.ac.uk>
	<42475b4b-9882-4fd2-98c8-4c0c21f6d5a4@HUB03.ad.oak.ox.ac.uk>
Message-ID: <506F32C2.80500@it.ox.ac.uk>

On 05/10/12 20:12, Sebastian Rahtz wrote:
> James is right, of course. but does not affect the problem over the rules, surely?

True. We just need to be clear that it is the priority in which 
the documentation is to be untangled, whether and how things are 
inherited, etc. not rules over processing them for any specific 
output. ;-)

As soon as @style is processed in Sebastian's stylesheets, people 
will, of course, en masse use it to record the output styling 
they want even when this does not reflect the source document at 
all.

Ok, I'll try to not harp on about it, I've made my reminder which 
I'm sure Lou will bear in mind when redrafting prose.

-James

-- 
Dr James Cummings, researchsupport at it.ox.ac.uk
Research Support, IT Services, University of Oxford

From lou.burnard at retired.ox.ac.uk  Fri Oct  5 15:37:13 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Fri, 05 Oct 2012 20:37:13 +0100
Subject: [tei-council] @style /rend/rendition coexistence
In-Reply-To: <BF61FB79-CB2A-4105-A652-4A7280B47019@it.ox.ac.uk>
References: <506F2216.3010703@retired.ox.ac.uk>
	<BF61FB79-CB2A-4105-A652-4A7280B47019@it.ox.ac.uk>
Message-ID: <506F36E9.60609@retired.ox.ac.uk>

On 05/10/12 19:46, Sebastian Rahtz wrote:
>
> On 5 Oct 2012, at 19:08, Lou Burnard <lou.burnard at retired.ox.ac.uk>
>   wrote:
>
>>
>> <foo style="something else" rend="wibble"> mean?
>>
>
> If I meet <hi style="font-weight:bold;" rend="italic">hello</hi>
> I guess I am just going to swallow nervously and generate
>    <span style="font-weight:bold; font-style:italic">hello</span>
> and
>   {\bfseries\itshape hello}
> etc

I think that's the start of a very very slippery slope

>
> but equally I dont mind being told that @rend wipes out @style/@rendition
> --

  "wipes out" in what sense? the attributes are all still there; it's up 
to your app what it does with them.

From sebastian.rahtz at it.ox.ac.uk  Fri Oct  5 15:45:39 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Fri, 5 Oct 2012 19:45:39 +0000
Subject: [tei-council] @style /rend/rendition coexistence
In-Reply-To: <506F36E9.60609@retired.ox.ac.uk>
References: <506F2216.3010703@retired.ox.ac.uk>
	<BF61FB79-CB2A-4105-A652-4A7280B47019@it.ox.ac.uk>
	<506F36E9.60609@retired.ox.ac.uk>
Message-ID: <68bdd4ac-8a16-451f-ba27-79766c8796c4@HUB02.ad.oak.ox.ac.uk>


On 5 Oct 2012, at 20:37, Lou Burnard <lou.burnard at retired.ox.ac.uk>
 wrote:

>> If I meet <hi style="font-weight:bold;" rend="italic">hello</hi>
>> I guess I am just going to swallow nervously and generate
>>   <span style="font-weight:bold; font-style:italic">hello</span>
>> and
>>  {\bfseries\itshape hello}
>> etc
> 
> I think that's the start of a very very slippery slope

not sure why?

> 
>> 
>> but equally I dont mind being told that @rend wipes out @style/@rendition
>> --
> 
> "wipes out" in what sense? the attributes are all still there; it's up to your app what it does with them.


ok, put it another way, @style and @rend are alternates. the encoder has kindly provided two different
ways of describing what the source looks like, you can read whichever you like (but not process both if you
are a stylesheet).


did we ever decide what <hi rend="nice" rendition="#lions">hello</hi> means?

oh what a tangled web we've woved for ourselves with this business. 
--
Sebastian Rahtz      
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431


From lou.burnard at retired.ox.ac.uk  Fri Oct  5 15:58:04 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Fri, 05 Oct 2012 20:58:04 +0100
Subject: [tei-council] @style /rend/rendition coexistence
In-Reply-To: <126FCE0E-B8A0-464B-8FD6-6A9157B017F9@it.ox.ac.uk>
References: <506F2216.3010703@retired.ox.ac.uk>
	<BF61FB79-CB2A-4105-A652-4A7280B47019@it.ox.ac.uk>
	<506F36E9.60609@retired.ox.ac.uk>
	<126FCE0E-B8A0-464B-8FD6-6A9157B017F9@it.ox.ac.uk>
Message-ID: <506F3BCC.90405@retired.ox.ac.uk>

On 05/10/12 20:45, Sebastian Rahtz wrote:
>
> On 5 Oct 2012, at 20:37, Lou Burnard <lou.burnard at retired.ox.ac.uk>
>   wrote:
>
>>> If I meet <hi style="font-weight:bold;" rend="italic">hello</hi>
>>> I guess I am just going to swallow nervously and generate
>>>    <span style="font-weight:bold; font-style:italic">hello</span>
>>> and
>>>   {\bfseries\itshape hello}
>>> etc
>>
>> I think that's the start of a very very slippery slope
>
> not sure why?

because you are mixing languages. it's ok to unify @rendition and @style 
values because they come from the same domain, but I dont think you can 
ever do that with @rend. Maybe my @rend="italic" means "uses a fair 
Italian hand"


>
>>
>>>
>>> but equally I dont mind being told that @rend wipes out @style/@rendition
>>> --
>>
>> "wipes out" in what sense? the attributes are all still there; it's up to your app what it does with them.
>
>
> ok, put it another way, @style and @rend are alternates. the encoder has kindly provided two different
> ways of describing what the source looks like, you can read whichever you like (but not process both if you
> are a stylesheet).

yes, i think I would agree with that. A stylesheet can of course do 
whatever it likes, but the idea that @rend is an ALTERNATIVE to the 
others makes good sense.

>
>
> did we ever decide what <hi rend="nice" rendition="#lions">hello</hi> means?
>

Well, if we agree on the above, it means that some aspects of the 
rendition of the source are "nice" and some others (possibly the same, 
but not necessarily) are described by whatever #lions is pointing to, 
possibly unified with whatever the default properties for <hi> are.


> oh what a tangled web we've woved for ourselves with this business.

I blame that J Walsh.



From mholmes at uvic.ca  Fri Oct  5 16:04:14 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Fri, 5 Oct 2012 13:04:14 -0700
Subject: [tei-council] @style
In-Reply-To: <E3395C5E-1499-402C-8279-4DC91E059B2F@it.ox.ac.uk>
References: <506F1BCE.4010102@retired.ox.ac.uk> <506F2250.2010705@uvic.ca>
	<E3395C5E-1499-402C-8279-4DC91E059B2F@it.ox.ac.uk>
Message-ID: <506F3D3E.4050204@uvic.ca>

On 12-10-05 11:32 AM, Sebastian Rahtz wrote:
>
> On 5 Oct 2012, at 19:09, Martin Holmes <mholmes at uvic.ca>
>   wrote:
>
>>
>> <rendition xml:id="saidBefore">content: '\2018';</rendition>
>> <rendition xml:id="saidAfter">content: '\2019';</rendition>
>>
> <rendiition xml:id="saidBefore" scope="before">content: '\2018';</rendition>
>
> this is what @scope was put in for.

I never knew that was there. Gawd.

Cheers,
Martin

> --
> Sebastian Rahtz
> Director (Research Support) of Academic IT Services
> University of Oxford IT Services
> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>
>

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From sebastian.rahtz at it.ox.ac.uk  Fri Oct  5 16:05:33 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Fri, 5 Oct 2012 20:05:33 +0000
Subject: [tei-council] @style
In-Reply-To: <506F3D3E.4050204@uvic.ca>
References: <506F1BCE.4010102@retired.ox.ac.uk> <506F2250.2010705@uvic.ca>
	<E3395C5E-1499-402C-8279-4DC91E059B2F@it.ox.ac.uk>
	<506F3D3E.4050204@uvic.ca>
Message-ID: <E00831A1-1CA3-4B75-A0AF-C005CF977842@it.ox.ac.uk>


On 5 Oct 2012, at 21:04, Martin Holmes <mholmes at uvic.ca>
 wrote:

>> 
>> this is what @scope was put in for.
> 
> I never knew that was there. Gawd.
> 

I require you to sacrifice an owl on my altar every week then.

--
Sebastian Rahtz      
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431


From mholmes at uvic.ca  Fri Oct  5 16:07:11 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Fri, 5 Oct 2012 13:07:11 -0700
Subject: [tei-council] @style /rend/rendition coexistence
In-Reply-To: <506F3122.30507@it.ox.ac.uk>
References: <506F2216.3010703@retired.ox.ac.uk>
	<e38c3e27-e5b7-42f7-8b0b-9026ffffe9a0@HUB01.ad.oak.ox.ac.uk>
	<506F3122.30507@it.ox.ac.uk>
Message-ID: <506F3DEF.3010909@uvic.ca>

 >    (If I was being extreme I might be tempted to argue we should
 > never have <hi style="font-weight:bold">...</hi> in born digital
 > documents because we shouldn't be marking 'highlighting' only
 > semantic instances of 'emphasis' or 'distinct' or similar for
 > which we have elements.)

Ah, but you have quotes in a born-digital document. When you're quoting, 
you can't always presume to discern why the original author bolded 
something.

Cheers,
Martin

On 12-10-05 12:12 PM, James Cummings wrote:
> On 05/10/12 19:46, Sebastian Rahtz wrote:
>> On 5 Oct 2012, at 19:08, Lou Burnard<lou.burnard at retired.ox.ac.uk>
>>    wrote:
>>> <foo style="something else" rend="wibble">  mean?
>> If I meet<hi style="font-weight:bold;" rend="italic">hello</hi>
>> I guess I am just going to swallow nervously and generate
>>     <span style="font-weight:bold; font-style:italic">hello</span> and
>>    {\bfseries\itshape hello}
>> etc
>> but equally I dont mind being told that @rend wipes out @style/@rendition
>
> I would argue against this. I can envision quite easily a project
> workflow where one person is adding @rend values from a
> constrained list because that is all they are capable and someone
> else is looking at _different_ features and adding @rendtion
> rules because they know XSL-FO in the same project.  Ok, the
> @rend values may be converted at a later point to @rendition for
> consistency but it should not be seen and wrong or bad practice
> to have both.
>
> But again, you are interpreting based on your need and fears of
> implementation in the stylesheet suite. (Which is good, laudable,
> and understandable.) But we can't let stylesheet implementation
> drive the definition of the documentation aspect of this. The
> user is documenting their interpretation of the original, not
> coding to a particular output. Or at least, they *shouldn't* be
> and one of my arguments against @style was that I feel it
> encourages this, especially in processing born digital documents.

>
> -James
>

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From sebastian.rahtz at it.ox.ac.uk  Fri Oct  5 16:07:47 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Fri, 5 Oct 2012 20:07:47 +0000
Subject: [tei-council] @style /rend/rendition coexistence
In-Reply-To: <506F3BCC.90405@retired.ox.ac.uk>
References: <506F2216.3010703@retired.ox.ac.uk>
	<BF61FB79-CB2A-4105-A652-4A7280B47019@it.ox.ac.uk>
	<506F36E9.60609@retired.ox.ac.uk>
	<126FCE0E-B8A0-464B-8FD6-6A9157B017F9@it.ox.ac.uk>
	<506F3BCC.90405@retired.ox.ac.uk>
Message-ID: <278343e2-ea0e-4e70-bae8-fc6717a3303a@HUB01.ad.oak.ox.ac.uk>


On 5 Oct 2012, at 20:58, Lou Burnard <lou.burnard at retired.ox.ac.uk>
 wrote:

>> 
>> not sure why?
> 
> because you are mixing languages. it's ok to unify @rendition and @style values because they come from the same domain, but I dont think you can ever do that with @rend. Maybe my @rend="italic" means "uses a fair Italian hand"
> 

yes, that assumes I have some way of working out what "italic" means, as now

>> ok, put it another way, @style and @rend are alternates. the encoder has kindly provided two different
>> ways of describing what the source looks like, you can read whichever you like (but not process both if you
>> are a stylesheet).
> 
> yes, i think I would agree with that. A stylesheet can of course do whatever it likes, but the idea that @rend is an ALTERNATIVE to the others makes good sense.
> 
so can we say, 

  * @style and @rendition are from a formal descriptive  language, and are cumulative
  * @rend is an alternate to @style/@rendition. if both exist, a processor can follow which it likes, depending on what its trying to do
  * if there is nothing on the element at all, you can look up tagsDecl/@render to see what the thing looked like


?

or are @style/@rendition building on tagsDecl/@render?

--
Sebastian Rahtz      
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431


From sebastian.rahtz at it.ox.ac.uk  Fri Oct  5 16:15:22 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Fri, 5 Oct 2012 20:15:22 +0000
Subject: [tei-council] I'm feeling radical about P5 distribution
Message-ID: <9D8F9C26-72D1-43B1-B469-A76EE15C1A3A@it.ox.ac.uk>

folks,

I am fed up with the division of the TEI into source, doc, schema, test, exemplars, and database.
I don't believe it's ever used meaningfully, and it is only exposed in the debian packages. I am 
being asked again by the Debian people to clean up our packages for inclusion in the core
Debian, and I'd like to make a clean start.

Waddya say we only have

  tei-source (includes old exemplars, database, source, test)
  tei-schema (compiled schemas for daily use, and templates)
  tei-doc (compiled documentation)

from now on?

--
Sebastian Rahtz      
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431


From lou.burnard at retired.ox.ac.uk  Fri Oct  5 16:15:37 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Fri, 05 Oct 2012 21:15:37 +0100
Subject: [tei-council] @style /rend/rendition coexistence
In-Reply-To: <F135FAB8-96B7-49D7-A9D4-C47229FD5FD2@it.ox.ac.uk>
References: <506F2216.3010703@retired.ox.ac.uk>
	<BF61FB79-CB2A-4105-A652-4A7280B47019@it.ox.ac.uk>
	<506F36E9.60609@retired.ox.ac.uk>
	<126FCE0E-B8A0-464B-8FD6-6A9157B017F9@it.ox.ac.uk>
	<506F3BCC.90405@retired.ox.ac.uk>
	<F135FAB8-96B7-49D7-A9D4-C47229FD5FD2@it.ox.ac.uk>
Message-ID: <506F3FE9.6060904@retired.ox.ac.uk>

On 05/10/12 21:07, Sebastian Rahtz wrote:
>    * @style and @rendition are from a formal descriptive  language, and are cumulative
>    * @rend is an alternate to @style/@rendition. if both exist, a processor can follow which it likes, depending on what its trying to do

Yes

>    * if there is nothing on the element at all, you can look up tagsDecl/@render to see what the thing looked like
>
>
> or are @style/@rendition building on tagsDecl/@render?
>

I had been assuming the latter. So in the worst case you might have

- @render telling you the font family
- @rendition telling you the size
- @style telling you some other property

Also, I believe the rule is that if the same property gets specified 
more than once, you are supposed to take the last one. so if @render 
says font family is bembo and @style says it is garamond, you believe 
the latter.


From mholmes at uvic.ca  Fri Oct  5 16:17:11 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Fri, 5 Oct 2012 13:17:11 -0700
Subject: [tei-council] @style /rend/rendition coexistence
In-Reply-To: <506F3BCC.90405@retired.ox.ac.uk>
References: <506F2216.3010703@retired.ox.ac.uk>
	<BF61FB79-CB2A-4105-A652-4A7280B47019@it.ox.ac.uk>
	<506F36E9.60609@retired.ox.ac.uk>
	<126FCE0E-B8A0-464B-8FD6-6A9157B017F9@it.ox.ac.uk>
	<506F3BCC.90405@retired.ox.ac.uk>
Message-ID: <506F4047.7000201@uvic.ca>

> the idea that @rend is an ALTERNATIVE to the
> others makes good sense.

What about my point that there may be things that are not expressible in 
your chosen style language, so you need to use @rend to add them?

Cheers,
Martin

On 12-10-05 12:58 PM, Lou Burnard wrote:
> On 05/10/12 20:45, Sebastian Rahtz wrote:
>>
>> On 5 Oct 2012, at 20:37, Lou Burnard <lou.burnard at retired.ox.ac.uk>
>>    wrote:
>>
>>>> If I meet <hi style="font-weight:bold;" rend="italic">hello</hi>
>>>> I guess I am just going to swallow nervously and generate
>>>>     <span style="font-weight:bold; font-style:italic">hello</span>
>>>> and
>>>>    {\bfseries\itshape hello}
>>>> etc
>>>
>>> I think that's the start of a very very slippery slope
>>
>> not sure why?
>
> because you are mixing languages. it's ok to unify @rendition and @style
> values because they come from the same domain, but I dont think you can
> ever do that with @rend. Maybe my @rend="italic" means "uses a fair
> Italian hand"
>
>
>>
>>>
>>>>
>>>> but equally I dont mind being told that @rend wipes out @style/@rendition
>>>> --
>>>
>>> "wipes out" in what sense? the attributes are all still there; it's up to your app what it does with them.
>>
>>
>> ok, put it another way, @style and @rend are alternates. the encoder has kindly provided two different
>> ways of describing what the source looks like, you can read whichever you like (but not process both if you
>> are a stylesheet).
>
> yes, i think I would agree with that. A stylesheet can of course do
> whatever it likes, but the idea that @rend is an ALTERNATIVE to the
> others makes good sense.
>
>>
>>
>> did we ever decide what <hi rend="nice" rendition="#lions">hello</hi> means?
>>
>
> Well, if we agree on the above, it means that some aspects of the
> rendition of the source are "nice" and some others (possibly the same,
> but not necessarily) are described by whatever #lions is pointing to,
> possibly unified with whatever the default properties for <hi> are.
>
>
>> oh what a tangled web we've woved for ourselves with this business.
>
> I blame that J Walsh.
>
>

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From mholmes at uvic.ca  Fri Oct  5 16:19:05 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Fri, 5 Oct 2012 13:19:05 -0700
Subject: [tei-council] I'm feeling radical about P5 distribution
In-Reply-To: <9D8F9C26-72D1-43B1-B469-A76EE15C1A3A@it.ox.ac.uk>
References: <9D8F9C26-72D1-43B1-B469-A76EE15C1A3A@it.ox.ac.uk>
Message-ID: <506F40B9.9030507@uvic.ca>

Where does stuff like Documents/Editing/Jenkins fit into this?

On 12-10-05 01:15 PM, Sebastian Rahtz wrote:
> folks,
>
> I am fed up with the division of the TEI into source, doc, schema, test, exemplars, and database.
> I don't believe it's ever used meaningfully, and it is only exposed in the debian packages. I am
> being asked again by the Debian people to clean up our packages for inclusion in the core
> Debian, and I'd like to make a clean start.
>
> Waddya say we only have
>
>    tei-source (includes old exemplars, database, source, test)
>    tei-schema (compiled schemas for daily use, and templates)
>    tei-doc (compiled documentation)
>
> from now on?
>
> --
> Sebastian Rahtz
> Director (Research Support) of Academic IT Services
> University of Oxford IT Services
> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From sebastian.rahtz at it.ox.ac.uk  Fri Oct  5 16:21:43 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Fri, 5 Oct 2012 20:21:43 +0000
Subject: [tei-council] I'm feeling radical about P5 distribution
In-Reply-To: <506F40B9.9030507@uvic.ca>
References: <9D8F9C26-72D1-43B1-B469-A76EE15C1A3A@it.ox.ac.uk>
	<506F40B9.9030507@uvic.ca>
Message-ID: <87BA8578-40A5-4C6E-A20D-4BFAF10F2218@it.ox.ac.uk>


On 5 Oct 2012, at 21:19, Martin Holmes <mholmes at uvic.ca>
 wrote:

> Where does stuff like Documents/Editing/Jenkins fit into this?
> 

not at all. its not part of our public distro. as is right, surely?

--
Sebastian Rahtz      
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431


From sebastian.rahtz at it.ox.ac.uk  Fri Oct  5 16:23:56 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Fri, 5 Oct 2012 20:23:56 +0000
Subject: [tei-council] @style /rend/rendition coexistence
In-Reply-To: <506F3FE9.6060904@retired.ox.ac.uk>
References: <506F2216.3010703@retired.ox.ac.uk>
	<BF61FB79-CB2A-4105-A652-4A7280B47019@it.ox.ac.uk>
	<506F36E9.60609@retired.ox.ac.uk>
	<126FCE0E-B8A0-464B-8FD6-6A9157B017F9@it.ox.ac.uk>
	<506F3BCC.90405@retired.ox.ac.uk>
	<F135FAB8-96B7-49D7-A9D4-C47229FD5FD2@it.ox.ac.uk>
	<506F3FE9.6060904@retired.ox.ac.uk>
Message-ID: <d21a73ae-19e7-47ec-886b-083745e9a4b6@HUB01.ad.oak.ox.ac.uk>


On 5 Oct 2012, at 21:15, Lou Burnard <lou.burnard at retired.ox.ac.uk>
 wrote:
> 
> I had been assuming the latter. So in the worst case you might have
> 
> - @render telling you the font family
> - @rendition telling you the size
> - @style telling you some other property
> 

I can live with that. this all assumes the formal languages are the same, of course.
I suppose tagsDecl/@render may point to groff code [1], and @style may be CSS.

[1] one of these days I'm going to implement groff output in my XSL
--
Sebastian Rahtz      
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431


From lou.burnard at retired.ox.ac.uk  Fri Oct  5 16:27:51 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Fri, 05 Oct 2012 21:27:51 +0100
Subject: [tei-council] @style /rend/rendition coexistence
In-Reply-To: <055BC51B-B430-4E02-91B7-5D7D4BF26524@it.ox.ac.uk>
References: <506F2216.3010703@retired.ox.ac.uk>
	<BF61FB79-CB2A-4105-A652-4A7280B47019@it.ox.ac.uk>
	<506F36E9.60609@retired.ox.ac.uk>
	<126FCE0E-B8A0-464B-8FD6-6A9157B017F9@it.ox.ac.uk>
	<506F3BCC.90405@retired.ox.ac.uk>
	<F135FAB8-96B7-49D7-A9D4-C47229FD5FD2@it.ox.ac.uk>
	<506F3FE9.6060904@retired.ox.ac.uk>
	<055BC51B-B430-4E02-91B7-5D7D4BF26524@it.ox.ac.uk>
Message-ID: <506F42C7.5030903@retired.ox.ac.uk>

On 05/10/12 21:23, Sebastian Rahtz wrote:
>
> On 5 Oct 2012, at 21:15, Lou Burnard <lou.burnard at retired.ox.ac.uk>
>   wrote:
>>
>> I had been assuming the latter. So in the worst case you might have
>>
>> - @render telling you the font family
>> - @rendition telling you the size
>> - @style telling you some other property
>>
>
> I can live with that. this all assumes the formal languages are the same, of course.

Yes indeed. I am coming round to the view that one should be 
Linguistically Pure


> I suppose tagsDecl/@render may point to groff code [1], and @style may be CSS.

In which case, I think we'd have to say you can't unify them, any more 
than you can unify @rend with @rendition.
>

This also makes me think that we might say that the language used by 
@style *must be* specified by @scheme on some <rendition>, even if you 
don't use <rendition> for any other purpose.


> [1] one of these days I'm going to implement groff output in my XSL
> --

i probably have some spitbol to do that somewhere




From kevin.s.hawkins at ultraslavonic.info  Fri Oct  5 16:39:16 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Fri, 05 Oct 2012 16:39:16 -0400
Subject: [tei-council] @style /rend/rendition coexistence
In-Reply-To: <506F3FE9.6060904@retired.ox.ac.uk>
References: <506F2216.3010703@retired.ox.ac.uk>	<BF61FB79-CB2A-4105-A652-4A7280B47019@it.ox.ac.uk>	<506F36E9.60609@retired.ox.ac.uk>	<126FCE0E-B8A0-464B-8FD6-6A9157B017F9@it.ox.ac.uk>	<506F3BCC.90405@retired.ox.ac.uk>	<F135FAB8-96B7-49D7-A9D4-C47229FD5FD2@it.ox.ac.uk>
	<506F3FE9.6060904@retired.ox.ac.uk>
Message-ID: <506F4574.3030507@ultraslavonic.info>

On 10/5/2012 4:15 PM, Lou Burnard wrote:
> Also, I believe the rule is that if the same property gets specified
> more than once, you are supposed to take the last one. so if @render
> says font family is bembo and @style says it is garamond, you believe
> the latter.

How do you define "the last one"?  Surely this doesn't have to do with 
the order in which the attributes are serialized in the XML?

From lou.burnard at retired.ox.ac.uk  Fri Oct  5 16:41:47 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Fri, 05 Oct 2012 21:41:47 +0100
Subject: [tei-council] @style /rend/rendition coexistence
In-Reply-To: <506F4574.3030507@ultraslavonic.info>
References: <506F2216.3010703@retired.ox.ac.uk>	<BF61FB79-CB2A-4105-A652-4A7280B47019@it.ox.ac.uk>	<506F36E9.60609@retired.ox.ac.uk>	<126FCE0E-B8A0-464B-8FD6-6A9157B017F9@it.ox.ac.uk>	<506F3BCC.90405@retired.ox.ac.uk>	<F135FAB8-96B7-49D7-A9D4-C47229FD5FD2@it.ox.ac.uk>
	<506F3FE9.6060904@retired.ox.ac.uk>
	<506F4574.3030507@ultraslavonic.info>
Message-ID: <506F460B.6050509@retired.ox.ac.uk>

On 05/10/12 21:39, Kevin Hawkins wrote:
> On 10/5/2012 4:15 PM, Lou Burnard wrote:
>> Also, I believe the rule is that if the same property gets specified
>> more than once, you are supposed to take the last one. so if @render
>> says font family is bembo and @style says it is garamond, you believe
>> the latter.
>
> How do you define "the last one"?  Surely this doesn't have to do with
> the order in which the attributes are serialized in the XML?
>

Sorry, no, I was unclear. I meant the last one in the list in my 
example, i.e. the one that is hierarchically nearest the element you're 
trying to figure out how it was rendered.

@style is first
@rendition is next
@render is last



From kevin.s.hawkins at ultraslavonic.info  Fri Oct  5 16:48:01 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Fri, 05 Oct 2012 16:48:01 -0400
Subject: [tei-council] @style /rend/rendition coexistence
In-Reply-To: <506F460B.6050509@retired.ox.ac.uk>
References: <506F2216.3010703@retired.ox.ac.uk>	<BF61FB79-CB2A-4105-A652-4A7280B47019@it.ox.ac.uk>	<506F36E9.60609@retired.ox.ac.uk>	<126FCE0E-B8A0-464B-8FD6-6A9157B017F9@it.ox.ac.uk>	<506F3BCC.90405@retired.ox.ac.uk>	<F135FAB8-96B7-49D7-A9D4-C47229FD5FD2@it.ox.ac.uk>	<506F3FE9.6060904@retired.ox.ac.uk>	<506F4574.3030507@ultraslavonic.info>
	<506F460B.6050509@retired.ox.ac.uk>
Message-ID: <506F4781.4020901@ultraslavonic.info>

On 10/5/2012 4:41 PM, Lou Burnard wrote:
> On 05/10/12 21:39, Kevin Hawkins wrote:
>> On 10/5/2012 4:15 PM, Lou Burnard wrote:
>>> Also, I believe the rule is that if the same property gets specified
>>> more than once, you are supposed to take the last one. so if @render
>>> says font family is bembo and @style says it is garamond, you believe
>>> the latter.
>>
>> How do you define "the last one"?  Surely this doesn't have to do with
>> the order in which the attributes are serialized in the XML?
>>
>
> Sorry, no, I was unclear. I meant the last one in the list in my
> example, i.e. the one that is hierarchically nearest the element you're
> trying to figure out how it was rendered.
>
> @style is first
> @rendition is next
> @render is last

Okay, you really did mean @render (on <tagsDecl>) -- this wasn't a typo 
auto-corrected from @rend as I assumed.

Since @render only appears on <tagsDecl>, it is farther in the XML 
hierarchy from @style or @rendition, used on an element in the body and 
should therefore be considered to be overridden (in the sense of a CSS 
inheritance) by @style and @rendition.

And if you have both @style and @rendition on the same element, the TEI 
document should be understood in a way that gives @style precedence over 
@rendition.  (Whether and how a processor handles this is another matter.)

Have I got all of that right?

K.

From sebastian.rahtz at it.ox.ac.uk  Fri Oct  5 17:06:03 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Fri, 5 Oct 2012 21:06:03 +0000
Subject: [tei-council] oxygen, schematron
In-Reply-To: <506F12E9.6050409@uvic.ca>
References: <B99C360E-B20C-43F4-9EA9-80BD268A5714@it.ox.ac.uk>
	<69992D4E-9E73-4DE9-BD67-F13693506BAB@it.ox.ac.uk>
	<506F12E9.6050409@uvic.ca>
Message-ID: <0256CC17-8CDF-46B0-AE9E-E74ECEBCFF33@it.ox.ac.uk>


On 5 Oct 2012, at 18:03, Martin Holmes <mholmes at uvic.ca>
 wrote:

> I think perhaps we should be explicit in calling the templates directory 
> "Oxygen-Templates". It would be easier for the likes of me to figure 
> out, a year from now, where that Oxygen-related stuff is coming from. It 
> would also help regular users who might want to grab the 
> latest-and-greatest templates from SVN and put them into their Oxygen 
> directory.



I have put a load of files in Exemplates called *.template, which are
waiting to be put into oXYgen, by processing with template.xsl

I am now coming round to the idea of just using file suffixes
to distinguish function, so that when you examine e.g. tei_speech,
you see all the related files.
--
Sebastian Rahtz      
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431


From mholmes at uvic.ca  Fri Oct  5 17:31:17 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Fri, 5 Oct 2012 14:31:17 -0700
Subject: [tei-council] oxygen, schematron
In-Reply-To: <0256CC17-8CDF-46B0-AE9E-E74ECEBCFF33@it.ox.ac.uk>
References: <B99C360E-B20C-43F4-9EA9-80BD268A5714@it.ox.ac.uk>
	<69992D4E-9E73-4DE9-BD67-F13693506BAB@it.ox.ac.uk>
	<506F12E9.6050409@uvic.ca>
	<0256CC17-8CDF-46B0-AE9E-E74ECEBCFF33@it.ox.ac.uk>
Message-ID: <506F51A5.2030000@uvic.ca>

I must admit I don't really understand where this is going, and it's 
going a bit fast for me to know whether I think it's a good idea or not, 
so one thing I will do is to document it for myself when it's all over, 
and add it to one of the TCWs. I never understood the original directory 
structure anyway, so I'm sure this is going to be an improvement.

Are we going to be requiring Oxygen users to process a bunch of files 
through XSLT to get latest templates for use in Oxygen, though? That 
seems a bit harsh.

Cheers,
Martin

On 12-10-05 02:06 PM, Sebastian Rahtz wrote:
>
> On 5 Oct 2012, at 18:03, Martin Holmes <mholmes at uvic.ca>
>   wrote:
>
>> I think perhaps we should be explicit in calling the templates directory
>> "Oxygen-Templates". It would be easier for the likes of me to figure
>> out, a year from now, where that Oxygen-related stuff is coming from. It
>> would also help regular users who might want to grab the
>> latest-and-greatest templates from SVN and put them into their Oxygen
>> directory.
>
>
>
> I have put a load of files in Exemplates called *.template, which are
> waiting to be put into oXYgen, by processing with template.xsl
>
> I am now coming round to the idea of just using file suffixes
> to distinguish function, so that when you examine e.g. tei_speech,
> you see all the related files.
> --
> Sebastian Rahtz
> Director (Research Support) of Academic IT Services
> University of Oxford IT Services
> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>
>

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From sebastian.rahtz at it.ox.ac.uk  Fri Oct  5 17:35:51 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Fri, 5 Oct 2012 21:35:51 +0000
Subject: [tei-council] oxygen, schematron
In-Reply-To: <506F51A5.2030000@uvic.ca>
References: <B99C360E-B20C-43F4-9EA9-80BD268A5714@it.ox.ac.uk>
	<69992D4E-9E73-4DE9-BD67-F13693506BAB@it.ox.ac.uk>
	<506F12E9.6050409@uvic.ca>
	<0256CC17-8CDF-46B0-AE9E-E74ECEBCFF33@it.ox.ac.uk>,
	<506F51A5.2030000@uvic.ca>
Message-ID: <7AED11A2-38FE-4F5A-BFA2-3C35CC62C41D@oucs.ox.ac.uk>


> 
> 
> Are we going to be requiring Oxygen users to process a bunch of files 
> through XSLT to get latest templates for use in Oxygen, though? That 
> seems a bit harsh.

No. I will extend the tei-oxygen processing to do this, and put the templates in place where needed. Users won't see any difference at all, just that we will be more on control

It's simpler than you think...

S

From mholmes at uvic.ca  Fri Oct  5 17:37:01 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Fri, 5 Oct 2012 14:37:01 -0700
Subject: [tei-council] oxygen, schematron
In-Reply-To: <7AED11A2-38FE-4F5A-BFA2-3C35CC62C41D@oucs.ox.ac.uk>
References: <B99C360E-B20C-43F4-9EA9-80BD268A5714@it.ox.ac.uk>
	<69992D4E-9E73-4DE9-BD67-F13693506BAB@it.ox.ac.uk>
	<506F12E9.6050409@uvic.ca>
	<0256CC17-8CDF-46B0-AE9E-E74ECEBCFF33@it.ox.ac.uk>,
	<506F51A5.2030000@uvic.ca>
	<7AED11A2-38FE-4F5A-BFA2-3C35CC62C41D@oucs.ox.ac.uk>
Message-ID: <506F52FD.1030407@uvic.ca>

Could you lay out the new structure, and what each directory will contain?

Cheers,
Martin

On 12-10-05 02:35 PM, Sebastian Rahtz wrote:
>
>>
>>
>> Are we going to be requiring Oxygen users to process a bunch of files
>> through XSLT to get latest templates for use in Oxygen, though? That
>> seems a bit harsh.
>
> No. I will extend the tei-oxygen processing to do this, and put the templates in place where needed. Users won't see any difference at all, just that we will be more on control
>
> It's simpler than you think...
>
> S
>

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From sebastian.rahtz at it.ox.ac.uk  Fri Oct  5 17:50:10 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Fri, 5 Oct 2012 21:50:10 +0000
Subject: [tei-council] oxygen, schematron
In-Reply-To: <506F52FD.1030407@uvic.ca>
References: <B99C360E-B20C-43F4-9EA9-80BD268A5714@it.ox.ac.uk>
	<69992D4E-9E73-4DE9-BD67-F13693506BAB@it.ox.ac.uk>
	<506F12E9.6050409@uvic.ca>
	<0256CC17-8CDF-46B0-AE9E-E74ECEBCFF33@it.ox.ac.uk>,
	<506F51A5.2030000@uvic.ca>
	<7AED11A2-38FE-4F5A-BFA2-3C35CC62C41D@oucs.ox.ac.uk>,
	<506F52FD.1030407@uvic.ca>
Message-ID: <56520ec3-a348-4272-95bc-3dbde3261dbf@HUB02.ad.oak.ox.ac.uk>

I am coming round to the idea of no changes, simply having for each tei_nnn.odd a corresponding .template file which will be made available in oxygen, linked to the right schema + schematron. Each nnn will be exposed in Roma as an odd. I need to automate that too.

Carved in stone on my iPad

On 5 Oct 2012, at 22:37, "Martin Holmes" <mholmes at uvic.ca> wrote:

> Could you lay out the new structure, and what each directory will contain?
> 
> Cheers,
> Martin
> 
> 

From lou.burnard at retired.ox.ac.uk  Sat Oct  6 11:08:09 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Sat, 06 Oct 2012 16:08:09 +0100
Subject: [tei-council] style lang definition
In-Reply-To: <506F2874.5070104@uvic.ca>
References: <506F2216.3010703@retired.ox.ac.uk> <506F2874.5070104@uvic.ca>
Message-ID: <50704959.5030001@retired.ox.ac.uk>

On 05/10/12 19:35, Martin Holmes wrote:

>   > -- Where do we specify the language in which @style values are
> expressed ?
>
> There has to be an element in the header, presumably in <tagsDecl>.
> Something like this:
>
> <style scheme="css"></style>
>
> although I'm not sure we want to go with the same potential confusion as
> we've already got with <rendition> vs @rendition.

This would be OK, except that we already have <rendition scheme="css"> 
inside <tagsDecl> which would give us two ways of doing the same thing. 
I am proposing to just use the existing mechanism, which means that we 
will need to require that if @style is used anywhere there must be (at 
least) one <rendition> with a @scheme attribute in the header. Unless we 
want to say "if all else fails it's got to be in CSS".

I checked in a bunch of changes to CO and ST yesterday as part of this 
fix, so  if you want to see how the revision is going, visit (for 
example) 
http://tei.svn.sourceforge.net/viewvc/tei/trunk/P5/Source/Guidelines/en/CO-CoreElements.xml?r1=10912&r2=10924



From lou.burnard at retired.ox.ac.uk  Sat Oct  6 11:58:33 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Sat, 06 Oct 2012 16:58:33 +0100
Subject: [tei-council] Fwd:  style lang definition
In-Reply-To: <50704959.5030001@retired.ox.ac.uk>
References: <50704959.5030001@retired.ox.ac.uk>
Message-ID: <50705529.3010905@retired.ox.ac.uk>

Apologies, I had forgotten that the minutes of the Oxford meeting quite 
clearly (if elliptically) provide a better solution to this problem.

* A new element, which will be declarable, to specify the style language 
will also be created after discussion on council list.

* @scheme on <rendition> should be moved into its own class, so that the 
new element can have it.

So here's for the "discussion on council list"

I am proposing to create a new element <styleDefDecl> to specify the 
default formal language used to express rendition, and also a new 
attribute class att.styleDef. This class will supply unchanged the 
attribute @source, currently locally defined on <rendition>. The new 
element will be a member of model.encodingPart, so it will occur, 
possibly multiple times, within <encodingDesc> It will also be a member 
of att.declarable, so you can use one language in one chunk of a 
language and another in another. Nevertheless, I would like to  add some 
prose to the effect that using more than one lang in a given document is 
Not A Good Idea, since it makes the combination of rendition information 
(already possible factored across three different places) needlessly 
complicated.

Does this sound plausible?

And is there any support for my suggestion that in the absence of a 
<styleDefDecl> we assume @style values (and <rendition> contents) are in 
CSS?




-------- Original Message --------
Subject: [tei-council] style lang definition
Date: Sat, 6 Oct 2012 16:08:09 +0100
From: Lou Burnard <lou.burnard at retired.ox.ac.uk>
To: <tei-council at lists.village.Virginia.EDU>

On 05/10/12 19:35, Martin Holmes wrote:

>   > -- Where do we specify the language in which @style values are
> expressed ?
>
> There has to be an element in the header, presumably in <tagsDecl>.
> Something like this:
>
> <style scheme="css"></style>
>
> although I'm not sure we want to go with the same potential confusion as
> we've already got with <rendition> vs @rendition.

This would be OK, except that we already have <rendition scheme="css">
inside <tagsDecl> which would give us two ways of doing the same thing.
I am proposing to just use the existing mechanism, which means that we
will need to require that if @style is used anywhere there must be (at
least) one <rendition> with a @scheme attribute in the header. Unless we
want to say "if all else fails it's got to be in CSS".

I checked in a bunch of changes to CO and ST yesterday as part of this
fix, so  if you want to see how the revision is going, visit (for
example)
http://tei.svn.sourceforge.net/viewvc/tei/trunk/P5/Source/Guidelines/en/CO-CoreElements.xml?r1=10912&r2=10924


-- 
tei-council mailing list
tei-council at lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

PLEASE NOTE: postings to this list are publicly archived



From mholmes at uvic.ca  Sat Oct  6 12:37:50 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Sat, 06 Oct 2012 09:37:50 -0700
Subject: [tei-council] Fwd:  style lang definition
In-Reply-To: <50705529.3010905@retired.ox.ac.uk>
References: <50704959.5030001@retired.ox.ac.uk>
	<50705529.3010905@retired.ox.ac.uk>
Message-ID: <50705E5E.8090801@uvic.ca>

Yes to both of these. I don't think there is a serious alternative to 
CSS anywhere. XSL:FO is a different kind of thing entirely, and in any 
case it uses CSS to express typographical styles; I don't really see how 
it could be used as a style description language in the context of a TEI 
element. DSSSL is obsolete and I really don't know of anything else.

Cheers,
Martin

On 12-10-06 08:58 AM, Lou Burnard wrote:
> Apologies, I had forgotten that the minutes of the Oxford meeting quite
> clearly (if elliptically) provide a better solution to this problem.
>
> * A new element, which will be declarable, to specify the style language
> will also be created after discussion on council list.
>
> * @scheme on <rendition> should be moved into its own class, so that the
> new element can have it.
>
> So here's for the "discussion on council list"
>
> I am proposing to create a new element <styleDefDecl> to specify the
> default formal language used to express rendition, and also a new
> attribute class att.styleDef. This class will supply unchanged the
> attribute @source, currently locally defined on <rendition>. The new
> element will be a member of model.encodingPart, so it will occur,
> possibly multiple times, within <encodingDesc> It will also be a member
> of att.declarable, so you can use one language in one chunk of a
> language and another in another. Nevertheless, I would like to  add some
> prose to the effect that using more than one lang in a given document is
> Not A Good Idea, since it makes the combination of rendition information
> (already possible factored across three different places) needlessly
> complicated.
>
> Does this sound plausible?
>
> And is there any support for my suggestion that in the absence of a
> <styleDefDecl> we assume @style values (and <rendition> contents) are in
> CSS?
>
>
>
>
> -------- Original Message --------
> Subject: [tei-council] style lang definition
> Date: Sat, 6 Oct 2012 16:08:09 +0100
> From: Lou Burnard <lou.burnard at retired.ox.ac.uk>
> To: <tei-council at lists.village.Virginia.EDU>
>
> On 05/10/12 19:35, Martin Holmes wrote:
>
>>    > -- Where do we specify the language in which @style values are
>> expressed ?
>>
>> There has to be an element in the header, presumably in <tagsDecl>.
>> Something like this:
>>
>> <style scheme="css"></style>
>>
>> although I'm not sure we want to go with the same potential confusion as
>> we've already got with <rendition> vs @rendition.
>
> This would be OK, except that we already have <rendition scheme="css">
> inside <tagsDecl> which would give us two ways of doing the same thing.
> I am proposing to just use the existing mechanism, which means that we
> will need to require that if @style is used anywhere there must be (at
> least) one <rendition> with a @scheme attribute in the header. Unless we
> want to say "if all else fails it's got to be in CSS".
>
> I checked in a bunch of changes to CO and ST yesterday as part of this
> fix, so  if you want to see how the revision is going, visit (for
> example)
> http://tei.svn.sourceforge.net/viewvc/tei/trunk/P5/Source/Guidelines/en/CO-CoreElements.xml?r1=10912&r2=10924
>
>

-- 
Martin Holmes
mholmes at uvic.ca
UVic Humanities Computing and Media Centre

From kevin.s.hawkins at ultraslavonic.info  Sat Oct  6 12:38:36 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Sat, 06 Oct 2012 12:38:36 -0400
Subject: [tei-council] Fwd:  style lang definition
In-Reply-To: <50705529.3010905@retired.ox.ac.uk>
References: <50704959.5030001@retired.ox.ac.uk>
	<50705529.3010905@retired.ox.ac.uk>
Message-ID: <50705E8C.4060103@ultraslavonic.info>

On 10/6/12 11:58 AM, Lou Burnard wrote:
> Nevertheless, I would like to  add some
> prose to the effect that using more than one lang in a given document is
> Not A Good Idea, since it makes the combination of rendition information
> (already possible factored across three different places) needlessly
> complicated.

I agree that we should have a statement to this effect in the 
Guidelines.  But we should also be precise, as James keeps reminding us. 
  Specifically, we should say that you should use only one (or as a few 
as possible) syntaxes for describing rendering in the source document so 
that processing the TEI document, such as for rendering of the digital 
text, is not needlessly complicated.

> And is there any support for my suggestion that in the absence of a
> <styleDefDecl> we assume @style values (and <rendition> contents) are in
> CSS?

I'm not sure that we want to say that if @rendition is used and yet the 
<rendition> element is empty (or entirely missing), you should assume 
that CSS is used.  Might this cause backwards compatibility for people 
with previosly encoded P5 documents?  If this isn't a concern and we 
decide to do this, I think we want scheme="css" to be the default value 
(which it currently is not).

As for assuming values of @style use CSS if there's no <styleDefDecl>, I 
think we need to specify which version of CSS to assume.  But I'm not 
sure which version to suggest.

--Kevin

From lou.burnard at retired.ox.ac.uk  Sat Oct  6 12:46:04 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Sat, 06 Oct 2012 17:46:04 +0100
Subject: [tei-council] Fwd:  style lang definition
In-Reply-To: <50705E8C.4060103@ultraslavonic.info>
References: <50704959.5030001@retired.ox.ac.uk>
	<50705529.3010905@retired.ox.ac.uk>
	<50705E8C.4060103@ultraslavonic.info>
Message-ID: <5070604C.6060100@retired.ox.ac.uk>

On 06/10/12 17:38, Kevin Hawkins wrote:

>> And is there any support for my suggestion that in the absence of a
>> <styleDefDecl> we assume @style values (and <rendition> contents) are in
>> CSS?
>
> I'm not sure that we want to say that if @rendition is used and yet the
> <rendition> element is empty (or entirely missing), you should assume
> that CSS is used.

You can't use @rendition without supplying a <rendition>. The problem is 
with @style.

> Might this cause backwards compatibility for people
> with previosly encoded P5 documents?  If this isn't a concern and we
> decide to do this, I think we want scheme="css" to be the default value
> (which it currently is not).

Yes, I am proposing to change this : you can say explicitly on 
<styleDefDecl> what the default is, so you won't need to supply @source 
on all your <rendition>s (but there's no back-compat problem if you do, 
since the values for the attribute aren't changing)

>
> As for assuming values of @style use CSS if there's no <styleDefDecl>, I
> think we need to specify which version of CSS to assume.  But I'm not
> sure which version to suggest.

Me neither... you can do this in the content of the <styleDefDecl> though



From kevin.s.hawkins at ultraslavonic.info  Sat Oct  6 13:03:33 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Sat, 06 Oct 2012 13:03:33 -0400
Subject: [tei-council] Fwd:  style lang definition
In-Reply-To: <5070604C.6060100@retired.ox.ac.uk>
References: <50704959.5030001@retired.ox.ac.uk>
	<50705529.3010905@retired.ox.ac.uk>
	<50705E8C.4060103@ultraslavonic.info>
	<5070604C.6060100@retired.ox.ac.uk>
Message-ID: <50706465.2070206@ultraslavonic.info>

On 10/6/12 12:46 PM, Lou Burnard wrote:
>> As for assuming values of @style use CSS if there's no <styleDefDecl>, I
>> think we need to specify which version of CSS to assume.  But I'm not
>> sure which version to suggest.
>
> Me neither... you can do this in the content of the <styleDefDecl> though

I understand that a user might specify a version of CSS in 
<styleDefDecl>, but the question is at hand is whether to specify in P5 
that CSS is implied when there's no <styleDefDecl> and, if so, which 
version.

From lou.burnard at retired.ox.ac.uk  Sat Oct  6 14:37:54 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Sat, 06 Oct 2012 19:37:54 +0100
Subject: [tei-council] 3519866... are we nearly there yet?
In-Reply-To: <50705E8C.4060103@ultraslavonic.info>
References: <50704959.5030001@retired.ox.ac.uk>
	<50705529.3010905@retired.ox.ac.uk>
	<50705E8C.4060103@ultraslavonic.info>
Message-ID: <50707A82.6000105@retired.ox.ac.uk>

Thanks for helpful comments, and on a saturday night too...

I've now checked in my best shot at implementing this pesky ticket. 
Please propose clarifications and better examples, or identify lacunas.

  http://tei.svn.sourceforge.net/tei/?rev=10930&view=rev

Or, when Mr Jenkins has finished, you can look in his bleeding edge HTML 
directory for the following revised sections:
  ST (revised 1.3.1.1.3)
  CO (revised 3.3.1)
  HD (revised 2.3.4)



From sebastian.rahtz at gmail.com  Sat Oct  6 17:55:53 2012
From: sebastian.rahtz at gmail.com (Sebastian Rahtz)
Date: Sat, 6 Oct 2012 22:55:53 +0100
Subject: [tei-council] P5 templates
Message-ID: <F3FD9EAE-CBAD-48F9-9DF1-5D8666A859C0@gmail.com>

I have now set up the Exemplars so that every setup has 3 files
   .odd. The customization which appears in Roma
   .tei.    A test file for the customization
   .template a document template. From this a .xml file is generated which will appear in oxygen, with schemas attached.

Result: compatibility between Roma and oxygen, same suite to appear in both places.

Work remaining to do is change Roma to pick up the last at build time from current p5.

Apologies for breaking things along the way. And yes you may congratulate me on finally making the kindle version version of the guidelines valid, hence making p5 valid after a long gap.

Just back from seeing Liberal Arts film. Golly them guys are so far off digital humanities.
Make sure you don see it, Lou, it may bring on a coronary.

Carved in stone on my iPad

From kevin.s.hawkins at ultraslavonic.info  Sat Oct  6 18:16:17 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Sat, 06 Oct 2012 18:16:17 -0400
Subject: [tei-council] 3519866... are we nearly there yet?
In-Reply-To: <50707A82.6000105@retired.ox.ac.uk>
References: <50704959.5030001@retired.ox.ac.uk>
	<50705529.3010905@retired.ox.ac.uk>
	<50705E8C.4060103@ultraslavonic.info>
	<50707A82.6000105@retired.ox.ac.uk>
Message-ID: <5070ADB1.8040103@ultraslavonic.info>

On 10/6/12 2:37 PM, Lou Burnard wrote:
> Thanks for helpful comments, and on a saturday night too...
>
> I've now checked in my best shot at implementing this pesky ticket.
> Please propose clarifications and better examples, or identify lacunas.
>
>    http://tei.svn.sourceforge.net/tei/?rev=10930&view=rev

See also http://tei.svn.sourceforge.net/tei/?rev=10924&view=rev as 
mentioned yesterday.

> Or, when Mr Jenkins has finished, you can look in his bleeding edge HTML
> directory for the following revised sections:
>    ST (revised 1.3.1.1.3)

Looking at 
http://teijenkins.hcmc.uvic.ca:8080/job/TEIP5-Documentation/lastSuccessfulBuild/artifact/Guidelines-web/en/html/ST.html#STGAre 
...

Your CSS is invalid.  Instead of

text-style:italic

it is

font-style:italic

However, I would actually use

font-style: italic

here (with the space) because you go on to imply that @style, unlike 
@rend, doesn't use space characters to separate tokens.

I think it would be good to avoid the phrase "unconstrained tokens" 
since this is opaque to most readers.  I think you're going to need to 
explain that @rend may contain one or more tokens from any vocabulary 
devised by the encoder, each separated by space characters.  And instead 
of implying that @style doesn't use space to divide tokens, I would say 
it explicitly.

>    CO (revised 3.3.1)

(See 
http://teijenkins.hcmc.uvic.ca:8080/job/TEIP5-Documentation/lastSuccessfulBuild/artifact/Guidelines-web/en/html/CO.html#COHQW 
.  Looks fine to me.)

>    HD (revised 2.3.4)

Looking at 
http://teijenkins.hcmc.uvic.ca:8080/job/TEIP5-Documentation/lastSuccessfulBuild/artifact/Guidelines-web/en/html/HD.html#HD57 
...

First of all, mention of <styleDefDecl> should also go in the list of 
children of <encodingDesc> at the beginning of section 2.3.

In 2.3.4.1, I would change

or either of the existing standard languages:

to

or any standard language such as

Next, where you first mention <styleDefDecl> in 2.3.4.1, I would say 
that it is a child of <encodingDesc> since it's not clear where to find 
this element, which hasn't been mentioned recently.

It seems to me that 2.3.4.2 (about <styleDefDecl>) should not be under 
2.3.4 (about <tagsDecl>) since it is not a child of that element. 
Instead, it should be a child of 2.3.  Not sure what order to put it in: 
it depends on where in the list at the beginning of section 2.3 you 
insert it.

In the section currently numbered 2.3.4.2, you say "whichever default 
style definition language is in force for the context in which it 
appears".  Are you referring to the numbered list (1 to 3) of what's 
applicable appearing in section 1.3.1.1.3?  If so, please 
cross-reference it.

Finally, in the current 2.3.4.2, I don't care for "That context may be 
varied".  Maybe "The default style language in force may be overridden"? 
  And drop "in the usual way" later in the sentence: it's unnecessary.

--K.

From lou.burnard at retired.ox.ac.uk  Sat Oct  6 19:04:01 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Sun, 07 Oct 2012 00:04:01 +0100
Subject: [tei-council] 3519866... are we nearly there yet?
In-Reply-To: <5070ADB1.8040103@ultraslavonic.info>
References: <50704959.5030001@retired.ox.ac.uk>
	<50705529.3010905@retired.ox.ac.uk>
	<50705E8C.4060103@ultraslavonic.info>
	<50707A82.6000105@retired.ox.ac.uk>
	<5070ADB1.8040103@ultraslavonic.info>
Message-ID: <5070B8E1.20104@retired.ox.ac.uk>

Many thanks for the quick feedback.


On 06/10/12 23:16, Kevin Hawkins wrote:

>
> Your CSS is invalid.  Instead of
>
> text-style:italic
>
> it is
>
> font-style:italic

Oh yes, of course. Fixed passim and seriatim
>
> However, I would actually use
>
> font-style: italic
>
> here (with the space) because you go on to imply that @style, unlike
> @rend, doesn't use space characters to separate tokens.
>
> I think it would be good to avoid the phrase "unconstrained tokens"
> since this is opaque to most readers.  I think you're going to need to
> explain that @rend may contain one or more tokens from any vocabulary
> devised by the encoder, each separated by space characters.  And instead
> of implying that @style doesn't use space to divide tokens, I would say
> it explicitly.


Reworded a bit to bring out this distinction more clearly.


> First of all, mention of <styleDefDecl> should also go in the list of
> children of <encodingDesc> at the beginning of section 2.3.

True. Fixed.

>
> In 2.3.4.1, I would change
>
> or either of the existing standard languages:
>
> to
>
> or any standard language such as

Except that we can't think of any other language. However, I have 
adopted your suggestion.

>
> Next, where you first mention <styleDefDecl> in 2.3.4.1, I would say
> that it is a child of <encodingDesc> since it's not clear where to find
> this element, which hasn't been mentioned recently.
>
> It seems to me that 2.3.4.2 (about <styleDefDecl>) should not be under
> 2.3.4 (about <tagsDecl>) since it is not a child of that element.
> Instead, it should be a child of 2.3.  Not sure what order to put it in:
> it depends on where in the list at the beginning of section 2.3 you
> insert it.

Yes, you're right. I hesitated quite a long time about where to put it, 
but have now I think moved it to the right place.


>
> In the section currently numbered 2.3.4.2, you say "whichever default
> style definition language is in force for the context in which it
> appears".  Are you referring to the numbered list (1 to 3) of what's
> applicable appearing in section 1.3.1.1.3?  If so, please
> cross-reference it.

No I didn't meant that at all. Have reworded as follows:

"<p>When the <att>style</att> attribute is used, its value must always
be expressed using whichever default style definition language is in
force. If more than one occurrence of the <gi>styleDefDecl</gi> is
provided, there will be more than one default available, and the
<att>decls</att> attribute must be used to select which is applicable
in a given context, as discussed in section <ptr
target="#CCAS"/>. </p>"

Hope this is less misleading.

Please take your time to produce the next tranch of corrections! I'm 
going to bed now.



From mholmes at uvic.ca  Sun Oct  7 14:03:21 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Sun, 7 Oct 2012 11:03:21 -0700
Subject: [tei-council] TEI Media Type
Message-ID: <5071C3E9.6060308@uvic.ca>

Hi all,

One of my actions from Oxford was to draft a short section encouraging 
the use of the TEI media type when serving TEI files:

http://purl.org/tei/fr/3565152

I've added a short draft to the ticket. Any objections or changes, 
before I implement?

Cheers,
Martin

From mholmes at uvic.ca  Sun Oct  7 20:39:42 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Sun, 7 Oct 2012 17:39:42 -0700
Subject: [tei-council] TEI Media Type
In-Reply-To: <4frod8n5px7rou9rtohq71e5.1349637007898@email.android.com>
References: <5071C3E9.6060308@uvic.ca>
	<4frod8n5px7rou9rtohq71e5.1349637007898@email.android.com>
Message-ID: <507220CE.8060807@uvic.ca>

On 12-10-07 12:11 PM, James Cummings wrote:
>
> Does the IANA really say "interchange" like that? Sigh.

Sigh indeed. We really should get this changed. I'll raise a bug, and 
assign it to Laurent.

That aside, are you OK with it?

Cheers,
Martin

>
> JamesC
> --
> James Cummings, Research Support, IT Services, University of Oxford (from phone)
>
> Martin Holmes <mholmes at uvic.ca> wrote:
>
>
> Hi all,
>
> One of my actions from Oxford was to draft a short section encouraging
> the use of the TEI media type when serving TEI files:
>
> http://purl.org/tei/fr/3565152
>
> I've added a short draft to the ticket. Any objections or changes,
> before I implement?
>
> Cheers,
> Martin
> --
> tei-council mailing list
> tei-council at lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>
> PLEASE NOTE: postings to this list are publicly archived
>

From gabriel.bodard at kcl.ac.uk  Mon Oct  8 07:15:53 2012
From: gabriel.bodard at kcl.ac.uk (Gabriel Bodard)
Date: Mon, 8 Oct 2012 12:15:53 +0100
Subject: [tei-council] moduleRef/@except != elementSpec[@mode=delete]
Message-ID: <5072B5E9.9080101@kcl.ac.uk>

This is arcane and probably not very interesting, but a bit confusing to me:

I recently decided to change the EpiDoc ODD from listing almost 100 
elementSpecs with mode=delete at the end of the schemaSpec, to listing 
these elements in the @except attribute on the relevant moduleRefs, on 
the assumption that the resulting schema would be functionally (if not 
byte-level) identical.

To my slight surprise, although the schema still seems to validate all 
of the files that it did before, there are a huge number of changes to 
the RNG code, that I thought I'd better check here are both expected and 
harmless. In about 80% of cases where the RNG contained an element:

<define name="tei_model.msQuoteLike">
immediately followed by:
<define name="tei_model.msQuoteLike_alternation">

the tei_model.*_alternation is missing from the new schema.

As I say, this hasn't made my schema stop working, but I don't know if 
this is just because I never used any of these "alternation" features 
that were there before. Is this something Sebastian needs to worry 
about, or is it all expected and benign? (And if the latter, could 
someone explain to me what is the expected functional difference between 
using @except and @mode=delete?

Thanks,

Gabby

-- 
Dr Gabriel BODARD
Researcher in Digital Epigraphy

Digital Humanities
King's College London
26-29 Drury Lane
London WC2B 5RL

T: +44 (0)20 7848 1388
F: +44 (0)20 7848 2980
E: gabriel.bodard at kcl.ac.uk

http://www.digitalclassicist.org/
http://www.currentepigraphy.org/


From sebastian.rahtz at it.ox.ac.uk  Mon Oct  8 14:47:06 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Mon, 8 Oct 2012 18:47:06 +0000
Subject: [tei-council] moduleRef/@except != elementSpec[@mode=delete]
In-Reply-To: <5072B5E9.9080101@kcl.ac.uk>
References: <5072B5E9.9080101@kcl.ac.uk>
Message-ID: <106F33BF-A111-4A37-B453-CA2216455A3A@it.ox.ac.uk>

the XSL which generates the schemas has also changed, remember; that would
explain the alternation models changing

can you compare schemas generated from new ODD and old ODD  on the same day?
--
Sebastian Rahtz      
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431


From sebastian.rahtz at it.ox.ac.uk  Tue Oct  9 04:43:42 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Tue, 9 Oct 2012 08:43:42 +0000
Subject: [tei-council] moduleRef/@except != elementSpec[@mode=delete]
In-Reply-To: <5072B5E9.9080101@kcl.ac.uk>
References: <5072B5E9.9080101@kcl.ac.uk>
Message-ID: <2232DCB3-F566-40A7-B2B3-E990D4660B71@it.ox.ac.uk>

to expand further

  a) xxx mode="delete" and except="xxx" should be functionally identically. if they are not, its an error
  b) i have made several attempts to generate leaner schemas. so I tend to delete patterns (like "tei_model.msQuoteLike_alternation")
which are not referenced anywhere. I suspect you are seeing the results of this austerity regime
--
Sebastian Rahtz      
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431


From gabriel.bodard at kcl.ac.uk  Tue Oct  9 09:24:29 2012
From: gabriel.bodard at kcl.ac.uk (Gabriel Bodard)
Date: Tue, 9 Oct 2012 14:24:29 +0100
Subject: [tei-council] moduleRef/@except != elementSpec[@mode=delete]
In-Reply-To: <2232DCB3-F566-40A7-B2B3-E990D4660B71@it.ox.ac.uk>
References: <5072B5E9.9080101@kcl.ac.uk>
	<2232DCB3-F566-40A7-B2B3-E990D4660B71@it.ox.ac.uk>
Message-ID: <5074258D.5030102@kcl.ac.uk>

Oh right, I keep forgetting that Roma updates are not restricted to the 
Guidelines release schedule--so because the last two schemas I generated 
were both against the same version of the ODD, I expected them to be 
identical.

But yes, I've performed your experiment and run both versions of our ODD 
through Roma today and they are indeed almost identical. (The one 
difference is I suspect something else I'd changed at the same time.)

Thanks, Sebastian,

G

On 2012-10-09 09:43, Sebastian Rahtz wrote:
> to expand further
>
>    a) xxx mode="delete" and except="xxx" should be functionally identically. if they are not, its an error
>    b) i have made several attempts to generate leaner schemas. so I tend to delete patterns (like "tei_model.msQuoteLike_alternation")
> which are not referenced anywhere. I suspect you are seeing the results of this austerity regime
> --
> Sebastian Rahtz
> Director (Research Support) of Academic IT Services
> University of Oxford IT Services
> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>
>

-- 
Dr Gabriel BODARD
Researcher in Digital Epigraphy

Digital Humanities
King's College London
26-29 Drury Lane
London WC2B 5RL

T: +44 (0)20 7848 1388
F: +44 (0)20 7848 2980
E: gabriel.bodard at kcl.ac.uk

http://www.digitalclassicist.org/
http://www.currentepigraphy.org/


From James.Cummings at it.ox.ac.uk  Wed Oct 10 06:46:11 2012
From: James.Cummings at it.ox.ac.uk (James Cummings)
Date: Wed, 10 Oct 2012 11:46:11 +0100
Subject: [tei-council] Meeting minutes and action list done
In-Reply-To: <506B0EC5.5010505@uvic.ca>
References: <506B0EC5.5010505@uvic.ca>
Message-ID: <507551F3.1000707@it.ox.ac.uk>


I've not heard any screams of outrage concerning Martin's 
minutes. I propose to announce these to TEI-L at 5pm (my local 
time) today.  If anyone has any changes to them either do them 
(if you have access to OpenCMS) or tell me and I'll do them.

Best,

-James



On 02/10/12 16:56, Martin Holmes wrote:
> Hi all,
>
> The minutes from Oxford are here:
>
> <http://www.tei-c.org/Activities/Council/Meetings/tcm52.xml>
>
> and there's now a wiki page with a list of actions for us all, on the
> model of the one James created from Ann Arbor, here:
>
> <http://wiki.tei-c.org/index.php/Oxford2012-Actions>
>
> Cheers,
> Martin
>


-- 
Dr James Cummings, researchsupport at it.ox.ac.uk
Research Support, IT Services, University of Oxford

From mholmes at uvic.ca  Thu Oct 11 11:45:47 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Thu, 11 Oct 2012 08:45:47 -0700
Subject: [tei-council] New Prefix Definition Proposal (was "Private URI
	Schemes")
Message-ID: <5076E9AB.8030600@uvic.ca>

Hi all,

At the Council meeting we discussed my proposal for Private URI Schemes, 
and I was tasked with rewriting it in a more generic form to make it 
more broadly applicable. I've created a new version here:

<http://wiki.tei-c.org/index.php/Prefix_Definition_Proposal>

All comments are welcome, and there's a Notes section at the end you can 
add your concerns to. I'll also raise a ticket for it too, to make sure 
we don't lose track of it. There's no pressure to get this into the 
upcoming release, so we can take our time with it.

Cheers,
Martin
-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From James.Cummings at it.ox.ac.uk  Mon Oct 15 17:19:01 2012
From: James.Cummings at it.ox.ac.uk (James Cummings)
Date: Mon, 15 Oct 2012 22:19:01 +0100
Subject: [tei-council] listChange example
Message-ID: <507C7DC5.70402@it.ox.ac.uk>


Hi all,

Is the example just above
http://www.tei-c.org/release/doc/tei-p5-doc/en/html/PH.html#PHTRXX
correct?

i.e. <profileDesc> should be inside a <teiHeader> but isn't 
there... but then isn't the border around the example supposed to 
be a different colour?

This strikes me as a good example, and one that should maybe just 
be expanded to have a <teiHeader> and made a completely valid file?
(it would only add a handful of lines to the example and would be 
more understandable).

-James
-- 
Dr James Cummings, James.Cummings at it.ox.ac.uk
Research Support, IT Services, University of Oxford

From lou.burnard at retired.ox.ac.uk  Mon Oct 15 17:29:39 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Mon, 15 Oct 2012 22:29:39 +0100
Subject: [tei-council] listChange example
In-Reply-To: <507C7DC5.70402@it.ox.ac.uk>
References: <507C7DC5.70402@it.ox.ac.uk>
Message-ID: <507C8043.5010301@retired.ox.ac.uk>

On 15/10/12 22:19, James Cummings wrote:
>
> Is the example just above
> http://www.tei-c.org/release/doc/tei-p5-doc/en/html/PH.html#PHTRXX
> correct?
>

feasibly


> i.e. <profileDesc> should be inside a <teiHeader> but isn't
> there... but then isn't the border around the example supposed to
> be a different colour?

probably

>
> This strikes me as a good example, and one that should maybe just
> be expanded to have a <teiHeader> and made a completely valid file?
> (it would only add a handful of lines to the example and would be
> more understandable).

feel free to add a few more lines!

(you could remove the extra space in front of the full stop before "From 
the textual perspective..." while you're at it)



From mholmes at uvic.ca  Mon Oct 15 18:20:02 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Mon, 15 Oct 2012 15:20:02 -0700
Subject: [tei-council] listChange example
In-Reply-To: <507C7DC5.70402@it.ox.ac.uk>
References: <507C7DC5.70402@it.ox.ac.uk>
Message-ID: <507C8C12.6040306@uvic.ca>

The default value for egXML/@valid is "true", so I guess it's coloured 
on the assumption that it's valid. Adding <teiHeader> and <TEI> would 
make it technically complete, but the content obviously isn't complete, 
so it should probably have commented ellipses or something to indicate 
that only fragments of content are being shown.

Cheers,
Martin

On 12-10-15 02:19 PM, James Cummings wrote:
>
> Hi all,
>
> Is the example just above
> http://www.tei-c.org/release/doc/tei-p5-doc/en/html/PH.html#PHTRXX
> correct?
>
> i.e. <profileDesc> should be inside a <teiHeader> but isn't
> there... but then isn't the border around the example supposed to
> be a different colour?
>
> This strikes me as a good example, and one that should maybe just
> be expanded to have a <teiHeader> and made a completely valid file?
> (it would only add a handful of lines to the example and would be
> more understandable).
>
> -James
>

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From kevin.s.hawkins at ultraslavonic.info  Tue Oct 16 21:11:12 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Tue, 16 Oct 2012 21:11:12 -0400
Subject: [tei-council] listChange example
In-Reply-To: <507C8C12.6040306@uvic.ca>
References: <507C7DC5.70402@it.ox.ac.uk> <507C8C12.6040306@uvic.ca>
Message-ID: <507E05B0.4040509@ultraslavonic.info>

I agree that the example has the wrong value of @valid, and I agree with 
Martin's suggestion of how to fix it.

On 10/15/12 6:20 PM, Martin Holmes wrote:
> The default value for egXML/@valid is "true", so I guess it's coloured
> on the assumption that it's valid. Adding <teiHeader> and <TEI> would
> make it technically complete, but the content obviously isn't complete,
> so it should probably have commented ellipses or something to indicate
> that only fragments of content are being shown.
>
> Cheers,
> Martin
>
> On 12-10-15 02:19 PM, James Cummings wrote:
>>
>> Hi all,
>>
>> Is the example just above
>> http://www.tei-c.org/release/doc/tei-p5-doc/en/html/PH.html#PHTRXX
>> correct?
>>
>> i.e. <profileDesc> should be inside a <teiHeader> but isn't
>> there... but then isn't the border around the example supposed to
>> be a different colour?
>>
>> This strikes me as a good example, and one that should maybe just
>> be expanded to have a <teiHeader> and made a completely valid file?
>> (it would only add a handful of lines to the example and would be
>> more understandable).
>>
>> -James
>>
>

From sebastian.rahtz at it.ox.ac.uk  Wed Oct 17 06:41:45 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Wed, 17 Oct 2012 10:41:45 +0000
Subject: [tei-council] listChange example
In-Reply-To: <507E05B0.4040509@ultraslavonic.info>
References: <507C7DC5.70402@it.ox.ac.uk> <507C8C12.6040306@uvic.ca>
	<507E05B0.4040509@ultraslavonic.info>
Message-ID: <C01E1DA9-838B-4DB2-8010-43B828F27A76@it.ox.ac.uk>

the difference between valid and feasibly valid is that
feasible means that if one added some extra children
it could be valid.

but "valid" here means "value against a schema where any element
can be the root of the tree".  Almost none of our examples
are valid against tei_all, cos they have no <TEI> root,
or a header.
--
Sebastian Rahtz      
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431


From lou.burnard at retired.ox.ac.uk  Wed Oct 17 07:45:48 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Wed, 17 Oct 2012 12:45:48 +0100
Subject: [tei-council] listChange example
In-Reply-To: <C01E1DA9-838B-4DB2-8010-43B828F27A76@it.ox.ac.uk>
References: <507C7DC5.70402@it.ox.ac.uk> <507C8C12.6040306@uvic.ca>
	<507E05B0.4040509@ultraslavonic.info>
	<C01E1DA9-838B-4DB2-8010-43B828F27A76@it.ox.ac.uk>
Message-ID: <507E9A6C.1060500@retired.ox.ac.uk>

However, for the case in point, it isn't even well-formed, since it 
doesn't have a single root node.

On 17/10/12 11:41, Sebastian Rahtz wrote:
> the difference between valid and feasibly valid is that
> feasible means that if one added some extra children
> it could be valid.
>
> but "valid" here means "value against a schema where any element
> can be the root of the tree".  Almost none of our examples
> are valid against tei_all, cos they have no <TEI> root,
> or a header.
> --
> Sebastian Rahtz
> Director (Research Support) of Academic IT Services
> University of Oxford IT Services
> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>


From sebastian.rahtz at it.ox.ac.uk  Wed Oct 17 08:07:04 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Wed, 17 Oct 2012 12:07:04 +0000
Subject: [tei-council] listChange example
In-Reply-To: <507E9A6C.1060500@retired.ox.ac.uk>
References: <507C7DC5.70402@it.ox.ac.uk> <507C8C12.6040306@uvic.ca>
	<507E05B0.4040509@ultraslavonic.info>
	<C01E1DA9-838B-4DB2-8010-43B828F27A76@it.ox.ac.uk>
	<507E9A6C.1060500@retired.ox.ac.uk>
Message-ID: <ba9c18a4-e6b1-447f-8dce-9bb5a46fa477@HUB04.ad.oak.ox.ac.uk>


On 17 Oct 2012, at 12:45, Lou Burnard <lou.burnard at retired.ox.ac.uk> wrote:

> However, for the case in point, it isn't even well-formed, since it 
> doesn't have a single root node.


its technically several distinct well-formed "valid" nodes, I suspect
--
Sebastian Rahtz      
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431


From mholmes at uvic.ca  Wed Oct 17 08:34:55 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Wed, 17 Oct 2012 05:34:55 -0700
Subject: [tei-council] listChange example
In-Reply-To: <ba9c18a4-e6b1-447f-8dce-9bb5a46fa477@HUB04.ad.oak.ox.ac.uk>
References: <507C7DC5.70402@it.ox.ac.uk> <507C8C12.6040306@uvic.ca>
	<507E05B0.4040509@ultraslavonic.info>
	<C01E1DA9-838B-4DB2-8010-43B828F27A76@it.ox.ac.uk>
	<507E9A6C.1060500@retired.ox.ac.uk>
	<ba9c18a4-e6b1-447f-8dce-9bb5a46fa477@HUB04.ad.oak.ox.ac.uk>
Message-ID: <507EA5EF.6040409@uvic.ca>

"Feasibly valid" doesn't apply to well-formed fragments, though, does it?

On 12-10-17 05:07 AM, Sebastian Rahtz wrote:
>
> On 17 Oct 2012, at 12:45, Lou Burnard <lou.burnard at retired.ox.ac.uk> wrote:
>
>> However, for the case in point, it isn't even well-formed, since it
>> doesn't have a single root node.
>
>
> its technically several distinct well-formed "valid" nodes, I suspect
> --
> Sebastian Rahtz
> Director (Research Support) of Academic IT Services
> University of Oxford IT Services
> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>

-- 
Martin Holmes
mholmes at uvic.ca
UVic Humanities Computing and Media Centre

From sebastian.rahtz at it.ox.ac.uk  Wed Oct 17 08:38:34 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Wed, 17 Oct 2012 12:38:34 +0000
Subject: [tei-council] listChange example
In-Reply-To: <507EA5EF.6040409@uvic.ca>
References: <507C7DC5.70402@it.ox.ac.uk> <507C8C12.6040306@uvic.ca>
	<507E05B0.4040509@ultraslavonic.info>
	<C01E1DA9-838B-4DB2-8010-43B828F27A76@it.ox.ac.uk>
	<507E9A6C.1060500@retired.ox.ac.uk>
	<ba9c18a4-e6b1-447f-8dce-9bb5a46fa477@HUB04.ad.oak.ox.ac.uk>
	<507EA5EF.6040409@uvic.ca>
Message-ID: <C853DE52-B26D-416E-A56D-A97465E8F9BD@it.ox.ac.uk>


On 17 Oct 2012, at 13:34, Martin Holmes <mholmes at uvic.ca>
 wrote:

> "Feasibly valid" doesn't apply to well-formed fragments, though, does it?


yes, why not?
--
Sebastian Rahtz      
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431


From mholmes at uvic.ca  Wed Oct 17 08:42:40 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Wed, 17 Oct 2012 05:42:40 -0700
Subject: [tei-council] listChange example
In-Reply-To: <C853DE52-B26D-416E-A56D-A97465E8F9BD@it.ox.ac.uk>
References: <507C7DC5.70402@it.ox.ac.uk> <507C8C12.6040306@uvic.ca>
	<507E05B0.4040509@ultraslavonic.info>
	<C01E1DA9-838B-4DB2-8010-43B828F27A76@it.ox.ac.uk>
	<507E9A6C.1060500@retired.ox.ac.uk>
	<ba9c18a4-e6b1-447f-8dce-9bb5a46fa477@HUB04.ad.oak.ox.ac.uk>
	<507EA5EF.6040409@uvic.ca>
	<C853DE52-B26D-416E-A56D-A97465E8F9BD@it.ox.ac.uk>
Message-ID: <507EA7C0.1080003@uvic.ca>

On 12-10-17 05:38 AM, Sebastian Rahtz wrote:
>
> On 17 Oct 2012, at 13:34, Martin Holmes <mholmes at uvic.ca>
>   wrote:
>
>> "Feasibly valid" doesn't apply to well-formed fragments, though, does it?
>
>
> yes, why not?

Well, it says:

feasible
     the example could be transformed into a valid document by inserting 
any number of valid attributes and child elements anywhere within it; or 
it is valid against a version of the schema concerned in which the 
provision of character data, list, element, or attribute values has been 
made optional.

A fragment consisting of sibling nodes with no single root node can't be 
validated, and the insertion of child elements can't fix that, can it?

Cheers,
Martin

> --
> Sebastian Rahtz
> Director (Research Support) of Academic IT Services
> University of Oxford IT Services
> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>

-- 
Martin Holmes
mholmes at uvic.ca
UVic Humanities Computing and Media Centre

From sebastian.rahtz at it.ox.ac.uk  Wed Oct 17 08:48:02 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Wed, 17 Oct 2012 12:48:02 +0000
Subject: [tei-council] listChange example
In-Reply-To: <507EA7C0.1080003@uvic.ca>
References: <507C7DC5.70402@it.ox.ac.uk> <507C8C12.6040306@uvic.ca>
	<507E05B0.4040509@ultraslavonic.info>
	<C01E1DA9-838B-4DB2-8010-43B828F27A76@it.ox.ac.uk>
	<507E9A6C.1060500@retired.ox.ac.uk>
	<ba9c18a4-e6b1-447f-8dce-9bb5a46fa477@HUB04.ad.oak.ox.ac.uk>
	<507EA5EF.6040409@uvic.ca>
	<C853DE52-B26D-416E-A56D-A97465E8F9BD@it.ox.ac.uk>
	<507EA7C0.1080003@uvic.ca>
Message-ID: <22C528D8-0926-4421-89A0-91218A91934B@it.ox.ac.uk>


On 17 Oct 2012, at 13:42, Martin Holmes <mholmes at uvic.ca>
 wrote:

> On 12-10-17 05:38 AM, Sebastian Rahtz wrote:
>> 
>> On 17 Oct 2012, at 13:34, Martin Holmes <mholmes at uvic.ca>
>>  wrote:
>> 
>>> "Feasibly valid" doesn't apply to well-formed fragments, though, does it?
>> 
>> 
>> yes, why not?
> 
> Well, it says:
> 
> feasible
>    the example could be transformed into a valid document by inserting any number of valid attributes and child elements anywhere within it; or it is valid against a version of the schema concerned in which the provision of character data, list, element, or attribute values has been made optional.
> 
> A fragment consisting of sibling nodes with no single root node can't be validated, and the insertion of child elements can't fix that, can it?
> 

yes, but if you treat it as several distinct fragments it can

or maybe Jing interpolates parents as well, in feasible mode?
--
Sebastian Rahtz      
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431


From mholmes at uvic.ca  Wed Oct 17 11:12:16 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Wed, 17 Oct 2012 08:12:16 -0700
Subject: [tei-council] listChange example
In-Reply-To: <22C528D8-0926-4421-89A0-91218A91934B@it.ox.ac.uk>
References: <507C7DC5.70402@it.ox.ac.uk> <507C8C12.6040306@uvic.ca>
	<507E05B0.4040509@ultraslavonic.info>
	<C01E1DA9-838B-4DB2-8010-43B828F27A76@it.ox.ac.uk>
	<507E9A6C.1060500@retired.ox.ac.uk>
	<ba9c18a4-e6b1-447f-8dce-9bb5a46fa477@HUB04.ad.oak.ox.ac.uk>
	<507EA5EF.6040409@uvic.ca>
	<C853DE52-B26D-416E-A56D-A97465E8F9BD@it.ox.ac.uk>
	<507EA7C0.1080003@uvic.ca>
	<22C528D8-0926-4421-89A0-91218A91934B@it.ox.ac.uk>
Message-ID: <507ECAD0.30404@uvic.ca>

On 12-10-17 05:48 AM, Sebastian Rahtz wrote:
>
> On 17 Oct 2012, at 13:42, Martin Holmes <mholmes at uvic.ca>
>   wrote:
>
>> On 12-10-17 05:38 AM, Sebastian Rahtz wrote:
>>>
>>> On 17 Oct 2012, at 13:34, Martin Holmes <mholmes at uvic.ca>
>>>   wrote:
>>>
>>>> "Feasibly valid" doesn't apply to well-formed fragments, though, does it?
>>>
>>>
>>> yes, why not?
>>
>> Well, it says:
>>
>> feasible
>>     the example could be transformed into a valid document by inserting any number of valid attributes and child elements anywhere within it; or it is valid against a version of the schema concerned in which the provision of character data, list, element, or attribute values has been made optional.
>>
>> A fragment consisting of sibling nodes with no single root node can't be validated, and the insertion of child elements can't fix that, can it?
>>
>
> yes, but if you treat it as several distinct fragments it can
>
> or maybe Jing interpolates parents as well, in feasible mode?

It doesn't appear to add a wrapper root element. I just removed the root 
<TEI> element from a valid file and validated it with jing -f, and got this:

ABBE2.xml:11:16: error: element "teiHeader" not allowed here; expected 
element "TEI" (with xmlns="http://www.tei-c.org/ns/1.0")

ABBE2.xml:39:6: fatal: The markup in the document following the root 
element must be well-formed.

So not only should jing be finding a fragment like this one invalid, 
it's not valid according to our own definition of @valid="feasible".

Is the build process actually checking whether <egXML>s that claim to be 
valid actually are? I thought it was. Perhaps it only does that if they 
have an explicit @valid="true"?

Cheers,
Martin



> --
> Sebastian Rahtz
> Director (Research Support) of Academic IT Services
> University of Oxford IT Services
> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>
>

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From sebastian.rahtz at it.ox.ac.uk  Wed Oct 17 17:23:09 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Wed, 17 Oct 2012 21:23:09 +0000
Subject: [tei-council] listChange example
In-Reply-To: <507ECAD0.30404@uvic.ca>
References: <507C7DC5.70402@it.ox.ac.uk> <507C8C12.6040306@uvic.ca>
	<507E05B0.4040509@ultraslavonic.info>
	<C01E1DA9-838B-4DB2-8010-43B828F27A76@it.ox.ac.uk>
	<507E9A6C.1060500@retired.ox.ac.uk>
	<ba9c18a4-e6b1-447f-8dce-9bb5a46fa477@HUB04.ad.oak.ox.ac.uk>
	<507EA5EF.6040409@uvic.ca>
	<C853DE52-B26D-416E-A56D-A97465E8F9BD@it.ox.ac.uk>
	<507EA7C0.1080003@uvic.ca>
	<22C528D8-0926-4421-89A0-91218A91934B@it.ox.ac.uk>
	<507ECAD0.30404@uvic.ca>
Message-ID: <69CB5A68-23F9-453A-A408-EF66A912DA03@it.ox.ac.uk>


On 17 Oct 2012, at 16:12, Martin Holmes <mholmes at uvic.ca> wrote:
> 
> It doesn't appear to add a wrapper root element. I just removed the root <TEI> element from a valid file and validated it with jing -f, and got this:
> 
> ABBE2.xml:11:16: error: element "teiHeader" not allowed here; expected element "TEI" (with xmlns="http://www.tei-c.org/ns/1.0")
> 
> ABBE2.xml:39:6: fatal: The markup in the document following the root element must be well-formed.

ah, we are forgetting that there is always an <egXML> wrapper. _that_ is what it is validating,
the fragment rooted at <egXML>.

> 
> Is the build process actually checking whether <egXML>s that claim to be valid actually are? I thought it was. Perhaps it only does that if they have an explicit @valid="true"?


read the Makefile, Luke:

@echo BUILD: Check full validity of relevant examples with nvdl
	${SAXON} p5.xml Utilities/extractegXML.xsl > v.body
	echo "<!DOCTYPE p [" > v.header
	(cd valid; ls | perl -p -e  "s+(.*)+<\!ENTITY \1 SYSTEM \"valid/\1\">+") >> v.header
	echo "]>" >> v.header
	cat v.header v.body > v.xml
	./run-onvdl  p5valid.nvdl  v.xml

all the @valid='true' or not(@valid) examples  are included in v.xml inside a <p> (arbitrary choice) which is validated.

trust me,  they are checked. try breaking one.
--
Sebastian Rahtz      
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431


From lou.burnard at retired.ox.ac.uk  Sun Oct 21 13:21:24 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Sun, 21 Oct 2012 18:21:24 +0100
Subject: [tei-council] next release
Message-ID: <50842F14.9090601@retired.ox.ac.uk>

how are we doing on this front? I am painfully aware that i still have 
some outstanding actions to complete (less painfully that i am not alone 
in this) and am wondering what the dropdead deadline should be to 
accomplish them if they are to make it to the next release



From mholmes at uvic.ca  Sun Oct 21 13:28:32 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Sun, 21 Oct 2012 10:28:32 -0700
Subject: [tei-council] next release
In-Reply-To: <50842F14.9090601@retired.ox.ac.uk>
References: <50842F14.9090601@retired.ox.ac.uk>
Message-ID: <508430C0.6070301@uvic.ca>

Just took a look through stuff assigned to me on the actions page:

<http://wiki.tei-c.org/index.php/Oxford2012-Actions>

James and I still have one major issue, the prefixing of xml:ids with tei_:

MH and JC 	implement expanded unique xml:id values in guidelines 
(http://purl.org/TEI/Bug/3472477).

and there's one similar one outstanding for me alone:

MH 	Implement linking of the "Version 2.1.0" at the bottom of each HTML 
page to something, possibly to 
http://www.tei-c.org/Guidelines/P5/#previous, or better, to something 
which explains what version numbers mean and then links on to the above 
location.

Apart from that one, I think all the release-blocking actions assigned 
to me are done.

Unfortunately I'm about as busy as I could possibly be at work at the 
moment, and I will be until the middle of November. The first task above 
already defeated me once, mainly because I really need to get a thorough 
understanding of how the Guidelines stylesheets work before I can handle 
it, but I should be able to manage the second if the deadline is not too 
close.

Do we have a release date yet?

Cheers,
Martin

On 12-10-21 10:21 AM, Lou Burnard wrote:
> how are we doing on this front? I am painfully aware that i still have
> some outstanding actions to complete (less painfully that i am not alone
> in this) and am wondering what the dropdead deadline should be to
> accomplish them if they are to make it to the next release
>
>

From bansp at o2.pl  Sun Oct 21 13:46:54 2012
From: bansp at o2.pl (=?ISO-8859-2?Q?Piotr_Ba=F1ski?=)
Date: Sun, 21 Oct 2012 19:46:54 +0200
Subject: [tei-council] next release
In-Reply-To: <50842F14.9090601@retired.ox.ac.uk>
References: <50842F14.9090601@retired.ox.ac.uk>
Message-ID: <5084350E.3010006@o2.pl>

I'm planning to implement my tickets on Tue.

@Martin: I have reserved Thursday for the release.

Best,

  P.

On 21/10/12 19:21, Lou Burnard wrote:
> how are we doing on this front? I am painfully aware that i still have 
> some outstanding actions to complete (less painfully that i am not alone 
> in this) and am wondering what the dropdead deadline should be to 
> accomplish them if they are to make it to the next release
> 
> 


From sebastian.rahtz at it.ox.ac.uk  Sun Oct 21 14:08:15 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Sun, 21 Oct 2012 18:08:15 +0000
Subject: [tei-council] next release
In-Reply-To: <508430C0.6070301@uvic.ca>
References: <50842F14.9090601@retired.ox.ac.uk> <508430C0.6070301@uvic.ca>
Message-ID: <E3B71914-BB3F-407B-9B5D-A7108798224D@it.ox.ac.uk>


On 21 Oct 2012, at 18:28, Martin Holmes <mholmes at uvic.ca>
 wrote:

> Just took a look through stuff assigned to me on the actions page:
> 
> <http://wiki.tei-c.org/index.php/Oxford2012-Actions>

I could not resist ordering this table by the values for Who,
so that we can each easily assess our exposure.

I am trying to knock mine on the head now.
--
Sebastian Rahtz      
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431


From James.Cummings at it.ox.ac.uk  Sun Oct 21 14:36:40 2012
From: James.Cummings at it.ox.ac.uk (James Cummings)
Date: Sun, 21 Oct 2012 20:36:40 +0200
Subject: [tei-council] next release
In-Reply-To: <5084350E.3010006@o2.pl>
References: <50842F14.9090601@retired.ox.ac.uk> <5084350E.3010006@o2.pl>
Message-ID: <508440B8.7050905@it.ox.ac.uk>


As Piotr noted he has reserved Thursday 25 October for the 
release. We've asked Virginia for an account on tei-c.org for 
him. I don't think any of the current assigned actions are 
specifically release blocking (but some would good to get done). 
Let me know if you think anything you're assigned will affect this.

Can we set a deadline of 5pm (UK time) on Wednesday 24 October 
for committing significant schema-modifying changes, after which 
any changes should be only correcting prose or bugs caused by our 
changes?

Best,
-James


On 21/10/12 19:46, Piotr Ba?ski wrote:
> I'm planning to implement my tickets on Tue.
>
> @Martin: I have reserved Thursday for the release.
>
> Best,
>
>    P.
>
> On 21/10/12 19:21, Lou Burnard wrote:
>> how are we doing on this front? I am painfully aware that i still have
>> some outstanding actions to complete (less painfully that i am not alone
>> in this) and am wondering what the dropdead deadline should be to
>> accomplish them if they are to make it to the next release
>>
>>
>


-- 
Dr James Cummings, researchsupport at it.ox.ac.uk
Research Support, IT Services, University of Oxford

From sebastian.rahtz at it.ox.ac.uk  Sun Oct 21 14:54:12 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Sun, 21 Oct 2012 18:54:12 +0000
Subject: [tei-council] next release
In-Reply-To: <508440B8.7050905@it.ox.ac.uk>
References: <50842F14.9090601@retired.ox.ac.uk> <5084350E.3010006@o2.pl>
	<508440B8.7050905@it.ox.ac.uk>
Message-ID: <284adc54-8f31-4b18-afe4-48b65b65cdf7@HUB03.ad.oak.ox.ac.uk>


On 21 Oct 2012, at 19:36, James Cummings <James.Cummings at it.ox.ac.uk>
 wrote:

> Can we set a deadline of 5pm (UK time) on Wednesday 24 October 
> for committing significant schema-modifying changes, after which 
> any changes should be only correcting prose or bugs caused by our 
> changes?
> 
with the obvious caveat that  if everyone submits their changes at 4.45 pm,
each expecting to Jenkins to work with them to identify mistakes
and consequences, all hell will break lose

give yourself plenty of time to see any non-trivial change work through
the system.

--
Sebastian Rahtz      
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431


From gabriel.bodard at kcl.ac.uk  Sun Oct 21 15:02:04 2012
From: gabriel.bodard at kcl.ac.uk (Gabriel Bodard)
Date: Sun, 21 Oct 2012 20:02:04 +0100
Subject: [tei-council] next release
In-Reply-To: <508440B8.7050905@it.ox.ac.uk>
References: <50842F14.9090601@retired.ox.ac.uk> <5084350E.3010006@o2.pl>
	<508440B8.7050905@it.ox.ac.uk>
Message-ID: <508446AC.1030601@kcl.ac.uk>

I'm about to leave town, not to return until past the Wednesday 
deadline, so I fear most of my tasks at 
<http://wiki.tei-c.org/index.php/Oxford2012-Actions> won't make it in. I 
will try tomorrow morning before hitting the airport to implement at 
least the schema-changing parts of http://purl.org/TEI/FR/3526114 (add 
attribute class to msDesc) and http://purl.org/TEI/Bug/3496958 (remove 
schematron and prose constraint).

I'll do all the other things assigned to me as soon as possible--which 
won't be before next week.

Apologies,

G

On 21/10/2012 19:36, James Cummings wrote:
>
> As Piotr noted he has reserved Thursday 25 October for the
> release. We've asked Virginia for an account on tei-c.org for
> him. I don't think any of the current assigned actions are
> specifically release blocking (but some would good to get done).
> Let me know if you think anything you're assigned will affect this.
>
> Can we set a deadline of 5pm (UK time) on Wednesday 24 October
> for committing significant schema-modifying changes, after which
> any changes should be only correcting prose or bugs caused by our
> changes?
>
> Best,
> -James
>
>
> On 21/10/12 19:46, Piotr Ba?ski wrote:
>> I'm planning to implement my tickets on Tue.
>>
>> @Martin: I have reserved Thursday for the release.
>>
>> Best,
>>
>>     P.
>>
>> On 21/10/12 19:21, Lou Burnard wrote:
>>> how are we doing on this front? I am painfully aware that i still have
>>> some outstanding actions to complete (less painfully that i am not alone
>>> in this) and am wondering what the dropdead deadline should be to
>>> accomplish them if they are to make it to the next release
>>>
>>>
>>
>
>

-- 
Dr Gabriel BODARD
(Research Associate in Digital Epigraphy)

Department of Digital Humanities
King's College London
26-29 Drury Lane
London WC2B 5RL

Email: gabriel.bodard at kcl.ac.uk
Tel: +44 (0)20 7848 1388
Fax: +44 (0)20 7848 2980

http://www.digitalclassicist.org/
http://www.currentepigraphy.org/


From dsewell at virginia.edu  Sun Oct 21 17:40:14 2012
From: dsewell at virginia.edu (David Sewell)
Date: Sun, 21 Oct 2012 17:40:14 -0400 (EDT)
Subject: [tei-council] next release
In-Reply-To: <508440B8.7050905@it.ox.ac.uk>
References: <50842F14.9090601@retired.ox.ac.uk> <5084350E.3010006@o2.pl>
	<508440B8.7050905@it.ox.ac.uk>
Message-ID: <alpine.OSX.2.00.1210211739420.13922@tadai.local>

I'll remind Shayne first thing tomorrow about adding an account for 
Piotr.

On Sun, 21 Oct 2012, James Cummings wrote:

>
> As Piotr noted he has reserved Thursday 25 October for the 
> release. We've asked Virginia for an account on tei-c.org for 
> him. I don't think any of the current assigned actions are 
> specifically release blocking (but some would good to get done). 
> Let me know if you think anything you're assigned will affect this.
>
> Can we set a deadline of 5pm (UK time) on Wednesday 24 October 
> for committing significant schema-modifying changes, after which 
> any changes should be only correcting prose or bugs caused by our 
> changes?
>
> Best,
> -James
>
>
> On 21/10/12 19:46, Piotr Ba?ski wrote:
>> I'm planning to implement my tickets on Tue.
>>
>> @Martin: I have reserved Thursday for the release.
>>
>> Best,
>>
>>    P.
>>
>> On 21/10/12 19:21, Lou Burnard wrote:
>>> how are we doing on this front? I am painfully aware that i still have
>>> some outstanding actions to complete (less painfully that i am not alone
>>> in this) and am wondering what the dropdead deadline should be to
>>> accomplish them if they are to make it to the next release
>>>
>>>
>>
>
>
> -- 
> Dr James Cummings, researchsupport at it.ox.ac.uk
> Research Support, IT Services, University of Oxford
> -- 
> tei-council mailing list
> tei-council at lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>
> PLEASE NOTE: postings to this list are publicly archived

-- 
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 rwelzenbach at gmail.com  Mon Oct 22 11:08:48 2012
From: rwelzenbach at gmail.com (Rebecca Welzenbach)
Date: Mon, 22 Oct 2012 11:08:48 -0400
Subject: [tei-council] next release
In-Reply-To: <alpine.OSX.2.00.1210211739420.13922@tadai.local>
References: <50842F14.9090601@retired.ox.ac.uk> <5084350E.3010006@o2.pl>
	<508440B8.7050905@it.ox.ac.uk>
	<alpine.OSX.2.00.1210211739420.13922@tadai.local>
Message-ID: <CAA2irt+gpCpBDp++3r7-k_4KaYy0HiCz5JBAbjVONTNVf+eW-A@mail.gmail.com>

This has been on my mind as well. Will plan on tonight and tomorrow for
getting as much done as I can.

Becky

On Sun, Oct 21, 2012 at 5:40 PM, David Sewell <dsewell at virginia.edu> wrote:

> I'll remind Shayne first thing tomorrow about adding an account for Piotr.
>
>
> On Sun, 21 Oct 2012, James Cummings wrote:
>
>
>> As Piotr noted he has reserved Thursday 25 October for the release. We've
>> asked Virginia for an account on tei-c.org for him. I don't think any of
>> the current assigned actions are specifically release blocking (but some
>> would good to get done). Let me know if you think anything you're assigned
>> will affect this.
>>
>> Can we set a deadline of 5pm (UK time) on Wednesday 24 October for
>> committing significant schema-modifying changes, after which any changes
>> should be only correcting prose or bugs caused by our changes?
>>
>> Best,
>> -James
>>
>>
>> On 21/10/12 19:46, Piotr Ba?ski wrote:
>>
>>> I'm planning to implement my tickets on Tue.
>>>
>>> @Martin: I have reserved Thursday for the release.
>>>
>>> Best,
>>>
>>>    P.
>>>
>>> On 21/10/12 19:21, Lou Burnard wrote:
>>>
>>>> how are we doing on this front? I am painfully aware that i still have
>>>> some outstanding actions to complete (less painfully that i am not alone
>>>> in this) and am wondering what the dropdead deadline should be to
>>>> accomplish them if they are to make it to the next release
>>>>
>>>>
>>>>
>>>
>>
>> --
>> Dr James Cummings, researchsupport at it.ox.ac.uk
>> Research Support, IT Services, University of Oxford
>> --
>> tei-council mailing list
>> tei-council at lists.village.**Virginia.EDU<tei-council at lists.village.Virginia.EDU>
>> http://lists.village.Virginia.**EDU/mailman/listinfo/tei-**council<http://lists.village.Virginia.EDU/mailman/listinfo/tei-council>
>>
>> PLEASE NOTE: postings to this list are publicly archived
>>
>
> --
> 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/<http://rotunda.upress.virginia.edu/>
> --
> tei-council mailing list
> tei-council at lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>
> PLEASE NOTE: postings to this list are publicly archived
>

From bansp at o2.pl  Tue Oct 23 07:50:40 2012
From: bansp at o2.pl (Piotr Banski)
Date: Tue, 23 Oct 2012 13:50:40 +0200
Subject: [tei-council] the xpointer comments
Message-ID: <50868490.70200@o2.pl>

In the wiki, at the top of the Actions page, we say:

"Council members (e.g. PB, LB and GB) will add comments directly to HC?s 
original proposal by the end of October, and then we will be happy to 
receive any further drafts of it."

http://wiki.tei-c.org/index.php/Oxford2012-Actions

I was wondering: can we move this to the end of November, and first hear 
what Hugh has to say about that at the TEI-MM, and discuss it, at least 
in part, there on the spot?

I'm now taking on my tickets, then it's release time, then the 
preparation for the MM talk and the SIG meeting (and I'm flying to the 
States very soon, it's a joint work trip), and I just can't see the 
possibility of getting down to preparing detailed remarks on this right 
now (there's the day job to be handled before the MM trip, too).

On another note, I would really like to see Syd involved in this -- I 
believe his input to be quite crucial, given that he was the author of 
the original TEI XPointer schemes.

I am not even sure of the status of Hugh's proposal in the googledoc -- 
is this something submitted to the Council to act on, or is that an 
abstract of his MM talk? If the former were the case, I could understand 
why the Council would delegate its three members to handle it, but it 
seems to me to be a sketch of a proposal only, and so I don't understand 
why we should act on something that isn't in fact finalised before Hugh 
presents it at the MM:

http://idhmc.tamu.edu/teiconference/program/papers/session-1b/

So once again: can we say
a) please submit a concrete proposal
b) "end of November at the earliest"
, there?

Otherwise, it seems to me that we may act on this as fellow researchers 
and members of a WG, but not really in our capacity as members of the 
Council.

Best,

   P.


From kevin.s.hawkins at ultraslavonic.info  Tue Oct 23 09:02:35 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Tue, 23 Oct 2012 09:02:35 -0400
Subject: [tei-council] the xpointer comments
In-Reply-To: <50868490.70200@o2.pl>
References: <50868490.70200@o2.pl>
Message-ID: <5086956B.1070805@ultraslavonic.info>

I think the consensus in Oxford was that PB, LB, and GB would respond to 
the draft proposal in Google Docs so that HC and/or others could submit 
a revised proposal for Council to consider again.  However, if PB, LB, 
and GB feel they can't respond to the draft in its current state, or 
could do so more effectively if they just talked it over in person with 
Hugh Cayless and Syd Bauman in person -- and if we know that they'll be 
in College Station -- then I see no reason not to discuss it in person 
with them instead.

In any case, it's obviously not going to happen by the end of October.

--K.

On 10/23/12 7:50 AM, Piotr Banski wrote:
> In the wiki, at the top of the Actions page, we say:
>
> "Council members (e.g. PB, LB and GB) will add comments directly to HC?s
> original proposal by the end of October, and then we will be happy to
> receive any further drafts of it."
>
> http://wiki.tei-c.org/index.php/Oxford2012-Actions
>
> I was wondering: can we move this to the end of November, and first hear
> what Hugh has to say about that at the TEI-MM, and discuss it, at least
> in part, there on the spot?
>
> I'm now taking on my tickets, then it's release time, then the
> preparation for the MM talk and the SIG meeting (and I'm flying to the
> States very soon, it's a joint work trip), and I just can't see the
> possibility of getting down to preparing detailed remarks on this right
> now (there's the day job to be handled before the MM trip, too).
>
> On another note, I would really like to see Syd involved in this -- I
> believe his input to be quite crucial, given that he was the author of
> the original TEI XPointer schemes.
>
> I am not even sure of the status of Hugh's proposal in the googledoc --
> is this something submitted to the Council to act on, or is that an
> abstract of his MM talk? If the former were the case, I could understand
> why the Council would delegate its three members to handle it, but it
> seems to me to be a sketch of a proposal only, and so I don't understand
> why we should act on something that isn't in fact finalised before Hugh
> presents it at the MM:
>
> http://idhmc.tamu.edu/teiconference/program/papers/session-1b/
>
> So once again: can we say
> a) please submit a concrete proposal
> b) "end of November at the earliest"
> , there?
>
> Otherwise, it seems to me that we may act on this as fellow researchers
> and members of a WG, but not really in our capacity as members of the
> Council.
>
> Best,
>
>     P.
>

From mholmes at uvic.ca  Tue Oct 23 11:45:36 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Tue, 23 Oct 2012 08:45:36 -0700
Subject: [tei-council] the xpointer comments
In-Reply-To: <5086956B.1070805@ultraslavonic.info>
References: <50868490.70200@o2.pl> <5086956B.1070805@ultraslavonic.info>
Message-ID: <5086BBA0.4040306@uvic.ca>

We have had some discussion on the TEI-SOM list following the Oxford 
meeting, starting here:

<http://listserv.brown.edu/archives/cgi-bin/wa?A2=ind1209&L=tei-som&F=&S=&P=66>

Gaby asked me to summarise my issues with it, which I did, and Hugh 
responded in some detail. In that discussion, I think this is the 
clearest statement of my position:

<http://listserv.brown.edu/archives/cgi-bin/wa?A2=ind1209&L=tei-som&F=&S=&P=5669>

and Hugh's response to that answers some of those objections, but 
largely by saying that much of what I worry about would be 
implementation-dependent and outside the scope of the specification. The 
implication seems to be that what you get when you process one of these 
pointers will differ radically depending on the implementation; that 
seems to me to be a fundamental problem, but clearly Hugh doesn't think so.

Syd said he was going to look at the proposal, but it looks like he 
hasn't had time to do so yet. I also think his input is essential. I'm 
looking forward to seeing what comes out of the TEI meeting (which I 
can't attend, unfortunately).

Cheers,
Martin

On 12-10-23 06:02 AM, Kevin Hawkins wrote:
> I think the consensus in Oxford was that PB, LB, and GB would respond to
> the draft proposal in Google Docs so that HC and/or others could submit
> a revised proposal for Council to consider again.  However, if PB, LB,
> and GB feel they can't respond to the draft in its current state, or
> could do so more effectively if they just talked it over in person with
> Hugh Cayless and Syd Bauman in person -- and if we know that they'll be
> in College Station -- then I see no reason not to discuss it in person
> with them instead.
>
> In any case, it's obviously not going to happen by the end of October.
>
> --K.
>
> On 10/23/12 7:50 AM, Piotr Banski wrote:
>> In the wiki, at the top of the Actions page, we say:
>>
>> "Council members (e.g. PB, LB and GB) will add comments directly to HC?s
>> original proposal by the end of October, and then we will be happy to
>> receive any further drafts of it."
>>
>> http://wiki.tei-c.org/index.php/Oxford2012-Actions
>>
>> I was wondering: can we move this to the end of November, and first hear
>> what Hugh has to say about that at the TEI-MM, and discuss it, at least
>> in part, there on the spot?
>>
>> I'm now taking on my tickets, then it's release time, then the
>> preparation for the MM talk and the SIG meeting (and I'm flying to the
>> States very soon, it's a joint work trip), and I just can't see the
>> possibility of getting down to preparing detailed remarks on this right
>> now (there's the day job to be handled before the MM trip, too).
>>
>> On another note, I would really like to see Syd involved in this -- I
>> believe his input to be quite crucial, given that he was the author of
>> the original TEI XPointer schemes.
>>
>> I am not even sure of the status of Hugh's proposal in the googledoc --
>> is this something submitted to the Council to act on, or is that an
>> abstract of his MM talk? If the former were the case, I could understand
>> why the Council would delegate its three members to handle it, but it
>> seems to me to be a sketch of a proposal only, and so I don't understand
>> why we should act on something that isn't in fact finalised before Hugh
>> presents it at the MM:
>>
>> http://idhmc.tamu.edu/teiconference/program/papers/session-1b/
>>
>> So once again: can we say
>> a) please submit a concrete proposal
>> b) "end of November at the earliest"
>> , there?
>>
>> Otherwise, it seems to me that we may act on this as fellow researchers
>> and members of a WG, but not really in our capacity as members of the
>> Council.
>>
>> Best,
>>
>>      P.
>>

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From sebastian.rahtz at it.ox.ac.uk  Tue Oct 23 12:11:26 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Tue, 23 Oct 2012 16:11:26 +0000
Subject: [tei-council] Sourceforge down-ish
Message-ID: <A2323422-A3D1-49D0-94F6-6BFF5E08F2A8@it.ox.ac.uk>

Our Subversion is not working, I am afraid (http://sourceforge.net/blog/various-sourceforge-services-down/)
which will hit anyone trying to do their ticket work
--
Sebastian Rahtz      
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431


From lou.burnard at retired.ox.ac.uk  Tue Oct 23 16:07:08 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Tue, 23 Oct 2012 21:07:08 +0100
Subject: [tei-council] Report from Berlin
Message-ID: <5086F8EC.4030901@retired.ox.ac.uk>

*EIT MMI Meeting, Berlin 22 oct 2012*

As noted at the last FTF, Laurent Romary in his capacity as ISO TC7 WG3 
chair has proposed a new ISO/TEI joint activity in the area of speech 
transcription, which comes with the slightly obscure label of EIT MMI: 
the last part of which is short for ?multimodal interaction?, although 
it seems the activity is really only concerned with speech 
transcription. I was invited to attend the third EIT MMI workshop, held 
at the DIN's offices in Berlin. Prime movers in the activity, apart from 
Laurent, appear to be Thomas Schmidt and Andreas Witt from the Institut 
fur Deutsche Sprache in Mannheim, but a number of other European 
research labs, mostly concerned with analysis of corpora of human 
computer interaction, were also represented; specifically: Nadia Mana 
from FBK (Trento, Italy); Tatjana Scheffler (DFKI, Germany); Khiet 
Truong (Univ of Twente) ; Benjamin Weiss (TU Berlin); Mathias Wilhelm 
(DAI Labor); Bertrand Gaiffe (ATILF, Nancy). This being an ISO activity, 
the real world of commerce and industry was also represented by Felix 
Burkhardt from Deutsche Telekom's Innovation Lab.
Related ISO activity mentioned by Laurent included the work on Discourse 
Relations led by Harry Bunt, and the long-awaited MAF (morpho-syntactic 
annotation framework) which are both due to appear Real Soon Now. A 
quick tour de table confirmed my impression that most of the attendees 
were primarily researchers in Human Computer Interaction with little 
direct experience of the construction or encoding of spoken corpora, but 
Thomas Schmidt more than made up for that. The main business of the day 
was to go through his preliminary draft working document, the objective 
of which is to confer ISO authority on a subset of the existing TEI 
proposals for spoken text transcription, with some possible 
modification. The underlying work is well described in Schmidt's recent 
excellent article in TEIJ, so I won't repeat it: essentially, it 
consists of a close look at the majority of transcription formats used 
by the relevant research community/ies and tools, a synthesis of what 
they have in common, and suggestions of how that synthesis maps to TEI. 
This is to a large extent motivated by concerns about preservation and 
migration of data in ?legacy? formats.

The discussion began by establishing boundaries: despite my proposal to 
the contrary, it seems there was little appetite to extend the work into 
the area of truly multimodal transcriptions, which was still generally 
felt to be insufficiently understood for a practice-based standard to be 
appropriate. Concern was expressed that we should not make ad hoc 
premature suggestions. So the document really only concerns transcribed 
speech. There was no disagreement with the general approach which is to
distinguish a small number of macro-structural featuresprovide 
guidelines about how to mark up specific units of analysis at the 
micro-structural level, using a subset of the TEI.
I was also much cheered by two further remarks he made
the graph-based ?annotation framework? formalisation proposed by Bird 
and Liberman was theoretically complete but so generic as to be 
practically useless (I paraphrase)
at the micro level, everything you need is there in the TEI (I quote)

Discussion focussed on the following points raised by the working document:

*Tiers*

Many existing tools organise transcriptions into ?tiers? of annotation. 
These seem to be purely technical artefacts, which can be addressed more 
exactly by used of XML markup. Unlike ?levels? of annotation, they have 
no semantics. It's doubtful that we need a <tier> element.

*Metadata -1*

How many of the (very rich) TEI proposals should be included, or 
mentioned? And how should the three things Thomas had found missing be 
supplied? I suggested that <appinfo> was an appropriate way to record 
information about the transcription tool used; that the definition of 
the transcription system used belonged in the <encodingDesc>; and agreed 
that there was nothing specifically provided for recording pointers or 
links to the original video or audio transcribed. In the meeting, I 
speculated that maybe there was scope for extending (or misusing) 
<facsimile> for this last purpose; another possibility which pccurs to 
me as I type these notes is that one could also extend <recordingDesc>.

*Timing*

The timeline is fundamental to the macrostructure of a transcript. 
Thomas' examples all used absolute times for its <when>s, but I 
suggested that relative ones might be easier. The document ordering both 
of <when>s and of transcribed speech should reflect the temporal order 
as far as possible; this would allegedly facilitate interoperability

*Metadata-2*

What metadata was needed, required, recommended for the description of 
participants? (@sex raised its ugly head here). Could we use <person> to 
refer to artificial respondents in MMI experiments? (yes, if they have 
person-like characteristics; no otherwise)

It was noted that almost any personal trait or state might be crucial to 
the analysis of some corpora. We noted that CMDI now recommended using 
the ISOCAT data category registry as an independent way of defining 
metadata terminology; also that ISOCAT was now available within the TEI 
scheme (though whether it fits into personal metadata I am less sure). 
There was (I think) general agreement that we'd reference the various 
options available in the TEI but not incorporate all of them.

We agreed that the principles underlying a given transcription should be 
clearly documented, either in associated articles, in the formal 
specification for an encoding, or in the header of individual documents.

*Utterances*

Several people disliked the expanded element name <u> and its 
definition, for various theoretical reasons. Its definition should be 
modified to remove the implication that it necessarily followed a 
silence, though we seemed to agree that a <u> could only contain a 
stretch of speech from a single speaker.

The temporal alignment of a <u> can be indicated either by @start and 
@end or by nested <anchor/>s : the standard should probably recommend 
use of one or the other methods but not both. We discussed whether or 
not the fact that existing tools did not support the (even simpler) use 
of @trans to indicate overlap should lead us not to recommend it.

*U-plus*

Thomas wanted some method of associating with a <u> the whole block of 
annotations made on it (represented as one or more <interpGrp>s). His 
document suggested using <div> for this purpose. A lighter-weight 
solution might be to include <interpGrp> within <u>, or to propose a new 
wrapper <annotatedU> element.

*Tokenization*

Laurent noted that MAF recommended use of <w> for individual tokens; we 
didn't need to take a stand on the definition of ?word? but could simply 
refer to MAF. We needed some way of signalling the things that older 
transcription formats had found important, e.g. words considered 
incomplete, false starts, repetitions, abbreviations etc. so we needed 
to choose an appropriate TEI construct for them, even if we thought the 
concept was not useful or ill-defined. The general purpose <seg> element 
might be the simplest solution, but some diplomacy would be needed about 
how to define its application and its possible @type or @function values.

*Conclusions*

This workgroup will probably produce a useful document describing an 
important use case for the TEI recommendations on spoken language. It is 
currently a Google Doc which the group has agreed to share with the 
Council. I undertook to help turn this into an ODD, which could 
eventually become one of our Exemplars. Work on standardising other 
aspects of transcribed multimodal interactions probably needs to be 
deferred to a later stage.



From bansp at o2.pl  Tue Oct 23 16:33:17 2012
From: bansp at o2.pl (Piotr Banski)
Date: Tue, 23 Oct 2012 22:33:17 +0200
Subject: [tei-council] the xpointer comments
In-Reply-To: <5086BBA0.4040306@uvic.ca>
References: <50868490.70200@o2.pl> <5086956B.1070805@ultraslavonic.info>
	<5086BBA0.4040306@uvic.ca>
Message-ID: <5086FF0D.3060704@o2.pl>

Hi Martin,

Thanks for this info. I've either got a kick out of the list (it's 
happened to me in the past, for excess bounces off my free server), or 
I've managed to overlook that thread completely (been there as well). 
Will verify.

   P.



On 23/10/12 17:45, Martin Holmes wrote:
> We have had some discussion on the TEI-SOM list following the Oxford
> meeting, starting here:
>
> <http://listserv.brown.edu/archives/cgi-bin/wa?A2=ind1209&L=tei-som&F=&S=&P=66>
>
> Gaby asked me to summarise my issues with it, which I did, and Hugh
> responded in some detail. In that discussion, I think this is the
> clearest statement of my position:
>
> <http://listserv.brown.edu/archives/cgi-bin/wa?A2=ind1209&L=tei-som&F=&S=&P=5669>
>
> and Hugh's response to that answers some of those objections, but
> largely by saying that much of what I worry about would be
> implementation-dependent and outside the scope of the specification. The
> implication seems to be that what you get when you process one of these
> pointers will differ radically depending on the implementation; that
> seems to me to be a fundamental problem, but clearly Hugh doesn't think so.
>
> Syd said he was going to look at the proposal, but it looks like he
> hasn't had time to do so yet. I also think his input is essential. I'm
> looking forward to seeing what comes out of the TEI meeting (which I
> can't attend, unfortunately).
>
> Cheers,
> Martin
>
> On 12-10-23 06:02 AM, Kevin Hawkins wrote:
>> I think the consensus in Oxford was that PB, LB, and GB would respond to
>> the draft proposal in Google Docs so that HC and/or others could submit
>> a revised proposal for Council to consider again.  However, if PB, LB,
>> and GB feel they can't respond to the draft in its current state, or
>> could do so more effectively if they just talked it over in person with
>> Hugh Cayless and Syd Bauman in person -- and if we know that they'll be
>> in College Station -- then I see no reason not to discuss it in person
>> with them instead.
>>
>> In any case, it's obviously not going to happen by the end of October.
>>
>> --K.
>>
>> On 10/23/12 7:50 AM, Piotr Banski wrote:
>>> In the wiki, at the top of the Actions page, we say:
>>>
>>> "Council members (e.g. PB, LB and GB) will add comments directly to HC?s
>>> original proposal by the end of October, and then we will be happy to
>>> receive any further drafts of it."
>>>
>>> http://wiki.tei-c.org/index.php/Oxford2012-Actions
>>>
>>> I was wondering: can we move this to the end of November, and first hear
>>> what Hugh has to say about that at the TEI-MM, and discuss it, at least
>>> in part, there on the spot?
>>>
>>> I'm now taking on my tickets, then it's release time, then the
>>> preparation for the MM talk and the SIG meeting (and I'm flying to the
>>> States very soon, it's a joint work trip), and I just can't see the
>>> possibility of getting down to preparing detailed remarks on this right
>>> now (there's the day job to be handled before the MM trip, too).
>>>
>>> On another note, I would really like to see Syd involved in this -- I
>>> believe his input to be quite crucial, given that he was the author of
>>> the original TEI XPointer schemes.
>>>
>>> I am not even sure of the status of Hugh's proposal in the googledoc --
>>> is this something submitted to the Council to act on, or is that an
>>> abstract of his MM talk? If the former were the case, I could understand
>>> why the Council would delegate its three members to handle it, but it
>>> seems to me to be a sketch of a proposal only, and so I don't understand
>>> why we should act on something that isn't in fact finalised before Hugh
>>> presents it at the MM:
>>>
>>> http://idhmc.tamu.edu/teiconference/program/papers/session-1b/
>>>
>>> So once again: can we say
>>> a) please submit a concrete proposal
>>> b) "end of November at the earliest"
>>> , there?
>>>
>>> Otherwise, it seems to me that we may act on this as fellow researchers
>>> and members of a WG, but not really in our capacity as members of the
>>> Council.
>>>
>>> Best,
>>>
>>>       P.
>>>
>


From lou.burnard at retired.ox.ac.uk  Tue Oct 23 16:44:50 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Tue, 23 Oct 2012 21:44:50 +0100
Subject: [tei-council] the xpointer comments
In-Reply-To: <5086FF0D.3060704@o2.pl>
References: <50868490.70200@o2.pl> <5086956B.1070805@ultraslavonic.info>
	<5086BBA0.4040306@uvic.ca> <5086FF0D.3060704@o2.pl>
Message-ID: <508701C2.4030606@retired.ox.ac.uk>

Yeah, I thought I was subscribed to that list too, but this is the first 
I've heard of any messages on it.

On 23/10/12 21:33, Piotr Banski wrote:
> Hi Martin,
>
> Thanks for this info. I've either got a kick out of the list (it's
> happened to me in the past, for excess bounces off my free server), or
> I've managed to overlook that thread completely (been there as well).
> Will verify.
>
>     P.
>
>
>
> On 23/10/12 17:45, Martin Holmes wrote:
>> We have had some discussion on the TEI-SOM list following the Oxford
>> meeting, starting here:
>>
>> <http://listserv.brown.edu/archives/cgi-bin/wa?A2=ind1209&L=tei-som&F=&S=&P=66>
>>
>> Gaby asked me to summarise my issues with it, which I did, and Hugh
>> responded in some detail. In that discussion, I think this is the
>> clearest statement of my position:
>>
>> <http://listserv.brown.edu/archives/cgi-bin/wa?A2=ind1209&L=tei-som&F=&S=&P=5669>
>>
>> and Hugh's response to that answers some of those objections, but
>> largely by saying that much of what I worry about would be
>> implementation-dependent and outside the scope of the specification. The
>> implication seems to be that what you get when you process one of these
>> pointers will differ radically depending on the implementation; that
>> seems to me to be a fundamental problem, but clearly Hugh doesn't think so.
>>
>> Syd said he was going to look at the proposal, but it looks like he
>> hasn't had time to do so yet. I also think his input is essential. I'm
>> looking forward to seeing what comes out of the TEI meeting (which I
>> can't attend, unfortunately).
>>
>> Cheers,
>> Martin
>>
>> On 12-10-23 06:02 AM, Kevin Hawkins wrote:
>>> I think the consensus in Oxford was that PB, LB, and GB would respond to
>>> the draft proposal in Google Docs so that HC and/or others could submit
>>> a revised proposal for Council to consider again.  However, if PB, LB,
>>> and GB feel they can't respond to the draft in its current state, or
>>> could do so more effectively if they just talked it over in person with
>>> Hugh Cayless and Syd Bauman in person -- and if we know that they'll be
>>> in College Station -- then I see no reason not to discuss it in person
>>> with them instead.
>>>
>>> In any case, it's obviously not going to happen by the end of October.
>>>
>>> --K.
>>>
>>> On 10/23/12 7:50 AM, Piotr Banski wrote:
>>>> In the wiki, at the top of the Actions page, we say:
>>>>
>>>> "Council members (e.g. PB, LB and GB) will add comments directly to HC?s
>>>> original proposal by the end of October, and then we will be happy to
>>>> receive any further drafts of it."
>>>>
>>>> http://wiki.tei-c.org/index.php/Oxford2012-Actions
>>>>
>>>> I was wondering: can we move this to the end of November, and first hear
>>>> what Hugh has to say about that at the TEI-MM, and discuss it, at least
>>>> in part, there on the spot?
>>>>
>>>> I'm now taking on my tickets, then it's release time, then the
>>>> preparation for the MM talk and the SIG meeting (and I'm flying to the
>>>> States very soon, it's a joint work trip), and I just can't see the
>>>> possibility of getting down to preparing detailed remarks on this right
>>>> now (there's the day job to be handled before the MM trip, too).
>>>>
>>>> On another note, I would really like to see Syd involved in this -- I
>>>> believe his input to be quite crucial, given that he was the author of
>>>> the original TEI XPointer schemes.
>>>>
>>>> I am not even sure of the status of Hugh's proposal in the googledoc --
>>>> is this something submitted to the Council to act on, or is that an
>>>> abstract of his MM talk? If the former were the case, I could understand
>>>> why the Council would delegate its three members to handle it, but it
>>>> seems to me to be a sketch of a proposal only, and so I don't understand
>>>> why we should act on something that isn't in fact finalised before Hugh
>>>> presents it at the MM:
>>>>
>>>> http://idhmc.tamu.edu/teiconference/program/papers/session-1b/
>>>>
>>>> So once again: can we say
>>>> a) please submit a concrete proposal
>>>> b) "end of November at the earliest"
>>>> , there?
>>>>
>>>> Otherwise, it seems to me that we may act on this as fellow researchers
>>>> and members of a WG, but not really in our capacity as members of the
>>>> Council.
>>>>
>>>> Best,
>>>>
>>>>        P.
>>>>


From mholmes at uvic.ca  Tue Oct 23 16:50:47 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Tue, 23 Oct 2012 13:50:47 -0700
Subject: [tei-council] Report from Berlin
In-Reply-To: <5086F8EC.4030901@retired.ox.ac.uk>
References: <5086F8EC.4030901@retired.ox.ac.uk>
Message-ID: <50870327.1000802@uvic.ca>

Thanks Lou for such a clear and detailed account. This looks very 
interesting.

I've just been doing some work with ISOCAT myself, in an effort to start 
mapping feature structures from a TEI dictionary onto the GOLD 2010 
ontology, as expressed in ISOCAT. There are a couple of minor issues we 
should look at here (see below for boring detail).

I've also been talking to Laurent a little about the possibility of TEI 
as a serialization for Lexical Markup Framework, and I'm expecting to 
work more on this ahead of a presentation at the ICLDC3 conference in 
Hawaii next year. LMF is also an ISO standard, so Laurent's mission to 
bring ISO standards and TEI into closer integration is moving forward.

Issues I've found with ISOCAT/TEI integration:

It's not precisely clear to me how the attributes dcr:datcat and 
dcr:valueDatcat should map into a system with multiple hierarchical 
levels; and given such a system, I don't see the value of dcr:datcat 
since whatever level of ancestor it's supposed to point to can be 
discovered from what dcr:valueDatcat is pointing at. Meanwhile, it 
remains impossible to point to a particular ontology in ISOCAT because 
they don't have unique ids/URIs, but individual ontological components 
can be imported into multiple ontologies, so AFAICS you can't specify 
that you're pointing at the instance of 3062 (AcousticProperty) that's 
in RELISH / GOLD 2010, or the one that's in GOLD / GOLD 2010, or one 
that's somewhere else (assuming this could be said to matter).

This could all be due to my own ignorance, of course.

Cheers,
Martin

On 12-10-23 01:07 PM, Lou Burnard wrote:
> *EIT MMI Meeting, Berlin 22 oct 2012*
>
> As noted at the last FTF, Laurent Romary in his capacity as ISO TC7 WG3
> chair has proposed a new ISO/TEI joint activity in the area of speech
> transcription, which comes with the slightly obscure label of EIT MMI:
> the last part of which is short for ?multimodal interaction?, although
> it seems the activity is really only concerned with speech
> transcription. I was invited to attend the third EIT MMI workshop, held
> at the DIN's offices in Berlin. Prime movers in the activity, apart from
> Laurent, appear to be Thomas Schmidt and Andreas Witt from the Institut
> fur Deutsche Sprache in Mannheim, but a number of other European
> research labs, mostly concerned with analysis of corpora of human
> computer interaction, were also represented; specifically: Nadia Mana
> from FBK (Trento, Italy); Tatjana Scheffler (DFKI, Germany); Khiet
> Truong (Univ of Twente) ; Benjamin Weiss (TU Berlin); Mathias Wilhelm
> (DAI Labor); Bertrand Gaiffe (ATILF, Nancy). This being an ISO activity,
> the real world of commerce and industry was also represented by Felix
> Burkhardt from Deutsche Telekom's Innovation Lab.
> Related ISO activity mentioned by Laurent included the work on Discourse
> Relations led by Harry Bunt, and the long-awaited MAF (morpho-syntactic
> annotation framework) which are both due to appear Real Soon Now. A
> quick tour de table confirmed my impression that most of the attendees
> were primarily researchers in Human Computer Interaction with little
> direct experience of the construction or encoding of spoken corpora, but
> Thomas Schmidt more than made up for that. The main business of the day
> was to go through his preliminary draft working document, the objective
> of which is to confer ISO authority on a subset of the existing TEI
> proposals for spoken text transcription, with some possible
> modification. The underlying work is well described in Schmidt's recent
> excellent article in TEIJ, so I won't repeat it: essentially, it
> consists of a close look at the majority of transcription formats used
> by the relevant research community/ies and tools, a synthesis of what
> they have in common, and suggestions of how that synthesis maps to TEI.
> This is to a large extent motivated by concerns about preservation and
> migration of data in ?legacy? formats.
>
> The discussion began by establishing boundaries: despite my proposal to
> the contrary, it seems there was little appetite to extend the work into
> the area of truly multimodal transcriptions, which was still generally
> felt to be insufficiently understood for a practice-based standard to be
> appropriate. Concern was expressed that we should not make ad hoc
> premature suggestions. So the document really only concerns transcribed
> speech. There was no disagreement with the general approach which is to
> distinguish a small number of macro-structural featuresprovide
> guidelines about how to mark up specific units of analysis at the
> micro-structural level, using a subset of the TEI.
> I was also much cheered by two further remarks he made
> the graph-based ?annotation framework? formalisation proposed by Bird
> and Liberman was theoretically complete but so generic as to be
> practically useless (I paraphrase)
> at the micro level, everything you need is there in the TEI (I quote)
>
> Discussion focussed on the following points raised by the working document:
>
> *Tiers*
>
> Many existing tools organise transcriptions into ?tiers? of annotation.
> These seem to be purely technical artefacts, which can be addressed more
> exactly by used of XML markup. Unlike ?levels? of annotation, they have
> no semantics. It's doubtful that we need a <tier> element.
>
> *Metadata -1*
>
> How many of the (very rich) TEI proposals should be included, or
> mentioned? And how should the three things Thomas had found missing be
> supplied? I suggested that <appinfo> was an appropriate way to record
> information about the transcription tool used; that the definition of
> the transcription system used belonged in the <encodingDesc>; and agreed
> that there was nothing specifically provided for recording pointers or
> links to the original video or audio transcribed. In the meeting, I
> speculated that maybe there was scope for extending (or misusing)
> <facsimile> for this last purpose; another possibility which pccurs to
> me as I type these notes is that one could also extend <recordingDesc>.
>
> *Timing*
>
> The timeline is fundamental to the macrostructure of a transcript.
> Thomas' examples all used absolute times for its <when>s, but I
> suggested that relative ones might be easier. The document ordering both
> of <when>s and of transcribed speech should reflect the temporal order
> as far as possible; this would allegedly facilitate interoperability
>
> *Metadata-2*
>
> What metadata was needed, required, recommended for the description of
> participants? (@sex raised its ugly head here). Could we use <person> to
> refer to artificial respondents in MMI experiments? (yes, if they have
> person-like characteristics; no otherwise)
>
> It was noted that almost any personal trait or state might be crucial to
> the analysis of some corpora. We noted that CMDI now recommended using
> the ISOCAT data category registry as an independent way of defining
> metadata terminology; also that ISOCAT was now available within the TEI
> scheme (though whether it fits into personal metadata I am less sure).
> There was (I think) general agreement that we'd reference the various
> options available in the TEI but not incorporate all of them.
>
> We agreed that the principles underlying a given transcription should be
> clearly documented, either in associated articles, in the formal
> specification for an encoding, or in the header of individual documents.
>
> *Utterances*
>
> Several people disliked the expanded element name <u> and its
> definition, for various theoretical reasons. Its definition should be
> modified to remove the implication that it necessarily followed a
> silence, though we seemed to agree that a <u> could only contain a
> stretch of speech from a single speaker.
>
> The temporal alignment of a <u> can be indicated either by @start and
> @end or by nested <anchor/>s : the standard should probably recommend
> use of one or the other methods but not both. We discussed whether or
> not the fact that existing tools did not support the (even simpler) use
> of @trans to indicate overlap should lead us not to recommend it.
>
> *U-plus*
>
> Thomas wanted some method of associating with a <u> the whole block of
> annotations made on it (represented as one or more <interpGrp>s). His
> document suggested using <div> for this purpose. A lighter-weight
> solution might be to include <interpGrp> within <u>, or to propose a new
> wrapper <annotatedU> element.
>
> *Tokenization*
>
> Laurent noted that MAF recommended use of <w> for individual tokens; we
> didn't need to take a stand on the definition of ?word? but could simply
> refer to MAF. We needed some way of signalling the things that older
> transcription formats had found important, e.g. words considered
> incomplete, false starts, repetitions, abbreviations etc. so we needed
> to choose an appropriate TEI construct for them, even if we thought the
> concept was not useful or ill-defined. The general purpose <seg> element
> might be the simplest solution, but some diplomacy would be needed about
> how to define its application and its possible @type or @function values.
>
> *Conclusions*
>
> This workgroup will probably produce a useful document describing an
> important use case for the TEI recommendations on spoken language. It is
> currently a Google Doc which the group has agreed to share with the
> Council. I undertook to help turn this into an ODD, which could
> eventually become one of our Exemplars. Work on standardising other
> aspects of transcribed multimodal interactions probably needs to be
> deferred to a later stage.
>
>

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From rwelzenbach at gmail.com  Tue Oct 23 22:36:10 2012
From: rwelzenbach at gmail.com (Rebecca Welzenbach)
Date: Tue, 23 Oct 2012 22:36:10 -0400
Subject: [tei-council] documenting xml:space
Message-ID: <CAA2irtKjjrGd-LYLtHUo8-7uGki+qM14nSJK7+s1E=3VW49r=A@mail.gmail.com>

Hi all,

One of my tasks was to reconcile two tickets dealing with the xml:space
attribute.

1) Bug 3223636 (closed before the September F2F)
2) FR 3554294

Currently, Chapter 1 of the Guidelines describes the usual treatment of
whitespace by XML processors and suggests that in TEI there is usually
little reason to change this--but if required, the encoder can use
@xml:space and should refer to the XML spec for guidance. (see:
http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ST.html#index-body.1_div.1_div.3_div.1_div.1_div.4
)

FR 3554294 asks the Guidelines to use clearer and stronger language in
explaining this, and proposes some sample language. It also asks for these
recommendations to be included in the xml:space attribute spec. Most what
it says, though, is already accounted for in the prose of the Guidelines.
There are two exceptions:

1) "If encoders expect applications to process whitespace otherwise, this
should be noted in <encodingStmt>."

Here I think he means <encodingDesc>. This warrants discussion and perhaps
its own ticket: do we want to expand <normalization> to include how the
encoder expects a processor to handle whitespace? In addition, although it
is not mentioned in the ticket, in his wiki page, John suggests that even
in cases where no modification to whitespace normalization is expected,
encoders should state this explicitly, rather than letting it be implied by
omission. Do we agree?

2) "For further background and recommendations, see XML Whitespace in the
TEI Wiki (http://wiki.tei-c.org/index.php/XML_Whitespace) and the XML
specification (http://www.w3.org/TR/REC-xml/#sec-white-space)." Do we have
a policy or practice about linking from the Guidelines to wiki pages?

I propose:

   - Close this ticket. The things that John is asking for have been, or
   are being, addressed elsewhere. John asks for these recommendations to be
   added to the attribute spec, but I propose that we stick with handling them
   in the prose.
   - Pending council feedback, open a new ticket to address the question of
   documenting assumptions about whitespace normalization in the header
   - Open a new ticket to revise/edit for clarity the prose dealing with
   whitespace at 1.3.1.1.4. The prose as it stands is not wrong: it is
   consistent with what John asks for in this ticket, and covers the same
   ground, but it could be clearer and easier to read.

Best,

Becky

From lou.burnard at retired.ox.ac.uk  Wed Oct 24 05:54:40 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Wed, 24 Oct 2012 10:54:40 +0100
Subject: [tei-council] revised version of my Berlin visit report now online
In-Reply-To: <A09BAF91-5ADF-4027-8017-FD306DDE6F69@inria.fr>
References: <A8FFAE6E-E8B6-4B0A-AAB1-CB750CFD6657@inria.fr>
	<85E843E7-6252-4FBB-AA9C-ECE66BB1FE2C@inria.fr>
	<5086FCCC.70905@retired.ox.ac.uk>
	<A09BAF91-5ADF-4027-8017-FD306DDE6F69@inria.fr>
Message-ID: <5087BAE0.1040708@retired.ox.ac.uk>

thanks for corrections from laurent and felix!

http://www.tei-c.org/Activities/Council/Working/tcw25.xml



From James.Cummings at it.ox.ac.uk  Wed Oct 24 06:42:16 2012
From: James.Cummings at it.ox.ac.uk (James Cummings)
Date: Wed, 24 Oct 2012 11:42:16 +0100
Subject: [tei-council] rationalizing attributes on
	persName/placeName/orgName/name (3519806)
Message-ID: <5087C608.7050704@it.ox.ac.uk>

In implementing http://purl.org/tei/bug/3519806 to add 
att.datable to name, as I've been tasked to do I have the 
following proposal (that I will implement before the deadline 
today if no strenuous objections are made).

The current situation:
persName: att.global, att.datable, att.editLike, att.personal, 
att.typed
placeName: att.global, att.datable, att.editLike, att.naming, 
att.typed
orgName: att.global, att.datable, att.editLike, att.personal, 
att.typed
name: att.global, att.naming, att.personal, att.typed

Note that placeName and name claim membership of att.naming which 
provides @role ("may be used to specify further information about 
the entity referenced by this name") and @nymRef ("reference to 
the canonical name") but includes att.canonical.

Note that persName and orgName claim att.personal which provides 
@full ("indicates whether the name component is given in full") 
and @sort ("specifies the sort order") but includes att.naming 
and att.canonical.

Note that name claims membership in att.naming and att.personal 
(doesn't this mean it gets att.canonical twice?) and does not get 
att.editLike which all the rest get which provides @evidence, 
@source, and @instant.

My proposal: aside from removing a prose statement saying that 
@sort only refers to personal names (which seems weird to me), I 
would like to rationalize all of these.

I would suggest that name and placeName not claim membership in 
att.naming, but instead (the probably misnamed) att.personal. I 
would also have name claim membership in att.editLike.

This would result in all
persName: att.global, att.datable, att.editLike, att.naming, 
att.typed
placeName: att.global, att.datable, att.editLike, att.naming, 
att.typed
orgName: att.global, att.datable, att.editLike, att.naming, att.typed
name: att.global, att.datable, att.editLike, att.naming, att.typed

So all of these would get the same attributes. If I've understood 
correctly then no elements would lose attributes and name would 
become significantly richer and have the same attributes of the 
others. (Which means that our claim that <*Name> is syntactic 
sugar for <name type="*"> is closer to the truth.) If implemented 
I'll make sure the descriptions are consistent.

Does anyone have any objections to this? Or does anyone see any 
major pitfalls in terms of recursive class membership that I'm 
overlooking? (If so, I'll postpone until after release.)

-James

-- 
Dr James Cummings, researchsupport at it.ox.ac.uk
Research Support, IT Services, University of Oxford

From James.Cummings at it.ox.ac.uk  Wed Oct 24 07:44:27 2012
From: James.Cummings at it.ox.ac.uk (James Cummings)
Date: Wed, 24 Oct 2012 12:44:27 +0100
Subject: [tei-council] documenting xml:space
In-Reply-To: <CAA2irtKjjrGd-LYLtHUo8-7uGki+qM14nSJK7+s1E=3VW49r=A@mail.gmail.com>
References: <CAA2irtKjjrGd-LYLtHUo8-7uGki+qM14nSJK7+s1E=3VW49r=A@mail.gmail.com>
Message-ID: <5087D49B.1050300@it.ox.ac.uk>

On 24/10/12 03:36, Rebecca Welzenbach wrote:
> Here I think he means <encodingDesc>. This warrants discussion and perhaps
> its own ticket: do we want to expand <normalization> to include how the
> encoder expects a processor to handle whitespace? In addition, although it
> is not mentioned in the ticket, in his wiki page, John suggests that even
> in cases where no modification to whitespace normalization is expected,
> encoders should state this explicitly, rather than letting it be implied by
> omission. Do we agree?

That seems reasonable to me.

> I propose:
>     - Close this ticket. The things that John is asking for have been, or
>     are being, addressed elsewhere. John asks for these recommendations to be
>     added to the attribute spec, but I propose that we stick with handling them
>     in the prose.
>     - Pending council feedback, open a new ticket to address the question of
>     documenting assumptions about whitespace normalization in the header
>     - Open a new ticket to revise/edit for clarity the prose dealing with
>     whitespace at 1.3.1.1.4. The prose as it stands is not wrong: it is
>     consistent with what John asks for in this ticket, and covers the same
>     ground, but it could be clearer and easier to read.

I'd agree with that.

-James

-- 
Dr James Cummings, researchsupport at it.ox.ac.uk
Research Support, IT Services, University of Oxford

From mholmes at uvic.ca  Wed Oct 24 08:47:31 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Wed, 24 Oct 2012 05:47:31 -0700
Subject: [tei-council] documenting xml:space
In-Reply-To: <5087D49B.1050300@it.ox.ac.uk>
References: <CAA2irtKjjrGd-LYLtHUo8-7uGki+qM14nSJK7+s1E=3VW49r=A@mail.gmail.com>
	<5087D49B.1050300@it.ox.ac.uk>
Message-ID: <5087E363.5040307@uvic.ca>

On 12-10-24 04:44 AM, James Cummings wrote:
> On 24/10/12 03:36, Rebecca Welzenbach wrote:
>> Here I think he means <encodingDesc>. This warrants discussion and perhaps
>> its own ticket: do we want to expand <normalization> to include how the
>> encoder expects a processor to handle whitespace? In addition, although it
>> is not mentioned in the ticket, in his wiki page, John suggests that even
>> in cases where no modification to whitespace normalization is expected,
>> encoders should state this explicitly, rather than letting it be implied by
>> omission. Do we agree?
>
> That seems reasonable to me.

I see no harm in gently recommending it, but I'd be reluctant to make it 
any stronger than that.

>> I propose:
>>      - Close this ticket. The things that John is asking for have been, or
>>      are being, addressed elsewhere. John asks for these recommendations to be
>>      added to the attribute spec, but I propose that we stick with handling them
>>      in the prose.
>>      - Pending council feedback, open a new ticket to address the question of
>>      documenting assumptions about whitespace normalization in the header
>>      - Open a new ticket to revise/edit for clarity the prose dealing with
>>      whitespace at 1.3.1.1.4. The prose as it stands is not wrong: it is
>>      consistent with what John asks for in this ticket, and covers the same
>>      ground, but it could be clearer and easier to read.
>
> I'd agree with that.

If you're able to clean up the prose now, I'd have a go at it, and avoid 
the second new ticket.

Cheers,
Martin

-- 
Martin Holmes
mholmes at uvic.ca
UVic Humanities Computing and Media Centre

From gabriel.bodard at kcl.ac.uk  Wed Oct 24 11:06:50 2012
From: gabriel.bodard at kcl.ac.uk (Gabriel Bodard)
Date: Wed, 24 Oct 2012 16:06:50 +0100
Subject: [tei-council] the xpointer comments
In-Reply-To: <508701C2.4030606@retired.ox.ac.uk>
References: <50868490.70200@o2.pl> <5086956B.1070805@ultraslavonic.info>
	<5086BBA0.4040306@uvic.ca> <5086FF0D.3060704@o2.pl>
	<508701C2.4030606@retired.ox.ac.uk>
Message-ID: <5088040A.7010909@kcl.ac.uk>

Syd is the owner of the SOM list, so if anyone has any queries about 
whether they are on it or not (or would like to join) probably best to 
ping him.

On 23/10/2012 21:44, Lou Burnard wrote:
> Yeah, I thought I was subscribed to that list too, but this is the first
> I've heard of any messages on it.
>
> On 23/10/12 21:33, Piotr Banski wrote:
>> Hi Martin,
>>
>> Thanks for this info. I've either got a kick out of the list (it's
>> happened to me in the past, for excess bounces off my free server), or
>> I've managed to overlook that thread completely (been there as well).
>> Will verify.
>>
>>      P.
>>
>>
>>
>> On 23/10/12 17:45, Martin Holmes wrote:
>>> We have had some discussion on the TEI-SOM list following the Oxford
>>> meeting, starting here:
>>>
>>> <http://listserv.brown.edu/archives/cgi-bin/wa?A2=ind1209&L=tei-som&F=&S=&P=66>
>>>
>>> Gaby asked me to summarise my issues with it, which I did, and Hugh
>>> responded in some detail. In that discussion, I think this is the
>>> clearest statement of my position:
>>>
>>> <http://listserv.brown.edu/archives/cgi-bin/wa?A2=ind1209&L=tei-som&F=&S=&P=5669>
>>>
>>> and Hugh's response to that answers some of those objections, but
>>> largely by saying that much of what I worry about would be
>>> implementation-dependent and outside the scope of the specification. The
>>> implication seems to be that what you get when you process one of these
>>> pointers will differ radically depending on the implementation; that
>>> seems to me to be a fundamental problem, but clearly Hugh doesn't think so.
>>>
>>> Syd said he was going to look at the proposal, but it looks like he
>>> hasn't had time to do so yet. I also think his input is essential. I'm
>>> looking forward to seeing what comes out of the TEI meeting (which I
>>> can't attend, unfortunately).
>>>
>>> Cheers,
>>> Martin
>>>
>>> On 12-10-23 06:02 AM, Kevin Hawkins wrote:
>>>> I think the consensus in Oxford was that PB, LB, and GB would respond to
>>>> the draft proposal in Google Docs so that HC and/or others could submit
>>>> a revised proposal for Council to consider again.  However, if PB, LB,
>>>> and GB feel they can't respond to the draft in its current state, or
>>>> could do so more effectively if they just talked it over in person with
>>>> Hugh Cayless and Syd Bauman in person -- and if we know that they'll be
>>>> in College Station -- then I see no reason not to discuss it in person
>>>> with them instead.
>>>>
>>>> In any case, it's obviously not going to happen by the end of October.
>>>>
>>>> --K.
>>>>
>>>> On 10/23/12 7:50 AM, Piotr Banski wrote:
>>>>> In the wiki, at the top of the Actions page, we say:
>>>>>
>>>>> "Council members (e.g. PB, LB and GB) will add comments directly to HC?s
>>>>> original proposal by the end of October, and then we will be happy to
>>>>> receive any further drafts of it."
>>>>>
>>>>> http://wiki.tei-c.org/index.php/Oxford2012-Actions
>>>>>
>>>>> I was wondering: can we move this to the end of November, and first hear
>>>>> what Hugh has to say about that at the TEI-MM, and discuss it, at least
>>>>> in part, there on the spot?
>>>>>
>>>>> I'm now taking on my tickets, then it's release time, then the
>>>>> preparation for the MM talk and the SIG meeting (and I'm flying to the
>>>>> States very soon, it's a joint work trip), and I just can't see the
>>>>> possibility of getting down to preparing detailed remarks on this right
>>>>> now (there's the day job to be handled before the MM trip, too).
>>>>>
>>>>> On another note, I would really like to see Syd involved in this -- I
>>>>> believe his input to be quite crucial, given that he was the author of
>>>>> the original TEI XPointer schemes.
>>>>>
>>>>> I am not even sure of the status of Hugh's proposal in the googledoc --
>>>>> is this something submitted to the Council to act on, or is that an
>>>>> abstract of his MM talk? If the former were the case, I could understand
>>>>> why the Council would delegate its three members to handle it, but it
>>>>> seems to me to be a sketch of a proposal only, and so I don't understand
>>>>> why we should act on something that isn't in fact finalised before Hugh
>>>>> presents it at the MM:
>>>>>
>>>>> http://idhmc.tamu.edu/teiconference/program/papers/session-1b/
>>>>>
>>>>> So once again: can we say
>>>>> a) please submit a concrete proposal
>>>>> b) "end of November at the earliest"
>>>>> , there?
>>>>>
>>>>> Otherwise, it seems to me that we may act on this as fellow researchers
>>>>> and members of a WG, but not really in our capacity as members of the
>>>>> Council.
>>>>>
>>>>> Best,
>>>>>
>>>>>         P.
>>>>>
>

-- 
Dr Gabriel BODARD
(Research Associate in Digital Epigraphy)

Department of Digital Humanities
King's College London
26-29 Drury Lane
London WC2B 5RL

Email: gabriel.bodard at kcl.ac.uk
Tel: +44 (0)20 7848 1388
Fax: +44 (0)20 7848 2980

http://www.digitalclassicist.org/
http://www.currentepigraphy.org/


From rwelzenbach at gmail.com  Wed Oct 24 11:08:59 2012
From: rwelzenbach at gmail.com (Rebecca Welzenbach)
Date: Wed, 24 Oct 2012 11:08:59 -0400
Subject: [tei-council] documenting xml:space
In-Reply-To: <5087E363.5040307@uvic.ca>
References: <CAA2irtKjjrGd-LYLtHUo8-7uGki+qM14nSJK7+s1E=3VW49r=A@mail.gmail.com>
	<5087D49B.1050300@it.ox.ac.uk> <5087E363.5040307@uvic.ca>
Message-ID: <CAA2irtJjAToQ5i8_LeMrLNu3U1qAy19Jjxizoi-MxvwnxECYzA@mail.gmail.com>

>
> If you're able to clean up the prose now, I'd have a go at it, and avoid
> the second new ticket.
>
> Cheers,
> Martin
>
>
Good idea, Martin--I tried to do this last night and gave up (thus the
cop-out proposal) but have done it now, and the revised proposed language
is below. We're getting down to the wire now, but if it's acceptable I'll
put it in ASAP.

In reviewing this language closely I did find an important point of
conflict between the Guidelines and John's argument. The guidelines say
more than once that where whitespace characters are significant, XML "requires
that a processor preserve all of them." This suggests to me that if I
foolishly decide to use two spaces between all of my sentences in a <p>, I
can assume that each space character will be preserved by default. To the
contrary, John argues that in practice, many/most processors normalize
(collapse and trim) whitespace by default--so the space will be preserved,
but each whitespace character will not be.

I've hedged on this in my proposed revision by dropping "all of" from the
phrase "requires that a processor preserve all of them," but we should
clarify this. Can we agree on which behavior is really most likely to be
the "default"?

Proposed revision to the piece of
http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ST.html#index-body.1_div.1_div.3_div.1_div.1_div.4that
deals with whitespace:

The XML Recommendation defines *whitespace* as a single term for the space,
tab, and linebreak characters which may appear in a document. By default,
XML processors treat whitespace in predictable ways, depending on where it
occurs:


   - When whitespace characters occur as part of a text node, within the
   content of an element, XML generally considers them significant and
   requires that a processor preserve them.
   - When whitespace characters occur within an element that contains mixed
   content, that is, an element that contains both element and text nodes, XML
   assumes that they are significant and requires that a processor preserve
   them.
   - When whitespace characters occur between elements (not inside those
   elements or mixed with text), XML generally assumes that they are
*not* significant
   and may be ignored by an XML processor. This kind of whitespace is most
   commonly introduced by an encoder or by XML editing software to enhance the
   readability of the displayed text. This should only happen at locations
   where the whitespace can be reliably understood as insignificant (so there
   is no conflict with significant whitespace), but not all processors can
   detect this reliably.

The function of the xml:space attribute is to indicate whether the default
processing described above should be used (indicated by the value
?default?) or whether whitespace should be preserved (indicated by the
value ?preserve?) everywhere within the element on which it is used.
However, it is rarely necessary to do this: most TEI elements permit mixed
content, and consequently the presence or absence of whitespace is usually
significant in a TEI document. In most cases where whitespace may be
desired in the output, this should be indicated using native TEI elements
(such as <l>) to convey the structure of the text, with whitespace for
display introduced in processing, rather than by introducing whitespace
into the text and using xml:space=?preserve?. It is worth noting that while
the value of "preserve" on xml:space indicates the encoder's intention that
whitespace be preserved, not all processors will obey this.


There are a few situations in which it may be essential to use
xml:space=?preserve?, typically where complex markup is being used within
the context of a tool that by default introduces whitespace in order to
enhance display of the text. For example, when transcribing an inscription
with the elements described in chapter 11 Representation of Primary
Sources<http://www.tei-c.org/release/doc/tei-p5-doc/en/html/PH.html>,
a single word may well gain several additional tags to mark parts of the
word which are supplied or conjectural. Such tags do not interrupt the word
however, and hence introducing space where they occur would be misleading.
The value of preserve for the xml:space attribute on the parent
div<http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-div.html>
element
may be used to indicate that all and only the spaces actually present in
the XML source should be regarded as significant; an XML editor or other
processor is not then permitted to introduce additional spaces.

From mholmes at uvic.ca  Wed Oct 24 11:41:16 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Wed, 24 Oct 2012 08:41:16 -0700
Subject: [tei-council] rationalizing attributes on
 persName/placeName/orgName/name (3519806)
In-Reply-To: <5087C608.7050704@it.ox.ac.uk>
References: <5087C608.7050704@it.ox.ac.uk>
Message-ID: <50880C1C.5070500@uvic.ca>

This all looks really good to me. I'm intrigued as to why <name> getting 
att.canonical twice didn't cause errors before, but perhaps ODD 
processing is robust enough to handle that now. Kudos to Sebastian, if so.

Cheers,
Martin

On 12-10-24 03:42 AM, James Cummings wrote:
> In implementing http://purl.org/tei/bug/3519806 to add
> att.datable to name, as I've been tasked to do I have the
> following proposal (that I will implement before the deadline
> today if no strenuous objections are made).
>
> The current situation:
> persName: att.global, att.datable, att.editLike, att.personal,
> att.typed
> placeName: att.global, att.datable, att.editLike, att.naming,
> att.typed
> orgName: att.global, att.datable, att.editLike, att.personal,
> att.typed
> name: att.global, att.naming, att.personal, att.typed
>
> Note that placeName and name claim membership of att.naming which
> provides @role ("may be used to specify further information about
> the entity referenced by this name") and @nymRef ("reference to
> the canonical name") but includes att.canonical.
>
> Note that persName and orgName claim att.personal which provides
> @full ("indicates whether the name component is given in full")
> and @sort ("specifies the sort order") but includes att.naming
> and att.canonical.
>
> Note that name claims membership in att.naming and att.personal
> (doesn't this mean it gets att.canonical twice?) and does not get
> att.editLike which all the rest get which provides @evidence,
> @source, and @instant.
>
> My proposal: aside from removing a prose statement saying that
> @sort only refers to personal names (which seems weird to me), I
> would like to rationalize all of these.
>
> I would suggest that name and placeName not claim membership in
> att.naming, but instead (the probably misnamed) att.personal. I
> would also have name claim membership in att.editLike.
>
> This would result in all
> persName: att.global, att.datable, att.editLike, att.naming,
> att.typed
> placeName: att.global, att.datable, att.editLike, att.naming,
> att.typed
> orgName: att.global, att.datable, att.editLike, att.naming, att.typed
> name: att.global, att.datable, att.editLike, att.naming, att.typed
>
> So all of these would get the same attributes. If I've understood
> correctly then no elements would lose attributes and name would
> become significantly richer and have the same attributes of the
> others. (Which means that our claim that <*Name> is syntactic
> sugar for <name type="*"> is closer to the truth.) If implemented
> I'll make sure the descriptions are consistent.
>
> Does anyone have any objections to this? Or does anyone see any
> major pitfalls in terms of recursive class membership that I'm
> overlooking? (If so, I'll postpone until after release.)
>
> -James
>

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From mholmes at uvic.ca  Wed Oct 24 12:19:27 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Wed, 24 Oct 2012 09:19:27 -0700
Subject: [tei-council] documenting xml:space
In-Reply-To: <CAA2irtJjAToQ5i8_LeMrLNu3U1qAy19Jjxizoi-MxvwnxECYzA@mail.gmail.com>
References: <CAA2irtKjjrGd-LYLtHUo8-7uGki+qM14nSJK7+s1E=3VW49r=A@mail.gmail.com>
	<5087D49B.1050300@it.ox.ac.uk>	<5087E363.5040307@uvic.ca>
	<CAA2irtJjAToQ5i8_LeMrLNu3U1qAy19Jjxizoi-MxvwnxECYzA@mail.gmail.com>
Message-ID: <5088150F.9060908@uvic.ca>

On 12-10-24 08:08 AM, Rebecca Welzenbach wrote:
>     If you're able to clean up the prose now, I'd have a go at it, and avoid
>     the second new ticket.
>
>     Cheers,
>     Martin
>
> Good idea, Martin--I tried to do this last night and gave up (thus the
> cop-out proposal) but have done it now, and the revised proposed
> language is below. We're getting down to the wire now, but if it's
> acceptable I'll put it in ASAP.
>
> In reviewing this language closely I did find an important point of
> conflict between the Guidelines and John's argument. The guidelines say
> more than once that where whitespace characters are significant, XML
> "requires that a processor preserve all of them." This suggests to me
> that if I foolishly decide to use two spaces between all of my sentences
> in a <p>, I can assume that each space character will be preserved by
> default. To the contrary, John argues that in practice, many/most
> processors normalize (collapse and trim) whitespace by default--so the
> space will be preserved, but each whitespace character will not be.
>
> I've hedged on this in my proposed revision by dropping "all of" from
> the phrase "requires that a processor preserve all of them," but we
> should clarify this. Can we agree on which behavior is really most
> likely to be the "default"?

Both the XML 1.0 and 1.1 specs are identical in what they say about 
whitespace, and they would seem to agree with "all of":

"An XML processor MUST always pass all characters in a document that are 
not markup through to the application. A validating XML processor MUST 
also inform the application which of these characters constitute white 
space appearing in element content.
[...]
"...the value "preserve" indicates the intent that applications preserve 
all the white space."

<http://www.w3.org/TR/xml11/#sec-white-space>

The normalization of whitespace (collapsing whitespace sequences to 
single instances of whitespace) is not the behaviour typically required 
when you use "preserve"; one of the examples given in the spec is the 
(presumably XHTML) <pre> element, in which whitespace-based linebreaks 
and indenting are expected to be retained, so normalization would be 
wrong. So I think the existing "all of" should be retained.

Other than that, I think the text below is fine.

It might also be worth doing here what we've been doing elsewhere (e.g. 
with the language subcodes), and instead of trying to paraphrase and 
explain the specification, just point to it.

Cheers,
Martin


>
> Proposed revision to the piece of
> http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ST.html#index-body.1_div.1_div.3_div.1_div.1_div.4
> that deals with whitespace:
>
> The XML Recommendation defines /whitespace/ as a single term for the
> space, tab, and linebreak characters which may appear in a document. By
> default, XML processors treat whitespace in predictable ways, depending
> on where it occurs:
>
>   * When whitespace characters occur as part of a text node, within the
>     content of an element, XML generally considers them significant and
>     requires that a processor preserve them.
>   * When whitespace characters occur within an element that contains
>     mixed content, that is, an element that contains both element and
>     text nodes, XML assumes that they are significant and requires that
>     a processor preserve them.
>   * When whitespace characters occur between elements (not inside those
>     elements or mixed with text), XML generally assumes that they are
>     /not/ significant and may be ignored by an XML processor. This kind
>     of whitespace is most commonly introduced by an encoder or by XML
>     editing software to enhance the readability of the displayed text.
>     This should only happen at locations where the whitespace can be
>     reliably understood as insignificant (so there is no conflict with
>     significant whitespace), but not all processors can detect this
>     reliably.
>
> The function of the xml:space attribute is to indicate whether the
> default processing described above should be used (indicated by the
> value ?default?) or whether whitespace should be preserved (indicated by
> the value ?preserve?) everywhere within the element on which it is used.
> However, it is rarely necessary to do this: most TEI elements permit
> mixed content, and consequently the presence or absence of whitespace is
> usually significant in a TEI document. In most cases where whitespace
> may be desired in the output, this should be indicated using native TEI
> elements (such as <l>) to convey the structure of the text, with
> whitespace for display introduced in processing, rather than by
> introducing whitespace into the text and using xml:space=?preserve?. It
> is worth noting that while the value of "preserve" on xml:space
> indicates the encoder's intention that whitespace be preserved, not all
> processors will obey this.
>
>
> There are a few situations in which it may be essential to use
> xml:space=?preserve?, typically where complex markup is being used
> within the context of a tool that by default introduces whitespace in
> order to enhance display of the text. For example, when transcribing an
> inscription with the elements described in chapter 11 Representation of
> Primary Sources
> <http://www.tei-c.org/release/doc/tei-p5-doc/en/html/PH.html>, a single
> word may well gain several additional tags to mark parts of the word
> which are supplied or conjectural. Such tags do not interrupt the word
> however, and hence introducing space where they occur would be
> misleading. The value of preserve for the xml:space attribute on the
> parent div
> <http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-div.html> element
> may be used to indicate that all and only the spaces actually present in
> the XML source should be regarded as significant; an XML editor or other
> processor is not then permitted to introduce additional spaces.
>

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From James.Cummings at it.ox.ac.uk  Wed Oct 24 12:22:04 2012
From: James.Cummings at it.ox.ac.uk (James Cummings)
Date: Wed, 24 Oct 2012 17:22:04 +0100
Subject: [tei-council] rationalizing attributes on
 persName/placeName/orgName/name (3519806)
In-Reply-To: <50880C1C.5070500@uvic.ca>
References: <5087C608.7050704@it.ox.ac.uk> <50880C1C.5070500@uvic.ca>
Message-ID: <508815AC.7030408@it.ox.ac.uk>

On 24/10/12 16:41, Martin Holmes wrote:
> This all looks really good to me. I'm intrigued as to why <name> getting
> att.canonical twice didn't cause errors before, but perhaps ODD
> processing is robust enough to handle that now. Kudos to Sebastian, if so.

Actually I think that was my mistake... name claims membership in 
att.personal(att.naming), so gets att.canonical only once (from 
att.naming's membership in it).

Will go and implement this in principle, though I note your 
Jenkins is currently claiming something is broken somewhere.

-James

>
> Cheers,
> Martin
>
> On 12-10-24 03:42 AM, James Cummings wrote:
>> In implementing http://purl.org/tei/bug/3519806 to add
>> att.datable to name, as I've been tasked to do I have the
>> following proposal (that I will implement before the deadline
>> today if no strenuous objections are made).
>>
>> The current situation:
>> persName: att.global, att.datable, att.editLike, att.personal,
>> att.typed
>> placeName: att.global, att.datable, att.editLike, att.naming,
>> att.typed
>> orgName: att.global, att.datable, att.editLike, att.personal,
>> att.typed
>> name: att.global, att.naming, att.personal, att.typed
>>
>> Note that placeName and name claim membership of att.naming which
>> provides @role ("may be used to specify further information about
>> the entity referenced by this name") and @nymRef ("reference to
>> the canonical name") but includes att.canonical.
>>
>> Note that persName and orgName claim att.personal which provides
>> @full ("indicates whether the name component is given in full")
>> and @sort ("specifies the sort order") but includes att.naming
>> and att.canonical.
>>
>> Note that name claims membership in att.naming and att.personal
>> (doesn't this mean it gets att.canonical twice?) and does not get
>> att.editLike which all the rest get which provides @evidence,
>> @source, and @instant.
>>
>> My proposal: aside from removing a prose statement saying that
>> @sort only refers to personal names (which seems weird to me), I
>> would like to rationalize all of these.
>>
>> I would suggest that name and placeName not claim membership in
>> att.naming, but instead (the probably misnamed) att.personal. I
>> would also have name claim membership in att.editLike.
>>
>> This would result in all
>> persName: att.global, att.datable, att.editLike, att.naming,
>> att.typed
>> placeName: att.global, att.datable, att.editLike, att.naming,
>> att.typed
>> orgName: att.global, att.datable, att.editLike, att.naming, att.typed
>> name: att.global, att.datable, att.editLike, att.naming, att.typed
>>
>> So all of these would get the same attributes. If I've understood
>> correctly then no elements would lose attributes and name would
>> become significantly richer and have the same attributes of the
>> others. (Which means that our claim that <*Name> is syntactic
>> sugar for <name type="*"> is closer to the truth.) If implemented
>> I'll make sure the descriptions are consistent.
>>
>> Does anyone have any objections to this? Or does anyone see any
>> major pitfalls in terms of recursive class membership that I'm
>> overlooking? (If so, I'll postpone until after release.)
>>
>> -James
>>
>


-- 
Dr James Cummings, researchsupport at it.ox.ac.uk
Research Support, IT Services, University of Oxford

From sebastian.rahtz at it.ox.ac.uk  Wed Oct 24 12:32:17 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Wed, 24 Oct 2012 16:32:17 +0000
Subject: [tei-council] rationalizing attributes on
 persName/placeName/orgName/name (3519806)
In-Reply-To: <50880C1C.5070500@uvic.ca>
References: <5087C608.7050704@it.ox.ac.uk> <50880C1C.5070500@uvic.ca>
Message-ID: <70EA5E1D-3FEC-4009-864A-577648DE9927@it.ox.ac.uk>

if you're saying "they all get all possible attributes" then I'm ok with that
--
Sebastian Rahtz      
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431


From mholmes at uvic.ca  Wed Oct 24 12:42:30 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Wed, 24 Oct 2012 09:42:30 -0700
Subject: [tei-council] rationalizing attributes on
 persName/placeName/orgName/name (3519806)
In-Reply-To: <508815AC.7030408@it.ox.ac.uk>
References: <5087C608.7050704@it.ox.ac.uk> <50880C1C.5070500@uvic.ca>
	<508815AC.7030408@it.ox.ac.uk>
Message-ID: <50881A76.7050109@uvic.ca>

My Jinks build of P5-Documentation failed because of an SVN connection 
failure -- looks like Sourceforge isn't quite back to normal yet. But 
when the current build of P5-Test is done, it'll kick off another 
Documentation build, and hopefully that'll complete OK.

Cheers,
Martin

On 12-10-24 09:22 AM, James Cummings wrote:
> On 24/10/12 16:41, Martin Holmes wrote:
>> This all looks really good to me. I'm intrigued as to why <name> getting
>> att.canonical twice didn't cause errors before, but perhaps ODD
>> processing is robust enough to handle that now. Kudos to Sebastian, if so.
>
> Actually I think that was my mistake... name claims membership in
> att.personal(att.naming), so gets att.canonical only once (from
> att.naming's membership in it).
>
> Will go and implement this in principle, though I note your
> Jenkins is currently claiming something is broken somewhere.
>
> -James
>
>>
>> Cheers,
>> Martin
>>
>> On 12-10-24 03:42 AM, James Cummings wrote:
>>> In implementing http://purl.org/tei/bug/3519806 to add
>>> att.datable to name, as I've been tasked to do I have the
>>> following proposal (that I will implement before the deadline
>>> today if no strenuous objections are made).
>>>
>>> The current situation:
>>> persName: att.global, att.datable, att.editLike, att.personal,
>>> att.typed
>>> placeName: att.global, att.datable, att.editLike, att.naming,
>>> att.typed
>>> orgName: att.global, att.datable, att.editLike, att.personal,
>>> att.typed
>>> name: att.global, att.naming, att.personal, att.typed
>>>
>>> Note that placeName and name claim membership of att.naming which
>>> provides @role ("may be used to specify further information about
>>> the entity referenced by this name") and @nymRef ("reference to
>>> the canonical name") but includes att.canonical.
>>>
>>> Note that persName and orgName claim att.personal which provides
>>> @full ("indicates whether the name component is given in full")
>>> and @sort ("specifies the sort order") but includes att.naming
>>> and att.canonical.
>>>
>>> Note that name claims membership in att.naming and att.personal
>>> (doesn't this mean it gets att.canonical twice?) and does not get
>>> att.editLike which all the rest get which provides @evidence,
>>> @source, and @instant.
>>>
>>> My proposal: aside from removing a prose statement saying that
>>> @sort only refers to personal names (which seems weird to me), I
>>> would like to rationalize all of these.
>>>
>>> I would suggest that name and placeName not claim membership in
>>> att.naming, but instead (the probably misnamed) att.personal. I
>>> would also have name claim membership in att.editLike.
>>>
>>> This would result in all
>>> persName: att.global, att.datable, att.editLike, att.naming,
>>> att.typed
>>> placeName: att.global, att.datable, att.editLike, att.naming,
>>> att.typed
>>> orgName: att.global, att.datable, att.editLike, att.naming, att.typed
>>> name: att.global, att.datable, att.editLike, att.naming, att.typed
>>>
>>> So all of these would get the same attributes. If I've understood
>>> correctly then no elements would lose attributes and name would
>>> become significantly richer and have the same attributes of the
>>> others. (Which means that our claim that <*Name> is syntactic
>>> sugar for <name type="*"> is closer to the truth.) If implemented
>>> I'll make sure the descriptions are consistent.
>>>
>>> Does anyone have any objections to this? Or does anyone see any
>>> major pitfalls in terms of recursive class membership that I'm
>>> overlooking? (If so, I'll postpone until after release.)
>>>
>>> -James
>>>
>>
>
>

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From James.Cummings at it.ox.ac.uk  Wed Oct 24 12:42:53 2012
From: James.Cummings at it.ox.ac.uk (James Cummings)
Date: Wed, 24 Oct 2012 17:42:53 +0100
Subject: [tei-council] rationalizing attributes on
 persName/placeName/orgName/name (3519806)
In-Reply-To: <70EA5E1D-3FEC-4009-864A-577648DE9927@it.ox.ac.uk>
References: <5087C608.7050704@it.ox.ac.uk> <50880C1C.5070500@uvic.ca>
	<70EA5E1D-3FEC-4009-864A-577648DE9927@it.ox.ac.uk>
Message-ID: <50881A8D.3050300@it.ox.ac.uk>

On 24/10/12 17:32, Sebastian Rahtz wrote:
> if you're saying "they all get all possible attributes" then I'm ok with that

I think that is what should happen. (my message was unclear in 
that I reverse att.naming and att.personal, they should have 
att.personal which gets them att.naming).

  I've just committed this change which changes 
name/orgName/persName/placeName to have identical attribute class 
membership, and removed the prose restriction on @sort from 
att.personal to only be about personal names.

Let's see what (new) breaks...

-James

-- 
Dr James Cummings, researchsupport at it.ox.ac.uk
Research Support, IT Services, University of Oxford

From James.Cummings at it.ox.ac.uk  Wed Oct 24 14:00:02 2012
From: James.Cummings at it.ox.ac.uk (James Cummings)
Date: Wed, 24 Oct 2012 19:00:02 +0100
Subject: [tei-council] rationalizing attributes on
 persName/placeName/orgName/name (3519806)
In-Reply-To: <50881A8D.3050300@it.ox.ac.uk>
References: <5087C608.7050704@it.ox.ac.uk> <50880C1C.5070500@uvic.ca>
	<70EA5E1D-3FEC-4009-864A-577648DE9927@it.ox.ac.uk>
	<50881A8D.3050300@it.ox.ac.uk>
Message-ID: <50882CA2.7000506@it.ox.ac.uk>

On 24/10/12 17:42, James Cummings wrote:
>    I've just committed this change which changes
> name/orgName/persName/placeName to have identical attribute class
> membership, and removed the prose restriction on @sort from
> att.personal to only be about personal names.
>
> Let's see what (new) breaks...

It seems this doesn't break anything and new changes seem to have 
worked at
http://teijenkins.hcmc.uvic.ca:8080/job/TEIP5-Documentation/lastSuccessfulBuild/artifact/Guidelines-web/en/html/ref-name.html

I'll go through the Names, (Dates,) People, and Places chapter to 
see if there is any obvious related prose that needs changing.

-James

-- 
Dr James Cummings, researchsupport at it.ox.ac.uk
Research Support, IT Services, University of Oxford

From bansp at o2.pl  Wed Oct 24 15:50:53 2012
From: bansp at o2.pl (Piotr Banski)
Date: Wed, 24 Oct 2012 21:50:53 +0200
Subject: [tei-council] easier said...
Message-ID: <5088469D.7020507@o2.pl>

Hi Council,

What would you do if you had to add a little <ref name="model.global"/> 
to the following:

<content>
     <rng:group>
       <rng:zeroOrMore>
         <rng:ref name="model.headLike"/>
       </rng:zeroOrMore>
       <rng:choice>
         <rng:group>
           <rng:zeroOrMore>
             <rng:ref name="model.pLike"/>
           </rng:zeroOrMore>
         </rng:group>
         <rng:zeroOrMore>
           <rng:choice>
             <rng:ref name="model.labelLike"/>
             <rng:ref name="model.placeStateLike"/>
             <rng:ref name="model.placeEventLike"/>
           </rng:choice>
         </rng:zeroOrMore>
       </rng:choice>
       <rng:zeroOrMore>
         <rng:choice>
           <rng:ref name="model.noteLike"/>
           <rng:ref name="model.biblLike"/>
           <rng:ref name="idno"/>
         </rng:choice>
       </rng:zeroOrMore>
       <rng:zeroOrMore>
         <rng:choice>
           <rng:ref name="model.placeLike"/>
           <rng:ref name="listPlace"/>
         </rng:choice>
       </rng:zeroOrMore>
     </rng:group>
   </content>

?

I realize that using common sense is a fine strategy, but do we have any 
kind of best practice in such cases? (No.)

Whatever I do, I make a choice that I am not so sure I was licensed to 
do, at least a choice concerning the relative ordering of elements.

In the case at hand, I am inclined to just put yet another <zeroOrMore> 
at the end of the group, to be maximally permissive about the possible 
links, given that we didn't have any clear use cases when going for this 
solution (it's about #3060867 [1]).

Good/OK/bad/horrible?

Thanks,

   Piotr

PS. (I know: it's late :-/ )

[1]: 
http://sourceforge.net/tracker/index.php?func=detail&group_id=106328&atid=644065&aid=3060867

From sebastian.rahtz at it.ox.ac.uk  Wed Oct 24 16:49:15 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Wed, 24 Oct 2012 20:49:15 +0000
Subject: [tei-council] easier said...
In-Reply-To: <5088469D.7020507@o2.pl>
References: <5088469D.7020507@o2.pl>
Message-ID: <AA70119F-4BD8-4E96-9F12-882FED95BC49@it.ox.ac.uk>


On 24 Oct 2012, at 20:50, Piotr Banski <bansp at o2.pl>
 wrote:

> 

> What would you do if you had to add a little <ref name="model.global"/> 
> to the following:
> 
depends where you want it to occur. literally anywhere? before the possible <head>?
you need to specify the algorithm more precisely...


--
Sebastian Rahtz      
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431


From mholmes at uvic.ca  Wed Oct 24 17:19:36 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Wed, 24 Oct 2012 14:19:36 -0700
Subject: [tei-council] easier said...
In-Reply-To: <AA70119F-4BD8-4E96-9F12-882FED95BC49@it.ox.ac.uk>
References: <5088469D.7020507@o2.pl>
	<AA70119F-4BD8-4E96-9F12-882FED95BC49@it.ox.ac.uk>
Message-ID: <50885B68.2000103@uvic.ca>

I'm not sure how this relates to the ticket you linked to -- what 
content model are you trying to add model.global to, and why?

It seems to have caused the testbasic to fail on Jinks, though, 
presumably due to a non-deterministic content model.

Cheers,
Martin

On 12-10-24 01:49 PM, Sebastian Rahtz wrote:
>
> On 24 Oct 2012, at 20:50, Piotr Banski <bansp at o2.pl>
>   wrote:
>
>>
>
>> What would you do if you had to add a little <ref name="model.global"/>
>> to the following:
>>
> depends where you want it to occur. literally anywhere? before the possible <head>?
> you need to specify the algorithm more precisely...
>
>
> --
> Sebastian Rahtz
> Director (Research Support) of Academic IT Services
> University of Oxford IT Services
> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From bansp at o2.pl  Wed Oct 24 17:27:36 2012
From: bansp at o2.pl (Piotr Banski)
Date: Wed, 24 Oct 2012 23:27:36 +0200
Subject: [tei-council] easier said...
In-Reply-To: <50885B68.2000103@uvic.ca>
References: <5088469D.7020507@o2.pl>
	<AA70119F-4BD8-4E96-9F12-882FED95BC49@it.ox.ac.uk>
	<50885B68.2000103@uvic.ca>
Message-ID: <50885D48.2060102@o2.pl>

Oh gosh, thanks, Martin -- I was trying to be fast and clever, and ended 
up neither.

Firstly, I've withdrawn the mods now, and secondly, I went too high in 
the hierarchy -- I didn't really want model.global there, indeed.

Thanks, I'm trying to switch thinking mode on now, something's got rusty 
there.

Best,

   P.


On 24/10/12 23:19, Martin Holmes wrote:
> I'm not sure how this relates to the ticket you linked to -- what
> content model are you trying to add model.global to, and why?
>
> It seems to have caused the testbasic to fail on Jinks, though,
> presumably due to a non-deterministic content model.
>
> Cheers,
> Martin
>
> On 12-10-24 01:49 PM, Sebastian Rahtz wrote:
>>
>> On 24 Oct 2012, at 20:50, Piotr Banski <bansp at o2.pl>
>>    wrote:
>>
>>>
>>
>>> What would you do if you had to add a little <ref name="model.global"/>
>>> to the following:
>>>
>> depends where you want it to occur. literally anywhere? before the possible <head>?
>> you need to specify the algorithm more precisely...
>>
>>
>> --
>> Sebastian Rahtz
>> Director (Research Support) of Academic IT Services
>> University of Oxford IT Services
>> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>>
>


From sebastian.rahtz at it.ox.ac.uk  Wed Oct 24 17:30:59 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Wed, 24 Oct 2012 21:30:59 +0000
Subject: [tei-council] easier said...
In-Reply-To: <5088469D.7020507@o2.pl>
References: <5088469D.7020507@o2.pl>
Message-ID: <79E4CCB4-2F8B-4AB3-AD59-93492DFC4646@it.ox.ac.uk>

> In the case at hand, I am inclined to just put yet another <zeroOrMore> 
> at the end of the group, to be maximally permissive about the possible 
> links, given that we didn't have any clear use cases when going for this 
> solution (it's about #3060867 [1]).
> 
> Good/OK/bad/horrible?


the ticket wording says

" We should add link/linkGrp to <place> and <org> for consistency."

so I think you want to add them into here

     <rng:zeroOrMore>
        <rng:choice>
          <rng:ref name="model.noteLike"/>
          <rng:ref name="model.biblLike"/>
          <rng:ref name="idno"/>
        </rng:choice>
      </rng:zeroOrMore>

as the links are like notes and bibls

I strongly recommend not doing anything with model.global
unless you have a lot of time and patience to spare. the
day before a release is the worst time for delicate surgery
on content models :-}
--
Sebastian Rahtz      
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431


From bansp at o2.pl  Wed Oct 24 17:34:56 2012
From: bansp at o2.pl (Piotr Banski)
Date: Wed, 24 Oct 2012 23:34:56 +0200
Subject: [tei-council] easier said...
In-Reply-To: <79E4CCB4-2F8B-4AB3-AD59-93492DFC4646@it.ox.ac.uk>
References: <5088469D.7020507@o2.pl>
	<79E4CCB4-2F8B-4AB3-AD59-93492DFC4646@it.ox.ac.uk>
Message-ID: <50885F00.2040109@o2.pl>

Hi Sebastian,

On 24/10/12 23:30, Sebastian Rahtz wrote:
[...]
> " We should add link/linkGrp to <place> and <org> for consistency."
>
> so I think you want to add them into here
[...]
 > as the links are like notes and bibls

Thanks.

> I strongly recommend not doing anything with model.global
> unless you have a lot of time and patience to spare. the
> day before a release is the worst time for delicate surgery
> on content models :-}

Yup, apologies. Woke up now.

   P.



From sebastian.rahtz at it.ox.ac.uk  Wed Oct 24 17:39:46 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Wed, 24 Oct 2012 21:39:46 +0000
Subject: [tei-council] easier said...
In-Reply-To: <50885F00.2040109@o2.pl>
References: <5088469D.7020507@o2.pl>
	<79E4CCB4-2F8B-4AB3-AD59-93492DFC4646@it.ox.ac.uk>
	<50885F00.2040109@o2.pl>
Message-ID: <402EC9B2-7937-40CB-9410-46125AB210FF@it.ox.ac.uk>

sadly you may have to hardwire <link> and <linkGrp> in alongside idno, as they
don't form part of an appropriate class.

unless you can argue for model.global.meta, and the things that implies:

../../P5/Source/Specs/alt.xml:    <memberOf key="model.global.meta"/>
../../P5/Source/Specs/altGrp.xml:    <memberOf key="model.global.meta"/>
../../P5/Source/Specs/certainty.xml:    <memberOf key="model.global.meta"/>
../../P5/Source/Specs/fLib.xml:    <memberOf key="model.global.meta"/>
../../P5/Source/Specs/fs.xml:    <memberOf key="model.global.meta"/>
../../P5/Source/Specs/fvLib.xml:    <memberOf key="model.global.meta"/>
../../P5/Source/Specs/index.xml:    <memberOf key="model.global.meta"/>
../../P5/Source/Specs/interp.xml:    <memberOf key="model.global.meta"/>
../../P5/Source/Specs/interpGrp.xml:    <memberOf key="model.global.meta"/>
../../P5/Source/Specs/join.xml:    <memberOf key="model.global.meta"/>
../../P5/Source/Specs/joinGrp.xml:    <memberOf key="model.global.meta"/>
../../P5/Source/Specs/link.xml:    <memberOf key="model.global.meta"/>
../../P5/Source/Specs/linkGrp.xml:    <memberOf key="model.global.meta"/>
../../P5/Source/Specs/precision.xml:    <memberOf key="model.global.meta"/>
../../P5/Source/Specs/respons.xml:    <memberOf key="model.global.meta"/>
../../P5/Source/Specs/span.xml:    <memberOf key="model.global.meta"/>
../../P5/Source/Specs/spanGrp.xml:    <memberOf key="model.global.meta"/>
../../P5/Source/Specs/substJoin.xml:    <memberOf key="model.global.meta"/>
../../P5/Source/Specs/timeline.xml:    <memberOf key="model.global.meta"/>

which you may indeed like.  But I suspect thats a stage too far.
--
Sebastian Rahtz      
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431


From bansp at o2.pl  Wed Oct 24 17:57:49 2012
From: bansp at o2.pl (Piotr Banski)
Date: Wed, 24 Oct 2012 23:57:49 +0200
Subject: [tei-council] easier said...
In-Reply-To: <402EC9B2-7937-40CB-9410-46125AB210FF@it.ox.ac.uk>
References: <5088469D.7020507@o2.pl>
	<79E4CCB4-2F8B-4AB3-AD59-93492DFC4646@it.ox.ac.uk>
	<50885F00.2040109@o2.pl>
	<402EC9B2-7937-40CB-9410-46125AB210FF@it.ox.ac.uk>
Message-ID: <5088645D.9040501@o2.pl>

On 24/10/12 23:39, Sebastian Rahtz wrote:
> sadly you may have to hardwire <link> and <linkGrp> in alongside idno, as they
> don't form part of an appropriate class.

I did and it looks like something has gone wrong anyway, will have a 
look now. I'm looking at both Jenkinses, and they are as usual subtly 
different in how fast they react, so I'm getting a mix of success and 
failure e-mail now ;-)

(both meaning uvic.ca and ox.ac.uk)

> unless you can argue for model.global.meta, and the things that implies:

As you said below, I think that for now, it may be too far.

   P.

From sebastian.rahtz at it.ox.ac.uk  Wed Oct 24 18:00:40 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Wed, 24 Oct 2012 22:00:40 +0000
Subject: [tei-council] easier said...
In-Reply-To: <5088645D.9040501@o2.pl>
References: <5088469D.7020507@o2.pl>
	<79E4CCB4-2F8B-4AB3-AD59-93492DFC4646@it.ox.ac.uk>
	<50885F00.2040109@o2.pl>
	<402EC9B2-7937-40CB-9410-46125AB210FF@it.ox.ac.uk>
	<5088645D.9040501@o2.pl>
Message-ID: <79A0B036-8F82-4CAA-9D07-1F48ABEBD614@it.ox.ac.uk>

that error may be mine, Piotr, hang on...
--
Sebastian Rahtz      
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431


From sebastian.rahtz at it.ox.ac.uk  Wed Oct 24 18:04:05 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Wed, 24 Oct 2012 22:04:05 +0000
Subject: [tei-council] easier said...
In-Reply-To: <5088645D.9040501@o2.pl>
References: <5088469D.7020507@o2.pl>
	<79E4CCB4-2F8B-4AB3-AD59-93492DFC4646@it.ox.ac.uk>
	<50885F00.2040109@o2.pl>
	<402EC9B2-7937-40CB-9410-46125AB210FF@it.ox.ac.uk>
	<5088645D.9040501@o2.pl>
Message-ID: <36FE595F-B6A0-44E2-B897-0A71AACCB42B@it.ox.ac.uk>

yes, my fault. fixing, many apologies. Blame Torsten....
--
Sebastian Rahtz      
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431


From bansp at o2.pl  Wed Oct 24 18:08:26 2012
From: bansp at o2.pl (Piotr Banski)
Date: Thu, 25 Oct 2012 00:08:26 +0200
Subject: [tei-council] easier said...
In-Reply-To: <36FE595F-B6A0-44E2-B897-0A71AACCB42B@it.ox.ac.uk>
References: <5088469D.7020507@o2.pl>
	<79E4CCB4-2F8B-4AB3-AD59-93492DFC4646@it.ox.ac.uk>
	<50885F00.2040109@o2.pl>
	<402EC9B2-7937-40CB-9410-46125AB210FF@it.ox.ac.uk>
	<5088645D.9040501@o2.pl>
	<36FE595F-B6A0-44E2-B897-0A71AACCB42B@it.ox.ac.uk>
Message-ID: <508866DA.6010009@o2.pl>

On 25/10/12 00:04, Sebastian Rahtz wrote:
> yes, my fault. fixing, many apologies. Blame Torsten....

Uff ;-) I looked at the console output and just couldn't figure out what 
was possibly wrong there.

Thanks, as usual (!)

   P.

From sebastian.rahtz at it.ox.ac.uk  Wed Oct 24 18:13:26 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Wed, 24 Oct 2012 22:13:26 +0000
Subject: [tei-council] easier said...
In-Reply-To: <508866DA.6010009@o2.pl>
References: <5088469D.7020507@o2.pl>
	<79E4CCB4-2F8B-4AB3-AD59-93492DFC4646@it.ox.ac.uk>
	<50885F00.2040109@o2.pl>
	<402EC9B2-7937-40CB-9410-46125AB210FF@it.ox.ac.uk>
	<5088645D.9040501@o2.pl>
	<36FE595F-B6A0-44E2-B897-0A71AACCB42B@it.ox.ac.uk>
	<508866DA.6010009@o2.pl>
Message-ID: <7B6C4982-B205-4658-AE6E-629164E56BF9@it.ox.ac.uk>


On 24 Oct 2012, at 23:08, Piotr Banski <bansp at o2.pl>
 wrote:

>> yes, my fault. fixing, many apologies. Blame Torsten....
> 
> Uff ;-) I looked at the console output and just couldn't figure out what was possibly wrong there.
> 

it was all about multiple values for attributes. pretend you didnt see.

--
Sebastian Rahtz      
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431


From bansp at o2.pl  Thu Oct 25 06:06:55 2012
From: bansp at o2.pl (Piotr Banski)
Date: Thu, 25 Oct 2012 12:06:55 +0200
Subject: [tei-council] datcat's ugly head
Message-ID: <50890F3F.8010100@o2.pl>

May I ask the Council to have a quick look at

https://sourceforge.net/tracker/?func=detail&atid=644062&aid=3569990&group_id=106328

?

I'm a bit afraid that I'm trying to put a stick in our wheel, with a 
chance to succeed :-/

The issue is the semantics of <fDecl> with dcr:datcat on it. I'm a bit 
afraid it's like putting datcat on <elementSpec> or <equiv> (as opposed 
to putting it on <pos> or <gram>).

Thanks,

   P.

From lou.burnard at retired.ox.ac.uk  Thu Oct 25 06:23:01 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Thu, 25 Oct 2012 11:23:01 +0100
Subject: [tei-council] datcat's ugly head
In-Reply-To: <50890F3F.8010100@o2.pl>
References: <50890F3F.8010100@o2.pl>
Message-ID: <50891305.9090209@retired.ox.ac.uk>

Let's come back to this after the release: it's tricky. My first thought 
is that a dcr:datcat on an <fdecl> establishes a default mapping, which 
might then be remapped/over=ridden by a <f> . Either that or it's an 
error. I  agree that it's more or less the same as <equiv> but that's 
probably not relevant



On 25/10/12 11:06, Piotr Banski wrote:
> May I ask the Council to have a quick look at
>
> https://sourceforge.net/tracker/?func=detail&atid=644062&aid=3569990&group_id=106328
>
> ?
>
> I'm a bit afraid that I'm trying to put a stick in our wheel, with a
> chance to succeed :-/
>
> The issue is the semantics of <fDecl> with dcr:datcat on it. I'm a bit
> afraid it's like putting datcat on <elementSpec> or <equiv> (as opposed
> to putting it on <pos> or <gram>).
>
> Thanks,
>
>     P.

From sebastian.rahtz at it.ox.ac.uk  Thu Oct 25 06:31:02 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Thu, 25 Oct 2012 10:31:02 +0000
Subject: [tei-council] datcat's ugly head
In-Reply-To: <50891305.9090209@retired.ox.ac.uk>
References: <50890F3F.8010100@o2.pl> <50891305.9090209@retired.ox.ac.uk>
Message-ID: <9f19f7a0-a819-4e09-a104-05e498385213@HUB04.ad.oak.ox.ac.uk>

On 25 Oct 2012, at 11:23, Lou Burnard <lou.burnard at retired.ox.ac.uk>
 wrote:

> Let's come back to this after the release: it's tricky. 

yes. its not at all obvious which way to jump. 

Similarly, I am 
nervous about just adding <standoff> at the last minute without
any supporting prose drafted. This will be a big deal, and needs
a full-scale consultation, examples, and so on
--
Sebastian Rahtz      
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431


From James.Cummings at it.ox.ac.uk  Thu Oct 25 06:41:17 2012
From: James.Cummings at it.ox.ac.uk (James Cummings)
Date: Thu, 25 Oct 2012 11:41:17 +0100
Subject: [tei-council] datcat's ugly head
In-Reply-To: <9f19f7a0-a819-4e09-a104-05e498385213@HUB04.ad.oak.ox.ac.uk>
References: <50890F3F.8010100@o2.pl> <50891305.9090209@retired.ox.ac.uk>
	<9f19f7a0-a819-4e09-a104-05e498385213@HUB04.ad.oak.ox.ac.uk>
Message-ID: <5089174D.1030400@it.ox.ac.uk>

On 25/10/12 11:31, Sebastian Rahtz wrote:
> On 25 Oct 2012, at 11:23, Lou Burnard <lou.burnard at retired.ox.ac.uk>
>   wrote:
>
>> Let's come back to this after the release: it's tricky.
>
> yes. its not at all obvious which way to jump.
>
> Similarly, I am
> nervous about just adding <standoff> at the last minute without
> any supporting prose drafted. This will be a big deal, and needs
> a full-scale consultation, examples, and so on

I didn't think we _had_ added <standoff> had we? I agree with all 
that you said, big change. We've agreed it is a good idea but 
that means more work on prose, drafting examples, etc.

I certainly don't see a standoff.xml in P5/Source/Specs ?

-James

> --
> Sebastian Rahtz
> Director (Research Support) of Academic IT Services
> University of Oxford IT Services
> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>


-- 
Dr James Cummings, researchsupport at it.ox.ac.uk
Research Support, IT Services, University of Oxford

From bansp at o2.pl  Thu Oct 25 06:46:28 2012
From: bansp at o2.pl (Piotr Banski)
Date: Thu, 25 Oct 2012 12:46:28 +0200
Subject: [tei-council] datcat's ugly head
In-Reply-To: <5089174D.1030400@it.ox.ac.uk>
References: <50890F3F.8010100@o2.pl> <50891305.9090209@retired.ox.ac.uk>
	<9f19f7a0-a819-4e09-a104-05e498385213@HUB04.ad.oak.ox.ac.uk>
	<5089174D.1030400@it.ox.ac.uk>
Message-ID: <50891884.5010906@o2.pl>

That's my bit of enlightenment of yesterday. I was utterly unhappy 
thinking that I was supposed to put in something completely incomplete...

Then I reread the minutes and realised that I was (I now /hope/ I was) 
misinterpreting, and that all that the Council did in Oxford was in fact 
give a green light to starting work on this concept. Right?

   P.

On 25/10/12 12:41, James Cummings wrote:
> On 25/10/12 11:31, Sebastian Rahtz wrote:
>> On 25 Oct 2012, at 11:23, Lou Burnard <lou.burnard at retired.ox.ac.uk>
>>    wrote:
>>
>>> Let's come back to this after the release: it's tricky.
>>
>> yes. its not at all obvious which way to jump.
>>
>> Similarly, I am
>> nervous about just adding <standoff> at the last minute without
>> any supporting prose drafted. This will be a big deal, and needs
>> a full-scale consultation, examples, and so on
>
> I didn't think we _had_ added <standoff> had we? I agree with all
> that you said, big change. We've agreed it is a good idea but
> that means more work on prose, drafting examples, etc.
>
> I certainly don't see a standoff.xml in P5/Source/Specs ?
>
> -James
>
>> --
>> Sebastian Rahtz
>> Director (Research Support) of Academic IT Services
>> University of Oxford IT Services
>> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>>
>
>


From sebastian.rahtz at it.ox.ac.uk  Thu Oct 25 06:48:41 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Thu, 25 Oct 2012 10:48:41 +0000
Subject: [tei-council] datcat's ugly head
In-Reply-To: <5089174D.1030400@it.ox.ac.uk>
References: <50890F3F.8010100@o2.pl> <50891305.9090209@retired.ox.ac.uk>
	<9f19f7a0-a819-4e09-a104-05e498385213@HUB04.ad.oak.ox.ac.uk>
	<5089174D.1030400@it.ox.ac.uk>
Message-ID: <bde2eb0d-dc12-4b7e-9fb5-210e14cde60f@HUB02.ad.oak.ox.ac.uk>


On 25 Oct 2012, at 11:41, James Cummings <James.Cummings at it.ox.ac.uk>
 wrote:
> 
> I didn't think we _had_ added <standoff> had we?

no, but Laurent is badgering Piotr on the ticket to Just Do it

--
Sebastian Rahtz      
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431


From bansp at o2.pl  Thu Oct 25 06:51:46 2012
From: bansp at o2.pl (Piotr Banski)
Date: Thu, 25 Oct 2012 12:51:46 +0200
Subject: [tei-council] datcat's ugly head
In-Reply-To: <9f19f7a0-a819-4e09-a104-05e498385213@HUB04.ad.oak.ox.ac.uk>
References: <50890F3F.8010100@o2.pl> <50891305.9090209@retired.ox.ac.uk>
	<9f19f7a0-a819-4e09-a104-05e498385213@HUB04.ad.oak.ox.ac.uk>
Message-ID: <508919C2.40901@o2.pl>

On 25/10/12 12:31, Sebastian Rahtz wrote:
> On 25 Oct 2012, at 11:23, Lou Burnard <lou.burnard at retired.ox.ac.uk>
>   wrote:
>
>> Let's come back to this after the release: it's tricky.
>
> yes. its not at all obvious which way to jump.

I'm having a (mis)interpretation problem again: what are you guys 
saying, then, please:

* shall we leave this in, and allow for actual TEI-conformant schemas to 
be created with datcat on fDecl, and then we'll come back to it and 
maybe decide to pull it out, OR

* should we pull it out now, and then come back to it (the more so that 
it possibly needs to be in sync with work done in TC37 SC4)

?

From James.Cummings at it.ox.ac.uk  Thu Oct 25 06:53:46 2012
From: James.Cummings at it.ox.ac.uk (James Cummings)
Date: Thu, 25 Oct 2012 11:53:46 +0100
Subject: [tei-council] datcat's ugly head
In-Reply-To: <A99C2F92-09E7-4CC4-A296-CA761065C66F@it.ox.ac.uk>
References: <50890F3F.8010100@o2.pl> <50891305.9090209@retired.ox.ac.uk>
	<9f19f7a0-a819-4e09-a104-05e498385213@HUB04.ad.oak.ox.ac.uk>
	<5089174D.1030400@it.ox.ac.uk>
	<A99C2F92-09E7-4CC4-A296-CA761065C66F@it.ox.ac.uk>
Message-ID: <50891A3A.5050705@it.ox.ac.uk>

On 25/10/12 11:48, Sebastian Rahtz wrote:
>
> On 25 Oct 2012, at 11:41, James Cummings <James.Cummings at it.ox.ac.uk>
>   wrote:
>>
>> I didn't think we _had_ added <standoff> had we?
>
> no, but Laurent is badgering Piotr on the ticket to Just Do it

That isn't a reason to do it.  If Piotr as implementer of the 
ticket has any reservations then he should revert the changes. 
This is why the deadline for schema-related changes was yesterday ;-)

In answer to Piotr's next message: I argue that if you think it 
causes problems and are not 98% happy with it, then remove it, 
and put it back in post-release. Laurent can always use schemas 
from SVN, or wait until next release.

-James
-- 
Dr James Cummings, researchsupport at it.ox.ac.uk
Research Support, IT Services, University of Oxford

From James.Cummings at it.ox.ac.uk  Thu Oct 25 12:20:45 2012
From: James.Cummings at it.ox.ac.uk (James Cummings)
Date: Thu, 25 Oct 2012 17:20:45 +0100
Subject: [tei-council] Commit Freeze before Release 2.20
Message-ID: <508966DD.6080208@it.ox.ac.uk>


Piotr and I have been working on the release notes to release 
2.2.0, which we've currently got as a google doc (if you wish to 
proofread them to make sure your favourite ticket is mentioned, 
send me your google account).

Please do *NOT* commit anything to sourceforge (unless your name 
is Piotr) until after the release is announced.

Best,

-James

-- 
Dr James Cummings, researchsupport at it.ox.ac.uk
Research Support, IT Services, University of Oxford

From sebastian.rahtz at it.ox.ac.uk  Thu Oct 25 12:47:10 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Thu, 25 Oct 2012 16:47:10 +0000
Subject: [tei-council] Commit Freeze before Release 2.20
In-Reply-To: <508966DD.6080208@it.ox.ac.uk>
References: <508966DD.6080208@it.ox.ac.uk>
Message-ID: <6BCD63DC-5A32-48A0-8A81-123660D0EF38@it.ox.ac.uk>


On 25 Oct 2012, at 17:20, James Cummings <James.Cummings at it.ox.ac.uk>
 wrote:

> 
> Please do *NOT* commit anything to sourceforge (unless your name 
> is Piotr) until after the release is announced.



i have to change Stylesheets, sorry. New bug report from Louis Dubeau
is catastrophic (it loses attributes). i am very dismayed my tests didn't catch it
--
Sebastian Rahtz      
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431


From James.Cummings at it.ox.ac.uk  Thu Oct 25 13:47:44 2012
From: James.Cummings at it.ox.ac.uk (James Cummings)
Date: Thu, 25 Oct 2012 18:47:44 +0100
Subject: [tei-council] Commit Freeze before Release 2.20
In-Reply-To: <6BCD63DC-5A32-48A0-8A81-123660D0EF38@it.ox.ac.uk>
References: <508966DD.6080208@it.ox.ac.uk>
	<6BCD63DC-5A32-48A0-8A81-123660D0EF38@it.ox.ac.uk>
Message-ID: <50897B40.8030802@it.ox.ac.uk>

On 25/10/12 17:47, Sebastian Rahtz wrote:
>> Please do *NOT* commit anything to sourceforge (unless your name
>> is Piotr) until after the release is announced.
> i have to change Stylesheets, sorry. New bug report from Louis Dubeau
> is catastrophic (it loses attributes). i am very dismayed my tests didn't catch it

Understood, we'll proceed assuming that all your changes will 
work, but hold off on final release until they do.

-James

-- 
Dr James Cummings, James.Cummings at it.ox.ac.uk
Research Support, IT Services, University of Oxford

From sebastian.rahtz at it.ox.ac.uk  Thu Oct 25 13:51:03 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Thu, 25 Oct 2012 17:51:03 +0000
Subject: [tei-council] Commit Freeze before Release 2.20
In-Reply-To: <50897B40.8030802@it.ox.ac.uk>
References: <508966DD.6080208@it.ox.ac.uk>
	<6BCD63DC-5A32-48A0-8A81-123660D0EF38@it.ox.ac.uk>
	<50897B40.8030802@it.ox.ac.uk>
Message-ID: <0ffde49f-1af1-4e72-bef9-09f7d1728cd4@HUB06.ad.oak.ox.ac.uk>


On 25 Oct 2012, at 18:47, James Cummings <James.Cummings at it.ox.ac.uk>
 wrote:

> On 25/10/12 17:47, Sebastian Rahtz wrote:
>>> Please do *NOT* commit anything to sourceforge (unless your name
>>> is Piotr) until after the release is announced.
>> i have to change Stylesheets, sorry. New bug report from Louis Dubeau
>> is catastrophic (it loses attributes). i am very dismayed my tests didn't catch it
> 
> Understood, we'll proceed assuming that all your changes will 
> work, but hold off on final release until they do.


Oxford jenkins appears to be heading up the home straight now with
no problems. but I am worried that uvic seems to yoyo between
success and failure with the stack overflow. I can't see a pattern there.
--
Sebastian Rahtz      
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431


From mholmes at uvic.ca  Thu Oct 25 14:16:55 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Thu, 25 Oct 2012 11:16:55 -0700
Subject: [tei-council] Commit Freeze before Release 2.20
In-Reply-To: <0ffde49f-1af1-4e72-bef9-09f7d1728cd4@HUB06.ad.oak.ox.ac.uk>
References: <508966DD.6080208@it.ox.ac.uk>
	<6BCD63DC-5A32-48A0-8A81-123660D0EF38@it.ox.ac.uk>
	<50897B40.8030802@it.ox.ac.uk>
	<0ffde49f-1af1-4e72-bef9-09f7d1728cd4@HUB06.ad.oak.ox.ac.uk>
Message-ID: <50898217.402@uvic.ca>

It's OK right now -- I kicked off a second P5-Test build. After all this 
is over, I'm going to nuke that workspace. I don't know what the problem 
is there, but one possibility is memory allocation to jing. I'll have to 
compare your settings to mine. But my server is 64-bit and yours is 
32-bit, IIRC, so my memory allocations may have to be more generous.

Cheers,
Martin

On 12-10-25 10:51 AM, Sebastian Rahtz wrote:
>
> On 25 Oct 2012, at 18:47, James Cummings <James.Cummings at it.ox.ac.uk>
>   wrote:
>
>> On 25/10/12 17:47, Sebastian Rahtz wrote:
>>>> Please do *NOT* commit anything to sourceforge (unless your name
>>>> is Piotr) until after the release is announced.
>>> i have to change Stylesheets, sorry. New bug report from Louis Dubeau
>>> is catastrophic (it loses attributes). i am very dismayed my tests didn't catch it
>>
>> Understood, we'll proceed assuming that all your changes will
>> work, but hold off on final release until they do.
>
>
> Oxford jenkins appears to be heading up the home straight now with
> no problems. but I am worried that uvic seems to yoyo between
> success and failure with the stack overflow. I can't see a pattern there.
> --
> Sebastian Rahtz
> Director (Research Support) of Academic IT Services
> University of Oxford IT Services
> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From sebastian.rahtz at it.ox.ac.uk  Thu Oct 25 18:03:45 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Thu, 25 Oct 2012 22:03:45 +0000
Subject: [tei-council] stylesheets re-released
Message-ID: <478058F5-C080-4B4E-BA70-19C4C30AB432@it.ox.ac.uk>

with apologies, I just did a new Stylesheets release correcting the evilness Louis Dubeau found;
it was introduced in June as part of the work on local class overriding, and I can't think
why no-one has been bitten by it before. Oh well.

the good thing is that this makes the stylesheets up to date with new "about to be released"
@style, by doing a much more consistent implementation of @rend/@rendition/@style and <tagsDecl>. 
Well, in HTML and ePub at least. The other output languages will take longer.

Eagle-eyed folks will see a new compiled ODD -> json conversion. If I tell you this was
added to allow a new Roma implementation to do some clever stuff, and that
James will be able to show you it in Texas if you ask nicely, are you excited
already?

lets not even mention that I am homing in on how to make OxGarage produce XSD
and RNC output. Woof. My cup brimmeth over.
--
Sebastian Rahtz      
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431


From sebastian.rahtz at it.ox.ac.uk  Thu Oct 25 18:15:43 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Thu, 25 Oct 2012 22:15:43 +0000
Subject: [tei-council] release notes & Lite
Message-ID: <D41E9818-35AC-4EA2-BA50-EB58893B978C@it.ox.ac.uk>

I wonder, how much should we draw attention to the fact that the schema for  Lite has changed name?
Those few, those lucky few, who point their docs at

      http://www.tei-c.org/release/xml/tei/custom/schema/dtd/teilite.dtd

are going to wake up in a few days to find their favourite resource gone. We agreed this
was OK, but they won't find it mentioned in the release notes.

Or am I misremembering and have we asked David or Kevin to add a rewrite
rule to make the above url work?
--
Sebastian Rahtz      
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431


From kevin.s.hawkins at ultraslavonic.info  Thu Oct 25 19:40:41 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Thu, 25 Oct 2012 19:40:41 -0400
Subject: [tei-council] release notes & Lite
In-Reply-To: <D41E9818-35AC-4EA2-BA50-EB58893B978C@it.ox.ac.uk>
References: <D41E9818-35AC-4EA2-BA50-EB58893B978C@it.ox.ac.uk>
Message-ID: <5089CDF9.1070904@ultraslavonic.info>

I have a to-do list item for myself to correct the links for Lite at 
http://www.tei-c.org/Guidelines/Customization/ to include the 
underscore.  As for whether to set up a redirect, I think we agreed that 
we shouldn't because major changes have been made to Lite since the last 
release, so it is different enough that we want people to be clued in to 
the change.  But I can be convinced otherwise.  --K.

On 10/25/12 6:15 PM, Sebastian Rahtz wrote:
> I wonder, how much should we draw attention to the fact that the schema for  Lite has changed name?
> Those few, those lucky few, who point their docs at
>
>        http://www.tei-c.org/release/xml/tei/custom/schema/dtd/teilite.dtd
>
> are going to wake up in a few days to find their favourite resource gone. We agreed this
> was OK, but they won't find it mentioned in the release notes.
>
> Or am I misremembering and have we asked David or Kevin to add a rewrite
> rule to make the above url work?
> --
> Sebastian Rahtz
> Director (Research Support) of Academic IT Services
> University of Oxford IT Services
> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>

From bansp at o2.pl  Thu Oct 25 21:22:01 2012
From: bansp at o2.pl (=?ISO-8859-2?Q?Piotr_Ba=F1ski?=)
Date: Fri, 26 Oct 2012 03:22:01 +0200
Subject: [tei-council] Commit Freeze for 2.2.0 lifted
In-Reply-To: <508966DD.6080208@it.ox.ac.uk>
References: <508966DD.6080208@it.ox.ac.uk>
Message-ID: <5089E5B9.3090709@o2.pl>

Hi Council,

The freeze has been lifted, release 2.0.0 is accessible, so now let us
rejoice and commit like crazy.

I would like to stress that without James and Martin, this would have
been an absolute ordeal. Thanks to their help, everything now works.

Cheers,

  Piotr

From James.Cummings at it.ox.ac.uk  Thu Oct 25 21:27:37 2012
From: James.Cummings at it.ox.ac.uk (James Cummings)
Date: Fri, 26 Oct 2012 02:27:37 +0100
Subject: [tei-council] Commit Freeze for 2.2.0 lifted
In-Reply-To: <5089E5B9.3090709@o2.pl>
References: <508966DD.6080208@it.ox.ac.uk> <5089E5B9.3090709@o2.pl>
Message-ID: <5089E709.6000203@it.ox.ac.uk>

On 26/10/12 02:22, Piotr Ba?ski wrote:
> Hi Council,
>
> The freeze has been lifted, release 2.0.0 is accessible, so now let us
> rejoice and commit like crazy.

2.2.0 of course.. ;-)

> I would like to stress that without James and Martin, this would have
> been an absolute ordeal. Thanks to their help, everything now works.

This will all feed into making tcw22 even better, Martin is 
updating it as we type.

-James

-- 
Dr James Cummings, James.Cummings at it.ox.ac.uk
Research Support, IT Services, University of Oxford

From mholmes at uvic.ca  Thu Oct 25 21:39:55 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Thu, 25 Oct 2012 18:39:55 -0700
Subject: [tei-council] Updates to TCW 22
Message-ID: <5089E9EB.5090701@uvic.ca>

Hi all,

Following our adventures today, I've updated TCW 22:

<http://www.tei-c.org/Activities/Council/Working/tcw22.xml>

"Building a TEI Release". These are the main changes:

1. We've added a step that says you need to get an SF TEI admin to give 
you shell access to the SF account. That's the step that tripped Gaby up 
last time, it turns out, and caused him to have to generate his own ssh key.

2. We've clarified the explanation of how to add the tei key to your SF 
account.

2. I've expanded the explanation of how to get the oxygen-tei packages 
updated, after doing that for the first time myself (I think only 
Sebastian has done it before). We discovered a need for Ant 1.8 which we 
didn't know about.

I've also raised a bug about the ugliness of the HTML rendering of the 
readme on the website.

I think that's it -- have I missed anything?

By the way, we owe James and Piotr a lot of thanks. They've stayed up 
well past anybody's bedtime waiting for Jenkins builds of last-minute 
commits to complete before they could work through the release steps.

Cheers,
Martin


From kevin.s.hawkins at ultraslavonic.info  Thu Oct 25 21:56:10 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Thu, 25 Oct 2012 21:56:10 -0400
Subject: [tei-council] release notes & Lite
In-Reply-To: <5089CDF9.1070904@ultraslavonic.info>
References: <D41E9818-35AC-4EA2-BA50-EB58893B978C@it.ox.ac.uk>
	<5089CDF9.1070904@ultraslavonic.info>
Message-ID: <5089EDBA.4030100@ultraslavonic.info>

(I have just updated the Lite links on that webpage.)

On 10/25/12 7:40 PM, Kevin Hawkins wrote:
> I have a to-do list item for myself to correct the links for Lite at
> http://www.tei-c.org/Guidelines/Customization/ to include the
> underscore.  As for whether to set up a redirect, I think we agreed that
> we shouldn't because major changes have been made to Lite since the last
> release, so it is different enough that we want people to be clued in to
> the change.  But I can be convinced otherwise.  --K.
>
> On 10/25/12 6:15 PM, Sebastian Rahtz wrote:
>> I wonder, how much should we draw attention to the fact that the
>> schema for  Lite has changed name?
>> Those few, those lucky few, who point their docs at
>>
>>        http://www.tei-c.org/release/xml/tei/custom/schema/dtd/teilite.dtd
>>
>> are going to wake up in a few days to find their favourite resource
>> gone. We agreed this
>> was OK, but they won't find it mentioned in the release notes.
>>
>> Or am I misremembering and have we asked David or Kevin to add a rewrite
>> rule to make the above url work?
>> --
>> Sebastian Rahtz
>> Director (Research Support) of Academic IT Services
>> University of Oxford IT Services
>> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>>

From lou.burnard at retired.ox.ac.uk  Fri Oct 26 02:40:05 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Fri, 26 Oct 2012 06:40:05 +0000
Subject: [tei-council] release notes & Lite
In-Reply-To: <5089EDBA.4030100@ultraslavonic.info>
References: <D41E9818-35AC-4EA2-BA50-EB58893B978C@it.ox.ac.uk>
	<5089CDF9.1070904@ultraslavonic.info>,
	<5089EDBA.4030100@ultraslavonic.info>
Message-ID: <20i2u8614o7cxw68pbmx3kvl.1351233491895@email.android.com>

any mention of the new lite at all only got into the release notice at the very last moment and I at least completely forgot the name change. apologies.

Kevin Hawkins <kevin.s.hawkins at ultraslavonic.info> wrote:


(I have just updated the Lite links on that webpage.)

On 10/25/12 7:40 PM, Kevin Hawkins wrote:
> I have a to-do list item for myself to correct the links for Lite at
> http://www.tei-c.org/Guidelines/Customization/ to include the
> underscore.  As for whether to set up a redirect, I think we agreed that
> we shouldn't because major changes have been made to Lite since the last
> release, so it is different enough that we want people to be clued in to
> the change.  But I can be convinced otherwise.  --K.
>
> On 10/25/12 6:15 PM, Sebastian Rahtz wrote:
>> I wonder, how much should we draw attention to the fact that the
>> schema for  Lite has changed name?
>> Those few, those lucky few, who point their docs at
>>
>>        http://www.tei-c.org/release/xml/tei/custom/schema/dtd/teilite.dtd
>>
>> are going to wake up in a few days to find their favourite resource
>> gone. We agreed this
>> was OK, but they won't find it mentioned in the release notes.
>>
>> Or am I misremembering and have we asked David or Kevin to add a rewrite
>> rule to make the above url work?
>> --
>> Sebastian Rahtz
>> Director (Research Support) of Academic IT Services
>> University of Oxford IT Services
>> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>>
--
tei-council mailing list
tei-council at lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

PLEASE NOTE: postings to this list are publicly archived

From mholmes at uvic.ca  Fri Oct 26 11:43:21 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Fri, 26 Oct 2012 08:43:21 -0700
Subject: [tei-council] Speeding up Jinks builds
Message-ID: <508AAF99.7060506@uvic.ca>

This message is mostly for Sebastian, but I'm sending it to the list 
because anyone could potentially have suggestions that would help, and 
most of us will end up as a Release Technician at some point.

Yesterday was a bit exceptional in that there were lots of last-minute 
commits that held up the build process, but we did notice that waiting 
for Jinks builds to complete was very tedious, and spent some time 
thinking about ways we might speed this up. These issues crossed my mind:

  - I'm not sure why P5-Documentation and P5 are two separate jobs. 
Could they be combined? I think that would be quicker in that it would 
save copying over lots of stuff from the workspace of one build to the 
other.

  - A few months ago, all builds were going much more quickly on both 
Jinkses. I can't think what's changed, except for the move to XInclude 
from entities. Is it possible that makes a difference? It might be worth 
doing some tests to find out, and if it does, investigate a way of doing 
the XIncludes more quickly.

  - Both Jinkses are running on virtual machines, so we can presumably 
push up the memory or change the processing for the VMs if that will 
help. I'd like to investigate whether adding more cores would be useful 
(if, for instance, separate build jobs run on separate cores), and 
whether more memory will make much difference.

  - I suspect there are lots of tweaks I could make to how memory is 
allocated to ant tasks etc., and those could also be integrated into the 
Jinks server build script.

Anything else anyone can think of that would help speed up the Jinkses? 
We're committed to steadily adding more and more tests to P5-Test 
(Schematron etc.), so that build is going to take progressively longer; 
anything we can do to mitigate that would be really helpful.

Cheers,
Martin
-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From James.Cummings at it.ox.ac.uk  Fri Oct 26 11:51:24 2012
From: James.Cummings at it.ox.ac.uk (James Cummings)
Date: Fri, 26 Oct 2012 16:51:24 +0100
Subject: [tei-council] Speeding up Jinks builds
In-Reply-To: <508AAF99.7060506@uvic.ca>
References: <508AAF99.7060506@uvic.ca>
Message-ID: <508AB17C.4070402@it.ox.ac.uk>


Hi Martin,

The whitepaper I read on optimizing Jenkins is: 
http://www.cloudbees.com/sites/default/files/whitepapers/7WaysToOptimizeJenkins.pdf 
but really I don't think most of it applies to us.  (Well, we 
could do a distributed set of VM nodes all in the same set of VM 
to do different tasks, but this seems overkill.)

I'm interested in whether just throwing multiple cores and more 
memory at it will give significant improvements... maybe 
something we could test but upping it for a week or two to see if 
it has any effect.

-James


On 26/10/12 16:43, Martin Holmes wrote:
> This message is mostly for Sebastian, but I'm sending it to the list
> because anyone could potentially have suggestions that would help, and
> most of us will end up as a Release Technician at some point.
>
> Yesterday was a bit exceptional in that there were lots of last-minute
> commits that held up the build process, but we did notice that waiting
> for Jinks builds to complete was very tedious, and spent some time
> thinking about ways we might speed this up. These issues crossed my mind:
>
>    - I'm not sure why P5-Documentation and P5 are two separate jobs.
> Could they be combined? I think that would be quicker in that it would
> save copying over lots of stuff from the workspace of one build to the
> other.
>
>    - A few months ago, all builds were going much more quickly on both
> Jinkses. I can't think what's changed, except for the move to XInclude
> from entities. Is it possible that makes a difference? It might be worth
> doing some tests to find out, and if it does, investigate a way of doing
> the XIncludes more quickly.
>
>    - Both Jinkses are running on virtual machines, so we can presumably
> push up the memory or change the processing for the VMs if that will
> help. I'd like to investigate whether adding more cores would be useful
> (if, for instance, separate build jobs run on separate cores), and
> whether more memory will make much difference.
>
>    - I suspect there are lots of tweaks I could make to how memory is
> allocated to ant tasks etc., and those could also be integrated into the
> Jinks server build script.
>
> Anything else anyone can think of that would help speed up the Jinkses?
> We're committed to steadily adding more and more tests to P5-Test
> (Schematron etc.), so that build is going to take progressively longer;
> anything we can do to mitigate that would be really helpful.
>
> Cheers,
> Martin
>


-- 
Dr James Cummings, researchsupport at it.ox.ac.uk
Research Support, IT Services, University of Oxford

From gabriel.bodard at kcl.ac.uk  Fri Oct 26 11:55:35 2012
From: gabriel.bodard at kcl.ac.uk (Gabriel Bodard)
Date: Fri, 26 Oct 2012 16:55:35 +0100
Subject: [tei-council] Speeding up Jinks builds
In-Reply-To: <508AB17C.4070402@it.ox.ac.uk>
References: <508AAF99.7060506@uvic.ca> <508AB17C.4070402@it.ox.ac.uk>
Message-ID: <508AB277.20002@kcl.ac.uk>

In the past I've seen XSLT-heavy processes like this sped up by 
literally several orders of magnitude just by writing a simple java 
wrapper for Saxon so that it opens once and performs all the 
transformations from one call, rather than opening, performing 
transformation, closing, opening, performing transformation, closing 
(repeat a thousand times). I don't know if this is anything that would 
be useful for us, or if we already do this, or if it just isn't the 
Saxon call that is slowing us down, but I thought I'd throw it out there.

On 2012-10-26 16:51, James Cummings wrote:
>
> Hi Martin,
>
> The whitepaper I read on optimizing Jenkins is:
> http://www.cloudbees.com/sites/default/files/whitepapers/7WaysToOptimizeJenkins.pdf
> but really I don't think most of it applies to us.  (Well, we
> could do a distributed set of VM nodes all in the same set of VM
> to do different tasks, but this seems overkill.)
>
> I'm interested in whether just throwing multiple cores and more
> memory at it will give significant improvements... maybe
> something we could test but upping it for a week or two to see if
> it has any effect.
>
> -James
>
>
> On 26/10/12 16:43, Martin Holmes wrote:
>> This message is mostly for Sebastian, but I'm sending it to the list
>> because anyone could potentially have suggestions that would help, and
>> most of us will end up as a Release Technician at some point.
>>
>> Yesterday was a bit exceptional in that there were lots of last-minute
>> commits that held up the build process, but we did notice that waiting
>> for Jinks builds to complete was very tedious, and spent some time
>> thinking about ways we might speed this up. These issues crossed my mind:
>>
>>     - I'm not sure why P5-Documentation and P5 are two separate jobs.
>> Could they be combined? I think that would be quicker in that it would
>> save copying over lots of stuff from the workspace of one build to the
>> other.
>>
>>     - A few months ago, all builds were going much more quickly on both
>> Jinkses. I can't think what's changed, except for the move to XInclude
>> from entities. Is it possible that makes a difference? It might be worth
>> doing some tests to find out, and if it does, investigate a way of doing
>> the XIncludes more quickly.
>>
>>     - Both Jinkses are running on virtual machines, so we can presumably
>> push up the memory or change the processing for the VMs if that will
>> help. I'd like to investigate whether adding more cores would be useful
>> (if, for instance, separate build jobs run on separate cores), and
>> whether more memory will make much difference.
>>
>>     - I suspect there are lots of tweaks I could make to how memory is
>> allocated to ant tasks etc., and those could also be integrated into the
>> Jinks server build script.
>>
>> Anything else anyone can think of that would help speed up the Jinkses?
>> We're committed to steadily adding more and more tests to P5-Test
>> (Schematron etc.), so that build is going to take progressively longer;
>> anything we can do to mitigate that would be really helpful.
>>
>> Cheers,
>> Martin
>>
>
>

-- 
Dr Gabriel BODARD
Researcher in Digital Epigraphy

Digital Humanities
King's College London
26-29 Drury Lane
London WC2B 5RL

T: +44 (0)20 7848 1388
F: +44 (0)20 7848 2980
E: gabriel.bodard at kcl.ac.uk

http://www.digitalclassicist.org/
http://www.currentepigraphy.org/


From James.Cummings at it.ox.ac.uk  Fri Oct 26 12:00:17 2012
From: James.Cummings at it.ox.ac.uk (James Cummings)
Date: Fri, 26 Oct 2012 17:00:17 +0100
Subject: [tei-council] Speeding up Jinks builds
In-Reply-To: <508AB277.20002@kcl.ac.uk>
References: <508AAF99.7060506@uvic.ca> <508AB17C.4070402@it.ox.ac.uk>
	<508AB277.20002@kcl.ac.uk>
Message-ID: <508AB391.1060302@it.ox.ac.uk>


This kind of thing certainly could help, I think. The complexity 
comes in the different sets of activities done as part of the 
build process. (Some of them might not be able to be bundled 
together... but those that are, perhaps should be.)

-James

On 26/10/12 16:55, Gabriel Bodard wrote:
> In the past I've seen XSLT-heavy processes like this sped up by
> literally several orders of magnitude just by writing a simple java
> wrapper for Saxon so that it opens once and performs all the
> transformations from one call, rather than opening, performing
> transformation, closing, opening, performing transformation, closing
> (repeat a thousand times). I don't know if this is anything that would
> be useful for us, or if we already do this, or if it just isn't the
> Saxon call that is slowing us down, but I thought I'd throw it out there.
>
> On 2012-10-26 16:51, James Cummings wrote:
>>
>> Hi Martin,
>>
>> The whitepaper I read on optimizing Jenkins is:
>> http://www.cloudbees.com/sites/default/files/whitepapers/7WaysToOptimizeJenkins.pdf
>> but really I don't think most of it applies to us.  (Well, we
>> could do a distributed set of VM nodes all in the same set of VM
>> to do different tasks, but this seems overkill.)
>>
>> I'm interested in whether just throwing multiple cores and more
>> memory at it will give significant improvements... maybe
>> something we could test but upping it for a week or two to see if
>> it has any effect.
>>
>> -James
>>
>>
>> On 26/10/12 16:43, Martin Holmes wrote:
>>> This message is mostly for Sebastian, but I'm sending it to the list
>>> because anyone could potentially have suggestions that would help, and
>>> most of us will end up as a Release Technician at some point.
>>>
>>> Yesterday was a bit exceptional in that there were lots of last-minute
>>> commits that held up the build process, but we did notice that waiting
>>> for Jinks builds to complete was very tedious, and spent some time
>>> thinking about ways we might speed this up. These issues crossed my mind:
>>>
>>>      - I'm not sure why P5-Documentation and P5 are two separate jobs.
>>> Could they be combined? I think that would be quicker in that it would
>>> save copying over lots of stuff from the workspace of one build to the
>>> other.
>>>
>>>      - A few months ago, all builds were going much more quickly on both
>>> Jinkses. I can't think what's changed, except for the move to XInclude
>>> from entities. Is it possible that makes a difference? It might be worth
>>> doing some tests to find out, and if it does, investigate a way of doing
>>> the XIncludes more quickly.
>>>
>>>      - Both Jinkses are running on virtual machines, so we can presumably
>>> push up the memory or change the processing for the VMs if that will
>>> help. I'd like to investigate whether adding more cores would be useful
>>> (if, for instance, separate build jobs run on separate cores), and
>>> whether more memory will make much difference.
>>>
>>>      - I suspect there are lots of tweaks I could make to how memory is
>>> allocated to ant tasks etc., and those could also be integrated into the
>>> Jinks server build script.
>>>
>>> Anything else anyone can think of that would help speed up the Jinkses?
>>> We're committed to steadily adding more and more tests to P5-Test
>>> (Schematron etc.), so that build is going to take progressively longer;
>>> anything we can do to mitigate that would be really helpful.
>>>
>>> Cheers,
>>> Martin
>>>
>>
>>
>


-- 
Dr James Cummings, researchsupport at it.ox.ac.uk
Research Support, IT Services, University of Oxford

From sebastian.rahtz at it.ox.ac.uk  Fri Oct 26 12:01:45 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Fri, 26 Oct 2012 16:01:45 +0000
Subject: [tei-council] Speeding up Jinks builds
In-Reply-To: <508AB277.20002@kcl.ac.uk>
References: <508AAF99.7060506@uvic.ca> <508AB17C.4070402@it.ox.ac.uk>
	<508AB277.20002@kcl.ac.uk>
Message-ID: <5D2906F6-7633-4D15-A143-0455B26C84D6@it.ox.ac.uk>


On 26 Oct 2012, at 16:55, Gabriel Bodard <gabriel.bodard at kcl.ac.uk>
 wrote:

> In the past I've seen XSLT-heavy processes like this sped up by 
> literally several orders of magnitude just by writing a simple java 
> wrapper for Saxon so that it opens once and performs all the 
> transformations from one call, rather than opening, performing 
> transformation, closing, opening, performing transformation, closing 
> (repeat a thousand times).
indeed. that could probably do be done by wrapping each test in a single
ant script.

most of the test files do, for a given .odd file:

	-which rnv && rnv ../p5odds.rnc $< 
	$(ROMA) $(ROMAOPTS) --xsl=$(XSL) $< .
	jing -t $*.rng $*.xml
	-which rnv && (xmllint --noent --dropdtd  $*.xml | rnv $*.rnc )
	xmllint --dropdtd $*.xml | xmllint --noout --dtdvalid $*.dtd -
	saxon $*.isosch ../Utilities/iso_schematron_message_xslt2.xsl  > $*.xsl
	saxon $*.xml $*.xsl

which involves 

 2 x xmllint
 2 x rnv
 at least 4 Java startups, if not more
--
Sebastian Rahtz      
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431


From sebastian.rahtz at it.ox.ac.uk  Fri Oct 26 12:03:26 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Fri, 26 Oct 2012 16:03:26 +0000
Subject: [tei-council] Speeding up Jinks builds
In-Reply-To: <508AAF99.7060506@uvic.ca>
References: <508AAF99.7060506@uvic.ca>
Message-ID: <1FA9F5FE-5E8D-4E5E-874C-6C313FC6A7DA@it.ox.ac.uk>


On 26 Oct 2012, at 16:43, Martin Holmes <mholmes at uvic.ca> wrote:
> 
>  - I'm not sure why P5-Documentation and P5 are two separate jobs. 
> Could they be combined? I think that would be quicker in that it would 
> save copying over lots of stuff from the workspace of one build to the 
> other.

hmm. I don't know why we did 3 jobs instead of 2. I can't see a downside
to removing Documentation, and letting P5 do the work.

> 
>  - A few months ago, all builds were going much more quickly on both 
> Jinkses. I can't think what's changed, except for the move to XInclude 
> from entities. Is it possible that makes a difference? It might be worth 
> doing some tests to find out, and if it does, investigate a way of doing 
> the XIncludes more quickly.

can't explain it, sorry. I am sure its not the XIncludes - that happens once,
early on, and thereafter everyone uses the same single file.  that should
have made it faster, not slower.

someone could put in timing messages and see which part of the build
takes time. I am not volunteering :-}
> 
>  - Both Jinkses are running on virtual machines, so we can presumably 
> push up the memory or change the processing for the VMs if that will 
> help.

maybe.  my gut feeling is that looking at the work its doing is more benefit,
but i may well be wrong

>  - I suspect there are lots of tweaks I could make to how memory is 
> allocated to ant tasks etc., and those could also be integrated into the 
> Jinks server build script.
i am curious. why do you think these are an issue?

> Anything else anyone can think of that would help speed up the Jinkses? 
> We're committed to steadily adding more and more tests to P5-Test 
> (Schematron etc.), so that build is going to take progressively longer; 
> anything we can do to mitigate that would be really helpful.


we need profiling. which components of the build take the time?

my observation of slow bits are:

  - the jobs needed for each test file
  - running LaTeX 3 times
  - making .mobi file
  - validating all the HTML files

--
Sebastian Rahtz      
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431


From mholmes at uvic.ca  Fri Oct 26 12:34:35 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Fri, 26 Oct 2012 09:34:35 -0700
Subject: [tei-council] Speeding up Jinks builds
In-Reply-To: <1FA9F5FE-5E8D-4E5E-874C-6C313FC6A7DA@it.ox.ac.uk>
References: <508AAF99.7060506@uvic.ca>
	<1FA9F5FE-5E8D-4E5E-874C-6C313FC6A7DA@it.ox.ac.uk>
Message-ID: <508ABB9B.2070107@uvic.ca>

On 12-10-26 09:03 AM, Sebastian Rahtz wrote:
>
> On 26 Oct 2012, at 16:43, Martin Holmes <mholmes at uvic.ca> wrote:
>>
>>   - I'm not sure why P5-Documentation and P5 are two separate jobs.
>> Could they be combined? I think that would be quicker in that it would
>> save copying over lots of stuff from the workspace of one build to the
>> other.
>
> hmm. I don't know why we did 3 jobs instead of 2. I can't see a downside
> to removing Documentation, and letting P5 do the work.

Let's do that then. In the next few days I'll summarize this discussion 
into a ticket, and get started on it in a month or so, when lots of 
other stuff is out of the way.

>>   - A few months ago, all builds were going much more quickly on both
>> Jinkses. I can't think what's changed, except for the move to XInclude
>> from entities. Is it possible that makes a difference? It might be worth
>> doing some tests to find out, and if it does, investigate a way of doing
>> the XIncludes more quickly.
>
> can't explain it, sorry. I am sure its not the XIncludes - that happens once,
> early on, and thereafter everyone uses the same single file.  that should
> have made it faster, not slower.
>
> someone could put in timing messages and see which part of the build
> takes time. I am not volunteering :-}

One benefit of having two Jinkses is that we can use mine for this kind 
of testing and still have yours working normally.

>>   - Both Jinkses are running on virtual machines, so we can presumably
>> push up the memory or change the processing for the VMs if that will
>> help.
>
> maybe.  my gut feeling is that looking at the work its doing is more benefit,
> but i may well be wrong
>
>>   - I suspect there are lots of tweaks I could make to how memory is
>> allocated to ant tasks etc., and those could also be integrated into the
>> Jinks server build script.
> i am curious. why do you think these are an issue?

I keep having to add memory to java processes (like with jing 
yesterday). I haven't made any tweaks for ant, though, so I thought it 
might be worth looking at.

>> Anything else anyone can think of that would help speed up the Jinkses?
>> We're committed to steadily adding more and more tests to P5-Test
>> (Schematron etc.), so that build is going to take progressively longer;
>> anything we can do to mitigate that would be really helpful.
>
> we need profiling. which components of the build take the time?
>
> my observation of slow bits are:
>
>    - the jobs needed for each test file
>    - running LaTeX 3 times

I wonder if XSL:FO and FOP would be faster? (I know that's a HUGE task.)

>    - making .mobi file

That's kindlegen, right? My Jinks isn't doing that, because it's trying 
to be completely open-source, but my jobs are still slower than yours.

>    - validating all the HTML files

Have to do that. :-) But you're right, it takes ages.

Cheers,
Martin

>
> --
> Sebastian Rahtz
> Director (Research Support) of Academic IT Services
> University of Oxford IT Services
> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>
> .
>

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From sebastian.rahtz at it.ox.ac.uk  Fri Oct 26 12:41:59 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Fri, 26 Oct 2012 16:41:59 +0000
Subject: [tei-council] Speeding up Jinks builds
In-Reply-To: <508ABB9B.2070107@uvic.ca>
References: <508AAF99.7060506@uvic.ca>
	<1FA9F5FE-5E8D-4E5E-874C-6C313FC6A7DA@it.ox.ac.uk>
	<508ABB9B.2070107@uvic.ca>
Message-ID: <CB1FE9CF-16A0-4512-9BB4-E93BB9AE7DDF@it.ox.ac.uk>

>>   - running LaTeX 3 times
> 
> I wonder if XSL:FO and FOP would be faster? (I know that's a HUGE task.)

It would, yes. Enjoy :-}

>>   - validating all the HTML files
> 
> Have to do that. :-) But you're right, it takes ages.
> 

that could be sped up hugely!

validate-html:
        @echo BUILD: Validate HTML version of Guidelines
        (cd Guidelines-web/${LANGUAGE}/html; \
        for i in *.html; do \
        xmllint --noent --dropdtd $$i > z_$$i; \
        $(JING) -c ../../../xhtml.rnc z_$$i; \
         rm z_$$i;\
         done)

that's starting a new Java for each of 1322
HTML files! bring on Ant again?...

--
Sebastian Rahtz      
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431


From dsewell at virginia.edu  Fri Oct 26 12:58:38 2012
From: dsewell at virginia.edu (David Sewell)
Date: Fri, 26 Oct 2012 12:58:38 -0400 (EDT)
Subject: [tei-council] release notes & Lite
In-Reply-To: <5089CDF9.1070904@ultraslavonic.info>
References: <D41E9818-35AC-4EA2-BA50-EB58893B978C@it.ox.ac.uk>
	<5089CDF9.1070904@ultraslavonic.info>
Message-ID: <alpine.OSX.2.00.1210261254180.36525@lister.ei.virginia.edu>

We could create a text file at the location pointed to by 
http://www.tei-c.org/release/xml/tei/custom/schema/dtd/teilite.dtd to note the 
name and schema changes.

Incidentally, everything under 
http://www.tei-c.org/release/xml/tei/custom/schema seems to be at edition 2.1.0, 
"Last updated on 17th June 2012". Is that right? Shouldn't those all be 2.2.0? 
(If I'm missing something totally obvious, ignore the question.)

On Thu, 25 Oct 2012, Kevin Hawkins wrote:

> I have a to-do list item for myself to correct the links for Lite at
> http://www.tei-c.org/Guidelines/Customization/ to include the
> underscore.  As for whether to set up a redirect, I think we agreed that
> we shouldn't because major changes have been made to Lite since the last
> release, so it is different enough that we want people to be clued in to
> the change.  But I can be convinced otherwise.  --K.
>
> On 10/25/12 6:15 PM, Sebastian Rahtz wrote:
>> I wonder, how much should we draw attention to the fact that the schema for  Lite has changed name?
>> Those few, those lucky few, who point their docs at
>>
>>        http://www.tei-c.org/release/xml/tei/custom/schema/dtd/teilite.dtd
>>
>> are going to wake up in a few days to find their favourite resource gone. We agreed this
>> was OK, but they won't find it mentioned in the release notes.
>>
>> Or am I misremembering and have we asked David or Kevin to add a rewrite
>> rule to make the above url work?
>> --
>> Sebastian Rahtz
>> Director (Research Support) of Academic IT Services
>> University of Oxford IT Services
>> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>>
>

-- 
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 it.ox.ac.uk  Fri Oct 26 12:59:54 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Fri, 26 Oct 2012 16:59:54 +0000
Subject: [tei-council] release notes & Lite
In-Reply-To: <alpine.OSX.2.00.1210261254180.36525@lister.ei.virginia.edu>
References: <D41E9818-35AC-4EA2-BA50-EB58893B978C@it.ox.ac.uk>
	<5089CDF9.1070904@ultraslavonic.info>
	<alpine.OSX.2.00.1210261254180.36525@lister.ei.virginia.edu>
Message-ID: <62CABDAB-6A7E-41C2-9E3A-2DEA3EC6722B@it.ox.ac.uk>


On 26 Oct 2012, at 17:58, David Sewell <dsewell at virginia.edu>
 wrote:
> 
> Incidentally, everything under 
> http://www.tei-c.org/release/xml/tei/custom/schema seems to be at edition 2.1.0, 
> "Last updated on 17th June 2012". Is that right? Shouldn't those all be 2.2.0? 

OMG?...

--
Sebastian Rahtz      
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431


From James.Cummings at it.ox.ac.uk  Fri Oct 26 13:01:57 2012
From: James.Cummings at it.ox.ac.uk (James Cummings)
Date: Fri, 26 Oct 2012 18:01:57 +0100
Subject: [tei-council] release notes & Lite
In-Reply-To: <62CABDAB-6A7E-41C2-9E3A-2DEA3EC6722B@it.ox.ac.uk>
References: <D41E9818-35AC-4EA2-BA50-EB58893B978C@it.ox.ac.uk>
	<5089CDF9.1070904@ultraslavonic.info>
	<alpine.OSX.2.00.1210261254180.36525@lister.ei.virginia.edu>
	<62CABDAB-6A7E-41C2-9E3A-2DEA3EC6722B@it.ox.ac.uk>
Message-ID: <508AC205.5060902@it.ox.ac.uk>

On 26/10/12 17:59, Sebastian Rahtz wrote:
>
> On 26 Oct 2012, at 17:58, David Sewell <dsewell at virginia.edu>
>   wrote:
>>
>> Incidentally, everything under
>> http://www.tei-c.org/release/xml/tei/custom/schema seems to be at edition 2.1.0,
>> "Last updated on 17th June 2012". Is that right? Shouldn't those all be 2.2.0?
>
> OMG?...

As far as I can tell the files are correct, but the dates are 
wrong.  Did we miss a step somewhere, or something not built 
properly?

-James

-- 
Dr James Cummings, researchsupport at it.ox.ac.uk
Research Support, IT Services, University of Oxford

From sebastian.rahtz at it.ox.ac.uk  Fri Oct 26 13:07:33 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Fri, 26 Oct 2012 17:07:33 +0000
Subject: [tei-council] release notes & Lite
In-Reply-To: <508AC205.5060902@it.ox.ac.uk>
References: <D41E9818-35AC-4EA2-BA50-EB58893B978C@it.ox.ac.uk>
	<5089CDF9.1070904@ultraslavonic.info>
	<alpine.OSX.2.00.1210261254180.36525@lister.ei.virginia.edu>
	<62CABDAB-6A7E-41C2-9E3A-2DEA3EC6722B@it.ox.ac.uk>
	<508AC205.5060902@it.ox.ac.uk>
Message-ID: <0118a031-f981-41d8-85e0-161830e2225e@HUB02.ad.oak.ox.ac.uk>

I have a feeling this is a disaster, and that the example schemas are
not being rebuilt every time, but are being preserved across builds

--
Sebastian Rahtz      
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431


From bansp at o2.pl  Fri Oct 26 13:23:09 2012
From: bansp at o2.pl (Piotr Banski)
Date: Fri, 26 Oct 2012 19:23:09 +0200
Subject: [tei-council] release notes & Lite
In-Reply-To: <0118a031-f981-41d8-85e0-161830e2225e@HUB02.ad.oak.ox.ac.uk>
References: <D41E9818-35AC-4EA2-BA50-EB58893B978C@it.ox.ac.uk>
	<5089CDF9.1070904@ultraslavonic.info>
	<alpine.OSX.2.00.1210261254180.36525@lister.ei.virginia.edu>
	<62CABDAB-6A7E-41C2-9E3A-2DEA3EC6722B@it.ox.ac.uk>
	<508AC205.5060902@it.ox.ac.uk>
	<0118a031-f981-41d8-85e0-161830e2225e@HUB02.ad.oak.ox.ac.uk>
Message-ID: <508AC6FD.2070402@o2.pl>

On 26/10/12 19:07, Sebastian Rahtz wrote:
> I have a feeling this is a disaster, and that the example schemas are
> not being rebuilt every time, but are being preserved across builds

Disaster or just a... "latent feature", to be handled by the next release?

   P.

From sebastian.rahtz at it.ox.ac.uk  Fri Oct 26 13:30:54 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Fri, 26 Oct 2012 17:30:54 +0000
Subject: [tei-council] release notes & Lite
In-Reply-To: <508AC6FD.2070402@o2.pl>
References: <D41E9818-35AC-4EA2-BA50-EB58893B978C@it.ox.ac.uk>
	<5089CDF9.1070904@ultraslavonic.info>
	<alpine.OSX.2.00.1210261254180.36525@lister.ei.virginia.edu>
	<62CABDAB-6A7E-41C2-9E3A-2DEA3EC6722B@it.ox.ac.uk>
	<508AC205.5060902@it.ox.ac.uk>
	<0118a031-f981-41d8-85e0-161830e2225e@HUB02.ad.oak.ox.ac.uk>
	<508AC6FD.2070402@o2.pl>
Message-ID: <A3224732-3D51-4524-8D97-6FDEA61E39AE@it.ox.ac.uk>


On 26 Oct 2012, at 18:23, Piotr Banski <bansp at o2.pl>
 wrote:

> On 26/10/12 19:07, Sebastian Rahtz wrote:
>> I have a feeling this is a disaster, and that the example schemas are
>> not being rebuilt every time, but are being preserved across builds
> 
> Disaster or just a... "latent feature", to be handled by the next release?


investigating. not promising anythuing.
--
Sebastian Rahtz      
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431


From lou.burnard at retired.ox.ac.uk  Fri Oct 26 15:02:17 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Fri, 26 Oct 2012 19:02:17 +0000
Subject: [tei-council] release notes & Lite
In-Reply-To: <alpine.OSX.2.00.1210261254180.36525@lister.ei.virginia.edu>
References: <D41E9818-35AC-4EA2-BA50-EB58893B978C@it.ox.ac.uk>
	<5089CDF9.1070904@ultraslavonic.info>,
	<alpine.OSX.2.00.1210261254180.36525@lister.ei.virginia.edu>
Message-ID: <p9hkhq1by5xvdg8080ukf3tk.1351278023126@email.android.com>

this sounds like a very good idea. I will do it after dinner.

David Sewell <dsewell at virginia.edu> wrote:


We could create a text file at the location pointed to by
http://www.tei-c.org/release/xml/tei/custom/schema/dtd/teilite.dtd to note the
name and schema changes.

Incidentally, everything under
http://www.tei-c.org/release/xml/tei/custom/schema seems to be at edition 2.1.0,
"Last updated on 17th June 2012". Is that right? Shouldn't those all be 2.2.0?
(If I'm missing something totally obvious, ignore the question.)

On Thu, 25 Oct 2012, Kevin Hawkins wrote:

> I have a to-do list item for myself to correct the links for Lite at
> http://www.tei-c.org/Guidelines/Customization/ to include the
> underscore.  As for whether to set up a redirect, I think we agreed that
> we shouldn't because major changes have been made to Lite since the last
> release, so it is different enough that we want people to be clued in to
> the change.  But I can be convinced otherwise.  --K.
>
> On 10/25/12 6:15 PM, Sebastian Rahtz wrote:
>> I wonder, how much should we draw attention to the fact that the schema for  Lite has changed name?
>> Those few, those lucky few, who point their docs at
>>
>>        http://www.tei-c.org/release/xml/tei/custom/schema/dtd/teilite.dtd
>>
>> are going to wake up in a few days to find their favourite resource gone. We agreed this
>> was OK, but they won't find it mentioned in the release notes.
>>
>> Or am I misremembering and have we asked David or Kevin to add a rewrite
>> rule to make the above url work?
>> --
>> Sebastian Rahtz
>> Director (Research Support) of Academic IT Services
>> University of Oxford IT Services
>> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>>
>

--
David Sewell, Editorial and Technical Manager
ROTUNDA, The University of Virginia Press
PO Box 400314, Charlottesville, VA 22904-4314 USA
Email: dsewell at virginia.edu   Tel: +1 434 924 9973
Web: http://rotunda.upress.virginia.edu/
--
tei-council mailing list
tei-council at lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

PLEASE NOTE: postings to this list are publicly archived

From mholmes at uvic.ca  Fri Oct 26 15:04:54 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Fri, 26 Oct 2012 12:04:54 -0700
Subject: [tei-council] release notes & Lite
In-Reply-To: <A3224732-3D51-4524-8D97-6FDEA61E39AE@it.ox.ac.uk>
References: <D41E9818-35AC-4EA2-BA50-EB58893B978C@it.ox.ac.uk>
	<5089CDF9.1070904@ultraslavonic.info>
	<alpine.OSX.2.00.1210261254180.36525@lister.ei.virginia.edu>
	<62CABDAB-6A7E-41C2-9E3A-2DEA3EC6722B@it.ox.ac.uk>
	<508AC205.5060902@it.ox.ac.uk>
	<0118a031-f981-41d8-85e0-161830e2225e@HUB02.ad.oak.ox.ac.uk>
	<508AC6FD.2070402@o2.pl>
	<A3224732-3D51-4524-8D97-6FDEA61E39AE@it.ox.ac.uk>
Message-ID: <508ADED6.5050403@uvic.ca>

Problems are in:

P5/DTD
P5/Exemplars
P5/Schema

and in these files in P5:

p5odd-examples.rnc/g
p5odds.rnc/g

Apparently nowhere else.

On 12-10-26 10:30 AM, Sebastian Rahtz wrote:
>
> On 26 Oct 2012, at 18:23, Piotr Banski <bansp at o2.pl>
>   wrote:
>
>> On 26/10/12 19:07, Sebastian Rahtz wrote:
>>> I have a feeling this is a disaster, and that the example schemas are
>>> not being rebuilt every time, but are being preserved across builds
>>
>> Disaster or just a... "latent feature", to be handled by the next release?
>
>
> investigating. not promising anythuing.
> --
> Sebastian Rahtz
> Director (Research Support) of Academic IT Services
> University of Oxford IT Services
> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From mholmes at uvic.ca  Fri Oct 26 15:08:51 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Fri, 26 Oct 2012 12:08:51 -0700
Subject: [tei-council] release notes & Lite
In-Reply-To: <508ADED6.5050403@uvic.ca>
References: <D41E9818-35AC-4EA2-BA50-EB58893B978C@it.ox.ac.uk>
	<5089CDF9.1070904@ultraslavonic.info>
	<alpine.OSX.2.00.1210261254180.36525@lister.ei.virginia.edu>
	<62CABDAB-6A7E-41C2-9E3A-2DEA3EC6722B@it.ox.ac.uk>
	<508AC205.5060902@it.ox.ac.uk>
	<0118a031-f981-41d8-85e0-161830e2225e@HUB02.ad.oak.ox.ac.uk>
	<508AC6FD.2070402@o2.pl>	<A3224732-3D51-4524-8D97-6FDEA61E39AE@it.ox.ac.uk>
	<508ADED6.5050403@uvic.ca>
Message-ID: <508ADFC3.9020801@uvic.ca>

Options:

Quick-fix search-and-replace on the release package, for the bad date 
and version number, then update the website, the oxygen-tei package and 
the debs, followed by debug, fix, and point release; or

debug, fix and do point release when we're ready, leaving 2.2.0 as 
damaged (but usable -- only the version and date are wrong).

Thoughts?

On 12-10-26 12:04 PM, Martin Holmes wrote:
> Problems are in:
>
> P5/DTD
> P5/Exemplars
> P5/Schema
>
> and in these files in P5:
>
> p5odd-examples.rnc/g
> p5odds.rnc/g
>
> Apparently nowhere else.
>
> On 12-10-26 10:30 AM, Sebastian Rahtz wrote:
>>
>> On 26 Oct 2012, at 18:23, Piotr Banski <bansp at o2.pl>
>>    wrote:
>>
>>> On 26/10/12 19:07, Sebastian Rahtz wrote:
>>>> I have a feeling this is a disaster, and that the example schemas are
>>>> not being rebuilt every time, but are being preserved across builds
>>>
>>> Disaster or just a... "latent feature", to be handled by the next release?
>>
>>
>> investigating. not promising anythuing.
>> --
>> Sebastian Rahtz
>> Director (Research Support) of Academic IT Services
>> University of Oxford IT Services
>> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>>
>

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From lou.burnard at retired.ox.ac.uk  Fri Oct 26 15:26:42 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Fri, 26 Oct 2012 19:26:42 +0000
Subject: [tei-council] release notes & Lite
In-Reply-To: <508ADFC3.9020801@uvic.ca>
References: <D41E9818-35AC-4EA2-BA50-EB58893B978C@it.ox.ac.uk>
	<5089CDF9.1070904@ultraslavonic.info>
	<alpine.OSX.2.00.1210261254180.36525@lister.ei.virginia.edu>
	<62CABDAB-6A7E-41C2-9E3A-2DEA3EC6722B@it.ox.ac.uk>
	<508AC205.5060902@it.ox.ac.uk>
	<0118a031-f981-41d8-85e0-161830e2225e@HUB02.ad.oak.ox.ac.uk>
	<508AC6FD.2070402@o2.pl>	<A3224732-3D51-4524-8D97-6FDEA61E39AE@it.ox.ac.uk>
	<508ADED6.5050403@uvic.ca>,<508ADFC3.9020801@uvic.ca>
Message-ID: <6fvuuoia9xnjhum1ngd27jrf.1351279448231@email.android.com>

option two for me every time

Martin Holmes <mholmes at uvic.ca> wrote:


Options:

Quick-fix search-and-replace on the release package, for the bad date
and version number, then update the website, the oxygen-tei package and
the debs, followed by debug, fix, and point release; or

debug, fix and do point release when we're ready, leaving 2.2.0 as
damaged (but usable -- only the version and date are wrong).

Thoughts?

On 12-10-26 12:04 PM, Martin Holmes wrote:
> Problems are in:
>
> P5/DTD
> P5/Exemplars
> P5/Schema
>
> and in these files in P5:
>
> p5odd-examples.rnc/g
> p5odds.rnc/g
>
> Apparently nowhere else.
>
> On 12-10-26 10:30 AM, Sebastian Rahtz wrote:
>>
>> On 26 Oct 2012, at 18:23, Piotr Banski <bansp at o2.pl>
>>    wrote:
>>
>>> On 26/10/12 19:07, Sebastian Rahtz wrote:
>>>> I have a feeling this is a disaster, and that the example schemas are
>>>> not being rebuilt every time, but are being preserved across builds
>>>
>>> Disaster or just a... "latent feature", to be handled by the next release?
>>
>>
>> investigating. not promising anythuing.
>> --
>> Sebastian Rahtz
>> Director (Research Support) of Academic IT Services
>> University of Oxford IT Services
>> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>>
>

--
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)
--
tei-council mailing list
tei-council at lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

PLEASE NOTE: postings to this list are publicly archived

From sebastian.rahtz at it.ox.ac.uk  Fri Oct 26 15:34:59 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Fri, 26 Oct 2012 19:34:59 +0000
Subject: [tei-council] release notes & Lite
In-Reply-To: <508ADFC3.9020801@uvic.ca>
References: <D41E9818-35AC-4EA2-BA50-EB58893B978C@it.ox.ac.uk>
	<5089CDF9.1070904@ultraslavonic.info>
	<alpine.OSX.2.00.1210261254180.36525@lister.ei.virginia.edu>
	<62CABDAB-6A7E-41C2-9E3A-2DEA3EC6722B@it.ox.ac.uk>
	<508AC205.5060902@it.ox.ac.uk>
	<0118a031-f981-41d8-85e0-161830e2225e@HUB02.ad.oak.ox.ac.uk>
	<508AC6FD.2070402@o2.pl>	<A3224732-3D51-4524-8D97-6FDEA61E39AE@it.ox.ac.uk>
	<508ADED6.5050403@uvic.ca> <508ADFC3.9020801@uvic.ca>
Message-ID: <80DC437F-E6CE-485E-AACE-E33B80493188@it.ox.ac.uk>


On 26 Oct 2012, at 20:08, Martin Holmes <mholmes at uvic.ca>
 wrote:
> 
> Quick-fix search-and-replace on the release package, for the bad date 
> and version number, then update the website, the oxygen-tei package and 
> the debs, followed by debug, fix, and point release; or
> 
> debug, fix and do point release when we're ready, leaving 2.2.0 as 
> damaged (but usable -- only the version and date are wrong).


i believe the problem is deeper than the date and version number.
if its just those, the ok, do the first; otherwise, its gotta be 2.2.1
--
Sebastian Rahtz      
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431


From mholmes at uvic.ca  Fri Oct 26 16:15:54 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Fri, 26 Oct 2012 13:15:54 -0700
Subject: [tei-council] release notes & Lite
In-Reply-To: <80DC437F-E6CE-485E-AACE-E33B80493188@it.ox.ac.uk>
References: <D41E9818-35AC-4EA2-BA50-EB58893B978C@it.ox.ac.uk>
	<5089CDF9.1070904@ultraslavonic.info>
	<alpine.OSX.2.00.1210261254180.36525@lister.ei.virginia.edu>
	<62CABDAB-6A7E-41C2-9E3A-2DEA3EC6722B@it.ox.ac.uk>
	<508AC205.5060902@it.ox.ac.uk>
	<0118a031-f981-41d8-85e0-161830e2225e@HUB02.ad.oak.ox.ac.uk>
	<508AC6FD.2070402@o2.pl>	<A3224732-3D51-4524-8D97-6FDEA61E39AE@it.ox.ac.uk>
	<508ADED6.5050403@uvic.ca> <508ADFC3.9020801@uvic.ca>
	<80DC437F-E6CE-485E-AACE-E33B80493188@it.ox.ac.uk>
Message-ID: <508AEF7A.9090908@uvic.ca>

I think I might have found something: the last date on which lots of 
schemas were built was June 21, and there's this:

r10605 | martindholmes | 2012-06-22 14:17:53 -0700 (Fri, 22 Jun 2012) | 
2 lines
Changed paths:
    M /trunk/P5/Makefile

Commenting out apparently redundant duplicate target line for "valid", 
after consulting with Sebastian and Syd. If all hell breaks loose, we 
can just change it back.
-----------------------------

It's possible that all hell did in fact break loose, and we didn't 
notice. I've restored the line, and we'll see what Mr Jenkins does.

If it was caused by that, my apologies. If not, there were a lot of 
other changes to the Makefile around that time, so we can look closely 
at them.

Cheers,
Martin



On 12-10-26 12:34 PM, Sebastian Rahtz wrote:
>
> On 26 Oct 2012, at 20:08, Martin Holmes <mholmes at uvic.ca>
>   wrote:
>>
>> Quick-fix search-and-replace on the release package, for the bad date
>> and version number, then update the website, the oxygen-tei package and
>> the debs, followed by debug, fix, and point release; or
>>
>> debug, fix and do point release when we're ready, leaving 2.2.0 as
>> damaged (but usable -- only the version and date are wrong).
>
>
> i believe the problem is deeper than the date and version number.
> if its just those, the ok, do the first; otherwise, its gotta be 2.2.1
> --
> Sebastian Rahtz
> Director (Research Support) of Academic IT Services
> University of Oxford IT Services
> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>
>

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From mholmes at uvic.ca  Fri Oct 26 16:33:23 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Fri, 26 Oct 2012 13:33:23 -0700
Subject: [tei-council] release notes & Lite
In-Reply-To: <508AEF7A.9090908@uvic.ca>
References: <D41E9818-35AC-4EA2-BA50-EB58893B978C@it.ox.ac.uk>
	<5089CDF9.1070904@ultraslavonic.info>
	<alpine.OSX.2.00.1210261254180.36525@lister.ei.virginia.edu>
	<62CABDAB-6A7E-41C2-9E3A-2DEA3EC6722B@it.ox.ac.uk>
	<508AC205.5060902@it.ox.ac.uk>
	<0118a031-f981-41d8-85e0-161830e2225e@HUB02.ad.oak.ox.ac.uk>
	<508AC6FD.2070402@o2.pl>	<A3224732-3D51-4524-8D97-6FDEA61E39AE@it.ox.ac.uk>
	<508ADED6.5050403@uvic.ca> <508ADFC3.9020801@uvic.ca>
	<80DC437F-E6CE-485E-AACE-E33B80493188@it.ox.ac.uk>
	<508AEF7A.9090908@uvic.ca>
Message-ID: <508AF393.9030501@uvic.ca>

I was looking at dates on my local machine. Looking at my Jinks 
workspace, the last date for lots of schemas in Exemplars to be built 
was June 29. Following that, I think schemas are only rebuilt if their 
ODD file changes.

So something that happened between June 29 and August 4, when tei_all 
was built without the rest being built, must have caused it, I think.

Cheers,
Martin

On 12-10-26 01:15 PM, Martin Holmes wrote:
> I think I might have found something: the last date on which lots of
> schemas were built was June 21, and there's this:
>
> r10605 | martindholmes | 2012-06-22 14:17:53 -0700 (Fri, 22 Jun 2012) |
> 2 lines
> Changed paths:
>      M /trunk/P5/Makefile
>
> Commenting out apparently redundant duplicate target line for "valid",
> after consulting with Sebastian and Syd. If all hell breaks loose, we
> can just change it back.
> -----------------------------
>
> It's possible that all hell did in fact break loose, and we didn't
> notice. I've restored the line, and we'll see what Mr Jenkins does.
>
> If it was caused by that, my apologies. If not, there were a lot of
> other changes to the Makefile around that time, so we can look closely
> at them.
>
> Cheers,
> Martin
>
>
>
> On 12-10-26 12:34 PM, Sebastian Rahtz wrote:
>>
>> On 26 Oct 2012, at 20:08, Martin Holmes <mholmes at uvic.ca>
>>    wrote:
>>>
>>> Quick-fix search-and-replace on the release package, for the bad date
>>> and version number, then update the website, the oxygen-tei package and
>>> the debs, followed by debug, fix, and point release; or
>>>
>>> debug, fix and do point release when we're ready, leaving 2.2.0 as
>>> damaged (but usable -- only the version and date are wrong).
>>
>>
>> i believe the problem is deeper than the date and version number.
>> if its just those, the ok, do the first; otherwise, its gotta be 2.2.1
>> --
>> Sebastian Rahtz
>> Director (Research Support) of Academic IT Services
>> University of Oxford IT Services
>> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>>
>>
>

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From lou.burnard at retired.ox.ac.uk  Fri Oct 26 16:37:13 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Fri, 26 Oct 2012 21:37:13 +0100
Subject: [tei-council] teilite.dtd standin
Message-ID: <508AF479.9070409@retired.ox.ac.uk>

Everyone happy if I plonk this in the appropriate place on the TEI website?

----

<!--

What's happened to the file teilite.dtd ?

At Release 2.2.0 of TEI P5 the TEI Lite customization was renamed
tei_lite, for two reasons. Firstly, for compatibility with all the
other TEI customizations; secondly, to signal that this version of TEI
Lite is constructed in a different way from preceding versions.

TEI Lite was first defined in 1996, and has been very widely
disseminated. Consequently there are now  many many, often mutually
incompatible, files called "teilite.dtd" around on the internet.
Some of these are TEI P4 files, some are earlier TEI P5 versions, and
there has been no systematic use of version numbering to distinguish
them.

In this new version, the schema is defined in a way that is more
independent of changes in the underlying TEI P5 infrastructure.
As of this release, the TEI undertakes to maintain the current state
of TEI Lite unchanged, and to validate its compatibility with future
TEI P5 releases.

LB, for TEI Technical Council
27 Oct 2012

-->



From kevin.s.hawkins at ultraslavonic.info  Fri Oct 26 17:11:59 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Fri, 26 Oct 2012 17:11:59 -0400
Subject: [tei-council] teilite.dtd standin
In-Reply-To: <508AF479.9070409@retired.ox.ac.uk>
References: <508AF479.9070409@retired.ox.ac.uk>
Message-ID: <508AFC9F.9060202@ultraslavonic.info>

Looks good.

On 10/26/2012 4:37 PM, Lou Burnard wrote:
> Everyone happy if I plonk this in the appropriate place on the TEI website?
>
> ----
>
> <!--
>
> What's happened to the file teilite.dtd ?
>
> At Release 2.2.0 of TEI P5 the TEI Lite customization was renamed
> tei_lite, for two reasons. Firstly, for compatibility with all the
> other TEI customizations; secondly, to signal that this version of TEI
> Lite is constructed in a different way from preceding versions.
>
> TEI Lite was first defined in 1996, and has been very widely
> disseminated. Consequently there are now  many many, often mutually
> incompatible, files called "teilite.dtd" around on the internet.
> Some of these are TEI P4 files, some are earlier TEI P5 versions, and
> there has been no systematic use of version numbering to distinguish
> them.
>
> In this new version, the schema is defined in a way that is more
> independent of changes in the underlying TEI P5 infrastructure.
> As of this release, the TEI undertakes to maintain the current state
> of TEI Lite unchanged, and to validate its compatibility with future
> TEI P5 releases.
>
> LB, for TEI Technical Council
> 27 Oct 2012
>
> -->
>
>

From sebastian.rahtz at it.ox.ac.uk  Fri Oct 26 17:36:08 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Fri, 26 Oct 2012 21:36:08 +0000
Subject: [tei-council] teilite.dtd standin
In-Reply-To: <508AFC9F.9060202@ultraslavonic.info>
References: <508AF479.9070409@retired.ox.ac.uk>
	<508AFC9F.9060202@ultraslavonic.info>
Message-ID: <415BCCD6-B24E-47FE-AD0F-4D52C2E14F2C@it.ox.ac.uk>

sorry to be a party pooper, but this is (IMHO) an awful idea. My
file containing

 <!DOCTYPE ...." SYSTEM "...tei_lite.dtd">

will now fail catastrophically, saying the DTD is invalid,
and I will have no idea why. Making the file non-existent
would be a much cleaner error.

heck, I dont care that much but mark my words there'll
be tears......
--
Sebastian Rahtz      
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431


From sebastian.rahtz at it.ox.ac.uk  Fri Oct 26 17:49:18 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Fri, 26 Oct 2012 21:49:18 +0000
Subject: [tei-council] release notes & Lite
In-Reply-To: <508AF393.9030501@uvic.ca>
References: <D41E9818-35AC-4EA2-BA50-EB58893B978C@it.ox.ac.uk>
	<5089CDF9.1070904@ultraslavonic.info>
	<alpine.OSX.2.00.1210261254180.36525@lister.ei.virginia.edu>
	<62CABDAB-6A7E-41C2-9E3A-2DEA3EC6722B@it.ox.ac.uk>
	<508AC205.5060902@it.ox.ac.uk>
	<0118a031-f981-41d8-85e0-161830e2225e@HUB02.ad.oak.ox.ac.uk>
	<508AC6FD.2070402@o2.pl>	<A3224732-3D51-4524-8D97-6FDEA61E39AE@it.ox.ac.uk>
	<508ADED6.5050403@uvic.ca> <508ADFC3.9020801@uvic.ca>
	<80DC437F-E6CE-485E-AACE-E33B80493188@it.ox.ac.uk>
	<508AEF7A.9090908@uvic.ca> <508AF393.9030501@uvic.ca>
Message-ID: <D4D5E8AE-B27F-4B78-B182-C3B9A84E5945@it.ox.ac.uk>

Yes, I am with you on this. The dependencies are not right,
so things are not getting rebuilt. I have added a "make clean"
to Oxford Jenkins, to force the right effect.

I think this is all me to blame, to be honest. I didn't think
through some of the eventualities when I attempted some
Makefile goodness in the summer.

I have stuck in a new faster way to validate HTML, 
which may even work.
--
Sebastian Rahtz      
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431


From sebastian.rahtz at it.ox.ac.uk  Fri Oct 26 18:11:15 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Fri, 26 Oct 2012 22:11:15 +0000
Subject: [tei-council] 2.2.0  / 2.1.0
Message-ID: <327C29A7-72D0-448D-BF7A-1708C2C239F5@it.ox.ac.uk>

I just pulled the release from SF and did some searches; my view is that only the files in xml/tei/custom/schema
are affected, but that they are (potentially) badly affected - they are the versions from June.

I feel like crying, to be honest :-{

We need a rapid decision - is this a rapid replacement reissue
or version 2.3.0?  and who will do it.

HOWEVER, I at least need some more time to check things are actually working
properly now, I don't trust my patches and its too late at night. So someone
make some decisions tomorrow am.

PS if its not obvious, can I stress that this unfortunate event is no way
the result of anything Piotr, James and Martin did during the release?
--
Sebastian Rahtz      
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431


From james.cummings at it.ox.ac.uk  Fri Oct 26 18:42:24 2012
From: james.cummings at it.ox.ac.uk (James Cummings)
Date: Fri, 26 Oct 2012 22:42:24 +0000
Subject: [tei-council] 2.2.0  / 2.1.0
In-Reply-To: <327C29A7-72D0-448D-BF7A-1708C2C239F5@it.ox.ac.uk>
References: <327C29A7-72D0-448D-BF7A-1708C2C239F5@it.ox.ac.uk>
Message-ID: <711b0f44-012c-4bbf-84c1-8770ddd9fcb5@HUB04.ad.oak.ox.ac.uk>


I would argue that if we do it in the next few days it is a reissue or 2.2.1 not 2.3.0 ...

The version numbering indicated our intention of the full changes to the schema part of which did not get released.

Sound reasonable?

JamesC
--
James Cummings, Research Support, IT Services, University of Oxford (from phone)

Sebastian Rahtz <sebastian.rahtz at it.ox.ac.uk> wrote:


I just pulled the release from SF and did some searches; my view is that only the files in xml/tei/custom/schema
are affected, but that they are (potentially) badly affected - they are the versions from June.

I feel like crying, to be honest :-{

We need a rapid decision - is this a rapid replacement reissue
or version 2.3.0?  and who will do it.

HOWEVER, I at least need some more time to check things are actually working
properly now, I don't trust my patches and its too late at night. So someone
make some decisions tomorrow am.

PS if its not obvious, can I stress that this unfortunate event is no way
the result of anything Piotr, James and Martin did during the release?
--
Sebastian Rahtz
Director (Research Support) of Academic IT Services
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431

--
tei-council mailing list
tei-council at lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

PLEASE NOTE: postings to this list are publicly archived

From bansp at o2.pl  Fri Oct 26 20:27:44 2012
From: bansp at o2.pl (Piotr Banski)
Date: Sat, 27 Oct 2012 02:27:44 +0200
Subject: [tei-council] 2.2.0  / 2.1.0
In-Reply-To: <711b0f44-012c-4bbf-84c1-8770ddd9fcb5@HUB04.ad.oak.ox.ac.uk>
References: <327C29A7-72D0-448D-BF7A-1708C2C239F5@it.ox.ac.uk>
	<711b0f44-012c-4bbf-84c1-8770ddd9fcb5@HUB04.ad.oak.ox.ac.uk>
Message-ID: <508B2A80.3060608@o2.pl>

I'm relatively available, on Sat and Sun evenings, and during the week.

I've already asked Shayne to hibernate my tei-c.org account, but I guess 
that that is not necessarily a problem.

In other words, I'm available to do a re-release.

Best,

   P.

On 27/10/12 00:42, James Cummings wrote:
>
> I would argue that if we do it in the next few days it is a reissue or 2.2.1 not 2.3.0 ...
>
> The version numbering indicated our intention of the full changes to the schema part of which did not get released.
>
> Sound reasonable?
>
> JamesC
> --
> James Cummings, Research Support, IT Services, University of Oxford (from phone)
>
> Sebastian Rahtz <sebastian.rahtz at it.ox.ac.uk> wrote:
>
>
> I just pulled the release from SF and did some searches; my view is that only the files in xml/tei/custom/schema
> are affected, but that they are (potentially) badly affected - they are the versions from June.
>
> I feel like crying, to be honest :-{
>
> We need a rapid decision - is this a rapid replacement reissue
> or version 2.3.0?  and who will do it.
>
> HOWEVER, I at least need some more time to check things are actually working
> properly now, I don't trust my patches and its too late at night. So someone
> make some decisions tomorrow am.
>
> PS if its not obvious, can I stress that this unfortunate event is no way
> the result of anything Piotr, James and Martin did during the release?
> --
> Sebastian Rahtz
> Director (Research Support) of Academic IT Services
> University of Oxford IT Services
> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>
> --
> tei-council mailing list
> tei-council at lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>
> PLEASE NOTE: postings to this list are publicly archived
>


From mholmes at uvic.ca  Sat Oct 27 02:09:00 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Fri, 26 Oct 2012 23:09:00 -0700
Subject: [tei-council] 2.2.0  / 2.1.0
In-Reply-To: <327C29A7-72D0-448D-BF7A-1708C2C239F5@it.ox.ac.uk>
References: <327C29A7-72D0-448D-BF7A-1708C2C239F5@it.ox.ac.uk>
Message-ID: <508B7A7C.4040608@uvic.ca>

On 12-10-26 03:11 PM, Sebastian Rahtz wrote:
> I just pulled the release from SF and did some searches; my view is that only the files in xml/tei/custom/schema
> are affected, but that they are (potentially) badly affected - they are the versions from June.

You're right that those are the ones affected as far as I can see.

> I feel like crying, to be honest :-{

I hope you're not serious. A few slightly borked schemas available for 
48 hours is not a disaster. Most people are still using P4 anyway. :-)

> We need a rapid decision - is this a rapid replacement reissue
> or version 2.3.0?  and who will do it.

I think we should rapidly replace the existing 2.2 schemas with the ones 
from the Oxford Jinks. Only James, Piotr and I think you can do that; 
the rest of us no longer have active logins for tei-c.org due to the new 
security thing.

Then I think we should do 2.2.1 within a few days. Kevin might try being 
release tech, if he's got time, and if not, I'm happy to do it. I 
wouldn't mind going through TCW22 again one more time while the recent 
experience is fresh in my mind.

> HOWEVER, I at least need some more time to check things are actually working
> properly now, I don't trust my patches and its too late at night. So someone
> make some decisions tomorrow am.

James's decision, ultimately, I think.

> PS if its not obvious, can I stress that this unfortunate event is no way
> the result of anything Piotr, James and Martin did during the release?

It's still not clear (to me anyway) whether it was something you did, or 
my decision back in June to comment out that one line in the P5 
Makefile. It might perfectly well be my fault.

As it stands, your Jinks (whose workspaces you wiped out) is building 
with the correct date, but mine (which I left intact) is not; it still 
has the old dates. That means that we haven't actually fixed the problem 
yet; if we don't get my Jinks to build correctly, then the next time we 
come to do this, we'll have the same issue (and lastSuccessfulArtifact 
schemas in between releases will be borked).

One thing is clear to me: I had intended to gain a better understanding 
of how the Makefiles work, but I've failed to do that. I understand 
individual blocks, but I don't have a clear idea of how all the 
different targets fit together. I think it might be a good idea for me 
to try making some flowcharts that map out how the builds proceed, so I 
have a clearer sense of where to look when something goes wrong.

Cheers,
Martin

> --
> Sebastian Rahtz
> Director (Research Support) of Academic IT Services
> University of Oxford IT Services
> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>

-- 
Martin Holmes
mholmes at uvic.ca
UVic Humanities Computing and Media Centre

From mholmes at uvic.ca  Sat Oct 27 02:35:20 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Fri, 26 Oct 2012 23:35:20 -0700
Subject: [tei-council] 2.2.0  / 2.1.0
In-Reply-To: <508B7A7C.4040608@uvic.ca>
References: <327C29A7-72D0-448D-BF7A-1708C2C239F5@it.ox.ac.uk>
	<508B7A7C.4040608@uvic.ca>
Message-ID: <508B80A8.5080800@uvic.ca>

On 12-10-26 11:09 PM, Martin Holmes wrote:

> Then I think we should do 2.2.1 within a few days. Kevin might try being
> release tech, if he's got time, and if not, I'm happy to do it. I
> wouldn't mind going through TCW22 again one more time while the recent
> experience is fresh in my mind.

On 12-10-26 05:27 PM, Piotr Banski wrote:
 > In other words, I'm available to do a re-release.

Sorry, I didn't mean to suggest that it shouldn't be you; I just figured 
you'd done so much more than your duty on Thursday (and Friday) you 
might not want to face it again!

If you're willing, it would be an even better test of TCW22 to have you 
go through the revised version and see if we've made all the necessary 
changes.

Cheers,
Martin
-- 
Martin Holmes
mholmes at uvic.ca
UVic Humanities Computing and Media Centre

From lou.burnard at retired.ox.ac.uk  Sat Oct 27 07:55:52 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Sat, 27 Oct 2012 12:55:52 +0100
Subject: [tei-council] teilite.dtd standin
In-Reply-To: <B09E0153-F2AA-48E8-9C3E-8F5F02BC8C08@it.ox.ac.uk>
References: <508AF479.9070409@retired.ox.ac.uk>
	<508AFC9F.9060202@ultraslavonic.info>
	<415BCCD6-B24E-47FE-AD0F-4D52C2E14F2C@it.ox.ac.uk>
	<508BA151.7020909@retired.ox.ac.uk>
	<B09E0153-F2AA-48E8-9C3E-8F5F02BC8C08@it.ox.ac.uk>
Message-ID: <508BCBC8.4020000@retired.ox.ac.uk>

I had a vague memory that we considered but decided against doing a 
redirection though I can't remember why. But if it's possible, I agree 
this would be preferable.



On 27/10/12 12:08, Sebastian Rahtz wrote:
> On 27 Oct 2012, at 09:54, Lou Burnard <lou.burnard at retired.ox.ac.uk> wrote:
>
>> On 26/10/12 22:36, Sebastian Rahtz wrote:
>>> sorry to be a party pooper, but this is (IMHO) an awful idea.
>> so what would you propose we do instead?
>>
> My preference is for a rewrite teilite.{dtd,rnc,rng) -> tei_lite.{dtd,rnc,rng)
> because for most people it will just work. My second preference
> is for no file at all, and trigger a comprehensible 404 error.
>
>>>   My
>>> file containing
>>>
>>>   <!DOCTYPE ...." SYSTEM "...tei_lite.dtd">
>>>
>>> will now fail catastrophically, saying the DTD is invalid,
>>> and I will have no idea why.
>> Possibly you'll think, hmm, maybe I should take a look at that file?
>>
> I fear that we come from a generation which thinks like that. I have
> no confidence many other people conceptualize the world like that.
>
> Consider the person with a repository of 1000 files, in P5, with
> a  DOCTYPE pointing at Lite from the web site.  Possibly
> these links are auto-generated. The user sees HTML generated on
> the fly. Suddenly the HTML stops working. The error, when some
> poor sys person follows up, says that the DTD is invalid. They follow
> up, and find that the document calling itself teilite.dtd isn't a DTD at all!
> I call that counter-intuitive. If the error is a 404, they say "oh well, links
> break on the web, I wonder where its moved to" and go look.
>
> You may well reply that this scenario doesnt exist ....
>>> Making the file non-existent
>>> would be a much cleaner error.
>> Is that your proposal? we simply remove the file teilite.dtd wherever we can? I dont mind doing that, but it doesnt help with the fact that lots of people point to copies of it we don't control.
> thats an issue, always has been, i agree
>
>>   If the one we do control explains itself, maybe that's a good thing?
>>
> sure, its an argument.
>
> would you like it if, when you typed "perl", you got a message
> saying that the file /usr/bin/perl was not executable, and you found,
> on examining it, that it was in fact a README saying "gone fishing, use python instead"?
> of course, you'd prefer it if that /usr/bin/perl _was_ executable, and gave you
> a human readable message when you ran it. But we cant do that, since DTDs
> dont do anything.  But having a file which claims (by its suffix and by its location)
> to be a DTD, but isnt one, seems wrong.
> --
> Sebastian Rahtz
> Director (Research Support) of Academic IT Services
> University of Oxford IT Services
> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>


From sebastian.rahtz at it.ox.ac.uk  Sat Oct 27 08:28:31 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Sat, 27 Oct 2012 12:28:31 +0000
Subject: [tei-council] 2.2.0  / 2.1.0
In-Reply-To: <508B80A8.5080800@uvic.ca>
References: <327C29A7-72D0-448D-BF7A-1708C2C239F5@it.ox.ac.uk>
	<508B7A7C.4040608@uvic.ca> <508B80A8.5080800@uvic.ca>
Message-ID: <736818A2-DD37-4F8F-9360-AD877A6602EC@it.ox.ac.uk>

I have pressed the Big Red Button, in that I have run the install on www.tei-c.org, remade the Debian packages,
and remade the oxygen package.  It seems important that the damage is undone as soon as possible,
and then worry about comms and repairs later.

There is an issue which has emerged as a result of the build working properly. 
Look at http://bits.nsms.ox.ac.uk:8080/jenkins/job/TEIP5/741/parsed_console/?
and you'll see an issue over something in tei_speech. I don't want to look at and fix
this now, for several reasons

 - i am going to the pictures to see James Bond shortly
 - that sort of error is horrible to track down
 - the fix might mean  a 2.3.0 release
 - i have to concentrate on other stuff

but if someone else feels strong....

PS the fact that tei_dictionaries.* is still in the distro is something which can be fixed at leisure
PPS if you are an "ant"-savvy person, look at P5/Test/antruntest.xml which I started working
on, and see if you can finish it off. if you succeed then lo! you have built a new Roma script.
--
Sebastian Rahtz      
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431


From kevin.s.hawkins at ultraslavonic.info  Sat Oct 27 11:03:17 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Sat, 27 Oct 2012 11:03:17 -0400
Subject: [tei-council] 2.2.0  / 2.1.0
In-Reply-To: <508B80A8.5080800@uvic.ca>
References: <327C29A7-72D0-448D-BF7A-1708C2C239F5@it.ox.ac.uk>
	<508B7A7C.4040608@uvic.ca> <508B80A8.5080800@uvic.ca>
Message-ID: <508BF7B5.8020602@ultraslavonic.info>

On 10/27/12 2:35 AM, Martin Holmes wrote:
> On 12-10-26 11:09 PM, Martin Holmes wrote:
>
>> Then I think we should do 2.2.1 within a few days. Kevin might try being
>> release tech, if he's got time, and if not, I'm happy to do it. I
>> wouldn't mind going through TCW22 again one more time while the recent
>> experience is fresh in my mind.
>
> On 12-10-26 05:27 PM, Piotr Banski wrote:
>   > In other words, I'm available to do a re-release.
>
> Sorry, I didn't mean to suggest that it shouldn't be you; I just figured
> you'd done so much more than your duty on Thursday (and Friday) you
> might not want to face it again!
>
> If you're willing, it would be an even better test of TCW22 to have you
> go through the revised version and see if we've made all the necessary
> changes.

No, not me this time.  I don't have shell access on www.tei-c.org yet 
(haven't needed it), and I am overcommitted right now (hence all the 
tickets I still haven't implemented after Oxford).

From lou.burnard at retired.ox.ac.uk  Sat Oct 27 12:26:46 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Sat, 27 Oct 2012 17:26:46 +0100
Subject: [tei-council] 2.2.0  / 2.1.0
In-Reply-To: <736818A2-DD37-4F8F-9360-AD877A6602EC@it.ox.ac.uk>
References: <327C29A7-72D0-448D-BF7A-1708C2C239F5@it.ox.ac.uk>
	<508B7A7C.4040608@uvic.ca> <508B80A8.5080800@uvic.ca>
	<736818A2-DD37-4F8F-9360-AD877A6602EC@it.ox.ac.uk>
Message-ID: <508C0B46.7040002@retired.ox.ac.uk>

On 27/10/12 13:28, Sebastian Rahtz wrote:
> There is an issue which has emerged as a result of the build working properly.
> Look at http://bits.nsms.ox.ac.uk:8080/jenkins/job/TEIP5/741/parsed_console/?
> and you'll see an issue over something in tei_speech. I don't want to look at and fix
> this now, for several reasons
>
>   - i am going to the pictures to see James Bond shortly
>   - that sort of error is horrible to track down
>   - the fix might mean  a 2.3.0 release
>   - i have to concentrate on other stuff
>
> but if someone else feels strong....

I notice that att.duration is declared in module tei as a subclass of 
both att.duration.iso and att.duration .w3c.
The former is declared in module namesdates, and the latter in spoken. I 
suspect this may be not unconnected with the problem..

From sebastian.rahtz at it.ox.ac.uk  Sat Oct 27 12:42:58 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Sat, 27 Oct 2012 16:42:58 +0000
Subject: [tei-council] 2.2.0  / 2.1.0
In-Reply-To: <508C0B46.7040002@retired.ox.ac.uk>
References: <327C29A7-72D0-448D-BF7A-1708C2C239F5@it.ox.ac.uk>
	<508B7A7C.4040608@uvic.ca> <508B80A8.5080800@uvic.ca>
	<736818A2-DD37-4F8F-9360-AD877A6602EC@it.ox.ac.uk>
	<508C0B46.7040002@retired.ox.ac.uk>
Message-ID: <eed50c2b-c2dd-4c3e-a8a5-fdafdaf7f528@HUB06.ad.oak.ox.ac.uk>


On 27 Oct 2012, at 17:26, Lou Burnard <lou.burnard at retired.ox.ac.uk>
 wrote:

> 
> I notice that att.duration is declared in module tei as a subclass of 
> both att.duration.iso and att.duration .w3c.
> The former is declared in module namesdates, and the latter in spoken. I 
> suspect this may be not unconnected with the problem..

That'll be the issue, yes.  I bet its been there for quite a few years, and lord
knows why its never come up before.

James Bond "Skyfall" film is excellent, by the way.

--
Sebastian Rahtz      
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431


From lou.burnard at retired.ox.ac.uk  Sat Oct 27 12:45:59 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Sat, 27 Oct 2012 17:45:59 +0100
Subject: [tei-council] 2.2.0  / 2.1.0
In-Reply-To: <A39BDF0A-D51E-422E-AA8C-FEB31CB931D8@it.ox.ac.uk>
References: <327C29A7-72D0-448D-BF7A-1708C2C239F5@it.ox.ac.uk>
	<508B7A7C.4040608@uvic.ca> <508B80A8.5080800@uvic.ca>
	<736818A2-DD37-4F8F-9360-AD877A6602EC@it.ox.ac.uk>
	<508C0B46.7040002@retired.ox.ac.uk>
	<A39BDF0A-D51E-422E-AA8C-FEB31CB931D8@it.ox.ac.uk>
Message-ID: <508C0FC7.9070206@retired.ox.ac.uk>

On 27/10/12 17:42, Sebastian Rahtz wrote:
> On 27 Oct 2012, at 17:26, Lou Burnard <lou.burnard at retired.ox.ac.uk>
>   wrote:
>
>> I notice that att.duration is declared in module tei as a subclass of
>> both att.duration.iso and att.duration .w3c.
>> The former is declared in module namesdates, and the latter in spoken. I
>> suspect this may be not unconnected with the problem..
> That'll be the issue, yes.  I bet its been there for quite a few years, and lord
> knows why its never come up before.

It just means that the attribute @dur-iso doesn't get declared -- 
clearly no-one has ever used it, oh what a surprise.

Anyway, I have a fix here -- shall I check it in or not?



From sebastian.rahtz at it.ox.ac.uk  Sat Oct 27 12:54:57 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Sat, 27 Oct 2012 16:54:57 +0000
Subject: [tei-council] 2.2.0  / 2.1.0
In-Reply-To: <508C0FC7.9070206@retired.ox.ac.uk>
References: <327C29A7-72D0-448D-BF7A-1708C2C239F5@it.ox.ac.uk>
	<508B7A7C.4040608@uvic.ca> <508B80A8.5080800@uvic.ca>
	<736818A2-DD37-4F8F-9360-AD877A6602EC@it.ox.ac.uk>
	<508C0B46.7040002@retired.ox.ac.uk>
	<A39BDF0A-D51E-422E-AA8C-FEB31CB931D8@it.ox.ac.uk>
	<508C0FC7.9070206@retired.ox.ac.uk>
Message-ID: <9701ba05-d0bb-4d4b-9ca3-4840d1f7b90c@HUB02.ad.oak.ox.ac.uk>


On 27 Oct 2012, at 17:45, Lou Burnard <lou.burnard at retired.ox.ac.uk>
 wrote:
> 
> It just means that the attribute @dur-iso doesn't get declared -- clearly no-one has ever used it, oh what a surprise.
> 
> Anyway, I have a fix here -- shall I check it in or not?


i'd say so. the 2.2.0 release should now be consistent, so we're
in the next round for release at some undefined future date
--
Sebastian Rahtz      
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431


From mholmes at uvic.ca  Sat Oct 27 13:09:26 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Sat, 27 Oct 2012 10:09:26 -0700
Subject: [tei-council] 2.2.0  / 2.1.0
In-Reply-To: <736818A2-DD37-4F8F-9360-AD877A6602EC@it.ox.ac.uk>
References: <327C29A7-72D0-448D-BF7A-1708C2C239F5@it.ox.ac.uk>
	<508B7A7C.4040608@uvic.ca> <508B80A8.5080800@uvic.ca>
	<736818A2-DD37-4F8F-9360-AD877A6602EC@it.ox.ac.uk>
Message-ID: <508C1546.6070404@uvic.ca>

I think I've spotted something that may be related to this:

att.duration.w3c is in the tei module, but att.duration.iso is in 
namesdates. tei_speech.odd includes both modules, so I'm not sure yet 
how the problem is happening, but can anyone remember which module these 
are supposed to be in? I suspect iso is wrong and should be in tei.

Cheers,
Martin

On 12-10-27 05:28 AM, Sebastian Rahtz wrote:
> I have pressed the Big Red Button, in that I have run the install on www.tei-c.org, remade the Debian packages,
> and remade the oxygen package.  It seems important that the damage is undone as soon as possible,
> and then worry about comms and repairs later.
>
> There is an issue which has emerged as a result of the build working properly.
> Look at http://bits.nsms.ox.ac.uk:8080/jenkins/job/TEIP5/741/parsed_console/?
> and you'll see an issue over something in tei_speech. I don't want to look at and fix
> this now, for several reasons
>
>   - i am going to the pictures to see James Bond shortly
>   - that sort of error is horrible to track down
>   - the fix might mean  a 2.3.0 release
>   - i have to concentrate on other stuff
>
> but if someone else feels strong....
>
> PS the fact that tei_dictionaries.* is still in the distro is something which can be fixed at leisure
> PPS if you are an "ant"-savvy person, look at P5/Test/antruntest.xml which I started working
> on, and see if you can finish it off. if you succeed then lo! you have built a new Roma script.
> --
> Sebastian Rahtz
> Director (Research Support) of Academic IT Services
> University of Oxford IT Services
> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>

-- 
Martin Holmes
mholmes at uvic.ca
UVic Humanities Computing and Media Centre

From lou.burnard at retired.ox.ac.uk  Sat Oct 27 13:12:05 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Sat, 27 Oct 2012 18:12:05 +0100
Subject: [tei-council] 2.2.0  / 2.1.0
In-Reply-To: <508C1546.6070404@uvic.ca>
References: <327C29A7-72D0-448D-BF7A-1708C2C239F5@it.ox.ac.uk>
	<508B7A7C.4040608@uvic.ca> <508B80A8.5080800@uvic.ca>
	<736818A2-DD37-4F8F-9360-AD877A6602EC@it.ox.ac.uk>
	<508C1546.6070404@uvic.ca>
Message-ID: <508C15E5.6010908@retired.ox.ac.uk>

Yes, that is the fix I am just about to check in, as per previous messages

On 27/10/12 18:09, Martin Holmes wrote:
> I think I've spotted something that may be related to this:
>
> att.duration.w3c is in the tei module, but att.duration.iso is in
> namesdates. tei_speech.odd includes both modules, so I'm not sure yet
> how the problem is happening, but can anyone remember which module these
> are supposed to be in? I suspect iso is wrong and should be in tei.
>
> Cheers,
> Martin
>
> On 12-10-27 05:28 AM, Sebastian Rahtz wrote:
>> I have pressed the Big Red Button, in that I have run the install on www.tei-c.org, remade the Debian packages,
>> and remade the oxygen package.  It seems important that the damage is undone as soon as possible,
>> and then worry about comms and repairs later.
>>
>> There is an issue which has emerged as a result of the build working properly.
>> Look at http://bits.nsms.ox.ac.uk:8080/jenkins/job/TEIP5/741/parsed_console/?
>> and you'll see an issue over something in tei_speech. I don't want to look at and fix
>> this now, for several reasons
>>
>>    - i am going to the pictures to see James Bond shortly
>>    - that sort of error is horrible to track down
>>    - the fix might mean  a 2.3.0 release
>>    - i have to concentrate on other stuff
>>
>> but if someone else feels strong....
>>
>> PS the fact that tei_dictionaries.* is still in the distro is something which can be fixed at leisure
>> PPS if you are an "ant"-savvy person, look at P5/Test/antruntest.xml which I started working
>> on, and see if you can finish it off. if you succeed then lo! you have built a new Roma script.
>> --
>> Sebastian Rahtz
>> Director (Research Support) of Academic IT Services
>> University of Oxford IT Services
>> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>>


From mholmes at uvic.ca  Sat Oct 27 14:19:37 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Sat, 27 Oct 2012 11:19:37 -0700
Subject: [tei-council] Jenkins config changes
Message-ID: <508C25B9.4060704@uvic.ca>

I've updated the configs on my Jenkins box to match Sebastian's new ones 
(although I've also slightly tweaked a couple of them in SVN to add 
emailing where it was missing).

I've wiped out the workspaces for the OxGarage, Roma and Stylesheet1 
jobs, so they'll build freshly, but I've purposely left the Stylesheets 
and TEI job workspaces alone, so that we can see when they build whether 
the problem with the old version and date has cleared. I think Sebastian 
wiped his workspaces, forcing the job to build everything afresh, which 
was needed to get clean files for deployment, but my server is still 
unclean; that means if it builds good output, the problem shouldn't 
recur next time we change the version number, but if it doesn't, then it 
will, if you see what I mean.

I kicked off a Stylesheets build but it instantly failed. Investigating now.

Cheers,
Martin

From sebastian.rahtz at it.ox.ac.uk  Sat Oct 27 14:22:43 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Sat, 27 Oct 2012 18:22:43 +0000
Subject: [tei-council] Jenkins config changes
In-Reply-To: <508C25B9.4060704@uvic.ca>
References: <508C25B9.4060704@uvic.ca>
Message-ID: <F4832A1C-5EAB-4213-A877-7B6F8EC98B71@it.ox.ac.uk>


On 27 Oct 2012, at 19:19, Martin Holmes <mholmes at uvic.ca>
 wrote:

> the problem with the old version and date has cleared. I think Sebastian 
> wiped his workspaces, forcing the job to build everything afresh, which 
> was needed to get clean files for deployment, but my server is still 
> unclean; that means if it builds good output, the problem shouldn't 
> recur next time we change the version number, but if it doesn't, then it 
> will, if you see what I mean.



the cleanliness should be achieved by each task in Jenkins now starting
with a "make clean"
--
Sebastian Rahtz      
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431


From mholmes at uvic.ca  Sat Oct 27 14:27:06 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Sat, 27 Oct 2012 11:27:06 -0700
Subject: [tei-council] Jenkins config changes
In-Reply-To: <F4832A1C-5EAB-4213-A877-7B6F8EC98B71@it.ox.ac.uk>
References: <508C25B9.4060704@uvic.ca>
	<F4832A1C-5EAB-4213-A877-7B6F8EC98B71@it.ox.ac.uk>
Message-ID: <508C277A.9070109@uvic.ca>

Stylesheets seems to have failed because it's using old artifacts from 
prior to the 2.2.0 release (I see a mismatch between a line of text I 
changed in a typo fix after release time).

I'm going to kick off P5-Test instead, and see if that goes OK. If the 
P5s work, I'll wipe the Stylesheets workspace and start that one again. 
Then they'll all go through one more time.

I have a thought: we should make the occasional version change purely 
for internal testing, between releases. If we once in a while did e.g. 
2.2.1, 2.2.2 etc., but just for Jinks and not for release, we'd be able 
to inspect the results at our leisure, and know if the real release 
process would be likely to experience problems.

We could have a numbering convention to indicate a "not for release" 
version.

Cheers,
Martin

On 12-10-27 11:22 AM, Sebastian Rahtz wrote:
>
> On 27 Oct 2012, at 19:19, Martin Holmes <mholmes at uvic.ca>
>   wrote:
>
>> the problem with the old version and date has cleared. I think Sebastian
>> wiped his workspaces, forcing the job to build everything afresh, which
>> was needed to get clean files for deployment, but my server is still
>> unclean; that means if it builds good output, the problem shouldn't
>> recur next time we change the version number, but if it doesn't, then it
>> will, if you see what I mean.
>
>
>
> the cleanliness should be achieved by each task in Jenkins now starting
> with a "make clean"
> --
> Sebastian Rahtz
> Director (Research Support) of Academic IT Services
> University of Oxford IT Services
> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>

From bansp at o2.pl  Sat Oct 27 14:28:28 2012
From: bansp at o2.pl (Piotr Banski)
Date: Sat, 27 Oct 2012 20:28:28 +0200
Subject: [tei-council] 2.2.0  / 2.1.0
In-Reply-To: <508B80A8.5080800@uvic.ca>
References: <327C29A7-72D0-448D-BF7A-1708C2C239F5@it.ox.ac.uk>
	<508B7A7C.4040608@uvic.ca> <508B80A8.5080800@uvic.ca>
Message-ID: <508C27CC.5070105@o2.pl>

Hi Martin,

It's OK, I didn't interpret your words like that.

I was just thinking in terms of finishing what I have started. So let's 
say that, should the re-release happen tomorrow late evening, or on 
Mon-Tue, I'll be happy to handle that. Later than that, it should rather 
be someone else, unless you're willing to wait until (hmm) Friday, 
European early afternoon / US morning.

I have e-mailed Shayne again, asking to hold off the account hibernation.

So long,

   Piotr


On 27/10/12 08:35, Martin Holmes wrote:
> On 12-10-26 11:09 PM, Martin Holmes wrote:
>
>> Then I think we should do 2.2.1 within a few days. Kevin might try being
>> release tech, if he's got time, and if not, I'm happy to do it. I
>> wouldn't mind going through TCW22 again one more time while the recent
>> experience is fresh in my mind.
>
> On 12-10-26 05:27 PM, Piotr Banski wrote:
>   > In other words, I'm available to do a re-release.
>
> Sorry, I didn't mean to suggest that it shouldn't be you; I just figured
> you'd done so much more than your duty on Thursday (and Friday) you
> might not want to face it again!
>
> If you're willing, it would be an even better test of TCW22 to have you
> go through the revised version and see if we've made all the necessary
> changes.
>
> Cheers,
> Martin
>


From mholmes at uvic.ca  Sat Oct 27 17:31:16 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Sat, 27 Oct 2012 14:31:16 -0700
Subject: [tei-council] Jenkins config changes
In-Reply-To: <508C277A.9070109@uvic.ca>
References: <508C25B9.4060704@uvic.ca>
	<F4832A1C-5EAB-4213-A877-7B6F8EC98B71@it.ox.ac.uk>
	<508C277A.9070109@uvic.ca>
Message-ID: <508C52A4.3020302@uvic.ca>

P5 builds on the UVic Jinks are now showing the correct date and version 
information, so I think we're good.

P5-Test is still broken, though. I think it's something to do with ant 
not being able to find xerces when it's doing the HTML validation. 
Perhaps we need to add xerces to the <classpath> of the <taskdef> in 
validatehtml.xml?

Cheers,
Martin

On 12-10-27 11:27 AM, Martin Holmes wrote:
> Stylesheets seems to have failed because it's using old artifacts from
> prior to the 2.2.0 release (I see a mismatch between a line of text I
> changed in a typo fix after release time).
>
> I'm going to kick off P5-Test instead, and see if that goes OK. If the
> P5s work, I'll wipe the Stylesheets workspace and start that one again.
> Then they'll all go through one more time.
>
> I have a thought: we should make the occasional version change purely
> for internal testing, between releases. If we once in a while did e.g.
> 2.2.1, 2.2.2 etc., but just for Jinks and not for release, we'd be able
> to inspect the results at our leisure, and know if the real release
> process would be likely to experience problems.
>
> We could have a numbering convention to indicate a "not for release"
> version.
>
> Cheers,
> Martin
>
> On 12-10-27 11:22 AM, Sebastian Rahtz wrote:
>>
>> On 27 Oct 2012, at 19:19, Martin Holmes <mholmes at uvic.ca>
>>    wrote:
>>
>>> the problem with the old version and date has cleared. I think Sebastian
>>> wiped his workspaces, forcing the job to build everything afresh, which
>>> was needed to get clean files for deployment, but my server is still
>>> unclean; that means if it builds good output, the problem shouldn't
>>> recur next time we change the version number, but if it doesn't, then it
>>> will, if you see what I mean.
>>
>>
>>
>> the cleanliness should be achieved by each task in Jenkins now starting
>> with a "make clean"
>> --
>> Sebastian Rahtz
>> Director (Research Support) of Academic IT Services
>> University of Oxford IT Services
>> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>>

From sebastian.rahtz at it.ox.ac.uk  Sat Oct 27 17:32:19 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Sat, 27 Oct 2012 21:32:19 +0000
Subject: [tei-council] Jenkins config changes
In-Reply-To: <508C52A4.3020302@uvic.ca>
References: <508C25B9.4060704@uvic.ca>
	<F4832A1C-5EAB-4213-A877-7B6F8EC98B71@it.ox.ac.uk>
	<508C277A.9070109@uvic.ca> <508C52A4.3020302@uvic.ca>
Message-ID: <B4B025B4-6BDE-4765-824E-E99C495A6105@it.ox.ac.uk>


On 27 Oct 2012, at 22:31, Martin Holmes <mholmes at uvic.ca>
 wrote:

> P5 builds on the UVic Jinks are now showing the correct date and version 
> information, so I think we're good.
> 
> P5-Test is still broken, though. I think it's something to do with ant 
> not being able to find xerces when it's doing the HTML validation. 
> Perhaps we need to add xerces to the <classpath> of the <taskdef> in 
> validatehtml.xml?
> 

odd, that works here.

i am confused by that stuff....

--
Sebastian Rahtz      
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431


From lou.burnard at retired.ox.ac.uk  Sun Oct 28 06:06:52 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Sun, 28 Oct 2012 10:06:52 +0000
Subject: [tei-council] maybe a consideration for next utilities release?
Message-ID: <508D03BC.9050500@retired.ox.ac.uk>

I realise this is a minority interest, but still and all, I thought I 
might mention that to use the local installed version of p5subset.xml 
rather than sit and wait for the network with the following utilities I 
have to ...

a) odd2nuodd : add parameter P5=/usr/local/whatever

b) roma : add command line option --localsource=/usr/local/whatever

c) oddbyexample : add parameter tei=/usr/local/whatever

would a bit of consistency be too much to ask?



From sebastian.rahtz at it.ox.ac.uk  Sun Oct 28 06:41:34 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Sun, 28 Oct 2012 10:41:34 +0000
Subject: [tei-council] maybe a consideration for next utilities release?
In-Reply-To: <508D03BC.9050500@retired.ox.ac.uk>
References: <508D03BC.9050500@retired.ox.ac.uk>
Message-ID: <c7a829af-1aed-42d4-b3f5-d8e9487c7ead@HUB02.ad.oak.ox.ac.uk>


On 28 Oct 2012, at 10:06, Lou Burnard <lou.burnard at retired.ox.ac.uk> wrote:

> I realise this is a minority interest, but still and all, I thought I 
> might mention that to use the local installed version of p5subset.xml 
> rather than sit and wait for the network with the following utilities I 
> have to ...
> 
> a) odd2nuodd : add parameter P5=/usr/local/whatever
> 
> b) roma : add command line option --localsource=/usr/local/whatever
> 
> c) oddbyexample : add parameter tei=/usr/local/whatever
> 
> would a bit of consistency be too much to ask?


now all of them use the parameter called "defaultSource". Roma's
--localsource I can't so easily change.

can I remind everyone with a copy of emacs that these bits of XSL
are not my private fiefdom and that all of you can fix them too? :-}
--
Sebastian Rahtz      
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431


From lou.burnard at retired.ox.ac.uk  Sun Oct 28 06:46:52 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Sun, 28 Oct 2012 10:46:52 +0000
Subject: [tei-council] maybe a consideration for next utilities release?
In-Reply-To: <776704FA-A3BD-4EA7-890B-D4295B875CE9@it.ox.ac.uk>
References: <508D03BC.9050500@retired.ox.ac.uk>
	<776704FA-A3BD-4EA7-890B-D4295B875CE9@it.ox.ac.uk>
Message-ID: <508D0D1C.2080309@retired.ox.ac.uk>

On 28/10/12 10:41, Sebastian Rahtz wrote:
> On 28 Oct 2012, at 10:06, Lou Burnard <lou.burnard at retired.ox.ac.uk> wrote:
>
>> I realise this is a minority interest, but still and all, I thought I
>> might mention that to use the local installed version of p5subset.xml
>> rather than sit and wait for the network with the following utilities I
>> have to ...
>>
>> a) odd2nuodd : add parameter P5=/usr/local/whatever
>>
>> b) roma : add command line option --localsource=/usr/local/whatever
>>
>> c) oddbyexample : add parameter tei=/usr/local/whatever
>>
>> would a bit of consistency be too much to ask?
>
> now all of them use the parameter called "defaultSource". Roma's
> --localsource I can't so easily change.
>
> can I remind everyone with a copy of emacs that these bits of XSL
> are not my private fiefdom and that all of you can fix them too? :-}
> --
> S

Well I hesitate to blunder in and mess with them without your permission 
-- but if I did, I'd probably make them all say "localsource" rather 
than "defaultsource"

If you say "defaultsource" that implies there's some other kind of 
source one might specify to override it, which sfaik there isn't



From sebastian.rahtz at it.ox.ac.uk  Sun Oct 28 06:55:39 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Sun, 28 Oct 2012 10:55:39 +0000
Subject: [tei-council] maybe a consideration for next utilities release?
In-Reply-To: <508D0D1C.2080309@retired.ox.ac.uk>
References: <508D03BC.9050500@retired.ox.ac.uk>
	<776704FA-A3BD-4EA7-890B-D4295B875CE9@it.ox.ac.uk>
	<508D0D1C.2080309@retired.ox.ac.uk>
Message-ID: <077afa1f-0142-41db-90b1-7aea766d8088@HUB01.ad.oak.ox.ac.uk>


On 28 Oct 2012, at 10:46, Lou Burnard <lou.burnard at retired.ox.ac.uk>
 wrote:
> 
> Well I hesitate to blunder in and mess with them without your permission

you dont need my permission! trust the VCS, Luke.


> -- but if I did, I'd probably make them all say "localsource" rather than "defaultsource"
> 
> If you say "defaultsource" that implies there's some other kind of source one might specify to override it, which sfaik there isn't
> 

ah, but  there is.   Your ODD file may specify its own @source on some element. so the thing we provide
is indeed the _default_ source for when the ODD is agnostic.
--
Sebastian Rahtz      
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431


From lou.burnard at retired.ox.ac.uk  Sun Oct 28 06:58:23 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Sun, 28 Oct 2012 10:58:23 +0000
Subject: [tei-council] maybe a consideration for next utilities release?
In-Reply-To: <D616CE0E-99DD-4E2E-8148-6F8F049D7BA2@it.ox.ac.uk>
References: <508D03BC.9050500@retired.ox.ac.uk>
	<776704FA-A3BD-4EA7-890B-D4295B875CE9@it.ox.ac.uk>
	<508D0D1C.2080309@retired.ox.ac.uk>
	<D616CE0E-99DD-4E2E-8148-6F8F049D7BA2@it.ox.ac.uk>
Message-ID: <508D0FCF.20003@retired.ox.ac.uk>

On 28/10/12 10:55, Sebastian Rahtz wrote:
> On 28 Oct 2012, at 10:46, Lou Burnard <lou.burnard at retired.ox.ac.uk>
>   wrote:
>> Well I hesitate to blunder in and mess with them without your permission
> you dont need my permission! trust the VCS, Luke.

s/permission/wisdom/

>> -- but if I did, I'd probably make them all say "localsource" rather than "defaultsource"
>>
>> If you say "defaultsource" that implies there's some other kind of source one might specify to override it, which sfaik there isn't
>>
> ah, but  there is.   Your ODD file may specify its own @source on some element. so the thing we provide
> is indeed the _default_ source for when the ODD is agnostic.

ah, ok. though surely that cannot be true in the case of oddbyexample, 
where you are *generating* an ODD




From sebastian.rahtz at it.ox.ac.uk  Sun Oct 28 07:02:00 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Sun, 28 Oct 2012 11:02:00 +0000
Subject: [tei-council] maybe a consideration for next utilities release?
In-Reply-To: <508D0FCF.20003@retired.ox.ac.uk>
References: <508D03BC.9050500@retired.ox.ac.uk>
	<776704FA-A3BD-4EA7-890B-D4295B875CE9@it.ox.ac.uk>
	<508D0D1C.2080309@retired.ox.ac.uk>
	<D616CE0E-99DD-4E2E-8148-6F8F049D7BA2@it.ox.ac.uk>
	<508D0FCF.20003@retired.ox.ac.uk>
Message-ID: <640c641e-0496-454d-8454-aa79830425cf@HUB06.ad.oak.ox.ac.uk>


On 28 Oct 2012, at 10:58, Lou Burnard <lou.burnard at retired.ox.ac.uk>
 wrote:

>> ah, but  there is.   Your ODD file may specify its own @source on some element. so the thing we provide
>> is indeed the _default_ source for when the ODD is agnostic.
> 
> ah, ok. though surely that cannot be true in the case of oddbyexample, where you are *generating* an ODD
> 

very true. I blame whoever asked for it to be consistent.....

--
Sebastian Rahtz      
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431


From James.Cummings at it.ox.ac.uk  Sun Oct 28 14:55:15 2012
From: James.Cummings at it.ox.ac.uk (James Cummings)
Date: Sun, 28 Oct 2012 18:55:15 +0000
Subject: [tei-council] Jenkins config changes
In-Reply-To: <508C277A.9070109@uvic.ca>
References: <508C25B9.4060704@uvic.ca>
	<F4832A1C-5EAB-4213-A877-7B6F8EC98B71@it.ox.ac.uk>
	<508C277A.9070109@uvic.ca>
Message-ID: <508D7F93.7020002@it.ox.ac.uk>

On 27/10/12 19:27, Martin Holmes wrote:
> I have a thought: we should make the occasional version change purely
> for internal testing, between releases. If we once in a while did e.g.
> 2.2.1, 2.2.2 etc., but just for Jinks and not for release, we'd be able
> to inspect the results at our leisure, and know if the real release
> process would be likely to experience problems.

This is an interesting idea, what do others think? Though surely 
the point of Jenkins is it is built for release continually?

Some projects use odd numbering for 'testing' or 'release 
candidate' releases and even for actual releases.  I.e. we could 
do 2.2.1 as a candidate and then even with no significant changes 
do 2.2.2 as the stable version of it.  Just thinking out loud.

-James

-- 
Dr James Cummings, James.Cummings at it.ox.ac.uk
Research Support, IT Services, University of Oxford

From bansp at o2.pl  Sun Oct 28 15:40:30 2012
From: bansp at o2.pl (Piotr Banski)
Date: Sun, 28 Oct 2012 20:40:30 +0100
Subject: [tei-council] Jenkins config changes
In-Reply-To: <508D7F93.7020002@it.ox.ac.uk>
References: <508C25B9.4060704@uvic.ca>
	<F4832A1C-5EAB-4213-A877-7B6F8EC98B71@it.ox.ac.uk>
	<508C277A.9070109@uvic.ca> <508D7F93.7020002@it.ox.ac.uk>
Message-ID: <508D8A2E.90306@o2.pl>

On 28/10/12 19:55, James Cummings wrote:
[...]
> Some projects use odd numbering for 'testing' or 'release
> candidate' releases and even for actual releases.  I.e. we could
> do 2.2.1 as a candidate and then even with no significant changes
> do 2.2.2 as the stable version of it.  Just thinking out loud.

Given the number of post-factum-discovered problems in the recent 
releases, this idea doesn't sound bad. OTOH, these problems are most 
often (?) discovered thanks to the users.

So do you mean that, e.g., 2.2.1 would be released 'silently' (merely 
announced on the homepage and in SF, not on the list), and we would 
count on testers to find some wrinkles?

   P.

From dsewell at virginia.edu  Sun Oct 28 17:06:57 2012
From: dsewell at virginia.edu (David Sewell)
Date: Sun, 28 Oct 2012 17:06:57 -0400 (EDT)
Subject: [tei-council] teilite.dtd standin
In-Reply-To: <508BCBC8.4020000@retired.ox.ac.uk>
References: <508AF479.9070409@retired.ox.ac.uk>
	<508AFC9F.9060202@ultraslavonic.info>
	<415BCCD6-B24E-47FE-AD0F-4D52C2E14F2C@it.ox.ac.uk>
	<508BA151.7020909@retired.ox.ac.uk>
	<B09E0153-F2AA-48E8-9C3E-8F5F02BC8C08@it.ox.ac.uk>
	<508BCBC8.4020000@retired.ox.ac.uk>
Message-ID: <alpine.OSX.2.00.1210281701220.6941@cewagi.local>

If in the end Council decides an Apache redirect is the way to go, let 
me know and I'll ask Shayne to implement it. (With an HTTP 301 
"Permanent redirect" code?)

That's assuming UVA is still standing after Hurricane Sandy gets done 
with us.  :-)

David

(Actually, central Virginia is probably just going to get about 10-15 cm 
of rain and some gusty winds starting mid-day Monday, but I may be semi- 
or fully offline for a while if I'm stuck at home and the power goes 
out.)

On Sat, 27 Oct 2012, Lou Burnard wrote:

> I had a vague memory that we considered but decided against doing a
> redirection though I can't remember why. But if it's possible, I agree
> this would be preferable.
>
>
>
> On 27/10/12 12:08, Sebastian Rahtz wrote:
>> On 27 Oct 2012, at 09:54, Lou Burnard <lou.burnard at retired.ox.ac.uk> wrote:
>>
>>> On 26/10/12 22:36, Sebastian Rahtz wrote:
>>>> sorry to be a party pooper, but this is (IMHO) an awful idea.
>>> so what would you propose we do instead?
>>>
>> My preference is for a rewrite teilite.{dtd,rnc,rng) -> tei_lite.{dtd,rnc,rng)
>> because for most people it will just work. My second preference
>> is for no file at all, and trigger a comprehensible 404 error.
>>
>>>>   My
>>>> file containing
>>>>
>>>>   <!DOCTYPE ...." SYSTEM "...tei_lite.dtd">
>>>>
>>>> will now fail catastrophically, saying the DTD is invalid,
>>>> and I will have no idea why.
>>> Possibly you'll think, hmm, maybe I should take a look at that file?
>>>
>> I fear that we come from a generation which thinks like that. I have
>> no confidence many other people conceptualize the world like that.
>>
>> Consider the person with a repository of 1000 files, in P5, with
>> a  DOCTYPE pointing at Lite from the web site.  Possibly
>> these links are auto-generated. The user sees HTML generated on
>> the fly. Suddenly the HTML stops working. The error, when some
>> poor sys person follows up, says that the DTD is invalid. They follow
>> up, and find that the document calling itself teilite.dtd isn't a DTD at all!
>> I call that counter-intuitive. If the error is a 404, they say "oh well, links
>> break on the web, I wonder where its moved to" and go look.
>>
>> You may well reply that this scenario doesnt exist ....
>>>> Making the file non-existent
>>>> would be a much cleaner error.
>>> Is that your proposal? we simply remove the file teilite.dtd wherever we can? I dont mind doing that, but it doesnt help with the fact that lots of people point to copies of it we don't control.
>> thats an issue, always has been, i agree
>>
>>>   If the one we do control explains itself, maybe that's a good thing?
>>>
>> sure, its an argument.
>>
>> would you like it if, when you typed "perl", you got a message
>> saying that the file /usr/bin/perl was not executable, and you found,
>> on examining it, that it was in fact a README saying "gone fishing, use python instead"?
>> of course, you'd prefer it if that /usr/bin/perl _was_ executable, and gave you
>> a human readable message when you ran it. But we cant do that, since DTDs
>> dont do anything.  But having a file which claims (by its suffix and by its location)
>> to be a DTD, but isnt one, seems wrong.
>> --
>> Sebastian Rahtz
>> Director (Research Support) of Academic IT Services
>> University of Oxford IT Services
>> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>>
>
>

-- 
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 mholmes at uvic.ca  Sun Oct 28 17:49:19 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Sun, 28 Oct 2012 14:49:19 -0700
Subject: [tei-council] Jenkins config changes
In-Reply-To: <508D8A2E.90306@o2.pl>
References: <508C25B9.4060704@uvic.ca>
	<F4832A1C-5EAB-4213-A877-7B6F8EC98B71@it.ox.ac.uk>
	<508C277A.9070109@uvic.ca> <508D7F93.7020002@it.ox.ac.uk>
	<508D8A2E.90306@o2.pl>
Message-ID: <508DA85F.50804@uvic.ca>

On 12-10-28 12:40 PM, Piotr Banski wrote:
> On 28/10/12 19:55, James Cummings wrote:
> [...]
>> Some projects use odd numbering for 'testing' or 'release
>> candidate' releases and even for actual releases.  I.e. we could
>> do 2.2.1 as a candidate and then even with no significant changes
>> do 2.2.2 as the stable version of it.  Just thinking out loud.
>
> Given the number of post-factum-discovered problems in the recent
> releases, this idea doesn't sound bad. OTOH, these problems are most
> often (?) discovered thanks to the users.
>
> So do you mean that, e.g., 2.2.1 would be released 'silently' (merely
> announced on the homepage and in SF, not on the list), and we would
> count on testers to find some wrinkles?

It wouldn't necessarily be "released" at all; but if you went to the 
lastSuccessfulArtifact on Jenkins, it would show different version 
information. What we'd be testing, among other things, is the effect of 
actually changing the version information. At the moment, that only 
happens on release day, so if it doesn't work properly, we don't know 
until it's too late.

If we went with odd-for-dev, even-for-release numbering, we'd switch 
soon to 2.3.0, with a new "development" version of a readme, and we'd be 
able to see if the change in versioning percolated through correctly to 
all the products. Then when we switched to 2.4.0 for a real release, 
there should be less chance that something odd happens. We could even do 
a test 2.3.1 the day before the final freeze, to be sure the change to 
2.4.0 will go OK.

Only even-numbered builds would be publicly released and placed in the 
Vault.

Cheers,
Martin

Cheers,
Martin

-- 
Martin Holmes
mholmes at uvic.ca
UVic Humanities Computing and Media Centre

From sebastian.rahtz at it.ox.ac.uk  Sun Oct 28 17:58:18 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Sun, 28 Oct 2012 21:58:18 +0000
Subject: [tei-council] Jenkins config changes
In-Reply-To: <508DA85F.50804@uvic.ca>
References: <508C25B9.4060704@uvic.ca>
	<F4832A1C-5EAB-4213-A877-7B6F8EC98B71@it.ox.ac.uk>
	<508C277A.9070109@uvic.ca> <508D7F93.7020002@it.ox.ac.uk>
	<508D8A2E.90306@o2.pl> <508DA85F.50804@uvic.ca>
Message-ID: <7718C60D-0F4B-4355-B6B5-241C540265B7@it.ox.ac.uk>

I observe that this release's problems were
only spotted thanks to David's eagle-eyes.  We would not have been
saved by an intermediate release in any formal way, as we would have
been blind in the same way.

i think a more important rule is to have a week's freeze before a release,
and an action on everyone to check the lastSuccessfulArtefacts
in Jenkins for oddities. 

it wasn't the 2.1.0 per se which was wrong in the files, but
the wrong content.....
--
Sebastian Rahtz      
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431


From James.Cummings at it.ox.ac.uk  Sun Oct 28 18:34:46 2012
From: James.Cummings at it.ox.ac.uk (James Cummings)
Date: Sun, 28 Oct 2012 22:34:46 +0000
Subject: [tei-council] Jenkins config changes
In-Reply-To: <7718C60D-0F4B-4355-B6B5-241C540265B7@it.ox.ac.uk>
References: <508C25B9.4060704@uvic.ca>
	<F4832A1C-5EAB-4213-A877-7B6F8EC98B71@it.ox.ac.uk>
	<508C277A.9070109@uvic.ca> <508D7F93.7020002@it.ox.ac.uk>
	<508D8A2E.90306@o2.pl> <508DA85F.50804@uvic.ca>
	<7718C60D-0F4B-4355-B6B5-241C540265B7@it.ox.ac.uk>
Message-ID: <508DB306.3080506@it.ox.ac.uk>

On 28/10/12 21:58, Sebastian Rahtz wrote:
> i think a more important rule is to have a week's freeze before a release,
> and an action on everyone to check the lastSuccessfulArtefacts
> in Jenkins for oddities.

I certainly support that.  If no one disagrees, can we just make 
that Council policy?  I.e. all intentional changes done a week 
before the scheduled release date, and then it be proofread by 
cancel before release? (i.e. only mistakes introduced by the 
recent changes or typos changed after that)  Can anyone think of 
a reason why we shouldn't do that (aside from it forcing us to 
stick to our deadlines)?

> it wasn't the 2.1.0 per se which was wrong in the files, but
> the wrong content.....

Is this now fixed? When can we be ready for a maintenance release?

-James

-- 
Dr James Cummings, researchsupport at it.ox.ac.uk
Research Support, IT Services, University of Oxford

From sebastian.rahtz at it.ox.ac.uk  Sun Oct 28 18:38:24 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Sun, 28 Oct 2012 22:38:24 +0000
Subject: [tei-council] ongoing working with Jenkins
Message-ID: <5BC4C13B-0DCB-4618-B560-C7014A5E00E3@it.ox.ac.uk>

It may be helpful to look at http://bits.nsms.ox.ac.uk:8080/jenkins/
and consider how this continuous integration works now.

Look at the times for P5 Test, P5 Documentation, and P5. The idea
is that each change which is committed is first tested for
schema-related problems  (3 min 47 seconds); if no problems
are found there, documentation is built (4 min 57 seconds);
if that is all OK, the main distribution is built _from scratch_. This does do a few
extra things which can fail (building Exemplars) but mainly consists
of clean builds in all the right forms (ie all the languages for web
pages, Debian packages and ones for Sourceforge, making
mechanical schema conversions), and takes an extra hour.

The vast majority of mistakes are therefore caught in the first 3-4
minutes, but to be sure you need to wait just over an hour.

I am not saying this is perfect, or even right yet, but does the idea
seem OK?

it of course does not preclude work to make any particular stage
go faster.
--
Sebastian Rahtz      
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431


From sebastian.rahtz at it.ox.ac.uk  Sun Oct 28 18:43:35 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Sun, 28 Oct 2012 22:43:35 +0000
Subject: [tei-council] Jenkins config changes
In-Reply-To: <508DB306.3080506@it.ox.ac.uk>
References: <508C25B9.4060704@uvic.ca>
	<F4832A1C-5EAB-4213-A877-7B6F8EC98B71@it.ox.ac.uk>
	<508C277A.9070109@uvic.ca> <508D7F93.7020002@it.ox.ac.uk>
	<508D8A2E.90306@o2.pl> <508DA85F.50804@uvic.ca>
	<7718C60D-0F4B-4355-B6B5-241C540265B7@it.ox.ac.uk>
	<508DB306.3080506@it.ox.ac.uk>
Message-ID: <92ae8f9f-33a3-4a47-9bf4-4c74567548f9@HUB03.ad.oak.ox.ac.uk>


On 28 Oct 2012, at 22:34, James Cummings <James.Cummings at it.ox.ac.uk>
 wrote:
> 
> Is this now fixed? When can we be ready for a maintenance release?
> 

So far as I am concerned, the hole below our waterline which David
spotted has been plugged, and the water we shipped has been
pumped out (ie if you get 2.2.0 now from any source, it is
correct).  So yes, you can now plan a 2.2.1 or a 2.3.0 if you
want.  

I personally feel that we don't _need_ to do anything more.
The question is whether to 'fess up in public and
tell people who grabbed the release on Friday to get
a new copy. it was wrong for about 36 hours, I think.

--
Sebastian Rahtz      
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431


From lou.burnard at retired.ox.ac.uk  Mon Oct 29 05:59:48 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Mon, 29 Oct 2012 09:59:48 +0000
Subject: [tei-council] Jenkins config changes
In-Reply-To: <92ae8f9f-33a3-4a47-9bf4-4c74567548f9@HUB03.ad.oak.ox.ac.uk>
References: <508C25B9.4060704@uvic.ca>
	<F4832A1C-5EAB-4213-A877-7B6F8EC98B71@it.ox.ac.uk>
	<508C277A.9070109@uvic.ca> <508D7F93.7020002@it.ox.ac.uk>
	<508D8A2E.90306@o2.pl> <508DA85F.50804@uvic.ca>
	<7718C60D-0F4B-4355-B6B5-241C540265B7@it.ox.ac.uk>
	<508DB306.3080506@it.ox.ac.uk>
	<92ae8f9f-33a3-4a47-9bf4-4c74567548f9@HUB03.ad.oak.ox.ac.uk>
Message-ID: <508E5394.5080802@retired.ox.ac.uk>

On 28/10/12 22:43, Sebastian Rahtz wrote:
> On 28 Oct 2012, at 22:34, James Cummings <James.Cummings at it.ox.ac.uk>
>   wrote:
>> Is this now fixed? When can we be ready for a maintenance release?
>>
> So far as I am concerned, the hole below our waterline which David
> spotted has been plugged, and the water we shipped has been
> pumped out (ie if you get 2.2.0 now from any source, it is
> correct).  So yes, you can now plan a 2.2.1 or a 2.3.0 if you
> want.
>
> I personally feel that we don't _need_ to do anything more.
> The question is whether to 'fess up in public and
> tell people who grabbed the release on Friday to get
> a new copy. it was wrong for about 36 hours, I think.
>
>

for the outsider, maybe a brief statement of what sort of shape hole we 
actually suffered might be useful -- if i understand correctly it wasn't 
that serious!



From sebastian.rahtz at it.ox.ac.uk  Mon Oct 29 06:14:32 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Mon, 29 Oct 2012 10:14:32 +0000
Subject: [tei-council] Jenkins config changes
In-Reply-To: <508E5394.5080802@retired.ox.ac.uk>
References: <508C25B9.4060704@uvic.ca>
	<F4832A1C-5EAB-4213-A877-7B6F8EC98B71@it.ox.ac.uk>
	<508C277A.9070109@uvic.ca> <508D7F93.7020002@it.ox.ac.uk>
	<508D8A2E.90306@o2.pl> <508DA85F.50804@uvic.ca>
	<7718C60D-0F4B-4355-B6B5-241C540265B7@it.ox.ac.uk>
	<508DB306.3080506@it.ox.ac.uk>
	<92ae8f9f-33a3-4a47-9bf4-4c74567548f9@HUB03.ad.oak.ox.ac.uk>
	<508E5394.5080802@retired.ox.ac.uk>
Message-ID: <4fe9d1e3-9137-4e3e-932e-d54226ca0725@HUB02.ad.oak.ox.ac.uk>


On 29 Oct 2012, at 09:59, Lou Burnard <lou.burnard at retired.ox.ac.uk>
 wrote:

> 
> for the outsider, maybe a brief statement of what sort of shape hole we 
> actually suffered might be useful -- if i understand correctly it wasn't 
> that serious!
> 


the problem was that the generated artefacts in Exemplars were being kept from
build to build, and not updated when the source changed. A simple, but
catastrophic, lack of dependency info.

It was plugged by saying the the final build also wipes the slate clean
when it starts.
--
Sebastian Rahtz      
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431


From James.Cummings at it.ox.ac.uk  Mon Oct 29 06:22:29 2012
From: James.Cummings at it.ox.ac.uk (James Cummings)
Date: Mon, 29 Oct 2012 10:22:29 +0000
Subject: [tei-council] DH2013
Message-ID: <508E58E5.1070807@it.ox.ac.uk>


Hi Council,

It has been suggested on the Board that members of council might 
be interested in helping to propose a TEI panel session for DH2013.

a) Do you think this a good idea?
b) What topics do you think it would be important to cover?
c) Are you willing and potentially able to participate?

Many thanks,

-James

-- 
Dr James Cummings, James.Cummings at it.ox.ac.uk
Research Support, IT Services, University of Oxford

From mholmes at uvic.ca  Mon Oct 29 08:34:09 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Mon, 29 Oct 2012 05:34:09 -0700
Subject: [tei-council] DH2013
In-Reply-To: <508E58E5.1070807@it.ox.ac.uk>
References: <508E58E5.1070807@it.ox.ac.uk>
Message-ID: <508E77C1.60509@uvic.ca>

Interested and willing, but we have hardly any time left, do we? The 
deadline is Nov 1.

Cheers,
Martin

On 12-10-29 03:22 AM, James Cummings wrote:
>
> Hi Council,
>
> It has been suggested on the Board that members of council might
> be interested in helping to propose a TEI panel session for DH2013.
>
> a) Do you think this a good idea?
> b) What topics do you think it would be important to cover?
> c) Are you willing and potentially able to participate?
>
> Many thanks,
>
> -James
>

-- 
Martin Holmes
mholmes at uvic.ca
UVic Humanities Computing and Media Centre

From bansp at o2.pl  Mon Oct 29 08:44:43 2012
From: bansp at o2.pl (Piotr Banski)
Date: Mon, 29 Oct 2012 13:44:43 +0100
Subject: [tei-council] DH2013
In-Reply-To: <508E77C1.60509@uvic.ca>
References: <508E58E5.1070807@it.ox.ac.uk> <508E77C1.60509@uvic.ca>
Message-ID: <508E7A3B.4010709@o2.pl>

On 29/10/12 13:34, Martin Holmes wrote:
> Interested and willing, but we have hardly any time left, do we? The
> deadline is Nov 1.

The deadline for panels as well?
And anyway, it's the first deadline, I guess. These people are too smart 
not to extend it...

   P.

From lou.burnard at retired.ox.ac.uk  Mon Oct 29 09:03:10 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Mon, 29 Oct 2012 13:03:10 +0000
Subject: [tei-council] Jenkins config changes
In-Reply-To: <29E15CD8-F2AD-40CE-8738-C368BF14BAAE@it.ox.ac.uk>
References: <508C25B9.4060704@uvic.ca>
	<F4832A1C-5EAB-4213-A877-7B6F8EC98B71@it.ox.ac.uk>
	<508C277A.9070109@uvic.ca> <508D7F93.7020002@it.ox.ac.uk>
	<508D8A2E.90306@o2.pl> <508DA85F.50804@uvic.ca>
	<7718C60D-0F4B-4355-B6B5-241C540265B7@it.ox.ac.uk>
	<508DB306.3080506@it.ox.ac.uk>
	<92ae8f9f-33a3-4a47-9bf4-4c74567548f9@HUB03.ad.oak.ox.ac.uk>
	<508E5394.5080802@retired.ox.ac.uk>
	<29E15CD8-F2AD-40CE-8738-C368BF14BAAE@it.ox.ac.uk>
Message-ID: <508E7E8E.9000902@retired.ox.ac.uk>

On 29/10/12 10:14, Sebastian Rahtz wrote:
> the problem was that the generated artefacts in Exemplars were being 
> kept from build to build, and not updated when the source changed. A 
> simple, but catastrophic, lack of dependency info. It was plugged by 
> saying the the final build also wipes the slate clean when it starts. 
> -- Sebastian Rahtz Director (Research Support) of Academic IT Services 
> University of Oxford IT Services 13 Banbury Road, Oxford OX2 6NN. 
> Phone +44 1865 283431 

Or, if I may suggest, in English:

the example schemas and documentation files in the Exemplars directory 
were not updated to use the latest release of P5.







From James.Cummings at it.ox.ac.uk  Mon Oct 29 09:05:00 2012
From: James.Cummings at it.ox.ac.uk (James Cummings)
Date: Mon, 29 Oct 2012 13:05:00 +0000
Subject: [tei-council] DH2013
In-Reply-To: <508E7A3B.4010709@o2.pl>
References: <508E58E5.1070807@it.ox.ac.uk> <508E77C1.60509@uvic.ca>
	<508E7A3B.4010709@o2.pl>
Message-ID: <508E7EFC.2090101@it.ox.ac.uk>


All of this is true, hence why we'd have to work quickly.

If you are interested and willing, what topics should be covered?

-James

On 29/10/12 12:44, Piotr Banski wrote:
> On 29/10/12 13:34, Martin Holmes wrote:
>> Interested and willing, but we have hardly any time left, do we? The
>> deadline is Nov 1.
>
> The deadline for panels as well?
> And anyway, it's the first deadline, I guess. These people are too smart
> not to extend it...
>
>     P.
>


-- 
Dr James Cummings, James.Cummings at it.ox.ac.uk
Research Support, IT Services, University of Oxford

From bansp at o2.pl  Mon Oct 29 09:13:13 2012
From: bansp at o2.pl (Piotr Banski)
Date: Mon, 29 Oct 2012 14:13:13 +0100
Subject: [tei-council] DH2013
In-Reply-To: <508E7EFC.2090101@it.ox.ac.uk>
References: <508E58E5.1070807@it.ox.ac.uk> <508E77C1.60509@uvic.ca>
	<508E7A3B.4010709@o2.pl> <508E7EFC.2090101@it.ox.ac.uk>
Message-ID: <508E80E9.2010506@o2.pl>

The usual boring topics I could think of bringing in are TEI vs. the 
requirements of applied linguistic markup and data modelling and its 
possible serialization within the TEI. But I understand that this is 
pretty narrow.

   P.



On 29/10/12 14:05, James Cummings wrote:
>
> All of this is true, hence why we'd have to work quickly.
>
> If you are interested and willing, what topics should be covered?
>
> -James
>
> On 29/10/12 12:44, Piotr Banski wrote:
>> On 29/10/12 13:34, Martin Holmes wrote:
>>> Interested and willing, but we have hardly any time left, do we? The
>>> deadline is Nov 1.
>>
>> The deadline for panels as well?
>> And anyway, it's the first deadline, I guess. These people are too smart
>> not to extend it...
>>
>>      P.
>>
>
>


From kevin.s.hawkins at ultraslavonic.info  Mon Oct 29 10:19:35 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Mon, 29 Oct 2012 10:19:35 -0400
Subject: [tei-council] Jenkins config changes
In-Reply-To: <508E7E8E.9000902@retired.ox.ac.uk>
References: <508C25B9.4060704@uvic.ca>	<F4832A1C-5EAB-4213-A877-7B6F8EC98B71@it.ox.ac.uk>	<508C277A.9070109@uvic.ca>
	<508D7F93.7020002@it.ox.ac.uk>	<508D8A2E.90306@o2.pl>
	<508DA85F.50804@uvic.ca>	<7718C60D-0F4B-4355-B6B5-241C540265B7@it.ox.ac.uk>	<508DB306.3080506@it.ox.ac.uk>	<92ae8f9f-33a3-4a47-9bf4-4c74567548f9@HUB03.ad.oak.ox.ac.uk>	<508E5394.5080802@retired.ox.ac.uk>	<29E15CD8-F2AD-40CE-8738-C368BF14BAAE@it.ox.ac.uk>
	<508E7E8E.9000902@retired.ox.ac.uk>
Message-ID: <508E9077.6050408@ultraslavonic.info>

On 10/29/2012 9:03 AM, Lou Burnard wrote:
> On 29/10/12 10:14, Sebastian Rahtz wrote:
>> the problem was that the generated artefacts in Exemplars were being
>> kept from build to build, and not updated when the source changed. A
>> simple, but catastrophic, lack of dependency info. It was plugged by
>> saying the the final build also wipes the slate clean when it starts.
>> -- Sebastian Rahtz Director (Research Support) of Academic IT Services
>> University of Oxford IT Services 13 Banbury Road, Oxford OX2 6NN.
>> Phone +44 1865 283431
>
> Or, if I may suggest, in English:
>
> the example schemas and documentation files in the Exemplars directory
> were not updated to use the latest release of P5.

Thanks for the translation, Lou.

We need announce this in public.  We know from the question on TEI-L 
about updating <oXygen/> that at least one person grabbed the latest 
release, so we shouldn't lead them astray but not telling them that what 
they have doesn't match what is now available under www.tei-c.org/release/.

From sebastian.rahtz at it.ox.ac.uk  Mon Oct 29 10:20:21 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Mon, 29 Oct 2012 14:20:21 +0000
Subject: [tei-council] Jenkins config changes
In-Reply-To: <508E7E8E.9000902@retired.ox.ac.uk>
References: <508C25B9.4060704@uvic.ca>
	<F4832A1C-5EAB-4213-A877-7B6F8EC98B71@it.ox.ac.uk>
	<508C277A.9070109@uvic.ca> <508D7F93.7020002@it.ox.ac.uk>
	<508D8A2E.90306@o2.pl> <508DA85F.50804@uvic.ca>
	<7718C60D-0F4B-4355-B6B5-241C540265B7@it.ox.ac.uk>
	<508DB306.3080506@it.ox.ac.uk>
	<92ae8f9f-33a3-4a47-9bf4-4c74567548f9@HUB03.ad.oak.ox.ac.uk>
	<508E5394.5080802@retired.ox.ac.uk>
	<29E15CD8-F2AD-40CE-8738-C368BF14BAAE@it.ox.ac.uk>
	<508E7E8E.9000902@retired.ox.ac.uk>
Message-ID: <f2d8a698-b539-42d8-aacf-960ad978baa1@HUB04.ad.oak.ox.ac.uk>


On 29 Oct 2012, at 13:03, Lou Burnard <lou.burnard at retired.ox.ac.uk>
 wrote:
> 
> the example schemas and documentation files in the Exemplars directory were not updated to use the latest release of P5.
> 

thats the symptom, I described the cause?..

--
Sebastian Rahtz      
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431


From mholmes at uvic.ca  Mon Oct 29 11:58:13 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Mon, 29 Oct 2012 08:58:13 -0700
Subject: [tei-council] Jenkins config changes
In-Reply-To: <508DB306.3080506@it.ox.ac.uk>
References: <508C25B9.4060704@uvic.ca>
	<F4832A1C-5EAB-4213-A877-7B6F8EC98B71@it.ox.ac.uk>
	<508C277A.9070109@uvic.ca> <508D7F93.7020002@it.ox.ac.uk>
	<508D8A2E.90306@o2.pl> <508DA85F.50804@uvic.ca>
	<7718C60D-0F4B-4355-B6B5-241C540265B7@it.ox.ac.uk>
	<508DB306.3080506@it.ox.ac.uk>
Message-ID: <508EA795.9040609@uvic.ca>

On 12-10-28 03:34 PM, James Cummings wrote:
> On 28/10/12 21:58, Sebastian Rahtz wrote:
>> i think a more important rule is to have a week's freeze before a release,
>> and an action on everyone to check the lastSuccessfulArtefacts
>> in Jenkins for oddities.
>
> I certainly support that.  If no one disagrees, can we just make
> that Council policy?  I.e. all intentional changes done a week
> before the scheduled release date, and then it be proofread by
> cancel before release? (i.e. only mistakes introduced by the
> recent changes or typos changed after that)  Can anyone think of
> a reason why we shouldn't do that (aside from it forcing us to
> stick to our deadlines)?

That would definitely be good, but what actually happened on release day 
was that someone reported a crucial bug which couldn't be allowed into 
the release, so Sebastian had to leap in and start changing things. So I 
think what we have to say is:

  - Freeze one week ahead

  - If release-blocking bug is found, release date is moved and the 
one-week freeze starts again once the bug is fixed.

Also, if people DO diligently check stuff during the one-week freeze, 
they will _inevitably_ find things that need fixing. Do we fix such 
things or not? If so, do we restart the freeze for typo-fixes etc.?

Although the particular issue that caused our problem this time 
shouldn't occur again, I still think it's a bit of a wake-up call, and 
even given a week's time for everyone to check the release, we should 
still be looking at some automated checking of the release package 
contents, to make sure all dates and versions are correct, etc. We 
should also be trying to imagine as many possible problems as we can, 
and seeing if we can check for them automatically.

Cheers,
Martin

>> it wasn't the 2.1.0 per se which was wrong in the files, but
>> the wrong content.....
>
> Is this now fixed? When can we be ready for a maintenance release?
>
> -James
>

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From James.Cummings at it.ox.ac.uk  Mon Oct 29 12:20:42 2012
From: James.Cummings at it.ox.ac.uk (James Cummings)
Date: Mon, 29 Oct 2012 16:20:42 +0000
Subject: [tei-council] Jenkins config changes
In-Reply-To: <508EA795.9040609@uvic.ca>
References: <508C25B9.4060704@uvic.ca>
	<F4832A1C-5EAB-4213-A877-7B6F8EC98B71@it.ox.ac.uk>
	<508C277A.9070109@uvic.ca> <508D7F93.7020002@it.ox.ac.uk>
	<508D8A2E.90306@o2.pl> <508DA85F.50804@uvic.ca>
	<7718C60D-0F4B-4355-B6B5-241C540265B7@it.ox.ac.uk>
	<508DB306.3080506@it.ox.ac.uk> <508EA795.9040609@uvic.ca>
Message-ID: <508EACDA.2010100@it.ox.ac.uk>

On 29/10/12 15:58, Martin Holmes wrote:
>> I certainly support that.  If no one disagrees, can we just make
>> that Council policy?  I.e. all intentional changes done a week
>> before the scheduled release date, and then it be proofread by
>> cancel before release? (i.e. only mistakes introduced by the
>> recent changes or typos changed after that)  Can anyone think of
>> a reason why we shouldn't do that (aside from it forcing us to
>> stick to our deadlines)?
>
> That would definitely be good, but what actually happened on release day
> was that someone reported a crucial bug which couldn't be allowed into
> the release, so Sebastian had to leap in and start changing things. So I
> think what we have to say is:
>
>    - Freeze one week ahead

Agreed. (minimum 1 week)

>    - If release-blocking bug is found, release date is moved and the
> one-week freeze starts again once the bug is fixed.

Agreed.

> Also, if people DO diligently check stuff during the one-week freeze,
> they will _inevitably_ find things that need fixing. Do we fix such
> things or not? If so, do we restart the freeze for typo-fixes etc.?

No, I think that the only things that need to re-start the freeze 
are release-blocking bugs.  A release could go out with a typo, 
but since we've noticed it then we might as well correct it.  So 
I'd argue that corrigible bugs are ok, but things which either 
introduce new changes to the schema or change the _intent_ of the 
release are forbidden.  (i.e. I can change a typo, or having 
noticed we've changed the schema without changing the prose, 
update the prose to reflect our intent, but I shouldn't be doing 
a *new* ticket/change)

> Although the particular issue that caused our problem this time
> shouldn't occur again, I still think it's a bit of a wake-up call, and
> even given a week's time for everyone to check the release, we should
> still be looking at some automated checking of the release package
> contents, to make sure all dates and versions are correct, etc. We
> should also be trying to imagine as many possible problems as we can,
> and seeing if we can check for them automatically.

Agreed.

-James
-- 
Dr James Cummings, researchsupport at it.ox.ac.uk
Research Support, IT Services, University of Oxford

From mholmes at uvic.ca  Mon Oct 29 12:26:09 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Mon, 29 Oct 2012 09:26:09 -0700
Subject: [tei-council] UVic Jenkins temporarily down
Message-ID: <508EAE21.6020905@uvic.ca>

We've just brought down the UVic Jenkins server to increase its memory, 
and we're having a little trouble getting it started again (related to a 
VMWare license key). Talking to our sysops about it now. Hopefully we 
should be up and running again soon.

Cheers,
Martin
-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From mholmes at uvic.ca  Mon Oct 29 12:27:45 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Mon, 29 Oct 2012 09:27:45 -0700
Subject: [tei-council] DH2013
In-Reply-To: <508E80E9.2010506@o2.pl>
References: <508E58E5.1070807@it.ox.ac.uk> <508E77C1.60509@uvic.ca>
	<508E7A3B.4010709@o2.pl> <508E7EFC.2090101@it.ox.ac.uk>
	<508E80E9.2010506@o2.pl>
Message-ID: <508EAE81.7090201@uvic.ca>

I think Laurent would be interested in talking about TEI as a 
serialization for Lexical Markup Framework.

To make it broader, we could frame it as "how TEI fits into the 
infrastructure of other XML standards".

Cheers,
Martin

On 12-10-29 06:13 AM, Piotr Banski wrote:
> The usual boring topics I could think of bringing in are TEI vs. the
> requirements of applied linguistic markup and data modelling and its
> possible serialization within the TEI. But I understand that this is
> pretty narrow.
>
>     P.
>
>
>
> On 29/10/12 14:05, James Cummings wrote:
>>
>> All of this is true, hence why we'd have to work quickly.
>>
>> If you are interested and willing, what topics should be covered?
>>
>> -James
>>
>> On 29/10/12 12:44, Piotr Banski wrote:
>>> On 29/10/12 13:34, Martin Holmes wrote:
>>>> Interested and willing, but we have hardly any time left, do we? The
>>>> deadline is Nov 1.
>>>
>>> The deadline for panels as well?
>>> And anyway, it's the first deadline, I guess. These people are too smart
>>> not to extend it...
>>>
>>>       P.
>>>
>>
>>
>

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From gabriel.bodard at kcl.ac.uk  Mon Oct 29 12:40:32 2012
From: gabriel.bodard at kcl.ac.uk (Gabriel Bodard)
Date: Mon, 29 Oct 2012 16:40:32 +0000
Subject: [tei-council] Jenkins config changes
In-Reply-To: <508EA795.9040609@uvic.ca>
References: <508C25B9.4060704@uvic.ca>
	<F4832A1C-5EAB-4213-A877-7B6F8EC98B71@it.ox.ac.uk>
	<508C277A.9070109@uvic.ca> <508D7F93.7020002@it.ox.ac.uk>
	<508D8A2E.90306@o2.pl> <508DA85F.50804@uvic.ca>
	<7718C60D-0F4B-4355-B6B5-241C540265B7@it.ox.ac.uk>
	<508DB306.3080506@it.ox.ac.uk> <508EA795.9040609@uvic.ca>
Message-ID: <508EB180.5030309@kcl.ac.uk>

I think we need to think in terms not only of release blocking bugs vs 
typos etc., but of fixes that are, shall we say, infrastructural (such 
as XSLT or Ant fixes) that would restart the clock on the one-week 
freeze, and the vast majority of content-only bugs that can be fixed any 
time in the one-week period (up to a final 24-hour deep freeze)...

On 2012-10-29 15:58, Martin Holmes wrote:
> On 12-10-28 03:34 PM, James Cummings wrote:
>> On 28/10/12 21:58, Sebastian Rahtz wrote:
>>> i think a more important rule is to have a week's freeze before a release,
>>> and an action on everyone to check the lastSuccessfulArtefacts
>>> in Jenkins for oddities.
>>
>> I certainly support that.  If no one disagrees, can we just make
>> that Council policy?  I.e. all intentional changes done a week
>> before the scheduled release date, and then it be proofread by
>> cancel before release? (i.e. only mistakes introduced by the
>> recent changes or typos changed after that)  Can anyone think of
>> a reason why we shouldn't do that (aside from it forcing us to
>> stick to our deadlines)?
>
> That would definitely be good, but what actually happened on release day
> was that someone reported a crucial bug which couldn't be allowed into
> the release, so Sebastian had to leap in and start changing things. So I
> think what we have to say is:
>
>    - Freeze one week ahead
>
>    - If release-blocking bug is found, release date is moved and the
> one-week freeze starts again once the bug is fixed.
>
> Also, if people DO diligently check stuff during the one-week freeze,
> they will _inevitably_ find things that need fixing. Do we fix such
> things or not? If so, do we restart the freeze for typo-fixes etc.?
>
> Although the particular issue that caused our problem this time
> shouldn't occur again, I still think it's a bit of a wake-up call, and
> even given a week's time for everyone to check the release, we should
> still be looking at some automated checking of the release package
> contents, to make sure all dates and versions are correct, etc. We
> should also be trying to imagine as many possible problems as we can,
> and seeing if we can check for them automatically.
>
> Cheers,
> Martin
>
>>> it wasn't the 2.1.0 per se which was wrong in the files, but
>>> the wrong content.....
>>
>> Is this now fixed? When can we be ready for a maintenance release?
>>
>> -James
>>
>

-- 
Dr Gabriel BODARD
Researcher in Digital Epigraphy

Digital Humanities
King's College London
26-29 Drury Lane
London WC2B 5RL

T: +44 (0)20 7848 1388
F: +44 (0)20 7848 2980
E: gabriel.bodard at kcl.ac.uk

http://www.digitalclassicist.org/
http://www.currentepigraphy.org/


From bansp at o2.pl  Mon Oct 29 12:52:06 2012
From: bansp at o2.pl (Piotr Banski)
Date: Mon, 29 Oct 2012 17:52:06 +0100
Subject: [tei-council] DH2013
In-Reply-To: <508EA800.3000200@o2.pl>
References: <508E58E5.1070807@it.ox.ac.uk> <508E77C1.60509@uvic.ca>
	<508E7A3B.4010709@o2.pl> <508E7EFC.2090101@it.ox.ac.uk>
	<508E80E9.2010506@o2.pl> <508E9890.9090804@uvic.ca>
	<508EA800.3000200@o2.pl>
Message-ID: <508EB436.5020104@o2.pl>

[resending to the list]

On 29/10/12 17:00, Piotr Banski wrote:
> Hi Martin,
>
> That's come to me alone, not sure if you intended that.
>
> I think Laurent definitely should (and will surely want to) be part of
> this. Moreover, Menzo Windhouwer has prepared an actual serialization of
> LMF in the TEI, according to the needs of his project, and that might be
> a great contribution as well.
>
> Best,
>
>    P.
>
>
> On 29/10/12 15:54, Martin Holmes wrote:
>> I think Laurent would be interested in talking about TEI as a
>> serialization for Lexical Markup Framework.
>>
>> To make it broader, we could frame it as "how TEI fits into the
>> infrastructure of other XML standards".
>>
>> Cheers,
>> Martin
>>
>> On 12-10-29 06:13 AM, Piotr Banski wrote:
>>> The usual boring topics I could think of bringing in are TEI vs. the
>>> requirements of applied linguistic markup and data modelling and its
>>> possible serialization within the TEI. But I understand that this is
>>> pretty narrow.
>>>
>>>     P.
>>>
>>>
>>>
>>> On 29/10/12 14:05, James Cummings wrote:
>>>>
>>>> All of this is true, hence why we'd have to work quickly.
>>>>
>>>> If you are interested and willing, what topics should be covered?
>>>>
>>>> -James
>>>>
>>>> On 29/10/12 12:44, Piotr Banski wrote:
>>>>> On 29/10/12 13:34, Martin Holmes wrote:
>>>>>> Interested and willing, but we have hardly any time left, do we? The
>>>>>> deadline is Nov 1.
>>>>>
>>>>> The deadline for panels as well?
>>>>> And anyway, it's the first deadline, I guess. These people are too
>>>>> smart
>>>>> not to extend it...
>>>>>
>>>>>       P.
>>>>>
>>>>
>>>>
>>>
>>
>


From mholmes at uvic.ca  Mon Oct 29 18:38:17 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Mon, 29 Oct 2012 15:38:17 -0700
Subject: [tei-council] Roma oddity
Message-ID: <508F0559.4040900@uvic.ca>

I'm about to raise a bug for this, but before I do, I just want to check 
I'm not misunderstanding something crucial.

If I want to remove the @status attribute from the <change> element, I 
should presumably do this:

     <elementSpec ident="change" module="header" mode="change">
       <attList>
         <attDef ident="status" mode="delete"/>
       </attList>
     </elementSpec>

(That's what the Roma GUI puts in an ODD file if I delete the @status 
attribute from <change>). If I create an ODD file containing that, 
though, and generate a schema, it contains this:

<define name="change">
     <element name="change">
       <a:documentation 
xmlns:a="http://relaxng.org/ns/compatibility/annotations/1.0">documents 
a change or set of changes made during the production
   of a source document, or during the revision of an electronic file. 
[2.5.  2.4.1. ]</a:documentation>
       <ref name="macro.specialPara"/>
       <ref name="att.ascribed.attributes"/>
       <ref name="att.datable.attributes"/>
       <ref name="att.docStatus.attributes"/>
       <ref name="att.global.attributes"/>
       <ref name="att.typed.attributes"/>
       <optional>
         <attribute name="target">
           <a:documentation 
xmlns:a="http://relaxng.org/ns/compatibility/annotations/1.0">points to 
one or more elements that belong to this change.</a:documentation>
           <list>
             <oneOrMore>
               <ref name="data.pointer"/>
             </oneOrMore>
           </list>
         </attribute>
       </optional>
       <empty/>
     </element>
   </define>

@status is define in att.docStatus, and appears in the schema thus:

   <define name="att.docStatus.attributes">
     <ref name="att.docStatus.attribute.status"/>
   </define>
   <define name="att.docStatus.attribute.status">
     <optional>
       <attribute 
xmlns:a="http://relaxng.org/ns/compatibility/annotations/1.0" 
name="status" a:defaultValue="draft">
         <a:documentation>describes the status of a document either 
currently or, when
associated with a dated element, at the time indicated.
Sample values include: 1] approved; 2] candidate; 3] cleared; 4] 
deprecated; 5] draft; 6] embargoed; 7] expired; 8] frozen; 9] galley; 
10] proposed; 11] published; 12] recommendation; 13] submitted; 14] 
unfinished; 15] withdrawn</a:documentation>
         <ref name="data.enumerated"/>
       </attribute>
     </optional>
   </define>

So my attempt to delete @status from <change> appears to have failed. I 
get similar results using my local CLI roma (4.9) and the online version.

Cheers,
Martin

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From mholmes at uvic.ca  Mon Oct 29 19:49:37 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Mon, 29 Oct 2012 16:49:37 -0700
Subject: [tei-council] UVic Jinks still down
Message-ID: <508F1611.6010203@uvic.ca>

We're still working on the problem with our Jenkins VM, but mostly it's 
beyond my control, so as a backup measure we're building a new build box 
on a piece of hardware on my desk, and we'll bring that up as a 
temporary replacement by the end of tomorrow if the problem with VMWare 
can't be solved by then.

It will mean that my Jenkins build script gets put through its paces 
again, which is no bad thing; and the box we're going to use, although 
it has 4GB of RAM, only has an atom processor, so we'll get a very clear 
idea of whether RAM or processor power is the most significant factor in 
build speed.

Cheers,
Martin
-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From sebastian.rahtz at it.ox.ac.uk  Mon Oct 29 19:59:31 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Mon, 29 Oct 2012 23:59:31 +0000
Subject: [tei-council] Roma oddity
In-Reply-To: <508F0559.4040900@uvic.ca>
References: <508F0559.4040900@uvic.ca>
Message-ID: <F7AACBBF-7ED0-431D-8A3D-8A0416D9407E@it.ox.ac.uk>

oh 1000 million chiz chiz, not _another_ error.

--
Sebastian Rahtz      
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431


From sebastian.rahtz at it.ox.ac.uk  Tue Oct 30 05:15:36 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Tue, 30 Oct 2012 09:15:36 +0000
Subject: [tei-council] Roma oddity
In-Reply-To: <F7AACBBF-7ED0-431D-8A3D-8A0416D9407E@it.ox.ac.uk>
References: <508F0559.4040900@uvic.ca>
	<F7AACBBF-7ED0-431D-8A3D-8A0416D9407E@it.ox.ac.uk>
Message-ID: <618D9414-2CFA-4657-BDCF-264CDE312C6C@it.ox.ac.uk>

Now fixed, will be releasing a new version.

I believe this has been wrong since at least June, which doesn't cheer me up much.
--
Sebastian Rahtz      
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431


From lou.burnard at retired.ox.ac.uk  Tue Oct 30 05:52:11 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Tue, 30 Oct 2012 09:52:11 +0000
Subject: [tei-council] TEI Guidelines display
In-Reply-To: <618D9414-2CFA-4657-BDCF-264CDE312C6C@it.ox.ac.uk>
References: <508F0559.4040900@uvic.ca>
	<F7AACBBF-7ED0-431D-8A3D-8A0416D9407E@it.ox.ac.uk>
	<618D9414-2CFA-4657-BDCF-264CDE312C6C@it.ox.ac.uk>
Message-ID: <508FA34B.8000709@retired.ox.ac.uk>

One of the smarter students here in Tours has just pointed out to me 
that although it's marvellous having the element spec descriptions 
displayed in French, it's really confusing to see the explanatory 
expansion of an English tag name given in French. For example, if you 
look up the spec for <lb> in the Guidelines in French you will see

<lb>(saut de ligne) marque le d?but d'un ligne...

This doesnt really explain to the enquiring mind why the tag is "lb" 
(rather than say "sl"_).

It would be better if it said

<lb>(i.e. line break : saut de ligne) marque le d?but d'un ligne...




From James.Cummings at it.ox.ac.uk  Tue Oct 30 06:03:10 2012
From: James.Cummings at it.ox.ac.uk (James Cummings)
Date: Tue, 30 Oct 2012 10:03:10 +0000
Subject: [tei-council] TEI Guidelines display
In-Reply-To: <508FA34B.8000709@retired.ox.ac.uk>
References: <508F0559.4040900@uvic.ca>
	<F7AACBBF-7ED0-431D-8A3D-8A0416D9407E@it.ox.ac.uk>
	<618D9414-2CFA-4657-BDCF-264CDE312C6C@it.ox.ac.uk>
	<508FA34B.8000709@retired.ox.ac.uk>
Message-ID: <508FA5DE.9070607@it.ox.ac.uk>

On 30/10/12 09:52, Lou Burnard wrote:
> One of the smarter students here in Tours has just pointed out to me
> that although it's marvellous having the element spec descriptions
> displayed in French, it's really confusing to see the explanatory
> expansion of an English tag name given in French. For example, if you
> look up the spec for <lb> in the Guidelines in French you will see
>
> <lb>(saut de ligne) marque le d?but d'un ligne...
>
> This doesnt really explain to the enquiring mind why the tag is "lb"
> (rather than say "sl"_).
>
> It would be better if it said
>
> <lb>(i.e. line break : saut de ligne) marque le d?but d'un ligne...

Isn't this making the mistaken assumption that the TEI tag names 
are in English?  Admittedly they are often derived from English 
words, so maybe it would be better.

To play devil's advocate, I might point out that the gloss for 
<secFol> is "(second folio)" when the element name really derives 
from the term Secundo Folio and that is how it is referred to in 
the prose 
http://www.tei-c.org/release/doc/tei-p5-doc/en/html/MS.html#msmisc "The 
secFol element (for ?secundo folio?) is used to record...".  This 
leads to the conclusion that the glosses are translated and so 
'saut de ligne' is correct. Are you suggesting that we should 
always prefix glosses with the English version or the 'native 
language from which the element name was derived' version? i.e. 
should it be:
(secundo folio: second folio)?

I admit that your student has a point and that it is only on a 
theoretical level that I can argue that say, <settlement> is a 
language-independent token and not an element whose name is in 
English.

-James

-- 
Dr James Cummings, researchsupport at it.ox.ac.uk
Research Support, IT Services, University of Oxford

From lou.burnard at retired.ox.ac.uk  Tue Oct 30 06:21:31 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Tue, 30 Oct 2012 10:21:31 +0000
Subject: [tei-council] TEI Guidelines display
In-Reply-To: <508FA5DE.9070607@it.ox.ac.uk>
References: <508F0559.4040900@uvic.ca>
	<F7AACBBF-7ED0-431D-8A3D-8A0416D9407E@it.ox.ac.uk>
	<618D9414-2CFA-4657-BDCF-264CDE312C6C@it.ox.ac.uk>
	<508FA34B.8000709@retired.ox.ac.uk> <508FA5DE.9070607@it.ox.ac.uk>
Message-ID: <508FAA2B.50109@retired.ox.ac.uk>

On 30/10/12 10:03, James Cummings wrote:
> On 30/10/12 09:52, Lou Burnard wrote:
>> One of the smarter students here in Tours has just pointed out to me
>> that although it's marvellous having the element spec descriptions
>> displayed in French, it's really confusing to see the explanatory
>> expansion of an English tag name given in French. For example, if you
>> look up the spec for <lb> in the Guidelines in French you will see
>>
>> <lb>(saut de ligne) marque le d?but d'un ligne...
>>
>> This doesnt really explain to the enquiring mind why the tag is "lb"
>> (rather than say "sl"_).
>>
>> It would be better if it said
>>
>> <lb>(i.e. line break : saut de ligne) marque le d?but d'un ligne...
> Isn't this making the mistaken assumption that the TEI tag names
> are in English?  Admittedly they are often derived from English
> words, so maybe it would be better.

That is the point. You can say "ah they;re not really English words" 
till you're bleu in the face, but the fact is the TEI gis have a 
distinctly anglosaxon ring to them

The student in question just wants a handle to help remember what the 
tag means... and an English expansion works better than a non-English 
one for that purpose.

>
> To play devil's advocate, I might point out that the gloss for
> <secFol> is "(second folio)" when the element name really derives
> from the term Secundo Folio and that is how it is referred to in
> the prose

hard cases make bad law: in this case, I think, the primary gloss should 
probly be "secundo folio" , but either way "deuxieme folio" really 
doesnt help understand why this element has this gi.



> http://www.tei-c.org/release/doc/tei-p5-doc/en/html/MS.html#msmisc "The
> secFol element (for ?secundo folio?) is used to record...".  This
> leads to the conclusion that the glosses are translated and so
> 'saut de ligne' is correct. Are you suggesting that we should
> always prefix glosses with the English version or the 'native
> language from which the element name was derived' version? i.e.
> should it be:
> (secundo folio: second folio)?

the former, if the tag name is (as they all are, except this one) 
derived from english words




From sebastian.rahtz at it.ox.ac.uk  Tue Oct 30 06:42:41 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Tue, 30 Oct 2012 10:42:41 +0000
Subject: [tei-council] TEI Guidelines display
In-Reply-To: <508FA34B.8000709@retired.ox.ac.uk>
References: <508F0559.4040900@uvic.ca>
	<F7AACBBF-7ED0-431D-8A3D-8A0416D9407E@it.ox.ac.uk>
	<618D9414-2CFA-4657-BDCF-264CDE312C6C@it.ox.ac.uk>
	<508FA34B.8000709@retired.ox.ac.uk>
Message-ID: <3ce62562-bc2e-4934-a3ad-0b4ff78df8ec@HUB02.ad.oak.ox.ac.uk>

i am not so sanguine that the <gloss> always expands the abbreviation in that neat way.
I agree, it might improve things in some situations.

why not try it and see?


--
Sebastian Rahtz      
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431


From mholmes at uvic.ca  Tue Oct 30 08:35:25 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Tue, 30 Oct 2012 05:35:25 -0700
Subject: [tei-council] Roma oddity
In-Reply-To: <618D9414-2CFA-4657-BDCF-264CDE312C6C@it.ox.ac.uk>
References: <508F0559.4040900@uvic.ca>
	<F7AACBBF-7ED0-431D-8A3D-8A0416D9407E@it.ox.ac.uk>
	<618D9414-2CFA-4657-BDCF-264CDE312C6C@it.ox.ac.uk>
Message-ID: <508FC98D.9090806@uvic.ca>

I'm not sure how much testing of Roma is already in the system but we 
should probably have an ODD that does at least this:

  - Add a new attribute to an element

  - Add a new attribute to an attribute class

  - Delete an attribute from an element

  - Delete an attribute from an attribute class

  - Provide fixed valList for an attribute

  - Provide suggested valList for an attribute

  - Add a new element

  - Delete an element

  - Add an existing attribute class to an element

  - Create a new attribute class and add it to a couple of elements

  - Anything else???

Then generate a schema and validate a test file against it.

Cheers,
Martin

On 12-10-30 02:15 AM, Sebastian Rahtz wrote:
> Now fixed, will be releasing a new version.
>
> I believe this has been wrong since at least June, which doesn't cheer me up much.
> --
> Sebastian Rahtz
> Director (Research Support) of Academic IT Services
> University of Oxford IT Services
> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>

-- 
Martin Holmes
mholmes at uvic.ca
UVic Humanities Computing and Media Centre

From sebastian.rahtz at it.ox.ac.uk  Tue Oct 30 08:43:15 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Tue, 30 Oct 2012 12:43:15 +0000
Subject: [tei-council] Roma oddity
In-Reply-To: <508FC98D.9090806@uvic.ca>
References: <508F0559.4040900@uvic.ca>
	<F7AACBBF-7ED0-431D-8A3D-8A0416D9407E@it.ox.ac.uk>
	<618D9414-2CFA-4657-BDCF-264CDE312C6C@it.ox.ac.uk>
	<508FC98D.9090806@uvic.ca>
Message-ID: <2672CCE7-15D8-41E3-A80D-2AFEF820EA45@it.ox.ac.uk>


On 30 Oct 2012, at 12:35, Martin Holmes <mholmes at uvic.ca>
 wrote:

> I'm not sure how much testing of Roma is already in the system but we should probably have an ODD that does at least this:
> 
> - Add a new attribute to an element
> 
> - Add a new attribute to an attribute class
> 
> - Delete an attribute from an element
> 
> - Delete an attribute from an attribute class
> 
> - Provide fixed valList for an attribute
> 
> - Provide suggested valList for an attribute
> 
> - Add a new element
> 
> - Delete an element
> 
> - Add an existing attribute class to an element
> 
> - Create a new attribute class and add it to a couple of elements
> 
> - Anything else???
> 

Yes indeed. Not enough testing, as ever.

If you feel strong, Stylesheets/Test/test15.odd is intended to be just this test file,
so it just needs all those things adding. It hardly does anything at present.
Contributions gratefully received.

--
Sebastian Rahtz      
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431


From mholmes at uvic.ca  Tue Oct 30 08:48:00 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Tue, 30 Oct 2012 05:48:00 -0700
Subject: [tei-council] Roma oddity
In-Reply-To: <2672CCE7-15D8-41E3-A80D-2AFEF820EA45@it.ox.ac.uk>
References: <508F0559.4040900@uvic.ca>
	<F7AACBBF-7ED0-431D-8A3D-8A0416D9407E@it.ox.ac.uk>
	<618D9414-2CFA-4657-BDCF-264CDE312C6C@it.ox.ac.uk>
	<508FC98D.9090806@uvic.ca>
	<2672CCE7-15D8-41E3-A80D-2AFEF820EA45@it.ox.ac.uk>
Message-ID: <508FCC80.5030604@uvic.ca>

I'll take that job. I've generated a ticket and assigned it to myself:

http://purl.org/tei/FR/3581901

Cheers,
Martin

On 12-10-30 05:43 AM, Sebastian Rahtz wrote:
>
> On 30 Oct 2012, at 12:35, Martin Holmes <mholmes at uvic.ca>
>   wrote:
>
>> I'm not sure how much testing of Roma is already in the system but we should probably have an ODD that does at least this:
>>
>> - Add a new attribute to an element
>>
>> - Add a new attribute to an attribute class
>>
>> - Delete an attribute from an element
>>
>> - Delete an attribute from an attribute class
>>
>> - Provide fixed valList for an attribute
>>
>> - Provide suggested valList for an attribute
>>
>> - Add a new element
>>
>> - Delete an element
>>
>> - Add an existing attribute class to an element
>>
>> - Create a new attribute class and add it to a couple of elements
>>
>> - Anything else???
>>
>
> Yes indeed. Not enough testing, as ever.
>
> If you feel strong, Stylesheets/Test/test15.odd is intended to be just this test file,
> so it just needs all those things adding. It hardly does anything at present.
> Contributions gratefully received.
>
> --
> Sebastian Rahtz
> Director (Research Support) of Academic IT Services
> University of Oxford IT Services
> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>

-- 
Martin Holmes
mholmes at uvic.ca
UVic Humanities Computing and Media Centre

From rwelzenbach at gmail.com  Tue Oct 30 09:03:24 2012
From: rwelzenbach at gmail.com (Rebecca Welzenbach)
Date: Tue, 30 Oct 2012 09:03:24 -0400
Subject: [tei-council] TEI Guidelines display
In-Reply-To: <3ce62562-bc2e-4934-a3ad-0b4ff78df8ec@HUB02.ad.oak.ox.ac.uk>
References: <508F0559.4040900@uvic.ca>
	<F7AACBBF-7ED0-431D-8A3D-8A0416D9407E@it.ox.ac.uk>
	<618D9414-2CFA-4657-BDCF-264CDE312C6C@it.ox.ac.uk>
	<508FA34B.8000709@retired.ox.ac.uk>
	<3ce62562-bc2e-4934-a3ad-0b4ff78df8ec@HUB02.ad.oak.ox.ac.uk>
Message-ID: <CAA2irtKjyH+1xLoGhpnkpgOQObOG2T8QDdr+Rm0o3PXbeRf1jA@mail.gmail.com>

I agree that offering the expansion of the tag name in the gloss, in
addition to a translation, makes a lot of sense. As others have already
said, even if we want to think of the tag names as language independent
tokens they really are derived from words, almost always English, and
contain meaningful patterns (-grp, -list, -stmt, -decl, etc.) that should
be laid bare. It is reasonable (and seems only fair) to offer the same
expansions in the English and translated versions of the Guidelines.

This reminds me of learning the periodic table of elements in school. I
wish the teachers had explained the roots of Au, Ag, Pb, etc., rather than
just telling us we had to memorize them and making up arbitrary mnemonic
devices. Even if you don't know the language, if there is a
connection/explanation for the tag name that is perfectly simple and
sensible, it's better to offer it than not to.

I also agree that the gloss for <secFol> ought to give the expansion
"secundo folio," not "second folio."


On Tue, Oct 30, 2012 at 6:42 AM, Sebastian Rahtz <
sebastian.rahtz at it.ox.ac.uk> wrote:

> i am not so sanguine that the <gloss> always expands the abbreviation in
> that neat way.
> I agree, it might improve things in some situations.
>
> why not try it and see?
>
>
> --
> Sebastian Rahtz
> Director (Research Support) of Academic IT Services
> University of Oxford IT Services
> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>
> --
> tei-council mailing list
> tei-council at lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>
> PLEASE NOTE: postings to this list are publicly archived
>

From James.Cummings at it.ox.ac.uk  Tue Oct 30 09:28:29 2012
From: James.Cummings at it.ox.ac.uk (James Cummings)
Date: Tue, 30 Oct 2012 13:28:29 +0000
Subject: [tei-council] TEI Guidelines display
In-Reply-To: <CAA2irtKjyH+1xLoGhpnkpgOQObOG2T8QDdr+Rm0o3PXbeRf1jA@mail.gmail.com>
References: <508F0559.4040900@uvic.ca>
	<F7AACBBF-7ED0-431D-8A3D-8A0416D9407E@it.ox.ac.uk>
	<618D9414-2CFA-4657-BDCF-264CDE312C6C@it.ox.ac.uk>
	<508FA34B.8000709@retired.ox.ac.uk>
	<3ce62562-bc2e-4934-a3ad-0b4ff78df8ec@HUB02.ad.oak.ox.ac.uk>
	<CAA2irtKjyH+1xLoGhpnkpgOQObOG2T8QDdr+Rm0o3PXbeRf1jA@mail.gmail.com>
Message-ID: <508FD5FD.7040109@it.ox.ac.uk>


There seems to be a consensus of at least Lou, me, Sebastian and 
Becky.

Lou: I'm running off to a meeting, if you get a chance can you 
put in a ticket and assign it to me?

-James

On 30/10/12 13:03, Rebecca Welzenbach wrote:
> I agree that offering the expansion of the tag name in the gloss, in
> addition to a translation, makes a lot of sense. As others have already
> said, even if we want to think of the tag names as language independent
> tokens they really are derived from words, almost always English, and
> contain meaningful patterns (-grp, -list, -stmt, -decl, etc.) that should
> be laid bare. It is reasonable (and seems only fair) to offer the same
> expansions in the English and translated versions of the Guidelines.
>
> This reminds me of learning the periodic table of elements in school. I
> wish the teachers had explained the roots of Au, Ag, Pb, etc., rather than
> just telling us we had to memorize them and making up arbitrary mnemonic
> devices. Even if you don't know the language, if there is a
> connection/explanation for the tag name that is perfectly simple and
> sensible, it's better to offer it than not to.
>
> I also agree that the gloss for <secFol> ought to give the expansion
> "secundo folio," not "second folio."
>
>
> On Tue, Oct 30, 2012 at 6:42 AM, Sebastian Rahtz <
> sebastian.rahtz at it.ox.ac.uk> wrote:
>
>> i am not so sanguine that the <gloss> always expands the abbreviation in
>> that neat way.
>> I agree, it might improve things in some situations.
>>
>> why not try it and see?
>>
>>
>> --
>> Sebastian Rahtz
>> Director (Research Support) of Academic IT Services
>> University of Oxford IT Services
>> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>>
>> --
>> 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, researchsupport at it.ox.ac.uk
Research Support, IT Services, University of Oxford

From lou.burnard at retired.ox.ac.uk  Tue Oct 30 12:14:05 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Tue, 30 Oct 2012 16:14:05 +0000
Subject: [tei-council] TEI Guidelines display
In-Reply-To: <508FD5FD.7040109@it.ox.ac.uk>
References: <508F0559.4040900@uvic.ca>
	<F7AACBBF-7ED0-431D-8A3D-8A0416D9407E@it.ox.ac.uk>
	<618D9414-2CFA-4657-BDCF-264CDE312C6C@it.ox.ac.uk>
	<508FA34B.8000709@retired.ox.ac.uk>
	<3ce62562-bc2e-4934-a3ad-0b4ff78df8ec@HUB02.ad.oak.ox.ac.uk>
	<CAA2irtKjyH+1xLoGhpnkpgOQObOG2T8QDdr+Rm0o3PXbeRf1jA@mail.gmail.com>
	<508FD5FD.7040109@it.ox.ac.uk>
Message-ID: <508FFCCD.3080605@retired.ox.ac.uk>

Sure. Actually, I was going to Just Do It...

On 30/10/12 13:28, James Cummings wrote:
> There seems to be a consensus of at least Lou, me, Sebastian and
> Becky.
>
> Lou: I'm running off to a meeting, if you get a chance can you
> put in a ticket and assign it to me?
>
> -James
>
> On 30/10/12 13:03, Rebecca Welzenbach wrote:
>> I agree that offering the expansion of the tag name in the gloss, in
>> addition to a translation, makes a lot of sense. As others have already
>> said, even if we want to think of the tag names as language independent
>> tokens they really are derived from words, almost always English, and
>> contain meaningful patterns (-grp, -list, -stmt, -decl, etc.) that should
>> be laid bare. It is reasonable (and seems only fair) to offer the same
>> expansions in the English and translated versions of the Guidelines.
>>
>> This reminds me of learning the periodic table of elements in school. I
>> wish the teachers had explained the roots of Au, Ag, Pb, etc., rather than
>> just telling us we had to memorize them and making up arbitrary mnemonic
>> devices. Even if you don't know the language, if there is a
>> connection/explanation for the tag name that is perfectly simple and
>> sensible, it's better to offer it than not to.
>>
>> I also agree that the gloss for <secFol> ought to give the expansion
>> "secundo folio," not "second folio."
>>
>>
>> On Tue, Oct 30, 2012 at 6:42 AM, Sebastian Rahtz <
>> sebastian.rahtz at it.ox.ac.uk> wrote:
>>
>>> i am not so sanguine that the <gloss> always expands the abbreviation in
>>> that neat way.
>>> I agree, it might improve things in some situations.
>>>
>>> why not try it and see?
>>>
>>>
>>> --
>>> Sebastian Rahtz
>>> Director (Research Support) of Academic IT Services
>>> University of Oxford IT Services
>>> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>>>
>>> --
>>> 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 it.ox.ac.uk  Tue Oct 30 12:22:13 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Tue, 30 Oct 2012 16:22:13 +0000
Subject: [tei-council] TEI Guidelines display
In-Reply-To: <508FFCCD.3080605@retired.ox.ac.uk>
References: <508F0559.4040900@uvic.ca>
	<F7AACBBF-7ED0-431D-8A3D-8A0416D9407E@it.ox.ac.uk>
	<618D9414-2CFA-4657-BDCF-264CDE312C6C@it.ox.ac.uk>
	<508FA34B.8000709@retired.ox.ac.uk>
	<3ce62562-bc2e-4934-a3ad-0b4ff78df8ec@HUB02.ad.oak.ox.ac.uk>
	<CAA2irtKjyH+1xLoGhpnkpgOQObOG2T8QDdr+Rm0o3PXbeRf1jA@mail.gmail.com>
	<508FD5FD.7040109@it.ox.ac.uk> <508FFCCD.3080605@retired.ox.ac.uk>
Message-ID: <b9114a73-59c0-49a8-b921-f6931d452598@HUB05.ad.oak.ox.ac.uk>


On 30 Oct 2012, at 16:14, Lou Burnard <lou.burnard at retired.ox.ac.uk>
 wrote:

> Sure. Actually, I was going to Just Do It?
> 

Stylesheets/common2/odds.xsl, template makeGloss is your friend

enjoy :-}
--
Sebastian Rahtz      
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431


From mholmes at uvic.ca  Tue Oct 30 12:43:07 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Tue, 30 Oct 2012 09:43:07 -0700
Subject: [tei-council] Temporary Jenkins server
Message-ID: <5090039B.8010306@uvic.ca>

Hi all,

Pending resolution of our problem with VMWare, we have a temporary Jinks 
server set up here:

<http://plum.hcmc.uvic.ca:8080/>

This was built with the Jenkins build script I wrote earlier this year, 
which encountered only one hitch with a tei package install, but we 
won't know if it's really worked properly until builds are successfully 
completed. Most things won't build correctly until Stylesheets is built, 
so some builds have failed already.

We hope to have our original build server back up within a day or two, 
but in the meantime, it's no bad thing to go through this process. If it 
turns out that a fresh Jinks created from the script doesn't work 
properly, then that means we don't really know enough about the 
configuration of our Jinks servers, and we need to identify the problems 
and fix them in the build script.

Cheers,
Martin
-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From James.Cummings at it.ox.ac.uk  Tue Oct 30 13:25:07 2012
From: James.Cummings at it.ox.ac.uk (James Cummings)
Date: Tue, 30 Oct 2012 17:25:07 +0000
Subject: [tei-council] TEI Guidelines display
In-Reply-To: <b9114a73-59c0-49a8-b921-f6931d452598@HUB05.ad.oak.ox.ac.uk>
References: <508F0559.4040900@uvic.ca>
	<F7AACBBF-7ED0-431D-8A3D-8A0416D9407E@it.ox.ac.uk>
	<618D9414-2CFA-4657-BDCF-264CDE312C6C@it.ox.ac.uk>
	<508FA34B.8000709@retired.ox.ac.uk>
	<3ce62562-bc2e-4934-a3ad-0b4ff78df8ec@HUB02.ad.oak.ox.ac.uk>
	<CAA2irtKjyH+1xLoGhpnkpgOQObOG2T8QDdr+Rm0o3PXbeRf1jA@mail.gmail.com>
	<508FD5FD.7040109@it.ox.ac.uk> <508FFCCD.3080605@retired.ox.ac.uk>
	<b9114a73-59c0-49a8-b921-f6931d452598@HUB05.ad.oak.ox.ac.uk>
Message-ID: <50900D73.2090303@it.ox.ac.uk>

On 30/10/12 16:22, Sebastian Rahtz wrote:
>
> On 30 Oct 2012, at 16:14, Lou Burnard <lou.burnard at retired.ox.ac.uk>
>   wrote:
>> Sure. Actually, I was going to Just Do It?
> Stylesheets/common2/odds.xsl, template makeGloss is your friend
> enjoy :-}

Ok, I won't get to it tonight, so if you (Lou) just do it, that 
is fine.  (The benefit of the ticket is then it is easier to spot 
as something we've done at next release. ;-) purely accounting. )

-James


-- 
Dr James Cummings, James.Cummings at it.ox.ac.uk
Research Support, IT Services, University of Oxford

From mholmes at uvic.ca  Tue Oct 30 19:01:08 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Tue, 30 Oct 2012 16:01:08 -0700
Subject: [tei-council] Errors/warnings from P5 build
Message-ID: <50905C34.1040005@uvic.ca>

The freshly-minted (if rather feeble) UVic replacement Jenkins server 
reports the following issues after building P5:

BUILD SUCCESSFUL
(2 Warnings in this section)
1 tei_tite.dtd:810: parser warning : PEReference: 
%att.datable.w3c.attribute.period; not found

2 tei_tite.dtd:1341: parser warning : PEReference: 
%att.datable.w3c.attribute.period; not found

I also see them on the Oxford server, so it's something that needs 
looking it. It looks as though it might be related to the duration stuff 
Lou dealt with the other day.

There's also this, twice, although it's something I just need to fix in 
the log parser:

make[2]: [mobi] Error 127 (ignored)

Other than that, it works, which makes me inordinately happy. It did, 
however, take 3 hours and 11 minutes to build P5. So an ARM processor 
really isn't up to the job.

Hoping to get our real Jinks back up tomorrow...

Cheers,
Martin
-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From sebastian.rahtz at it.ox.ac.uk  Tue Oct 30 19:08:29 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Tue, 30 Oct 2012 23:08:29 +0000
Subject: [tei-council] Errors/warnings from P5 build
In-Reply-To: <50905C34.1040005@uvic.ca>
References: <50905C34.1040005@uvic.ca>
Message-ID: <81AE0AC2-7574-4E41-BF3B-36B70C067A79@it.ox.ac.uk>


On 30 Oct 2012, at 23:01, Martin Holmes <mholmes at uvic.ca>
 wrote:

> The freshly-minted (if rather feeble) UVic replacement Jenkins server 
> reports the following issues after building P5:
> 
> BUILD SUCCESSFUL
> (2 Warnings in this section)
> 1 tei_tite.dtd:810: parser warning : PEReference: 
> %att.datable.w3c.attribute.period; not found
> 
> 2 tei_tite.dtd:1341: parser warning : PEReference: 
> %att.datable.w3c.attribute.period; not found
> 
> I also see them on the Oxford server, so it's something that needs 
> looking it. It looks as though it might be related to the duration stuff 
> Lou dealt with the other day.

Yes, I am sure it is. I am hoping Lou can re-examine the problem.

Its very good to know that replicating the build machine
by script _does_ work properly.
--
Sebastian Rahtz      
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431


From lou.burnard at retired.ox.ac.uk  Wed Oct 31 04:09:41 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Wed, 31 Oct 2012 08:09:41 +0000
Subject: [tei-council] Errors/warnings from P5 build
In-Reply-To: <81AE0AC2-7574-4E41-BF3B-36B70C067A79@it.ox.ac.uk>
References: <50905C34.1040005@uvic.ca>
	<81AE0AC2-7574-4E41-BF3B-36B70C067A79@it.ox.ac.uk>
Message-ID: <5090DCC5.10400@retired.ox.ac.uk>

On 30/10/12 23:08, Sebastian Rahtz wrote:
> On 30 Oct 2012, at 23:01, Martin Holmes <mholmes at uvic.ca>
>   wrote:
>
>> The freshly-minted (if rather feeble) UVic replacement Jenkins server
>> reports the following issues after building P5:
>>
>> BUILD SUCCESSFUL
>> (2 Warnings in this section)
>> 1 tei_tite.dtd:810: parser warning : PEReference:
>> %att.datable.w3c.attribute.period; not found
>>
>> 2 tei_tite.dtd:1341: parser warning : PEReference:
>> %att.datable.w3c.attribute.period; not found
>>
>> I also see them on the Oxford server, so it's something that needs
>> looking it. It looks as though it might be related to the duration stuff
>> Lou dealt with the other day.
> Yes, I am sure it is. I am hoping Lou can re-examine the problem.

Nothing to do with me guv. The tei_tite.odd was mistakenly trying to 
delete @period from a class in which it no longer exists.

Fixed now.




From sebastian.rahtz at it.ox.ac.uk  Wed Oct 31 05:16:10 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Wed, 31 Oct 2012 09:16:10 +0000
Subject: [tei-council] Errors/warnings from P5 build
In-Reply-To: <5090DCC5.10400@retired.ox.ac.uk>
References: <50905C34.1040005@uvic.ca>
	<81AE0AC2-7574-4E41-BF3B-36B70C067A79@it.ox.ac.uk>
	<5090DCC5.10400@retired.ox.ac.uk>
Message-ID: <12a3bc9a-92a3-4a09-ba86-fcef26afc4fc@HUB02.ad.oak.ox.ac.uk>

Now that is a perfect example of the implications arising from freezing or not freezing things like
Lite and Tite?.
--
Sebastian Rahtz      
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431


From mholmes at uvic.ca  Wed Oct 31 08:43:14 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Wed, 31 Oct 2012 05:43:14 -0700
Subject: [tei-council] DH2013
In-Reply-To: <508EB436.5020104@o2.pl>
References: <508E58E5.1070807@it.ox.ac.uk> <508E77C1.60509@uvic.ca>
	<508E7A3B.4010709@o2.pl> <508E7EFC.2090101@it.ox.ac.uk>
	<508E80E9.2010506@o2.pl>
	<508E9890.9090804@uvic.ca>	<508EA800.3000200@o2.pl>
	<508EB436.5020104@o2.pl>
Message-ID: <50911CE2.4030004@uvic.ca>

They just extended the deadline but only by 48 hours. I submitted 
yesterday and my last submission was #180. So I reckon by the end of the 
extension, they'll have several hundred submissions already, so they may 
well not extend the deadline beyond this 48-hour one, which is in 
recognition of Hurricane Sandy disruptions.

So if we're doing this, we need to move fast. Any thoughts?

Cheers,
Martin

On 12-10-29 09:52 AM, Piotr Banski wrote:
> [resending to the list]
>
> On 29/10/12 17:00, Piotr Banski wrote:
>> Hi Martin,
>>
>> That's come to me alone, not sure if you intended that.
>>
>> I think Laurent definitely should (and will surely want to) be part of
>> this. Moreover, Menzo Windhouwer has prepared an actual serialization of
>> LMF in the TEI, according to the needs of his project, and that might be
>> a great contribution as well.
>>
>> Best,
>>
>>     P.
>>
>>
>> On 29/10/12 15:54, Martin Holmes wrote:
>>> I think Laurent would be interested in talking about TEI as a
>>> serialization for Lexical Markup Framework.
>>>
>>> To make it broader, we could frame it as "how TEI fits into the
>>> infrastructure of other XML standards".
>>>
>>> Cheers,
>>> Martin
>>>
>>> On 12-10-29 06:13 AM, Piotr Banski wrote:
>>>> The usual boring topics I could think of bringing in are TEI vs. the
>>>> requirements of applied linguistic markup and data modelling and its
>>>> possible serialization within the TEI. But I understand that this is
>>>> pretty narrow.
>>>>
>>>>      P.
>>>>
>>>>
>>>>
>>>> On 29/10/12 14:05, James Cummings wrote:
>>>>>
>>>>> All of this is true, hence why we'd have to work quickly.
>>>>>
>>>>> If you are interested and willing, what topics should be covered?
>>>>>
>>>>> -James
>>>>>
>>>>> On 29/10/12 12:44, Piotr Banski wrote:
>>>>>> On 29/10/12 13:34, Martin Holmes wrote:
>>>>>>> Interested and willing, but we have hardly any time left, do we? The
>>>>>>> deadline is Nov 1.
>>>>>>
>>>>>> The deadline for panels as well?
>>>>>> And anyway, it's the first deadline, I guess. These people are too
>>>>>> smart
>>>>>> not to extend it...
>>>>>>
>>>>>>        P.
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>

-- 
Martin Holmes
mholmes at uvic.ca
UVic Humanities Computing and Media Centre

From James.Cummings at it.ox.ac.uk  Wed Oct 31 08:48:01 2012
From: James.Cummings at it.ox.ac.uk (James Cummings)
Date: Wed, 31 Oct 2012 12:48:01 +0000
Subject: [tei-council] DH2013
In-Reply-To: <50911CE2.4030004@uvic.ca>
References: <508E58E5.1070807@it.ox.ac.uk> <508E77C1.60509@uvic.ca>
	<508E7A3B.4010709@o2.pl> <508E7EFC.2090101@it.ox.ac.uk>
	<508E80E9.2010506@o2.pl>
	<508E9890.9090804@uvic.ca>	<508EA800.3000200@o2.pl>
	<508EB436.5020104@o2.pl> <50911CE2.4030004@uvic.ca>
Message-ID: <50911E01.80406@it.ox.ac.uk>

Hi Council (Arianna CC'ed in)

I think the intention of the session was to have the TEI speaking 
Ex Cathedra.  At DH2008 we did one promoting TEI P5, where 4 or 5 
Board/Council members stood up and talked about what their 
favourite bit of P5 was.  (I talked about the change to URI-based 
pointing, still one of the most significant aspects IMHO.)

Remembering that this won't necessarily be a highly TEI-literate 
audience, how about those who are intending to be at DH2013 and 
are willing to participate email me off-list to let me know. 
We'll then take the discussion and working up a swift abstract 
off-list to save everyone else's inbox. ;-)

-James


On 31/10/12 12:43, Martin Holmes wrote:
> They just extended the deadline but only by 48 hours. I submitted
> yesterday and my last submission was #180. So I reckon by the end of the
> extension, they'll have several hundred submissions already, so they may
> well not extend the deadline beyond this 48-hour one, which is in
> recognition of Hurricane Sandy disruptions.
>
> So if we're doing this, we need to move fast. Any thoughts?
>
> Cheers,
> Martin
>
> On 12-10-29 09:52 AM, Piotr Banski wrote:
>> [resending to the list]
>>
>> On 29/10/12 17:00, Piotr Banski wrote:
>>> Hi Martin,
>>>
>>> That's come to me alone, not sure if you intended that.
>>>
>>> I think Laurent definitely should (and will surely want to) be part of
>>> this. Moreover, Menzo Windhouwer has prepared an actual serialization of
>>> LMF in the TEI, according to the needs of his project, and that might be
>>> a great contribution as well.
>>>
>>> Best,
>>>
>>>      P.
>>>
>>>
>>> On 29/10/12 15:54, Martin Holmes wrote:
>>>> I think Laurent would be interested in talking about TEI as a
>>>> serialization for Lexical Markup Framework.
>>>>
>>>> To make it broader, we could frame it as "how TEI fits into the
>>>> infrastructure of other XML standards".
>>>>
>>>> Cheers,
>>>> Martin
>>>>
>>>> On 12-10-29 06:13 AM, Piotr Banski wrote:
>>>>> The usual boring topics I could think of bringing in are TEI vs. the
>>>>> requirements of applied linguistic markup and data modelling and its
>>>>> possible serialization within the TEI. But I understand that this is
>>>>> pretty narrow.
>>>>>
>>>>>       P.
>>>>>
>>>>>
>>>>>
>>>>> On 29/10/12 14:05, James Cummings wrote:
>>>>>>
>>>>>> All of this is true, hence why we'd have to work quickly.
>>>>>>
>>>>>> If you are interested and willing, what topics should be covered?
>>>>>>
>>>>>> -James
>>>>>>
>>>>>> On 29/10/12 12:44, Piotr Banski wrote:
>>>>>>> On 29/10/12 13:34, Martin Holmes wrote:
>>>>>>>> Interested and willing, but we have hardly any time left, do we? The
>>>>>>>> deadline is Nov 1.
>>>>>>>
>>>>>>> The deadline for panels as well?
>>>>>>> And anyway, it's the first deadline, I guess. These people are too
>>>>>>> smart
>>>>>>> not to extend it...
>>>>>>>
>>>>>>>         P.
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>


-- 
Dr James Cummings, researchsupport at it.ox.ac.uk
Research Support, IT Services, University of Oxford

From mholmes at uvic.ca  Wed Oct 31 11:17:03 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Wed, 31 Oct 2012 08:17:03 -0700
Subject: [tei-council] Errors/warnings from P5 build
In-Reply-To: <12a3bc9a-92a3-4a09-ba86-fcef26afc4fc@HUB02.ad.oak.ox.ac.uk>
References: <50905C34.1040005@uvic.ca>
	<81AE0AC2-7574-4E41-BF3B-36B70C067A79@it.ox.ac.uk>
	<5090DCC5.10400@retired.ox.ac.uk>
	<12a3bc9a-92a3-4a09-ba86-fcef26afc4fc@HUB02.ad.oak.ox.ac.uk>
Message-ID: <509140EF.1020709@uvic.ca>

On 12-10-31 02:16 AM, Sebastian Rahtz wrote:
> Now that is a perfect example of the implications arising from freezing or not freezing things like
> Lite and Tite?.

It's good, though, that the build process tells us about them in useful 
detail. If we continue refining it, we should end up in a position where 
we're automatically warned whenever a change to P5 causes a problem with 
Tite or Lite, and so maintaining them becomes much less of a chore.

Cheers,
Martin
-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From mholmes at uvic.ca  Wed Oct 31 12:43:22 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Wed, 31 Oct 2012 09:43:22 -0700
Subject: [tei-council] UVic Jenkins back up
Message-ID: <5091552A.20901@uvic.ca>

Our Jinks is back, after the transfer of horrible amounts of money to 
VMWare, chiz chiz.

cheers,
Martin
-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From James.Cummings at it.ox.ac.uk  Wed Oct 31 13:08:34 2012
From: James.Cummings at it.ox.ac.uk (James Cummings)
Date: Wed, 31 Oct 2012 17:08:34 +0000
Subject: [tei-council] http://purl.org/tei/fr/3536363
Message-ID: <50915B12.60408@it.ox.ac.uk>


I've been trying to wrap my head around 
http://purl.org/tei/fr/3536363 and potential rationalizations of 
the person/place/org content models.  I've put some of my working 
notes into the ticket and if anyone else feels like trying to 
focus  their mind around the problems for a few minutes and has 
any thoughts, please add them to the ticket.


-James

-- 
Dr James Cummings, researchsupport at it.ox.ac.uk
Research Support, IT Services, University of Oxford

From sebastian.rahtz at it.ox.ac.uk  Wed Oct 31 19:46:45 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Wed, 31 Oct 2012 23:46:45 +0000
Subject: [tei-council] roma
Message-ID: <88693715-CE75-4BC3-9676-0784BD9C5C42@it.ox.ac.uk>

see http://www.tei-c.org/Roma/, the fruits of our labours in the Oxford meeting go live.
--
Sebastian Rahtz      
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431


From bansp at o2.pl  Wed Oct 31 19:58:06 2012
From: bansp at o2.pl (Piotr Banski)
Date: Thu, 01 Nov 2012 00:58:06 +0100
Subject: [tei-council] roma
In-Reply-To: <88693715-CE75-4BC3-9676-0784BD9C5C42@it.ox.ac.uk>
References: <88693715-CE75-4BC3-9676-0784BD9C5C42@it.ox.ac.uk>
Message-ID: <5091BB0E.1000505@o2.pl>

On 01/11/12 00:46, Sebastian Rahtz wrote:
> see http://www.tei-c.org/Roma/, the fruits of our labours in the Oxford meeting go live.

(you may want to force-clear your dirty caches, you Council members, 
before you can bask in all her glory and sleekness)



From mholmes at uvic.ca  Wed Oct 31 23:21:01 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Wed, 31 Oct 2012 20:21:01 -0700
Subject: [tei-council] roma
In-Reply-To: <88693715-CE75-4BC3-9676-0784BD9C5C42@it.ox.ac.uk>
References: <88693715-CE75-4BC3-9676-0784BD9C5C42@it.ox.ac.uk>
Message-ID: <5091EA9D.40502@uvic.ca>

That's grand. I'll try and break it for you tomorrow. :-)

On 12-10-31 04:46 PM, Sebastian Rahtz wrote:
> see http://www.tei-c.org/Roma/, the fruits of our labours in the Oxford meeting go live.
> --
> Sebastian Rahtz
> Director (Research Support) of Academic IT Services
> University of Oxford IT Services
> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>

-- 
Martin Holmes
mholmes at uvic.ca
UVic Humanities Computing and Media Centre

From lou.burnard at retired.ox.ac.uk  Fri Nov  2 07:02:09 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Fri, 02 Nov 2012 11:02:09 +0000
Subject: [tei-council] biblscope and imprint
Message-ID: <5093A831.7080901@retired.ox.ac.uk>

Tootling across france on the train yesterday I started trying to deal 
with http://purl.org/tei/FR/3555190...

The part about the scope of biblscope was fairly easy to add, as was 
guidance on usage of biblScope. But I hit a problem with the second 
part, where it says that biblScope doesn't belong inside <imprint> -- 
the logic behind that desire is impeccable, but it messes up an awful 
lot of out current practice.

Consider the following:

<biblStruct>
<analytic>
<author>Chesnutt, David</author>
<title>Historical Editions in the States</title>
</analytic>
<monogr>
<title level="j">Computers and the Humanities</title>
<imprint>
<biblScope>25.6</biblScope>
<date when="1991-12">(December, 1991):</date>
<biblScope>377?380</biblScope>
</imprint>
</monogr>
</biblStruct>

which is a fairly common pattern in P5 (and appears as the canonical
example for <imprint>)

If, following FR 3555190, we think <biblStruct> has no place within 
<imprint>, how should
this, and many similar cases, be tagged?

One possibility might be

<monogr>
<title level="j">Computers and the Humanities</title>
<biblScope>25.6</biblScope>
<biblScope>377?380</biblScope>
<imprint>
<date when="1991-12">(December, 1991):</date>
</imprint>
</monogr>

Another might be

<monogr>
<title level="j">Computers and the Humanities</title>
<biblScope>25.6</biblScope>
<biblScope>377?380</biblScope>
<biblScope type="date">(December, 1991)</biblScope>
</imprint>
</monogr>

or perhaps better

<biblScope><date when="1991-12">(December, 1991)</date></biblScope>


Another might be to tweak the content model so that
model.dateLike is permitted outside <imprint> and alongside <biblScope>

And another might be to reconsider the decision to remove <biblScope>
from within <imprint>

Any ideas? Everyone braced for the rush of complaints?


From kevin.s.hawkins at ultraslavonic.info  Fri Nov  2 10:29:28 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Fri, 02 Nov 2012 10:29:28 -0400
Subject: [tei-council] biblscope and imprint
In-Reply-To: <5093A831.7080901@retired.ox.ac.uk>
References: <5093A831.7080901@retired.ox.ac.uk>
Message-ID: <5093D8C8.6090209@ultraslavonic.info>

The ticket proposes putting <biblScope>s after the <imprint> element 
when its present.  So your example would now be encoded as:

<biblStruct>
   <analytic>
     <author>Chesnutt, David</author>
     <title>Historical Editions in the States</title>
   </analytic>
   <monogr>
     <title level="j">Computers and the Humanities</title>
     <imprint>
       <date when="1991-12">(December, 1991):</date>
     </imprint>
     <biblScope>25.6</biblScope>
     <biblScope>377?380</biblScope>
   </monogr>
</biblStruct>

--Kevin

On 11/2/2012 7:02 AM, Lou Burnard wrote:
> Tootling across france on the train yesterday I started trying to deal
> with http://purl.org/tei/FR/3555190...
>
> The part about the scope of biblscope was fairly easy to add, as was
> guidance on usage of biblScope. But I hit a problem with the second
> part, where it says that biblScope doesn't belong inside<imprint>  --
> the logic behind that desire is impeccable, but it messes up an awful
> lot of out current practice.
>
> Consider the following:
>
> <biblStruct>
> <analytic>
> <author>Chesnutt, David</author>
> <title>Historical Editions in the States</title>
> </analytic>
> <monogr>
> <title level="j">Computers and the Humanities</title>
> <imprint>
> <biblScope>25.6</biblScope>
> <date when="1991-12">(December, 1991):</date>
> <biblScope>377?380</biblScope>
> </imprint>
> </monogr>
> </biblStruct>
>
> which is a fairly common pattern in P5 (and appears as the canonical
> example for<imprint>)
>
> If, following FR 3555190, we think<biblStruct>  has no place within
> <imprint>, how should
> this, and many similar cases, be tagged?
>
> One possibility might be
>
> <monogr>
> <title level="j">Computers and the Humanities</title>
> <biblScope>25.6</biblScope>
> <biblScope>377?380</biblScope>
> <imprint>
> <date when="1991-12">(December, 1991):</date>
> </imprint>
> </monogr>
>
> Another might be
>
> <monogr>
> <title level="j">Computers and the Humanities</title>
> <biblScope>25.6</biblScope>
> <biblScope>377?380</biblScope>
> <biblScope type="date">(December, 1991)</biblScope>
> </imprint>
> </monogr>
>
> or perhaps better
>
> <biblScope><date when="1991-12">(December, 1991)</date></biblScope>
>
>
> Another might be to tweak the content model so that
> model.dateLike is permitted outside<imprint>  and alongside<biblScope>
>
> And another might be to reconsider the decision to remove<biblScope>
> from within<imprint>
>
> Any ideas? Everyone braced for the rush of complaints?
>

From gabriel.bodard at kcl.ac.uk  Fri Nov  2 10:50:47 2012
From: gabriel.bodard at kcl.ac.uk (Gabriel Bodard)
Date: Fri, 2 Nov 2012 14:50:47 +0000
Subject: [tei-council] biblscope and imprint
In-Reply-To: <5093D8C8.6090209@ultraslavonic.info>
References: <5093A831.7080901@retired.ox.ac.uk>
	<5093D8C8.6090209@ultraslavonic.info>
Message-ID: <5093DDC7.1050504@kcl.ac.uk>

Is that what we proposed?

I thought I remembered we had suggested to put the biblScope in the 
element whose scope is being defined by it, so <biblScope type="pp"> 
goes in <analytic> because the article is only pages 377-380 of the 
volume in question, and <biblScope type="issue"> goes in <monogr> 
because this volume is only issue 25.6 of the journal....

But looking at this stuff I find myself more and more agreeing with 
Martin that biblStruct was never a good idea. ;-)

G

On 2012-11-02 14:29, Kevin Hawkins wrote:
> The ticket proposes putting <biblScope>s after the <imprint> element
> when its present.  So your example would now be encoded as:
>
> <biblStruct>
>     <analytic>
>       <author>Chesnutt, David</author>
>       <title>Historical Editions in the States</title>
>     </analytic>
>     <monogr>
>       <title level="j">Computers and the Humanities</title>
>       <imprint>
>         <date when="1991-12">(December, 1991):</date>
>       </imprint>
>       <biblScope>25.6</biblScope>
>       <biblScope>377?380</biblScope>
>     </monogr>
> </biblStruct>
>
> --Kevin
>
> On 11/2/2012 7:02 AM, Lou Burnard wrote:
>> Tootling across france on the train yesterday I started trying to deal
>> with http://purl.org/tei/FR/3555190...
>>
>> The part about the scope of biblscope was fairly easy to add, as was
>> guidance on usage of biblScope. But I hit a problem with the second
>> part, where it says that biblScope doesn't belong inside<imprint>  --
>> the logic behind that desire is impeccable, but it messes up an awful
>> lot of out current practice.
>>
>> Consider the following:
>>
>> <biblStruct>
>> <analytic>
>> <author>Chesnutt, David</author>
>> <title>Historical Editions in the States</title>
>> </analytic>
>> <monogr>
>> <title level="j">Computers and the Humanities</title>
>> <imprint>
>> <biblScope>25.6</biblScope>
>> <date when="1991-12">(December, 1991):</date>
>> <biblScope>377?380</biblScope>
>> </imprint>
>> </monogr>
>> </biblStruct>
>>
>> which is a fairly common pattern in P5 (and appears as the canonical
>> example for<imprint>)
>>
>> If, following FR 3555190, we think<biblStruct>  has no place within
>> <imprint>, how should
>> this, and many similar cases, be tagged?
>>
>> One possibility might be
>>
>> <monogr>
>> <title level="j">Computers and the Humanities</title>
>> <biblScope>25.6</biblScope>
>> <biblScope>377?380</biblScope>
>> <imprint>
>> <date when="1991-12">(December, 1991):</date>
>> </imprint>
>> </monogr>
>>
>> Another might be
>>
>> <monogr>
>> <title level="j">Computers and the Humanities</title>
>> <biblScope>25.6</biblScope>
>> <biblScope>377?380</biblScope>
>> <biblScope type="date">(December, 1991)</biblScope>
>> </imprint>
>> </monogr>
>>
>> or perhaps better
>>
>> <biblScope><date when="1991-12">(December, 1991)</date></biblScope>
>>
>>
>> Another might be to tweak the content model so that
>> model.dateLike is permitted outside<imprint>  and alongside<biblScope>
>>
>> And another might be to reconsider the decision to remove<biblScope>
>> from within<imprint>
>>
>> Any ideas? Everyone braced for the rush of complaints?
>>

-- 
Dr Gabriel BODARD
Researcher in Digital Epigraphy

Digital Humanities
King's College London
26-29 Drury Lane
London WC2B 5RL

T: +44 (0)20 7848 1388
F: +44 (0)20 7848 2980
E: gabriel.bodard at kcl.ac.uk

http://www.digitalclassicist.org/
http://www.currentepigraphy.org/


From kevin.s.hawkins at ultraslavonic.info  Fri Nov  2 11:11:55 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Fri, 02 Nov 2012 11:11:55 -0400
Subject: [tei-council] biblscope and imprint
In-Reply-To: <5093DDC7.1050504@kcl.ac.uk>
References: <5093A831.7080901@retired.ox.ac.uk>	<5093D8C8.6090209@ultraslavonic.info>
	<5093DDC7.1050504@kcl.ac.uk>
Message-ID: <5093E2BB.6010106@ultraslavonic.info>

Gabby's right. I was focusing on placement of <biblScope> in relation to 
<imprint>.  So Lou's citation (from the Guidelines) would in fact be:

<biblStruct>
   <analytic>
     <author>Chesnutt, David</author>
     <title>Historical Editions in the States</title>
     <biblScope type="pp">377?380</biblScope>
   </analytic>
   <monogr>
     <title level="j">Computers and the Humanities</title>
     <imprint>
       <date when="1991-12">(December, 1991):</date>
     </imprint>
     <biblScope type="vol">25</biblScope>
     <biblScope type="issue">6</biblScope>
   </monogr>
</biblStruct>

On 11/2/2012 10:50 AM, Gabriel Bodard wrote:
> Is that what we proposed?
>
> I thought I remembered we had suggested to put the biblScope in the
> element whose scope is being defined by it, so<biblScope type="pp">
> goes in<analytic>  because the article is only pages 377-380 of the
> volume in question, and<biblScope type="issue">  goes in<monogr>
> because this volume is only issue 25.6 of the journal....
>
> But looking at this stuff I find myself more and more agreeing with
> Martin that biblStruct was never a good idea. ;-)
>
> G
>
> On 2012-11-02 14:29, Kevin Hawkins wrote:
>> The ticket proposes putting<biblScope>s after the<imprint>  element
>> when its present.  So your example would now be encoded as:
>>
>> <biblStruct>
>>      <analytic>
>>        <author>Chesnutt, David</author>
>>        <title>Historical Editions in the States</title>
>>      </analytic>
>>      <monogr>
>>        <title level="j">Computers and the Humanities</title>
>>        <imprint>
>>          <date when="1991-12">(December, 1991):</date>
>>        </imprint>
>>        <biblScope>25.6</biblScope>
>>        <biblScope>377?380</biblScope>
>>      </monogr>
>> </biblStruct>
>>
>> --Kevin
>>
>> On 11/2/2012 7:02 AM, Lou Burnard wrote:
>>> Tootling across france on the train yesterday I started trying to deal
>>> with http://purl.org/tei/FR/3555190...
>>>
>>> The part about the scope of biblscope was fairly easy to add, as was
>>> guidance on usage of biblScope. But I hit a problem with the second
>>> part, where it says that biblScope doesn't belong inside<imprint>   --
>>> the logic behind that desire is impeccable, but it messes up an awful
>>> lot of out current practice.
>>>
>>> Consider the following:
>>>
>>> <biblStruct>
>>> <analytic>
>>> <author>Chesnutt, David</author>
>>> <title>Historical Editions in the States</title>
>>> </analytic>
>>> <monogr>
>>> <title level="j">Computers and the Humanities</title>
>>> <imprint>
>>> <biblScope>25.6</biblScope>
>>> <date when="1991-12">(December, 1991):</date>
>>> <biblScope>377?380</biblScope>
>>> </imprint>
>>> </monogr>
>>> </biblStruct>
>>>
>>> which is a fairly common pattern in P5 (and appears as the canonical
>>> example for<imprint>)
>>>
>>> If, following FR 3555190, we think<biblStruct>   has no place within
>>> <imprint>, how should
>>> this, and many similar cases, be tagged?
>>>
>>> One possibility might be
>>>
>>> <monogr>
>>> <title level="j">Computers and the Humanities</title>
>>> <biblScope>25.6</biblScope>
>>> <biblScope>377?380</biblScope>
>>> <imprint>
>>> <date when="1991-12">(December, 1991):</date>
>>> </imprint>
>>> </monogr>
>>>
>>> Another might be
>>>
>>> <monogr>
>>> <title level="j">Computers and the Humanities</title>
>>> <biblScope>25.6</biblScope>
>>> <biblScope>377?380</biblScope>
>>> <biblScope type="date">(December, 1991)</biblScope>
>>> </imprint>
>>> </monogr>
>>>
>>> or perhaps better
>>>
>>> <biblScope><date when="1991-12">(December, 1991)</date></biblScope>
>>>
>>>
>>> Another might be to tweak the content model so that
>>> model.dateLike is permitted outside<imprint>   and alongside<biblScope>
>>>
>>> And another might be to reconsider the decision to remove<biblScope>
>>> from within<imprint>
>>>
>>> Any ideas? Everyone braced for the rush of complaints?
>>>
>

From gabriel.bodard at kcl.ac.uk  Fri Nov  2 13:16:49 2012
From: gabriel.bodard at kcl.ac.uk (Gabriel Bodard)
Date: Fri, 2 Nov 2012 17:16:49 +0000
Subject: [tei-council] space/certainty in release 2.2.0
Message-ID: <50940001.2010101@kcl.ac.uk>

A weird thing has happened: for the last couple of years now <space> has 
had the same content model as <gap>: i.e. ( model.descLike | 
model.certLike )*

As of the latest release, however, that seems to have reverted to 
model.descLike* only (breaking a number of my files).

Does anyone know how this happened, and can we try to fix this asap please?

G

-- 
Dr Gabriel BODARD
Researcher in Digital Epigraphy

Digital Humanities
King's College London
26-29 Drury Lane
London WC2B 5RL

T: +44 (0)20 7848 1388
F: +44 (0)20 7848 2980
E: gabriel.bodard at kcl.ac.uk

http://www.digitalclassicist.org/
http://www.currentepigraphy.org/


From gabriel.bodard at kcl.ac.uk  Fri Nov  2 13:22:05 2012
From: gabriel.bodard at kcl.ac.uk (Gabriel Bodard)
Date: Fri, 2 Nov 2012 17:22:05 +0000
Subject: [tei-council] space/certainty in release 2.2.0
In-Reply-To: <50940001.2010101@kcl.ac.uk>
References: <50940001.2010101@kcl.ac.uk>
Message-ID: <5094013D.4030702@kcl.ac.uk>

Oh, I see what happened. model.certLike is no longer a member of 
model.glossLike, and when this was changed, presumably someone forgot to 
add model.certLike to <space>, which previously inherited it.

Does this need a 2.2.1 release to fix (along with anything else we spot 
like this?)

G

On 2012-11-02 17:16, Gabriel Bodard wrote:
> A weird thing has happened: for the last couple of years now <space> has
> had the same content model as <gap>: i.e. ( model.descLike |
> model.certLike )*
>
> As of the latest release, however, that seems to have reverted to
> model.descLike* only (breaking a number of my files).
>
> Does anyone know how this happened, and can we try to fix this asap please?
>
> G
>

-- 
Dr Gabriel BODARD
Researcher in Digital Epigraphy

Digital Humanities
King's College London
26-29 Drury Lane
London WC2B 5RL

T: +44 (0)20 7848 1388
F: +44 (0)20 7848 2980
E: gabriel.bodard at kcl.ac.uk

http://www.digitalclassicist.org/
http://www.currentepigraphy.org/


From mholmes at uvic.ca  Fri Nov  2 13:44:11 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Fri, 2 Nov 2012 10:44:11 -0700
Subject: [tei-council] space/certainty in release 2.2.0
In-Reply-To: <5094013D.4030702@kcl.ac.uk>
References: <50940001.2010101@kcl.ac.uk> <5094013D.4030702@kcl.ac.uk>
Message-ID: <5094066B.50708@uvic.ca>

I think it might have been in here:

r10940 | louburnard | 2012-10-07 15:37:24 -0700 (Sun, 07 Oct 2012) | 2 lines

Separating model.descLike out from model.glossLike and changing some 
class memberships per FR/3565136

So it's pretty recent. Since it breaks backward compatibility, we should:

1. Fix it.

2. Put some <space> elements in the test files, to make sure we catch 
anything similar in future.

3. Do 2.2.1 fairly soon.

Cheers,
Martin

On 12-11-02 10:22 AM, Gabriel Bodard wrote:
> Oh, I see what happened. model.certLike is no longer a member of
> model.glossLike, and when this was changed, presumably someone forgot to
> add model.certLike to <space>, which previously inherited it.
>
> Does this need a 2.2.1 release to fix (along with anything else we spot
> like this?)
>
> G
>
> On 2012-11-02 17:16, Gabriel Bodard wrote:
>> A weird thing has happened: for the last couple of years now <space> has
>> had the same content model as <gap>: i.e. ( model.descLike |
>> model.certLike )*
>>
>> As of the latest release, however, that seems to have reverted to
>> model.descLike* only (breaking a number of my files).
>>
>> Does anyone know how this happened, and can we try to fix this asap please?
>>
>> G
>>
>

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From lou.burnard at retired.ox.ac.uk  Fri Nov  2 13:56:55 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Fri, 02 Nov 2012 17:56:55 +0000
Subject: [tei-council] space/certainty in release 2.2.0
In-Reply-To: <5094066B.50708@uvic.ca>
References: <50940001.2010101@kcl.ac.uk> <5094013D.4030702@kcl.ac.uk>
	<5094066B.50708@uvic.ca>
Message-ID: <50940967.4010007@retired.ox.ac.uk>

See ticket  at http://purl.org/tei/FR/3565137 (the number of which is 
mistyped in the svn log entry, sorry)

I quote from the fairly extensive notes on that ticket:

"char, glyph,incident, interpGrp, joinGrp, kinesic, space, vocal now 
have just model.descLike"

Any others on that list we think on second thoughts ought to be able to 
contain a member of model.certLike?




On 02/11/12 17:44, Martin Holmes wrote:
> I think it might have been in here:
>
> r10940 | louburnard | 2012-10-07 15:37:24 -0700 (Sun, 07 Oct 2012) | 2 lines
>
> Separating model.descLike out from model.glossLike and changing some
> class memberships per FR/3565136
>
> So it's pretty recent. Since it breaks backward compatibility, we should:
>
> 1. Fix it.
>
> 2. Put some <space> elements in the test files, to make sure we catch
> anything similar in future.
>
> 3. Do 2.2.1 fairly soon.
>
> Cheers,
> Martin
>
> On 12-11-02 10:22 AM, Gabriel Bodard wrote:
>> Oh, I see what happened. model.certLike is no longer a member of
>> model.glossLike, and when this was changed, presumably someone forgot to
>> add model.certLike to <space>, which previously inherited it.
>>
>> Does this need a 2.2.1 release to fix (along with anything else we spot
>> like this?)
>>
>> G
>>
>> On 2012-11-02 17:16, Gabriel Bodard wrote:
>>> A weird thing has happened: for the last couple of years now <space> has
>>> had the same content model as <gap>: i.e. ( model.descLike |
>>> model.certLike )*
>>>
>>> As of the latest release, however, that seems to have reverted to
>>> model.descLike* only (breaking a number of my files).
>>>
>>> Does anyone know how this happened, and can we try to fix this asap please?
>>>
>>> G
>>>
>>
>


From lou.burnard at retired.ox.ac.uk  Fri Nov  2 14:14:50 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Fri, 02 Nov 2012 18:14:50 +0000
Subject: [tei-council] biblscope and imprint
In-Reply-To: <5093E2BB.6010106@ultraslavonic.info>
References: <5093A831.7080901@retired.ox.ac.uk>	<5093D8C8.6090209@ultraslavonic.info>
	<5093DDC7.1050504@kcl.ac.uk> <5093E2BB.6010106@ultraslavonic.info>
Message-ID: <50940D9A.7030007@retired.ox.ac.uk>

OK. Seems like quite a lot of tagging, and I doubt if anyone will ever 
get it right, all the same. In cases like this, the pagination often 
runs across the volumes -- the December 1991 issue of this journal 
doesn't have over 380 pages!


On 02/11/12 15:11, Kevin Hawkins wrote:
> Gabby's right. I was focusing on placement of <biblScope> in relation to
> <imprint>.  So Lou's citation (from the Guidelines) would in fact be:
>
> <biblStruct>
>     <analytic>
>       <author>Chesnutt, David</author>
>       <title>Historical Editions in the States</title>
>       <biblScope type="pp">377?380</biblScope>
>     </analytic>
>     <monogr>
>       <title level="j">Computers and the Humanities</title>
>       <imprint>
>         <date when="1991-12">(December, 1991):</date>
>       </imprint>
>       <biblScope type="vol">25</biblScope>
>       <biblScope type="issue">6</biblScope>
>     </monogr>
> </biblStruct>
>
> On 11/2/2012 10:50 AM, Gabriel Bodard wrote:
>> Is that what we proposed?
>>
>> I thought I remembered we had suggested to put the biblScope in the
>> element whose scope is being defined by it, so<biblScope type="pp">
>> goes in<analytic>  because the article is only pages 377-380 of the
>> volume in question, and<biblScope type="issue">  goes in<monogr>
>> because this volume is only issue 25.6 of the journal....
>>
>> But looking at this stuff I find myself more and more agreeing with
>> Martin that biblStruct was never a good idea. ;-)
>>
>> G
>>
>> On 2012-11-02 14:29, Kevin Hawkins wrote:
>>> The ticket proposes putting<biblScope>s after the<imprint>  element
>>> when its present.  So your example would now be encoded as:
>>>
>>> <biblStruct>
>>>       <analytic>
>>>         <author>Chesnutt, David</author>
>>>         <title>Historical Editions in the States</title>
>>>       </analytic>
>>>       <monogr>
>>>         <title level="j">Computers and the Humanities</title>
>>>         <imprint>
>>>           <date when="1991-12">(December, 1991):</date>
>>>         </imprint>
>>>         <biblScope>25.6</biblScope>
>>>         <biblScope>377?380</biblScope>
>>>       </monogr>
>>> </biblStruct>
>>>
>>> --Kevin
>>>
>>> On 11/2/2012 7:02 AM, Lou Burnard wrote:
>>>> Tootling across france on the train yesterday I started trying to deal
>>>> with http://purl.org/tei/FR/3555190...
>>>>
>>>> The part about the scope of biblscope was fairly easy to add, as was
>>>> guidance on usage of biblScope. But I hit a problem with the second
>>>> part, where it says that biblScope doesn't belong inside<imprint>   --
>>>> the logic behind that desire is impeccable, but it messes up an awful
>>>> lot of out current practice.
>>>>
>>>> Consider the following:
>>>>
>>>> <biblStruct>
>>>> <analytic>
>>>> <author>Chesnutt, David</author>
>>>> <title>Historical Editions in the States</title>
>>>> </analytic>
>>>> <monogr>
>>>> <title level="j">Computers and the Humanities</title>
>>>> <imprint>
>>>> <biblScope>25.6</biblScope>
>>>> <date when="1991-12">(December, 1991):</date>
>>>> <biblScope>377?380</biblScope>
>>>> </imprint>
>>>> </monogr>
>>>> </biblStruct>
>>>>
>>>> which is a fairly common pattern in P5 (and appears as the canonical
>>>> example for<imprint>)
>>>>
>>>> If, following FR 3555190, we think<biblStruct>   has no place within
>>>> <imprint>, how should
>>>> this, and many similar cases, be tagged?
>>>>
>>>> One possibility might be
>>>>
>>>> <monogr>
>>>> <title level="j">Computers and the Humanities</title>
>>>> <biblScope>25.6</biblScope>
>>>> <biblScope>377?380</biblScope>
>>>> <imprint>
>>>> <date when="1991-12">(December, 1991):</date>
>>>> </imprint>
>>>> </monogr>
>>>>
>>>> Another might be
>>>>
>>>> <monogr>
>>>> <title level="j">Computers and the Humanities</title>
>>>> <biblScope>25.6</biblScope>
>>>> <biblScope>377?380</biblScope>
>>>> <biblScope type="date">(December, 1991)</biblScope>
>>>> </imprint>
>>>> </monogr>
>>>>
>>>> or perhaps better
>>>>
>>>> <biblScope><date when="1991-12">(December, 1991)</date></biblScope>
>>>>
>>>>
>>>> Another might be to tweak the content model so that
>>>> model.dateLike is permitted outside<imprint>   and alongside<biblScope>
>>>>
>>>> And another might be to reconsider the decision to remove<biblScope>
>>>> from within<imprint>
>>>>
>>>> Any ideas? Everyone braced for the rush of complaints?
>>>>
>>


From mholmes at uvic.ca  Fri Nov  2 15:07:18 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Fri, 2 Nov 2012 12:07:18 -0700
Subject: [tei-council] space/certainty in release 2.2.0
In-Reply-To: <50940967.4010007@retired.ox.ac.uk>
References: <50940001.2010101@kcl.ac.uk> <5094013D.4030702@kcl.ac.uk>
	<5094066B.50708@uvic.ca> <50940967.4010007@retired.ox.ac.uk>
Message-ID: <509419E6.1020402@uvic.ca>

The ticket is actually a bug, not fr:

<http://purl.org/tei/bugs/3565137>

On 12-11-02 10:56 AM, Lou Burnard wrote:
> See ticket  at http://purl.org/tei/FR/3565137 (the number of which is
> mistyped in the svn log entry, sorry)
>
> I quote from the fairly extensive notes on that ticket:
>
> "char, glyph,incident, interpGrp, joinGrp, kinesic, space, vocal now
> have just model.descLike"
>
> Any others on that list we think on second thoughts ought to be able to
> contain a member of model.certLike?
>
>
>
>
> On 02/11/12 17:44, Martin Holmes wrote:
>> I think it might have been in here:
>>
>> r10940 | louburnard | 2012-10-07 15:37:24 -0700 (Sun, 07 Oct 2012) | 2 lines
>>
>> Separating model.descLike out from model.glossLike and changing some
>> class memberships per FR/3565136
>>
>> So it's pretty recent. Since it breaks backward compatibility, we should:
>>
>> 1. Fix it.
>>
>> 2. Put some <space> elements in the test files, to make sure we catch
>> anything similar in future.
>>
>> 3. Do 2.2.1 fairly soon.
>>
>> Cheers,
>> Martin
>>
>> On 12-11-02 10:22 AM, Gabriel Bodard wrote:
>>> Oh, I see what happened. model.certLike is no longer a member of
>>> model.glossLike, and when this was changed, presumably someone forgot to
>>> add model.certLike to <space>, which previously inherited it.
>>>
>>> Does this need a 2.2.1 release to fix (along with anything else we spot
>>> like this?)
>>>
>>> G
>>>
>>> On 2012-11-02 17:16, Gabriel Bodard wrote:
>>>> A weird thing has happened: for the last couple of years now <space> has
>>>> had the same content model as <gap>: i.e. ( model.descLike |
>>>> model.certLike )*
>>>>
>>>> As of the latest release, however, that seems to have reverted to
>>>> model.descLike* only (breaking a number of my files).
>>>>
>>>> Does anyone know how this happened, and can we try to fix this asap please?
>>>>
>>>> G
>>>>
>>>
>>
>

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From lou.burnard at retired.ox.ac.uk  Fri Nov  2 15:23:57 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Fri, 02 Nov 2012 19:23:57 +0000
Subject: [tei-council] biblscope and imprint
In-Reply-To: <50940D9A.7030007@retired.ox.ac.uk>
References: <5093A831.7080901@retired.ox.ac.uk>	<5093D8C8.6090209@ultraslavonic.info>
	<5093DDC7.1050504@kcl.ac.uk> <5093E2BB.6010106@ultraslavonic.info>
	<50940D9A.7030007@retired.ox.ac.uk>
Message-ID: <50941DCD.9070406@retired.ox.ac.uk>

Kevin's recommended tagging below contradicts what it currently says in 
the Guidelines:

"<p>When the item being cited is a journal article, the
<gi>imprint</gi> element describing the issue in which it appeared
may contain <gi>biblScope</gi> elements for volume and
page numbers, together with a <gi>date</gi> element.
  </p>"

That doesn't mean it's wrong of course... but that para should probably 
be removed.

There is also the rather nasty Thaller example in section #COBICOL which 
contains an analytic, followed by two monogrs. The article in question 
was published twice, once in a journal and once as a free standing 
monograph. If we put the page numbers for the journal publication inside 
the analytic, as Kevin suggests, how do we know that they are not 
relevant to the second <monogr>?




On 02/11/12 18:14, Lou Burnard wrote:
> OK. Seems like quite a lot of tagging, and I doubt if anyone will ever
> get it right, all the same. In cases like this, the pagination often
> runs across the volumes -- the December 1991 issue of this journal
> doesn't have over 380 pages!
>
>
> On 02/11/12 15:11, Kevin Hawkins wrote:
>> Gabby's right. I was focusing on placement of <biblScope> in relation to
>> <imprint>.  So Lou's citation (from the Guidelines) would in fact be:
>>
>> <biblStruct>
>>      <analytic>
>>        <author>Chesnutt, David</author>
>>        <title>Historical Editions in the States</title>
>>        <biblScope type="pp">377?380</biblScope>
>>      </analytic>
>>      <monogr>
>>        <title level="j">Computers and the Humanities</title>
>>        <imprint>
>>          <date when="1991-12">(December, 1991):</date>
>>        </imprint>
>>        <biblScope type="vol">25</biblScope>
>>        <biblScope type="issue">6</biblScope>
>>      </monogr>
>> </biblStruct>
>>
>> On 11/2/2012 10:50 AM, Gabriel Bodard wrote:
>>> Is that what we proposed?
>>>
>>> I thought I remembered we had suggested to put the biblScope in the
>>> element whose scope is being defined by it, so<biblScope type="pp">
>>> goes in<analytic>  because the article is only pages 377-380 of the
>>> volume in question, and<biblScope type="issue">  goes in<monogr>
>>> because this volume is only issue 25.6 of the journal....
>>>
>>> But looking at this stuff I find myself more and more agreeing with
>>> Martin that biblStruct was never a good idea. ;-)
>>>
>>> G
>>>
>>> On 2012-11-02 14:29, Kevin Hawkins wrote:
>>>> The ticket proposes putting<biblScope>s after the<imprint>  element
>>>> when its present.  So your example would now be encoded as:
>>>>
>>>> <biblStruct>
>>>>        <analytic>
>>>>          <author>Chesnutt, David</author>
>>>>          <title>Historical Editions in the States</title>
>>>>        </analytic>
>>>>        <monogr>
>>>>          <title level="j">Computers and the Humanities</title>
>>>>          <imprint>
>>>>            <date when="1991-12">(December, 1991):</date>
>>>>          </imprint>
>>>>          <biblScope>25.6</biblScope>
>>>>          <biblScope>377?380</biblScope>
>>>>        </monogr>
>>>> </biblStruct>
>>>>
>>>> --Kevin
>>>>
>>>> On 11/2/2012 7:02 AM, Lou Burnard wrote:
>>>>> Tootling across france on the train yesterday I started trying to deal
>>>>> with http://purl.org/tei/FR/3555190...
>>>>>
>>>>> The part about the scope of biblscope was fairly easy to add, as was
>>>>> guidance on usage of biblScope. But I hit a problem with the second
>>>>> part, where it says that biblScope doesn't belong inside<imprint>   --
>>>>> the logic behind that desire is impeccable, but it messes up an awful
>>>>> lot of out current practice.
>>>>>
>>>>> Consider the following:
>>>>>
>>>>> <biblStruct>
>>>>> <analytic>
>>>>> <author>Chesnutt, David</author>
>>>>> <title>Historical Editions in the States</title>
>>>>> </analytic>
>>>>> <monogr>
>>>>> <title level="j">Computers and the Humanities</title>
>>>>> <imprint>
>>>>> <biblScope>25.6</biblScope>
>>>>> <date when="1991-12">(December, 1991):</date>
>>>>> <biblScope>377?380</biblScope>
>>>>> </imprint>
>>>>> </monogr>
>>>>> </biblStruct>
>>>>>
>>>>> which is a fairly common pattern in P5 (and appears as the canonical
>>>>> example for<imprint>)
>>>>>
>>>>> If, following FR 3555190, we think<biblStruct>   has no place within
>>>>> <imprint>, how should
>>>>> this, and many similar cases, be tagged?
>>>>>
>>>>> One possibility might be
>>>>>
>>>>> <monogr>
>>>>> <title level="j">Computers and the Humanities</title>
>>>>> <biblScope>25.6</biblScope>
>>>>> <biblScope>377?380</biblScope>
>>>>> <imprint>
>>>>> <date when="1991-12">(December, 1991):</date>
>>>>> </imprint>
>>>>> </monogr>
>>>>>
>>>>> Another might be
>>>>>
>>>>> <monogr>
>>>>> <title level="j">Computers and the Humanities</title>
>>>>> <biblScope>25.6</biblScope>
>>>>> <biblScope>377?380</biblScope>
>>>>> <biblScope type="date">(December, 1991)</biblScope>
>>>>> </imprint>
>>>>> </monogr>
>>>>>
>>>>> or perhaps better
>>>>>
>>>>> <biblScope><date when="1991-12">(December, 1991)</date></biblScope>
>>>>>
>>>>>
>>>>> Another might be to tweak the content model so that
>>>>> model.dateLike is permitted outside<imprint>   and alongside<biblScope>
>>>>>
>>>>> And another might be to reconsider the decision to remove<biblScope>
>>>>> from within<imprint>
>>>>>
>>>>> Any ideas? Everyone braced for the rush of complaints?
>>>>>


From kevin.s.hawkins at ultraslavonic.info  Fri Nov  2 22:14:59 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Fri, 02 Nov 2012 22:14:59 -0400
Subject: [tei-council] biblscope and imprint
In-Reply-To: <50941DCD.9070406@retired.ox.ac.uk>
References: <5093A831.7080901@retired.ox.ac.uk>	<5093D8C8.6090209@ultraslavonic.info>
	<5093DDC7.1050504@kcl.ac.uk> <5093E2BB.6010106@ultraslavonic.info>
	<50940D9A.7030007@retired.ox.ac.uk>
	<50941DCD.9070406@retired.ox.ac.uk>
Message-ID: <50947E23.6020703@ultraslavonic.info>

On 11/2/12 3:23 PM, Lou Burnard wrote:
> Kevin's recommended tagging below contradicts what it currently says in
> the Guidelines:
>
> "<p>When the item being cited is a journal article, the
> <gi>imprint</gi> element describing the issue in which it appeared
> may contain <gi>biblScope</gi> elements for volume and
> page numbers, together with a <gi>date</gi> element.
>    </p>"
>
> That doesn't mean it's wrong of course... but that para should probably
> be removed.

Exactly.  In the ticket, Gabby points this out in (2) and in the same 
ticket suggests removing it as the way to address (2).

> There is also the rather nasty Thaller example in section #COBICOL which
> contains an analytic, followed by two monogrs. The article in question
> was published twice, once in a journal and once as a free standing
> monograph. If we put the page numbers for the journal publication inside
> the analytic, as Kevin suggests, how do we know that they are not
> relevant to the second <monogr>?

An excellent question.  Gabby and I didn't consider this.  I'm not sure 
what to suggest.  :(

From lou.burnard at retired.ox.ac.uk  Sat Nov  3 07:35:22 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Sat, 03 Nov 2012 11:35:22 +0000
Subject: [tei-council] biblscope and imprint
In-Reply-To: <50940D9A.7030007@retired.ox.ac.uk>
References: <5093A831.7080901@retired.ox.ac.uk>	<5093D8C8.6090209@ultraslavonic.info>
	<5093DDC7.1050504@kcl.ac.uk> <5093E2BB.6010106@ultraslavonic.info>
	<50940D9A.7030007@retired.ox.ac.uk>
Message-ID: <5095017A.8060903@retired.ox.ac.uk>

Looking at this suggestion again: surely it cannot ever be right to put 
a <biblScope> within an <analytic> ?

See further my comment on the ticket -- specifically

"I think the sentence "Each <biblScope> describes where (within its 
parent element) to find the thing in the previous level" is correct, but 
only if you understand the word "level" as "preceding sibling of a 
different bibliographic level"

Hence the pagination biblScope ought to go within the monogr, not within 
the analytic. This also makes sense if the same article appears in two 
different monogrs, possibly with different pagination.



On 02/11/12 18:14, Lou Burnard wrote:
> On 02/11/12 15:11, Kevin Hawkins wrote:
>> Gabby's right. I was focusing on placement of <biblScope> in relation to
>> <imprint>.  So Lou's citation (from the Guidelines) would in fact be:
>>
>> <biblStruct>
>>      <analytic>
>>        <author>Chesnutt, David</author>
>>        <title>Historical Editions in the States</title>
>>        <biblScope type="pp">377?380</biblScope>
>>      </analytic>
>>      <monogr>
>>        <title level="j">Computers and the Humanities</title>
>>        <imprint>
>>          <date when="1991-12">(December, 1991):</date>
>>        </imprint>
>>        <biblScope type="vol">25</biblScope>
>>        <biblScope type="issue">6</biblScope>
>>      </monogr>
>> </biblStruct>
>>
>> On 11/2/2012 10:50 AM, Gabriel Bodard wrote:
>>> Is that what we proposed?
>>>
>>> I thought I remembered we had suggested to put the biblScope in the
>>> element whose scope is being defined by it, so<biblScope type="pp">
>>> goes in<analytic>  because the article is only pages 377-380 of the
>>> volume in question, and<biblScope type="issue">  goes in<monogr>
>>> because this volume is only issue 25.6 of the journal....
>>>
>>> But looking at this stuff I find myself more and more agreeing with
>>> Martin that biblStruct was never a good idea. ;-)
>>>
>>> G
>>>
>>> On 2012-11-02 14:29, Kevin Hawkins wrote:
>>>> The ticket proposes putting<biblScope>s after the<imprint>  element
>>>> when its present.  So your example would now be encoded as:
>>>>
>>>> <biblStruct>
>>>>        <analytic>
>>>>          <author>Chesnutt, David</author>
>>>>          <title>Historical Editions in the States</title>
>>>>        </analytic>
>>>>        <monogr>
>>>>          <title level="j">Computers and the Humanities</title>
>>>>          <imprint>
>>>>            <date when="1991-12">(December, 1991):</date>
>>>>          </imprint>
>>>>          <biblScope>25.6</biblScope>
>>>>          <biblScope>377?380</biblScope>
>>>>        </monogr>
>>>> </biblStruct>
>>>>
>>>> --Kevin
>>>>
>>>> On 11/2/2012 7:02 AM, Lou Burnard wrote:
>>>>> Tootling across france on the train yesterday I started trying to deal
>>>>> with http://purl.org/tei/FR/3555190...
>>>>>
>>>>> The part about the scope of biblscope was fairly easy to add, as was
>>>>> guidance on usage of biblScope. But I hit a problem with the second
>>>>> part, where it says that biblScope doesn't belong inside<imprint>   --
>>>>> the logic behind that desire is impeccable, but it messes up an awful
>>>>> lot of out current practice.
>>>>>
>>>>> Consider the following:
>>>>>
>>>>> <biblStruct>
>>>>> <analytic>
>>>>> <author>Chesnutt, David</author>
>>>>> <title>Historical Editions in the States</title>
>>>>> </analytic>
>>>>> <monogr>
>>>>> <title level="j">Computers and the Humanities</title>
>>>>> <imprint>
>>>>> <biblScope>25.6</biblScope>
>>>>> <date when="1991-12">(December, 1991):</date>
>>>>> <biblScope>377?380</biblScope>
>>>>> </imprint>
>>>>> </monogr>
>>>>> </biblStruct>
>>>>>
>>>>> which is a fairly common pattern in P5 (and appears as the canonical
>>>>> example for<imprint>)
>>>>>
>>>>> If, following FR 3555190, we think<biblStruct>   has no place within
>>>>> <imprint>, how should
>>>>> this, and many similar cases, be tagged?
>>>>>
>>>>> One possibility might be
>>>>>
>>>>> <monogr>
>>>>> <title level="j">Computers and the Humanities</title>
>>>>> <biblScope>25.6</biblScope>
>>>>> <biblScope>377?380</biblScope>
>>>>> <imprint>
>>>>> <date when="1991-12">(December, 1991):</date>
>>>>> </imprint>
>>>>> </monogr>
>>>>>
>>>>> Another might be
>>>>>
>>>>> <monogr>
>>>>> <title level="j">Computers and the Humanities</title>
>>>>> <biblScope>25.6</biblScope>
>>>>> <biblScope>377?380</biblScope>
>>>>> <biblScope type="date">(December, 1991)</biblScope>
>>>>> </imprint>
>>>>> </monogr>
>>>>>
>>>>> or perhaps better
>>>>>
>>>>> <biblScope><date when="1991-12">(December, 1991)</date></biblScope>
>>>>>
>>>>>
>>>>> Another might be to tweak the content model so that
>>>>> model.dateLike is permitted outside<imprint>   and alongside<biblScope>
>>>>>
>>>>> And another might be to reconsider the decision to remove<biblScope>
>>>>> from within<imprint>
>>>>>
>>>>> Any ideas? Everyone braced for the rush of complaints?
>>>>>
>>>
>


From lou.burnard at retired.ox.ac.uk  Sat Nov  3 07:36:50 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Sat, 03 Nov 2012 11:36:50 +0000
Subject: [tei-council] biblscope and imprint
In-Reply-To: <50947E23.6020703@ultraslavonic.info>
References: <5093A831.7080901@retired.ox.ac.uk>	<5093D8C8.6090209@ultraslavonic.info>
	<5093DDC7.1050504@kcl.ac.uk> <5093E2BB.6010106@ultraslavonic.info>
	<50940D9A.7030007@retired.ox.ac.uk>
	<50941DCD.9070406@retired.ox.ac.uk>
	<50947E23.6020703@ultraslavonic.info>
Message-ID: <509501D2.4050309@retired.ox.ac.uk>

On 03/11/12 02:14, Kevin Hawkins wrote:

>> There is also the rather nasty Thaller example in section #COBICOL which
>> contains an analytic, followed by two monogrs. The article in question
>> was published twice, once in a journal and once as a free standing
>> monograph. If we put the page numbers for the journal publication inside
>> the analytic, as Kevin suggests, how do we know that they are not
>> relevant to the second <monogr>?
>
> An excellent question.  Gabby and I didn't consider this.  I'm not sure
> what to suggest.  :(
>

Hmm. That's a bit of show stopper! See my note on the ticket...

http://purl.org/tei/FR/3555190

From kevin.s.hawkins at ultraslavonic.info  Sat Nov  3 09:51:34 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Sat, 03 Nov 2012 09:51:34 -0400
Subject: [tei-council] biblscope and imprint
In-Reply-To: <5095017A.8060903@retired.ox.ac.uk>
References: <5093A831.7080901@retired.ox.ac.uk>	<5093D8C8.6090209@ultraslavonic.info>
	<5093DDC7.1050504@kcl.ac.uk> <5093E2BB.6010106@ultraslavonic.info>
	<50940D9A.7030007@retired.ox.ac.uk>
	<5095017A.8060903@retired.ox.ac.uk>
Message-ID: <50952166.2060305@ultraslavonic.info>

Ugh, Gabby and I both misremembered the proposal at 
http://purl.org/tei/FR/3555190 .  Lou is right that according to that 
proposal, there is never a <biblScope> in <analytic>, so the Chestnutt 
citation encoded according to the proposal would be:

<biblStruct>
   <analytic>
     <author>Chesnutt, David</author>
     <title>Historical Editions in the States</title>
   </analytic>
   <monogr>
     <title level="j">Computers and the Humanities</title>
     <imprint>
       <date when="1991-12">(December, 1991):</date>
     </imprint>
     <biblScope type="vol">25</biblScope>
     <biblScope type="issue">6</biblScope>
     <biblScope type="pp">377?380</biblScope>
   </monogr>
</biblStruct>

(which is more or less how I first wrote it below).

On 11/3/12 7:35 AM, Lou Burnard wrote:
> Looking at this suggestion again: surely it cannot ever be right to put
> a <biblScope> within an <analytic> ?
>
> See further my comment on the ticket -- specifically
>
> "I think the sentence "Each <biblScope> describes where (within its
> parent element) to find the thing in the previous level" is correct, but
> only if you understand the word "level" as "preceding sibling of a
> different bibliographic level"
>
> Hence the pagination biblScope ought to go within the monogr, not within
> the analytic. This also makes sense if the same article appears in two
> different monogrs, possibly with different pagination.
>
>
>
> On 02/11/12 18:14, Lou Burnard wrote:
>> On 02/11/12 15:11, Kevin Hawkins wrote:
>>> Gabby's right. I was focusing on placement of <biblScope> in relation to
>>> <imprint>.  So Lou's citation (from the Guidelines) would in fact be:
>>>
>>> <biblStruct>
>>>       <analytic>
>>>         <author>Chesnutt, David</author>
>>>         <title>Historical Editions in the States</title>
>>>         <biblScope type="pp">377?380</biblScope>
>>>       </analytic>
>>>       <monogr>
>>>         <title level="j">Computers and the Humanities</title>
>>>         <imprint>
>>>           <date when="1991-12">(December, 1991):</date>
>>>         </imprint>
>>>         <biblScope type="vol">25</biblScope>
>>>         <biblScope type="issue">6</biblScope>
>>>       </monogr>
>>> </biblStruct>
>>>
>>> On 11/2/2012 10:50 AM, Gabriel Bodard wrote:
>>>> Is that what we proposed?
>>>>
>>>> I thought I remembered we had suggested to put the biblScope in the
>>>> element whose scope is being defined by it, so<biblScope type="pp">
>>>> goes in<analytic>  because the article is only pages 377-380 of the
>>>> volume in question, and<biblScope type="issue">  goes in<monogr>
>>>> because this volume is only issue 25.6 of the journal....
>>>>
>>>> But looking at this stuff I find myself more and more agreeing with
>>>> Martin that biblStruct was never a good idea. ;-)
>>>>
>>>> G
>>>>
>>>> On 2012-11-02 14:29, Kevin Hawkins wrote:
>>>>> The ticket proposes putting<biblScope>s after the<imprint>  element
>>>>> when its present.  So your example would now be encoded as:
>>>>>
>>>>> <biblStruct>
>>>>>         <analytic>
>>>>>           <author>Chesnutt, David</author>
>>>>>           <title>Historical Editions in the States</title>
>>>>>         </analytic>
>>>>>         <monogr>
>>>>>           <title level="j">Computers and the Humanities</title>
>>>>>           <imprint>
>>>>>             <date when="1991-12">(December, 1991):</date>
>>>>>           </imprint>
>>>>>           <biblScope>25.6</biblScope>
>>>>>           <biblScope>377?380</biblScope>
>>>>>         </monogr>
>>>>> </biblStruct>
>>>>>
>>>>> --Kevin
>>>>>
>>>>> On 11/2/2012 7:02 AM, Lou Burnard wrote:
>>>>>> Tootling across france on the train yesterday I started trying to deal
>>>>>> with http://purl.org/tei/FR/3555190...
>>>>>>
>>>>>> The part about the scope of biblscope was fairly easy to add, as was
>>>>>> guidance on usage of biblScope. But I hit a problem with the second
>>>>>> part, where it says that biblScope doesn't belong inside<imprint>   --
>>>>>> the logic behind that desire is impeccable, but it messes up an awful
>>>>>> lot of out current practice.
>>>>>>
>>>>>> Consider the following:
>>>>>>
>>>>>> <biblStruct>
>>>>>> <analytic>
>>>>>> <author>Chesnutt, David</author>
>>>>>> <title>Historical Editions in the States</title>
>>>>>> </analytic>
>>>>>> <monogr>
>>>>>> <title level="j">Computers and the Humanities</title>
>>>>>> <imprint>
>>>>>> <biblScope>25.6</biblScope>
>>>>>> <date when="1991-12">(December, 1991):</date>
>>>>>> <biblScope>377?380</biblScope>
>>>>>> </imprint>
>>>>>> </monogr>
>>>>>> </biblStruct>
>>>>>>
>>>>>> which is a fairly common pattern in P5 (and appears as the canonical
>>>>>> example for<imprint>)
>>>>>>
>>>>>> If, following FR 3555190, we think<biblStruct>   has no place within
>>>>>> <imprint>, how should
>>>>>> this, and many similar cases, be tagged?
>>>>>>
>>>>>> One possibility might be
>>>>>>
>>>>>> <monogr>
>>>>>> <title level="j">Computers and the Humanities</title>
>>>>>> <biblScope>25.6</biblScope>
>>>>>> <biblScope>377?380</biblScope>
>>>>>> <imprint>
>>>>>> <date when="1991-12">(December, 1991):</date>
>>>>>> </imprint>
>>>>>> </monogr>
>>>>>>
>>>>>> Another might be
>>>>>>
>>>>>> <monogr>
>>>>>> <title level="j">Computers and the Humanities</title>
>>>>>> <biblScope>25.6</biblScope>
>>>>>> <biblScope>377?380</biblScope>
>>>>>> <biblScope type="date">(December, 1991)</biblScope>
>>>>>> </imprint>
>>>>>> </monogr>
>>>>>>
>>>>>> or perhaps better
>>>>>>
>>>>>> <biblScope><date when="1991-12">(December, 1991)</date></biblScope>
>>>>>>
>>>>>>
>>>>>> Another might be to tweak the content model so that
>>>>>> model.dateLike is permitted outside<imprint>   and alongside<biblScope>
>>>>>>
>>>>>> And another might be to reconsider the decision to remove<biblScope>
>>>>>> from within<imprint>
>>>>>>
>>>>>> Any ideas? Everyone braced for the rush of complaints?
>>>>>>
>>>>
>>
>

From kevin.s.hawkins at ultraslavonic.info  Sat Nov  3 09:53:35 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Sat, 03 Nov 2012 09:53:35 -0400
Subject: [tei-council] biblscope and imprint
In-Reply-To: <509501D2.4050309@retired.ox.ac.uk>
References: <5093A831.7080901@retired.ox.ac.uk>	<5093D8C8.6090209@ultraslavonic.info>
	<5093DDC7.1050504@kcl.ac.uk> <5093E2BB.6010106@ultraslavonic.info>
	<50940D9A.7030007@retired.ox.ac.uk>
	<50941DCD.9070406@retired.ox.ac.uk>
	<50947E23.6020703@ultraslavonic.info>
	<509501D2.4050309@retired.ox.ac.uk>
Message-ID: <509521DF.4080600@ultraslavonic.info>

On 11/3/12 7:36 AM, Lou Burnard wrote:
> On 03/11/12 02:14, Kevin Hawkins wrote:
>
>>> There is also the rather nasty Thaller example in section #COBICOL which
>>> contains an analytic, followed by two monogrs. The article in question
>>> was published twice, once in a journal and once as a free standing
>>> monograph. If we put the page numbers for the journal publication inside
>>> the analytic, as Kevin suggests, how do we know that they are not
>>> relevant to the second <monogr>?
>>
>> An excellent question.  Gabby and I didn't consider this.  I'm not sure
>> what to suggest.  :(
>>
>
> Hmm. That's a bit of show stopper! See my note on the ticket...
>
> http://purl.org/tei/FR/3555190

Indeed.  Perhaps we should set up sort of pointing mechanism?  Lou made 
a comment that the markup was getting awfully verbose and therefore 
might feel that we don't need to make it more verbose, but I don't see 
how we can avoid it if we want to allow for structured citations and yet 
make them machine-readable.

From lou.burnard at retired.ox.ac.uk  Sat Nov  3 19:20:20 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Sat, 03 Nov 2012 23:20:20 +0000
Subject: [tei-council] biblscope and imprint
In-Reply-To: <50952166.2060305@ultraslavonic.info>
References: <5093A831.7080901@retired.ox.ac.uk>	<5093D8C8.6090209@ultraslavonic.info>
	<5093DDC7.1050504@kcl.ac.uk> <5093E2BB.6010106@ultraslavonic.info>
	<50940D9A.7030007@retired.ox.ac.uk>
	<5095017A.8060903@retired.ox.ac.uk>
	<50952166.2060305@ultraslavonic.info>
Message-ID: <5095A6B4.2080307@retired.ox.ac.uk>

I've now checked in a revised CO which I think addresses these concerns, 
but am leaving the ticket open till Gabby has also had a chance to check 
this out.



On 03/11/12 13:51, Kevin Hawkins wrote:
> Ugh, Gabby and I both misremembered the proposal at
> http://purl.org/tei/FR/3555190 .  Lou is right that according to that
> proposal, there is never a <biblScope> in <analytic>, so the Chestnutt
> citation encoded according to the proposal would be:
>
> <biblStruct>
>     <analytic>
>       <author>Chesnutt, David</author>
>       <title>Historical Editions in the States</title>
>     </analytic>
>     <monogr>
>       <title level="j">Computers and the Humanities</title>
>       <imprint>
>         <date when="1991-12">(December, 1991):</date>
>       </imprint>
>       <biblScope type="vol">25</biblScope>
>       <biblScope type="issue">6</biblScope>
>       <biblScope type="pp">377?380</biblScope>
>     </monogr>
> </biblStruct>
>
> (which is more or less how I first wrote it below).
>
> On 11/3/12 7:35 AM, Lou Burnard wrote:
>> Looking at this suggestion again: surely it cannot ever be right to put
>> a <biblScope> within an <analytic> ?
>>
>> See further my comment on the ticket -- specifically
>>
>> "I think the sentence "Each <biblScope> describes where (within its
>> parent element) to find the thing in the previous level" is correct, but
>> only if you understand the word "level" as "preceding sibling of a
>> different bibliographic level"
>>
>> Hence the pagination biblScope ought to go within the monogr, not within
>> the analytic. This also makes sense if the same article appears in two
>> different monogrs, possibly with different pagination.
>>
>>
>>
>> On 02/11/12 18:14, Lou Burnard wrote:
>>> On 02/11/12 15:11, Kevin Hawkins wrote:
>>>> Gabby's right. I was focusing on placement of <biblScope> in relation to
>>>> <imprint>.  So Lou's citation (from the Guidelines) would in fact be:
>>>>
>>>> <biblStruct>
>>>>        <analytic>
>>>>          <author>Chesnutt, David</author>
>>>>          <title>Historical Editions in the States</title>
>>>>          <biblScope type="pp">377?380</biblScope>
>>>>        </analytic>
>>>>        <monogr>
>>>>          <title level="j">Computers and the Humanities</title>
>>>>          <imprint>
>>>>            <date when="1991-12">(December, 1991):</date>
>>>>          </imprint>
>>>>          <biblScope type="vol">25</biblScope>
>>>>          <biblScope type="issue">6</biblScope>
>>>>        </monogr>
>>>> </biblStruct>
>>>>
>>>> On 11/2/2012 10:50 AM, Gabriel Bodard wrote:
>>>>> Is that what we proposed?
>>>>>
>>>>> I thought I remembered we had suggested to put the biblScope in the
>>>>> element whose scope is being defined by it, so<biblScope type="pp">
>>>>> goes in<analytic>  because the article is only pages 377-380 of the
>>>>> volume in question, and<biblScope type="issue">  goes in<monogr>
>>>>> because this volume is only issue 25.6 of the journal....
>>>>>
>>>>> But looking at this stuff I find myself more and more agreeing with
>>>>> Martin that biblStruct was never a good idea. ;-)
>>>>>
>>>>> G
>>>>>
>>>>> On 2012-11-02 14:29, Kevin Hawkins wrote:
>>>>>> The ticket proposes putting<biblScope>s after the<imprint>  element
>>>>>> when its present.  So your example would now be encoded as:
>>>>>>
>>>>>> <biblStruct>
>>>>>>          <analytic>
>>>>>>            <author>Chesnutt, David</author>
>>>>>>            <title>Historical Editions in the States</title>
>>>>>>          </analytic>
>>>>>>          <monogr>
>>>>>>            <title level="j">Computers and the Humanities</title>
>>>>>>            <imprint>
>>>>>>              <date when="1991-12">(December, 1991):</date>
>>>>>>            </imprint>
>>>>>>            <biblScope>25.6</biblScope>
>>>>>>            <biblScope>377?380</biblScope>
>>>>>>          </monogr>
>>>>>> </biblStruct>
>>>>>>
>>>>>> --Kevin
>>>>>>
>>>>>> On 11/2/2012 7:02 AM, Lou Burnard wrote:
>>>>>>> Tootling across france on the train yesterday I started trying to deal
>>>>>>> with http://purl.org/tei/FR/3555190...
>>>>>>>
>>>>>>> The part about the scope of biblscope was fairly easy to add, as was
>>>>>>> guidance on usage of biblScope. But I hit a problem with the second
>>>>>>> part, where it says that biblScope doesn't belong inside<imprint>   --
>>>>>>> the logic behind that desire is impeccable, but it messes up an awful
>>>>>>> lot of out current practice.
>>>>>>>
>>>>>>> Consider the following:
>>>>>>>
>>>>>>> <biblStruct>
>>>>>>> <analytic>
>>>>>>> <author>Chesnutt, David</author>
>>>>>>> <title>Historical Editions in the States</title>
>>>>>>> </analytic>
>>>>>>> <monogr>
>>>>>>> <title level="j">Computers and the Humanities</title>
>>>>>>> <imprint>
>>>>>>> <biblScope>25.6</biblScope>
>>>>>>> <date when="1991-12">(December, 1991):</date>
>>>>>>> <biblScope>377?380</biblScope>
>>>>>>> </imprint>
>>>>>>> </monogr>
>>>>>>> </biblStruct>
>>>>>>>
>>>>>>> which is a fairly common pattern in P5 (and appears as the canonical
>>>>>>> example for<imprint>)
>>>>>>>
>>>>>>> If, following FR 3555190, we think<biblStruct>   has no place within
>>>>>>> <imprint>, how should
>>>>>>> this, and many similar cases, be tagged?
>>>>>>>
>>>>>>> One possibility might be
>>>>>>>
>>>>>>> <monogr>
>>>>>>> <title level="j">Computers and the Humanities</title>
>>>>>>> <biblScope>25.6</biblScope>
>>>>>>> <biblScope>377?380</biblScope>
>>>>>>> <imprint>
>>>>>>> <date when="1991-12">(December, 1991):</date>
>>>>>>> </imprint>
>>>>>>> </monogr>
>>>>>>>
>>>>>>> Another might be
>>>>>>>
>>>>>>> <monogr>
>>>>>>> <title level="j">Computers and the Humanities</title>
>>>>>>> <biblScope>25.6</biblScope>
>>>>>>> <biblScope>377?380</biblScope>
>>>>>>> <biblScope type="date">(December, 1991)</biblScope>
>>>>>>> </imprint>
>>>>>>> </monogr>
>>>>>>>
>>>>>>> or perhaps better
>>>>>>>
>>>>>>> <biblScope><date when="1991-12">(December, 1991)</date></biblScope>
>>>>>>>
>>>>>>>
>>>>>>> Another might be to tweak the content model so that
>>>>>>> model.dateLike is permitted outside<imprint>   and alongside<biblScope>
>>>>>>>
>>>>>>> And another might be to reconsider the decision to remove<biblScope>
>>>>>>> from within<imprint>
>>>>>>>
>>>>>>> Any ideas? Everyone braced for the rush of complaints?
>>>>>>>


From kevin.s.hawkins at ultraslavonic.info  Sat Nov  3 21:07:04 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Sat, 03 Nov 2012 21:07:04 -0400
Subject: [tei-council] biblscope and imprint
In-Reply-To: <5095A6B4.2080307@retired.ox.ac.uk>
References: <5093A831.7080901@retired.ox.ac.uk>	<5093D8C8.6090209@ultraslavonic.info>
	<5093DDC7.1050504@kcl.ac.uk> <5093E2BB.6010106@ultraslavonic.info>
	<50940D9A.7030007@retired.ox.ac.uk>
	<5095017A.8060903@retired.ox.ac.uk>
	<50952166.2060305@ultraslavonic.info>
	<5095A6B4.2080307@retired.ox.ac.uk>
Message-ID: <5095BFB8.2050101@ultraslavonic.info>

I've looked over:

http://tei.svn.sourceforge.net/viewvc/tei/trunk/P5/Source/Guidelines/en/CO-CoreElements.xml?r1=11111&r2=11110&pathrev=11111

and it looks good to me, though I agree that we should wait on Gabby. 
Lou, you might also post a comment on the ticket for the benefit of John 
McCaskey and Laurent, who may be following this ticket's progress.

Lou added an XML comment in the Guidelines (but didn't we agree in Paris 
to stop using these?) at:

http://tei.svn.sourceforge.net/viewvc/tei/trunk/P5/Source/Guidelines/en/CO-CoreElements.xml?r1=11111&r2=11110&pathrev=11111

asking whether "ru" is the correct value for @xml:lang for Russian 
written in roman letters.  BCP 47 does not say that a script subtag must 
be used if a language is written in a script that is not the usual one, 
so I believe use of "ru" is correct though it underspecifies.  If you 
like, you could change to "ru-Latn".

--Kevin

On 11/3/12 7:20 PM, Lou Burnard wrote:
> I've now checked in a revised CO which I think addresses these concerns,
> but am leaving the ticket open till Gabby has also had a chance to check
> this out.
>
>
>
> On 03/11/12 13:51, Kevin Hawkins wrote:
>> Ugh, Gabby and I both misremembered the proposal at
>> http://purl.org/tei/FR/3555190 .  Lou is right that according to that
>> proposal, there is never a <biblScope> in <analytic>, so the Chestnutt
>> citation encoded according to the proposal would be:
>>
>> <biblStruct>
>>      <analytic>
>>        <author>Chesnutt, David</author>
>>        <title>Historical Editions in the States</title>
>>      </analytic>
>>      <monogr>
>>        <title level="j">Computers and the Humanities</title>
>>        <imprint>
>>          <date when="1991-12">(December, 1991):</date>
>>        </imprint>
>>        <biblScope type="vol">25</biblScope>
>>        <biblScope type="issue">6</biblScope>
>>        <biblScope type="pp">377?380</biblScope>
>>      </monogr>
>> </biblStruct>
>>
>> (which is more or less how I first wrote it below).
>>
>> On 11/3/12 7:35 AM, Lou Burnard wrote:
>>> Looking at this suggestion again: surely it cannot ever be right to put
>>> a <biblScope> within an <analytic> ?
>>>
>>> See further my comment on the ticket -- specifically
>>>
>>> "I think the sentence "Each <biblScope> describes where (within its
>>> parent element) to find the thing in the previous level" is correct, but
>>> only if you understand the word "level" as "preceding sibling of a
>>> different bibliographic level"
>>>
>>> Hence the pagination biblScope ought to go within the monogr, not within
>>> the analytic. This also makes sense if the same article appears in two
>>> different monogrs, possibly with different pagination.
>>>
>>>
>>>
>>> On 02/11/12 18:14, Lou Burnard wrote:
>>>> On 02/11/12 15:11, Kevin Hawkins wrote:
>>>>> Gabby's right. I was focusing on placement of <biblScope> in relation to
>>>>> <imprint>.  So Lou's citation (from the Guidelines) would in fact be:
>>>>>
>>>>> <biblStruct>
>>>>>         <analytic>
>>>>>           <author>Chesnutt, David</author>
>>>>>           <title>Historical Editions in the States</title>
>>>>>           <biblScope type="pp">377?380</biblScope>
>>>>>         </analytic>
>>>>>         <monogr>
>>>>>           <title level="j">Computers and the Humanities</title>
>>>>>           <imprint>
>>>>>             <date when="1991-12">(December, 1991):</date>
>>>>>           </imprint>
>>>>>           <biblScope type="vol">25</biblScope>
>>>>>           <biblScope type="issue">6</biblScope>
>>>>>         </monogr>
>>>>> </biblStruct>
>>>>>
>>>>> On 11/2/2012 10:50 AM, Gabriel Bodard wrote:
>>>>>> Is that what we proposed?
>>>>>>
>>>>>> I thought I remembered we had suggested to put the biblScope in the
>>>>>> element whose scope is being defined by it, so<biblScope type="pp">
>>>>>> goes in<analytic>  because the article is only pages 377-380 of the
>>>>>> volume in question, and<biblScope type="issue">  goes in<monogr>
>>>>>> because this volume is only issue 25.6 of the journal....
>>>>>>
>>>>>> But looking at this stuff I find myself more and more agreeing with
>>>>>> Martin that biblStruct was never a good idea. ;-)
>>>>>>
>>>>>> G
>>>>>>
>>>>>> On 2012-11-02 14:29, Kevin Hawkins wrote:
>>>>>>> The ticket proposes putting<biblScope>s after the<imprint>  element
>>>>>>> when its present.  So your example would now be encoded as:
>>>>>>>
>>>>>>> <biblStruct>
>>>>>>>           <analytic>
>>>>>>>             <author>Chesnutt, David</author>
>>>>>>>             <title>Historical Editions in the States</title>
>>>>>>>           </analytic>
>>>>>>>           <monogr>
>>>>>>>             <title level="j">Computers and the Humanities</title>
>>>>>>>             <imprint>
>>>>>>>               <date when="1991-12">(December, 1991):</date>
>>>>>>>             </imprint>
>>>>>>>             <biblScope>25.6</biblScope>
>>>>>>>             <biblScope>377?380</biblScope>
>>>>>>>           </monogr>
>>>>>>> </biblStruct>
>>>>>>>
>>>>>>> --Kevin
>>>>>>>
>>>>>>> On 11/2/2012 7:02 AM, Lou Burnard wrote:
>>>>>>>> Tootling across france on the train yesterday I started trying to deal
>>>>>>>> with http://purl.org/tei/FR/3555190...
>>>>>>>>
>>>>>>>> The part about the scope of biblscope was fairly easy to add, as was
>>>>>>>> guidance on usage of biblScope. But I hit a problem with the second
>>>>>>>> part, where it says that biblScope doesn't belong inside<imprint>   --
>>>>>>>> the logic behind that desire is impeccable, but it messes up an awful
>>>>>>>> lot of out current practice.
>>>>>>>>
>>>>>>>> Consider the following:
>>>>>>>>
>>>>>>>> <biblStruct>
>>>>>>>> <analytic>
>>>>>>>> <author>Chesnutt, David</author>
>>>>>>>> <title>Historical Editions in the States</title>
>>>>>>>> </analytic>
>>>>>>>> <monogr>
>>>>>>>> <title level="j">Computers and the Humanities</title>
>>>>>>>> <imprint>
>>>>>>>> <biblScope>25.6</biblScope>
>>>>>>>> <date when="1991-12">(December, 1991):</date>
>>>>>>>> <biblScope>377?380</biblScope>
>>>>>>>> </imprint>
>>>>>>>> </monogr>
>>>>>>>> </biblStruct>
>>>>>>>>
>>>>>>>> which is a fairly common pattern in P5 (and appears as the canonical
>>>>>>>> example for<imprint>)
>>>>>>>>
>>>>>>>> If, following FR 3555190, we think<biblStruct>   has no place within
>>>>>>>> <imprint>, how should
>>>>>>>> this, and many similar cases, be tagged?
>>>>>>>>
>>>>>>>> One possibility might be
>>>>>>>>
>>>>>>>> <monogr>
>>>>>>>> <title level="j">Computers and the Humanities</title>
>>>>>>>> <biblScope>25.6</biblScope>
>>>>>>>> <biblScope>377?380</biblScope>
>>>>>>>> <imprint>
>>>>>>>> <date when="1991-12">(December, 1991):</date>
>>>>>>>> </imprint>
>>>>>>>> </monogr>
>>>>>>>>
>>>>>>>> Another might be
>>>>>>>>
>>>>>>>> <monogr>
>>>>>>>> <title level="j">Computers and the Humanities</title>
>>>>>>>> <biblScope>25.6</biblScope>
>>>>>>>> <biblScope>377?380</biblScope>
>>>>>>>> <biblScope type="date">(December, 1991)</biblScope>
>>>>>>>> </imprint>
>>>>>>>> </monogr>
>>>>>>>>
>>>>>>>> or perhaps better
>>>>>>>>
>>>>>>>> <biblScope><date when="1991-12">(December, 1991)</date></biblScope>
>>>>>>>>
>>>>>>>>
>>>>>>>> Another might be to tweak the content model so that
>>>>>>>> model.dateLike is permitted outside<imprint>   and alongside<biblScope>
>>>>>>>>
>>>>>>>> And another might be to reconsider the decision to remove<biblScope>
>>>>>>>> from within<imprint>
>>>>>>>>
>>>>>>>> Any ideas? Everyone braced for the rush of complaints?
>>>>>>>>
>

From mholmes at uvic.ca  Sat Nov  3 21:13:05 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Sat, 3 Nov 2012 18:13:05 -0700
Subject: [tei-council] biblscope and imprint
In-Reply-To: <5095BFB8.2050101@ultraslavonic.info>
References: <5093A831.7080901@retired.ox.ac.uk>
	<5093D8C8.6090209@ultraslavonic.info>	<5093DDC7.1050504@kcl.ac.uk>
	<5093E2BB.6010106@ultraslavonic.info>	<50940D9A.7030007@retired.ox.ac.uk>
	<5095017A.8060903@retired.ox.ac.uk>	<50952166.2060305@ultraslavonic.info>
	<5095A6B4.2080307@retired.ox.ac.uk>
	<5095BFB8.2050101@ultraslavonic.info>
Message-ID: <5095C121.1010600@uvic.ca>

>
> Lou added an XML comment in the Guidelines (but didn't we agree in Paris
> to stop using these?)

We didn't say we'd stop using them, IIRC; we said we would sign and date 
them, so it would be easier going forward to determine whether comments 
were no longer of interest or relevance, and could be deleted.

So I think Lou should sign and date that comment. To answer his 
question, I think the language subtag should be:

ru-Latn

for Russian in Latin script.

Cheers,
Martin

On 12-11-03 06:07 PM, Kevin Hawkins wrote:
> I've looked over:
>
> http://tei.svn.sourceforge.net/viewvc/tei/trunk/P5/Source/Guidelines/en/CO-CoreElements.xml?r1=11111&r2=11110&pathrev=11111
>
> and it looks good to me, though I agree that we should wait on Gabby.
> Lou, you might also post a comment on the ticket for the benefit of John
> McCaskey and Laurent, who may be following this ticket's progress.
>
> Lou added an XML comment in the Guidelines (but didn't we agree in Paris
> to stop using these?) at:
>
> http://tei.svn.sourceforge.net/viewvc/tei/trunk/P5/Source/Guidelines/en/CO-CoreElements.xml?r1=11111&r2=11110&pathrev=11111
>
> asking whether "ru" is the correct value for @xml:lang for Russian
> written in roman letters.  BCP 47 does not say that a script subtag must
> be used if a language is written in a script that is not the usual one,
> so I believe use of "ru" is correct though it underspecifies.  If you
> like, you could change to "ru-Latn".
>
> --Kevin
>
> On 11/3/12 7:20 PM, Lou Burnard wrote:
>> I've now checked in a revised CO which I think addresses these concerns,
>> but am leaving the ticket open till Gabby has also had a chance to check
>> this out.
>>
>>
>>
>> On 03/11/12 13:51, Kevin Hawkins wrote:
>>> Ugh, Gabby and I both misremembered the proposal at
>>> http://purl.org/tei/FR/3555190 .  Lou is right that according to that
>>> proposal, there is never a <biblScope> in <analytic>, so the Chestnutt
>>> citation encoded according to the proposal would be:
>>>
>>> <biblStruct>
>>>       <analytic>
>>>         <author>Chesnutt, David</author>
>>>         <title>Historical Editions in the States</title>
>>>       </analytic>
>>>       <monogr>
>>>         <title level="j">Computers and the Humanities</title>
>>>         <imprint>
>>>           <date when="1991-12">(December, 1991):</date>
>>>         </imprint>
>>>         <biblScope type="vol">25</biblScope>
>>>         <biblScope type="issue">6</biblScope>
>>>         <biblScope type="pp">377?380</biblScope>
>>>       </monogr>
>>> </biblStruct>
>>>
>>> (which is more or less how I first wrote it below).
>>>
>>> On 11/3/12 7:35 AM, Lou Burnard wrote:
>>>> Looking at this suggestion again: surely it cannot ever be right to put
>>>> a <biblScope> within an <analytic> ?
>>>>
>>>> See further my comment on the ticket -- specifically
>>>>
>>>> "I think the sentence "Each <biblScope> describes where (within its
>>>> parent element) to find the thing in the previous level" is correct, but
>>>> only if you understand the word "level" as "preceding sibling of a
>>>> different bibliographic level"
>>>>
>>>> Hence the pagination biblScope ought to go within the monogr, not within
>>>> the analytic. This also makes sense if the same article appears in two
>>>> different monogrs, possibly with different pagination.
>>>>
>>>>
>>>>
>>>> On 02/11/12 18:14, Lou Burnard wrote:
>>>>> On 02/11/12 15:11, Kevin Hawkins wrote:
>>>>>> Gabby's right. I was focusing on placement of <biblScope> in relation to
>>>>>> <imprint>.  So Lou's citation (from the Guidelines) would in fact be:
>>>>>>
>>>>>> <biblStruct>
>>>>>>          <analytic>
>>>>>>            <author>Chesnutt, David</author>
>>>>>>            <title>Historical Editions in the States</title>
>>>>>>            <biblScope type="pp">377?380</biblScope>
>>>>>>          </analytic>
>>>>>>          <monogr>
>>>>>>            <title level="j">Computers and the Humanities</title>
>>>>>>            <imprint>
>>>>>>              <date when="1991-12">(December, 1991):</date>
>>>>>>            </imprint>
>>>>>>            <biblScope type="vol">25</biblScope>
>>>>>>            <biblScope type="issue">6</biblScope>
>>>>>>          </monogr>
>>>>>> </biblStruct>
>>>>>>
>>>>>> On 11/2/2012 10:50 AM, Gabriel Bodard wrote:
>>>>>>> Is that what we proposed?
>>>>>>>
>>>>>>> I thought I remembered we had suggested to put the biblScope in the
>>>>>>> element whose scope is being defined by it, so<biblScope type="pp">
>>>>>>> goes in<analytic>  because the article is only pages 377-380 of the
>>>>>>> volume in question, and<biblScope type="issue">  goes in<monogr>
>>>>>>> because this volume is only issue 25.6 of the journal....
>>>>>>>
>>>>>>> But looking at this stuff I find myself more and more agreeing with
>>>>>>> Martin that biblStruct was never a good idea. ;-)
>>>>>>>
>>>>>>> G
>>>>>>>
>>>>>>> On 2012-11-02 14:29, Kevin Hawkins wrote:
>>>>>>>> The ticket proposes putting<biblScope>s after the<imprint>  element
>>>>>>>> when its present.  So your example would now be encoded as:
>>>>>>>>
>>>>>>>> <biblStruct>
>>>>>>>>            <analytic>
>>>>>>>>              <author>Chesnutt, David</author>
>>>>>>>>              <title>Historical Editions in the States</title>
>>>>>>>>            </analytic>
>>>>>>>>            <monogr>
>>>>>>>>              <title level="j">Computers and the Humanities</title>
>>>>>>>>              <imprint>
>>>>>>>>                <date when="1991-12">(December, 1991):</date>
>>>>>>>>              </imprint>
>>>>>>>>              <biblScope>25.6</biblScope>
>>>>>>>>              <biblScope>377?380</biblScope>
>>>>>>>>            </monogr>
>>>>>>>> </biblStruct>
>>>>>>>>
>>>>>>>> --Kevin
>>>>>>>>
>>>>>>>> On 11/2/2012 7:02 AM, Lou Burnard wrote:
>>>>>>>>> Tootling across france on the train yesterday I started trying to deal
>>>>>>>>> with http://purl.org/tei/FR/3555190...
>>>>>>>>>
>>>>>>>>> The part about the scope of biblscope was fairly easy to add, as was
>>>>>>>>> guidance on usage of biblScope. But I hit a problem with the second
>>>>>>>>> part, where it says that biblScope doesn't belong inside<imprint>   --
>>>>>>>>> the logic behind that desire is impeccable, but it messes up an awful
>>>>>>>>> lot of out current practice.
>>>>>>>>>
>>>>>>>>> Consider the following:
>>>>>>>>>
>>>>>>>>> <biblStruct>
>>>>>>>>> <analytic>
>>>>>>>>> <author>Chesnutt, David</author>
>>>>>>>>> <title>Historical Editions in the States</title>
>>>>>>>>> </analytic>
>>>>>>>>> <monogr>
>>>>>>>>> <title level="j">Computers and the Humanities</title>
>>>>>>>>> <imprint>
>>>>>>>>> <biblScope>25.6</biblScope>
>>>>>>>>> <date when="1991-12">(December, 1991):</date>
>>>>>>>>> <biblScope>377?380</biblScope>
>>>>>>>>> </imprint>
>>>>>>>>> </monogr>
>>>>>>>>> </biblStruct>
>>>>>>>>>
>>>>>>>>> which is a fairly common pattern in P5 (and appears as the canonical
>>>>>>>>> example for<imprint>)
>>>>>>>>>
>>>>>>>>> If, following FR 3555190, we think<biblStruct>   has no place within
>>>>>>>>> <imprint>, how should
>>>>>>>>> this, and many similar cases, be tagged?
>>>>>>>>>
>>>>>>>>> One possibility might be
>>>>>>>>>
>>>>>>>>> <monogr>
>>>>>>>>> <title level="j">Computers and the Humanities</title>
>>>>>>>>> <biblScope>25.6</biblScope>
>>>>>>>>> <biblScope>377?380</biblScope>
>>>>>>>>> <imprint>
>>>>>>>>> <date when="1991-12">(December, 1991):</date>
>>>>>>>>> </imprint>
>>>>>>>>> </monogr>
>>>>>>>>>
>>>>>>>>> Another might be
>>>>>>>>>
>>>>>>>>> <monogr>
>>>>>>>>> <title level="j">Computers and the Humanities</title>
>>>>>>>>> <biblScope>25.6</biblScope>
>>>>>>>>> <biblScope>377?380</biblScope>
>>>>>>>>> <biblScope type="date">(December, 1991)</biblScope>
>>>>>>>>> </imprint>
>>>>>>>>> </monogr>
>>>>>>>>>
>>>>>>>>> or perhaps better
>>>>>>>>>
>>>>>>>>> <biblScope><date when="1991-12">(December, 1991)</date></biblScope>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Another might be to tweak the content model so that
>>>>>>>>> model.dateLike is permitted outside<imprint>   and alongside<biblScope>
>>>>>>>>>
>>>>>>>>> And another might be to reconsider the decision to remove<biblScope>
>>>>>>>>> from within<imprint>
>>>>>>>>>
>>>>>>>>> Any ideas? Everyone braced for the rush of complaints?
>>>>>>>>>
>>

From mholmes at uvic.ca  Sat Nov  3 22:19:41 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Sat, 3 Nov 2012 19:19:41 -0700
Subject: [tei-council] Uploading files to the WIKI
Message-ID: <5095D0BD.5090100@uvic.ca>

Hi all,

I'm working on my Prefix Definition Proposal on the wiki, and I've 
drafted a new section of the Guidelines that I wanted to include as part 
of the proposal. This is a regular TEI file, including a div which could 
be inserted into the SA chapter. It's obviously easier to write it 
directly in TEI, and then insert it into the chapter if and when it gets 
approval, than to draft it in a word-processor and then have to tag it 
up afterwards.

I wanted to upload this to the wiki so people could vet it, but when I 
tried to upload it as an XML file, the wiki said:

"This file contains HTML or script code that may be erroneously 
interpreted by a web browser."

So I tried zipping it up (as I've done before with a script file). This 
time, it said:

"Files of the MIME type "application/zip" are not allowed to be uploaded."

But the wiki upload page also says:

"Permitted file types: png, gif, jpg, jpeg, ogg, zip, xsl, xml, dtd, 
odd, rnc, rng, txt, pdf."

In other words, it's supposed to be able to accept both XML and zip 
files, but it won't. Someone or something must have changed the settings 
since I last uploaded a zip file last year, but not changed the text of 
the page which explains the limitations.

I think a TEI wiki that doesn't allow us to upload XML files is a bit 
ridiculous. Could we get this changed?

Cheers,
Martin

From bansp at o2.pl  Sun Nov  4 02:31:25 2012
From: bansp at o2.pl (=?ISO-8859-2?Q?Piotr_Ba=F1ski?=)
Date: Sun, 04 Nov 2012 08:31:25 +0100
Subject: [tei-council] Uploading files to the WIKI
In-Reply-To: <5095D0BD.5090100@uvic.ca>
References: <5095D0BD.5090100@uvic.ca>
Message-ID: <509619CD.5080202@o2.pl>

Hi Martin,

It might have been inadvertently changed during the upgrade of the wiki
software (veeery useful, it fixed a few problems, spambots among
others). David has done a great wizarding job on that, hopefully he can
help with the file upload issue as well.

  P.

On 04/11/12 03:19, Martin Holmes wrote:
> Hi all,
> 
> I'm working on my Prefix Definition Proposal on the wiki, and I've 
> drafted a new section of the Guidelines that I wanted to include as part 
> of the proposal. This is a regular TEI file, including a div which could 
> be inserted into the SA chapter. It's obviously easier to write it 
> directly in TEI, and then insert it into the chapter if and when it gets 
> approval, than to draft it in a word-processor and then have to tag it 
> up afterwards.
> 
> I wanted to upload this to the wiki so people could vet it, but when I 
> tried to upload it as an XML file, the wiki said:
> 
> "This file contains HTML or script code that may be erroneously 
> interpreted by a web browser."
> 
> So I tried zipping it up (as I've done before with a script file). This 
> time, it said:
> 
> "Files of the MIME type "application/zip" are not allowed to be uploaded."
> 
> But the wiki upload page also says:
> 
> "Permitted file types: png, gif, jpg, jpeg, ogg, zip, xsl, xml, dtd, 
> odd, rnc, rng, txt, pdf."
> 
> In other words, it's supposed to be able to accept both XML and zip 
> files, but it won't. Someone or something must have changed the settings 
> since I last uploaded a zip file last year, but not changed the text of 
> the page which explains the limitations.
> 
> I think a TEI wiki that doesn't allow us to upload XML files is a bit 
> ridiculous. Could we get this changed?
> 
> Cheers,
> Martin
> 


From lou.burnard at retired.ox.ac.uk  Sun Nov  4 07:04:00 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Sun, 04 Nov 2012 12:04:00 +0000
Subject: [tei-council] Uploading files to the WIKI
In-Reply-To: <5095D0BD.5090100@uvic.ca>
References: <5095D0BD.5090100@uvic.ca>
Message-ID: <509659B0.3040209@retired.ox.ac.uk>

On 04/11/12 02:19, Martin Holmes wrote:

>
> I think a TEI wiki that doesn't allow us to upload XML files is a bit
> ridiculous.

+1 from me. One of the reasons I am reluctant to mess with it.

Could we get this changed?

Preferably to import and export in some simple TEI subset?




From lou.burnard at retired.ox.ac.uk  Sun Nov  4 07:52:52 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Sun, 04 Nov 2012 12:52:52 +0000
Subject: [tei-council] biblscope and imprint
In-Reply-To: <5095C121.1010600@uvic.ca>
References: <5093A831.7080901@retired.ox.ac.uk>
	<5093D8C8.6090209@ultraslavonic.info>	<5093DDC7.1050504@kcl.ac.uk>
	<5093E2BB.6010106@ultraslavonic.info>	<50940D9A.7030007@retired.ox.ac.uk>
	<5095017A.8060903@retired.ox.ac.uk>	<50952166.2060305@ultraslavonic.info>
	<5095A6B4.2080307@retired.ox.ac.uk>
	<5095BFB8.2050101@ultraslavonic.info> <5095C121.1010600@uvic.ca>
Message-ID: <50966524.5010708@retired.ox.ac.uk>

The comment was just a note to myself while I was going through that 
section and I will remove it before closing the ticket. However it does 
raise some interesting issues, which I have now had the leisure to 
investigate further.

Firstly the comment that using "ru" for Russian transliterated in Roman 
characters is simply "underspecified" seems to me rather to miss the 
point. If I see something in a Unicode document which says it has 
xml:lang="ru" I expect to see proper Russian Unicode characters.

Secondly, even if I am prepared to accept Romanized versions of those 
characters and figure out for myself what the Russian should have been, 
this is not entirely easy. There are several different (Wikipedia lists 
ten) possible Romanization schemes, which vary quite considerably. In 
some, for example, the sequence "ye" stands for the Russian letter that 
looks like a Roman "e"; in others this character is represented by "e", 
unless it is iotated by a preceding soft sign. So generating a correct 
Cyrillic version of this citation isn't easy, and neither is deciding 
which scheme we're dealing with here!

Thirdly, this particular example is actually taken verbatim from a 
rather elderly ISO standard on bibliographic reference (ISO 690, 1987). 
  Hence we probably should not mess with its representation at all. (You 
can see it cited as a example in the Wikipedia entry for ISO_690, 
curiously enough). There is a new version of ISO 690 (from 2010) but I 
don't have 140 swiss francs at my disposal to pay for a PDF download, 
the libraries are all shut, and it's raining anyway ... so I can't see 
whether or not this example has been updated to use what would 
(presumably) be the current recommended transliteration scheme - ISO 9 
(1995).

My guess, but I defer to the Russian expert in our midst, is that this 
uses the now deprecated ISO/R:1968 but without access to the original, 
it's hard to be sure, and without being sure I'd rather not try to 
convert it into proper Russian.

All of which I suppose we can side-step cheerfully, by saying "ru-Latn", 
even though this particular combination isn't actually proposed in 
http://www.iana.org/assignments/language-subtag-registry, and even 
though this won't help anyone who *does* want to see the original title 
as it should have been presented!



   On 04/11/12 01:13, Martin Holmes wrote:
>>
>> Lou added an XML comment in the Guidelines (but didn't we agree in Paris
>> to stop using these?)
>
> We didn't say we'd stop using them, IIRC; we said we would sign and date
> them, so it would be easier going forward to determine whether comments
> were no longer of interest or relevance, and could be deleted.
>
> So I think Lou should sign and date that comment. To answer his
> question, I think the language subtag should be:
>
> ru-Latn
>
> for Russian in Latin script.
>
> Cheers,
> Martin
>
> On 12-11-03 06:07 PM, Kevin Hawkins wrote:
>> I've looked over:
>>
>> http://tei.svn.sourceforge.net/viewvc/tei/trunk/P5/Source/Guidelines/en/CO-CoreElements.xml?r1=11111&r2=11110&pathrev=11111
>>
>> and it looks good to me, though I agree that we should wait on Gabby.
>> Lou, you might also post a comment on the ticket for the benefit of John
>> McCaskey and Laurent, who may be following this ticket's progress.
>>
>> Lou added an XML comment in the Guidelines (but didn't we agree in Paris
>> to stop using these?) at:
>>
>> http://tei.svn.sourceforge.net/viewvc/tei/trunk/P5/Source/Guidelines/en/CO-CoreElements.xml?r1=11111&r2=11110&pathrev=11111
>>
>> asking whether "ru" is the correct value for @xml:lang for Russian
>> written in roman letters.  BCP 47 does not say that a script subtag must
>> be used if a language is written in a script that is not the usual one,
>> so I believe use of "ru" is correct though it underspecifies.  If you
>> like, you could change to "ru-Latn".
>>
>> --Kevin
>>
>> On 11/3/12 7:20 PM, Lou Burnard wrote:
>>> I've now checked in a revised CO which I think addresses these concerns,
>>> but am leaving the ticket open till Gabby has also had a chance to check
>>> this out.
>>>
>>>
>>>
>>> On 03/11/12 13:51, Kevin Hawkins wrote:
>>>> Ugh, Gabby and I both misremembered the proposal at
>>>> http://purl.org/tei/FR/3555190 .  Lou is right that according to that
>>>> proposal, there is never a <biblScope> in <analytic>, so the Chestnutt
>>>> citation encoded according to the proposal would be:
>>>>
>>>> <biblStruct>
>>>>        <analytic>
>>>>          <author>Chesnutt, David</author>
>>>>          <title>Historical Editions in the States</title>
>>>>        </analytic>
>>>>        <monogr>
>>>>          <title level="j">Computers and the Humanities</title>
>>>>          <imprint>
>>>>            <date when="1991-12">(December, 1991):</date>
>>>>          </imprint>
>>>>          <biblScope type="vol">25</biblScope>
>>>>          <biblScope type="issue">6</biblScope>
>>>>          <biblScope type="pp">377?380</biblScope>
>>>>        </monogr>
>>>> </biblStruct>
>>>>
>>>> (which is more or less how I first wrote it below).
>>>>
>>>> On 11/3/12 7:35 AM, Lou Burnard wrote:
>>>>> Looking at this suggestion again: surely it cannot ever be right to put
>>>>> a <biblScope> within an <analytic> ?
>>>>>
>>>>> See further my comment on the ticket -- specifically
>>>>>
>>>>> "I think the sentence "Each <biblScope> describes where (within its
>>>>> parent element) to find the thing in the previous level" is correct, but
>>>>> only if you understand the word "level" as "preceding sibling of a
>>>>> different bibliographic level"
>>>>>
>>>>> Hence the pagination biblScope ought to go within the monogr, not within
>>>>> the analytic. This also makes sense if the same article appears in two
>>>>> different monogrs, possibly with different pagination.
>>>>>
>>>>>
>>>>>
>>>>> On 02/11/12 18:14, Lou Burnard wrote:
>>>>>> On 02/11/12 15:11, Kevin Hawkins wrote:
>>>>>>> Gabby's right. I was focusing on placement of <biblScope> in relation to
>>>>>>> <imprint>.  So Lou's citation (from the Guidelines) would in fact be:
>>>>>>>
>>>>>>> <biblStruct>
>>>>>>>           <analytic>
>>>>>>>             <author>Chesnutt, David</author>
>>>>>>>             <title>Historical Editions in the States</title>
>>>>>>>             <biblScope type="pp">377?380</biblScope>
>>>>>>>           </analytic>
>>>>>>>           <monogr>
>>>>>>>             <title level="j">Computers and the Humanities</title>
>>>>>>>             <imprint>
>>>>>>>               <date when="1991-12">(December, 1991):</date>
>>>>>>>             </imprint>
>>>>>>>             <biblScope type="vol">25</biblScope>
>>>>>>>             <biblScope type="issue">6</biblScope>
>>>>>>>           </monogr>
>>>>>>> </biblStruct>
>>>>>>>
>>>>>>> On 11/2/2012 10:50 AM, Gabriel Bodard wrote:
>>>>>>>> Is that what we proposed?
>>>>>>>>
>>>>>>>> I thought I remembered we had suggested to put the biblScope in the
>>>>>>>> element whose scope is being defined by it, so<biblScope type="pp">
>>>>>>>> goes in<analytic>  because the article is only pages 377-380 of the
>>>>>>>> volume in question, and<biblScope type="issue">  goes in<monogr>
>>>>>>>> because this volume is only issue 25.6 of the journal....
>>>>>>>>
>>>>>>>> But looking at this stuff I find myself more and more agreeing with
>>>>>>>> Martin that biblStruct was never a good idea. ;-)
>>>>>>>>
>>>>>>>> G
>>>>>>>>
>>>>>>>> On 2012-11-02 14:29, Kevin Hawkins wrote:
>>>>>>>>> The ticket proposes putting<biblScope>s after the<imprint>  element
>>>>>>>>> when its present.  So your example would now be encoded as:
>>>>>>>>>
>>>>>>>>> <biblStruct>
>>>>>>>>>             <analytic>
>>>>>>>>>               <author>Chesnutt, David</author>
>>>>>>>>>               <title>Historical Editions in the States</title>
>>>>>>>>>             </analytic>
>>>>>>>>>             <monogr>
>>>>>>>>>               <title level="j">Computers and the Humanities</title>
>>>>>>>>>               <imprint>
>>>>>>>>>                 <date when="1991-12">(December, 1991):</date>
>>>>>>>>>               </imprint>
>>>>>>>>>               <biblScope>25.6</biblScope>
>>>>>>>>>               <biblScope>377?380</biblScope>
>>>>>>>>>             </monogr>
>>>>>>>>> </biblStruct>
>>>>>>>>>
>>>>>>>>> --Kevin
>>>>>>>>>
>>>>>>>>> On 11/2/2012 7:02 AM, Lou Burnard wrote:
>>>>>>>>>> Tootling across france on the train yesterday I started trying to deal
>>>>>>>>>> with http://purl.org/tei/FR/3555190...
>>>>>>>>>>
>>>>>>>>>> The part about the scope of biblscope was fairly easy to add, as was
>>>>>>>>>> guidance on usage of biblScope. But I hit a problem with the second
>>>>>>>>>> part, where it says that biblScope doesn't belong inside<imprint>   --
>>>>>>>>>> the logic behind that desire is impeccable, but it messes up an awful
>>>>>>>>>> lot of out current practice.
>>>>>>>>>>
>>>>>>>>>> Consider the following:
>>>>>>>>>>
>>>>>>>>>> <biblStruct>
>>>>>>>>>> <analytic>
>>>>>>>>>> <author>Chesnutt, David</author>
>>>>>>>>>> <title>Historical Editions in the States</title>
>>>>>>>>>> </analytic>
>>>>>>>>>> <monogr>
>>>>>>>>>> <title level="j">Computers and the Humanities</title>
>>>>>>>>>> <imprint>
>>>>>>>>>> <biblScope>25.6</biblScope>
>>>>>>>>>> <date when="1991-12">(December, 1991):</date>
>>>>>>>>>> <biblScope>377?380</biblScope>
>>>>>>>>>> </imprint>
>>>>>>>>>> </monogr>
>>>>>>>>>> </biblStruct>
>>>>>>>>>>
>>>>>>>>>> which is a fairly common pattern in P5 (and appears as the canonical
>>>>>>>>>> example for<imprint>)
>>>>>>>>>>
>>>>>>>>>> If, following FR 3555190, we think<biblStruct>   has no place within
>>>>>>>>>> <imprint>, how should
>>>>>>>>>> this, and many similar cases, be tagged?
>>>>>>>>>>
>>>>>>>>>> One possibility might be
>>>>>>>>>>
>>>>>>>>>> <monogr>
>>>>>>>>>> <title level="j">Computers and the Humanities</title>
>>>>>>>>>> <biblScope>25.6</biblScope>
>>>>>>>>>> <biblScope>377?380</biblScope>
>>>>>>>>>> <imprint>
>>>>>>>>>> <date when="1991-12">(December, 1991):</date>
>>>>>>>>>> </imprint>
>>>>>>>>>> </monogr>
>>>>>>>>>>
>>>>>>>>>> Another might be
>>>>>>>>>>
>>>>>>>>>> <monogr>
>>>>>>>>>> <title level="j">Computers and the Humanities</title>
>>>>>>>>>> <biblScope>25.6</biblScope>
>>>>>>>>>> <biblScope>377?380</biblScope>
>>>>>>>>>> <biblScope type="date">(December, 1991)</biblScope>
>>>>>>>>>> </imprint>
>>>>>>>>>> </monogr>
>>>>>>>>>>
>>>>>>>>>> or perhaps better
>>>>>>>>>>
>>>>>>>>>> <biblScope><date when="1991-12">(December, 1991)</date></biblScope>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Another might be to tweak the content model so that
>>>>>>>>>> model.dateLike is permitted outside<imprint>   and alongside<biblScope>
>>>>>>>>>>
>>>>>>>>>> And another might be to reconsider the decision to remove<biblScope>
>>>>>>>>>> from within<imprint>
>>>>>>>>>>
>>>>>>>>>> Any ideas? Everyone braced for the rush of complaints?
>>>>>>>>>>
>>>


From dsewell at virginia.edu  Sun Nov  4 08:52:54 2012
From: dsewell at virginia.edu (David Sewell)
Date: Sun, 4 Nov 2012 08:52:54 -0500 (EST)
Subject: [tei-council] Uploading files to the WIKI
In-Reply-To: <509619CD.5080202@o2.pl>
References: <5095D0BD.5090100@uvic.ca> <509619CD.5080202@o2.pl>
Message-ID: <alpine.OSX.2.00.1211040850470.7761@cewagi.local>

During the last upgrade of the TEI wiki, we ran into a PHP issue or two 
that required changes to files on the server that were root-access only, 
meaning Shayne needed to intervene. If that's the case this time, a fix 
will probably need to wait until Monday. But I'll take a look at things 
when I can today--may not be until evening as I have a commitment 
earlier.

On Sun, 4 Nov 2012, Piotr Ba?ski wrote:

> Hi Martin,
>
> It might have been inadvertently changed during the upgrade of the wiki
> software (veeery useful, it fixed a few problems, spambots among
> others). David has done a great wizarding job on that, hopefully he can
> help with the file upload issue as well.
>
>  P.
>
> On 04/11/12 03:19, Martin Holmes wrote:
>> Hi all,
>>
>> I'm working on my Prefix Definition Proposal on the wiki, and I've
>> drafted a new section of the Guidelines that I wanted to include as part
>> of the proposal. This is a regular TEI file, including a div which could
>> be inserted into the SA chapter. It's obviously easier to write it
>> directly in TEI, and then insert it into the chapter if and when it gets
>> approval, than to draft it in a word-processor and then have to tag it
>> up afterwards.
>>
>> I wanted to upload this to the wiki so people could vet it, but when I
>> tried to upload it as an XML file, the wiki said:
>>
>> "This file contains HTML or script code that may be erroneously
>> interpreted by a web browser."
>>
>> So I tried zipping it up (as I've done before with a script file). This
>> time, it said:
>>
>> "Files of the MIME type "application/zip" are not allowed to be uploaded."
>>
>> But the wiki upload page also says:
>>
>> "Permitted file types: png, gif, jpg, jpeg, ogg, zip, xsl, xml, dtd,
>> odd, rnc, rng, txt, pdf."
>>
>> In other words, it's supposed to be able to accept both XML and zip
>> files, but it won't. Someone or something must have changed the settings
>> since I last uploaded a zip file last year, but not changed the text of
>> the page which explains the limitations.
>>
>> I think a TEI wiki that doesn't allow us to upload XML files is a bit
>> ridiculous. Could we get this changed?
>>
>> Cheers,
>> Martin
>>
>
>

-- 
David Sewell, Editorial and Technical Manager
ROTUNDA, The University of Virginia Press
PO Box 400314, Charlottesville, VA 22904-4314 USA
Email: dsewell at virginia.edu   Tel: +1 434 924 9973
Web: http://rotunda.upress.virginia.edu/

From James.Cummings at it.ox.ac.uk  Sun Nov  4 13:43:20 2012
From: James.Cummings at it.ox.ac.uk (James Cummings)
Date: Sun, 04 Nov 2012 18:43:20 +0000
Subject: [tei-council] Uploading files to the WIKI
In-Reply-To: <alpine.OSX.2.00.1211040850470.7761@cewagi.local>
References: <5095D0BD.5090100@uvic.ca> <509619CD.5080202@o2.pl>
	<alpine.OSX.2.00.1211040850470.7761@cewagi.local>
Message-ID: <5096B748.1000709@it.ox.ac.uk>


David (Council CC'ed),

This is actually a different problem. We've always had the 
permitted file types: png, gif, jpg, jpeg, ogg, zip, xsl, xml, 
dtd, odd, rnc, rng, txt, pdf. It is just an earlier upgrade on 
media wiki introduced script checking where it (falsely) 
identifies TEI files as potentially dodgy HTML or javascript. 
I've not investigated how it does this check and why it is 
failing, but found a number of reported  bugs about it.

I've set $wgDisableUploadScriptChecks to true, and explicitly 
marked non-registered users as not being able to upload (though I 
think this was our default any way).  Piotr and Kevin will 
probably advise if this results in people who shouldn't being 
able to upload files.

It allowed me to, but I might have special powers.

Lou: We're not talking about uploading and processing TEI files 
of any particular type, but just uploading XML files in the same 
way you might upload PDFs or PNGs, etc.  Frankly if I was Martin 
I'd probably just link to the XML file provided elsewhere.

-James

On 04/11/12 13:52, David Sewell wrote:
> During the last upgrade of the TEI wiki, we ran into a PHP issue
> or two that required changes to files on the server that were
> root-access only, meaning Shayne needed to intervene. If that's
> the case this time, a fix will probably need to wait until
> Monday. But I'll take a look at things when I can today--may not
> be until evening as I have a commitment earlier.
>
> On Sun, 4 Nov 2012, Piotr Ba?ski wrote:
>
>> Hi Martin,
>>
>> It might have been inadvertently changed during the upgrade of
>> the wiki
>> software (veeery useful, it fixed a few problems, spambots among
>> others). David has done a great wizarding job on that,
>> hopefully he can
>> help with the file upload issue as well.
>>
>>  P.
>>
>> On 04/11/12 03:19, Martin Holmes wrote:
>>> Hi all,
>>>
>>> I'm working on my Prefix Definition Proposal on the wiki, and
>>> I've
>>> drafted a new section of the Guidelines that I wanted to
>>> include as part
>>> of the proposal. This is a regular TEI file, including a div
>>> which could
>>> be inserted into the SA chapter. It's obviously easier to
>>> write it
>>> directly in TEI, and then insert it into the chapter if and
>>> when it gets
>>> approval, than to draft it in a word-processor and then have
>>> to tag it
>>> up afterwards.
>>>
>>> I wanted to upload this to the wiki so people could vet it,
>>> but when I
>>> tried to upload it as an XML file, the wiki said:
>>>
>>> "This file contains HTML or script code that may be erroneously
>>> interpreted by a web browser."
>>>
>>> So I tried zipping it up (as I've done before with a script
>>> file). This
>>> time, it said:
>>>
>>> "Files of the MIME type "application/zip" are not allowed to
>>> be uploaded."
>>>
>>> But the wiki upload page also says:
>>>
>>> "Permitted file types: png, gif, jpg, jpeg, ogg, zip, xsl,
>>> xml, dtd,
>>> odd, rnc, rng, txt, pdf."
>>>
>>> In other words, it's supposed to be able to accept both XML
>>> and zip
>>> files, but it won't. Someone or something must have changed
>>> the settings
>>> since I last uploaded a zip file last year, but not changed
>>> the text of
>>> the page which explains the limitations.
>>>
>>> I think a TEI wiki that doesn't allow us to upload XML files
>>> is a bit
>>> ridiculous. Could we get this changed?
>>>
>>> Cheers,
>>> Martin
>>>
>>
>>
>
>
>
	

-- 
Dr James Cummings, James.Cummings at it.ox.ac.uk
Research Support, IT Services, University of Oxford

From dsewell at virginia.edu  Sun Nov  4 13:46:34 2012
From: dsewell at virginia.edu (David Sewell)
Date: Sun, 4 Nov 2012 13:46:34 -0500 (EST)
Subject: [tei-council] Uploading files to the WIKI
In-Reply-To: <5096B748.1000709@it.ox.ac.uk>
References: <5095D0BD.5090100@uvic.ca> <509619CD.5080202@o2.pl>
	<alpine.OSX.2.00.1211040850470.7761@cewagi.local>
	<5096B748.1000709@it.ox.ac.uk>
Message-ID: <alpine.OSX.2.00.1211041344560.5930@tadai.local>

James,

Thanks for tweaking the MediaWiki settings! And if anyone continues to 
have problems uploading files that should be legitimately accepted we 
can investigate further.

On Sun, 4 Nov 2012, James Cummings wrote:

>
> David (Council CC'ed),
>
> This is actually a different problem. We've always had the permitted file 
> types: png, gif, jpg, jpeg, ogg, zip, xsl, xml, dtd, odd, rnc, rng, txt, pdf. 
> It is just an earlier upgrade on media wiki introduced script checking where 
> it (falsely) identifies TEI files as potentially dodgy HTML or javascript. 
> I've not investigated how it does this check and why it is failing, but found 
> a number of reported  bugs about it.
>
> I've set $wgDisableUploadScriptChecks to true, and explicitly marked 
> non-registered users as not being able to upload (though I think this was our 
> default any way).  Piotr and Kevin will probably advise if this results in 
> people who shouldn't being able to upload files.
>
> It allowed me to, but I might have special powers.
>
> Lou: We're not talking about uploading and processing TEI files of any 
> particular type, but just uploading XML files in the same way you might 
> upload PDFs or PNGs, etc.  Frankly if I was Martin I'd probably just link to 
> the XML file provided elsewhere.
>
> -James
>
> On 04/11/12 13:52, David Sewell wrote:
>> During the last upgrade of the TEI wiki, we ran into a PHP issue
>> or two that required changes to files on the server that were
>> root-access only, meaning Shayne needed to intervene. If that's
>> the case this time, a fix will probably need to wait until
>> Monday. But I'll take a look at things when I can today--may not
>> be until evening as I have a commitment earlier.
>> 
>> On Sun, 4 Nov 2012, Piotr Ba?ski wrote:
>> 
>>> Hi Martin,
>>> 
>>> It might have been inadvertently changed during the upgrade of
>>> the wiki
>>> software (veeery useful, it fixed a few problems, spambots among
>>> others). David has done a great wizarding job on that,
>>> hopefully he can
>>> help with the file upload issue as well.
>>>
>>>  P.
>>> 
>>> On 04/11/12 03:19, Martin Holmes wrote:
>>>> Hi all,
>>>> 
>>>> I'm working on my Prefix Definition Proposal on the wiki, and
>>>> I've
>>>> drafted a new section of the Guidelines that I wanted to
>>>> include as part
>>>> of the proposal. This is a regular TEI file, including a div
>>>> which could
>>>> be inserted into the SA chapter. It's obviously easier to
>>>> write it
>>>> directly in TEI, and then insert it into the chapter if and
>>>> when it gets
>>>> approval, than to draft it in a word-processor and then have
>>>> to tag it
>>>> up afterwards.
>>>> 
>>>> I wanted to upload this to the wiki so people could vet it,
>>>> but when I
>>>> tried to upload it as an XML file, the wiki said:
>>>> 
>>>> "This file contains HTML or script code that may be erroneously
>>>> interpreted by a web browser."
>>>> 
>>>> So I tried zipping it up (as I've done before with a script
>>>> file). This
>>>> time, it said:
>>>> 
>>>> "Files of the MIME type "application/zip" are not allowed to
>>>> be uploaded."
>>>> 
>>>> But the wiki upload page also says:
>>>> 
>>>> "Permitted file types: png, gif, jpg, jpeg, ogg, zip, xsl,
>>>> xml, dtd,
>>>> odd, rnc, rng, txt, pdf."
>>>> 
>>>> In other words, it's supposed to be able to accept both XML
>>>> and zip
>>>> files, but it won't. Someone or something must have changed
>>>> the settings
>>>> since I last uploaded a zip file last year, but not changed
>>>> the text of
>>>> the page which explains the limitations.
>>>> 
>>>> I think a TEI wiki that doesn't allow us to upload XML files
>>>> is a bit
>>>> ridiculous. Could we get this changed?
>>>> 
>>>> Cheers,
>>>> Martin
>>>> 
>>> 
>>> 
>> 
>> 
>>
> 
>
>

-- 
David Sewell, Editorial and Technical Manager
ROTUNDA, The University of Virginia Press
PO Box 400314, Charlottesville, VA 22904-4314 USA
Email: dsewell at virginia.edu   Tel: +1 434 924 9973
Web: http://rotunda.upress.virginia.edu/

From James.Cummings at it.ox.ac.uk  Sun Nov  4 13:49:13 2012
From: James.Cummings at it.ox.ac.uk (James Cummings)
Date: Sun, 04 Nov 2012 18:49:13 +0000
Subject: [tei-council] Uploading files to the WIKI
In-Reply-To: <alpine.OSX.2.00.1211041344560.5930@tadai.local>
References: <5095D0BD.5090100@uvic.ca> <509619CD.5080202@o2.pl>
	<alpine.OSX.2.00.1211040850470.7761@cewagi.local>
	<5096B748.1000709@it.ox.ac.uk>
	<alpine.OSX.2.00.1211041344560.5930@tadai.local>
Message-ID: <5096B8A9.8000504@it.ox.ac.uk>


Actually, I say that fixed it... but I don't think it did. :-( 
(I thought it allowed me to upload but it just didn't complain... 
but doesn't seem to have uploaded.)

-James

On 04/11/12 18:46, David Sewell wrote:
> James,
>
> Thanks for tweaking the MediaWiki settings! And if anyone
> continues to have problems uploading files that should be
> legitimately accepted we can investigate further.
>
> On Sun, 4 Nov 2012, James Cummings wrote:
>
>>
>> David (Council CC'ed),
>>
>> This is actually a different problem. We've always had the
>> permitted file types: png, gif, jpg, jpeg, ogg, zip, xsl, xml,
>> dtd, odd, rnc, rng, txt, pdf. It is just an earlier upgrade on
>> media wiki introduced script checking where it (falsely)
>> identifies TEI files as potentially dodgy HTML or javascript.
>> I've not investigated how it does this check and why it is
>> failing, but found a number of reported  bugs about it.
>>
>> I've set $wgDisableUploadScriptChecks to true, and explicitly
>> marked non-registered users as not being able to upload (though
>> I think this was our default any way).  Piotr and Kevin will
>> probably advise if this results in people who shouldn't being
>> able to upload files.
>>
>> It allowed me to, but I might have special powers.
>>
>> Lou: We're not talking about uploading and processing TEI files
>> of any particular type, but just uploading XML files in the
>> same way you might upload PDFs or PNGs, etc.  Frankly if I was
>> Martin I'd probably just link to the XML file provided elsewhere.
>>
>> -James
>>
>> On 04/11/12 13:52, David Sewell wrote:
>>> During the last upgrade of the TEI wiki, we ran into a PHP issue
>>> or two that required changes to files on the server that were
>>> root-access only, meaning Shayne needed to intervene. If that's
>>> the case this time, a fix will probably need to wait until
>>> Monday. But I'll take a look at things when I can today--may not
>>> be until evening as I have a commitment earlier.
>>>
>>> On Sun, 4 Nov 2012, Piotr Ba?ski wrote:
>>>
>>>> Hi Martin,
>>>>
>>>> It might have been inadvertently changed during the upgrade of
>>>> the wiki
>>>> software (veeery useful, it fixed a few problems, spambots among
>>>> others). David has done a great wizarding job on that,
>>>> hopefully he can
>>>> help with the file upload issue as well.
>>>>
>>>>  P.
>>>>
>>>> On 04/11/12 03:19, Martin Holmes wrote:
>>>>> Hi all,
>>>>>
>>>>> I'm working on my Prefix Definition Proposal on the wiki, and
>>>>> I've
>>>>> drafted a new section of the Guidelines that I wanted to
>>>>> include as part
>>>>> of the proposal. This is a regular TEI file, including a div
>>>>> which could
>>>>> be inserted into the SA chapter. It's obviously easier to
>>>>> write it
>>>>> directly in TEI, and then insert it into the chapter if and
>>>>> when it gets
>>>>> approval, than to draft it in a word-processor and then have
>>>>> to tag it
>>>>> up afterwards.
>>>>>
>>>>> I wanted to upload this to the wiki so people could vet it,
>>>>> but when I
>>>>> tried to upload it as an XML file, the wiki said:
>>>>>
>>>>> "This file contains HTML or script code that may be erroneously
>>>>> interpreted by a web browser."
>>>>>
>>>>> So I tried zipping it up (as I've done before with a script
>>>>> file). This
>>>>> time, it said:
>>>>>
>>>>> "Files of the MIME type "application/zip" are not allowed to
>>>>> be uploaded."
>>>>>
>>>>> But the wiki upload page also says:
>>>>>
>>>>> "Permitted file types: png, gif, jpg, jpeg, ogg, zip, xsl,
>>>>> xml, dtd,
>>>>> odd, rnc, rng, txt, pdf."
>>>>>
>>>>> In other words, it's supposed to be able to accept both XML
>>>>> and zip
>>>>> files, but it won't. Someone or something must have changed
>>>>> the settings
>>>>> since I last uploaded a zip file last year, but not changed
>>>>> the text of
>>>>> the page which explains the limitations.
>>>>>
>>>>> I think a TEI wiki that doesn't allow us to upload XML files
>>>>> is a bit
>>>>> ridiculous. Could we get this changed?
>>>>>
>>>>> Cheers,
>>>>> Martin
>>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>>
>


-- 
Dr James Cummings, James.Cummings at it.ox.ac.uk
Research Support, IT Services, University of Oxford

From James.Cummings at it.ox.ac.uk  Sun Nov  4 13:51:41 2012
From: James.Cummings at it.ox.ac.uk (James Cummings)
Date: Sun, 04 Nov 2012 18:51:41 +0000
Subject: [tei-council] Uploading files to the WIKI
In-Reply-To: <5096B8A9.8000504@it.ox.ac.uk>
References: <5095D0BD.5090100@uvic.ca> <509619CD.5080202@o2.pl>
	<alpine.OSX.2.00.1211040850470.7761@cewagi.local>
	<5096B748.1000709@it.ox.ac.uk>
	<alpine.OSX.2.00.1211041344560.5930@tadai.local>
	<5096B8A9.8000504@it.ox.ac.uk>
Message-ID: <5096B93D.6070604@it.ox.ac.uk>


ah,  I see the problem.

we're running 1.16.5 and this override to the check is only 
introduced in 1.19.0

Investigating workarounds,

-James

On 04/11/12 18:49, James Cummings wrote:
>
> Actually, I say that fixed it... but I don't think it did. :-(
> (I thought it allowed me to upload but it just didn't complain...
> but doesn't seem to have uploaded.)
>
> -James
>
> On 04/11/12 18:46, David Sewell wrote:
>> James,
>>
>> Thanks for tweaking the MediaWiki settings! And if anyone
>> continues to have problems uploading files that should be
>> legitimately accepted we can investigate further.
>>
>> On Sun, 4 Nov 2012, James Cummings wrote:
>>
>>>
>>> David (Council CC'ed),
>>>
>>> This is actually a different problem. We've always had the
>>> permitted file types: png, gif, jpg, jpeg, ogg, zip, xsl, xml,
>>> dtd, odd, rnc, rng, txt, pdf. It is just an earlier upgrade on
>>> media wiki introduced script checking where it (falsely)
>>> identifies TEI files as potentially dodgy HTML or javascript.
>>> I've not investigated how it does this check and why it is
>>> failing, but found a number of reported  bugs about it.
>>>
>>> I've set $wgDisableUploadScriptChecks to true, and explicitly
>>> marked non-registered users as not being able to upload (though
>>> I think this was our default any way).  Piotr and Kevin will
>>> probably advise if this results in people who shouldn't being
>>> able to upload files.
>>>
>>> It allowed me to, but I might have special powers.
>>>
>>> Lou: We're not talking about uploading and processing TEI files
>>> of any particular type, but just uploading XML files in the
>>> same way you might upload PDFs or PNGs, etc.  Frankly if I was
>>> Martin I'd probably just link to the XML file provided elsewhere.
>>>
>>> -James
>>>
>>> On 04/11/12 13:52, David Sewell wrote:
>>>> During the last upgrade of the TEI wiki, we ran into a PHP issue
>>>> or two that required changes to files on the server that were
>>>> root-access only, meaning Shayne needed to intervene. If that's
>>>> the case this time, a fix will probably need to wait until
>>>> Monday. But I'll take a look at things when I can today--may not
>>>> be until evening as I have a commitment earlier.
>>>>
>>>> On Sun, 4 Nov 2012, Piotr Ba?ski wrote:
>>>>
>>>>> Hi Martin,
>>>>>
>>>>> It might have been inadvertently changed during the upgrade of
>>>>> the wiki
>>>>> software (veeery useful, it fixed a few problems, spambots among
>>>>> others). David has done a great wizarding job on that,
>>>>> hopefully he can
>>>>> help with the file upload issue as well.
>>>>>
>>>>>   P.
>>>>>
>>>>> On 04/11/12 03:19, Martin Holmes wrote:
>>>>>> Hi all,
>>>>>>
>>>>>> I'm working on my Prefix Definition Proposal on the wiki, and
>>>>>> I've
>>>>>> drafted a new section of the Guidelines that I wanted to
>>>>>> include as part
>>>>>> of the proposal. This is a regular TEI file, including a div
>>>>>> which could
>>>>>> be inserted into the SA chapter. It's obviously easier to
>>>>>> write it
>>>>>> directly in TEI, and then insert it into the chapter if and
>>>>>> when it gets
>>>>>> approval, than to draft it in a word-processor and then have
>>>>>> to tag it
>>>>>> up afterwards.
>>>>>>
>>>>>> I wanted to upload this to the wiki so people could vet it,
>>>>>> but when I
>>>>>> tried to upload it as an XML file, the wiki said:
>>>>>>
>>>>>> "This file contains HTML or script code that may be erroneously
>>>>>> interpreted by a web browser."
>>>>>>
>>>>>> So I tried zipping it up (as I've done before with a script
>>>>>> file). This
>>>>>> time, it said:
>>>>>>
>>>>>> "Files of the MIME type "application/zip" are not allowed to
>>>>>> be uploaded."
>>>>>>
>>>>>> But the wiki upload page also says:
>>>>>>
>>>>>> "Permitted file types: png, gif, jpg, jpeg, ogg, zip, xsl,
>>>>>> xml, dtd,
>>>>>> odd, rnc, rng, txt, pdf."
>>>>>>
>>>>>> In other words, it's supposed to be able to accept both XML
>>>>>> and zip
>>>>>> files, but it won't. Someone or something must have changed
>>>>>> the settings
>>>>>> since I last uploaded a zip file last year, but not changed
>>>>>> the text of
>>>>>> the page which explains the limitations.
>>>>>>
>>>>>> I think a TEI wiki that doesn't allow us to upload XML files
>>>>>> is a bit
>>>>>> ridiculous. Could we get this changed?
>>>>>>
>>>>>> Cheers,
>>>>>> Martin
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>
>


-- 
Dr James Cummings, James.Cummings at it.ox.ac.uk
Research Support, IT Services, University of Oxford

From mholmes at uvic.ca  Sun Nov  4 14:10:19 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Sun, 4 Nov 2012 11:10:19 -0800
Subject: [tei-council] biblscope and imprint
In-Reply-To: <50966524.5010708@retired.ox.ac.uk>
References: <5093A831.7080901@retired.ox.ac.uk>
	<5093D8C8.6090209@ultraslavonic.info>	<5093DDC7.1050504@kcl.ac.uk>
	<5093E2BB.6010106@ultraslavonic.info>	<50940D9A.7030007@retired.ox.ac.uk>
	<5095017A.8060903@retired.ox.ac.uk>	<50952166.2060305@ultraslavonic.info>
	<5095A6B4.2080307@retired.ox.ac.uk>	<5095BFB8.2050101@ultraslavonic.info>
	<5095C121.1010600@uvic.ca> <50966524.5010708@retired.ox.ac.uk>
Message-ID: <5096BD9B.4060402@uvic.ca>

>
> All of which I suppose we can side-step cheerfully, by saying "ru-Latn",
> even though this particular combination isn't actually proposed in
> http://www.iana.org/assignments/language-subtag-registry, and even
> though this won't help anyone who *does* want to see the original title
> as it should have been presented!

Both "ru" and "Latn" are in the subtag registry, and you're supposed to 
combine them in this way, if my understanding is correct. Not every 
combination of subtags is exhaustively listed; the components are there, 
and you combine them according to the rules and your needs, I think.

Cheers,
Martin

On 12-11-04 04:52 AM, Lou Burnard wrote:
> The comment was just a note to myself while I was going through that
> section and I will remove it before closing the ticket. However it does
> raise some interesting issues, which I have now had the leisure to
> investigate further.
>
> Firstly the comment that using "ru" for Russian transliterated in Roman
> characters is simply "underspecified" seems to me rather to miss the
> point. If I see something in a Unicode document which says it has
> xml:lang="ru" I expect to see proper Russian Unicode characters.
>
> Secondly, even if I am prepared to accept Romanized versions of those
> characters and figure out for myself what the Russian should have been,
> this is not entirely easy. There are several different (Wikipedia lists
> ten) possible Romanization schemes, which vary quite considerably. In
> some, for example, the sequence "ye" stands for the Russian letter that
> looks like a Roman "e"; in others this character is represented by "e",
> unless it is iotated by a preceding soft sign. So generating a correct
> Cyrillic version of this citation isn't easy, and neither is deciding
> which scheme we're dealing with here!
>
> Thirdly, this particular example is actually taken verbatim from a
> rather elderly ISO standard on bibliographic reference (ISO 690, 1987).
>    Hence we probably should not mess with its representation at all. (You
> can see it cited as a example in the Wikipedia entry for ISO_690,
> curiously enough). There is a new version of ISO 690 (from 2010) but I
> don't have 140 swiss francs at my disposal to pay for a PDF download,
> the libraries are all shut, and it's raining anyway ... so I can't see
> whether or not this example has been updated to use what would
> (presumably) be the current recommended transliteration scheme - ISO 9
> (1995).
>
> My guess, but I defer to the Russian expert in our midst, is that this
> uses the now deprecated ISO/R:1968 but without access to the original,
> it's hard to be sure, and without being sure I'd rather not try to
> convert it into proper Russian.
>
> All of which I suppose we can side-step cheerfully, by saying "ru-Latn",
> even though this particular combination isn't actually proposed in
> http://www.iana.org/assignments/language-subtag-registry, and even
> though this won't help anyone who *does* want to see the original title
> as it should have been presented!
>
>
>
>     On 04/11/12 01:13, Martin Holmes wrote:
>>>
>>> Lou added an XML comment in the Guidelines (but didn't we agree in Paris
>>> to stop using these?)
>>
>> We didn't say we'd stop using them, IIRC; we said we would sign and date
>> them, so it would be easier going forward to determine whether comments
>> were no longer of interest or relevance, and could be deleted.
>>
>> So I think Lou should sign and date that comment. To answer his
>> question, I think the language subtag should be:
>>
>> ru-Latn
>>
>> for Russian in Latin script.
>>
>> Cheers,
>> Martin
>>
>> On 12-11-03 06:07 PM, Kevin Hawkins wrote:
>>> I've looked over:
>>>
>>> http://tei.svn.sourceforge.net/viewvc/tei/trunk/P5/Source/Guidelines/en/CO-CoreElements.xml?r1=11111&r2=11110&pathrev=11111
>>>
>>> and it looks good to me, though I agree that we should wait on Gabby.
>>> Lou, you might also post a comment on the ticket for the benefit of John
>>> McCaskey and Laurent, who may be following this ticket's progress.
>>>
>>> Lou added an XML comment in the Guidelines (but didn't we agree in Paris
>>> to stop using these?) at:
>>>
>>> http://tei.svn.sourceforge.net/viewvc/tei/trunk/P5/Source/Guidelines/en/CO-CoreElements.xml?r1=11111&r2=11110&pathrev=11111
>>>
>>> asking whether "ru" is the correct value for @xml:lang for Russian
>>> written in roman letters.  BCP 47 does not say that a script subtag must
>>> be used if a language is written in a script that is not the usual one,
>>> so I believe use of "ru" is correct though it underspecifies.  If you
>>> like, you could change to "ru-Latn".
>>>
>>> --Kevin
>>>
>>> On 11/3/12 7:20 PM, Lou Burnard wrote:
>>>> I've now checked in a revised CO which I think addresses these concerns,
>>>> but am leaving the ticket open till Gabby has also had a chance to check
>>>> this out.
>>>>
>>>>
>>>>
>>>> On 03/11/12 13:51, Kevin Hawkins wrote:
>>>>> Ugh, Gabby and I both misremembered the proposal at
>>>>> http://purl.org/tei/FR/3555190 .  Lou is right that according to that
>>>>> proposal, there is never a <biblScope> in <analytic>, so the Chestnutt
>>>>> citation encoded according to the proposal would be:
>>>>>
>>>>> <biblStruct>
>>>>>         <analytic>
>>>>>           <author>Chesnutt, David</author>
>>>>>           <title>Historical Editions in the States</title>
>>>>>         </analytic>
>>>>>         <monogr>
>>>>>           <title level="j">Computers and the Humanities</title>
>>>>>           <imprint>
>>>>>             <date when="1991-12">(December, 1991):</date>
>>>>>           </imprint>
>>>>>           <biblScope type="vol">25</biblScope>
>>>>>           <biblScope type="issue">6</biblScope>
>>>>>           <biblScope type="pp">377?380</biblScope>
>>>>>         </monogr>
>>>>> </biblStruct>
>>>>>
>>>>> (which is more or less how I first wrote it below).
>>>>>
>>>>> On 11/3/12 7:35 AM, Lou Burnard wrote:
>>>>>> Looking at this suggestion again: surely it cannot ever be right to put
>>>>>> a <biblScope> within an <analytic> ?
>>>>>>
>>>>>> See further my comment on the ticket -- specifically
>>>>>>
>>>>>> "I think the sentence "Each <biblScope> describes where (within its
>>>>>> parent element) to find the thing in the previous level" is correct, but
>>>>>> only if you understand the word "level" as "preceding sibling of a
>>>>>> different bibliographic level"
>>>>>>
>>>>>> Hence the pagination biblScope ought to go within the monogr, not within
>>>>>> the analytic. This also makes sense if the same article appears in two
>>>>>> different monogrs, possibly with different pagination.
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 02/11/12 18:14, Lou Burnard wrote:
>>>>>>> On 02/11/12 15:11, Kevin Hawkins wrote:
>>>>>>>> Gabby's right. I was focusing on placement of <biblScope> in relation to
>>>>>>>> <imprint>.  So Lou's citation (from the Guidelines) would in fact be:
>>>>>>>>
>>>>>>>> <biblStruct>
>>>>>>>>            <analytic>
>>>>>>>>              <author>Chesnutt, David</author>
>>>>>>>>              <title>Historical Editions in the States</title>
>>>>>>>>              <biblScope type="pp">377?380</biblScope>
>>>>>>>>            </analytic>
>>>>>>>>            <monogr>
>>>>>>>>              <title level="j">Computers and the Humanities</title>
>>>>>>>>              <imprint>
>>>>>>>>                <date when="1991-12">(December, 1991):</date>
>>>>>>>>              </imprint>
>>>>>>>>              <biblScope type="vol">25</biblScope>
>>>>>>>>              <biblScope type="issue">6</biblScope>
>>>>>>>>            </monogr>
>>>>>>>> </biblStruct>
>>>>>>>>
>>>>>>>> On 11/2/2012 10:50 AM, Gabriel Bodard wrote:
>>>>>>>>> Is that what we proposed?
>>>>>>>>>
>>>>>>>>> I thought I remembered we had suggested to put the biblScope in the
>>>>>>>>> element whose scope is being defined by it, so<biblScope type="pp">
>>>>>>>>> goes in<analytic>  because the article is only pages 377-380 of the
>>>>>>>>> volume in question, and<biblScope type="issue">  goes in<monogr>
>>>>>>>>> because this volume is only issue 25.6 of the journal....
>>>>>>>>>
>>>>>>>>> But looking at this stuff I find myself more and more agreeing with
>>>>>>>>> Martin that biblStruct was never a good idea. ;-)
>>>>>>>>>
>>>>>>>>> G
>>>>>>>>>
>>>>>>>>> On 2012-11-02 14:29, Kevin Hawkins wrote:
>>>>>>>>>> The ticket proposes putting<biblScope>s after the<imprint>  element
>>>>>>>>>> when its present.  So your example would now be encoded as:
>>>>>>>>>>
>>>>>>>>>> <biblStruct>
>>>>>>>>>>              <analytic>
>>>>>>>>>>                <author>Chesnutt, David</author>
>>>>>>>>>>                <title>Historical Editions in the States</title>
>>>>>>>>>>              </analytic>
>>>>>>>>>>              <monogr>
>>>>>>>>>>                <title level="j">Computers and the Humanities</title>
>>>>>>>>>>                <imprint>
>>>>>>>>>>                  <date when="1991-12">(December, 1991):</date>
>>>>>>>>>>                </imprint>
>>>>>>>>>>                <biblScope>25.6</biblScope>
>>>>>>>>>>                <biblScope>377?380</biblScope>
>>>>>>>>>>              </monogr>
>>>>>>>>>> </biblStruct>
>>>>>>>>>>
>>>>>>>>>> --Kevin
>>>>>>>>>>
>>>>>>>>>> On 11/2/2012 7:02 AM, Lou Burnard wrote:
>>>>>>>>>>> Tootling across france on the train yesterday I started trying to deal
>>>>>>>>>>> with http://purl.org/tei/FR/3555190...
>>>>>>>>>>>
>>>>>>>>>>> The part about the scope of biblscope was fairly easy to add, as was
>>>>>>>>>>> guidance on usage of biblScope. But I hit a problem with the second
>>>>>>>>>>> part, where it says that biblScope doesn't belong inside<imprint>   --
>>>>>>>>>>> the logic behind that desire is impeccable, but it messes up an awful
>>>>>>>>>>> lot of out current practice.
>>>>>>>>>>>
>>>>>>>>>>> Consider the following:
>>>>>>>>>>>
>>>>>>>>>>> <biblStruct>
>>>>>>>>>>> <analytic>
>>>>>>>>>>> <author>Chesnutt, David</author>
>>>>>>>>>>> <title>Historical Editions in the States</title>
>>>>>>>>>>> </analytic>
>>>>>>>>>>> <monogr>
>>>>>>>>>>> <title level="j">Computers and the Humanities</title>
>>>>>>>>>>> <imprint>
>>>>>>>>>>> <biblScope>25.6</biblScope>
>>>>>>>>>>> <date when="1991-12">(December, 1991):</date>
>>>>>>>>>>> <biblScope>377?380</biblScope>
>>>>>>>>>>> </imprint>
>>>>>>>>>>> </monogr>
>>>>>>>>>>> </biblStruct>
>>>>>>>>>>>
>>>>>>>>>>> which is a fairly common pattern in P5 (and appears as the canonical
>>>>>>>>>>> example for<imprint>)
>>>>>>>>>>>
>>>>>>>>>>> If, following FR 3555190, we think<biblStruct>   has no place within
>>>>>>>>>>> <imprint>, how should
>>>>>>>>>>> this, and many similar cases, be tagged?
>>>>>>>>>>>
>>>>>>>>>>> One possibility might be
>>>>>>>>>>>
>>>>>>>>>>> <monogr>
>>>>>>>>>>> <title level="j">Computers and the Humanities</title>
>>>>>>>>>>> <biblScope>25.6</biblScope>
>>>>>>>>>>> <biblScope>377?380</biblScope>
>>>>>>>>>>> <imprint>
>>>>>>>>>>> <date when="1991-12">(December, 1991):</date>
>>>>>>>>>>> </imprint>
>>>>>>>>>>> </monogr>
>>>>>>>>>>>
>>>>>>>>>>> Another might be
>>>>>>>>>>>
>>>>>>>>>>> <monogr>
>>>>>>>>>>> <title level="j">Computers and the Humanities</title>
>>>>>>>>>>> <biblScope>25.6</biblScope>
>>>>>>>>>>> <biblScope>377?380</biblScope>
>>>>>>>>>>> <biblScope type="date">(December, 1991)</biblScope>
>>>>>>>>>>> </imprint>
>>>>>>>>>>> </monogr>
>>>>>>>>>>>
>>>>>>>>>>> or perhaps better
>>>>>>>>>>>
>>>>>>>>>>> <biblScope><date when="1991-12">(December, 1991)</date></biblScope>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Another might be to tweak the content model so that
>>>>>>>>>>> model.dateLike is permitted outside<imprint>   and alongside<biblScope>
>>>>>>>>>>>
>>>>>>>>>>> And another might be to reconsider the decision to remove<biblScope>
>>>>>>>>>>> from within<imprint>
>>>>>>>>>>>
>>>>>>>>>>> Any ideas? Everyone braced for the rush of complaints?
>>>>>>>>>>>
>>>>
>
> --
> tei-council mailing list
> tei-council at lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>
> PLEASE NOTE: postings to this list are publicly archived
>

From mholmes at uvic.ca  Sun Nov  4 14:24:10 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Sun, 4 Nov 2012 11:24:10 -0800
Subject: [tei-council] Uploading files to the WIKI
In-Reply-To: <509659B0.3040209@retired.ox.ac.uk>
References: <5095D0BD.5090100@uvic.ca> <509659B0.3040209@retired.ox.ac.uk>
Message-ID: <5096C0DA.3020808@uvic.ca>

Thanks to James and David for looking at this.

To answer Lou, I wasn't asking to be able to display XML files in a 
web-pagey way through a transformation or CSS, just to be able to post 
them there so people can download them or view them in their browser.

If it turns out to be a security issue, or no easy and safe workaround 
is available, then there is an obvious alternative, as James suggests: 
we can create a location (for instance in SVN) where files in support of 
wiki pages could be posted, and link to them there. I certainly don't 
want to expose the wiki to potential hacks. But if the restrictions are 
staying in place, we need to test what's allowed and what isn't, and 
revise the explanatory text on the upload page.

To test James's changes, I just tried uploading the XML file again, and 
the results are the same.

Cheers,
Martin


On 12-11-04 04:04 AM, Lou Burnard wrote:
> On 04/11/12 02:19, Martin Holmes wrote:
>
>>
>> I think a TEI wiki that doesn't allow us to upload XML files is a bit
>> ridiculous.
>
> +1 from me. One of the reasons I am reluctant to mess with it.
>
> Could we get this changed?
>
> Preferably to import and export in some simple TEI subset?



From dsewell at virginia.edu  Sun Nov  4 20:51:34 2012
From: dsewell at virginia.edu (David Sewell)
Date: Sun, 4 Nov 2012 20:51:34 -0500 (EST)
Subject: [tei-council] Uploading files to the WIKI (fwd)
Message-ID: <alpine.OSX.2.00.1211042051220.8000@tadai.local>

I am getting the same error message. But it is totally ignorable, no?

Here is all that I did:

1) Click "Upload file" in sidebar.

2) Upload a random XML file on my machine called Test.xml

3) The file uploads, and produces a file page that indeed contains an ominous 
warning:

http://wiki.tei-c.org/index.php/File:Test.xml

but it doesn't prevent the file from being opened:

http://wiki.tei-c.org/images/d/d1/Test.xml

or referenced:

http://wiki.tei-c.org/index.php/User:DavidSewell

(click on link in last line).

If an ordinary registered user can do that, we have no problem, I think.

David

On Sun, 4 Nov 2012, James Cummings wrote:

> 
> Bah I've hacked and hacked and hacked and not been able to solve this.
> 
> I went through includes/SpecialUpload.php commenting out *all* the checks it 
> does on mimetype, on whether it is an HTML file, javascript, etc. ...  ihad 
> huge functions  doing absolutely nothing but returning that everything was 
> ok.
> 
> *still* same error message.
> 
> I give up until after the members meeting if you or shayne haven't fixed it 
> by then. ;-)
> 
> -James
> 
> 
> On 04/11/12 18:46, David Sewell wrote:
>> James,
>> 
>> Thanks for tweaking the MediaWiki settings! And if anyone
>> continues to have problems uploading files that should be
>> legitimately accepted we can investigate further.
>> 
>> On Sun, 4 Nov 2012, James Cummings wrote:
>> 
>>> 
>>> David (Council CC'ed),
>>> 
>>> This is actually a different problem. We've always had the
>>> permitted file types: png, gif, jpg, jpeg, ogg, zip, xsl, xml,
>>> dtd, odd, rnc, rng, txt, pdf. It is just an earlier upgrade on
>>> media wiki introduced script checking where it (falsely)
>>> identifies TEI files as potentially dodgy HTML or javascript.
>>> I've not investigated how it does this check and why it is
>>> failing, but found a number of reported  bugs about it.
>>> 
>>> I've set $wgDisableUploadScriptChecks to true, and explicitly
>>> marked non-registered users as not being able to upload (though
>>> I think this was our default any way).  Piotr and Kevin will
>>> probably advise if this results in people who shouldn't being
>>> able to upload files.
>>> 
>>> It allowed me to, but I might have special powers.
>>> 
>>> Lou: We're not talking about uploading and processing TEI files
>>> of any particular type, but just uploading XML files in the
>>> same way you might upload PDFs or PNGs, etc.  Frankly if I was
>>> Martin I'd probably just link to the XML file provided elsewhere.
>>> 
>>> -James
>>> 
>>> On 04/11/12 13:52, David Sewell wrote:
>>>> During the last upgrade of the TEI wiki, we ran into a PHP issue
>>>> or two that required changes to files on the server that were
>>>> root-access only, meaning Shayne needed to intervene. If that's
>>>> the case this time, a fix will probably need to wait until
>>>> Monday. But I'll take a look at things when I can today--may not
>>>> be until evening as I have a commitment earlier.
>>>> 
>>>> On Sun, 4 Nov 2012, Piotr Ba?ski wrote:
>>>> 
>>>>> Hi Martin,
>>>>> 
>>>>> It might have been inadvertently changed during the upgrade of
>>>>> the wiki
>>>>> software (veeery useful, it fixed a few problems, spambots among
>>>>> others). David has done a great wizarding job on that,
>>>>> hopefully he can
>>>>> help with the file upload issue as well.
>>>>>
>>>>>  P.
>>>>> 
>>>>> On 04/11/12 03:19, Martin Holmes wrote:
>>>>>> Hi all,
>>>>>> 
>>>>>> I'm working on my Prefix Definition Proposal on the wiki, and
>>>>>> I've
>>>>>> drafted a new section of the Guidelines that I wanted to
>>>>>> include as part
>>>>>> of the proposal. This is a regular TEI file, including a div
>>>>>> which could
>>>>>> be inserted into the SA chapter. It's obviously easier to
>>>>>> write it
>>>>>> directly in TEI, and then insert it into the chapter if and
>>>>>> when it gets
>>>>>> approval, than to draft it in a word-processor and then have
>>>>>> to tag it
>>>>>> up afterwards.
>>>>>> 
>>>>>> I wanted to upload this to the wiki so people could vet it,
>>>>>> but when I
>>>>>> tried to upload it as an XML file, the wiki said:
>>>>>> 
>>>>>> "This file contains HTML or script code that may be erroneously
>>>>>> interpreted by a web browser."
>>>>>> 
>>>>>> So I tried zipping it up (as I've done before with a script
>>>>>> file). This
>>>>>> time, it said:
>>>>>> 
>>>>>> "Files of the MIME type "application/zip" are not allowed to
>>>>>> be uploaded."
>>>>>> 
>>>>>> But the wiki upload page also says:
>>>>>> 
>>>>>> "Permitted file types: png, gif, jpg, jpeg, ogg, zip, xsl,
>>>>>> xml, dtd,
>>>>>> odd, rnc, rng, txt, pdf."
>>>>>> 
>>>>>> In other words, it's supposed to be able to accept both XML
>>>>>> and zip
>>>>>> files, but it won't. Someone or something must have changed
>>>>>> the settings
>>>>>> since I last uploaded a zip file last year, but not changed
>>>>>> the text of
>>>>>> the page which explains the limitations.
>>>>>> 
>>>>>> I think a TEI wiki that doesn't allow us to upload XML files
>>>>>> is a bit
>>>>>> ridiculous. Could we get this changed?
>>>>>> 
>>>>>> Cheers,
>>>>>> Martin
>>>>>> 
>>>>> 
>>>>> 
>>>> 
>>>> 
>>>> 
>>> 
>>> 
>>> 
>> 
> 
> 
>

-- 
David Sewell, Editorial and Technical Manager
ROTUNDA, The University of Virginia Press
PO Box 400314, Charlottesville, VA 22904-4314 USA
Email: dsewell at virginia.edu   Tel: +1 434 924 9973
Web: http://rotunda.upress.virginia.edu/

From dsewell at virginia.edu  Sun Nov  4 21:17:22 2012
From: dsewell at virginia.edu (David Sewell)
Date: Sun, 4 Nov 2012 21:17:22 -0500 (EST)
Subject: [tei-council] Uploading files to the WIKI (fwd)
In-Reply-To: <alpine.OSX.2.00.1211042051220.8000@tadai.local>
References: <alpine.OSX.2.00.1211042051220.8000@tadai.local>
Message-ID: <alpine.OSX.2.00.1211042112120.8000@tadai.local>

Sorry: having just created a temporary wiki account lacking 
administrator privileges, I see that upload of the XML file is not only 
warned but prevented.

It may be that upgrading WikiMedia is the only fix. But I'll poke around 
some more as well.

David

On Sun, 4 Nov 2012, David Sewell wrote:

> I am getting the same error message. But it is totally ignorable, no?
>
> Here is all that I did:
>
> 1) Click "Upload file" in sidebar.
>
> 2) Upload a random XML file on my machine called Test.xml
>
> 3) The file uploads, and produces a file page that indeed contains an ominous 
> warning:
>
> http://wiki.tei-c.org/index.php/File:Test.xml
>
> but it doesn't prevent the file from being opened:
>
> http://wiki.tei-c.org/images/d/d1/Test.xml
>
> or referenced:
>
> http://wiki.tei-c.org/index.php/User:DavidSewell
>
> (click on link in last line).
>
> If an ordinary registered user can do that, we have no problem, I think.
>
> David
>
> On Sun, 4 Nov 2012, James Cummings wrote:
>
>> 
>> Bah I've hacked and hacked and hacked and not been able to solve this.
>> 
>> I went through includes/SpecialUpload.php commenting out *all* the checks 
>> it does on mimetype, on whether it is an HTML file, javascript, etc. ... 
>> ihad huge functions  doing absolutely nothing but returning that everything 
>> was ok.
>> 
>> *still* same error message.
>> 
>> I give up until after the members meeting if you or shayne haven't fixed it 
>> by then. ;-)
>> 
>> -James
>> 
>> 
>> On 04/11/12 18:46, David Sewell wrote:
>>> James,
>>> 
>>> Thanks for tweaking the MediaWiki settings! And if anyone
>>> continues to have problems uploading files that should be
>>> legitimately accepted we can investigate further.
>>> 
>>> On Sun, 4 Nov 2012, James Cummings wrote:
>>> 
>>>> 
>>>> David (Council CC'ed),
>>>> 
>>>> This is actually a different problem. We've always had the
>>>> permitted file types: png, gif, jpg, jpeg, ogg, zip, xsl, xml,
>>>> dtd, odd, rnc, rng, txt, pdf. It is just an earlier upgrade on
>>>> media wiki introduced script checking where it (falsely)
>>>> identifies TEI files as potentially dodgy HTML or javascript.
>>>> I've not investigated how it does this check and why it is
>>>> failing, but found a number of reported  bugs about it.
>>>> 
>>>> I've set $wgDisableUploadScriptChecks to true, and explicitly
>>>> marked non-registered users as not being able to upload (though
>>>> I think this was our default any way).  Piotr and Kevin will
>>>> probably advise if this results in people who shouldn't being
>>>> able to upload files.
>>>> 
>>>> It allowed me to, but I might have special powers.
>>>> 
>>>> Lou: We're not talking about uploading and processing TEI files
>>>> of any particular type, but just uploading XML files in the
>>>> same way you might upload PDFs or PNGs, etc.  Frankly if I was
>>>> Martin I'd probably just link to the XML file provided elsewhere.
>>>> 
>>>> -James
>>>> 
>>>> On 04/11/12 13:52, David Sewell wrote:
>>>>> During the last upgrade of the TEI wiki, we ran into a PHP issue
>>>>> or two that required changes to files on the server that were
>>>>> root-access only, meaning Shayne needed to intervene. If that's
>>>>> the case this time, a fix will probably need to wait until
>>>>> Monday. But I'll take a look at things when I can today--may not
>>>>> be until evening as I have a commitment earlier.
>>>>> 
>>>>> On Sun, 4 Nov 2012, Piotr Ba?ski wrote:
>>>>> 
>>>>>> Hi Martin,
>>>>>> 
>>>>>> It might have been inadvertently changed during the upgrade of
>>>>>> the wiki
>>>>>> software (veeery useful, it fixed a few problems, spambots among
>>>>>> others). David has done a great wizarding job on that,
>>>>>> hopefully he can
>>>>>> help with the file upload issue as well.
>>>>>>
>>>>>>  P.
>>>>>> 
>>>>>> On 04/11/12 03:19, Martin Holmes wrote:
>>>>>>> Hi all,
>>>>>>> 
>>>>>>> I'm working on my Prefix Definition Proposal on the wiki, and
>>>>>>> I've
>>>>>>> drafted a new section of the Guidelines that I wanted to
>>>>>>> include as part
>>>>>>> of the proposal. This is a regular TEI file, including a div
>>>>>>> which could
>>>>>>> be inserted into the SA chapter. It's obviously easier to
>>>>>>> write it
>>>>>>> directly in TEI, and then insert it into the chapter if and
>>>>>>> when it gets
>>>>>>> approval, than to draft it in a word-processor and then have
>>>>>>> to tag it
>>>>>>> up afterwards.
>>>>>>> 
>>>>>>> I wanted to upload this to the wiki so people could vet it,
>>>>>>> but when I
>>>>>>> tried to upload it as an XML file, the wiki said:
>>>>>>> 
>>>>>>> "This file contains HTML or script code that may be erroneously
>>>>>>> interpreted by a web browser."
>>>>>>> 
>>>>>>> So I tried zipping it up (as I've done before with a script
>>>>>>> file). This
>>>>>>> time, it said:
>>>>>>> 
>>>>>>> "Files of the MIME type "application/zip" are not allowed to
>>>>>>> be uploaded."
>>>>>>> 
>>>>>>> But the wiki upload page also says:
>>>>>>> 
>>>>>>> "Permitted file types: png, gif, jpg, jpeg, ogg, zip, xsl,
>>>>>>> xml, dtd,
>>>>>>> odd, rnc, rng, txt, pdf."
>>>>>>> 
>>>>>>> In other words, it's supposed to be able to accept both XML
>>>>>>> and zip
>>>>>>> files, but it won't. Someone or something must have changed
>>>>>>> the settings
>>>>>>> since I last uploaded a zip file last year, but not changed
>>>>>>> the text of
>>>>>>> the page which explains the limitations.
>>>>>>> 
>>>>>>> I think a TEI wiki that doesn't allow us to upload XML files
>>>>>>> is a bit
>>>>>>> ridiculous. Could we get this changed?
>>>>>>> 
>>>>>>> Cheers,
>>>>>>> Martin
>>>>>>> 
>>>>>> 
>>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>> 
>>>> 
>>>> 
>>> 
>> 
>> 
>> 
>
>

-- 
David Sewell, Editorial and Technical Manager
ROTUNDA, The University of Virginia Press
PO Box 400314, Charlottesville, VA 22904-4314 USA
Email: dsewell at virginia.edu   Tel: +1 434 924 9973
Web: http://rotunda.upress.virginia.edu/

From mholmes at uvic.ca  Sun Nov  4 23:15:22 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Sun, 4 Nov 2012 20:15:22 -0800
Subject: [tei-council] Uploading files to the WIKI (fwd)
In-Reply-To: <alpine.OSX.2.00.1211042051220.8000@tadai.local>
References: <alpine.OSX.2.00.1211042051220.8000@tadai.local>
Message-ID: <50973D5A.2080804@uvic.ca>

I think you must have special powers, at least compared with me. My file 
never ends up in the list of uploaded files.

Cheers,
Martin

On 12-11-04 05:51 PM, David Sewell wrote:
> I am getting the same error message. But it is totally ignorable, no?
>
> Here is all that I did:
>
> 1) Click "Upload file" in sidebar.
>
> 2) Upload a random XML file on my machine called Test.xml
>
> 3) The file uploads, and produces a file page that indeed contains an ominous
> warning:
>
> http://wiki.tei-c.org/index.php/File:Test.xml
>
> but it doesn't prevent the file from being opened:
>
> http://wiki.tei-c.org/images/d/d1/Test.xml
>
> or referenced:
>
> http://wiki.tei-c.org/index.php/User:DavidSewell
>
> (click on link in last line).
>
> If an ordinary registered user can do that, we have no problem, I think.
>
> David
>
> On Sun, 4 Nov 2012, James Cummings wrote:
>
>>
>> Bah I've hacked and hacked and hacked and not been able to solve this.
>>
>> I went through includes/SpecialUpload.php commenting out *all* the checks it
>> does on mimetype, on whether it is an HTML file, javascript, etc. ...  ihad
>> huge functions  doing absolutely nothing but returning that everything was
>> ok.
>>
>> *still* same error message.
>>
>> I give up until after the members meeting if you or shayne haven't fixed it
>> by then. ;-)
>>
>> -James
>>
>>
>> On 04/11/12 18:46, David Sewell wrote:
>>> James,
>>>
>>> Thanks for tweaking the MediaWiki settings! And if anyone
>>> continues to have problems uploading files that should be
>>> legitimately accepted we can investigate further.
>>>
>>> On Sun, 4 Nov 2012, James Cummings wrote:
>>>
>>>>
>>>> David (Council CC'ed),
>>>>
>>>> This is actually a different problem. We've always had the
>>>> permitted file types: png, gif, jpg, jpeg, ogg, zip, xsl, xml,
>>>> dtd, odd, rnc, rng, txt, pdf. It is just an earlier upgrade on
>>>> media wiki introduced script checking where it (falsely)
>>>> identifies TEI files as potentially dodgy HTML or javascript.
>>>> I've not investigated how it does this check and why it is
>>>> failing, but found a number of reported  bugs about it.
>>>>
>>>> I've set $wgDisableUploadScriptChecks to true, and explicitly
>>>> marked non-registered users as not being able to upload (though
>>>> I think this was our default any way).  Piotr and Kevin will
>>>> probably advise if this results in people who shouldn't being
>>>> able to upload files.
>>>>
>>>> It allowed me to, but I might have special powers.
>>>>
>>>> Lou: We're not talking about uploading and processing TEI files
>>>> of any particular type, but just uploading XML files in the
>>>> same way you might upload PDFs or PNGs, etc.  Frankly if I was
>>>> Martin I'd probably just link to the XML file provided elsewhere.
>>>>
>>>> -James
>>>>
>>>> On 04/11/12 13:52, David Sewell wrote:
>>>>> During the last upgrade of the TEI wiki, we ran into a PHP issue
>>>>> or two that required changes to files on the server that were
>>>>> root-access only, meaning Shayne needed to intervene. If that's
>>>>> the case this time, a fix will probably need to wait until
>>>>> Monday. But I'll take a look at things when I can today--may not
>>>>> be until evening as I have a commitment earlier.
>>>>>
>>>>> On Sun, 4 Nov 2012, Piotr Ba?ski wrote:
>>>>>
>>>>>> Hi Martin,
>>>>>>
>>>>>> It might have been inadvertently changed during the upgrade of
>>>>>> the wiki
>>>>>> software (veeery useful, it fixed a few problems, spambots among
>>>>>> others). David has done a great wizarding job on that,
>>>>>> hopefully he can
>>>>>> help with the file upload issue as well.
>>>>>>
>>>>>>   P.
>>>>>>
>>>>>> On 04/11/12 03:19, Martin Holmes wrote:
>>>>>>> Hi all,
>>>>>>>
>>>>>>> I'm working on my Prefix Definition Proposal on the wiki, and
>>>>>>> I've
>>>>>>> drafted a new section of the Guidelines that I wanted to
>>>>>>> include as part
>>>>>>> of the proposal. This is a regular TEI file, including a div
>>>>>>> which could
>>>>>>> be inserted into the SA chapter. It's obviously easier to
>>>>>>> write it
>>>>>>> directly in TEI, and then insert it into the chapter if and
>>>>>>> when it gets
>>>>>>> approval, than to draft it in a word-processor and then have
>>>>>>> to tag it
>>>>>>> up afterwards.
>>>>>>>
>>>>>>> I wanted to upload this to the wiki so people could vet it,
>>>>>>> but when I
>>>>>>> tried to upload it as an XML file, the wiki said:
>>>>>>>
>>>>>>> "This file contains HTML or script code that may be erroneously
>>>>>>> interpreted by a web browser."
>>>>>>>
>>>>>>> So I tried zipping it up (as I've done before with a script
>>>>>>> file). This
>>>>>>> time, it said:
>>>>>>>
>>>>>>> "Files of the MIME type "application/zip" are not allowed to
>>>>>>> be uploaded."
>>>>>>>
>>>>>>> But the wiki upload page also says:
>>>>>>>
>>>>>>> "Permitted file types: png, gif, jpg, jpeg, ogg, zip, xsl,
>>>>>>> xml, dtd,
>>>>>>> odd, rnc, rng, txt, pdf."
>>>>>>>
>>>>>>> In other words, it's supposed to be able to accept both XML
>>>>>>> and zip
>>>>>>> files, but it won't. Someone or something must have changed
>>>>>>> the settings
>>>>>>> since I last uploaded a zip file last year, but not changed
>>>>>>> the text of
>>>>>>> the page which explains the limitations.
>>>>>>>
>>>>>>> I think a TEI wiki that doesn't allow us to upload XML files
>>>>>>> is a bit
>>>>>>> ridiculous. Could we get this changed?
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Martin
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>
>>
>>
>

From mholmes at uvic.ca  Sun Nov  4 23:17:29 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Sun, 4 Nov 2012 20:17:29 -0800
Subject: [tei-council] Uploading files to the WIKI (fwd)
In-Reply-To: <alpine.OSX.2.00.1211042112120.8000@tadai.local>
References: <alpine.OSX.2.00.1211042051220.8000@tadai.local>
	<alpine.OSX.2.00.1211042112120.8000@tadai.local>
Message-ID: <50973DD9.3070109@uvic.ca>

I'm feeling a bit guilty about how much effort David and James are 
putting into this now. I figured it was just a setting that got 
inadvertently turned off. If it's not straightforward, please don't put 
any more time into it.

Cheers,
Martin

On 12-11-04 06:17 PM, David Sewell wrote:
> Sorry: having just created a temporary wiki account lacking
> administrator privileges, I see that upload of the XML file is not only
> warned but prevented.
>
> It may be that upgrading WikiMedia is the only fix. But I'll poke around
> some more as well.
>
> David
>
> On Sun, 4 Nov 2012, David Sewell wrote:
>
>> I am getting the same error message. But it is totally ignorable, no?
>>
>> Here is all that I did:
>>
>> 1) Click "Upload file" in sidebar.
>>
>> 2) Upload a random XML file on my machine called Test.xml
>>
>> 3) The file uploads, and produces a file page that indeed contains an ominous
>> warning:
>>
>> http://wiki.tei-c.org/index.php/File:Test.xml
>>
>> but it doesn't prevent the file from being opened:
>>
>> http://wiki.tei-c.org/images/d/d1/Test.xml
>>
>> or referenced:
>>
>> http://wiki.tei-c.org/index.php/User:DavidSewell
>>
>> (click on link in last line).
>>
>> If an ordinary registered user can do that, we have no problem, I think.
>>
>> David
>>
>> On Sun, 4 Nov 2012, James Cummings wrote:
>>
>>>
>>> Bah I've hacked and hacked and hacked and not been able to solve this.
>>>
>>> I went through includes/SpecialUpload.php commenting out *all* the checks
>>> it does on mimetype, on whether it is an HTML file, javascript, etc. ...
>>> ihad huge functions  doing absolutely nothing but returning that everything
>>> was ok.
>>>
>>> *still* same error message.
>>>
>>> I give up until after the members meeting if you or shayne haven't fixed it
>>> by then. ;-)
>>>
>>> -James
>>>
>>>
>>> On 04/11/12 18:46, David Sewell wrote:
>>>> James,
>>>>
>>>> Thanks for tweaking the MediaWiki settings! And if anyone
>>>> continues to have problems uploading files that should be
>>>> legitimately accepted we can investigate further.
>>>>
>>>> On Sun, 4 Nov 2012, James Cummings wrote:
>>>>
>>>>>
>>>>> David (Council CC'ed),
>>>>>
>>>>> This is actually a different problem. We've always had the
>>>>> permitted file types: png, gif, jpg, jpeg, ogg, zip, xsl, xml,
>>>>> dtd, odd, rnc, rng, txt, pdf. It is just an earlier upgrade on
>>>>> media wiki introduced script checking where it (falsely)
>>>>> identifies TEI files as potentially dodgy HTML or javascript.
>>>>> I've not investigated how it does this check and why it is
>>>>> failing, but found a number of reported  bugs about it.
>>>>>
>>>>> I've set $wgDisableUploadScriptChecks to true, and explicitly
>>>>> marked non-registered users as not being able to upload (though
>>>>> I think this was our default any way).  Piotr and Kevin will
>>>>> probably advise if this results in people who shouldn't being
>>>>> able to upload files.
>>>>>
>>>>> It allowed me to, but I might have special powers.
>>>>>
>>>>> Lou: We're not talking about uploading and processing TEI files
>>>>> of any particular type, but just uploading XML files in the
>>>>> same way you might upload PDFs or PNGs, etc.  Frankly if I was
>>>>> Martin I'd probably just link to the XML file provided elsewhere.
>>>>>
>>>>> -James
>>>>>
>>>>> On 04/11/12 13:52, David Sewell wrote:
>>>>>> During the last upgrade of the TEI wiki, we ran into a PHP issue
>>>>>> or two that required changes to files on the server that were
>>>>>> root-access only, meaning Shayne needed to intervene. If that's
>>>>>> the case this time, a fix will probably need to wait until
>>>>>> Monday. But I'll take a look at things when I can today--may not
>>>>>> be until evening as I have a commitment earlier.
>>>>>>
>>>>>> On Sun, 4 Nov 2012, Piotr Ba?ski wrote:
>>>>>>
>>>>>>> Hi Martin,
>>>>>>>
>>>>>>> It might have been inadvertently changed during the upgrade of
>>>>>>> the wiki
>>>>>>> software (veeery useful, it fixed a few problems, spambots among
>>>>>>> others). David has done a great wizarding job on that,
>>>>>>> hopefully he can
>>>>>>> help with the file upload issue as well.
>>>>>>>
>>>>>>>   P.
>>>>>>>
>>>>>>> On 04/11/12 03:19, Martin Holmes wrote:
>>>>>>>> Hi all,
>>>>>>>>
>>>>>>>> I'm working on my Prefix Definition Proposal on the wiki, and
>>>>>>>> I've
>>>>>>>> drafted a new section of the Guidelines that I wanted to
>>>>>>>> include as part
>>>>>>>> of the proposal. This is a regular TEI file, including a div
>>>>>>>> which could
>>>>>>>> be inserted into the SA chapter. It's obviously easier to
>>>>>>>> write it
>>>>>>>> directly in TEI, and then insert it into the chapter if and
>>>>>>>> when it gets
>>>>>>>> approval, than to draft it in a word-processor and then have
>>>>>>>> to tag it
>>>>>>>> up afterwards.
>>>>>>>>
>>>>>>>> I wanted to upload this to the wiki so people could vet it,
>>>>>>>> but when I
>>>>>>>> tried to upload it as an XML file, the wiki said:
>>>>>>>>
>>>>>>>> "This file contains HTML or script code that may be erroneously
>>>>>>>> interpreted by a web browser."
>>>>>>>>
>>>>>>>> So I tried zipping it up (as I've done before with a script
>>>>>>>> file). This
>>>>>>>> time, it said:
>>>>>>>>
>>>>>>>> "Files of the MIME type "application/zip" are not allowed to
>>>>>>>> be uploaded."
>>>>>>>>
>>>>>>>> But the wiki upload page also says:
>>>>>>>>
>>>>>>>> "Permitted file types: png, gif, jpg, jpeg, ogg, zip, xsl,
>>>>>>>> xml, dtd,
>>>>>>>> odd, rnc, rng, txt, pdf."
>>>>>>>>
>>>>>>>> In other words, it's supposed to be able to accept both XML
>>>>>>>> and zip
>>>>>>>> files, but it won't. Someone or something must have changed
>>>>>>>> the settings
>>>>>>>> since I last uploaded a zip file last year, but not changed
>>>>>>>> the text of
>>>>>>>> the page which explains the limitations.
>>>>>>>>
>>>>>>>> I think a TEI wiki that doesn't allow us to upload XML files
>>>>>>>> is a bit
>>>>>>>> ridiculous. Could we get this changed?
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>> Martin
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>>
>>
>>
>

From kevin.s.hawkins at ultraslavonic.info  Mon Nov  5 00:13:06 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Mon, 05 Nov 2012 00:13:06 -0500
Subject: [tei-council] Uploading files to the WIKI
In-Reply-To: <5096B93D.6070604@it.ox.ac.uk>
References: <5095D0BD.5090100@uvic.ca> <509619CD.5080202@o2.pl>
	<alpine.OSX.2.00.1211040850470.7761@cewagi.local>
	<5096B748.1000709@it.ox.ac.uk>
	<alpine.OSX.2.00.1211041344560.5930@tadai.local>
	<5096B8A9.8000504@it.ox.ac.uk> <5096B93D.6070604@it.ox.ac.uk>
Message-ID: <50974AE2.9050102@ultraslavonic.info>

The wiki no longer allows anonymous editing; instead, everyone has to 
create an account.  That explains why what James did didn't make a 
difference.

Even though I agree with Martin's recent message that this isn't urgent, 
I think we should try to upgrade MediaWiki anyway so that we don't fall 
too far behind in versions.

--Kevin

On 11/4/12 1:51 PM, James Cummings wrote:
>
> ah,  I see the problem.
>
> we're running 1.16.5 and this override to the check is only
> introduced in 1.19.0
>
> Investigating workarounds,
>
> -James
>
> On 04/11/12 18:49, James Cummings wrote:
>>
>> Actually, I say that fixed it... but I don't think it did. :-(
>> (I thought it allowed me to upload but it just didn't complain...
>> but doesn't seem to have uploaded.)
>>
>> -James
>>
>> On 04/11/12 18:46, David Sewell wrote:
>>> James,
>>>
>>> Thanks for tweaking the MediaWiki settings! And if anyone
>>> continues to have problems uploading files that should be
>>> legitimately accepted we can investigate further.
>>>
>>> On Sun, 4 Nov 2012, James Cummings wrote:
>>>
>>>>
>>>> David (Council CC'ed),
>>>>
>>>> This is actually a different problem. We've always had the
>>>> permitted file types: png, gif, jpg, jpeg, ogg, zip, xsl, xml,
>>>> dtd, odd, rnc, rng, txt, pdf. It is just an earlier upgrade on
>>>> media wiki introduced script checking where it (falsely)
>>>> identifies TEI files as potentially dodgy HTML or javascript.
>>>> I've not investigated how it does this check and why it is
>>>> failing, but found a number of reported  bugs about it.
>>>>
>>>> I've set $wgDisableUploadScriptChecks to true, and explicitly
>>>> marked non-registered users as not being able to upload (though
>>>> I think this was our default any way).  Piotr and Kevin will
>>>> probably advise if this results in people who shouldn't being
>>>> able to upload files.
>>>>
>>>> It allowed me to, but I might have special powers.
>>>>
>>>> Lou: We're not talking about uploading and processing TEI files
>>>> of any particular type, but just uploading XML files in the
>>>> same way you might upload PDFs or PNGs, etc.  Frankly if I was
>>>> Martin I'd probably just link to the XML file provided elsewhere.
>>>>
>>>> -James
>>>>
>>>> On 04/11/12 13:52, David Sewell wrote:
>>>>> During the last upgrade of the TEI wiki, we ran into a PHP issue
>>>>> or two that required changes to files on the server that were
>>>>> root-access only, meaning Shayne needed to intervene. If that's
>>>>> the case this time, a fix will probably need to wait until
>>>>> Monday. But I'll take a look at things when I can today--may not
>>>>> be until evening as I have a commitment earlier.
>>>>>
>>>>> On Sun, 4 Nov 2012, Piotr Ba?ski wrote:
>>>>>
>>>>>> Hi Martin,
>>>>>>
>>>>>> It might have been inadvertently changed during the upgrade of
>>>>>> the wiki
>>>>>> software (veeery useful, it fixed a few problems, spambots among
>>>>>> others). David has done a great wizarding job on that,
>>>>>> hopefully he can
>>>>>> help with the file upload issue as well.
>>>>>>
>>>>>>    P.
>>>>>>
>>>>>> On 04/11/12 03:19, Martin Holmes wrote:
>>>>>>> Hi all,
>>>>>>>
>>>>>>> I'm working on my Prefix Definition Proposal on the wiki, and
>>>>>>> I've
>>>>>>> drafted a new section of the Guidelines that I wanted to
>>>>>>> include as part
>>>>>>> of the proposal. This is a regular TEI file, including a div
>>>>>>> which could
>>>>>>> be inserted into the SA chapter. It's obviously easier to
>>>>>>> write it
>>>>>>> directly in TEI, and then insert it into the chapter if and
>>>>>>> when it gets
>>>>>>> approval, than to draft it in a word-processor and then have
>>>>>>> to tag it
>>>>>>> up afterwards.
>>>>>>>
>>>>>>> I wanted to upload this to the wiki so people could vet it,
>>>>>>> but when I
>>>>>>> tried to upload it as an XML file, the wiki said:
>>>>>>>
>>>>>>> "This file contains HTML or script code that may be erroneously
>>>>>>> interpreted by a web browser."
>>>>>>>
>>>>>>> So I tried zipping it up (as I've done before with a script
>>>>>>> file). This
>>>>>>> time, it said:
>>>>>>>
>>>>>>> "Files of the MIME type "application/zip" are not allowed to
>>>>>>> be uploaded."
>>>>>>>
>>>>>>> But the wiki upload page also says:
>>>>>>>
>>>>>>> "Permitted file types: png, gif, jpg, jpeg, ogg, zip, xsl,
>>>>>>> xml, dtd,
>>>>>>> odd, rnc, rng, txt, pdf."
>>>>>>>
>>>>>>> In other words, it's supposed to be able to accept both XML
>>>>>>> and zip
>>>>>>> files, but it won't. Someone or something must have changed
>>>>>>> the settings
>>>>>>> since I last uploaded a zip file last year, but not changed
>>>>>>> the text of
>>>>>>> the page which explains the limitations.
>>>>>>>
>>>>>>> I think a TEI wiki that doesn't allow us to upload XML files
>>>>>>> is a bit
>>>>>>> ridiculous. Could we get this changed?
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Martin
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>
>>
>
>

From kevin.s.hawkins at ultraslavonic.info  Mon Nov  5 00:49:18 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Mon, 05 Nov 2012 00:49:18 -0500
Subject: [tei-council] biblscope and imprint
In-Reply-To: <50966524.5010708@retired.ox.ac.uk>
References: <5093A831.7080901@retired.ox.ac.uk>
	<5093D8C8.6090209@ultraslavonic.info>	<5093DDC7.1050504@kcl.ac.uk>
	<5093E2BB.6010106@ultraslavonic.info>	<50940D9A.7030007@retired.ox.ac.uk>
	<5095017A.8060903@retired.ox.ac.uk>	<50952166.2060305@ultraslavonic.info>
	<5095A6B4.2080307@retired.ox.ac.uk>
	<5095BFB8.2050101@ultraslavonic.info>
	<5095C121.1010600@uvic.ca> <50966524.5010708@retired.ox.ac.uk>
Message-ID: <5097535E.7060204@ultraslavonic.info>

On 11/4/12 7:52 AM, Lou Burnard wrote:
> Firstly the comment that using "ru" for Russian transliterated in Roman
> characters is simply "underspecified" seems to me rather to miss the
> point. If I see something in a Unicode document which says it has
> xml:lang="ru" I expect to see proper Russian Unicode characters.

Perhaps.  I meant that while you might think that, it wasn't clear to me 
that the semantics of @xml:lang license that inference.  However, once I 
looked at BCP 47 and the discussion of "suppress script" further, I 
think it might indeed license Lou's inference.

> Secondly, even if I am prepared to accept Romanized versions of those
> characters and figure out for myself what the Russian should have been,
> this is not entirely easy. There are several different (Wikipedia lists
> ten) possible Romanization schemes, which vary quite considerably. In
> some, for example, the sequence "ye" stands for the Russian letter that
> looks like a Roman "e"; in others this character is represented by "e",
> unless it is iotated by a preceding soft sign. So generating a correct
> Cyrillic version of this citation isn't easy, and neither is deciding
> which scheme we're dealing with here!

BCP 47 allows for registering of variant subtags for systems of 
transliteration, but it does not require this.  However, per the 
discussion of "suppress script", it seems you effectively need to for 
transliteration.

This is puzzling.

> Thirdly, this particular example is actually taken verbatim from a
> rather elderly ISO standard on bibliographic reference (ISO 690, 1987).
>    Hence we probably should not mess with its representation at all.

I fully agree that as long as we are citing a citation in a source 
document, we shouldn't go de-transliterating it!

 >  (You
> can see it cited as a example in the Wikipedia entry for ISO_690,
>curiously enough).

I imagine that someone writing or improving the Wikipedia article on ISO 
690 googled around to see what they could find and stumbled upon the 
Guidelines ...

> My guess, but I defer to the Russian expert in our midst, is that this
> uses the now deprecated ISO/R:1968 but without access to the original,
> it's hard to be sure, and without being sure I'd rather not try to
> convert it into proper Russian.

Well, it looks like Lou not only tried, but as your resident Russian 
expert I can say that he also succeeded.

> All of which I suppose we can side-step cheerfully, by saying "ru-Latn",
> even though this particular combination isn't actually proposed in
> http://www.iana.org/assignments/language-subtag-registry, and even
> though this won't help anyone who *does* want to see the original title
> as it should have been presented!

I, like Martin in a later message, used to think that BCP 47 allowed for 
the various types of tags to be combined as you see fit, meaning that 
"ru-Latn" would be allowed.  But a closer reading of BCP 47 now makes me 
think that you can only use things in the IANA registry unless you use a 
private use subtag.

We could bring in Syd Bauman or Deborah Anderson to help us sort this 
out, or we could take a shortcut by simply removing the @xml:lang on 
this transliterated title.

--Kevin

From James.Cummings at it.ox.ac.uk  Mon Nov  5 04:32:19 2012
From: James.Cummings at it.ox.ac.uk (James Cummings)
Date: Mon, 05 Nov 2012 09:32:19 +0000
Subject: [tei-council] Uploading files to the WIKI (fwd)
In-Reply-To: <50973DD9.3070109@uvic.ca>
References: <alpine.OSX.2.00.1211042051220.8000@tadai.local>
	<alpine.OSX.2.00.1211042112120.8000@tadai.local>
	<50973DD9.3070109@uvic.ca>
Message-ID: <509787A3.8010309@it.ox.ac.uk>


As did we... I think it is an important thing to change, but it 
is non-urgent. I've suggested to David that we have Shayne 
upgrade mediawiki sometime after the members meeting.

-James


On 05/11/12 04:17, Martin Holmes wrote:
> I'm feeling a bit guilty about how much effort David and James are
> putting into this now. I figured it was just a setting that got
> inadvertently turned off. If it's not straightforward, please don't put
> any more time into it.
>
> Cheers,
> Martin
>
> On 12-11-04 06:17 PM, David Sewell wrote:
>> Sorry: having just created a temporary wiki account lacking
>> administrator privileges, I see that upload of the XML file is not only
>> warned but prevented.
>>
>> It may be that upgrading WikiMedia is the only fix. But I'll poke around
>> some more as well.
>>
>> David
>>
>> On Sun, 4 Nov 2012, David Sewell wrote:
>>
>>> I am getting the same error message. But it is totally ignorable, no?
>>>
>>> Here is all that I did:
>>>
>>> 1) Click "Upload file" in sidebar.
>>>
>>> 2) Upload a random XML file on my machine called Test.xml
>>>
>>> 3) The file uploads, and produces a file page that indeed contains an ominous
>>> warning:
>>>
>>> http://wiki.tei-c.org/index.php/File:Test.xml
>>>
>>> but it doesn't prevent the file from being opened:
>>>
>>> http://wiki.tei-c.org/images/d/d1/Test.xml
>>>
>>> or referenced:
>>>
>>> http://wiki.tei-c.org/index.php/User:DavidSewell
>>>
>>> (click on link in last line).
>>>
>>> If an ordinary registered user can do that, we have no problem, I think.
>>>
>>> David
>>>
>>> On Sun, 4 Nov 2012, James Cummings wrote:
>>>
>>>>
>>>> Bah I've hacked and hacked and hacked and not been able to solve this.
>>>>
>>>> I went through includes/SpecialUpload.php commenting out *all* the checks
>>>> it does on mimetype, on whether it is an HTML file, javascript, etc. ...
>>>> ihad huge functions  doing absolutely nothing but returning that everything
>>>> was ok.
>>>>
>>>> *still* same error message.
>>>>
>>>> I give up until after the members meeting if you or shayne haven't fixed it
>>>> by then. ;-)
>>>>
>>>> -James
>>>>
>>>>
>>>> On 04/11/12 18:46, David Sewell wrote:
>>>>> James,
>>>>>
>>>>> Thanks for tweaking the MediaWiki settings! And if anyone
>>>>> continues to have problems uploading files that should be
>>>>> legitimately accepted we can investigate further.
>>>>>
>>>>> On Sun, 4 Nov 2012, James Cummings wrote:
>>>>>
>>>>>>
>>>>>> David (Council CC'ed),
>>>>>>
>>>>>> This is actually a different problem. We've always had the
>>>>>> permitted file types: png, gif, jpg, jpeg, ogg, zip, xsl, xml,
>>>>>> dtd, odd, rnc, rng, txt, pdf. It is just an earlier upgrade on
>>>>>> media wiki introduced script checking where it (falsely)
>>>>>> identifies TEI files as potentially dodgy HTML or javascript.
>>>>>> I've not investigated how it does this check and why it is
>>>>>> failing, but found a number of reported  bugs about it.
>>>>>>
>>>>>> I've set $wgDisableUploadScriptChecks to true, and explicitly
>>>>>> marked non-registered users as not being able to upload (though
>>>>>> I think this was our default any way).  Piotr and Kevin will
>>>>>> probably advise if this results in people who shouldn't being
>>>>>> able to upload files.
>>>>>>
>>>>>> It allowed me to, but I might have special powers.
>>>>>>
>>>>>> Lou: We're not talking about uploading and processing TEI files
>>>>>> of any particular type, but just uploading XML files in the
>>>>>> same way you might upload PDFs or PNGs, etc.  Frankly if I was
>>>>>> Martin I'd probably just link to the XML file provided elsewhere.
>>>>>>
>>>>>> -James
>>>>>>
>>>>>> On 04/11/12 13:52, David Sewell wrote:
>>>>>>> During the last upgrade of the TEI wiki, we ran into a PHP issue
>>>>>>> or two that required changes to files on the server that were
>>>>>>> root-access only, meaning Shayne needed to intervene. If that's
>>>>>>> the case this time, a fix will probably need to wait until
>>>>>>> Monday. But I'll take a look at things when I can today--may not
>>>>>>> be until evening as I have a commitment earlier.
>>>>>>>
>>>>>>> On Sun, 4 Nov 2012, Piotr Ba?ski wrote:
>>>>>>>
>>>>>>>> Hi Martin,
>>>>>>>>
>>>>>>>> It might have been inadvertently changed during the upgrade of
>>>>>>>> the wiki
>>>>>>>> software (veeery useful, it fixed a few problems, spambots among
>>>>>>>> others). David has done a great wizarding job on that,
>>>>>>>> hopefully he can
>>>>>>>> help with the file upload issue as well.
>>>>>>>>
>>>>>>>>    P.
>>>>>>>>
>>>>>>>> On 04/11/12 03:19, Martin Holmes wrote:
>>>>>>>>> Hi all,
>>>>>>>>>
>>>>>>>>> I'm working on my Prefix Definition Proposal on the wiki, and
>>>>>>>>> I've
>>>>>>>>> drafted a new section of the Guidelines that I wanted to
>>>>>>>>> include as part
>>>>>>>>> of the proposal. This is a regular TEI file, including a div
>>>>>>>>> which could
>>>>>>>>> be inserted into the SA chapter. It's obviously easier to
>>>>>>>>> write it
>>>>>>>>> directly in TEI, and then insert it into the chapter if and
>>>>>>>>> when it gets
>>>>>>>>> approval, than to draft it in a word-processor and then have
>>>>>>>>> to tag it
>>>>>>>>> up afterwards.
>>>>>>>>>
>>>>>>>>> I wanted to upload this to the wiki so people could vet it,
>>>>>>>>> but when I
>>>>>>>>> tried to upload it as an XML file, the wiki said:
>>>>>>>>>
>>>>>>>>> "This file contains HTML or script code that may be erroneously
>>>>>>>>> interpreted by a web browser."
>>>>>>>>>
>>>>>>>>> So I tried zipping it up (as I've done before with a script
>>>>>>>>> file). This
>>>>>>>>> time, it said:
>>>>>>>>>
>>>>>>>>> "Files of the MIME type "application/zip" are not allowed to
>>>>>>>>> be uploaded."
>>>>>>>>>
>>>>>>>>> But the wiki upload page also says:
>>>>>>>>>
>>>>>>>>> "Permitted file types: png, gif, jpg, jpeg, ogg, zip, xsl,
>>>>>>>>> xml, dtd,
>>>>>>>>> odd, rnc, rng, txt, pdf."
>>>>>>>>>
>>>>>>>>> In other words, it's supposed to be able to accept both XML
>>>>>>>>> and zip
>>>>>>>>> files, but it won't. Someone or something must have changed
>>>>>>>>> the settings
>>>>>>>>> since I last uploaded a zip file last year, but not changed
>>>>>>>>> the text of
>>>>>>>>> the page which explains the limitations.
>>>>>>>>>
>>>>>>>>> I think a TEI wiki that doesn't allow us to upload XML files
>>>>>>>>> is a bit
>>>>>>>>> ridiculous. Could we get this changed?
>>>>>>>>>
>>>>>>>>> Cheers,
>>>>>>>>> Martin
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>


-- 
Dr James Cummings, researchsupport at it.ox.ac.uk
Research Support, IT Services, University of Oxford

From gabriel.bodard at kcl.ac.uk  Mon Nov  5 06:40:41 2012
From: gabriel.bodard at kcl.ac.uk (Gabriel Bodard)
Date: Mon, 5 Nov 2012 11:40:41 +0000
Subject: [tei-council] biblscope and imprint
In-Reply-To: <5095A6B4.2080307@retired.ox.ac.uk>
References: <5093A831.7080901@retired.ox.ac.uk>	<5093D8C8.6090209@ultraslavonic.info>
	<5093DDC7.1050504@kcl.ac.uk> <5093E2BB.6010106@ultraslavonic.info>
	<50940D9A.7030007@retired.ox.ac.uk>
	<5095017A.8060903@retired.ox.ac.uk>
	<50952166.2060305@ultraslavonic.info>
	<5095A6B4.2080307@retired.ox.ac.uk>
Message-ID: <5097A5B9.70402@kcl.ac.uk>

Just to be sure I understand what we're saying now:

  * Kevin and I had originally proposed to include in the analytic the 
page range taken up by it in the following monogr (and so forth; the 
volume-range of a monogr in the following series, ecc.);
  * Lou quite rightly pointed out that this is impossible because an 
analytic might appear in two different monogrs with different page 
numbering;
  * we are now proposing instead that a biblScope should be contained in 
the element that is being limited by it (e.g. in the monogr a subset of 
whose pages make up the preceding analytic).

Actually, looking at ticket http://purl.org/tei/FR/3555190, I see this 
is how we encoded the Schachter example, so the biblScope in analytic 
model was obviously already abandoned before August. So that's not the 
controversy at all. :-|

Kevin's markup below looks right to me, and I agree that biblScope 
doesn't belong in imprint, since the volume or page range is not part of 
the publication information. I'm looking slightly askance at the page, 
volume and issue biblScopes all being at the same level, but I can't 
think of any better way to do it.

I'm still concerned about our Schachter example on the ticket, however. 
I totally take Lou's point that 2 monogrs in a single biblStruct would 
normally mean the chapter/article appears twice in two different 
publications. How would we then mark up the case we have here, which is 
an article in a volume in a multi-vol monograph in a series?

(And how would you handle an article that appears in two different 
monographs, each part of a different series.)

The only way I can think of to handle both of these cases unambiguously 
would be to nest analytic, monogr and series as appropriate, but that 
would be a huge change to the way biblStruct currently works, so I 
suspect would not be at all popular.

(For the simpler case, however, I think we're all in agreement.)

G



On 2012-11-03 23:20, Lou Burnard wrote:
> I've now checked in a revised CO which I think addresses these concerns,
> but am leaving the ticket open till Gabby has also had a chance to check
> this out.
>
>
>
> On 03/11/12 13:51, Kevin Hawkins wrote:
>> Ugh, Gabby and I both misremembered the proposal at
>> http://purl.org/tei/FR/3555190 .  Lou is right that according to that
>> proposal, there is never a <biblScope> in <analytic>, so the Chestnutt
>> citation encoded according to the proposal would be:
>>
>> <biblStruct>
>>      <analytic>
>>        <author>Chesnutt, David</author>
>>        <title>Historical Editions in the States</title>
>>      </analytic>
>>      <monogr>
>>        <title level="j">Computers and the Humanities</title>
>>        <imprint>
>>          <date when="1991-12">(December, 1991):</date>
>>        </imprint>
>>        <biblScope type="vol">25</biblScope>
>>        <biblScope type="issue">6</biblScope>
>>        <biblScope type="pp">377?380</biblScope>
>>      </monogr>
>> </biblStruct>
>>
>> (which is more or less how I first wrote it below).
>>
>> On 11/3/12 7:35 AM, Lou Burnard wrote:
>>> Looking at this suggestion again: surely it cannot ever be right to put
>>> a <biblScope> within an <analytic> ?
>>>
>>> See further my comment on the ticket -- specifically
>>>
>>> "I think the sentence "Each <biblScope> describes where (within its
>>> parent element) to find the thing in the previous level" is correct, but
>>> only if you understand the word "level" as "preceding sibling of a
>>> different bibliographic level"
>>>
>>> Hence the pagination biblScope ought to go within the monogr, not within
>>> the analytic. This also makes sense if the same article appears in two
>>> different monogrs, possibly with different pagination.
>>>
>>>
>>>
>>> On 02/11/12 18:14, Lou Burnard wrote:
>>>> On 02/11/12 15:11, Kevin Hawkins wrote:
>>>>> Gabby's right. I was focusing on placement of <biblScope> in relation to
>>>>> <imprint>.  So Lou's citation (from the Guidelines) would in fact be:
>>>>>
>>>>> <biblStruct>
>>>>>         <analytic>
>>>>>           <author>Chesnutt, David</author>
>>>>>           <title>Historical Editions in the States</title>
>>>>>           <biblScope type="pp">377?380</biblScope>
>>>>>         </analytic>
>>>>>         <monogr>
>>>>>           <title level="j">Computers and the Humanities</title>
>>>>>           <imprint>
>>>>>             <date when="1991-12">(December, 1991):</date>
>>>>>           </imprint>
>>>>>           <biblScope type="vol">25</biblScope>
>>>>>           <biblScope type="issue">6</biblScope>
>>>>>         </monogr>
>>>>> </biblStruct>
>>>>>
>>>>> On 11/2/2012 10:50 AM, Gabriel Bodard wrote:
>>>>>> Is that what we proposed?
>>>>>>
>>>>>> I thought I remembered we had suggested to put the biblScope in the
>>>>>> element whose scope is being defined by it, so<biblScope type="pp">
>>>>>> goes in<analytic>  because the article is only pages 377-380 of the
>>>>>> volume in question, and<biblScope type="issue">  goes in<monogr>
>>>>>> because this volume is only issue 25.6 of the journal....
>>>>>>
>>>>>> But looking at this stuff I find myself more and more agreeing with
>>>>>> Martin that biblStruct was never a good idea. ;-)
>>>>>>
>>>>>> G
>>>>>>
>>>>>> On 2012-11-02 14:29, Kevin Hawkins wrote:
>>>>>>> The ticket proposes putting<biblScope>s after the<imprint>  element
>>>>>>> when its present.  So your example would now be encoded as:
>>>>>>>
>>>>>>> <biblStruct>
>>>>>>>           <analytic>
>>>>>>>             <author>Chesnutt, David</author>
>>>>>>>             <title>Historical Editions in the States</title>
>>>>>>>           </analytic>
>>>>>>>           <monogr>
>>>>>>>             <title level="j">Computers and the Humanities</title>
>>>>>>>             <imprint>
>>>>>>>               <date when="1991-12">(December, 1991):</date>
>>>>>>>             </imprint>
>>>>>>>             <biblScope>25.6</biblScope>
>>>>>>>             <biblScope>377?380</biblScope>
>>>>>>>           </monogr>
>>>>>>> </biblStruct>
>>>>>>>
>>>>>>> --Kevin
>>>>>>>
>>>>>>> On 11/2/2012 7:02 AM, Lou Burnard wrote:
>>>>>>>> Tootling across france on the train yesterday I started trying to deal
>>>>>>>> with http://purl.org/tei/FR/3555190...
>>>>>>>>
>>>>>>>> The part about the scope of biblscope was fairly easy to add, as was
>>>>>>>> guidance on usage of biblScope. But I hit a problem with the second
>>>>>>>> part, where it says that biblScope doesn't belong inside<imprint>   --
>>>>>>>> the logic behind that desire is impeccable, but it messes up an awful
>>>>>>>> lot of out current practice.
>>>>>>>>
>>>>>>>> Consider the following:
>>>>>>>>
>>>>>>>> <biblStruct>
>>>>>>>> <analytic>
>>>>>>>> <author>Chesnutt, David</author>
>>>>>>>> <title>Historical Editions in the States</title>
>>>>>>>> </analytic>
>>>>>>>> <monogr>
>>>>>>>> <title level="j">Computers and the Humanities</title>
>>>>>>>> <imprint>
>>>>>>>> <biblScope>25.6</biblScope>
>>>>>>>> <date when="1991-12">(December, 1991):</date>
>>>>>>>> <biblScope>377?380</biblScope>
>>>>>>>> </imprint>
>>>>>>>> </monogr>
>>>>>>>> </biblStruct>
>>>>>>>>
>>>>>>>> which is a fairly common pattern in P5 (and appears as the canonical
>>>>>>>> example for<imprint>)
>>>>>>>>
>>>>>>>> If, following FR 3555190, we think<biblStruct>   has no place within
>>>>>>>> <imprint>, how should
>>>>>>>> this, and many similar cases, be tagged?
>>>>>>>>
>>>>>>>> One possibility might be
>>>>>>>>
>>>>>>>> <monogr>
>>>>>>>> <title level="j">Computers and the Humanities</title>
>>>>>>>> <biblScope>25.6</biblScope>
>>>>>>>> <biblScope>377?380</biblScope>
>>>>>>>> <imprint>
>>>>>>>> <date when="1991-12">(December, 1991):</date>
>>>>>>>> </imprint>
>>>>>>>> </monogr>
>>>>>>>>
>>>>>>>> Another might be
>>>>>>>>
>>>>>>>> <monogr>
>>>>>>>> <title level="j">Computers and the Humanities</title>
>>>>>>>> <biblScope>25.6</biblScope>
>>>>>>>> <biblScope>377?380</biblScope>
>>>>>>>> <biblScope type="date">(December, 1991)</biblScope>
>>>>>>>> </imprint>
>>>>>>>> </monogr>
>>>>>>>>
>>>>>>>> or perhaps better
>>>>>>>>
>>>>>>>> <biblScope><date when="1991-12">(December, 1991)</date></biblScope>
>>>>>>>>
>>>>>>>>
>>>>>>>> Another might be to tweak the content model so that
>>>>>>>> model.dateLike is permitted outside<imprint>   and alongside<biblScope>
>>>>>>>>
>>>>>>>> And another might be to reconsider the decision to remove<biblScope>
>>>>>>>> from within<imprint>
>>>>>>>>
>>>>>>>> Any ideas? Everyone braced for the rush of complaints?
>>>>>>>>
>

-- 
Dr Gabriel BODARD
Researcher in Digital Epigraphy

Digital Humanities
King's College London
26-29 Drury Lane
London WC2B 5RL

T: +44 (0)20 7848 1388
F: +44 (0)20 7848 2980
E: gabriel.bodard at kcl.ac.uk

http://www.digitalclassicist.org/
http://www.currentepigraphy.org/


From mholmes at uvic.ca  Mon Nov  5 08:25:22 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Mon, 05 Nov 2012 05:25:22 -0800
Subject: [tei-council] biblscope and imprint
In-Reply-To: <5097535E.7060204@ultraslavonic.info>
References: <5093A831.7080901@retired.ox.ac.uk>
	<5093D8C8.6090209@ultraslavonic.info>	<5093DDC7.1050504@kcl.ac.uk>
	<5093E2BB.6010106@ultraslavonic.info>	<50940D9A.7030007@retired.ox.ac.uk>
	<5095017A.8060903@retired.ox.ac.uk>	<50952166.2060305@ultraslavonic.info>
	<5095A6B4.2080307@retired.ox.ac.uk>	<5095BFB8.2050101@ultraslavonic.info>
	<5095C121.1010600@uvic.ca> <50966524.5010708@retired.ox.ac.uk>
	<5097535E.7060204@ultraslavonic.info>
Message-ID: <5097BE42.4080908@uvic.ca>

The W3C guide to using language subtags actually uses ru-Latn as the 
specific example for script subtags:

"Script subtags should only be used as part of a language tag when the 
script adds some useful distinguishing information to the tag. Usually 
this is because a language is written in more than one script or because 
the content has been transcribed into a script that is unusual to the 
language (so one might tag Russian transcribed into the Latin script 
with a tag such as ru-Latn)."

<http://www.w3.org/International/questions/qa-choosing-language-tags>

So I think Kevin might be misunderstanding BCP 47, and ru-Latn should be 
used.

Cheers,
Martin

On 12-11-04 09:49 PM, Kevin Hawkins wrote:
> On 11/4/12 7:52 AM, Lou Burnard wrote:
>> Firstly the comment that using "ru" for Russian transliterated in Roman
>> characters is simply "underspecified" seems to me rather to miss the
>> point. If I see something in a Unicode document which says it has
>> xml:lang="ru" I expect to see proper Russian Unicode characters.
>
> Perhaps.  I meant that while you might think that, it wasn't clear to me
> that the semantics of @xml:lang license that inference.  However, once I
> looked at BCP 47 and the discussion of "suppress script" further, I
> think it might indeed license Lou's inference.
>
>> Secondly, even if I am prepared to accept Romanized versions of those
>> characters and figure out for myself what the Russian should have been,
>> this is not entirely easy. There are several different (Wikipedia lists
>> ten) possible Romanization schemes, which vary quite considerably. In
>> some, for example, the sequence "ye" stands for the Russian letter that
>> looks like a Roman "e"; in others this character is represented by "e",
>> unless it is iotated by a preceding soft sign. So generating a correct
>> Cyrillic version of this citation isn't easy, and neither is deciding
>> which scheme we're dealing with here!
>
> BCP 47 allows for registering of variant subtags for systems of
> transliteration, but it does not require this.  However, per the
> discussion of "suppress script", it seems you effectively need to for
> transliteration.
>
> This is puzzling.
>
>> Thirdly, this particular example is actually taken verbatim from a
>> rather elderly ISO standard on bibliographic reference (ISO 690, 1987).
>>     Hence we probably should not mess with its representation at all.
>
> I fully agree that as long as we are citing a citation in a source
> document, we shouldn't go de-transliterating it!
>
>   >  (You
>> can see it cited as a example in the Wikipedia entry for ISO_690,
>> curiously enough).
>
> I imagine that someone writing or improving the Wikipedia article on ISO
> 690 googled around to see what they could find and stumbled upon the
> Guidelines ...
>
>> My guess, but I defer to the Russian expert in our midst, is that this
>> uses the now deprecated ISO/R:1968 but without access to the original,
>> it's hard to be sure, and without being sure I'd rather not try to
>> convert it into proper Russian.
>
> Well, it looks like Lou not only tried, but as your resident Russian
> expert I can say that he also succeeded.
>
>> All of which I suppose we can side-step cheerfully, by saying "ru-Latn",
>> even though this particular combination isn't actually proposed in
>> http://www.iana.org/assignments/language-subtag-registry, and even
>> though this won't help anyone who *does* want to see the original title
>> as it should have been presented!
>
> I, like Martin in a later message, used to think that BCP 47 allowed for
> the various types of tags to be combined as you see fit, meaning that
> "ru-Latn" would be allowed.  But a closer reading of BCP 47 now makes me
> think that you can only use things in the IANA registry unless you use a
> private use subtag.
>
> We could bring in Syd Bauman or Deborah Anderson to help us sort this
> out, or we could take a shortcut by simply removing the @xml:lang on
> this transliterated title.
>
> --Kevin
>

-- 
Martin Holmes
mholmes at uvic.ca
UVic Humanities Computing and Media Centre

From kevin.s.hawkins at ultraslavonic.info  Mon Nov  5 09:29:48 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Mon, 05 Nov 2012 09:29:48 -0500
Subject: [tei-council] biblscope and imprint
In-Reply-To: <5097BE42.4080908@uvic.ca>
References: <5093A831.7080901@retired.ox.ac.uk>
	<5093D8C8.6090209@ultraslavonic.info>	<5093DDC7.1050504@kcl.ac.uk>
	<5093E2BB.6010106@ultraslavonic.info>	<50940D9A.7030007@retired.ox.ac.uk>
	<5095017A.8060903@retired.ox.ac.uk>	<50952166.2060305@ultraslavonic.info>
	<5095A6B4.2080307@retired.ox.ac.uk>	<5095BFB8.2050101@ultraslavonic.info>
	<5095C121.1010600@uvic.ca> <50966524.5010708@retired.ox.ac.uk>
	<5097535E.7060204@ultraslavonic.info> <5097BE42.4080908@uvic.ca>
Message-ID: <5097CD5C.2030206@ultraslavonic.info>

That document is helpful.  What wasn't clear to me about BCP 47 is 
whether you could only use a script subtag in combination with a 
language subtag if they were listed in combination in the IANA registry 
(as some are).  Whereas this W3C guide explicitly says you can only use 
extended language subtags with certain languages, I see that it 
explicitly says you can use a script subtag with any language when it's 
not written in the script given for "suppress script".  And, as we see, 
it even gives the examples of Russian "transcribed into the Latin script".

So if you encounter "ru-Latn", you're stuck figuring out which 
transliteration scheme was used (or whether the author just invented one).

--Kevin

On 11/5/12 8:25 AM, Martin Holmes wrote:
> The W3C guide to using language subtags actually uses ru-Latn as the
> specific example for script subtags:
>
> "Script subtags should only be used as part of a language tag when the
> script adds some useful distinguishing information to the tag. Usually
> this is because a language is written in more than one script or because
> the content has been transcribed into a script that is unusual to the
> language (so one might tag Russian transcribed into the Latin script
> with a tag such as ru-Latn)."
>
> <http://www.w3.org/International/questions/qa-choosing-language-tags>
>
> So I think Kevin might be misunderstanding BCP 47, and ru-Latn should be
> used.
>
> Cheers,
> Martin
>
> On 12-11-04 09:49 PM, Kevin Hawkins wrote:
>> On 11/4/12 7:52 AM, Lou Burnard wrote:
>>> Firstly the comment that using "ru" for Russian transliterated in Roman
>>> characters is simply "underspecified" seems to me rather to miss the
>>> point. If I see something in a Unicode document which says it has
>>> xml:lang="ru" I expect to see proper Russian Unicode characters.
>>
>> Perhaps.  I meant that while you might think that, it wasn't clear to me
>> that the semantics of @xml:lang license that inference.  However, once I
>> looked at BCP 47 and the discussion of "suppress script" further, I
>> think it might indeed license Lou's inference.
>>
>>> Secondly, even if I am prepared to accept Romanized versions of those
>>> characters and figure out for myself what the Russian should have been,
>>> this is not entirely easy. There are several different (Wikipedia lists
>>> ten) possible Romanization schemes, which vary quite considerably. In
>>> some, for example, the sequence "ye" stands for the Russian letter that
>>> looks like a Roman "e"; in others this character is represented by "e",
>>> unless it is iotated by a preceding soft sign. So generating a correct
>>> Cyrillic version of this citation isn't easy, and neither is deciding
>>> which scheme we're dealing with here!
>>
>> BCP 47 allows for registering of variant subtags for systems of
>> transliteration, but it does not require this.  However, per the
>> discussion of "suppress script", it seems you effectively need to for
>> transliteration.
>>
>> This is puzzling.
>>
>>> Thirdly, this particular example is actually taken verbatim from a
>>> rather elderly ISO standard on bibliographic reference (ISO 690, 1987).
>>>      Hence we probably should not mess with its representation at all.
>>
>> I fully agree that as long as we are citing a citation in a source
>> document, we shouldn't go de-transliterating it!
>>
>>    >  (You
>>> can see it cited as a example in the Wikipedia entry for ISO_690,
>>> curiously enough).
>>
>> I imagine that someone writing or improving the Wikipedia article on ISO
>> 690 googled around to see what they could find and stumbled upon the
>> Guidelines ...
>>
>>> My guess, but I defer to the Russian expert in our midst, is that this
>>> uses the now deprecated ISO/R:1968 but without access to the original,
>>> it's hard to be sure, and without being sure I'd rather not try to
>>> convert it into proper Russian.
>>
>> Well, it looks like Lou not only tried, but as your resident Russian
>> expert I can say that he also succeeded.
>>
>>> All of which I suppose we can side-step cheerfully, by saying "ru-Latn",
>>> even though this particular combination isn't actually proposed in
>>> http://www.iana.org/assignments/language-subtag-registry, and even
>>> though this won't help anyone who *does* want to see the original title
>>> as it should have been presented!
>>
>> I, like Martin in a later message, used to think that BCP 47 allowed for
>> the various types of tags to be combined as you see fit, meaning that
>> "ru-Latn" would be allowed.  But a closer reading of BCP 47 now makes me
>> think that you can only use things in the IANA registry unless you use a
>> private use subtag.
>>
>> We could bring in Syd Bauman or Deborah Anderson to help us sort this
>> out, or we could take a shortcut by simply removing the @xml:lang on
>> this transliterated title.
>>
>> --Kevin
>>
>

From kevin.s.hawkins at ultraslavonic.info  Mon Nov  5 09:32:18 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Mon, 05 Nov 2012 09:32:18 -0500
Subject: [tei-council] biblscope and imprint
In-Reply-To: <5097A5B9.70402@kcl.ac.uk>
References: <5093A831.7080901@retired.ox.ac.uk>	<5093D8C8.6090209@ultraslavonic.info>
	<5093DDC7.1050504@kcl.ac.uk> <5093E2BB.6010106@ultraslavonic.info>
	<50940D9A.7030007@retired.ox.ac.uk>
	<5095017A.8060903@retired.ox.ac.uk>
	<50952166.2060305@ultraslavonic.info>
	<5095A6B4.2080307@retired.ox.ac.uk> <5097A5B9.70402@kcl.ac.uk>
Message-ID: <5097CDF2.30005@ultraslavonic.info>



On 11/5/12 6:40 AM, Gabriel Bodard wrote:
> Just to be sure I understand what we're saying now:
>
>    * Kevin and I had originally proposed to include in the analytic the
> page range taken up by it in the following monogr (and so forth; the
> volume-range of a monogr in the following series, ecc.);
>    * Lou quite rightly pointed out that this is impossible because an
> analytic might appear in two different monogrs with different page
> numbering;
>    * we are now proposing instead that a biblScope should be contained in
> the element that is being limited by it (e.g. in the monogr a subset of
> whose pages make up the preceding analytic).
>
> Actually, looking at ticket http://purl.org/tei/FR/3555190, I see this
> is how we encoded the Schachter example, so the biblScope in analytic
> model was obviously already abandoned before August. So that's not the
> controversy at all. :-|

Yes, Lou and I both confused either other on this.

> Kevin's markup below looks right to me, and I agree that biblScope
> doesn't belong in imprint, since the volume or page range is not part of
> the publication information. I'm looking slightly askance at the page,
> volume and issue biblScopes all being at the same level, but I can't
> think of any better way to do it.
>
> I'm still concerned about our Schachter example on the ticket, however.
> I totally take Lou's point that 2 monogrs in a single biblStruct would
> normally mean the chapter/article appears twice in two different
> publications. How would we then mark up the case we have here, which is
> an article in a volume in a multi-vol monograph in a series?
>
> (And how would you handle an article that appears in two different
> monographs, each part of a different series.)
>
> The only way I can think of to handle both of these cases unambiguously
> would be to nest analytic, monogr and series as appropriate, but that
> would be a huge change to the way biblStruct currently works, so I
> suspect would not be at all popular.
>
> (For the simpler case, however, I think we're all in agreement.)

My previous suggestion was to use some sort of pointer mechanism to tie 
a particular <analytic> to a particular <monogr>.

--Kevin

From gabriel.bodard at kcl.ac.uk  Mon Nov  5 09:39:32 2012
From: gabriel.bodard at kcl.ac.uk (Gabriel Bodard)
Date: Mon, 5 Nov 2012 14:39:32 +0000
Subject: [tei-council] biblscope and imprint
In-Reply-To: <5097CDF2.30005@ultraslavonic.info>
References: <5093A831.7080901@retired.ox.ac.uk>	<5093D8C8.6090209@ultraslavonic.info>
	<5093DDC7.1050504@kcl.ac.uk> <5093E2BB.6010106@ultraslavonic.info>
	<50940D9A.7030007@retired.ox.ac.uk>
	<5095017A.8060903@retired.ox.ac.uk>
	<50952166.2060305@ultraslavonic.info>
	<5095A6B4.2080307@retired.ox.ac.uk> <5097A5B9.70402@kcl.ac.uk>
	<5097CDF2.30005@ultraslavonic.info>
Message-ID: <5097CFA4.3090402@kcl.ac.uk>

On 2012-11-05 14:32, Kevin Hawkins wrote:
> Yes, Lou and I both confused either other on this.

I think I played my part in confusing things. ;-)

>> I'm still concerned about our Schachter example on the ticket, however.
>> I totally take Lou's point that 2 monogrs in a single biblStruct would
>> normally mean the chapter/article appears twice in two different
>> publications. How would we then mark up the case we have here, which is
>> an article in a volume in a multi-vol monograph in a series?
>>
>> (And how would you handle an article that appears in two different
>> monographs, each part of a different series.)
 >
> My previous suggestion was to use some sort of pointer mechanism to tie
> a particular <analytic> to a particular <monogr>.

That answers the use case of two monogrs being tied to two series, but 
what of chapter->volume->monograph->series?

In other words:

<bibStruct>
    <analytic/>
    <monogr/>
    <series/>
    <monogr/>
    <series/>
</bibStruct>

is fine (except possibly for the order of the elements?), representing a 
chapter that appears in two places; but

<bibStruct>
    <analytic/>
    <monogr/>
    <monogr/>
    <series/>
</bibStruct>

can't be used to tag a chapter that's in a volume in a monograph in a 
series, because it should also mean the article appears in two different 
monographs. (Maybe I'm over-complicating things, and we should just 
combine the two monogrs in my example, give it two titles and biblScopes 
for both pages and volume?)

-- 
Dr Gabriel BODARD
Researcher in Digital Epigraphy

Digital Humanities
King's College London
26-29 Drury Lane
London WC2B 5RL

T: +44 (0)20 7848 1388
F: +44 (0)20 7848 2980
E: gabriel.bodard at kcl.ac.uk

http://www.digitalclassicist.org/
http://www.currentepigraphy.org/


From mholmes at uvic.ca  Mon Nov  5 12:06:23 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Mon, 5 Nov 2012 09:06:23 -0800
Subject: [tei-council] biblscope and imprint
In-Reply-To: <5097CD5C.2030206@ultraslavonic.info>
References: <5093A831.7080901@retired.ox.ac.uk>
	<5093D8C8.6090209@ultraslavonic.info>	<5093DDC7.1050504@kcl.ac.uk>
	<5093E2BB.6010106@ultraslavonic.info>	<50940D9A.7030007@retired.ox.ac.uk>
	<5095017A.8060903@retired.ox.ac.uk>	<50952166.2060305@ultraslavonic.info>
	<5095A6B4.2080307@retired.ox.ac.uk>	<5095BFB8.2050101@ultraslavonic.info>
	<5095C121.1010600@uvic.ca> <50966524.5010708@retired.ox.ac.uk>
	<5097535E.7060204@ultraslavonic.info> <5097BE42.4080908@uvic.ca>
	<5097CD5C.2030206@ultraslavonic.info>
Message-ID: <5097F20F.3080502@uvic.ca>

Hi Kevin,

On 12-11-05 06:29 AM, Kevin Hawkins wrote:
> That document is helpful.  What wasn't clear to me about BCP 47 is
> whether you could only use a script subtag in combination with a
> language subtag if they were listed in combination in the IANA registry
> (as some are).

Absolutely not. The idea of the "suppress script" thing, if I understand 
it correctly, is that you _don't_ need to specify that script, because 
it's the default or obvious, so when you use just "ru", the script 
"Cyrl" is understood; but if a different script is used, then you should 
specify it.

>  Whereas this W3C guide explicitly says you can only use
> extended language subtags with certain languages, I see that it
> explicitly says you can use a script subtag with any language when it's
> not written in the script given for "suppress script".  And, as we see,
> it even gives the examples of Russian "transcribed into the Latin script".
>
> So if you encounter "ru-Latn", you're stuck figuring out which
> transliteration scheme was used (or whether the author just invented one).

Yes, that's an interesting point; in many cases, there are ways to 
specify the transliteration scheme used:

Type: variant
Subtag: wadegile
Description: Wade-Giles romanization
Added: 2008-10-03
Prefix: zh-Latn

which specifies one particular romanization of Chinese. Use of variants 
is explained here:

<http://www.w3.org/International/questions/qa-choosing-language-tags#xxxshortcomings>

However, there are no such variants for Russian. If there are multiple 
latin transliteration schemes in use for Russian, it would be a good 
idea to register subtags for them.

To my mind, BCP 47 itself is actually quite hard to understand, but 
we've linked in the Guidelines to two W3C documents (including the one 
above) which really help to clarify the situation.

Cheers,
Martin

>
> --Kevin
>
> On 11/5/12 8:25 AM, Martin Holmes wrote:
>> The W3C guide to using language subtags actually uses ru-Latn as the
>> specific example for script subtags:
>>
>> "Script subtags should only be used as part of a language tag when the
>> script adds some useful distinguishing information to the tag. Usually
>> this is because a language is written in more than one script or because
>> the content has been transcribed into a script that is unusual to the
>> language (so one might tag Russian transcribed into the Latin script
>> with a tag such as ru-Latn)."
>>
>> <http://www.w3.org/International/questions/qa-choosing-language-tags>
>>
>> So I think Kevin might be misunderstanding BCP 47, and ru-Latn should be
>> used.
>>
>> Cheers,
>> Martin
>>
>> On 12-11-04 09:49 PM, Kevin Hawkins wrote:
>>> On 11/4/12 7:52 AM, Lou Burnard wrote:
>>>> Firstly the comment that using "ru" for Russian transliterated in Roman
>>>> characters is simply "underspecified" seems to me rather to miss the
>>>> point. If I see something in a Unicode document which says it has
>>>> xml:lang="ru" I expect to see proper Russian Unicode characters.
>>>
>>> Perhaps.  I meant that while you might think that, it wasn't clear to me
>>> that the semantics of @xml:lang license that inference.  However, once I
>>> looked at BCP 47 and the discussion of "suppress script" further, I
>>> think it might indeed license Lou's inference.
>>>
>>>> Secondly, even if I am prepared to accept Romanized versions of those
>>>> characters and figure out for myself what the Russian should have been,
>>>> this is not entirely easy. There are several different (Wikipedia lists
>>>> ten) possible Romanization schemes, which vary quite considerably. In
>>>> some, for example, the sequence "ye" stands for the Russian letter that
>>>> looks like a Roman "e"; in others this character is represented by "e",
>>>> unless it is iotated by a preceding soft sign. So generating a correct
>>>> Cyrillic version of this citation isn't easy, and neither is deciding
>>>> which scheme we're dealing with here!
>>>
>>> BCP 47 allows for registering of variant subtags for systems of
>>> transliteration, but it does not require this.  However, per the
>>> discussion of "suppress script", it seems you effectively need to for
>>> transliteration.
>>>
>>> This is puzzling.
>>>
>>>> Thirdly, this particular example is actually taken verbatim from a
>>>> rather elderly ISO standard on bibliographic reference (ISO 690, 1987).
>>>>       Hence we probably should not mess with its representation at all.
>>>
>>> I fully agree that as long as we are citing a citation in a source
>>> document, we shouldn't go de-transliterating it!
>>>
>>>     >  (You
>>>> can see it cited as a example in the Wikipedia entry for ISO_690,
>>>> curiously enough).
>>>
>>> I imagine that someone writing or improving the Wikipedia article on ISO
>>> 690 googled around to see what they could find and stumbled upon the
>>> Guidelines ...
>>>
>>>> My guess, but I defer to the Russian expert in our midst, is that this
>>>> uses the now deprecated ISO/R:1968 but without access to the original,
>>>> it's hard to be sure, and without being sure I'd rather not try to
>>>> convert it into proper Russian.
>>>
>>> Well, it looks like Lou not only tried, but as your resident Russian
>>> expert I can say that he also succeeded.
>>>
>>>> All of which I suppose we can side-step cheerfully, by saying "ru-Latn",
>>>> even though this particular combination isn't actually proposed in
>>>> http://www.iana.org/assignments/language-subtag-registry, and even
>>>> though this won't help anyone who *does* want to see the original title
>>>> as it should have been presented!
>>>
>>> I, like Martin in a later message, used to think that BCP 47 allowed for
>>> the various types of tags to be combined as you see fit, meaning that
>>> "ru-Latn" would be allowed.  But a closer reading of BCP 47 now makes me
>>> think that you can only use things in the IANA registry unless you use a
>>> private use subtag.
>>>
>>> We could bring in Syd Bauman or Deborah Anderson to help us sort this
>>> out, or we could take a shortcut by simply removing the @xml:lang on
>>> this transliterated title.
>>>
>>> --Kevin
>>>
>>

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From kevin.s.hawkins at ultraslavonic.info  Mon Nov  5 12:12:56 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Mon, 05 Nov 2012 12:12:56 -0500
Subject: [tei-council] biblscope and imprint
In-Reply-To: <5097F20F.3080502@uvic.ca>
References: <5093A831.7080901@retired.ox.ac.uk>
	<5093D8C8.6090209@ultraslavonic.info>	<5093DDC7.1050504@kcl.ac.uk>
	<5093E2BB.6010106@ultraslavonic.info>	<50940D9A.7030007@retired.ox.ac.uk>
	<5095017A.8060903@retired.ox.ac.uk>	<50952166.2060305@ultraslavonic.info>
	<5095A6B4.2080307@retired.ox.ac.uk>	<5095BFB8.2050101@ultraslavonic.info>
	<5095C121.1010600@uvic.ca> <50966524.5010708@retired.ox.ac.uk>
	<5097535E.7060204@ultraslavonic.info> <5097BE42.4080908@uvic.ca>
	<5097CD5C.2030206@ultraslavonic.info> <5097F20F.3080502@uvic.ca>
Message-ID: <5097F398.7070406@ultraslavonic.info>

On 11/5/12 12:06 PM, Martin Holmes wrote:
> Hi Kevin,
>
> On 12-11-05 06:29 AM, Kevin Hawkins wrote:
>> That document is helpful.  What wasn't clear to me about BCP 47 is
>> whether you could only use a script subtag in combination with a
>> language subtag if they were listed in combination in the IANA registry
>> (as some are).
>
> Absolutely not. The idea of the "suppress script" thing, if I understand
> it correctly, is that you _don't_ need to specify that script, because
> it's the default or obvious, so when you use just "ru", the script
> "Cyrl" is understood; but if a different script is used, then you should
> specify it.

Yes, I understand that.  I meant it's not clear that the non-default 
script subtags have to be enumerated in the registry or whether you can 
freely combine as needed.

>>   Whereas this W3C guide explicitly says you can only use
>> extended language subtags with certain languages, I see that it
>> explicitly says you can use a script subtag with any language when it's
>> not written in the script given for "suppress script".  And, as we see,
>> it even gives the examples of Russian "transcribed into the Latin script".
>>
>> So if you encounter "ru-Latn", you're stuck figuring out which
>> transliteration scheme was used (or whether the author just invented one).
>
> Yes, that's an interesting point; in many cases, there are ways to
> specify the transliteration scheme used:
>
> Type: variant
> Subtag: wadegile
> Description: Wade-Giles romanization
> Added: 2008-10-03
> Prefix: zh-Latn
>
> which specifies one particular romanization of Chinese. Use of variants
> is explained here:
>
> <http://www.w3.org/International/questions/qa-choosing-language-tags#xxxshortcomings>
>
> However, there are no such variants for Russian. If there are multiple
> latin transliteration schemes in use for Russian, it would be a good
> idea to register subtags for them.

Yes.  All 10 of them that Lou found in Wikipedia.

> To my mind, BCP 47 itself is actually quite hard to understand, but
> we've linked in the Guidelines to two W3C documents (including the one
> above) which really help to clarify the situation.

You know, when you sent that link, I recalled that we were going to add 
it to the Guidelines, but I don't see it at:

http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-att.global.html

which is where I go to look for advice on @xml:lang.  Perhaps we could 
add the two W3C documents to ref-att.global.xml as well?

--Kevin

From mholmes at uvic.ca  Mon Nov  5 12:25:42 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Mon, 5 Nov 2012 09:25:42 -0800
Subject: [tei-council] biblscope and imprint
In-Reply-To: <5097F398.7070406@ultraslavonic.info>
References: <5093A831.7080901@retired.ox.ac.uk>
	<5093D8C8.6090209@ultraslavonic.info>	<5093DDC7.1050504@kcl.ac.uk>
	<5093E2BB.6010106@ultraslavonic.info>	<50940D9A.7030007@retired.ox.ac.uk>
	<5095017A.8060903@retired.ox.ac.uk>	<50952166.2060305@ultraslavonic.info>
	<5095A6B4.2080307@retired.ox.ac.uk>	<5095BFB8.2050101@ultraslavonic.info>
	<5095C121.1010600@uvic.ca> <50966524.5010708@retired.ox.ac.uk>
	<5097535E.7060204@ultraslavonic.info> <5097BE42.4080908@uvic.ca>
	<5097CD5C.2030206@ultraslavonic.info> <5097F20F.3080502@uvic.ca>
	<5097F398.7070406@ultraslavonic.info>
Message-ID: <5097F696.3050102@uvic.ca>

Hi Kevin,

The bit of the Guidelines with the links is here:

<http://www.tei-c.org/release/doc/tei-p5-doc/en/html/CH.html#CHSH>

You're right that the att.global definition of @xml:lang should probably 
be revised too.

Of the Wikipedia definitions Lou found, I guess here:

<http://en.wikipedia.org/wiki/Romanization_of_Russian>

ALA-LC is already in the subtag registry:

Type: variant
Subtag: alalc97
Description: ALA-LC Romanization, 1997 edition
Added: 2009-12-09
Comments: Romanizations recommended by the American Library Association
   and the Library of Congress, in "ALA-LC Romanization Tables:
   Transliteration Schemes for Non-Roman Scripts" (1997), ISBN
   978-0-8444-0940-5.

so if that were the one used in this case, you could make the tag 
ur-Latn-alalc97. But I can't find any of the others.

Cheers,
Martin

On 12-11-05 09:12 AM, Kevin Hawkins wrote:
> On 11/5/12 12:06 PM, Martin Holmes wrote:
>> Hi Kevin,
>>
>> On 12-11-05 06:29 AM, Kevin Hawkins wrote:
>>> That document is helpful.  What wasn't clear to me about BCP 47 is
>>> whether you could only use a script subtag in combination with a
>>> language subtag if they were listed in combination in the IANA registry
>>> (as some are).
>>
>> Absolutely not. The idea of the "suppress script" thing, if I understand
>> it correctly, is that you _don't_ need to specify that script, because
>> it's the default or obvious, so when you use just "ru", the script
>> "Cyrl" is understood; but if a different script is used, then you should
>> specify it.
>
> Yes, I understand that.  I meant it's not clear that the non-default
> script subtags have to be enumerated in the registry or whether you can
> freely combine as needed.
>
>>>    Whereas this W3C guide explicitly says you can only use
>>> extended language subtags with certain languages, I see that it
>>> explicitly says you can use a script subtag with any language when it's
>>> not written in the script given for "suppress script".  And, as we see,
>>> it even gives the examples of Russian "transcribed into the Latin script".
>>>
>>> So if you encounter "ru-Latn", you're stuck figuring out which
>>> transliteration scheme was used (or whether the author just invented one).
>>
>> Yes, that's an interesting point; in many cases, there are ways to
>> specify the transliteration scheme used:
>>
>> Type: variant
>> Subtag: wadegile
>> Description: Wade-Giles romanization
>> Added: 2008-10-03
>> Prefix: zh-Latn
>>
>> which specifies one particular romanization of Chinese. Use of variants
>> is explained here:
>>
>> <http://www.w3.org/International/questions/qa-choosing-language-tags#xxxshortcomings>
>>
>> However, there are no such variants for Russian. If there are multiple
>> latin transliteration schemes in use for Russian, it would be a good
>> idea to register subtags for them.
>
> Yes.  All 10 of them that Lou found in Wikipedia.
>
>> To my mind, BCP 47 itself is actually quite hard to understand, but
>> we've linked in the Guidelines to two W3C documents (including the one
>> above) which really help to clarify the situation.
>
> You know, when you sent that link, I recalled that we were going to add
> it to the Guidelines, but I don't see it at:
>
> http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-att.global.html
>
> which is where I go to look for advice on @xml:lang.  Perhaps we could
> add the two W3C documents to ref-att.global.xml as well?
>
> --Kevin
>

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From lou.burnard at retired.ox.ac.uk  Mon Nov  5 16:56:39 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Mon, 05 Nov 2012 21:56:39 +0000
Subject: [tei-council] biblscope and imprint
In-Reply-To: <5097F398.7070406@ultraslavonic.info>
References: <5093A831.7080901@retired.ox.ac.uk>
	<5093D8C8.6090209@ultraslavonic.info>	<5093DDC7.1050504@kcl.ac.uk>
	<5093E2BB.6010106@ultraslavonic.info>	<50940D9A.7030007@retired.ox.ac.uk>
	<5095017A.8060903@retired.ox.ac.uk>	<50952166.2060305@ultraslavonic.info>
	<5095A6B4.2080307@retired.ox.ac.uk>	<5095BFB8.2050101@ultraslavonic.info>
	<5095C121.1010600@uvic.ca> <50966524.5010708@retired.ox.ac.uk>
	<5097535E.7060204@ultraslavonic.info> <5097BE42.4080908@uvic.ca>
	<5097CD5C.2030206@ultraslavonic.info> <5097F20F.3080502@uvic.ca>
	<5097F398.7070406@ultraslavonic.info>
Message-ID: <50983617.9080203@retired.ox.ac.uk>

On 05/11/12 17:12, Kevin Hawkins wrote:

> You know, when you sent that link, I recalled that we were going to add
> it to the Guidelines, but I don't see it at:
>
> http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-att.global.html
>
> which is where I go to look for advice on @xml:lang.

Possibly not the best place to look, tho I think it does link to the 
relevant bits of discussion eventually




From lou.burnard at retired.ox.ac.uk  Mon Nov  5 17:01:36 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Mon, 05 Nov 2012 22:01:36 +0000
Subject: [tei-council] biblscope and imprint
In-Reply-To: <5097CFA4.3090402@kcl.ac.uk>
References: <5093A831.7080901@retired.ox.ac.uk>	<5093D8C8.6090209@ultraslavonic.info>
	<5093DDC7.1050504@kcl.ac.uk> <5093E2BB.6010106@ultraslavonic.info>
	<50940D9A.7030007@retired.ox.ac.uk>
	<5095017A.8060903@retired.ox.ac.uk>
	<50952166.2060305@ultraslavonic.info>
	<5095A6B4.2080307@retired.ox.ac.uk> <5097A5B9.70402@kcl.ac.uk>
	<5097CDF2.30005@ultraslavonic.info> <5097CFA4.3090402@kcl.ac.uk>
Message-ID: <50983740.7050801@retired.ox.ac.uk>

On 05/11/12 14:39, Gabriel Bodard wrote:

> <bibStruct>
>      <analytic/>
>      <monogr/>
>      <series/>
>      <monogr/>
>      <series/>
> </bibStruct>
>
> is fine (except possibly for the order of the elements?), representing a
> chapter that appears in two places;

The order of the elements is essential! It enables you to know that the 
first monogr appears in the first series; and the second in the second.

but
>
> <bibStruct>
>      <analytic/>
>      <monogr/>
>      <monogr/>
>      <series/>
> </bibStruct>
>
> can't be used to tag a chapter that's in a volume in a monograph in a
> series, because it should also mean the article appears in two different
> monographs.

this means the article is in a monogr, and also in a monogr that's in a 
series

(Maybe I'm over-complicating things, and we should just
> combine the two monogrs in my example, give it two titles and biblScopes
> for both pages and volume?)
>

well, if by "my example" you mean the Schachter one, yes, I wondered why 
you didnt just give it two titles with different @levels




From James.Cummings at it.ox.ac.uk  Tue Nov  6 11:08:35 2012
From: James.Cummings at it.ox.ac.uk (James Cummings)
Date: Tue, 06 Nov 2012 16:08:35 +0000
Subject: [tei-council] Council report at members meeting
Message-ID: <50993603.9030301@it.ox.ac.uk>


Hi Council,

I'm compiling the report for the members meeting on activities 
we've undertaken and major changes since the last members 
meeting. While I'm going to go through the release notes, 
minutes, and mailing list, if you have particular items you want 
to make sure I'm going to include, please do email me!

Best,
-James

-- 
Dr James Cummings, researchsupport at it.ox.ac.uk
Research Support, IT Services, University of Oxford

From mholmes at uvic.ca  Tue Nov  6 19:07:41 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Tue, 6 Nov 2012 16:07:41 -0800
Subject: [tei-council] Updated oxygen-tei
Message-ID: <5099A64D.4000506@uvic.ca>

Having just got bitten once more by the default setting in Oxygen that 
tries to validate ODD files against Syd's old brown_odds.rng file 
instead of the tei_odds.rng file, I've made a couple of changes to the 
oxygen-tei source so that (hopefully, assuming it works properly) this 
default will be switched. Current ODD files don't validate against the 
brown file.

Shall endeavour to test thoroughly before next Oxygen release. If anyone 
else who knows the codebase would like to look at my changes (Sebastian? 
James?), they're in rev 53.

Cheers,
Martin
-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From sebastian.rahtz at it.ox.ac.uk  Wed Nov  7 13:54:36 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Wed, 7 Nov 2012 18:54:36 +0000
Subject: [tei-council] Updated oxygen-tei
In-Reply-To: <5099A64D.4000506@uvic.ca>
References: <5099A64D.4000506@uvic.ca>
Message-ID: <C4EECB57-8DE2-41C7-95CE-0ECD94AB19D7@it.ox.ac.uk>

looks OK to me. 

you might want to warn Syd, as he probably depends on certain behaviour for
his teaching.

--
Sebastian Rahtz      
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431


From mholmes at uvic.ca  Wed Nov  7 15:04:59 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Wed, 7 Nov 2012 12:04:59 -0800
Subject: [tei-council] Updated oxygen-tei
In-Reply-To: <C4EECB57-8DE2-41C7-95CE-0ECD94AB19D7@it.ox.ac.uk>
References: <5099A64D.4000506@uvic.ca>
	<C4EECB57-8DE2-41C7-95CE-0ECD94AB19D7@it.ox.ac.uk>
Message-ID: <509ABEEB.3090609@uvic.ca>

Done.

On 12-11-07 10:54 AM, Sebastian Rahtz wrote:
> looks OK to me.
>
> you might want to warn Syd, as he probably depends on certain behaviour for
> his teaching.
>
> --
> Sebastian Rahtz
> Director (Research Support) of Academic IT Services
> University of Oxford IT Services
> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>
>

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From lou.burnard at retired.ox.ac.uk  Sun Nov 11 15:58:38 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Sun, 11 Nov 2012 20:58:38 +0000
Subject: [tei-council] chic piotr
Message-ID: <50A0117E.2020609@retired.ox.ac.uk>


-------------- next part --------------
A non-text attachment was scrubbed...
Name: 20121108_191055.jpg
Type: image/jpeg
Size: 2610731 bytes
Desc: not available
Url : http://lists.village.Virginia.EDU/pipermail/tei-council/attachments/20121111/6140c55d/attachment-0001.jpg 

From bansp at o2.pl  Sun Nov 11 19:17:13 2012
From: bansp at o2.pl (=?ISO-8859-2?Q?Piotr_Ba=F1ski?=)
Date: Mon, 12 Nov 2012 01:17:13 +0100
Subject: [tei-council] chic piotr
In-Reply-To: <50A0117E.2020609@retired.ox.ac.uk>
References: <50A0117E.2020609@retired.ox.ac.uk>
Message-ID: <50A04009.9020407@o2.pl>

Ah, what cute little thing... and so stylish, too!

From kevin.s.hawkins at ultraslavonic.info  Sun Nov 11 22:12:50 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Sun, 11 Nov 2012 22:12:50 -0500
Subject: [tei-council] biblscope and imprint
In-Reply-To: <5097CFA4.3090402@kcl.ac.uk>
References: <5093A831.7080901@retired.ox.ac.uk>	<5093D8C8.6090209@ultraslavonic.info>
	<5093DDC7.1050504@kcl.ac.uk> <5093E2BB.6010106@ultraslavonic.info>
	<50940D9A.7030007@retired.ox.ac.uk>
	<5095017A.8060903@retired.ox.ac.uk>
	<50952166.2060305@ultraslavonic.info>
	<5095A6B4.2080307@retired.ox.ac.uk> <5097A5B9.70402@kcl.ac.uk>
	<5097CDF2.30005@ultraslavonic.info> <5097CFA4.3090402@kcl.ac.uk>
Message-ID: <50A06932.4050306@ultraslavonic.info>

All,

I've just updated the ticket so that the world knows what changes Lou 
already made in halfway implementing the ticket, and to summarize a 
discussion Lou and I had in College Station:

https://sourceforge.net/tracker/index.php?func=detail&aid=3555190&group_id=106328&atid=644065

Further to Gabby's latest comment ...

On 11/5/12 9:39 AM, Gabriel Bodard wrote:
> <bibStruct>
>      <analytic/>
>      <monogr/>
>      <monogr/>
>      <series/>
> </bibStruct>
>
> can't be used to tag a chapter that's in a volume in a monograph in a
> series, because it should also mean the article appears in two different
> monographs. (Maybe I'm over-complicating things, and we should just
> combine the two monogrs in my example, give it two titles and biblScopes
> for both pages and volume?)

... I think you might indeed combine the two <monogr>s (one for the 
"volume" and another for the "monograph" in which that volume appears). 
  Alternatively, you leave them in separate <monogr>s, but, as in 
discussed on the ticket, we give up on this idea that a <monogr> always 
describes its previous sibling, even if that sibling is another <monogr>.

--Kevin

From dsewell at virginia.edu  Mon Nov 12 11:04:41 2012
From: dsewell at virginia.edu (David Sewell)
Date: Mon, 12 Nov 2012 11:04:41 -0500 (EST)
Subject: [tei-council] Updates to Board/Council list, etc.
Message-ID: <alpine.OSX.2.00.1211121100480.15343@lister.ei.virginia.edu>

Dear Board & Council folks,

I hope that those of you who were in College Station for the meeting have had 
safe travel back! I am planning tonight to add the newly elected members to the 
email lists, per our usual practice, and may or may not have time to create a 
new joint Board/Council email list per the decision taken at the Members' 
Meeting. In any case, I will be tackling the website and administrative things 
on my end within the next couple of days.

David

-- 
David Sewell, Editorial and Technical Manager
ROTUNDA, The University of Virginia Press
PO Box 400314, Charlottesville, VA 22904-4314 USA
Email: dsewell at virginia.edu   Tel: +1 434 924 9973
Web: http://rotunda.upress.virginia.edu/

From James.Cummings at it.ox.ac.uk  Mon Nov 12 11:21:27 2012
From: James.Cummings at it.ox.ac.uk (James Cummings)
Date: Mon, 12 Nov 2012 10:21:27 -0600
Subject: [tei-council] [tei-board] Updates to Board/Council list, etc.
In-Reply-To: <alpine.OSX.2.00.1211121100480.15343@lister.ei.virginia.edu>
References: <alpine.OSX.2.00.1211121100480.15343@lister.ei.virginia.edu>
Message-ID: <50A12207.2030306@it.ox.ac.uk>


Thanks David!

-James

On 12/11/12 10:04, David Sewell wrote:
> Dear Board & Council folks,
>
> I hope that those of you who were in College Station for the meeting have had
> safe travel back! I am planning tonight to add the newly elected members to the
> email lists, per our usual practice, and may or may not have time to create a
> new joint Board/Council email list per the decision taken at the Members'
> Meeting. In any case, I will be tackling the website and administrative things
> on my end within the next couple of days.
>
> David
>


-- 
Dr James Cummings, James.Cummings at it.ox.ac.uk
Academic IT Services, University of Oxford

From dsewell at virginia.edu  Mon Nov 12 21:11:40 2012
From: dsewell at virginia.edu (David Sewell)
Date: Mon, 12 Nov 2012 21:11:40 -0500 (EST)
Subject: [tei-council] New Council members added to the list
Message-ID: <alpine.OSX.2.00.1211122109460.25360@tadai.local>

Dear Council members,

Per tradition, I have added the newly elected members to the list:

Syd Bauman
Hugh Cayless
Elli Mylonas

Welcome, and if you have alternate email addresses that you would like 
to be able to send from (or prefer to receive mail at), please let me 
know.

David S.
(list admin)

-- 
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 kevin.s.hawkins at ultraslavonic.info  Tue Nov 13 22:30:31 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Tue, 13 Nov 2012 22:30:31 -0500
Subject: [tei-council] representing transliteration in @xml:lang (was Re:
 biblscope and imprint)
In-Reply-To: <50983617.9080203@retired.ox.ac.uk>
References: <5093A831.7080901@retired.ox.ac.uk>
	<5093D8C8.6090209@ultraslavonic.info>	<5093DDC7.1050504@kcl.ac.uk>
	<5093E2BB.6010106@ultraslavonic.info>	<50940D9A.7030007@retired.ox.ac.uk>
	<5095017A.8060903@retired.ox.ac.uk>	<50952166.2060305@ultraslavonic.info>
	<5095A6B4.2080307@retired.ox.ac.uk>	<5095BFB8.2050101@ultraslavonic.info>
	<5095C121.1010600@uvic.ca> <50966524.5010708@retired.ox.ac.uk>
	<5097535E.7060204@ultraslavonic.info> <5097BE42.4080908@uvic.ca>
	<5097CD5C.2030206@ultraslavonic.info> <5097F20F.3080502@uvic.ca>
	<5097F398.7070406@ultraslavonic.info>
	<50983617.9080203@retired.ox.ac.uk>
Message-ID: <50A31057.6040507@ultraslavonic.info>

Let me attempt to summarize this discussion so far, especially for the 
benefit of the incoming Council members.

While Lou was implementing http://purl.org/TEI/FR/3555190 , he noticed 
this example given in passing in CO-CoreElements.xml:

<title xml:lang="ru" level="m">Ciklotronnye volny v plazme</title>

which is a TEI representation of part of a source document that includes 
a citation in which a title in Russian is transliterated into Roman 
letters.  Lou identified the transliteration scheme used as ISO/R 
9:1968, though I hereby note that it could also be a few other systems 
of transliteration which happen to coincide for the characters used in 
this title.

Lou asked whether "ru" is the correct value of @xml:lang for Russian 
written in Roman letters.  Lou thinks that for processing purposes it's 
wrong to have just "ru" when you expect to see Cyrillic letters, whereas 
Kevin argued that the language is simply underspecified when using only 
a language subtag.  (Note that according to the nomenclature of BCP 47, 
which defines how to create a value for @xml:lang, the whole value of 
this attribute is called a "language tag", whereas the components of 
this "tag", separated by hyphens, are called "subtags".)

Note also that we don't want to just detransliterate the Russian title 
since it comes from a source document that we are attempting to represent.

Lou thought that you can't use a script subtag with a language subtag 
unless the combination is enumerated in the IANA registry linked from 
BCP 47 ( http://www.iana.org/assignments/language-subtag-registry ), and 
while I at first agreed, as I read this document more closely, I see 
that none of the script subtags are paired with languages, implying that 
they could be used as needed (unless defined in a "Suppress-Script" 
field, per BCP 47).  That is, it appears to me that "ru-Latn" is an 
acceptable combination.

Still, we're left with the problem of whether "ru-Latn" is worth using 
in the Guidelines (or in any TEI document) since there's still more than 
one transliteration system you might use for Russian.  That is, it's 
barely more actionable than "ru".  The IANA registry lists various 
"variant subtags" for systems of transliteration, some of which are 
given with one or more prefix with which it might be used.  For example, 
"pinyin" -- for Pinyin romanization -- is given with the prefixes 
"zh-Latn" and "bo-Latn", showing that "pinyin" is meant to be used with 
Chinese.  On the other hand, the variant subtag "alalc97" -- for 
Romanizations recommended by the American Library Association and the 
Library of Congress, in "ALA-LC Romanization Tables: Transliteration 
Schemes for Non-Roman Scripts" (1997), ISBN 978-0-8444-0940-5 -- is not 
given with any prefixes, implying that you could construct 
"ru-Latn-alalc97" if that particular transliteration system was used for 
Russian.  Unfortunately, the example in the Guidelines definitely 
doesn't use this system.

According to BCP 47 section 2.2.5, paragraph 4, you can only use 
registered variants, so we couldn't just make up "ru-Latn-isor91968" or 
something like that for what's transliterated above.  (It wouldn't be 
much of a standard anyway if we could!)  So we could seek IANA 
registration of another variant subtag for one of the systems of 
transliteration of Russian used in the example above.

Alternatively, we simply remove @xml:lang entirely from this example in 
the Guidelines!

* * *

As an aside, Kevin and Martin suggested that we link to the following:

* http://www.iana.org/assignments/language-subtag-registry
* http://www.w3.org/International/articles/language-tags/
* http://www.w3.org/International/questions/qa-choosing-language-tags.

from:

http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-att.global.html

as we've done at:

http://www.tei-c.org/release/doc/tei-p5-doc/en/html/CH.html#CHSH

on the same grounds that Martin and I often argue: that we and most 
users of the TEI, when seeking guidance on a specific element, consult 
the element and attribute specifications and don't always make it to the 
prose of the Guidelines.  Lou, on the other hand, said that the 
definition of the attribute class isn't the best place to look for this 
information, and that if you follow links starting at 
http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-att.global.html 
, you will reach this information.

--Kevin

From kevin.s.hawkins at ultraslavonic.info  Tue Nov 13 23:01:31 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Tue, 13 Nov 2012 23:01:31 -0500
Subject: [tei-council] New Prefix Definition Proposal (was "Private URI
 Schemes")
In-Reply-To: <5076E9AB.8030600@uvic.ca>
References: <5076E9AB.8030600@uvic.ca>
Message-ID: <50A3179B.7030104@ultraslavonic.info>

I've clarified some wording and some of the statement of context, and 
I've added a comment at the end comparing to @xml:base.  Basically, 
though, it looks good to me.  --Kevin

On 10/11/12 11:45 AM, Martin Holmes wrote:
> Hi all,
>
> At the Council meeting we discussed my proposal for Private URI Schemes,
> and I was tasked with rewriting it in a more generic form to make it
> more broadly applicable. I've created a new version here:
>
> <http://wiki.tei-c.org/index.php/Prefix_Definition_Proposal>
>
> All comments are welcome, and there's a Notes section at the end you can
> add your concerns to. I'll also raise a ticket for it too, to make sure
> we don't lose track of it. There's no pressure to get this into the
> upcoming release, so we can take our time with it.
>
> Cheers,
> Martin
>

From lou.burnard at retired.ox.ac.uk  Wed Nov 14 03:13:28 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Wed, 14 Nov 2012 08:13:28 +0000
Subject: [tei-council] representing transliteration in @xml:lang (was
 Re: biblscope and imprint)
In-Reply-To: <50A31057.6040507@ultraslavonic.info>
References: <5093A831.7080901@retired.ox.ac.uk>
	<5093D8C8.6090209@ultraslavonic.info>	<5093DDC7.1050504@kcl.ac.uk>
	<5093E2BB.6010106@ultraslavonic.info>	<50940D9A.7030007@retired.ox.ac.uk>
	<5095017A.8060903@retired.ox.ac.uk>	<50952166.2060305@ultraslavonic.info>
	<5095A6B4.2080307@retired.ox.ac.uk>	<5095BFB8.2050101@ultraslavonic.info>
	<5095C121.1010600@uvic.ca> <50966524.5010708@retired.ox.ac.uk>
	<5097535E.7060204@ultraslavonic.info> <5097BE42.4080908@uvic.ca>
	<5097CD5C.2030206@ultraslavonic.info> <5097F20F.3080502@uvic.ca>
	<5097F398.7070406@ultraslavonic.info>
	<50983617.9080203@retired.ox.ac.uk>
	<50A31057.6040507@ultraslavonic.info>
Message-ID: <50A352A8.1000106@retired.ox.ac.uk>

On 14/11/12 03:30, Kevin Hawkins wrote:

>
> Lou thought that you can't use a script subtag with a language subtag
> unless the combination is enumerated in the IANA registry linked from
> BCP 47 ( http://www.iana.org/assignments/language-subtag-registry ),

No I didn't. I just wondered. Martin persuaded me otherwise.

>
> Alternatively, we simply remove @xml:lang entirely from this example in
> the Guidelines!
>

I think that would be misleading, as well as bad practice.

"ru-Latn" does the job of saying "this isn't English, despite the 
character set" which is a lot more use than saying just "ru" which is a 
lie.




From bansp at o2.pl  Wed Nov 14 08:37:44 2012
From: bansp at o2.pl (=?ISO-8859-2?Q?Piotr_Ba=F1ski?=)
Date: Wed, 14 Nov 2012 14:37:44 +0100
Subject: [tei-council] representing transliteration in @xml:lang (was
 Re: biblscope and imprint)
In-Reply-To: <50A352A8.1000106@retired.ox.ac.uk>
References: <5093A831.7080901@retired.ox.ac.uk>
	<5093D8C8.6090209@ultraslavonic.info>	<5093DDC7.1050504@kcl.ac.uk>
	<5093E2BB.6010106@ultraslavonic.info>	<50940D9A.7030007@retired.ox.ac.uk>
	<5095017A.8060903@retired.ox.ac.uk>	<50952166.2060305@ultraslavonic.info>
	<5095A6B4.2080307@retired.ox.ac.uk>	<5095BFB8.2050101@ultraslavonic.info>
	<5095C121.1010600@uvic.ca> <50966524.5010708@retired.ox.ac.uk>
	<5097535E.7060204@ultraslavonic.info> <5097BE42.4080908@uvic.ca>
	<5097CD5C.2030206@ultraslavonic.info> <5097F20F.3080502@uvic.ca>
	<5097F398.7070406@ultraslavonic.info>
	<50983617.9080203@retired.ox.ac.uk>
	<50A31057.6040507@ultraslavonic.info>
	<50A352A8.1000106@retired.ox.ac.uk>
Message-ID: <50A39EA8.2000904@o2.pl>

On 14/11/12 09:13, Lou Burnard wrote:
[...]
>>
>> Alternatively, we simply remove @xml:lang entirely from this example in
>> the Guidelines!
>>
> 
> I think that would be misleading, as well as bad practice.
> 
> "ru-Latn" does the job of saying "this isn't English, despite the 
> character set" which is a lot more use than saying just "ru" which is a 
> lie.

Or maybe rather "this is Russian, but don't expect the Cyrillic", which
in this case amounts to roughly the same. Kevin is right that "ru" is
underspecification, but it's very wide, so wide as to imply the default
that isn't the case. "ru-Latn" is still underspecification, but much
narrower, and with some consequences for machine processing.

Commenting on this further in the Guidelines seems a matter of taste and
balance, possibly a footnote on the existence of many alternative
romanized transliterations might be quite useful.

  P.


From mholmes at uvic.ca  Wed Nov 14 08:44:37 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Wed, 14 Nov 2012 05:44:37 -0800
Subject: [tei-council] New Prefix Definition Proposal (was "Private URI
 Schemes")
In-Reply-To: <50A3179B.7030104@ultraslavonic.info>
References: <5076E9AB.8030600@uvic.ca> <50A3179B.7030104@ultraslavonic.info>
Message-ID: <50A3A045.7060708@uvic.ca>

Thanks Kevin. I have a draft of a Guidelines section already done, and a 
couple more bits of Glines changes to write and add to the proposal 
before I ask for the final go-ahead. Should be done by next week.

Cheers,
Martin

On 12-11-13 08:01 PM, Kevin Hawkins wrote:
> I've clarified some wording and some of the statement of context, and
> I've added a comment at the end comparing to @xml:base.  Basically,
> though, it looks good to me.  --Kevin
>
> On 10/11/12 11:45 AM, Martin Holmes wrote:
>> Hi all,
>>
>> At the Council meeting we discussed my proposal for Private URI Schemes,
>> and I was tasked with rewriting it in a more generic form to make it
>> more broadly applicable. I've created a new version here:
>>
>> <http://wiki.tei-c.org/index.php/Prefix_Definition_Proposal>
>>
>> All comments are welcome, and there's a Notes section at the end you can
>> add your concerns to. I'll also raise a ticket for it too, to make sure
>> we don't lose track of it. There's no pressure to get this into the
>> upcoming release, so we can take our time with it.
>>
>> Cheers,
>> Martin
>>

From mholmes at uvic.ca  Wed Nov 14 08:51:33 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Wed, 14 Nov 2012 05:51:33 -0800
Subject: [tei-council] representing transliteration in @xml:lang (was
 Re: biblscope and imprint)
In-Reply-To: <50A39EA8.2000904@o2.pl>
References: <5093A831.7080901@retired.ox.ac.uk>
	<5093D8C8.6090209@ultraslavonic.info>	<5093DDC7.1050504@kcl.ac.uk>
	<5093E2BB.6010106@ultraslavonic.info>	<50940D9A.7030007@retired.ox.ac.uk>
	<5095017A.8060903@retired.ox.ac.uk>	<50952166.2060305@ultraslavonic.info>
	<5095A6B4.2080307@retired.ox.ac.uk>	<5095BFB8.2050101@ultraslavonic.info>
	<5095C121.1010600@uvic.ca> <50966524.5010708@retired.ox.ac.uk>
	<5097535E.7060204@ultraslavonic.info> <5097BE42.4080908@uvic.ca>
	<5097CD5C.2030206@ultraslavonic.info> <5097F20F.3080502@uvic.ca>
	<5097F398.7070406@ultraslavonic.info>	<50983617.9080203@retired.ox.ac.uk>
	<50A31057.6040507@ultraslavonic.info>	<50A352A8.1000106@retired.ox.ac.uk>
	<50A39EA8.2000904@o2.pl>
Message-ID: <50A3A1E5.1030600@uvic.ca>

On 12-11-14 05:37 AM, Piotr Ba?ski wrote:
> On 14/11/12 09:13, Lou Burnard wrote:
> [...]
>>>
>>> Alternatively, we simply remove @xml:lang entirely from this example in
>>> the Guidelines!
>>>
>>
>> I think that would be misleading, as well as bad practice.
>>
>> "ru-Latn" does the job of saying "this isn't English, despite the
>> character set" which is a lot more use than saying just "ru" which is a
>> lie.
>
> Or maybe rather "this is Russian, but don't expect the Cyrillic", which
> in this case amounts to roughly the same.

Yes. The subtag for Russian looks like this:

%%
Type: language
Subtag: ru
Description: Russian
Added: 2005-10-16
Suppress-Script: Cyrl
%%

which I interpret to mean that the default script is Cyrl; that means 
that you don't need to say ru-Cyrl, and in fact ru = ru-Cyrl. Therefore 
if we retain this example, we must supply a script subtag.

> Kevin is right that "ru" is
> underspecification, but it's very wide, so wide as to imply the default
> that isn't the case. "ru-Latn" is still underspecification, but much
> narrower, and with some consequences for machine processing.

Agreed. It's much better than nothing, and I don't think that there's a 
requirement that it be more precise. More precise would be better, and 
more processable, but since "ru-Latn" is actually used as an example in 
the W3C explanatory document, I maintain that it's at least adequate, 
and since the actual subtag required is not (yet) available, we should 
stick with it.

> Commenting on this further in the Guidelines seems a matter of taste and
> balance, possibly a footnote on the existence of many alternative
> romanized transliterations might be quite useful.

Or confusing. The example IIRC relates to bibliographic items, not 
languages or scripts. To remove the potential confusion, it could simply 
be changed to Cyrillic.

Cheers,
Martin

From lou.burnard at retired.ox.ac.uk  Wed Nov 14 09:29:44 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Wed, 14 Nov 2012 14:29:44 +0000
Subject: [tei-council] representing transliteration in @xml:lang (was
 Re: biblscope and imprint)
In-Reply-To: <50A3A1E5.1030600@uvic.ca>
References: <5093A831.7080901@retired.ox.ac.uk>
	<5093D8C8.6090209@ultraslavonic.info>	<5093DDC7.1050504@kcl.ac.uk>
	<5093E2BB.6010106@ultraslavonic.info>	<50940D9A.7030007@retired.ox.ac.uk>
	<5095017A.8060903@retired.ox.ac.uk>	<50952166.2060305@ultraslavonic.info>
	<5095A6B4.2080307@retired.ox.ac.uk>	<5095BFB8.2050101@ultraslavonic.info>
	<5095C121.1010600@uvic.ca> <50966524.5010708@retired.ox.ac.uk>
	<5097535E.7060204@ultraslavonic.info> <5097BE42.4080908@uvic.ca>
	<5097CD5C.2030206@ultraslavonic.info> <5097F20F.3080502@uvic.ca>
	<5097F398.7070406@ultraslavonic.info>	<50983617.9080203@retired.ox.ac.uk>
	<50A31057.6040507@ultraslavonic.info>	<50A352A8.1000106@retired.ox.ac.uk>
	<50A39EA8.2000904@o2.pl> <50A3A1E5.1030600@uvic.ca>
Message-ID: <50A3AAD8.6020608@retired.ox.ac.uk>

On 14/11/12 13:51, Martin Holmes wrote:
> Or confusing. The example IIRC relates to bibliographic items, not 
> languages or scripts. To remove the potential confusion, it could 
> simply be changed to Cyrillic. Cheers, Martin 
If you mean change the text to use Cyrillic characters, then (as Kevin 
notes), this would not be advisable, since we are *quoting* a text in 
which a Russian title is transliterated into Roman





From bansp at o2.pl  Wed Nov 14 10:41:11 2012
From: bansp at o2.pl (=?ISO-8859-2?Q?Piotr_Ba=F1ski?=)
Date: Wed, 14 Nov 2012 16:41:11 +0100
Subject: [tei-council] reimbursement in non-$
Message-ID: <50A3BB97.9010707@o2.pl>

Out of curiosity: for those of us who applied for reimbursements in
currencies other than USD, how does the amount transferred relate to
your claims, when checked against, e.g.

http://www.oanda.com/currency/converter/

?

(in case you're wondering: I'm OK, I can afford to donate the difference
to the TEI, it used to be worse; but I'm wondering about the general
principle applied in such cases, as it's never seemed very transparent
-- I mean, have I made a false, overstated claim? I'd like to be able to
apologise if that were the case...)

Thanks,

  P.

PS. Let me also note that the mention of Sarah as the Treasurer is
outdated at:

http://wiki.tei-c.org/index.php/TEI-Council-FAQ#What_funding_is_available_for_Council_Activities.3F

(I'm afraid to fix it myself: not sure who it should point to, and maybe
rather at a TEI-related rather than personal e-mail address)

and that the as-of-then unapproved procedure at and below
http://www.tei-c.org/Board/procedures.xml#body.1_div.8

cites a reasonable month, rather than 10 days, as the reporting period.

From kevin.s.hawkins at ultraslavonic.info  Wed Nov 14 10:52:03 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Wed, 14 Nov 2012 10:52:03 -0500
Subject: [tei-council] reimbursement in non-$
In-Reply-To: <50A3BB97.9010707@o2.pl>
References: <50A3BB97.9010707@o2.pl>
Message-ID: <50A3BE23.6000403@ultraslavonic.info>

On 11/14/2012 10:41 AM, Piotr Ba?ski wrote:
> PS. Let me also note that the mention of Sarah as the Treasurer is
> outdated at:
>
> http://wiki.tei-c.org/index.php/TEI-Council-FAQ#What_funding_is_available_for_Council_Activities.3F
>
> (I'm afraid to fix it myself: not sure who it should point to, and maybe
> rather at a TEI-related rather than personal e-mail address)

I've updated this to show that John Unsworth is the new treasurer.  As 
John said during the business meeting, th duties only officially shifted 
from Virginia to him.  Thanks for reporting that.

> and that the as-of-then unapproved procedure at and below
> http://www.tei-c.org/Board/procedures.xml#body.1_div.8
>
> cites a reasonable month, rather than 10 days, as the reporting period.

Hmm.  Looks like James added the 10-day period to the wiki on 23 
November 2006, whereas 
http://www.tei-c.org/Board/procedures.xml#body.1_div.8 was supposedly 
drafted in May 2009.  Don't know which is correct.

From mholmes at uvic.ca  Wed Nov 14 20:01:31 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Wed, 14 Nov 2012 17:01:31 -0800
Subject: [tei-council] Oddity with Roma
Message-ID: <50A43EEB.4090809@uvic.ca>

I have an ODD file here:

<https://hcmc.uvic.ca/people/martin/test/london_all2.odd>

When I generate an RNG schema from it, the schema seems to disallow some 
attributes which I haven't explicitly removed. Specifically, it doesn't 
allow:

@rend on <hi>
@xml:lang on <foreign>

I can't for the life of me see why this is happening. Can anyone else? 
@rend is explicitly removed from lots of elements, but not <hi>; and 
@xml:lang is removed from lots of elements, but not from <foreign>. 
Neither attribute is removed from att.global.

I've tried this with the live Roma on tei-c and at the command line.

This ODD file was originally created using oddbyexample.xsl, but then 
re-uploaded into Roma and tweaked a bit. It validates, and I can't see 
anything wrong with it.

Cheers,
Martin
-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From sebastian.rahtz at it.ox.ac.uk  Thu Nov 15 07:14:21 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Thu, 15 Nov 2012 12:14:21 +0000
Subject: [tei-council] Oddity with Roma
In-Reply-To: <50A43EEB.4090809@uvic.ca>
References: <50A43EEB.4090809@uvic.ca>
Message-ID: <941B3D20-0022-4251-A9B9-FF6A93D4D42A@it.ox.ac.uk>

I have another report of an anomalous omission of attributes to look at, so this may
be the same thing.

it will be my holiday task for the afternoon.
--
Sebastian Rahtz      
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431


From lou.burnard at retired.ox.ac.uk  Thu Nov 15 08:43:41 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Thu, 15 Nov 2012 13:43:41 +0000
Subject: [tei-council] Oddity with Roma
In-Reply-To: <50A43EEB.4090809@uvic.ca>
References: <50A43EEB.4090809@uvic.ca>
Message-ID: <50A4F18D.6080206@retired.ox.ac.uk>

On 15/11/12 01:01, Martin Holmes wrote:
> I have an ODD file here:
>
> <https://hcmc.uvic.ca/people/martin/test/london_all2.odd>
>
> When I generate an RNG schema from it, the schema seems to disallow some
> attributes which I haven't explicitly removed. Specifically, it doesn't
> allow:
>
> @rend on <hi>
> @xml:lang on <foreign>

It seems suspiciously coincidental that these two attributes used to be 
locally defined on their specific elements, rather than being inherited 
from the att.global class. I wonder if you're picking up an old version 
of something somewhere along the way?


From mholmes at uvic.ca  Thu Nov 15 11:29:10 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Thu, 15 Nov 2012 08:29:10 -0800
Subject: [tei-council] Oddity with Roma
In-Reply-To: <50A4F18D.6080206@retired.ox.ac.uk>
References: <50A43EEB.4090809@uvic.ca> <50A4F18D.6080206@retired.ox.ac.uk>
Message-ID: <50A51856.9000306@uvic.ca>

On 12-11-15 05:43 AM, Lou Burnard wrote:
> On 15/11/12 01:01, Martin Holmes wrote:
>> I have an ODD file here:
>>
>> <https://hcmc.uvic.ca/people/martin/test/london_all2.odd>
>>
>> When I generate an RNG schema from it, the schema seems to disallow some
>> attributes which I haven't explicitly removed. Specifically, it doesn't
>> allow:
>>
>> @rend on <hi>
>> @xml:lang on <foreign>
>
> It seems suspiciously coincidental that these two attributes used to be
> locally defined on their specific elements, rather than being inherited
> from the att.global class. I wonder if you're picking up an old version
> of something somewhere along the way?

Judging by the svn log, this must have happened quite a while ago. The 
first time I worked on this schema would have been the summer of 2011, 
and I've tweaked the ODD file repeatedly since then, but I've never used 
Roma to do it. Yesterday, at a TEI workshop we were giving, one of our 
RAs took my ODD file and uploaded it into Roma to add some new elements 
and attributes he needed. The result was the broken schema, although as 
far as I can see there's nothing wrong with the ODD file itself.

Other people at the same workshop managed to generate broken schemas 
too; a problem I saw twice was duplicate definitions of att.ascribed. We 
had no trouble with schemas where people just added modules, but once 
they started removing elements and attributes from their modules, they 
had some problems. I hadn't really thought before how easy it is to 
generate something irrational if you don't know exactly what you're 
doing -- you can for instance remove <biblStruct> and leave <analytic>, 
and then the sanity checker will rightly point out that you can't get to 
<analytic> from anywhere; that sort of thing isn't Roma's fault, and I 
don't think it causes a broken schema in itself, but it all made me 
realize that Roma isn't really a tool for novices, once you go beyond 
selecting your modules.

When I get a chance to check out the latest Byzantium I'll try running 
it through there.

Cheers,
Martin

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From sebastian.rahtz at it.ox.ac.uk  Thu Nov 15 11:53:01 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Thu, 15 Nov 2012 16:53:01 +0000
Subject: [tei-council] Oddity with Roma
In-Reply-To: <50A43EEB.4090809@uvic.ca>
References: <50A43EEB.4090809@uvic.ca>
Message-ID: <CE0235C6-90EC-4BDF-B9AA-EDCB4AFDEC9B@it.ox.ac.uk>


On 15 Nov 2012, at 01:01, Martin Holmes <mholmes at uvic.ca> wrote:

> I have an ODD file here:
> 
> <https://hcmc.uvic.ca/people/martin/test/london_all2.odd>
> 
> When I generate an RNG schema from it, the schema seems to disallow some 
> attributes which I haven't explicitly removed. Specifically, it doesn't 
> allow:
> 
> @rend on <hi>
> @xml:lang on <foreign>
> 

This is now resolved. I think it is yet another fallout from the work
done in June on local override of class attributes. I have
added another  test file in the Stylesheets which is all about this area,
so maybe another hole in the dike is plugged.


--
Sebastian Rahtz      
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431


From sebastian.rahtz at it.ox.ac.uk  Thu Nov 15 12:02:47 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Thu, 15 Nov 2012 17:02:47 +0000
Subject: [tei-council] Oddity with Roma
In-Reply-To: <50A51856.9000306@uvic.ca>
References: <50A43EEB.4090809@uvic.ca> <50A4F18D.6080206@retired.ox.ac.uk>
	<50A51856.9000306@uvic.ca>
Message-ID: <61ADE5A7-A1DC-4D6B-B579-C3EADA05AC78@it.ox.ac.uk>


On 15 Nov 2012, at 16:29, Martin Holmes <mholmes at uvic.ca> wrote:
> 
> Other people at the same workshop managed to generate broken schemas 
> too; a problem I saw twice was duplicate definitions of att.ascribed.

can you reproduce that?

> We 
> had no trouble with schemas where people just added modules, but once 
> they started removing elements and attributes from their modules, they 
> had some problems. I hadn't really thought before how easy it is to 
> generate something irrational if you don't know exactly what you're 
> doing

gosh yes. that's exactly why the sanity check exists.

> When I get a chance to check out the latest Byzantium I'll try running 
> it through there.


Byzantium and Roma both simply call OxGarage to do any processing,
so don't expect differences!

Byzantium does now have some features that Roma does not - for example, it 
does not allow you to get at attributes on an element coming from a
class, if the class is defined in a module you haven't loaded yet. Nick is working
at the moment on some graphical display of your choices, which I think
may be a direction teachers will like.

Github aficionadoes may like to grab from https://github.com/Burlinn/Byzantium
and give the eastern Rome a twirl on the dancefloor. He (Nick) only has two
more weeks on this, so we won't get a lot more functionality done, but I think
it is a foundation our community can build on. It is a lot easier to hack than Roma,
comprising under 1000 lines of Javascript, and no external dependencies apart
from OxGarage.
--
Sebastian Rahtz      
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431


From lou.burnard at retired.ox.ac.uk  Thu Nov 15 13:42:35 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Thu, 15 Nov 2012 18:42:35 +0000
Subject: [tei-council] Oddity with Roma
In-Reply-To: <61ADE5A7-A1DC-4D6B-B579-C3EADA05AC78@it.ox.ac.uk>
References: <50A43EEB.4090809@uvic.ca> <50A4F18D.6080206@retired.ox.ac.uk>
	<50A51856.9000306@uvic.ca>
	<61ADE5A7-A1DC-4D6B-B579-C3EADA05AC78@it.ox.ac.uk>
Message-ID: <50A5379B.9060306@retired.ox.ac.uk>

 >Github aficionadoes may like to grab from 
https://github.com/Burlinn/Byzantium and give the eastern >Rome a twirl 
on the dancefloor. He (Nick) only has two more weeks on this, so we 
won't get a lot >more functionality done, but I think it is a foundation 
our community can build on.

1. selecting a different language (e.g. francais) doesnt seem to do anything

2. I don't think "unadded" is a word is it? But in any case it makes no 
sense at all to base the camembert on the module count : elements 
included in the schema would be more use

3. I tried to supply a name for my customisation and save it, I got an 
amusing box headed "javascript alert" containing (just) a red exclamatin 
mark and an OK button

4. Pressing "export" (with ODD selected in the dropdown) gave me a file 
called "teidoc" rather than the name I supplied in (3) together with 
another inscrutable javascript alert. On inspection this did include a 
valid ODD

5. Ditto with HTML gave me a file called "teidoc.html" which looked 
promising but didnt seem to have anything in it except the title

6. Dito with DTD. Empty DTD.










It is a lot easier to hack than Roma, comprising under 1000 lines of 
Javascript, and no external dependencies apart from OxGarage. -- 
Sebastian Rahtz Director (Research Support) of Academic IT Services 
University of Oxford IT Services 13 Banbury Road, Oxford OX2 6NN. Phone 
+44 1865 283431


From mholmes at uvic.ca  Thu Nov 15 14:15:47 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Thu, 15 Nov 2012 11:15:47 -0800
Subject: [tei-council] Oddity with Roma
In-Reply-To: <61ADE5A7-A1DC-4D6B-B579-C3EADA05AC78@it.ox.ac.uk>
References: <50A43EEB.4090809@uvic.ca> <50A4F18D.6080206@retired.ox.ac.uk>
	<50A51856.9000306@uvic.ca>
	<61ADE5A7-A1DC-4D6B-B579-C3EADA05AC78@it.ox.ac.uk>
Message-ID: <50A53F63.2040105@uvic.ca>

On 12-11-15 09:02 AM, Sebastian Rahtz wrote:
>
> On 15 Nov 2012, at 16:29, Martin Holmes <mholmes at uvic.ca> wrote:
>>
>> Other people at the same workshop managed to generate broken schemas
>> too; a problem I saw twice was duplicate definitions of att.ascribed.
>
> can you reproduce that?

I've just recovered one from someone's trash:

ODD:
<http://hcmc.uvic.ca/people/martin/test/PL.xml>

RNG:
<http://hcmc.uvic.ca/people/martin/test/PL.rng>

The error on this one is "E [Jing] multiple definitions of 
"att.global.facs.attribute.facs" without "combine" attribute", but I saw 
something similar with att.ascribed on other machines if I remember 
correctly. Looking at this one, I realize he started from TEI Lite. I 
wonder if that's what the others did too?

>> We
>> had no trouble with schemas where people just added modules, but once
>> they started removing elements and attributes from their modules, they
>> had some problems. I hadn't really thought before how easy it is to
>> generate something irrational if you don't know exactly what you're
>> doing
>
> gosh yes. that's exactly why the sanity check exists.
>
>> When I get a chance to check out the latest Byzantium I'll try running
>> it through there.
>
> Byzantium and Roma both simply call OxGarage to do any processing,
> so don't expect differences!
>
> Byzantium does now have some features that Roma does not - for example, it
> does not allow you to get at attributes on an element coming from a
> class, if the class is defined in a module you haven't loaded yet. Nick is working
> at the moment on some graphical display of your choices, which I think
> may be a direction teachers will like.

I'm looking forward to seeing that. I hadn't taught the use of Roma in 
the last few years, and after yesterday I have a few ideas for minor 
improvements (for instance, the sanity check messages are 
programmer-messages and ordinary users couldn't make head or tail of 
them). But if I have time I'd also like to write a tutorial for using 
Roma, or at least some better presentation materials for myself.

> Github aficionadoes may like to grab from https://github.com/Burlinn/Byzantium
> and give the eastern Rome a twirl on the dancefloor. He (Nick) only has two
> more weeks on this, so we won't get a lot more functionality done, but I think
> it is a foundation our community can build on. It is a lot easier to hack than Roma,
> comprising under 1000 lines of Javascript, and no external dependencies apart
> from OxGarage.

Sorry I haven't been able to help with this. The last couple of months 
have been insanely busy. I do want to get involved as soon as I can, though.

Cheers,
Martin

> --
> Sebastian Rahtz
> Director (Research Support) of Academic IT Services
> University of Oxford IT Services
> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>
> .
>

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From sebastian.rahtz at it.ox.ac.uk  Thu Nov 15 14:20:28 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Thu, 15 Nov 2012 19:20:28 +0000
Subject: [tei-council] Oddity with Roma
In-Reply-To: <50A5379B.9060306@retired.ox.ac.uk>
References: <50A43EEB.4090809@uvic.ca> <50A4F18D.6080206@retired.ox.ac.uk>
	<50A51856.9000306@uvic.ca>
	<61ADE5A7-A1DC-4D6B-B579-C3EADA05AC78@it.ox.ac.uk>
	<50A5379B.9060306@retired.ox.ac.uk>
Message-ID: <5701b2fa-64ea-4873-a96b-da175753823b@HUB04.ad.oak.ox.ac.uk>


On 15 Nov 2012, at 18:42, Lou Burnard <lou.burnard at retired.ox.ac.uk> wrote:

> 
> 1. selecting a different language (e.g. francais) doesnt seem to do anything
> 

it does not do what you may think. its sets @docLang on the <schemaSpec>

> 2. I don't think "unadded" is a word is it? But in any case it makes no 
> sense at all to base the camembert on the module count : elements 
> included in the schema would be more use
strangely, I am working on just that even as we speak
> 
> 3. I tried to supply a name for my customisation and save it, I got an 
> amusing box headed "javascript alert" containing (just) a red exclamatin 
> mark and an OK button
pass
> 
> 4. Pressing "export" (with ODD selected in the dropdown) gave me a file 
> called "teidoc" rather than the name I supplied in (3) together with 
> another inscrutable javascript alert. On inspection this did include a 
> valid ODD

Nick may be in the middle of breaking this...

> 
> 5. Ditto with HTML gave me a file called "teidoc.html" which looked 
> promising but didnt seem to have anything in it except the title
> 
> 6. Dito with DTD. Empty DTD.


ah. his release may not have the fix yet.

switch tack and use https://github.com/sebastianrahtz/Byzantium instead, that 
has some things made nicer
--
Sebastian Rahtz      
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431


From sebastian.rahtz at it.ox.ac.uk  Thu Nov 15 18:27:36 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Thu, 15 Nov 2012 23:27:36 +0000
Subject: [tei-council] Oddity with Roma
In-Reply-To: <50A53F63.2040105@uvic.ca>
References: <50A43EEB.4090809@uvic.ca> <50A4F18D.6080206@retired.ox.ac.uk>
	<50A51856.9000306@uvic.ca>
	<61ADE5A7-A1DC-4D6B-B579-C3EADA05AC78@it.ox.ac.uk>
	<50A53F63.2040105@uvic.ca>
Message-ID: <89DD6AAF-695A-44FE-A823-856D202D52FF@it.ox.ac.uk>


On 15 Nov 2012, at 19:15, Martin Holmes <mholmes at uvic.ca> wrote:

> <http://hcmc.uvic.ca/people/martin/test/PL.xml>

yes, this is a problem because of its inheritance from tei_lite. That has the incantation

     <classRef key="att.global.facs"/>

because it only wants @facs, not the rest of the transcr module.

The student has then loaded the "transcr" module on top, thereby asking for 
att.global.facs _again_. As usual, the stylesheets are not very good
at finding your logical errors.

Moral: don't base your ODD on Lite, unless you are very sure you understand
what you are doing.
--
Sebastian Rahtz      
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431


From sebastian.rahtz at it.ox.ac.uk  Thu Nov 15 18:32:18 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Thu, 15 Nov 2012 23:32:18 +0000
Subject: [tei-council] Oddity with Roma
In-Reply-To: <50A53F63.2040105@uvic.ca>
References: <50A43EEB.4090809@uvic.ca> <50A4F18D.6080206@retired.ox.ac.uk>
	<50A51856.9000306@uvic.ca>
	<61ADE5A7-A1DC-4D6B-B579-C3EADA05AC78@it.ox.ac.uk>
	<50A53F63.2040105@uvic.ca>
Message-ID: <E8CE5A27-5329-4FCC-B400-EBED49DC202C@it.ox.ac.uk>

and before anyone asks:

  1. yes, I have trapped this particular situation, and now the class won't be duplicated
  2. no, you can't see or edit the <classRef> elements in Roma, so the student had no way of knowing they had made a mistake
  3. no, I can't enable that in Roma
  4. no, you cant see the beasts in Byzantium either
--
Sebastian Rahtz      
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431


From mholmes at uvic.ca  Thu Nov 15 18:59:51 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Thu, 15 Nov 2012 15:59:51 -0800
Subject: [tei-council] Oddity with Roma
In-Reply-To: <89DD6AAF-695A-44FE-A823-856D202D52FF@it.ox.ac.uk>
References: <50A43EEB.4090809@uvic.ca> <50A4F18D.6080206@retired.ox.ac.uk>
	<50A51856.9000306@uvic.ca>
	<61ADE5A7-A1DC-4D6B-B579-C3EADA05AC78@it.ox.ac.uk>
	<50A53F63.2040105@uvic.ca>
	<89DD6AAF-695A-44FE-A823-856D202D52FF@it.ox.ac.uk>
Message-ID: <50A581F7.9090009@uvic.ca>

On 12-11-15 03:27 PM, Sebastian Rahtz wrote:
>
> On 15 Nov 2012, at 19:15, Martin Holmes <mholmes at uvic.ca> wrote:
>
>> <http://hcmc.uvic.ca/people/martin/test/PL.xml>
>
> yes, this is a problem because of its inheritance from tei_lite. That has the incantation
>
>       <classRef key="att.global.facs"/>
>
> because it only wants @facs, not the rest of the transcr module.
>
> The student has then loaded the "transcr" module on top, thereby asking for
> att.global.facs _again_. As usual, the stylesheets are not very good
> at finding your logical errors.

That makes perfect sense. Thanks for fixing it.

>
> Moral: don't base your ODD on Lite, unless you are very sure you understand
> what you are doing.

I wouldn't dream of using Lite myself, but it's the first thing almost 
all my students chose. They were intimidated by both "start from 
nothing" and "start from everything", which both seemed like a lot of 
work, and they looked for something that seemed like it would be useful 
but not overwhelming.

Cheers,
Martin


> --
> Sebastian Rahtz
> Director (Research Support) of Academic IT Services
> University of Oxford IT Services
> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>
>

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From mholmes at uvic.ca  Thu Nov 15 20:20:58 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Thu, 15 Nov 2012 17:20:58 -0800
Subject: [tei-council] New Prefix Definition Proposal (was "Private URI
 Schemes")
In-Reply-To: <50A3179B.7030104@ultraslavonic.info>
References: <5076E9AB.8030600@uvic.ca> <50A3179B.7030104@ultraslavonic.info>
Message-ID: <50A594FA.2080507@uvic.ca>

I've expanded the document a little:

<http://wiki.tei-c.org/index.php/Prefix_Definition_Proposal>

by adding a section on revisions to the Guidelines, including a link to 
this document:

<http://tei.svn.sourceforge.net/viewvc/tei/trunk/P5/temp-dev/prefix_definition_proposal_draft.xml?view=markup>

which provides a proposed new section for chapter 16.

Please take a look and comment if you have time. I propose to start 
making the changes about a week from now.

Cheers,
Martin

On 12-11-13 08:01 PM, Kevin Hawkins wrote:
> I've clarified some wording and some of the statement of context, and
> I've added a comment at the end comparing to @xml:base.  Basically,
> though, it looks good to me.  --Kevin
>
> On 10/11/12 11:45 AM, Martin Holmes wrote:
>> Hi all,
>>
>> At the Council meeting we discussed my proposal for Private URI Schemes,
>> and I was tasked with rewriting it in a more generic form to make it
>> more broadly applicable. I've created a new version here:
>>
>> <http://wiki.tei-c.org/index.php/Prefix_Definition_Proposal>
>>
>> All comments are welcome, and there's a Notes section at the end you can
>> add your concerns to. I'll also raise a ticket for it too, to make sure
>> we don't lose track of it. There's no pressure to get this into the
>> upcoming release, so we can take our time with it.
>>
>> Cheers,
>> Martin
>>

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From kevin.s.hawkins at ultraslavonic.info  Thu Nov 15 21:05:00 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Thu, 15 Nov 2012 21:05:00 -0500
Subject: [tei-council] representing transliteration in @xml:lang (was
 Re: biblscope and imprint)
In-Reply-To: <50A3A1E5.1030600@uvic.ca>
References: <5093A831.7080901@retired.ox.ac.uk>
	<5093D8C8.6090209@ultraslavonic.info>	<5093DDC7.1050504@kcl.ac.uk>
	<5093E2BB.6010106@ultraslavonic.info>	<50940D9A.7030007@retired.ox.ac.uk>
	<5095017A.8060903@retired.ox.ac.uk>	<50952166.2060305@ultraslavonic.info>
	<5095A6B4.2080307@retired.ox.ac.uk>	<5095BFB8.2050101@ultraslavonic.info>
	<5095C121.1010600@uvic.ca> <50966524.5010708@retired.ox.ac.uk>
	<5097535E.7060204@ultraslavonic.info> <5097BE42.4080908@uvic.ca>
	<5097CD5C.2030206@ultraslavonic.info> <5097F20F.3080502@uvic.ca>
	<5097F398.7070406@ultraslavonic.info>	<50983617.9080203@retired.ox.ac.uk>
	<50A31057.6040507@ultraslavonic.info>	<50A352A8.1000106@retired.ox.ac.uk>
	<50A39EA8.2000904@o2.pl> <50A3A1E5.1030600@uvic.ca>
Message-ID: <50A59F4C.7080402@ultraslavonic.info>

On 11/14/12 8:51 AM, Martin Holmes wrote:
> The subtag for Russian looks like this:
>
> %%
> Type: language
> Subtag: ru
> Description: Russian
> Added: 2005-10-16
> Suppress-Script: Cyrl
> %%
>
> which I interpret to mean that the default script is Cyrl; that means
> that you don't need to say ru-Cyrl, and in fact ru = ru-Cyrl. Therefore
> if we retain this example, we must supply a script subtag.

BCP 47 says that you should not use a script subtag in combination with 
a language subtag for which a suppress script is given.  That is, 
"ru-Cyrl" is incorrect.  Nothing in BCP 47 says that you must or even 
should use a script subtag if there is a different script.  That is, 
"ru" for transliterated is not a lie, as Lou says.

>> Kevin is right that "ru" is
>> underspecification, but it's very wide, so wide as to imply the default
>> that isn't the case. "ru-Latn" is still underspecification, but much
>> narrower, and with some consequences for machine processing.
>
> Agreed. It's much better than nothing, and I don't think that there's a
> requirement that it be more precise. More precise would be better, and
> more processable, but since "ru-Latn" is actually used as an example in
> the W3C explanatory document, I maintain that it's at least adequate,
> and since the actual subtag required is not (yet) available, we should
> stick with it.

We all seem happy with "ru-Latn".  I was about to make that change, but 
I see that Lou did that already on 4 November.

>> Commenting on this further in the Guidelines seems a matter of taste and
>> balance, possibly a footnote on the existence of many alternative
>> romanized transliterations might be quite useful.

It's tempting to add a footnote, but I we can't put a footnote siglum 
inside of an <egXML> without it being confusing, and I don't see another 
sensible point of attachment.  I think it's fine how it is.

--Kevin

From James.Cummings at it.ox.ac.uk  Fri Nov 16 05:10:38 2012
From: James.Cummings at it.ox.ac.uk (James Cummings)
Date: Fri, 16 Nov 2012 10:10:38 +0000
Subject: [tei-council] reimbursement in non-$
In-Reply-To: <50A3BE23.6000403@ultraslavonic.info>
References: <50A3BB97.9010707@o2.pl> <50A3BE23.6000403@ultraslavonic.info>
Message-ID: <50A6111E.6050803@it.ox.ac.uk>

On 14/11/12 15:52, Kevin Hawkins wrote:
>> and that the as-of-then unapproved procedure at and below
>> http://www.tei-c.org/Board/procedures.xml#body.1_div.8
>>
>> cites a reasonable month, rather than 10 days, as the reporting period.
>
> Hmm.  Looks like James added the 10-day period to the wiki on 23
> November 2006, whereas
> http://www.tei-c.org/Board/procedures.xml#body.1_div.8 was supposedly
> drafted in May 2009.  Don't know which is correct.

Probably likely that both were correct at time of writing.  Feel 
free to correct the wiki of course. ;-)

-James


-- 
Dr James Cummings, James.Cummings at it.ox.ac.uk
Academic IT Services, University of Oxford

From bansp at o2.pl  Fri Nov 16 05:23:33 2012
From: bansp at o2.pl (=?ISO-8859-2?Q?Piotr_Ba=F1ski?=)
Date: Fri, 16 Nov 2012 11:23:33 +0100
Subject: [tei-council] reimbursement in non-$
In-Reply-To: <50A6111E.6050803@it.ox.ac.uk>
References: <50A3BB97.9010707@o2.pl> <50A3BE23.6000403@ultraslavonic.info>
	<50A6111E.6050803@it.ox.ac.uk>
Message-ID: <50A61425.2040404@o2.pl>

On 16/11/12 11:10, James Cummings wrote:
> On 14/11/12 15:52, Kevin Hawkins wrote:
>>> and that the as-of-then unapproved procedure at and below
>>> http://www.tei-c.org/Board/procedures.xml#body.1_div.8
>>>
>>> cites a reasonable month, rather than 10 days, as the reporting period.
>>
>> Hmm.  Looks like James added the 10-day period to the wiki on 23
>> November 2006, whereas
>> http://www.tei-c.org/Board/procedures.xml#body.1_div.8 was supposedly
>> drafted in May 2009.  Don't know which is correct.
> 
> Probably likely that both were correct at time of writing.  Feel 
> free to correct the wiki of course. ;-)

The reimbursement doc says 10 days, so this is an additional place for
potential corrections. Despite appearances, a 10 day deadline can be a
pain to meet, and I don't quite see why such a limit should be set up in
the first place, so I hope (for the sake of the continuing Council :-))
that it can go away.

  P.

From kevin.s.hawkins at ultraslavonic.info  Fri Nov 16 10:42:32 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Fri, 16 Nov 2012 10:42:32 -0500
Subject: [tei-council] reimbursement in non-$
In-Reply-To: <50A61425.2040404@o2.pl>
References: <50A3BB97.9010707@o2.pl>
	<50A3BE23.6000403@ultraslavonic.info>	<50A6111E.6050803@it.ox.ac.uk>
	<50A61425.2040404@o2.pl>
Message-ID: <50A65EE8.8060805@ultraslavonic.info>

On 11/16/2012 5:23 AM, Piotr Ba?ski wrote:
> On 16/11/12 11:10, James Cummings wrote:
>> On 14/11/12 15:52, Kevin Hawkins wrote:
>>>> and that the as-of-then unapproved procedure at and below
>>>> http://www.tei-c.org/Board/procedures.xml#body.1_div.8
>>>>
>>>> cites a reasonable month, rather than 10 days, as the reporting period.
>>>
>>> Hmm.  Looks like James added the 10-day period to the wiki on 23
>>> November 2006, whereas
>>> http://www.tei-c.org/Board/procedures.xml#body.1_div.8 was supposedly
>>> drafted in May 2009.  Don't know which is correct.
>>
>> Probably likely that both were correct at time of writing.  Feel
>> free to correct the wiki of course. ;-)
>
> The reimbursement doc says 10 days, so this is an additional place for
> potential corrections. Despite appearances, a 10 day deadline can be a
> pain to meet, and I don't quite see why such a limit should be set up in
> the first place, so I hope (for the sake of the continuing Council :-))
> that it can go away.

I've added a note to:

http://wiki.tei-c.org/index.php/Suggestions_for_bylaws_and_procedures#Board_procedures_document

a page which I've been adding to and which Elena is aware of.

From sebastian.rahtz at it.ox.ac.uk  Sat Nov 17 13:47:55 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Sat, 17 Nov 2012 18:47:55 +0000
Subject: [tei-council] byzantine amusement
Message-ID: <C4F0E2EC-693E-4F2C-A398-AC64CDC8D6C5@it.ox.ac.uk>

you're probably tired of this already, but if not you could try http://tei.oucs.ox.ac.uk/Byzantium/
for a current more or less working setup. I entertained myself on my day off yesterday
by redoing the whole interface to use tabs.
--
Sebastian Rahtz      
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431


From bansp at o2.pl  Sat Nov 17 14:04:17 2012
From: bansp at o2.pl (=?ISO-8859-2?Q?Piotr_Ba=F1ski?=)
Date: Sat, 17 Nov 2012 20:04:17 +0100
Subject: [tei-council] byzantine amusement
In-Reply-To: <C4F0E2EC-693E-4F2C-A398-AC64CDC8D6C5@it.ox.ac.uk>
References: <C4F0E2EC-693E-4F2C-A398-AC64CDC8D6C5@it.ox.ac.uk>
Message-ID: <50A7DFB1.2000709@o2.pl>

Ho ho... impressive.

And who's Nick Burlingame? Was this some kind of TEI-oriented job or a
general interface work?

  P.


On 17/11/12 19:47, Sebastian Rahtz wrote:
> you're probably tired of this already, but if not you could try http://tei.oucs.ox.ac.uk/Byzantium/
> for a current more or less working setup. I entertained myself on my day off yesterday
> by redoing the whole interface to use tabs.
> --
> Sebastian Rahtz      
> Director (Research Support) of Academic IT Services 
> University of Oxford IT Services
> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
> 


From sebastian.rahtz at it.ox.ac.uk  Sat Nov 17 14:10:02 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Sat, 17 Nov 2012 19:10:02 +0000
Subject: [tei-council] byzantine amusement
In-Reply-To: <50A7DFB1.2000709@o2.pl>
References: <C4F0E2EC-693E-4F2C-A398-AC64CDC8D6C5@it.ox.ac.uk>
	<50A7DFB1.2000709@o2.pl>
Message-ID: <754CE423-E5A7-464E-83C0-8F0D026B32FE@it.ox.ac.uk>


On 17 Nov 2012, at 19:04, Piotr Ba?ski <bansp at o2.pl>
 wrote:

> 
> And who's Nick Burlingame? Was this some kind of TEI-oriented job or a
> general interface work?

Nick is a student intern from the University of Georgia.

--
Sebastian Rahtz      
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431


From lou.burnard at retired.ox.ac.uk  Sat Nov 17 14:45:16 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Sat, 17 Nov 2012 19:45:16 +0000
Subject: [tei-council] byzantine amusement
In-Reply-To: <C4F0E2EC-693E-4F2C-A398-AC64CDC8D6C5@it.ox.ac.uk>
References: <C4F0E2EC-693E-4F2C-A398-AC64CDC8D6C5@it.ox.ac.uk>
Message-ID: <50A7E94C.5040809@retired.ox.ac.uk>

certainly looking much slicker. what does "local storage" mean ? and 
where does it put it?

wish it would do odds by inclusion though

On 17/11/12 18:47, Sebastian Rahtz wrote:
> you're probably tired of this already, but if not you could try http://tei.oucs.ox.ac.uk/Byzantium/
> for a current more or less working setup. I entertained myself on my day off yesterday
> by redoing the whole interface to use tabs.
> --
> Sebastian Rahtz
> Director (Research Support) of Academic IT Services
> University of Oxford IT Services
> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>


From sebastian.rahtz at it.ox.ac.uk  Sat Nov 17 14:55:46 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Sat, 17 Nov 2012 19:55:46 +0000
Subject: [tei-council] byzantine amusement
In-Reply-To: <50A7E94C.5040809@retired.ox.ac.uk>
References: <C4F0E2EC-693E-4F2C-A398-AC64CDC8D6C5@it.ox.ac.uk>
	<50A7E94C.5040809@retired.ox.ac.uk>
Message-ID: <85c30ab2-319b-4a21-97f0-10ae0897d4c7@HUB03.ad.oak.ox.ac.uk>


On 17 Nov 2012, at 19:45, Lou Burnard <lou.burnard at retired.ox.ac.uk>
 wrote:

> certainly looking much slicker. what does "local storage" mean ? and where does it put it?
> 
web browsers have their own storage area which you can read and write. not accessible
to the rest of the OS, though.

> wish it would do odds by inclusion though


its coming...
--
Sebastian Rahtz      
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431


From kevin.s.hawkins at ultraslavonic.info  Sat Nov 17 15:17:56 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Sat, 17 Nov 2012 15:17:56 -0500
Subject: [tei-council] byzantine amusement
In-Reply-To: <C4F0E2EC-693E-4F2C-A398-AC64CDC8D6C5@it.ox.ac.uk>
References: <C4F0E2EC-693E-4F2C-A398-AC64CDC8D6C5@it.ox.ac.uk>
Message-ID: <50A7F0F4.9030909@ultraslavonic.info>

In the spirit of amusement, I'd like to say that, in case we ever 
commission a replacement to Byzantium and I'm not still on Council to 
speak up for it, please name it "Moscua".

http://la.wikipedia.org/wiki/Moscua

It is, as explained here, "Tertia Roma".

On 11/17/12 1:47 PM, Sebastian Rahtz wrote:
> you're probably tired of this already, but if not you could try http://tei.oucs.ox.ac.uk/Byzantium/
> for a current more or less working setup. I entertained myself on my day off yesterday
> by redoing the whole interface to use tabs.
> --
> Sebastian Rahtz
> Director (Research Support) of Academic IT Services
> University of Oxford IT Services
> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>

From bansp at o2.pl  Sat Nov 17 15:39:45 2012
From: bansp at o2.pl (=?ISO-8859-2?Q?Piotr_Ba=F1ski?=)
Date: Sat, 17 Nov 2012 21:39:45 +0100
Subject: [tei-council] byzantine amusement
In-Reply-To: <50A7F0F4.9030909@ultraslavonic.info>
References: <C4F0E2EC-693E-4F2C-A398-AC64CDC8D6C5@it.ox.ac.uk>
	<50A7F0F4.9030909@ultraslavonic.info>
Message-ID: <50A7F611.9040205@o2.pl>

Mohikau? :-)

http://mi.wikipedia.org/wiki/Mohikau


On 17/11/12 21:17, Kevin Hawkins wrote:
> In the spirit of amusement, I'd like to say that, in case we ever 
> commission a replacement to Byzantium and I'm not still on Council to 
> speak up for it, please name it "Moscua".
> 
> http://la.wikipedia.org/wiki/Moscua
> 
> It is, as explained here, "Tertia Roma".
> 
> On 11/17/12 1:47 PM, Sebastian Rahtz wrote:
>> you're probably tired of this already, but if not you could try http://tei.oucs.ox.ac.uk/Byzantium/
>> for a current more or less working setup. I entertained myself on my day off yesterday
>> by redoing the whole interface to use tabs.
>> --
>> Sebastian Rahtz
>> Director (Research Support) of Academic IT Services
>> University of Oxford IT Services
>> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>>


From mholmes at uvic.ca  Mon Nov 19 13:17:05 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Mon, 19 Nov 2012 10:17:05 -0800
Subject: [tei-council] Constraints on anyURI
Message-ID: <50AA77A1.1050001@uvic.ca>

I was just addressing myself to some attribute-abuse I've been knowingly 
perpetrating in one of my projects, where I'm using @sameAs with a sort 
of key-like thing:

<m sameAs="n-CTL">...</m>

and I as intending to switch these values to a private URI scheme using 
a prefix. However, in the process I discovered that our encoders have 
been abusing the attribute in a broader sense, by putting multiple 
values in there, occasionally separated by commas:

<m sameAs="n-CTL t-TR ?-OBJ, n-SUBJ">n</m> (full example is below).

This validates against RNG schemas. The datatype of @sameAs is a single 
data.pointer, which is xsd:anyURI, so both the spaces and the comma 
should ideally trigger an error. But the schema doesn't seem to attempt 
to check anyURI values as far as I can see.

Would it be practical to make this happen? In other words, could we 
(perhaps through Schematron) enforce compliance with RFC 3986 and 3987 
for xsd:anyURI values?

I did try validating the file with tei_all.xsd:

<http://www.tei-c.org/release/xml/tei/custom/schema/xsd/tei_all.xsd>

but it doesn't seem to be working properly; I get lots of error messages 
like this:

"Engine name: Xerces
Severity: error
Description: src-resolve: Cannot resolve the name 'xml:base' to a(n) 
'attribute declaration' component.
Start location: 926:35
URL: http://www.w3.org/TR/xmlschema-1/#src-resolve"


[Full entry from which example above comes]
<entry xml:id="??y?uyn_lx">

                <form>
                   <pron>
                      <seg type="p" subtype="i">??y??yn lx</seg>
                      <bibl corresp="psn:ECH">ECH</bibl>
                      <seg type="n">??y??y?nl?x</seg>
                      <bibl corresp="psn:JM psn:AM">Y21.96</bibl>
                   </pron>
                   <hyph>
                      <m sameAs="DIST">C?C</m>+?<m 
sameAs="?uy">??y</m>-<m sameAs="n-CTL t-TR ?-OBJ, n-SUBJ">n</m>
                      <m sameAs="lx">lx</m>
             </hyph>
                </form>

                <sense>
                   <def>
                      <seg>
                         <gloss>annoy</gloss>; <gloss>bother</gloss> 
someone; <gloss>disturb</gloss>
                      </seg>
                      <bibl corresp="psn:JM psn:AM">Y21.96</bibl>
                   </def>
                </sense>

             </entry>

Cheers,
Martin
-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From mholmes at uvic.ca  Mon Nov 19 14:19:16 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Mon, 19 Nov 2012 11:19:16 -0800
Subject: [tei-council] Constraints on anyURI
In-Reply-To: <50AA77A1.1050001@uvic.ca>
References: <50AA77A1.1050001@uvic.ca>
Message-ID: <50AA8634.2030107@uvic.ca>

Further to this: the XML Schema Datatypes rec says:

"Note:  Each URI scheme imposes specialized syntax rules for URIs in 
that scheme, including restrictions on the syntax of allowed fragment 
identifiers. Because it is impractical for processors to check that a 
value is a context-appropriate URI reference, this specification follows 
the lead of [RFC 2396] (as amended by [RFC 2732]) in this matter: such 
rules and restrictions are not part of type validity and are not checked 
by ?minimally conforming? processors. Thus in practice the above 
definition imposes only very modest obligations on ?minimally 
conforming? processors. "

Looking at RFC 3987 (IRIs), I think it's probably impractical to do 
anything approaching real validation, but it might be possible to catch 
some obvious errors (such as spaces in single data.pointer values, or 
percent characters not followed by hexadecimal numbers). Is this worth 
pursuing?

Cheers,
Martin

On 12-11-19 10:17 AM, Martin Holmes wrote:
> I was just addressing myself to some attribute-abuse I've been knowingly
> perpetrating in one of my projects, where I'm using @sameAs with a sort
> of key-like thing:
>
> <m sameAs="n-CTL">...</m>
>
> and I as intending to switch these values to a private URI scheme using
> a prefix. However, in the process I discovered that our encoders have
> been abusing the attribute in a broader sense, by putting multiple
> values in there, occasionally separated by commas:
>
> <m sameAs="n-CTL t-TR ?-OBJ, n-SUBJ">n</m> (full example is below).
>
> This validates against RNG schemas. The datatype of @sameAs is a single
> data.pointer, which is xsd:anyURI, so both the spaces and the comma
> should ideally trigger an error. But the schema doesn't seem to attempt
> to check anyURI values as far as I can see.
>
> Would it be practical to make this happen? In other words, could we
> (perhaps through Schematron) enforce compliance with RFC 3986 and 3987
> for xsd:anyURI values?
>
> I did try validating the file with tei_all.xsd:
>
> <http://www.tei-c.org/release/xml/tei/custom/schema/xsd/tei_all.xsd>
>
> but it doesn't seem to be working properly; I get lots of error messages
> like this:
>
> "Engine name: Xerces
> Severity: error
> Description: src-resolve: Cannot resolve the name 'xml:base' to a(n)
> 'attribute declaration' component.
> Start location: 926:35
> URL: http://www.w3.org/TR/xmlschema-1/#src-resolve"
>
>
> [Full entry from which example above comes]
> <entry xml:id="??y?uyn_lx">
>
>                  <form>
>                     <pron>
>                        <seg type="p" subtype="i">??y??yn lx</seg>
>                        <bibl corresp="psn:ECH">ECH</bibl>
>                        <seg type="n">??y??y?nl?x</seg>
>                        <bibl corresp="psn:JM psn:AM">Y21.96</bibl>
>                     </pron>
>                     <hyph>
>                        <m sameAs="DIST">C?C</m>+?<m
> sameAs="?uy">??y</m>-<m sameAs="n-CTL t-TR ?-OBJ, n-SUBJ">n</m>
>                        <m sameAs="lx">lx</m>
>               </hyph>
>                  </form>
>
>                  <sense>
>                     <def>
>                        <seg>
>                           <gloss>annoy</gloss>; <gloss>bother</gloss>
> someone; <gloss>disturb</gloss>
>                        </seg>
>                        <bibl corresp="psn:JM psn:AM">Y21.96</bibl>
>                     </def>
>                  </sense>
>
>               </entry>
>
> Cheers,
> Martin
>

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From James.Cummings at it.ox.ac.uk  Mon Nov 19 15:28:29 2012
From: James.Cummings at it.ox.ac.uk (James Cummings)
Date: Mon, 19 Nov 2012 20:28:29 +0000
Subject: [tei-council] Constraints on anyURI
In-Reply-To: <50AA8634.2030107@uvic.ca>
References: <50AA77A1.1050001@uvic.ca> <50AA8634.2030107@uvic.ca>
Message-ID: <50AA966D.7010703@it.ox.ac.uk>

Hi Martin,

I think that if possible we should try to validate that 
attributes which contain a single data.pointer do not have any 
spaces in them. More complex validation is certainly possible, 
but lower priority I would say and much more error prone.

-James

On 19/11/12 19:19, Martin Holmes wrote:
> Further to this: the XML Schema Datatypes rec says:
>
> "Note:  Each URI scheme imposes specialized syntax rules for URIs in
> that scheme, including restrictions on the syntax of allowed fragment
> identifiers. Because it is impractical for processors to check that a
> value is a context-appropriate URI reference, this specification follows
> the lead of [RFC 2396] (as amended by [RFC 2732]) in this matter: such
> rules and restrictions are not part of type validity and are not checked
> by ?minimally conforming? processors. Thus in practice the above
> definition imposes only very modest obligations on ?minimally
> conforming? processors. "
>
> Looking at RFC 3987 (IRIs), I think it's probably impractical to do
> anything approaching real validation, but it might be possible to catch
> some obvious errors (such as spaces in single data.pointer values, or
> percent characters not followed by hexadecimal numbers). Is this worth
> pursuing?
>
> Cheers,
> Martin
>
> On 12-11-19 10:17 AM, Martin Holmes wrote:
>> I was just addressing myself to some attribute-abuse I've been knowingly
>> perpetrating in one of my projects, where I'm using @sameAs with a sort
>> of key-like thing:
>>
>> <m sameAs="n-CTL">...</m>
>>
>> and I as intending to switch these values to a private URI scheme using
>> a prefix. However, in the process I discovered that our encoders have
>> been abusing the attribute in a broader sense, by putting multiple
>> values in there, occasionally separated by commas:
>>
>> <m sameAs="n-CTL t-TR ?-OBJ, n-SUBJ">n</m> (full example is below).
>>
>> This validates against RNG schemas. The datatype of @sameAs is a single
>> data.pointer, which is xsd:anyURI, so both the spaces and the comma
>> should ideally trigger an error. But the schema doesn't seem to attempt
>> to check anyURI values as far as I can see.
>>
>> Would it be practical to make this happen? In other words, could we
>> (perhaps through Schematron) enforce compliance with RFC 3986 and 3987
>> for xsd:anyURI values?
>>
>> I did try validating the file with tei_all.xsd:
>>
>> <http://www.tei-c.org/release/xml/tei/custom/schema/xsd/tei_all.xsd>
>>
>> but it doesn't seem to be working properly; I get lots of error messages
>> like this:
>>
>> "Engine name: Xerces
>> Severity: error
>> Description: src-resolve: Cannot resolve the name 'xml:base' to a(n)
>> 'attribute declaration' component.
>> Start location: 926:35
>> URL: http://www.w3.org/TR/xmlschema-1/#src-resolve"
>>
>>
>> [Full entry from which example above comes]
>> <entry xml:id="??y?uyn_lx">
>>
>>                   <form>
>>                      <pron>
>>                         <seg type="p" subtype="i">??y??yn lx</seg>
>>                         <bibl corresp="psn:ECH">ECH</bibl>
>>                         <seg type="n">??y??y?nl?x</seg>
>>                         <bibl corresp="psn:JM psn:AM">Y21.96</bibl>
>>                      </pron>
>>                      <hyph>
>>                         <m sameAs="DIST">C?C</m>+?<m
>> sameAs="?uy">??y</m>-<m sameAs="n-CTL t-TR ?-OBJ, n-SUBJ">n</m>
>>                         <m sameAs="lx">lx</m>
>>                </hyph>
>>                   </form>
>>
>>                   <sense>
>>                      <def>
>>                         <seg>
>>                            <gloss>annoy</gloss>; <gloss>bother</gloss>
>> someone; <gloss>disturb</gloss>
>>                         </seg>
>>                         <bibl corresp="psn:JM psn:AM">Y21.96</bibl>
>>                      </def>
>>                   </sense>
>>
>>                </entry>
>>
>> Cheers,
>> Martin
>>
>


-- 
Dr James Cummings, James.Cummings at it.ox.ac.uk
Academic IT Services, University of Oxford

From sebastian.rahtz at it.ox.ac.uk  Mon Nov 19 16:30:33 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Mon, 19 Nov 2012 21:30:33 +0000
Subject: [tei-council] Constraints on anyURI
In-Reply-To: <50AA77A1.1050001@uvic.ca>
References: <50AA77A1.1050001@uvic.ca>
Message-ID: <BE372B5B-5E36-49CA-A118-91FC0ABEA616@it.ox.ac.uk>

jing seems to fail to check anyURI. but rnv checks the xsd:anyURI better:

Sebastians-MacBook-Pro:Exemplars rahtz$ rnv tei_all.rnc /tmp/foo.xmk 
/tmp/foo.xmk
/tmp/foo.xmk:7:0: error: attribute ^sameAs with invalid value "n-CTL t-TR ?-OBJ, n-SUBJ"
required:
	data http://www.w3.org/2001/XMLSchema-datatypes^anyURI
error: some documents are invalid

But then again, jing may silently URL-encodiing the spaces and commas for us.

I think you could maybe use http://www.w3.org/TR/xpath-functions/#func-resolve-uri in
a Schematron check to check the URI. But surprisingly Saxon seems to accept
almost anything as a valid URI.
--
Sebastian Rahtz      
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431


From mholmes at uvic.ca  Mon Nov 19 17:51:10 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Mon, 19 Nov 2012 14:51:10 -0800
Subject: [tei-council] Constraints on anyURI
In-Reply-To: <BE372B5B-5E36-49CA-A118-91FC0ABEA616@it.ox.ac.uk>
References: <50AA77A1.1050001@uvic.ca>
	<BE372B5B-5E36-49CA-A118-91FC0ABEA616@it.ox.ac.uk>
Message-ID: <50AAB7DE.9050605@uvic.ca>

On 12-11-19 01:30 PM, Sebastian Rahtz wrote:
> jing seems to fail to check anyURI. but rnv checks the xsd:anyURI better:
>
> Sebastians-MacBook-Pro:Exemplars rahtz$ rnv tei_all.rnc /tmp/foo.xmk
> /tmp/foo.xmk
> /tmp/foo.xmk:7:0: error: attribute ^sameAs with invalid value "n-CTL t-TR ?-OBJ, n-SUBJ"
> required:
> 	data http://www.w3.org/2001/XMLSchema-datatypes^anyURI
> error: some documents are invalid
>
> But then again, jing may silently URL-encodiing the spaces and commas for us.
>
> I think you could maybe use http://www.w3.org/TR/xpath-functions/#func-resolve-uri in
> a Schematron check to check the URI. But surprisingly Saxon seems to accept
> almost anything as a valid URI.

I think Saxon is probably playing it safe. As the spec says, there's no 
way to reliably resolve a URI, especially given the range of registered 
and unregistered URI schemes that exist, so the best we can probably do 
is check for some things we know must be wrong (such as spaces, commas 
and perhaps percent signs which don't precede hex numbers). If we do 
this through Schematron it will presumably work for everyone that's 
using RNG with embedded Schematron.

Cheers,
Martin

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From sebastian.rahtz at it.ox.ac.uk  Mon Nov 19 18:10:53 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Mon, 19 Nov 2012 23:10:53 +0000
Subject: [tei-council] Constraints on anyURI
In-Reply-To: <50AAB7DE.9050605@uvic.ca>
References: <50AA77A1.1050001@uvic.ca>
	<BE372B5B-5E36-49CA-A118-91FC0ABEA616@it.ox.ac.uk>
	<50AAB7DE.9050605@uvic.ca>
Message-ID: <C76E4B92-EAE5-40B2-9477-527A30C6152B@it.ox.ac.uk>


On 19 Nov 2012, at 22:51, Martin Holmes <mholmes at uvic.ca>
 wrote:
> I think Saxon is probably playing it safe. As the spec says, there's no 
> way to reliably resolve a URI, especially given the range of registered 
> and unregistered URI schemes that exist, so the best we can probably do 
> is check for some things we know must be wrong (such as spaces, commas 
> and perhaps percent signs which don't precede hex numbers). If we do 
> this through Schematron it will presumably work for everyone that's 
> using RNG with embedded Schematron.
> 



trouble is, when I tried this,. it was clear that Saxon is doing url-encoding
for me. the output of resolve-uri() from

n-/////CTL
foo:n-CT::#:L
http:/n-CTL t-TR ?-OBJ, n-SUBJ

was 

file:/Users/rahtz/TEI/Sourceforge/trunk/P5/Exemplars/n-/CTL
foo:n-CT::#:L
http:/n-CTL%20t-TR%20?-OBJ,%20n-SUBJ

So it is hard to catch it out!
--
Sebastian Rahtz      
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431


From sebastian.rahtz at it.ox.ac.uk  Mon Nov 19 18:19:39 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Mon, 19 Nov 2012 23:19:39 +0000
Subject: [tei-council] Constraints on anyURI
In-Reply-To: <C76E4B92-EAE5-40B2-9477-527A30C6152B@it.ox.ac.uk>
References: <50AA77A1.1050001@uvic.ca>
	<BE372B5B-5E36-49CA-A118-91FC0ABEA616@it.ox.ac.uk>
	<50AAB7DE.9050605@uvic.ca>
	<C76E4B92-EAE5-40B2-9477-527A30C6152B@it.ox.ac.uk>
Message-ID: <98D8C9E9-6E75-43A3-8E52-2DA535C71377@it.ox.ac.uk>

ah. if I run the document() function, I finally get a decent message

Recoverable error on line 604 of tei_all.xsl:
  FODC0002: I/O error reported by XML parser processing file:/tmp/n-/CTL: /tmp/n-/CTL (No
  such file or directory)
@sameAs must be a  valid URI. (resolve-uri(@sameAs))
Freddy foo:n-CT::#:L
Error on line 604 of tei_all.xsl:
  XTRE1160: The fragment identifier {:L} is not a valid NCName

so that may be a worthwhile test to put in  a schematron, just

  test="document(@sameAs)
--
Sebastian Rahtz      
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431


From mholmes at uvic.ca  Mon Nov 19 18:57:45 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Mon, 19 Nov 2012 15:57:45 -0800
Subject: [tei-council] Constraints on anyURI
In-Reply-To: <98D8C9E9-6E75-43A3-8E52-2DA535C71377@it.ox.ac.uk>
References: <50AA77A1.1050001@uvic.ca>
	<BE372B5B-5E36-49CA-A118-91FC0ABEA616@it.ox.ac.uk>
	<50AAB7DE.9050605@uvic.ca>
	<C76E4B92-EAE5-40B2-9477-527A30C6152B@it.ox.ac.uk>
	<98D8C9E9-6E75-43A3-8E52-2DA535C71377@it.ox.ac.uk>
Message-ID: <50AAC779.8090407@uvic.ca>

What happens if you make it:

sameAs="stuff:anything"

That's a valid private URI. If that generates an error, we couldn't use it.

Cheers,
Martin

On 12-11-19 03:19 PM, Sebastian Rahtz wrote:
> ah. if I run the document() function, I finally get a decent message
>
> Recoverable error on line 604 of tei_all.xsl:
>    FODC0002: I/O error reported by XML parser processing file:/tmp/n-/CTL: /tmp/n-/CTL (No
>    such file or directory)
> @sameAs must be a  valid URI. (resolve-uri(@sameAs))
> Freddy foo:n-CT::#:L
> Error on line 604 of tei_all.xsl:
>    XTRE1160: The fragment identifier {:L} is not a valid NCName
>
> so that may be a worthwhile test to put in  a schematron, just
>
>    test="document(@sameAs)
> --
> Sebastian Rahtz
> Director (Research Support) of Academic IT Services
> University of Oxford IT Services
> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>
>

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From gabriel.bodard at kcl.ac.uk  Wed Nov 21 12:11:09 2012
From: gabriel.bodard at kcl.ac.uk (Gabriel Bodard)
Date: Wed, 21 Nov 2012 17:11:09 +0000
Subject: [tei-council] space/certainty in release 2.2.0
In-Reply-To: <50940967.4010007@retired.ox.ac.uk>
References: <50940001.2010101@kcl.ac.uk> <5094013D.4030702@kcl.ac.uk>
	<5094066B.50708@uvic.ca> <50940967.4010007@retired.ox.ac.uk>
Message-ID: <50AD0B2D.1080605@kcl.ac.uk>

Have we made any progress on implementing this fix, and a suggested 
timescale for a 2.2.1 release? (I assume we can increment the third 
digit because this is a bug-fix, not new functionality, and doesn't 
break backward compatibility...)

G

On 2012-11-02 17:56, Lou Burnard wrote:
> See ticket  at http://purl.org/tei/FR/3565137 (the number of which is
> mistyped in the svn log entry, sorry)
>
> I quote from the fairly extensive notes on that ticket:
>
> "char, glyph,incident, interpGrp, joinGrp, kinesic, space, vocal now
> have just model.descLike"
>
> Any others on that list we think on second thoughts ought to be able to
> contain a member of model.certLike?
>
>
>
>
> On 02/11/12 17:44, Martin Holmes wrote:
>> I think it might have been in here:
>>
>> r10940 | louburnard | 2012-10-07 15:37:24 -0700 (Sun, 07 Oct 2012) | 2 lines
>>
>> Separating model.descLike out from model.glossLike and changing some
>> class memberships per FR/3565136
>>
>> So it's pretty recent. Since it breaks backward compatibility, we should:
>>
>> 1. Fix it.
>>
>> 2. Put some <space> elements in the test files, to make sure we catch
>> anything similar in future.
>>
>> 3. Do 2.2.1 fairly soon.
>>
>> Cheers,
>> Martin
>>
>> On 12-11-02 10:22 AM, Gabriel Bodard wrote:
>>> Oh, I see what happened. model.certLike is no longer a member of
>>> model.glossLike, and when this was changed, presumably someone forgot to
>>> add model.certLike to <space>, which previously inherited it.
>>>
>>> Does this need a 2.2.1 release to fix (along with anything else we spot
>>> like this?)
>>>
>>> G
>>>
>>> On 2012-11-02 17:16, Gabriel Bodard wrote:
>>>> A weird thing has happened: for the last couple of years now <space> has
>>>> had the same content model as <gap>: i.e. ( model.descLike |
>>>> model.certLike )*
>>>>
>>>> As of the latest release, however, that seems to have reverted to
>>>> model.descLike* only (breaking a number of my files).
>>>>
>>>> Does anyone know how this happened, and can we try to fix this asap please?
>>>>
>>>> G
>>>>
>>>
>>
>

-- 
Dr Gabriel BODARD
Researcher in Digital Epigraphy

Digital Humanities
King's College London
26-29 Drury Lane
London WC2B 5RL

T: +44 (0)20 7848 1388
F: +44 (0)20 7848 2980
E: gabriel.bodard at kcl.ac.uk

http://www.digitalclassicist.org/
http://www.currentepigraphy.org/


From gabriel.bodard at kcl.ac.uk  Thu Nov 22 12:00:35 2012
From: gabriel.bodard at kcl.ac.uk (Gabriel Bodard)
Date: Thu, 22 Nov 2012 17:00:35 +0000
Subject: [tei-council] space/certainty in release 2.2.0
In-Reply-To: <50AD0B2D.1080605@kcl.ac.uk>
References: <50940001.2010101@kcl.ac.uk> <5094013D.4030702@kcl.ac.uk>
	<5094066B.50708@uvic.ca> <50940967.4010007@retired.ox.ac.uk>
	<50AD0B2D.1080605@kcl.ac.uk>
Message-ID: <50AE5A33.5060801@kcl.ac.uk>

I've added certLike back to <space> (at r11158), but won't close ticket 
http://purl.org/tei/bugs/3565137, which I just reopened and commented 
on, just in case anyone thinks any of char, glyph, incident, interpGrp, 
joinGrp, kinesic, vocal should have certLike reinstated too.

Speak now or forever etc.

G

On 2012-11-21 17:11, Gabriel Bodard wrote:
> Have we made any progress on implementing this fix, and a suggested
> timescale for a 2.2.1 release? (I assume we can increment the third
> digit because this is a bug-fix, not new functionality, and doesn't
> break backward compatibility...)
>
> G
>
> On 2012-11-02 17:56, Lou Burnard wrote:
>> See ticket  at http://purl.org/tei/FR/3565137 (the number of which is
>> mistyped in the svn log entry, sorry)
>>
>> I quote from the fairly extensive notes on that ticket:
>>
>> "char, glyph,incident, interpGrp, joinGrp, kinesic, space, vocal now
>> have just model.descLike"
>>
>> Any others on that list we think on second thoughts ought to be able to
>> contain a member of model.certLike?
>>
>>
>>
>>
>> On 02/11/12 17:44, Martin Holmes wrote:
>>> I think it might have been in here:
>>>
>>> r10940 | louburnard | 2012-10-07 15:37:24 -0700 (Sun, 07 Oct 2012) | 2 lines
>>>
>>> Separating model.descLike out from model.glossLike and changing some
>>> class memberships per FR/3565136
>>>
>>> So it's pretty recent. Since it breaks backward compatibility, we should:
>>>
>>> 1. Fix it.
>>>
>>> 2. Put some <space> elements in the test files, to make sure we catch
>>> anything similar in future.
>>>
>>> 3. Do 2.2.1 fairly soon.
>>>
>>> Cheers,
>>> Martin
>>>
>>> On 12-11-02 10:22 AM, Gabriel Bodard wrote:
>>>> Oh, I see what happened. model.certLike is no longer a member of
>>>> model.glossLike, and when this was changed, presumably someone forgot to
>>>> add model.certLike to <space>, which previously inherited it.
>>>>
>>>> Does this need a 2.2.1 release to fix (along with anything else we spot
>>>> like this?)
>>>>
>>>> G
>>>>
>>>> On 2012-11-02 17:16, Gabriel Bodard wrote:
>>>>> A weird thing has happened: for the last couple of years now <space> has
>>>>> had the same content model as <gap>: i.e. ( model.descLike |
>>>>> model.certLike )*
>>>>>
>>>>> As of the latest release, however, that seems to have reverted to
>>>>> model.descLike* only (breaking a number of my files).
>>>>>
>>>>> Does anyone know how this happened, and can we try to fix this asap please?
>>>>>
>>>>> G
>>>>>
>>>>
>>>
>>
>

-- 
Dr Gabriel BODARD
Researcher in Digital Epigraphy

Digital Humanities
King's College London
26-29 Drury Lane
London WC2B 5RL

T: +44 (0)20 7848 1388
F: +44 (0)20 7848 2980
E: gabriel.bodard at kcl.ac.uk

http://www.digitalclassicist.org/
http://www.currentepigraphy.org/


From mholmes at uvic.ca  Thu Nov 22 17:43:37 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Thu, 22 Nov 2012 14:43:37 -0800
Subject: [tei-council] Unfinished <quotation> element in example?
Message-ID: <50AEAA99.3060801@uvic.ca>

Hi all,

Jinks seems to be showing a new error it hasn't shown before, triggered 
by validation of an example in the CO chapter, in COHQ:

'warning: unfinished element "quotation": "((teix:p | teix:ab))+" 
required to finish the element'

This is the relevant bit of the example:

<quotation marks="none"/>

According to the content model, this is an error:

   <content>
     <oneOrMore xmlns="http://relaxng.org/ns/structure/1.0">
       <ref name="model.pLike"/>
     </oneOrMore>
   </content>

But the content model hasn't changed since April, and the CO chapter 
hasn't changed for three weeks. Does anyone remember seeing the error 
before? We don't seem to have discussed the issue of the content model 
of <quotation> on the Council list or on SF recently.

Should we change the content model of <quotation> to <zeroOrMore>? Or 
would it be better to supply a paragraph with some explanation in the 
example?

Cheers,
Martin


-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From sebastian.rahtz at it.ox.ac.uk  Fri Nov 23 04:56:22 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Fri, 23 Nov 2012 09:56:22 +0000
Subject: [tei-council] whither HTML of Guidelines and @lang
Message-ID: <B9BE2CB6-4CC2-4B27-A5B5-5F946E83F7FE@it.ox.ac.uk>

Just  a report

As some if you will have noticed, meeting the request for @lang in web pages destroyed the Guidelines,
since they are pure XHTML, and that whats @xml:lang. Easy enough to fix, the of course the resulting
pages only have @xml:lang which browsers don't grok.

three choices

   1. forget validating our pages against  a strict XHTML schema, let them fly like doves
   2. generate @xml:lang as per the purists and accept that its useless
   3. switch entirely to HTML5  and accept the concomitant work to get it valid and politically correct (believe me, this aint that easy)

last night I implemented 2., to stop the build failing.

A 5 minute experiment with 3. found that a) there doesn't seem to be a simple HTML5 validation, and b) support for all the p.c. details of HTML5
are lacking in my XSL

If people prefer option 1., thats obviously easy
--
Sebastian Rahtz      
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431


From sebastian.rahtz at it.ox.ac.uk  Fri Nov 23 05:01:36 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Fri, 23 Nov 2012 10:01:36 +0000
Subject: [tei-council] Unfinished <quotation> element in example?
In-Reply-To: <50AEAA99.3060801@uvic.ca>
References: <50AEAA99.3060801@uvic.ca>
Message-ID: <8D10A864-01F4-4686-B39F-70266900D38F@it.ox.ac.uk>

surely CO is just wrong?

     <quotation marks="none"/>

can't possibly mean anything, and in the context of that example
doesn't do anything anyway. I would just remove it

<egXML xmlns="http://www.tei-c.org/ns/Examples" corresp="#COHQQ-eg-23" xml:lang="fr">Adolphe se tourna vers lui :
 <said rendition="#dashBefore">Alors,
 Albert, quoi de neuf ?</said>
 <said rendition="#dashBefore">Pas grand-chose.</said>
 <said rendition="#dashBefore">Il fait beau,</said>
 dit Robert.
<!-- ...  within the header  -->
<rendition xml:id="dashBefore" scope="before">content: '? '</rendition>
<!-- ... -->
<quotation marks="none"/>
</egXML>
--
Sebastian Rahtz      
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431


From james.cummings at it.ox.ac.uk  Fri Nov 23 05:07:01 2012
From: james.cummings at it.ox.ac.uk (James Cummings)
Date: Fri, 23 Nov 2012 10:07:01 +0000
Subject: [tei-council] whither HTML of Guidelines and @lang
In-Reply-To: <B9BE2CB6-4CC2-4B27-A5B5-5F946E83F7FE@it.ox.ac.uk>
References: <B9BE2CB6-4CC2-4B27-A5B5-5F946E83F7FE@it.ox.ac.uk>
Message-ID: <c6f7f3d7-11b8-4793-beeb-9905e86ebae8@HUB05.ad.oak.ox.ac.uk>


Isn't another option to step back to XHTML 1.0 ? If memory serves one of its types allows @lang doesn't it?  (Unchecked... do correct me if wrong!)

Not saying that is what I want. If we don't have good validation procedure for guidelines in html5 then we should probably not use it. IMHO.


JamesC


--
James Cummings, Academic IT Services, University of Oxford

Sebastian Rahtz <sebastian.rahtz at it.ox.ac.uk> wrote:


Just  a report

As some if you will have noticed, meeting the request for @lang in web pages destroyed the Guidelines,
since they are pure XHTML, and that whats @xml:lang. Easy enough to fix, the of course the resulting
pages only have @xml:lang which browsers don't grok.

three choices

   1. forget validating our pages against  a strict XHTML schema, let them fly like doves
   2. generate @xml:lang as per the purists and accept that its useless
   3. switch entirely to HTML5  and accept the concomitant work to get it valid and politically correct (believe me, this aint that easy)

last night I implemented 2., to stop the build failing.

A 5 minute experiment with 3. found that a) there doesn't seem to be a simple HTML5 validation, and b) support for all the p.c. details of HTML5
are lacking in my XSL

If people prefer option 1., thats obviously easy
--
Sebastian Rahtz
Director (Research Support) of Academic IT Services
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431

--
tei-council mailing list
tei-council at lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

PLEASE NOTE: postings to this list are publicly archived

From James.Cummings at it.ox.ac.uk  Fri Nov 23 05:48:48 2012
From: James.Cummings at it.ox.ac.uk (James Cummings)
Date: Fri, 23 Nov 2012 10:48:48 +0000
Subject: [tei-council] space/certainty in release 2.2.0
In-Reply-To: <50AE5A33.5060801@kcl.ac.uk>
References: <50940001.2010101@kcl.ac.uk> <5094013D.4030702@kcl.ac.uk>
	<5094066B.50708@uvic.ca> <50940967.4010007@retired.ox.ac.uk>
	<50AD0B2D.1080605@kcl.ac.uk> <50AE5A33.5060801@kcl.ac.uk>
Message-ID: <50AF5490.3000800@it.ox.ac.uk>


I can't invent any reasonable usecase  for 
char/glyph/interGrp/joinGrp having model.certLike, but 
potentially there are arguments for incident/kinesic/vocal as 
forms of (audio) transcriptional elements.

I've no real desire for them there .... just playing devil's 
advocate.

-James

On 22/11/12 17:00, Gabriel Bodard wrote:
> I've added certLike back to <space> (at r11158), but won't close ticket
> http://purl.org/tei/bugs/3565137, which I just reopened and commented
> on, just in case anyone thinks any of char, glyph, incident, interpGrp,
> joinGrp, kinesic, vocal should have certLike reinstated too.
>
> Speak now or forever etc.
>
> G
>
> On 2012-11-21 17:11, Gabriel Bodard wrote:
>> Have we made any progress on implementing this fix, and a suggested
>> timescale for a 2.2.1 release? (I assume we can increment the third
>> digit because this is a bug-fix, not new functionality, and doesn't
>> break backward compatibility...)
>>
>> G
>>
>> On 2012-11-02 17:56, Lou Burnard wrote:
>>> See ticket  at http://purl.org/tei/FR/3565137 (the number of which is
>>> mistyped in the svn log entry, sorry)
>>>
>>> I quote from the fairly extensive notes on that ticket:
>>>
>>> "char, glyph,incident, interpGrp, joinGrp, kinesic, space, vocal now
>>> have just model.descLike"
>>>
>>> Any others on that list we think on second thoughts ought to be able to
>>> contain a member of model.certLike?
>>>
>>>
>>>
>>>
>>> On 02/11/12 17:44, Martin Holmes wrote:
>>>> I think it might have been in here:
>>>>
>>>> r10940 | louburnard | 2012-10-07 15:37:24 -0700 (Sun, 07 Oct 2012) | 2 lines
>>>>
>>>> Separating model.descLike out from model.glossLike and changing some
>>>> class memberships per FR/3565136
>>>>
>>>> So it's pretty recent. Since it breaks backward compatibility, we should:
>>>>
>>>> 1. Fix it.
>>>>
>>>> 2. Put some <space> elements in the test files, to make sure we catch
>>>> anything similar in future.
>>>>
>>>> 3. Do 2.2.1 fairly soon.
>>>>
>>>> Cheers,
>>>> Martin
>>>>
>>>> On 12-11-02 10:22 AM, Gabriel Bodard wrote:
>>>>> Oh, I see what happened. model.certLike is no longer a member of
>>>>> model.glossLike, and when this was changed, presumably someone forgot to
>>>>> add model.certLike to <space>, which previously inherited it.
>>>>>
>>>>> Does this need a 2.2.1 release to fix (along with anything else we spot
>>>>> like this?)
>>>>>
>>>>> G
>>>>>
>>>>> On 2012-11-02 17:16, Gabriel Bodard wrote:
>>>>>> A weird thing has happened: for the last couple of years now <space> has
>>>>>> had the same content model as <gap>: i.e. ( model.descLike |
>>>>>> model.certLike )*
>>>>>>
>>>>>> As of the latest release, however, that seems to have reverted to
>>>>>> model.descLike* only (breaking a number of my files).
>>>>>>
>>>>>> Does anyone know how this happened, and can we try to fix this asap please?
>>>>>>
>>>>>> G
>>>>>>
>>>>>
>>>>
>>>
>>
>


-- 
Dr James Cummings, James.Cummings at it.ox.ac.uk
Academic IT Services, University of Oxford

From sebastian.rahtz at it.ox.ac.uk  Fri Nov 23 06:00:19 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Fri, 23 Nov 2012 11:00:19 +0000
Subject: [tei-council] Unfinished <quotation> element in example?
In-Reply-To: <njuur7hm3f0khe0y2n344ufr.1353667921193@email.android.com>
References: <50AEAA99.3060801@uvic.ca>,
	<8D10A864-01F4-4686-B39F-70266900D38F@it.ox.ac.uk>
	<njuur7hm3f0khe0y2n344ufr.1353667921193@email.android.com>
Message-ID: <2c450275-edac-4169-87a6-96a019d82344@HUB06.ad.oak.ox.ac.uk>


On 23 Nov 2012, at 10:54, Lou Burnard <lou.burnard at retired.ox.ac.uk>
 wrote:

> iT means quote marks have been removed in the encoding.


oh, just cancel me. I am dumb. I saw <quotation> and read <quote>

--
Sebastian Rahtz      
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431


From sebastian.rahtz at it.ox.ac.uk  Fri Nov 23 06:01:04 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Fri, 23 Nov 2012 11:01:04 +0000
Subject: [tei-council] whither HTML of Guidelines and @lang
In-Reply-To: <vrv61avharqsuoefqcg4yi0x.1353665217960@email.android.com>
References: <B9BE2CB6-4CC2-4B27-A5B5-5F946E83F7FE@it.ox.ac.uk>
	<vrv61avharqsuoefqcg4yi0x.1353665217960@email.android.com>
Message-ID: <c73bd390-310a-4a11-8dab-a24d4e09795a@HUB01.ad.oak.ox.ac.uk>


On 23 Nov 2012, at 10:07, James Cummings <james.cummings at it.ox.ac.uk>
 wrote:

> 
> Isn't another option to step back to XHTML 1.0 ? If memory serves one of its types allows @lang doesn't it?  (Unchecked... do correct me if wrong!)

dunno, to be honest

> 
> Not saying that is what I want. If we don't have good validation procedure for guidelines in html5 then we should probably not use it.

well, _are_ there good validation procedures for HTML5?.
--
Sebastian Rahtz      
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431


From lou.burnard at retired.ox.ac.uk  Fri Nov 23 06:07:53 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Fri, 23 Nov 2012 11:07:53 +0000
Subject: [tei-council] Unfinished <quotation> element in example?
In-Reply-To: <50AEAA99.3060801@uvic.ca>
References: <50AEAA99.3060801@uvic.ca>
Message-ID: <50AF5909.1020705@retired.ox.ac.uk>

I think changing the content model to permit an empty element would be 
preferable.
Same probably applies to those other members of enodingDesc which have 
specialised attributes like this.


On 22/11/12 22:43, Martin Holmes wrote:
> Hi all,
>
> Jinks seems to be showing a new error it hasn't shown before, triggered
> by validation of an example in the CO chapter, in COHQ:
>
> 'warning: unfinished element "quotation": "((teix:p | teix:ab))+"
> required to finish the element'
>
> This is the relevant bit of the example:
>
> <quotation marks="none"/>
>
> According to the content model, this is an error:
>
>     <content>
>       <oneOrMore xmlns="http://relaxng.org/ns/structure/1.0">
>         <ref name="model.pLike"/>
>       </oneOrMore>
>     </content>
>
> But the content model hasn't changed since April, and the CO chapter
> hasn't changed for three weeks. Does anyone remember seeing the error
> before? We don't seem to have discussed the issue of the content model
> of <quotation> on the Council list or on SF recently.
>
> Should we change the content model of <quotation> to <zeroOrMore>? Or
> would it be better to supply a paragraph with some explanation in the
> example?
>
> Cheers,
> Martin
>
>


From lou.burnard at retired.ox.ac.uk  Fri Nov 23 06:11:11 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Fri, 23 Nov 2012 11:11:11 +0000
Subject: [tei-council] whither HTML of Guidelines and @lang
In-Reply-To: <c73bd390-310a-4a11-8dab-a24d4e09795a@HUB01.ad.oak.ox.ac.uk>
References: <B9BE2CB6-4CC2-4B27-A5B5-5F946E83F7FE@it.ox.ac.uk>
	<vrv61avharqsuoefqcg4yi0x.1353665217960@email.android.com>
	<c73bd390-310a-4a11-8dab-a24d4e09795a@HUB01.ad.oak.ox.ac.uk>
Message-ID: <50AF59CF.9030406@retired.ox.ac.uk>

On 23/11/12 11:01, Sebastian Rahtz wrote:
>
> Not saying that is what I want. If we don't have good validation procedure for guidelines in html5 then we should probably not use it.
> well, _are_ there good validation procedures for HTML5?.

Earlier you said "A 5 minute experiment... found that a) there doesn't 
seem to be a simple HTML5 validation, and b) support for all the p.c. 
details of HTML5 are lacking in my XSL"

can you perhaps elaborate on this ? if the stylesheets are generating 
HTML which doesn't meet generally accepted criteria  that should be a 
subject of some concern, no?



From gabriel.bodard at kcl.ac.uk  Fri Nov 23 06:15:01 2012
From: gabriel.bodard at kcl.ac.uk (Gabriel Bodard)
Date: Fri, 23 Nov 2012 11:15:01 +0000
Subject: [tei-council] whither HTML of Guidelines and @lang
In-Reply-To: <c6f7f3d7-11b8-4793-beeb-9905e86ebae8@HUB05.ad.oak.ox.ac.uk>
References: <B9BE2CB6-4CC2-4B27-A5B5-5F946E83F7FE@it.ox.ac.uk>
	<c6f7f3d7-11b8-4793-beeb-9905e86ebae8@HUB05.ad.oak.ox.ac.uk>
Message-ID: <50AF5AB5.5080904@kcl.ac.uk>

On 2012-11-23 10:07, James Cummings wrote:
> Isn't another option to step back to XHTML 1.0 ? If memory serves
> one of its types allows @lang doesn't it? (Unchecked... do correct me
> > if wrong!)

I think this is correct (that is, I'm sure I've output XHTML1.0 
Transitional with both @xml:lang and @lang in the past and never had any 
complaints from the W3 validator, but I can't back that up...).

> Not saying that is what I want. If we don't have good validation
> procedure for guidelines in html5 then we should probably not use it.
> IMHO.

Why do we need to validate the HTML output of the Guidelines? HTML5 
doesn't even need to be well-formed XML (although it can be, and I like 
it to be). As Sebastian was arguing earlier in the TEI-L thread on 
@lang, the HTML is just a delivery medium, not something we need to 
process or expect anyone else to re-use, right?

If we produce HTML5 to the best of our ability, and don't get it all 
right first time, what breaks?

-- 
Dr Gabriel BODARD
Researcher in Digital Epigraphy

Digital Humanities
King's College London
26-29 Drury Lane
London WC2B 5RL

T: +44 (0)20 7848 1388
F: +44 (0)20 7848 2980
E: gabriel.bodard at kcl.ac.uk

http://www.digitalclassicist.org/
http://www.currentepigraphy.org/


From James.Cummings at it.ox.ac.uk  Fri Nov 23 06:23:11 2012
From: James.Cummings at it.ox.ac.uk (James Cummings)
Date: Fri, 23 Nov 2012 11:23:11 +0000
Subject: [tei-council] whither HTML of Guidelines and @lang
In-Reply-To: <50AF5AB5.5080904@kcl.ac.uk>
References: <B9BE2CB6-4CC2-4B27-A5B5-5F946E83F7FE@it.ox.ac.uk>
	<c6f7f3d7-11b8-4793-beeb-9905e86ebae8@HUB05.ad.oak.ox.ac.uk>
	<50AF5AB5.5080904@kcl.ac.uk>
Message-ID: <50AF5C9F.5090100@it.ox.ac.uk>

On 23/11/12 11:15, Gabriel Bodard wrote:
> Why do we need to validate the HTML output of the Guidelines? HTML5
> doesn't even need to be well-formed XML (although it can be, and I like
> it to be). As Sebastian was arguing earlier in the TEI-L thread on
> @lang, the HTML is just a delivery medium, not something we need to
> process or expect anyone else to re-use, right?
>
> If we produce HTML5 to the best of our ability, and don't get it all
> right first time, what breaks?

It just seems to me to be a good policy for a markup-related 
standard's website to make error-free use of other markup 
standards in its website.  If we were selling bicycles I wouldn't 
care. ;-)

I suggest we stick with what we have (but with Sebastian's fix 
using @xml:lang) and reinvestigate in the new year?  (I.e. I 
think we have other things that are a higher priority.) What do 
others think?

-James

-- 
Dr James Cummings, James.Cummings at it.ox.ac.uk
Academic IT Services, University of Oxford

From sebastian.rahtz at it.ox.ac.uk  Fri Nov 23 07:18:27 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Fri, 23 Nov 2012 12:18:27 +0000
Subject: [tei-council] whither HTML of Guidelines and @lang
In-Reply-To: <50AF59CF.9030406@retired.ox.ac.uk>
References: <B9BE2CB6-4CC2-4B27-A5B5-5F946E83F7FE@it.ox.ac.uk>
	<vrv61avharqsuoefqcg4yi0x.1353665217960@email.android.com>
	<c73bd390-310a-4a11-8dab-a24d4e09795a@HUB01.ad.oak.ox.ac.uk>
	<50AF59CF.9030406@retired.ox.ac.uk>
Message-ID: <24d61df0-ba7f-4bc2-8721-c02201aad3cd@HUB02.ad.oak.ox.ac.uk>


On 23 Nov 2012, at 11:11, Lou Burnard <lou.burnard at retired.ox.ac.uk>
 wrote:

> On 23/11/12 11:01, Sebastian Rahtz wrote:
>> 
>> Not saying that is what I want. If we don't have good validation procedure for guidelines in html5 then we should probably not use it.
>> well, _are_ there good validation procedures for HTML5?.
> 
> Earlier you said "A 5 minute experiment... found that a) there doesn't 
> seem to be a simple HTML5 validation, and b) support for all the p.c. 
> details of HTML5 are lacking in my XSL"
> 
> can you perhaps elaborate on this ? if the stylesheets are generating 
> HTML which doesn't meet generally accepted criteria  that should be a 
> subject of some concern, no?


Generating HTML5, not plain ole HTML. things like <meta> tags working
differently in HTML5.

Now I know, I will obviously work on it slowly, but thats a different priority
from the urgency of having the P5 Guidelines work properly now.
--
Sebastian Rahtz      
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431


From sebastian.rahtz at it.ox.ac.uk  Fri Nov 23 07:21:38 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Fri, 23 Nov 2012 12:21:38 +0000
Subject: [tei-council] whither HTML of Guidelines and @lang
In-Reply-To: <50AF5AB5.5080904@kcl.ac.uk>
References: <B9BE2CB6-4CC2-4B27-A5B5-5F946E83F7FE@it.ox.ac.uk>
	<c6f7f3d7-11b8-4793-beeb-9905e86ebae8@HUB05.ad.oak.ox.ac.uk>
	<50AF5AB5.5080904@kcl.ac.uk>
Message-ID: <252809B2-7658-4133-B8A1-FB03BE15DE4F@it.ox.ac.uk>


On 23 Nov 2012, at 11:15, Gabriel Bodard <gabriel.bodard at kcl.ac.uk>
 wrote:

> 
> I think this is correct (that is, I'm sure I've output XHTML1.0 
> Transitional with both @xml:lang and @lang in the past and never had any 
> complaints from the W3 validator, but I can't back that up?)

is there an XHTML 1.0 Relaxng schema we can drop in to validate the pages?
but see below re epub
> 

> Why do we need to validate the HTML output of the Guidelines?

well, yes. I like to do it, cos I want the same code to generate epub,
and epub validators insist on valid XHTML. if we get that right, everyone
else will be happy too, was my view


> If we produce HTML5 to the best of our ability, and don't get it all 
> right first time, what breaks?


nothing, i think. needs some CSS tweaks for reasons I don't understand
(my 5 minutes ended there). but it fails the XHTML validation, obviously
--
Sebastian Rahtz      
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431


From sebastian.rahtz at it.ox.ac.uk  Fri Nov 23 07:23:06 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Fri, 23 Nov 2012 12:23:06 +0000
Subject: [tei-council] whither HTML of Guidelines and @lang
In-Reply-To: <50AF5C9F.5090100@it.ox.ac.uk>
References: <B9BE2CB6-4CC2-4B27-A5B5-5F946E83F7FE@it.ox.ac.uk>
	<c6f7f3d7-11b8-4793-beeb-9905e86ebae8@HUB05.ad.oak.ox.ac.uk>
	<50AF5AB5.5080904@kcl.ac.uk> <50AF5C9F.5090100@it.ox.ac.uk>
Message-ID: <ab1f7fc9-9e00-4075-bfd2-c246105be850@HUB04.ad.oak.ox.ac.uk>


On 23 Nov 2012, at 11:23, James Cummings <James.Cummings at it.ox.ac.uk>
 wrote:

> It just seems to me to be a good policy for a markup-related 
> standard's website to make error-free use of other markup 
> standards in its website.

i put it to you that "the web" community has no meaningful  standards in this area:-}

--
Sebastian Rahtz      
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431


From James.Cummings at it.ox.ac.uk  Fri Nov 23 08:11:26 2012
From: James.Cummings at it.ox.ac.uk (James Cummings)
Date: Fri, 23 Nov 2012 13:11:26 +0000
Subject: [tei-council] whither HTML of Guidelines and @lang
In-Reply-To: <A7496291-F106-4507-AA29-100BB73506EB@it.ox.ac.uk>
References: <B9BE2CB6-4CC2-4B27-A5B5-5F946E83F7FE@it.ox.ac.uk>
	<c6f7f3d7-11b8-4793-beeb-9905e86ebae8@HUB05.ad.oak.ox.ac.uk>
	<50AF5AB5.5080904@kcl.ac.uk> <50AF5C9F.5090100@it.ox.ac.uk>
	<A7496291-F106-4507-AA29-100BB73506EB@it.ox.ac.uk>
Message-ID: <50AF75FE.3050108@it.ox.ac.uk>

On 23/11/12 12:23, Sebastian Rahtz wrote:
> i put it to you that "the web" community has no meaningful  standards in this area:-}

I couldn't possibly comment.

"To ease migration to and from XHTML, authors may specify an 
attribute in no namespace with no prefix and with the literal 
localname "xml:lang" on HTML elements in HTML documents, but such 
attributes must only be specified if a lang attribute in no 
namespace is also specified, and both attributes must have the 
same value when compared in an ASCII case-insensitive manner."

I.e. they are abuse xml:lang to say the xml: part is *NOT* a 
namespace!?!  I mean I know they borked the doctype and made 
other silly decisions but I didn't think they were actually 
saying xml: wasn't really a namespace in HTML5.

silly, silly, silly.

-James

-- 
Dr James Cummings, James.Cummings at it.ox.ac.uk
Academic IT Services, University of Oxford

From mholmes at uvic.ca  Fri Nov 23 08:31:51 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Fri, 23 Nov 2012 05:31:51 -0800
Subject: [tei-council] whither HTML of Guidelines and @lang
In-Reply-To: <50AF5AB5.5080904@kcl.ac.uk>
References: <B9BE2CB6-4CC2-4B27-A5B5-5F946E83F7FE@it.ox.ac.uk>
	<c6f7f3d7-11b8-4793-beeb-9905e86ebae8@HUB05.ad.oak.ox.ac.uk>
	<50AF5AB5.5080904@kcl.ac.uk>
Message-ID: <50AF7AC7.8030604@uvic.ca>

Hi there,

On 12-11-23 03:15 AM, Gabriel Bodard wrote:

> Why do we need to validate the HTML output of the Guidelines? HTML5
> doesn't even need to be well-formed XML (although it can be, and I like
> it to be). As Sebastian was arguing earlier in the TEI-L thread on
> @lang, the HTML is just a delivery medium, not something we need to
> process or expect anyone else to re-use, right?

I think this is a very dangerous point of view. If your XHTML doesn't 
validate, then browsers go into quirks mode, where they behave 
differently from each other. Anyone who remembers dealing with the 
miseries of different behaviour from different browsers should never 
want to go anywhere near it again. Validate, I say. Always.

We've got by without @(xml:)lang for years, so implementing it for the 
Guidelines specifically is not a high priority. I think it should be a 
long-term goal to move towards XHTML5 (for which the W3C seems to have a 
good functioning validator, so it's possible), but we should move slowly 
and carefully.

> If we produce HTML5 to the best of our ability, and don't get it all
> right first time, what breaks?

Personally, I use the Jenkins builds of the Glines in preference to the 
official release, so if they're broken for extended periods of time it's 
annoying. It's also hard to implement changes to the Glines in response 
to tickets when you can't see good working builds.

Cheers,
Martin

-- 
Martin Holmes
mholmes at uvic.ca
UVic Humanities Computing and Media Centre

From mholmes at uvic.ca  Fri Nov 23 08:48:24 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Fri, 23 Nov 2012 05:48:24 -0800
Subject: [tei-council] whither HTML of Guidelines and @lang
In-Reply-To: <50AF75FE.3050108@it.ox.ac.uk>
References: <B9BE2CB6-4CC2-4B27-A5B5-5F946E83F7FE@it.ox.ac.uk>
	<c6f7f3d7-11b8-4793-beeb-9905e86ebae8@HUB05.ad.oak.ox.ac.uk>
	<50AF5AB5.5080904@kcl.ac.uk> <50AF5C9F.5090100@it.ox.ac.uk>
	<A7496291-F106-4507-AA29-100BB73506EB@it.ox.ac.uk>
	<50AF75FE.3050108@it.ox.ac.uk>
Message-ID: <50AF7EA8.7010306@uvic.ca>

On 12-11-23 05:11 AM, James Cummings wrote:
> On 23/11/12 12:23, Sebastian Rahtz wrote:
>> i put it to you that "the web" community has no meaningful  standards in this area:-}
>
> I couldn't possibly comment.
>
> "To ease migration to and from XHTML, authors may specify an
> attribute in no namespace with no prefix and with the literal
> localname "xml:lang" on HTML elements in HTML documents, but such
> attributes must only be specified if a lang attribute in no
> namespace is also specified, and both attributes must have the
> same value when compared in an ASCII case-insensitive manner."
>
> I.e. they are abuse xml:lang to say the xml: part is *NOT* a
> namespace!?!  I mean I know they borked the doctype and made
> other silly decisions but I didn't think they were actually
> saying xml: wasn't really a namespace in HTML5.
>
> silly, silly, silly.

Agreed. But I think the situation with HTML5 was taken out of the hands 
of W3 by WhatWG, who were more interested in pushing forward with HTML5 
(basically ignoring XHTML) than maintaining consistency and doing the 
right thing; the W3C would have moved more slowly and cautiously if 
they'd been able to.

There will eventually be a strict, validatable XHTML5 we can target, and 
it will be more TEI-friendly because of things like <article>, <figure>, 
<heading>, <section> and <wbr>.

Cheers,
Martin

-- 
Martin Holmes
mholmes at uvic.ca
UVic Humanities Computing and Media Centre

From gabriel.bodard at kcl.ac.uk  Fri Nov 23 09:49:37 2012
From: gabriel.bodard at kcl.ac.uk (Gabriel Bodard)
Date: Fri, 23 Nov 2012 14:49:37 +0000
Subject: [tei-council] whither HTML of Guidelines and @lang
In-Reply-To: <50AF7AC7.8030604@uvic.ca>
References: <B9BE2CB6-4CC2-4B27-A5B5-5F946E83F7FE@it.ox.ac.uk>
	<c6f7f3d7-11b8-4793-beeb-9905e86ebae8@HUB05.ad.oak.ox.ac.uk>
	<50AF5AB5.5080904@kcl.ac.uk> <50AF7AC7.8030604@uvic.ca>
Message-ID: <50AF8D01.1010301@kcl.ac.uk>

On 2012-11-23 13:31, Martin Holmes wrote:
>> Why do we need to validate the HTML output of the Guidelines? HTML5
>> doesn't even need to be well-formed XML (although it can be, and I like
>> it to be). As Sebastian was arguing earlier in the TEI-L thread on
>> @lang, the HTML is just a delivery medium, not something we need to
>> process or expect anyone else to re-use, right?
>
> I think this is a very dangerous point of view. If your XHTML doesn't
> validate, then browsers go into quirks mode, where they behave
> differently from each other. Anyone who remembers dealing with the
> miseries of different behaviour from different browsers should never
> want to go anywhere near it again. Validate, I say. Always.

I don't disagree with any of this. I should stress that I was asking, 
"Do *we* really need [for technical reasons] validation as part of our 
output process?" rather than suggesting that we should not produce valid 
HTML.

My understanding was the XHTML is kind of a dead-end anyway, as far as 
HTML5 is concerned. HTML5 doesn't have to be XML at all, does it? If we 
decided to use HTML5 (and I also agree that there's no rush to do so; 
only the so far speculative request that we output @lang in HTML having 
brought this up at all) then our HTML output doesn't have to be XHTML or 
run through a validator--although it should be as good and standard as 
possible, of course.

But we also need to produce XHTML output for the Epub conversion, right? 
Does that mean we don't want to use HTML5 at all? (At least until 
there's more normalization between the two?)

-- 
Dr Gabriel BODARD
Researcher in Digital Epigraphy

Digital Humanities
King's College London
26-29 Drury Lane
London WC2B 5RL

T: +44 (0)20 7848 1388
F: +44 (0)20 7848 2980
E: gabriel.bodard at kcl.ac.uk

http://www.digitalclassicist.org/
http://www.currentepigraphy.org/


From kevin.s.hawkins at ultraslavonic.info  Fri Nov 23 10:07:42 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Fri, 23 Nov 2012 10:07:42 -0500
Subject: [tei-council] Unfinished <quotation> element in example?
In-Reply-To: <50AF5909.1020705@retired.ox.ac.uk>
References: <50AEAA99.3060801@uvic.ca> <50AF5909.1020705@retired.ox.ac.uk>
Message-ID: <50AF913E.9030505@ultraslavonic.info>

I support allowing members of model.encodingDescPart with have 
specialized attributes to be empty elements -- that is, changing 
model.pLike+ to model.pLike*.  We might get questions from people about 
why certain members of model.encodingDescPart require at least one <p> 
inside while others don't, but I think our rationale for doing so is 
pretty sound.

Should this be a ticket for discussion with a wider community, or should 
we just do this?

On 11/23/12 6:07 AM, Lou Burnard wrote:
> I think changing the content model to permit an empty element would be
> preferable.
> Same probably applies to those other members of enodingDesc which have
> specialised attributes like this.
>
>
> On 22/11/12 22:43, Martin Holmes wrote:
>> Hi all,
>>
>> Jinks seems to be showing a new error it hasn't shown before, triggered
>> by validation of an example in the CO chapter, in COHQ:
>>
>> 'warning: unfinished element "quotation": "((teix:p | teix:ab))+"
>> required to finish the element'
>>
>> This is the relevant bit of the example:
>>
>> <quotation marks="none"/>
>>
>> According to the content model, this is an error:
>>
>>      <content>
>>        <oneOrMore xmlns="http://relaxng.org/ns/structure/1.0">
>>          <ref name="model.pLike"/>
>>        </oneOrMore>
>>      </content>
>>
>> But the content model hasn't changed since April, and the CO chapter
>> hasn't changed for three weeks. Does anyone remember seeing the error
>> before? We don't seem to have discussed the issue of the content model
>> of <quotation> on the Council list or on SF recently.
>>
>> Should we change the content model of <quotation> to <zeroOrMore>? Or
>> would it be better to supply a paragraph with some explanation in the
>> example?
>>
>> Cheers,
>> Martin
>>
>>
>

From sebastian.rahtz at it.ox.ac.uk  Fri Nov 23 10:15:05 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Fri, 23 Nov 2012 15:15:05 +0000
Subject: [tei-council] whither HTML of Guidelines and @lang
In-Reply-To: <50AF8D01.1010301@kcl.ac.uk>
References: <B9BE2CB6-4CC2-4B27-A5B5-5F946E83F7FE@it.ox.ac.uk>
	<c6f7f3d7-11b8-4793-beeb-9905e86ebae8@HUB05.ad.oak.ox.ac.uk>
	<50AF5AB5.5080904@kcl.ac.uk> <50AF7AC7.8030604@uvic.ca>
	<50AF8D01.1010301@kcl.ac.uk>
Message-ID: <D44C0FE6-FDF6-4825-AE74-14A615CFCD8A@it.ox.ac.uk>


On 23 Nov 2012, at 14:49, Gabriel Bodard <gabriel.bodard at kcl.ac.uk> wrote:
> I don't disagree with any of this. I should stress that I was asking, 
> "Do *we* really need [for technical reasons] validation as part of our 
> output process?" 

for my part, the answer is yes, as the same process is used to make epub,
and that has strict validation.

> 
> But we also need to produce XHTML output for the Epub conversion, right? 
> Does that mean we don't want to use HTML5 at all? (At least until 
> there's more normalization between the two?)


epub3 uses html5, and validates it (fussily). So again, I need to be
sure that my XSL produces HTML which can survive the epub tests.


--
Sebastian Rahtz      
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431


From James.Cummings at it.ox.ac.uk  Fri Nov 23 10:18:52 2012
From: James.Cummings at it.ox.ac.uk (James Cummings)
Date: Fri, 23 Nov 2012 15:18:52 +0000
Subject: [tei-council] Unfinished <quotation> element in example?
In-Reply-To: <50AF913E.9030505@ultraslavonic.info>
References: <50AEAA99.3060801@uvic.ca> <50AF5909.1020705@retired.ox.ac.uk>
	<50AF913E.9030505@ultraslavonic.info>
Message-ID: <50AF93DC.3040104@it.ox.ac.uk>

On 23/11/12 15:07, Kevin Hawkins wrote:
> I support allowing members of model.encodingDescPart with have
> specialized attributes to be empty elements -- that is, changing
> model.pLike+ to model.pLike*.  We might get questions from people about
> why certain members of model.encodingDescPart require at least one <p>
> inside while others don't, but I think our rationale for doing so is
> pretty sound.


I'd support this as well.  Though I think it is _good practice_ 
to provide a paragraph of explanation as well, I don't think it 
is should always be required.

> Should this be a ticket for discussion with a wider community, or should
> we just do this?

I like to have tickets where possible so we can more easily track 
something being done (when I help compile release notes ;-) ).

-James

>
> On 11/23/12 6:07 AM, Lou Burnard wrote:
>> I think changing the content model to permit an empty element would be
>> preferable.
>> Same probably applies to those other members of enodingDesc which have
>> specialised attributes like this.
>>
>>
>> On 22/11/12 22:43, Martin Holmes wrote:
>>> Hi all,
>>>
>>> Jinks seems to be showing a new error it hasn't shown before, triggered
>>> by validation of an example in the CO chapter, in COHQ:
>>>
>>> 'warning: unfinished element "quotation": "((teix:p | teix:ab))+"
>>> required to finish the element'
>>>
>>> This is the relevant bit of the example:
>>>
>>> <quotation marks="none"/>
>>>
>>> According to the content model, this is an error:
>>>
>>>       <content>
>>>         <oneOrMore xmlns="http://relaxng.org/ns/structure/1.0">
>>>           <ref name="model.pLike"/>
>>>         </oneOrMore>
>>>       </content>
>>>
>>> But the content model hasn't changed since April, and the CO chapter
>>> hasn't changed for three weeks. Does anyone remember seeing the error
>>> before? We don't seem to have discussed the issue of the content model
>>> of <quotation> on the Council list or on SF recently.
>>>
>>> Should we change the content model of <quotation> to <zeroOrMore>? Or
>>> would it be better to supply a paragraph with some explanation in the
>>> example?
>>>
>>> Cheers,
>>> Martin
>>>
>>>
>>


-- 
Dr James Cummings, James.Cummings at it.ox.ac.uk
Academic IT Services, University of Oxford

From philomousos at gmail.com  Fri Nov 23 10:19:01 2012
From: philomousos at gmail.com (Hugh Cayless)
Date: Fri, 23 Nov 2012 10:19:01 -0500
Subject: [tei-council] whither HTML of Guidelines and @lang
In-Reply-To: <50AF7AC7.8030604@uvic.ca>
References: <B9BE2CB6-4CC2-4B27-A5B5-5F946E83F7FE@it.ox.ac.uk>
	<c6f7f3d7-11b8-4793-beeb-9905e86ebae8@HUB05.ad.oak.ox.ac.uk>
	<50AF5AB5.5080904@kcl.ac.uk> <50AF7AC7.8030604@uvic.ca>
Message-ID: <CAObhq+fC=R9SjLz9L7z2gYqT1-0uPkzHgfMs7E9+dpcgRMnavA@mail.gmail.com>

I was under the impression that quirks mode was triggered by the doctype
(or lack thereof). Use of the HTML5 doctype puts browsers into standards
mode afaik. For what it's worth, I ditched XHTML for my own work years ago,
and would advise against using it without some compelling reason.

Best,
Hugh
On Nov 23, 2012 8:31 AM, "Martin Holmes" <mholmes at uvic.ca> wrote:

> Hi there,
>
> On 12-11-23 03:15 AM, Gabriel Bodard wrote:
>
> > Why do we need to validate the HTML output of the Guidelines? HTML5
> > doesn't even need to be well-formed XML (although it can be, and I like
> > it to be). As Sebastian was arguing earlier in the TEI-L thread on
> > @lang, the HTML is just a delivery medium, not something we need to
> > process or expect anyone else to re-use, right?
>
> I think this is a very dangerous point of view. If your XHTML doesn't
> validate, then browsers go into quirks mode, where they behave
> differently from each other. Anyone who remembers dealing with the
> miseries of different behaviour from different browsers should never
> want to go anywhere near it again. Validate, I say. Always.
>
> We've got by without @(xml:)lang for years, so implementing it for the
> Guidelines specifically is not a high priority. I think it should be a
> long-term goal to move towards XHTML5 (for which the W3C seems to have a
> good functioning validator, so it's possible), but we should move slowly
> and carefully.
>
> > If we produce HTML5 to the best of our ability, and don't get it all
> > right first time, what breaks?
>
> Personally, I use the Jenkins builds of the Glines in preference to the
> official release, so if they're broken for extended periods of time it's
> annoying. It's also hard to implement changes to the Glines in response
> to tickets when you can't see good working builds.
>
> Cheers,
> Martin
>
> --
> Martin Holmes
> mholmes at uvic.ca
> UVic Humanities Computing and Media Centre
> --
> tei-council mailing list
> tei-council at lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>
> PLEASE NOTE: postings to this list are publicly archived
>

From mholmes at uvic.ca  Fri Nov 23 11:36:34 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Fri, 23 Nov 2012 08:36:34 -0800
Subject: [tei-council] whither HTML of Guidelines and @lang
In-Reply-To: <50AF8D01.1010301@kcl.ac.uk>
References: <B9BE2CB6-4CC2-4B27-A5B5-5F946E83F7FE@it.ox.ac.uk>
	<c6f7f3d7-11b8-4793-beeb-9905e86ebae8@HUB05.ad.oak.ox.ac.uk>
	<50AF5AB5.5080904@kcl.ac.uk> <50AF7AC7.8030604@uvic.ca>
	<50AF8D01.1010301@kcl.ac.uk>
Message-ID: <50AFA612.50105@uvic.ca>

Hi there,

On 12-11-23 06:49 AM, Gabriel Bodard wrote:

> My understanding was the XHTML is kind of a dead-end anyway, as far as
> HTML5 is concerned. HTML5 doesn't have to be XML at all, does it? If we
> decided to use HTML5 (and I also agree that there's no rush to do so;
> only the so far speculative request that we output @lang in HTML having
> brought this up at all) then our HTML output doesn't have to be XHTML or
> run through a validator--although it should be as good and standard as
> possible, of course.
>
> But we also need to produce XHTML output for the Epub conversion, right?
> Does that mean we don't want to use HTML5 at all? (At least until
> there's more normalization between the two?)

I think we should aim for the kind of polyglot document described here:

<http://blog.whatwg.org/xhtml5-in-a-nutshell>

In other words, valid HTML5 which is also XHTML5, and will function 
correctly whether served as html or xml. I also think it's quite a 
realistic possibility that we might make virtually the entire document 
XHTML 1.1 compliant as well; I've had a number of documents which were 
XHTML 1.1, but which validated as XHTML5 with one or two tiny changes 
(such as the doctype <!DOCTYPE html>).

Of course, that means that we fail to take advantage of the cool new 
HTML5 features such as Custom Data Attributes, which give us the 
enticing promise of round-tripping between TEI and (X)HTML5.

Cheers,
Martin

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From mholmes at uvic.ca  Fri Nov 23 11:44:38 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Fri, 23 Nov 2012 08:44:38 -0800
Subject: [tei-council] whither HTML of Guidelines and @lang
In-Reply-To: <CAObhq+fC=R9SjLz9L7z2gYqT1-0uPkzHgfMs7E9+dpcgRMnavA@mail.gmail.com>
References: <B9BE2CB6-4CC2-4B27-A5B5-5F946E83F7FE@it.ox.ac.uk>
	<c6f7f3d7-11b8-4793-beeb-9905e86ebae8@HUB05.ad.oak.ox.ac.uk>
	<50AF5AB5.5080904@kcl.ac.uk>	<50AF7AC7.8030604@uvic.ca>
	<CAObhq+fC=R9SjLz9L7z2gYqT1-0uPkzHgfMs7E9+dpcgRMnavA@mail.gmail.com>
Message-ID: <50AFA7F6.7020406@uvic.ca>

On 12-11-23 07:19 AM, Hugh Cayless wrote:
> I was under the impression that quirks mode was triggered by the doctype
> (or lack thereof). Use of the HTML5 doctype puts browsers into standards
> mode afaik. For what it's worth, I ditched XHTML for my own work years
> ago, and would advise against using it without some compelling reason.

The compelling reason for me is the ability to fix or change things 
across a whole website using XSLT.

You're right about the triggering of quirks mode for modern browsers, 
but I suppose what I meant was: when you create HTML which doesn't 
adhere to the standard, there's no guidance for the browser on how to 
render it, and therefore it has to make a decision about how best to 
proceed. Browser makers take different decisions in these situations, 
and additionally, the nature of the the browser's parsing algorithms can 
cause the same set of decisions to be triggered in different orders, so 
that even if they're thinking along the same lines, the results may be 
different. If your HTML is valid, at least you know what browsers are 
_supposed_ to do with it, and you can file a bug report if you find one 
that doesn't do the right thing.

Cheers,
Martin

>
> Best,
> Hugh
>
> On Nov 23, 2012 8:31 AM, "Martin Holmes" <mholmes at uvic.ca
> <mailto:mholmes at uvic.ca>> wrote:
>
>     Hi there,
>
>     On 12-11-23 03:15 AM, Gabriel Bodard wrote:
>
>      > Why do we need to validate the HTML output of the Guidelines? HTML5
>      > doesn't even need to be well-formed XML (although it can be, and
>     I like
>      > it to be). As Sebastian was arguing earlier in the TEI-L thread on
>      > @lang, the HTML is just a delivery medium, not something we need to
>      > process or expect anyone else to re-use, right?
>
>     I think this is a very dangerous point of view. If your XHTML doesn't
>     validate, then browsers go into quirks mode, where they behave
>     differently from each other. Anyone who remembers dealing with the
>     miseries of different behaviour from different browsers should never
>     want to go anywhere near it again. Validate, I say. Always.
>
>     We've got by without @(xml:)lang for years, so implementing it for the
>     Guidelines specifically is not a high priority. I think it should be a
>     long-term goal to move towards XHTML5 (for which the W3C seems to have a
>     good functioning validator, so it's possible), but we should move slowly
>     and carefully.
>
>      > If we produce HTML5 to the best of our ability, and don't get it all
>      > right first time, what breaks?
>
>     Personally, I use the Jenkins builds of the Glines in preference to the
>     official release, so if they're broken for extended periods of time it's
>     annoying. It's also hard to implement changes to the Glines in response
>     to tickets when you can't see good working builds.
>
>     Cheers,
>     Martin
>
>     --
>     Martin Holmes
>     mholmes at uvic.ca <mailto:mholmes at uvic.ca>
>     UVic Humanities Computing and Media Centre
>     --
>     tei-council mailing list
>     tei-council at lists.village.Virginia.EDU
>     <mailto:tei-council at lists.village.Virginia.EDU>
>     http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>
>     PLEASE NOTE: postings to this list are publicly archived
>

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From sebastian.rahtz at it.ox.ac.uk  Fri Nov 23 12:09:29 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Fri, 23 Nov 2012 17:09:29 +0000
Subject: [tei-council] whither HTML of Guidelines and @lang
In-Reply-To: <50AFA612.50105@uvic.ca>
References: <B9BE2CB6-4CC2-4B27-A5B5-5F946E83F7FE@it.ox.ac.uk>
	<c6f7f3d7-11b8-4793-beeb-9905e86ebae8@HUB05.ad.oak.ox.ac.uk>
	<50AF5AB5.5080904@kcl.ac.uk> <50AF7AC7.8030604@uvic.ca>
	<50AF8D01.1010301@kcl.ac.uk> <50AFA612.50105@uvic.ca>
Message-ID: <22271B06-5337-49A6-B246-830F89378FFE@it.ox.ac.uk>


On 23 Nov 2012, at 16:36, Martin Holmes <mholmes at uvic.ca> wrote:

> 
> In other words, valid HTML5 which is also XHTML5, and will function 
> correctly whether served as html or xml.

thats more or less where we are i think

> I also think it's quite a 
> realistic possibility that we might make virtually the entire document 
> XHTML 1.1 compliant as well; I've had a number of documents which were 
> XHTML 1.1, but which validated as XHTML5 with one or two tiny changes 
> (such as the doctype <!DOCTYPE html>).

so you don't use @lang :-}


--
Sebastian Rahtz      
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431


From sebastian.rahtz at it.ox.ac.uk  Fri Nov 23 12:15:55 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Fri, 23 Nov 2012 17:15:55 +0000
Subject: [tei-council] whither HTML of Guidelines and @lang
In-Reply-To: <50AFA7F6.7020406@uvic.ca>
References: <B9BE2CB6-4CC2-4B27-A5B5-5F946E83F7FE@it.ox.ac.uk>
	<c6f7f3d7-11b8-4793-beeb-9905e86ebae8@HUB05.ad.oak.ox.ac.uk>
	<50AF5AB5.5080904@kcl.ac.uk>	<50AF7AC7.8030604@uvic.ca>
	<CAObhq+fC=R9SjLz9L7z2gYqT1-0uPkzHgfMs7E9+dpcgRMnavA@mail.gmail.com>
	<50AFA7F6.7020406@uvic.ca>
Message-ID: <4E1A54BC-61FF-4F78-9174-D5649E90A321@it.ox.ac.uk>

when I switch to HTML5 for the Gidlines, I get errors like

	Error: Bad value ?70%? for attribute ?width? on element ?img?: Expected a digit but saw ?%? instead.
	From line 1273, column 118; to line 1273, column 261

which puzzles me. why can't I have a width of 70% for images?

--
Sebastian Rahtz      
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431


From mholmes at uvic.ca  Fri Nov 23 12:22:08 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Fri, 23 Nov 2012 09:22:08 -0800
Subject: [tei-council] Glines index page
Message-ID: <50AFB0C0.5040007@uvic.ca>

Here's something that's always puzzled me. This page:

<http://teijenkins.hcmc.uvic.ca/job/TEIP5/lastSuccessfulBuild/artifact/release/doc/tei-p5-doc/en/html/index.html>

is a sort of half-a-table-of-contents, and I don't really see the point 
of it. Much of what's there is also on the real table of contents:

<http://teijenkins.hcmc.uvic.ca/job/TEIP5/lastSuccessfulBuild/artifact/release/doc/tei-p5-doc/en/html/index-toc.html>

but not all of it, so half the time it gets in the way. I noticed a 
couple of people at the workshop last week a bit confused by it too.

Does anyone else think it would be a good idea to merge index and 
index_toc into a single front page?

Cheers,
Martin
-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From mholmes at uvic.ca  Fri Nov 23 12:23:00 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Fri, 23 Nov 2012 09:23:00 -0800
Subject: [tei-council] whither HTML of Guidelines and @lang
In-Reply-To: <4E1A54BC-61FF-4F78-9174-D5649E90A321@it.ox.ac.uk>
References: <B9BE2CB6-4CC2-4B27-A5B5-5F946E83F7FE@it.ox.ac.uk>
	<c6f7f3d7-11b8-4793-beeb-9905e86ebae8@HUB05.ad.oak.ox.ac.uk>
	<50AF5AB5.5080904@kcl.ac.uk>	<50AF7AC7.8030604@uvic.ca>
	<CAObhq+fC=R9SjLz9L7z2gYqT1-0uPkzHgfMs7E9+dpcgRMnavA@mail.gmail.com>
	<50AFA7F6.7020406@uvic.ca>
	<4E1A54BC-61FF-4F78-9174-D5649E90A321@it.ox.ac.uk>
Message-ID: <50AFB0F4.3070405@uvic.ca>

<img style="width: 70%"/>, surely? Not <img width="70%"/>.

Cheers,
Martin

On 12-11-23 09:15 AM, Sebastian Rahtz wrote:
> when I switch to HTML5 for the Gidlines, I get errors like
>
> 	Error: Bad value ?70%? for attribute ?width? on element ?img?: Expected a digit but saw ?%? instead.
> 	From line 1273, column 118; to line 1273, column 261
>
> which puzzles me. why can't I have a width of 70% for images?
>
> --
> Sebastian Rahtz
> Director (Research Support) of Academic IT Services
> University of Oxford IT Services
> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>
>

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From lou.burnard at retired.ox.ac.uk  Fri Nov 23 15:06:56 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Fri, 23 Nov 2012 20:06:56 +0000
Subject: [tei-council] Glines index page
In-Reply-To: <50AFB0C0.5040007@uvic.ca>
References: <50AFB0C0.5040007@uvic.ca>
Message-ID: <50AFD760.6020304@retired.ox.ac.uk>

It's the way it is because someone (can't remember who now) wanted a 
simpler front page, when they saw the full index_toc


On 23/11/12 17:22, Martin Holmes wrote:
> Here's something that's always puzzled me. This page:
>
> <http://teijenkins.hcmc.uvic.ca/job/TEIP5/lastSuccessfulBuild/artifact/release/doc/tei-p5-doc/en/html/index.html>
>
> is a sort of half-a-table-of-contents, and I don't really see the point
> of it. Much of what's there is also on the real table of contents:
>
> <http://teijenkins.hcmc.uvic.ca/job/TEIP5/lastSuccessfulBuild/artifact/release/doc/tei-p5-doc/en/html/index-toc.html>
>
> but not all of it, so half the time it gets in the way. I noticed a
> couple of people at the workshop last week a bit confused by it too.
>
> Does anyone else think it would be a good idea to merge index and
> index_toc into a single front page?
>
> Cheers,
> Martin


From mholmes at uvic.ca  Fri Nov 23 16:01:13 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Fri, 23 Nov 2012 13:01:13 -0800
Subject: [tei-council] Glines index page
In-Reply-To: <50AFD760.6020304@retired.ox.ac.uk>
References: <50AFB0C0.5040007@uvic.ca> <50AFD760.6020304@retired.ox.ac.uk>
Message-ID: <50AFE419.6090002@uvic.ca>

On 12-11-23 12:06 PM, Lou Burnard wrote:
> It's the way it is because someone (can't remember who now) wanted a
> simpler front page, when they saw the full index_toc

I can't find any discussion of this in the archives, although my search 
may have missed it. But with its rather odd "Some Popular Sections" bit, 
the index.html is hardly smaller than the index_toc.html. I vote for a 
single front/TOC page at index.html, with a 301 at the old _toc location.

Cheers,
Martin

>
>
> On 23/11/12 17:22, Martin Holmes wrote:
>> Here's something that's always puzzled me. This page:
>>
>> <http://teijenkins.hcmc.uvic.ca/job/TEIP5/lastSuccessfulBuild/artifact/release/doc/tei-p5-doc/en/html/index.html>
>>
>> is a sort of half-a-table-of-contents, and I don't really see the point
>> of it. Much of what's there is also on the real table of contents:
>>
>> <http://teijenkins.hcmc.uvic.ca/job/TEIP5/lastSuccessfulBuild/artifact/release/doc/tei-p5-doc/en/html/index-toc.html>
>>
>> but not all of it, so half the time it gets in the way. I noticed a
>> couple of people at the workshop last week a bit confused by it too.
>>
>> Does anyone else think it would be a good idea to merge index and
>> index_toc into a single front page?
>>
>> Cheers,
>> Martin
>

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From sebastian.rahtz at it.ox.ac.uk  Fri Nov 23 16:32:13 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Fri, 23 Nov 2012 21:32:13 +0000
Subject: [tei-council] Glines index page
In-Reply-To: <50AFE419.6090002@uvic.ca>
References: <50AFB0C0.5040007@uvic.ca>
	<50AFD760.6020304@retired.ox.ac.uk>,<50AFE419.6090002@uvic.ca>
Message-ID: <D29F2DE9-0EFE-4286-8FEA-07DEFF58F425@oucs.ox.ac.uk>

I believe there was a design cttee and that Julia f was involved. But I may be be misrembering
(Or "miser bearing" as the spell thing would have it)

Carved in stone on my iPad

On 23 Nov 2012, at 21:01, "Martin Holmes" <mholmes at uvic.ca> wrote:

> On 12-11-23 12:06 PM, Lou Burnard wrote:
>> It's the way it is because someone (can't remember who now) wanted a
>> simpler front page, when they saw the full index_toc
> 
> I can't find any discussion of this in the archives, although my search 
> may have missed it. But with its rather odd "Some Popular Sections" bit, 
> the index.html is hardly smaller than the index_toc.html. I vote for a 
> single front/TOC page at index.html, with a 301 at the old _toc location.
> 
> Cheers,
> Martin
> 
>> 
>> 
>> On 23/11/12 17:22, Martin Holmes wrote:
>>> Here's something that's always puzzled me. This page:
>>> 
>>> <http://teijenkins.hcmc.uvic.ca/job/TEIP5/lastSuccessfulBuild/artifact/release/doc/tei-p5-doc/en/html/index.html>
>>> 
>>> is a sort of half-a-table-of-contents, and I don't really see the point
>>> of it. Much of what's there is also on the real table of contents:
>>> 
>>> <http://teijenkins.hcmc.uvic.ca/job/TEIP5/lastSuccessfulBuild/artifact/release/doc/tei-p5-doc/en/html/index-toc.html>
>>> 
>>> but not all of it, so half the time it gets in the way. I noticed a
>>> couple of people at the workshop last week a bit confused by it too.
>>> 
>>> Does anyone else think it would be a good idea to merge index and
>>> index_toc into a single front page?
>>> 
>>> Cheers,
>>> Martin
> 
> -- 
> Martin Holmes
> University of Victoria Humanities Computing and Media Centre
> (mholmes at uvic.ca)
> -- 
> tei-council mailing list
> tei-council at lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
> 
> PLEASE NOTE: postings to this list are publicly archived

From lou.burnard at retired.ox.ac.uk  Fri Nov 23 16:59:10 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Fri, 23 Nov 2012 21:59:10 +0000
Subject: [tei-council] Glines index page
In-Reply-To: <D29F2DE9-0EFE-4286-8FEA-07DEFF58F425@oucs.ox.ac.uk>
References: <50AFB0C0.5040007@uvic.ca> <50AFD760.6020304@retired.ox.ac.uk>,
	<50AFE419.6090002@uvic.ca>
	<D29F2DE9-0EFE-4286-8FEA-07DEFF58F425@oucs.ox.ac.uk>
Message-ID: <50AFF1AE.4090200@retired.ox.ac.uk>

Yes, there was a design committee and Julia was on it. Much, very much, 
blood was spilt as far as i recall, though not necessarily for that reason.

Is it worth tinkering with this particular aspect, which has been like 
this ever since the web site came into being in its present incarnation? 
If/when the website moves from its current host we will have much more 
significant changes to put in place.


On 23/11/12 21:32, Sebastian Rahtz wrote:
> I believe there was a design cttee and that Julia f was involved. But I may be be misrembering
> (Or "miser bearing" as the spell thing would have it)
>
> Carved in stone on my iPad
>
> On 23 Nov 2012, at 21:01, "Martin Holmes" <mholmes at uvic.ca> wrote:
>
>> On 12-11-23 12:06 PM, Lou Burnard wrote:
>>> It's the way it is because someone (can't remember who now) wanted a
>>> simpler front page, when they saw the full index_toc
>> I can't find any discussion of this in the archives, although my search
>> may have missed it. But with its rather odd "Some Popular Sections" bit,
>> the index.html is hardly smaller than the index_toc.html. I vote for a
>> single front/TOC page at index.html, with a 301 at the old _toc location.
>>
>> Cheers,
>> Martin
>>
>>>
>>> On 23/11/12 17:22, Martin Holmes wrote:
>>>> Here's something that's always puzzled me. This page:
>>>>
>>>> <http://teijenkins.hcmc.uvic.ca/job/TEIP5/lastSuccessfulBuild/artifact/release/doc/tei-p5-doc/en/html/index.html>
>>>>
>>>> is a sort of half-a-table-of-contents, and I don't really see the point
>>>> of it. Much of what's there is also on the real table of contents:
>>>>
>>>> <http://teijenkins.hcmc.uvic.ca/job/TEIP5/lastSuccessfulBuild/artifact/release/doc/tei-p5-doc/en/html/index-toc.html>
>>>>
>>>> but not all of it, so half the time it gets in the way. I noticed a
>>>> couple of people at the workshop last week a bit confused by it too.
>>>>
>>>> Does anyone else think it would be a good idea to merge index and
>>>> index_toc into a single front page?
>>>>
>>>> Cheers,
>>>> Martin
>> -- 
>> Martin Holmes
>> University of Victoria Humanities Computing and Media Centre
>> (mholmes at uvic.ca)
>> -- 
>> tei-council mailing list
>> tei-council at lists.village.Virginia.EDU
>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>>
>> PLEASE NOTE: postings to this list are publicly archived


From sebastian.rahtz at it.ox.ac.uk  Fri Nov 23 18:04:45 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Fri, 23 Nov 2012 23:04:45 +0000
Subject: [tei-council] whither HTML of Guidelines and @lang
In-Reply-To: <50AFB0F4.3070405@uvic.ca>
References: <B9BE2CB6-4CC2-4B27-A5B5-5F946E83F7FE@it.ox.ac.uk>
	<c6f7f3d7-11b8-4793-beeb-9905e86ebae8@HUB05.ad.oak.ox.ac.uk>
	<50AF5AB5.5080904@kcl.ac.uk>	<50AF7AC7.8030604@uvic.ca>
	<CAObhq+fC=R9SjLz9L7z2gYqT1-0uPkzHgfMs7E9+dpcgRMnavA@mail.gmail.com>
	<50AFA7F6.7020406@uvic.ca>
	<4E1A54BC-61FF-4F78-9174-D5649E90A321@it.ox.ac.uk>
	<50AFB0F4.3070405@uvic.ca>
Message-ID: <9A23CAF5-B6D5-424D-A219-6D66863FD06E@it.ox.ac.uk>

I have switched over to HTML5 for the Guidelines for a laugh.

Can switch back again in a few minutes if it causes issues. So don't be surprised
if things come and go tomorrow morning.
--
Sebastian Rahtz      
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431


From mholmes at uvic.ca  Sat Nov 24 02:20:04 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Fri, 23 Nov 2012 23:20:04 -0800
Subject: [tei-council] Glines index page
In-Reply-To: <50AFF1AE.4090200@retired.ox.ac.uk>
References: <50AFB0C0.5040007@uvic.ca> <50AFD760.6020304@retired.ox.ac.uk>,
	<50AFE419.6090002@uvic.ca>
	<D29F2DE9-0EFE-4286-8FEA-07DEFF58F425@oucs.ox.ac.uk>
	<50AFF1AE.4090200@retired.ox.ac.uk>
Message-ID: <50B07524.6060008@uvic.ca>

I don't want to start a fight, or re-start an old one, or open old 
wounds. But I do want to say: I think what we have now is not... well, 
_optimal_. Am I the only one that feels this way? If so, of course I'll 
slink away to my burrow and never mention it again.

Cheers,
Martin

On 12-11-23 01:59 PM, Lou Burnard wrote:
> Yes, there was a design committee and Julia was on it. Much, very much,
> blood was spilt as far as i recall, though not necessarily for that reason.
>
> Is it worth tinkering with this particular aspect, which has been like
> this ever since the web site came into being in its present incarnation?
> If/when the website moves from its current host we will have much more
> significant changes to put in place.
>
>
> On 23/11/12 21:32, Sebastian Rahtz wrote:
>> I believe there was a design cttee and that Julia f was involved. But I may be be misrembering
>> (Or "miser bearing" as the spell thing would have it)
>>
>> Carved in stone on my iPad
>>
>> On 23 Nov 2012, at 21:01, "Martin Holmes" <mholmes at uvic.ca> wrote:
>>
>>> On 12-11-23 12:06 PM, Lou Burnard wrote:
>>>> It's the way it is because someone (can't remember who now) wanted a
>>>> simpler front page, when they saw the full index_toc
>>> I can't find any discussion of this in the archives, although my search
>>> may have missed it. But with its rather odd "Some Popular Sections" bit,
>>> the index.html is hardly smaller than the index_toc.html. I vote for a
>>> single front/TOC page at index.html, with a 301 at the old _toc location.
>>>
>>> Cheers,
>>> Martin
>>>
>>>>
>>>> On 23/11/12 17:22, Martin Holmes wrote:
>>>>> Here's something that's always puzzled me. This page:
>>>>>
>>>>> <http://teijenkins.hcmc.uvic.ca/job/TEIP5/lastSuccessfulBuild/artifact/release/doc/tei-p5-doc/en/html/index.html>
>>>>>
>>>>> is a sort of half-a-table-of-contents, and I don't really see the point
>>>>> of it. Much of what's there is also on the real table of contents:
>>>>>
>>>>> <http://teijenkins.hcmc.uvic.ca/job/TEIP5/lastSuccessfulBuild/artifact/release/doc/tei-p5-doc/en/html/index-toc.html>
>>>>>
>>>>> but not all of it, so half the time it gets in the way. I noticed a
>>>>> couple of people at the workshop last week a bit confused by it too.
>>>>>
>>>>> Does anyone else think it would be a good idea to merge index and
>>>>> index_toc into a single front page?
>>>>>
>>>>> Cheers,
>>>>> Martin
>>> --
>>> Martin Holmes
>>> University of Victoria Humanities Computing and Media Centre
>>> (mholmes at uvic.ca)
>>> --
>>> tei-council mailing list
>>> tei-council at lists.village.Virginia.EDU
>>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>>>
>>> PLEASE NOTE: postings to this list are publicly archived
>

From sebastian.rahtz at it.ox.ac.uk  Sat Nov 24 07:09:46 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Sat, 24 Nov 2012 12:09:46 +0000
Subject: [tei-council] Glines index page
In-Reply-To: <50B07524.6060008@uvic.ca>
References: <50AFB0C0.5040007@uvic.ca> <50AFD760.6020304@retired.ox.ac.uk>,
	<50AFE419.6090002@uvic.ca>
	<D29F2DE9-0EFE-4286-8FEA-07DEFF58F425@oucs.ox.ac.uk>
	<50AFF1AE.4090200@retired.ox.ac.uk> <50B07524.6060008@uvic.ca>
Message-ID: <C3249966-6D20-4865-A2CA-83B36084012A@it.ox.ac.uk>


On 24 Nov 2012, at 07:20, Martin Holmes <mholmes at uvic.ca> wrote:

> I don't want to start a fight, or re-start an old one, or open old 
> wounds. But I do want to say: I think what we have now is not... well, 
> _optimal_. Am I the only one that feels this way?

I don't think the landing page is great. But i don't think it's in crisis either.
I'd say put it on the agenda for our next meeting (which is when, James?).

--
Sebastian Rahtz      
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431


From james.cummings at it.ox.ac.uk  Sat Nov 24 07:17:42 2012
From: james.cummings at it.ox.ac.uk (James Cummings)
Date: Sat, 24 Nov 2012 12:17:42 +0000
Subject: [tei-council] Glines index page
In-Reply-To: <C3249966-6D20-4865-A2CA-83B36084012A@it.ox.ac.uk>
References: <50AFB0C0.5040007@uvic.ca> <50AFD760.6020304@retired.ox.ac.uk>,
	<50AFE419.6090002@uvic.ca>
	<D29F2DE9-0EFE-4286-8FEA-07DEFF58F425@oucs.ox.ac.uk>
	<50AFF1AE.4090200@retired.ox.ac.uk> <50B07524.6060008@uvic.ca>,
	<C3249966-6D20-4865-A2CA-83B36084012A@it.ox.ac.uk>
Message-ID: <s2j77cekf46bu9cfhbjsa6tn.1353759460455@email.android.com>


I was thinking we should have another teleconference in mid Dec. will set up a poll for dateTimes later today.

JamesC
--
James Cummings, Academic IT Services, University of Oxford (from phone)

Sebastian Rahtz <sebastian.rahtz at it.ox.ac.uk> wrote:


On 24 Nov 2012, at 07:20, Martin Holmes <mholmes at uvic.ca> wrote:

> I don't want to start a fight, or re-start an old one, or open old
> wounds. But I do want to say: I think what we have now is not... well,
> _optimal_. Am I the only one that feels this way?

I don't think the landing page is great. But i don't think it's in crisis either.
I'd say put it on the agenda for our next meeting (which is when, James?).

--
Sebastian Rahtz
Director (Research Support) of Academic IT Services
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431

--
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 it.ox.ac.uk  Sat Nov 24 07:28:59 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Sat, 24 Nov 2012 12:28:59 +0000
Subject: [tei-council] whither HTML of Guidelines and @lang
In-Reply-To: <9A23CAF5-B6D5-424D-A219-6D66863FD06E@it.ox.ac.uk>
References: <B9BE2CB6-4CC2-4B27-A5B5-5F946E83F7FE@it.ox.ac.uk>
	<c6f7f3d7-11b8-4793-beeb-9905e86ebae8@HUB05.ad.oak.ox.ac.uk>
	<50AF5AB5.5080904@kcl.ac.uk>	<50AF7AC7.8030604@uvic.ca>
	<CAObhq+fC=R9SjLz9L7z2gYqT1-0uPkzHgfMs7E9+dpcgRMnavA@mail.gmail.com>
	<50AFA7F6.7020406@uvic.ca>
	<4E1A54BC-61FF-4F78-9174-D5649E90A321@it.ox.ac.uk>
	<50AFB0F4.3070405@uvic.ca>
	<9A23CAF5-B6D5-424D-A219-6D66863FD06E@it.ox.ac.uk>
Message-ID: <AEBA5F91-70C1-4734-9FFE-0AE53020ADB6@it.ox.ac.uk>

pah, I hate the web and all its doings.

The story so far.  I have fixed up all the  XSL to generate what seems like proper HTML5 for
the Guidelines, and now I want to check it. How hard can that be? answer; very.

* the validator.nu online service can be driven by a Python script. great.

    - the Python script uses gzip, which needs zlib.  the Python under ubuntu is broke and does not have zlib. gah. #fail, as they say

    - the validator complains that (eg)

	"Guidelines-web/en/html/examples-title.html":95.52982-95.53063: info warning: Text run is not in Unicode Normalization Form C.

	sorry?? is this some new fascism I was unaware of? only NFC form permitted now?

* the RELAXNG schemas at http://syntax.whattf.org/ are unuseable with normal validators, cos they just report

	Guidelines-web/en/html/ref-p.html:113:280: error: no datatype library for URI 'http://whattf.org/datatype-draft'
	required:
		data http://whattf.org/datatype-draft^iri-ref
		data http://www.w3.org/2001/XMLSchema-datatypes^string

You know, I don't have time or energy to recompile Python on the Jenkins server, and ask Martin to do the same.
No, I also don't  have time or energy to compile a Java datatype library and work out how to use that with rnv.  

I feel depressed. I don't want to produce clunky XHTML  that no-one  takes any notice of. I don't want to produce
"any old" HTML which is just guesswork as to whether browsers do the right thing. I don't want to produce HTML5
that seems like something from the Branch Davidians.

I'll make mince pies for dinner instead. at least Lou will benefit.
--
Sebastian Rahtz      
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431


From kevin.s.hawkins at ultraslavonic.info  Sat Nov 24 09:27:03 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Sat, 24 Nov 2012 09:27:03 -0500
Subject: [tei-council] Unfinished <quotation> element in example?
In-Reply-To: <50AF93DC.3040104@it.ox.ac.uk>
References: <50AEAA99.3060801@uvic.ca> <50AF5909.1020705@retired.ox.ac.uk>
	<50AF913E.9030505@ultraslavonic.info>
	<50AF93DC.3040104@it.ox.ac.uk>
Message-ID: <50B0D937.7030902@ultraslavonic.info>

On 11/23/12 10:18 AM, James Cummings wrote:
>> Should this be a ticket for discussion with a wider community, or should
>> we just do this?
>
> I like to have tickets where possible so we can more easily track
> something being done (when I help compile release notes ;-) ).

Now at 
https://sourceforge.net/tracker/?func=detail&aid=3589618&group_id=106328&atid=644065 
.

From sebastian.rahtz at it.ox.ac.uk  Sat Nov 24 11:57:02 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Sat, 24 Nov 2012 16:57:02 +0000
Subject: [tei-council] whither HTML of Guidelines and @lang
In-Reply-To: <9A23CAF5-B6D5-424D-A219-6D66863FD06E@it.ox.ac.uk>
References: <B9BE2CB6-4CC2-4B27-A5B5-5F946E83F7FE@it.ox.ac.uk>
	<c6f7f3d7-11b8-4793-beeb-9905e86ebae8@HUB05.ad.oak.ox.ac.uk>
	<50AF5AB5.5080904@kcl.ac.uk>	<50AF7AC7.8030604@uvic.ca>
	<CAObhq+fC=R9SjLz9L7z2gYqT1-0uPkzHgfMs7E9+dpcgRMnavA@mail.gmail.com>
	<50AFA7F6.7020406@uvic.ca>
	<4E1A54BC-61FF-4F78-9174-D5649E90A321@it.ox.ac.uk>
	<50AFB0F4.3070405@uvic.ca>
	<9A23CAF5-B6D5-424D-A219-6D66863FD06E@it.ox.ac.uk>
Message-ID: <D63462C1-33B4-4237-BE5C-17DDBD1F5569@it.ox.ac.uk>

to answer my own questions (I find myself doing that a lot, I need to found a sect), I have
dropped the validation of the HTML of the Gidlines, cos I realize that converting to epub and epub3
(and running their checks) will do the same tests on the same source and the same transformation code.

you can disagree with me, of course :-} but I may then demand that your sacrifice your
first born. your wifes and daughters can rest easy, however, I am not vengeful.
--
David Koresh

From James.Cummings at it.ox.ac.uk  Sun Nov 25 12:36:18 2012
From: James.Cummings at it.ox.ac.uk (James Cummings)
Date: Sun, 25 Nov 2012 17:36:18 +0000
Subject: [tei-council] Scheduling 2012-12 Teleconference
Message-ID: <50B25712.2010609@it.ox.ac.uk>


Hi All,

I've set up a doodle poll for scheduling our next TEI Technical 
Council at:

http://www.doodle.com/p7y5qws7kqpc4d3v

I've suggested 4pm GMT as the time and given you the choice of 
the first two weeks of December. You should be able to change the 
timezone to your own in the upper right.  (Otherwise see 
www.timeanddate.com's meeting planner to double-check.)

A place to put agenda items is available at the top of:

http://wiki.tei-c.org/index.php/Council

Please try to fill it out in the next 2 or 3 days.  New members 
of Council are also welcome to the teleconference!

Volunteers to take minutes who are not Martin (who has done it 
lots!) appreciated!

-James

-- 
Dr James Cummings, James.Cummings at it.ox.ac.uk
Academic IT Services, University of Oxford

From sebastian.rahtz at it.ox.ac.uk  Sun Nov 25 12:59:33 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Sun, 25 Nov 2012 17:59:33 +0000
Subject: [tei-council] Scheduling 2012-12 Teleconference
In-Reply-To: <50B25712.2010609@it.ox.ac.uk>
References: <50B25712.2010609@it.ox.ac.uk>
Message-ID: <c7c56e71-e1d4-4ea1-bd38-9cd95584ec55@HUB01.ad.oak.ox.ac.uk>


On 25 Nov 2012, at 17:36, James Cummings <James.Cummings at it.ox.ac.uk>
 wrote:

> A place to put agenda items is available at the top of:
> 
> http://wiki.tei-c.org/index.php/Council
> 

I've added a few things

--
Sebastian Rahtz      
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431


From mholmes at uvic.ca  Sun Nov 25 13:28:40 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Sun, 25 Nov 2012 10:28:40 -0800
Subject: [tei-council] Abbreviated pointers, prefixDef etc.
Message-ID: <50B26358.7040106@uvic.ca>

Hi all,

I've finished the work arising out of <http://purl.org/tei/fr/3576367>, 
the Prefix Definition Proposal, and the results are now in the Jinks 
builds. Could you take a look at the results and let me know if anything 
needs changing or fixing? If all is OK, I can close the ticket (although 
I have an idea for a slight enhancement that I'll propose on another 
ticket once we have this one done).

Main Guidelines section:

<http://teijenkins.hcmc.uvic.ca/job/TEIP5/lastSuccessfulBuild/artifact/release/doc/tei-p5-doc/en/html/SA.html#SAPU>

Element definitions:

<http://teijenkins.hcmc.uvic.ca/job/TEIP5/lastSuccessfulBuild/artifact/release/doc/tei-p5-doc/en/html/ref-listPrefixDef.html>

<http://teijenkins.hcmc.uvic.ca/job/TEIP5/lastSuccessfulBuild/artifact/release/doc/tei-p5-doc/en/html/ref-prefixDef.html>

New attribute class:

<http://teijenkins.hcmc.uvic.ca/job/TEIP5/lastSuccessfulBuild/artifact/release/doc/tei-p5-doc/en/html/ref-att.patternReplacement.html>

Thanks,
Martin

From Syd_Bauman at Brown.edu  Sun Nov 25 14:05:03 2012
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Sun, 25 Nov 2012 14:05:03 -0500
Subject: [tei-council] Scheduling 2012-12 Teleconference
In-Reply-To: <c7c56e71-e1d4-4ea1-bd38-9cd95584ec55@HUB01.ad.oak.ox.ac.uk>
References: <50B25712.2010609@it.ox.ac.uk>
	<c7c56e71-e1d4-4ea1-bd38-9cd95584ec55@HUB01.ad.oak.ox.ac.uk>
Message-ID: <20658.27615.646970.203248@emt.ad.brown.edu>

* Do you want councilors-elect to sign up on the Doodle poll?
* The poll gives a time of "11:00 AM" each day, but does not say in
  which time zone.

From James.Cummings at it.ox.ac.uk  Sun Nov 25 14:09:59 2012
From: James.Cummings at it.ox.ac.uk (James Cummings)
Date: Sun, 25 Nov 2012 19:09:59 +0000
Subject: [tei-council] Scheduling 2012-12 Teleconference
In-Reply-To: <20658.27615.646970.203248@emt.ad.brown.edu>
References: <50B25712.2010609@it.ox.ac.uk>
	<c7c56e71-e1d4-4ea1-bd38-9cd95584ec55@HUB01.ad.oak.ox.ac.uk>
	<20658.27615.646970.203248@emt.ad.brown.edu>
Message-ID: <50B26D07.1000002@it.ox.ac.uk>

On 25/11/12 19:05, Syd Bauman wrote:
> * Do you want councilors-elect to sign up on the Doodle poll?

Yes please. I figure during the overlap new ppl should act as 
full members of council (as much as they feel able to).

> * The poll gives a time of "11:00 AM" each day, but does not say in
>    which time zone.

Presumably that is your time zone.  I've set it for 16:00 (4pm) 
GMT. In the upper-right just above the table should be a place to 
change the time zone.  Mine says: "Time zone: (GMT+00:00) London 
change" with the word 'change' being a link. It attempts to pick 
up your timezone from your browser, I believe, and use that by 
default.

-James

-- 
Dr James Cummings, James.Cummings at it.ox.ac.uk
Academic IT Services, University of Oxford

From dsewell at virginia.edu  Sun Nov 25 20:48:27 2012
From: dsewell at virginia.edu (David Sewell)
Date: Sun, 25 Nov 2012 20:48:27 -0500 (EST)
Subject: [tei-council] Glines index page
In-Reply-To: <50B07524.6060008@uvic.ca>
References: <50AFB0C0.5040007@uvic.ca> <50AFD760.6020304@retired.ox.ac.uk>,
	<50AFE419.6090002@uvic.ca>
	<D29F2DE9-0EFE-4286-8FEA-07DEFF58F425@oucs.ox.ac.uk>
	<50AFF1AE.4090200@retired.ox.ac.uk> <50B07524.6060008@uvic.ca>
Message-ID: <alpine.OSX.2.00.1211252035390.23078@tadai.local>

One of the recommendations that came out of the Board's discussion of 
the website earlier this month was for some formal usability studies to 
be undertaken prior to any requests (to the TEI community and/or 
third-party vendors) for proposals to contract for website migration. 
I'm sure that any such studies would report that the status quo is not 
optimal, from a user-friendliness point of view, and improved navigation 
would be a sine qua non of any website redesign.

I wasn't part of the previous website design committee, but it's pretty 
clear that the site navigation is confronting two competing needs: (1) 
to provide an upfront overview of what the "TEI Guidelines" are in 
general, and (2) provide ready access to the Guidelines themselves.

Need #1 is met by two pages within the OpenCMS framework:

1.1 Overview of "TEI Guidelines" (http://www.tei-c.org/Guidelines/)
1.2 Overview of "P5 Guidelines" (http://www.tei-c.org/Guidelines/P5/)

Need #2, qua P5, is met by two pages generated by the source release, as 
noted by Martin:

2.1 a P5 general info page 
(http://www.tei-c.org/release/doc/tei-p5-doc/en/html/index.html)
2.2 the formal P5 Guidlines Table of Contents 
(http://www.tei-c.org/release/doc/tei-p5-doc/en/html/index-toc.html)

So the reasoning behind it all is clear, even if the implementation is 
clunky.

It occurs to me that an interim fix might be to add, immediately below 
the page headers for 1.1 and 1.2, a prominent link saying something like 
"Go to the TEI P5 Guidelines Table of Contents", to help people who 
assume that is what "the Guidelines" means.

David

On Fri, 23 Nov 2012, Martin Holmes wrote:

> I don't want to start a fight, or re-start an old one, or open old
> wounds. But I do want to say: I think what we have now is not... well,
> _optimal_. Am I the only one that feels this way? If so, of course I'll
> slink away to my burrow and never mention it again.
>
> Cheers,
> Martin
>
> On 12-11-23 01:59 PM, Lou Burnard wrote:
>> Yes, there was a design committee and Julia was on it. Much, very much,
>> blood was spilt as far as i recall, though not necessarily for that reason.
>>
>> Is it worth tinkering with this particular aspect, which has been like
>> this ever since the web site came into being in its present incarnation?
>> If/when the website moves from its current host we will have much more
>> significant changes to put in place.
>>
>>
>> On 23/11/12 21:32, Sebastian Rahtz wrote:
>>> I believe there was a design cttee and that Julia f was involved. But I may be be misrembering
>>> (Or "miser bearing" as the spell thing would have it)
>>>
>>> Carved in stone on my iPad
>>>
>>> On 23 Nov 2012, at 21:01, "Martin Holmes" <mholmes at uvic.ca> wrote:
>>>
>>>> On 12-11-23 12:06 PM, Lou Burnard wrote:
>>>>> It's the way it is because someone (can't remember who now) wanted a
>>>>> simpler front page, when they saw the full index_toc
>>>> I can't find any discussion of this in the archives, although my search
>>>> may have missed it. But with its rather odd "Some Popular Sections" bit,
>>>> the index.html is hardly smaller than the index_toc.html. I vote for a
>>>> single front/TOC page at index.html, with a 301 at the old _toc location.
>>>>
>>>> Cheers,
>>>> Martin
>>>>
>>>>>
>>>>> On 23/11/12 17:22, Martin Holmes wrote:
>>>>>> Here's something that's always puzzled me. This page:
>>>>>>
>>>>>> <http://teijenkins.hcmc.uvic.ca/job/TEIP5/lastSuccessfulBuild/artifact/release/doc/tei-p5-doc/en/html/index.html>
>>>>>>
>>>>>> is a sort of half-a-table-of-contents, and I don't really see the point
>>>>>> of it. Much of what's there is also on the real table of contents:
>>>>>>
>>>>>> <http://teijenkins.hcmc.uvic.ca/job/TEIP5/lastSuccessfulBuild/artifact/release/doc/tei-p5-doc/en/html/index-toc.html>
>>>>>>
>>>>>> but not all of it, so half the time it gets in the way. I noticed a
>>>>>> couple of people at the workshop last week a bit confused by it too.
>>>>>>
>>>>>> Does anyone else think it would be a good idea to merge index and
>>>>>> index_toc into a single front page?
>>>>>>
>>>>>> Cheers,
>>>>>> Martin
>>>> --
>>>> Martin Holmes
>>>> University of Victoria Humanities Computing and Media Centre
>>>> (mholmes at uvic.ca)
>>>> --
>>>> tei-council mailing list
>>>> tei-council at lists.village.Virginia.EDU
>>>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>>>>
>>>> PLEASE NOTE: postings to this list are publicly archived
>>
>

-- 
David Sewell, Editorial and Technical Manager
ROTUNDA, The University of Virginia Press
PO Box 400314, Charlottesville, VA 22904-4314 USA
Email: dsewell at virginia.edu   Tel: +1 434 924 9973
Web: http://rotunda.upress.virginia.edu/

From gabriel.bodard at kcl.ac.uk  Mon Nov 26 07:41:00 2012
From: gabriel.bodard at kcl.ac.uk (Gabriel Bodard)
Date: Mon, 26 Nov 2012 12:41:00 +0000
Subject: [tei-council] Examples for certainty|precision @match
Message-ID: <50B3635C.6040106@kcl.ac.uk>

After fixing the problem with certLike having been inadvertently removed 
from the content model of <space>, I was about to add an example or two 
to the usage of <certainty> and/or <precision>, when I noticed an 
apparent inconsistency (or at least potential confusion) in the 
guidelines description of the @match attribute.

At 
<http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-att.scoping.html>, 
@match is defined:
"supplies an arbitrary XPath expression identifying a set of nodes, 
selected within the context identified by the @target attribute if this 
is supplied, or within the context of the element bearing this attribute 
if it is not."

I take this to mean that in the absence of @target, if I want to point 
to a <gap> element from a <certainty> inside it, I should write:

<gap><certainty match=".."/></gap>

(The example under match indeed gives match="parent::tei:gap/@reason", 
which I take to be consistent with my usage.)

A note further down adds:
"If neither attribute (sc. @target, @match) is present, the expression 
of certainty applies to the context of the certainty element itself, 
i.e. its parent element." (For starters, this should say "certainty, 
precision etc.".)

But I take this to mean that an element <precision/> should be 
understood to have a default value of match=".." (rather than match="." 
which might be more intuitive). This is not inconsistent, but perhaps 
slightly confusing. (At the very least we should offer more examples here.)

In the examples at 
<http://www.tei-c.org/release/doc/tei-p5-doc/en/html/CE.html#index-body.1_div.21_div.1_div.2_div.4> 
(yuk!) however, we uniformly see values such as:

<certainty match="@who" locus="value" degree="0.5"/>
<certainty match="@resp" locus="value" degree="0.2"/>
etc.

Since the certainty element in these cases has neither who nor resp, 
this usage seems to imply that the starting point for the XPath in 
@match is the parent of the [certainty|precision] element that bears the 
@match attribute.

On the one hand, it is probably simplest to say that the examples in CE 
are wrong and we should just fix them by prefixing all of these @ with 
../ (which is how I've been using this attribute).

On the other, however, if the starting point of the XPath were the 
parent element rather than the [certainty|precision] element itself, 
then it becomes less defensible to have some transcriptional elements 
that cannot take certainty or precision as children, as I argued at the 
last F2F. So I don't mind which way we go on this one. ;-)

Any thoughts?

G

-- 
Dr Gabriel BODARD
Researcher in Digital Epigraphy

Digital Humanities
King's College London
26-29 Drury Lane
London WC2B 5RL

T: +44 (0)20 7848 1388
F: +44 (0)20 7848 2980
E: gabriel.bodard at kcl.ac.uk

http://www.digitalclassicist.org/
http://www.currentepigraphy.org/


From bbarney2 at unl.edu  Mon Nov 26 11:58:53 2012
From: bbarney2 at unl.edu (Brett Barney)
Date: Mon, 26 Nov 2012 16:58:53 +0000
Subject: [tei-council] Glines index page
In-Reply-To: <50B07524.6060008@uvic.ca>
References: <50AFB0C0.5040007@uvic.ca> <50AFD760.6020304@retired.ox.ac.uk>,
	<50AFE419.6090002@uvic.ca>
	<D29F2DE9-0EFE-4286-8FEA-07DEFF58F425@oucs.ox.ac.uk>
	<50AFF1AE.4090200@retired.ox.ac.uk> <50B07524.6060008@uvic.ca>
Message-ID: <596F07805EF3FB4CAB6D065ACD28447A12327D3A@BY2PRD0811MB427.namprd08.prod.outlook.com>


On Nov 24, 2012, at 1:20 AM, Martin Holmes wrote:

> I don't want to start a fight, or re-start an old one, or open old 
> wounds. But I do want to say: I think what we have now is not... well, 
> _optimal_. Am I the only one that feels this way? If so, of course I'll 
> slink away to my burrow and never mention it again.
> 
> Cheers,
> Martin


I feel that way, too. 
(Late to the conversation, I know.)




From rwelzenbach at gmail.com  Mon Nov 26 14:59:50 2012
From: rwelzenbach at gmail.com (Rebecca Welzenbach)
Date: Mon, 26 Nov 2012 14:59:50 -0500
Subject: [tei-council] Glines index page
In-Reply-To: <596F07805EF3FB4CAB6D065ACD28447A12327D3A@BY2PRD0811MB427.namprd08.prod.outlook.com>
References: <50AFB0C0.5040007@uvic.ca> <50AFD760.6020304@retired.ox.ac.uk>
	<50AFE419.6090002@uvic.ca>
	<D29F2DE9-0EFE-4286-8FEA-07DEFF58F425@oucs.ox.ac.uk>
	<50AFF1AE.4090200@retired.ox.ac.uk> <50B07524.6060008@uvic.ca>
	<596F07805EF3FB4CAB6D065ACD28447A12327D3A@BY2PRD0811MB427.namprd08.prod.outlook.com>
Message-ID: <CAA2irtLpy-Xf33_Z_-oEDd-3cN=SOgNKKpyCtb=0W0zQ0qwMJg@mail.gmail.com>

I agree with Martin and Brett that this is really confusing (and have been
trying to make sense of these two pages for a workshop myself this month).

As others have suggested, it may well make sense to hold off on evaluating
whether both pages are desirable/necessary until a usability study can be
carried out on the whole site, but in the meantime, as David said, some
additional labels might really help. It would be good if 2.2 said "Table of
Contents" on it somewhere, and if 2.1 said "Overview," "Summary," "Index,"
"General Info," or whatever the right name is.

Becky


On Mon, Nov 26, 2012 at 11:58 AM, Brett Barney <bbarney2 at unl.edu> wrote:

>
> On Nov 24, 2012, at 1:20 AM, Martin Holmes wrote:
>
> > I don't want to start a fight, or re-start an old one, or open old
> > wounds. But I do want to say: I think what we have now is not... well,
> > _optimal_. Am I the only one that feels this way? If so, of course I'll
> > slink away to my burrow and never mention it again.
> >
> > Cheers,
> > Martin
>
>
> I feel that way, too.
> (Late to the conversation, I know.)
>
>
>
> --
> 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 it.ox.ac.uk  Mon Nov 26 15:05:54 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Mon, 26 Nov 2012 20:05:54 +0000
Subject: [tei-council] Glines index page
In-Reply-To: <CAA2irtLpy-Xf33_Z_-oEDd-3cN=SOgNKKpyCtb=0W0zQ0qwMJg@mail.gmail.com>
References: <50AFB0C0.5040007@uvic.ca> <50AFD760.6020304@retired.ox.ac.uk>
	<50AFE419.6090002@uvic.ca>
	<D29F2DE9-0EFE-4286-8FEA-07DEFF58F425@oucs.ox.ac.uk>
	<50AFF1AE.4090200@retired.ox.ac.uk> <50B07524.6060008@uvic.ca>
	<596F07805EF3FB4CAB6D065ACD28447A12327D3A@BY2PRD0811MB427.namprd08.prod.outlook.com>
	<CAA2irtLpy-Xf33_Z_-oEDd-3cN=SOgNKKpyCtb=0W0zQ0qwMJg@mail.gmail.com>
Message-ID: <B22EEF52-EDAE-44E9-A1D3-AD11C5ACAB5A@it.ox.ac.uk>


On 26 Nov 2012, at 19:59, Rebecca Welzenbach <rwelzenbach at gmail.com>
 wrote:

> I agree with Martin and Brett that this is really confusing (and have been
> trying to make sense of these two pages for a workshop myself this month).
> 

i dont have any particular defence for the page, but I do note that
its been that way for quite a few years without anyone complaining
before. which is odd.

--
Sebastian Rahtz      
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431


From dsewell at virginia.edu  Mon Nov 26 17:08:03 2012
From: dsewell at virginia.edu (David Sewell)
Date: Mon, 26 Nov 2012 17:08:03 -0500 (EST)
Subject: [tei-council] Glines index page
In-Reply-To: <B22EEF52-EDAE-44E9-A1D3-AD11C5ACAB5A@it.ox.ac.uk>
References: <50AFB0C0.5040007@uvic.ca> <50AFD760.6020304@retired.ox.ac.uk>
	<50AFE419.6090002@uvic.ca>
	<D29F2DE9-0EFE-4286-8FEA-07DEFF58F425@oucs.ox.ac.uk>
	<50AFF1AE.4090200@retired.ox.ac.uk> <50B07524.6060008@uvic.ca>
	<596F07805EF3FB4CAB6D065ACD28447A12327D3A@BY2PRD0811MB427.namprd08.prod.outlook.com>
	<CAA2irtLpy-Xf33_Z_-oEDd-3cN=SOgNKKpyCtb=0W0zQ0qwMJg@mail.gmail.com>
	<B22EEF52-EDAE-44E9-A1D3-AD11C5ACAB5A@it.ox.ac.uk>
Message-ID: <alpine.OSX.2.00.1211261705490.13770@lister.ei.virginia.edu>

On Mon, 26 Nov 2012, Sebastian Rahtz wrote:

> i dont have any particular defence for the page, but I do note that
> its been that way for quite a few years without anyone complaining
> before. which is odd.

There haven't been major complaints, but I'm pretty sure that a previous 
discussion along these lines is what led us to the decision to make "P5 
Guidelines - Table of Contents" a one-click link under the Guidelines item in 
the menu bar. Also, seem to remember Melissa Terras giving us all some grief 
about the navigation in her TEI Members Meeting keynote a while back.

David

-- 
David Sewell, Editorial and Technical Manager
ROTUNDA, The University of Virginia Press
PO Box 400314, Charlottesville, VA 22904-4314 USA
Email: dsewell at virginia.edu   Tel: +1 434 924 9973
Web: http://rotunda.upress.virginia.edu/

From kevin.s.hawkins at ultraslavonic.info  Tue Nov 27 09:47:55 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Tue, 27 Nov 2012 09:47:55 -0500
Subject: [tei-council] Fwd: Re: Google Books > TEI
In-Reply-To: <CAHScxsXgBDv_vY2=1S-Ux9Wv+y82tmHdoWj-j2DJ0fpak_gfWA@mail.gmail.com>
References: <CAHScxsXxO188J7bFBH929-r2btB1ajB8Fv=ESNPerXjVgEb24g@mail.gmail.com>
	<4F56CA83.8050704@ultraslavonic.info>
	<CAA2irtJs0PfM8=FgJdRC3FxK7Oqu_U9_=8R3PRLbFOam6qka0w@mail.gmail.com>
	<CAHScxsWcSq5Yp=xcmJbTGW3cKrKBrVdpJuhj1cG_=+AS-NvJcA@mail.gmail.com>
	<4F5A3E50.7020508@oucs.ox.ac.uk>
	<CAHScxsXgBDv_vY2=1S-Ux9Wv+y82tmHdoWj-j2DJ0fpak_gfWA@mail.gmail.com>
Message-ID: <50B4D29B.5070904@ultraslavonic.info>

Hi Ranjith,

Any progress on deployment of TEI export capability in Google Books?

If not, perhaps we can supplement the info at 
https://docs.google.com/document/d/1PWBt_y-svn8ESAFDz1KxZinKXxc9dfn6kj5sbsIbBR0/edit 
by setting up a form in Google Drive where we ask one or two questions 
of the community (like "If Google Books made public domain titles 
available to download as TEI documents, how would you use these?") and 
let people fill in free-form responses.  I can circulate send the link 
to the form to the TEI email list in the hope of getting a broader set 
of responses than just the few of us who have been editing the Google 
Drive document above.  What do you think?

--Kevin

On 3/9/2012 12:39 PM, Ranjith Unnikrishnan wrote:
> That's a great idea, James. I look forward to getting your collective input.
>
> Best,
> ~R
>
>
> On Fri, Mar 9, 2012 at 9:30 AM, James Cummings
> <James.Cummings at oucs.ox.ac.uk <mailto:James.Cummings at oucs.ox.ac.uk>> wrote:
>
>     On 07/03/12 18:48, Ranjith Unnikrishnan wrote:
>
>         I'm looking for formal justification from you for our producing
>         and making TEI files available for download on Google Books. Both
>         require our commitment of several resources for the long term eg.
>         for updating and maintaining code, making necessary changes in
>         our processing pipeline, maintaining the download functionality
>         for the lifetime of Google Books, committing to the extra storage
>         space and computation etc. I have some anecdotal knowledge of why
>         TEI is important, and have already spent a substantial amount of
>         personal time writing the code and vetting the converted TEI
>         output along with various interested parties; so we know it is
>         possible and obviously I have an interest in seeing this all the
>         way through. But since this will be "product"-level decision,
>         there are others who will need to be convinced and will ask the
>         big questions such as:
>
>
>     Hi Ranjith,
>
>     I'm more than happy to work with you in coming up with some
>     executive summary kind of answers to these questions if that will
>     help. How about I share a google doc with you and some of the others
>     of the ad hoc working group.
>
>
>         Hope that makes sense. I'm just trying to move this effort
>         forward with your input.
>
>
>     We really appreciate that and all your hard work. We're more than
>     happy to work with you in any way to benefit TEI users.
>
>     I'll share a google doc link from my gapps account soon.
>
>
>     -James
>
>     --
>     Dr James Cummings, InfoDev,
>     Computing Services, University of Oxford
>
>

From mholmes at uvic.ca  Tue Nov 27 19:48:42 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Tue, 27 Nov 2012 16:48:42 -0800
Subject: [tei-council] @mimeType content
Message-ID: <50B55F6A.905@uvic.ca>

Apologies if we've discussed this before; I see two tickets on related 
issues, but nothing seems to address this specific concern. Both Hugh 
and Syd may have clear ideas on this, since I seem to recall it was 
discussed on TEI-SOM:

@mimeType (att.internetMedia) is defined thusly:

-------
mimeType	(MIME media type) specifies the applicable multimedia internet 
mail extension (MIME) media type
Status 	Optional
Datatype 	1?? occurrences of

data.word

separated by whitespace
Values 	The value should be a valid MIME media type
-------

The "1?? occurrences" suggests that you could have multiple instances of 
mime types, separated by spaces, but the Values description says not.

The example we have for it looks like this:

<ref
   mimeType="application/tei+xml; charset=UTF-8"
 
target="http://tei.svn.sourceforge.net/viewvc/tei/trunk/P5/Source/guidelines-en.xml"/>

In this case, the space (along with the preceding semi-colon) separates 
the actual mime type from the character encoding; in fact the whole 
content of the @mimeType attribute is apparently part of a single "mime 
type" definition, rather than two, separated by spaces.

Should we be more explicit in saying, for instance:

Although multiple data.words may be supplied in this attribute, the 
intention is that they form part of a _single_ mime type, and that the 
spaces separate components of that single mime type, rather than that 
multiple mime types could be supplied inside the attribute.

Or have I understood this wrongly, and in fact it is possible to supply 
more than one mime type, thusly:

mimeType="text/xml application/tei+xml"

leaving it up to a processor to decide the function of the space 
delimiter in any given implementation?

Cheers,
Martin

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From mholmes at uvic.ca  Wed Nov 28 08:49:07 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Wed, 28 Nov 2012 05:49:07 -0800
Subject: [tei-council] Examples for certainty|precision @match
In-Reply-To: <50B3635C.6040106@kcl.ac.uk>
References: <50B3635C.6040106@kcl.ac.uk>
Message-ID: <50B61653.9060000@uvic.ca>

This is a tough one. My instinct is that we should go with what seems to 
be intuitive, and what's most intuitive to me is that if you specify 
nothing, the default is the current context. In other words, the default 
value of @match should be ".", and that if you want to point to a parent 
element, you have to use "..". That means the examples should be 
rewritten to:

<certainty match="../@who" locus="value" degree="0.5"/>

etc. And in realistic usage, the @match attribute would be required, to 
prevent the <certainty> attribute from expressing uncertainty about itself.

This would also make @match in line with @target; if @target contained a 
TEI Pointer of some kind, that would be evaluated relative to the 
current context <certainty>, wouldn't it?

My head hurts when I think about this, though. <certainty> can contain 
<certainty>, meaning that you could have a child <certainty> expressing 
doubt about the value of the parent <certainty>'s @match attribute, 
while the parent <certainty> could express doubt about the child 
<certainty>'s @target. Gawd.

Cheers,
Martin

On 12-11-26 04:41 AM, Gabriel Bodard wrote:
> After fixing the problem with certLike having been inadvertently removed
> from the content model of <space>, I was about to add an example or two
> to the usage of <certainty> and/or <precision>, when I noticed an
> apparent inconsistency (or at least potential confusion) in the
> guidelines description of the @match attribute.
>
> At
> <http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-att.scoping.html>,
> @match is defined:
> "supplies an arbitrary XPath expression identifying a set of nodes,
> selected within the context identified by the @target attribute if this
> is supplied, or within the context of the element bearing this attribute
> if it is not."
>
> I take this to mean that in the absence of @target, if I want to point
> to a <gap> element from a <certainty> inside it, I should write:
>
> <gap><certainty match=".."/></gap>
>
> (The example under match indeed gives match="parent::tei:gap/@reason",
> which I take to be consistent with my usage.)
>
> A note further down adds:
> "If neither attribute (sc. @target, @match) is present, the expression
> of certainty applies to the context of the certainty element itself,
> i.e. its parent element." (For starters, this should say "certainty,
> precision etc.".)
>
> But I take this to mean that an element <precision/> should be
> understood to have a default value of match=".." (rather than match="."
> which might be more intuitive). This is not inconsistent, but perhaps
> slightly confusing. (At the very least we should offer more examples here.)
>
> In the examples at
> <http://www.tei-c.org/release/doc/tei-p5-doc/en/html/CE.html#index-body.1_div.21_div.1_div.2_div.4>
> (yuk!) however, we uniformly see values such as:
>
> <certainty match="@who" locus="value" degree="0.5"/>
> <certainty match="@resp" locus="value" degree="0.2"/>
> etc.
>
> Since the certainty element in these cases has neither who nor resp,
> this usage seems to imply that the starting point for the XPath in
> @match is the parent of the [certainty|precision] element that bears the
> @match attribute.
>
> On the one hand, it is probably simplest to say that the examples in CE
> are wrong and we should just fix them by prefixing all of these @ with
> ../ (which is how I've been using this attribute).
>
> On the other, however, if the starting point of the XPath were the
> parent element rather than the [certainty|precision] element itself,
> then it becomes less defensible to have some transcriptional elements
> that cannot take certainty or precision as children, as I argued at the
> last F2F. So I don't mind which way we go on this one. ;-)
>
> Any thoughts?
>
> G
>

-- 
Martin Holmes
mholmes at uvic.ca
UVic Humanities Computing and Media Centre

From James.Cummings at it.ox.ac.uk  Wed Nov 28 10:30:34 2012
From: James.Cummings at it.ox.ac.uk (James Cummings)
Date: Wed, 28 Nov 2012 15:30:34 +0000
Subject: [tei-council] Examples for certainty|precision @match
In-Reply-To: <50B61653.9060000@uvic.ca>
References: <50B3635C.6040106@kcl.ac.uk> <50B61653.9060000@uvic.ca>
Message-ID: <50B62E1A.30008@it.ox.ac.uk>


Whereas my intuition is telling me the exact opposite. ;-)

If we have:

<name type="place">Foo<certainty match="$" locus="value" 
degree="0.5"/></name>

I think the certainty can't and *shouldn't* be able to refer to 
itself, that is what a nested certainty is for, therefore the 
default @target is an assumed parent::node(). So in this case $ 
should be @type not ../@type.

As Gabby pointed out the flaw in this reasoning of mine is where 
we want to be uncertain or imprecise about milestone elements 
which don't have certainty in them (lb for example).  That is why 
I'm with him in thinking they should have this content (and I 
think should have <desc> as well given recent discussion on TEI-L).

-James

On 28/11/12 13:49, Martin Holmes wrote:
> This is a tough one. My instinct is that we should go with what seems to
> be intuitive, and what's most intuitive to me is that if you specify
> nothing, the default is the current context. In other words, the default
> value of @match should be ".", and that if you want to point to a parent
> element, you have to use "..". That means the examples should be
> rewritten to:
>
> <certainty match="../@who" locus="value" degree="0.5"/>
>
> etc. And in realistic usage, the @match attribute would be required, to
> prevent the <certainty> attribute from expressing uncertainty about itself.
>
> This would also make @match in line with @target; if @target contained a
> TEI Pointer of some kind, that would be evaluated relative to the
> current context <certainty>, wouldn't it?
>
> My head hurts when I think about this, though. <certainty> can contain
> <certainty>, meaning that you could have a child <certainty> expressing
> doubt about the value of the parent <certainty>'s @match attribute,
> while the parent <certainty> could express doubt about the child
> <certainty>'s @target. Gawd.
>
> Cheers,
> Martin
>
> On 12-11-26 04:41 AM, Gabriel Bodard wrote:
>> After fixing the problem with certLike having been inadvertently removed
>> from the content model of <space>, I was about to add an example or two
>> to the usage of <certainty> and/or <precision>, when I noticed an
>> apparent inconsistency (or at least potential confusion) in the
>> guidelines description of the @match attribute.
>>
>> At
>> <http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-att.scoping.html>,
>> @match is defined:
>> "supplies an arbitrary XPath expression identifying a set of nodes,
>> selected within the context identified by the @target attribute if this
>> is supplied, or within the context of the element bearing this attribute
>> if it is not."
>>
>> I take this to mean that in the absence of @target, if I want to point
>> to a <gap> element from a <certainty> inside it, I should write:
>>
>> <gap><certainty match=".."/></gap>
>>
>> (The example under match indeed gives match="parent::tei:gap/@reason",
>> which I take to be consistent with my usage.)
>>
>> A note further down adds:
>> "If neither attribute (sc. @target, @match) is present, the expression
>> of certainty applies to the context of the certainty element itself,
>> i.e. its parent element." (For starters, this should say "certainty,
>> precision etc.".)
>>
>> But I take this to mean that an element <precision/> should be
>> understood to have a default value of match=".." (rather than match="."
>> which might be more intuitive). This is not inconsistent, but perhaps
>> slightly confusing. (At the very least we should offer more examples here.)
>>
>> In the examples at
>> <http://www.tei-c.org/release/doc/tei-p5-doc/en/html/CE.html#index-body.1_div.21_div.1_div.2_div.4>
>> (yuk!) however, we uniformly see values such as:
>>
>> <certainty match="@who" locus="value" degree="0.5"/>
>> <certainty match="@resp" locus="value" degree="0.2"/>
>> etc.
>>
>> Since the certainty element in these cases has neither who nor resp,
>> this usage seems to imply that the starting point for the XPath in
>> @match is the parent of the [certainty|precision] element that bears the
>> @match attribute.
>>
>> On the one hand, it is probably simplest to say that the examples in CE
>> are wrong and we should just fix them by prefixing all of these @ with
>> ../ (which is how I've been using this attribute).
>>
>> On the other, however, if the starting point of the XPath were the
>> parent element rather than the [certainty|precision] element itself,
>> then it becomes less defensible to have some transcriptional elements
>> that cannot take certainty or precision as children, as I argued at the
>> last F2F. So I don't mind which way we go on this one. ;-)
>>
>> Any thoughts?
>>
>> G
>>
>


-- 
Dr James Cummings, James.Cummings at it.ox.ac.uk
Academic IT Services, University of Oxford

From mholmes at uvic.ca  Wed Nov 28 11:04:56 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Wed, 28 Nov 2012 08:04:56 -0800
Subject: [tei-council] Examples for certainty|precision @match
In-Reply-To: <50B62E1A.30008@it.ox.ac.uk>
References: <50B3635C.6040106@kcl.ac.uk> <50B61653.9060000@uvic.ca>
	<50B62E1A.30008@it.ox.ac.uk>
Message-ID: <50B63628.406@uvic.ca>

I see the logic there.

If @target is used instead, with an xpath pointer, would the context 
node for that also be considered to be the parent node? If so, wouldn't 
that make the user of pointers in att.scoping/@target different from 
@target defined in e.g. att.pointing?

Cheers,
Martin

On 12-11-28 07:30 AM, James Cummings wrote:
>
> Whereas my intuition is telling me the exact opposite. ;-)
>
> If we have:
>
> <name type="place">Foo<certainty match="$" locus="value"
> degree="0.5"/></name>
>
> I think the certainty can't and *shouldn't* be able to refer to
> itself, that is what a nested certainty is for, therefore the
> default @target is an assumed parent::node(). So in this case $
> should be @type not ../@type.
>
> As Gabby pointed out the flaw in this reasoning of mine is where
> we want to be uncertain or imprecise about milestone elements
> which don't have certainty in them (lb for example).  That is why
> I'm with him in thinking they should have this content (and I
> think should have <desc> as well given recent discussion on TEI-L).
>
> -James
>
> On 28/11/12 13:49, Martin Holmes wrote:
>> This is a tough one. My instinct is that we should go with what seems to
>> be intuitive, and what's most intuitive to me is that if you specify
>> nothing, the default is the current context. In other words, the default
>> value of @match should be ".", and that if you want to point to a parent
>> element, you have to use "..". That means the examples should be
>> rewritten to:
>>
>> <certainty match="../@who" locus="value" degree="0.5"/>
>>
>> etc. And in realistic usage, the @match attribute would be required, to
>> prevent the <certainty> attribute from expressing uncertainty about itself.
>>
>> This would also make @match in line with @target; if @target contained a
>> TEI Pointer of some kind, that would be evaluated relative to the
>> current context <certainty>, wouldn't it?
>>
>> My head hurts when I think about this, though. <certainty> can contain
>> <certainty>, meaning that you could have a child <certainty> expressing
>> doubt about the value of the parent <certainty>'s @match attribute,
>> while the parent <certainty> could express doubt about the child
>> <certainty>'s @target. Gawd.
>>
>> Cheers,
>> Martin
>>
>> On 12-11-26 04:41 AM, Gabriel Bodard wrote:
>>> After fixing the problem with certLike having been inadvertently removed
>>> from the content model of <space>, I was about to add an example or two
>>> to the usage of <certainty> and/or <precision>, when I noticed an
>>> apparent inconsistency (or at least potential confusion) in the
>>> guidelines description of the @match attribute.
>>>
>>> At
>>> <http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-att.scoping.html>,
>>> @match is defined:
>>> "supplies an arbitrary XPath expression identifying a set of nodes,
>>> selected within the context identified by the @target attribute if this
>>> is supplied, or within the context of the element bearing this attribute
>>> if it is not."
>>>
>>> I take this to mean that in the absence of @target, if I want to point
>>> to a <gap> element from a <certainty> inside it, I should write:
>>>
>>> <gap><certainty match=".."/></gap>
>>>
>>> (The example under match indeed gives match="parent::tei:gap/@reason",
>>> which I take to be consistent with my usage.)
>>>
>>> A note further down adds:
>>> "If neither attribute (sc. @target, @match) is present, the expression
>>> of certainty applies to the context of the certainty element itself,
>>> i.e. its parent element." (For starters, this should say "certainty,
>>> precision etc.".)
>>>
>>> But I take this to mean that an element <precision/> should be
>>> understood to have a default value of match=".." (rather than match="."
>>> which might be more intuitive). This is not inconsistent, but perhaps
>>> slightly confusing. (At the very least we should offer more examples here.)
>>>
>>> In the examples at
>>> <http://www.tei-c.org/release/doc/tei-p5-doc/en/html/CE.html#index-body.1_div.21_div.1_div.2_div.4>
>>> (yuk!) however, we uniformly see values such as:
>>>
>>> <certainty match="@who" locus="value" degree="0.5"/>
>>> <certainty match="@resp" locus="value" degree="0.2"/>
>>> etc.
>>>
>>> Since the certainty element in these cases has neither who nor resp,
>>> this usage seems to imply that the starting point for the XPath in
>>> @match is the parent of the [certainty|precision] element that bears the
>>> @match attribute.
>>>
>>> On the one hand, it is probably simplest to say that the examples in CE
>>> are wrong and we should just fix them by prefixing all of these @ with
>>> ../ (which is how I've been using this attribute).
>>>
>>> On the other, however, if the starting point of the XPath were the
>>> parent element rather than the [certainty|precision] element itself,
>>> then it becomes less defensible to have some transcriptional elements
>>> that cannot take certainty or precision as children, as I argued at the
>>> last F2F. So I don't mind which way we go on this one. ;-)
>>>
>>> Any thoughts?
>>>
>>> G
>>>
>>
>
>

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From gabriel.bodard at kcl.ac.uk  Wed Nov 28 11:06:17 2012
From: gabriel.bodard at kcl.ac.uk (Gabriel Bodard)
Date: Wed, 28 Nov 2012 16:06:17 +0000
Subject: [tei-council] Examples for certainty|precision @match
In-Reply-To: <50B63628.406@uvic.ca>
References: <50B3635C.6040106@kcl.ac.uk> <50B61653.9060000@uvic.ca>
	<50B62E1A.30008@it.ox.ac.uk> <50B63628.406@uvic.ca>
Message-ID: <50B63679.5090702@kcl.ac.uk>

I thought the base of an xpointer in @target was deemed to be root, 
*not* any relation to the current node, hence the need for @match in the 
first place?

On 2012-11-28 16:04, Martin Holmes wrote:
> I see the logic there.
>
> If @target is used instead, with an xpath pointer, would the context
> node for that also be considered to be the parent node? If so, wouldn't
> that make the user of pointers in att.scoping/@target different from
> @target defined in e.g. att.pointing?
>
> Cheers,
> Martin
>
> On 12-11-28 07:30 AM, James Cummings wrote:
>>
>> Whereas my intuition is telling me the exact opposite. ;-)
>>
>> If we have:
>>
>> <name type="place">Foo<certainty match="$" locus="value"
>> degree="0.5"/></name>
>>
>> I think the certainty can't and *shouldn't* be able to refer to
>> itself, that is what a nested certainty is for, therefore the
>> default @target is an assumed parent::node(). So in this case $
>> should be @type not ../@type.
>>
>> As Gabby pointed out the flaw in this reasoning of mine is where
>> we want to be uncertain or imprecise about milestone elements
>> which don't have certainty in them (lb for example).  That is why
>> I'm with him in thinking they should have this content (and I
>> think should have <desc> as well given recent discussion on TEI-L).
>>
>> -James
>>
>> On 28/11/12 13:49, Martin Holmes wrote:
>>> This is a tough one. My instinct is that we should go with what seems to
>>> be intuitive, and what's most intuitive to me is that if you specify
>>> nothing, the default is the current context. In other words, the default
>>> value of @match should be ".", and that if you want to point to a parent
>>> element, you have to use "..". That means the examples should be
>>> rewritten to:
>>>
>>> <certainty match="../@who" locus="value" degree="0.5"/>
>>>
>>> etc. And in realistic usage, the @match attribute would be required, to
>>> prevent the <certainty> attribute from expressing uncertainty about itself.
>>>
>>> This would also make @match in line with @target; if @target contained a
>>> TEI Pointer of some kind, that would be evaluated relative to the
>>> current context <certainty>, wouldn't it?
>>>
>>> My head hurts when I think about this, though. <certainty> can contain
>>> <certainty>, meaning that you could have a child <certainty> expressing
>>> doubt about the value of the parent <certainty>'s @match attribute,
>>> while the parent <certainty> could express doubt about the child
>>> <certainty>'s @target. Gawd.
>>>
>>> Cheers,
>>> Martin
>>>
>>> On 12-11-26 04:41 AM, Gabriel Bodard wrote:
>>>> After fixing the problem with certLike having been inadvertently removed
>>>> from the content model of <space>, I was about to add an example or two
>>>> to the usage of <certainty> and/or <precision>, when I noticed an
>>>> apparent inconsistency (or at least potential confusion) in the
>>>> guidelines description of the @match attribute.
>>>>
>>>> At
>>>> <http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-att.scoping.html>,
>>>> @match is defined:
>>>> "supplies an arbitrary XPath expression identifying a set of nodes,
>>>> selected within the context identified by the @target attribute if this
>>>> is supplied, or within the context of the element bearing this attribute
>>>> if it is not."
>>>>
>>>> I take this to mean that in the absence of @target, if I want to point
>>>> to a <gap> element from a <certainty> inside it, I should write:
>>>>
>>>> <gap><certainty match=".."/></gap>
>>>>
>>>> (The example under match indeed gives match="parent::tei:gap/@reason",
>>>> which I take to be consistent with my usage.)
>>>>
>>>> A note further down adds:
>>>> "If neither attribute (sc. @target, @match) is present, the expression
>>>> of certainty applies to the context of the certainty element itself,
>>>> i.e. its parent element." (For starters, this should say "certainty,
>>>> precision etc.".)
>>>>
>>>> But I take this to mean that an element <precision/> should be
>>>> understood to have a default value of match=".." (rather than match="."
>>>> which might be more intuitive). This is not inconsistent, but perhaps
>>>> slightly confusing. (At the very least we should offer more examples here.)
>>>>
>>>> In the examples at
>>>> <http://www.tei-c.org/release/doc/tei-p5-doc/en/html/CE.html#index-body.1_div.21_div.1_div.2_div.4>
>>>> (yuk!) however, we uniformly see values such as:
>>>>
>>>> <certainty match="@who" locus="value" degree="0.5"/>
>>>> <certainty match="@resp" locus="value" degree="0.2"/>
>>>> etc.
>>>>
>>>> Since the certainty element in these cases has neither who nor resp,
>>>> this usage seems to imply that the starting point for the XPath in
>>>> @match is the parent of the [certainty|precision] element that bears the
>>>> @match attribute.
>>>>
>>>> On the one hand, it is probably simplest to say that the examples in CE
>>>> are wrong and we should just fix them by prefixing all of these @ with
>>>> ../ (which is how I've been using this attribute).
>>>>
>>>> On the other, however, if the starting point of the XPath were the
>>>> parent element rather than the [certainty|precision] element itself,
>>>> then it becomes less defensible to have some transcriptional elements
>>>> that cannot take certainty or precision as children, as I argued at the
>>>> last F2F. So I don't mind which way we go on this one. ;-)
>>>>
>>>> Any thoughts?
>>>>
>>>> G
>>>>
>>>
>>
>>
>

-- 
Dr Gabriel BODARD
Researcher in Digital Epigraphy

Digital Humanities
King's College London
26-29 Drury Lane
London WC2B 5RL

T: +44 (0)20 7848 1388
F: +44 (0)20 7848 2980
E: gabriel.bodard at kcl.ac.uk

http://www.digitalclassicist.org/
http://www.currentepigraphy.org/


From kevin.s.hawkins at ultraslavonic.info  Wed Nov 28 12:16:30 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Wed, 28 Nov 2012 12:16:30 -0500
Subject: [tei-council] Examples for certainty|precision @match
In-Reply-To: <50B63679.5090702@kcl.ac.uk>
References: <50B3635C.6040106@kcl.ac.uk>
	<50B61653.9060000@uvic.ca>	<50B62E1A.30008@it.ox.ac.uk>
	<50B63628.406@uvic.ca> <50B63679.5090702@kcl.ac.uk>
Message-ID: <50B646EE.7070703@ultraslavonic.info>

Actually, I believe the base of a relative URI in @target is calculated 
in the following order:

1) The value of @xml:base on the element.
2) The value of @xml:base on the parent element.
3) The value of @xml:base on the grandparent element.
4) etc.
5) / (root)

--Kevin

On 11/28/2012 11:06 AM, Gabriel Bodard wrote:
> I thought the base of an xpointer in @target was deemed to be root,
> *not* any relation to the current node, hence the need for @match in the
> first place?
>
> On 2012-11-28 16:04, Martin Holmes wrote:
>> I see the logic there.
>>
>> If @target is used instead, with an xpath pointer, would the context
>> node for that also be considered to be the parent node? If so, wouldn't
>> that make the user of pointers in att.scoping/@target different from
>> @target defined in e.g. att.pointing?
>>
>> Cheers,
>> Martin
>>
>> On 12-11-28 07:30 AM, James Cummings wrote:
>>>
>>> Whereas my intuition is telling me the exact opposite. ;-)
>>>
>>> If we have:
>>>
>>> <name type="place">Foo<certainty match="$" locus="value"
>>> degree="0.5"/></name>
>>>
>>> I think the certainty can't and *shouldn't* be able to refer to
>>> itself, that is what a nested certainty is for, therefore the
>>> default @target is an assumed parent::node(). So in this case $
>>> should be @type not ../@type.
>>>
>>> As Gabby pointed out the flaw in this reasoning of mine is where
>>> we want to be uncertain or imprecise about milestone elements
>>> which don't have certainty in them (lb for example).  That is why
>>> I'm with him in thinking they should have this content (and I
>>> think should have<desc>  as well given recent discussion on TEI-L).
>>>
>>> -James
>>>
>>> On 28/11/12 13:49, Martin Holmes wrote:
>>>> This is a tough one. My instinct is that we should go with what seems to
>>>> be intuitive, and what's most intuitive to me is that if you specify
>>>> nothing, the default is the current context. In other words, the default
>>>> value of @match should be ".", and that if you want to point to a parent
>>>> element, you have to use "..". That means the examples should be
>>>> rewritten to:
>>>>
>>>> <certainty match="../@who" locus="value" degree="0.5"/>
>>>>
>>>> etc. And in realistic usage, the @match attribute would be required, to
>>>> prevent the<certainty>  attribute from expressing uncertainty about itself.
>>>>
>>>> This would also make @match in line with @target; if @target contained a
>>>> TEI Pointer of some kind, that would be evaluated relative to the
>>>> current context<certainty>, wouldn't it?
>>>>
>>>> My head hurts when I think about this, though.<certainty>  can contain
>>>> <certainty>, meaning that you could have a child<certainty>  expressing
>>>> doubt about the value of the parent<certainty>'s @match attribute,
>>>> while the parent<certainty>  could express doubt about the child
>>>> <certainty>'s @target. Gawd.
>>>>
>>>> Cheers,
>>>> Martin
>>>>
>>>> On 12-11-26 04:41 AM, Gabriel Bodard wrote:
>>>>> After fixing the problem with certLike having been inadvertently removed
>>>>> from the content model of<space>, I was about to add an example or two
>>>>> to the usage of<certainty>  and/or<precision>, when I noticed an
>>>>> apparent inconsistency (or at least potential confusion) in the
>>>>> guidelines description of the @match attribute.
>>>>>
>>>>> At
>>>>> <http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-att.scoping.html>,
>>>>> @match is defined:
>>>>> "supplies an arbitrary XPath expression identifying a set of nodes,
>>>>> selected within the context identified by the @target attribute if this
>>>>> is supplied, or within the context of the element bearing this attribute
>>>>> if it is not."
>>>>>
>>>>> I take this to mean that in the absence of @target, if I want to point
>>>>> to a<gap>  element from a<certainty>  inside it, I should write:
>>>>>
>>>>> <gap><certainty match=".."/></gap>
>>>>>
>>>>> (The example under match indeed gives match="parent::tei:gap/@reason",
>>>>> which I take to be consistent with my usage.)
>>>>>
>>>>> A note further down adds:
>>>>> "If neither attribute (sc. @target, @match) is present, the expression
>>>>> of certainty applies to the context of the certainty element itself,
>>>>> i.e. its parent element." (For starters, this should say "certainty,
>>>>> precision etc.".)
>>>>>
>>>>> But I take this to mean that an element<precision/>  should be
>>>>> understood to have a default value of match=".." (rather than match="."
>>>>> which might be more intuitive). This is not inconsistent, but perhaps
>>>>> slightly confusing. (At the very least we should offer more examples here.)
>>>>>
>>>>> In the examples at
>>>>> <http://www.tei-c.org/release/doc/tei-p5-doc/en/html/CE.html#index-body.1_div.21_div.1_div.2_div.4>
>>>>> (yuk!) however, we uniformly see values such as:
>>>>>
>>>>> <certainty match="@who" locus="value" degree="0.5"/>
>>>>> <certainty match="@resp" locus="value" degree="0.2"/>
>>>>> etc.
>>>>>
>>>>> Since the certainty element in these cases has neither who nor resp,
>>>>> this usage seems to imply that the starting point for the XPath in
>>>>> @match is the parent of the [certainty|precision] element that bears the
>>>>> @match attribute.
>>>>>
>>>>> On the one hand, it is probably simplest to say that the examples in CE
>>>>> are wrong and we should just fix them by prefixing all of these @ with
>>>>> ../ (which is how I've been using this attribute).
>>>>>
>>>>> On the other, however, if the starting point of the XPath were the
>>>>> parent element rather than the [certainty|precision] element itself,
>>>>> then it becomes less defensible to have some transcriptional elements
>>>>> that cannot take certainty or precision as children, as I argued at the
>>>>> last F2F. So I don't mind which way we go on this one. ;-)
>>>>>
>>>>> Any thoughts?
>>>>>
>>>>> G
>>>>>
>>>>
>>>
>>>
>>
>

From gabriel.bodard at kcl.ac.uk  Thu Nov 29 06:11:11 2012
From: gabriel.bodard at kcl.ac.uk (Gabriel Bodard)
Date: Thu, 29 Nov 2012 11:11:11 +0000
Subject: [tei-council] Examples for certainty|precision @match
In-Reply-To: <50B646EE.7070703@ultraslavonic.info>
References: <50B3635C.6040106@kcl.ac.uk>
	<50B61653.9060000@uvic.ca>	<50B62E1A.30008@it.ox.ac.uk>
	<50B63628.406@uvic.ca> <50B63679.5090702@kcl.ac.uk>
	<50B646EE.7070703@ultraslavonic.info>
Message-ID: <50B742CF.200@kcl.ac.uk>

That rings a bell. :-) So in the absence of @xml:base, the starting 
point for any xpointer in @target is root. (Which was an aside anyway.)

There are two questions re the starting point for xpath in @match:

1. What is the starting point assumed to be for any @match (in the 
absence of @target)? The guidelines say current element, but some 
examples in CE seem to assume the element's parent;

2. What is the assumed context of any certainty|precision element in the 
absence of @match (and @target)? The guidelines say current element's 
parent, which I feel is slightly unintuitive alongside the official 
answer to question 1.

There are then 4 possible solutions to this:

  a. context is always current element, so most @match attributes will 
begin "../", but other possibilities such as match="preceding::lb[1]" 
are possible. This may be the most strictly rational solution, although 
not the most popular, as far as conversation so far indicates. (Plus, 
and more importantly, I bet no one actually uses xsl:evaluate to 
interpret the content of @match as XPath...)

  b. context is always parent of current element, so @match can often be 
omitted, and most examples in the Guidelines showing values such as 
match="@reason" are correct. This is also nice and consistent, if 
slightly more limiting (but in a good way: a certainty element can no 
longer refer to itself), and also convenient for anyone who doesn't want 
to have to evaluate document-source XPath on the fly, but just embed 
certainty|precision inside the qualified element and treat it as an 
"enhanced attribute".

  c. context is current if there is content in @match (and no @target), 
parent if there is not: status quo; examples in guidelines need fixing. 
(Slightly unintuitive?)

[d. context is parent if there is content in @match (and no @target), 
current if not: clearly nonsense.]

There are arguments for and against all of a, b and c. In my opinion b 
is the strongest, for the reasons articulated above (and argued by James 
yesterday), but there may be some value to c, the status quo.

Does this express the options clearly, do you think?

G

On 2012-11-28 17:16, Kevin Hawkins wrote:
> Actually, I believe the base of a relative URI in @target is calculated
> in the following order:
>
> 1) The value of @xml:base on the element.
> 2) The value of @xml:base on the parent element.
> 3) The value of @xml:base on the grandparent element.
> 4) etc.
> 5) / (root)
>
> --Kevin
>
> On 11/28/2012 11:06 AM, Gabriel Bodard wrote:
>> I thought the base of an xpointer in @target was deemed to be root,
>> *not* any relation to the current node, hence the need for @match in the
>> first place?
>>
>> On 2012-11-28 16:04, Martin Holmes wrote:
>>> I see the logic there.
>>>
>>> If @target is used instead, with an xpath pointer, would the context
>>> node for that also be considered to be the parent node? If so, wouldn't
>>> that make the user of pointers in att.scoping/@target different from
>>> @target defined in e.g. att.pointing?
>>>
>>> Cheers,
>>> Martin
>>>
>>> On 12-11-28 07:30 AM, James Cummings wrote:
>>>>
>>>> Whereas my intuition is telling me the exact opposite. ;-)
>>>>
>>>> If we have:
>>>>
>>>> <name type="place">Foo<certainty match="$" locus="value"
>>>> degree="0.5"/></name>
>>>>
>>>> I think the certainty can't and *shouldn't* be able to refer to
>>>> itself, that is what a nested certainty is for, therefore the
>>>> default @target is an assumed parent::node(). So in this case $
>>>> should be @type not ../@type.
>>>>
>>>> As Gabby pointed out the flaw in this reasoning of mine is where
>>>> we want to be uncertain or imprecise about milestone elements
>>>> which don't have certainty in them (lb for example).  That is why
>>>> I'm with him in thinking they should have this content (and I
>>>> think should have<desc>  as well given recent discussion on TEI-L).
>>>>
>>>> -James
>>>>
>>>> On 28/11/12 13:49, Martin Holmes wrote:
>>>>> This is a tough one. My instinct is that we should go with what seems to
>>>>> be intuitive, and what's most intuitive to me is that if you specify
>>>>> nothing, the default is the current context. In other words, the default
>>>>> value of @match should be ".", and that if you want to point to a parent
>>>>> element, you have to use "..". That means the examples should be
>>>>> rewritten to:
>>>>>
>>>>> <certainty match="../@who" locus="value" degree="0.5"/>
>>>>>
>>>>> etc. And in realistic usage, the @match attribute would be required, to
>>>>> prevent the<certainty>  attribute from expressing uncertainty about itself.
>>>>>
>>>>> This would also make @match in line with @target; if @target contained a
>>>>> TEI Pointer of some kind, that would be evaluated relative to the
>>>>> current context<certainty>, wouldn't it?
>>>>>
>>>>> My head hurts when I think about this, though.<certainty>  can contain
>>>>> <certainty>, meaning that you could have a child<certainty>  expressing
>>>>> doubt about the value of the parent<certainty>'s @match attribute,
>>>>> while the parent<certainty>  could express doubt about the child
>>>>> <certainty>'s @target. Gawd.
>>>>>
>>>>> Cheers,
>>>>> Martin
>>>>>
>>>>> On 12-11-26 04:41 AM, Gabriel Bodard wrote:
>>>>>> After fixing the problem with certLike having been inadvertently removed
>>>>>> from the content model of<space>, I was about to add an example or two
>>>>>> to the usage of<certainty>  and/or<precision>, when I noticed an
>>>>>> apparent inconsistency (or at least potential confusion) in the
>>>>>> guidelines description of the @match attribute.
>>>>>>
>>>>>> At
>>>>>> <http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-att.scoping.html>,
>>>>>> @match is defined:
>>>>>> "supplies an arbitrary XPath expression identifying a set of nodes,
>>>>>> selected within the context identified by the @target attribute if this
>>>>>> is supplied, or within the context of the element bearing this attribute
>>>>>> if it is not."
>>>>>>
>>>>>> I take this to mean that in the absence of @target, if I want to point
>>>>>> to a<gap>  element from a<certainty>  inside it, I should write:
>>>>>>
>>>>>> <gap><certainty match=".."/></gap>
>>>>>>
>>>>>> (The example under match indeed gives match="parent::tei:gap/@reason",
>>>>>> which I take to be consistent with my usage.)
>>>>>>
>>>>>> A note further down adds:
>>>>>> "If neither attribute (sc. @target, @match) is present, the expression
>>>>>> of certainty applies to the context of the certainty element itself,
>>>>>> i.e. its parent element." (For starters, this should say "certainty,
>>>>>> precision etc.".)
>>>>>>
>>>>>> But I take this to mean that an element<precision/>  should be
>>>>>> understood to have a default value of match=".." (rather than match="."
>>>>>> which might be more intuitive). This is not inconsistent, but perhaps
>>>>>> slightly confusing. (At the very least we should offer more examples here.)
>>>>>>
>>>>>> In the examples at
>>>>>> <http://www.tei-c.org/release/doc/tei-p5-doc/en/html/CE.html#index-body.1_div.21_div.1_div.2_div.4>
>>>>>> (yuk!) however, we uniformly see values such as:
>>>>>>
>>>>>> <certainty match="@who" locus="value" degree="0.5"/>
>>>>>> <certainty match="@resp" locus="value" degree="0.2"/>
>>>>>> etc.
>>>>>>
>>>>>> Since the certainty element in these cases has neither who nor resp,
>>>>>> this usage seems to imply that the starting point for the XPath in
>>>>>> @match is the parent of the [certainty|precision] element that bears the
>>>>>> @match attribute.
>>>>>>
>>>>>> On the one hand, it is probably simplest to say that the examples in CE
>>>>>> are wrong and we should just fix them by prefixing all of these @ with
>>>>>> ../ (which is how I've been using this attribute).
>>>>>>
>>>>>> On the other, however, if the starting point of the XPath were the
>>>>>> parent element rather than the [certainty|precision] element itself,
>>>>>> then it becomes less defensible to have some transcriptional elements
>>>>>> that cannot take certainty or precision as children, as I argued at the
>>>>>> last F2F. So I don't mind which way we go on this one. ;-)
>>>>>>
>>>>>> Any thoughts?
>>>>>>
>>>>>> G
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>

-- 
Dr Gabriel BODARD
Researcher in Digital Epigraphy

Digital Humanities
King's College London
26-29 Drury Lane
London WC2B 5RL

T: +44 (0)20 7848 1388
F: +44 (0)20 7848 2980
E: gabriel.bodard at kcl.ac.uk

http://www.digitalclassicist.org/
http://www.currentepigraphy.org/


From James.Cummings at it.ox.ac.uk  Thu Nov 29 07:50:49 2012
From: James.Cummings at it.ox.ac.uk (James Cummings)
Date: Thu, 29 Nov 2012 12:50:49 +0000
Subject: [tei-council] Examples for certainty|precision @match
In-Reply-To: <50B742CF.200@kcl.ac.uk>
References: <50B3635C.6040106@kcl.ac.uk>
	<50B61653.9060000@uvic.ca>	<50B62E1A.30008@it.ox.ac.uk>
	<50B63628.406@uvic.ca> <50B63679.5090702@kcl.ac.uk>
	<50B646EE.7070703@ultraslavonic.info> <50B742CF.200@kcl.ac.uk>
Message-ID: <50B75A29.3010606@it.ox.ac.uk>

On 29/11/12 11:11, Gabriel Bodard wrote:
> That rings a bell. :-) So in the absence of @xml:base, the starting
> point for any xpointer in @target is root. (Which was an aside anyway.)
>
> There are two questions re the starting point for xpath in @match:
>
> 1. What is the starting point assumed to be for any @match (in the
> absence of @target)? The guidelines say current element, but some
> examples in CE seem to assume the element's parent;

The guidelines explicitly say the opposite of this surely?  They 
say things like:

"When no target is specified, by default the proposed certainty 
applies to its parent element, in this case the placeName 
element. The match attribute discussed below may be used to 
further vary this behaviour."

and

"As previously noted, if no value is supplied for target, the 
context within which the value of match should be evaluated is 
the parent element of the certainty element itself."

It is only on the reference page for att.scoping that it says 
that @match:

"supplies an arbitrary XPath expression identifying a set of 
nodes, selected within the context identified by the target 
attribute if this is supplied, or within the context of the 
element bearing this attribute if it is not."

I would contend that this should just be changed to "or within 
the context of the parent of the element bearing this attribute 
if it is not." (or something even clearer!)

> 2. What is the assumed context of any certainty|precision element in the
> absence of @match (and @target)? The guidelines say current element's
> parent, which I feel is slightly unintuitive alongside the official
> answer to question 1.

I think to say one of these is 'official' and the other isn't is 
a bit misleading. ;-)

> There are then 4 possible solutions to this:

I would vote for b.

-James


>    a. context is always current element, so most @match attributes will
> begin "../", but other possibilities such as match="preceding::lb[1]"
> are possible. This may be the most strictly rational solution, although
> not the most popular, as far as conversation so far indicates. (Plus,
> and more importantly, I bet no one actually uses xsl:evaluate to
> interpret the content of @match as XPath...)
>
>    b. context is always parent of current element, so @match can often be
> omitted, and most examples in the Guidelines showing values such as
> match="@reason" are correct. This is also nice and consistent, if
> slightly more limiting (but in a good way: a certainty element can no
> longer refer to itself), and also convenient for anyone who doesn't want
> to have to evaluate document-source XPath on the fly, but just embed
> certainty|precision inside the qualified element and treat it as an
> "enhanced attribute".
>
>    c. context is current if there is content in @match (and no @target),
> parent if there is not: status quo; examples in guidelines need fixing.
> (Slightly unintuitive?)
>
> [d. context is parent if there is content in @match (and no @target),
> current if not: clearly nonsense.]
>
> There are arguments for and against all of a, b and c. In my opinion b
> is the strongest, for the reasons articulated above (and argued by James
> yesterday), but there may be some value to c, the status quo.
>
> Does this express the options clearly, do you think?



-- 
Dr James Cummings, James.Cummings at it.ox.ac.uk
Academic IT Services, University of Oxford

From mholmes at uvic.ca  Thu Nov 29 08:41:32 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Thu, 29 Nov 2012 05:41:32 -0800
Subject: [tei-council] Examples for certainty|precision @match
In-Reply-To: <50B75A29.3010606@it.ox.ac.uk>
References: <50B3635C.6040106@kcl.ac.uk>	<50B61653.9060000@uvic.ca>
	<50B62E1A.30008@it.ox.ac.uk>	<50B63628.406@uvic.ca>
	<50B63679.5090702@kcl.ac.uk>	<50B646EE.7070703@ultraslavonic.info>
	<50B742CF.200@kcl.ac.uk> <50B75A29.3010606@it.ox.ac.uk>
Message-ID: <50B7660C.3070404@uvic.ca>

> I would vote for b.

+1 from me.

Cheers,
Martin

On 12-11-29 04:50 AM, James Cummings wrote:
> On 29/11/12 11:11, Gabriel Bodard wrote:
>> That rings a bell. :-) So in the absence of @xml:base, the starting
>> point for any xpointer in @target is root. (Which was an aside anyway.)
>>
>> There are two questions re the starting point for xpath in @match:
>>
>> 1. What is the starting point assumed to be for any @match (in the
>> absence of @target)? The guidelines say current element, but some
>> examples in CE seem to assume the element's parent;
>
> The guidelines explicitly say the opposite of this surely?  They
> say things like:
>
> "When no target is specified, by default the proposed certainty
> applies to its parent element, in this case the placeName
> element. The match attribute discussed below may be used to
> further vary this behaviour."
>
> and
>
> "As previously noted, if no value is supplied for target, the
> context within which the value of match should be evaluated is
> the parent element of the certainty element itself."
>
> It is only on the reference page for att.scoping that it says
> that @match:
>
> "supplies an arbitrary XPath expression identifying a set of
> nodes, selected within the context identified by the target
> attribute if this is supplied, or within the context of the
> element bearing this attribute if it is not."
>
> I would contend that this should just be changed to "or within
> the context of the parent of the element bearing this attribute
> if it is not." (or something even clearer!)
>
>> 2. What is the assumed context of any certainty|precision element in the
>> absence of @match (and @target)? The guidelines say current element's
>> parent, which I feel is slightly unintuitive alongside the official
>> answer to question 1.
>
> I think to say one of these is 'official' and the other isn't is
> a bit misleading. ;-)
>
>> There are then 4 possible solutions to this:
>
> I would vote for b.
>
> -James
>
>
>>     a. context is always current element, so most @match attributes will
>> begin "../", but other possibilities such as match="preceding::lb[1]"
>> are possible. This may be the most strictly rational solution, although
>> not the most popular, as far as conversation so far indicates. (Plus,
>> and more importantly, I bet no one actually uses xsl:evaluate to
>> interpret the content of @match as XPath...)
>>
>>     b. context is always parent of current element, so @match can often be
>> omitted, and most examples in the Guidelines showing values such as
>> match="@reason" are correct. This is also nice and consistent, if
>> slightly more limiting (but in a good way: a certainty element can no
>> longer refer to itself), and also convenient for anyone who doesn't want
>> to have to evaluate document-source XPath on the fly, but just embed
>> certainty|precision inside the qualified element and treat it as an
>> "enhanced attribute".
>>
>>     c. context is current if there is content in @match (and no @target),
>> parent if there is not: status quo; examples in guidelines need fixing.
>> (Slightly unintuitive?)
>>
>> [d. context is parent if there is content in @match (and no @target),
>> current if not: clearly nonsense.]
>>
>> There are arguments for and against all of a, b and c. In my opinion b
>> is the strongest, for the reasons articulated above (and argued by James
>> yesterday), but there may be some value to c, the status quo.
>>
>> Does this express the options clearly, do you think?
>
>
>

-- 
Martin Holmes
mholmes at uvic.ca
UVic Humanities Computing and Media Centre

From James.Cummings at it.ox.ac.uk  Thu Nov 29 08:41:40 2012
From: James.Cummings at it.ox.ac.uk (James Cummings)
Date: Thu, 29 Nov 2012 13:41:40 +0000
Subject: [tei-council] TEI Council Teleconference 2012-12-13
Message-ID: <50B76614.6030602@it.ox.ac.uk>


According to the doodle poll at:

http://doodle.com/p7y5qws7kqpc4d3v

Either I have to disappoint Kevin or Lou.  I've checked with 
Becky to ensure that the 'yes, if necessary' wasn't too much of 
an inconvenience - she may just have to leave early/late.

So, mostly because it gives us more time, I'm going to schedule 
the next council meeting for Thursday 13 December at 4pm GMT. 
(Sorry Lou!) Pity it wasn't possible the day before as it would 
be (20)12-12-12. ;-)

Please update the agenda on the wiki if you have things to add to it.

Please also go through outstanding items from:

http://wiki.tei-c.org/index.php/Oxford2012-Actions
http://wiki.tei-c.org/index.php/AnnArbor2012-Actions

And where you have finished items mark them as done, or provide 
an explanation.

See also actions on minutes 
http://www.tei-c.org/Activities/Council/Meetings/index.xml

Teleconference details and finalised agenda will be circulated 
closer to the meeting date.

-James

-- 
Dr James Cummings, James.Cummings at it.ox.ac.uk
Academic IT Services, University of Oxford

From gabriel.bodard at kcl.ac.uk  Thu Nov 29 09:41:06 2012
From: gabriel.bodard at kcl.ac.uk (Gabriel Bodard)
Date: Thu, 29 Nov 2012 14:41:06 +0000
Subject: [tei-council] Examples for certainty|precision @match
In-Reply-To: <50B75A29.3010606@it.ox.ac.uk>
References: <50B3635C.6040106@kcl.ac.uk>
	<50B61653.9060000@uvic.ca>	<50B62E1A.30008@it.ox.ac.uk>
	<50B63628.406@uvic.ca> <50B63679.5090702@kcl.ac.uk>
	<50B646EE.7070703@ultraslavonic.info> <50B742CF.200@kcl.ac.uk>
	<50B75A29.3010606@it.ox.ac.uk>
Message-ID: <50B77402.6030204@kcl.ac.uk>

On 2012-11-29 12:50, James Cummings wrote:
> On 29/11/12 11:11, Gabriel Bodard wrote:
>> 1. What is the starting point assumed to be for any @match (in the
>> absence of @target)? The guidelines say current element, but some
>> examples in CE seem to assume the element's parent;
>
> The guidelines explicitly say the opposite of this surely?  They
> say things like:
>
> "When no target is specified, by default the proposed certainty
> applies to its parent element, in this case the placeName
> element. The match attribute discussed below may be used to
> further vary this behaviour."
> and
> "As previously noted, if no value is supplied for target, the
> context within which the value of match should be evaluated is
> the parent element of the certainty element itself."

I think we're in violent agreement here, just perhaps my formulation 
wasn't clear. As I interpret it, the guidelines (in the classSpec for 
att.scoping) explicitly specify that (1) any XPath in @match should be 
interpreted as starting from the context of the element bearing this 
attribute (this is what I menat by "starting point" above), and (2) that 
in the absence of @match, the object of the certainty|precision 
statement is the parent of the element bearing this attribute.

As I read it, this means that, as written, the following would be 
correct for a certainty statement qualifying a gap element:

<gap><certainty/></gap>

But if you wanted to specify an attribute on gap, then you would need to 
say:

<gap @reason="lost"><certainty match="../@reason"/></gap>

Do I take it that the two people who have voted for b. so far are saying 
they would prefer the first of those to remain correct, but the second 
to become <certainty match="@reason"/> (as *some of* the examples in the 
GL currently offer)?


> It is only on the reference page for att.scoping that it says
> that @match:
>
> "supplies an arbitrary XPath expression identifying a set of
> nodes, selected within the context identified by the target
> attribute if this is supplied, or within the context of the
> element bearing this attribute if it is not."
>
> I would contend that this should just be changed to "or within
> the context of the parent of the element bearing this attribute
> if it is not." (or something even clearer!)
>
>> 2. What is the assumed context of any certainty|precision element in the
>> absence of @match (and @target)? The guidelines say current element's
>> parent, which I feel is slightly unintuitive alongside the official
>> answer to question 1.
>
> I think to say one of these is 'official' and the other isn't is
> a bit misleading. ;-)
>
>> There are then 4 possible solutions to this:
>
> I would vote for b.
>
> -James
>
>
>>     a. context is always current element, so most @match attributes will
>> begin "../", but other possibilities such as match="preceding::lb[1]"
>> are possible. This may be the most strictly rational solution, although
>> not the most popular, as far as conversation so far indicates. (Plus,
>> and more importantly, I bet no one actually uses xsl:evaluate to
>> interpret the content of @match as XPath...)
>>
>>     b. context is always parent of current element, so @match can often be
>> omitted, and most examples in the Guidelines showing values such as
>> match="@reason" are correct. This is also nice and consistent, if
>> slightly more limiting (but in a good way: a certainty element can no
>> longer refer to itself), and also convenient for anyone who doesn't want
>> to have to evaluate document-source XPath on the fly, but just embed
>> certainty|precision inside the qualified element and treat it as an
>> "enhanced attribute".
>>
>>     c. context is current if there is content in @match (and no @target),
>> parent if there is not: status quo; examples in guidelines need fixing.
>> (Slightly unintuitive?)
>>
>> [d. context is parent if there is content in @match (and no @target),
>> current if not: clearly nonsense.]
>>
>> There are arguments for and against all of a, b and c. In my opinion b
>> is the strongest, for the reasons articulated above (and argued by James
>> yesterday), but there may be some value to c, the status quo.
>>
>> Does this express the options clearly, do you think?
>
>
>

-- 
Dr Gabriel BODARD
Researcher in Digital Epigraphy

Digital Humanities
King's College London
26-29 Drury Lane
London WC2B 5RL

T: +44 (0)20 7848 1388
F: +44 (0)20 7848 2980
E: gabriel.bodard at kcl.ac.uk

http://www.digitalclassicist.org/
http://www.currentepigraphy.org/


From mholmes at uvic.ca  Thu Nov 29 11:22:38 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Thu, 29 Nov 2012 08:22:38 -0800
Subject: [tei-council] Examples for certainty|precision @match
In-Reply-To: <50B77402.6030204@kcl.ac.uk>
References: <50B3635C.6040106@kcl.ac.uk>	<50B61653.9060000@uvic.ca>
	<50B62E1A.30008@it.ox.ac.uk>	<50B63628.406@uvic.ca>
	<50B63679.5090702@kcl.ac.uk>	<50B646EE.7070703@ultraslavonic.info>
	<50B742CF.200@kcl.ac.uk>	<50B75A29.3010606@it.ox.ac.uk>
	<50B77402.6030204@kcl.ac.uk>
Message-ID: <50B78BCE.3070004@uvic.ca>

On 12-11-29 06:41 AM, Gabriel Bodard wrote:
> On 2012-11-29 12:50, James Cummings wrote:
>> On 29/11/12 11:11, Gabriel Bodard wrote:
>>> 1. What is the starting point assumed to be for any @match (in the
>>> absence of @target)? The guidelines say current element, but some
>>> examples in CE seem to assume the element's parent;
>>
>> The guidelines explicitly say the opposite of this surely?  They
>> say things like:
>>
>> "When no target is specified, by default the proposed certainty
>> applies to its parent element, in this case the placeName
>> element. The match attribute discussed below may be used to
>> further vary this behaviour."
>> and
>> "As previously noted, if no value is supplied for target, the
>> context within which the value of match should be evaluated is
>> the parent element of the certainty element itself."
>
> I think we're in violent agreement here, just perhaps my formulation
> wasn't clear. As I interpret it, the guidelines (in the classSpec for
> att.scoping) explicitly specify that (1) any XPath in @match should be
> interpreted as starting from the context of the element bearing this
> attribute (this is what I menat by "starting point" above), and (2) that
> in the absence of @match, the object of the certainty|precision
> statement is the parent of the element bearing this attribute.
>
> As I read it, this means that, as written, the following would be
> correct for a certainty statement qualifying a gap element:
>
> <gap><certainty/></gap>
>
> But if you wanted to specify an attribute on gap, then you would need to
> say:
>
> <gap @reason="lost"><certainty match="../@reason"/></gap>
>
> Do I take it that the two people who have voted for b. so far are saying
> they would prefer the first of those to remain correct, but the second
> to become <certainty match="@reason"/> (as *some of* the examples in the
> GL currently offer)?

Yes, that was what I thought I was voting for.

>> It is only on the reference page for att.scoping that it says
>> that @match:
>>
>> "supplies an arbitrary XPath expression identifying a set of
>> nodes, selected within the context identified by the target
>> attribute if this is supplied, or within the context of the
>> element bearing this attribute if it is not."

That looks good to me, assuming the example in att.scoping is also 
changed accordingly -- so:

<gap reason="cancelled">
  <certainty match="parent::tei:gap/@reason" locus="value" cert="low"/>
</gap>

should presumably be:

<gap reason="cancelled">
  <certainty match="@reason" locus="value" cert="low"/>
</gap>

Cheers,
Martin

>> I would contend that this should just be changed to "or within
>> the context of the parent of the element bearing this attribute
>> if it is not." (or something even clearer!)
>>
>>> 2. What is the assumed context of any certainty|precision element in the
>>> absence of @match (and @target)? The guidelines say current element's
>>> parent, which I feel is slightly unintuitive alongside the official
>>> answer to question 1.
>>
>> I think to say one of these is 'official' and the other isn't is
>> a bit misleading. ;-)
>>
>>> There are then 4 possible solutions to this:
>>
>> I would vote for b.
>>
>> -James
>>
>>
>>>      a. context is always current element, so most @match attributes will
>>> begin "../", but other possibilities such as match="preceding::lb[1]"
>>> are possible. This may be the most strictly rational solution, although
>>> not the most popular, as far as conversation so far indicates. (Plus,
>>> and more importantly, I bet no one actually uses xsl:evaluate to
>>> interpret the content of @match as XPath...)
>>>
>>>      b. context is always parent of current element, so @match can often be
>>> omitted, and most examples in the Guidelines showing values such as
>>> match="@reason" are correct. This is also nice and consistent, if
>>> slightly more limiting (but in a good way: a certainty element can no
>>> longer refer to itself), and also convenient for anyone who doesn't want
>>> to have to evaluate document-source XPath on the fly, but just embed
>>> certainty|precision inside the qualified element and treat it as an
>>> "enhanced attribute".
>>>
>>>      c. context is current if there is content in @match (and no @target),
>>> parent if there is not: status quo; examples in guidelines need fixing.
>>> (Slightly unintuitive?)
>>>
>>> [d. context is parent if there is content in @match (and no @target),
>>> current if not: clearly nonsense.]
>>>
>>> There are arguments for and against all of a, b and c. In my opinion b
>>> is the strongest, for the reasons articulated above (and argued by James
>>> yesterday), but there may be some value to c, the status quo.
>>>
>>> Does this express the options clearly, do you think?
>>
>>
>>
>

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From kevin.s.hawkins at ultraslavonic.info  Sun Dec  2 21:51:45 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Sun, 02 Dec 2012 21:51:45 -0500
Subject: [tei-council] Unfinished <quotation> element in example?
In-Reply-To: <50B0D937.7030902@ultraslavonic.info>
References: <50AEAA99.3060801@uvic.ca> <50AF5909.1020705@retired.ox.ac.uk>
	<50AF913E.9030505@ultraslavonic.info>
	<50AF93DC.3040104@it.ox.ac.uk>
	<50B0D937.7030902@ultraslavonic.info>
Message-ID: <50BC13C1.5030303@ultraslavonic.info>

On 11/24/12 9:27 AM, Kevin Hawkins wrote:
> On 11/23/12 10:18 AM, James Cummings wrote:
>>> Should this be a ticket for discussion with a wider community, or should
>>> we just do this?
>>
>> I like to have tickets where possible so we can more easily track
>> something being done (when I help compile release notes ;-) ).
>
> Now at
> https://sourceforge.net/tracker/?func=detail&aid=3589618&group_id=106328&atid=644065
> .

So, any objection to carrying out this ticket in the next couple of 
days?  Jenkins has been broken since November 22, and it would be good 
if we could fix it soon.

I realized this because I committed a revision which caused another 
error that I can't decipher.  I emailed Sebastian and Martin for help, 
but they are probably sleeping and doing something more fun than editing 
the Guidelines, respectively.  If anyone else would like to check out 
the error I caused related to <meeting>, see 
http://bits.nsms.ox.ac.uk:8080/jenkins/job/TEIP5-Test/1299/parsed_console/? 
and http://tei.svn.sourceforge.net/viewvc/tei?view=revision&revision=11196 .

--Kevin

From mholmes at uvic.ca  Sun Dec  2 22:05:22 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Sun, 02 Dec 2012 19:05:22 -0800
Subject: [tei-council] Unfinished <quotation> element in example?
In-Reply-To: <50BC13C1.5030303@ultraslavonic.info>
References: <50AEAA99.3060801@uvic.ca> <50AF5909.1020705@retired.ox.ac.uk>
	<50AF913E.9030505@ultraslavonic.info>	<50AF93DC.3040104@it.ox.ac.uk>
	<50B0D937.7030902@ultraslavonic.info>
	<50BC13C1.5030303@ultraslavonic.info>
Message-ID: <50BC16F2.9050901@uvic.ca>

Hi Kevin,

The UVic Jenkins hasn't been broken since Nov 22; the last successful 
builds were just a few hours ago. I see the Oxford Jinks is down right 
now, but it was sending out emails about builds until a couple of hours 
ago. Sebastian committed a change which seems to have broken the 
Stylesheets build, and then I think your commit which changed monogr.xml 
caused a P5Test build, which failed, but I'm not sure yet whether it was 
your commit that made it fail. The first error seems to relate to an 
empty <quotation> element. I'm not sure quite what's wrong with the P5 
build itself, but generally it's best to fix Test before worrying about 
the downstream builds.

I'll try to figure out what the problem is after dinner.

Cheers,
Martin

On 12-12-02 06:51 PM, Kevin Hawkins wrote:
> On 11/24/12 9:27 AM, Kevin Hawkins wrote:
>> On 11/23/12 10:18 AM, James Cummings wrote:
>>>> Should this be a ticket for discussion with a wider community, or should
>>>> we just do this?
>>>
>>> I like to have tickets where possible so we can more easily track
>>> something being done (when I help compile release notes ;-) ).
>>
>> Now at
>> https://sourceforge.net/tracker/?func=detail&aid=3589618&group_id=106328&atid=644065
>> .
>
> So, any objection to carrying out this ticket in the next couple of
> days?  Jenkins has been broken since November 22, and it would be good
> if we could fix it soon.
>
> I realized this because I committed a revision which caused another
> error that I can't decipher.  I emailed Sebastian and Martin for help,
> but they are probably sleeping and doing something more fun than editing
> the Guidelines, respectively.  If anyone else would like to check out
> the error I caused related to <meeting>, see
> http://bits.nsms.ox.ac.uk:8080/jenkins/job/TEIP5-Test/1299/parsed_console/?
> and http://tei.svn.sourceforge.net/viewvc/tei?view=revision&revision=11196 .
>
> --Kevin
>

-- 
Martin Holmes
mholmes at uvic.ca
UVic Humanities Computing and Media Centre

From mholmes at uvic.ca  Mon Dec  3 00:11:55 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Sun, 02 Dec 2012 21:11:55 -0800
Subject: [tei-council] Unfinished <quotation> element in example?
In-Reply-To: <50BC16F2.9050901@uvic.ca>
References: <50AEAA99.3060801@uvic.ca> <50AF5909.1020705@retired.ox.ac.uk>
	<50AF913E.9030505@ultraslavonic.info>	<50AF93DC.3040104@it.ox.ac.uk>
	<50B0D937.7030902@ultraslavonic.info>	<50BC13C1.5030303@ultraslavonic.info>
	<50BC16F2.9050901@uvic.ca>
Message-ID: <50BC349B.1080805@uvic.ca>

I've fixed the <quotation> problem, but monogr.xml still has 
non-deterministic content model issues. I tried one fix on the first 
bit, but rolled it back when it didn't solve the problem. I'll come back 
to it tomorrow.

Cheers,
Martin

On 12-12-02 07:05 PM, Martin Holmes wrote:
> Hi Kevin,
>
> The UVic Jenkins hasn't been broken since Nov 22; the last successful
> builds were just a few hours ago. I see the Oxford Jinks is down right
> now, but it was sending out emails about builds until a couple of hours
> ago. Sebastian committed a change which seems to have broken the
> Stylesheets build, and then I think your commit which changed monogr.xml
> caused a P5Test build, which failed, but I'm not sure yet whether it was
> your commit that made it fail. The first error seems to relate to an
> empty <quotation> element. I'm not sure quite what's wrong with the P5
> build itself, but generally it's best to fix Test before worrying about
> the downstream builds.
>
> I'll try to figure out what the problem is after dinner.
>
> Cheers,
> Martin
>
> On 12-12-02 06:51 PM, Kevin Hawkins wrote:
>> On 11/24/12 9:27 AM, Kevin Hawkins wrote:
>>> On 11/23/12 10:18 AM, James Cummings wrote:
>>>>> Should this be a ticket for discussion with a wider community, or should
>>>>> we just do this?
>>>>
>>>> I like to have tickets where possible so we can more easily track
>>>> something being done (when I help compile release notes ;-) ).
>>>
>>> Now at
>>> https://sourceforge.net/tracker/?func=detail&aid=3589618&group_id=106328&atid=644065
>>> .
>>
>> So, any objection to carrying out this ticket in the next couple of
>> days?  Jenkins has been broken since November 22, and it would be good
>> if we could fix it soon.
>>
>> I realized this because I committed a revision which caused another
>> error that I can't decipher.  I emailed Sebastian and Martin for help,
>> but they are probably sleeping and doing something more fun than editing
>> the Guidelines, respectively.  If anyone else would like to check out
>> the error I caused related to <meeting>, see
>> http://bits.nsms.ox.ac.uk:8080/jenkins/job/TEIP5-Test/1299/parsed_console/?
>> and http://tei.svn.sourceforge.net/viewvc/tei?view=revision&revision=11196 .
>>
>> --Kevin
>>
>

-- 
Martin Holmes
mholmes at uvic.ca
UVic Humanities Computing and Media Centre

From lou.burnard at retired.ox.ac.uk  Mon Dec  3 05:06:46 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Mon, 03 Dec 2012 10:06:46 +0000
Subject: [tei-council] meeting problem
In-Reply-To: <50BC13C1.5030303@ultraslavonic.info>
References: <50AEAA99.3060801@uvic.ca> <50AF5909.1020705@retired.ox.ac.uk>
	<50AF913E.9030505@ultraslavonic.info>
	<50AF93DC.3040104@it.ox.ac.uk>
	<50B0D937.7030902@ultraslavonic.info>
	<50BC13C1.5030303@ultraslavonic.info>
Message-ID: <50BC79B6.4000201@retired.ox.ac.uk>

On 03/12/12 02:51, Kevin Hawkins wrote:
> I realized this because I committed a revision which caused another 
> error that I can't decipher. I emailed Sebastian and Martin for help, 
> but they are probably sleeping and doing something more fun than 
> editing the Guidelines, respectively. If anyone else would like to 
> check out the error I caused related to <meeting>, see 
> http://bits.nsms.ox.ac.uk:8080/jenkins/job/TEIP5-Test/1299/parsed_console/? 
> and 
> http://tei.svn.sourceforge.net/viewvc/tei?view=revision&revision=11196 
> . --Kevin 

You can't have an optional occurrence of meeting followed by another 
optional occurrence of meeting. Which one is a poor non-looking-ahead 
parser supposed to believe?

Why are you adding <meeting> into all those models as a sibling of 
respStmt anyway? Can a meeting take intellectual responsibillity for a 
monographic work? Apologies if this was discussed already (as I assume 
it must have been) but this just seems wrong to me.

I have very flaky internet right now so I havent been able to check out 
the ticket -- so further apologies if there is a knockdown argument in  
favour of the change therein!

From lou.burnard at retired.ox.ac.uk  Mon Dec  3 05:19:17 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Mon, 03 Dec 2012 10:19:17 +0000
Subject: [tei-council] meeting problem
In-Reply-To: <50BC79B6.4000201@retired.ox.ac.uk>
References: <50AEAA99.3060801@uvic.ca> <50AF5909.1020705@retired.ox.ac.uk>
	<50AF913E.9030505@ultraslavonic.info>
	<50AF93DC.3040104@it.ox.ac.uk>
	<50B0D937.7030902@ultraslavonic.info>
	<50BC13C1.5030303@ultraslavonic.info>
	<50BC79B6.4000201@retired.ox.ac.uk>
Message-ID: <50BC7CA5.7040600@retired.ox.ac.uk>

On 03/12/12 10:06, Lou Burnard wrote:
> On 03/12/12 02:51, Kevin Hawkins wrote:
>> I realized this because I committed a revision which caused another
>> error that I can't decipher. I emailed Sebastian and Martin for help,
>> but they are probably sleeping and doing something more fun than
>> editing the Guidelines, respectively. If anyone else would like to
>> check out the error I caused related to <meeting>, see
>> http://bits.nsms.ox.ac.uk:8080/jenkins/job/TEIP5-Test/1299/parsed_console/?
>> and
>> http://tei.svn.sourceforge.net/viewvc/tei?view=revision&revision=11196
>> . --Kevin
> You can't have an optional occurrence of meeting followed by another
> optional occurrence of meeting. Which one is a poor non-looking-ahead
> parser supposed to believe?
>
> Why are you adding <meeting> into all those models as a sibling of
> respStmt anyway? Can a meeting take intellectual responsibillity for a
> monographic work? Apologies if this was discussed already (as I assume
> it must have been) but this just seems wrong to me.
>
> I have very flaky internet right now so I havent been able to check out
> the ticket -- so further apologies if there is a knockdown argument in
> favour of the change therein!
Have now re-read the ticket I see that some character with my name 
suggests that a <meeting> might indeed be considered to have 
intellectual responsibility for e.g. its minutes. So if we believe that 
idiot, the answer is to remove the occurrence of <meeting> from the 
content model where it is given as an alternate for <note>.


From lou.burnard at retired.ox.ac.uk  Mon Dec  3 05:21:03 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Mon, 03 Dec 2012 10:21:03 +0000
Subject: [tei-council] meeting problem
In-Reply-To: <50BC7CA5.7040600@retired.ox.ac.uk>
References: <50AEAA99.3060801@uvic.ca> <50AF5909.1020705@retired.ox.ac.uk>
	<50AF913E.9030505@ultraslavonic.info>
	<50AF93DC.3040104@it.ox.ac.uk>
	<50B0D937.7030902@ultraslavonic.info>
	<50BC13C1.5030303@ultraslavonic.info>
	<50BC79B6.4000201@retired.ox.ac.uk>
	<50BC7CA5.7040600@retired.ox.ac.uk>
Message-ID: <50BC7D0F.1040907@retired.ox.ac.uk>

On 03/12/12 10:19, Lou Burnard wrote:
> On 03/12/12 10:06, Lou Burnard wrote:
> the answer is to remove the occurrence of <meeting> from the content 
> model where it is given as an alternate for <note>. 

... which I see Sebastian has just done.



From sebastian.rahtz at it.ox.ac.uk  Mon Dec  3 05:24:20 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Mon, 3 Dec 2012 10:24:20 +0000
Subject: [tei-council] meeting problem
In-Reply-To: <50BC79B6.4000201@retired.ox.ac.uk>
References: <50AEAA99.3060801@uvic.ca> <50AF5909.1020705@retired.ox.ac.uk>
	<50AF913E.9030505@ultraslavonic.info> <50AF93DC.3040104@it.ox.ac.uk>
	<50B0D937.7030902@ultraslavonic.info>
	<50BC13C1.5030303@ultraslavonic.info>
	<50BC79B6.4000201@retired.ox.ac.uk>
Message-ID: <b6d59758-a6b9-49f2-bff2-f0cb50077fa0@HUB03.ad.oak.ox.ac.uk>


On 3 Dec 2012, at 10:06, Lou Burnard <lou.burnard at retired.ox.ac.uk> wrote:

> 
> You can't have an optional occurrence of meeting followed by another 
> optional occurrence of meeting. Which one is a poor non-looking-ahead 
> parser supposed to believe?
indeed. the problem is that meeting is now occurring as a sibling of
<author> _and_ as a sibling of <note> later on. Since everything in
<monogr> is optional, this will always cause a non-determinism error.

I have dealt with the error by removing the option of <meeting> occurring
interleaved with <note>. We cant have it both ways.

obviously this is trivial to undo if I jumped the the wrong way

that manual content model of <monogr> is truly evil, by the way. But
i feel too ill to attempt an alternative simplification.
--
Sebastian Rahtz      
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431


From kevin.s.hawkins at ultraslavonic.info  Mon Dec  3 09:50:21 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Mon, 03 Dec 2012 09:50:21 -0500
Subject: [tei-council] meeting problem
In-Reply-To: <50BC7D0F.1040907@retired.ox.ac.uk>
References: <50AEAA99.3060801@uvic.ca> <50AF5909.1020705@retired.ox.ac.uk>
	<50AF913E.9030505@ultraslavonic.info>
	<50AF93DC.3040104@it.ox.ac.uk>
	<50B0D937.7030902@ultraslavonic.info>
	<50BC13C1.5030303@ultraslavonic.info>
	<50BC79B6.4000201@retired.ox.ac.uk>
	<50BC7CA5.7040600@retired.ox.ac.uk>
	<50BC7D0F.1040907@retired.ox.ac.uk>
Message-ID: <50BCBC2D.30402@ultraslavonic.info>

On 12/3/12 5:21 AM, Lou Burnard wrote:
> On 03/12/12 10:19, Lou Burnard wrote:
>> On 03/12/12 10:06, Lou Burnard wrote:
>> the answer is to remove the occurrence of <meeting> from the content
>> model where it is given as an alternate for <note>.
>
> ... which I see Sebastian has just done.

The problem with doing this is that it invalidates:

<biblStruct>
  <monogr>
   <title>Proceedings of a workshop on corpus resources</title>
   <respStmt>
    <resp>Programme Organizer</resp>
    <name>Geoffrey Leech</name>
   </respStmt>
   <meeting>DTI Speech and Language Technology Club meeting, 3-4
      January 1990, Wadham College, Oxford</meeting>
   <imprint>
    <pubPlace>Oxford</pubPlace>
   </imprint>
  </monogr>
</biblStruct>

which is given at the end of section 3.11.2.2 
(http://www.tei-c.org/release/doc/tei-p5-doc/en/html/CO.html#COBICOR). 
In this example, the work emanates from Geoffrey Leech and yet the 
<meeting> is included as well.

If we continue to allow this, I suggest that I simply remove <meeting> 
from the content model in the *other* places I added it but add it back 
here.  For this ticket, I was just trying to complete the content model 
of <monogr> to be internally consistent in the TEI.  We weren't 
responding to any request from someone trying to use <monogr> with 
<meeting>.

--Kevin

From kevin.s.hawkins at ultraslavonic.info  Mon Dec  3 09:57:01 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Mon, 03 Dec 2012 09:57:01 -0500
Subject: [tei-council] meeting problem
In-Reply-To: <50BCBC2D.30402@ultraslavonic.info>
References: <50AEAA99.3060801@uvic.ca> <50AF5909.1020705@retired.ox.ac.uk>
	<50AF913E.9030505@ultraslavonic.info>
	<50AF93DC.3040104@it.ox.ac.uk>
	<50B0D937.7030902@ultraslavonic.info>
	<50BC13C1.5030303@ultraslavonic.info>
	<50BC79B6.4000201@retired.ox.ac.uk>
	<50BC7CA5.7040600@retired.ox.ac.uk>
	<50BC7D0F.1040907@retired.ox.ac.uk>
	<50BCBC2D.30402@ultraslavonic.info>
Message-ID: <50BCBDBD.8040301@ultraslavonic.info>

Oh wait ... it actually doesn't invalidate that since we now have 
meeting earlier in the content model.  So now I think Sebastian's fix is 
the best way out.

On 12/3/12 9:50 AM, Kevin Hawkins wrote:
> On 12/3/12 5:21 AM, Lou Burnard wrote:
>> On 03/12/12 10:19, Lou Burnard wrote:
>>> On 03/12/12 10:06, Lou Burnard wrote:
>>> the answer is to remove the occurrence of <meeting> from the content
>>> model where it is given as an alternate for <note>.
>>
>> ... which I see Sebastian has just done.
>
> The problem with doing this is that it invalidates:
>
> <biblStruct>
>   <monogr>
>    <title>Proceedings of a workshop on corpus resources</title>
>    <respStmt>
>     <resp>Programme Organizer</resp>
>     <name>Geoffrey Leech</name>
>    </respStmt>
>    <meeting>DTI Speech and Language Technology Club meeting, 3-4
>       January 1990, Wadham College, Oxford</meeting>
>    <imprint>
>     <pubPlace>Oxford</pubPlace>
>    </imprint>
>   </monogr>
> </biblStruct>
>
> which is given at the end of section 3.11.2.2
> (http://www.tei-c.org/release/doc/tei-p5-doc/en/html/CO.html#COBICOR).
> In this example, the work emanates from Geoffrey Leech and yet the
> <meeting> is included as well.
>
> If we continue to allow this, I suggest that I simply remove <meeting>
> from the content model in the *other* places I added it but add it back
> here.  For this ticket, I was just trying to complete the content model
> of <monogr> to be internally consistent in the TEI.  We weren't
> responding to any request from someone trying to use <monogr> with
> <meeting>.
>
> --Kevin

From sebastian.rahtz at it.ox.ac.uk  Mon Dec  3 09:59:37 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Mon, 3 Dec 2012 14:59:37 +0000
Subject: [tei-council] meeting problem
In-Reply-To: <50BCBC2D.30402@ultraslavonic.info>
References: <50AEAA99.3060801@uvic.ca> <50AF5909.1020705@retired.ox.ac.uk>
	<50AF913E.9030505@ultraslavonic.info> <50AF93DC.3040104@it.ox.ac.uk>
	<50B0D937.7030902@ultraslavonic.info>
	<50BC13C1.5030303@ultraslavonic.info>
	<50BC79B6.4000201@retired.ox.ac.uk> <50BC7CA5.7040600@retired.ox.ac.uk>
	<50BC7D0F.1040907@retired.ox.ac.uk> <50BCBC2D.30402@ultraslavonic.info>
Message-ID: <AEBD65A7-4555-43FC-9E0F-EEA5780EC199@it.ox.ac.uk>


On 3 Dec 2012, at 14:50, Kevin Hawkins <kevin.s.hawkins at ultraslavonic.info> wrote:

> The problem with doing this is that it invalidates:
> 
> <biblStruct>
>  <monogr>
>   <title>Proceedings of a workshop on corpus resources</title>
>   <respStmt>
>    <resp>Programme Organizer</resp>
>    <name>Geoffrey Leech</name>
>   </respStmt>
>   <meeting>DTI Speech and Language Technology Club meeting, 3-4
>      January 1990, Wadham College, Oxford</meeting>
>   <imprint>
>    <pubPlace>Oxford</pubPlace>
>   </imprint>
>  </monogr>
> </biblStruct>
> 
> which is given at the end of section 3.11.2.2 
> (http://www.tei-c.org/release/doc/tei-p5-doc/en/html/CO.html#COBICOR). 
> 

eh? thats perfectly valid according to the new schema. the tests would not
have passed otherwise.

--
Sebastian Rahtz      
http://www.justgiving.com/SebastianRahtz
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431


From James.Cummings at it.ox.ac.uk  Wed Dec  5 11:45:22 2012
From: James.Cummings at it.ox.ac.uk (James Cummings)
Date: Wed, 05 Dec 2012 16:45:22 +0000
Subject: [tei-council] Upgrading TEI Project on SF
Message-ID: <50BF7A22.7060401@it.ox.ac.uk>


Hi all,

SourceForge seems to be recommending people upgrade their project 
to their new Allura platform.  However, this gives some 
unintended side effects, like it will break all currently checked 
out versions of the SVN repository, and all our URLs will change 
(I'll have to change where those handy PURLs go, but at least 
they should still work, old full URLs might not).

We will have to do this *sometime* the question I guess I have 
for you is when is the right time to do this?

Sebastian will say that we should use this as an opportunity to 
move any non-Guidelines community contributed but TEIC owned 
software to our shiny new github account at 
https://github.com/organizations/TEIC which is another 
discussion.  (e.g. should things like Byzantium and 
odd-by-example move there)


Thoughts?

Info from Sourceforge below.

-James

=====

Upgrading your project to the Allura platform gives you access to 
some great new features, including custom tracker fields, 
integrated wiki, blog and code browsing tools, threaded 
discussions, and more! Here are changes you can expect to see 
when you upgrade your project:

Will be upgraded
At this time, we are able to update the following aspects of your 
project:
Meta-data (name, description, trove categories, etc)
Members and permissions
Project News
Forums
Hosted Applications and Project Web
Virtual Host configuration and MySQL databases
Git, Subversion, Mercurial, Bazaar and CVS repositories
Mailing Lists
Tracker data
Project Donations*

Will not be upgraded
These items will not be moved to your upgraded project:
Project Help Wanted
SCM stats, Forum stats, Ticket stats & Traffic stats
Trac will no longer integrate with SVN

Will work exactly the same
These items will continue to function they way they currently do:
Project summary page
File releases and download stats
Project Reviews

Note that the URLs used to access your code repositories will 
change, and an email will be sent to all project developers with 
the new URLs after the upgrade is complete.

Once you click Upgrade, the upgrade will be scheduled and will 
begin shortly. Any changes made to your project while the upgrade 
is in progress may not be reflected in the upgraded project.

Prior to upgrading, you can obtain a copy of your project's data 
as an XML file by clicking on the project name, selecting Project 
Admin ? Features, then selecting XML Export.


-- 
Dr James Cummings, James.Cummings at it.ox.ac.uk
Academic IT Services, University of Oxford

From dsewell at virginia.edu  Wed Dec  5 11:58:36 2012
From: dsewell at virginia.edu (David Sewell)
Date: Wed, 5 Dec 2012 11:58:36 -0500 (EST)
Subject: [tei-council] Upgrading TEI Project on SF
In-Reply-To: <50BF7A22.7060401@it.ox.ac.uk>
References: <50BF7A22.7060401@it.ox.ac.uk>
Message-ID: <alpine.OSX.2.00.1212051154280.1891@lister.ei.virginia.edu>

It would seem that the most important thing would be to contact everyone who has 
write privileges on TEI-SF and ask whether anyone is in the middle of major 
changes to code/Guidelines. If not, set a deadline for committing any 
uncommitted changes to SVN, and then institute a code freeze while migrating the 
repository. After which everyone would presumably have to check out a new copy 
or copies of source.

David

On Wed, 5 Dec 2012, James Cummings wrote:

>
> Hi all,
>
> SourceForge seems to be recommending people upgrade their project
> to their new Allura platform.  However, this gives some
> unintended side effects, like it will break all currently checked
> out versions of the SVN repository, and all our URLs will change
> (I'll have to change where those handy PURLs go, but at least
> they should still work, old full URLs might not).
>
> We will have to do this *sometime* the question I guess I have
> for you is when is the right time to do this?
>
> Sebastian will say that we should use this as an opportunity to
> move any non-Guidelines community contributed but TEIC owned
> software to our shiny new github account at
> https://github.com/organizations/TEIC which is another
> discussion.  (e.g. should things like Byzantium and
> odd-by-example move there)
>
>
> Thoughts?
>
> Info from Sourceforge below.
>
> -James
>
> =====
>
> Upgrading your project to the Allura platform gives you access to
> some great new features, including custom tracker fields,
> integrated wiki, blog and code browsing tools, threaded
> discussions, and more! Here are changes you can expect to see
> when you upgrade your project:
>
> Will be upgraded
> At this time, we are able to update the following aspects of your
> project:
> Meta-data (name, description, trove categories, etc)
> Members and permissions
> Project News
> Forums
> Hosted Applications and Project Web
> Virtual Host configuration and MySQL databases
> Git, Subversion, Mercurial, Bazaar and CVS repositories
> Mailing Lists
> Tracker data
> Project Donations*
>
> Will not be upgraded
> These items will not be moved to your upgraded project:
> Project Help Wanted
> SCM stats, Forum stats, Ticket stats & Traffic stats
> Trac will no longer integrate with SVN
>
> Will work exactly the same
> These items will continue to function they way they currently do:
> Project summary page
> File releases and download stats
> Project Reviews
>
> Note that the URLs used to access your code repositories will
> change, and an email will be sent to all project developers with
> the new URLs after the upgrade is complete.
>
> Once you click Upgrade, the upgrade will be scheduled and will
> begin shortly. Any changes made to your project while the upgrade
> is in progress may not be reflected in the upgraded project.
>
> Prior to upgrading, you can obtain a copy of your project's data
> as an XML file by clicking on the project name, selecting Project
> Admin ? Features, then selecting XML Export.
>
>
>

-- 
David Sewell, Editorial and Technical Manager
ROTUNDA, The University of Virginia Press
PO Box 400314, Charlottesville, VA 22904-4314 USA
Email: dsewell at virginia.edu   Tel: +1 434 924 9973
Web: http://rotunda.upress.virginia.edu/

From gabriel.bodard at kcl.ac.uk  Wed Dec  5 12:00:43 2012
From: gabriel.bodard at kcl.ac.uk (Gabriel Bodard)
Date: Wed, 5 Dec 2012 17:00:43 +0000
Subject: [tei-council] Upgrading TEI Project on SF
In-Reply-To: <alpine.OSX.2.00.1212051154280.1891@lister.ei.virginia.edu>
References: <50BF7A22.7060401@it.ox.ac.uk>
	<alpine.OSX.2.00.1212051154280.1891@lister.ei.virginia.edu>
Message-ID: <50BF7DBB.20809@kcl.ac.uk>

That is true. The biggest deal, though, is making sure that all 
checkouts of the repo (e.g. in the various Jenkinses), including 
externals and other dependencies, are updated as soon as possible after 
the migration, because there will be major breakage everywhere until 
that happens.

On 2012-12-05 16:58, David Sewell wrote:
> It would seem that the most important thing would be to contact everyone
> who has write privileges on TEI-SF and ask whether anyone is in the
> middle of major changes to code/Guidelines. If not, set a deadline for
> committing any uncommitted changes to SVN, and then institute a code
> freeze while migrating the repository. After which everyone would
> presumably have to check out a new copy or copies of source.
>
> David
>
> On Wed, 5 Dec 2012, James Cummings wrote:
>
>>
>> Hi all,
>>
>> SourceForge seems to be recommending people upgrade their project
>> to their new Allura platform.  However, this gives some
>> unintended side effects, like it will break all currently checked
>> out versions of the SVN repository, and all our URLs will change
>> (I'll have to change where those handy PURLs go, but at least
>> they should still work, old full URLs might not).
>>
>> We will have to do this *sometime* the question I guess I have
>> for you is when is the right time to do this?
>>
>> Sebastian will say that we should use this as an opportunity to
>> move any non-Guidelines community contributed but TEIC owned
>> software to our shiny new github account at
>> https://github.com/organizations/TEIC which is another
>> discussion.  (e.g. should things like Byzantium and
>> odd-by-example move there)
>>
>>
>> Thoughts?
>>
>> Info from Sourceforge below.
>>
>> -James
>>
>> =====
>>
>> Upgrading your project to the Allura platform gives you access to
>> some great new features, including custom tracker fields,
>> integrated wiki, blog and code browsing tools, threaded
>> discussions, and more! Here are changes you can expect to see
>> when you upgrade your project:
>>
>> Will be upgraded
>> At this time, we are able to update the following aspects of your
>> project:
>> Meta-data (name, description, trove categories, etc)
>> Members and permissions
>> Project News
>> Forums
>> Hosted Applications and Project Web
>> Virtual Host configuration and MySQL databases
>> Git, Subversion, Mercurial, Bazaar and CVS repositories
>> Mailing Lists
>> Tracker data
>> Project Donations*
>>
>> Will not be upgraded
>> These items will not be moved to your upgraded project:
>> Project Help Wanted
>> SCM stats, Forum stats, Ticket stats & Traffic stats
>> Trac will no longer integrate with SVN
>>
>> Will work exactly the same
>> These items will continue to function they way they currently do:
>> Project summary page
>> File releases and download stats
>> Project Reviews
>>
>> Note that the URLs used to access your code repositories will
>> change, and an email will be sent to all project developers with
>> the new URLs after the upgrade is complete.
>>
>> Once you click Upgrade, the upgrade will be scheduled and will
>> begin shortly. Any changes made to your project while the upgrade
>> is in progress may not be reflected in the upgraded project.
>>
>> Prior to upgrading, you can obtain a copy of your project's data
>> as an XML file by clicking on the project name, selecting Project
>> Admin ? Features, then selecting XML Export.
>>
>>
>>
>
>
>

-- 
Dr Gabriel BODARD
Researcher in Digital Epigraphy

Digital Humanities
King's College London
26-29 Drury Lane
London WC2B 5RL

T: +44 (0)20 7848 1388
F: +44 (0)20 7848 2980
E: gabriel.bodard at kcl.ac.uk

http://www.digitalclassicist.org/
http://www.currentepigraphy.org/


From kevin.s.hawkins at ultraslavonic.info  Wed Dec  5 12:02:13 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Wed, 05 Dec 2012 12:02:13 -0500
Subject: [tei-council] Upgrading TEI Project on SF
In-Reply-To: <50BF7A22.7060401@it.ox.ac.uk>
References: <50BF7A22.7060401@it.ox.ac.uk>
Message-ID: <50BF7E15.4000008@ultraslavonic.info>

On 12/5/2012 11:45 AM, James Cummings wrote:
>
> Hi all,
>
> SourceForge seems to be recommending people upgrade their project
> to their new Allura platform.  However, this gives some
> unintended side effects, like it will break all currently checked
> out versions of the SVN repository, and all our URLs will change
> (I'll have to change where those handy PURLs go, but at least
> they should still work, old full URLs might not).
>
> We will have to do this *sometime* the question I guess I have
> for you is when is the right time to do this?'

For the change in read/write access to the version control repository, 
we'll need to update tutorials on www.tei-c.org, the various tcw 
documents relating to updating the Guidelines and making releases, and 
publicize in the community for those who download releases through SVN.

Before we move, I would like to have a script that will take a text file 
(XML or MediaWiki markup) as input and which will substitute each SF URL 
for the equivalent PURL.  I can update all wiki.tei-c.org and 
www.tei-c.org pages affected.

This will make it easier for people digging through old Council minutes 
and other wiki discussions to make sense of what was being discussed (by 
referring to the associated SF tickets).

I'll start a Google Docs file of things that need to happen and share 
with you all.

> Sebastian will say that we should use this as an opportunity to
> move any non-Guidelines community contributed but TEIC owned
> software to our shiny new github account at
> https://github.com/organizations/TEIC which is another
> discussion.  (e.g. should things like Byzantium and
> odd-by-example move there)

Yes, we keep talking disentangling official TEI-C content and other 
things that Sebastian has worked on over the years, moving the latter 
somewhere else.  This should happen in any case, but I guess Sebastian's 
point is that this forces our hand to actually go ahead.

While we're going to discuss which category Byzantium falls into during 
our call next week, are there any other unclear cases?

From kevin.s.hawkins at ultraslavonic.info  Wed Dec  5 12:17:56 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Wed, 05 Dec 2012 12:17:56 -0500
Subject: [tei-council] Upgrading TEI Project on SF
In-Reply-To: <50BF7E15.4000008@ultraslavonic.info>
References: <50BF7A22.7060401@it.ox.ac.uk>
	<50BF7E15.4000008@ultraslavonic.info>
Message-ID: <50BF81C4.5070804@ultraslavonic.info>

I've just shared the promised document with one of the email addresses I 
have on file for each of you that I now of to be on this list. 
Obviously if you'd like the document shared with another account, please 
let me know.

On 12/5/2012 12:02 PM, Kevin Hawkins wrote:
> I'll start a Google Docs file of things that need to happen and share
> with you all.

From mholmes at uvic.ca  Wed Dec  5 12:23:11 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Wed, 5 Dec 2012 09:23:11 -0800
Subject: [tei-council] Upgrading TEI Project on SF
In-Reply-To: <50BF7A22.7060401@it.ox.ac.uk>
References: <50BF7A22.7060401@it.ox.ac.uk>
Message-ID: <50BF82FF.3030804@uvic.ca>

What an absolute pain this will be. I think we need to schedule it for a 
period immediately following a release, to give us maximum time to get 
everything working. I guess that means it should really be right now, 
because the next release is likely to be in April/May, and June/July is 
conference and workshop season, when everyone will be really busy.

Another reason for moving soon is that the new members of Council who 
aren't yet familiar with the system will only have to learn the setup once.

If we also move things like oddbyexample, there will be more 
complication -- oddbyexample, for instance, is called during the 
Stylesheets build process, so if it's moved, the Stylesheets Makefile 
will have to be changed, or the build job will have to check it out from 
wherever it ends up. I think it would be simpler to move the whole 
shebang as-is, and treat the separation of extra bits and pieces as a 
separate task to be undertaken when we have everything working again.

Does SF have a deadline by which we need to move?

They seem to suggest that SCM stats will not be available in the new 
system. Does this matter to us?

Cheers,
Martin

On 12-12-05 08:45 AM, James Cummings wrote:
>
> Hi all,
>
> SourceForge seems to be recommending people upgrade their project
> to their new Allura platform.  However, this gives some
> unintended side effects, like it will break all currently checked
> out versions of the SVN repository, and all our URLs will change
> (I'll have to change where those handy PURLs go, but at least
> they should still work, old full URLs might not).
>
> We will have to do this *sometime* the question I guess I have
> for you is when is the right time to do this?
>
> Sebastian will say that we should use this as an opportunity to
> move any non-Guidelines community contributed but TEIC owned
> software to our shiny new github account at
> https://github.com/organizations/TEIC which is another
> discussion.  (e.g. should things like Byzantium and
> odd-by-example move there)
>
>
> Thoughts?
>
> Info from Sourceforge below.
>
> -James
>
> =====
>
> Upgrading your project to the Allura platform gives you access to
> some great new features, including custom tracker fields,
> integrated wiki, blog and code browsing tools, threaded
> discussions, and more! Here are changes you can expect to see
> when you upgrade your project:
>
> Will be upgraded
> At this time, we are able to update the following aspects of your
> project:
> Meta-data (name, description, trove categories, etc)
> Members and permissions
> Project News
> Forums
> Hosted Applications and Project Web
> Virtual Host configuration and MySQL databases
> Git, Subversion, Mercurial, Bazaar and CVS repositories
> Mailing Lists
> Tracker data
> Project Donations*
>
> Will not be upgraded
> These items will not be moved to your upgraded project:
> Project Help Wanted
> SCM stats, Forum stats, Ticket stats & Traffic stats
> Trac will no longer integrate with SVN
>
> Will work exactly the same
> These items will continue to function they way they currently do:
> Project summary page
> File releases and download stats
> Project Reviews
>
> Note that the URLs used to access your code repositories will
> change, and an email will be sent to all project developers with
> the new URLs after the upgrade is complete.
>
> Once you click Upgrade, the upgrade will be scheduled and will
> begin shortly. Any changes made to your project while the upgrade
> is in progress may not be reflected in the upgraded project.
>
> Prior to upgrading, you can obtain a copy of your project's data
> as an XML file by clicking on the project name, selecting Project
> Admin ? Features, then selecting XML Export.
>
>

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From James.Cummings at it.ox.ac.uk  Wed Dec  5 12:29:43 2012
From: James.Cummings at it.ox.ac.uk (James Cummings)
Date: Wed, 05 Dec 2012 17:29:43 +0000
Subject: [tei-council] Upgrading TEI Project on SF
In-Reply-To: <50BF82FF.3030804@uvic.ca>
References: <50BF7A22.7060401@it.ox.ac.uk> <50BF82FF.3030804@uvic.ca>
Message-ID: <50BF8487.6020103@it.ox.ac.uk>

On 05/12/12 17:23, Martin Holmes wrote:
> What an absolute pain this will be. I think we need to schedule it for a
> period immediately following a release, to give us maximum time to get
> everything working. I guess that means it should really be right now,
> because the next release is likely to be in April/May, and June/July is
> conference and workshop season, when everyone will be really busy.

I've been assuming that we'll probably do a maintenance release 
in January to solve some of the problems people have pointed out, 
but we've not timetabled anything as of yet.  (adding to 
teleconference agenda now)

> Another reason for moving soon is that the new members of Council who
> aren't yet familiar with the system will only have to learn the setup once.

That is true, but I think they can cope. ;-)

> If we also move things like oddbyexample, there will be more
> complication -- oddbyexample, for instance, is called during the
> Stylesheets build process, so if it's moved, the Stylesheets Makefile
> will have to be changed, or the build job will have to check it out from
> wherever it ends up. I think it would be simpler to move the whole
> shebang as-is, and treat the separation of extra bits and pieces as a
> separate task to be undertaken when we have everything working again.

That is why hiving those off to a different repository seems a 
separate thing to me than upgrading to the new sourceforge platform

> Does SF have a deadline by which we need to move?

Not that I've seen so far.

> They seem to suggest that SCM stats will not be available in the new
> system. Does this matter to us?

I've not used them.


-James

-- 
Dr James Cummings, James.Cummings at it.ox.ac.uk
Academic IT Services, University of Oxford

From lou.burnard at retired.ox.ac.uk  Wed Dec  5 13:19:52 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Wed, 05 Dec 2012 18:19:52 +0000
Subject: [tei-council] Upgrading TEI Project on SF
In-Reply-To: <50BF7A22.7060401@it.ox.ac.uk>
References: <50BF7A22.7060401@it.ox.ac.uk>
Message-ID: <50BF9048.7050505@retired.ox.ac.uk>

On 05/12/12 16:45, James Cummings wrote:
>
> SourceForge seems to be recommending people upgrade their project
> to their new Allura platform.  However, this gives some
> unintended side effects, like it will break all currently checked
> out versions of the SVN repository, and all our URLs will change
> (I'll have to change where those handy PURLs go, but at least
> they should still work, old full URLs might not).

"all our urls" meaning what exactly? Internally in the Guidelines we 
dont refer to anything sf specific, so those links clearly won't break.  
In what sense will all currently checked out versions of the repo break? 
They will remain internally consistent, so you cant mean that. 
Presumably you mean that they won't automatically get in touch with the 
new allura-svn repo, but who would expect them  to?


> We will have to do this *sometime* the question I guess I have
> for you is when is the right time to do this?

tout de suite, and the tooter the sweeter

> Sebastian will say that we should use this as an opportunity to
> move any non-Guidelines community contributed but TEIC owned
> software to our shiny new github account at
> https://github.com/organizations/TEIC which is another
> discussion.  (e.g. should things like Byzantium and
> odd-by-example move there)
>

totally another discussion



From kevin.s.hawkins at ultraslavonic.info  Wed Dec  5 22:28:09 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Wed, 05 Dec 2012 22:28:09 -0500
Subject: [tei-council] $Date: and $Id:
Message-ID: <50C010C9.1040805@ultraslavonic.info>

Every file in Guidelines/ and Specs/ contains at the top:

<!--
Copyright TEI Consortium.
Dual-licensed under CC-by and BSD2 licences
See the file COPYING.txt for details.

which is followed by lines beginning:

$Date:
$Id:

after which there is machine-generated information about the last time 
the file is touched.  I understand that this is automatically by a 
properly configured text editor of some sort.  (I've gone looking for 
information on this in the past out of my own curiosity but have been 
unable to find anything since searching on these terms turns up just 
sourcecode and webpages that were edited using such an editor.  Your 
leads appreciated.)

As far as I can tell, 
http://www.tei-c.org/Activities/Council/Working/tcw20.xml doesn't say 
require that we use a particular editor configuration that will update 
this information when editing an existing file.  I certainly haven't 
ever touched it, so I suppose that when I make an edit, the info listed 
here is inaccurate until someone with such a configuration edits the 
file.  And I suppose that's okay since no one has ever complained or 
suggested we add it to 
http://www.tei-c.org/Activities/Council/Working/tcw20.xml .

However, I am about to create my first element spec (in at last 
implementing http://purl.org/TEI/FR/3555191 ) and am not sure whether to 
put in anything for "$Date:" and "$Id:".  I could create some by hand, 
but I'd like to put in whatever will work best for anyone who further 
edits the file using a properly configured editor.

Please advise.

Kevin

From kevin.s.hawkins at ultraslavonic.info  Wed Dec  5 23:20:25 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Wed, 05 Dec 2012 23:20:25 -0500
Subject: [tei-council] one <exemplum> or many?
Message-ID: <50C01D09.7080102@ultraslavonic.info>

I notice that biblScope.xml has one <exemplum> containing four examples 
of <biblScope>.  This should actually be four separate <exemplum>s, 
right?  That is, you should only ever have a chunk of code meant to be 
read together in a single <exemplum>, right?

If so, perhaps someone could hack together an XSLT that looks for 
multiple occurrences of the same element within a single <exemplum> in 
order to detect others in Specs/ that need to be separated?

K.

From mholmes at uvic.ca  Wed Dec  5 23:41:40 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Wed, 05 Dec 2012 20:41:40 -0800
Subject: [tei-council] $Date: and $Id:
In-Reply-To: <50C010C9.1040805@ultraslavonic.info>
References: <50C010C9.1040805@ultraslavonic.info>
Message-ID: <50C02204.8090402@uvic.ca>

Hi Kevin,

The Subversion system adds the file date, id, date etc. to every 
checkout if you do this:

1. When you create your new file, copy and paste that header bit from 
any other file into the top of your file. (It doesn't matter if the 
date, filename and other info from the old file is in there. Subversion 
will replace it automatically later.)

2. Run this at the command line in the directory where your file is:

  svn add yourfile.xml

so Subversion knows about your new file.

3. Run this:

svn propset svn:keywords 'LastChangedRevision LastChangedBy Id 
LastChangedDate HeadURL' filename.xml

4. Run svn commit to commit your changes. You'll find that even your 
local copy is automatically updated by SVN to show the right id and 
date, and show your id as the last editor of it.

I think I remember putting this in one of the TCWs, but I don't remember 
where. I'll have a look, and if I can't find it I'll put it somewhere.

Cheers,
Martin

On 12-12-05 07:28 PM, Kevin Hawkins wrote:
> Every file in Guidelines/ and Specs/ contains at the top:
>
> <!--
> Copyright TEI Consortium.
> Dual-licensed under CC-by and BSD2 licences
> See the file COPYING.txt for details.
>
> which is followed by lines beginning:
>
> $Date:
> $Id:
>
> after which there is machine-generated information about the last time
> the file is touched.  I understand that this is automatically by a
> properly configured text editor of some sort.  (I've gone looking for
> information on this in the past out of my own curiosity but have been
> unable to find anything since searching on these terms turns up just
> sourcecode and webpages that were edited using such an editor.  Your
> leads appreciated.)
>
> As far as I can tell,
> http://www.tei-c.org/Activities/Council/Working/tcw20.xml doesn't say
> require that we use a particular editor configuration that will update
> this information when editing an existing file.  I certainly haven't
> ever touched it, so I suppose that when I make an edit, the info listed
> here is inaccurate until someone with such a configuration edits the
> file.  And I suppose that's okay since no one has ever complained or
> suggested we add it to
> http://www.tei-c.org/Activities/Council/Working/tcw20.xml .
>
> However, I am about to create my first element spec (in at last
> implementing http://purl.org/TEI/FR/3555191 ) and am not sure whether to
> put in anything for "$Date:" and "$Id:".  I could create some by hand,
> but I'd like to put in whatever will work best for anyone who further
> edits the file using a properly configured editor.
>
> Please advise.
>
> Kevin
>

-- 
Martin Holmes
mholmes at uvic.ca
UVic Humanities Computing and Media Centre

From mholmes at uvic.ca  Thu Dec  6 08:50:04 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Thu, 06 Dec 2012 05:50:04 -0800
Subject: [tei-council] one <exemplum> or many?
In-Reply-To: <50C01D09.7080102@ultraslavonic.info>
References: <50C01D09.7080102@ultraslavonic.info>
Message-ID: <50C0A28C.6090807@uvic.ca>

I count 213 instances of <egXML> with multiple identical child elements, 
such as the instance you see in biblScope.xml, but I'm not so sure 
there's anything wrong with including multiple instances of a tag inside 
one <exemplum>/<egXML> block, especially when the examples are very 
short. Is it wrong, or just convenient and efficient?

Cheers,
Martin

On 12-12-05 08:20 PM, Kevin Hawkins wrote:
> I notice that biblScope.xml has one <exemplum> containing four examples
> of <biblScope>.  This should actually be four separate <exemplum>s,
> right?  That is, you should only ever have a chunk of code meant to be
> read together in a single <exemplum>, right?
>
> If so, perhaps someone could hack together an XSLT that looks for
> multiple occurrences of the same element within a single <exemplum> in
> order to detect others in Specs/ that need to be separated?
>
> K.
>

-- 
Martin Holmes
mholmes at uvic.ca
UVic Humanities Computing and Media Centre

From kevin.s.hawkins at ultraslavonic.info  Thu Dec  6 09:04:22 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Thu, 06 Dec 2012 09:04:22 -0500
Subject: [tei-council] one <exemplum> or many?
In-Reply-To: <50C0A28C.6090807@uvic.ca>
References: <50C01D09.7080102@ultraslavonic.info> <50C0A28C.6090807@uvic.ca>
Message-ID: <50C0A5E6.9040803@ultraslavonic.info>

It strikes me as wrong semantically (an "exemplum" is a single example) 
and also potentially confusing to a user (for an element that can 
repeat, not being sure whether the multiple examples rendered in the 
same green box online could appear together in the same place in a 
document).  I see the convenience, but I think it's something we should 
avoid.

On 12/6/2012 8:50 AM, Martin Holmes wrote:
> I count 213 instances of<egXML>  with multiple identical child elements,
> such as the instance you see in biblScope.xml, but I'm not so sure
> there's anything wrong with including multiple instances of a tag inside
> one<exemplum>/<egXML>  block, especially when the examples are very
> short. Is it wrong, or just convenient and efficient?
>
> Cheers,
> Martin
>
> On 12-12-05 08:20 PM, Kevin Hawkins wrote:
>> I notice that biblScope.xml has one<exemplum>  containing four examples
>> of<biblScope>.  This should actually be four separate<exemplum>s,
>> right?  That is, you should only ever have a chunk of code meant to be
>> read together in a single<exemplum>, right?
>>
>> If so, perhaps someone could hack together an XSLT that looks for
>> multiple occurrences of the same element within a single<exemplum>  in
>> order to detect others in Specs/ that need to be separated?
>>
>> K.
>>
>

From gabriel.bodard at kcl.ac.uk  Thu Dec  6 09:19:56 2012
From: gabriel.bodard at kcl.ac.uk (Gabriel Bodard)
Date: Thu, 6 Dec 2012 14:19:56 +0000
Subject: [tei-council] Upgrading TEI Project on SF
In-Reply-To: <50BF8487.6020103@it.ox.ac.uk>
References: <50BF7A22.7060401@it.ox.ac.uk> <50BF82FF.3030804@uvic.ca>
	<50BF8487.6020103@it.ox.ac.uk>
Message-ID: <50C0A98C.5090007@kcl.ac.uk>

On 2012-12-05 17:29, James Cummings wrote:
>> Does SF have a deadline by which we need to move?
>
> Not that I've seen so far.

They say "in the first quarter of 2013", which I think implies that if 
we haven't upgraded by end March, they'll probably do it for us soon 
thereafter.

On 2012-12-05 18:19, Lou Burnard wrote:
> "all our urls" meaning what exactly? Internally in the Guidelines we
> dont refer to anything sf specific, so those links clearly won't
> break. In what sense will all currently checked out versions of the
> repo break? They will remain internally consistent, so you cant mean
> that. Presumably you mean that they won't automatically get in touch
> with the new allura-svn repo, but who would expect them to?

Well, by default most people will expect files that they have checked 
out, especially if they are externals or dependencies within a larger 
process that they had set up once and don't need to think about very 
often, to continue working. I don't know about you, but many of the 
processes I have set up include all sorts of externalled files and 
directories in useful places, in ways that I may not be entirely sure I 
remember how (let alone why) they work any more. It's not, as you say, 
unexpected that these will break if the repo is moved, but it is a major 
pain. That is I think the only reason to make sure everyone is warned, 
and we have surveyed what we'll need to fix, before we jump in 
feet-first and press that "upgrade" button.

I'm about to do this for EpiDoc (which is a lot smaller than TEI) and am 
giving people (and myself) several weeks notice before actually pressing 
the button.

-- 
Dr Gabriel BODARD
Researcher in Digital Epigraphy

Digital Humanities
King's College London
26-29 Drury Lane
London WC2B 5RL

T: +44 (0)20 7848 1388
F: +44 (0)20 7848 2980
E: gabriel.bodard at kcl.ac.uk

http://www.digitalclassicist.org/
http://www.currentepigraphy.org/


From mholmes at uvic.ca  Thu Dec  6 11:07:01 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Thu, 6 Dec 2012 08:07:01 -0800
Subject: [tei-council] $Date: and $Id:
In-Reply-To: <50C02204.8090402@uvic.ca>
References: <50C010C9.1040805@ultraslavonic.info> <50C02204.8090402@uvic.ca>
Message-ID: <50C0C2A5.7000409@uvic.ca>

There's an abbreviated form of these instructions in the release 
technician's guide:

<http://www.tei-c.org/Activities/Council/Working/tcw22.xml#releaseSteps>

but I think it should also go in TCW20 (How to edit the Guidelines), in 
here:

<http://www.tei-c.org/Activities/Council/Working/tcw20.xml#body.1_div.4>

Before I add it, does anyone have any suggestions for improvements to 
the text below?

Cheers,
Martin

On 12-12-05 08:41 PM, Martin Holmes wrote:
> Hi Kevin,
>
> The Subversion system adds the file date, id, date etc. to every
> checkout if you do this:
>
> 1. When you create your new file, copy and paste that header bit from
> any other file into the top of your file. (It doesn't matter if the
> date, filename and other info from the old file is in there. Subversion
> will replace it automatically later.)
>
> 2. Run this at the command line in the directory where your file is:
>
>    svn add yourfile.xml
>
> so Subversion knows about your new file.
>
> 3. Run this:
>
> svn propset svn:keywords 'LastChangedRevision LastChangedBy Id
> LastChangedDate HeadURL' filename.xml
>
> 4. Run svn commit to commit your changes. You'll find that even your
> local copy is automatically updated by SVN to show the right id and
> date, and show your id as the last editor of it.
>
> I think I remember putting this in one of the TCWs, but I don't remember
> where. I'll have a look, and if I can't find it I'll put it somewhere.
>
> Cheers,
> Martin
>
> On 12-12-05 07:28 PM, Kevin Hawkins wrote:
>> Every file in Guidelines/ and Specs/ contains at the top:
>>
>> <!--
>> Copyright TEI Consortium.
>> Dual-licensed under CC-by and BSD2 licences
>> See the file COPYING.txt for details.
>>
>> which is followed by lines beginning:
>>
>> $Date:
>> $Id:
>>
>> after which there is machine-generated information about the last time
>> the file is touched.  I understand that this is automatically by a
>> properly configured text editor of some sort.  (I've gone looking for
>> information on this in the past out of my own curiosity but have been
>> unable to find anything since searching on these terms turns up just
>> sourcecode and webpages that were edited using such an editor.  Your
>> leads appreciated.)
>>
>> As far as I can tell,
>> http://www.tei-c.org/Activities/Council/Working/tcw20.xml doesn't say
>> require that we use a particular editor configuration that will update
>> this information when editing an existing file.  I certainly haven't
>> ever touched it, so I suppose that when I make an edit, the info listed
>> here is inaccurate until someone with such a configuration edits the
>> file.  And I suppose that's okay since no one has ever complained or
>> suggested we add it to
>> http://www.tei-c.org/Activities/Council/Working/tcw20.xml .
>>
>> However, I am about to create my first element spec (in at last
>> implementing http://purl.org/TEI/FR/3555191 ) and am not sure whether to
>> put in anything for "$Date:" and "$Id:".  I could create some by hand,
>> but I'd like to put in whatever will work best for anyone who further
>> edits the file using a properly configured editor.
>>
>> Please advise.
>>
>> Kevin
>>
>

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From mholmes at uvic.ca  Thu Dec  6 11:44:30 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Thu, 6 Dec 2012 08:44:30 -0800
Subject: [tei-council] one <exemplum> or many?
In-Reply-To: <50C0A5E6.9040803@ultraslavonic.info>
References: <50C01D09.7080102@ultraslavonic.info> <50C0A28C.6090807@uvic.ca>
	<50C0A5E6.9040803@ultraslavonic.info>
Message-ID: <50C0CB6E.80601@uvic.ca>

Here's a quick-and-dirty list of situations that look like they're 
instances of this. Obviously I haven't checked them all; it may be a 
legitimate exemplum which has a sequence of sibling elements with the 
same name.

att.ascribed.xml: castItem appears 2 times.
att.datable.custom.xml: p appears 4 times.
att.datable.w3c.xml: date appears 2 times.
att.datable.xml: date appears 2 times.
att.milestoneUnit.xml: milestone appears 2 times.
att.milestoneUnit.xml: milestone appears 2 times.
att.milestoneUnit.xml: milestone appears 2 times.
att.placement.xml: add appears 2 times.
att.sourced.xml: l appears 3 times.
sponsor.xml: sponsor appears 3 times.
sponsor.xml: sponsor appears 3 times.
funder.xml: funder appears 4 times.
funder.xml: funder appears 2 times.
funder.xml: funder appears 4 times.
edition.xml: edition appears 2 times.
edition.xml: edition appears 2 times.
extent.xml: extent appears 3 times.
extent.xml: extent appears 3 times.
extent.xml: extent appears 3 times.
distributor.xml: distributor appears 2 times.
distributor.xml: distributor appears 2 times.
distributor.xml: distributor appears 2 times.
idno.xml: idno appears 7 times.
idno.xml: idno appears 3 times.
availability.xml: availability appears 3 times.
availability.xml: availability appears 3 times.
refState.xml: refState appears 2 times.
refState.xml: refState appears 2 times.
handNote.xml: handNote appears 2 times.
change.xml: change appears 2 times.
p.xml: p appears 4 times.
p.xml: p appears 5 times.
emph.xml: q appears 2 times.
emph.xml: q appears 2 times.
hi.xml: hi appears 2 times.
hi.xml: hi appears 2 times.
distinct.xml: distinct appears 2 times.
distinct.xml: distinct appears 2 times.
said.xml: p appears 2 times.
said.xml: p appears 2 times.
q.xml: q appears 4 times.
q.xml: q appears 4 times.
mentioned.xml: mentioned appears 2 times.
mentioned.xml: mentioned appears 2 times.
term.xml: p appears 2 times.
term.xml: index appears 2 times.
orig.xml: l appears 2 times.
orig.xml: l appears 2 times.
orig.xml: l appears 2 times.
orig.xml: l appears 2 times.
orig.xml: l appears 2 times.
name.xml: name appears 4 times.
rs.xml: q appears 2 times.
rs.xml: q appears 2 times.
num.xml: p appears 2 times.
measure.xml: measure appears 3 times.
measure.xml: measure appears 3 times.
measure.xml: measure appears 3 times.
measure.xml: measure appears 3 times.
measure.xml: measure appears 3 times.
measure.xml: measure appears 3 times.
measureGrp.xml: measureGrp appears 3 times.
measureGrp.xml: measureGrp appears 3 times.
measureGrp.xml: measureGrp appears 3 times.
date.xml: date appears 2 times.
time.xml: time appears 2 times.
ptr.xml: ptr appears 3 times.
ptr.xml: ptr appears 3 times.
ref.xml: ref appears 2 times.
ref.xml: ref appears 2 times.
label.xml: p appears 2 times.
index.xml: index appears 2 times.
index.xml: index appears 3 times.
index.xml: index appears 2 times.
milestone.xml: milestone appears 2 times.
milestone.xml: milestone appears 2 times.
milestone.xml: milestone appears 2 times.
lb.xml: l appears 3 times.
author.xml: author appears 6 times.
author.xml: author appears 4 times.
author.xml: author appears 2 times.
editor.xml: editor appears 2 times.
editor.xml: editor appears 2 times.
editor.xml: editor appears 2 times.
biblScope.xml: biblScope appears 4 times.
biblScope.xml: biblScope appears 4 times.
biblScope.xml: biblScope appears 4 times.
lg.xml: lg appears 3 times.
lg.xml: lg appears 2 times.
sp.xml: sp appears 3 times.
sp.xml: sp appears 2 times.
sp.xml: sp appears 3 times.
speaker.xml: sp appears 5 times.
stage.xml: stage appears 10 times.
stage.xml: stage appears 11 times.
stage.xml: stage appears 10 times.
div1.xml: div1 appears 2 times.
div1.xml: div1 appears 2 times.
div1.xml: div1 appears 2 times.
charProp.xml: charProp appears 2 times.
charProp.xml: charProp appears 2 times.
localName.xml: localName appears 2 times.
localName.xml: localName appears 2 times.
mapping.xml: mapping appears 2 times.
mapping.xml: mapping appears 2 times.
unicodeName.xml: unicodeName appears 2 times.
unicodeName.xml: unicodeName appears 2 times.
metSym.xml: metSym appears 3 times.
metSym.xml: metSym appears 3 times.
metSym.xml: metSym appears 2 times.
caesura.xml: l appears 3 times.
caesura.xml: l appears 2 times.
caesura.xml: l appears 4 times.
castList.xml: div appears 2 times.
castGroup.xml: castGroup appears 2 times.
spGrp.xml: sp appears 2 times.
view.xml: view appears 2 times.
view.xml: view appears 2 times.
view.xml: div appears 2 times.
view.xml: div appears 2 times.
sound.xml: sp appears 4 times.
sound.xml: sp appears 4 times.
u.xml: u appears 2 times.
u.xml: u appears 2 times.
u.xml: u appears 2 times.
vocal.xml: vocal appears 2 times.
vocal.xml: vocal appears 2 times.
vocal.xml: vocal appears 2 times.
writing.xml: l appears 4 times.
shift.xml: u appears 3 times.
shift.xml: u appears 3 times.
shift.xml: u appears 3 times.
dimensions.xml: dimensions appears 3 times.
dimensions.xml: dimensions appears 2 times.
dimensions.xml: dimensions appears 3 times.
explicit.xml: explicit appears 3 times.
explicit.xml: explicit appears 3 times.
finalRubric.xml: finalRubric appears 2 times.
finalRubric.xml: finalRubric appears 2 times.
incipit.xml: incipit appears 6 times.
incipit.xml: incipit appears 6 times.
rubric.xml: rubric appears 3 times.
rubric.xml: rubric appears 3 times.
rubric.xml: rubric appears 3 times.
condition.xml: condition appears 2 times.
provenance.xml: provenance appears 2 times.
provenance.xml: provenance appears 2 times.
provenance.xml: provenance appears 2 times.
damage.xml: l appears 2 times.
damageSpan.xml: p appears 3 times.
damageSpan.xml: p appears 3 times.
damageSpan.xml: p appears 3 times.
delSpan.xml: p appears 4 times.
delSpan.xml: p appears 4 times.
delSpan.xml: p appears 4 times.
handShift.xml: l appears 2 times.
redo.xml: line appears 2 times.
bloc.xml: bloc appears 2 times.
bloc.xml: bloc appears 2 times.
bloc.xml: bloc appears 2 times.
affiliation.xml: affiliation appears 2 times.
affiliation.xml: affiliation appears 2 times.
affiliation.xml: affiliation appears 2 times.
education.xml: education appears 2 times.
education.xml: education appears 2 times.
education.xml: education appears 2 times.
geo.xml: geoDecl appears 2 times.
langKnown.xml: langKnown appears 2 times.
langKnown.xml: langKnown appears 2 times.
langKnown.xml: langKnown appears 2 times.
residence.xml: residence appears 2 times.
residence.xml: residence appears 2 times.
residence.xml: residence appears 2 times.
att.datable.iso.xml: date appears 3 times.
att.datable.iso.xml: date appears 3 times.
domain.xml: domain appears 2 times.
domain.xml: domain appears 2 times.
domain.xml: domain appears 2 times.
purpose.xml: purpose appears 2 times.
purpose.xml: purpose appears 2 times.
link.xml: s appears 2 times.
anchor.xml: s appears 2 times.
anchor.xml: s appears 2 times.
anchor.xml: s appears 2 times.
seg.xml: seg appears 2 times.
seg.xml: seg appears 2 times.
seg.xml: seg appears 2 times.
join.xml: sp appears 3 times.
join.xml: sp appears 3 times.
join.xml: p appears 2 times.
join.xml: sp appears 3 times.
join.xml: p appears 2 times.
join.xml: p appears 2 times.
s.xml: s appears 2 times.
s.xml: s appears 2 times.
span.xml: p appears 3 times.
span.xml: p appears 3 times.
span.xml: p appears 3 times.
spanGrp.xml: u appears 6 times.
binary.xml: f appears 2 times.
binary.xml: f appears 2 times.
respons.xml: respons appears 2 times.
respons.xml: respons appears 2 times.
respons.xml: respons appears 2 times.
tag.xml: tag appears 3 times.
tag.xml: tag appears 3 times.
tag.xml: tag appears 2 times.
memberOf.xml: memberOf appears 2 times.
memberOf.xml: memberOf appears 2 times.
memberOf.xml: memberOf appears 2 times.
equiv.xml: elementSpec appears 2 times.
equiv.xml: elementSpec appears 2 times.
equiv.xml: elementSpec appears 2 times.

Cheers,
Martin

On 12-12-06 06:04 AM, Kevin Hawkins wrote:
> It strikes me as wrong semantically (an "exemplum" is a single example)
> and also potentially confusing to a user (for an element that can
> repeat, not being sure whether the multiple examples rendered in the
> same green box online could appear together in the same place in a
> document).  I see the convenience, but I think it's something we should
> avoid.
>
> On 12/6/2012 8:50 AM, Martin Holmes wrote:
>> I count 213 instances of<egXML>  with multiple identical child elements,
>> such as the instance you see in biblScope.xml, but I'm not so sure
>> there's anything wrong with including multiple instances of a tag inside
>> one<exemplum>/<egXML>  block, especially when the examples are very
>> short. Is it wrong, or just convenient and efficient?
>>
>> Cheers,
>> Martin
>>
>> On 12-12-05 08:20 PM, Kevin Hawkins wrote:
>>> I notice that biblScope.xml has one<exemplum>  containing four examples
>>> of<biblScope>.  This should actually be four separate<exemplum>s,
>>> right?  That is, you should only ever have a chunk of code meant to be
>>> read together in a single<exemplum>, right?
>>>
>>> If so, perhaps someone could hack together an XSLT that looks for
>>> multiple occurrences of the same element within a single<exemplum>  in
>>> order to detect others in Specs/ that need to be separated?
>>>
>>> K.
>>>
>>

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From sebastian.rahtz at it.ox.ac.uk  Thu Dec  6 11:50:45 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Thu, 6 Dec 2012 16:50:45 +0000
Subject: [tei-council] one <exemplum> or many?
In-Reply-To: <50C0CB6E.80601@uvic.ca>
References: <50C01D09.7080102@ultraslavonic.info> <50C0A28C.6090807@uvic.ca>
	<50C0A5E6.9040803@ultraslavonic.info> <50C0CB6E.80601@uvic.ca>
Message-ID: <9C74DD25-FB85-4595-BF37-ECB2903161A7@it.ox.ac.uk>

frankly, I'd be inclined to trust the original editors to have got this right,
though I agree its something for new drafters to bear in mind
--
Sebastian Rahtz      
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431


From gabriel.bodard at kcl.ac.uk  Thu Dec  6 11:53:02 2012
From: gabriel.bodard at kcl.ac.uk (Gabriel Bodard)
Date: Thu, 6 Dec 2012 16:53:02 +0000
Subject: [tei-council] one <exemplum> or many?
In-Reply-To: <9C74DD25-FB85-4595-BF37-ECB2903161A7@it.ox.ac.uk>
References: <50C01D09.7080102@ultraslavonic.info> <50C0A28C.6090807@uvic.ca>
	<50C0A5E6.9040803@ultraslavonic.info> <50C0CB6E.80601@uvic.ca>
	<9C74DD25-FB85-4595-BF37-ECB2903161A7@it.ox.ac.uk>
Message-ID: <50C0CD6E.3000201@kcl.ac.uk>

Well, if Kevin's formulation is the one we accept (which seems 
reasonable to me) then I can confirm that I incorrectly included 4 
separate examples in one <exemplum> in att.datable.custom.

I guess this is something for anyone who feels strongly enough about to 
check by hand, and either fix or make a list of with a request that 
someone else go in and fix them...

On 2012-12-06 16:50, Sebastian Rahtz wrote:
> frankly, I'd be inclined to trust the original editors to have got this right,
> though I agree its something for new drafters to bear in mind
> --
> Sebastian Rahtz
> Director (Research Support) of Academic IT Services
> University of Oxford IT Services
> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>

-- 
Dr Gabriel BODARD
Researcher in Digital Epigraphy

Digital Humanities
King's College London
26-29 Drury Lane
London WC2B 5RL

T: +44 (0)20 7848 1388
F: +44 (0)20 7848 2980
E: gabriel.bodard at kcl.ac.uk

http://www.digitalclassicist.org/
http://www.currentepigraphy.org/


From kevin.s.hawkins at ultraslavonic.info  Thu Dec  6 21:09:27 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Thu, 06 Dec 2012 21:09:27 -0500
Subject: [tei-council] $Date: and $Id:
In-Reply-To: <50C0C2A5.7000409@uvic.ca>
References: <50C010C9.1040805@ultraslavonic.info> <50C02204.8090402@uvic.ca>
	<50C0C2A5.7000409@uvic.ca>
Message-ID: <50C14FD7.6040708@ultraslavonic.info>

Martin, your instructions below and in tcw22 are clear, so please do 
update tcw20 if we should be doing this with every commit.  Do I really 
understand correctly that you all run this svn propset command every 
time before committing?  It seems tedious.

On 12/6/12 11:07 AM, Martin Holmes wrote:
> There's an abbreviated form of these instructions in the release
> technician's guide:
>
> <http://www.tei-c.org/Activities/Council/Working/tcw22.xml#releaseSteps>
>
> but I think it should also go in TCW20 (How to edit the Guidelines), in
> here:
>
> <http://www.tei-c.org/Activities/Council/Working/tcw20.xml#body.1_div.4>
>
> Before I add it, does anyone have any suggestions for improvements to
> the text below?
>
> Cheers,
> Martin
>
> On 12-12-05 08:41 PM, Martin Holmes wrote:
>> Hi Kevin,
>>
>> The Subversion system adds the file date, id, date etc. to every
>> checkout if you do this:
>>
>> 1. When you create your new file, copy and paste that header bit from
>> any other file into the top of your file. (It doesn't matter if the
>> date, filename and other info from the old file is in there. Subversion
>> will replace it automatically later.)
>>
>> 2. Run this at the command line in the directory where your file is:
>>
>>     svn add yourfile.xml
>>
>> so Subversion knows about your new file.
>>
>> 3. Run this:
>>
>> svn propset svn:keywords 'LastChangedRevision LastChangedBy Id
>> LastChangedDate HeadURL' filename.xml
>>
>> 4. Run svn commit to commit your changes. You'll find that even your
>> local copy is automatically updated by SVN to show the right id and
>> date, and show your id as the last editor of it.
>>
>> I think I remember putting this in one of the TCWs, but I don't remember
>> where. I'll have a look, and if I can't find it I'll put it somewhere.
>>
>> Cheers,
>> Martin
>>
>> On 12-12-05 07:28 PM, Kevin Hawkins wrote:
>>> Every file in Guidelines/ and Specs/ contains at the top:
>>>
>>> <!--
>>> Copyright TEI Consortium.
>>> Dual-licensed under CC-by and BSD2 licences
>>> See the file COPYING.txt for details.
>>>
>>> which is followed by lines beginning:
>>>
>>> $Date:
>>> $Id:
>>>
>>> after which there is machine-generated information about the last time
>>> the file is touched.  I understand that this is automatically by a
>>> properly configured text editor of some sort.  (I've gone looking for
>>> information on this in the past out of my own curiosity but have been
>>> unable to find anything since searching on these terms turns up just
>>> sourcecode and webpages that were edited using such an editor.  Your
>>> leads appreciated.)
>>>
>>> As far as I can tell,
>>> http://www.tei-c.org/Activities/Council/Working/tcw20.xml doesn't say
>>> require that we use a particular editor configuration that will update
>>> this information when editing an existing file.  I certainly haven't
>>> ever touched it, so I suppose that when I make an edit, the info listed
>>> here is inaccurate until someone with such a configuration edits the
>>> file.  And I suppose that's okay since no one has ever complained or
>>> suggested we add it to
>>> http://www.tei-c.org/Activities/Council/Working/tcw20.xml .
>>>
>>> However, I am about to create my first element spec (in at last
>>> implementing http://purl.org/TEI/FR/3555191 ) and am not sure whether to
>>> put in anything for "$Date:" and "$Id:".  I could create some by hand,
>>> but I'd like to put in whatever will work best for anyone who further
>>> edits the file using a properly configured editor.
>>>
>>> Please advise.
>>>
>>> Kevin
>>>
>>
>

From kevin.s.hawkins at ultraslavonic.info  Thu Dec  6 21:11:17 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Thu, 06 Dec 2012 21:11:17 -0500
Subject: [tei-council] one <exemplum> or many?
In-Reply-To: <50C0CD6E.3000201@kcl.ac.uk>
References: <50C01D09.7080102@ultraslavonic.info> <50C0A28C.6090807@uvic.ca>
	<50C0A5E6.9040803@ultraslavonic.info> <50C0CB6E.80601@uvic.ca>
	<9C74DD25-FB85-4595-BF37-ECB2903161A7@it.ox.ac.uk>
	<50C0CD6E.3000201@kcl.ac.uk>
Message-ID: <50C15045.4000201@ultraslavonic.info>

I'm willing to create a ticket and assign itself to me to go through 
these if no one feels that there was any intention to using a single 
<exemplum> for multiple examples.

On 12/6/12 11:53 AM, Gabriel Bodard wrote:
> Well, if Kevin's formulation is the one we accept (which seems
> reasonable to me) then I can confirm that I incorrectly included 4
> separate examples in one <exemplum> in att.datable.custom.
>
> I guess this is something for anyone who feels strongly enough about to
> check by hand, and either fix or make a list of with a request that
> someone else go in and fix them...
>
> On 2012-12-06 16:50, Sebastian Rahtz wrote:
>> frankly, I'd be inclined to trust the original editors to have got this right,
>> though I agree its something for new drafters to bear in mind
>> --
>> Sebastian Rahtz
>> Director (Research Support) of Academic IT Services
>> University of Oxford IT Services
>> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>>
>

From mholmes at uvic.ca  Thu Dec  6 21:11:15 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Thu, 06 Dec 2012 18:11:15 -0800
Subject: [tei-council] $Date: and $Id:
In-Reply-To: <50C14FD7.6040708@ultraslavonic.info>
References: <50C010C9.1040805@ultraslavonic.info> <50C02204.8090402@uvic.ca>
	<50C0C2A5.7000409@uvic.ca> <50C14FD7.6040708@ultraslavonic.info>
Message-ID: <50C15043.7000509@uvic.ca>

Hi Kevin,

No, you only need to go through this procedure when you create a new 
file and add it to svn. Once the properties are set for a specific file, 
svn will take care of updating the info every time the file is committed 
or checked out.

Cheers,
Martin

On 12-12-06 06:09 PM, Kevin Hawkins wrote:
> Martin, your instructions below and in tcw22 are clear, so please do
> update tcw20 if we should be doing this with every commit.  Do I really
> understand correctly that you all run this svn propset command every
> time before committing?  It seems tedious.
>
> On 12/6/12 11:07 AM, Martin Holmes wrote:
>> There's an abbreviated form of these instructions in the release
>> technician's guide:
>>
>> <http://www.tei-c.org/Activities/Council/Working/tcw22.xml#releaseSteps>
>>
>> but I think it should also go in TCW20 (How to edit the Guidelines), in
>> here:
>>
>> <http://www.tei-c.org/Activities/Council/Working/tcw20.xml#body.1_div.4>
>>
>> Before I add it, does anyone have any suggestions for improvements to
>> the text below?
>>
>> Cheers,
>> Martin
>>
>> On 12-12-05 08:41 PM, Martin Holmes wrote:
>>> Hi Kevin,
>>>
>>> The Subversion system adds the file date, id, date etc. to every
>>> checkout if you do this:
>>>
>>> 1. When you create your new file, copy and paste that header bit from
>>> any other file into the top of your file. (It doesn't matter if the
>>> date, filename and other info from the old file is in there. Subversion
>>> will replace it automatically later.)
>>>
>>> 2. Run this at the command line in the directory where your file is:
>>>
>>>      svn add yourfile.xml
>>>
>>> so Subversion knows about your new file.
>>>
>>> 3. Run this:
>>>
>>> svn propset svn:keywords 'LastChangedRevision LastChangedBy Id
>>> LastChangedDate HeadURL' filename.xml
>>>
>>> 4. Run svn commit to commit your changes. You'll find that even your
>>> local copy is automatically updated by SVN to show the right id and
>>> date, and show your id as the last editor of it.
>>>
>>> I think I remember putting this in one of the TCWs, but I don't remember
>>> where. I'll have a look, and if I can't find it I'll put it somewhere.
>>>
>>> Cheers,
>>> Martin
>>>
>>> On 12-12-05 07:28 PM, Kevin Hawkins wrote:
>>>> Every file in Guidelines/ and Specs/ contains at the top:
>>>>
>>>> <!--
>>>> Copyright TEI Consortium.
>>>> Dual-licensed under CC-by and BSD2 licences
>>>> See the file COPYING.txt for details.
>>>>
>>>> which is followed by lines beginning:
>>>>
>>>> $Date:
>>>> $Id:
>>>>
>>>> after which there is machine-generated information about the last time
>>>> the file is touched.  I understand that this is automatically by a
>>>> properly configured text editor of some sort.  (I've gone looking for
>>>> information on this in the past out of my own curiosity but have been
>>>> unable to find anything since searching on these terms turns up just
>>>> sourcecode and webpages that were edited using such an editor.  Your
>>>> leads appreciated.)
>>>>
>>>> As far as I can tell,
>>>> http://www.tei-c.org/Activities/Council/Working/tcw20.xml doesn't say
>>>> require that we use a particular editor configuration that will update
>>>> this information when editing an existing file.  I certainly haven't
>>>> ever touched it, so I suppose that when I make an edit, the info listed
>>>> here is inaccurate until someone with such a configuration edits the
>>>> file.  And I suppose that's okay since no one has ever complained or
>>>> suggested we add it to
>>>> http://www.tei-c.org/Activities/Council/Working/tcw20.xml .
>>>>
>>>> However, I am about to create my first element spec (in at last
>>>> implementing http://purl.org/TEI/FR/3555191 ) and am not sure whether to
>>>> put in anything for "$Date:" and "$Id:".  I could create some by hand,
>>>> but I'd like to put in whatever will work best for anyone who further
>>>> edits the file using a properly configured editor.
>>>>
>>>> Please advise.
>>>>
>>>> Kevin
>>>>
>>>
>>

-- 
Martin Holmes
mholmes at uvic.ca
UVic Humanities Computing and Media Centre

From sebastian.rahtz at it.ox.ac.uk  Fri Dec  7 04:27:15 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Fri, 7 Dec 2012 09:27:15 +0000
Subject: [tei-council] one <exemplum> or many?
In-Reply-To: <50C15045.4000201@ultraslavonic.info>
References: <50C01D09.7080102@ultraslavonic.info> <50C0A28C.6090807@uvic.ca>
	<50C0A5E6.9040803@ultraslavonic.info> <50C0CB6E.80601@uvic.ca>
	<9C74DD25-FB85-4595-BF37-ECB2903161A7@it.ox.ac.uk>
	<50C0CD6E.3000201@kcl.ac.uk> <50C15045.4000201@ultraslavonic.info>
Message-ID: <A8052343-F036-403B-9177-AC3921156EE3@it.ox.ac.uk>


On 7 Dec 2012, at 02:11, Kevin Hawkins <kevin.s.hawkins at ultraslavonic.info>
 wrote:

> I'm willing to create a ticket and assign itself to me to go through 
> these if no one feels that there was any intention to using a single 
> <exemplum> for multiple examples.


Lou can comment better, but in P4 the editors certainly had the facility,
and used it, to make multiple distinct examples. So the working assumption must
be that when you have an exemplum with multiple children, the author
intended it to be a valid free-standing example.

I looked  at a trivial one, <sponsor>, surely that is intentionally
multiple elements?
--
Sebastian Rahtz      
http://www.justgiving.com/SebastianRahtz
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431


From kevin.s.hawkins at ultraslavonic.info  Fri Dec  7 09:34:23 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Fri, 07 Dec 2012 09:34:23 -0500
Subject: [tei-council] one <exemplum> or many?
In-Reply-To: <A8052343-F036-403B-9177-AC3921156EE3@it.ox.ac.uk>
References: <50C01D09.7080102@ultraslavonic.info> <50C0A28C.6090807@uvic.ca>
	<50C0A5E6.9040803@ultraslavonic.info> <50C0CB6E.80601@uvic.ca>
	<9C74DD25-FB85-4595-BF37-ECB2903161A7@it.ox.ac.uk>
	<50C0CD6E.3000201@kcl.ac.uk> <50C15045.4000201@ultraslavonic.info>
	<A8052343-F036-403B-9177-AC3921156EE3@it.ox.ac.uk>
Message-ID: <50C1FE6F.3080502@ultraslavonic.info>

On 12/7/2012 4:27 AM, Sebastian Rahtz wrote:
>
> On 7 Dec 2012, at 02:11, Kevin Hawkins<kevin.s.hawkins at ultraslavonic.info>
>   wrote:
>
>> I'm willing to create a ticket and assign itself to me to go through
>> these if no one feels that there was any intention to using a single
>> <exemplum>  for multiple examples.
>
>
> Lou can comment better, but in P4 the editors certainly had the facility,
> and used it, to make multiple distinct examples. So the working assumption must
> be that when you have an exemplum with multiple children, the author
> intended it to be a valid free-standing example.
>
> I looked  at a trivial one,<sponsor>, surely that is intentionally
> multiple elements?

This is an example of a difficult case that could be interpreted two ways:

a) There are three sponsors of a given bibliographic entity (that are 
meant to repeat within a single <titleStmt>)

b) These are three separate examples of the use of the <sponsor> element.

Because I recognize the names of these three organizations as 
co-sponsors of P3, I can guess that this particular case was intended as 
(a).  So I'd leave it, though to be honest I think any example of 
repetition without context would be confusing for a complete novice.

From lou.burnard at retired.ox.ac.uk  Fri Dec  7 10:35:59 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Fri, 07 Dec 2012 15:35:59 +0000
Subject: [tei-council] one <exemplum> or many?
In-Reply-To: <50C1FE6F.3080502@ultraslavonic.info>
References: <50C01D09.7080102@ultraslavonic.info> <50C0A28C.6090807@uvic.ca>
	<50C0A5E6.9040803@ultraslavonic.info> <50C0CB6E.80601@uvic.ca>
	<9C74DD25-FB85-4595-BF37-ECB2903161A7@it.ox.ac.uk>
	<50C0CD6E.3000201@kcl.ac.uk> <50C15045.4000201@ultraslavonic.info>
	<A8052343-F036-403B-9177-AC3921156EE3@it.ox.ac.uk>
	<50C1FE6F.3080502@ultraslavonic.info>
Message-ID: <50C20CDF.9020908@retired.ox.ac.uk>

Surely we have more urgent and important matters to work on than this?

An exemplum " groups an example demonstrating the use of an element 
along with optional paragraphs of commentary"

As the content model shows, it contains a single <egXML>. Whether that 
contains one or  more occurrence of the element being exemplified is 
entirely an editorial matter. Sometimes it's useful to provide muiltiple 
instances, more usually it isn't.

The content of an egXML is supposed to be well formed, but we relaxed 
the constraint that there has to be a single root containing the whole 
content to permit examples containing mixed content.

In this particular case, does it really matter whether or n ot you 
consider the fact that there are three sponsor elements as exemplying 
the repeatability of <sponsor> within its parent? Many may elements are 
repeatable within their parent, and for most of them we don't bother to 
indicate the fact when we exemplify them!



On 07/12/12 14:34, Kevin Hawkins wrote:
> On 12/7/2012 4:27 AM, Sebastian Rahtz wrote:
>> On 7 Dec 2012, at 02:11, Kevin Hawkins<kevin.s.hawkins at ultraslavonic.info>
>>    wrote:
>>
>>> I'm willing to create a ticket and assign itself to me to go through
>>> these if no one feels that there was any intention to using a single
>>> <exemplum>  for multiple examples.
>>
>> Lou can comment better, but in P4 the editors certainly had the facility,
>> and used it, to make multiple distinct examples. So the working assumption must
>> be that when you have an exemplum with multiple children, the author
>> intended it to be a valid free-standing example.
>>
>> I looked  at a trivial one,<sponsor>, surely that is intentionally
>> multiple elements?
> This is an example of a difficult case that could be interpreted two ways:
>
> a) There are three sponsors of a given bibliographic entity (that are
> meant to repeat within a single <titleStmt>)
>
> b) These are three separate examples of the use of the <sponsor> element.
>
> Because I recognize the names of these three organizations as
> co-sponsors of P3, I can guess that this particular case was intended as
> (a).  So I'd leave it, though to be honest I think any example of
> repetition without context would be confusing for a complete novice.


From kevin.s.hawkins at ultraslavonic.info  Fri Dec  7 12:03:45 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Fri, 07 Dec 2012 12:03:45 -0500
Subject: [tei-council] one <exemplum> or many?
In-Reply-To: <50C20CDF.9020908@retired.ox.ac.uk>
References: <50C01D09.7080102@ultraslavonic.info>
	<50C0A28C.6090807@uvic.ca>	<50C0A5E6.9040803@ultraslavonic.info>
	<50C0CB6E.80601@uvic.ca>	<9C74DD25-FB85-4595-BF37-ECB2903161A7@it.ox.ac.uk>	<50C0CD6E.3000201@kcl.ac.uk>
	<50C15045.4000201@ultraslavonic.info>	<A8052343-F036-403B-9177-AC3921156EE3@it.ox.ac.uk>	<50C1FE6F.3080502@ultraslavonic.info>
	<50C20CDF.9020908@retired.ox.ac.uk>
Message-ID: <50C22171.4020500@ultraslavonic.info>

On 12/7/2012 10:35 AM, Lou Burnard wrote:
> Surely we have more urgent and important matters to work on than this?

I agree, and if I assigned this to myself, I would give it the lowest 
priority compared to the other tickets I still haven't made time for. 
And yet ...

> An exemplum " groups an example demonstrating the use of an element
> along with optional paragraphs of commentary"
>
> As the content model shows, it contains a single<egXML>. Whether that
> contains one or  more occurrence of the element being exemplified is
> entirely an editorial matter. Sometimes it's useful to provide muiltiple
> instances, more usually it isn't.
>
> The content of an egXML is supposed to be well formed, but we relaxed
> the constraint that there has to be a single root containing the whole
> content to permit examples containing mixed content.
>
> In this particular case, does it really matter whether or n ot you
> consider the fact that there are three sponsor elements as exemplying
> the repeatability of<sponsor>  within its parent? Many may elements are
> repeatable within their parent, and for most of them we don't bother to
> indicate the fact when we exemplify them!

The HTML output of the Guidelines labels each <exemplum> with "Example", 
so I find it misleading if a single "Example" contains more than one. 
You might say that this is a problem of the stylesheets that generate 
the output, but I maintain that if exemplum "groups an example", there 
should be a single example in it, not a whole set of them.

From mholmes at uvic.ca  Fri Dec  7 12:07:13 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Fri, 7 Dec 2012 09:07:13 -0800
Subject: [tei-council] one <exemplum> or many?
In-Reply-To: <50C20CDF.9020908@retired.ox.ac.uk>
References: <50C01D09.7080102@ultraslavonic.info> <50C0A28C.6090807@uvic.ca>
	<50C0A5E6.9040803@ultraslavonic.info> <50C0CB6E.80601@uvic.ca>
	<9C74DD25-FB85-4595-BF37-ECB2903161A7@it.ox.ac.uk>
	<50C0CD6E.3000201@kcl.ac.uk> <50C15045.4000201@ultraslavonic.info>
	<A8052343-F036-403B-9177-AC3921156EE3@it.ox.ac.uk>
	<50C1FE6F.3080502@ultraslavonic.info>
	<50C20CDF.9020908@retired.ox.ac.uk>
Message-ID: <50C22241.5090305@uvic.ca>

I think this would be important if a case were identified where multiple 
sibling instances in a single <exemplum> appear, but the schema would 
not in fact allow multiple siblings anywhere. That would arguably be an 
error (assuming it were not an intentional illustration of an invalid 
structure), and should probably be corrected. I don't know whether there 
are actually any instances of this among the list I sent out.

Cheers,
Martin

On 12-12-07 07:35 AM, Lou Burnard wrote:
> Surely we have more urgent and important matters to work on than this?
>
> An exemplum " groups an example demonstrating the use of an element
> along with optional paragraphs of commentary"
>
> As the content model shows, it contains a single <egXML>. Whether that
> contains one or  more occurrence of the element being exemplified is
> entirely an editorial matter. Sometimes it's useful to provide muiltiple
> instances, more usually it isn't.
>
> The content of an egXML is supposed to be well formed, but we relaxed
> the constraint that there has to be a single root containing the whole
> content to permit examples containing mixed content.
>
> In this particular case, does it really matter whether or n ot you
> consider the fact that there are three sponsor elements as exemplying
> the repeatability of <sponsor> within its parent? Many may elements are
> repeatable within their parent, and for most of them we don't bother to
> indicate the fact when we exemplify them!
>
>
>
> On 07/12/12 14:34, Kevin Hawkins wrote:
>> On 12/7/2012 4:27 AM, Sebastian Rahtz wrote:
>>> On 7 Dec 2012, at 02:11, Kevin Hawkins<kevin.s.hawkins at ultraslavonic.info>
>>>     wrote:
>>>
>>>> I'm willing to create a ticket and assign itself to me to go through
>>>> these if no one feels that there was any intention to using a single
>>>> <exemplum>  for multiple examples.
>>>
>>> Lou can comment better, but in P4 the editors certainly had the facility,
>>> and used it, to make multiple distinct examples. So the working assumption must
>>> be that when you have an exemplum with multiple children, the author
>>> intended it to be a valid free-standing example.
>>>
>>> I looked  at a trivial one,<sponsor>, surely that is intentionally
>>> multiple elements?
>> This is an example of a difficult case that could be interpreted two ways:
>>
>> a) There are three sponsors of a given bibliographic entity (that are
>> meant to repeat within a single <titleStmt>)
>>
>> b) These are three separate examples of the use of the <sponsor> element.
>>
>> Because I recognize the names of these three organizations as
>> co-sponsors of P3, I can guess that this particular case was intended as
>> (a).  So I'd leave it, though to be honest I think any example of
>> repetition without context would be confusing for a complete novice.
>

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From lou.burnard at retired.ox.ac.uk  Fri Dec  7 12:18:17 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Fri, 07 Dec 2012 17:18:17 +0000
Subject: [tei-council] one <exemplum> or many?
In-Reply-To: <50C22241.5090305@uvic.ca>
References: <50C01D09.7080102@ultraslavonic.info> <50C0A28C.6090807@uvic.ca>
	<50C0A5E6.9040803@ultraslavonic.info> <50C0CB6E.80601@uvic.ca>
	<9C74DD25-FB85-4595-BF37-ECB2903161A7@it.ox.ac.uk>
	<50C0CD6E.3000201@kcl.ac.uk> <50C15045.4000201@ultraslavonic.info>
	<A8052343-F036-403B-9177-AC3921156EE3@it.ox.ac.uk>
	<50C1FE6F.3080502@ultraslavonic.info>
	<50C20CDF.9020908@retired.ox.ac.uk> <50C22241.5090305@uvic.ca>
Message-ID: <50C224D9.1000106@retired.ox.ac.uk>

On 07/12/12 17:07, Martin Holmes wrote:
> I think this would be important if a case were identified where multiple
> sibling instances in a single <exemplum> appear, but the schema would
> not in fact allow multiple siblings anywhere. That would arguably be an
> error (assuming it were not an intentional illustration of an invalid
> structure), and should probably be corrected.


As I believe Sebastian already pointed out, if there are any such they 
ought to be have been caught by our existing example-validation process.



From mholmes at uvic.ca  Mon Dec 10 16:31:00 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Mon, 10 Dec 2012 13:31:00 -0800
Subject: [tei-council] New problem with stylesheet processing of the
	Guidelines?
Message-ID: <50C65494.6080801@uvic.ca>

Hi all,

I was just looking at the latest Jenkins build of the Guidelines, and I 
see that processing of examples seems to have been buggered up somehow. 
For instance, if you look here:

<http://teijenkins.hcmc.uvic.ca/job/TEIP5/lastSuccessfulBuild/artifact/release/doc/tei-p5-doc/en/html/SA.html#SAPT>

you'll see that an example that in the TEI source looks like this:

<egXML xml:lang="und" xmlns="http://www.tei-c.org/ns/Examples"><ptr 
xml:id="sa-p1" target="#sa-p2"/><ptr xml:id="sa-p2" 
target="#sa-p1"/></egXML>

comes out looking like this on the Glines page:

<span class="element"><ptr xml:id="<span 
class="attributevalue">sa-p1</span>" target="<span 
class="attributevalue">#sa-p2</span>"/></span><br/><span 
class="element"><ptr xml:id="<span class="attributevalue">sa-p2</span>" 
target="<span class="attributevalue">#sa-p1</span>"/></span>

It looks as though any instance of an attribute value is being wrapped 
in a <span class="attributevalue">, when I suspect that should actually 
only be happening to things that are tagged as <val>, not which _are_ 
vals. A sort of use-mention problem.

Cheers,
Martin
-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From mholmes at uvic.ca  Mon Dec 10 16:47:37 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Mon, 10 Dec 2012 13:47:37 -0800
Subject: [tei-council] New problem with stylesheet processing of the
	Guidelines?
In-Reply-To: <50C65494.6080801@uvic.ca>
References: <50C65494.6080801@uvic.ca>
Message-ID: <50C65879.9030902@uvic.ca>

I don't see this problem on the Oxford server:

<http://bits.nsms.ox.ac.uk:8080/jenkins/job/TEIP5/lastSuccessfulBuild/artifact/release/doc/tei-p5-doc/en/html/SA.html#SAPT>

so clearly something has changed on one or the other that's put them out 
of sync. My server has version 6.21 of the TEI packages, but the 
Guidelines _should_ be generated using the latest artifact from the 
Stylesheets job.

I'm going to try triggering another Stylesheets build on my server; that 
should generate a rebuild of all the P5 jobs when it's done, and the 
results should confirm whether it's just a glitch on my server. 
Sebastian, could you do the same? I see that your last successful builds 
are showing as six days ago, whereas mine are only a few hours old, so 
it looks like the changes to Stylesheets since then might have a bug 
which has found its way through as far as my Glines build, but hasn't 
shown up in yours yet.

Cheers,
Martin

On 12-12-10 01:31 PM, Martin Holmes wrote:
> Hi all,
>
> I was just looking at the latest Jenkins build of the Guidelines, and I
> see that processing of examples seems to have been buggered up somehow.
> For instance, if you look here:
>
> <http://teijenkins.hcmc.uvic.ca/job/TEIP5/lastSuccessfulBuild/artifact/release/doc/tei-p5-doc/en/html/SA.html#SAPT>
>
> you'll see that an example that in the TEI source looks like this:
>
> <egXML xml:lang="und" xmlns="http://www.tei-c.org/ns/Examples"><ptr
> xml:id="sa-p1" target="#sa-p2"/><ptr xml:id="sa-p2"
> target="#sa-p1"/></egXML>
>
> comes out looking like this on the Glines page:
>
> <span class="element"><ptr xml:id="<span
> class="attributevalue">sa-p1</span>" target="<span
> class="attributevalue">#sa-p2</span>"/></span><br/><span
> class="element"><ptr xml:id="<span class="attributevalue">sa-p2</span>"
> target="<span class="attributevalue">#sa-p1</span>"/></span>
>
> It looks as though any instance of an attribute value is being wrapped
> in a <span class="attributevalue">, when I suspect that should actually
> only be happening to things that are tagged as <val>, not which _are_
> vals. A sort of use-mention problem.
>
> Cheers,
> Martin
>

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From sebastian.rahtz at it.ox.ac.uk  Mon Dec 10 17:03:05 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Mon, 10 Dec 2012 22:03:05 +0000
Subject: [tei-council] New problem with stylesheet processing of
	the	Guidelines?
In-Reply-To: <50C65879.9030902@uvic.ca>
References: <50C65494.6080801@uvic.ca> <50C65879.9030902@uvic.ca>
Message-ID: <88348F35-8992-414C-9C93-0C7B93726E5E@it.ox.ac.uk>


On 10 Dec 2012, at 21:47, Martin Holmes <mholmes at uvic.ca>
 wrote:

> I don't see this problem on the Oxford server:
> 
> <http://bits.nsms.ox.ac.uk:8080/jenkins/job/TEIP5/lastSuccessfulBuild/artifact/release/doc/tei-p5-doc/en/html/SA.html#SAPT>
> 
> so clearly something has changed on one or the other that's put them out 
> of sync

it's because your server's config runs P5 after a change in Stylesheets,
and mine doesn't yet

I am investigating the issue, now that the school Christmas concert has
ended. Once in Royal David's City and all.

--
Sebastian Rahtz      
http://www.justgiving.com/SebastianRahtz
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431


From sebastian.rahtz at it.ox.ac.uk  Mon Dec 10 17:58:12 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Mon, 10 Dec 2012 22:58:12 +0000
Subject: [tei-council] New problem with stylesheet processing of
	the	Guidelines?
In-Reply-To: <50C65494.6080801@uvic.ca>
References: <50C65494.6080801@uvic.ca>
Message-ID: <35C39536-32F1-4613-BB36-0D1967F964E6@it.ox.ac.uk>

oh the joys of disable-output-escaping="yes", eh. How many times has that bitten me in the last 12 years? Alas, I am undone

--
Sebastian Rahtz      
http://www.justgiving.com/SebastianRahtz
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431


From sebastian.rahtz at it.ox.ac.uk  Mon Dec 10 18:12:54 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Mon, 10 Dec 2012 23:12:54 +0000
Subject: [tei-council] New problem with stylesheet processing of
	the	Guidelines?
In-Reply-To: <50C65494.6080801@uvic.ca>
References: <50C65494.6080801@uvic.ca>
Message-ID: <DF2941F0-46D3-436C-B373-2E31DB4DBDB5@it.ox.ac.uk>


On 10 Dec 2012, at 21:31, Martin Holmes <mholmes at uvic.ca> wrote:
> 
> I was just looking at the latest Jenkins build of the Guidelines, and I 
> see that processing of examples seems to have been buggered up somehow. 

I am not sure that "seems to have been buggered up somehow"
is up to the error-reporting standards of Louis Dubeau, but
anyway, duly fixed now.

--
Sebastian Rahtz      
http://www.justgiving.com/SebastianRahtz
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431


From mholmes at uvic.ca  Mon Dec 10 18:54:54 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Mon, 10 Dec 2012 15:54:54 -0800
Subject: [tei-council] New problem with stylesheet processing of the
	Guidelines?
In-Reply-To: <DF2941F0-46D3-436C-B373-2E31DB4DBDB5@it.ox.ac.uk>
References: <50C65494.6080801@uvic.ca>
	<DF2941F0-46D3-436C-B373-2E31DB4DBDB5@it.ox.ac.uk>
Message-ID: <50C6764E.2060606@uvic.ca>

On 12-12-10 03:12 PM, Sebastian Rahtz wrote:
>
> On 10 Dec 2012, at 21:31, Martin Holmes <mholmes at uvic.ca> wrote:
>>
>> I was just looking at the latest Jenkins build of the Guidelines, and I
>> see that processing of examples seems to have been buggered up somehow.
>
> I am not sure that "seems to have been buggered up somehow"
> is up to the error-reporting standards of Louis Dubeau, but
> anyway, duly fixed now.

Alas, I am no Louis, I know. But I've seen your commit messages, and 
you're not in a position to complain. My favourite recently is "ytypo" 
(sic). :-)

Cheers,
Martin

> --
> Sebastian Rahtz
> http://www.justgiving.com/SebastianRahtz
> Director (Research Support) of Academic IT Services
> University of Oxford IT Services
> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>
>

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From sebastian.rahtz at it.ox.ac.uk  Tue Dec 11 04:48:12 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Tue, 11 Dec 2012 09:48:12 +0000
Subject: [tei-council] <quotation>
Message-ID: <1194C04B-9D82-4624-BD76-BCA331A1BF25@it.ox.ac.uk>

as you'll probably have seen on TEI-L, I note that <quotation> is an optional element, with
an optional attribute "marks". This "indicates whether or not quotation marks have been retained as content within the text."
and has      <defaultVal>all</defaultVal>

I'd like to ask permission to remove that <defaultVal>, for two reasons

  a) we can't implement default values in RELAXNG schemas
  b) because <quotation> is optional, the meaning of the "default" is ambiguous

I note that the Guidelines examples seem universally to
NOT retain quotation marks.
--
Sebastian Rahtz      
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431


From lou.burnard at retired.ox.ac.uk  Tue Dec 11 05:11:12 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Tue, 11 Dec 2012 10:11:12 +0000
Subject: [tei-council] <quotation>
In-Reply-To: <1194C04B-9D82-4624-BD76-BCA331A1BF25@it.ox.ac.uk>
References: <1194C04B-9D82-4624-BD76-BCA331A1BF25@it.ox.ac.uk>
Message-ID: <50C706C0.2070602@retired.ox.ac.uk>

On 11/12/12 09:48, Sebastian Rahtz wrote:
> as you'll probably have seen on TEI-L,

(If I didn't know you better, I'd find the tone of your message there a 
little offensive, btw)

I note that <quotation> is an optional element, with
> an optional attribute "marks". This "indicates whether or not quotation marks have been retained as content within the text."
> and has      <defaultVal>all</defaultVal>
>
> I'd like to ask permission to remove that <defaultVal>, for two reasons
>
>    a) we can't implement default values in RELAXNG schemas

Tail wagging dog?

>    b) because <quotation> is optional, the meaning of the "default" is ambiguous
>

It's not ambiguous: it's underspecified. They are not the same thing. 
"Underspecified" means an implementer can make up their own mind what to 
do in that case. "Ambiguous" means they cannot because they are given 
contradictory pieces of information

> I note that the Guidelines examples seem universally to
> NOT retain quotation marks.

"universally" meaning "nearly all of the time" I assume since your TEI-L 
message points to a case where they *are* retained. Anyway, yes, I think 
it reasonable to assume that <q> etc. normally replace the punctuation 
marks which triggered the assumption that this stretch of text should be 
treated as  "quotation" (that's what the definition says anyway). I 
think there's some discussion along those lines in the prose.  On the 
other hand, some people think (equally reasonably) that source 
punctuation is interesting and should be retained, so you need some way 
of being told which doctrine obtains in a given text.



From sebastian.rahtz at it.ox.ac.uk  Tue Dec 11 05:26:56 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Tue, 11 Dec 2012 10:26:56 +0000
Subject: [tei-council] <quotation>
In-Reply-To: <50C706C0.2070602@retired.ox.ac.uk>
References: <1194C04B-9D82-4624-BD76-BCA331A1BF25@it.ox.ac.uk>
	<50C706C0.2070602@retired.ox.ac.uk>
Message-ID: <67686261-2ee2-4ae0-a7c7-c5e78e2dcaf8@HUB06.ad.oak.ox.ac.uk>


On 11 Dec 2012, at 10:11, Lou Burnard <lou.burnard at retired.ox.ac.uk>
 wrote:
>> as you'll probably have seen on TEI-L,
> 
> (If I didn't know you better, I'd find the tone of your message there a 
> little offensive, btw)

Yup. Apologies. Error of tone in my message.


>> I'd like to ask permission to remove that <defaultVal>, for two reasons
>> 
>>   a) we can't implement default values in RELAXNG schemas
> 
> Tail wagging dog?

well, yes, there's an element of that I confess. but  we have gone so far
in the last few years to make the Guidelines outputs closer to being
implementable (datatyping, schematron etc), that I think <defaultVal>
is looking a bit out of place now. 

>>   b) because <quotation> is optional, the meaning of the "default" is ambiguous
>> 
> 
> It's not ambiguous: it's underspecified. They are not the same thing. 
> "Underspecified" means an implementer can make up their own mind what to 
> do in that case. "Ambiguous" means they cannot because they are given 
> contradictory pieces of information

I'll accept the word may be wrong, but the effect is the same. The creator
of the <text> does not know what will happen in the rendered output if she omits
<quotation>. If she chooses to write <quotation marks="some"> the
she'll get her sandy deserts of course.

> 
>> I note that the Guidelines examples seem universally to
>> NOT retain quotation marks.
> 
> "universally" meaning "nearly all of the time" I assume since your TEI-L 
> message points to a case where they *are* retained.

I did take the liberty of removing the one I found in <said>. If people
think that was bad, I'll restore them.

> Anyway, yes, I think 
> it reasonable to assume that <q> etc. normally replace the punctuation 
> marks which triggered the assumption that this stretch of text should be 
> treated as  "quotation" (that's what the definition says anyway).

yes, that seems to be the tone of the discussion, and backed up
by our own examples. In which case the (possibly) implied default of <quotation marks=":all">
is contradictory.

>   On the 
> other hand, some people think (equally reasonably) that source 
> punctuation is interesting and should be retained, so you need some way 
> of being told which doctrine obtains in a given text.


sure. and thats what <quotation> lets you do. I have duly implemented
a check for that in the XSL.


So do you agree that the simplest thing to do is remove that <defaultVal>,
as it arguably contradicts the prose?
--
Sebastian Rahtz      
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431


From lou.burnard at retired.ox.ac.uk  Tue Dec 11 05:36:12 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Tue, 11 Dec 2012 10:36:12 +0000
Subject: [tei-council] <quotation>
In-Reply-To: <A1D7EF0F-5540-4437-B37A-C470DC93EEC9@it.ox.ac.uk>
References: <1194C04B-9D82-4624-BD76-BCA331A1BF25@it.ox.ac.uk>
	<50C706C0.2070602@retired.ox.ac.uk>
	<A1D7EF0F-5540-4437-B37A-C470DC93EEC9@it.ox.ac.uk>
Message-ID: <50C70C9C.4040204@retired.ox.ac.uk>

On 11/12/12 10:26, Sebastian Rahtz wrote:
>
>>>> I'd like to ask permission to remove that <defaultVal>, for two reasons
>>>
>>>    a) we can't implement default values in RELAXNG schemas
>>
>> Tail wagging dog?
>
> well, yes, there's an element of that I confess. but  we have gone so far
> in the last few years to make the Guidelines outputs closer to being
> implementable (datatyping, schematron etc), that I think <defaultVal>
> is looking a bit out of place now.


By all means lets have a discussion about the usefulness of <defaultVal>


>
>>>    b) because <quotation> is optional, the meaning of the "default" is ambiguous
>>>
>>
>> It's not ambiguous: it's underspecified. They are not the same thing.
>> "Underspecified" means an implementer can make up their own mind what to
>> do in that case. "Ambiguous" means they cannot because they are given
>> contradictory pieces of information
>
> I'll accept the word may be wrong, but the effect is the same. The creator
> of the <text> does not know what will happen in the rendered output if she omits
> <quotation>. If she chooses to write <quotation marks="some"> the
> she'll get her sandy deserts of course.


Who is this foolish woman? The encoder of a text chooses to encode what 
is significant to them. They may not ever intend the text to be 
rendered, and they may not care tuppence what happens when your 
stylesheet hits it!

>
>>
>>> I note that the Guidelines examples seem universally to
>>> NOT retain quotation marks.
>>
>> "universally" meaning "nearly all of the time" I assume since your TEI-L
>> message points to a case where they *are* retained.
>
> I did take the liberty of removing the one I found in <said>. If people
> think that was bad, I'll restore them.

I think they should be restored but *inside* the element, for 
consistency with the other <said> examples, where you have mdashes 
retained inside the element. I suspect that Martin originally put them 
outside by analogy with the punctuation inside a <bibl>, but I think the 
analogy is misleading.


> So do you agree that the simplest thing to do is remove that <defaultVal>,
> as it arguably contradicts the prose?

As aforesaid, I don't see that there is a contradiction, but I agree 
that <defaultVal> is a pain in the bum



From gabriel.bodard at kcl.ac.uk  Tue Dec 11 06:13:39 2012
From: gabriel.bodard at kcl.ac.uk (Gabriel Bodard)
Date: Tue, 11 Dec 2012 11:13:39 +0000
Subject: [tei-council] <quotation>
In-Reply-To: <1194C04B-9D82-4624-BD76-BCA331A1BF25@it.ox.ac.uk>
References: <1194C04B-9D82-4624-BD76-BCA331A1BF25@it.ox.ac.uk>
Message-ID: <50C71563.1000203@kcl.ac.uk>

On 11/12/2012 09:48, Sebastian Rahtz wrote:
>    a) we can't implement default values in RELAXNG schemas

As an aside on this discussion, can someone explain to me, given the 
above statement from Sebastian is true (as I have always understood it 
to be), what is meant by the option in the latest versions of Oxygen to: 
"Add default attribute values" [in RNG]? (See 
http://www.oxygenxml.com/doc/ug-editor/topics/relax-ng-preferences-page.html)

(I discovered this a few weeks ago because, upon upgrading to Oxygen 14 
at work, I found all sorts of unfamiliar attributes being added to my 
XML by an identity transform. My first thought was, "I thought we'd got 
away from this crap when we stopped using DTDs!" It seems that the 
option is selected by default in Oxygen, and you need to turn it off if 
you don't want default attribute values being added. Which I don't.)

Apologies if this is irrelevant to the defaultVal discussion.

-- 
Dr Gabriel BODARD
(Research Associate in Digital Epigraphy)

Department of Digital Humanities
King's College London
26-29 Drury Lane
London WC2B 5RL

Email: gabriel.bodard at kcl.ac.uk
Tel: +44 (0)20 7848 1388
Fax: +44 (0)20 7848 2980

http://www.digitalclassicist.org/
http://www.currentepigraphy.org/


From sebastian.rahtz at it.ox.ac.uk  Tue Dec 11 06:37:27 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Tue, 11 Dec 2012 11:37:27 +0000
Subject: [tei-council] <quotation>
In-Reply-To: <50C71563.1000203@kcl.ac.uk>
References: <1194C04B-9D82-4624-BD76-BCA331A1BF25@it.ox.ac.uk>
	<50C71563.1000203@kcl.ac.uk>
Message-ID: <DC315E23-E36C-4DCA-B737-2C2AA1027F66@it.ox.ac.uk>


On 11 Dec 2012, at 11:13, Gabriel Bodard <gabriel.bodard at kcl.ac.uk> wrote:

> On 11/12/2012 09:48, Sebastian Rahtz wrote:
>>   a) we can't implement default values in RELAXNG schemas
> 
> As an aside on this discussion, can someone explain to me, given the 
> above statement from Sebastian is true (as I have always understood it 
> to be), what is meant by the option in the latest versions of Oxygen to: 
> "Add default attribute values" [in RNG]? (See 
> http://www.oxygenxml.com/doc/ug-editor/topics/relax-ng-preferences-page.html)
> 

The default values are put in the schema by a trick, as an annotation. RELAX NG
per se does not understand this, but oxygen folks follow the convention
of the annotation. and of course it will depend on whether you associate a schema
which your document.

but the waters are muddy, I may not be seeing clearly.


--
Sebastian Rahtz      
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431


From sebastian.rahtz at it.ox.ac.uk  Tue Dec 11 06:38:11 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Tue, 11 Dec 2012 11:38:11 +0000
Subject: [tei-council] <quotation>
In-Reply-To: <50C70C9C.4040204@retired.ox.ac.uk>
References: <1194C04B-9D82-4624-BD76-BCA331A1BF25@it.ox.ac.uk>
	<50C706C0.2070602@retired.ox.ac.uk>
	<A1D7EF0F-5540-4437-B37A-C470DC93EEC9@it.ox.ac.uk>
	<50C70C9C.4040204@retired.ox.ac.uk>
Message-ID: <7096db69-d514-4ecd-bc0d-b707e21728bf@HUB04.ad.oak.ox.ac.uk>


On 11 Dec 2012, at 10:36, Lou Burnard <lou.burnard at retired.ox.ac.uk>
 wrote:
> 
> By all means lets have a discussion about the usefulness of <defaultVal>
> 
we have 83 of them, so its not a trivial issue to resolve

>> of the <text> does not know what will happen in the rendered output if she omits
>> <quotation>. If she chooses to write <quotation marks="some"> the
>> she'll get her sandy deserts of course.
> 
> 
> Who is this foolish woman? The encoder of a text chooses to encode what is significant to them. They may not ever intend the text to be rendered, and they may not care tuppence what happens when your stylesheet hits it!
> 
That's burying your head in the sand. No-one encodes a text in TEI XML without expecting someone sometime to do _some_ processing
on it, in the vaguest sense. whether it is my stylesheets or  whatever tool, there must be a processing model of this stuff.

>> I did take the liberty of removing the one I found in <said>. If people
>> think that was bad, I'll restore them.
> 
> I think they should be restored but *inside* the element, for consistency with the other <said> examples, where you have mdashes retained inside the element. 

those French examples with mdashes are anomalous, as most of the examples of <said> have omitted
the quote marks or whatever.  I'd argue they should have a <quotation marks="all"> as part of the example,
to show readers how to get the meaning they want.

Shall I get started now on  the confusion for the reader by showing them
both
	rend="PRE+lsquo POST+rsquo"
and
	rend="pre(?) post(?)
or shall I leave that for another day or another lifetime?
--
Sebastian Rahtz      
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431


From lou.burnard at retired.ox.ac.uk  Tue Dec 11 07:55:17 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Tue, 11 Dec 2012 12:55:17 +0000
Subject: [tei-council] <quotation>
In-Reply-To: <C5C83A9B-579E-4954-AA2E-5D43DA25045A@it.ox.ac.uk>
References: <1194C04B-9D82-4624-BD76-BCA331A1BF25@it.ox.ac.uk>
	<50C706C0.2070602@retired.ox.ac.uk>
	<A1D7EF0F-5540-4437-B37A-C470DC93EEC9@it.ox.ac.uk>
	<50C70C9C.4040204@retired.ox.ac.uk>
	<C5C83A9B-579E-4954-AA2E-5D43DA25045A@it.ox.ac.uk>
Message-ID: <50C72D35.2060704@retired.ox.ac.uk>

On 11/12/12 11:38, Sebastian Rahtz wrote:
>
> On 11 Dec 2012, at 10:36, Lou Burnard <lou.burnard at retired.ox.ac.uk>
>   wrote:
>>
>> By all means lets have a discussion about the usefulness of <defaultVal>
>>
> we have 83 of them, so its not a trivial issue to resolve

Yes. I suggest we put it on the council agenda though.

...


> The encoder of a text chooses to encode what is significant to them. They may not ever intend the text to be rendered, and they may not care tuppence what happens when your stylesheet hits it!
>>
> That's burying your head in the sand. No-one encodes a text in TEI XML without expecting someone sometime to do _some_ processing
> on it, in the vaguest sense. whether it is my stylesheets or  whatever tool, there must be a processing model of this stuff.

We are in a bad temper today aren't we? All I'm saying is that the 
processing model anticipated by the encoder may not have much or 
anything to do with realising the text in a nice HTML-like form. They 
may just want to count the words or align the transcription with an 
audio, or who knows what.

>
>>> I did take the liberty of removing the one I found in <said>. If people
>>> think that was bad, I'll restore them.
>>
>> I think they should be restored but *inside* the element, for consistency with the other <said> examples, where you have mdashes retained inside the element.
>
> those French examples with mdashes are anomalous, as most of the examples of <said> have omitted
> the quote marks or whatever.  I'd argue they should have a <quotation marks="all"> as part of the example,
> to show readers how to get the meaning they want.

"anomalous" does not mean "inconsistent with what I would do". If we 
restore the ones you removed, then we'd have three examples with 
preserved quotes and seven without, which seems about right to me, 
especially since the text explicitly says you can choose between leaving 
quotes in and not doing so. You might for instance want to determine how 
many of your <said>s use the mdash convention, and how many use others.

I quote:

"Quotation marks themselves may, like other punctuation marks, be felt 
for some purposes to be worth retaining within a text, quite 
independently of their description by the rend attribute."

>
> Shall I get started now on  the confusion for the reader by showing them
> both
> 	rend="PRE+lsquo POST+rsquo"
> and
> 	rend="pre(?) post(?)
> or shall I leave that for another day or another lifetime?

I wanted to replace all that rendition laddering, but my courage failed 
me at the last moment. Syd, since you're now on this list, would you 
care to express an opinion about whether we should replace all these 
examples with a CSS formulation?



From sebastian.rahtz at it.ox.ac.uk  Tue Dec 11 08:11:17 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Tue, 11 Dec 2012 13:11:17 +0000
Subject: [tei-council] <quotation>
In-Reply-To: <50C72D35.2060704@retired.ox.ac.uk>
References: <1194C04B-9D82-4624-BD76-BCA331A1BF25@it.ox.ac.uk>
	<50C706C0.2070602@retired.ox.ac.uk>
	<A1D7EF0F-5540-4437-B37A-C470DC93EEC9@it.ox.ac.uk>
	<50C70C9C.4040204@retired.ox.ac.uk>
	<C5C83A9B-579E-4954-AA2E-5D43DA25045A@it.ox.ac.uk>
	<50C72D35.2060704@retired.ox.ac.uk>
Message-ID: <F9770600-792E-4EAA-98AF-01B0E83F7828@it.ox.ac.uk>


On 11 Dec 2012, at 12:55, Lou Burnard <lou.burnard at retired.ox.ac.uk> wrote:
> All I'm saying is that the processing model anticipated by the encoder may not have much or anything to do with realising the text in a nice HTML-like form. They may just want to count the words or align the transcription with an audio, or who knows what.
\
oh, agreed, yes. in many cases the decision about the presence of absence of " will be immaterial. but you still have to decide.

> 
> "anomalous" does not mean "inconsistent with what I would do".

ah, now that explains where I am going wrong.

> If we restore the ones you removed, then we'd have three examples with preserved quotes and seven without, which seems about right to me, especially since the text explicitly says you can choose between leaving quotes in and not doing so.

this comes back to the debate sometime in the last 12 months where you argued that the examples should
show every type of different practice under the sun, and Martin and I argued that the the examples
within the Guidelines should show a consistent story. I mind less if the discursive chapters show
varying practice, but having two different styles on the same reference page at http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-said.html
jars. The difference between the two last examples (one with @rend, one without) is by contrast fine.

>> Shall I get started now on  the confusion for the reader by showing them
>> both
>> 	rend="PRE+lsquo POST+rsquo"
>> and
>> 	rend="pre(?) post(?)
>> or shall I leave that for another day or another lifetime?
> 
> I wanted to replace all that rendition laddering, but my courage failed me at the last moment. Syd, since you're now on this list, would you care to express an opinion about whether we should replace all these examples with a CSS formulation?

I don't mind the  concept of rendition ladders, but having two related, but different, implementations of the idea on a single page
(http://www.tei-c.org/release/doc/tei-p5-doc/en/html/examples-said.html) seems a step too far.


--
Sebastian Rahtz      
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431


From lou.burnard at retired.ox.ac.uk  Tue Dec 11 08:16:38 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Tue, 11 Dec 2012 13:16:38 +0000
Subject: [tei-council] <quotation>
In-Reply-To: <F9770600-792E-4EAA-98AF-01B0E83F7828@it.ox.ac.uk>
References: <1194C04B-9D82-4624-BD76-BCA331A1BF25@it.ox.ac.uk>
	<50C706C0.2070602@retired.ox.ac.uk>
	<A1D7EF0F-5540-4437-B37A-C470DC93EEC9@it.ox.ac.uk>
	<50C70C9C.4040204@retired.ox.ac.uk>
	<C5C83A9B-579E-4954-AA2E-5D43DA25045A@it.ox.ac.uk>
	<50C72D35.2060704@retired.ox.ac.uk>
	<F9770600-792E-4EAA-98AF-01B0E83F7828@it.ox.ac.uk>
Message-ID: <50C73236.2030509@retired.ox.ac.uk>

On 11/12/12 13:11, Sebastian Rahtz wrote:

> this comes back to the debate sometime in the last 12 months where you argued that the examples should
> show every type of different practice under the sun, and Martin and I argued that the the examples
> within the Guidelines should show a consistent story. I mind less if the discursive chapters show
> varying practice, but having two different styles on the same reference page at http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-said.html
> jars. The difference between the two last examples (one with @rend, one without) is by contrast fine.

I dont think I ever argued that the examples should show every possible 
divergent practice. But I did (and do) object to their showing only one 
possibility, expecially where the text explicitly licenses more than one.



From sebastian.rahtz at it.ox.ac.uk  Tue Dec 11 08:23:44 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Tue, 11 Dec 2012 13:23:44 +0000
Subject: [tei-council] <quotation>
In-Reply-To: <50C73236.2030509@retired.ox.ac.uk>
References: <1194C04B-9D82-4624-BD76-BCA331A1BF25@it.ox.ac.uk>
	<50C706C0.2070602@retired.ox.ac.uk>
	<A1D7EF0F-5540-4437-B37A-C470DC93EEC9@it.ox.ac.uk>
	<50C70C9C.4040204@retired.ox.ac.uk>
	<C5C83A9B-579E-4954-AA2E-5D43DA25045A@it.ox.ac.uk>
	<50C72D35.2060704@retired.ox.ac.uk>
	<F9770600-792E-4EAA-98AF-01B0E83F7828@it.ox.ac.uk>
	<50C73236.2030509@retired.ox.ac.uk>
Message-ID: <3baf5beb-c1f5-47c2-b102-ea70832b2ce9@HUB04.ad.oak.ox.ac.uk>


On 11 Dec 2012, at 13:16, Lou Burnard <lou.burnard at retired.ox.ac.uk>
 wrote:
> 
> I dont think I ever argued that the examples should show every possible divergent practice. But I did (and do) object to their showing only one possibility, expecially where the text explicitly licenses more than one.
> 
> 

Sticking to this one case, we have a clear mechanism (<quotation>) which is provided for the encoder to explain the choice
she has made.  so I suggest that we decide clearly what the default is, if no <quotation> is present (I'd prefer marks="none"),
and then in examples where we don't follow the default we supply a <quotation>. so the reader will see both practices,
but understand how to control them.

as I said before, this doesn't apply to the @rend variants, as those require no information outside their context. but in the
case of <q> and <said>, you can only understand the markup by reference to the <quotation>

i rest my case, m'lud.
--
Sebastian Rahtz      
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431


From gabriel.bodard at kcl.ac.uk  Tue Dec 11 09:49:37 2012
From: gabriel.bodard at kcl.ac.uk (Gabriel Bodard)
Date: Tue, 11 Dec 2012 14:49:37 +0000
Subject: [tei-council] <quotation>
In-Reply-To: <DC315E23-E36C-4DCA-B737-2C2AA1027F66@it.ox.ac.uk>
References: <1194C04B-9D82-4624-BD76-BCA331A1BF25@it.ox.ac.uk>
	<50C71563.1000203@kcl.ac.uk>
	<DC315E23-E36C-4DCA-B737-2C2AA1027F66@it.ox.ac.uk>
Message-ID: <50C74801.7040307@kcl.ac.uk>

Aha, I see. Thanks.

Is this "convention of the annotation" then something we might want to 
take advantage of, if we want to make default attribute values useful to 
at least some users?

I have to say that I'm with Wendell, however, and don't like the idea of 
default attributes anyway anyhow. If I don't specify @marks on 
<quotation>, that means I am not specifying whether some or any or all 
quotations marks are preserved or not. (What assumptions you want to 
make about that is another question.) The default value of all missing 
attributes should be @*='unspecified', in other words.

(I suppose a default value on a _required_ attribute might make sense, 
if only as a convenience for data-entry.)

On 11/12/2012 11:37, Sebastian Rahtz wrote:
> On 11 Dec 2012, at 11:13, Gabriel Bodard <gabriel.bodard at kcl.ac.uk> wrote:
>> On 11/12/2012 09:48, Sebastian Rahtz wrote:
>>>    a) we can't implement default values in RELAXNG schemas
>>
>> As an aside on this discussion, can someone explain to me, given the
>> above statement from Sebastian is true (as I have always understood it
>> to be), what is meant by the option in the latest versions of Oxygen to:
>> "Add default attribute values" [in RNG]? (See
>> http://www.oxygenxml.com/doc/ug-editor/topics/relax-ng-preferences-page.html)
>
> The default values are put in the schema by a trick, as an annotation. RELAX NG
> per se does not understand this, but oxygen folks follow the convention
> of the annotation. and of course it will depend on whether you associate a schema
> which your document.
>
> but the waters are muddy, I may not be seeing clearly.
>

-- 
Dr Gabriel BODARD
(Research Associate in Digital Epigraphy)

Department of Digital Humanities
King's College London
26-29 Drury Lane
London WC2B 5RL

Email: gabriel.bodard at kcl.ac.uk
Tel: +44 (0)20 7848 1388
Fax: +44 (0)20 7848 2980

http://www.digitalclassicist.org/
http://www.currentepigraphy.org/


From kevin.s.hawkins at ultraslavonic.info  Tue Dec 11 10:16:26 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Tue, 11 Dec 2012 10:16:26 -0500
Subject: [tei-council] <quotation>
In-Reply-To: <50C74801.7040307@kcl.ac.uk>
References: <1194C04B-9D82-4624-BD76-BCA331A1BF25@it.ox.ac.uk>
	<50C71563.1000203@kcl.ac.uk>
	<DC315E23-E36C-4DCA-B737-2C2AA1027F66@it.ox.ac.uk>
	<50C74801.7040307@kcl.ac.uk>
Message-ID: <50C74E4A.4060008@ultraslavonic.info>

Below ...

On 12/11/12 9:49 AM, Gabriel Bodard wrote:
> Aha, I see. Thanks.
>
> Is this "convention of the annotation" then something we might want to
> take advantage of, if we want to make default attribute values useful to
> at least some users?

I want to clarify what this "convention of the annotation" actually is. 
  It sounds like syncRO has implemented a non-standard extension to 
RELAX NG in <oXygen/>.  While proprietary standards are sometimes 
adopted by a community at large and may even be come part of the 
non-proprietary standard, I don't think the TEI should yet tether itself 
to something not adopted elsewhere, especially if it isn't even openly 
documented.

> I have to say that I'm with Wendell, however, and don't like the idea of
> default attributes anyway anyhow. If I don't specify @marks on
> <quotation>, that means I am not specifying whether some or any or all
> quotations marks are preserved or not. (What assumptions you want to
> make about that is another question.) The default value of all missing
> attributes should be @*='unspecified', in other words.
>
> (I suppose a default value on a _required_ attribute might make sense,
> if only as a convenience for data-entry.)

I have always assumed that a default value for a required attribute is a 
convenience for data entry, but I still don't understand what a default 
value for an optional attribute actually means.

--K.

From sebastian.rahtz at it.ox.ac.uk  Tue Dec 11 10:26:18 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Tue, 11 Dec 2012 15:26:18 +0000
Subject: [tei-council] <quotation>
In-Reply-To: <50C74E4A.4060008@ultraslavonic.info>
References: <1194C04B-9D82-4624-BD76-BCA331A1BF25@it.ox.ac.uk>
	<50C71563.1000203@kcl.ac.uk>
	<DC315E23-E36C-4DCA-B737-2C2AA1027F66@it.ox.ac.uk>
	<50C74801.7040307@kcl.ac.uk> <50C74E4A.4060008@ultraslavonic.info>
Message-ID: <CC489383-F8C7-4E4A-AF84-882B8267F746@it.ox.ac.uk>


On 11 Dec 2012, at 15:16, Kevin Hawkins <kevin.s.hawkins at ultraslavonic.info> wrote:

> I want to clarify what this "convention of the annotation" actually is. 
>  It sounds like syncRO has implemented a non-standard extension to 
> RELAX NG in <oXygen/>.

no, not all. its well understood (http://books.xmlschemata.org/relaxng/relax-CHP-13-SECT-1.html)
and widely used, to have documentation in a foreign namespace, typically http://relaxng.org/ns/compatibility/annotations/1.0, e.g.

<attribute name="decls">
        <a:documentation xmlns:a="http://relaxng.org/ns/compatibility/annotations/1.0">identifies one or more declarable elements within the
header, which are understood to apply to the element bearing this
attribute and its content.</a:documentation>

and the encoding of defaults using this is fully understood. See
http://relaxng.org/compatibility-20011203.html#default-value

> 
> I have always assumed that a default value for a required attribute is a 
> convenience for data entry, but I still don't understand what a default 
> value for an optional attribute actually means.
> 

hang on, you can't have it both ways. If an attribute is required, it
can't have a default. Its it optional, the default is what you
get if the attribute is not supplied.

there is no concept (in XML) of an attribute present without an explicit
value.

there is a related idea of a _suggested_ value for an attribute, which
an editor might insert for you, but thats not the same thing as a default.

--
Sebastian Rahtz      
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431


From sebastian.rahtz at it.ox.ac.uk  Tue Dec 11 10:29:37 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Tue, 11 Dec 2012 15:29:37 +0000
Subject: [tei-council] <quotation>
In-Reply-To: <50C74801.7040307@kcl.ac.uk>
References: <1194C04B-9D82-4624-BD76-BCA331A1BF25@it.ox.ac.uk>
	<50C71563.1000203@kcl.ac.uk>
	<DC315E23-E36C-4DCA-B737-2C2AA1027F66@it.ox.ac.uk>
	<50C74801.7040307@kcl.ac.uk>
Message-ID: <2B738422-2880-4AE2-9A6C-2570B54333A4@it.ox.ac.uk>


On 11 Dec 2012, at 14:49, Gabriel Bodard <gabriel.bodard at kcl.ac.uk> wrote:

> Is this "convention of the annotation" then something we might want to 
> take advantage of, if we want to make default attribute values useful to 
> at least some users?
> 
we do already. its just that many people never see any use of it.
only oXYgen users running their transform within the editor get the added
magic.


--
Sebastian Rahtz      
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431


From gabriel.bodard at kcl.ac.uk  Tue Dec 11 10:33:15 2012
From: gabriel.bodard at kcl.ac.uk (Gabriel Bodard)
Date: Tue, 11 Dec 2012 15:33:15 +0000
Subject: [tei-council] <quotation>
In-Reply-To: <2B738422-2880-4AE2-9A6C-2570B54333A4@it.ox.ac.uk>
References: <1194C04B-9D82-4624-BD76-BCA331A1BF25@it.ox.ac.uk>
	<50C71563.1000203@kcl.ac.uk>
	<DC315E23-E36C-4DCA-B737-2C2AA1027F66@it.ox.ac.uk>
	<50C74801.7040307@kcl.ac.uk>
	<2B738422-2880-4AE2-9A6C-2570B54333A4@it.ox.ac.uk>
Message-ID: <50C7523B.8040700@kcl.ac.uk>

D'oh! Of course we do, otherwise the (very annoying) behavior I spotted 
in Oxygen a few weeks ago would never have happened!

I have to say, I don't like it. When we have the conversation about 
default attributes, I think I'm going to argue in as many cases as 
possible for getting rid of them! :-)

On 11/12/2012 15:29, Sebastian Rahtz wrote:
>
> On 11 Dec 2012, at 14:49, Gabriel Bodard <gabriel.bodard at kcl.ac.uk> wrote:
>
>> Is this "convention of the annotation" then something we might want to
>> take advantage of, if we want to make default attribute values useful to
>> at least some users?
>>
> we do already. its just that many people never see any use of it.
> only oXYgen users running their transform within the editor get the added
> magic.
>
>
> --
> Sebastian Rahtz
> Director (Research Support) of Academic IT Services
> University of Oxford IT Services
> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>
>

-- 
Dr Gabriel BODARD
(Research Associate in Digital Epigraphy)

Department of Digital Humanities
King's College London
26-29 Drury Lane
London WC2B 5RL

Email: gabriel.bodard at kcl.ac.uk
Tel: +44 (0)20 7848 1388
Fax: +44 (0)20 7848 2980

http://www.digitalclassicist.org/
http://www.currentepigraphy.org/


From mholmes at uvic.ca  Tue Dec 11 12:52:01 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Tue, 11 Dec 2012 09:52:01 -0800
Subject: [tei-council] <quotation>
In-Reply-To: <50C7523B.8040700@kcl.ac.uk>
References: <1194C04B-9D82-4624-BD76-BCA331A1BF25@it.ox.ac.uk>
	<50C71563.1000203@kcl.ac.uk>
	<DC315E23-E36C-4DCA-B737-2C2AA1027F66@it.ox.ac.uk>
	<50C74801.7040307@kcl.ac.uk>
	<2B738422-2880-4AE2-9A6C-2570B54333A4@it.ox.ac.uk>
	<50C7523B.8040700@kcl.ac.uk>
Message-ID: <50C772C1.1080608@uvic.ca>

On 12-12-11 07:33 AM, Gabriel Bodard wrote:
> D'oh! Of course we do, otherwise the (very annoying) behavior I spotted
> in Oxygen a few weeks ago would never have happened!
>
> I have to say, I don't like it. When we have the conversation about
> default attributes, I think I'm going to argue in as many cases as
> possible for getting rid of them! :-)

+1 from me. I've been bitten by this too, doing a simple identity transform.

We would presumably want to retain the functionality for default values 
in the ODD infrastructure, since we offer this as a generic solution for 
non-TEI XML languages, but (if we went down this road) remove all 
defined default values from TEI specifications. Do I understand this 
correctly?

Cheers,
Martin

>
> On 11/12/2012 15:29, Sebastian Rahtz wrote:
>>
>> On 11 Dec 2012, at 14:49, Gabriel Bodard <gabriel.bodard at kcl.ac.uk> wrote:
>>
>>> Is this "convention of the annotation" then something we might want to
>>> take advantage of, if we want to make default attribute values useful to
>>> at least some users?
>>>
>> we do already. its just that many people never see any use of it.
>> only oXYgen users running their transform within the editor get the added
>> magic.
>>
>>
>> --
>> Sebastian Rahtz
>> Director (Research Support) of Academic IT Services
>> University of Oxford IT Services
>> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>>
>>
>

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From sebastian.rahtz at it.ox.ac.uk  Tue Dec 11 13:58:20 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Tue, 11 Dec 2012 18:58:20 +0000
Subject: [tei-council] <quotation>
In-Reply-To: <50C772C1.1080608@uvic.ca>
References: <1194C04B-9D82-4624-BD76-BCA331A1BF25@it.ox.ac.uk>
	<50C71563.1000203@kcl.ac.uk>
	<DC315E23-E36C-4DCA-B737-2C2AA1027F66@it.ox.ac.uk>
	<50C74801.7040307@kcl.ac.uk>
	<2B738422-2880-4AE2-9A6C-2570B54333A4@it.ox.ac.uk>
	<50C7523B.8040700@kcl.ac.uk> <50C772C1.1080608@uvic.ca>
Message-ID: <41CA32E9-134E-4396-9AE0-1F5F542ADCD4@it.ox.ac.uk>


On 11 Dec 2012, at 17:52, Martin Holmes <mholmes at uvic.ca> wrote:
> 
> We would presumably want to retain the functionality for default values 
> in the ODD infrastructure, since we offer this as a generic solution for 
> non-TEI XML languages, but (if we went down this road) remove all 
> defined default values from TEI specifications. 

Or we could just not pass them on to the schemas. 

The data performs a valuable function. To take a simple example,
it tells you that attDef/@usage defaults to "opt", which is important.
It's just less clear how to make it available to a processor these days
--
Sebastian Rahtz      
http://www.justgiving.com/SebastianRahtz
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431


From mholmes at uvic.ca  Thu Dec 13 08:36:28 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Thu, 13 Dec 2012 05:36:28 -0800
Subject: [tei-council] Council teleconference still on?
Message-ID: <50C9D9DC.6070503@uvic.ca>

Hi all,

I have a teleconference on my agenda for today (4 my time, 8GMT). Is it 
still on, and if so, what are the connection instructions?

Cheers,
Martin
-- 
Martin Holmes
mholmes at uvic.ca
UVic Humanities Computing and Media Centre

From rwelzenbach at gmail.com  Thu Dec 13 08:42:09 2012
From: rwelzenbach at gmail.com (Rebecca Welzenbach)
Date: Thu, 13 Dec 2012 08:42:09 -0500
Subject: [tei-council] Council teleconference still on?
In-Reply-To: <50C9D9DC.6070503@uvic.ca>
References: <50C9D9DC.6070503@uvic.ca>
Message-ID: <CAA2irtL7sUK3yCur8t80vskfZacFgXdQtiq3n94yHEEkGRYQ7g@mail.gmail.com>

I was just looking for connection details as well. I see the conference
scheduled for 4 p.m. GMT (which would be 8 a.m. for Martin, I think).


On Thu, Dec 13, 2012 at 8:36 AM, Martin Holmes <mholmes at uvic.ca> wrote:

> Hi all,
>
> I have a teleconference on my agenda for today (4 my time, 8GMT). Is it
> still on, and if so, what are the connection instructions?
>
> Cheers,
> Martin
> --
> Martin Holmes
> mholmes at uvic.ca
> UVic Humanities Computing and Media Centre
> --
> tei-council mailing list
> tei-council at lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>
> PLEASE NOTE: postings to this list are publicly archived
>

From bansp at o2.pl  Thu Dec 13 09:27:05 2012
From: bansp at o2.pl (=?ISO-8859-2?Q?Piotr_Ba=F1ski?=)
Date: Thu, 13 Dec 2012 15:27:05 +0100
Subject: [tei-council] Council teleconference still on?
In-Reply-To: <CAA2irtL7sUK3yCur8t80vskfZacFgXdQtiq3n94yHEEkGRYQ7g@mail.gmail.com>
References: <50C9D9DC.6070503@uvic.ca>
	<CAA2irtL7sUK3yCur8t80vskfZacFgXdQtiq3n94yHEEkGRYQ7g@mail.gmail.com>
Message-ID: <50C9E5B9.7090903@o2.pl>

Oh gosh, and I've just realised that I have no idea of how to get an
external connection from the office, and whether I can get it at all.

Maybe one of the topics on the agenda of both the Board and the Council
could be how to move this to a no-pay Internet platform, such as the one
I have suggested (and whose address I now happily forget...).

So long,

  P.

On 13/12/12 14:42, Rebecca Welzenbach wrote:
> I was just looking for connection details as well. I see the conference
> scheduled for 4 p.m. GMT (which would be 8 a.m. for Martin, I think).
> 
> 
> On Thu, Dec 13, 2012 at 8:36 AM, Martin Holmes <mholmes at uvic.ca> wrote:
> 
>> Hi all,
>>
>> I have a teleconference on my agenda for today (4 my time, 8GMT). Is it
>> still on, and if so, what are the connection instructions?
>>
>> Cheers,
>> Martin
>> --
>> Martin Holmes
>> mholmes at uvic.ca
>> UVic Humanities Computing and Media Centre
>> --
>> tei-council mailing list
>> tei-council at lists.village.Virginia.EDU
>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>>
>> PLEASE NOTE: postings to this list are publicly archived
>>


From rwelzenbach at gmail.com  Thu Dec 13 09:29:26 2012
From: rwelzenbach at gmail.com (Rebecca Welzenbach)
Date: Thu, 13 Dec 2012 09:29:26 -0500
Subject: [tei-council] Council teleconference still on?
In-Reply-To: <50C9E5B9.7090903@o2.pl>
References: <50C9D9DC.6070503@uvic.ca>
	<CAA2irtL7sUK3yCur8t80vskfZacFgXdQtiq3n94yHEEkGRYQ7g@mail.gmail.com>
	<50C9E5B9.7090903@o2.pl>
Message-ID: <CAA2irtJ7CQroeAFLjHnAsngQaGwifwC-xK3VWVMK-HEmyxQjig@mail.gmail.com>

I also know that Paul is on the road today, en route to a funeral,
unfortunately. This is not looking so promising...

I'm on my way into another meeting right now and will re-surface shortly
before the scheduled start time of the teleconference.


On Thu, Dec 13, 2012 at 9:27 AM, Piotr Ba?ski <bansp at o2.pl> wrote:

> Oh gosh, and I've just realised that I have no idea of how to get an
> external connection from the office, and whether I can get it at all.
>
> Maybe one of the topics on the agenda of both the Board and the Council
> could be how to move this to a no-pay Internet platform, such as the one
> I have suggested (and whose address I now happily forget...).
>
> So long,
>
>   P.
>
> On 13/12/12 14:42, Rebecca Welzenbach wrote:
> > I was just looking for connection details as well. I see the conference
> > scheduled for 4 p.m. GMT (which would be 8 a.m. for Martin, I think).
> >
> >
> > On Thu, Dec 13, 2012 at 8:36 AM, Martin Holmes <mholmes at uvic.ca> wrote:
> >
> >> Hi all,
> >>
> >> I have a teleconference on my agenda for today (4 my time, 8GMT). Is it
> >> still on, and if so, what are the connection instructions?
> >>
> >> Cheers,
> >> Martin
> >> --
> >> Martin Holmes
> >> mholmes at uvic.ca
> >> UVic Humanities Computing and Media Centre
> >> --
> >> 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 James.Cummings at it.ox.ac.uk  Thu Dec 13 09:35:22 2012
From: James.Cummings at it.ox.ac.uk (James Cummings)
Date: Thu, 13 Dec 2012 14:35:22 +0000
Subject: [tei-council] Council teleconference still on?
In-Reply-To: <50C9E5B9.7090903@o2.pl>
References: <50C9D9DC.6070503@uvic.ca>
	<CAA2irtL7sUK3yCur8t80vskfZacFgXdQtiq3n94yHEEkGRYQ7g@mail.gmail.com>
	<50C9E5B9.7090903@o2.pl>
Message-ID: <50C9E7AA.2010906@it.ox.ac.uk>

Apologies for the delay in distributing this information.

We'll be using the same conferencing system as last time run by 
economyconferencecall.com.  This should allow you to dial in 
toll-free and is using an account that is being used for the 
Board as well and the TEI-C will pay for the toll-free calls. 
(Though the cost is per call so if you are in the same location 
as another council member, do consider sharing a 
conference/speaker phone.)

I've got the toll free numbers for:

US and Canada: 866-906-0040
France (excl. Monaco): 0-800-916-758
Germany: 0-800-182-0270
New Zealand: 0-800-446-259
Poland: 00-800-112-4271 (0.35 zloty charge)
UK: 0-800-635-0541

(If you need a different country number, please contact me asap.)

I believe it did not play well with people connecting via skype.

Dial the appropriate number, and then enter the access code:
4614041 followed by the # button.

You'll be asked to give your name. I'm told you can mute/unmute
your line using *6 but have never tried it myself.

Can I have a volunteer to take minutes?

There is a draft agenda at
http://wiki.tei-c.org/index.php/Council


-James


On 13/12/12 14:27, Piotr Ba?ski wrote:
> Oh gosh, and I've just realised that I have no idea of how to get an
> external connection from the office, and whether I can get it at all.
>
> Maybe one of the topics on the agenda of both the Board and the Council
> could be how to move this to a no-pay Internet platform, such as the one
> I have suggested (and whose address I now happily forget...).
>
> So long,
>
>    P.
>
> On 13/12/12 14:42, Rebecca Welzenbach wrote:
>> I was just looking for connection details as well. I see the conference
>> scheduled for 4 p.m. GMT (which would be 8 a.m. for Martin, I think).
>>
>>
>> On Thu, Dec 13, 2012 at 8:36 AM, Martin Holmes <mholmes at uvic.ca> wrote:
>>
>>> Hi all,
>>>
>>> I have a teleconference on my agenda for today (4 my time, 8GMT). Is it
>>> still on, and if so, what are the connection instructions?
>>>
>>> Cheers,
>>> Martin
>>> --
>>> Martin Holmes
>>> mholmes at uvic.ca
>>> UVic Humanities Computing and Media Centre
>>> --
>>> 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, James.Cummings at it.ox.ac.uk
Academic IT Services, University of Oxford

From bansp at o2.pl  Thu Dec 13 09:43:34 2012
From: bansp at o2.pl (=?ISO-8859-2?Q?Piotr_Ba=F1ski?=)
Date: Thu, 13 Dec 2012 15:43:34 +0100
Subject: [tei-council] Council teleconference still on?
In-Reply-To: <50C9E7AA.2010906@it.ox.ac.uk>
References: <50C9D9DC.6070503@uvic.ca>
	<CAA2irtL7sUK3yCur8t80vskfZacFgXdQtiq3n94yHEEkGRYQ7g@mail.gmail.com>
	<50C9E5B9.7090903@o2.pl> <50C9E7AA.2010906@it.ox.ac.uk>
Message-ID: <50C9E996.9010500@o2.pl>

Darn, I'm tempted to bet that 0-800 may be out of the question. Will
check...

This isn't for cell phones, is it? I'm reading that page and it seems
that I might be able to call a toll number for a low price from my cell,
that just might be a solution for me, do you have such a number for
Germany, by any chance, James?

Thanks,

  P.

On 13/12/12 15:35, James Cummings wrote:
> Apologies for the delay in distributing this information.
> 
> We'll be using the same conferencing system as last time run by 
> economyconferencecall.com.  This should allow you to dial in 
> toll-free and is using an account that is being used for the 
> Board as well and the TEI-C will pay for the toll-free calls. 
> (Though the cost is per call so if you are in the same location 
> as another council member, do consider sharing a 
> conference/speaker phone.)
> 
> I've got the toll free numbers for:
> 
> US and Canada: 866-906-0040
> France (excl. Monaco): 0-800-916-758
> Germany: 0-800-182-0270
> New Zealand: 0-800-446-259
> Poland: 00-800-112-4271 (0.35 zloty charge)
> UK: 0-800-635-0541
> 
> (If you need a different country number, please contact me asap.)
> 
> I believe it did not play well with people connecting via skype.
> 
> Dial the appropriate number, and then enter the access code:
> 4614041 followed by the # button.
> 
> You'll be asked to give your name. I'm told you can mute/unmute
> your line using *6 but have never tried it myself.
> 
> Can I have a volunteer to take minutes?
> 
> There is a draft agenda at
> http://wiki.tei-c.org/index.php/Council
> 
> 
> -James
> 
> 
> On 13/12/12 14:27, Piotr Ba?ski wrote:
>> Oh gosh, and I've just realised that I have no idea of how to get an
>> external connection from the office, and whether I can get it at all.
>>
>> Maybe one of the topics on the agenda of both the Board and the Council
>> could be how to move this to a no-pay Internet platform, such as the one
>> I have suggested (and whose address I now happily forget...).
>>
>> So long,
>>
>>    P.
>>
>> On 13/12/12 14:42, Rebecca Welzenbach wrote:
>>> I was just looking for connection details as well. I see the conference
>>> scheduled for 4 p.m. GMT (which would be 8 a.m. for Martin, I think).
>>>
>>>
>>> On Thu, Dec 13, 2012 at 8:36 AM, Martin Holmes <mholmes at uvic.ca> wrote:
>>>
>>>> Hi all,
>>>>
>>>> I have a teleconference on my agenda for today (4 my time, 8GMT). Is it
>>>> still on, and if so, what are the connection instructions?
>>>>
>>>> Cheers,
>>>> Martin
>>>> --
>>>> Martin Holmes
>>>> mholmes at uvic.ca
>>>> UVic Humanities Computing and Media Centre
>>>> --
>>>> tei-council mailing list
>>>> tei-council at lists.village.Virginia.EDU
>>>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>>>>
>>>> PLEASE NOTE: postings to this list are publicly archived
>>>>
>>
> 
> 


From gabriel.bodard at kcl.ac.uk  Thu Dec 13 10:09:41 2012
From: gabriel.bodard at kcl.ac.uk (Gabriel Bodard)
Date: Thu, 13 Dec 2012 15:09:41 +0000
Subject: [tei-council] Council teleconference still on?
In-Reply-To: <50C9E7AA.2010906@it.ox.ac.uk>
References: <50C9D9DC.6070503@uvic.ca>
	<CAA2irtL7sUK3yCur8t80vskfZacFgXdQtiq3n94yHEEkGRYQ7g@mail.gmail.com>
	<50C9E5B9.7090903@o2.pl> <50C9E7AA.2010906@it.ox.ac.uk>
Message-ID: <50C9EFB5.20707@kcl.ac.uk>

FWIW, I've just tested it with Skype and it seems to work for me this 
time. (I think it was just me it didn't work for last time... Lou 
connected via Skype just fine.)

(I'm still going to go buy a telephone extension cable before we start 
just in case...)

G

On 13/12/2012 14:35, James Cummings wrote:
> Apologies for the delay in distributing this information.
>
> We'll be using the same conferencing system as last time run by
> economyconferencecall.com.  This should allow you to dial in
> toll-free and is using an account that is being used for the
> Board as well and the TEI-C will pay for the toll-free calls.
> (Though the cost is per call so if you are in the same location
> as another council member, do consider sharing a
> conference/speaker phone.)
>
> I've got the toll free numbers for:
>
> US and Canada: 866-906-0040
> France (excl. Monaco): 0-800-916-758
> Germany: 0-800-182-0270
> New Zealand: 0-800-446-259
> Poland: 00-800-112-4271 (0.35 zloty charge)
> UK: 0-800-635-0541
>
> (If you need a different country number, please contact me asap.)
>
> I believe it did not play well with people connecting via skype.
>
> Dial the appropriate number, and then enter the access code:
> 4614041 followed by the # button.
>
> You'll be asked to give your name. I'm told you can mute/unmute
> your line using *6 but have never tried it myself.
>
> Can I have a volunteer to take minutes?
>
> There is a draft agenda at
> http://wiki.tei-c.org/index.php/Council
>
>
> -James
>
>
> On 13/12/12 14:27, Piotr Ba?ski wrote:
>> Oh gosh, and I've just realised that I have no idea of how to get an
>> external connection from the office, and whether I can get it at all.
>>
>> Maybe one of the topics on the agenda of both the Board and the Council
>> could be how to move this to a no-pay Internet platform, such as the one
>> I have suggested (and whose address I now happily forget...).
>>
>> So long,
>>
>>     P.
>>
>> On 13/12/12 14:42, Rebecca Welzenbach wrote:
>>> I was just looking for connection details as well. I see the conference
>>> scheduled for 4 p.m. GMT (which would be 8 a.m. for Martin, I think).
>>>
>>>
>>> On Thu, Dec 13, 2012 at 8:36 AM, Martin Holmes <mholmes at uvic.ca> wrote:
>>>
>>>> Hi all,
>>>>
>>>> I have a teleconference on my agenda for today (4 my time, 8GMT). Is it
>>>> still on, and if so, what are the connection instructions?
>>>>
>>>> Cheers,
>>>> Martin
>>>> --
>>>> Martin Holmes
>>>> mholmes at uvic.ca
>>>> UVic Humanities Computing and Media Centre
>>>> --
>>>> 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 Gabriel BODARD
(Research Associate in Digital Epigraphy)

Department of Digital Humanities
King's College London
26-29 Drury Lane
London WC2B 5RL

Email: gabriel.bodard at kcl.ac.uk
Tel: +44 (0)20 7848 1388
Fax: +44 (0)20 7848 2980

http://www.digitalclassicist.org/
http://www.currentepigraphy.org/


From mholmes at uvic.ca  Thu Dec 13 10:44:34 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Thu, 13 Dec 2012 07:44:34 -0800
Subject: [tei-council] Council teleconference still on?
In-Reply-To: <50C9E7AA.2010906@it.ox.ac.uk>
References: <50C9D9DC.6070503@uvic.ca>
	<CAA2irtL7sUK3yCur8t80vskfZacFgXdQtiq3n94yHEEkGRYQ7g@mail.gmail.com>
	<50C9E5B9.7090903@o2.pl> <50C9E7AA.2010906@it.ox.ac.uk>
Message-ID: <50C9F7E2.8020506@uvic.ca>

I successfully used Skype from Canada last time, and I'm hoping I can do 
so again, so I can use headphones. On the regular phone it's virtually 
impossible to type.

Cheers,
Martin

On 12-12-13 06:35 AM, James Cummings wrote:
> Apologies for the delay in distributing this information.
>
> We'll be using the same conferencing system as last time run by
> economyconferencecall.com.  This should allow you to dial in
> toll-free and is using an account that is being used for the
> Board as well and the TEI-C will pay for the toll-free calls.
> (Though the cost is per call so if you are in the same location
> as another council member, do consider sharing a
> conference/speaker phone.)
>
> I've got the toll free numbers for:
>
> US and Canada: 866-906-0040
> France (excl. Monaco): 0-800-916-758
> Germany: 0-800-182-0270
> New Zealand: 0-800-446-259
> Poland: 00-800-112-4271 (0.35 zloty charge)
> UK: 0-800-635-0541
>
> (If you need a different country number, please contact me asap.)
>
> I believe it did not play well with people connecting via skype.
>
> Dial the appropriate number, and then enter the access code:
> 4614041 followed by the # button.
>
> You'll be asked to give your name. I'm told you can mute/unmute
> your line using *6 but have never tried it myself.
>
> Can I have a volunteer to take minutes?
>
> There is a draft agenda at
> http://wiki.tei-c.org/index.php/Council
>
>
> -James
>
>
> On 13/12/12 14:27, Piotr Ba?ski wrote:
>> Oh gosh, and I've just realised that I have no idea of how to get an
>> external connection from the office, and whether I can get it at all.
>>
>> Maybe one of the topics on the agenda of both the Board and the Council
>> could be how to move this to a no-pay Internet platform, such as the one
>> I have suggested (and whose address I now happily forget...).
>>
>> So long,
>>
>>     P.
>>
>> On 13/12/12 14:42, Rebecca Welzenbach wrote:
>>> I was just looking for connection details as well. I see the conference
>>> scheduled for 4 p.m. GMT (which would be 8 a.m. for Martin, I think).
>>>
>>>
>>> On Thu, Dec 13, 2012 at 8:36 AM, Martin Holmes <mholmes at uvic.ca> wrote:
>>>
>>>> Hi all,
>>>>
>>>> I have a teleconference on my agenda for today (4 my time, 8GMT). Is it
>>>> still on, and if so, what are the connection instructions?
>>>>
>>>> Cheers,
>>>> Martin
>>>> --
>>>> Martin Holmes
>>>> mholmes at uvic.ca
>>>> UVic Humanities Computing and Media Centre
>>>> --
>>>> tei-council mailing list
>>>> tei-council at lists.village.Virginia.EDU
>>>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>>>>
>>>> PLEASE NOTE: postings to this list are publicly archived
>>>>
>>
>
>

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From mholmes at uvic.ca  Thu Dec 13 10:51:48 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Thu, 13 Dec 2012 07:51:48 -0800
Subject: [tei-council] Google id for sharing minutes
Message-ID: <50C9F994.3060208@uvic.ca>

Hi all,

If you want to be able to hack at the minutes as we go, please send me 
your Google id and I'll share the doc with you. It's here:

<https://docs.google.com/document/d/1S-9tOBPDzuc3D_FaSX-PN-wrBhIjG8fDRJ0XmHd7DiE/edit>

Cheers,
Martin
-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From sebastian.rahtz at it.ox.ac.uk  Thu Dec 13 11:25:34 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Thu, 13 Dec 2012 16:25:34 +0000
Subject: [tei-council] council members using Sourceforge
Message-ID: <CCDFCA41-6995-43C4-AB74-6FB3E7DC9291@it.ox.ac.uk>

if Hugh or Elli want to be able to do TEI tickets on Sourceforge, they need to tell one of the admins
(me, Lou, James, Martin) to add them to the list of project members
--
Sebastian Rahtz      
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431


From kevin.s.hawkins at ultraslavonic.info  Thu Dec 13 11:45:29 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Thu, 13 Dec 2012 11:45:29 -0500
Subject: [tei-council] outstanding questions regarding P4 deprecation in the
	Vault
Message-ID: <50CA0629.50006@ultraslavonic.info>

Per our discussion during today's conf call, I'm asking you all for any 
comments you have on these outstanding matters related to moving P4 to 
the Vault.

A) What do we do about files in http://www.tei-c.org/Guidelines/DTD/ ? 
(which is the same except whitespace for content originally at 
http://www.tei-c.org/P4X/DTD/ and now at 
http://www.tei-c.org/Vault/P4/xml/schema/dtd/ ) Do we leave these files 
there so they can be directly found as targets of the P4 DTD (typically 
invoked as http://www.tei-c.org/Guidelines/DTD/tei2.dtd), or do we put 
in permanent redirects to the Vault location?

B) What do we do about 
http://www.tei-c.org/Guidelines/Customization/Lite/DTD/ ? The URL that 
is used for the P4 TEI Lite DTD in oXygen and no doubt elsewhere points 
to http://www.tei-c.org/Lite/DTD/teixlite.dtd , which in turn redirects 
to http://www.tei-c.org/Guidelines/Customization/Lite/DTD/teixlite.dtd .

C) The link at http://www.tei-c.org/Guidelines/ for P4 now points to the 
Vault. Any objections to removing mention of P4 from this page entirely 
(since it's no longer supported)?

D) James has suggested adding a note at the top of 
http://www.tei-c.org/Vault/P4/doc/html/index.html ? or to all HTML files 
? noting that P4 is no longer supported. Kevin notes that we didn't 
attempt to do this with P1, P2, and P3 as far as I know, and I don't 
think it's worth the effort for P4. People who are using it already know 
it's not current, and the fact that 'Vault/' is now in the URL should 
clue them in if they've somehow had their head in the ground for the 
past five years.

--Kevin

From sebastian.rahtz at gmail.com  Thu Dec 13 12:04:23 2012
From: sebastian.rahtz at gmail.com (Sebastian Rahtz)
Date: Thu, 13 Dec 2012 17:04:23 +0000
Subject: [tei-council] G'hub vs SF
Message-ID: <B17EC521-15C5-4CD5-9963-F0ECF74B84EC@gmail.com>

Actually, I do have a proposal. which is to move the entire development of Stylesheets
to Github, with all its fandangles like docx to TEI; and to maintain a stable
fork of a subset for the TEI-C. 

so this lets me fool around in public, hopefully with other people,
doing a community work on TEI <--> XXX; while separately,
more slowly, making sure the Consortium gets its outputs right.

feel free to shoot me down
--
Sebastian Rahtz      
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431


From mholmes at uvic.ca  Thu Dec 13 12:18:31 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Thu, 13 Dec 2012 09:18:31 -0800
Subject: [tei-council] Minutes from the meeting
Message-ID: <50CA0DE7.3050709@uvic.ca>

Hi all,

The Council meeting minutes are here:

<https://docs.google.com/document/d/1S-9tOBPDzuc3D_FaSX-PN-wrBhIjG8fDRJ0XmHd7DiE/edit>

Anyone can edit them, but I've saved a local copy just in case of vandalism.

Please read and amend as appropriate -- I'm sort of condensing-as-I-go, 
so I may well have misrepresented what you said, or misattributed some 
contributions (it's harder to tell who's talking with some new folks there).

I'll leave the doc there for a few days, then I'll call time and mark it 
up to go on the website through the CMS as usual.

Thanks everyone!

Cheers,
Martin

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From mholmes at uvic.ca  Thu Dec 13 12:27:33 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Thu, 13 Dec 2012 09:27:33 -0800
Subject: [tei-council] G'hub vs SF
In-Reply-To: <B17EC521-15C5-4CD5-9963-F0ECF74B84EC@gmail.com>
References: <B17EC521-15C5-4CD5-9963-F0ECF74B84EC@gmail.com>
Message-ID: <50CA1005.9060209@uvic.ca>

I bet this will double your work. You'll get lots of contributors 
breaking the Stylesheets in GitHub, or making changes you have to mess 
with, and then you'll have a tremendous job filtering out the desired 
from the undesirable changes to be migrated over to the SF fork; and 
over time, the two projects will drift further and further apart.

I think I would be more in favour of making the Stylesheets an official 
project, and taking a more cautious approach to their development, so 
you don't feel you have to leap in and fix things at midnight whenever a 
ticket comes in, because you're the only one competent to edit the code. 
I have long had the intention of forcing myself to learn how all that 
works, so I could be some sort of backup for you, but lots of other 
tickets have got in the way of that. Perhaps we could make a concerted 
plan for a few of us to take some of that weight off you.

On the other hand, if what you'd really like to do is hack away merrily 
every midnight without worrying that you're going to break the builds on 
Jenkins, then forking would be the obvious solution. :-)

Cheers,
Martin

On 12-12-13 09:04 AM, Sebastian Rahtz wrote:
> Actually, I do have a proposal. which is to move the entire development of Stylesheets
> to Github, with all its fandangles like docx to TEI; and to maintain a stable
> fork of a subset for the TEI-C.
>
> so this lets me fool around in public, hopefully with other people,
> doing a community work on TEI <--> XXX; while separately,
> more slowly, making sure the Consortium gets its outputs right.
>
> feel free to shoot me down
> --
> Sebastian Rahtz
> Director (Research Support) of Academic IT Services
> University of Oxford IT Services
> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From gabriel.bodard at kcl.ac.uk  Thu Dec 13 12:31:23 2012
From: gabriel.bodard at kcl.ac.uk (Gabriel Bodard)
Date: Thu, 13 Dec 2012 17:31:23 +0000
Subject: [tei-council] Code bounty candidate tools
Message-ID: <50CA10EB.9010504@kcl.ac.uk>

As discussed in the teleconf today, here are the tools/activities that 
have been suggested so far that would benefit from community support 
and/or some dedicated (and paid) coder time:

1. Byzantium / Roma replacement (pending discussion of Sebastian's proof 
of concept)

2. "Foxtrot" tool: Lou's proposed tool to solve the Durand Conundrum 
(can you remind us what this does and what the problem is that it solves?)

3. XPointer reference implementation (pending discussion of Hugh's proposal)

Any other suggestions we should add to this list before we start 
discussing priorities?

G

-- 
Dr Gabriel BODARD
(Research Associate in Digital Epigraphy)

Department of Digital Humanities
King's College London
26-29 Drury Lane
London WC2B 5RL

Email: gabriel.bodard at kcl.ac.uk
Tel: +44 (0)20 7848 1388
Fax: +44 (0)20 7848 2980

http://www.digitalclassicist.org/
http://www.currentepigraphy.org/


From lou.burnard at retired.ox.ac.uk  Thu Dec 13 12:37:17 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Thu, 13 Dec 2012 17:37:17 +0000
Subject: [tei-council] Code bounty candidate tools
In-Reply-To: <50CA10EB.9010504@kcl.ac.uk>
References: <50CA10EB.9010504@kcl.ac.uk>
Message-ID: <50CA124D.4040602@retired.ox.ac.uk>

On 13/12/12 17:31, Gabriel Bodard wrote:
> 2. "Foxtrot" tool: Lou's proposed tool to solve the Durand Conundrum
> (can you remind us what this does and what the problem is that it solves?)

I am not sure why this got on the list of tools : the proposal is to 
make some revisions to the existing ODD format so as to enable 
everything to be expressed in TEI ODD, instead of having some bits 
expressed in a subset of RELAXNG. I believe  I am supposed to be 
completing and testing the existing proposal but would of course welcome 
input from anyone interested. When (if) the spec is completed, then  
some existing ODD processing tools may wish to change the ways they 
generate schemas, etc, but I don't see that there's need for any 
specific tool here.


From gabriel.bodard at kcl.ac.uk  Thu Dec 13 12:46:14 2012
From: gabriel.bodard at kcl.ac.uk (Gabriel Bodard)
Date: Thu, 13 Dec 2012 17:46:14 +0000
Subject: [tei-council] Code bounty candidate tools
In-Reply-To: <50CA124D.4040602@retired.ox.ac.uk>
References: <50CA10EB.9010504@kcl.ac.uk> <50CA124D.4040602@retired.ox.ac.uk>
Message-ID: <50CA1466.5040804@kcl.ac.uk>

So is it the case that ideally the completion of this work would be a 
precondition for speccing a new Roma? (I'm trying to reconstruct why we 
thought a code bounty might help with this... I guess I need to dig out 
the minutes of Oxford... unless I'm just misremembering that?)

On 13/12/2012 17:37, Lou Burnard wrote:
> On 13/12/12 17:31, Gabriel Bodard wrote:
>> 2. "Foxtrot" tool: Lou's proposed tool to solve the Durand Conundrum
>> (can you remind us what this does and what the problem is that it solves?)
>
> I am not sure why this got on the list of tools : the proposal is to
> make some revisions to the existing ODD format so as to enable
> everything to be expressed in TEI ODD, instead of having some bits
> expressed in a subset of RELAXNG. I believe  I am supposed to be
> completing and testing the existing proposal but would of course welcome
> input from anyone interested. When (if) the spec is completed, then
> some existing ODD processing tools may wish to change the ways they
> generate schemas, etc, but I don't see that there's need for any
> specific tool here.
>

-- 
Dr Gabriel BODARD
(Research Associate in Digital Epigraphy)

Department of Digital Humanities
King's College London
26-29 Drury Lane
London WC2B 5RL

Email: gabriel.bodard at kcl.ac.uk
Tel: +44 (0)20 7848 1388
Fax: +44 (0)20 7848 2980

http://www.digitalclassicist.org/
http://www.currentepigraphy.org/


From lou.burnard at retired.ox.ac.uk  Thu Dec 13 12:50:53 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Thu, 13 Dec 2012 17:50:53 +0000
Subject: [tei-council] outstanding questions regarding P4 deprecation in
 the Vault
In-Reply-To: <50CA0629.50006@ultraslavonic.info>
References: <50CA0629.50006@ultraslavonic.info>
Message-ID: <50CA157D.70808@retired.ox.ac.uk>

On 13/12/12 16:45, Kevin Hawkins wrote:
>
> A) What do we do about files in http://www.tei-c.org/Guidelines/DTD/ ?
shd be permanent redirects to the Vault
> B) What do we do about
> http://www.tei-c.org/Guidelines/Customization/Lite/DTD/ ? The URL that
> is used for the P4 TEI Lite DTD in oXygen and no doubt elsewhere points
> to http://www.tei-c.org/Lite/DTD/teixlite.dtd , which in turn redirects
> to http://www.tei-c.org/Guidelines/Customization/Lite/DTD/teixlite.dtd .
Not sure I understand the question. The p4 teilite dtd is not supported 
anymore, is it? so these should be in the vault too.

>
> C) The link at http://www.tei-c.org/Guidelines/ for P4 now points to the
> Vault. Any objections to removing mention of P4 from this page entirely
> (since it's no longer supported)?

No strong objection, but it might be kind to add a sentence to the 
effect that older versions of the Guidelines (P1, P32, P3, and P4) are 
all available from the Vault.

>
> D) James has suggested adding a note at the top of
> http://www.tei-c.org/Vault/P4/doc/html/index.html ? or to all HTML files
> ? noting that P4 is no longer supported. Kevin notes that we didn't
> attempt to do this with P1, P2, and P3 as far as I know, and I don't
> think it's worth the effort for P4. People who are using it already know
> it's not current, and the fact that 'Vault/' is now in the URL should
> clue them in if they've somehow had their head in the ground for the
> past five years.

I can understand the desire to add warning messages or a popup that says 
"Warning ! You are using a superannuated version of the TEI Guidelines! 
Don't blame us if everything goes wrong! "  but I share your feeling 
that it's probably unnecessary.



From lou.burnard at retired.ox.ac.uk  Thu Dec 13 12:58:31 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Thu, 13 Dec 2012 17:58:31 +0000
Subject: [tei-council] G'hub vs SF
In-Reply-To: <B17EC521-15C5-4CD5-9963-F0ECF74B84EC@gmail.com>
References: <B17EC521-15C5-4CD5-9963-F0ECF74B84EC@gmail.com>
Message-ID: <50CA1747.5080007@retired.ox.ac.uk>

On 13/12/12 17:04, Sebastian Rahtz wrote:
> Actually, I do have a proposal. which is to move the entire development of Stylesheets
> to Github, with all its fandangles like docx to TEI; and to maintain a stable
> fork of a subset for the TEI-C.

That makes more sense. Assuming you can clearly identify the "stable 
fork subset". I assume the touchstone is that it's used to generate a 
release of TEI P5 then  it must be in the sf repo, and the rules about 
who can modify it  and with what level of testing are a little fiercer. 
So teitohtml is needed, as is teitolatex (for the PDF generation) but 
teitodocx is not. How about teitoepub?




From elli_mylonas at brown.edu  Thu Dec 13 14:38:41 2012
From: elli_mylonas at brown.edu (Mylonas, Elli)
Date: Thu, 13 Dec 2012 14:38:41 -0500
Subject: [tei-council] Doodle Poll for Spring Council meeting
Message-ID: <CAMuBKpe+vQ3zdeaB93SDGt08gvgAjzMmQPCBipm96sxnjEoh5A@mail.gmail.com>

Please visit the following link

http://www.doodle.com/58khxi5tk9eieg3i

to vote on most desirable and least desirable dates for the spring meeting.

  --elli

[Elli Mylonas
 Senior Digital Humanities Librarian
 and
 Center for Digital Scholarship
 University Library
 Brown University
 library.brown.edu/cds]

From sebastian.rahtz at it.ox.ac.uk  Thu Dec 13 17:46:37 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Thu, 13 Dec 2012 22:46:37 +0000
Subject: [tei-council] Code bounty candidate tools
In-Reply-To: <50CA1466.5040804@kcl.ac.uk>
References: <50CA10EB.9010504@kcl.ac.uk> <50CA124D.4040602@retired.ox.ac.uk>
	<50CA1466.5040804@kcl.ac.uk>
Message-ID: <44342C08-A13E-4588-B313-F3FACC0DC0AA@it.ox.ac.uk>


On 13 Dec 2012, at 17:46, Gabriel Bodard <gabriel.bodard at kcl.ac.uk> wrote:

> So is it the case that ideally the completion of this work would be a 
> precondition for speccing a new Roma? 

I dont think so. The new Roma needs to have a robust setup which deal with
changes to ODD
--
Sebastian Rahtz      
http://www.justgiving.com/SebastianRahtz
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431


From sebastian.rahtz at it.ox.ac.uk  Thu Dec 13 18:15:28 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Thu, 13 Dec 2012 23:15:28 +0000
Subject: [tei-council] outstanding questions regarding P4 deprecation in
 the	Vault
In-Reply-To: <50CA0629.50006@ultraslavonic.info>
References: <50CA0629.50006@ultraslavonic.info>
Message-ID: <3BBC4B9B-5F21-4A6A-9A85-1CDEB7BD7666@it.ox.ac.uk>


On 13 Dec 2012, at 16:45, Kevin Hawkins <kevin.s.hawkins at ultraslavonic.info> wrote:
> A) What do we do about files in http://www.tei-c.org/Guidelines/DTD/ ? 
> (which is the same except whitespace for content originally at 
> http://www.tei-c.org/P4X/DTD/ and now at 
> http://www.tei-c.org/Vault/P4/xml/schema/dtd/ ) Do we leave these files 
> there so they can be directly found as targets of the P4 DTD (typically 
> invoked as http://www.tei-c.org/Guidelines/DTD/tei2.dtd), or do we put 
> in permanent redirects to the Vault location?
permanent redirects, I'd say
> 
> B) What do we do about 
> http://www.tei-c.org/Guidelines/Customization/Lite/DTD/ ? The URL that 
> is used for the P4 TEI Lite DTD in oXygen and no doubt elsewhere points 
> to http://www.tei-c.org/Lite/DTD/teixlite.dtd , which in turn redirects 
> to http://www.tei-c.org/Guidelines/Customization/Lite/DTD/teixlite.dtd .

oh lord. that sounds like a horrible mess. I dont have a simple answer
> 
> C) The link at http://www.tei-c.org/Guidelines/ for P4 now points to the 
> Vault. Any objections to removing mention of P4 from this page entirely 
> (since it's no longer supported)?
I'd say yes

> 
> D) James has suggested adding a note at the top of 
> http://www.tei-c.org/Vault/P4/doc/html/index.html ? or to all HTML files 
> ? noting that P4 is no longer supported. Kevin notes that we didn't 
> attempt to do this with P1, P2, and P3 as far as I know, and I don't 
> think it's worth the effort for P4. People who are using it already know 
> it's not current, and the fact that 'Vault/' is now in the URL should 
> clue them in if they've somehow had their head in the ground for the 
> past five years.

I'm agreeing with Kevin
--
Sebastian Rahtz      
http://www.justgiving.com/SebastianRahtz
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431


From mholmes at uvic.ca  Sat Dec 15 01:51:35 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Fri, 14 Dec 2012 22:51:35 -0800
Subject: [tei-council] [TEI-DIR-WG] Rotation and Reflection
In-Reply-To: <50CBDC13.4080802@nmu.edu>
References: <CANLs5w17Q6pfTs9Tnb7oQonaweT1L2eikzywnpgsbksAxuDsgw@mail.gmail.com>
	<50C90F2F.60506@uvic.ca>
	<CANLs5w1bYsEx2-pjWwmwgNwSgcnrfmxb0o0adyKVcaT9bP4eUw@mail.gmail.com>
	<50CA48CC.2030908@uvic.ca>
	<6DBB140D-7873-4D01-A40E-05E9C0AC07C7@nmu.edu>
	<50CB5DF0.7050503@uvic.ca> <50CBDC13.4080802@nmu.edu>
Message-ID: <50CC1DF7.4090907@uvic.ca>

Hi Rob,

This is a publicly-archived list, so if that login is sensitive, you 
might want to change it.

Nice XML! It's good to see it available. Not enough sites do that.

Cheers,
Martin

On 12-12-14 06:10 PM, Robert Whalen wrote:
> Perhaps the best way for everyone to see the "Easter Wings" example is
> to go to the following site, complements of UVaP using the temporary
> username/password herbert1633 (same for both):
>
> http://digitaltemple.rotunda.upress.virginia.edu
>
> Go to parallel display and find Easter Wings using one of the drop
> downs. The rest is pretty intuitive. Note the link to the TEI-XML.
>
> Cheers,
> Rob
>
> On 12/14/12 12:12 PM, Martin Holmes wrote:
>>
>>
>> On 12-12-14 02:17 AM, Rob Whalen wrote:
>>> On Dec 13, 2012, at 4:29 PM, Martin Holmes <mholmes at uvic.ca> wrote:
>>>
>>>> I'd like to bring in Robert and Stella here. Robert, does it seem
>>>> to you that what's happening in Easter Wings is something very
>>>> different from what's happening when Japanese is written (as it
>>>> normally is, in a lot of contexts) from top-to-bottom, left to
>>>> right?
>>>
>>> Clearly what's happening in ewings is entirely different. From a
>>> writing or reading perspective, it's not an instance of t to b and l
>>> to r but rather a block of text rotated clockwise 90 degrees. The
>>> question for me is how best to capture this in a TEI-XML
>>> transcription so as NOT semantically to suggest a t to b reading
>>> orientation, and to render the rotated block in the display. An added
>>> wrinkle, as concerns the encoded transcription, is that of the three
>>> witnesses to the poem (encoded using TEI parallel segmentation), only
>>> one is rotated. I'd like to preserve the line by line parallel
>>> encoding while capturing the rotated orientation of the one witness
>>> and writing XSL and CSS to handle it effectively.
>>
>> This is an interesting wrinkle that I hadn't really thought about, but
>> now you raise it, it's obvious: whatever we choose to do to represent
>> both text directionality and rotational phenomena must be expressible
>> in ways which make it easy to connect it with specific witnesses or
>> readings. Your encoding should be one of our test cases here.
>>
>> Cheers,
>> Martin
>>
>>>> Stella, are there any instances in which Arabic might be written
>>>> vertically? I don't recall seeing anything like that, but with shop
>>>> signs etc. I guess it might happen. If it does happen, what is the
>>>> effect on the shapes of glyphs? IIRC the shape of a glyph in Arabic
>>>> is dependent on context, and enables the clean joining of glyph
>>>> sequences.
>>>>
>>>> It occurs to me that one of our test cases for encoding complex
>>>> rotational phenomena might be a captcha image; these often show
>>>> letters partially rotated, and sometimes skewed in ways which mimic
>>>> 3D rotation.
>>>>
>>>> Which brings me to a more general point: I'd like to start
>>>> gathering a set of small but interesting test cases -- real
>>>> documents, as short as we can find them, which cover all the
>>>> phenomena we need to deal with. Easter Wings is one. It would be
>>>> great to get examples of all the Japanese variants, Greek written
>>>> right-to-left (I didn't even know that happened until recently),
>>>> and English written vertically with letters both upright and not.
>>>> If you have examples of texts that would be useful, especially if
>>>> you have a page-image, and _especially_ if there are no
>>>> restrictions on use of same so we could actually consider putting
>>>> it in the Guidelines, please send them along.
>>>>
>>>> Cheers, Martin
>>>>
>>>> On 12-12-13 12:31 PM, Marcus Bingenheimer wrote:
>>>>> Hi Martin,
>>>>>
>>>>> I like the logic of replacing reflection with rotation. Apart
>>>>> from Ockham's razor it opens up new games like: What is this: ".
>>>>> ._ _ _  _ _ _"" (answer: Non-serif "I love you" rotated 90 deg on
>>>>> the x-axis). We should default the value for x and y rotation to
>>>>> 180 deg, however, as most writing happens in 2D and the
>>>>> introduction of 3D opens a can of worms. We do not want people to
>>>>> think that we want to describe character "thinkness" or the
>>>>> spherical qualities of an "o" ring with TEI. To say nothing of 4D
>>>>> animations, let's leave that to TEI P8.
>>>>>
>>>>> I also like the idea of distinguishing between "rotational
>>>>> effects" and "directionality". One can indeed argue that some
>>>>> directions are merely a secondary effect introduced by a
>>>>> typesetter or an artist, and that writing system have a innate
>>>>> direction (or two equally valid ones as in Ch or Jp). For
>>>>> instance, the Mongolian word in the Unicode example (Sec.3.3) is
>>>>> not "actually" written that way, I would say that it is written
>>>>> top-to-bottom and then rotated counter-clockwise 90deg.
>>>>>
>>>>> all the best
>>>>>
>>>>> marcus
>>>>>
>>>>>
>>>>> -- Dr. Marcus Bingenheimer ??? Department of Religion, Temple
>>>>> University http://mbingenheimer.net
>>>>
>>>> -- Martin Holmes University of Victoria Humanities Computing and
>>>> Media Centre (mholmes at uvic.ca)
>>
>
> --
>
> Robert Whalen, PhD
>
> Professor, Department of English
>
> Northern Michigan University
>
> 1401 Presque Isle Avenue
>
> Marquette, MI 49855
>
> 906-227-2678
>
> Office hours: Monday and Wednesday, 8:10-9:50 and 4:40-5:30
>
> rwhalen at nmu.edu <mailto:rwhalen at nmu.edu>
>
> http://myweb.nmu.edu/~rwhalen/home.htm
> <http://myweb.nmu.edu/%7Erwhalen/home.htm>
>
> /The truth will set you free. But not until it?s finished with you./
>
> - David Foster Wallace
>

-- 
Martin Holmes
mholmes at uvic.ca
UVic Humanities Computing and Media Centre

From mholmes at uvic.ca  Sat Dec 15 02:00:41 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Fri, 14 Dec 2012 23:00:41 -0800
Subject: [tei-council] [TEI-DIR-WG] Rotation and Reflection
In-Reply-To: <50CC1DF7.4090907@uvic.ca>
References: <CANLs5w17Q6pfTs9Tnb7oQonaweT1L2eikzywnpgsbksAxuDsgw@mail.gmail.com>
	<50C90F2F.60506@uvic.ca>
	<CANLs5w1bYsEx2-pjWwmwgNwSgcnrfmxb0o0adyKVcaT9bP4eUw@mail.gmail.com>
	<50CA48CC.2030908@uvic.ca>	<6DBB140D-7873-4D01-A40E-05E9C0AC07C7@nmu.edu>
	<50CB5DF0.7050503@uvic.ca> <50CBDC13.4080802@nmu.edu>
	<50CC1DF7.4090907@uvic.ca>
Message-ID: <50CC2019.1040201@uvic.ca>

Sorry, sent this to the wrong list. Especially ironic, given the content...

On 12-12-14 10:51 PM, Martin Holmes wrote:
> Hi Rob,
>
> This is a publicly-archived list, so if that login is sensitive, you
> might want to change it.
>
> Nice XML! It's good to see it available. Not enough sites do that.
>
> Cheers,
> Martin
>
> On 12-12-14 06:10 PM, Robert Whalen wrote:

>> http://digitaltemple.rotunda.upress.virginia.edu
>>
>> Go to parallel display and find Easter Wings using one of the drop
>> downs. The rest is pretty intuitive. Note the link to the TEI-XML.
>>
>> Cheers,
>> Rob
>>
>> On 12/14/12 12:12 PM, Martin Holmes wrote:
>>>
>>>
>>> On 12-12-14 02:17 AM, Rob Whalen wrote:
>>>> On Dec 13, 2012, at 4:29 PM, Martin Holmes <mholmes at uvic.ca> wrote:
>>>>
>>>>> I'd like to bring in Robert and Stella here. Robert, does it seem
>>>>> to you that what's happening in Easter Wings is something very
>>>>> different from what's happening when Japanese is written (as it
>>>>> normally is, in a lot of contexts) from top-to-bottom, left to
>>>>> right?
>>>>
>>>> Clearly what's happening in ewings is entirely different. From a
>>>> writing or reading perspective, it's not an instance of t to b and l
>>>> to r but rather a block of text rotated clockwise 90 degrees. The
>>>> question for me is how best to capture this in a TEI-XML
>>>> transcription so as NOT semantically to suggest a t to b reading
>>>> orientation, and to render the rotated block in the display. An added
>>>> wrinkle, as concerns the encoded transcription, is that of the three
>>>> witnesses to the poem (encoded using TEI parallel segmentation), only
>>>> one is rotated. I'd like to preserve the line by line parallel
>>>> encoding while capturing the rotated orientation of the one witness
>>>> and writing XSL and CSS to handle it effectively.
>>>
>>> This is an interesting wrinkle that I hadn't really thought about, but
>>> now you raise it, it's obvious: whatever we choose to do to represent
>>> both text directionality and rotational phenomena must be expressible
>>> in ways which make it easy to connect it with specific witnesses or
>>> readings. Your encoding should be one of our test cases here.
>>>
>>> Cheers,
>>> Martin
>>>
>>>>> Stella, are there any instances in which Arabic might be written
>>>>> vertically? I don't recall seeing anything like that, but with shop
>>>>> signs etc. I guess it might happen. If it does happen, what is the
>>>>> effect on the shapes of glyphs? IIRC the shape of a glyph in Arabic
>>>>> is dependent on context, and enables the clean joining of glyph
>>>>> sequences.
>>>>>
>>>>> It occurs to me that one of our test cases for encoding complex
>>>>> rotational phenomena might be a captcha image; these often show
>>>>> letters partially rotated, and sometimes skewed in ways which mimic
>>>>> 3D rotation.
>>>>>
>>>>> Which brings me to a more general point: I'd like to start
>>>>> gathering a set of small but interesting test cases -- real
>>>>> documents, as short as we can find them, which cover all the
>>>>> phenomena we need to deal with. Easter Wings is one. It would be
>>>>> great to get examples of all the Japanese variants, Greek written
>>>>> right-to-left (I didn't even know that happened until recently),
>>>>> and English written vertically with letters both upright and not.
>>>>> If you have examples of texts that would be useful, especially if
>>>>> you have a page-image, and _especially_ if there are no
>>>>> restrictions on use of same so we could actually consider putting
>>>>> it in the Guidelines, please send them along.
>>>>>
>>>>> Cheers, Martin
>>>>>
>>>>> On 12-12-13 12:31 PM, Marcus Bingenheimer wrote:
>>>>>> Hi Martin,
>>>>>>
>>>>>> I like the logic of replacing reflection with rotation. Apart
>>>>>> from Ockham's razor it opens up new games like: What is this: ".
>>>>>> ._ _ _  _ _ _"" (answer: Non-serif "I love you" rotated 90 deg on
>>>>>> the x-axis). We should default the value for x and y rotation to
>>>>>> 180 deg, however, as most writing happens in 2D and the
>>>>>> introduction of 3D opens a can of worms. We do not want people to
>>>>>> think that we want to describe character "thinkness" or the
>>>>>> spherical qualities of an "o" ring with TEI. To say nothing of 4D
>>>>>> animations, let's leave that to TEI P8.
>>>>>>
>>>>>> I also like the idea of distinguishing between "rotational
>>>>>> effects" and "directionality". One can indeed argue that some
>>>>>> directions are merely a secondary effect introduced by a
>>>>>> typesetter or an artist, and that writing system have a innate
>>>>>> direction (or two equally valid ones as in Ch or Jp). For
>>>>>> instance, the Mongolian word in the Unicode example (Sec.3.3) is
>>>>>> not "actually" written that way, I would say that it is written
>>>>>> top-to-bottom and then rotated counter-clockwise 90deg.
>>>>>>
>>>>>> all the best
>>>>>>
>>>>>> marcus
>>>>>>
>>>>>>
>>>>>> -- Dr. Marcus Bingenheimer ??? Department of Religion, Temple
>>>>>> University http://mbingenheimer.net
>>>>>
>>>>> -- Martin Holmes University of Victoria Humanities Computing and
>>>>> Media Centre (mholmes at uvic.ca)
>>>
>>
>> --
>>
>> Robert Whalen, PhD
>>
>> Professor, Department of English
>>
>> Northern Michigan University
>>
>> 1401 Presque Isle Avenue
>>
>> Marquette, MI 49855
>>
>> 906-227-2678
>>
>> Office hours: Monday and Wednesday, 8:10-9:50 and 4:40-5:30
>>
>> rwhalen at nmu.edu <mailto:rwhalen at nmu.edu>
>>
>> http://myweb.nmu.edu/~rwhalen/home.htm
>> <http://myweb.nmu.edu/%7Erwhalen/home.htm>
>>
>> /The truth will set you free. But not until it?s finished with you./
>>
>> - David Foster Wallace
>>
>

-- 
Martin Holmes
mholmes at uvic.ca
UVic Humanities Computing and Media Centre

From kevin.s.hawkins at ultraslavonic.info  Sun Dec 16 12:15:56 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Sun, 16 Dec 2012 12:15:56 -0500
Subject: [tei-council] outstanding questions regarding P4 deprecation in
 the Vault
In-Reply-To: <50CA157D.70808@retired.ox.ac.uk>
References: <50CA0629.50006@ultraslavonic.info>
	<50CA157D.70808@retired.ox.ac.uk>
Message-ID: <50CE01CC.3090806@ultraslavonic.info>



On 12/13/12 12:50 PM, Lou Burnard wrote:
> On 13/12/12 16:45, Kevin Hawkins wrote:
>>
>> A) What do we do about files in http://www.tei-c.org/Guidelines/DTD/ ?
> shd be permanent redirects to the Vault

Noted.

>> B) What do we do about
>> http://www.tei-c.org/Guidelines/Customization/Lite/DTD/ ? The URL that
>> is used for the P4 TEI Lite DTD in oXygen and no doubt elsewhere points
>> to http://www.tei-c.org/Lite/DTD/teixlite.dtd , which in turn redirects
>> to http://www.tei-c.org/Guidelines/Customization/Lite/DTD/teixlite.dtd .
> Not sure I understand the question. The p4 teilite dtd is not supported
> anymore, is it? so these should be in the vault too.

Yes, you're right.  David and I overlooked that, I didn't think it 
through before relaying this question that arose to all of you.  I'm 
working on plan for migrating Lite P4 to the Vault.  David or I might 
come back to Lou asking for a technically correct description of P4 Lite.

>> C) The link at http://www.tei-c.org/Guidelines/ for P4 now points to the
>> Vault. Any objections to removing mention of P4 from this page entirely
>> (since it's no longer supported)?
>
> No strong objection, but it might be kind to add a sentence to the
> effect that older versions of the Guidelines (P1, P32, P3, and P4) are
> all available from the Vault.

I didn't want to list some but not all deprecated versions, but I like 
this approach.  After all, people looking for an old version might well 
start at http://www.tei-c.org/Guidelines/ and not think to go look in 
the Vault.

>> D) James has suggested adding a note at the top of
>> http://www.tei-c.org/Vault/P4/doc/html/index.html ? or to all HTML files
>> ? noting that P4 is no longer supported. Kevin notes that we didn't
>> attempt to do this with P1, P2, and P3 as far as I know, and I don't
>> think it's worth the effort for P4. People who are using it already know
>> it's not current, and the fact that 'Vault/' is now in the URL should
>> clue them in if they've somehow had their head in the ground for the
>> past five years.
>
> I can understand the desire to add warning messages or a popup that says
> "Warning ! You are using a superannuated version of the TEI Guidelines!
> Don't blame us if everything goes wrong! "  but I share your feeling
> that it's probably unnecessary.

Noted.

--K.

From mholmes at uvic.ca  Mon Dec 17 12:11:00 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Mon, 17 Dec 2012 09:11:00 -0800
Subject: [tei-council] Some working papers the new Council members might
	like to look at
Message-ID: <50CF5224.9070605@uvic.ca>

Hi all,

During the teleconference, James mentioned that there are some useful 
resources on the wiki for Council members. There are also some helpful 
documents on the TEI site itself, in the working papers:

TCW 20: "How to edit the TEI Guidelines"
<http://www.tei-c.org/Activities/Council/Working/tcw20.xml>

This is a work-in-progress which endeavours to explain how the 
Guidelines are built, and how to make changes and check that your 
changes have worked. Now I come to look at it, I see at least one thing 
which is out of date (it tells you to use <!ENTITY...> declarations when 
you add a new file, and we've now switched over to XInclude, so I'll 
have to update that bit). But that aside, I think it's helpful.

TCW22: "Building a TEI Release"
<http://www.tei-c.org/Activities/Council/Working/tcw22.xml>

This is the document that Hugh will have to follow when he's acting as 
the release technician in January. It aims to be a complete, 
step-by-step guide to everything that needs to happen during the release 
process. We've used it for several releases now, and every time, we've 
added more detail, clarification or correction, so it's pretty good at 
this point.

TCW 24: " Style Guide for Editing the TEI Guidelines"
<http://www.tei-c.org/Activities/Council/Working/tcw24.xml>

This is currently quite basic, but growing; it tends to be added to when 
we have some disagreement or discussion about some element of style, and 
need to record our consensus.

While you are new and getting familiar with the system, it would be 
helpful if you could make some notes on what is puzzling or 
undocumented, so we can fill those holes with better explanatory material.

Cheers,
Martin
-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From dsewell at virginia.edu  Mon Dec 17 12:59:54 2012
From: dsewell at virginia.edu (David Sewell)
Date: Mon, 17 Dec 2012 12:59:54 -0500 (EST)
Subject: [tei-council] [TEI-DIR-WG] Rotation and Reflection
In-Reply-To: <50CC2019.1040201@uvic.ca>
References: <CANLs5w17Q6pfTs9Tnb7oQonaweT1L2eikzywnpgsbksAxuDsgw@mail.gmail.com>
	<50C90F2F.60506@uvic.ca>
	<CANLs5w1bYsEx2-pjWwmwgNwSgcnrfmxb0o0adyKVcaT9bP4eUw@mail.gmail.com>
	<50CA48CC.2030908@uvic.ca>
	<6DBB140D-7873-4D01-A40E-05E9C0AC07C7@nmu.edu>
	<50CB5DF0.7050503@uvic.ca> <50CBDC13.4080802@nmu.edu>
	<50CC1DF7.4090907@uvic.ca> <50CC2019.1040201@uvic.ca>
Message-ID: <alpine.OSX.2.00.1212171259160.52461@lister.ei.virginia.edu>

No harm, as Rob's Digital Temple just launched and will be open-access for the 
next two weeks anyway.

On Fri, 14 Dec 2012, Martin Holmes wrote:

> Sorry, sent this to the wrong list. Especially ironic, given the content...
>
> On 12-12-14 10:51 PM, Martin Holmes wrote:
>> Hi Rob,
>>
>> This is a publicly-archived list, so if that login is sensitive, you
>> might want to change it.
>>
>> Nice XML! It's good to see it available. Not enough sites do that.
>>
>> Cheers,
>> Martin
>>
>> On 12-12-14 06:10 PM, Robert Whalen wrote:
>
>>> http://digitaltemple.rotunda.upress.virginia.edu
>>>
>>> Go to parallel display and find Easter Wings using one of the drop
>>> downs. The rest is pretty intuitive. Note the link to the TEI-XML.
>>>
>>> Cheers,
>>> Rob
>>>
>>> On 12/14/12 12:12 PM, Martin Holmes wrote:
>>>>
>>>>
>>>> On 12-12-14 02:17 AM, Rob Whalen wrote:
>>>>> On Dec 13, 2012, at 4:29 PM, Martin Holmes <mholmes at uvic.ca> wrote:
>>>>>
>>>>>> I'd like to bring in Robert and Stella here. Robert, does it seem
>>>>>> to you that what's happening in Easter Wings is something very
>>>>>> different from what's happening when Japanese is written (as it
>>>>>> normally is, in a lot of contexts) from top-to-bottom, left to
>>>>>> right?
>>>>>
>>>>> Clearly what's happening in ewings is entirely different. From a
>>>>> writing or reading perspective, it's not an instance of t to b and l
>>>>> to r but rather a block of text rotated clockwise 90 degrees. The
>>>>> question for me is how best to capture this in a TEI-XML
>>>>> transcription so as NOT semantically to suggest a t to b reading
>>>>> orientation, and to render the rotated block in the display. An added
>>>>> wrinkle, as concerns the encoded transcription, is that of the three
>>>>> witnesses to the poem (encoded using TEI parallel segmentation), only
>>>>> one is rotated. I'd like to preserve the line by line parallel
>>>>> encoding while capturing the rotated orientation of the one witness
>>>>> and writing XSL and CSS to handle it effectively.
>>>>
>>>> This is an interesting wrinkle that I hadn't really thought about, but
>>>> now you raise it, it's obvious: whatever we choose to do to represent
>>>> both text directionality and rotational phenomena must be expressible
>>>> in ways which make it easy to connect it with specific witnesses or
>>>> readings. Your encoding should be one of our test cases here.
>>>>
>>>> Cheers,
>>>> Martin
>>>>
>>>>>> Stella, are there any instances in which Arabic might be written
>>>>>> vertically? I don't recall seeing anything like that, but with shop
>>>>>> signs etc. I guess it might happen. If it does happen, what is the
>>>>>> effect on the shapes of glyphs? IIRC the shape of a glyph in Arabic
>>>>>> is dependent on context, and enables the clean joining of glyph
>>>>>> sequences.
>>>>>>
>>>>>> It occurs to me that one of our test cases for encoding complex
>>>>>> rotational phenomena might be a captcha image; these often show
>>>>>> letters partially rotated, and sometimes skewed in ways which mimic
>>>>>> 3D rotation.
>>>>>>
>>>>>> Which brings me to a more general point: I'd like to start
>>>>>> gathering a set of small but interesting test cases -- real
>>>>>> documents, as short as we can find them, which cover all the
>>>>>> phenomena we need to deal with. Easter Wings is one. It would be
>>>>>> great to get examples of all the Japanese variants, Greek written
>>>>>> right-to-left (I didn't even know that happened until recently),
>>>>>> and English written vertically with letters both upright and not.
>>>>>> If you have examples of texts that would be useful, especially if
>>>>>> you have a page-image, and _especially_ if there are no
>>>>>> restrictions on use of same so we could actually consider putting
>>>>>> it in the Guidelines, please send them along.
>>>>>>
>>>>>> Cheers, Martin
>>>>>>
>>>>>> On 12-12-13 12:31 PM, Marcus Bingenheimer wrote:
>>>>>>> Hi Martin,
>>>>>>>
>>>>>>> I like the logic of replacing reflection with rotation. Apart
>>>>>>> from Ockham's razor it opens up new games like: What is this: ".
>>>>>>> ._ _ _  _ _ _"" (answer: Non-serif "I love you" rotated 90 deg on
>>>>>>> the x-axis). We should default the value for x and y rotation to
>>>>>>> 180 deg, however, as most writing happens in 2D and the
>>>>>>> introduction of 3D opens a can of worms. We do not want people to
>>>>>>> think that we want to describe character "thinkness" or the
>>>>>>> spherical qualities of an "o" ring with TEI. To say nothing of 4D
>>>>>>> animations, let's leave that to TEI P8.
>>>>>>>
>>>>>>> I also like the idea of distinguishing between "rotational
>>>>>>> effects" and "directionality". One can indeed argue that some
>>>>>>> directions are merely a secondary effect introduced by a
>>>>>>> typesetter or an artist, and that writing system have a innate
>>>>>>> direction (or two equally valid ones as in Ch or Jp). For
>>>>>>> instance, the Mongolian word in the Unicode example (Sec.3.3) is
>>>>>>> not "actually" written that way, I would say that it is written
>>>>>>> top-to-bottom and then rotated counter-clockwise 90deg.
>>>>>>>
>>>>>>> all the best
>>>>>>>
>>>>>>> marcus
>>>>>>>
>>>>>>>
>>>>>>> -- Dr. Marcus Bingenheimer ??? Department of Religion, Temple
>>>>>>> University http://mbingenheimer.net
>>>>>>
>>>>>> -- Martin Holmes University of Victoria Humanities Computing and
>>>>>> Media Centre (mholmes at uvic.ca)
>>>>
>>>
>>> --
>>>
>>> Robert Whalen, PhD
>>>
>>> Professor, Department of English
>>>
>>> Northern Michigan University
>>>
>>> 1401 Presque Isle Avenue
>>>
>>> Marquette, MI 49855
>>>
>>> 906-227-2678
>>>
>>> Office hours: Monday and Wednesday, 8:10-9:50 and 4:40-5:30
>>>
>>> rwhalen at nmu.edu <mailto:rwhalen at nmu.edu>
>>>
>>> http://myweb.nmu.edu/~rwhalen/home.htm
>>> <http://myweb.nmu.edu/%7Erwhalen/home.htm>
>>>
>>> /The truth will set you free. But not until it?s finished with you./
>>>
>>> - David Foster Wallace
>>>
>>
>
> -- 
> Martin Holmes
> mholmes at uvic.ca
> UVic Humanities Computing and Media Centre
> -- 
> 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

-- 
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 elli_mylonas at brown.edu  Mon Dec 17 16:06:20 2012
From: elli_mylonas at brown.edu (Mylonas, Elli)
Date: Mon, 17 Dec 2012 16:06:20 -0500
Subject: [tei-council] Some working papers the new Council members might
 like to look at
In-Reply-To: <50CF5224.9070605@uvic.ca>
References: <50CF5224.9070605@uvic.ca>
Message-ID: <CAMuBKpc0N0N6NOMQT5nOFZEWHUtt5NzACg2+wUy3pkqEJOLpug@mail.gmail.com>

this is really helpful, thank you. --elli
[Elli Mylonas
 Senior Digital Humanities Librarian
 and
 Center for Digital Scholarship
 University Library
 Brown University
 library.brown.edu/cds]


On Mon, Dec 17, 2012 at 12:11 PM, Martin Holmes <mholmes at uvic.ca> wrote:
> Hi all,
>
> During the teleconference, James mentioned that there are some useful
> resources on the wiki for Council members. There are also some helpful
> documents on the TEI site itself, in the working papers:
>
> TCW 20: "How to edit the TEI Guidelines"
> <http://www.tei-c.org/Activities/Council/Working/tcw20.xml>
>
> This is a work-in-progress which endeavours to explain how the
> Guidelines are built, and how to make changes and check that your
> changes have worked. Now I come to look at it, I see at least one thing
> which is out of date (it tells you to use <!ENTITY...> declarations when
> you add a new file, and we've now switched over to XInclude, so I'll
> have to update that bit). But that aside, I think it's helpful.
>
> TCW22: "Building a TEI Release"
> <http://www.tei-c.org/Activities/Council/Working/tcw22.xml>
>
> This is the document that Hugh will have to follow when he's acting as
> the release technician in January. It aims to be a complete,
> step-by-step guide to everything that needs to happen during the release
> process. We've used it for several releases now, and every time, we've
> added more detail, clarification or correction, so it's pretty good at
> this point.
>
> TCW 24: " Style Guide for Editing the TEI Guidelines"
> <http://www.tei-c.org/Activities/Council/Working/tcw24.xml>
>
> This is currently quite basic, but growing; it tends to be added to when
> we have some disagreement or discussion about some element of style, and
> need to record our consensus.
>
> While you are new and getting familiar with the system, it would be
> helpful if you could make some notes on what is puzzling or
> undocumented, so we can fill those holes with better explanatory material.
>
> Cheers,
> Martin
> --
> Martin Holmes
> University of Victoria Humanities Computing and Media Centre
> (mholmes at uvic.ca)
> --
> tei-council mailing list
> tei-council at lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>
> PLEASE NOTE: postings to this list are publicly archived

From mholmes at uvic.ca  Tue Dec 18 12:10:54 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Tue, 18 Dec 2012 09:10:54 -0800
Subject: [tei-council] some questions about non-textual components and
	media
In-Reply-To: <50D0A011.4060809@ling.unipi.it>
References: <6068589664506483.WA.saeeds58yahoo.com@listserv.brown.edu>
	<50CF3F49.8090402@johnmccaskey.com>
	<AF624D57-B5E6-49B7-8C83-1310F46F3B6C@it.ox.ac.uk>
	<50CF42D3.6020107@johnmccaskey.com>
	<0922D1C5-176F-4569-A81C-A1BA3DE0079B@it.ox.ac.uk>
	<20687.18536.598674.638845@emt.ad.brown.edu>
	<FA8BD5E5-FC61-459F-B6EF-3E280A0401B8@it.ox.ac.uk>
	<50CF5CC0.9070505@uvic.ca> <50CF65A3.7070504@johnmccaskey.com>
	<50CF9C27.90807@retired.ox.ac.uk>
	<5279c8c4-e987-4a30-bc8f-1ff5afd54309@HUB02.ad.oak.ox.ac.uk>
	<50D049B8.7010207@retired.ox.ac.uk>
	<168a07fa-12d0-44ba-aa93-92ba8c6601e3@HUB05.ad.oak.ox.ac.uk>
	<50D0943D.70108@uvic.ca> <50D0A011.4060809@ling.unipi.it>
Message-ID: <50D0A39E.1020901@uvic.ca>

Bringing this discussion to the Council list for a minute:

There's a ticket relating to handling of audio and video has already 
been open for a long time (and is assigned to me, although it's red):

<https://sourceforge.net/tracker/index.php?func=detail&aid=2724997&group_id=106328&atid=644065>

Council minutes from April this year show that we discussed it:

<http://www.tei-c.org/Activities/Council/Meetings/tcm50.xml>

[quote]
2724997 and 2507305: These relate to the linking of TEI texts to audio 
and video. The consensus is that there should be at least a simple way 
to do this, but it?s not clear how best to approach it. PB:

<timeline> works for audio, and <facsimile> works for static images; 
what?s required for video is some clever combination of the two.

Consensus is that we need to create a working group to make recommendations.

KH: We should make an open call on the TEI list for people who could 
participate in the group.

Action: JC will write to TEI-L asking for people who are interested in 
this area to get in touch. He will run the message by Council first. 
These people will join a Council working group to come back with a 
consistent proposal to be discussed later at this meeting.
[/quote]

and the action list shows we then postponed any action pending a report 
from Lou from a workshop on speech and video. That was taking place in 
October or November IIRC, and I can't remember if Lou reported back or not.

In any case, that ticket, which is concerned with pointing at specific 
locations or ranges in media files, has kind of blocked us from 
proceeding on what is a much simpler requirement: the need to point to 
audio and video files as we can to graphics. If no-one has any 
objection, I'd like to put in a feature request for a <media> element:

element media
{
     att.global.attributes,
     att.global.linking.attributes,
     att.global.analytic.attributes,
     att.global.facs.attributes,
     att.global.change.attributes,
     att.internetMedia.attributes,
     att.declaring.attributes,
     att.duration,
     attribute url { data.pointer },
     model.descLike*
}

which would answer the immediate need, and would give us a starting 
point for addressing the issue of pointing to specific offsets in media 
files, zones on videos, and so on, which is a much more complicated issue.

Cheers,
Martin


On 12-12-18 08:55 AM, Roberto Rosselli Del Turco wrote:
> Il 18/12/2012 17:05, Martin Holmes ha scritto:
>> On 12-12-18 03:34 AM, Sebastian Rahtz wrote:
>>>
>>> <html:media> doesn't exist per se.  separate img, audio and video.
>>>
>>> I would not be averse to deprecating <graphic> in favour of a simple
>>> <media desc="how hard can it be"> which explicitly allows video, audio
>>> and still pictures,
>>> as a shorthand fior the full paraphernalia needed for born-digital
>>> multimedia.
>>>
>>> in the short term, myself i'd abuse <graphic>. In fact I already do, I
>>> see:
>>>
>>>          <graphic url="Pages/07 Father, set you.mp4"
>>> mimeType="video/mpeg4"/>
>>
>> I must admit I don't like this. I'd rather see a <media> element:
>>
>> element media
>> {
>>      att.global.attributes,
>>      att.global.linking.attributes,
>>      att.global.analytic.attributes,
>>      att.global.facs.attributes,
>>      att.global.change.attributes,
>>      att.internetMedia.attributes,
>>      att.declaring.attributes,
>>      att.duration,
>>      attribute url { data.pointer },
>>      model.descLike*
>> }
>
> Voting for <media> too, it just looks like the most effective (and
> elegant) solution for the problem.
>
> R
>

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From sebastian.rahtz at it.ox.ac.uk  Tue Dec 18 12:20:57 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Tue, 18 Dec 2012 17:20:57 +0000
Subject: [tei-council] some questions about non-textual components
	and	media
In-Reply-To: <50D0A39E.1020901@uvic.ca>
References: <6068589664506483.WA.saeeds58yahoo.com@listserv.brown.edu>
	<50CF3F49.8090402@johnmccaskey.com>
	<AF624D57-B5E6-49B7-8C83-1310F46F3B6C@it.ox.ac.uk>
	<50CF42D3.6020107@johnmccaskey.com>
	<0922D1C5-176F-4569-A81C-A1BA3DE0079B@it.ox.ac.uk>
	<20687.18536.598674.638845@emt.ad.brown.edu>
	<FA8BD5E5-FC61-459F-B6EF-3E280A0401B8@it.ox.ac.uk>
	<50CF5CC0.9070505@uvic.ca> <50CF65A3.7070504@johnmccaskey.com>
	<50CF9C27.90807@retired.ox.ac.uk>
	<5279c8c4-e987-4a30-bc8f-1ff5afd54309@HUB02.ad.oak.ox.ac.uk>
	<50D049B8.7010207@retired.ox.ac.uk>
	<168a07fa-12d0-44ba-aa93-92ba8c6601e3@HUB05.ad.oak.ox.ac.uk>
	<50D0943D.70108@uvic.ca> <50D0A011.4060809@ling.unipi.it>
	<50D0A39E.1020901@uvic.ca>
Message-ID: <8CF36F67-4E01-44E4-8E31-D9E7FAA2BB22@it.ox.ac.uk>

I am still wary of the complexity described at http://www.w3.org/TR/2012/CR-html5-20121217/, section 4.8.9

please don't tell me people won't ask for any of all the attributes and children described there?...
--
Sebastian Rahtz      
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431


From mholmes at uvic.ca  Tue Dec 18 12:36:53 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Tue, 18 Dec 2012 09:36:53 -0800
Subject: [tei-council] some questions about non-textual components and
 media
In-Reply-To: <8CF36F67-4E01-44E4-8E31-D9E7FAA2BB22@it.ox.ac.uk>
References: <6068589664506483.WA.saeeds58yahoo.com@listserv.brown.edu>
	<50CF3F49.8090402@johnmccaskey.com>
	<AF624D57-B5E6-49B7-8C83-1310F46F3B6C@it.ox.ac.uk>
	<50CF42D3.6020107@johnmccaskey.com>
	<0922D1C5-176F-4569-A81C-A1BA3DE0079B@it.ox.ac.uk>
	<20687.18536.598674.638845@emt.ad.brown.edu>
	<FA8BD5E5-FC61-459F-B6EF-3E280A0401B8@it.ox.ac.uk>
	<50CF5CC0.9070505@uvic.ca> <50CF65A3.7070504@johnmccaskey.com>
	<50CF9C27.90807@retired.ox.ac.uk>
	<5279c8c4-e987-4a30-bc8f-1ff5afd54309@HUB02.ad.oak.ox.ac.uk>
	<50D049B8.7010207@retired.ox.ac.uk>
	<168a07fa-12d0-44ba-aa93-92ba8c6601e3@HUB05.ad.oak.ox.ac.uk>
	<50D0943D.70108@uvic.ca> <50D0A011.4060809@ling.unipi.it>
	<50D0A39E.1020901@uvic.ca>
	<8CF36F67-4E01-44E4-8E31-D9E7FAA2BB22@it.ox.ac.uk>
Message-ID: <50D0A9B5.2090809@uvic.ca>

On 12-12-18 09:20 AM, Sebastian Rahtz wrote:
> I am still wary of the complexity described at http://www.w3.org/TR/2012/CR-html5-20121217/, section 4.8.9
>
> please don't tell me people won't ask for any of all the attributes and children described there?...

They may ask, but that would be a different feature request. The HTML 
elements are all about the actual embedding of a media presentation in a 
document which is to be processed by a user agent for an end user to 
consume; TEI is not really doing anything comparable.* Whether a video 
should loop or not when being played is something to be decided by the 
processing that generates some kind of output from the TEI file, rather 
than the TEI file itself.

I think the scenarios we should be thinking about here are

  - Born-digital documents that include media files (e.g. journal 
articles including audio or video).

  - Transcriptions of primary sources where editorial content such as 
annotations may include audio or video.

*Of course, you have to think about what the Stylesheets are going to do 
with these elements, and I can see why that would be a worrying 
prospect. But there are lots of things the default Stylesheets can't 
really be expected to deal with, and this might be one of them. You can 
always just turn them into links.

Cheers,
Martin

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From sebastian.rahtz at it.ox.ac.uk  Tue Dec 18 13:04:13 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Tue, 18 Dec 2012 18:04:13 +0000
Subject: [tei-council] some questions about non-textual components and
 media
In-Reply-To: <50D0A9B5.2090809@uvic.ca>
References: <6068589664506483.WA.saeeds58yahoo.com@listserv.brown.edu>
	<50CF3F49.8090402@johnmccaskey.com>
	<AF624D57-B5E6-49B7-8C83-1310F46F3B6C@it.ox.ac.uk>
	<50CF42D3.6020107@johnmccaskey.com>
	<0922D1C5-176F-4569-A81C-A1BA3DE0079B@it.ox.ac.uk>
	<20687.18536.598674.638845@emt.ad.brown.edu>
	<FA8BD5E5-FC61-459F-B6EF-3E280A0401B8@it.ox.ac.uk>
	<50CF5CC0.9070505@uvic.ca> <50CF65A3.7070504@johnmccaskey.com>
	<50CF9C27.90807@retired.ox.ac.uk>
	<5279c8c4-e987-4a30-bc8f-1ff5afd54309@HUB02.ad.oak.ox.ac.uk>
	<50D049B8.7010207@retired.ox.ac.uk>
	<168a07fa-12d0-44ba-aa93-92ba8c6601e3@HUB05.ad.oak.ox.ac.uk>
	<50D0943D.70108@uvic.ca> <50D0A011.4060809@ling.unipi.it>
	<50D0A39E.1020901@uvic.ca>
	<8CF36F67-4E01-44E4-8E31-D9E7FAA2BB22@it.ox.ac.uk>
	<50D0A9B5.2090809@uvic.ca>
Message-ID: <278EC652-CDD6-4C77-982B-C51C333DE086@it.ox.ac.uk>


On 18 Dec 2012, at 17:36, Martin Holmes <mholmes at uvic.ca>
 wrote:
> I think the scenarios we should be thinking about here are
> 
>  - Born-digital documents that include media files (e.g. journal 
> articles including audio or video).

exactly. where the original _does_ have the control and annotation
features present and you want to capture them. you just end up
passing everything off to @rend and @rendition and @style,
and I doubt they are powerful enough to cope with all that. After all,
if they were expressible in CSS, HTML5 would not have included all that jazz, surely?

The document you are describing in TEI  may have an _authorial_  decision as to
whether a video should loop or not when being played. It is the usual
@rend stuff.

I betcha that when we added <graphic> someone said "why isn't it <media> (vel sim)"
and a sage someone said "ah now, graphics are easy, but video and audio are harder,
steer clear". Whether that someone was me, Lou, Syd, or my fevered imagination
I don't know.

what the heck. i have the code ready for audio and video anyway, cos I just
abuse <graphic> :-}
--
Sebastian Rahtz      
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431


From mholmes at uvic.ca  Tue Dec 18 14:24:18 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Tue, 18 Dec 2012 11:24:18 -0800
Subject: [tei-council] some questions about non-textual components and
 media
In-Reply-To: <278EC652-CDD6-4C77-982B-C51C333DE086@it.ox.ac.uk>
References: <6068589664506483.WA.saeeds58yahoo.com@listserv.brown.edu>
	<50CF3F49.8090402@johnmccaskey.com>
	<AF624D57-B5E6-49B7-8C83-1310F46F3B6C@it.ox.ac.uk>
	<50CF42D3.6020107@johnmccaskey.com>
	<0922D1C5-176F-4569-A81C-A1BA3DE0079B@it.ox.ac.uk>
	<20687.18536.598674.638845@emt.ad.brown.edu>
	<FA8BD5E5-FC61-459F-B6EF-3E280A0401B8@it.ox.ac.uk>
	<50CF5CC0.9070505@uvic.ca> <50CF65A3.7070504@johnmccaskey.com>
	<50CF9C27.90807@retired.ox.ac.uk>
	<5279c8c4-e987-4a30-bc8f-1ff5afd54309@HUB02.ad.oak.ox.ac.uk>
	<50D049B8.7010207@retired.ox.ac.uk>
	<168a07fa-12d0-44ba-aa93-92ba8c6601e3@HUB05.ad.oak.ox.ac.uk>
	<50D0943D.70108@uvic.ca> <50D0A011.4060809@ling.unipi.it>
	<50D0A39E.1020901@uvic.ca>
	<8CF36F67-4E01-44E4-8E31-D9E7FAA2BB22@it.ox.ac.uk>
	<50D0A9B5.2090809@uvic.ca>
	<278EC652-CDD6-4C77-982B-C51C333DE086@it.ox.ac.uk>
Message-ID: <50D0C2E2.70009@uvic.ca>

On 12-12-18 10:04 AM, Sebastian Rahtz wrote:
>
> On 18 Dec 2012, at 17:36, Martin Holmes <mholmes at uvic.ca>
>   wrote:
>> I think the scenarios we should be thinking about here are
>>
>>   - Born-digital documents that include media files (e.g. journal
>> articles including audio or video).
>
> exactly. where the original _does_ have the control and annotation
> features present and you want to capture them.

In the case of born-digital documents, there's nothing to capture: 
you're authoring directly. Imagine you're writing for a journal like 
DHQ. You (as author) know you want to include a media file, which you do 
in a simple way; DHQ has its own rendering pipelines, and it handles the 
display of video or audio in ways conforming to its own styleguide, 
depending on the output format. It's not the author's or encoder's job 
to worry about that.

> you just end up
> passing everything off to @rend and @rendition and @style,
> and I doubt they are powerful enough to cope with all that. After all,
> if they were expressible in CSS, HTML5 would not have included all that jazz, surely?

Sure, but in this scenario, you don't care. It's up to the publisher or 
the web application designer what to do with it.

> The document you are describing in TEI  may have an _authorial_  decision as to
> whether a video should loop or not when being played. It is the usual
> @rend stuff.

I think if the author wants to do such complex stuff, they can import 
the HTML5 elements and attributes.

> I betcha that when we added <graphic> someone said "why isn't it <media> (vel sim)"
> and a sage someone said "ah now, graphics are easy, but video and audio are harder,
> steer clear". Whether that someone was me, Lou, Syd, or my fevered imagination
> I don't know.

There are lots of other things you can say about graphics too -- 
thumbnail sizes, different resolutions available, lossy encodings vs 
archive quality versions, etc. But most people don't really need them, 
and they're happy with just <graphic>.

> what the heck. i have the code ready for audio and video anyway, cos I just
> abuse <graphic> :-}

That worries me more than the implications of a new relatively basic 
<media> element. Especially if the content is audio; it's flat-out 
misleading, surely.

Cheers,
Martin

> --
> Sebastian Rahtz
> Director (Research Support) of Academic IT Services
> University of Oxford IT Services
> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>
>

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From sebastian.rahtz at it.ox.ac.uk  Tue Dec 18 14:41:24 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Tue, 18 Dec 2012 19:41:24 +0000
Subject: [tei-council] some questions about non-textual components and
 media
In-Reply-To: <50D0C2E2.70009@uvic.ca>
References: <6068589664506483.WA.saeeds58yahoo.com@listserv.brown.edu>
	<50CF3F49.8090402@johnmccaskey.com>
	<AF624D57-B5E6-49B7-8C83-1310F46F3B6C@it.ox.ac.uk>
	<50CF42D3.6020107@johnmccaskey.com>
	<0922D1C5-176F-4569-A81C-A1BA3DE0079B@it.ox.ac.uk>
	<20687.18536.598674.638845@emt.ad.brown.edu>
	<FA8BD5E5-FC61-459F-B6EF-3E280A0401B8@it.ox.ac.uk>
	<50CF5CC0.9070505@uvic.ca> <50CF65A3.7070504@johnmccaskey.com>
	<50CF9C27.90807@retired.ox.ac.uk>
	<5279c8c4-e987-4a30-bc8f-1ff5afd54309@HUB02.ad.oak.ox.ac.uk>
	<50D049B8.7010207@retired.ox.ac.uk>
	<168a07fa-12d0-44ba-aa93-92ba8c6601e3@HUB05.ad.oak.ox.ac.uk>
	<50D0943D.70108@uvic.ca> <50D0A011.4060809@ling.unipi.it>
	<50D0A39E.1020901@uvic.ca>
	<8CF36F67-4E01-44E4-8E31-D9E7FAA2BB22@it.ox.ac.uk>
	<50D0A9B5.2090809@uvic.ca>
	<278EC652-CDD6-4C77-982B-C51C333DE086@it.ox.ac.uk>
	<50D0C2E2.70009@uvic.ca>
Message-ID: <D22A08C7-DDFE-43B9-AB7C-01C5BAA9EDF1@it.ox.ac.uk>


On 18 Dec 2012, at 19:24, Martin Holmes <mholmes at uvic.ca>
wrote:
> 
> In the case of born-digital documents, there's nothing to capture: 
> you're authoring directly. Imagine you're writing for a journal like 
> DHQ. You (as author) know you want to include a media file, which you do 
> in a simple way; DHQ has its own rendering pipelines, and it handles the 
> display of video or audio in ways conforming to its own styleguide, 
> depending on the output format. It's not the author's or encoder's job 
> to worry about that.

true. but the person encoding the archives of DHQ in TEI wants to preserve
the final look of the journal.
...
> I think if the author wants to do such complex stuff, they can import 
> the HTML5 elements and attributes.

yeah, ok, i guess thats always the fallback

> 
....
>> what the heck. i have the code ready for audio and video anyway, cos I just
>> abuse <graphic> :-}
> 
> That worries me more than the implications of a new relatively basic 
> <media> element. Especially if the content is audio; it's flat-out 
> misleading, surely.


oh, its Christmas, you'll forgive me, wont you? must I switch to <ptr target="foo.mp4" rend="transclude"/>?

Do remember that if I meet
 	<media target="foo.mp4"/>
and
	<media target="foo.tiff"/>
I really really really don't want to work out that I should use <video> for one, and <img>
for the other, by looking at file suffixes. Either let's have <video> and <audio>,
or mandate mime types.

I suspect actually that I could decide to pull the audio from a video file
using HTML <audio>, so thats another reason not to use <media>, because
it is not precise enough  - what aspect of the media did the author include?

--
Sebastian Rahtz      
http://www.justgiving.com/SebastianRahtz
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431


From gabriel.bodard at kcl.ac.uk  Tue Dec 18 14:50:18 2012
From: gabriel.bodard at kcl.ac.uk (Gabriel Bodard)
Date: Tue, 18 Dec 2012 19:50:18 +0000
Subject: [tei-council] some questions about non-textual components and
 media
In-Reply-To: <D22A08C7-DDFE-43B9-AB7C-01C5BAA9EDF1@it.ox.ac.uk>
References: <6068589664506483.WA.saeeds58yahoo.com@listserv.brown.edu>
	<50CF3F49.8090402@johnmccaskey.com>
	<AF624D57-B5E6-49B7-8C83-1310F46F3B6C@it.ox.ac.uk>
	<50CF42D3.6020107@johnmccaskey.com>
	<0922D1C5-176F-4569-A81C-A1BA3DE0079B@it.ox.ac.uk>
	<20687.18536.598674.638845@emt.ad.brown.edu>
	<FA8BD5E5-FC61-459F-B6EF-3E280A0401B8@it.ox.ac.uk>
	<50CF5CC0.9070505@uvic.ca> <50CF65A3.7070504@johnmccaskey.com>
	<50CF9C27.90807@retired.ox.ac.uk>
	<5279c8c4-e987-4a30-bc8f-1ff5afd54309@HUB02.ad.oak.ox.ac.uk>
	<50D049B8.7010207@retired.ox.ac.uk>
	<168a07fa-12d0-44ba-aa93-92ba8c6601e3@HUB05.ad.oak.ox.ac.uk>
	<50D0943D.70108@uvic.ca> <50D0A011.4060809@ling.unipi.it>
	<50D0A39E.1020901@uvic.ca>
	<8CF36F67-4E01-44E4-8E31-D9E7FAA2BB22@it.ox.ac.uk>
	<50D0A9B5.2090809@uvic.ca>
	<278EC652-CDD6-4C77-982B-C51C333DE086@it.ox.ac.uk>
	<50D0C2E2.70009@uvic.ca>
	<D22A08C7-DDFE-43B9-AB7C-01C5BAA9EDF1@it.ox.ac.uk>
Message-ID: <50D0C8FA.3050408@kcl.ac.uk>

On 18/12/2012 19:41, Sebastian Rahtz wrote:
> Do remember that if I meet
>   	<media target="foo.mp4"/>
> and
> 	<media target="foo.tiff"/>
> I really really really don't want to work out that I should use <video> for one, and <img>
> for the other, by looking at file suffixes. Either let's have <video> and <audio>,
> or mandate mime types.
>
> I suspect actually that I could decide to pull the audio from a video file
> using HTML <audio>, so thats another reason not to use <media>, because
> it is not precise enough  - what aspect of the media did the author include?

I'd actually prefer to have something generic like <media> (of which 
<graphic> is a specialization, and possible audio and video too, if you 
really want) and both mandate @mimetype and something like @medium if 
you want to be able to pull audio only from a video file (or a still 
frame from a multimedia file) or something. I'm sure there are media 
that don't easily fit into one of graphic, video, audio that we might 
want to include in here as well (QTVR; Powerpoint; interactive maps; 
embedded app; holographic projector) so let's be as generic and agnostic 
as possible.

G

-- 
Dr Gabriel BODARD
Researcher in Digital Epigraphy

Department of Digital Humanities
King's College London
26-29 Drury Lane
London WC2B 5RL

Email: gabriel.bodard at kcl.ac.uk
Tel: +44 (0)20 7848 1388
Fax: +44 (0)20 7848 2980

http://www.digitalclassicist.org/
http://www.currentepigraphy.org/


From sebastian.rahtz at it.ox.ac.uk  Tue Dec 18 15:14:09 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Tue, 18 Dec 2012 20:14:09 +0000
Subject: [tei-council] some questions about non-textual components and
 media
In-Reply-To: <50D0C8FA.3050408@kcl.ac.uk>
References: <6068589664506483.WA.saeeds58yahoo.com@listserv.brown.edu>
	<50CF3F49.8090402@johnmccaskey.com>
	<AF624D57-B5E6-49B7-8C83-1310F46F3B6C@it.ox.ac.uk>
	<50CF42D3.6020107@johnmccaskey.com>
	<0922D1C5-176F-4569-A81C-A1BA3DE0079B@it.ox.ac.uk>
	<20687.18536.598674.638845@emt.ad.brown.edu>
	<FA8BD5E5-FC61-459F-B6EF-3E280A0401B8@it.ox.ac.uk>
	<50CF5CC0.9070505@uvic.ca> <50CF65A3.7070504@johnmccaskey.com>
	<50CF9C27.90807@retired.ox.ac.uk>
	<5279c8c4-e987-4a30-bc8f-1ff5afd54309@HUB02.ad.oak.ox.ac.uk>
	<50D049B8.7010207@retired.ox.ac.uk>
	<168a07fa-12d0-44ba-aa93-92ba8c6601e3@HUB05.ad.oak.ox.ac.uk>
	<50D0943D.70108@uvic.ca> <50D0A011.4060809@ling.unipi.it>
	<50D0A39E.1020901@uvic.ca>
	<8CF36F67-4E01-44E4-8E31-D9E7FAA2BB22@it.ox.ac.uk>
	<50D0A9B5.2090809@uvic.ca>
	<278EC652-CDD6-4C77-982B-C51C333DE086@it.ox.ac.uk>
	<50D0C2E2.70009@uvic.ca>
	<D22A08C7-DDFE-43B9-AB7C-01C5BAA9EDF1@it.ox.ac.uk>
	<50D0C8FA.3050408@kcl.ac.uk>
Message-ID: <BA78DCFB-94FA-47A6-A271-D96E9CEEC3CA@it.ox.ac.uk>


On 18 Dec 2012, at 19:50, Gabriel Bodard <gabriel.bodard at kcl.ac.uk>
 wrote:
> 
>  I'm sure there are media 
> that don't easily fit into one of graphic, video, audio that we might 
> want to include in here as well (QTVR; Powerpoint; interactive maps; 
> embedded app; holographic projector) so let's be as generic and agnostic 
> as possible.


ah, its HTML <embed> you want..... or is it <object>...

sorry to bang on, but it does behoove us to consider _why_ the HTML5
designers included all of <embed>, <object>, <video>, <audio> and <img>,
not just <media>. Just worrying that they have given this some thought.

I'll stop now :-}
--
Sebastian Rahtz      
http://www.justgiving.com/SebastianRahtz
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431


From mholmes at uvic.ca  Tue Dec 18 15:56:44 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Tue, 18 Dec 2012 12:56:44 -0800
Subject: [tei-council] some questions about non-textual components and
 media
In-Reply-To: <BA78DCFB-94FA-47A6-A271-D96E9CEEC3CA@it.ox.ac.uk>
References: <6068589664506483.WA.saeeds58yahoo.com@listserv.brown.edu>
	<50CF3F49.8090402@johnmccaskey.com>
	<AF624D57-B5E6-49B7-8C83-1310F46F3B6C@it.ox.ac.uk>
	<50CF42D3.6020107@johnmccaskey.com>
	<0922D1C5-176F-4569-A81C-A1BA3DE0079B@it.ox.ac.uk>
	<20687.18536.598674.638845@emt.ad.brown.edu>
	<FA8BD5E5-FC61-459F-B6EF-3E280A0401B8@it.ox.ac.uk>
	<50CF5CC0.9070505@uvic.ca> <50CF65A3.7070504@johnmccaskey.com>
	<50CF9C27.90807@retired.ox.ac.uk>
	<5279c8c4-e987-4a30-bc8f-1ff5afd54309@HUB02.ad.oak.ox.ac.uk>
	<50D049B8.7010207@retired.ox.ac.uk>
	<168a07fa-12d0-44ba-aa93-92ba8c6601e3@HUB05.ad.oak.ox.ac.uk>
	<50D0943D.70108@uvic.ca> <50D0A011.4060809@ling.unipi.it>
	<50D0A39E.1020901@uvic.ca>
	<8CF36F67-4E01-44E4-8E31-D9E7FAA2BB22@it.ox.ac.uk>
	<50D0A9B5.2090809@uvic.ca>
	<278EC652-CDD6-4C77-982B-C51C333DE086@it.ox.ac.uk>	<50D0C2E2.70009@uvic.ca>
	<D22A08C7-DDFE-43B9-AB7C-01C5BAA9EDF1@it.ox.ac.uk>
	<50D0C8FA.3050408@kcl.ac.uk>
	<BA78DCFB-94FA-47A6-A271-D96E9CEEC3CA@it.ox.ac.uk>
Message-ID: <50D0D88C.4040407@uvic.ca>

On 12-12-18 12:14 PM, Sebastian Rahtz wrote:
>
> On 18 Dec 2012, at 19:50, Gabriel Bodard <gabriel.bodard at kcl.ac.uk>
>   wrote:
>>
>>   I'm sure there are media
>> that don't easily fit into one of graphic, video, audio that we might
>> want to include in here as well (QTVR; Powerpoint; interactive maps;
>> embedded app; holographic projector) so let's be as generic and agnostic
>> as possible.
>
>
> ah, its HTML <embed> you want..... or is it <object>...
>
> sorry to bang on, but it does behoove us to consider _why_ the HTML5
> designers included all of <embed>, <object>, <video>, <audio> and <img>,
> not just <media>. Just worrying that they have given this some thought.
>
> I'll stop now :-}

You're absolutely right to raise these issues, and of course we have to 
consider them if we raise a ticket for this. But we're not writing an 
end-user language for rendering agents like HTML5, we're writing a 
language for describing a document. We should also try not to be too 
driven by the processing concerns. Most projects will have their own 
rendering pipelines and XSLT, and if something is just too difficult for 
you to provide a good generic rendering solution, the Stylesheets can 
simply output a link.

>
> oh, its Christmas, you'll forgive me, wont you? must I switch to <ptr target="foo.mp4" rend="transclude"/>?

Sorry indeed if I annoyed you; it wasn't my intention to tell you not to 
do what you're doing, just to suggest that I don't think it would be a 
good thing to recommend to other people when they ask how to deal with 
video and audio.

Cheers,
Martin

> --
> Sebastian Rahtz
> http://www.justgiving.com/SebastianRahtz
> Director (Research Support) of Academic IT Services
> University of Oxford IT Services
> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From kevin.s.hawkins at ultraslavonic.info  Tue Dec 18 16:15:46 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Tue, 18 Dec 2012 16:15:46 -0500
Subject: [tei-council] some questions about non-textual components and
 media
In-Reply-To: <50D0C8FA.3050408@kcl.ac.uk>
References: <6068589664506483.WA.saeeds58yahoo.com@listserv.brown.edu>	<50CF3F49.8090402@johnmccaskey.com>	<AF624D57-B5E6-49B7-8C83-1310F46F3B6C@it.ox.ac.uk>	<50CF42D3.6020107@johnmccaskey.com>	<0922D1C5-176F-4569-A81C-A1BA3DE0079B@it.ox.ac.uk>	<20687.18536.598674.638845@emt.ad.brown.edu>	<FA8BD5E5-FC61-459F-B6EF-3E280A0401B8@it.ox.ac.uk>	<50CF5CC0.9070505@uvic.ca>
	<50CF65A3.7070504@johnmccaskey.com>	<50CF9C27.90807@retired.ox.ac.uk>	<5279c8c4-e987-4a30-bc8f-1ff5afd54309@HUB02.ad.oak.ox.ac.uk>	<50D049B8.7010207@retired.ox.ac.uk>	<168a07fa-12d0-44ba-aa93-92ba8c6601e3@HUB05.ad.oak.ox.ac.uk>	<50D0943D.70108@uvic.ca>
	<50D0A011.4060809@ling.unipi.it>	<50D0A39E.1020901@uvic.ca>	<8CF36F67-4E01-44E4-8E31-D9E7FAA2BB22@it.ox.ac.uk>	<50D0A9B5.2090809@uvic.ca>	<278EC652-CDD6-4C77-982B-C51C333DE086@it.ox.ac.uk>	<50D0C2E2.70009@uvic.ca>	<D22A08C7-DDFE-43B9-AB7C-01C5BAA9EDF1@it.ox.ac.uk>
	<50D0C8FA.3050408@kcl.ac.uk>
Message-ID: <50D0DD02.2070405@ultraslavonic.info>

On 12/18/2012 2:50 PM, Gabriel Bodard wrote:
> On 18/12/2012 19:41, Sebastian Rahtz wrote:
>> Do remember that if I meet
>>    	<media target="foo.mp4"/>
>> and
>> 	<media target="foo.tiff"/>
>> I really really really don't want to work out that I should use<video>  for one, and<img>
>> for the other, by looking at file suffixes. Either let's have<video>  and<audio>,
>> or mandate mime types.
>>
>> I suspect actually that I could decide to pull the audio from a video file
>> using HTML<audio>, so thats another reason not to use<media>, because
>> it is not precise enough  - what aspect of the media did the author include?
>
> I'd actually prefer to have something generic like<media>  (of which
> <graphic>  is a specialization, and possible audio and video too, if you
> really want) and both mandate @mimetype and something like @medium if
> you want to be able to pull audio only from a video file (or a still
> frame from a multimedia file) or something. I'm sure there are media
> that don't easily fit into one of graphic, video, audio that we might
> want to include in here as well (QTVR; Powerpoint; interactive maps;
> embedded app; holographic projector) so let's be as generic and agnostic
> as possible.

I too am attracted to the idea of a generic element (<media>?) of which 
<graphic> is a specialization ... perhaps, in fact, syntactic sugar for 
<media type="graphic">.

From lou.burnard at retired.ox.ac.uk  Tue Dec 18 16:19:52 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Tue, 18 Dec 2012 21:19:52 +0000
Subject: [tei-council] some questions about non-textual components and
 media
In-Reply-To: <50D0C8FA.3050408@kcl.ac.uk>
References: <6068589664506483.WA.saeeds58yahoo.com@listserv.brown.edu>
	<50CF3F49.8090402@johnmccaskey.com>
	<AF624D57-B5E6-49B7-8C83-1310F46F3B6C@it.ox.ac.uk>
	<50CF42D3.6020107@johnmccaskey.com>
	<0922D1C5-176F-4569-A81C-A1BA3DE0079B@it.ox.ac.uk>
	<20687.18536.598674.638845@emt.ad.brown.edu>
	<FA8BD5E5-FC61-459F-B6EF-3E280A0401B8@it.ox.ac.uk>
	<50CF5CC0.9070505@uvic.ca> <50CF65A3.7070504@johnmccaskey.com>
	<50CF9C27.90807@retired.ox.ac.uk>
	<5279c8c4-e987-4a30-bc8f-1ff5afd54309@HUB02.ad.oak.ox.ac.uk>
	<50D049B8.7010207@retired.ox.ac.uk>
	<168a07fa-12d0-44ba-aa93-92ba8c6601e3@HUB05.ad.oak.ox.ac.uk>
	<50D0943D.70108@uvic.ca> <50D0A011.4060809@ling.unipi.it>
	<50D0A39E.1020901@uvic.ca>
	<8CF36F67-4E01-44E4-8E31-D9E7FAA2BB22@it.ox.ac.uk>
	<50D0A9B5.2090809@uvic.ca>
	<278EC652-CDD6-4C77-982B-C51C333DE086@it.ox.ac.uk>
	<50D0C2E2.70009@uvic.ca>
	<D22A08C7-DDFE-43B9-AB7C-01C5BAA9EDF1@it.ox.ac.uk>
	<50D0C8FA.3050408@kcl.ac.uk>
Message-ID: <50D0DDF8.9040105@retired.ox.ac.uk>

On 18/12/12 19:50, Gabriel Bodard wrote:
> On 18/12/2012 19:41, Sebastian Rahtz wrote:
>> Do remember that if I meet
>>    	<media target="foo.mp4"/>
>> and
>> 	<media target="foo.tiff"/>
>> I really really really don't want to work out that I should use <video> for one, and <img>
>> for the other, by looking at file suffixes. Either let's have <video> and <audio>,
>> or mandate mime types.
>>
>> I suspect actually that I could decide to pull the audio from a video file
>> using HTML <audio>, so thats another reason not to use <media>, because
>> it is not precise enough  - what aspect of the media did the author include?
> I'd actually prefer to have something generic like <media> (of which
> <graphic> is a specialization, and possible audio and video too, if you
> really want) and both mandate @mimetype and something like @medium if
> you want to be able to pull audio only from a video file (or a still
> frame from a multimedia file) or something. I'm sure there are media
> that don't easily fit into one of graphic, video, audio that we might
> want to include in here as well (QTVR; Powerpoint; interactive maps;
> embedded app; holographic projector) so let's be as generic and agnostic
> as possible.
>

I agree with GB here. We do already have  @mimetype after all and we 
could make it mandatory on <media>

Or we could just add <audio> and <video> and have this argument all over 
again when someone invents smellovision.


>


From sebastian.rahtz at it.ox.ac.uk  Tue Dec 18 16:54:49 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Tue, 18 Dec 2012 21:54:49 +0000
Subject: [tei-council] some questions about non-textual components and
 media
In-Reply-To: <50D0DDF8.9040105@retired.ox.ac.uk>
References: <6068589664506483.WA.saeeds58yahoo.com@listserv.brown.edu>
	<50CF3F49.8090402@johnmccaskey.com>
	<AF624D57-B5E6-49B7-8C83-1310F46F3B6C@it.ox.ac.uk>
	<50CF42D3.6020107@johnmccaskey.com>
	<0922D1C5-176F-4569-A81C-A1BA3DE0079B@it.ox.ac.uk>
	<20687.18536.598674.638845@emt.ad.brown.edu>
	<FA8BD5E5-FC61-459F-B6EF-3E280A0401B8@it.ox.ac.uk>
	<50CF5CC0.9070505@uvic.ca> <50CF65A3.7070504@johnmccaskey.com>
	<50CF9C27.90807@retired.ox.ac.uk>
	<5279c8c4-e987-4a30-bc8f-1ff5afd54309@HUB02.ad.oak.ox.ac.uk>
	<50D049B8.7010207@retired.ox.ac.uk>
	<168a07fa-12d0-44ba-aa93-92ba8c6601e3@HUB05.ad.oak.ox.ac.uk>
	<50D0943D.70108@uvic.ca> <50D0A011.4060809@ling.unipi.it>
	<50D0A39E.1020901@uvic.ca>
	<8CF36F67-4E01-44E4-8E31-D9E7FAA2BB22@it.ox.ac.uk>
	<50D0A9B5.2090809@uvic.ca>
	<278EC652-CDD6-4C77-982B-C51C333DE086@it.ox.ac.uk>
	<50D0C2E2.70009@uvic.ca>
	<D22A08C7-DDFE-43B9-AB7C-01C5BAA9EDF1@it.ox.ac.uk>
	<50D0C8FA.3050408@kcl.ac.uk> <50D0DDF8.9040105@retired.ox.ac.uk>
Message-ID: <23b2cbd4-d8a7-4566-a63d-15783b11cc96@HUB04.ad.oak.ox.ac.uk>


On 18 Dec 2012, at 21:19, Lou Burnard <lou.burnard at retired.ox.ac.uk>
 wrote:
> 
> I agree with GB here. We do already have  @mimetype after all and we 
> could make it mandatory on <media>
> 
> Or we could just add <audio> and <video> and have this argument all over 
> again when someone invents smellovision.


If we have <media>, we still have to maintain a closed list
for a @medium attribute (and therefore add smellovision).  
If anyone suggests that just @mimeType will do the job,  
I'll thcream and thcream 'till I'm thick
--
Sebastian Rahtz      
http://www.justgiving.com/SebastianRahtz
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431


From sebastian.rahtz at it.ox.ac.uk  Tue Dec 18 16:56:18 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Tue, 18 Dec 2012 21:56:18 +0000
Subject: [tei-council] some questions about non-textual components and
 media
In-Reply-To: <50D0D88C.4040407@uvic.ca>
References: <6068589664506483.WA.saeeds58yahoo.com@listserv.brown.edu>
	<50CF3F49.8090402@johnmccaskey.com>
	<AF624D57-B5E6-49B7-8C83-1310F46F3B6C@it.ox.ac.uk>
	<50CF42D3.6020107@johnmccaskey.com>
	<0922D1C5-176F-4569-A81C-A1BA3DE0079B@it.ox.ac.uk>
	<20687.18536.598674.638845@emt.ad.brown.edu>
	<FA8BD5E5-FC61-459F-B6EF-3E280A0401B8@it.ox.ac.uk>
	<50CF5CC0.9070505@uvic.ca> <50CF65A3.7070504@johnmccaskey.com>
	<50CF9C27.90807@retired.ox.ac.uk>
	<5279c8c4-e987-4a30-bc8f-1ff5afd54309@HUB02.ad.oak.ox.ac.uk>
	<50D049B8.7010207@retired.ox.ac.uk>
	<168a07fa-12d0-44ba-aa93-92ba8c6601e3@HUB05.ad.oak.ox.ac.uk>
	<50D0943D.70108@uvic.ca> <50D0A011.4060809@ling.unipi.it>
	<50D0A39E.1020901@uvic.ca>
	<8CF36F67-4E01-44E4-8E31-D9E7FAA2BB22@it.ox.ac.uk>
	<50D0A9B5.2090809@uvic.ca>
	<278EC652-CDD6-4C77-982B-C51C333DE086@it.ox.ac.uk>	<50D0C2E2.70009@uvic.ca>
	<D22A08C7-DDFE-43B9-AB7C-01C5BAA9EDF1@it.ox.ac.uk>
	<50D0C8FA.3050408@kcl.ac.uk>
	<BA78DCFB-94FA-47A6-A271-D96E9CEEC3CA@it.ox.ac.uk>
	<50D0D88C.4040407@uvic.ca>
Message-ID: <798ECC0B-E245-404E-B347-3FA7AED77183@it.ox.ac.uk>


On 18 Dec 2012, at 20:56, Martin Holmes <mholmes at uvic.ca>
 wrote:
>> 
>> oh, its Christmas, you'll forgive me, wont you? must I switch to <ptr target="foo.mp4" rend="transclude"/>?
> 
> Sorry indeed if I annoyed you; it wasn't my intention to tell you not to 
> do what you're doing, just to suggest that I don't think it would be a 
> good thing to recommend to other people when they ask how to deal with 
> video and audio.

don't worry, I never document what I implement, so its a dark
secret between my file and the XSL :-}

--
Sebastian Rahtz      
http://www.justgiving.com/SebastianRahtz
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431


From mholmes at uvic.ca  Tue Dec 18 17:40:41 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Tue, 18 Dec 2012 14:40:41 -0800
Subject: [tei-council] some questions about non-textual components and
 media
In-Reply-To: <798ECC0B-E245-404E-B347-3FA7AED77183@it.ox.ac.uk>
References: <6068589664506483.WA.saeeds58yahoo.com@listserv.brown.edu>
	<50CF42D3.6020107@johnmccaskey.com>
	<0922D1C5-176F-4569-A81C-A1BA3DE0079B@it.ox.ac.uk>
	<20687.18536.598674.638845@emt.ad.brown.edu>
	<FA8BD5E5-FC61-459F-B6EF-3E280A0401B8@it.ox.ac.uk>
	<50CF5CC0.9070505@uvic.ca> <50CF65A3.7070504@johnmccaskey.com>
	<50CF9C27.90807@retired.ox.ac.uk>
	<5279c8c4-e987-4a30-bc8f-1ff5afd54309@HUB02.ad.oak.ox.ac.uk>
	<50D049B8.7010207@retired.ox.ac.uk>
	<168a07fa-12d0-44ba-aa93-92ba8c6601e3@HUB05.ad.oak.ox.ac.uk>
	<50D0943D.70108@uvic.ca> <50D0A011.4060809@ling.unipi.it>
	<50D0A39E.1020901@uvic.ca>
	<8CF36F67-4E01-44E4-8E31-D9E7FAA2BB22@it.ox.ac.uk>
	<50D0A9B5.2090809@uvic.ca>
	<278EC652-CDD6-4C77-982B-C51C333DE086@it.ox.ac.uk>	<50D0C2E2.70009@uvic.ca>
	<D22A08C7-DDFE-43B9-AB7C-01C5BAA9EDF1@it.ox.ac.uk>
	<50D0C8FA.3050408@kcl.ac.uk>
	<BA78DCFB-94FA-47A6-A271-D96E9CEEC3CA@it.ox.ac.uk>
	<50D0D88C.4040407@uvic.ca>
	<798ECC0B-E245-404E-B347-3FA7AED77183@it.ox.ac.uk>
Message-ID: <50D0F0E9.7050400@uvic.ca>

I've created a ticket:

<http://purl.org/tei/fr/3597335>

Cheers,
Martin

On 12-12-18 01:56 PM, Sebastian Rahtz wrote:
>
> On 18 Dec 2012, at 20:56, Martin Holmes <mholmes at uvic.ca>
>   wrote:
>>>
>>> oh, its Christmas, you'll forgive me, wont you? must I switch to <ptr target="foo.mp4" rend="transclude"/>?
>>
>> Sorry indeed if I annoyed you; it wasn't my intention to tell you not to
>> do what you're doing, just to suggest that I don't think it would be a
>> good thing to recommend to other people when they ask how to deal with
>> video and audio.
>
> don't worry, I never document what I implement, so its a dark
> secret between my file and the XSL :-}
>
> --
> Sebastian Rahtz
> http://www.justgiving.com/SebastianRahtz
> Director (Research Support) of Academic IT Services
> University of Oxford IT Services
> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>
>

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From sebastian.rahtz at it.ox.ac.uk  Wed Dec 19 04:06:00 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Wed, 19 Dec 2012 09:06:00 +0000
Subject: [tei-council] quotation/@marks/defaultVal
Message-ID: <DFD2C13F-B5DA-46F7-AACB-226B07A3B36E@it.ox.ac.uk>

I haven't heard from anyone defending this, so I am zapping it.

if you meant to speak up for it, shout, and it can always come back
between now and the release
--
Sebastian Rahtz      
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431


From lou.burnard at retired.ox.ac.uk  Wed Dec 19 04:36:17 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Wed, 19 Dec 2012 09:36:17 +0000
Subject: [tei-council] some questions about non-textual components and
 media
In-Reply-To: <50D0A39E.1020901@uvic.ca>
References: <6068589664506483.WA.saeeds58yahoo.com@listserv.brown.edu>
	<50CF3F49.8090402@johnmccaskey.com>
	<AF624D57-B5E6-49B7-8C83-1310F46F3B6C@it.ox.ac.uk>
	<50CF42D3.6020107@johnmccaskey.com>
	<0922D1C5-176F-4569-A81C-A1BA3DE0079B@it.ox.ac.uk>
	<20687.18536.598674.638845@emt.ad.brown.edu>
	<FA8BD5E5-FC61-459F-B6EF-3E280A0401B8@it.ox.ac.uk>
	<50CF5CC0.9070505@uvic.ca> <50CF65A3.7070504@johnmccaskey.com>
	<50CF9C27.90807@retired.ox.ac.uk>
	<5279c8c4-e987-4a30-bc8f-1ff5afd54309@HUB02.ad.oak.ox.ac.uk>
	<50D049B8.7010207@retired.ox.ac.uk>
	<168a07fa-12d0-44ba-aa93-92ba8c6601e3@HUB05.ad.oak.ox.ac.uk>
	<50D0943D.70108@uvic.ca> <50D0A011.4060809@ling.unipi.it>
	<50D0A39E.1020901@uvic.ca>
Message-ID: <50D18A91.5010401@retired.ox.ac.uk>

On 18/12/12 17:10, Martin Holmes wrote:
> Bringing this discussion to the Council list for a minute:
>
> There's a ticket relating to handling of audio and video has already
> been open for a long time (and is assigned to me, although it's red):
>
> <https://sourceforge.net/tracker/index.php?func=detail&aid=2724997&group_id=106328&atid=644065>
>
> Council minutes from April this year show that we discussed it:
>
> <http://www.tei-c.org/Activities/Council/Meetings/tcm50.xml>
>
> ...
> and the action list shows we then postponed any action pending a report
> from Lou from a workshop on speech and video. That was taking place in
> October or November IIRC, and I can't remember if Lou reported back or not.

Well, in fact I wrote a lengthy report and circulated it to Council 
shortly after the meeting (it's still online at 
http://www.tei-c.org/Activities/Council/Working/tcw25.xml
but it did not seem to have provoked much discussion, or indeed been 
noticed. I can also report  a conversation with Thomas Schmidt at a 
conference in Bordeaux last
week, where he re-expressed the desire to progress the ideas in his jTEI 
paper, by formulating some detailed tutorial material, with an 
accompanying ODD, for evaluation by a group of european experts.

So I think this is progressing along the lines vaguely suggested in the 
ticket referred to.


From sebastian.rahtz at it.ox.ac.uk  Wed Dec 19 06:39:21 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Wed, 19 Dec 2012 11:39:21 +0000
Subject: [tei-council] TEI ODD processing stylesheets
Message-ID: <CFA306C9-7D19-4296-A3B7-9DA10EC87864@it.ox.ac.uk>

Thanks to Syd for uncovering a really serious bug in odd processing. I have had to make a new release of XSL stylesheets
to cover it.

you'd have noticed it if you provided an <attDef mode='replace'> for a attribute inherited from a class.
--
Sebastian Rahtz      
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431


From sebastian.rahtz at it.ox.ac.uk  Wed Dec 19 06:47:56 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Wed, 19 Dec 2012 11:47:56 +0000
Subject: [tei-council] tagUsage/@render
Message-ID: <B3791205-CD2A-4548-BFD4-E0738417A9B1@it.ox.ac.uk>

is bug 3596659, John M asks:

 On the description page for <tagUsage>, in the description for @render, change
	"specifies the identifier of a rendition element which defines how this element is to be rendered."
to 
	"specifies the identifier of a rendition element which defines how this element was rendered in the source text."

presumably because it contradicts 2.3.4.1 Rendition

Are we entirely agreed about this, that the long-standing phrase "_ is to be_ rendered." is not what
we intend?
--
Sebastian Rahtz      
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431


From mholmes at uvic.ca  Wed Dec 19 08:47:19 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Wed, 19 Dec 2012 05:47:19 -0800
Subject: [tei-council] some questions about non-textual components and
 media
In-Reply-To: <50D18A91.5010401@retired.ox.ac.uk>
References: <6068589664506483.WA.saeeds58yahoo.com@listserv.brown.edu>
	<50CF3F49.8090402@johnmccaskey.com>
	<AF624D57-B5E6-49B7-8C83-1310F46F3B6C@it.ox.ac.uk>
	<50CF42D3.6020107@johnmccaskey.com>
	<0922D1C5-176F-4569-A81C-A1BA3DE0079B@it.ox.ac.uk>
	<20687.18536.598674.638845@emt.ad.brown.edu>
	<FA8BD5E5-FC61-459F-B6EF-3E280A0401B8@it.ox.ac.uk>
	<50CF5CC0.9070505@uvic.ca> <50CF65A3.7070504@johnmccaskey.com>
	<50CF9C27.90807@retired.ox.ac.uk>
	<5279c8c4-e987-4a30-bc8f-1ff5afd54309@HUB02.ad.oak.ox.ac.uk>
	<50D049B8.7010207@retired.ox.ac.uk>
	<168a07fa-12d0-44ba-aa93-92ba8c6601e3@HUB05.ad.oak.ox.ac.uk>
	<50D0943D.70108@uvic.ca> <50D0A011.4060809@ling.unipi.it>
	<50D0A39E.1020901@uvic.ca> <50D18A91.5010401@retired.ox.ac.uk>
Message-ID: <50D1C567.2070504@uvic.ca>

Thanks Lou -- sorry I missed the report. I've added a link to it to the 
two previous tickets.

Do you think the <media> proposal can proceed as a preliminary step 
before we look at alignment issues in those tickets?

Cheers,
Martin

On 12-12-19 01:36 AM, Lou Burnard wrote:
> On 18/12/12 17:10, Martin Holmes wrote:
>> Bringing this discussion to the Council list for a minute:
>>
>> There's a ticket relating to handling of audio and video has already
>> been open for a long time (and is assigned to me, although it's red):
>>
>> <https://sourceforge.net/tracker/index.php?func=detail&aid=2724997&group_id=106328&atid=644065>
>>
>> Council minutes from April this year show that we discussed it:
>>
>> <http://www.tei-c.org/Activities/Council/Meetings/tcm50.xml>
>>
>> ...
>> and the action list shows we then postponed any action pending a report
>> from Lou from a workshop on speech and video. That was taking place in
>> October or November IIRC, and I can't remember if Lou reported back or not.
>
> Well, in fact I wrote a lengthy report and circulated it to Council
> shortly after the meeting (it's still online at
> http://www.tei-c.org/Activities/Council/Working/tcw25.xml
> but it did not seem to have provoked much discussion, or indeed been
> noticed. I can also report  a conversation with Thomas Schmidt at a
> conference in Bordeaux last
> week, where he re-expressed the desire to progress the ideas in his jTEI
> paper, by formulating some detailed tutorial material, with an
> accompanying ODD, for evaluation by a group of european experts.
>
> So I think this is progressing along the lines vaguely suggested in the
> ticket referred to.
>

-- 
Martin Holmes
mholmes at uvic.ca
UVic Humanities Computing and Media Centre

From kevin.s.hawkins at ultraslavonic.info  Wed Dec 19 12:02:30 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Wed, 19 Dec 2012 12:02:30 -0500
Subject: [tei-council] tagUsage/@render
In-Reply-To: <B3791205-CD2A-4548-BFD4-E0738417A9B1@it.ox.ac.uk>
References: <B3791205-CD2A-4548-BFD4-E0738417A9B1@it.ox.ac.uk>
Message-ID: <50D1F326.8050108@ultraslavonic.info>

Yes.  The various elements and attributes for describing rendition 
always refer to the source, not intended rendering.  In fact, see the 
definition of <rendition>.

Poking around the guidelines leads me to see that we have been 
inconsistent in our referring to the source as:

source
source document
source text

Would be good to pick one and stick to it.  Since some use the TEI is 
for encoding a platonic object (a source text) and others for an 
artifact (a source document), the best option seems to be "source".

On 12/19/2012 6:47 AM, Sebastian Rahtz wrote:
> is bug 3596659, John M asks:
>
>   On the description page for<tagUsage>, in the description for @render, change
> 	"specifies the identifier of a rendition element which defines how this element is to be rendered."
> to
> 	"specifies the identifier of a rendition element which defines how this element was rendered in the source text."
>
> presumably because it contradicts 2.3.4.1 Rendition
>
> Are we entirely agreed about this, that the long-standing phrase "_ is to be_ rendered." is not what
> we intend?
> --
> Sebastian Rahtz
> Director (Research Support) of Academic IT Services
> University of Oxford IT Services
> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>

From mholmes at uvic.ca  Wed Dec 19 12:26:35 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Wed, 19 Dec 2012 09:26:35 -0800
Subject: [tei-council] Minutes marked up and on the site
Message-ID: <50D1F8CB.6020601@uvic.ca>

Hi all,

Minutes from the teleconference are now on the site:

<http://www.tei-c.org/Activities/Council/Meetings/tcm53.xml>

These are the actions, some of which are done:

     JC & HC: Coordinate to select an appropriate day for the next release.
     KH: Send outstanding questions re TEI P4 deprecation to the Council 
list for comment.
     GB: Create a list of potential projects for code-bounties.
     All: Continue the discussion of moving some parts of the codebase 
into GitHub.
     MH: Raise on TEI-L the issue of collapsing the front page and the 
TOC of the Guidelines into a single page.
     EM: Create a Doodle poll for dates for Council Face-to-Face meeting 
in April.

Cheers,
Martin

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From mholmes at uvic.ca  Wed Dec 19 12:29:26 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Wed, 19 Dec 2012 09:29:26 -0800
Subject: [tei-council] tagUsage/@render
In-Reply-To: <B3791205-CD2A-4548-BFD4-E0738417A9B1@it.ox.ac.uk>
References: <B3791205-CD2A-4548-BFD4-E0738417A9B1@it.ox.ac.uk>
Message-ID: <50D1F976.8090406@uvic.ca>

On 12-12-19 03:47 AM, Sebastian Rahtz wrote:
> is bug 3596659, John M asks:
>
>   On the description page for <tagUsage>, in the description for @render, change
> 	"specifies the identifier of a rendition element which defines how this element is to be rendered."
> to
> 	"specifies the identifier of a rendition element which defines how this element was rendered in the source text."
>
> presumably because it contradicts 2.3.4.1 Rendition
>
> Are we entirely agreed about this, that the long-standing phrase "_ is to be_ rendered." is not what
> we intend?

I agree. I thought all the various rendition-related stuff was designed 
to describe what the source document looked like.

Cheers,
Martin

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From lou.burnard at retired.ox.ac.uk  Wed Dec 19 15:06:58 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Wed, 19 Dec 2012 20:06:58 +0000
Subject: [tei-council] quotation/@marks/defaultVal
In-Reply-To: <DFD2C13F-B5DA-46F7-AACB-226B07A3B36E@it.ox.ac.uk>
References: <DFD2C13F-B5DA-46F7-AACB-226B07A3B36E@it.ox.ac.uk>
Message-ID: <50D21E62.2060609@retired.ox.ac.uk>

On 19/12/12 09:06, Sebastian Rahtz wrote:
> I haven't heard from anyone defending this, so I am zapping it.
>
> if you meant to speak up for it, shout, and it can always come back
> between now and the release
> --

I don't object to removing the defaultVal, but I would like those quote 
marks back inside a few of the example <quote>s



From sebastian.rahtz at it.ox.ac.uk  Wed Dec 19 15:35:52 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Wed, 19 Dec 2012 20:35:52 +0000
Subject: [tei-council] quotation/@marks/defaultVal
In-Reply-To: <50D21E62.2060609@retired.ox.ac.uk>
References: <DFD2C13F-B5DA-46F7-AACB-226B07A3B36E@it.ox.ac.uk>,
	<50D21E62.2060609@retired.ox.ac.uk>
Message-ID: <a70c08c5-a0b3-4918-b31b-f85006cdcb26@HUB04.ad.oak.ox.ac.uk>


> 
> I don't object to removing the defaultVal, but I would like those quote 
> marks back inside a few of the example <quote>s
> 

Sure, but how will you want to show the difference? With a quotation element?

S

From lou.burnard at retired.ox.ac.uk  Wed Dec 19 15:37:20 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Wed, 19 Dec 2012 20:37:20 +0000
Subject: [tei-council] quotation/@marks/defaultVal
In-Reply-To: <AF90F0AF-9567-4507-9795-8EA1EB117936@oucs.ox.ac.uk>
References: <DFD2C13F-B5DA-46F7-AACB-226B07A3B36E@it.ox.ac.uk>,
	<50D21E62.2060609@retired.ox.ac.uk>
	<AF90F0AF-9567-4507-9795-8EA1EB117936@oucs.ox.ac.uk>
Message-ID: <50D22580.1000809@retired.ox.ac.uk>

On 19/12/12 20:35, Sebastian Rahtz wrote:
>> I don't object to removing the defaultVal, but I would like those quote
>> marks back inside a few of the example <quote>s
>>
> Sure, but how will you want to show the difference? With a quotation element?
>

Not necessarily.



From sebastian.rahtz at it.ox.ac.uk  Wed Dec 19 17:05:55 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Wed, 19 Dec 2012 22:05:55 +0000
Subject: [tei-council] quotation/@marks/defaultVal
In-Reply-To: <50D22580.1000809@retired.ox.ac.uk>
References: <DFD2C13F-B5DA-46F7-AACB-226B07A3B36E@it.ox.ac.uk>,
	<50D21E62.2060609@retired.ox.ac.uk>
	<AF90F0AF-9567-4507-9795-8EA1EB117936@oucs.ox.ac.uk>
	<50D22580.1000809@retired.ox.ac.uk>
Message-ID: <af634baa-7bd0-4847-8020-b4e4e7316dd9@HUB06.ad.oak.ox.ac.uk>

On 19 Dec 2012, at 20:37, Lou Burnard <lou.burnard at retired.ox.ac.uk>
 wrote:

>>> I don't object to removing the defaultVal, but I would like those quote
>>> marks back inside a few of the example <quote>s
>>> 
>> Sure, but how will you want to show the difference? With a quotation element?
>> 
> 
> Not necessarily.


Banged a few back in <said>, see what you think. I did use <quotation> there, because my heart fails me
at the thought of sibling examples with and without quotes.

did it in <said> cos <quote> only has one example.

--
Sebastian Rahtz      
http://www.justgiving.com/SebastianRahtz
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431


From James.Cummings at it.ox.ac.uk  Thu Dec 20 04:29:58 2012
From: James.Cummings at it.ox.ac.uk (James Cummings)
Date: Thu, 20 Dec 2012 09:29:58 +0000
Subject: [tei-council] SF Tickets getting agreement on Council mailing list
Message-ID: <50D2DA96.3010502@it.ox.ac.uk>

Hi all,

At some point probably in the next few days, I'm going to do a 
triage of SF tickets -- sort of like the triages that have been 
done before face2face meetings -- to try to remind ourselves of 
the tickets that we need to finish off and assign unassigned 
tickets to people.

As part of that I'll go through and assign tickets to people I 
think vaguely might be interested in them or willing to do them. 
  If that means I assign you a ticket that you really don't think 
you can do, even with help, then reassign it back to me! 
Certainly don't be offended if I assign you something you think 
horrible.

So if you want to ensure you get particular tickets go to
http://purl.org/tei/fr
and set assignee to 'nobody' and status to 'open' and click Filter.
Likewise with http://purl.org/tei/bug

I will try to spread the tickets around, especially to those not 
having lots of tickets at the moment and assign our new members 
of Council some tickets as well!

Best,
-James

-- 
Dr James Cummings, James.Cummings at it.ox.ac.uk
Research Support, IT Services, University of Oxford

From kevin.s.hawkins at ultraslavonic.info  Thu Dec 20 09:14:55 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Thu, 20 Dec 2012 09:14:55 -0500
Subject: [tei-council] SF Tickets getting agreement on Council mailing
 list
In-Reply-To: <50D2DA96.3010502@it.ox.ac.uk>
References: <50D2DA96.3010502@it.ox.ac.uk>
Message-ID: <50D31D5F.7010303@ultraslavonic.info>

James, I'm confused.  You said:

On 12/20/12 4:29 AM, James Cummings wrote:
> So if you want to ensure you get particular tickets go to
> http://purl.org/tei/fr
> and set assignee to 'nobody' and status to 'open' and click Filter.
> Likewise with http://purl.org/tei/bug

but this will just let you find unassigned tickets (those that haven't 
yet been "triaged").  Are you suggesting that people then claim any 
tickets they're interested in, by assigning them to themselves?

From James.Cummings at it.ox.ac.uk  Thu Dec 20 09:53:25 2012
From: James.Cummings at it.ox.ac.uk (James Cummings)
Date: Thu, 20 Dec 2012 14:53:25 +0000
Subject: [tei-council] SF Tickets getting agreement on Council mailing
 list
In-Reply-To: <50D31D5F.7010303@ultraslavonic.info>
References: <50D2DA96.3010502@it.ox.ac.uk>
	<50D31D5F.7010303@ultraslavonic.info>
Message-ID: <50D32665.7000903@it.ox.ac.uk>

On 20/12/12 14:14, Kevin Hawkins wrote:
> James, I'm confused.  You said:
>
> On 12/20/12 4:29 AM, James Cummings wrote:
>> So if you want to ensure you get particular tickets go to
>> http://purl.org/tei/fr
>> and set assignee to 'nobody' and status to 'open' and click Filter.
>> Likewise with http://purl.org/tei/bug
>
> but this will just let you find unassigned tickets (those that haven't
> yet been "triaged").  Are you suggesting that people then claim any
> tickets they're interested in, by assigning them to themselves?


Correct! Exactly that! Apologies, I thought that was clear. I 
have no desire to stop people working on tickets they are 
interested in implementing... quite the reverse.  Sadly we all 
have to work on some tickets we're less interested in completing 
as well. :-)  I'll assign the rest in another few days.

What I'd like also to do is to get a workflow agreed going for 
assenting to decisions made on tickets as well. For example, 
Sebastian's asking about @defaultVal highlights that we probably 
want to be able to assume that silence equals assent as long as 
there has been a suitable period of time, a reminder, and any 
discussion summarised on the ticket. This should probably be for 
'green' categorised tickets (or corrigible bugs) since 'amber' 
implies they need further discussion. I want to remove any 
roadblocks from us completing tickets but also keep Council 
oversight of them. We all volunteer our work at different times 
and are usually very busy with all sorts of other concerns.

Any thoughts?

-James


-- 
Dr James Cummings, James.Cummings at it.ox.ac.uk
Academic IT Services, University of Oxford

From James.Cummings at it.ox.ac.uk  Thu Dec 20 11:27:28 2012
From: James.Cummings at it.ox.ac.uk (James Cummings)
Date: Thu, 20 Dec 2012 16:27:28 +0000
Subject: [tei-council] Some working papers the new Council members might
 like to look at
In-Reply-To: <50CF5224.9070605@uvic.ca>
References: <50CF5224.9070605@uvic.ca>
Message-ID: <50D33C70.4070501@it.ox.ac.uk>


Hi all,

I've just added Elli to the TEI project on sourceforge (Hugh and 
Syd already had access).  The main task that new members should 
do is make sure that they are able to edit the guidelines, commit 
changes, and see them build on Jenkins.  See the list at:

http://www.tei-c.org/Activities/Council/Working/tcw20.xml#body.1_div.4

which probably needs some expansion.

Whenever you have any questions post them here and we can improve 
that document!

Best,

-james

On 17/12/12 17:11, Martin Holmes wrote:
> Hi all,
>
> During the teleconference, James mentioned that there are some useful
> resources on the wiki for Council members. There are also some helpful
> documents on the TEI site itself, in the working papers:
>
> TCW 20: "How to edit the TEI Guidelines"
> <http://www.tei-c.org/Activities/Council/Working/tcw20.xml>
>
> This is a work-in-progress which endeavours to explain how the
> Guidelines are built, and how to make changes and check that your
> changes have worked. Now I come to look at it, I see at least one thing
> which is out of date (it tells you to use <!ENTITY...> declarations when
> you add a new file, and we've now switched over to XInclude, so I'll
> have to update that bit). But that aside, I think it's helpful.
>
> TCW22: "Building a TEI Release"
> <http://www.tei-c.org/Activities/Council/Working/tcw22.xml>
>
> This is the document that Hugh will have to follow when he's acting as
> the release technician in January. It aims to be a complete,
> step-by-step guide to everything that needs to happen during the release
> process. We've used it for several releases now, and every time, we've
> added more detail, clarification or correction, so it's pretty good at
> this point.
>
> TCW 24: " Style Guide for Editing the TEI Guidelines"
> <http://www.tei-c.org/Activities/Council/Working/tcw24.xml>
>
> This is currently quite basic, but growing; it tends to be added to when
> we have some disagreement or discussion about some element of style, and
> need to record our consensus.
>
> While you are new and getting familiar with the system, it would be
> helpful if you could make some notes on what is puzzling or
> undocumented, so we can fill those holes with better explanatory material.
>
> Cheers,
> Martin
>


-- 
Dr James Cummings, James.Cummings at it.ox.ac.uk
Academic IT Services, University of Oxford

From James.Cummings at it.ox.ac.uk  Thu Dec 20 11:29:48 2012
From: James.Cummings at it.ox.ac.uk (James Cummings)
Date: Thu, 20 Dec 2012 16:29:48 +0000
Subject: [tei-council] tagUsage/@render
In-Reply-To: <50D1F976.8090406@uvic.ca>
References: <B3791205-CD2A-4548-BFD4-E0738417A9B1@it.ox.ac.uk>
	<50D1F976.8090406@uvic.ca>
Message-ID: <50D33CFC.7050305@it.ox.ac.uk>

On 19/12/12 17:29, Martin Holmes wrote:
>> Are we entirely agreed about this, that the long-standing phrase "_ is to be_ rendered." is not what
>> we intend?
>
> I agree. I thought all the various rendition-related stuff was designed
> to describe what the source document looked like.

I agree certainly, as I've argued many times all rendition in TEI 
should be about the source document because we can make countless 
presentations in different outputs...recording just one of them 
is nonsensical IMHO.

-James


-- 
Dr James Cummings, James.Cummings at it.ox.ac.uk
Academic IT Services, University of Oxford

From sebastian.rahtz at it.ox.ac.uk  Thu Dec 20 11:32:02 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Thu, 20 Dec 2012 16:32:02 +0000
Subject: [tei-council] Some working papers the new Council members might
 like to look at
In-Reply-To: <50D33C70.4070501@it.ox.ac.uk>
References: <50CF5224.9070605@uvic.ca> <50D33C70.4070501@it.ox.ac.uk>
Message-ID: <efd4d9ae-1e80-4bd0-a656-87a9fdd81835@HUB03.ad.oak.ox.ac.uk>


On 20 Dec 2012, at 16:27, James Cummings <James.Cummings at it.ox.ac.uk>
 wrote:

> 
> I've just added Elli to the TEI project on sourceforge (Hugh and 
> Syd already had access).  The main task that new members should 
> do is make sure that they are able to edit the guidelines, commit 
> changes, and see them build on Jenkins.  

Hugh will also need an account on www.tei-c.org for January release
--
Sebastian Rahtz      
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431


From sebastian.rahtz at it.ox.ac.uk  Thu Dec 20 11:35:27 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Thu, 20 Dec 2012 16:35:27 +0000
Subject: [tei-council] tagUsage/@render
In-Reply-To: <50D33CFC.7050305@it.ox.ac.uk>
References: <B3791205-CD2A-4548-BFD4-E0738417A9B1@it.ox.ac.uk>
	<50D1F976.8090406@uvic.ca> <50D33CFC.7050305@it.ox.ac.uk>
Message-ID: <76bb36b1-05a7-4cb5-9008-13d6f872eaab@HUB02.ad.oak.ox.ac.uk>


On 20 Dec 2012, at 16:29, James Cummings <james.cummings at it.ox.ac.uk> wrote:

>>> Are we entirely agreed about this, that the long-standing phrase "_ is to be_ rendered." is not what
>>> we intend?
>> 
>> I agree. I thought all the various rendition-related stuff was designed
>> to describe what the source document looked like.
> 
> I agree certainly, as I've argued many times all rendition in TEI 
> should be about the source document

tagUsage/@render is now in line, as per John McC's wording in SF ticket.

someone want to look at http://bits.nsms.ox.ac.uk:8080/jenkins/job/TEIP5/lastSuccessfulBuild/artifact/release/doc/tei-p5-doc/en/html/ref-said.html
and see if they like the examples of quotation marks? would you rather these appear in the main chapter?
--
Sebastian Rahtz      
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431


From mholmes at uvic.ca  Thu Dec 20 12:02:31 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Thu, 20 Dec 2012 09:02:31 -0800
Subject: [tei-council] SF Tickets getting agreement on Council mailing
 list
In-Reply-To: <50D32665.7000903@it.ox.ac.uk>
References: <50D2DA96.3010502@it.ox.ac.uk>
	<50D31D5F.7010303@ultraslavonic.info>
	<50D32665.7000903@it.ox.ac.uk>
Message-ID: <50D344A7.7020706@uvic.ca>

On 12-12-20 06:53 AM, James Cummings wrote:

> What I'd like also to do is to get a workflow agreed going for
> assenting to decisions made on tickets as well. For example,
> Sebastian's asking about @defaultVal highlights that we probably
> want to be able to assume that silence equals assent as long as
> there has been a suitable period of time, a reminder, and any
> discussion summarised on the ticket. This should probably be for
> 'green' categorised tickets (or corrigible bugs) since 'amber'
> implies they need further discussion. I want to remove any
> roadblocks from us completing tickets but also keep Council
> oversight of them. We all volunteer our work at different times
> and are usually very busy with all sorts of other concerns.
>
> Any thoughts?

For substantial changes, I think it's good to commit your changes and 
record the revision number on the ticket, but then send a message to the 
Council list asking people to check over your work. Note that you've 
done this on the ticket, and leave the ticket open for a few days to 
allow for feedback, then close it once any feedback has been 
incorporated, or in the case of silence.

This section of our guide:

<http://www.tei-c.org/Activities/Council/Working/tcw20.xml#body.1_div.4>

says this:

"Assuming the change was successful (see below), add a comment to the 
SourceForge ticket which includes the SVN revision number of your 
commit. You may also close the ticket if it is complete."

but we might want to expand the last bit to incorporate a period for 
feedback.

Cheers,
Martin



-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From mholmes at uvic.ca  Thu Dec 20 12:13:03 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Thu, 20 Dec 2012 09:13:03 -0800
Subject: [tei-council] tagUsage/@render
In-Reply-To: <76bb36b1-05a7-4cb5-9008-13d6f872eaab@HUB02.ad.oak.ox.ac.uk>
References: <B3791205-CD2A-4548-BFD4-E0738417A9B1@it.ox.ac.uk>
	<50D1F976.8090406@uvic.ca> <50D33CFC.7050305@it.ox.ac.uk>
	<76bb36b1-05a7-4cb5-9008-13d6f872eaab@HUB02.ad.oak.ox.ac.uk>
Message-ID: <50D3471F.6070800@uvic.ca>

These look good to me. The last example (beginning with "Hmmm") doesn't 
have any linebreaks in it, so it makes the page scroll horizontally.

Looking at the chapter, though, I see this example:

<said rend="PRE+lsquo POST+rsquo">

while in the said.xml, we have this:

<said aloud="true" rend="pre(?) post(?)">

I wonder if we should be consistent there? Although anything token-like 
goes in @rend, people tend to think of examples in the Guidelines as a 
bit authoritative, so it might be confusing to see two ways of doing the 
same thing.

I still have trouble disambiguating <q> from <said>, and <q> from 
<quote>. I have malicious thoughts towards <q>.

Cheers,
Martin

On 12-12-20 08:35 AM, Sebastian Rahtz wrote:
>
> On 20 Dec 2012, at 16:29, James Cummings <james.cummings at it.ox.ac.uk> wrote:
>
>>>> Are we entirely agreed about this, that the long-standing phrase "_ is to be_ rendered." is not what
>>>> we intend?
>>>
>>> I agree. I thought all the various rendition-related stuff was designed
>>> to describe what the source document looked like.
>>
>> I agree certainly, as I've argued many times all rendition in TEI
>> should be about the source document
>
> tagUsage/@render is now in line, as per John McC's wording in SF ticket.
>
> someone want to look at http://bits.nsms.ox.ac.uk:8080/jenkins/job/TEIP5/lastSuccessfulBuild/artifact/release/doc/tei-p5-doc/en/html/ref-said.html
> and see if they like the examples of quotation marks? would you rather these appear in the main chapter?
> --
> Sebastian Rahtz
> Director (Research Support) of Academic IT Services
> University of Oxford IT Services
> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From lou.burnard at retired.ox.ac.uk  Thu Dec 20 14:02:52 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Thu, 20 Dec 2012 19:02:52 +0000
Subject: [tei-council] tagUsage/@render
In-Reply-To: <50D3471F.6070800@uvic.ca>
References: <B3791205-CD2A-4548-BFD4-E0738417A9B1@it.ox.ac.uk>
	<50D1F976.8090406@uvic.ca> <50D33CFC.7050305@it.ox.ac.uk>
	<76bb36b1-05a7-4cb5-9008-13d6f872eaab@HUB02.ad.oak.ox.ac.uk>
	<50D3471F.6070800@uvic.ca>
Message-ID: <50D360DC.3080102@retired.ox.ac.uk>

On 20/12/12 17:13, Martin Holmes wrote:
> Looking at the chapter, though, I see this example:
>
> <said rend="PRE+lsquo POST+rsquo">
>
> while in the said.xml, we have this:
>
> <said aloud="true" rend="pre(?) post(?)">
>
> I wonder if we should be consistent there? Although anything token-like
> goes in @rend, people tend to think of examples in the Guidelines as a
> bit authoritative, so it might be confusing to see two ways of doing the
> same thing.

Sebastian raised the same point when we were talking about these <said> 
examples a week or two ago. It might b e a good idea to add an example 
using @render with predefined CSS or @style with non-predefined CSS if 
that's the example we think we'd rather people followed.


| I still have trouble disambiguating <q> from <said>, and <q> from 
<quote>. I have malicious thoughts towards <q>.

This maybe is something you should share with your confessor. Happy to 
help out if you need explanation...

Lou


Cheers, Martin On 12-12-20 08:35 AM, Sebastian Rahtz wrote:
>> On 20 Dec 2012, at 16:29, James Cummings <james.cummings at it.ox.ac.uk> wrote:
>>
>>>>> Are we entirely agreed about this, that the long-standing phrase "_ is to be_ rendered." is not what
>>>>> we intend?
>>>> I agree. I thought all the various rendition-related stuff was designed
>>>> to describe what the source document looked like.
>>> I agree certainly, as I've argued many times all rendition in TEI
>>> should be about the source document
>> tagUsage/@render is now in line, as per John McC's wording in SF ticket.
>>
>> someone want to look at http://bits.nsms.ox.ac.uk:8080/jenkins/job/TEIP5/lastSuccessfulBuild/artifact/release/doc/tei-p5-doc/en/html/ref-said.html
>> and see if they like the examples of quotation marks? would you rather these appear in the main chapter?
>> --
>> Sebastian Rahtz
>> Director (Research Support) of Academic IT Services
>> University of Oxford IT Services
>> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>>


From James.Cummings at it.ox.ac.uk  Thu Dec 20 14:08:33 2012
From: James.Cummings at it.ox.ac.uk (James Cummings)
Date: Thu, 20 Dec 2012 19:08:33 +0000
Subject: [tei-council] Some working papers the new Council members might
 like to look at
In-Reply-To: <E92D9E3C-8D8B-44A3-B36E-8EC5F4ABCEBF@it.ox.ac.uk>
References: <50CF5224.9070605@uvic.ca> <50D33C70.4070501@it.ox.ac.uk>
	<E92D9E3C-8D8B-44A3-B36E-8EC5F4ABCEBF@it.ox.ac.uk>
Message-ID: <50D36231.8080202@it.ox.ac.uk>

On 20/12/12 16:32, Sebastian Rahtz wrote:
> Hugh will also need an account on www.tei-c.org for January release

Already on my to-do list, don't worry. ;-)

-James

-- 
Dr James Cummings, James.Cummings at it.ox.ac.uk
Academic IT Services, University of Oxford

From kevin.s.hawkins at ultraslavonic.info  Thu Dec 20 23:13:21 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Thu, 20 Dec 2012 23:13:21 -0500
Subject: [tei-council] Attributes without examples
In-Reply-To: <502848C5.5030504@uvic.ca>
References: <5028011F.4050007@it.ox.ac.uk> <502848C5.5030504@uvic.ca>
Message-ID: <50D3E1E1.7080201@ultraslavonic.info>

To bring back an old thread, I've looked at this wiki page that Martin 
created and seen that it includes attributes that have a defined list of 
legal values.  It seems to me that there's not much point in giving 
examples of these since the list of values generally explains what each 
means.

Martin, do you still have the code you used to create the list?  Could 
you possibly exclude those that have a list of legal values?  If you are 
able to create this list, we are still, unfortunately, stuck merging the 
existing page, where people have signed up to add certain examples.

--Kevin

On 8/12/12 8:22 PM, Martin Holmes wrote:
> The last time I took a look through these, I seem to remember coming to
> the conclusion that one situation in particular is most urgent: where
> attributes are declared in an attribute class, and none of the elements
> which are members of that attribute class have examples which illustrate
> the use of that attribute.
>
> I'm not sure how many of these there are -- I was halfway through some
> XSLT to find out, but I got distracted. I'll try to finish that.
>
> Cheers,
> Martin
>
> On 12-08-12 12:16 PM, James Cummings wrote:
>>
>> One of the things that Kevin reminded me of recently was that we
>> still have lots of attributes without examples:
>>
>> http://wiki.tei-c.org/index.php/AttsWithoutEgs
>>
>> I'm as guilty as the others who have not signed up to provide
>> some, but will try to do so in the next week or two.  Any other
>> suggestions? Can everyone sign up to provide some examples?
>>
>> -James
>>

From sebastian.rahtz at it.ox.ac.uk  Fri Dec 21 05:05:25 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Fri, 21 Dec 2012 10:05:25 +0000
Subject: [tei-council] tagUsage/@render
In-Reply-To: <50D360DC.3080102@retired.ox.ac.uk>
References: <B3791205-CD2A-4548-BFD4-E0738417A9B1@it.ox.ac.uk>
	<50D1F976.8090406@uvic.ca> <50D33CFC.7050305@it.ox.ac.uk>
	<76bb36b1-05a7-4cb5-9008-13d6f872eaab@HUB02.ad.oak.ox.ac.uk>
	<50D3471F.6070800@uvic.ca> <50D360DC.3080102@retired.ox.ac.uk>
Message-ID: <857d0f3d-1231-4b1f-8c06-f26bf6378ae3@HUB06.ad.oak.ox.ac.uk>


On 20 Dec 2012, at 19:02, Lou Burnard <lou.burnard at retired.ox.ac.uk> wrote:

> Sebastian raised the same point when we were talking about these <said> 
> examples a week or two ago. It might b e a good idea to add an example 
> using @render with predefined CSS or @style with non-predefined CSS if 
> that's the example we think we'd rather people followed.
> 
I am working on this now, results for inspection shortly
--
Sebastian Rahtz      
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431


From sebastian.rahtz at it.ox.ac.uk  Fri Dec 21 05:57:09 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Fri, 21 Dec 2012 10:57:09 +0000
Subject: [tei-council] tagUsage/@render
Message-ID: <4057CE62-214C-454A-AEAA-F0DCC9B93185@it.ox.ac.uk>

while attempting to make examples of this, I found an anomaly.

I want to say that <said> is always rendered with double quote marks fore and aft. So in the header I write

     <rendition xml:id="prequote" scheme="css" scope="before">content:"?";</rendition>
      <rendition xml:id="postquote" scheme="css"	 scope="after">content:"?";</rendition>
      <namespace name="http://www.tei-c.org/ns/1.0">
	<tagUsage gi="said" render="#prequote #postquote"/>
      </namespace>

notice that because I need content added before _and_ after, I have to define two <rendition>, with different @scope
values. This means the tagUSage needs to point to _both_ rendition rules.

Flaw: @render is only allowed one value.

Action: I have changed the datatype to allow multiple space-separates values.

Justification: I claim this is a corrigible error

You: if you disagree, shout at me
--
Sebastian Rahtz      
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431


From lou.burnard at retired.ox.ac.uk  Fri Dec 21 07:51:08 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Fri, 21 Dec 2012 12:51:08 +0000
Subject: [tei-council] tagUsage/@render
In-Reply-To: <4057CE62-214C-454A-AEAA-F0DCC9B93185@it.ox.ac.uk>
References: <4057CE62-214C-454A-AEAA-F0DCC9B93185@it.ox.ac.uk>
Message-ID: <50D45B3C.1080003@retired.ox.ac.uk>

On 21/12/12 10:57, Sebastian Rahtz wrote:
> while attempting to make examples of this, I found an anomaly.
>
> I want to say that <said> is always rendered with double quote marks fore and aft. So in the header I write
>
>       <rendition xml:id="prequote" scheme="css" scope="before">content:"?";</rendition>
>        <rendition xml:id="postquote" scheme="css"	 scope="after">content:"?";</rendition>
>        <namespace name="http://www.tei-c.org/ns/1.0">
> 	<tagUsage gi="said" render="#prequote #postquote"/>
>        </namespace>
>
> notice that because I need content added before _and_ after, I have to define two <rendition>, with different @scope
> values. This means the tagUSage needs to point to _both_ rendition rules.
>
> Flaw: @render is only allowed one value.
>
> Action: I have changed the datatype to allow multiple space-separates values.
>
> Justification: I claim this is a corrigible error
>
> You: if you disagree, shout at me


I SHOUT AGREEMENT

(noting however that we thus open the door to nonsensical codings where 
the <renditions> indicated cannot be meaningfully combined)

From sebastian.rahtz at it.ox.ac.uk  Fri Dec 21 08:11:08 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Fri, 21 Dec 2012 13:11:08 +0000
Subject: [tei-council] tagUsage/@render
In-Reply-To: <50D45B3C.1080003@retired.ox.ac.uk>
References: <4057CE62-214C-454A-AEAA-F0DCC9B93185@it.ox.ac.uk>
	<50D45B3C.1080003@retired.ox.ac.uk>
Message-ID: <06cee3ca-a602-47b8-a5b6-9f250ae620e2@HUB03.ad.oak.ox.ac.uk>


On 21 Dec 2012, at 12:51, Lou Burnard <lou.burnard at retired.ox.ac.uk> wrote:
> 
> I SHOUT AGREEMENT
> 
> (noting however that we thus open the door to nonsensical codings where 
> the <renditions> indicated cannot be meaningfully combined)

yes, indeed, but at least tagUsage/@render can now sin in the same way as 
@rend and @rendition

--
Sebastian Rahtz      
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431


From lou.burnard at retired.ox.ac.uk  Fri Dec 21 08:21:57 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Fri, 21 Dec 2012 13:21:57 +0000
Subject: [tei-council] tagUsage/@render
In-Reply-To: <7CEA5013-2DF6-4B43-A498-42462060CF71@it.ox.ac.uk>
References: <4057CE62-214C-454A-AEAA-F0DCC9B93185@it.ox.ac.uk>
	<50D45B3C.1080003@retired.ox.ac.uk>
	<7CEA5013-2DF6-4B43-A498-42462060CF71@it.ox.ac.uk>
Message-ID: <50D46275.6080907@retired.ox.ac.uk>

On 21/12/12 13:11, Sebastian Rahtz wrote:
>
> On 21 Dec 2012, at 12:51, Lou Burnard <lou.burnard at retired.ox.ac.uk> wrote:
>>
>> I SHOUT AGREEMENT
>>
>> (noting however that we thus open the door to nonsensical codings where
>> the <renditions> indicated cannot be meaningfully combined)
>
> yes, indeed, but at least tagUsage/@render can now sin in the same way as
> @rend and @rendition
>
>

I'm not in general in favour of extending this particular franchise : 
maybe a sentence or two of warning in the text would be useful ...

@rend is a hopeless case, but @rendition at least should be constrained 
to respect the usage of its target syntax, if only by a statement of 
intent.

From sebastian.rahtz at it.ox.ac.uk  Fri Dec 21 08:26:35 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Fri, 21 Dec 2012 13:26:35 +0000
Subject: [tei-council] tagUsage/@render
In-Reply-To: <50D46275.6080907@retired.ox.ac.uk>
References: <4057CE62-214C-454A-AEAA-F0DCC9B93185@it.ox.ac.uk>
	<50D45B3C.1080003@retired.ox.ac.uk>
	<7CEA5013-2DF6-4B43-A498-42462060CF71@it.ox.ac.uk>
	<50D46275.6080907@retired.ox.ac.uk>
Message-ID: <f2d7042d-8f2c-4838-a83f-6eea5beed3e0@HUB06.ad.oak.ox.ac.uk>


On 21 Dec 2012, at 13:21, Lou Burnard <lou.burnard at retired.ox.ac.uk>
 wrote:
> 
> I'm not in general in favour of extending this particular franchise : maybe a sentence or two of warning in the text would be useful ...
> 
> @rend is a hopeless case, but @rendition at least should be constrained to respect the usage of its target syntax, if only by a statement of intent.


do you mean that we need to tell people that

 <rendition xml:id="funny" scheme="css":>font-style:normal; font-style:italic</rendition>

is silly? or do you mean say that the content must be syntactically correct CSS?

Are you looking to protect against syntactic sin or semantic sin?
--
Sebastian Rahtz      
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431


From mholmes at uvic.ca  Fri Dec 21 08:36:14 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Fri, 21 Dec 2012 05:36:14 -0800
Subject: [tei-council] Attributes without examples
In-Reply-To: <50D3E1E1.7080201@ultraslavonic.info>
References: <5028011F.4050007@it.ox.ac.uk> <502848C5.5030504@uvic.ca>
	<50D3E1E1.7080201@ultraslavonic.info>
Message-ID: <50D465CE.3010509@uvic.ca>

Hi Kevin,

I'm sure I have the code around somewhere. That page is quite out of 
date, and I think it was in any case too daunting; a more practical 
project might be to pick a smaller subset to work on, and eliminating 
attributes with defined or suggested values might be a good way to do 
that. I'll generate a new page.

Cheers,
Martin



On 12-12-20 08:13 PM, Kevin Hawkins wrote:
> To bring back an old thread, I've looked at this wiki page that Martin
> created and seen that it includes attributes that have a defined list of
> legal values.  It seems to me that there's not much point in giving
> examples of these since the list of values generally explains what each
> means.
>
> Martin, do you still have the code you used to create the list?  Could
> you possibly exclude those that have a list of legal values?  If you are
> able to create this list, we are still, unfortunately, stuck merging the
> existing page, where people have signed up to add certain examples.
>
> --Kevin
>
> On 8/12/12 8:22 PM, Martin Holmes wrote:
>> The last time I took a look through these, I seem to remember coming to
>> the conclusion that one situation in particular is most urgent: where
>> attributes are declared in an attribute class, and none of the elements
>> which are members of that attribute class have examples which illustrate
>> the use of that attribute.
>>
>> I'm not sure how many of these there are -- I was halfway through some
>> XSLT to find out, but I got distracted. I'll try to finish that.
>>
>> Cheers,
>> Martin
>>
>> On 12-08-12 12:16 PM, James Cummings wrote:
>>>
>>> One of the things that Kevin reminded me of recently was that we
>>> still have lots of attributes without examples:
>>>
>>> http://wiki.tei-c.org/index.php/AttsWithoutEgs
>>>
>>> I'm as guilty as the others who have not signed up to provide
>>> some, but will try to do so in the next week or two.  Any other
>>> suggestions? Can everyone sign up to provide some examples?
>>>
>>> -James
>>>

-- 
Martin Holmes
mholmes at uvic.ca
UVic Humanities Computing and Media Centre

From sebastian.rahtz at it.ox.ac.uk  Fri Dec 21 10:09:03 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Fri, 21 Dec 2012 15:09:03 +0000
Subject: [tei-council] tagUsage/@render
Message-ID: <8C0DC069-CD54-4688-A92B-C424BA6EDE4A@it.ox.ac.uk>

I have changed some of the examples in http://bits.nsms.ox.ac.uk:8080/jenkins/job/TEIP5/lastSuccessfulBuild/artifact/release/doc/tei-p5-doc/en/html/CO.html#COHQQ
to a) use the same rendition-latter syntax as the <said> reference page, and b) have one with a proper rendition link

look well, o wolves
--
Sebastian Rahtz      
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431


From sebastian.rahtz at it.ox.ac.uk  Fri Dec 21 10:39:38 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Fri, 21 Dec 2012 15:39:38 +0000
Subject: [tei-council] tagUsage/@render
In-Reply-To: <50D3471F.6070800@uvic.ca>
References: <B3791205-CD2A-4548-BFD4-E0738417A9B1@it.ox.ac.uk>
	<50D1F976.8090406@uvic.ca> <50D33CFC.7050305@it.ox.ac.uk>
	<76bb36b1-05a7-4cb5-9008-13d6f872eaab@HUB02.ad.oak.ox.ac.uk>
	<50D3471F.6070800@uvic.ca>
Message-ID: <17D29C9A-D3BB-443A-997B-2D771BCCD926@it.ox.ac.uk>


On 20 Dec 2012, at 17:13, Martin Holmes <mholmes at uvic.ca> wrote:
> Looking at the chapter, though, I see this example:
> 
> <said rend="PRE+lsquo POST+rsquo">
> 
> while in the said.xml, we have this:
> 
> <said aloud="true" rend="pre(?) post(?)">
> 
the use of PRE+ notation has now been eliminated from the Guidelines.
the examples use the the pre(xxx) notation instead.

I removed the tentative I had for this stuff in my XSL,
as it didn't work right anyway
--
Sebastian Rahtz      
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431


From mholmes at uvic.ca  Fri Dec 21 11:11:11 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Fri, 21 Dec 2012 08:11:11 -0800
Subject: [tei-council] Attributes without examples
In-Reply-To: <50D3E1E1.7080201@ultraslavonic.info>
References: <5028011F.4050007@it.ox.ac.uk> <502848C5.5030504@uvic.ca>
	<50D3E1E1.7080201@ultraslavonic.info>
Message-ID: <50D48A1F.60202@uvic.ca>

I've posted a new list:

<http://wiki.tei-c.org/index.php/AttsWithoutEgs>

It's a bit shorter (only 164 attributes). I'll do a bit more work on it 
-- my code wasn't dealing with @xml:* attributes properly, and I also 
want to turn the "Defined in" field into a link to the appropriate page 
on the latest Jenkins build.

Cheers,
Martin

On 12-12-20 08:13 PM, Kevin Hawkins wrote:
> To bring back an old thread, I've looked at this wiki page that Martin
> created and seen that it includes attributes that have a defined list of
> legal values.  It seems to me that there's not much point in giving
> examples of these since the list of values generally explains what each
> means.
>
> Martin, do you still have the code you used to create the list?  Could
> you possibly exclude those that have a list of legal values?  If you are
> able to create this list, we are still, unfortunately, stuck merging the
> existing page, where people have signed up to add certain examples.
>
> --Kevin
>
> On 8/12/12 8:22 PM, Martin Holmes wrote:
>> The last time I took a look through these, I seem to remember coming to
>> the conclusion that one situation in particular is most urgent: where
>> attributes are declared in an attribute class, and none of the elements
>> which are members of that attribute class have examples which illustrate
>> the use of that attribute.
>>
>> I'm not sure how many of these there are -- I was halfway through some
>> XSLT to find out, but I got distracted. I'll try to finish that.
>>
>> Cheers,
>> Martin
>>
>> On 12-08-12 12:16 PM, James Cummings wrote:
>>>
>>> One of the things that Kevin reminded me of recently was that we
>>> still have lots of attributes without examples:
>>>
>>> http://wiki.tei-c.org/index.php/AttsWithoutEgs
>>>
>>> I'm as guilty as the others who have not signed up to provide
>>> some, but will try to do so in the next week or two.  Any other
>>> suggestions? Can everyone sign up to provide some examples?
>>>
>>> -James
>>>

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From kevin.s.hawkins at ultraslavonic.info  Fri Dec 21 11:27:51 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Fri, 21 Dec 2012 11:27:51 -0500
Subject: [tei-council] Attributes without examples
In-Reply-To: <50D48A1F.60202@uvic.ca>
References: <5028011F.4050007@it.ox.ac.uk>
	<502848C5.5030504@uvic.ca>	<50D3E1E1.7080201@ultraslavonic.info>
	<50D48A1F.60202@uvic.ca>
Message-ID: <50D48E07.2040709@ultraslavonic.info>

Excellent.  I've added back in "assigned to" initials from the old chart 
for a few claimed by by Brett and Paul.

On 12/21/2012 11:11 AM, Martin Holmes wrote:
> I've posted a new list:
>
> <http://wiki.tei-c.org/index.php/AttsWithoutEgs>
>
> It's a bit shorter (only 164 attributes). I'll do a bit more work on it
> -- my code wasn't dealing with @xml:* attributes properly, and I also
> want to turn the "Defined in" field into a link to the appropriate page
> on the latest Jenkins build.
>
> Cheers,
> Martin
>
> On 12-12-20 08:13 PM, Kevin Hawkins wrote:
>> To bring back an old thread, I've looked at this wiki page that Martin
>> created and seen that it includes attributes that have a defined list of
>> legal values.  It seems to me that there's not much point in giving
>> examples of these since the list of values generally explains what each
>> means.
>>
>> Martin, do you still have the code you used to create the list?  Could
>> you possibly exclude those that have a list of legal values?  If you are
>> able to create this list, we are still, unfortunately, stuck merging the
>> existing page, where people have signed up to add certain examples.
>>
>> --Kevin
>>
>> On 8/12/12 8:22 PM, Martin Holmes wrote:
>>> The last time I took a look through these, I seem to remember coming to
>>> the conclusion that one situation in particular is most urgent: where
>>> attributes are declared in an attribute class, and none of the elements
>>> which are members of that attribute class have examples which illustrate
>>> the use of that attribute.
>>>
>>> I'm not sure how many of these there are -- I was halfway through some
>>> XSLT to find out, but I got distracted. I'll try to finish that.
>>>
>>> Cheers,
>>> Martin
>>>
>>> On 12-08-12 12:16 PM, James Cummings wrote:
>>>>
>>>> One of the things that Kevin reminded me of recently was that we
>>>> still have lots of attributes without examples:
>>>>
>>>> http://wiki.tei-c.org/index.php/AttsWithoutEgs
>>>>
>>>> I'm as guilty as the others who have not signed up to provide
>>>> some, but will try to do so in the next week or two.  Any other
>>>> suggestions? Can everyone sign up to provide some examples?
>>>>
>>>> -James
>>>>
>

From mholmes at uvic.ca  Fri Dec 21 11:46:51 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Fri, 21 Dec 2012 08:46:51 -0800
Subject: [tei-council] tagUsage/@render
In-Reply-To: <8C0DC069-CD54-4688-A92B-C424BA6EDE4A@it.ox.ac.uk>
References: <8C0DC069-CD54-4688-A92B-C424BA6EDE4A@it.ox.ac.uk>
Message-ID: <50D4927B.90207@uvic.ca>

Looks good to me. I never knew @render couldn't take multiple values. I 
would have called it as an error if I'd come across it. @rendition has 
always allowed multiples, and they're used in its examples.

Cheers,
Martin

On 12-12-21 07:09 AM, Sebastian Rahtz wrote:
> I have changed some of the examples in http://bits.nsms.ox.ac.uk:8080/jenkins/job/TEIP5/lastSuccessfulBuild/artifact/release/doc/tei-p5-doc/en/html/CO.html#COHQQ
> to a) use the same rendition-latter syntax as the <said> reference page, and b) have one with a proper rendition link
>
> look well, o wolves
> --
> Sebastian Rahtz
> Director (Research Support) of Academic IT Services
> University of Oxford IT Services
> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)

From James.Cummings at it.ox.ac.uk  Wed Dec 26 14:16:39 2012
From: James.Cummings at it.ox.ac.uk (James Cummings)
Date: Wed, 26 Dec 2012 19:16:39 +0000
Subject: [tei-council] January TEI Release
Message-ID: <50DB4D17.2050209@it.ox.ac.uk>

Hi all,

Hugh mentions that 17 January might be a good day for him to do a 
TEI release and it is a day that I'm relatively free as well.

Could I propose that we _try_ to stop any schema-affecting 
changes to the TEI SVN repository on the evening of the 15th 
January?  (obvious exceptions being solving bugs introduced in 
the run up to that, typos, etc.)

Also, some time before then, could everyone read the chapter 
whose number is the same as the month of their birth.  (I.e. my 
birthdate is in December, like Lou's, so we'll both read chapter 
12).

I'm not in any way thinking this will get us a good complete 
coverage, but at least means some spot proofreading will be done 
and means we don't need to come up with a set list of 
assignments, etc.  Obviously any typos, lack of clarity, etc. can 
just be corrected. Anything you think warrants a ticket, should 
be created.

I've assigned the open SF bugs without ticket owners (only a 
handful) and will be doing so with the SF feature requests soon.

-James

-- 
Dr James Cummings, James.Cummings at it.ox.ac.uk
Academic IT Services, University of Oxford

From mholmes at uvic.ca  Wed Dec 26 14:36:11 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Wed, 26 Dec 2012 11:36:11 -0800
Subject: [tei-council] January TEI Release
In-Reply-To: <50DB4D17.2050209@it.ox.ac.uk>
References: <50DB4D17.2050209@it.ox.ac.uk>
Message-ID: <50DB51AB.1060200@uvic.ca>

When you read the chapter of your birth month (good idea, James), it's 
best to read one of the current Jenkins build versions:

<http://teijenkins.hcmc.uvic.ca/job/TEIP5/lastSuccessfulBuild/artifact/release/doc/tei-p5-doc/en/html/index-toc.html>

<http://tei.oucs.ox.ac.uk/jenkins/job/TEIP5/lastSuccessfulBuild/artifact/release/doc/tei-p5-doc/en/html/index-toc.html>

(one at Oxford, one at UVic, both hopefully identical) so that you're 
reading the very latest build, including any changes since the last 
release. Differences will be minor, but it is most important to proof 
the latest changes, which are only in the Jenkins builds.

Cheers,
Martin

On 12-12-26 11:16 AM, James Cummings wrote:
> Hi all,
>
> Hugh mentions that 17 January might be a good day for him to do a
> TEI release and it is a day that I'm relatively free as well.
>
> Could I propose that we _try_ to stop any schema-affecting
> changes to the TEI SVN repository on the evening of the 15th
> January?  (obvious exceptions being solving bugs introduced in
> the run up to that, typos, etc.)
>
> Also, some time before then, could everyone read the chapter
> whose number is the same as the month of their birth.  (I.e. my
> birthdate is in December, like Lou's, so we'll both read chapter
> 12).
>
> I'm not in any way thinking this will get us a good complete
> coverage, but at least means some spot proofreading will be done
> and means we don't need to come up with a set list of
> assignments, etc.  Obviously any typos, lack of clarity, etc. can
> just be corrected. Anything you think warrants a ticket, should
> be created.
>
> I've assigned the open SF bugs without ticket owners (only a
> handful) and will be doing so with the SF feature requests soon.
>
> -James
>

-- 
Martin Holmes
mholmes at uvic.ca
UVic Humanities Computing and Media Centre

From kevin.s.hawkins at ultraslavonic.info  Wed Dec 26 16:00:27 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Wed, 26 Dec 2012 16:00:27 -0500
Subject: [tei-council] SF Tickets getting agreement on Council mailing
 list
In-Reply-To: <50D32665.7000903@it.ox.ac.uk>
References: <50D2DA96.3010502@it.ox.ac.uk>
	<50D31D5F.7010303@ultraslavonic.info>
	<50D32665.7000903@it.ox.ac.uk>
Message-ID: <50DB656B.6060809@ultraslavonic.info>

On 12/20/12 9:53 AM, James Cummings wrote:
> On 20/12/12 14:14, Kevin Hawkins wrote:
>> James, I'm confused.  You said:
>>
>> On 12/20/12 4:29 AM, James Cummings wrote:
>>> So if you want to ensure you get particular tickets go to
>>> http://purl.org/tei/fr
>>> and set assignee to 'nobody' and status to 'open' and click Filter.
>>> Likewise with http://purl.org/tei/bug
>>
>> but this will just let you find unassigned tickets (those that haven't
>> yet been "triaged").  Are you suggesting that people then claim any
>> tickets they're interested in, by assigning them to themselves?
>
>
> Correct! Exactly that! Apologies, I thought that was clear. I
> have no desire to stop people working on tickets they are
> interested in implementing... quite the reverse.  Sadly we all
> have to work on some tickets we're less interested in completing
> as well. :-)  I'll assign the rest in another few days.

And does triaging a ticket involve assigning a group (GREEN, AMBER, or 
RED)?  And analyzing, possibly also proposing a solution?  And 
implementing if we feel it's not controversial?  I realize this leads 
into what you wrote next ...

> What I'd like also to do is to get a workflow agreed going for
> assenting to decisions made on tickets as well. For example,
> Sebastian's asking about @defaultVal highlights that we probably
> want to be able to assume that silence equals assent as long as
> there has been a suitable period of time, a reminder, and any
> discussion summarised on the ticket. This should probably be for
> 'green' categorised tickets (or corrigible bugs) since 'amber'
> implies they need further discussion. I want to remove any
> roadblocks from us completing tickets but also keep Council
> oversight of them. We all volunteer our work at different times
> and are usually very busy with all sorts of other concerns.
>
> Any thoughts?

Laurent generally had the approach that silence equals assent, but it's 
good to restate such a policy, especially as there is turnover among 
members, to make sure everyone is aware of that.  We should also figure 
out who assigns a group (GREEN, AMBER, or RED) and under what 
circumstances this can be changed.  (When I grabbed a few tickets for 
myself, I assigned a group for each of them, but I see that in a ticket 
assigned to me by James, he did not choose a group for it.)

From mholmes at uvic.ca  Wed Dec 26 16:36:00 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Wed, 26 Dec 2012 13:36:00 -0800
Subject: [tei-council] Standard form for elementSpec/desc
Message-ID: <50DB6DC0.5080100@uvic.ca>

Proofing my birthday chapter (#8), I've come across something which I 
recall bothering me in the past. Most element descriptions take the form 
of verb phrases:

[<scriptStmt>] contains a citation giving details of the script used for
a spoken text.

Others are in the form of noun phrases:

[<recording>] details of an audio or video recording event
used as the source of a spoken text, either directly or from
a public broadcast.

This becomes slightly problematic when the Guidelines text brings them 
together in a context in which they should be parallel in structure:

<http://teijenkins.hcmc.uvic.ca/job/TEIP5/lastSuccessfulBuild/artifact/release/doc/tei-p5-doc/en/html/TS.html#HD32>

I think we need to settle on one form or the other for all our <desc>s, 
to avoid parallel structure violations like this.

My sense is that the verb phrase version is much more common, and should 
be universal. I therefore propose to fix the <desc> of <recording> by 
adding "provides" like this:

[<recording>] provides details of an audio or video recording event
used as the source of a spoken text, either directly or from
a public broadcast.

Then I'll take a quick look through all the other <desc>s to find and 
fix any others which are in the form of noun phrases.

Please object mightily if you wish to prevent this.

Cheers,
Martin




From mholmes at uvic.ca  Wed Dec 26 16:52:55 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Wed, 26 Dec 2012 13:52:55 -0800
Subject: [tei-council] Standard form for elementSpec/desc
In-Reply-To: <50DB6DC0.5080100@uvic.ca>
References: <50DB6DC0.5080100@uvic.ca>
Message-ID: <50DB71B7.8030900@uvic.ca>

These are the affected descs (the ones which take the form of a noun 
phrase):

<prefixDef> (my own error, in a new file, so I've fixed it already)

<recording>
<street>
<editor>
<sp>
<speaker>
<argument>
<role>
<actor>
<spGrp>
<u>
<pause>
<vocal>
<kinesic>
<incident>
<writing>
<lang>
<secFol>
<offset>
<geogName>
<pc>

Cheers,
Martin

On 12-12-26 01:36 PM, Martin Holmes wrote:
> Proofing my birthday chapter (#8), I've come across something which I
> recall bothering me in the past. Most element descriptions take the form
> of verb phrases:
>
> [<scriptStmt>] contains a citation giving details of the script used for
> a spoken text.
>
> Others are in the form of noun phrases:
>
> [<recording>] details of an audio or video recording event
> used as the source of a spoken text, either directly or from
> a public broadcast.
>
> This becomes slightly problematic when the Guidelines text brings them
> together in a context in which they should be parallel in structure:
>
> <http://teijenkins.hcmc.uvic.ca/job/TEIP5/lastSuccessfulBuild/artifact/release/doc/tei-p5-doc/en/html/TS.html#HD32>
>
> I think we need to settle on one form or the other for all our <desc>s,
> to avoid parallel structure violations like this.
>
> My sense is that the verb phrase version is much more common, and should
> be universal. I therefore propose to fix the <desc> of <recording> by
> adding "provides" like this:
>
> [<recording>] provides details of an audio or video recording event
> used as the source of a spoken text, either directly or from
> a public broadcast.
>
> Then I'll take a quick look through all the other <desc>s to find and
> fix any others which are in the form of noun phrases.
>
> Please object mightily if you wish to prevent this.
>
> Cheers,
> Martin
>
>
>

From sebastian.rahtz at it.ox.ac.uk  Wed Dec 26 17:21:07 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Wed, 26 Dec 2012 22:21:07 +0000
Subject: [tei-council] Standard form for elementSpec/desc
In-Reply-To: <50DB71B7.8030900@uvic.ca>
References: <50DB6DC0.5080100@uvic.ca>,<50DB71B7.8030900@uvic.ca>
Message-ID: <CF94950D-9832-49CF-89AC-BFCB7437931C@oucs.ox.ac.uk>

Seems fine to me to change them, if you have the energy. I wouldn't give a huge high priority myself tho.

Wonder why you want us to read chapters, James? So little has changed. Not better to try and close old tickets? I started on one from march 2011 today but ran out f time.

yrs, on a ferry in harwich about to depart for The Continent.

Carved in stone on my iPad

From mholmes at uvic.ca  Wed Dec 26 17:29:45 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Wed, 26 Dec 2012 14:29:45 -0800
Subject: [tei-council] Use of "below" and "above" in Guidelines prose
Message-ID: <50DB7A59.7010602@uvic.ca>

I think this sort of phrasing:

"...see sections 15.2.3 The Setting Description and 15.2.2 The 
Participant Description below." (from Chapter 8)

is confusing, given that the Guidelines are now almost universally read 
in their modular online format. In Chapter 8, "below" suggests to me 
that the relevant sections will be found within the current page 
somewhere; actually, they're in a different chapter, which is a 
different page.

"Below" and "above" still make sense in the context of the one-document 
PDF, but there also the sections referred to would be linked directly, 
so finding them is not an issue.

Absent loud protestations, I'm going to remove "below" from the sentence 
above, and elsewhere in the chapter I'm proofing (except where it points 
to a location which actually is in that chapter).

Cheers,
Martin

From mholmes at uvic.ca  Wed Dec 26 17:39:03 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Wed, 26 Dec 2012 14:39:03 -0800
Subject: [tei-council] Standard form for elementSpec/desc
In-Reply-To: <CF94950D-9832-49CF-89AC-BFCB7437931C@oucs.ox.ac.uk>
References: <50DB6DC0.5080100@uvic.ca>, <50DB71B7.8030900@uvic.ca>
	<CF94950D-9832-49CF-89AC-BFCB7437931C@oucs.ox.ac.uk>
Message-ID: <50DB7C87.7010009@uvic.ca>

On 12-12-26 02:21 PM, Sebastian Rahtz wrote:
> Seems fine to me to change them, if you have the energy. I wouldn't
> give a huge high priority myself tho.

I think it makes the Guidelines prose appear unprofessional. Anyone who 
teaches writing or is a bit pedantic like me will feel a slight jar when 
they come across bad parallel structure.

> Wonder why you want us to read chapters, James? So little has
> changed.

I'll wager than many of the admittedly minor changes we've made over 
many months have never been proofed properly by anyone other than the 
submitter (this is a consequence of "silence means assent"). Also, over 
the long haul, as lots of minor changes and edits accumulate, I think a 
chapter can drift into slight incoherence. I think it's a good idea for 
every chapter to be proofed once in a while.

I pity the people born in March and November, though. Big chapters.

 > Not better to try and close old tickets? I started on one
> from march 2011 today but ran out f time.

We should be doing that too. But sometimes proofing is something you can 
manage when you're not really up to tackling a difficult ticket.

Cheers,
Martin

> yrs, on a ferry in harwich about to depart for The Continent.

Surely A Continent.

> Carved in stone on my iPad
>

From james.cummings at it.ox.ac.uk  Wed Dec 26 17:49:33 2012
From: james.cummings at it.ox.ac.uk (James Cummings)
Date: Wed, 26 Dec 2012 22:49:33 +0000
Subject: [tei-council] Standard form for elementSpec/desc
In-Reply-To: <CF94950D-9832-49CF-89AC-BFCB7437931C@oucs.ox.ac.uk>
References: <50DB6DC0.5080100@uvic.ca>, <50DB71B7.8030900@uvic.ca>,
	<CF94950D-9832-49CF-89AC-BFCB7437931C@oucs.ox.ac.uk>
Message-ID: <3382d4a6-1c0a-4291-8cd5-8bcba735580a@HUB04.ad.oak.ox.ac.uk>


Sebastian,

Because as Martin proves this turns up lots of other inconsistencies.

Fairly low priority, as you say, but we've had a fair number of typos reported in the last year, and good to have many eyes. But closing tickets certainly higher priority.

JamesC

Sebastian Rahtz <sebastian.rahtz at it.ox.ac.uk> wrote:


Seems fine to me to change them, if you have the energy. I wouldn't give a huge high priority myself tho.

Wonder why you want us to read chapters, James? So little has changed. Not better to try and close old tickets? I started on one from march 2011 today but ran out f time.

yrs, on a ferry in harwich about to depart for The Continent.

Carved in stone on my iPad
--
tei-council mailing list
tei-council at lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

PLEASE NOTE: postings to this list are publicly archived

From mholmes at uvic.ca  Wed Dec 26 23:17:57 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Wed, 26 Dec 2012 20:17:57 -0800
Subject: [tei-council] More Chapter 8 oddities
Message-ID: <50DBCBF5.2090200@uvic.ca>

Can anyone explain why the transcription in this example:

<http://teijenkins.hcmc.uvic.ca/job/TEIP5/lastSuccessfulBuild/artifact/release/doc/tei-p5-doc/en/html/TS.html#index-egXML-d51e63744>

in this section (in case the egXML id turns out to be transitory):

<http://teijenkins.hcmc.uvic.ca/job/TEIP5/lastSuccessfulBuild/artifact/release/doc/tei-p5-doc/en/html/TS.html#TSBA>

lacks apostrophes in e.g. "isnt" or "dont"? The text says "It is recoded 
from a text originally transcribed in the CHILDES format", which I know 
nothing about, so perhaps there is some historical reason for omitting 
the apostrophe, but I see no reason for it in this context, where it's 
just exemplifying encoding of a transcription.

Cheers,
Martin



From mholmes at uvic.ca  Wed Dec 26 23:37:19 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Wed, 26 Dec 2012 20:37:19 -0800
Subject: [tei-council] @who="all | various | unknown"
Message-ID: <50DBD07F.80909@uvic.ca>

One bit of my birthday chapter 
(<http://teijenkins.hcmc.uvic.ca/job/TEIP5/lastSuccessfulBuild/artifact/release/doc/tei-p5-doc/en/html/TS.html#TSBAUT>) 
says, regarding the <u> element:

"Use of the @who attribute to associate the utterance with a particular 
speaker is recommended but not required. Its use implies as a further 
requirement that all speakers be identified by a person or personGrp 
element in the TEI header (see section 15.2.2 The Participant 
Description), but it may also point to another external source of 
information about the speaker. Where utterances or other parts of the 
transcription cannot be attributed with confidence to any particular 
participant or group of participants, the encoder may choose to define 
?participants? such as all or various, or unknown. "

@who is 1?? occurrences of data.pointer, so clearly its values cannot be 
"all", "various" or "unknown", unless files with those names exist as 
siblings of the file containing the @who.

I think I know what this means: encoders should create e.g. <personGrp> 
elements with @xml:id="all", "various" or "unknown". But I don't think 
this is clear enough in the prose of the chapter. If I have understood 
correctly, or misunderstood, please let me know. Either way I'll expand 
this paragraph to clarify what strategy is actually being recommended here.

Cheers,
Martin

From mholmes at uvic.ca  Wed Dec 26 23:56:39 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Wed, 26 Dec 2012 20:56:39 -0800
Subject: [tei-council] Why is <pause> only att.duration.w3c?
Message-ID: <50DBD507.1080808@uvic.ca>

Most timing elements are members of att.duration, which gets them 
att.duration.w3c and att.duration.iso.

But <pause>:

<http://teijenkins.hcmc.uvic.ca/job/TEIP5/lastSuccessfulBuild/artifact/release/doc/tei-p5-doc/en/html/ref-pause.html>

along with its friends in att.timed, is directly a member of 
att.duration.w3c, and not of att.duration.iso:

<http://teijenkins.hcmc.uvic.ca/job/TEIP5/lastSuccessfulBuild/artifact/release/doc/tei-p5-doc/en/html/ref-att.timed.html>

I'm sure there must be a reason that att.timed should be a member only 
of att.duration.w3c and not att.duration, but I can't see it. Anyone know?

Cheers,
Martin

From mholmes at uvic.ca  Thu Dec 27 01:06:24 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Wed, 26 Dec 2012 22:06:24 -0800
Subject: [tei-council] Misleadingly invalid example
Message-ID: <50DBE560.3040403@uvic.ca>

The second example in this section of chapter 8:

<http://teijenkins.hcmc.uvic.ca/job/TEIP5/lastSuccessfulBuild/artifact/release/doc/tei-p5-doc/en/html/TS.html#TSSASE>

is marked (correctly) as invalid, because it contains an element defined 
in an external namespace as an extension to TEI (<ext:paraphasia>). 
However, the example is introduced as a demonstration of how to use the 
TEI @type attribute on <seg>:

"Where segments of different kinds are to be distinguished within the 
same stretch of speech, the type attribute may be used, as in the 
following example:"

and the extension element is only explained after the example.

This is confusing. I'd like to re-draft this so that the initial 
example, demonstrating usage of @type, is valid, and the extension is 
introduced separately in a later, shorter example.

Yell now to prevent same.

Cheers,
Martin


From sebastian.rahtz at it.ox.ac.uk  Thu Dec 27 04:44:52 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Thu, 27 Dec 2012 09:44:52 +0000
Subject: [tei-council] SF.net SVN: tei:[11270]
 trunk/P5/Source/Guidelines/en/ TS-TranscriptionsofSpeech.xml
In-Reply-To: <E1TnzyO-0002hc-Mh@sfp-svn-4.v30.ch3.sourceforge.com>
References: <E1TnzyO-0002hc-Mh@sfp-svn-4.v30.ch3.sourceforge.com>
Message-ID: <15B12685-4B23-4243-B925-29172EC0D1DA@oucs.ox.ac.uk>



On 27 Dec 2012, at 00:01, "martindholmes at users.sourceforge.net" <martindholmes at users.sourceforge.net> wrote:

> Revision: 11270
>          http://tei.svn.sourceforge.net/tei/?rev=11270&view=rev
> Author:   martindholmes
> Date:     2012-12-26 23:01:16 +0000 (Wed, 26 Dec 2012)
> Log Message:
> -----------
> Fixing more typos in TS chapter, including reference to non-existent class model.phrase.spoken.
> 
> 
> .... the <gi>u</i
> -element; the class <ident type="class">model.phrase.spoken</ident>
> +element; the class <ident type="class">model.global.spoken</ident>
> provides the six other elements listed above.</p>
> 

This suggests we should look at content of ident type="class" to check that ID exists? I could
Add that to the validator.

Sebastian 

From kevin.s.hawkins at ultraslavonic.info  Thu Dec 27 09:18:32 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Thu, 27 Dec 2012 09:18:32 -0500
Subject: [tei-council] SF.net SVN: tei:[11270]
 trunk/P5/Source/Guidelines/en/ TS-TranscriptionsofSpeech.xml
In-Reply-To: <15B12685-4B23-4243-B925-29172EC0D1DA@oucs.ox.ac.uk>
References: <E1TnzyO-0002hc-Mh@sfp-svn-4.v30.ch3.sourceforge.com>
	<15B12685-4B23-4243-B925-29172EC0D1DA@oucs.ox.ac.uk>
Message-ID: <50DC58B8.4030302@ultraslavonic.info>

On 12/27/12 4:44 AM, Sebastian Rahtz wrote:
> On 27 Dec 2012, at 00:01, "martindholmes at users.sourceforge.net" <martindholmes at users.sourceforge.net> wrote:
>
>> Revision: 11270
>>           http://tei.svn.sourceforge.net/tei/?rev=11270&view=rev
>> Author:   martindholmes
>> Date:     2012-12-26 23:01:16 +0000 (Wed, 26 Dec 2012)
>> Log Message:
>> -----------
>> Fixing more typos in TS chapter, including reference to non-existent class model.phrase.spoken.
>>
>>
>> .... the <gi>u</i
>> -element; the class <ident type="class">model.phrase.spoken</ident>
>> +element; the class <ident type="class">model.global.spoken</ident>
>> provides the six other elements listed above.</p>
>>
>
> This suggests we should look at content of ident type="class" to check that ID exists? I could
> Add that to the validator.

To validation as part of the build process?  Yes, please.

From sebastian.rahtz at gmail.com  Thu Dec 27 12:39:16 2012
From: sebastian.rahtz at gmail.com (Sebastian Rahtz)
Date: Thu, 27 Dec 2012 18:39:16 +0100
Subject: [tei-council] http://www.tei-c.org/Guidelines/P5/
Message-ID: <EECECDE1-994B-4552-89E2-3A6291692DFC@gmail.com>

This page has a nonsense bit about extra data files - it fails to give the file name! Who controls the xslt? I assume it fails to render gloss lists.

Sebastian 

Carved in stone on my iPad

From sebastian.rahtz at it.ox.ac.uk  Thu Dec 27 12:40:13 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Thu, 27 Dec 2012 17:40:13 +0000
Subject: [tei-council] Why is <pause> only att.duration.w3c?
In-Reply-To: <50DBD507.1080808@uvic.ca>
References: <50DBD507.1080808@uvic.ca>
Message-ID: <4F91046B-0E85-492E-83CB-94DB015CF6FB@oucs.ox.ac.uk>

It's very hard to think of a plausible reason. I'd says its a corrigibke error.

Sebastan

Carved in stone on my iPad
> 

From sebastian.rahtz at it.ox.ac.uk  Thu Dec 27 12:55:19 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Thu, 27 Dec 2012 17:55:19 +0000
Subject: [tei-council] More Chapter 8 oddities
In-Reply-To: <50DBCBF5.2090200@uvic.ca>
References: <50DBCBF5.2090200@uvic.ca>
Message-ID: <C82E381E-C46D-4F22-A9D4-D66156C5A74E@oucs.ox.ac.uk>

Given that it has a source listed in the biblio,
I don't think you should change it. If its confusing, a different example?

 I'd tag that one "sleeping dog" ;-)

Carved in stone on my iPad

On 27 Dec 2012, at 05:18, "Martin Holmes" <mholmes at uvic.ca> wrote:

> Can anyone explain why the transcription in this example:
> 
> <http://teijenkins.hcmc.uvic.ca/job/TEIP5/lastSuccessfulBuild/artifact/release/doc/tei-p5-doc/en/html/TS.html#index-egXML-d51e63744>
> 
> in this section (in case the egXML id turns out to be transitory):
> 
> <http://teijenkins.hcmc.uvic.ca/job/TEIP5/lastSuccessfulBuild/artifact/release/doc/tei-p5-doc/en/html/TS.html#TSBA>
> 
> lacks apostrophes in e.g. "isnt" or "dont"? The text says "It is recoded 
> from a text originally transcribed in the CHILDES format", which I know 
> nothing about, so perhaps there is some historical reason for omitting 
> the apostrophe, but I see no reason for it in this context, where it's 
> just exemplifying encoding of a transcription.
> 
> Cheers,
> Martin
> 
> 
> -- 
> tei-council mailing list
> tei-council at lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
> 
> PLEASE NOTE: postings to this list are publicly archived

From kevin.s.hawkins at ultraslavonic.info  Thu Dec 27 13:01:04 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Thu, 27 Dec 2012 13:01:04 -0500
Subject: [tei-council] http://www.tei-c.org/Guidelines/P5/
In-Reply-To: <EECECDE1-994B-4552-89E2-3A6291692DFC@gmail.com>
References: <EECECDE1-994B-4552-89E2-3A6291692DFC@gmail.com>
Message-ID: <50DC8CE0.80208@ultraslavonic.info>

David Sewell as TEI webmaster and I as assistant webmaster control the 
XSLT for this and all other pages on www.tei-c.org that are rendered 
from TEI source documents, which I happen to know can be found at:

http://www.tei-c.org/xsl/tei2.xsl

I'll look into fixing the bug.

In the meantime, at the bottom of http://www.tei-c.org/Guidelines/P5/ , 
if you click "XML view", it gives you:

http://www.tei-c.org/Guidelines/P5/index.xml?style=raw

from which you can see the filenames.

On 12/27/12 12:39 PM, Sebastian Rahtz wrote:
> This page has a nonsense bit about extra data files - it fails to give the file name! Who controls the xslt? I assume it fails to render gloss lists.
>
> Sebastian
>
> Carved in stone on my iPad
>

From kevin.s.hawkins at ultraslavonic.info  Thu Dec 27 13:09:25 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Thu, 27 Dec 2012 13:09:25 -0500
Subject: [tei-council] More Chapter 8 oddities
In-Reply-To: <C82E381E-C46D-4F22-A9D4-D66156C5A74E@oucs.ox.ac.uk>
References: <50DBCBF5.2090200@uvic.ca>
	<C82E381E-C46D-4F22-A9D4-D66156C5A74E@oucs.ox.ac.uk>
Message-ID: <50DC8ED5.7070203@ultraslavonic.info>

I agree that this is likely presented as in the source document, much 
like the transliterated Russian title we discussed a few months ago.

(The source doucment is at http://books.google.com/books?id=DskfAQAAIAAJ 
, where the book is described as being about computerized speech, which 
probably meant IRC logs.  Snippet search isn't turning up the cited 
passage for me in order to verify, but I think we are just seeing ICR 
logs encoded in TEI.)

--K.

On 12/27/12 12:55 PM, Sebastian Rahtz wrote:
> Given that it has a source listed in the biblio,
> I don't think you should change it. If its confusing, a different example?
>
>   I'd tag that one "sleeping dog" ;-)
>
> Carved in stone on my iPad
>
> On 27 Dec 2012, at 05:18, "Martin Holmes" <mholmes at uvic.ca> wrote:
>
>> Can anyone explain why the transcription in this example:
>>
>> <http://teijenkins.hcmc.uvic.ca/job/TEIP5/lastSuccessfulBuild/artifact/release/doc/tei-p5-doc/en/html/TS.html#index-egXML-d51e63744>
>>
>> in this section (in case the egXML id turns out to be transitory):
>>
>> <http://teijenkins.hcmc.uvic.ca/job/TEIP5/lastSuccessfulBuild/artifact/release/doc/tei-p5-doc/en/html/TS.html#TSBA>
>>
>> lacks apostrophes in e.g. "isnt" or "dont"? The text says "It is recoded
>> from a text originally transcribed in the CHILDES format", which I know
>> nothing about, so perhaps there is some historical reason for omitting
>> the apostrophe, but I see no reason for it in this context, where it's
>> just exemplifying encoding of a transcription.
>>
>> Cheers,
>> Martin
>>
>>
>> --
>> tei-council mailing list
>> tei-council at lists.village.Virginia.EDU
>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>>
>> PLEASE NOTE: postings to this list are publicly archived

From dsewell at virginia.edu  Thu Dec 27 13:22:26 2012
From: dsewell at virginia.edu (David Sewell)
Date: Thu, 27 Dec 2012 13:22:26 -0500 (EST)
Subject: [tei-council] http://www.tei-c.org/Guidelines/P5/
In-Reply-To: <50DC8CE0.80208@ultraslavonic.info>
References: <EECECDE1-994B-4552-89E2-3A6291692DFC@gmail.com>
	<50DC8CE0.80208@ultraslavonic.info>
Message-ID: <alpine.OSX.2.00.1212271317170.69546@lister.ei.virginia.edu>

I believe that there will need to be an explicit '@type="gloss"' on the <list> 
element for it to render properly, based on the existing stylesheet expectations 
(cf. http://www.tei-c.org/xsl/tei2.xsl at liine 1453).

The XSLT powering the site probably needs some wholesale revision; I've always 
been hesitant to experiment with that as my memory is that you actually have to 
"publish" the modified XSLT files to get them to apply the transforms, meaning 
you can't test changes in the offline version only. But maybe we can test that 
some more, say on New Year's Eve, when few people are likely to notice if the 
site breaks...

On Thu, 27 Dec 2012, Kevin Hawkins wrote:

> David Sewell as TEI webmaster and I as assistant webmaster control the
> XSLT for this and all other pages on www.tei-c.org that are rendered
> from TEI source documents, which I happen to know can be found at:
>
> http://www.tei-c.org/xsl/tei2.xsl
>
> I'll look into fixing the bug.
>
> In the meantime, at the bottom of http://www.tei-c.org/Guidelines/P5/ ,
> if you click "XML view", it gives you:
>
> http://www.tei-c.org/Guidelines/P5/index.xml?style=raw
>
> from which you can see the filenames.
>
> On 12/27/12 12:39 PM, Sebastian Rahtz wrote:
>> This page has a nonsense bit about extra data files - it fails to give the file name! Who controls the xslt? I assume it fails to render gloss lists.
>>
>> Sebastian
>>
>> Carved in stone on my iPad
>>
>

-- 
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 kevin.s.hawkins at ultraslavonic.info  Thu Dec 27 14:03:23 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Thu, 27 Dec 2012 14:03:23 -0500
Subject: [tei-council] http://www.tei-c.org/Guidelines/P5/
In-Reply-To: <alpine.OSX.2.00.1212271317170.69546@lister.ei.virginia.edu>
References: <EECECDE1-994B-4552-89E2-3A6291692DFC@gmail.com>
	<50DC8CE0.80208@ultraslavonic.info>
	<alpine.OSX.2.00.1212271317170.69546@lister.ei.virginia.edu>
Message-ID: <50DC9B7B.5010604@ultraslavonic.info>

On 12/27/12 1:22 PM, David Sewell wrote:
> I believe that there will need to be an explicit '@type="gloss"' on the <list>
> element for it to render properly, based on the existing stylesheet expectations
> (cf. http://www.tei-c.org/xsl/tei2.xsl at liine 1453).

Yes, that was it.  I've just fixed http://www.tei-c.org/Guidelines/P5/ .

--K.

From lou.burnard at retired.ox.ac.uk  Thu Dec 27 17:52:36 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Thu, 27 Dec 2012 22:52:36 +0000
Subject: [tei-council] January TEI Release
In-Reply-To: <50DB4D17.2050209@it.ox.ac.uk>
References: <50DB4D17.2050209@it.ox.ac.uk>
Message-ID: <50DCD134.4060807@retired.ox.ac.uk>

On 26/12/12 19:16, James Cummings wrote:
>
> Could I propose that we _try_ to stop any schema-affecting
> changes to the TEI SVN repository on the evening of the 15th
> January?  (obvious exceptions being solving bugs introduced in
> the run up to that, typos, etc.)

Fine by me

> Also, some time before then, could everyone read the chapter
> whose number is the same as the month of their birth.  (I.e. my
> birthdate is in December, like Lou's, so we'll both read chapter
> 12).

I cannot for the life of me understand why this is a good idea. If you 
want to randomly allocate chapters for reading, why on earth do so in a  
way which guarantees that some chapters will get multiple readers and 
some (those numbered greater than 12 for example) will never ever get 
read? Surely you can think of a better algorithm?



From lou.burnard at retired.ox.ac.uk  Thu Dec 27 17:56:09 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Thu, 27 Dec 2012 22:56:09 +0000
Subject: [tei-council] Standard form for elementSpec/desc
In-Reply-To: <50DB6DC0.5080100@uvic.ca>
References: <50DB6DC0.5080100@uvic.ca>
Message-ID: <50DCD209.6030600@retired.ox.ac.uk>

On 26/12/12 21:36, Martin Holmes wrote:
> Proofing my birthday chapter (#8), I've come across something which I
> recall bothering me in the past. Most element descriptions take the form
> of verb phrases:
>
> [<scriptStmt>] contains a citation giving details of the script used for
> a spoken text.
>
> Others are in the form of noun phrases:
>
> [<recording>] details of an audio or video recording event
> used as the source of a spoken text, either directly or from
> a public broadcast.

The second example is erroneous. There used to be a house style rule 
which explicitly said that the description should follow the pattern of 
the first one, i.e. should contain a verb phrase, but I don't recall 
when or why it disappeared.  For the reasons Martin points out, it 
should definitely come back.



From lou.burnard at retired.ox.ac.uk  Thu Dec 27 17:59:53 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Thu, 27 Dec 2012 22:59:53 +0000
Subject: [tei-council] Use of "below" and "above" in Guidelines prose
In-Reply-To: <50DB7A59.7010602@uvic.ca>
References: <50DB7A59.7010602@uvic.ca>
Message-ID: <50DCD2E9.8020003@retired.ox.ac.uk>

On 26/12/12 22:29, Martin Holmes wrote:
> Absent loud protestations, I'm going to remove "below" from the sentence
> above, and elsewhere in the chapter I'm proofing (except where it points
> to a location which actually is in that chapter).
>
>
I protest, though not very loudly. The "below" or "above" is generally a 
useful indication for people who are actually paging through the 
Guidelines, whether or not they're doing so online. It is also fairly 
generally used, and I think it would seem odd to remove it from just one 
chapter.



From lou.burnard at retired.ox.ac.uk  Thu Dec 27 18:02:07 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Thu, 27 Dec 2012 23:02:07 +0000
Subject: [tei-council] Standard form for elementSpec/desc
In-Reply-To: <50DB7C87.7010009@uvic.ca>
References: <50DB6DC0.5080100@uvic.ca>, <50DB71B7.8030900@uvic.ca>
	<CF94950D-9832-49CF-89AC-BFCB7437931C@oucs.ox.ac.uk>
	<50DB7C87.7010009@uvic.ca>
Message-ID: <50DCD36F.8040108@retired.ox.ac.uk>

On 26/12/12 22:39, Martin Holmes wrote:
>
> Wonder why you want us to read chapters, James? So little has
> changed.
> I'll wager than many of the admittedly minor changes we've made over
> many months have never been proofed properly by anyone other than the
> submitter (this is a consequence of "silence means assent"). Also, over
> the long haul, as lots of minor changes and edits accumulate, I think a
> chapter can drift into slight incoherence. I think it's a good idea for
> every chapter to be proofed once in a while.

I agree that proofing is a good idea : surely though it would be better 
to proof the chapters which have had the most changes applied to them 
over the last year, rather than randomly?



From lou.burnard at retired.ox.ac.uk  Thu Dec 27 18:05:04 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Thu, 27 Dec 2012 23:05:04 +0000
Subject: [tei-council] More Chapter 8 oddities
In-Reply-To: <50DBCBF5.2090200@uvic.ca>
References: <50DBCBF5.2090200@uvic.ca>
Message-ID: <50DCD420.6040400@retired.ox.ac.uk>

On 27/12/12 04:17, Martin Holmes wrote:
> Can anyone explain why the transcription in this example:
>
> <http://teijenkins.hcmc.uvic.ca/job/TEIP5/lastSuccessfulBuild/artifact/release/doc/tei-p5-doc/en/html/TS.html#index-egXML-d51e63744>
>
> in this section (in case the egXML id turns out to be transitory):
>
> <http://teijenkins.hcmc.uvic.ca/job/TEIP5/lastSuccessfulBuild/artifact/release/doc/tei-p5-doc/en/html/TS.html#TSBA>
>
> lacks apostrophes in e.g. "isnt" or "dont"? The text says "It is recoded
> from a text originally transcribed in the CHILDES format", which I know
> nothing about, so perhaps there is some historical reason for omitting
> the apostrophe, but I see no reason for it in this context, where it's
> just exemplifying encoding of a transcription.
>
>

It is not uncommon practice in transcribing speech to omit punctuation.

I'm surprised you've not come across CHILDES before -- it's one of the 
older speech transcription projects/formats (and did not, I think, use 
punctuation)



From lou.burnard at retired.ox.ac.uk  Thu Dec 27 18:07:15 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Thu, 27 Dec 2012 23:07:15 +0000
Subject: [tei-council] @who="all | various | unknown"
In-Reply-To: <50DBD07F.80909@uvic.ca>
References: <50DBD07F.80909@uvic.ca>
Message-ID: <50DCD4A3.7070509@retired.ox.ac.uk>

On 27/12/12 04:37, Martin Holmes wrote:
> One bit of my birthday chapter
> (<http://teijenkins.hcmc.uvic.ca/job/TEIP5/lastSuccessfulBuild/artifact/release/doc/tei-p5-doc/en/html/TS.html#TSBAUT>)
> says, regarding the <u> element:
>
> "Use of the @who attribute to associate the utterance with a particular
> speaker is recommended but not required. Its use implies as a further
> requirement that all speakers be identified by a person or personGrp
> element in the TEI header (see section 15.2.2 The Participant
> Description), but it may also point to another external source of
> information about the speaker. Where utterances or other parts of the
> transcription cannot be attributed with confidence to any particular
> participant or group of participants, the encoder may choose to define
> ?participants? such as all or various, or unknown. "
>
> @who is 1?? occurrences of data.pointer, so clearly its values cannot be
> "all", "various" or "unknown", unless files with those names exist as
> siblings of the file containing the @who.
>
> I think I know what this means: encoders should create e.g. <personGrp>
> elements with @xml:id="all", "various" or "unknown". But I don't think
> this is clear enough in the prose of the chapter. If I have understood
> correctly, or misunderstood, please let me know. Either way I'll expand
> this paragraph to clarify what strategy is actually being recommended here.
>

Yes. I think the references to "all" etc. are a survival from an early 
era in which @who was not necessarily a data pointer. Your proposed 
addition sounds like a very good one.



From lou.burnard at retired.ox.ac.uk  Thu Dec 27 18:07:51 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Thu, 27 Dec 2012 23:07:51 +0000
Subject: [tei-council] Why is <pause> only att.duration.w3c?
In-Reply-To: <50DBD507.1080808@uvic.ca>
References: <50DBD507.1080808@uvic.ca>
Message-ID: <50DCD4C7.5000406@retired.ox.ac.uk>

On 27/12/12 04:56, Martin Holmes wrote:
> I'm sure there must be a reason that att.timed should be a member only
> of att.duration.w3c and not att.duration, but I can't see it. Anyone know?
>
>

Homer nodded. Fix it.





From lou.burnard at retired.ox.ac.uk  Thu Dec 27 18:13:18 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Thu, 27 Dec 2012 23:13:18 +0000
Subject: [tei-council] Misleadingly invalid example
In-Reply-To: <50DBE560.3040403@uvic.ca>
References: <50DBE560.3040403@uvic.ca>
Message-ID: <50DCD60E.4080900@retired.ox.ac.uk>

On 27/12/12 06:06, Martin Holmes wrote:
> The second example in this section of chapter 8:
>
> <http://teijenkins.hcmc.uvic.ca/job/TEIP5/lastSuccessfulBuild/artifact/release/doc/tei-p5-doc/en/html/TS.html#TSSASE>
>
> is marked (correctly) as invalid, because it contains an element defined
> in an external namespace as an extension to TEI (<ext:paraphasia>).
> However, the example is introduced as a demonstration of how to use the
> TEI @type attribute on <seg>:
>
> "Where segments of different kinds are to be distinguished within the
> same stretch of speech, the type attribute may be used, as in the
> following example:"
>
> and the extension element is only explained after the example.
>
> This is confusing. I'd like to re-draft this so that the initial
> example, demonstrating usage of @type, is valid, and the extension is
> introduced separately in a later, shorter example.
>
> Yell now to prevent same.
>
>


No yelling from me. I just note that the example is an authentic one, 
which is why it has the paraphasia in it. I would suggest simply 
splitting the example, and  motivating the use of the non-tei element by 
saying something like  "sometimes rather than say <seg type="weirdTerm"> 
it's more convenient to introduce <my:weirdTerm>"





From lou.burnard at retired.ox.ac.uk  Thu Dec 27 18:14:08 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Thu, 27 Dec 2012 23:14:08 +0000
Subject: [tei-council] SF.net SVN: tei:[11270]
 trunk/P5/Source/Guidelines/en/ TS-TranscriptionsofSpeech.xml
In-Reply-To: <15B12685-4B23-4243-B925-29172EC0D1DA@oucs.ox.ac.uk>
References: <E1TnzyO-0002hc-Mh@sfp-svn-4.v30.ch3.sourceforge.com>
	<15B12685-4B23-4243-B925-29172EC0D1DA@oucs.ox.ac.uk>
Message-ID: <50DCD640.6080909@retired.ox.ac.uk>

On 27/12/12 09:44, Sebastian Rahtz wrote:
>
> This suggests we should look at content of ident type="class" to check that ID exists? I could
> Add that to the validator.

Excellent suggestion (sure I've asked for it before now...)


From James.Cummings at it.ox.ac.uk  Thu Dec 27 20:01:03 2012
From: James.Cummings at it.ox.ac.uk (James Cummings)
Date: Fri, 28 Dec 2012 01:01:03 +0000
Subject: [tei-council] @who="all | various | unknown"
In-Reply-To: <50DBD07F.80909@uvic.ca>
References: <50DBD07F.80909@uvic.ca>
Message-ID: <50DCEF4F.50808@it.ox.ac.uk>

On 27/12/12 04:37, Martin Holmes wrote:
> I think I know what this means: encoders should create e.g. <personGrp>
> elements with @xml:id="all", "various" or "unknown". But I don't think
> this is clear enough in the prose of the chapter. If I have understood
> correctly, or misunderstood, please let me know. Either way I'll expand
> this paragraph to clarify what strategy is actually being recommended here.

Yes, I think this way of expressing it probably is a hold-over 
from before it was data.pointer. Definitely, if pointing to a 
group of people then in it a personGrp/@xml:id -- though I'd be 
tempted to put xml:id="all" on the listPerson.

-James

-- 
Dr James Cummings, James.Cummings at it.ox.ac.uk
Academic IT Services, University of Oxford

From James.Cummings at it.ox.ac.uk  Thu Dec 27 20:04:25 2012
From: James.Cummings at it.ox.ac.uk (James Cummings)
Date: Fri, 28 Dec 2012 01:04:25 +0000
Subject: [tei-council] January TEI Release
In-Reply-To: <50DCD134.4060807@retired.ox.ac.uk>
References: <50DB4D17.2050209@it.ox.ac.uk> <50DCD134.4060807@retired.ox.ac.uk>
Message-ID: <50DCF019.60901@it.ox.ac.uk>

On 27/12/12 22:52, Lou Burnard wrote:
> I cannot for the life of me understand why this is a good idea. If you
> want to randomly allocate chapters for reading, why on earth do so in a
> way which guarantees that some chapters will get multiple readers and
> some (those numbered greater than 12 for example) will never ever get
> read? Surely you can think of a better algorithm?

I was going to say birthdayMonth+1 or similar at the next 
release. ;-)  You are right that we need a better overall and 
systematic review of the Guidelines, but I thought this might be 
a fairly quick, easy, way to have people look at a chapter they 
might not have re-read recently.

T'was only a suggestion but I'll certainly be reading chapter 12.

-James


-- 
Dr James Cummings, James.Cummings at it.ox.ac.uk
Academic IT Services, University of Oxford

From kevin.s.hawkins at ultraslavonic.info  Fri Dec 28 12:06:18 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Fri, 28 Dec 2012 12:06:18 -0500
Subject: [tei-council] <specList>s in Guidelines: exhaustive or selected?
Message-ID: <50DDD18A.8090507@ultraslavonic.info>

I am unclear on whether <specList>s in the Guidelines are supposed to 
list all child elements or just those that are most relevant.  This has 
come up in http://purl.org/TEI/FR/3585570 , and I would like to clarify 
it at 
http://www.tei-c.org/Activities/Council/Working/tcw20.xml#body.1_div.1 .

From lou.burnard at retired.ox.ac.uk  Fri Dec 28 12:16:38 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Fri, 28 Dec 2012 17:16:38 +0000
Subject: [tei-council] <specList>s in Guidelines: exhaustive or selected?
In-Reply-To: <50DDD18A.8090507@ultraslavonic.info>
References: <50DDD18A.8090507@ultraslavonic.info>
Message-ID: <50DDD3F6.3090705@retired.ox.ac.uk>

On 28/12/12 17:06, Kevin Hawkins wrote:
> I am unclear on whether <specList>s in the Guidelines are supposed to
> list all child elements or just those that are most relevant.

That is a stylistic issue. A specList will typically list all the 
elements discussed within a given section. Sometimes (quite often in the 
Header) sections are organised in terms of the hierarchic structure but 
this is definitely not necessarily the case: you can group the elements 
discussed in a section in any way that makes sense (as for example in 
the Core chapter). You can also choose not to discuss all the elements 
which might appear as content for the elements being discussed -- lots 
of elements have a content model of paraContent: you wouldn't want all 
the components of para Content to be listed anew each time each such 
element is discussed.

   This has
> come up in http://purl.org/TEI/FR/3585570 , and I would like to clarify
> it at
> http://www.tei-c.org/Activities/Council/Working/tcw20.xml#body.1_div.1 .

I've commented on the ticket.






From kevin.s.hawkins at ultraslavonic.info  Fri Dec 28 13:44:18 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Fri, 28 Dec 2012 13:44:18 -0500
Subject: [tei-council] <specList>s in Guidelines: exhaustive or selected?
In-Reply-To: <50DDD3F6.3090705@retired.ox.ac.uk>
References: <50DDD18A.8090507@ultraslavonic.info>
	<50DDD3F6.3090705@retired.ox.ac.uk>
Message-ID: <50DDE882.6030708@ultraslavonic.info>

On 12/28/12 12:16 PM, Lou Burnard wrote:
> On 28/12/12 17:06, Kevin Hawkins wrote:
>> I am unclear on whether <specList>s in the Guidelines are supposed to
>> list all child elements or just those that are most relevant.
>
> That is a stylistic issue. A specList will typically list all the
> elements discussed within a given section. Sometimes (quite often in the
> Header) sections are organised in terms of the hierarchic structure but
> this is definitely not necessarily the case: you can group the elements
> discussed in a section in any way that makes sense (as for example in
> the Core chapter). You can also choose not to discuss all the elements
> which might appear as content for the elements being discussed -- lots
> of elements have a content model of paraContent: you wouldn't want all
> the components of para Content to be listed anew each time each such
> element is discussed.

Okay, that all makes sense.  I've clarified in tcw20.

>     This has
>> come up in http://purl.org/TEI/FR/3585570 , and I would like to clarify
>> it at
>> http://www.tei-c.org/Activities/Council/Working/tcw20.xml#body.1_div.1 .
>
> I've commented on the ticket.

Thanks.

On the ticket, Lou suggests that we might want the ability to specify a 
model class (and its members) within a specList.  I've created a new 
ticket for discussion of that: http://purl.org/TEI/FR/3598775 .

From sebastian.rahtz at it.ox.ac.uk  Fri Dec 28 17:07:40 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Fri, 28 Dec 2012 22:07:40 +0000
Subject: [tei-council] <specList>s in Guidelines: exhaustive or selected?
In-Reply-To: <50DDD3F6.3090705@retired.ox.ac.uk>
References: <50DDD18A.8090507@ultraslavonic.info>,
	<50DDD3F6.3090705@retired.ox.ac.uk>
Message-ID: <a913ce42-efcf-445f-84a3-014a3ce29bd0@HUB04.ad.oak.ox.ac.uk>

The ability to show a class in a specList already exists, and is mentioned in the ref doc for specDesc. What the effect is,   i recall not. If its wrong, can adjust.

Carved in stone on my iPad

On 28 Dec 2012, at 18:16, "Lou Burnard" <lou.burnard at retired.ox.ac.uk> wrote:

> On 28/12/12 17:06, Kevin Hawkins wrote:
>> I am unclear on whether <specList>s in the Guidelines are supposed to
>> list all child elements or just those that are most relevant.
> 
> That is a stylistic issue. A specList will typically list all the 
> elements discussed within a given section. Sometimes (quite often in the 
> Header) sections are organised in terms of the hierarchic structure but 
> this is definitely not necessarily the case: you can group the elements 
> discussed in a section in any way that makes sense (as for example in 
> the Core chapter). You can also choose not to discuss all the elements 
> which might appear as content for the elements being discussed -- lots 
> of elements have a content model of paraContent: you wouldn't want all 
> the components of para Content to be listed anew each time each such 
> element is discussed.
> 
> 

From lou.burnard at retired.ox.ac.uk  Fri Dec 28 18:24:25 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Fri, 28 Dec 2012 23:24:25 +0000
Subject: [tei-council] <specList>s in Guidelines: exhaustive or selected?
In-Reply-To: <10C65A6C-15ED-4DB0-82B0-79DBE1A32E9E@oucs.ox.ac.uk>
References: <50DDD18A.8090507@ultraslavonic.info>,
	<50DDD3F6.3090705@retired.ox.ac.uk>
	<10C65A6C-15ED-4DB0-82B0-79DBE1A32E9E@oucs.ox.ac.uk>
Message-ID: <50DE2A29.2080204@retired.ox.ac.uk>

My recollection is that this works for attribute classes, but I'm not 
sure it does anything sensible for model classes. Will check.


On 28/12/12 22:07, Sebastian Rahtz wrote:
> The ability to show a class in a specList already exists, and is mentioned in the ref doc for specDesc. What the effect is,   i recall not. If its wrong, can adjust.
>
> Carved in stone on my iPad
>
> On 28 Dec 2012, at 18:16, "Lou Burnard" <lou.burnard at retired.ox.ac.uk> wrote:
>
>> On 28/12/12 17:06, Kevin Hawkins wrote:
>>> I am unclear on whether <specList>s in the Guidelines are supposed to
>>> list all child elements or just those that are most relevant.
>>
>> That is a stylistic issue. A specList will typically list all the
>> elements discussed within a given section. Sometimes (quite often in the
>> Header) sections are organised in terms of the hierarchic structure but
>> this is definitely not necessarily the case: you can group the elements
>> discussed in a section in any way that makes sense (as for example in
>> the Core chapter). You can also choose not to discuss all the elements
>> which might appear as content for the elements being discussed -- lots
>> of elements have a content model of paraContent: you wouldn't want all
>> the components of para Content to be listed anew each time each such
>> element is discussed.
>>
>>


From kevin.s.hawkins at ultraslavonic.info  Fri Dec 28 21:28:54 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Fri, 28 Dec 2012 21:28:54 -0500
Subject: [tei-council] Standard form for elementSpec/desc
In-Reply-To: <50DCD209.6030600@retired.ox.ac.uk>
References: <50DB6DC0.5080100@uvic.ca> <50DCD209.6030600@retired.ox.ac.uk>
Message-ID: <50DE5566.6060204@ultraslavonic.info>

On 12/27/12 5:56 PM, Lou Burnard wrote:
> On 26/12/12 21:36, Martin Holmes wrote:
>> Proofing my birthday chapter (#8), I've come across something which I
>> recall bothering me in the past. Most element descriptions take the form
>> of verb phrases:
>>
>> [<scriptStmt>] contains a citation giving details of the script used for
>> a spoken text.
>>
>> Others are in the form of noun phrases:
>>
>> [<recording>] details of an audio or video recording event
>> used as the source of a spoken text, either directly or from
>> a public broadcast.
>
> The second example is erroneous. There used to be a house style rule
> which explicitly said that the description should follow the pattern of
> the first one, i.e. should contain a verb phrase, but I don't recall
> when or why it disappeared.  For the reasons Martin points out, it
> should definitely come back.

The rule is at http://www.tei-c.org/Vault/ED/edw11.txt , which is linked 
from http://www.tei-c.org/Activities/Council/Working/tcw24.xml as one of 
the mostly superseded documents.  I've just added this rule to tcw24.

From lou.burnard at retired.ox.ac.uk  Sat Dec 29 08:14:19 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Sat, 29 Dec 2012 13:14:19 +0000
Subject: [tei-council] [TEI-notify] SF.net SVN: tei:[11278]
	trunk/P5/Source/Guidelines/en/CO-CoreElements.xml
In-Reply-To: <E1Too4z-0005wE-DR@sfp-svn-1.v30.ch3.sourceforge.com>
References: <E1Too4z-0005wE-DR@sfp-svn-1.v30.ch3.sourceforge.com>
Message-ID: <50DEECAB.3090508@retired.ox.ac.uk>

On 29/12/12 04:31, kshawkin at users.sourceforge.net wrote:
> Revision: 11278
>            http://tei.svn.sourceforge.net/tei/?rev=11278&view=rev
> Author:   kshawkin
> Date:     2012-12-29 04:31:24 +0000 (Sat, 29 Dec 2012)
> Log Message:
> -----------
> fixed bug 3585939 plus some corrections related to incomplete implementation at revisions 7427, 7521, and 7964 of biblio document circulated on tei-council on 2012-04-24
>
> Modified Paths:
> --------------
>      trunk/P5/Source/Guidelines/en/CO-CoreElements.xml
>

This change seems to have introduced an inconsistency between what the 
prose of the Guidelines says and what the examples do. The prose says 
that it is not necessary to add a @level attribute to title when the 
level can be inferred from the parent element (<analytic> <monogr> etc) 
and gives an example which explicitly says that this attribute has been 
omitted, even though it is in fact present (the Merlin one).

A sentence has been added earlier saying that we recommend always 
supplying the @level attribute, which I don't recall our having 
discussed as such. It seems an unnecessary redundancy (sorry for the 
pleonasm but you know what I mean) to me, but in any case we ought to 
decide what the status of this "recommendation" is. If  @level is not 
mandatory on <title> (which it currently isn't) then we ought to explain 
in what circs it can be omitted, and how its absence is to be 
interpreted, (as we currently do more or less). And we ought to have 
some examples showing it being omitted, obv.

From kevin.s.hawkins at ultraslavonic.info  Sat Dec 29 09:07:43 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Sat, 29 Dec 2012 09:07:43 -0500
Subject: [tei-council] [TEI-notify] SF.net SVN: tei:[11278]
	trunk/P5/Source/Guidelines/en/CO-CoreElements.xml
In-Reply-To: <50DEECAB.3090508@retired.ox.ac.uk>
References: <E1Too4z-0005wE-DR@sfp-svn-1.v30.ch3.sourceforge.com>
	<50DEECAB.3090508@retired.ox.ac.uk>
Message-ID: <50DEF92F.7080400@ultraslavonic.info>

On 12/29/12 8:14 AM, Lou Burnard wrote:
> On 29/12/12 04:31, kshawkin at users.sourceforge.net wrote:
>> Revision: 11278
>>             http://tei.svn.sourceforge.net/tei/?rev=11278&view=rev
>> Author:   kshawkin
>> Date:     2012-12-29 04:31:24 +0000 (Sat, 29 Dec 2012)
>> Log Message:
>> -----------
>> fixed bug 3585939 plus some corrections related to incomplete implementation at revisions 7427, 7521, and 7964 of biblio document circulated on tei-council on 2012-04-24
>>
>> Modified Paths:
>> --------------
>>       trunk/P5/Source/Guidelines/en/CO-CoreElements.xml
>>
>
> This change seems to have introduced an inconsistency between what the
> prose of the Guidelines says and what the examples do. The prose says
> that it is not necessary to add a @level attribute to title when the
> level can be inferred from the parent element (<analytic> <monogr> etc)
> and gives an example which explicitly says that this attribute has been
> omitted, even though it is in fact present (the Merlin one).

Actually, the prose no longer says this (see below), so in this latest 
commit I corrected the example so that the Merlin example no longer has 
an inferred value of @level.

> A sentence has been added earlier saying that we recommend always
> supplying the @level attribute, which I don't recall our having
> discussed as such.

Following the sentence "When it appears directly within an 
<gi>analytic</gi>, <gi>monogr</gi>, or <gi>series</gi> element, 
<gi>title</gi> is interpreted as belonging to the appropriate level.", 
the Guidelines used to say:

When it appears elsewhere, its <att>level</att> attribute should be used 
to signal its bibliographic level.

But at revision 7964, Lou changed it to:

However, it is recommended that the <att>level</att> attribute should 
always be used to signal this explicitly

This was one of the changes recommended in the biblio document 
circulated on tei-council on 2012-04-24 ( 
http://lists.village.virginia.edu/pipermail/tei-council/2010/011823.html 
), which Lou selectively implemented in revisions 7427, 7521, and 7964 
and then sent back to Martin, Laurent, and me to rework what remained 
(which we've been doing over the past few years in various tickets).

 > It seems an unnecessary redundancy (sorry for the
> pleonasm but you know what I mean) to me, but in any case we ought to
> decide what the status of this "recommendation" is. If  @level is not
> mandatory on <title> (which it currently isn't) then we ought to explain
> in what circs it can be omitted, and how its absence is to be
> interpreted, (as we currently do more or less). And we ought to have
> some examples showing it being omitted, obv.

One of the principles in the biblio document was to be explicit in the 
markup for ease of processing.  We were focused on use of @level on 
<title> when <title> occurs in bibl*, not elsewhere in a document. 
While I added @level to all <title>s in <biblStruct>s, I left a few 
<titles> without @level in <bibl>s.

From lou.burnard at retired.ox.ac.uk  Sat Dec 29 10:51:29 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Sat, 29 Dec 2012 15:51:29 +0000
Subject: [tei-council] [TEI-notify] SF.net SVN: tei:[11278]
	trunk/P5/Source/Guidelines/en/CO-CoreElements.xml
In-Reply-To: <50DEF92F.7080400@ultraslavonic.info>
References: <E1Too4z-0005wE-DR@sfp-svn-1.v30.ch3.sourceforge.com>
	<50DEECAB.3090508@retired.ox.ac.uk>
	<50DEF92F.7080400@ultraslavonic.info>
Message-ID: <50DF1181.60800@retired.ox.ac.uk>

On 29/12/12 14:07, Kevin Hawkins wrote:

> Actually, the prose no longer says this (see below), so in this latest
> commit I corrected the example so that the Merlin example no longer has
> an inferred value of @level.

I'm referring to the following:

"In this case, the analytic title <q>Notes on Manuscripts of the
<title level="m" xml:lang="fr">Proph?cies de Merlin</title></q> needs no 
<att>level</att>
attribute because it is directly contained by an <gi>analytic</gi>
element. The  monographic title it contains similarly needs no
<att>level</att> attribute, since it is a constituent of the analytic
title. "

which follows an example in which the @level attribute *is* supplied, on 
both <title>s. I think that's rather confusing.


>
>> A sentence has been added earlier saying that we recommend always
>> supplying the @level attribute, which I don't recall our having
>> discussed as such.
>
> Following the sentence "When it appears directly within an
> <gi>analytic</gi>, <gi>monogr</gi>, or <gi>series</gi> element,
> <gi>title</gi> is interpreted as belonging to the appropriate level.",
> the Guidelines used to say:
>
> When it appears elsewhere, its <att>level</att> attribute should be used
> to signal its bibliographic level.
>
> But at revision 7964, Lou changed it to:
>
> However, it is recommended that the <att>level</att> attribute should
> always be used to signal this explicitly

No need to be ad hominem about this. I stand by my assertion that this 
recommendation needs more justification (f  @level is not
 >> mandatory on <title> (which it currently isn't) then we ought to explain
 >> in what circs it can be omitted, and how its absence is to be
 >> interpreted, (as we currently do more or less). And we ought to have
 >> some examples showing it being omitted, obv.

>
> This was one of the changes recommended in the biblio document
> circulated on tei-council on 2012-04-24 (

I think that date is a bit unlikely!



From kevin.s.hawkins at ultraslavonic.info  Sat Dec 29 11:09:29 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Sat, 29 Dec 2012 11:09:29 -0500
Subject: [tei-council] [TEI-notify] SF.net SVN: tei:[11278]
	trunk/P5/Source/Guidelines/en/CO-CoreElements.xml
In-Reply-To: <50DF1181.60800@retired.ox.ac.uk>
References: <E1Too4z-0005wE-DR@sfp-svn-1.v30.ch3.sourceforge.com>
	<50DEECAB.3090508@retired.ox.ac.uk>
	<50DEF92F.7080400@ultraslavonic.info>
	<50DF1181.60800@retired.ox.ac.uk>
Message-ID: <50DF15B9.7090908@ultraslavonic.info>

On 12/29/12 10:51 AM, Lou Burnard wrote:
> On 29/12/12 14:07, Kevin Hawkins wrote:
>
>> Actually, the prose no longer says this (see below), so in this latest
>> commit I corrected the example so that the Merlin example no longer has
>> an inferred value of @level.
>
> I'm referring to the following:
>
> "In this case, the analytic title <q>Notes on Manuscripts of the
> <title level="m" xml:lang="fr">Proph?cies de Merlin</title></q> needs no
> <att>level</att>
> attribute because it is directly contained by an <gi>analytic</gi>
> element. The  monographic title it contains similarly needs no
> <att>level</att> attribute, since it is a constituent of the analytic
> title. "
>
> which follows an example in which the @level attribute *is* supplied, on
> both <title>s. I think that's rather confusing.

Fair enough, even though the "needs to <att>level</att> attribute" is 
still strictly true.

>>> A sentence has been added earlier saying that we recommend always
>>> supplying the @level attribute, which I don't recall our having
>>> discussed as such.
>>
>> Following the sentence "When it appears directly within an
>> <gi>analytic</gi>, <gi>monogr</gi>, or <gi>series</gi> element,
>> <gi>title</gi> is interpreted as belonging to the appropriate level.",
>> the Guidelines used to say:
>>
>> When it appears elsewhere, its <att>level</att> attribute should be used
>> to signal its bibliographic level.
>>
>> But at revision 7964, Lou changed it to:
>>
>> However, it is recommended that the <att>level</att> attribute should
>> always be used to signal this explicitly
>
> No need to be ad hominem about this. I stand by my assertion that this
> recommendation needs more justification (f  @level is not
>   >> mandatory on <title> (which it currently isn't) then we ought to explain
>   >> in what circs it can be omitted, and how its absence is to be
>   >> interpreted, (as we currently do more or less). And we ought to have
>   >> some examples showing it being omitted, obv.

Possibly, though the "however" sentence follows the one about appearing 
directly within <analytic>, <monogr>, and <series>, so it seems to me 
that we are giving this recommendation only in the case that <title> 
appears directly within <analytic>, <monogr>, and <series>.  Maybe that 
recommendation should be expanded to other positions in which <title> 
may appear (such as in a <bibl> or elsewhere in the document).  Or we 
should revert this particular change from revision 7964.

>> This was one of the changes recommended in the biblio document
>> circulated on tei-council on 2012-04-24 (
>
> I think that date is a bit unlikely!

Oops.  2010-04-24, as in the timestamp on the message at the URL.


From kevin.s.hawkins at ultraslavonic.info  Sat Dec 29 12:58:51 2012
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Sat, 29 Dec 2012 12:58:51 -0500
Subject: [tei-council] Attributes without examples
In-Reply-To: <50D48E07.2040709@ultraslavonic.info>
References: <5028011F.4050007@it.ox.ac.uk>
	<502848C5.5030504@uvic.ca>	<50D3E1E1.7080201@ultraslavonic.info>
	<50D48A1F.60202@uvic.ca> <50D48E07.2040709@ultraslavonic.info>
Message-ID: <50DF2F5B.1030904@ultraslavonic.info>

A procedural question about this task ...

Is it okay to copy an example from a chapter of the Guidelines into the 
appropriate elementSpec or classSpec?  That is, we're not concerned 
about such duplicated examples falling out of sync in case we adjust one 
and not another?

--Kevin

On 12/21/12 11:27 AM, Kevin Hawkins wrote:
> Excellent.  I've added back in "assigned to" initials from the old chart
> for a few claimed by by Brett and Paul.
>
> On 12/21/2012 11:11 AM, Martin Holmes wrote:
>> I've posted a new list:
>>
>> <http://wiki.tei-c.org/index.php/AttsWithoutEgs>
>>
>> It's a bit shorter (only 164 attributes). I'll do a bit more work on it
>> -- my code wasn't dealing with @xml:* attributes properly, and I also
>> want to turn the "Defined in" field into a link to the appropriate page
>> on the latest Jenkins build.
>>
>> Cheers,
>> Martin
>>
>> On 12-12-20 08:13 PM, Kevin Hawkins wrote:
>>> To bring back an old thread, I've looked at this wiki page that Martin
>>> created and seen that it includes attributes that have a defined list of
>>> legal values.  It seems to me that there's not much point in giving
>>> examples of these since the list of values generally explains what each
>>> means.
>>>
>>> Martin, do you still have the code you used to create the list?  Could
>>> you possibly exclude those that have a list of legal values?  If you are
>>> able to create this list, we are still, unfortunately, stuck merging the
>>> existing page, where people have signed up to add certain examples.
>>>
>>> --Kevin
>>>
>>> On 8/12/12 8:22 PM, Martin Holmes wrote:
>>>> The last time I took a look through these, I seem to remember coming to
>>>> the conclusion that one situation in particular is most urgent: where
>>>> attributes are declared in an attribute class, and none of the elements
>>>> which are members of that attribute class have examples which
>>>> illustrate
>>>> the use of that attribute.
>>>>
>>>> I'm not sure how many of these there are -- I was halfway through some
>>>> XSLT to find out, but I got distracted. I'll try to finish that.
>>>>
>>>> Cheers,
>>>> Martin
>>>>
>>>> On 12-08-12 12:16 PM, James Cummings wrote:
>>>>>
>>>>> One of the things that Kevin reminded me of recently was that we
>>>>> still have lots of attributes without examples:
>>>>>
>>>>> http://wiki.tei-c.org/index.php/AttsWithoutEgs
>>>>>
>>>>> I'm as guilty as the others who have not signed up to provide
>>>>> some, but will try to do so in the next week or two.  Any other
>>>>> suggestions? Can everyone sign up to provide some examples?
>>>>>
>>>>> -James
>>>>>
>>

From sebastian.rahtz at it.ox.ac.uk  Sat Dec 29 13:02:49 2012
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Sat, 29 Dec 2012 18:02:49 +0000
Subject: [tei-council] Attributes without examples
In-Reply-To: <50DF2F5B.1030904@ultraslavonic.info>
References: <5028011F.4050007@it.ox.ac.uk>	<502848C5.5030504@uvic.ca>
	<50D3E1E1.7080201@ultraslavonic.info>	<50D48A1F.60202@uvic.ca>
	<50D48E07.2040709@ultraslavonic.info>,
	<50DF2F5B.1030904@ultraslavonic.info>
Message-ID: <20F882EE-360B-4F9B-BD98-17C9B6A20E50@oucs.ox.ac.uk>



Carved in stone on my iPad

On 29 Dec 2012, at 18:58, "Kevin Hawkins" <kevin.s.hawkins at ultraslavonic.info> wrote:

> A procedural question about this task ...
> 
> Is it okay to copy an example from a chapter of the Guidelines into the 
> appropriate elementSpec or classSpec?  That is, we're not concerned 
> about such duplicated examples falling out of sync in case we adjust one 
> and not another?


I would be inclined not to copy. I would either move from chapter to Spec, or find a new one.

Sebastian

From lou.burnard at retired.ox.ac.uk  Sat Dec 29 13:03:04 2012
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Sat, 29 Dec 2012 18:03:04 +0000
Subject: [tei-council] Attributes without examples
In-Reply-To: <50DF2F5B.1030904@ultraslavonic.info>
References: <5028011F.4050007@it.ox.ac.uk>
	<502848C5.5030504@uvic.ca>	<50D3E1E1.7080201@ultraslavonic.info>
	<50D48A1F.60202@uvic.ca> <50D48E07.2040709@ultraslavonic.info>
	<50DF2F5B.1030904@ultraslavonic.info>
Message-ID: <50DF3058.80508@retired.ox.ac.uk>

On 29/12/12 17:58, Kevin Hawkins wrote:
> A procedural question about this task ...
>
> Is it okay to copy an example from a chapter of the Guidelines into the
> appropriate elementSpec or classSpec?  That is, we're not concerned
> about such duplicated examples falling out of sync in case we adjust one
> and not another?
There's ample precedent for that. Both the copying, and the failing to 
keep them in sync. :-(

On the list of ODD enhancements that hasn't made it yet is the ability 
to suck an example out of the spec and plonk it into the prose, the same 
way as we currently suck <desc>s out for <specList>s. Would need some 
way of identifying which example you wanted, of course, so might involve 
adding xml:ids to all the <egXML>s.

> --Kevin
>
> On 12/21/12 11:27 AM, Kevin Hawkins wrote:
>> Excellent.  I've added back in "assigned to" initials from the old chart
>> for a few claimed by by Brett and Paul.
>>
>> On 12/21/2012 11:11 AM, Martin Holmes wrote:
>>> I've posted a new list:
>>>
>>> <http://wiki.tei-c.org/index.php/AttsWithoutEgs>
>>>
>>> It's a bit shorter (only 164 attributes). I'll do a bit more work on it
>>> -- my code wasn't dealing with @xml:* attributes properly, and I also
>>> want to turn the "Defined in" field into a link to the appropriate page
>>> on the latest Jenkins build.
>>>
>>> Cheers,
>>> Martin
>>>
>>> On 12-12-20 08:13 PM, Kevin Hawkins wrote:
>>>> To bring back an old thread, I've looked at this wiki page that Martin
>>>> created and seen that it includes attributes that have a defined list of
>>>> legal values.  It seems to me that there's not much point in giving
>>>> examples of these since the list of values generally explains what each
>>>> means.
>>>>
>>>> Martin, do you still have the code you used to create the list?  Could
>>>> you possibly exclude those that have a list of legal values?  If you are
>>>> able to create this list, we are still, unfortunately, stuck merging the
>>>> existing page, where people have signed up to add certain examples.
>>>>
>>>> --Kevin
>>>>
>>>> On 8/12/12 8:22 PM, Martin Holmes wrote:
>>>>> The last time I took a look through these, I seem to remember coming to
>>>>> the conclusion that one situation in particular is most urgent: where
>>>>> attributes are declared in an attribute class, and none of the elements
>>>>> which are members of that attribute class have examples which
>>>>> illustrate
>>>>> the use of that attribute.
>>>>>
>>>>> I'm not sure how many of these there are -- I was halfway through some
>>>>> XSLT to find out, but I got distracted. I'll try to finish that.
>>>>>
>>>>> Cheers,
>>>>> Martin
>>>>>
>>>>> On 12-08-12 12:16 PM, James Cummings wrote:
>>>>>> One of the things that Kevin reminded me of recently was that we
>>>>>> still have lots of attributes without examples:
>>>>>>
>>>>>> http://wiki.tei-c.org/index.php/AttsWithoutEgs
>>>>>>
>>>>>> I'm as guilty as the others who have not signed up to provide
>>>>>> some, but will try to do so in the next week or two.  Any other
>>>>>> suggestions? Can everyone sign up to provide some examples?
>>>>>>
>>>>>> -James
>>>>>>


From James.Cummings at it.ox.ac.uk  Mon Dec 31 06:24:18 2012
From: James.Cummings at it.ox.ac.uk (James Cummings)
Date: Mon, 31 Dec 2012 11:24:18 +0000
Subject: [tei-council] TEI Newsfeed problem
Message-ID: <50E175E2.5020208@it.ox.ac.uk>

Hiya David and Council

My email has been being spammed by the TEI Newsfeed because it 
keeps updating.  This is because for some reason when we wget the 
Atom feed it has changed the links to be <a> elements, and 
sometimes it hasn't.  Weird eh?

e.g. it 2012-12-31T05:30:03.atom.xml we have:

===
You can see the details of the vote from here: 
https://opavote.appspot.com/results/678015/0</p>
===

whereas in  2012-12-31T05:45:03.atom.xml we have:

===
You can see the details of the vote from here: <a 
href="https://opavote.appspot.com/results/678015/0" 
rel="nofollow">https://opavote.appspot.com/results/678015/0</a></p>
===

Nothing has changed really in the meantime, just the way that 
wordpress serializes its HTML seems to be one of the two ways 
randomly.

The tests that wget-news.sh does are:

1) If identical then stop
2) If not well-formed then error
3) If doesn't at least have one <entry in it, then error

Previously we used to test if one was bigger than the other, but 
that now won't work since we don't see all articles.

The wget-newsfeed.sh is in SVN in the TEIC/newsfeed/ directory:
http://tei.svn.sourceforge.net/viewvc/tei/trunk/TEIC/newsfeed/wget-news.sh?revision=11283&content-type=text%2Fplain

Can anyone think of a bash shell script test that we could do to 
see if this is a real changed/updated file or not? Is there a 
wordpress setting we can change? Is there some way to wget it 
while telling it we do/don't want this? Any ideas appreciated.

It isn't doing it every 15 minutes ... sometimes the expansion or 
not is the same as the previous time it grabbed it, but it did it 
more than 40 times on 2012-12-30. Now I could turn off the 
email'ing me of the updated atom file easily enough -- though 
getting this helps me know if there are any sudden problems.

However, currently every time the newsfeed updates it makes a 
dateTime-stamped backup copy in: 
/lv1/projects/tei/web/include/news-old/ on the tei-c.org machine. 
   At 224K each, the files from 2012-12-30 took up 10 meg. While 
we're not going to run out of space soon (14G currently available 
on /lv1), it does seem like a problem we should solve.

Any suggestions appreciated.

-James

-- 
Dr James Cummings, James.Cummings at it.ox.ac.uk
Research Support, IT Services, University of Oxford

From dsewell at virginia.edu  Mon Dec 31 10:20:55 2012
From: dsewell at virginia.edu (David Sewell)
Date: Mon, 31 Dec 2012 10:20:55 -0500 (EST)
Subject: [tei-council] TEI Newsfeed problem
In-Reply-To: <50E175E2.5020208@it.ox.ac.uk>
References: <50E175E2.5020208@it.ox.ac.uk>
Message-ID: <alpine.OSX.2.00.1212311019470.62513@tadai.local>

As Kevin had a query to me about the newsfeed and I think I may have a 
solution to James's problem, I'm going to respond offline to the two of 
them so as not to clutter the list with technical details,

David

On Mon, 31 Dec 2012, James Cummings wrote:

> Hiya David and Council
>
> My email has been being spammed by the TEI Newsfeed because it keeps 
> updating.  This is because for some reason when we wget the Atom feed it has 
> changed the links to be <a> elements, and sometimes it hasn't.  Weird eh?
>
> e.g. it 2012-12-31T05:30:03.atom.xml we have:
>
> ===
> You can see the details of the vote from here: 
> https://opavote.appspot.com/results/678015/0</p>
> ===
>
> whereas in  2012-12-31T05:45:03.atom.xml we have:
>
> ===
> You can see the details of the vote from here: <a 
> href="https://opavote.appspot.com/results/678015/0" 
> rel="nofollow">https://opavote.appspot.com/results/678015/0</a></p>
> ===
>
> Nothing has changed really in the meantime, just the way that wordpress 
> serializes its HTML seems to be one of the two ways randomly.
>
> The tests that wget-news.sh does are:
>
> 1) If identical then stop
> 2) If not well-formed then error
> 3) If doesn't at least have one <entry in it, then error
>
> Previously we used to test if one was bigger than the other, but that now 
> won't work since we don't see all articles.
>
> The wget-newsfeed.sh is in SVN in the TEIC/newsfeed/ directory:
> http://tei.svn.sourceforge.net/viewvc/tei/trunk/TEIC/newsfeed/wget-news.sh?revision=11283&content-type=text%2Fplain
>
> Can anyone think of a bash shell script test that we could do to see if this 
> is a real changed/updated file or not? Is there a wordpress setting we can 
> change? Is there some way to wget it while telling it we do/don't want this? 
> Any ideas appreciated.
>
> It isn't doing it every 15 minutes ... sometimes the expansion or not is the 
> same as the previous time it grabbed it, but it did it more than 40 times on 
> 2012-12-30. Now I could turn off the email'ing me of the updated atom file 
> easily enough -- though getting this helps me know if there are any sudden 
> problems.
>
> However, currently every time the newsfeed updates it makes a 
> dateTime-stamped backup copy in: /lv1/projects/tei/web/include/news-old/ on 
> the tei-c.org machine.   At 224K each, the files from 2012-12-30 took up 10 
> meg. While we're not going to run out of space soon (14G currently available 
> on /lv1), it does seem like a problem we should solve.
>
> Any suggestions appreciated.
>
> -James
>
>

-- 
David Sewell, Editorial and Technical Manager
ROTUNDA, The University of Virginia Press
PO Box 400314, Charlottesville, VA 22904-4314 USA
Email: dsewell at virginia.edu   Tel: +1 434 924 9973
Web: http://rotunda.upress.virginia.edu/

From mholmes at uvic.ca  Mon Dec 31 17:49:03 2012
From: mholmes at uvic.ca (Martin Holmes)
Date: Mon, 31 Dec 2012 14:49:03 -0800
Subject: [tei-council] <when>/@absolute and dateTime values
Message-ID: <50E2165F.304@uvic.ca>

This bit of Chapter 8:

<http://www.tei-c.org/release/doc/tei-p5-doc/en/html/TS.html#TSSAPA>

contains this example:

<timeline unit="s" origin="#TS-P1">
  <when xml:id="TS-P1" absolute="12:20:01"/>
  <when xml:id="TS-P2" interval="4.5" since="#TS-P1"/>
  <when xml:id="TS-P6"/>
  <when xml:id="TS-P3" interval="1.5" since="#TS-P6"/>
</timeline>

with the following commentary:

"... TS-P1 is located absolutely, at 12:20:01:01 BST. TS-P2 is 4.5 
seconds later than TS-P2 (i.e. at 12:20:46)..."

I was first of all puzzled by the assertion that this is BST (British 
Summer Time). Nothing in the example suggests that there is any timezone 
offset from UTC, which I assumed was the default. Then I looked at the 
datatype for @absolute, which is data.temporal.w3c, about which we say 
in a note:

"If it is likely that the value used is to be compared with another, 
then a time zone indicator should always be included, and only the 
dateTime representation should be used."

<http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-data.temporal.w3c.html>

So in this context, the xsd:dateTime representation should be used, and 
it should include a timezone. So I looked at the W3C spec:

<http://www.w3.org/TR/xmlschema-2/#dateTime>

which, as I read it, requires the presence of a date; whereas our 
example has only a time.

It seems to me, therefore, that this usage of @absolute is wrong on two 
counts: first, it should include a date, and second, it ought to have a 
timezone offset of 'Z', the canonical representation for an offset of 
zero, i.e. UTC. Further, I think the claim that this value is BST makes 
no sense (BST is UTC+1) given that the example has no timezone offset in it.

Am I missing anything here?

Cheers,
Martin


From Syd_Bauman at Brown.edu  Mon Dec 31 22:52:50 2012
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Mon, 31 Dec 2012 22:52:50 -0500
Subject: [tei-council] <when>/@absolute and dateTime values
In-Reply-To: <50E2165F.304@uvic.ca>
References: <50E2165F.304@uvic.ca>
Message-ID: <20706.23954.938588.700568@emt.ad.brown.edu>

I think your analysis is pretty correct, although I reach a slightly
different conclusion.

* The "BST" is leftover from P4, when it was specified in the
  absolute=. I don't know how it got dropped. Seems to me the value
  of absolute= in that example in TS should have been 12:20:01+01:00.

* While you're right, and in many cases the note in data.temporal.w3c
  is right, in many (if not most) cases where we can imagine
  <timeline> being used, dates (and for that matter time zones) are
  simply irrelevant. In many (if not most) cases, although the times
  might be compared, they're only going to be compared to other
  <when> in the same timeline, or other <timeline>s in the same
  corpus. Thus requiring a date (IMHO) would be silly.

So my first reaction is that think we should drop the "BST", and
re-iterate the warning that if you expect the values in your timeline
to be compared to other values out there in the world, you should
include a date and timezone.

> This bit of Chapter 8:
> 
> <http://www.tei-c.org/release/doc/tei-p5-doc/en/html/TS.html#TSSAPA>
> 
> contains this example:
> 
> <timeline unit="s" origin="#TS-P1">
>   <when xml:id="TS-P1" absolute="12:20:01"/>
>   <when xml:id="TS-P2" interval="4.5" since="#TS-P1"/>
>   <when xml:id="TS-P6"/>
>   <when xml:id="TS-P3" interval="1.5" since="#TS-P6"/>
> </timeline>
> 
> with the following commentary:
> 
> "... TS-P1 is located absolutely, at 12:20:01:01 BST. TS-P2 is 4.5 
> seconds later than TS-P2 (i.e. at 12:20:46)..."
> 
> I was first of all puzzled by the assertion that this is BST (British
> Summer Time). Nothing in the example suggests that there is any
> timezone offset from UTC, which I assumed was the default. Then I
> looked at the datatype for @absolute, which is data.temporal.w3c,
> about which we say in a note:
> 
> "If it is likely that the value used is to be compared with another, 
> then a time zone indicator should always be included, and only the 
> dateTime representation should be used."
> 
> <http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-data.temporal.w3c.html>
> 
> So in this context, the xsd:dateTime representation should be used,
> and it should include a timezone. So I looked at the W3C spec:
> 
> <http://www.w3.org/TR/xmlschema-2/#dateTime>
> 
> which, as I read it, requires the presence of a date; whereas our 
> example has only a time.
> 
> It seems to me, therefore, that this usage of @absolute is wrong on
> two counts: first, it should include a date, and second, it ought to
> have a timezone offset of 'Z', the canonical representation for an
> offset of zero, i.e. UTC. Further, I think the claim that this value
> is BST makes no sense (BST is UTC+1) given that the example has no
> timezone offset in it.
> 
> Am I missing anything here?