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

Sun Dec 22 14:03:50 EST 2013

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
>>