[tei-council] @key to be deprecated?

[Lou Burnard]

I'm not sure that I agree with Martin's analysis.

a) Are there any places where @key is permitted but not @ref? if there 
are, then I agree that @ref should be added as an alternative

b) Changing *all* examples using @key to examples using @ref seems like 
an over reaction to me though I agree that we need to increase the 
number of examples using @ref=my:uri:notation

I had interpreted the sense of the preceding discussion to be that we 
understood why people might want to supply a privately magic token as 
the value for @key but that they needed to be reminded that an 
alternative slightly less magical option would be to use @ref with the 
proposed URI syntax.




On 20/09/11 16:19, David Sewell wrote:
> 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
>>>
>>
>>
>