From lou.burnard at retired.ox.ac.uk Tue Jan 1 06:08:21 2013
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Tue, 01 Jan 2013 11:08:21 +0000
Subject: [tei-council] /@absolute and dateTime values
In-Reply-To: <20706.23954.938588.700568@emt.ad.brown.edu>
References: <50E2165F.304@uvic.ca> <20706.23954.938588.700568@emt.ad.brown.edu>
Message-ID: <50E2C3A5.3020907@retired.ox.ac.uk>
On 01/01/13 03:52, Syd Bauman wrote:
> I think your analysis is pretty correct, although I reach a slightly
> different conclusion.
Twas ever thus.... just for the record, I think it might be better to
make the example conform to the documentation, i.e. reinstate the
"+01:00" rather than removing the reference to BST.
The comment on should make explicit that this is not required in the
(more usual) circumstance where the times in the timeline are just
relative to a specified , which is not itself absolutely located
in time. This is the only situation in which one might care about the
date, or time zone, of course.
>
> * 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
> 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
> in the same timeline, or other 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:
>>
>>
>>
>> contains this example:
>>
>>
>>
>>
>>
>>
>>
>>
>> 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."
>>
>>
>>
>> So in this context, the xsd:dateTime representation should be used,
>> and it should include a timezone. So I looked at the W3C spec:
>>
>>
>>
>> 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?
From mholmes at uvic.ca Tue Jan 1 13:27:51 2013
From: mholmes at uvic.ca (Martin Holmes)
Date: Tue, 1 Jan 2013 10:27:51 -0800
Subject: [tei-council] /@absolute and dateTime values
In-Reply-To: <20706.23954.938588.700568@emt.ad.brown.edu>
References: <50E2165F.304@uvic.ca> <20706.23954.938588.700568@emt.ad.brown.edu>
Message-ID: <50E32AA7.2070005@uvic.ca>
That makes sense, and I'll make the relevant changes. This text, though:
"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."
needs to be changed a bit to make it clear that what we mean here is
comparison with an external datetime source, because in a TEI
, as shown in the example below, the @absolute value is
arguably always being compared with other internal values such as those
specified in @interval.
Cheers,
Martin
On 12-12-31 07:52 PM, Syd Bauman wrote:
> 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
> 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
> in the same timeline, or other 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:
>>
>>
>>
>> contains this example:
>>
>>
>>
>>
>>
>>
>>
>>
>> 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."
>>
>>
>>
>> So in this context, the xsd:dateTime representation should be used,
>> and it should include a timezone. So I looked at the W3C spec:
>>
>>
>>
>> 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?
From mholmes at uvic.ca Tue Jan 1 14:07:16 2013
From: mholmes at uvic.ca (Martin Holmes)
Date: Tue, 1 Jan 2013 11:07:16 -0800
Subject: [tei-council] without timing information?
Message-ID: <50E333E4.3080807@uvic.ca>
Take a look at this block from Chapter 8:
--------------------
Where the whole of one or another utterance is to be synchronized, the
start and end attributes may be used:
I used to smoke a lot more than this
but I never inhaled the smoke
You used to smoke
[...]
If synchronization with specific timing information is required, a
timeline must be included:
I used to smoke
a lot more than this
but I never inhaled the smoke
You used to smoke
-----------------
The expanded version with is introduced explicitly to show
"specific timing information", but it doesn't seem to do so; there's no
@absolute or @interval, and as far as I can see, the addition of
provides no benefit to the encoding. I think this is a simple
omission, which could be remedied by adding appropriate timing info,
like this:
I used to smoke
a lot more than this
but I never inhaled the smoke
You used to smoke
Have I misunderstood, or should I go ahead and make this change?
Cheers,
Martin
From kevin.s.hawkins at ultraslavonic.info Wed Jan 2 09:04:50 2013
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Wed, 02 Jan 2013 09:04:50 -0500
Subject: [tei-council] January TEI Release
In-Reply-To: <50DB51AB.1060200@uvic.ca>
References: <50DB4D17.2050209@it.ox.ac.uk> <50DB51AB.1060200@uvic.ca>
Message-ID: <50E43E82.40703@ultraslavonic.info>
I've just noticed that the Oxford Jenkins is outdated.
You'll notice that the citation including "Historical Social Research"
contains biblScopes outside of imprint at
http://teijenkins.hcmc.uvic.ca/job/TEIP5/lastSuccessfulBuild/artifact/release/doc/tei-p5-doc/en/html/CO.html
but they are still inside the imprint at
http://tei.oucs.ox.ac.uk/jenkins/job/TEIP5/lastSuccessfulBuild/artifact/release/doc/tei-p5-doc/en/html/CO.html#COBI
The relevant change was committed on November 3!
--Kevin
On 12/26/12 2:36 PM, Martin Holmes wrote:
> When you read the chapter of your birth month (good idea, James), it's
> best to read one of the current Jenkins build versions:
>
>
>
>
>
> (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
>>
>
From mholmes at uvic.ca Wed Jan 2 14:22:09 2013
From: mholmes at uvic.ca (Martin Holmes)
Date: Wed, 2 Jan 2013 11:22:09 -0800
Subject: [tei-council] January TEI Release
In-Reply-To: <50E43E82.40703@ultraslavonic.info>
References: <50DB4D17.2050209@it.ox.ac.uk> <50DB51AB.1060200@uvic.ca>
<50E43E82.40703@ultraslavonic.info>
Message-ID: <50E488E1.8060109@uvic.ca>
Well spotted, and especially so because if you hadn't noticed, we might
have released from the Oxford Jinks build and had another bad release
experience.
I don't know what would cause this, but the Oxford Jinks has been down a
couple of times recently (once yesterday). I think only Sebastian has
admin access. Might be time to nuke the workspace of the P5 job and make
it do a fresh checkout.
I wonder if we should set something up to check whether the two servers
are producing identical products? It would be good to run that before a
release, just to be sure. The two servers are supposed to act as a check
on each other, but if they're producing different results we would
currently only notice by accident.
Cheers,
Martin
On 13-01-02 06:04 AM, Kevin Hawkins wrote:
> I've just noticed that the Oxford Jenkins is outdated.
>
> You'll notice that the citation including "Historical Social Research"
> contains biblScopes outside of imprint at
>
> http://teijenkins.hcmc.uvic.ca/job/TEIP5/lastSuccessfulBuild/artifact/release/doc/tei-p5-doc/en/html/CO.html
>
> but they are still inside the imprint at
>
> http://tei.oucs.ox.ac.uk/jenkins/job/TEIP5/lastSuccessfulBuild/artifact/release/doc/tei-p5-doc/en/html/CO.html#COBI
>
> The relevant change was committed on November 3!
>
> --Kevin
>
> On 12/26/12 2:36 PM, Martin Holmes wrote:
>> When you read the chapter of your birth month (good idea, James), it's
>> best to read one of the current Jenkins build versions:
>>
>>
>>
>>
>>
>> (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
>>>
>>
From sebastian.rahtz at it.ox.ac.uk Wed Jan 2 14:33:55 2013
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Wed, 2 Jan 2013 19:33:55 +0000
Subject: [tei-council] January TEI Release
In-Reply-To: <50E43E82.40703@ultraslavonic.info>
References: <50DB4D17.2050209@it.ox.ac.uk>
<50DB51AB.1060200@uvic.ca>,<50E43E82.40703@ultraslavonic.info>
Message-ID:
That's deeply disturbing. I'd like to analyse how this happened before I just do a deep clean
Carved in stone on my iPad
On 2 Jan 2013, at 14:04, "Kevin Hawkins" wrote:
> I've just noticed that the Oxford Jenkins is outdated.
>
> You'll notice that the citation including "Historical Social Research"
> contains biblScopes outside of imprint at
>
> http://teijenkins.hcmc.uvic.ca/job/TEIP5/lastSuccessfulBuild/artifact/release/doc/tei-p5-doc/en/html/CO.html
>
> but they are still inside the imprint at
>
> http://tei.oucs.ox.ac.uk/jenkins/job/TEIP5/lastSuccessfulBuild/artifact/release/doc/tei-p5-doc/en/html/CO.html#COBI
>
> The relevant change was committed on November 3!
>
> --Kevin
>
> On 12/26/12 2:36 PM, Martin Holmes wrote:
>> When you read the chapter of your birth month (good idea, James), it's
>> best to read one of the current Jenkins build versions:
>>
>>
>>
>>
>>
>> (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
> --
> 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 Jan 2 17:42:01 2013
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Wed, 2 Jan 2013 22:42:01 +0000
Subject: [tei-council] January TEI Release
In-Reply-To: <50E43E82.40703@ultraslavonic.info>
References: <50DB4D17.2050209@it.ox.ac.uk> <50DB51AB.1060200@uvic.ca>
<50E43E82.40703@ultraslavonic.info>
Message-ID: <3668239B-5603-4070-8A3D-313BDDD17B01@it.ox.ac.uk>
ah, the truth is revealed.
the URL http://tei.oucs.ox.ac.uk/jenkins/job/TEIP5/lastSuccessfulBuild/artifact/release/doc/tei-p5-doc/en/html/CO.html#CO.html
is a proxy rewrite on tei.oucs.ox.ac.uk to
http://bits.nsms.ox.ac.uk:8080/jenkins/job/TEIP5/lastSuccessfulBuild/artifact/release/doc/tei-p5-doc/en/html/CO.html
and the latter is correct.
so why does tei.oucs appear to be caching the files? because I messed up the rewrite rules... fixed...
So I am happy that the
Jenkins is correct. And the good news is that the install script uses the http://bits.nsms.ox.ac.uk:8080/jenkins
version anyway, so releases would have been fine.
--
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 Jan 3 06:04:21 2013
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Thu, 3 Jan 2013 11:04:21 +0000
Subject: [tei-council] SF.net SVN: tei:[11270]
trunk/P5/Source/Guidelines/en/ TS-TranscriptionsofSpeech.xml
In-Reply-To: <50DC58B8.4030302@ultraslavonic.info>
References:
<15B12685-4B23-4243-B925-29172EC0D1DA@oucs.ox.ac.uk>
<50DC58B8.4030302@ultraslavonic.info>
Message-ID:
On 27 Dec 2012, at 14:18, Kevin Hawkins wrote:
>>> -element; the class model.phrase.spoken
>>> +element; the class model.global.spoken
>>> provides the six other elements listed above.
>>>
>>
>> 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.
I have added this test.
Lo! a slew of errors are reported :-}
--
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 Jan 3 06:34:13 2013
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Thu, 3 Jan 2013 11:34:13 +0000
Subject: [tei-council] SF.net SVN: tei:[11270]
trunk/P5/Source/Guidelines/en/ TS-TranscriptionsofSpeech.xml
In-Reply-To:
References:
<15B12685-4B23-4243-B925-29172EC0D1DA@oucs.ox.ac.uk>
<50DC58B8.4030302@ultraslavonic.info>
Message-ID: <5BDE34F0-634E-4C01-B7ED-14C63DEAEB65@it.ox.ac.uk>
On 3 Jan 2013, at 11:04, 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.
>>
>> To validation as part of the build process? Yes, please.
>
> I have added this test.
>
> Lo! a slew of errors are reported :-}
I have, in case you wondered, fixed all these now. All the ones in old Prefaces
which pointed at old names for classes I have simply changed to with
no @type
This was well worth doing - there were quite a few (understandable) typos and mis-rememberings there.
--
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 Jan 3 07:37:18 2013
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Thu, 3 Jan 2013 12:37:18 +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: <82AA5839-10AD-4B42-8498-F2323846B291@it.ox.ac.uk>
On 26 Dec 2012, at 22:29, Martin Holmes wrote:
> 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
For what its worth, I have no problem myself in mentally translating the old meanings
of "above" and "below" into their digital equivalents. But I guess it does no harm
in simplifying the prose in the way you suggest.
--
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 Jan 3 08:36:07 2013
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Thu, 3 Jan 2013 13:36:07 +0000
Subject: [tei-council] without timing information?
In-Reply-To: <50E333E4.3080807@uvic.ca>
References: <50E333E4.3080807@uvic.ca>
Message-ID: <3F316662-D2D9-4EA1-86DA-E0C9BCE1AB4D@it.ox.ac.uk>
i support your interpretation that, without the timeline attributes on , the example is incoherent. so I'd say add 'em
--
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 Jan 3 09:54:36 2013
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Thu, 3 Jan 2013 14:54:36 +0000
Subject: [tei-council] description of @type's data values
Message-ID:
there's some interesting observations by the indefatigable John M at https://sourceforge.net/tracker/?func=detail&atid=644062&aid=3599062&group_id=106328
which needs some loving care. Anyone feel like a go at it?
You have to love the on distinct/@type:
"a semi-open user-defined list"
I bet that meant something very specific to whoever wrote it :-}
--
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 lou.burnard at retired.ox.ac.uk Thu Jan 3 09:59:18 2013
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Thu, 03 Jan 2013 14:59:18 +0000
Subject: [tei-council] description of @type's data values
In-Reply-To:
References:
Message-ID: <50E59CC6.5050703@retired.ox.ac.uk>
On 03/01/13 14:54, Sebastian Rahtz wrote:
> there's some interesting observations by the indefatigable John M at https://sourceforge.net/tracker/?func=detail&atid=644062&aid=3599062&group_id=106328
> which needs some loving care. Anyone feel like a go at it?
Happy to have a crack at these. Actually, there is an outstanding ticket
somewhere (I think; or it may just be a council action) to check on all
s. Although most of them are deeply suspicious we left them
untouched because some of them express constraints that could or should
be schematronized
From sebastian.rahtz at it.ox.ac.uk Thu Jan 3 10:04:01 2013
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Thu, 3 Jan 2013 15:04:01 +0000
Subject: [tei-council] description of @type's data values
In-Reply-To: <50E59CC6.5050703@retired.ox.ac.uk>
References:
<50E59CC6.5050703@retired.ox.ac.uk>
Message-ID:
On 3 Jan 2013, at 14:59, Lou Burnard
wrote:
> On 03/01/13 14:54, Sebastian Rahtz wrote:
>> there's some interesting observations by the indefatigable John M at https://sourceforge.net/tracker/?func=detail&atid=644062&aid=3599062&group_id=106328
>> which needs some loving care. Anyone feel like a go at it?
>
> Happy to have a crack at these. Actually, there is an outstanding ticket
> somewhere (I think; or it may just be a council action) to check on all
> s. Although most of them are deeply suspicious we left them
> untouched because some of them express constraints that could or should
> be schematronized
yes, nothing wrong with the use of per se, the concern is where
the description is not consonant with data.enumerated. its language like
"word or phrase" which jumps out at the reader.
--
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 Thu Jan 3 10:11:40 2013
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Thu, 03 Jan 2013 10:11:40 -0500
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: <50E59FAC.5090307@ultraslavonic.info>
I'll give a "+1" in support of Martin, not to clutter everyone's inboxes
but to counter the weak protests. --Kevin
On 12/26/2012 5:29 PM, Martin Holmes wrote:
> 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 sebastian.rahtz at it.ox.ac.uk Thu Jan 3 12:05:27 2013
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Thu, 3 Jan 2013 17:05:27 +0000
Subject: [tei-council] specList/specDesc/@key=model.XXXX
Message-ID: <3D11821D65070D4BADB84B46F7FE203CBF7572@MBX01.ad.oak.ox.ac.uk>
you can see the way this is now displayed at http://bits.nsms.ox.ac.uk:8080/jenkins/job/TEIP5/lastSuccessfulBuild/artifact/release/doc/tei-p5-doc/en/html/CO.html#COBICOI
if people dont like this display, they should shout now and say what they want :-}
Sebastian Rahtz
Oxford University Computing Services
From mholmes at uvic.ca Thu Jan 3 13:54:57 2013
From: mholmes at uvic.ca (Martin Holmes)
Date: Thu, 3 Jan 2013 10:54:57 -0800
Subject: [tei-council] description of @type's data values
In-Reply-To:
References:
<50E59CC6.5050703@retired.ox.ac.uk>
Message-ID: <50E5D401.9010000@uvic.ca>
It's this ticket:
which I've made a start on. Would anyone care to read my last comment,
and see if I've outlined the target attributes correctly?
Cheers,
Martin
On 13-01-03 07:04 AM, Sebastian Rahtz wrote:
>
> On 3 Jan 2013, at 14:59, Lou Burnard
> wrote:
>
>> On 03/01/13 14:54, Sebastian Rahtz wrote:
>>> there's some interesting observations by the indefatigable John M at https://sourceforge.net/tracker/?func=detail&atid=644062&aid=3599062&group_id=106328
>>> which needs some loving care. Anyone feel like a go at it?
>>
>> Happy to have a crack at these. Actually, there is an outstanding ticket
>> somewhere (I think; or it may just be a council action) to check on all
>> s. Although most of them are deeply suspicious we left them
>> untouched because some of them express constraints that could or should
>> be schematronized
>
>
> yes, nothing wrong with the use of per se, the concern is where
> the description is not consonant with data.enumerated. its language like
> "word or phrase" which jumps out at the reader.
> --
> 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 lou.burnard at retired.ox.ac.uk Fri Jan 4 11:22:06 2013
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Fri, 04 Jan 2013 16:22:06 +0000
Subject: [tei-council] span span span span
Message-ID: <50E701AE.9010705@retired.ox.ac.uk>
As Piotr is no longer with us :-( I have taken it on myself to implement
purl.org/TEI/FR/3526975 -- a bit irregular since I submitted the fr in
the first place, but this has been sitting around for months. Pray
forgive me!
To do it properly I had to add a bunch of schematron rules, which
someone else should check for me,
From sebastian.rahtz at it.ox.ac.uk Fri Jan 4 11:25:59 2013
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Fri, 4 Jan 2013 16:25:59 +0000
Subject: [tei-council] span span span span
In-Reply-To: <50E701AE.9010705@retired.ox.ac.uk>
References: <50E701AE.9010705@retired.ox.ac.uk>
Message-ID:
On 4 Jan 2013, at 16:22, Lou Burnard
wrote:
> As Piotr is no longer with us :-( I have taken it on myself to implement
> purl.org/TEI/FR/3526975 -- a bit irregular since I submitted the fr in
> the first place, but this has been sitting around for months. Pray
> forgive me!
> To do it properly I had to add a bunch of schematron rules, which
> someone else should check for me,
i will add some test material to Tests/detest.xml 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 lou.burnard at retired.ox.ac.uk Fri Jan 4 11:56:28 2013
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Fri, 04 Jan 2013 16:56:28 +0000
Subject: [tei-council] span span span span
In-Reply-To:
References: <50E701AE.9010705@retired.ox.ac.uk>
Message-ID: <50E709BC.8010400@retired.ox.ac.uk>
On 04/01/13 16:33, Sebastian Rahtz wrote:
> should @target test it points to two things?
>
> --
> S
Not nessa, i think. is semantically equivalent to
From dsewell at virginia.edu Fri Jan 4 12:29:24 2013
From: dsewell at virginia.edu (David Sewell)
Date: Fri, 4 Jan 2013 12:29:24 -0500 (EST)
Subject: [tei-council] TEI Tite status question
Message-ID:
Anyone on Council: Is the TEI Tite exemplar (at SF rev 11160,
http://tei.svn.sourceforge.net/viewvc/tei/trunk/P5/Exemplars/tei_tite.odd?view=log)
more or less in a frozen state at the moment, or are substantive changes
envisioned in any near future?
I need to update an in-house vendor schema deriving from Tite but will wait if
it is still in flux.
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 sebastian.rahtz at it.ox.ac.uk Fri Jan 4 12:34:26 2013
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Fri, 4 Jan 2013 17:34:26 +0000
Subject: [tei-council] description of @type's data values
In-Reply-To: <50E5D401.9010000@uvic.ca>
References:
<50E59CC6.5050703@retired.ox.ac.uk>
<50E5D401.9010000@uvic.ca>
Message-ID:
On 3 Jan 2013, at 18:54, Martin Holmes wrote:
> It's this ticket:
>
>
>
> which I've made a start on.
I chipped and sorted 60-70 of the s, about 180 remaining.
A good many are perfectly sensible:
Source/Specs/leaf.xml: The identifier of the parent node.
others remain silly:
Source/Specs/iNode.xml: A list of identifiers.
while yet others are amenable to checking, but its hard:
A series of one or more space-separated pointers (URIs) to category
elements, typically located within a taxonomy element inside a TEI header.
(not easy in Schematron if there are multiple pointers?)
--
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 Jan 4 12:36:20 2013
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Fri, 4 Jan 2013 17:36:20 +0000
Subject: [tei-council] TEI Tite status question
In-Reply-To:
References:
Message-ID: <3DF945EE-E0A8-4DA6-8D0B-576D1EA27561@it.ox.ac.uk>
On 4 Jan 2013, at 17:29, David Sewell
wrote:
> Anyone on Council: Is the TEI Tite exemplar (at SF rev 11160,
> http://tei.svn.sourceforge.net/viewvc/tei/trunk/P5/Exemplars/tei_tite.odd?view=log)
> more or less in a frozen state at the moment, or are substantive changes
> envisioned in any near future?
I believe it to be in very slow flux. i.e. there are changes which Apex
made by hand which need to be integrated back into the source,
but its taking a while to get that done. I fear the burden is on Kevin's broad
shoulders as ever.
--
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 Fri Jan 4 12:41:04 2013
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Fri, 04 Jan 2013 12:41:04 -0500
Subject: [tei-council] TEI Tite status question
In-Reply-To:
References:
Message-ID: <50E71430.1030604@ultraslavonic.info>
It's more or less frozen. I have an action item from the Ann Arbor
meeting last April to freeze Tite more officially, like Lou did for Lite
in early 2012, and I still haven't found time to do this.
(On the other hand, from a prior Council meeting I also have an action
item to to verify syncing the Apex and canonical Tite versions (partly
held up by family illness on the Apex end), and I also want to implement
a few long-standing Tite feature requests in SourceForge that I
intentionally put off until I finished syncing the two Tite schemas.
Still, none of these things are going to happen in the very near future.)
--K.
On 1/4/2013 12:29 PM, David Sewell wrote:
> Anyone on Council: Is the TEI Tite exemplar (at SF rev 11160,
> http://tei.svn.sourceforge.net/viewvc/tei/trunk/P5/Exemplars/tei_tite.odd?view=log)
> more or less in a frozen state at the moment, or are substantive changes
> envisioned in any near future?
>
> I need to update an in-house vendor schema deriving from Tite but will wait if
> it is still in flux.
>
> thanks,
>
> David
>
From sebastian.rahtz at it.ox.ac.uk Fri Jan 4 16:32:33 2013
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Fri, 4 Jan 2013 21:32:33 +0000
Subject: [tei-council] att.sourced () contradiction
Message-ID:
see conversation about Pessoa on TEI-L.
On the one hand:
@ed is described with "supplies an arbitrary identifier for the source edition in which
the associated feature (for example, a page, column, or line
break) occurs at this point in the text" , with a gloss of
"A string of characters or sigil used conventionally to identify the edition", and an example is
On the other hand:
The datatype of @ed is data.code, which is anyURI
I put if to you all that this cannot stand. The prose describes something like @cRef,
the datatype is like @wit.
I suggest that the datatype is what we intended, and that the prose
has not been brought into line.
Anyone with me?
--
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 Jan 4 22:38:57 2013
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Fri, 04 Jan 2013 22:38:57 -0500
Subject: [tei-council] att.sourced () contradiction
In-Reply-To:
References:
Message-ID: <50E7A051.2040006@ultraslavonic.info>
Looking through the history in Subversion, I see that att.sourced has
had data.code since the beginning, when it was implemented as part of
http://purl.org/TEI/FR/2216574 . Perhaps that sheds some light on this.
On 1/4/13 4:32 PM, Sebastian Rahtz wrote:
> see conversation about Pessoa on TEI-L.
>
> On the one hand:
> @ed is described with "supplies an arbitrary identifier for the source edition in which
> the associated feature (for example, a page, column, or line
> break) occurs at this point in the text" , with a gloss of
> "A string of characters or sigil used conventionally to identify the edition", and an example is
>
> On the other hand:
> The datatype of @ed is data.code, which is anyURI
>
> I put if to you all that this cannot stand. The prose describes something like @cRef,
> the datatype is like @wit.
>
> I suggest that the datatype is what we intended, and that the prose
> has not been brought into line.
>
> Anyone with me?
> --
> 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 Sat Jan 5 08:11:49 2013
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Sat, 5 Jan 2013 13:11:49 +0000
Subject: [tei-council] att.sourced () contradiction
In-Reply-To: <50E7A051.2040006@ultraslavonic.info>
References:
<50E7A051.2040006@ultraslavonic.info>
Message-ID:
On 5 Jan 2013, at 03:38, Kevin Hawkins wrote:
> Looking through the history in Subversion, I see that att.sourced has
> had data.code since the beginning, when it was implemented as part of
> http://purl.org/TEI/FR/2216574 .
true. but what we're missing is a collective memory of how we intended
data.code to work. It isn't used anywhere else except att.sourced, and
I cant recall now why it is different to data.pointer. I think I remember there _was_
discussion about that, but I can't trace it.
Mr Occam would suggest that the correct course of action could be
- remove data.code
- change att.sourced to use data.pointer
- change prose to say that @ed must point to something
--
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 Sat Jan 5 08:39:09 2013
From: gabriel.bodard at kcl.ac.uk (Gabriel Bodard)
Date: Sat, 5 Jan 2013 13:39:09 +0000
Subject: [tei-council] att.sourced () contradiction
In-Reply-To:
References:
<50E7A051.2040006@ultraslavonic.info>
Message-ID: <50E82CFD.1080101@kcl.ac.uk>
What about all the people who are now using @ed to contain a cRef like
string that "conventionally expresses" the edition that has a linebreak
at this point? (They should stop and start using a pointer instead of a
cRef, I agree, but backwards compatibility?) I'm not sure if I'm
suggesting forking @ed into @ed-string and @ed-ref, but I worry a little
bit about it.
Gabby
On 05/01/2013 13:11, Sebastian Rahtz wrote:
>
> On 5 Jan 2013, at 03:38, Kevin Hawkins wrote:
>
>> Looking through the history in Subversion, I see that att.sourced has
>> had data.code since the beginning, when it was implemented as part of
>> http://purl.org/TEI/FR/2216574 .
>
> true. but what we're missing is a collective memory of how we intended
> data.code to work. It isn't used anywhere else except att.sourced, and
> I cant recall now why it is different to data.pointer. I think I remember there _was_
> discussion about that, but I can't trace it.
>
> Mr Occam would suggest that the correct course of action could be
>
> - remove data.code
> - change att.sourced to use data.pointer
> - change prose to say that @ed must point to something
> --
> 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
>
--
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 Sat Jan 5 09:00:09 2013
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Sat, 5 Jan 2013 14:00:09 +0000
Subject: [tei-council] att.sourced () contradiction
In-Reply-To: <50E82CFD.1080101@kcl.ac.uk>
References:
<50E7A051.2040006@ultraslavonic.info>
<50E82CFD.1080101@kcl.ac.uk>
Message-ID: <993D356D-F447-4AD2-8B09-6942B65CCA0D@it.ox.ac.uk>
On 5 Jan 2013, at 13:39, Gabriel Bodard
wrote:
> What about all the people who are now using @ed to contain a cRef like
> string that "conventionally expresses" the edition that has a linebreak
> at this point? (They should stop and start using a pointer instead of a
> cRef, I agree, but backwards compatibility?)
people who are currently saying
are pointing
at a local file called "1665", though they realize it or not.
the alternative is to change data.code to be simply text,
but the consider the question on TEI-L, where the questioner
asks where to define what @ed refers to.
in fact, the _text_ about @ed really seems to suggest
use of data.key ("the range of attribute values expressing a coded value by means of an arbitrary
identifier, typically taken from a set of externally-defined possibilities")
--
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 Sat Jan 5 11:50:04 2013
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Sat, 5 Jan 2013 16:50:04 +0000
Subject: [tei-council] my open tickets for next release
Message-ID: <0A125FC4-733F-4F26-A872-066FCEB27F0F@it.ox.ac.uk>
I have been over the tickets assigned to me in Bugs and Feature Requests and resolved/fixed/implemented
those that I feel I can have any effect on.
I have 16 bugs assigned to me, but most are about Roma, and I am not about to work on that.
I have 2 feature requests assigned to me, but cannot fix either
Unless anyone is waiting on me to do anything, I am calling it a day
for now. I am going outside the tent and may be some time :-}
--
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 Jan 5 15:36:40 2013
From: mholmes at uvic.ca (Martin Holmes)
Date: Sat, 5 Jan 2013 12:36:40 -0800
Subject: [tei-council] description of @type's data values
In-Reply-To:
References:
<50E59CC6.5050703@retired.ox.ac.uk>
<50E5D401.9010000@uvic.ca>
Message-ID: <50E88ED8.9060409@uvic.ca>
Thanks Sebastian. I'm hoping to have a little time to work on this tomorrow.
The challenge of checking a list of multiple pointers in Schematron is
interesting. It might be possible to check pointers to @xml:ids inside
the same file, but I don't think it's possible to check for the
existence of a element in another file from inside a
Schematron constraint, is it?
Cheers,
Martin
On 13-01-04 09:34 AM, Sebastian Rahtz wrote:
>
> On 3 Jan 2013, at 18:54, Martin Holmes wrote:
>
>> It's this ticket:
>>
>>
>>
>> which I've made a start on.
>
> I chipped and sorted 60-70 of the s, about 180 remaining.
> A good many are perfectly sensible:
>
> Source/Specs/leaf.xml: The identifier of the parent node.
>
> others remain silly:
>
> Source/Specs/iNode.xml: A list of identifiers.
>
> while yet others are amenable to checking, but its hard:
> A series of one or more space-separated pointers (URIs) to category
> elements, typically located within a taxonomy element inside a TEI header.
> (not easy in Schematron if there are multiple pointers?)
> --
> 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 Jan 5 15:58:38 2013
From: mholmes at uvic.ca (Martin Holmes)
Date: Sat, 5 Jan 2013 12:58:38 -0800
Subject: [tei-council] att.sourced () contradiction
In-Reply-To:
References:
Message-ID: <50E893FE.3040205@uvic.ca>
+1 from me.
On 13-01-04 01:32 PM, Sebastian Rahtz wrote:
> see conversation about Pessoa on TEI-L.
>
> On the one hand:
> @ed is described with "supplies an arbitrary identifier for the source edition in which
> the associated feature (for example, a page, column, or line
> break) occurs at this point in the text" , with a gloss of
> "A string of characters or sigil used conventionally to identify the edition", and an example is
>
> On the other hand:
> The datatype of @ed is data.code, which is anyURI
>
> I put if to you all that this cannot stand. The prose describes something like @cRef,
> the datatype is like @wit.
>
> I suggest that the datatype is what we intended, and that the prose
> has not been brought into line.
>
> Anyone with me?
> --
> 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 Sat Jan 5 16:06:36 2013
From: gabriel.bodard at kcl.ac.uk (Gabriel Bodard)
Date: Sat, 5 Jan 2013 21:06:36 +0000
Subject: [tei-council] att.sourced () contradiction
In-Reply-To: <993D356D-F447-4AD2-8B09-6942B65CCA0D@it.ox.ac.uk>
References:
<50E7A051.2040006@ultraslavonic.info>
<50E82CFD.1080101@kcl.ac.uk>
<993D356D-F447-4AD2-8B09-6942B65CCA0D@it.ox.ac.uk>
Message-ID: <50E895DC.8030705@kcl.ac.uk>
No I agree with you that a pointer makes sense, and of the three options
a. define @ed to take text, like @cRef
b. define @ed to be a pointer and take a uri
c. fork @ed so we have ways to do both the above
I like (a) the least. But I'm a bit torn between b. and c., simply
because of all the people who have been misled by the text ("A string of
characters or sigil used conventionally to identify the edition") and
example in the guidelines, which I suspect is the majority. (I haven't
used @ed very often, and certainly not very recently, but I don't recall
what I put in it. Probably not a pointer.)
Not feeling strongly enough about this to shout if there is a clear
consensus for (b), however. :-)
Gabby
On 05/01/2013 14:00, Sebastian Rahtz wrote:
>
> On 5 Jan 2013, at 13:39, Gabriel Bodard
> wrote:
>
>> What about all the people who are now using @ed to contain a cRef like
>> string that "conventionally expresses" the edition that has a linebreak
>> at this point? (They should stop and start using a pointer instead of a
>> cRef, I agree, but backwards compatibility?)
>
> people who are currently saying
are pointing
> at a local file called "1665", though they realize it or not.
>
> the alternative is to change data.code to be simply text,
> but the consider the question on TEI-L, where the questioner
> asks where to define what @ed refers to.
>
> in fact, the _text_ about @ed really seems to suggest
> use of data.key ("the range of attribute values expressing a coded value by means of an arbitrary
> identifier, typically taken from a set of externally-defined possibilities")
>
> --
> 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
>
>
--
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 mholmes at uvic.ca Sat Jan 5 16:32:05 2013
From: mholmes at uvic.ca (Martin Holmes)
Date: Sat, 5 Jan 2013 13:32:05 -0800
Subject: [tei-council] att.sourced () contradiction
In-Reply-To: <50E82CFD.1080101@kcl.ac.uk>
References:
<50E7A051.2040006@ultraslavonic.info>
<50E82CFD.1080101@kcl.ac.uk>
Message-ID: <50E89BD5.8000103@uvic.ca>
A quick fix for existing projects would be to implement a prefix
definition declaration, and search-and-replace ed=" for ed="def:
But that's hardly Birnbaumian.
Cheers,
Martin
On 13-01-05 05:39 AM, Gabriel Bodard wrote:
> What about all the people who are now using @ed to contain a cRef like
> string that "conventionally expresses" the edition that has a linebreak
> at this point? (They should stop and start using a pointer instead of a
> cRef, I agree, but backwards compatibility?) I'm not sure if I'm
> suggesting forking @ed into @ed-string and @ed-ref, but I worry a little
> bit about it.
>
> Gabby
>
> On 05/01/2013 13:11, Sebastian Rahtz wrote:
>>
>> On 5 Jan 2013, at 03:38, Kevin Hawkins wrote:
>>
>>> Looking through the history in Subversion, I see that att.sourced has
>>> had data.code since the beginning, when it was implemented as part of
>>> http://purl.org/TEI/FR/2216574 .
>>
>> true. but what we're missing is a collective memory of how we intended
>> data.code to work. It isn't used anywhere else except att.sourced, and
>> I cant recall now why it is different to data.pointer. I think I remember there _was_
>> discussion about that, but I can't trace it.
>>
>> Mr Occam would suggest that the correct course of action could be
>>
>> - remove data.code
>> - change att.sourced to use data.pointer
>> - change prose to say that @ed must point to something
>> --
>> 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 Jan 5 16:45:07 2013
From: mholmes at uvic.ca (Martin Holmes)
Date: Sat, 5 Jan 2013 13:45:07 -0800
Subject: [tei-council] att.sourced () contradiction
In-Reply-To: <50E895DC.8030705@kcl.ac.uk>
References:
<50E7A051.2040006@ultraslavonic.info>
<50E82CFD.1080101@kcl.ac.uk>
<993D356D-F447-4AD2-8B09-6942B65CCA0D@it.ox.ac.uk>
<50E895DC.8030705@kcl.ac.uk>
Message-ID: <50E89EE3.8060700@uvic.ca>
If we do b), I don't think we'll actually break very much, will we? The
only case in which a currently-valid project would become invalid would
be where the identifiers happen to begin with a number. If that's only a
few cases, then it might be acceptable. Other cases where a cRef-style
identifier is used would be formally wrong (they would apparently point
to a file that didn't exist), but wouldn't show as invalid.
Cheers,
Martin
On 13-01-05 01:06 PM, Gabriel Bodard wrote:
> No I agree with you that a pointer makes sense, and of the three options
>
> a. define @ed to take text, like @cRef
> b. define @ed to be a pointer and take a uri
> c. fork @ed so we have ways to do both the above
>
> I like (a) the least. But I'm a bit torn between b. and c., simply
> because of all the people who have been misled by the text ("A string of
> characters or sigil used conventionally to identify the edition") and
> example in the guidelines, which I suspect is the majority. (I haven't
> used @ed very often, and certainly not very recently, but I don't recall
> what I put in it. Probably not a pointer.)
>
> Not feeling strongly enough about this to shout if there is a clear
> consensus for (b), however. :-)
>
> Gabby
>
> On 05/01/2013 14:00, Sebastian Rahtz wrote:
>>
>> On 5 Jan 2013, at 13:39, Gabriel Bodard
>> wrote:
>>
>>> What about all the people who are now using @ed to contain a cRef like
>>> string that "conventionally expresses" the edition that has a linebreak
>>> at this point? (They should stop and start using a pointer instead of a
>>> cRef, I agree, but backwards compatibility?)
>>
>> people who are currently saying
are pointing
>> at a local file called "1665", though they realize it or not.
>>
>> the alternative is to change data.code to be simply text,
>> but the consider the question on TEI-L, where the questioner
>> asks where to define what @ed refers to.
>>
>> in fact, the _text_ about @ed really seems to suggest
>> use of data.key ("the range of attribute values expressing a coded value by means of an arbitrary
>> identifier, typically taken from a set of externally-defined possibilities")
>>
>> --
>> 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 Sat Jan 5 17:00:44 2013
From: gabriel.bodard at kcl.ac.uk (Gabriel Bodard)
Date: Sat, 5 Jan 2013 22:00:44 +0000
Subject: [tei-council] att.sourced () contradiction
In-Reply-To: <50E89EE3.8060700@uvic.ca>
References:
<50E7A051.2040006@ultraslavonic.info>
<50E82CFD.1080101@kcl.ac.uk>
<993D356D-F447-4AD2-8B09-6942B65CCA0D@it.ox.ac.uk>
<50E895DC.8030705@kcl.ac.uk> <50E89EE3.8060700@uvic.ca>
Message-ID: <50E8A28C.1020709@kcl.ac.uk>
But whether the file is technically valid or not is less of an issue as
far as I'm concerned than whether a file uses the TEI correctly. There
are all sorts of ways for a file to be valid but wrong (a pointer that
has nothing at the target explaining what is in your markup). If @ed is
defined to be a pointer to a description of the edition in question, and
instead it is being treated as an arbitrary, conventional string, then
even if the schema can't tell the difference that is a bigger kind of
broken.
The analogous case, for me, of an attribute that didn't get a strict
pointer/valList datatype in P5, is @lemma, and there were have the
parallel @lemmaRef for the case where someone wants to use it in the
more strict way, so there's precedent for forking, I guess.
G
On 05/01/2013 21:45, Martin Holmes wrote:
> If we do b), I don't think we'll actually break very much, will we? The
> only case in which a currently-valid project would become invalid would
> be where the identifiers happen to begin with a number. If that's only a
> few cases, then it might be acceptable. Other cases where a cRef-style
> identifier is used would be formally wrong (they would apparently point
> to a file that didn't exist), but wouldn't show as invalid.
>
> Cheers,
> Martin
>
> On 13-01-05 01:06 PM, Gabriel Bodard wrote:
>> No I agree with you that a pointer makes sense, and of the three options
>>
>> a. define @ed to take text, like @cRef
>> b. define @ed to be a pointer and take a uri
>> c. fork @ed so we have ways to do both the above
>>
>> I like (a) the least. But I'm a bit torn between b. and c., simply
>> because of all the people who have been misled by the text ("A string of
>> characters or sigil used conventionally to identify the edition") and
>> example in the guidelines, which I suspect is the majority. (I haven't
>> used @ed very often, and certainly not very recently, but I don't recall
>> what I put in it. Probably not a pointer.)
>>
>> Not feeling strongly enough about this to shout if there is a clear
>> consensus for (b), however. :-)
>>
>> Gabby
>>
>> On 05/01/2013 14:00, Sebastian Rahtz wrote:
>>>
>>> On 5 Jan 2013, at 13:39, Gabriel Bodard
>>> wrote:
>>>
>>>> What about all the people who are now using @ed to contain a cRef like
>>>> string that "conventionally expresses" the edition that has a linebreak
>>>> at this point? (They should stop and start using a pointer instead of a
>>>> cRef, I agree, but backwards compatibility?)
>>>
>>> people who are currently saying
are pointing
>>> at a local file called "1665", though they realize it or not.
>>>
>>> the alternative is to change data.code to be simply text,
>>> but the consider the question on TEI-L, where the questioner
>>> asks where to define what @ed refers to.
>>>
>>> in fact, the _text_ about @ed really seems to suggest
>>> use of data.key ("the range of attribute values expressing a coded value by means of an arbitrary
>>> identifier, typically taken from a set of externally-defined possibilities")
>>>
>>> --
>>> 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
>>>
>>>
>>
--
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 mholmes at uvic.ca Sat Jan 5 17:09:52 2013
From: mholmes at uvic.ca (Martin Holmes)
Date: Sat, 5 Jan 2013 14:09:52 -0800
Subject: [tei-council] att.sourced () contradiction
In-Reply-To: <50E8A28C.1020709@kcl.ac.uk>
References:
<50E7A051.2040006@ultraslavonic.info>
<50E82CFD.1080101@kcl.ac.uk>
<993D356D-F447-4AD2-8B09-6942B65CCA0D@it.ox.ac.uk>
<50E895DC.8030705@kcl.ac.uk> <50E89EE3.8060700@uvic.ca>
<50E8A28C.1020709@kcl.ac.uk>
Message-ID: <50E8A4B0.6010605@uvic.ca>
Fair enough. I see so much abuse of data.pointer attributes that I guess
I've become immune to it; I've lost count of the number of times I've
said "you do know that this points to a file called xxxx which doesn't
exist, don't you?"
But the precedent of @lemma and @lemmaRef is a good one; that inclines
me towards solution c), adding @edRef, with a plan to deprecate @ed in
the long term.
Cheers,
Martin
On 13-01-05 02:00 PM, Gabriel Bodard wrote:
> But whether the file is technically valid or not is less of an issue as
> far as I'm concerned than whether a file uses the TEI correctly. There
> are all sorts of ways for a file to be valid but wrong (a pointer that
> has nothing at the target explaining what is in your markup). If @ed is
> defined to be a pointer to a description of the edition in question, and
> instead it is being treated as an arbitrary, conventional string, then
> even if the schema can't tell the difference that is a bigger kind of
> broken.
>
> The analogous case, for me, of an attribute that didn't get a strict
> pointer/valList datatype in P5, is @lemma, and there were have the
> parallel @lemmaRef for the case where someone wants to use it in the
> more strict way, so there's precedent for forking, I guess.
>
> G
>
> On 05/01/2013 21:45, Martin Holmes wrote:
>> If we do b), I don't think we'll actually break very much, will we? The
>> only case in which a currently-valid project would become invalid would
>> be where the identifiers happen to begin with a number. If that's only a
>> few cases, then it might be acceptable. Other cases where a cRef-style
>> identifier is used would be formally wrong (they would apparently point
>> to a file that didn't exist), but wouldn't show as invalid.
>>
>> Cheers,
>> Martin
>>
>> On 13-01-05 01:06 PM, Gabriel Bodard wrote:
>>> No I agree with you that a pointer makes sense, and of the three options
>>>
>>> a. define @ed to take text, like @cRef
>>> b. define @ed to be a pointer and take a uri
>>> c. fork @ed so we have ways to do both the above
>>>
>>> I like (a) the least. But I'm a bit torn between b. and c., simply
>>> because of all the people who have been misled by the text ("A string of
>>> characters or sigil used conventionally to identify the edition") and
>>> example in the guidelines, which I suspect is the majority. (I haven't
>>> used @ed very often, and certainly not very recently, but I don't recall
>>> what I put in it. Probably not a pointer.)
>>>
>>> Not feeling strongly enough about this to shout if there is a clear
>>> consensus for (b), however. :-)
>>>
>>> Gabby
>>>
>>> On 05/01/2013 14:00, Sebastian Rahtz wrote:
>>>>
>>>> On 5 Jan 2013, at 13:39, Gabriel Bodard
>>>> wrote:
>>>>
>>>>> What about all the people who are now using @ed to contain a cRef like
>>>>> string that "conventionally expresses" the edition that has a linebreak
>>>>> at this point? (They should stop and start using a pointer instead of a
>>>>> cRef, I agree, but backwards compatibility?)
>>>>
>>>> people who are currently saying
are pointing
>>>> at a local file called "1665", though they realize it or not.
>>>>
>>>> the alternative is to change data.code to be simply text,
>>>> but the consider the question on TEI-L, where the questioner
>>>> asks where to define what @ed refers to.
>>>>
>>>> in fact, the _text_ about @ed really seems to suggest
>>>> use of data.key ("the range of attribute values expressing a coded value by means of an arbitrary
>>>> identifier, typically taken from a set of externally-defined possibilities")
>>>>
>>>> --
>>>> 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 lou.burnard at retired.ox.ac.uk Sat Jan 5 17:10:00 2013
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Sat, 05 Jan 2013 22:10:00 +0000
Subject: [tei-council] att.sourced () contradiction
In-Reply-To: <50E8A28C.1020709@kcl.ac.uk>
References:
<50E7A051.2040006@ultraslavonic.info>
<50E82CFD.1080101@kcl.ac.uk>
<993D356D-F447-4AD2-8B09-6942B65CCA0D@it.ox.ac.uk>
<50E895DC.8030705@kcl.ac.uk> <50E89EE3.8060700@uvic.ca>
<50E8A28C.1020709@kcl.ac.uk>
Message-ID: <50E8A4B8.70606@retired.ox.ac.uk>
I think most people who actually use @ed are quite comfortable with the
idea of referring to an edition by means of a siglum such as "1815" or
"Blenkinsop" without any particular need to point to an explanation of
what that edition is. That's why it was originally defined in this way
at any rate. Insisting that it become a pointer seems a bit harsh to me.
So my vote is for (a).
On 05/01/13 22:00, Gabriel Bodard wrote:
> But whether the file is technically valid or not is less of an issue as
> far as I'm concerned than whether a file uses the TEI correctly. There
> are all sorts of ways for a file to be valid but wrong (a pointer that
> has nothing at the target explaining what is in your markup). If @ed is
> defined to be a pointer to a description of the edition in question, and
> instead it is being treated as an arbitrary, conventional string, then
> even if the schema can't tell the difference that is a bigger kind of
> broken.
>
> The analogous case, for me, of an attribute that didn't get a strict
> pointer/valList datatype in P5, is @lemma, and there were have the
> parallel @lemmaRef for the case where someone wants to use it in the
> more strict way, so there's precedent for forking, I guess.
>
> G
>
> On 05/01/2013 21:45, Martin Holmes wrote:
>> If we do b), I don't think we'll actually break very much, will we? The
>> only case in which a currently-valid project would become invalid would
>> be where the identifiers happen to begin with a number. If that's only a
>> few cases, then it might be acceptable. Other cases where a cRef-style
>> identifier is used would be formally wrong (they would apparently point
>> to a file that didn't exist), but wouldn't show as invalid.
>>
>> Cheers,
>> Martin
>>
>> On 13-01-05 01:06 PM, Gabriel Bodard wrote:
>>> No I agree with you that a pointer makes sense, and of the three options
>>>
>>> a. define @ed to take text, like @cRef
>>> b. define @ed to be a pointer and take a uri
>>> c. fork @ed so we have ways to do both the above
>>>
>>> I like (a) the least. But I'm a bit torn between b. and c., simply
>>> because of all the people who have been misled by the text ("A string of
>>> characters or sigil used conventionally to identify the edition") and
>>> example in the guidelines, which I suspect is the majority. (I haven't
>>> used @ed very often, and certainly not very recently, but I don't recall
>>> what I put in it. Probably not a pointer.)
>>>
>>> Not feeling strongly enough about this to shout if there is a clear
>>> consensus for (b), however. :-)
>>>
>>> Gabby
>>>
>>> On 05/01/2013 14:00, Sebastian Rahtz wrote:
>>>>
>>>> On 5 Jan 2013, at 13:39, Gabriel Bodard
>>>> wrote:
>>>>
>>>>> What about all the people who are now using @ed to contain a cRef like
>>>>> string that "conventionally expresses" the edition that has a linebreak
>>>>> at this point? (They should stop and start using a pointer instead of a
>>>>> cRef, I agree, but backwards compatibility?)
>>>>
>>>> people who are currently saying
are pointing
>>>> at a local file called "1665", though they realize it or not.
>>>>
>>>> the alternative is to change data.code to be simply text,
>>>> but the consider the question on TEI-L, where the questioner
>>>> asks where to define what @ed refers to.
>>>>
>>>> in fact, the _text_ about @ed really seems to suggest
>>>> use of data.key ("the range of attribute values expressing a coded value by means of an arbitrary
>>>> identifier, typically taken from a set of externally-defined possibilities")
>>>>
>>>> --
>>>> 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 Sat Jan 5 18:16:21 2013
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Sat, 5 Jan 2013 23:16:21 +0000
Subject: [tei-council] att.sourced () contradiction
In-Reply-To: <50E8A4B8.70606@retired.ox.ac.uk>
References:
<50E7A051.2040006@ultraslavonic.info>
<50E82CFD.1080101@kcl.ac.uk>
<993D356D-F447-4AD2-8B09-6942B65CCA0D@it.ox.ac.uk>
<50E895DC.8030705@kcl.ac.uk> <50E89EE3.8060700@uvic.ca>
<50E8A28C.1020709@kcl.ac.uk> <50E8A4B8.70606@retired.ox.ac.uk>
Message-ID: <82f98f9a-cc89-4320-b449-2cad019ee524@HUB04.ad.oak.ox.ac.uk>
On 5 Jan 2013, at 22:10, Lou Burnard
wrote:
> I think most people who actually use @ed are quite comfortable with the
> idea of referring to an edition by means of a siglum such as "1815" or
> "Blenkinsop" without any particular need to point to an explanation of
> what that edition is.
indeed. how do you answer Ant?nio Rito Silva, though? by adding edRef?
> That's why it was originally defined in this way
> at any rate. Insisting that it become a pointer seems a bit harsh to me.
well, except that it _is_ a pointer, and has been so for 4 years 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 gabriel.bodard at kcl.ac.uk Sat Jan 5 18:20:11 2013
From: gabriel.bodard at kcl.ac.uk (Gabriel Bodard)
Date: Sat, 5 Jan 2013 23:20:11 +0000
Subject: [tei-council] att.sourced () contradiction
In-Reply-To: <82f98f9a-cc89-4320-b449-2cad019ee524@HUB04.ad.oak.ox.ac.uk>
References:
<50E7A051.2040006@ultraslavonic.info>
<50E82CFD.1080101@kcl.ac.uk>
<993D356D-F447-4AD2-8B09-6942B65CCA0D@it.ox.ac.uk>
<50E895DC.8030705@kcl.ac.uk> <50E89EE3.8060700@uvic.ca>
<50E8A28C.1020709@kcl.ac.uk> <50E8A4B8.70606@retired.ox.ac.uk>
<82f98f9a-cc89-4320-b449-2cad019ee524@HUB04.ad.oak.ox.ac.uk>
Message-ID: <50E8B52B.4070406@kcl.ac.uk>
On 05/01/2013 23:16, Sebastian Rahtz wrote:
> indeed. how do you answer Ant?nio Rito Silva, though? by adding edRef?
One possibility. Or treating it like a key--a magic bullet.
Project-specific definition for how it relates to a bibliographical
entry in the header or elsewhere in the project documentation.
Adding @edRef seems nicer to me though. It has the advantage of keeping
@ed "dumb" while adding smartness, and parallels @lemma[Ref] nicely.
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 Sat Jan 5 18:22:57 2013
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Sat, 5 Jan 2013 23:22:57 +0000
Subject: [tei-council] att.sourced () contradiction
In-Reply-To: <82f98f9a-cc89-4320-b449-2cad019ee524@HUB04.ad.oak.ox.ac.uk>
References:
<50E7A051.2040006@ultraslavonic.info>
<50E82CFD.1080101@kcl.ac.uk>
<993D356D-F447-4AD2-8B09-6942B65CCA0D@it.ox.ac.uk>
<50E895DC.8030705@kcl.ac.uk> <50E89EE3.8060700@uvic.ca>
<50E8A28C.1020709@kcl.ac.uk> <50E8A4B8.70606@retired.ox.ac.uk>
<82f98f9a-cc89-4320-b449-2cad019ee524@HUB04.ad.oak.ox.ac.uk>
Message-ID: <673D6640-1C76-45A1-822C-5F8AA62D6CA0@it.ox.ac.uk>
I think I like GB's solution of adding a new @edRef attribute, deleting data.code, changing @ed to use data.key, and deprecating @ed. Its complicated,
but it does the least damage to existing practice (which has almost certainly followed the prose), while giving a proper solution to the Pessoa question.
--
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 Sat Jan 5 18:24:27 2013
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Sat, 5 Jan 2013 23:24:27 +0000
Subject: [tei-council] att.sourced () contradiction
In-Reply-To: <50E8B52B.4070406@kcl.ac.uk>
References:
<50E7A051.2040006@ultraslavonic.info>
<50E82CFD.1080101@kcl.ac.uk>
<993D356D-F447-4AD2-8B09-6942B65CCA0D@it.ox.ac.uk>
<50E895DC.8030705@kcl.ac.uk> <50E89EE3.8060700@uvic.ca>
<50E8A28C.1020709@kcl.ac.uk> <50E8A4B8.70606@retired.ox.ac.uk>
<82f98f9a-cc89-4320-b449-2cad019ee524@HUB04.ad.oak.ox.ac.uk>
<50E8B52B.4070406@kcl.ac.uk>
Message-ID: <04765FCD-9043-40AE-B448-7B268712AB6C@it.ox.ac.uk>
On 5 Jan 2013, at 23:20, Gabriel Bodard
wrote:
>
> Adding @edRef seems nicer to me though. It has the advantage of keeping
> @ed "dumb" while adding smartness, and parallels @lemma[Ref] nicely.
we shouldnt be using the existing @resp?
--
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 Sat Jan 5 18:26:28 2013
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Sat, 5 Jan 2013 23:26:28 +0000
Subject: [tei-council] description of @type's data values
In-Reply-To: <50E88ED8.9060409@uvic.ca>
References:
<50E59CC6.5050703@retired.ox.ac.uk>
<50E5D401.9010000@uvic.ca>
<50E88ED8.9060409@uvic.ca>
Message-ID: <88CF8458-FAEB-4535-8934-4C3CF09E52A1@it.ox.ac.uk>
On 5 Jan 2013, at 20:36, Martin Holmes
wrote:
>
> The challenge of checking a list of multiple pointers in Schematron is interesting. It might be possible to check pointers to @xml:ids inside the same file, but I don't think it's possible to check for the existence of a element in another file from inside a Schematron constraint, is it?
>
unless you can use the doc() function. which I doubt. and anyway, its not a fault if the URI is inaccessible at check time.
I think its fairly well accepted that you can't really validate a URI in all generality.
--
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 Sat Jan 5 18:27:31 2013
From: gabriel.bodard at kcl.ac.uk (Gabriel Bodard)
Date: Sat, 5 Jan 2013 23:27:31 +0000
Subject: [tei-council] att.sourced () contradiction
In-Reply-To: <04765FCD-9043-40AE-B448-7B268712AB6C@it.ox.ac.uk>
References:
<50E7A051.2040006@ultraslavonic.info>
<50E82CFD.1080101@kcl.ac.uk>
<993D356D-F447-4AD2-8B09-6942B65CCA0D@it.ox.ac.uk>
<50E895DC.8030705@kcl.ac.uk> <50E89EE3.8060700@uvic.ca>
<50E8A28C.1020709@kcl.ac.uk> <50E8A4B8.70606@retired.ox.ac.uk>
<82f98f9a-cc89-4320-b449-2cad019ee524@HUB04.ad.oak.ox.ac.uk>
<50E8B52B.4070406@kcl.ac.uk>
<04765FCD-9043-40AE-B448-7B268712AB6C@it.ox.ac.uk>
Message-ID: <50E8B6E3.6060308@kcl.ac.uk>
@resp is slightly different, isn't it? It's saying who made the encoding
decision to put an
tag here in the document. @ed is saying, this
is the edition in which (the current encoder asserts) a line begins here.
On 05/01/2013 23:24, Sebastian Rahtz wrote:
>
> On 5 Jan 2013, at 23:20, Gabriel Bodard
> wrote:
>
>>
>> Adding @edRef seems nicer to me though. It has the advantage of keeping
>> @ed "dumb" while adding smartness, and parallels @lemma[Ref] nicely.
>
>
> we shouldnt be using the existing @resp?
> --
> 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
>
>
--
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 kevin.s.hawkins at ultraslavonic.info Sat Jan 5 18:28:26 2013
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Sat, 05 Jan 2013 18:28:26 -0500
Subject: [tei-council] att.sourced () contradiction
In-Reply-To: <82f98f9a-cc89-4320-b449-2cad019ee524@HUB04.ad.oak.ox.ac.uk>
References:
<50E7A051.2040006@ultraslavonic.info>
<50E82CFD.1080101@kcl.ac.uk>
<993D356D-F447-4AD2-8B09-6942B65CCA0D@it.ox.ac.uk>
<50E895DC.8030705@kcl.ac.uk> <50E89EE3.8060700@uvic.ca>
<50E8A28C.1020709@kcl.ac.uk> <50E8A4B8.70606@retired.ox.ac.uk>
<82f98f9a-cc89-4320-b449-2cad019ee524@HUB04.ad.oak.ox.ac.uk>
Message-ID: <50E8B71A.4010706@ultraslavonic.info>
On 1/5/13 6:16 PM, Sebastian Rahtz wrote:
>> That's why it was originally defined in this way
>> at any rate. Insisting that it become a pointer seems a bit harsh to me.
>
> well, except that it _is_ a pointer, and has been so for 4 years now....
Given that the prose and the datatype of the attribute haven't matched
for four years, and given that validators don't resolve pointers, it
seems to me that if we don't want to create @edRef (as Gabby suggests),
we should revert the data type to match the prose.
However, I have no problem with the solution Gabby proposes. I am
generally well disposed to having parallel structures (in this case,
@lemma : @lemmaRef :: @ed : @edRef).
--K.
From Syd_Bauman at Brown.edu Sat Jan 5 19:21:41 2013
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Sat, 5 Jan 2013 19:21:41 -0500
Subject: [tei-council] att.sourced () contradiction
In-Reply-To: <50E8B71A.4010706@ultraslavonic.info>
References:
<50E7A051.2040006@ultraslavonic.info>
<50E82CFD.1080101@kcl.ac.uk>
<993D356D-F447-4AD2-8B09-6942B65CCA0D@it.ox.ac.uk>
<50E895DC.8030705@kcl.ac.uk> <50E89EE3.8060700@uvic.ca>
<50E8A28C.1020709@kcl.ac.uk> <50E8A4B8.70606@retired.ox.ac.uk>
<82f98f9a-cc89-4320-b449-2cad019ee524@HUB04.ad.oak.ox.ac.uk>
<50E8B71A.4010706@ultraslavonic.info>
Message-ID: <20712.50069.513046.773515@emt.ad.brown.edu>
The difference between data.code and data.pointer is that in some
previous (probably pre-release) iteration of P5, data.code was
intended to point to something *in the same file*, thus being a
mechanism for on-the-fly controlled vocabularies.
The TEI has (or at least had) 5 general-purpose mechanisms for
providing vocabularies for attribute values:
* list of values is supplied in the ODD (either TEI ODD, user's ODD,
or combination thereof) and thus the schema: data.enumerated.
* list of values is supplied in the instance file (typically in the
header): data.code.
* list of values is supplied in a specific external source:
data.language (which I think is only example of this at the moment,
since data.outputMeasurement and data.sex do not reference the
specs, but rather check for values themselves)
* list of values is supplied somewhere on the web: data.pointer.
* list of values is magically generated at run-time by the user, with
the algorithm supplied in a TEI-conformant way (@cRef) or some
other way, typically an index into an external database (@key).
I think Lou is right, most people who actually use @ed are perfectly
happy using a data.word-like string that everyone in their project
(sometimes in their entire field) recognizes immediately. IMHO,
that's an argument for this to be data.enumerated.
But I can see that a lot of folks would want to point from @ed to a
bibliographic entry for the particular edition. In which case
data.pointer seems reasonable. So I'm thinking (reiterating some of
this thread) we have three choices:
* change @ed to data.pointer, thus requiring (in some loose sense)
that the "Silver" edition be indicated with "#Silver" and that the
1674 edition be indicated with "#e1674" or some such. (But as has
been pointed out, many users obliviously point to non-existent
local files named "Silver" and "1674", and go on with their lives
quite happily.)
* change @ed to data.enumerated, and folks who want a bibliographic
description of their edition can put it inside the of the
appropriate .
* change @ed to data.enumerated, and provide @edRef as a
data.pointer.
I don't really see any place for data.text here.
From kevin.s.hawkins at ultraslavonic.info Sat Jan 5 19:34:18 2013
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Sat, 05 Jan 2013 19:34:18 -0500
Subject: [tei-council] Attributes without examples
In-Reply-To: <50DF3058.80508@retired.ox.ac.uk>
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>
<50DF3058.80508@retired.ox.ac.uk>
Message-ID: <50E8C68A.1050005@ultraslavonic.info>
On 12/29/12 1:03 PM, Lou Burnard wrote:
> 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. :-(
Okay, but do you agree with Sebastian that we shouldn't do it when
adding new examples?
I can of course tweak an example from the chapter before inserting into
the spec, but that feels silly. If that's all I'm doing, why not keep
the example as is (albeit without a mechanism to keep them in sync)?
From sebastian.rahtz at it.ox.ac.uk Sun Jan 6 10:56:09 2013
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Sun, 6 Jan 2013 15:56:09 +0000
Subject: [tei-council] att.sourced () contradiction
In-Reply-To: <20712.50069.513046.773515@emt.ad.brown.edu>
References:
<50E7A051.2040006@ultraslavonic.info>
<50E82CFD.1080101@kcl.ac.uk>
<993D356D-F447-4AD2-8B09-6942B65CCA0D@it.ox.ac.uk>
<50E895DC.8030705@kcl.ac.uk> <50E89EE3.8060700@uvic.ca>
<50E8A28C.1020709@kcl.ac.uk> <50E8A4B8.70606@retired.ox.ac.uk>
<82f98f9a-cc89-4320-b449-2cad019ee524@HUB04.ad.oak.ox.ac.uk>
<50E8B71A.4010706@ultraslavonic.info>
<20712.50069.513046.773515@emt.ad.brown.edu>
Message-ID: <2C15EA68-4B05-4600-BFB3-9A051085B1FD@it.ox.ac.uk>
Syd's useful analysis explains, I think, what happened. We set up data.code with the
intention of it being a special case of linking to a set of known values, but then
forgot the plan and made it a pointer instead.
>
> So I'm thinking (reiterating some of
> this thread) we have three choices:
>
> * change @ed to data.pointer,..
> * change @ed to data.enumerated
> * change @ed to data.enumerated, and provide @edRef as a
> data.pointer.
everyone who has spoken seems in favour of the last of these - any objections?
(though I think I'd say data.key not data.enumerated, as that seems to fit
the "everyone knows" case of "1661 edition" better)
--
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 lou.burnard at retired.ox.ac.uk Sun Jan 6 11:25:55 2013
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Sun, 06 Jan 2013 16:25:55 +0000
Subject: [tei-council] att.sourced () contradiction
In-Reply-To: <2C15EA68-4B05-4600-BFB3-9A051085B1FD@it.ox.ac.uk>
References:
<50E7A051.2040006@ultraslavonic.info>
<50E82CFD.1080101@kcl.ac.uk>
<993D356D-F447-4AD2-8B09-6942B65CCA0D@it.ox.ac.uk>
<50E895DC.8030705@kcl.ac.uk> <50E89EE3.8060700@uvic.ca>
<50E8A28C.1020709@kcl.ac.uk> <50E8A4B8.70606@retired.ox.ac.uk>
<82f98f9a-cc89-4320-b449-2cad019ee524@HUB04.ad.oak.ox.ac.uk>
<50E8B71A.4010706@ultraslavonic.info>
<20712.50069.513046.773515@emt.ad.brown.edu>
<2C15EA68-4B05-4600-BFB3-9A051085B1FD@it.ox.ac.uk>
Message-ID: <50E9A593.4080207@retired.ox.ac.uk>
On 06/01/13 15:56, Sebastian Rahtz wrote:
> Syd's useful analysis explains, I think, what happened. We set up data.code with the
> intention of it being a special case of linking to a set of known values, but then
> forgot the plan and made it a pointer instead.
I for one did not forget that data.code was meant not to be a pointer,
but I seem to remember being over-ruled!
>
>>
>> So I'm thinking (reiterating some of
>> this thread) we have three choices:
>>
>> * change @ed to data.pointer,..
>> * change @ed to data.enumerated
>> * change @ed to data.enumerated, and provide @edRef as a
>> data.pointer.
>
>
> everyone who has spoken seems in favour of the last of these - any objections?
data.enumerated is (as we agreed on a previous thread) constrained to be
an XML name so ed="1666" would actually be illegal.
> (though I think I'd say data.key not data.enumerated, as that seems to fit
> the "everyone knows" case of "1661 edition" better)
Yes, data.key probably has the right semantics here, although it doesn't
actually exist in the TEI any more. I seem to remember some inconclusive
argument about what the distinction between data.key and data.code
should be, but the only upshot seems to have been the abolition of
data.key and mass deployment of anyURI even in rather dubious contexts.
I think the answer is to change the datatype of data.code from anyURI
(which is silly) to data.text (which is painful, since it permits
blanks, but is consistent with what we currently do with @key)
Or (better) to reinvent data.key as something intermediate between
data.name and data.text
> --
> 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 Sun Jan 6 11:40:53 2013
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Sun, 6 Jan 2013 16:40:53 +0000
Subject: [tei-council] att.sourced () contradiction
In-Reply-To: <50E9A593.4080207@retired.ox.ac.uk>
References:
<50E7A051.2040006@ultraslavonic.info>
<50E82CFD.1080101@kcl.ac.uk>
<993D356D-F447-4AD2-8B09-6942B65CCA0D@it.ox.ac.uk>
<50E895DC.8030705@kcl.ac.uk> <50E89EE3.8060700@uvic.ca>
<50E8A28C.1020709@kcl.ac.uk> <50E8A4B8.70606@retired.ox.ac.uk>
<82f98f9a-cc89-4320-b449-2cad019ee524@HUB04.ad.oak.ox.ac.uk>
<50E8B71A.4010706@ultraslavonic.info>
<20712.50069.513046.773515@emt.ad.brown.edu>
<2C15EA68-4B05-4600-BFB3-9A051085B1FD@it.ox.ac.uk>
<50E9A593.4080207@retired.ox.ac.uk>
Message-ID: <607b3a5b-0a5e-4d06-beec-024478b1b852@HUB05.ad.oak.ox.ac.uk>
On 6 Jan 2013, at 16:25, Lou Burnard wrote:
>> Syd's useful analysis explains, I think, what happened. We set up data.code with the
>> intention of it being a special case of linking to a set of known values, but then
>> forgot the plan and made it a pointer instead.
>
> I for one did not forget that data.code was meant not to be a pointer,
> but I seem to remember being over-ruled!
I think I remember that discussion vaguely.....
> ...
> Yes, data.key probably has the right semantics here, although it doesn't
> actually exist in the TEI any more.
poor thing is still there, just unused by anyone
> I think the answer is to change the datatype of data.code from anyURI
> (which is silly) to data.text (which is painful, since it permits
> blanks, but is consistent with what we currently do with @key)
data.word covers this case already
>
> Or (better) to reinvent data.key as something intermediate between
> data.name and data.text
since data.code is not used anywhere except in att.sourced, and data.key is not used at all,
we can drop both of them in favour of data.word
--
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 Syd_Bauman at Brown.edu Sun Jan 6 12:52:36 2013
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Sun, 6 Jan 2013 12:52:36 -0500
Subject: [tei-council] att.sourced () contradiction
In-Reply-To: <607b3a5b-0a5e-4d06-beec-024478b1b852@HUB05.ad.oak.ox.ac.uk>
References:
<50E7A051.2040006@ultraslavonic.info>
<50E82CFD.1080101@kcl.ac.uk>
<993D356D-F447-4AD2-8B09-6942B65CCA0D@it.ox.ac.uk>
<50E895DC.8030705@kcl.ac.uk> <50E89EE3.8060700@uvic.ca>
<50E8A28C.1020709@kcl.ac.uk> <50E8A4B8.70606@retired.ox.ac.uk>
<82f98f9a-cc89-4320-b449-2cad019ee524@HUB04.ad.oak.ox.ac.uk>
<50E8B71A.4010706@ultraslavonic.info>
<20712.50069.513046.773515@emt.ad.brown.edu>
<2C15EA68-4B05-4600-BFB3-9A051085B1FD@it.ox.ac.uk>
<50E9A593.4080207@retired.ox.ac.uk>
<607b3a5b-0a5e-4d06-beec-024478b1b852@HUB05.ad.oak.ox.ac.uk>
Message-ID: <20713.47588.337416.135396@emt.ad.brown.edu>
The advantage of data.word is that a value could start with a digit
(like "1674"). The advantage of data.enumerated is that means the TEI
is saying (appropriately, I think) "you should document your set of
values in your ODD". Personally, I think the latter is more
important, but it also would break backwards compatibility, so I'm
thinking we should leave the official datatype as data.word, perhaps
with some sort of prose recommendation for defining a constrained
value list via in your ODD.
> since data.code is not used anywhere except in att.sourced, and
> data.key is not used at all, we can drop both of them in favour of
> data.word
From sebastian.rahtz at it.ox.ac.uk Sun Jan 6 13:57:30 2013
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Sun, 6 Jan 2013 18:57:30 +0000
Subject: [tei-council] att.sourced () contradiction
In-Reply-To: <20713.47588.337416.135396@emt.ad.brown.edu>
References:
<50E7A051.2040006@ultraslavonic.info>
<50E82CFD.1080101@kcl.ac.uk>
<993D356D-F447-4AD2-8B09-6942B65CCA0D@it.ox.ac.uk>
<50E895DC.8030705@kcl.ac.uk> <50E89EE3.8060700@uvic.ca>
<50E8A28C.1020709@kcl.ac.uk> <50E8A4B8.70606@retired.ox.ac.uk>
<82f98f9a-cc89-4320-b449-2cad019ee524@HUB04.ad.oak.ox.ac.uk>
<50E8B71A.4010706@ultraslavonic.info>
<20712.50069.513046.773515@emt.ad.brown.edu>
<2C15EA68-4B05-4600-BFB3-9A051085B1FD@it.ox.ac.uk>
<50E9A593.4080207@retired.ox.ac.uk>
<607b3a5b-0a5e-4d06-beec-024478b1b852@HUB05.ad.oak.ox.ac.uk>
<20713.47588.337416.135396@emt.ad.brown.edu>
Message-ID: <00D259E6-48C2-4729-9CDF-93F9B0576C9F@it.ox.ac.uk>
On 6 Jan 2013, at 17:52, Syd Bauman
wrote:
> The advantage of data.word is that a value could start with a digit
> (like "1674"). The advantage of data.enumerated is that means the TEI
> is saying (appropriately, I think) "you should document your set of
> values in your ODD".
really? surely the ODD is designed for the project level, while this information
is for the document level. In my ODD I set up documented lists of (eg)
the values I use for @type, but do I really embed in my schema the fact that
for this one of document (of many in my set) I want to use "1661" and "1671" as
values for lb/@ed? those seem like things I'll list in my header, not my schema.
--
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 lou.burnard at retired.ox.ac.uk Sun Jan 6 14:08:33 2013
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Sun, 06 Jan 2013 19:08:33 +0000
Subject: [tei-council] att.sourced () contradiction
In-Reply-To: <20713.47588.337416.135396@emt.ad.brown.edu>
References:
<50E7A051.2040006@ultraslavonic.info>
<50E82CFD.1080101@kcl.ac.uk>
<993D356D-F447-4AD2-8B09-6942B65CCA0D@it.ox.ac.uk>
<50E895DC.8030705@kcl.ac.uk> <50E89EE3.8060700@uvic.ca>
<50E8A28C.1020709@kcl.ac.uk> <50E8A4B8.70606@retired.ox.ac.uk>
<82f98f9a-cc89-4320-b449-2cad019ee524@HUB04.ad.oak.ox.ac.uk>
<50E8B71A.4010706@ultraslavonic.info>
<20712.50069.513046.773515@emt.ad.brown.edu>
<2C15EA68-4B05-4600-BFB3-9A051085B1FD@it.ox.ac.uk>
<50E9A593.4080207@retired.ox.ac.uk>
<607b3a5b-0a5e-4d06-beec-024478b1b852@HUB05.ad.oak.ox.ac.uk>
<20713.47588.337416.135396@emt.ad.brown.edu>
Message-ID: <50E9CBB1.1090307@retired.ox.ac.uk>
Not sure about that. Some TEI datatypes provide both information about
both what sort of value this is and also how it should be used.
data.enumerated, for example says "the value should (actually or
potentially) come from a fixed list of possible values". It also says
"the value looks like an XML name". If we found a way of implementing
enumerations which didn't need the additional constraint of being a
name, then we'd change the mapping of data.enumerated
Simly, I think I'd prefer to retain (or reinsert) data.key for its
ability to say "this is an identifier of some non-pointerly kind that
everyone recognizes" distinct from data.word -- the latter (analogously
to data.name) provides only information that this thing has certain
syntactic constraints.
On 06/01/13 17:52, Syd Bauman wrote:
> The advantage of data.word is that a value could start with a digit
> (like "1674"). The advantage of data.enumerated is that means the TEI
> is saying (appropriately, I think) "you should document your set of
> values in your ODD". Personally, I think the latter is more
> important, but it also would break backwards compatibility, so I'm
> thinking we should leave the official datatype as data.word, perhaps
> with some sort of prose recommendation for defining a constrained
> value list via in your ODD.
>
>
>> since data.code is not used anywhere except in att.sourced, and
>> data.key is not used at all, we can drop both of them in favour of
>> data.word
From lou.burnard at retired.ox.ac.uk Sun Jan 6 14:11:11 2013
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Sun, 06 Jan 2013 19:11:11 +0000
Subject: [tei-council] att.sourced () contradiction
In-Reply-To: <00D259E6-48C2-4729-9CDF-93F9B0576C9F@it.ox.ac.uk>
References:
<50E7A051.2040006@ultraslavonic.info>
<50E82CFD.1080101@kcl.ac.uk>
<993D356D-F447-4AD2-8B09-6942B65CCA0D@it.ox.ac.uk>
<50E895DC.8030705@kcl.ac.uk> <50E89EE3.8060700@uvic.ca>
<50E8A28C.1020709@kcl.ac.uk> <50E8A4B8.70606@retired.ox.ac.uk>
<82f98f9a-cc89-4320-b449-2cad019ee524@HUB04.ad.oak.ox.ac.uk>
<50E8B71A.4010706@ultraslavonic.info>
<20712.50069.513046.773515@emt.ad.brown.edu>
<2C15EA68-4B05-4600-BFB3-9A051085B1FD@it.ox.ac.uk>
<50E9A593.4080207@retired.ox.ac.uk>
<607b3a5b-0a5e-4d06-beec-024478b1b852@HUB05.ad.oak.ox.ac.uk>
<20713.47588.337416.135396@emt.ad.brown.edu>
<00D259E6-48C2-4729-9CDF-93F9B0576C9F@it.ox.ac.uk>
Message-ID: <50E9CC4F.20501@retired.ox.ac.uk>
On 06/01/13 18:57, Sebastian Rahtz wrote:
>
> On 6 Jan 2013, at 17:52, Syd Bauman
> wrote:
>
>> The advantage of data.word is that a value could start with a digit
>> (like "1674"). The advantage of data.enumerated is that means the TEI
>> is saying (appropriately, I think) "you should document your set of
>> values in your ODD".
>
> really? surely the ODD is designed for the project level, while this information
> is for the document level. In my ODD I set up documented lists of (eg)
> the values I use for @type, but do I really embed in my schema the fact that
> for this one of document (of many in my set) I want to use "1661" and "1671" as
> values for lb/@ed? those seem like things I'll list in my header, not my schema.
Surely both are plausible ?
However, I agree that enumerations are not *necessarily* provided in
your ODD. They might well be documented in a corpus or text header. But
that really is a project-specific choice.
From sebastian.rahtz at it.ox.ac.uk Sun Jan 6 16:26:54 2013
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Sun, 6 Jan 2013 21:26:54 +0000
Subject: [tei-council] att.sourced () contradiction
In-Reply-To: <50E9CC4F.20501@retired.ox.ac.uk>
References:
<50E7A051.2040006@ultraslavonic.info>
<50E82CFD.1080101@kcl.ac.uk>
<993D356D-F447-4AD2-8B09-6942B65CCA0D@it.ox.ac.uk>
<50E895DC.8030705@kcl.ac.uk> <50E89EE3.8060700@uvic.ca>
<50E8A28C.1020709@kcl.ac.uk> <50E8A4B8.70606@retired.ox.ac.uk>
<82f98f9a-cc89-4320-b449-2cad019ee524@HUB04.ad.oak.ox.ac.uk>
<50E8B71A.4010706@ultraslavonic.info>
<20712.50069.513046.773515@emt.ad.brown.edu>
<2C15EA68-4B05-4600-BFB3-9A051085B1FD@it.ox.ac.uk>
<50E9A593.4080207@retired.ox.ac.uk>
<607b3a5b-0a5e-4d06-beec-024478b1b852@HUB05.ad.oak.ox.ac.uk>
<20713.47588.337416.135396@emt.ad.brown.edu>
<00D259E6-48C2-4729-9CDF-93F9B0576C9F@it.ox.ac.uk>
<50E9CC4F.20501@retired.ox.ac.uk>
Message-ID: <54b36d17-62c4-4bc7-9879-04171e14c8d1@HUB02.ad.oak.ox.ac.uk>
On 6 Jan 2013, at 19:11, Lou Burnard wrote:
> However, I agree that enumerations are not *necessarily* provided in
> your ODD. They might well be documented in a corpus or text header. But
> that really is a project-specific choice.
James will tell us that the ODD can be embedded in the header, so you can
can have your cake and eat it :-}
--
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 Sun Jan 6 16:37:20 2013
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Sun, 6 Jan 2013 21:37:20 +0000
Subject: [tei-council] att.sourced () contradiction
In-Reply-To: <50E9CBB1.1090307@retired.ox.ac.uk>
References:
<50E7A051.2040006@ultraslavonic.info>
<50E82CFD.1080101@kcl.ac.uk>
<993D356D-F447-4AD2-8B09-6942B65CCA0D@it.ox.ac.uk>
<50E895DC.8030705@kcl.ac.uk> <50E89EE3.8060700@uvic.ca>
<50E8A28C.1020709@kcl.ac.uk> <50E8A4B8.70606@retired.ox.ac.uk>
<82f98f9a-cc89-4320-b449-2cad019ee524@HUB04.ad.oak.ox.ac.uk>
<50E8B71A.4010706@ultraslavonic.info>
<20712.50069.513046.773515@emt.ad.brown.edu>
<2C15EA68-4B05-4600-BFB3-9A051085B1FD@it.ox.ac.uk>
<50E9A593.4080207@retired.ox.ac.uk>
<607b3a5b-0a5e-4d06-beec-024478b1b852@HUB05.ad.oak.ox.ac.uk>
<20713.47588.337416.135396@emt.ad.brown.edu>
<50E9CBB1.1090307@retired.ox.ac.uk>
Message-ID:
On 6 Jan 2013, at 19:08, Lou Burnard wrote:
> data.enumerated, for example says "the value should (actually or
> potentially) come from a fixed list of possible values". It also says
> "the value looks like an XML name". If we found a way of implementing
> enumerations which didn't need the additional constraint of being a
> name, then we'd change the mapping of data.enumerated
why do we still have that restriction, I wonder? it used to be, I think,
'cos we had that restriction on valItem/@ident, but that is no longer the case.
what would go wrong if we said data.enumerated used data.word instead
of data.name?
apologies if we've had this discussion in the past and I have forgot.
>
> Simly, I think I'd prefer to retain (or reinsert) data.key for its
> ability to say "this is an identifier of some non-pointerly kind that
> everyone recognizes" distinct from data.word -- the latter (analogously
> to data.name) provides only information that this thing has certain
> syntactic constraints.
you can have data.key, pointing to data.word, as a specialization;
just as data.enumerated points at data.name now.
so we might do the following:
- change @ed to be data.key or data.enumerated (I vote for key myself, but am not wedded to it)
- zap data.code
- change data.enumerated to point to data.word
- add @edRef, using data.pointer
--
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 lou.burnard at retired.ox.ac.uk Sun Jan 6 16:46:00 2013
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Sun, 06 Jan 2013 21:46:00 +0000
Subject: [tei-council] att.sourced () contradiction
In-Reply-To: <6CAE525B-5E4F-4E81-BB8A-F215547CBE1E@it.ox.ac.uk>
References:
<50E7A051.2040006@ultraslavonic.info>
<50E82CFD.1080101@kcl.ac.uk>
<993D356D-F447-4AD2-8B09-6942B65CCA0D@it.ox.ac.uk>
<50E895DC.8030705@kcl.ac.uk> <50E89EE3.8060700@uvic.ca>
<50E8A28C.1020709@kcl.ac.uk> <50E8A4B8.70606@retired.ox.ac.uk>
<82f98f9a-cc89-4320-b449-2cad019ee524@HUB04.ad.oak.ox.ac.uk>
<50E8B71A.4010706@ultraslavonic.info>
<20712.50069.513046.773515@emt.ad.brown.edu>
<2C15EA68-4B05-4600-BFB3-9A051085B1FD@it.ox.ac.uk>
<50E9A593.4080207@retired.ox.ac.uk>
<607b3a5b-0a5e-4d06-beec-024478b1b852@HUB05.ad.oak.ox.ac.uk>
<20713.47588.337416.135396@emt.ad.brown.edu>
<50E9CBB1.1090307@retired.ox.ac.uk>
<6CAE525B-5E4F-4E81-BB8A-F215547CBE1E@it.ox.ac.uk>
Message-ID: <50E9F098.3060603@retired.ox.ac.uk>
On 06/01/13 21:37, Sebastian Rahtz wrote:
>
> On 6 Jan 2013, at 19:08, Lou Burnard wrote:
>
>> data.enumerated, for example says "the value should (actually or
>> potentially) come from a fixed list of possible values". It also says
>> "the value looks like an XML name". If we found a way of implementing
>> enumerations which didn't need the additional constraint of being a
>> name, then we'd change the mapping of data.enumerated
>
> why do we still have that restriction, I wonder? it used to be, I think,
> 'cos we had that restriction on valItem/@ident, but that is no longer the case.
yes, I'd forgotten that in a weak moment we allowed valItem/ident to
become just text!
> what would go wrong if we said data.enumerated used data.word instead
> of data.name?
all those people who insisted on using spaces within @ident values would
get v. cross ?
>
> apologies if we've had this discussion in the past and I have forgot.
good thing we have this tracker system eh
>>
From sebastian.rahtz at it.ox.ac.uk Sun Jan 6 16:49:25 2013
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Sun, 6 Jan 2013 21:49:25 +0000
Subject: [tei-council] att.sourced () contradiction
In-Reply-To: <50E9F098.3060603@retired.ox.ac.uk>
References:
<50E7A051.2040006@ultraslavonic.info>
<50E82CFD.1080101@kcl.ac.uk>
<993D356D-F447-4AD2-8B09-6942B65CCA0D@it.ox.ac.uk>
<50E895DC.8030705@kcl.ac.uk> <50E89EE3.8060700@uvic.ca>
<50E8A28C.1020709@kcl.ac.uk> <50E8A4B8.70606@retired.ox.ac.uk>
<82f98f9a-cc89-4320-b449-2cad019ee524@HUB04.ad.oak.ox.ac.uk>
<50E8B71A.4010706@ultraslavonic.info>
<20712.50069.513046.773515@emt.ad.brown.edu>
<2C15EA68-4B05-4600-BFB3-9A051085B1FD@it.ox.ac.uk>
<50E9A593.4080207@retired.ox.ac.uk>
<607b3a5b-0a5e-4d06-beec-024478b1b852@HUB05.ad.oak.ox.ac.uk>
<20713.47588.337416.135396@emt.ad.brown.edu>
<50E9CBB1.1090307@retired.ox.ac.uk>
<6CAE525B-5E4F-4E81-BB8A-F215547CBE1E@it.ox.ac.uk>
<50E9F098.3060603@retired.ox.ac.uk>
Message-ID: <4cc8632e-b774-40e9-a9e6-0ca7064856b8@HUB06.ad.oak.ox.ac.uk>
On 6 Jan 2013, at 21:46, Lou Burnard
wrote:
>
>> what would go wrong if we said data.enumerated used data.word instead
>> of data.name?
>
> all those people who insisted on using spaces within @ident values would get v. cross ?
>
this would not affect them. if you make a with /@ident s which has
spaces, then your datatype is no longer data.enumerated. But that is true already. We
would _extend_ the number of people who could keep using data.enumerated,
as would now allow in the "1671" crowd (louche lot that they are).
--
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 rwelzenbach at gmail.com Mon Jan 7 09:15:44 2013
From: rwelzenbach at gmail.com (Rebecca Welzenbach)
Date: Mon, 7 Jan 2013 09:15:44 -0500
Subject: [tei-council] Guidelines Ch. 6
Message-ID:
Hi all,
I've been reading Chapter 6, which overall seems to be in really good
shape--extremely thorough examples and very clearly written. One bit
that gives me pause is below.
In 6.1 there is an example:
In the first year of Freedom's second dawn
Died George the Third; although no tyrant, one
Who shielded tyrants, till each sense withdrawn
Left him nor mental nor external sun:
A better farmer ne'er brushed dew from lawn,
A worse king never left a realm undone!
He died ? but left his subjects still behind,
One half as mad ? and t'other no less blind.
Followed by some commentary:
"Note the use of the type attribute to name the type of unit encoded
by the lg element; this attribute is common to all members of the
att.divLikeclass (see section 4.1.1 Un-numbered Divisions). ?Sestet?
and ?couplet? might conceivably also be used as the values of the
rhyme attribute in an analysis of rhyme scheme, for which see below,
section 6.3 Rhyme and Metrical Analysis. The type attribute is
intended solely for conventional names of different classes of text
block; the met attribute is intended for systematic metrical
analysis."
I'm not convinced that 'sestet' and 'couplet' are on their own viable
values for @rhyme. These terms simply define how many lines are in a
group. While there are conventions/implications about what this means
for rhyme in certain kinds of poetry, they do not explicitly document
a rhyme scheme, which is the purpose of @rhyme. If others agree, I
propose the following revision:
"Note the use of the type attribute to name the type of unit encoded
by the lg element; this attribute is common to all members of the
att.divLikeclass (see section 4.1.1 Un-numbered Divisions). When used
on , the type attribute is intended solely for conventional names
of different classes of text block. For systematic analysis of
metrical and rhyme schemes, use the met and rhyme attributes, for
which see below, section 6.3 Rhyme and Metrical Analysis."
Or maybe I'm wrong: would 'sestet' and 'couplet' become meaningful
values for @rhyme if (and perhaps only if) a specific rhyme scheme
corresponding to each were defined in ? In this case, my
proposed revision to the text is still correct, but the original could
stay as it is.
Becky
From mholmes at uvic.ca Mon Jan 7 11:47:44 2013
From: mholmes at uvic.ca (Martin Holmes)
Date: Mon, 7 Jan 2013 08:47:44 -0800
Subject: [tei-council] Guidelines Ch. 6
In-Reply-To:
References:
Message-ID: <50EAFC30.10400@uvic.ca>
I think I'm with you on this. Rhyme schemes are variable in sestets
(according to Wikipedia: ), so it
makes no sense to characterize a rhyme scheme using "sestet".
Cheers,
Martin
On 13-01-07 06:15 AM, Rebecca Welzenbach wrote:
> Hi all,
>
> I've been reading Chapter 6, which overall seems to be in really good
> shape--extremely thorough examples and very clearly written. One bit
> that gives me pause is below.
>
> In 6.1 there is an example:
>
>
>
> In the first year of Freedom's second dawn
> Died George the Third; although no tyrant, one
> Who shielded tyrants, till each sense withdrawn
> Left him nor mental nor external sun:
> A better farmer ne'er brushed dew from lawn,
> A worse king never left a realm undone!
>
>
> He died ? but left his subjects still behind,
> One half as mad ? and t'other no less blind.
>
>
>
> Followed by some commentary:
> "Note the use of the type attribute to name the type of unit encoded
> by the lg element; this attribute is common to all members of the
> att.divLikeclass (see section 4.1.1 Un-numbered Divisions). ?Sestet?
> and ?couplet? might conceivably also be used as the values of the
> rhyme attribute in an analysis of rhyme scheme, for which see below,
> section 6.3 Rhyme and Metrical Analysis. The type attribute is
> intended solely for conventional names of different classes of text
> block; the met attribute is intended for systematic metrical
> analysis."
>
> I'm not convinced that 'sestet' and 'couplet' are on their own viable
> values for @rhyme. These terms simply define how many lines are in a
> group. While there are conventions/implications about what this means
> for rhyme in certain kinds of poetry, they do not explicitly document
> a rhyme scheme, which is the purpose of @rhyme. If others agree, I
> propose the following revision:
>
> "Note the use of the type attribute to name the type of unit encoded
> by the lg element; this attribute is common to all members of the
> att.divLikeclass (see section 4.1.1 Un-numbered Divisions). When used
> on , the type attribute is intended solely for conventional names
> of different classes of text block. For systematic analysis of
> metrical and rhyme schemes, use the met and rhyme attributes, for
> which see below, section 6.3 Rhyme and Metrical Analysis."
>
> Or maybe I'm wrong: would 'sestet' and 'couplet' become meaningful
> values for @rhyme if (and perhaps only if) a specific rhyme scheme
> corresponding to each were defined in ? In this case, my
> proposed revision to the text is still correct, but the original could
> stay as it is.
>
> Becky
>
--
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)
From lou.burnard at retired.ox.ac.uk Mon Jan 7 11:57:56 2013
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Mon, 07 Jan 2013 16:57:56 +0000
Subject: [tei-council] Guidelines Ch. 6
In-Reply-To: <50EAFC30.10400@uvic.ca>
References:
<50EAFC30.10400@uvic.ca>
Message-ID: <50EAFE94.5080802@retired.ox.ac.uk>
Well, to defend this apparent oddity, in this particular case, the
ottavarima, as practiced by Byron at least, it *does* make sense to talk
of the sestet and the couplet, and the rhyming structure is completely
regular within that structure. So I can see why the author of this piece
might propose using these as values for @rhyme, to avoid the tedium of
saying "ABABAB" for the former and "CC" for the latter (vel sim). And a
"couplet" is always a pair of lines which rhyme, not just a pair of lines.
However, I have no problem with Becky's revision, which leaves this
whole question (rightly) under specified.
On 07/01/13 16:47, Martin Holmes wrote:
> I think I'm with you on this. Rhyme schemes are variable in sestets
> (according to Wikipedia: ), so it
> makes no sense to characterize a rhyme scheme using "sestet".
>
> Cheers,
> Martin
>
> On 13-01-07 06:15 AM, Rebecca Welzenbach wrote:
>> Hi all,
>>
>> I've been reading Chapter 6, which overall seems to be in really good
>> shape--extremely thorough examples and very clearly written. One bit
>> that gives me pause is below.
>>
>> In 6.1 there is an example:
>>
>>
>>
>> In the first year of Freedom's second dawn
>> Died George the Third; although no tyrant, one
>> Who shielded tyrants, till each sense withdrawn
>> Left him nor mental nor external sun:
>> A better farmer ne'er brushed dew from lawn,
>> A worse king never left a realm undone!
>>
>>
>> He died ? but left his subjects still behind,
>> One half as mad ? and t'other no less blind.
>>
>>
>>
>> Followed by some commentary:
>> "Note the use of the type attribute to name the type of unit encoded
>> by the lg element; this attribute is common to all members of the
>> att.divLikeclass (see section 4.1.1 Un-numbered Divisions). ?Sestet?
>> and ?couplet? might conceivably also be used as the values of the
>> rhyme attribute in an analysis of rhyme scheme, for which see below,
>> section 6.3 Rhyme and Metrical Analysis. The type attribute is
>> intended solely for conventional names of different classes of text
>> block; the met attribute is intended for systematic metrical
>> analysis."
>>
>> I'm not convinced that 'sestet' and 'couplet' are on their own viable
>> values for @rhyme. These terms simply define how many lines are in a
>> group. While there are conventions/implications about what this means
>> for rhyme in certain kinds of poetry, they do not explicitly document
>> a rhyme scheme, which is the purpose of @rhyme. If others agree, I
>> propose the following revision:
>>
>> "Note the use of the type attribute to name the type of unit encoded
>> by the lg element; this attribute is common to all members of the
>> att.divLikeclass (see section 4.1.1 Un-numbered Divisions). When used
>> on , the type attribute is intended solely for conventional names
>> of different classes of text block. For systematic analysis of
>> metrical and rhyme schemes, use the met and rhyme attributes, for
>> which see below, section 6.3 Rhyme and Metrical Analysis."
>>
>> Or maybe I'm wrong: would 'sestet' and 'couplet' become meaningful
>> values for @rhyme if (and perhaps only if) a specific rhyme scheme
>> corresponding to each were defined in ? In this case, my
>> proposed revision to the text is still correct, but the original could
>> stay as it is.
>>
>> Becky
>>
>
From mholmes at uvic.ca Mon Jan 7 18:27:16 2013
From: mholmes at uvic.ca (Martin Holmes)
Date: Mon, 7 Jan 2013 15:27:16 -0800
Subject: [tei-council] My tickets
Message-ID: <50EB59D4.6000300@uvic.ca>
Hi all,
I think I've now completed all tickets assigned to me that should be
done before the upcoming release. There are two exceptions:
which I think should be obviated by Lou's work on this one:
Lou, could you confirm?
I also still have this one outstanding:
which is the one about adding "tei_" to all anchors and their
corresponding links inside the web version of the Guidelines. I had one
shot at this a few months ago and failed, but I'm not giving up, and
James promised to take a look at it and help. Since screwing it up is
potentially so disastrous, though, I don't propose to take it on in the
run-up to a release.
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 8 04:15:05 2013
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Tue, 08 Jan 2013 09:15:05 +0000
Subject: [tei-council] My tickets
In-Reply-To: <50EB59D4.6000300@uvic.ca>
References: <50EB59D4.6000300@uvic.ca>
Message-ID: <50EBE399.1030002@retired.ox.ac.uk>
On 07/01/13 23:27, Martin Holmes wrote:
> There are two exceptions:
>
>
>
> which I think should be obviated by Lou's work on this one:
>
>
>
> Lou, could you confirm?
>
Yes, was planning to update that ticket accordingly, but ran out of
steam dealing with the long overdue att.fragmentable last night
> I also still have this one outstanding:
>
>
>
> which is the one about adding "tei_" to all anchors and their
> corresponding links inside the web version of the Guidelines. I had one
> shot at this a few months ago and failed, but I'm not giving up, and
> James promised to take a look at it and help. Since screwing it up is
> potentially so disastrous, though, I don't propose to take it on in the
> run-up to a release.
hear hear
From James.Cummings at it.ox.ac.uk Tue Jan 8 07:04:59 2013
From: James.Cummings at it.ox.ac.uk (James Cummings)
Date: Tue, 08 Jan 2013 12:04:59 +0000
Subject: [tei-council] TEI2013: Programme Committee
Message-ID: <50EC0B6B.7090003@it.ox.ac.uk>
Hi all,
The TEI Technical Council usually has a representative on the
TEI2013 Programme Committee. While it isn't necessary for it to
be someone who will be attending, it is beneficial IMHO. I happen
to know already that I'll be unable to attend this year's
Conference and so feel that someone else should be on the
Programme Committee this year.
If you think you might be able to attend the TEI2013 conference,
happening in Italy in early October, and are interested in being
the Council's representative to the TEI2013 Programme Committee
please let me know. I'll pass the first name I get on to the board.
Best wishes,
-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 Tue Jan 8 07:06:24 2013
From: James.Cummings at it.ox.ac.uk (James Cummings)
Date: Tue, 08 Jan 2013 12:06:24 +0000
Subject: [tei-council] My tickets
In-Reply-To: <50EBE399.1030002@retired.ox.ac.uk>
References: <50EB59D4.6000300@uvic.ca> <50EBE399.1030002@retired.ox.ac.uk>
Message-ID: <50EC0BC0.40204@it.ox.ac.uk>
>> I also still have this one outstanding:
>>
>>
>>
>> which is the one about adding "tei_" to all anchors and their
>> corresponding links inside the web version of the Guidelines. I had one
>> shot at this a few months ago and failed, but I'm not giving up, and
>> James promised to take a look at it and help. Since screwing it up is
>> potentially so disastrous, though, I don't propose to take it on in the
>> run-up to a release.
> hear hear
I'd agree with that. Although the problem may still exist it is
best to get any solution to it solid.
-James
--
Dr James Cummings, James.Cummings at it.ox.ac.uk
Academic IT Services, University of Oxford
From gabriel.bodard at kcl.ac.uk Tue Jan 8 08:40:05 2013
From: gabriel.bodard at kcl.ac.uk (Gabriel Bodard)
Date: Tue, 8 Jan 2013 13:40:05 +0000
Subject: [tei-council] TEI2013: Programme Committee
In-Reply-To: <50EC0B6B.7090003@it.ox.ac.uk>
References: <50EC0B6B.7090003@it.ox.ac.uk>
Message-ID: <50EC21B5.8030503@kcl.ac.uk>
I'm only 75% likely to go to Rome, but if no one more certain signs up
in the meantime I'm happy to help with this.
G
On 2013-01-08 12:04, James Cummings wrote:
> Hi all,
>
> The TEI Technical Council usually has a representative on the
> TEI2013 Programme Committee. While it isn't necessary for it to
> be someone who will be attending, it is beneficial IMHO. I happen
> to know already that I'll be unable to attend this year's
> Conference and so feel that someone else should be on the
> Programme Committee this year.
>
> If you think you might be able to attend the TEI2013 conference,
> happening in Italy in early October, and are interested in being
> the Council's representative to the TEI2013 Programme Committee
> please let me know. I'll pass the first name I get on to the board.
>
> Best wishes,
>
> -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 sebastian.rahtz at it.ox.ac.uk Tue Jan 8 09:09:31 2013
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Tue, 8 Jan 2013 14:09:31 +0000
Subject: [tei-council] TEI2013: Programme Committee
In-Reply-To: <50EC0B6B.7090003@it.ox.ac.uk>
References: <50EC0B6B.7090003@it.ox.ac.uk>
Message-ID: <9e5c02c4-4419-4c36-ac11-975b3dccd168@HUB02.ad.oak.ox.ac.uk>
If its in Rome, I will go even if I have to pay for it myself and take holiday. So I could do if needed
Sent from my iPad
On 8 Jan 2013, at 12:05, "James Cummings" wrote:
> Hi all,
>
> The TEI Technical Council usually has a representative on the
> TEI2013 Programme Committee. While it isn't necessary for it to
> be someone who will be attending, it is beneficial IMHO. I happen
> to know already that I'll be unable to attend this year's
> Conference and so feel that someone else should be on the
> Programme Committee this year.
>
> If you think you might be able to attend the TEI2013 conference,
> happening in Italy in early October, and are interested in being
> the Council's representative to the TEI2013 Programme Committee
> please let me know. I'll pass the first name I get on to the board.
>
> Best wishes,
>
> -James
>
> --
> Dr James Cummings, James.Cummings at it.ox.ac.uk
> Academic 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
From sebastian.rahtz at it.ox.ac.uk Tue Jan 8 10:28:03 2013
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Tue, 8 Jan 2013 15:28:03 +0000
Subject: [tei-council] the word according to John
Message-ID: <527F1FDD-98A3-485D-BFE3-B862B7EC12DE@it.ox.ac.uk>
Lovely quote from an SF ticket comment by John M:
"?.reminding them that examples in the Guidelines often assume
particular downstream processing that is nowhere documented.
That is: Use these examples to guide your own practice, but -- secret of
secrets -- be sure the consumers of your TEI file process whitespace the
way the examples presume they will. What exactly that is, is for you to
figure out. Case by case. Good luck."
--
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 Jan 8 12:13:11 2013
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Tue, 8 Jan 2013 17:13:11 +0000
Subject: [tei-council] attribute names used in classes which are duplicated
on elements
Message-ID: <078B8ED1-305F-459C-BDD8-29E5273C33AD@it.ox.ac.uk>
As per FR 3567935, I have compiled a catalogue at
of all the cases where an attribute name defined in a class is also used on an element.
This happens 49 times. Each of them needs examining to see whether they can now be
replaced with class membership and local override of the given attribute.
you can see the catalogue as an editable spreadsheet at https://docs.google.com/spreadsheet/ccc?key=0AhciBT9b4XaZdEQ1bmZ6emF0ck9GQU9sWDlFSlRkUFE
(and with better formatting and links at http://tei.oucs.ox.ac.uk/duplatts.html).
this raises many questions. A simple one:
/@ref is pretty much the same as att.canonical/@ref, but if we
add to att.canonical, it gains @key as well. Is that a
Good Thing or a Bad Thing? obviously we can have the status quo,
by adding to
I think I could go ahead and do 90% of these myself by common sense, but
thats not sensible :-}. I suggest that we use that spreadsheet
to look at some of these cases and add a decision/recommendation/vote
to the first column. choices may be:
easy: make all elements members of class
hard: make elements members of class, but with adjustments (i.e. only having some attributes from class, overriding description)
harder: some elements only, needs careful thought
impossible: the attributes are definitely not the same beast
I have some suggestions already
Then at a second stage someone can go in and action each case.
--
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 Jan 8 12:16:28 2013
From: James.Cummings at it.ox.ac.uk (James Cummings)
Date: Tue, 08 Jan 2013 17:16:28 +0000
Subject: [tei-council] TEI2013: Programme Committee
In-Reply-To: <0C86FD9F-5BBD-45B7-B10F-05AEFAACCBE2@it.ox.ac.uk>
References: <50EC0B6B.7090003@it.ox.ac.uk>
<0C86FD9F-5BBD-45B7-B10F-05AEFAACCBE2@it.ox.ac.uk>
Message-ID: <50EC546C.50504@it.ox.ac.uk>
This sounds like a winner to me. I'll be forwarding Sebastian's
name to the Board for inclusion on the committee.
-James
On 08/01/13 14:09, Sebastian Rahtz wrote:
> If its in Rome, I will go even if I have to pay for it myself and take holiday. So I could do if needed
>
> Sent from my iPad
>
> On 8 Jan 2013, at 12:05, "James Cummings" wrote:
>
>> Hi all,
>>
>> The TEI Technical Council usually has a representative on the
>> TEI2013 Programme Committee. While it isn't necessary for it to
>> be someone who will be attending, it is beneficial IMHO. I happen
>> to know already that I'll be unable to attend this year's
>> Conference and so feel that someone else should be on the
>> Programme Committee this year.
>>
>> If you think you might be able to attend the TEI2013 conference,
>> happening in Italy in early October, and are interested in being
>> the Council's representative to the TEI2013 Programme Committee
>> please let me know. I'll pass the first name I get on to the board.
>>
>> Best wishes,
>>
>> -James
>>
>> --
>> Dr James Cummings, James.Cummings at it.ox.ac.uk
>> Academic 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
--
Dr James Cummings, James.Cummings at it.ox.ac.uk
Academic IT Services, University of Oxford
From kevin.s.hawkins at ultraslavonic.info Tue Jan 8 12:52:53 2013
From: kevin.s.hawkins at ultraslavonic.info (Kevin Hawkins)
Date: Tue, 08 Jan 2013 12:52:53 -0500
Subject: [tei-council] attribute names used in classes which are
duplicated on elements
In-Reply-To: <078B8ED1-305F-459C-BDD8-29E5273C33AD@it.ox.ac.uk>
References: <078B8ED1-305F-459C-BDD8-29E5273C33AD@it.ox.ac.uk>
Message-ID: <50EC5CF5.6070709@ultraslavonic.info>
On 1/8/2013 12:13 PM, Sebastian Rahtz wrote:
> As per FR 3567935, I have compiled a catalogue at
> of all the cases where an attribute name defined in a class is also used on an element.
> This happens 49 times. Each of them needs examining to see whether they can now be
> replaced with class membership and local override of the given attribute.
>
> you can see the catalogue as an editable spreadsheet at https://docs.google.com/spreadsheet/ccc?key=0AhciBT9b4XaZdEQ1bmZ6emF0ck9GQU9sWDlFSlRkUFE
> (and with better formatting and links at http://tei.oucs.ox.ac.uk/duplatts.html).
>
> this raises many questions. A simple one:
>
> /@ref is pretty much the same as att.canonical/@ref, but if we
> add to att.canonical, it gains @key as well. Is that a
> Good Thing or a Bad Thing? obviously we can have the status quo,
> by adding to
If I understand correctly, these sorts of questions are not included in
your spreadsheet and have to be discovered by looking at each element in
column D, and seeing whether it lacks any of the attributes that come
along with those in the class in column B. And then we decide whether
we think it's good to add those attributes, keep them out using
mode="delete", or not use the class at all.
> I think I could go ahead and do 90% of these myself by common sense, but
> thats not sensible :-}. I suggest that we use that spreadsheet
> to look at some of these cases and add a decision/recommendation/vote
> to the first column. choices may be:
>
> easy: make all elements members of class
> hard: make elements members of class, but with adjustments (i.e. only having some attributes from class, overriding description)
> harder: some elements only, needs careful thought
> impossible: the attributes are definitely not the same beast
>
> I have some suggestions already
Since you've added your suggestions there already, I guess we need to
put "SR: " in front of each and then let people add their own votes on
separate lines in each cell in column A.
> Then at a second stage someone can go in and action each case.
For each "hard" we're going to have to decide which attributes will be
included and which will have mode="delete". And for each "harder",
we're going to have to say which elements will get the membership class.
So I feel that these two labels won't actually help us reach consensus
on these questions, and in fact, if two people choosing one of these
labels are assuming different sets of attributes or elements to be
affected, we might have less consensus than it appears.
In short, I feel we need a different method to tackle this problem. Do
we dare create a ticket for each row in the table and let people propose
and discuss how to handle the affected elements and attributes?
K.
From sebastian.rahtz at it.ox.ac.uk Tue Jan 8 13:07:02 2013
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Tue, 8 Jan 2013 18:07:02 +0000
Subject: [tei-council] attribute names used in classes which are
duplicated on elements
In-Reply-To: <50EC5CF5.6070709@ultraslavonic.info>
References: <078B8ED1-305F-459C-BDD8-29E5273C33AD@it.ox.ac.uk>
<50EC5CF5.6070709@ultraslavonic.info>
Message-ID: <3E4F2AA0-6CB1-47D2-A766-45EB8F2036D5@it.ox.ac.uk>
On 8 Jan 2013, at 17:52, Kevin Hawkins
wrote:
>> /@ref is pretty much the same as att.canonical/@ref, but if we
>> add to att.canonical, it gains @key as well. Is that a
>> Good Thing or a Bad Thing? obviously we can have the status quo,
>> by adding to
>
> If I understand correctly, these sorts of questions are not included in
> your spreadsheet and have to be discovered by looking at each element in
> column D, and seeing whether it lacks any of the attributes that come
> along with those in the class in column B. And then we decide whether
> we think it's good to add those attributes, keep them out using
> mode="delete", or not use the class at all.
correct. thats what I am imagining you doing
>>
>> I have some suggestions already
>
> Since you've added your suggestions there already, I guess we need to
> put "SR: " in front of each and then let people add their own votes on
> separate lines in each cell in column A.
well, I'd say thats over-problematizing it. just override my suggestion
if its wrong. i honestly doubt we'll fight over it. just add more prose
as needed.
>
>> Then at a second stage someone can go in and action each case.
>
> For each "hard" we're going to have to decide which attributes will be
> included and which will have mode="delete". And for each "harder",
> we're going to have to say which elements will get the membership class.
yup.
and the cases where the description needs a local override.
> So I feel that these two labels won't actually help us reach consensus
> on these questions, and in fact, if two people choosing one of these
> labels are assuming different sets of attributes or elements to be
> affected, we might have less consensus than it appears.
i'd say just write prose in column A to make clear what the status
is, as much as is needed.
>
> In short, I feel we need a different method to tackle this problem. Do
> we dare create a ticket for each row in the table and let people propose
> and discuss how to handle the affected elements and attributes?
>
please god no. 150 extra tickets in SF? oh how I hate using that clumsy system.
honest, I claim its easier than you think to sort most of these. @type
will take a month of someone's life one day, however,
--
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 Jan 8 13:14:02 2013
From: gabriel.bodard at kcl.ac.uk (Gabriel Bodard)
Date: Tue, 8 Jan 2013 18:14:02 +0000
Subject: [tei-council] attribute names used in classes which are
duplicated on elements
In-Reply-To: <3E4F2AA0-6CB1-47D2-A766-45EB8F2036D5@it.ox.ac.uk>
References: <078B8ED1-305F-459C-BDD8-29E5273C33AD@it.ox.ac.uk>
<50EC5CF5.6070709@ultraslavonic.info>
<3E4F2AA0-6CB1-47D2-A766-45EB8F2036D5@it.ox.ac.uk>
Message-ID: <50EC61EA.30602@kcl.ac.uk>
On 2013-01-08 18:07, Sebastian Rahtz wrote:
> On 8 Jan 2013, at 17:52, Kevin Hawkins
> wrote:
>> In short, I feel we need a different method to tackle this problem. Do
>> we dare create a ticket for each row in the table and let people propose
>> and discuss how to handle the affected elements and attributes?
>>
> please god no. 150 extra tickets in SF? oh how I hate using that clumsy system.
>
> honest, I claim its easier than you think to sort most of these. @type
> will take a month of someone's life one day, however,
I agree. Most of these can be settled by one person looking at them and
making a decision/recommendation. The few that remain (even if that's a
dozen or more) could conceivably be ticketed (in groups or singly), but
only when we're tried and failed to resolve them in this way.
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 Tue Jan 8 13:15:01 2013
From: mholmes at uvic.ca (Martin Holmes)
Date: Tue, 8 Jan 2013 10:15:01 -0800
Subject: [tei-council] attribute names used in classes which are
duplicated on elements
In-Reply-To: <078B8ED1-305F-459C-BDD8-29E5273C33AD@it.ox.ac.uk>
References: <078B8ED1-305F-459C-BDD8-29E5273C33AD@it.ox.ac.uk>
Message-ID: <50EC6225.9080409@uvic.ca>
Hi there,
On 13-01-08 09:13 AM, Sebastian Rahtz wrote:
> As per FR 3567935, I have compiled a catalogue at
> of all the cases where an attribute name defined in a class is also used on an element.
> This happens 49 times. Each of them needs examining to see whether they can now be
> replaced with class membership and local override of the given attribute.
>
> you can see the catalogue as an editable spreadsheet at https://docs.google.com/spreadsheet/ccc?key=0AhciBT9b4XaZdEQ1bmZ6emF0ck9GQU9sWDlFSlRkUFE
> (and with better formatting and links at http://tei.oucs.ox.ac.uk/duplatts.html).
>
> this raises many questions. A simple one:
>
> /@ref is pretty much the same as att.canonical/@ref, but if we
> add to att.canonical, it gains @key as well. Is that a
> Good Thing or a Bad Thing? obviously we can have the status quo,
> by adding to
I don't think we should add @key to anything, given that we're thinking
of deprecating it.
> I think I could go ahead and do 90% of these myself by common sense, but
> thats not sensible :-}. I suggest that we use that spreadsheet
> to look at some of these cases and add a decision/recommendation/vote
> to the first column. choices may be:
>
> easy: make all elements members of class
> hard: make elements members of class, but with adjustments (i.e. only having some attributes from class, overriding description)
> harder: some elements only, needs careful thought
> impossible: the attributes are definitely not the same beast
>
> I have some suggestions already
>
> Then at a second stage someone can go in and action each case.
One question I raised on the ticket was that with @type and @target,
more than one class exists. Should we be aiming to collapse those
classes into one?
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 Jan 8 13:21:32 2013
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Tue, 8 Jan 2013 18:21:32 +0000
Subject: [tei-council] attribute names used in classes which are
duplicated on elements
In-Reply-To: <50EC6225.9080409@uvic.ca>
References: <078B8ED1-305F-459C-BDD8-29E5273C33AD@it.ox.ac.uk>
<50EC6225.9080409@uvic.ca>
Message-ID:
On 8 Jan 2013, at 18:15, Martin Holmes
wrote:
>> /@ref is pretty much the same as att.canonical/@ref, but if we
>> add to att.canonical, it gains @key as well. Is that a
>> Good Thing or a Bad Thing? obviously we can have the status quo,
>> by adding to
>
> I don't think we should add @key to anything, given that we're thinking
> of deprecating it.
>
but when we do so, we'll deprecate it in att. canonical,
so it will apply to everyone. arguably more honest.
>> Then at a second stage someone can go in and action each case.
>
> One question I raised on the ticket was that with @type and @target,
> more than one class exists. Should we be aiming to collapse those
> classes into one?
at first blush, simply too hard, IMHO
we can either
a) do the simpler cases first, and leave @type
or
b) tackle @type head on and clean up others at leisure
my innate laziness suggests a), but b) is equally sensible.
--
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 Jan 8 13:35:42 2013
From: mholmes at uvic.ca (Martin Holmes)
Date: Tue, 8 Jan 2013 10:35:42 -0800
Subject: [tei-council] attribute names used in classes which are
duplicated on elements
In-Reply-To:
References: <078B8ED1-305F-459C-BDD8-29E5273C33AD@it.ox.ac.uk>
<50EC6225.9080409@uvic.ca>
Message-ID: <50EC66FE.8030405@uvic.ca>
On 13-01-08 10:21 AM, Sebastian Rahtz wrote:
>
> On 8 Jan 2013, at 18:15, Martin Holmes
> wrote:
>>> /@ref is pretty much the same as att.canonical/@ref, but if we
>>> add to att.canonical, it gains @key as well. Is that a
>>> Good Thing or a Bad Thing? obviously we can have the status quo,
>>> by adding to
>>
>> I don't think we should add @key to anything, given that we're thinking
>> of deprecating it.
>>
> but when we do so, we'll deprecate it in att. canonical,
> so it will apply to everyone. arguably more honest.
True, but in the meantime we'd be providing a new opportunity for people
to use @key in a new context, only to deprecate it soon after.
>>> Then at a second stage someone can go in and action each case.
>>
>> One question I raised on the ticket was that with @type and @target,
>> more than one class exists. Should we be aiming to collapse those
>> classes into one?
>
> at first blush, simply too hard, IMHO
>
> we can either
>
> a) do the simpler cases first, and leave @type
> or
> b) tackle @type head on and clean up others at leisure
>
> my innate laziness suggests a), but b) is equally sensible.
+1 for laziness and low-hanging fruit. I think @type is a different
species of problem, to be honest. I've always felt that @type and
@subtype should be generic attributes with no suggested values in
att.global, and where we're inclined to suggest or prescribe values, a
separate attribute should be created with a more precise name --
list/@format, factuality/@value, or whatever.
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 lou.burnard at retired.ox.ac.uk Tue Jan 8 15:57:47 2013
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Tue, 08 Jan 2013 20:57:47 +0000
Subject: [tei-council] attribute names used in classes which are
duplicated on elements
In-Reply-To: <50EC66FE.8030405@uvic.ca>
References: <078B8ED1-305F-459C-BDD8-29E5273C33AD@it.ox.ac.uk>
<50EC6225.9080409@uvic.ca>
<50EC66FE.8030405@uvic.ca>
Message-ID: <50EC884B.7030507@retired.ox.ac.uk>
On 08/01/13 18:35, Martin Holmes wrote:
>
> On 13-01-08 10:21 AM, Sebastian Rahtz wrote:
>> On 8 Jan 2013, at 18:15, Martin Holmes
>> wrote:
>>>> /@ref is pretty much the same as att.canonical/@ref, but if we
>>>> add to att.canonical, it gains @key as well. Is that a
>>>> Good Thing or a Bad Thing? obviously we can have the status quo,
>>>> by adding to
>>> I don't think we should add @key to anything, given that we're thinking
>>> of deprecating it.
>>>
>> but when we do so, we'll deprecate it in att. canonical,
>> so it will apply to everyone. arguably more honest.
> True, but in the meantime we'd be providing a new opportunity for people
> to use @key in a new context, only to deprecate it soon after.
Maybe we might revise our view on the heinousness of @key ? (cf recent
discussion about lb/@ed)
From mholmes at uvic.ca Tue Jan 8 17:32:54 2013
From: mholmes at uvic.ca (Martin Holmes)
Date: Tue, 8 Jan 2013 14:32:54 -0800
Subject: [tei-council] attribute names used in classes which are
duplicated on elements
In-Reply-To: <50EC884B.7030507@retired.ox.ac.uk>
References: <078B8ED1-305F-459C-BDD8-29E5273C33AD@it.ox.ac.uk>
<50EC6225.9080409@uvic.ca>
<50EC66FE.8030405@uvic.ca>
<50EC884B.7030507@retired.ox.ac.uk>
Message-ID: <50EC9E96.2040603@uvic.ca>
On 13-01-08 12:57 PM, Lou Burnard wrote:
> On 08/01/13 18:35, Martin Holmes wrote:
>>
>> On 13-01-08 10:21 AM, Sebastian Rahtz wrote:
>>> On 8 Jan 2013, at 18:15, Martin Holmes
>>> wrote:
>>>>> /@ref is pretty much the same as att.canonical/@ref, but if we
>>>>> add to att.canonical, it gains @key as well. Is that a
>>>>> Good Thing or a Bad Thing? obviously we can have the status quo,
>>>>> by adding to
>>>> I don't think we should add @key to anything, given that we're thinking
>>>> of deprecating it.
>>>>
>>> but when we do so, we'll deprecate it in att. canonical,
>>> so it will apply to everyone. arguably more honest.
>> True, but in the meantime we'd be providing a new opportunity for people
>> to use @key in a new context, only to deprecate it soon after.
>
> Maybe we might revise our view on the heinousness of @key ? (cf recent
> discussion about lb/@ed)
I don't think I'm going to revise my view, to be honest. I don't think
it's heinous; I just think better options exist (private uri schemes +
dereferencing mechanisms), and I think that as we're continually
expanding the TEI in response to needs, we should also be trying to
deprecate and eventually remove cruft.
The discussion of lb/@ed concluded that we should keep @ed for backwards
compatibility, but add @edRef because it's better; then eventually we
can deprecate @ed too.
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 Jan 8 17:43:51 2013
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Tue, 8 Jan 2013 22:43:51 +0000
Subject: [tei-council] lb/@ed agayne
Message-ID:
I'd like to invoke the "you have 48 hours to say nay" convention on lb/@ed
my proposed plan of action if there is no protest is
1. make data.code have the same datatype as data.word
2. add @edRef to att.sourced, with the data.pointer datatype
with appropriate examples added for @edRef.
would it be sensible for the example @edRef to point to a ?
--
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 Jan 8 18:28:04 2013
From: mholmes at uvic.ca (Martin Holmes)
Date: Tue, 8 Jan 2013 15:28:04 -0800
Subject: [tei-council] lb/@ed agayne
In-Reply-To:
References:
Message-ID: <50ECAB84.9040508@uvic.ca>
Shouldn't @edRef be one-to-infinity data.pointers?
Cheers,
Martin
On 13-01-08 02:43 PM, Sebastian Rahtz wrote:
> I'd like to invoke the "you have 48 hours to say nay" convention on lb/@ed
>
> my proposed plan of action if there is no protest is
>
> 1. make data.code have the same datatype as data.word
> 2. add @edRef to att.sourced, with the data.pointer datatype
>
> with appropriate examples added for @edRef.
>
> would it be sensible for the example @edRef to point to a ?
> --
> 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 Jan 8 18:44:07 2013
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Tue, 8 Jan 2013 23:44:07 +0000
Subject: [tei-council] lb/@ed agayne
In-Reply-To: <50ECAB84.9040508@uvic.ca>
References:
<50ECAB84.9040508@uvic.ca>
Message-ID:
On 8 Jan 2013, at 23:28, Martin Holmes
wrote:
> Shouldn't @edRef be one-to-infinity data.pointers?
>
sorry, yes, I assumed that
--
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 Jan 9 10:42:49 2013
From: James.Cummings at it.ox.ac.uk (James Cummings)
Date: Wed, 09 Jan 2013 15:42:49 +0000
Subject: [tei-council] lb/@ed agayne
In-Reply-To:
References:
Message-ID: <50ED8FF9.7030007@it.ox.ac.uk>
For the record I agree with this.
(While silence provides assumed consent, active agreement is
allowed and reinforces that we agree ;-) )
-James
On 08/01/13 22:43, Sebastian Rahtz wrote:
> I'd like to invoke the "you have 48 hours to say nay" convention on lb/@ed
>
> my proposed plan of action if there is no protest is
>
> 1. make data.code have the same datatype as data.word
> 2. add @edRef to att.sourced, with the data.pointer datatype
>
> with appropriate examples added for @edRef.
>
> would it be sensible for the example @edRef to point to a ?
--
Dr James Cummings, James.Cummings at it.ox.ac.uk
Academic IT Services, University of Oxford
From mholmes at uvic.ca Wed Jan 9 12:06:48 2013
From: mholmes at uvic.ca (Martin Holmes)
Date: Wed, 9 Jan 2013 09:06:48 -0800
Subject: [tei-council] lb/@ed agayne
In-Reply-To: <50ED8FF9.7030007@it.ox.ac.uk>
References:
<50ED8FF9.7030007@it.ox.ac.uk>
Message-ID: <50EDA3A8.101@uvic.ca>
+1 from me. I see no reason why @edRef shouldn't point to a .
Cheers,
Martin
On 13-01-09 07:42 AM, James Cummings wrote:
>
> For the record I agree with this.
>
> (While silence provides assumed consent, active agreement is
> allowed and reinforces that we agree ;-) )
>
> -James
>
> On 08/01/13 22:43, Sebastian Rahtz wrote:
>> I'd like to invoke the "you have 48 hours to say nay" convention on lb/@ed
>>
>> my proposed plan of action if there is no protest is
>>
>> 1. make data.code have the same datatype as data.word
>> 2. add @edRef to att.sourced, with the data.pointer datatype
>>
>> with appropriate examples added for @edRef.
>>
>> would it be sensible for the example @edRef to point to a ?
>
--
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)
From mholmes at uvic.ca Wed Jan 9 12:23:37 2013
From: mholmes at uvic.ca (Martin Holmes)
Date: Wed, 9 Jan 2013 09:23:37 -0800
Subject: [tei-council] Please weigh in on this debate
Message-ID: <50EDA799.5020202@uvic.ca>
Hi all,
Lou and I are having a discussion on this ticket:
and I'd like to get some other people to provide input on it. Could you
take a look, and comment if you can?
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 Jan 9 13:13:20 2013
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Wed, 09 Jan 2013 18:13:20 +0000
Subject: [tei-council] lb/@ed agayne
In-Reply-To: <50ED8FF9.7030007@it.ox.ac.uk>
References:
<50ED8FF9.7030007@it.ox.ac.uk>
Message-ID: <50EDB340.9050002@retired.ox.ac.uk>
On 08/01/13 22:43, Sebastian Rahtz wrote:
>> I'd like to invoke the "you have 48 hours to say nay" convention on lb/@ed
>>
>> my proposed plan of action if there is no protest is
>>
>> 1. make data.code have the same datatype as data.word
does this mean
(a) replace the definition for data.code (currently "anyURI")
with that for data,word (currently a rather hairy regexp)
(b) replace the reference to "anyURI" with a reference to data.word
(c) replace the definition for @ed (currently a reference to
data.code) with a reference to data.word
I think I would vote for (c) or (b) but not for (a)
>> 2. add @edRef to att.sourced, with the data.pointer datatype
>>
>> with appropriate examples added for @edRef.
> would it be sensible for the example @edRef to point to a ?
No objection to that ... (assuming that this is not another case for the
attribute which is not @corresp)
From sebastian.rahtz at it.ox.ac.uk Wed Jan 9 15:23:06 2013
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Wed, 9 Jan 2013 20:23:06 +0000
Subject: [tei-council] lb/@ed agayne
In-Reply-To: <50EDB340.9050002@retired.ox.ac.uk>
References:
<50ED8FF9.7030007@it.ox.ac.uk> <50EDB340.9050002@retired.ox.ac.uk>
Message-ID:
On 9 Jan 2013, at 18:13, Lou Burnard wrote:
> does this mean
>
> (a) replace the definition for data.code (currently "anyURI")
> with that for data,word (currently a rather hairy regexp)
> (b) replace the reference to "anyURI" with a reference to data.word
> (c) replace the definition for @ed (currently a reference to
> data.code) with a reference to data.word
>
> I think I would vote for (c) or (b) but not for (a)
well, actually, I was thinking of (a), in order to preserve the singular
characteristics of data.code. but I have switched to (b), which has the same
outcome
>>> with appropriate examples added for @edRef.
>
>> would it be sensible for the example @edRef to point to a ?
>
> No objection to that ... (assuming that this is not another case for the
> attribute which is not @corresp)
ah well, not sure we want to go into the many very similar
but slightly variants of the "attribute which points at
something sourcelike".....
changes duly committed to att.sourced
--
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 Syd_Bauman at Brown.edu Thu Jan 10 09:35:58 2013
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Thu, 10 Jan 2013 09:35:58 -0500
Subject: [tei-council] TEI2013: Programme Committee
In-Reply-To: <9e5c02c4-4419-4c36-ac11-975b3dccd168@HUB02.ad.oak.ox.ac.uk>
References: <50EC0B6B.7090003@it.ox.ac.uk>
<9e5c02c4-4419-4c36-ac11-975b3dccd168@HUB02.ad.oak.ox.ac.uk>
Message-ID: <20718.53710.69059.927777@emt.ad.brown.edu>
I'll throw a bid in for next year, then. :-)
(I was on the programme committee every year from 2002 to 2010,
IIRC, so a few years away is not a bad idea.)
From sebastian.rahtz at it.ox.ac.uk Thu Jan 10 09:37:30 2013
From: sebastian.rahtz at it.ox.ac.uk (Sebastian Rahtz)
Date: Thu, 10 Jan 2013 14:37:30 +0000
Subject: [tei-council] another High Noon proposal
Message-ID: <455304B0-EC01-4903-A4FA-24D43AF6CF9B@it.ox.ac.uk>
with regard to the new element (http://bits.nsms.ox.ac.uk:8080/jenkins/job/TEIP5/lastSuccessfulBuild/artifact/release/doc/tei-p5-doc/en/html/ref-media.html)
I propose to
- make mimeType mandatory
- change the examples of @type to use @mimeType (and associated prose)
- move all those attributes to a class (from media, graphic, binary object) called att. graphical
why not @type? because I think thats not specific enough. I want to force people to say
what this beast is
any anti-votes?
--
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 Jan 10 09:44:52 2013
From: lou.burnard at retired.ox.ac.uk (Lou Burnard)
Date: Thu, 10 Jan 2013 14:44:52 +0000
Subject: [tei-council] another High Noon proposal
In-Reply-To: <455304B0-EC01-4903-A4FA-24D43AF6CF9B@it.ox.ac.uk>
References: <455304B0-EC01-4903-A4FA-24D43AF6CF9B@it.ox.ac.uk>
Message-ID: