[tei-council] list types and rends: bug 460

Sun Dec 22 14:13:11 EST 2013

Yes, it might be worth exploring this distinction in the Guidelines, 
giving contrasting examples of it done both ways and noting that the 
<label> approach is required if you want to capture errors in the original.

I've also been thinking about how the question of whether a list can 
reallyl be ordered depends in part on whether you are transcribing a 
source document (as we generally assume in TEI) or you are composing 
something brand new in TEI (as we've tried to support since P5 was 
released).  In other words, when you identify a list in a source 
document, it has inherent ordering, but when you create your own list, 
you may want to assert that the list you are creating has no order (even 
though the act of writing requires that you impose an order when putting 
it in a document).

--Kevin

On 12/22/2013 2:03 PM, Martin Holmes wrote:
> Thinking more about this, there is some apparent inconsistency in my
> position:
>
> On the one hand, I'm arguing that "1", "2", "3" etc. shouldn't appear in
> @n if they appear in the original text, because transcribed text
> shouldn't be put into attributes;
>
> On the other hand, I'm arguing that<list rend="numbered">  should be
> used to represent a list which appears with numbers in front of the items.
>
> But there is some method in this. If the transcriber's view is that the
> numerical or bullet-like symbols decorating the items are in textual --
> in other words, part of the transcription -- then they can use<label>
> to capture them. If they believe that the decorations are non-textual
> (in the same way that indents, margins, italics and other such features
> are non-textual -- maybe supra-textual?), and that they are
> typographically consistent, then they can be represented using @rend.
> This is a useful distinction. It's interesting that if you create a list
> in HTML and set it to list-style-type: decimal, then copy-paste the list
> from your browser, the numbers will not be included in the paste.
>
> Cheers,
> Martin
>
> On 13-12-22 10:45 AM, Martin Holmes wrote:
>> On 13-12-22 10:12 AM, Sebastian Rahtz wrote:
>>>
>>> On 22 Dec 2013, at 17:54, Martin Holmes<mholmes at uvic.ca>  wrote:
>>>> I see nothing in the definition of @n which suggests it's intended for transcribing things that actually appear in the text:
>>>>
>>>> <http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-att.global.html#tei_att.n>
>>>>
>>>> Are there other instances in which we ask people to put transcribed text into attributes? I thought the war on attributes was supposed to eliminate this sort of thing entirely. It seems especially bad when<label>  is sitting there for precisely this purpose.
>>>
>>> if you want a glorious example of our madness, look at att.global.xml:
>>>
>>>                  <bibl n="   1">
>>>                  <bibl n="   2">
>>>                  <bibl n="   3”>
>>>
>>> what on earth are those spaces/tabs doing in @n, I wonder??
>>
>> That is very hideous. I couldn't bear it so I've removed them. But even
>> more amusing is the following French example, in which although the
>> nasty @n attributes remain, the @xml:base attribute which is supposed to
>> be the point of the example has been deleted. Urg. Should I make up a
>> phony @xml:base for that one?
>>
>>
>>> but consider these:
>>>
>>>              <divGen n="Index Nominum" type="NAMES"/>
>>>              <divGen n="Index Rerum" type="THINGS”/>
>>>
>>> what is “Index Rerum” if not literal text? mind you, that suggests to me that<divGen>  should support<head>.
>>
>>
>> I've always assumed that divGen is most likely to be used to create a
>> modern, external list of contents, rather than to hopefully reconstruct
>> programmatically something that appears in the original text; my
>> experience with original TOCs is that they're inevitably inconsistent or
>> idiosyncratic, and it would be impractical to try to reconstruct them
>> mechanically.
>>
>>>
>>> @n "gives a number (or other label) for an element”, which surely is something that should have been killed the The Attribute Wat.
>>
>> I have no objection to its being used to provide a label, but not when
>> that label is in the original text.
>>
>> Cheers,
>> Martin
>>
>>> --
>>> Sebastian Rahtz
>>> Director (Research) of Academic IT
>>> University of Oxford IT Services
>>> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>>>