[tei-council] @key to be deprecated?

[David Sewell]

Should the issue of deprecating @key be submitted for discussion to 
TEI-L before any final decision is made? So far as I can see, this has 
been mentioned only once on TEI-L in posts by Gabby and James, see 
http://listserv.brown.edu/archives/cgi-bin/wa?A2=ind1102&L=TEI-L&P=R297

David

On Tue, 20 Sep 2011, Martin Holmes wrote:

> OK, I'm becoming convinced on this. It looks like we need a ticket in
> SF, along the lines of:
>
> 1. @key will be deprecated. (Still not exactly clear on that process.)
>
> 2. @ref will be added wherever @key is currently allowed, but @ref is not.
>
> 3. All examples showing @key will be changed to show @ref, and magic
> tokens without colons will be replaced with magic tokens that have colons.
>
> 4. The documentation for @ref will be expanded to include an explanation
> and examples of URIs which are not URLs (by which I presume we mean:
> URIs which do not resolve to anything that can be located on the network).
>
> Have I missed anything? Does this replace or subsume any existing tickets?
>
> Cheers,
> Martin
>
> On 11-09-19 08:49 AM, James Cummings wrote:
>> On 19/09/11 16:12, Martin Holmes wrote:
>>> Hi James,
>>
>> Hi Martin,
>>
>>>> I'll play devil's advocate on this. I think using URIs (in the
>>>> form of URNs), even just locally constructed ones like
>>>> foo:blort:1234 is a much better system than just bare keys which
>>>> are just as much magic.
>>>
>>> Isn't foo:blort:1234 just magic too? If I've understood the proposal
>>> correctly, foo: and blort: don't resolve to anything meaningful; isn't
>>> foo:blort:1234 just a magic key that happens to have colons in it?
>>
>> Yes, that is what I meant be 'just as much magic'. They are both
>> magic. However, the URN-style magic key is a faceted one. (I know
>> you could just make your @key value do this as well.)
>>
>>> Backward-compatibility is the obvious one.
>>
>> Yes, agreed.
>>
>>> In that case, we're going to have an escalating tension between the
>>> Birnbaum doctrine and the need to clean up problems in P5 (like this
>>> one, perhaps, if you see it as a problem).
>>
>> Perhaps, but the Birnbaum Doctrine doesn't say that we're not
>> allow to break backwards compatibility, just that we should have
>> a deprecation structure to do so.
>>
>>> You actually caught me doing that (inadvertently) in an early version of
>>> the Image Markup Tool, IIRC.
>>
>> Oh yes, I remember that, naughty Martin. :-P (He says quickly
>> hiding any of his code where he certainly sins in greater orders
>> of magnitude.)
>>
>>> And I agree that's completely wrong when
>>> using @ref; but I would argue that's why @key is helpful. When you're
>>> still working out the structure of your repository and the relative
>>> locations of files and subcollections, not having to be precise about
>>> the path to a particular @xml:id is very handy.
>>
>> Surely since you *can* do this ref="foo" then people will just do
>> that while they are still working out their repository structure
>> or system of magic keys?
>>
>>> And if you get rid of
>>> @key, people are just going to use @n for the same job, I bet.
>>
>> What people abuse @n for something that is not a potentially
>> non-unique number or other label, but instead some magic token to
>> identify specific classes of elements?  Never... no one would
>> ever do that!  I mean that would be like using @rend to refer to
>> _output_ rendition not source rendition. *grin*  Erm, yeah, ok, I
>> see your point. People would certainly do that, yes.
>>
>> I still think using a URN-like URI on @ref is better because it
>> forces you to consider _some_ form of classification or
>> documentation principle. But yours are all good arguments for
>> maintaining @key.
>>
>> -James
>>
>
>

-- 
David Sewell, Editorial and Technical Manager
ROTUNDA, The University of Virginia Press
PO Box 400314, Charlottesville, VA 22904-4314 USA
Email: dsewell at virginia.edu   Tel: +1 434 924 9973
Web: http://rotunda.upress.virginia.edu/