[tei-council] attribute names used in classes which are duplicated on elements

[Martin Holmes]

On 13-01-08 10:21 AM, Sebastian Rahtz wrote:
>
> On 8 Jan 2013, at 18:15, Martin Holmes <mholmes at uvic.ca>
>   wrote:
>>>   <g>/@ref is pretty much the same as att.canonical/@ref, but if we
>>> add <gi> to att.canonical, it gains @key as well.  Is that a
>>> Good Thing or a Bad Thing? obviously we can have the status quo,
>>> by adding <attDef ident="key" mode="delete"/> to <g>
>>
>> I don't think we should add @key to anything, given that we're thinking
>> of deprecating it.
>>
> but when we do so, we'll deprecate it in att. canonical,
> so it will apply to everyone. arguably more honest.

True, but in the meantime we'd be providing a new opportunity for people 
to use @key in a new context, only to deprecate it soon after.

>>> Then at a second stage someone can go in and action each case.
>>
>> One question I raised on the ticket was that with @type and @target,
>> more than one class exists. Should we be aiming to collapse those
>> classes into one?
>
> at first blush, simply too hard, IMHO
>
> we can either
>
>    a) do the simpler cases first, and leave @type
> or
>    b) tackle @type head on and clean up others at leisure
>
> my innate laziness suggests a), but b) is equally sensible.

+1 for laziness and low-hanging fruit. I think @type is a different 
species of problem, to be honest. I've always felt that @type and 
@subtype should be generic attributes with no suggested values in 
att.global, and where we're inclined to suggest or prescribe values, a 
separate attribute should be created with a more precise name -- 
list/@format, factuality/@value, or whatever.

Cheers,
Martin

> --
> Sebastian Rahtz
> Director (Research Support) of Academic IT Services
> University of Oxford IT Services
> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>
> .
>

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)