[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