[tei-council] P5 source, modifying class atts at the base level.

Lou Burnard lou.burnard at retired.ox.ac.uk
Fri Sep 30 07:25:42 EDT 2011


On 30/09/11 11:40, Sebastian Rahtz wrote:
>
> On 30 Sep 2011, at 10:42, Lou Burnard wrote:
>
>
> I can see why you say this, but its quite a change in direction? I see c. 129
> <valList>s in the sources, 63 of them closed. You seriously suggest we
> abandon these?

Well, I wasn't suggesting abandoning any thing that's already in place, 
of course. I am a bit surprised there are so many closed lists though. 
One thing we might consider for P6 is a review of how many of them might 
be better done as new elements.


>
> I personally think we should expand, not reduce, the number of closed
> valLists, because I am less keen on the  Classic TEI Thousand Flowers Blooming
> vagueness :-}

That is one extreme: the other is that nobody can possibly use the TEI 
because it is too prescriptive/anglocentric etc.

>
>>
>> We could certainly consider adding some other syntactic mechanism to
>> achieve the same goal, as you suggest, by using mode="change". But I
>> think that somewhat confuses the issue. Either this attribute is a
>> member of the class or it isn't. If it is, then changing it anywhere
>> affects all instances equally: that's what being a member of a class
>> means. Or it isn't, in which case we cannot be "changing" it here, but
>> rather adding a different one which happens to have the same name
>> (that's the current way of doing it).
>>
>> If we're really dissatisfied with the status quo, I'd say a different
>> value for @mode ("override"?) would be much clearer. But I'm still
>> unconvinced.
>
> I see what you mean about the semantics of mode="change", but surely
> this is what we do in our local ODD all the time? we give div/@type a closed
> <valList>, but we're not stopping it being a member of att.typed, are we?


As you have repeatedly pointed out, what we do in a local ODD is not the 
same as what we do in the TEI Guidelines ODD. And yes we are stopping it 
being a member of att.typed in the sense that we are redefining what 
that means -- specifically what attributes it has. Does "being a member 
of att.typed" actually mean anything at all, except "has these 
attributes"? Not as far as processing document instances is concerned 
certainly !


More information about the tei-council mailing list