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

[Martin Holmes]

On 13-12-22 11:13 AM, Kevin Hawkins wrote:
> 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.

Definitely. I think that section might expand a bit.

The other thing that strikes me is that, given the lengths we go to to 
exemplify the specialities of glossary lists, why is there no 
<listGloss> to go along with <listPerson> et al? Does anyone remember?

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

The whole idea of an unordered list is fascinating. Imagine if the 
Stylesheets, on being presented with a <soCalled>unordered</soCalled> 
list, randomly shuffled its items before rendering them? I bet everyone 
would scream. 99% of the time, what people mean is "give me bullets".

Cheers,
Martin

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