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

[Martin Holmes]

On 13-01-08 12:57 PM, Lou Burnard wrote:
> On 08/01/13 18:35, Martin Holmes wrote:
>>
>> 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.
>
> Maybe we might revise our view on the heinousness of @key ? (cf recent
> discussion about lb/@ed)

I don't think I'm going to revise my view, to be honest. I don't think 
it's heinous; I just think better options exist (private uri schemes + 
dereferencing mechanisms), and I think that as we're continually 
expanding the TEI in response to needs, we should also be trying to 
deprecate and eventually remove cruft.

The discussion of lb/@ed concluded that we should keep @ed for backwards 
compatibility, but add @edRef because it's better; then eventually we 
can deprecate @ed too.

Cheers,
Martin

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