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

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


Coincidentally, Gabby raised the same question with respect to adding a 
vallist to @type on <provenance> and I didn't get round to replying to 
him yet.

But fwiw, I think supplying valLists in the P5 source is, in general, a 
bad idea. That is something which projects should be encouraged to do 
for themselves in their own ODDs. The Guidelines should (in general) 
specify a datatype, and may (sometimes) provide a list of suggested 
values in order to indicate the intended semantics of the attribute, but 
the TEI per se is not in the business of enumerating all possible 
attribute value lists.

There is a case for being able to specify a different set of suggested 
values on some member of a class than that it would otherwise inherit. 
This typically arises where the inherited attribute is too vague in its 
semantics (@type being a notable offender here, which is one reason I 
dislike its use as a panacea) and at present the appropriate syntactic 
mechanism for resolving it is to redefine the attribute locally.

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.


On 30/09/11 10:13, Sebastian Rahtz wrote:
> James and I met this last night again.
>
> look at<abbr>. instead of being a member of att.typed, it defines its own
> @type attribute, because it wants to supply a<valList>.  What one would like
> to do is say<attDef mode="change" ident="type">  inside the original source
> of P5. We can't do that now, because the processing does not support it at all,
> but in general, do people believe that it _should_ work?
>
> frankly, I have not a clue about how to implement this, but if its a serious
> problem I should try.
> --
> Stormageddon Rahtz
> Head of Information and Support Group
> Oxford University Computing Services
> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>
> Sólo le pido a Dios
> que el futuro no me sea indiferente
>
> _______________________________________________
> tei-council mailing list
> tei-council at lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>
> PLEASE NOTE: postings to this list are publicly archived



More information about the tei-council mailing list